Add addr:unit support to nominatim

[tpikonen]

(This is essentially a repost of bug 4886 in trac at https://trac.openstreetmap.org/ticket/4886 )

addr:unit is the recommended way of tagging staircases in European style apartment buildings. Support for addr:unit would be necessary in order to get a unique address to many buildings, i.e. there can be more than one building with the address 'Foo Street 5' and they are differentiated by the addr:unit on their entrance nodes. The address 'Foo Street 5 B' should then resolve to the (entrance) node tagged with addr:unit=B on a building tagged with addr:housenumber=5 and addr:street="Foo Street".

[oiva]

At least in Finland the unit is most often a letter after the house number. One test case is Kalastajanmäki 2 which has four buildings with addr:housenumber=2 and one of the buildings has two entrances, addr:unit=A and addr:unit=B.

Currently a search for "Kalastajanmäki 2" finds one of the buildings but a search for "Kalastajanmäki 2 A" doesn't find any of the buildings and instead only highlights the street Kalastajanmäki.

[melvyn-sopacua]

In some regions a separator is used , like "2-A" or even "2 appt B". How is this stored in addr:unit if at all and is it consistent?

[tpikonen]

i don't think a separator should be stored in addr:unit, since it is, as you said, dependent on region and the OSM data should be as universal as possible. The search engine (or renderer, or whatever is processing the human readable address) should infer the region from the rest of the address and use separator(s) appropriate for the region.

[tvainika]

Also support for addr:flats would be nice.

E.g. searching for "Pietolankatu 59 A 1, Järvenpää, Finland", I would expect to find https://www.openstreetmap.org/node/2222227520 which is a node with addr:flats=1 in a way that has addr:unit=A (actually addr:unit is repeated in the node and the way)
and for "Pietolankatu 59 E, Järvenpää, Finland", I would expect to find just a way with addr:unit=E https://www.openstreetmap.org/way/197508914

Currently adding letters after number ruins the search at least in Finland, but how about other locations, languages, and address conventions?

[james2432]

This is becoming more important now that the osm carto supports addr:units:
gravitystorm/openstreetmap-carto@v4.3.0...v4.4.0

[omgitsgela]

This is extremely important in the United States, as most urban locations have businesses and residences divided up into suites / apartments / units. It's extremely common place, and should be standard in Nominatim

[wolfbert]

Would love to see addr:unit supported too. There is - once again - a raging discussion in the Austrian community to institute redundant tagging as in addr:housenumber=24/7 instead of addr:housenumber=24, addr:unit=7, simply to make Nominatim work.

In fact, none of the above cuts it. The building, or group of buildings, has an address tagged on the building or a site/cluster/multipolygon relation (not to speak of surrounding polygons). Each building has multiple staircases (nodes in the building outline tagged with addr:unit=*). This requires inferring the address (i.e. move from the unit to the building outline to relations containing the building to assemble the address data), and may result in multiple valid addresses for a single object.
For a fairly simple eaxmple, see here.

Nominatim, as far as I understand it, does none of this but only finds addresses explicitly coded on a node/way/relation (and, alas, often not even that). In fact, a query for "Vorgartenstraße 158" may or may not give the desired result (even though it is properly coded), but "Vorgartenstraße 158 1" will fail every time.

Please support addr:unit in conjunction with e.g. addr:housenumber and addr:street, and, if found alone on a node contained within a building outline, augment the address with tags of the building (which in turn could come from, say, a site, cluster or multipolygon relation).

[omgitsgela]

It's inappropriate to modify the data to accommodate poor coding of a tool that uses the data. Enter the data correctly, and have the developers of the tools fix their data interpretation problems. I will always enter my data according to the tags represented on the OSM wiki for best practices, and Nominatim should adapt to that standard.

…

On Feb 18, 2018 6:23 PM, "wolfbert" ***@***.***> wrote: Would love to see addr:unit supported too. There is - once again - a raging discussion in the Austrian community to institute redundant tagging as in addr:housenumber=24/7 instead of addr:housenumber=24, addr:unit=7, simply to make Nominatim work. In fact, none of the above cuts it. The building, or group of buildings, has an address tagged on the building or a site/cluster/multipolygon relation (not to speak of surrounding polygons). Each building has multiple staircases (nodes in the building outline tagged with addr:unit=*). This requires inferring the address (i.e. move from the unit to the building outline to relations containing the building to assemble the address data), and may result in multiple valid addresses for a single object. For a fairly simple eaxmple, see here <https://osm.org/go/0JrJmFf7n>. Nominatim, as far as I understand it, does none of this but only finds addresses explicitly coded on a node/way/relation (and, alas, often not even that). In fact, a query for "Vorgartenstraße 158" may or may not give the desired result (even though it is properly coded), but "Vorgartenstraße 158 1" will fail every time. Please support addr:unit in conjunction with e.g. addr:housenumber and addr:street, and, if found alone on a node contained within a building outline, augment the address with tags of the building (which in turn could come from, say, a site, cluster or multipolygon relation). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#587 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYPkkOcSBAGOAJVJP67ANUe-CeLlzifsks5tWLEMgaJpZM4LAKgY> .

[tpikonen]

In fact, none of the above cuts it. The building, or group of buildings, has an address tagged on the building or a site/cluster/multipolygon relation (not to speak of surrounding polygons). Each building has multiple staircases (nodes in the building outline tagged with addr:unit=*). This requires inferring the address (i.e. move from the unit to the building outline to relations containing the building to assemble the address data), and may result in multiple valid addresses for a single object.
For a fairly simple eaxmple, see here.

This is maybe slightly off-topic for this bug, but is there a reason not to tag the full address to the entrance node? Of course it would be nice if nominatim could infer the missing street/housenumber from the building or other related features.

[wolfbert]

This is maybe slightly off-topic for this bug, but is there a reason not to tag the full address to the entrance node?

Well, that's what the discussion in Austria is about. It leads to a lot of redundancy (the same address is repeated for each stair case), the notion of an apartment complex with single address becomes implicit (only can be recognized through common address, or additional relation/polygon), and it makes the job a lot more difficult for the renderer (which would have to figure out that all the addresses are the same and need to be rendered only once).

Unfortunately, I have neither the time nor equipment for Nominatim development, and I'm not even sure if it would be feasible.

[omgitsgela]

This is getting way off topic, but the only time I can see setting a redundant address is for a business POI on top of a building, where both the building polygon and the business have address information. Most end use mobile software I've seen does NOT support editing polygon tags, but only POI tags when mobile, and businesses change all the time whereas buildings don't, and you can always mark a POI as closed rather than delete it, so searches return relevant information. Also, name: on a building should refer to the commonly accepted historic name for that building, and not the business currently inside it.

…

On Feb 19, 2018 6:51 AM, "wolfbert" ***@***.***> wrote: This is maybe slightly off-topic for this bug, but is there a reason not to tag the full address to the entrance node? Well, that's what the discussion in Austria is about. It leads to a lot of redundancy (the same address is repeated for each stair case), the notion of an apartment complex with single address becomes implicit (only can be recognized through common address, or additional relation/polygon), and it makes the job a lot more difficult for the renderer (which would have to figure out that all the addresses are the same and need to be rendered only once). Unfortunately, I have neither the time nor equipment for Nominatim development, and I'm not even sure if it would be feasible. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#587 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYPkkDx8t6BnkvipqRdSrCk6QO-NBJLNks5tWWBNgaJpZM4LAKgY> .

[lonvia]

As a Nominatim dev, I can say that this issue is acknowledged but at this point I have not even thought about what it entails and how this can be implemented.

On two points I can comment though:

• There will be no parsing of addr:housenumber for unit numbers. Any support for unit numbers on the Nominatim side will only rely on a separate tag addr:unit. Don't hack them into housenumber just to tag for a broken Nomiantim.
• Nominatim can (and already does) take missing address parts from a surrounding building polygon. So a node with only addr:unit inside a building with a full address is just fine.

Also: please find better communication channels for the off-topic discussions.

[KaiRo-at]

Please let our Austrian tagging discussion out of this issue, it's only clutter here (and the discussion with the guy who wants to put the unit into the housenumber is difficult enough, let's not have this spill over to here). Take tagging discussions to the relevant lists please, not to Nominatim issues.

