Open sebastianfrey opened 1 year ago
Also wondering if there is any relationship with the "externalIds" parameter in Records... syntax and execution seems to be similar to the "ids" one, but the semantic is maybe not a match.
@sebastianfrey - We have not really had a discussion about the proposal yet (the same is true for most other proposals, the focus has been lately on moving the candidate standards forward and clarify questions on the approved standards). The next working group meeting is on 3 July, I will put it on the agenda.
Personally, I support the proposal, it consider it a fundamental capability. In that sense, maybe it belongs into Part 1 (as a new conformance class) in a version 1.1?
With respect to the discussion item, I would treat ids
as just another filter query parameter and use a logical AND
with the filter expressions from all the other filter query parameters.
@aaime - As far as I understand it, this is different. ids
would operate on the featureId
while externalIds
are other identifiers associated with a record. @pvretano, is this correct?
@cportele Thank you for the quick response. That's great to know. I am looking forward to hearing the result.
@aaime @cportele correct. externalIds
are identifiers, external to the catalogue, assigned to the resource that a record is describing. The only relationship with Feature would be this ... say I have a record in the catalogue that is describing a feature that is offered by a Feature server. The feature id of that feature could be in the list of externalIds
in the record.
As for the Query by IDs
proposal ... agreed ... there should be an ids
parameter that would allow querying multiple features by id in a single request ... although we should be clear that the value of the ids
parameter would be a list of local featrure ids ... otherwise it get a bit unwieldy if we use the URIs of the features!
As for the Query by IDs proposal ... agreed ... there should be an ids parameter that would allow querying multiple features by id in a single request ... although we should be clear that the value of the ids parameter would be a list of local featrure ids
Yes, of course, these must be only the values of the featureId
path parameter, aka the local feature ids.
Meeting 2023-07-03: We agree that this is a fundamental capability and should be in a new conformance class in Part 1 (version 1.1). It will be another filter parameter that will be combined with a logical AND with the other filter parameter.
Just to lend support to the proposal, we have an implementation of this ... https://www.pvretano.com/cubewerx/cubeserv/default/ogcapi/foundation/collections/coastl_bnd_1m/items?f=json&ids=CWFID.COASTL_BND_1M.0.9135,CWFID.COASTL_BND_1M.0.1310,CWFID.COASTL_BND_1M.0.623
@cportele Around a year ago I have submitted the draft proposal Query by IDs with PR https://github.com/opengeospatial/ogcapi-features/pull/691.
Now I am interested in implementing that proposal in the GeoServers OGC API community plugin. For more details see here.
As suggested by @aaime in the linked Jira issue, it would be good, to check with you, if the proposal is still considered as useful by the committee and the direction of the proposed API is not considered as totally off the track.
I am looking forward for your feedback on that.
Thank you very much!