Intersects as its own mini-extension?

[cholmes]

In STAC API we have an intersects query parameter, see our query param table. It sits between a BBOX and the full CQL 'intersects', and is in some ways the best of both worlds. It doesn't require the user to specify the name of their geometry like CQL does, instead just using the default like BBOX does. But it takes a full GeoJSON, and will give you a real geometry operation instead of just rough bounds.

Our community generally wants to keep it even if we adopt CQL. I'm aiming to align things with OGC as much as possible, so an ideal for me would be if it is defined as a small Features API extension that anyone (including STAC implementors) can use.

With this we can probably get rid of the proposes 'intersects' geometry class in #579, since it'd be covered here in an even easier to use / implement way.

I don't think we're set on GeoJSON, it could just as easily be Well known Text, and maybe that would fit better with CQL?

If there's interest in this I'm happy to write up a PR with the extension. I think this would make an ideal 'building block' for various API implementations.

[cportele]

This could be a useful, separate extension that sits somewhere between Core and CQL. Three thoughts:

• For cases where the request is sent as a JSON document in the body, it should be GeoJSON. For cases where the request is a GET request and intersects would be a query parameter, WKT would be better. This is consistent with the CQL approach where spatial geometries are GeoJSON in CQL JSON and WKT in CQL Text.
• For servers supporting Part 2 (CRS), we also would need to have a mechanism to declare the CRS of the geometry unless we would restrict it to WGS84 only. For bbox there is bbox-crs, for filter there is filter-crs.
• If we add such a capability, it could be worth to discuss to have an option where the geometry is not provided inline, but is referenced by a URI. The URI could reference a GeoJSON feature or geometry. This could be via a Features API or just a static document in an S3 bucket, etc.

[pvretano]

@cportele we already discussed this some time ago ... @cholmes proposal kinda follows a discussion we were having early on about several levels of query capability. At that time we discusses that:

• bbox/datetime/propeq would represent the lowest level of query capability
• something like OpenSearch would represent the next level of query capability
• CQL, would represent the top level of query capability

What distinguishes one level of capability from the next is the amount of control the client has in directing how the query is processed.
At the lowest level, the client has very little control. He/she can't, for example, indicate which spatial property the bbox should be applied to and they can only use and INTERSECTS and only use an envelope.
At the next level of capability, the client have more control. He/she can, for example, specify and non-box geometry and maybe even the specific operator to apply but still has no control over which property the predicate is applied to.
Finally, at the top level -- CQL for example -- she/he has full control over which operators to use, which properties to apply predicates to, the ability to logically combine predicates with something other than AND, etc.

So, in short, I think I support @cholmes idea ... although I think that middle level of capability, the one that sits between CORE and CQL should be a bit more than just INTERSECTS. OpenSearch Geo might be a good starting place to figure out the level of capability to add to this middle level. B.T.W. Records is taking this approach an support CORE-level query capability, OpenSearch-like query capability and full CQL capability ... all is separate conformance classes of course.

[philvarner]

@cholmes said

With this we can probably get rid of the proposes 'intersects' geometry class in #579, since it'd be covered here in an even easier to use / implement way.

I don't think this would get rid of the need for that class, as the the CQL intersects geometry class is composable with other predicates through the logical operators, whereas this proposed mini-extension would only be a conjunctive filter like bbox.

[cholmes]

I don't think this would get rid of the need for that class, as the the CQL intersects geometry class is composable with other predicates through the logical operators, whereas this proposed mini-extension would only be a conjunctive filter like bbox.

Ah, good point.

[cholmes]

For cases where the request is sent as a JSON document in the body, it should be GeoJSON. For cases where the request is a GET request and intersects would be a query parameter, WKT would be better. This is consistent with the CQL approach where spatial geometries are GeoJSON in CQL JSON and WKT in CQL Text.

+1 - I only realized at the very end of that comment that it could be GeoJSON or WKT. I like WKT for GET and GeoJSON geometry fro POST

For servers supporting Part 2 (CRS), we also would need to have a mechanism to declare the CRS of the geometry unless we would restrict it to WGS84 only. For bbox there is bbox-crs, for filter there is filter-crs.

Seems reasonable. I suppose for JSON we need the results of the new geospatial JSON SWG, since geojson doesn't give an option.

If we add such a capability, it could be worth to discuss to have an option where the geometry is not provided inline, but is referenced by a URI. The URI could reference a GeoJSON feature or geometry. This could be via a Features API or just a static document in an S3 bucket, etc.

I don't know that it makes sense in the 'core', as that seems to me to be a much higher implementation burden, for the server to have to make network calls out. But I agree it can be useful, especially combined with a good gazeteer / geocoder - let people use a URL like https://www.google.com/maps/place/Antioch,+CA/ (if that response returned a GeoJSON).

[cholmes]

So, in short, I think I support @cholmes idea ... although I think that middle level of capability, the one that sits between CORE and CQL should be a bit more than just INTERSECTS. OpenSearch Geo might be a good starting place to figure out the level of capability to add to this middle level. B.T.W. Records is taking this approach an support CORE-level query capability, OpenSearch-like query capability and full CQL capability ... all is separate conformance classes of course.

Yeah, as long as it's separate conformance classes I think it's ok. Though I maybe go a bit further, wanting them as separate 'building blocks', ie not all in one big document. But I can see it being very valuable to have those three 'levels' that we explain to implementors.

I'd like to go ahead and start writing this up. Should I do it as a PR in features API repo? And like make it a new 'part'? Or just a stand alone repo?

[aaime]

Making requests out is often easy in most modern languages. However, allowing connection to whatever user provided host can be used to mount a Server Side Request Forgery attack. Adding the machinery to handle a white list of potential hosts that the server can actually connect to, now that's indeed more complicated.

[pvretano]

@cholmes create the PR in this repo. Create a sub directory in the proposals directory and write up your proposal there.