The fact here is that addr:unit is a tag that is in use in multiple parts of the world and is part of addresses but not supported by Nominatim (just like addr:city, another important piece of addresses). Either Nominatim needs to become fuzzy enough to still match at least something usefully when a full address with unit is present, but even better, Nominatim should support addr:unit itself.
Note that in Austria, the unit is usually separated by / when specifying addresses, so that separator should also be supported in Nominatim, ideally.
As a testcase, "Davidgasse 76-80/14/10, 1100 Wien, Austria" is a full address of an apartment within a unit, "Davidgasse 76-80/14, 1100 Wien, Austria" the address of a unit, represented by a node in OSM with the following tags:
addr:country=AT
addr:city=Wien
addr:postcode=1100
addr:street=Davidgasse
addr:housenumber=76-80
addr:unit=14
(You can't assume fixed format of the second field being unit, though, as in houses without units, the second field tends to be just the door number of the apartment.)

[omgitsgela]

Thanks for acknowledging this (and rightly suggesting a better off topic area. Sorry!) Every locale would render addr:unit differently for their address format. In the USA, you'll likely see 123 Something Street, Unit 5B, Town, State, ZIP. I'd say you could either create a regional expression for each with data on how that address structure works, or add it in line with either a concatenated tag of Unit or # before the value. Would this be compatible with address schemas for other locations around the world?

…

On Feb 19, 2018 7:30 AM, "Sarah Hoffmann" ***@***.***> wrote: As a Nominatim dev, I can say that this issue is acknowledged but at this point I have not even thought about what it entails and how this can be implemented. On two points I can comment though: - There will be no parsing of addr:housenumber for unit numbers. Any support for unit numbers on the Nominatim side will only rely on a separate tag addr:unit. Don't hack them into housenumber just to tag for a broken Nomiantim. - Nominatim can (and already does) take missing address parts from a surrounding building polygon. So a node with only addr:unit inside a building with a full address is just fine. Also: please find better communication channels for the off-topic discussions. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#587 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYPkkBN6unmInSGw-mpak9lJg2dWIHiYks5tWWlZgaJpZM4LAKgY> .

[james2432]

In Canada it would be 5B-123 Something Street, Town, Province, Postal Code