CRS:84 is shown FIRST in the WMS GetCapabilities even if it is not declared, causing delays in providing the response

Description

Even if trough https://osgeo-org.atlassian.net/browse/GEOS-1830 it is now possible to limit the number of CRS exposed in the GetCapabilities document of the WMS, the bounding box of the data in CRS:84 appears first in the list in the GetCapabilities document even if the CRS:84 is not provided in the list of supported CRS in the Geoserver interface.

Because the CRS:84 is shown FIRST in the list, the INSPIRE Validator assumes this is the default CRS in which the data is stored in the database and consequently the test fails to provide the image in due time for a large database.

In section 7.2.4.6.8 BoundingBox of the WMS standard is written ”A Layer shall not provide a BoundingBox for a CRS it does not support. Conversely, a Layer may support CRSs for which it does not provide a BoundingBox: a server that has the ability to transform data to different CRSs may choose not to provide an explicit BoundingBox for every possible CRS available for each Layer. The server should provide BoundingBox information for at least the native CRS of the Layer (that is, the CRS in which the Layer is stored in the server’s database). ”

We assume that the first one listed CRS should be default one in which the data is stored in the database.

In INSPIRE the native/default CRS should not be in any case CRS:84.

So either CRS:84 should not be provided at all in the GetCapabilities document if it is not listed by the user as supported CRS, either if there is a reason to keep this CRS:84 in the GetCapabilities document, then it should be the LAST one in the list (and not the FIRST as it is now).

Example: Only 3035, 3857, 4258 & 4326 CRS are declared, but the request http://gmlid.eu/RO/ENV/PADS/WMS?service=WMS&request=GetCapabilities is listing CRS:84 bounding box FIRST in the list.

<BoundingBox CRS="CRS:84" minx="19.89845971056449" miny="42.60851659662052" maxx="31.920387534192024" maxy="48.91485268358077"/>
<BoundingBox CRS="EPSG:3035" minx="2387242.0" miny="5112395.5" maxx="2925234.25" maxy="5954230.5"/>
<BoundingBox CRS="EPSG:3857" minx="2215086.4025505083" miny="5252572.658584902" maxx="3553361.2862302135" maxy="6260426.012935738"/>
<BoundingBox CRS="EPSG:4258" minx="42.60851659662052" miny="19.89845971056449" maxx="48.91485268358077" maxy="31.920387534192024"/>
<BoundingBox CRS="EPSG:4326" minx="42.60851663710712" miny="19.898459710564484" maxx="48.914852723390496" maxy="31.920387534192024"/>

Iurie

Environment

None

Attachments

1

Activity

Iurie Maxim 
January 31, 2023 at 7:49 PM

@Jukka Rahkonen that’s great

Jukka Rahkonen 
January 31, 2023 at 4:37 PM

With Geoserver 2.22.1 CRS:84 is the last on the list

Andrea Aime 
June 5, 2018 at 4:26 PM

Limited SRS lists are just shortening the capabilities document, all request can still be made successfully against any non listed CRS.

Jakub Balhar 
June 4, 2018 at 5:09 PM

Based on the code in the Capabilities_1_3_0_Transformer, the CRS:84 is always added as the default after the limited list is processed. The relevant code is on line 786:

{{
// the default CRS:84
element("CRS", "CRS:84");
}}

Is it possible that even if the CRS:84 isn't on the list the GeoServer will accept it for future requests to WMS?

Iurie Maxim 
May 14, 2018 at 5:38 PM

Sorry for writing WFS. My mistake. i ment WMS.

Fixed

Details

Assignee

Reporter

Priority

Created May 14, 2018 at 7:41 AM
Updated January 31, 2023 at 7:49 PM
Resolved January 31, 2023 at 4:37 PM