You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Slightly tangential to the original issue, but perhaps relevant when implementing a fix: It looks like support for 3D bounding boxes (I assume that's what a 6 numbered bbox is for) hangs on shapely's lack of support for z-coordinates. What I'm wondering is whether a 501 (not implemented) response would be appropriate when such bboxes are used
501 isn't appropriate, because that's only when the request's method is not supported. I think 400 is probably the right response to use. The drawback is that it technically makes it non-compliant with STAC API. We inherit this from OGC API - Features Part 1, so it would be better not to change it, but this was definitely put in there without enough consideration for the implementation implications.
However, if your datastore only has 2d data, you can just drop the elevation params and use the 2d bbox with shapely, since a 2d geometry is assumed to have "infinite" elevation in either direction.
bbox parameters may be either 4 or 6 numbers. Other values are invalid, and should return a 400. Instead, a 500 is returned with these values:
This was tested with a local docker-compose instance of stac-fastapi-sqlalchemy.
The text was updated successfully, but these errors were encountered: