-
-
Notifications
You must be signed in to change notification settings - Fork 713
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add addr:unit support to nominatim #587
Comments
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 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. |
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? |
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. |
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) Currently adding letters after number ruins the search at least in Finland, but how about other locations, languages, and address conventions? |
This is becoming more important now that the osm carto supports addr:units: |
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 |
Would love to see 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 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 |
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>
.
|
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. |
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. |
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>
.
|
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:
Also: please find better communication channels for the off-topic discussions. |
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. |
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>
.
|
In Canada it would be 5B-123 Something Street, Town, Province, Postal Code |
(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".
The text was updated successfully, but these errors were encountered: