Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#4723 closed defect (fixed)

boundarybox property returning fixed size, small boundaries for places

Reported by: craigloftus Owned by: geocoding@…
Priority: major Milestone:
Component: nominatim Version:
Keywords: Cc:


When making a search request such as:

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.

Change History (3)

comment:1 Changed 8 years ago by twain

Someone had added admin_level=2 to the node making it a country, I've removed this.

Because it was a country it was returned first in the listing and wasn't correctly linked to the city polygon for london.

comment:2 Changed 8 years ago by twain

Resolution: fixed
Status: newclosed

comment:3 Changed 8 years ago by craigloftus

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:


Which return




The place node for Kidlington is 5494559, which was last updated in July.

I don't see any properties on it that should obviously confuse Nominatim? Perhaps the partial postcode?

Note: See TracTickets for help on using tickets.