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
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.
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
https://api.ohsome.org/v1
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)?
The text was updated successfully, but these errors were encountered: