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
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
I noticed that this is different behaviour from the MapQuest Nominatim endpoint, which for the same query returns a much larger bounding box that neatly fits 'London':
Is this a bug or a configuration decision? The MapQuest behaviour is a lot more intuitive and it makes the MapQuest endpoint a lot more suitable for my particular use-case.
The text was updated successfully, but these errors were encountered:
Author: craigloftus [Added to the original trac issue at 11.09am, Thursday, 27th December 2012]
I had thought it might be a data issue, however, I checked several other places for comparison and got the same result. London is fixed for me now, but the other examples I found are still 'broken', so I guess there is something wrong with their data?
Another example of a different boundarybox result is for Kidlington:
Reporter: craigloftus
[Submitted to the original trac issue database at 3.05pm, Friday, 21st December 2012]
When making a search request such as:
http://nominatim.openstreetmap.org/search?format=json&q=London&countrycodes=gb&limit=1
The boundingbox returned does not correspond with any 'boundary' of London, but just describes a small box around the place node.
boundingbox: ["51.5072746276855","51.5072784423828","-0.12765970826149","-0.127659693360329"]
I noticed that this is different behaviour from the MapQuest Nominatim endpoint, which for the same query returns a much larger bounding box that neatly fits 'London':
boundingbox: ["51.286190032959","51.6918830871582","-0.511035442352295","0.334359914064407"]
Is this a bug or a configuration decision? The MapQuest behaviour is a lot more intuitive and it makes the MapQuest endpoint a lot more suitable for my particular use-case.
The text was updated successfully, but these errors were encountered: