GIScience/ohsome-api

IDL crossing bboxes neither caught nor handled

SlowMo24 opened this issue · 1 comments

SlowMo24 commented

Bug Description

When requesting a IDL-crossing bbox the result is wrong, the inverted bbox is queried (doing some sorting magic on the bbox parameters internally?).

General Information

  • Version of the ohsome API 1.6.3
  • remote instance at https://api.ohsome.org/v1
  • Affected endpoint(s): all
  • URL of your request: see below
  • Used HTTP method: GET
  • Utilized tool/library for the request: swagger

Expected Behaviour

  • The bbox should either be queried correctly (split into its eastern and western part) or

  • the user should get a format issue for the bbox or

  • the documentation should explicitly mention this behaviour. Currently one has to combine "

    Bottom left and top right points to define a bounding box. The following two formats are allowed:

    lon1,lat1,lon2,lat2|lon1,lat1,lon2,lat2|…" to know that lon1=minX

IDL crossing bbox

https://api.ohsome.org/v1/elements/count?bboxes=160.0%2C0.0%2C-160.0%2C0.001&filter=geometry%3Apoint&format=json&time=2014-01-01

Result: 232
Expected result: 0

inverted bbox

https://api.ohsome.org/v1/elements/count?bboxes=-160.0%2C0.0%2C160.0%2C0.001&filter=geometry%3Apoint&format=json&time=2014-01-01

Result: 232
Expected result: 232

"western" part of IDL crossing bbox

https://api.ohsome.org/v1/elements/count?bboxes=-180.0%2C0.0%2C-160.0%2C0.001&filter=geometry%3Apoint&format=json&time=2014-01-01

Result: 0
Expected result: 0

"eastern" part of IDL crossing bbox

https://api.ohsome.org/v1/elements/count?bboxes=160.0%2C0.0%2C180.0%2C0.001&filter=geometry%3Apoint&format=json&time=2014-01-01

Result: 0
Expected Result: 0

Notes

Does this behaviour come from upstream (OSHDB)?

tyrasd commented

the cause for this is that the ohsome API internally converts the user input bboxes to a (multi)polygon and uses that for the query. Since polygons' vertices are always assumed to not cross the 180° boundary, so the resulting effective request geometry is the "inverted" bbox.

I guess the best way to prevent this would be to check the user input and throw an error when the bounding box is crossing the 180° boundary.