[Tagging] Feature Proposal - RFC - addrN:*

[Serge Wroclawski]

On Thu, Jan 15, 2015 at 8:29 PM, Friedrich Volkmann <bsd at volki.at> wrote:

>> In that scenario, I'd much prefer to see two nodes, each with their
>> address, and each tagged as an entrance.
>
> What you prefer certainly depends on your needs. Adresses on entrances are
> fine for routing, maybe for visual representation too, but if you want to
> run a script generating a list of building sizes and addresses, you need
> addresses on buildings.

I'll explain how we dealt with this issue in NYC later in the mail.

>> What benefit does this proposal have over simply using a list separator?
>
> A list separator is fine as long as there is only one key. Unfortunately,
> there is no simple addr=* key.

The addr key can be used on its own to denote a complete address,
without using subkeys. The subkeys are preferable in most cases since
they can be used to construct the keys themselves, but are not
strictly necessary.

> There is an addr:city=* key for the city,

Is there a building in your dataset that lives in two cities?

> an  addr:postcode=* key for the postcode

Postcode's an interesting one- but again, in actuality, do you have a
building that has two postcodes?

> an addr:street=* key, and addr:housenumber=* key, and others.

These are the two we care most about in this discussion.

And here's where we simply say:

addr=val1;val2;val3

If you're in North America or a European country, it would be something like

<housnumber> <street name>

Let's say 123 Foo and 567 Bar

addr:123 Foo;567 Bar

We can omit the city because the city is the same (if you have a real
life counter example, please show me) and we can omit the postalcode
for the same reason.

> Here you do not need to count semicolons, neither do applications. You can
> check address for address. Which solution do you like better?

Maybe I'm mistaken, but it's my understanding that this solution is to
address the exceptions in the data.

I live in New York City, and we do have some buildings with multiple
addresses, so this isn't a theoretical for me. We already dealth with
this.


There will be some exceptions, but not many. Even in a city like New
York City, with over a million buildings (litterally), the number of
multi-addressed buildings which we
In most cases, going back to your first question, the solution was to
use naked address nodes placed inside the building polygon.

You asked how one would retrieve addresses from a data processing
perspective. The answer is that in these cases, you *might* want to
use some kind of building relation, and then you'd have the building
as a relation and the nodes inside it, but what we did in NYC is to
simply add naked address nodes inside the building polygon.

This adds an extra step in data retrival, but it's not that bad.

As an aside, it may be useful for someone to create some kind of an
API or SDK on top of OSM to make it easy to retrieve these broad
categories of data which may be represented in different ways.

- Serge