Implement proposal "OGC API - Features - Part n: Query by IDs"

Yes, go ahead!

Understand, my comment was not meant in a offended way, but simply a statement of fact.

Regarding the discussions direction on the linked GitHub issue, implementing the draft proposal within GeoServers OGC API plugin seems ok, isn’t it?

Mind, my comment was not because of reputation, but because I’ve seen the process in action, which normally gets a lot of feedback only at the very end when a given “part” is nearing completion, or even more, when is considered done and ready to go. CQL2 got on public comments once, and received lots of feedback, to the point it go back to the drawing board and is now quite different from the first proposed structure (now CQL2 is complex and there is a lot to comment on, unlike selection by id, just want to point out that spec is not stable until it’s declared final).

Hi, thank you for coming back. I totally agree, that it should be implemented with caution, since it is a proposal backed by a me, without any notable reputation in the world of geo. That’s the reason, why I started this discussion.

As you have suggested, I started an attempt to get in contact with Clemens, to confirm that the committee is still on board. This is the link to the issue: .

When I provide the PR, I will document very clearly, that this feature is considered as an experimental implementation of a draft proposal. I am just not sure, where to put that warning. I can imagine to document it in directly in the plugins code somewhere, but also in the ids parameters OpenAPI description. So it should be clear for developers and consumers, that the parameter and its usage might change in the future.

Also I am not sure, how the conformance class for that feature should be named. I have something like this in mind

http://www.opengis.net/spec/ogcapi-features-x/1.0/req/ids

but I am not sure, if that’s the right direction. (Note: the x in ogcapi-features means extended/custom.)

Normally having a proposal backed by a single person is a red flag, but I see the initial discussion here and the PR being merged by specification leads, so there is at least some basic level of agreement that it may be useful. It also matches the existing functionality in WFS and seems to fit an obvious need.

However, we’d like to upgrade OGC API Features in the medium term, and having functionality that is not part of a stable specification is a problem, backward compatibility-wise. In your PR, can you document very clearly that this extra functionality is a proposal, and as such, it’s subject to change in the future? (a “use at your own risk” kind of warning).

Maybe also double-check with Clemens that they are still on board with this direction (it’s been over a year).