> 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 <ine...@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@openstreetmap.org >https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
