Inconsistency in in /cube coords requirements
Closed this issue · 3 comments
There are seemingly inconsistencies in the cube description in the standard, and the formal requirements for all query types in terms of the coords query parameter requirement. It is well described for all geometry based resources except Cube. Our findings in the standard are:
We can see, that coords is meant to be a shared parameter as stated in section 8.2.1 and further defined in section A.2.5 :
8.2.1. Shared query parameters
Query parameters are used in URLs to define the resources which are returned on a GET request. The following are defined as standard shared parameters for use.
8.2.1.1. Parameter coords
A.2.5. Requirement /req/edr/coords-definition Parameter coords definition
Requirement A.9
/req/edr/coords-definition
A:
Each geometry based resource (Position, Radius, Area, Cube , Trajectory, Corridor) collection operation SHALL support a parameter coords with the following characteristics (using an OpenAPI Specification 3.0 fragment):
We can also see examples of coords usages in all the sections describing the geometry based resources, (Position, Radius, Area, Cube , Trajectory, Corridor), fx. in section 8.2.2.1 for the position query, which could be coords=POINT(0 51.48), but for Cube (section, 8.2.5) there is no such example. So, if coords usage is intended, the coords parameter for cube queries is underspecified.
Furthermore requirement A.61 (/req/edr/rc-cube) does not require the coords parameter as a query parameter. For all other query requirement classes (A.59, A.60, A.62, A.63 (sidenote, is radius missing a requirements class here?)), fx A.60, such an requirement is stated as "An area GET operation MUST include a coords query parameter". This seems like a contradiction in the standard.
On the other hand does Abstract test 77 test (in the B.10.1.3. Cube section) require that there is a coords parameter
This leads us to the following question in terms of implementing EDR as of now:
Is it true, that a coords parameter can be used together with a /CUBE call and if so, how should it be used ?
It is an error in the requirement, left over from the development of EDR. The Cube query does not support the coords parameter as a WKT Polygon cannot be limited to having four sides.
@CarstenTeichert We have removed the erroneous text, which should now be self-consistent.
Are you happy to close this issue, please?
I can confirm that both of the Abstract Tests that specified coords parameter tests in Cube queries have been removed.
Closing the issue.