opengeospatial / ogcapi-features

An open standard for querying geospatial information on the web.
https://ogcapi.ogc.org/features
Other
335 stars 83 forks source link

Question regarding "Draft proposal "Query by IDs"" #839

Open sebastianfrey opened 1 year ago

sebastianfrey commented 1 year ago

@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!

aaime commented 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.

cportele commented 1 year ago

@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?

sebastianfrey commented 1 year ago

@cportele Thank you for the quick response. That's great to know. I am looking forward to hearing the result.

pvretano commented 1 year ago

@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!

cportele commented 1 year ago

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.

cportele commented 1 year ago

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.

pvretano commented 1 year ago

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