<HTML><BODY>Markus, there is no problems with distinct addresses at all <br>if you treat them as first class citizen in your database.<br><br><br>Table address<br>id, scheme, hn, street, quarter, neighbourhood, city, e.t.c<br><br>Table POI<br>id, name, brand, operator, something, else<br><br>Table POI_Addr<br>POI (POI.id), addr (address.id)<br><br>So you'll get distinct addresses and distinct POI with multiple addresses.<br><br>Of course keeping two addresses (or three or more, look at the Vilnus) is more <br>difficult than one address. But cause of this difficulties isn't an OSM tagging schema<br>cause of this difficulties is multiple addressing itself.<br><br>Me and Friedrich do not propose to trow away addr points or conscription numbers.<br>There is a demand for addressing schema based on tags, and such<br>schemes pop up every year. <br><br>So I want, when somebody will find that he need to map 2 or more addresses<br>and points (or anything else based on fake geometry) doesn't fit him, I want him to <br>use addr2 and not addr:2 or addr_2 or street2+housenumber2.<br><br>And if we don't have description for multiple addresses mapping via tags, it will <br>be created and used without proposals and RFCs.<br><br><br>Sun, 18 Jan 2015 22:23:30 +0100 от Markus Lindholm <markus.lindholm@gmail.com>:<br>
<blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">
<div id="">
<div class="js-helper js-readmsg-msg">
<style type="text/css"></style>
<div>
<base target="_self" href="https://e.mail.ru/">
<div id="style_14216163400000000895_BODY">On 18 January 2015 at 22:11, Dan S <<a href="/compose?To=danstowell%2bosm@gmail.com">danstowell+osm@gmail.com</a>> wrote:<br>
> 2015-01-18 20:52 GMT+00:00 Markus Lindholm <<a href="/compose?To=markus.lindholm@gmail.com">markus.lindholm@gmail.com</a>>:<br>
>> On 17 January 2015 at 22:16, Friedrich Volkmann <<a href="/compose?To=bsd@volki.at">bsd@volki.at</a>> wrote:<br>
>>> With the addrN schema, we need one object (a node tagged shop=* and<br>
>>> addrN:*=*) for a shop.<br>
>>> With the provides_feature relation we need one node for the shop, one node<br>
>>> for each address, and one relation.<br>
>><br>
>> And if there are two shops that both have the same address? Then your<br>
>> scheme breaks down as you would end up with a database with two<br>
>> distinct nodes but same address. Clearly a bad thing and against the<br>
>> principle of 'One feature - one element'<br>
>> <a href="http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element" target="_blank">http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element</a><br>
><br>
> This criticism is mistaken. (The wiki page even gives a counterexample<br>
> of "More than one of something on the same site" which is rather<br>
> similar to "two shops with the same address".) We have lots of<br>
> examples in OSM of two distinct objects with the same address - it's<br>
> quite common in real life, and if it is a problem then it's nothing to<br>
> do with "addrN", it would be a problem with a large portion of our<br>
> "addr" data!<br>
<br>
I think that comes down to how addresses are viewed, either as a<br>
proper feature in their one right or as an attribute to some other<br>
feature. I think addresses are proper features, so a distinct address<br>
should be found only once in the database.<br>
<br>
/Markus<br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="/compose?To=Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</div>
<base target="_self" href="https://e.mail.ru/">
</div>
</div>
</div>
</blockquote>
<br></BODY></HTML>