[Tagging] Feature Proposal - RFC - addrN:*

[Dmitry Kiselev]

 > addr:city=<ukrainian city name>
> addr:city:ru=<russian city name>
> addr:street=<ukrainian street name>
> addr:street:ru=<russian street name>
> addr:housenumber=123

It's unnecessary.

addr:city=<ukrainian city name>
addr:street=<ukrainian street name>
addr:housenumber=123

Is enough, all kind of translations might be taken from matched street/city
as good as any kind of old_names or alt_names

Ofc. any scheme might be misused.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20150119/161356e9/attachment.html>