All tests asserting a collection's crs identifiers shall consider the global crs property if included as a JSON pointer

[groldan]

Describe the bug

According to 6.2.3. Global list of CRS identifiers, Requirement 5 /req/crs/fc-md-crs-list-global:

"If the crs property in the collection object of a spatial feature collection includes a JSON Pointer to the global list of CRS identifiers (#/crs), then all CRS identifiers in the global list SHALL be valid for the referencing collection."

And from the example on that same section:

Example 1. Collections object containing a global list of CRS identifiers

{
  "crs": [
     "http://www.opengis.net/def/crs/OGC/1.3/CRS84",
     "http://www.opengis.net/def/crs/EPSG/0/4326",
     "http://www.opengis.net/def/crs/EPSG/0/3857",
     "http://www.opengis.net/def/crs/EPSG/0/3395"
  ],
  "collections": [
     {
       "id": "bonn_buildings",
       "title": "Bonn Buildings",
       "description": "Buildings in the city of Bonn.",
       ...
       "crs": [
          "#/crs",
          "http://www.opengis.net/def/crs/EPSG/0/4258",
          "http://www.opengis.net/def/crs/EPSG/0/25831",
          "http://www.opengis.net/def/crs/EPSG/0/25832"
       ]
     }
  ]
}

Whenever a collection's crs property is to be checked for an assertion, and if includes the global crs JSON pointer #/crs, the global crs needs to be expanded as part of the collection's declared crs.

Instead, the following test classes assume the global crs would be the single element in the collection's crs list, with conditionals like if ( crs.size() == 1 && "#/crs".equals( crs.get( 0 ) ) ):

• DiscoveryCollectionsDefaultCrs (not covered by unit tests)
• DiscoveryCollectionsStorageCrs (not covered by unit tests)

Expected behavior For collections in the collections document containing both the #/crs JSON pointer and collection-specific crs identifiers to pass the tests

Screenshots

Additional context

In GeoServer in particular, the global list of published CRS codes can be configured at the global WFS/OGCAPI-Features level. Then for each collection, the storageCrs will be set in the collection's crs, as well as the #/crs pointer, hence adhering to the 6.2.3. Global list of CRS identifiers's purpose of "To prevent unnecessary duplication of lists of supported CRS identifiers in the collection object, a global list of supported CRS identifiers may be provided as part of the collections object.". But the current test suite will fail under those circumstances.

[dstenger]

Thank you for reporting. We will do further investigation. Is it possible to provide a test API we can use to test a potential fix?

[groldan]

Hi, I'm about to issue a pull request