<HTML><BODY>> addr:city=<ukrainian city name><br> > addr:city:ru=<russian city name><br> > addr:street=<ukrainian street name><br> > addr:street:ru=<russian street name><br> > addr:housenumber=123<br><br>It's unnecessary.<br><br>addr:city=<ukrainian city name><br>addr:street=<ukrainian street name><br>addr:housenumber=123<br><br>Is enough, all kind of translations might be taken from matched street/city<br>as good as any kind of old_names or alt_names<br><br>Ofc. any scheme might be misused.<br><br>Mon, 19 Jan 2015 02:40:14 -0500 от Ineiev <ineiev@gnu.org>:<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_14216533590000000920_BODY">On Sat, Jan 17, 2015 at 11:11:23PM +0100, Friedrich Volkmann wrote:<br>
> On 16.01.2015 05:48, Ineiev wrote:<br>
> > On Thu, Jan 15, 2015 at 12:53:13PM +0100, Martin Koppenhoefer wrote:<br>
> >><br>
> >> you could use polygons (e.g. 2 distinct multipolygons, one for each<br>
> >> address), and add a note to inform your fellow mapping colleagues that the<br>
> >> overlap is intended (note is not needed but nice).<br>
> > <br>
> > I think this solution has an essential advantage: distinct<br>
> > multipoligons with single addr:housenumbers can go do distinct<br>
> > associatedStreet relations. you can't do it with addrN:; and<br>
> > the mapper may want to use associatedStreet e.g. because<br>
> > it provides a way to specify parallel addresses in different<br>
> > languages (I believe, this feature is used in countries like Ukraine).<br>
> <br>
> If we need language versions for the street name, we'll probably need them<br>
> for city names (Kiyev/Kiyiv) etc. too. So you'll not only need an<br>
> associatedStreet relation, but also an associatedCity relation.<br>
<br>
TTBOMK the city/country part of the address comes from the city<br>
multipoligon, and it does have an established way to specify<br>
localized versions.<br>
<br>
> You can (mis-)use the addrN schema for that purpose:<br>
> <br>
> addr:city=<ukrainian city name><br>
> addr:street=<ukrainian street name><br>
> addr:housenumber=123<br>
> addr:2:city=<russian city name><br>
> addr:2:street=<russian street name><br>
> addr:2:housenumber=123<br>
<br>
Indeed, it would be a misuse. the user of data should<br>
be able to identify the language.<br>
<br>
> The number of tags multiplies with the number of street/housenumber<br>
> combinations, but that may still be simpler than congruent housenumber<br>
> polygons all of which are member of several associatedSomething relations.<br>
> <br>
> I think that the best solution may be:<br>
> <br>
> addr:city=<ukrainian city name><br>
> addr:city:ru=<russian city name><br>
> addr:street=<ukrainian street name><br>
> addr:street:ru=<russian street name><br>
> addr:housenumber=123<br>
<br>
Agreed; but those would be a bunch of new tags, while<br>
associatedStreet is already documented in wiki and hopefully<br>
supported by software.<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>