[Tagging] Feature Proposal - RFC - addrN:*

[Friedrich Volkmann]

On 16.01.2015 17:04, Serge Wroclawski wrote:
>> There is an addr:city=* key for the city,
> 
> Is there a building in your dataset that lives in two cities?

No. I used a bogus example just to demonstrate the syntax.

> 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>

That's a similar approach as addr:full. So you use the mere addr=* key for
half of the full address. I did not know, because it isn't documented on
http://wiki.openstreetmap.org/wiki/Key:addr or
http://wiki.openstreetmap.org/wiki/Addresses.

Taginfo lists exactly 247 occurences of the addr=* key. The most common
value is "none".

> Let's say 123 Foo and 567 Bar
> 
> addr:123 Foo;567 Bar

Provided that you get along with just one addr=* key in place of the full
addr:* schema, the semicolon notation seems reasonable. However, this is all
hopothetical, as the addr=* key is not really in use and will certainly
never become widely accepted.

> 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.

So where do applications take the city and postcode from?

>> 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.

That's a widespread habit in Europe too, but it's a defective concept, because
1) the scope of the addresses is not defined. Particularly, it is undefined
whether both nodes apply to the whole building or each node applies to part
of the building.
2) you cannot use address nodes to denote addresses of POIs which are nodes
themselves.

> 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.

There are already databases with integrated all-purpose GIS functions, such
as PostGIS. I agree that extensions for OSM specific data would also be
useful. Many routines have been developed, few have been published. But
everybody is free to do so.

Anyway, a routine determining the scope of adresses will always fail for
address nodes, because the scope is undefined by concept, see above.

-- 
Friedrich K. Volkmann       http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria