[Tagging] address property vs. housenumber as a feature

Javier Sánchez Portero javiersanp at gmail.com
Fri May 11 12:35:27 UTC 2018

2018-05-11 10:53 GMT+01:00 Martin Koppenhoefer <dieterdreist at gmail.com>:

> May be it would be good to have a relation to keep in only one place an
>> address and link there the affected elements: entrances, buildings, POI's
>> and area for this address. This would be necessary only for some cases like
>> a building with many addresses/POI's. The simplest use cases would be done
>> as usual. Looking the history of the associated_street and street relation
>> may be this idea is too controversial so opinions are appreciated.
> We could add relations to model which addresses belong to which POI (and
> this would also work for multiple addresses for one POI), but it really
> isn't the same as stating the address the POI is _using_, because it might
> "have" several entrances (and windows) with addresses but use only part of
> them (i.e. we would need roles to say which addresses lead to the POI, and
> which is the "official" address of it, the one on it's website, business
> register, receipt, advertising etc.). This would be a lot of relations for
> something that can be easily modelled by adding the address property as
> used by the POI to the object and be done. From the relation you will not
> be able to construct actual address strings like "Foo Street 33-35" because
> this could mean things like "33A, 33B, 33C, 35" or "33, 34, 35", or "33,
> 35", etc.
> Even for simple cases, I would like to tag whether they are representing
> an entrance (entrance=yes/main or barrier=gate) or not (entrance=no, these
> are either windows or former entrances now closed or potential future
> entrances, and on top of this, situations that shouldn't get a housenumber
> according to current legislation, but already have one). I am also
> interested in adding details like level=1 (I see the absence of level as
> level=0 and the default, but add level=1 for first floor entrances. This is
> useful to understand situations where the sequence of numbers seem "odd" on
> the map, but actually are accurate).
> Cheers,
> Martin

The kind of relation I have in mind is a type=address relation with the
usual tags for an address (addr:*). A quick sketch of the members could be

* role=plaque, cardinality=0-1 for a node near where the house number
plaque is located. This member will be present only if exists a plaque with
the number. This node could have the entrance=*, barrier=*, door=*,
wheelchair=*, etc. tags if the plaque is associated to an entrance or not,
like in [1]
* role=to define, cardinality=0-many for the features related to this
address. This could be buildings, features like shops, a landuse area, etc.

Generally the current schema will still be used. The address relation will
be necessary only for this:

* If you have many features associated to an address and you can't draw the
actual limits of a enclosing area to put the address or you want to use a
node for the reasons mentioned. Then we will have one relation.
* If you have many addresses for a feature. Then you will have as many
relations as plaques found. The case of the official address you mention
could be stated in the role.

Lets see a real world example, like the Empire State Building [2]. We have
one address in the building footprint and many others in nodes you can see
inside the footprint (and even two of them outside, making it hard to
associate them). The 350 of 5th Avenue it's repeated in many POI's. This
give to inconsistency: **there are three different addr:postcode values**.
It would be solved moving the addr:* tags to one relation with the POI's as

The building have the number 2 in the West 34th Street, with the next
building having the 22 housenumber. Similar for the West 33rd Street, and
in the 5th Avenue the building is between 326 and 362 housenumbers, so I
think that the building have many housenumbers associated in each street.
Only to clarify the example, we can confirm this at [3], this entrance give
access to housenumbers 1 to 25. With the actual scheme, to improve this I
would move the address node [4] to this point with the entrance=main tag
and using addr:housenumber=1-25 and similar for the other two streets. With
the proposed relation, I would create a relation with this tags

addr:street=West 33rd Street

With the entrance, building and POI's (when present) as members. Each POI
could have tagged their individual addr:housenumber=n. The consumer will
get the full address for a POI from:

* The addr:housenumber of it (only present the addr:* tags that differs
from the parent address relation
* The addr:* tags of the parent address relations
* Can complete it with the name or addr:housename of the building if it's
only one.

The final number of relations needed will be one for entrance with plaque.
I think it could be possible three, one for each street.

[1] https://goo.gl/maps/yTDHWbVuRWF2
[2] https://www.openstreetmap.org/way/34633854
[3] https://goo.gl/maps/gen2q28NvfB2
[4] https://www.openstreetmap.org/node/2709306512
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180511/d8c40905/attachment.html>

More information about the Tagging mailing list