You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"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.
The text was updated successfully, but these errors were encountered:
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:
Whenever a collection's
crs
property is to be checked for an assertion, and if includes the global crs JSON pointer#/crs
, the globalcrs
needs to be expanded as part of the collection's declaredcrs
.Instead, the following test classes assume the global
crs
would be the single element in the collection'scrs
list, with conditionals likeif ( 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 testsScreenshots
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'scrs
, 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.The text was updated successfully, but these errors were encountered: