Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

Certain house numbers are not found #5025

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 6 comments
Closed

Certain house numbers are not found #5025

openstreetmap-trac opened this issue Jul 23, 2021 · 6 comments

Comments

@openstreetmap-trac
Copy link

Reporter: thefish1[at]gmx.de
[Submitted to the original trac issue database at 12.59am, Sunday, 3rd November 2013]

I just encountered that when searching for an address with house number, nominatim does not always return the exact result, even though the house number is contained in the OSM data correctly. I don't think that this is a known issue, at least I couldn't find anything about it.

I found this issue when searching for an address in Karlsruhe, Germany. I currently don't know other places where it can be reproduced, but I doubt that the reason is bad/incomplete OSM data (see below for the reason):

works:

http://nominatim.openstreetmap.org/search?q=Kriegsstra%C3%9Fe+80,+Karlsruhe
http://nominatim.openstreetmap.org/search?q=Kriegsstra%C3%9Fe+99,+Karlsruhe
http://nominatim.openstreetmap.org/search?q=Kriegsstra%C3%9Fe+153,+Karlsruhe

dosn't work:

http://nominatim.openstreetmap.org/search?q=Kriegsstra%C3%9Fe+196,+Karlsruhe
http://nominatim.openstreetmap.org/search?q=Kriegsstra%C3%9Fe+256,+Karlsruhe

All street numbers I'm looking for are contained in the OSM data and are associated with the street correctly. In particular, if I provide a viewbox as "hint" for Nominatim, all numbers are resolved correctly. For example, this is the last link from above; just extended by a viewbox:

http://nominatim.openstreetmap.org/search?q=Kriegsstra%C3%9Fe+256,+Karlsruhe&viewbox=8.36%2C49.01%2C8.38%2C49

@openstreetmap-trac
Copy link
Author

Author: lonvia
[Added to the original trac issue at 7.36pm, Tuesday, 3rd December 2013]

The Kriegsstr has been divided into so many parts, that a search for it does not return all of them. With house number search that becomes a problem because a house number is attached to a specific part and if that one is not returned, the house number cannot be found either. That is why some work and some don't.

See also #5010.

@openstreetmap-trac
Copy link
Author

Author: thefish1[at]gmx.de
[Added to the original trac issue at 2.03pm, Friday, 13th December 2013]

Ok, this explains the behaviour. I have no idea how nominatim works internally, thus I don't know how difficult some improvement would be. If OSM raw data is preprocessed somehow (I assume it is) an obvious solution would be to recompose streets that have been split into several parts... the most difficult thing would probably be to detect those parts that belong together. Why isn't this information contained in OSM data? Or is it?

@openstreetmap-trac
Copy link
Author

Author: lonvia
[Added to the original trac issue at 9.42pm, Sunday, 15th December 2013]

It is possible to reconstruct the full streets from the OSM data but requires some non-trivial changes to Nominatim's internal data structures. It is something that is on the todo list.

@openstreetmap-trac
Copy link
Author

Author: skyper
[Added to the original trac issue at 1.46pm, Monday, 7th July 2014]

Still a problem even with a simple housenumber on a node.
https://nominatim.openstreetmap.org/search.php?q=Talhauser+Strae+54a,+Ebringen&viewbox=7.77%2C47.96%2C7.78%2C47.95

This one works:
https://nominatim.openstreetmap.org/search.php?q=Talhauser+Strae+16

Street and associatedStreet relations are one solution within the data but they seem to be problematic in other ways.

@openstreetmap-trac
Copy link
Author

Author: lonvia
[Added to the original trac issue at 8.44pm, Monday, 2nd February 2015]

nominatim.osm.org now runs [changeset:04d5d12/nominatim] for testing which should fix this problem for all addresses that are in OSM (not for TIGER address data in the US). Now waiting to see if there are any performance issues with this solution.

@openstreetmap-trac
Copy link
Author

Author: lonvia
[Added to the original trac issue at 8.00pm, Wednesday, 4th February 2015]

No performance issues have emerged. Patch now officially applied.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant