-
Notifications
You must be signed in to change notification settings - Fork 26
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
Clarification Needed for /locations Endpoint in OGC API - EDR Specification #568
Comments
@webb-ben |
I presume what is different about the locations query is that you can still filter by time and parameter? i.e. |
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. |
Where do you see that in the spec? |
When reading the description about The next section on I understand it may be a bit more complicated than the OAF specification, because the single location at |
As a related/aside, as I update geopython/pygeoapi#1776, is z a valid query paramter for locations? |
I see -- yeah, |
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?The text was updated successfully, but these errors were encountered: