Clarification Needed for /locations Endpoint in OGC API - EDR Specification

[webb-ben]

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?

[m-burgoyne]

@webb-ben /locations/{locationid} is the correct usage for accessing specific location data. /locations?locationId={locationId} is not a valid EDR locations query

[webb-ben]

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?

[m-burgoyne]

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.

[dblodgett-usgs]

The current spec appears to suggest using /locations?locationId={locationId}

Where do you see that in the spec?

[webb-ben]

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.

[webb-ben]

As a related/aside, as I update geopython/pygeoapi#1776, is z a valid query paramter for locations?

[dblodgett-usgs]

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.

I see -- yeah, locationId being listed as a query parameter in table 13 seems wrong, I agree..

[m-burgoyne]

The current EDR specification does not include a z query parameter for the locations query