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.
Reporter: tom[at]acrewoods.net [Submitted to the original trac issue database at 11.29am, Thursday, 22nd December 2011]
The place name hierarchy is often a bit random in London, with its complicated and imperfectly mapped mess of place nodes and administrative boundaries.
Google seems to lump huge swathes under names such as "Camberwell", whereas Nominatim puts roads in all sorts of interesting places that are often several miles away.
This gets really confusing when you have a road comprised of several ways, e.g. because one part of the road is one-way or because a relation only applies to part of the road. These can show up multiple, different results.
Two examples local to me, where I've tried to make sure the place name hierarchy is fairly logical:
Ondine Road is NOT part of the Champion Hill estate (you have to travel via several other road connections to reach that estate) and again the two sections show different places (Walworth, New Cross Gate), both of which are considerably farther away than East Dulwich and Peckham (confusingly residents may claim to be part of either of those two places). http://open.mapquestapi.com/nominatim/v1/search.php?q=ondine+road&viewbox=-0.08%2C51.47%2C-0.06%2C51.45
If this is a problem with the map data, please describe how to correctly use nodes and boundaries to help Nominatim deal with cities with lots of local place names.
The text was updated successfully, but these errors were encountered:
Author: datendelphin [Added to the original trac issue at 11.01am, Sunday, 15th July 2012]
there was a bug in nominatim, see #4247.
But not all is due to this bug. With everything mapped only as a node, nominatim can not do better than an educated guess where the element belongs to. So for fixing map data, features need to be mapped as polygons.
but currently this seems to be only an issue for the place=housing_estate, which is not documented on the wiki and probably best is removed.
Reporter: tom[at]acrewoods.net
[Submitted to the original trac issue database at 11.29am, Thursday, 22nd December 2011]
The place name hierarchy is often a bit random in London, with its complicated and imperfectly mapped mess of place nodes and administrative boundaries.
Google seems to lump huge swathes under names such as "Camberwell", whereas Nominatim puts roads in all sorts of interesting places that are often several miles away.
This gets really confusing when you have a road comprised of several ways, e.g. because one part of the road is one-way or because a relation only applies to part of the road. These can show up multiple, different results.
Two examples local to me, where I've tried to make sure the place name hierarchy is fairly logical:
Friern Road is closest to the East Dulwich place node, and is within the East Dulwich administrative boundary (level 10). Yet the two sections of the road show up in Sydenham and then in Crystal Palace, both of which are a couple of miles away and past some other place nodes.
http://open.mapquestapi.com/nominatim/v1/search.php?q=friern+road&viewbox=-180%2C77.89%2C180%2C-65.58
Ondine Road is NOT part of the Champion Hill estate (you have to travel via several other road connections to reach that estate) and again the two sections show different places (Walworth, New Cross Gate), both of which are considerably farther away than East Dulwich and Peckham (confusingly residents may claim to be part of either of those two places).
http://open.mapquestapi.com/nominatim/v1/search.php?q=ondine+road&viewbox=-0.08%2C51.47%2C-0.06%2C51.45
If this is a problem with the map data, please describe how to correctly use nodes and boundaries to help Nominatim deal with cities with lots of local place names.
The text was updated successfully, but these errors were encountered: