Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

for bbox query parameter, 3d bboxes and invalid bbox values return 500 instead of 400 #222

Closed
philvarner opened this issue Aug 11, 2021 · 3 comments · Fixed by #235
Closed

Comments

@philvarner
Copy link
Collaborator

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:

  • GET Search with bbox=100.0,0.0,0.0,105.0,1.0,1.0 returned status code 500
  • POST Search with bbox:[100.0, 0.0, 0.0, 105.0, 1.0, 1.0] returned status code 500
  • GET Search with bbox=[100.0, 0.0, 105.0, 1.0] returned status code 500, instead of 400
  • GET Search with bbox=param (lat 1 > lat 2) returned status code 500, instead of 400
  • GET Search with bbox=0 returned status code 500, instead of 400
  • GET Search with bbox=0,0 returned status code 500, instead of 400
  • GET Search with bbox=0,0,0 returned status code 500, instead of 400
  • GET Search with bbox=0,0,0,1,1 returned status code 500, instead of 400
  • GET Search with bbox=0,0,0,1,1,1,1 returned status code 500, instead of 400

This was tested with a local docker-compose instance of stac-fastapi-sqlalchemy.

@moradology
Copy link
Collaborator

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

@philvarner
Copy link
Collaborator Author

yes, 6 number bbox is 3d.

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.

@moradology
Copy link
Collaborator

That sounds like a reasonable compromise. I'll add that and drop the 501

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants