Implement Requirement Class "Search" from OGC API - Features Part 5 proposal
Description
None
Environment
Currently the OGC API - Features plugin allows only to query features through HTTP GET via the /collections/{collection}/items resource. Querying features with HTTP GET works fine for simple bounding box querys or small CQL filters. As soon as a client tries to filter by larger geometries like cadastral borders or rivers things go bad. The reason for that is, that the amount of vertices of such filter geometries blows up the max http header size of the underlying servlet container very fast. Sure, increasing the max http header size might be a work around, but it does not scale well. In addition it is also a security risk to increase the max http header size to far.
So if you are interested in adding this functionality to the plugin, I am willing to provide a PR for it.
Activity
Sebastian Frey July 18, 2023 at 10:39 AM
Edited
Ok. I have already looked into the search part of the STAC module. Basically they could share the SearchQuery bean, but there is problem which makes that right now not possible:
In STAC the filter is built with org.geotools.data.Query, which leverages int for parameters such as limit or startIndex. In contrast, OGC API - Features is built on top of org.geoserver.wfs.GetFeature, which leverages BigInteger for parameters such as limit or startIndex. That means, if I try to introduce a common SearchQuery bean, the Query class of GeoTools also has to be modified. IMO that’s something bigger, so I will only take inspiration from STAC rather than migrating it to a common basis.
Hope that’s ok.
Andrea Aime July 18, 2023 at 8:03 AM
Go for it. Mind we already have a “search” in the STAC module, it may be different, but at the very least, there is something to get inspiration from (and if it’s similar enough, the common classes can be moved to ogcapi-core.
Currently the OGC API - Features plugin allows only to query features through HTTP GET via the
/collections/{collection}/itemsresource. Querying features with HTTP GET works fine for simple bounding box querys or small CQL filters. As soon as a client tries to filter by larger geometries like cadastral borders or rivers things go bad. The reason for that is, that the amount of vertices of such filter geometries blows up the max http header size of the underlying servlet container very fast. Sure, increasing the max http header size might be a work around, but it does not scale well. In addition it is also a security risk to increase the max http header size to far.Because of that, I propose the implementation of the OGC API - Features - Part 5: Requirements Class "Search" in the OGC API - Features plugin. I did also some research regarding the status of the proposal and found the following statement https://github.com/opengeospatial/ogcapi-features/issues/771#issuecomment-1508048697. As stated out in the linked comment the
searchendpoint of Part 5 seems to be the go-to way for querying features via POST.So if you are interested in adding this functionality to the plugin, I am willing to provide a PR for it.