[Tagging] Please don't think name_1 tags are errors.

[Martin Koppenhoefer]

sent from a phone

> Am 15.01.2016 um 18:03 schrieb moltonel 3x Combo <moltonel at gmail.com>:
> 
> The problem is that all those name key variations carry semantic
> meaning. A loc_name isn't the same thing as an alt_name which isn't
> the same thing as an old_name.


yes, but a name, an alt_name and a nat_name are quite the same. I haven't yet encountered situations with more then 3 alternative names in the same language for the same thing, and that didn't fit into other kinds of distinctions either (short, official, old, ...). Are we maybe talking about different spelling (e.g. often coming from different transcription of non-latin scripts)?


> You can't shuffle all your names into
> random foo_name keys, it has to make sense.


+1


> And as soon as you've got
> more than one name, you've got a problem.


IMHO more than 2-3 (alt_name and nat_name).

I've looked a bit around in taginfo and found an example for excessive indexed alt names: http://www.openstreetmap.org/relation/5725722
to me this looks as if the mappers wanted to work around some supposedly bad working search engine, looks more like SEO then like sensible tagging, but I might be wrong, I don't know the context.

> 
> To get back to my http://www.openstreetmap.org/relation/5257865
> example, I've got 3 names to tag. One of them distinguishes itself by
> also appearing on an out-of-copyright map, the other two are at the
> exact same level with each other and, as far as I'm concerned, pretty
> much at the same level as the first one. I can't fit them into "loc"
> or "old" or "whatever" categories, to the best of my knowledge they
> are just "other names".


if one of your sources "authorative", you could put the value under official_name, the other two could be name and alt_name (if there really isn't just a typo at least in one of them).


> Having multiple values for one tag is awkward in OSM, so we always try
> to find clever ways around it. Sometimes that clever trick is the
> right thing to do, sometimes we really just need a way to tag multiple
> values.


+1, I agree there might really be situations where this could be the best solution, but it is really, really rare, most of the cases where multiple values are actually used come from approximative mapping and would better be solved by more detail (e.g. area in area or node(s) in area rather than trying to put everything in one poor node).

cheers,
Martin