EDR version 1.1 comment: WGS84 as requirement is unclear
Closed this issue · 5 comments
Requirement:
/req/core/crs84 and Abstract Test 8
Implementation Specification Section number:
Coordinate Reference Systems, Section 9.6
Comments/justifications for changes:
It's currently unclear whether or not CRS84 or CRS84h is required CRS to support. As the standard states in Section 9.6:
For the reasons discussed in the Best Practices, EDR APIs SHOULD support WGS84 longitude and latitude (http://www.opengis.net/def/crs/OGC/1.3/CRS84) as a coordinate reference system.
The wording SHOULD leads us at DMI believe that CRS84 is optional, but strongly encouraged. Together with requirement /req/core/crs84 it leads one to believe that ONLY IF WGS84 is supported, then /req/core/crs84 applies, and therefore CRS84 should be the default CRS in case of the crs query parameter not being specified by the client. However, Abstract Test 8 states:
Validate that all spatial geometries provided through the API are in the http://www.opengis.net/def/crs/OGC/1.3/CRS84 coordinate reference system unless otherwise requested by the client.
The way DMI understands the standard, this leaves no room for NOT implementing CRS84. The standard should either change the paragraph in section 9.6 so SHOULD -> SHALL, or change Abstract Test 8.
DMI are looking to use the standard to provide a query interface to its forecast data, which are not using CRS84 as its native CRS. DMI would like to keep CRS84 optional, so that it is possible to create a compliant API without the need to re-project all coordinates and return non-grid data. CRS84 support could then be implemented in a future version of the API. For context, here is an issue showing the kind of data and CRS we are working with: opengeospatial/CoverageJSON#159.
As a sidenote, this issue is also present in the currently published version of the standard, v1.0.1.
@petergarnaes the error is in the Abstract test, CRS84 is optional but encouraged in EDR recognising that there will be data results that cannot be represented in the coordinate system.
Just in case we need to issue a V1.0.2 before V1.1.
Close when V1.0.2 created.
@petergarnaes This has been corrected in V1.1, and also in a change to V1.0 (V1.0.2) if required,.
Are you happy to close this issue please?
Fixed in PR#443 for V1.1 publication