[Tagging] AddrN

[Dmitry Kiselev]

 I have found a previous topic, so let's continue.

It's not an another solution, there is some mess with wiki pages but
http://wiki.openstreetmap.org/wiki/AddrN
and
http://wiki.openstreetmap.org/wiki/Proposed_Features/addrN
Are the same scheme

Andrew, I have already written, why point's isn't a good decision.
There is no un contradictory way to determine, does POI have 1 address (from a nearest point inside one building polygon) or two.

Martin, Dan
usage of two overlapped polygons or duplicating things for address is a worst case. 
It will broke geometry, 
it will broke any kind of statistics for buildings, 
it will broke 3d and so on. 
And it's a huge overhead to draw one more polygon just to specify another address.

Clifford,
"If the business only uses one of the addresses, then the problem is solved with two nodes, ideally inside a building polygon."

No both addresses is in use, if you open yellow pages - there is two addresses, even more, there is two addresses in government address plan.

And one more time, how would you distinguish such two cases:
One building with one polygon, and every enter marked as node with it's on address (some countries and some cities use address per entrance approach)
In this case, building itself doesn't have an address

One building with one polygon, and two addresses

What would you suggest as an address for POI point inside such building polygon?
For node buildings, how would you know, is it two buildings marked by nodes or two addresses for one building.

Guys, it's look awkward because you have never met such things as two addresses for one building in real life.
And it's not a problem to support such scheme, I have done plsql function that treats addrN case as two poins (table rows) 
for 3-4 hours, and I'm not an SQL expert. Nominatim already treats double addresses (marked via conscription numbers scheme)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150118/c9a762d0/attachment.html>