Compute housenumber based on proximity and/or relations

[bxl-forever]

A POI without a house number, e.g. https://nominatim.openstreetmap.org/ui/details.html?osmtype=N&osmid=6236706985 Nominatim currently returns the nearest street but assumes the house number cannot be found.

This POI is close to an existing address node, located on the door: https://www.openstreetmap.org/node/1392751632

Both nodes are linked through a "type_provides_feature" relation: https://www.openstreetmap.org/relation/9319590
This relation type has been proposed as an elegant way to explicitely associate a POI and an address and inherit its properties. This avoids duplicating addresses on all the POI within a building. Moreover, in several countries, such as Norway or Denmark, address nodes are permanently kept in sync with government data and addresses are expected to be unique.

Is there a way to have this work in Nominatim? Ideally through the relation, because they have been invented specifically for that purpose. If that is not possible, a simple match based on proximity (e.g. if the POI is within a building, find all the nodes that have an address within the building, and the closest one wins).

[lonvia]

This relation type has only a few thousand uses and they are all in Stockholm, as far as I can make out. This is not sufficient to justify adding support for such a relation in Nominatim, you'd have to find wider community support for such a scheme.

That said, I'm rather reluctant in general to see relations used for this kind of connection. The French have resorted to using the contact:* name space for the same thing, which is better. It is much easier to handle for mappers and also for data users. I'm speaking from experience here because Nominatim does support associated_street relations and they are a major pain. There are a lot of corner cases where they behave slightly different than normal tags and getting updates right is difficult when at least three objects need to be taken into account.

The next step with addresses on entrances might be to check that they can be for the simple one-entrance case inherited back to the building and from there to the underlying POIs. But even that is rather expensive because most building outlines are not even taken into account yet by Nominatim.

[bxl-forever]

We have over 600 such relations in Brussels too, as an attempt to clean up the mess with addresses: it’s a bilingual territory and when users type addresses on POI we end up with lots of nonsense in the database (people only type the address in one language, or do not spell the street name right, or make horrible mistakes with postcodes).

But OK, I get your point, thanks for explaining.

[lonvia]

I'm aware of the massive spelling problem in Belgium (see https://nominatim.org/qa/#map=9.00/50.52/4.84&layer=addr_street_wrong_name) but adding even more complicated constructs on top of it, won't solve it. What helps with your specific problem is editor support that checks spelling of new addresses against existing street names, postcodes etc.

[joostschouppe]

By now there's over 10.000 uses; about 2/3ds in Brussels, but also in Denmark now. And the mapper from Stockholm also did Nice it seems... I guess it scratches an itch for some heavy mappers, though it does not come without a significant cost (i.e. making things harder to map & data harder to use). But it does seem like the numbers will keep rising, so sooner or later it will probably be worth it to implement this.

[lonvia]

Doing a quick check, more than 6k of these uses have been entered by @bxl-forever and another 3k by a user uSnusmumriken. That leaves a couple of hundred uses by everybody else. This is far from picking up popularity.