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

Hyphenated housenumber ranges don't index the intermediate numbers #4789

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

Comments

@openstreetmap-trac
Copy link

Reporter: otbj
[Submitted to the original trac issue database at 8.02pm, Wednesday, 20th February 2013]

See http://www.openstreetmap.org/browse/way/205900169

This is a building directly tagged with:

  • addr:housenumber = 76-102
  • addr:interpolation = even
  • addr:street = Chieftain Way
  • building = apartments

I would expect this to match queries for:

  • "76 Chieftain Way, Cambridge, UK" (works)
  • "102 Chieftain Way, Cambridge, UK" (works)
  • "78 Chieftain Way, Cambridge, UK" (no match on the house number, returns the whole street)

i.e. the intermediate values of the hyphenated addr:housenumber range are not being indexed, only the endpoints of the range.

@openstreetmap-trac
Copy link
Author

Author: oliver.jowett[at]gmail.com
[Added to the original trac issue at 10.11am, Monday, 25th February 2013]

Similar problem occurs on nodes tagged with hyphenated address ranges.

e.g. http://www.openstreetmap.org/browse/node/2172269184, a singleton node not part of a way, tagged with:

  • addr:housenumber = 17-27
  • addr:interpolation = odd
  • addr:street = Graham Road

This is a group of flats with a single entrance that is part of a larger building.
None of the housenumbers (not even the endpoints) are indexed.

@openstreetmap-trac
Copy link
Author

Author: lonvia
[Added to the original trac issue at 3.49pm, Friday, 7th February 2014]

See also [https://github.com/osm-search/Nominatim/issues/111]

@openstreetmap-trac
Copy link
Author

Author: lonvia
[Added to the original trac issue at 8.30am, Sunday, 18th May 2014]

Putting a range into addr:housenumber is a bad idea because a dash may be a valid part of the house number. Real world examples can be found [http://www.openstreetmap.org/#map=19/52.36034/4.89425 in the Netherlands] and [http://www.openstreetmap.org/#map=19/40.71407/-73.83444 in Queens, NY]. Use a short way with addr:interpolation and two separate addr:housenumber nodes instead.

@openstreetmap-trac
Copy link
Author

Author: oliver.jowett[at]gmail.com
[Added to the original trac issue at 8.55am, Sunday, 18th May 2014]

I followed [http://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers this wiki advice], which says to do exactly what you say is a bad idea:

Specify the range (e.g., "10-95"). This is the preferred method when such a range is
officially used for the entire house. You may also use addr:interpolation=* to describe
whether that includes odd, even or all numbers.

This is unambiguous if addr:interpolation is also present.
For single housenumbers containing a dash, there would no addr:interpolation present.

@openstreetmap-trac
Copy link
Author

Author: lonvia
[Added to the original trac issue at 9.16am, Sunday, 18th May 2014]

There is a lot of contradictory advice in the wiki and that page was probably written by somebody who simply wasn't aware that there are house numbers with dashes out there. Fact is that implementing ranges in that way requires some complicated heuristics. And that simply won't happen in Nominatim if there is a tagging schema that is unambiguous and already works.

Please don't reopen this ticket unless you have a patch that implements this (although a pull request over at github is preferred then).

@openstreetmap-trac
Copy link
Author

Author: oliver.jowett[at]gmail.com
[Added to the original trac issue at 9.36am, Sunday, 18th May 2014]

I should note that overpass says that, looking at just the greater London area (to keep the data manageable), there are:

  • 732 nodes and 237 ways tagged with a number range and addr:interpolation;
  • 2144 nodes and 3229 ways tagged with a number range and no addr:interpolation key; a casual inspection of a few of these shows that they do appear to be ranges, not single housenumbers.

So you will be throwing away a lot of existing data by not supporting this.

It would be in your own interests, if you are not going to add support to Nominatum for this, to update the wiki so that the apparently-bad advice is not there. You probably also want to think about a mechanical edit to "repair" all the existing data.

@openstreetmap-trac
Copy link
Author

Author: oliver.jowett[at]gmail.com
[Added to the original trac issue at 9.53am, Sunday, 18th May 2014]

FWIW, I cloned the Nominatum repository to take a look, but immediately ran into a twisty little maze of autoconf problems - couldn't even get the clean source to build - so I won't be playing with fixing this bug myself any time soon.

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