Open webb-ben opened 2 months ago
@webb-ben /locations/{locationid}
is the correct usage for accessing specific location data. /locations?locationId={locationId}
is not a valid EDR locations query
I presume what is different about the locations query is that you can still filter by time and parameter?
i.e. /locations/{locationId}?datetime=2020
?
Yes, that is correct. The locations id is basically an identifier for a predefined set of spatial coordinates, and the user can define datetime, parameter-name, CRS and format as part of the request.
The current spec appears to suggest using /locations?locationId={locationId}
Where do you see that in the spec?
When reading the description about /items
, it is clear there are more than paths in the URL pattern, one for requesting a FeatureCollection
, and on that will return a Feature
.
The next section on /locations
, proceeds to acknowledge a similar behavior, but instead listing the additional URL path within the query structure table. Table 13 seems to be the only table that implements path elements of a URL inside the query argument table.
I understand it may be a bit more complicated than the OAF specification, because the single location at /locations/{locationId}
still allows for those query parameters to be used in addition to the single item.
As a related/aside, as I update https://github.com/geopython/pygeoapi/pull/1776, is z a valid query paramter for locations?
When reading the description about
/items
, it is clear there are more than paths in the URL pattern, one for requesting aFeatureCollection
, and on that will return aFeature
.The next section on
/locations
, proceeds to acknowledge a similar behavior, but instead listing the additional URL path within the query structure table. Table 13 seems to be the only table that implements path elements of a URL inside the query argument table.I understand it may be a bit more complicated than the OAF specification, because the single location at
/locations/{locationId}
still allows for those query parameters to be used in addition to the single item.
I see -- yeah, locationId
being listed as a query parameter in table 13 seems wrong, I agree..
The current EDR specification does not include a z query parameter for the locations query
I am seeking clarification on the usage of the
/locations
query in the OGC API - EDR specification. There seems to be ambiguity regarding whether the endpoint should support a RESTful pattern like /locations/{locationId} for accessing specific location data. This pattern is not explicitly mentioned in the documentation, which has led to confusion.The current spec appears to suggest using
/locations?locationId={locationId}
, but this approach feels less intuitive and deviates from typical RESTful practices. Additionally, we're wondering if the/locations
endpoint is intended to follow a similar pattern to the/items
query, where specific items can be accessed via a direct path.Could you clarify if
/locations/{locationId}
should be supported as part of the standard, similar to how /items queries work?