Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
groldan opened this issue Nov 13, 2024 · 2 comments · May be fixed by #255
Assignees

Comments

@groldan
Copy link
Contributor

groldan commented Nov 13, 2024

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

image image

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
Copy link
Contributor

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?

@dstenger dstenger added this to CITE Nov 14, 2024
@github-project-automation github-project-automation bot moved this to To do in CITE Nov 14, 2024
@dstenger dstenger moved this from To do to In progress in CITE Nov 14, 2024
@groldan
Copy link
Contributor Author

groldan commented Nov 14, 2024

Hi, I'm about to issue a pull request

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: To verify
3 participants