[Tagging] Removing name_1 and alt_name_1 from Wiki

moltonel 3x Combo moltonel at gmail.com
Sun Jan 10 21:29:33 UTC 2016


On 9 January 2016 at 18:50, Hakuch <hakuch at posteo.de> wrote:
> I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.

I disagree.

> **better use diverse name-tags**

Diverse name tags are a good thing when there is some semantic
difference between names, but often enough there's no semantic
differences between various alternatives and we need to put a list of
values for the same tag. The question of wether to use semicolons or
tag suffixes is independant from that.

> **semicolons instead of _1 suffixes**
>
> Their only advantage is
> the better legibility for human eyes, thats a reason why some people may
> favour them over the semicolon. But for mechanical computation, it is
> easier to regex the semicolon than crawling through all possible
> existing suffixed tags.

Actually to my human eyes, both semicolons and suffixes are equally
ugly (but pragmatic). It's for processing that suffixes are supperior:
* Spliting by semicolons (no regexp needed :p) is easy but naive,
because semicolons are sometimes part of the actual value.
* One workaround is to use some kind of escape character, but this is
an impementation/spec minefield that we'll never get right.
* Another is to maintain a whitelist of tags that can be split by
semicolon, but it's extra work and everybody'll have a different list.
* Tag suffixes on the other hand can be implemented easily, for all
tags without distinction, and do not suffer from false-positives.
* If a consumer forgot to implement multivalue names, he'll have
incorrect data in the semicolon case and incomplete data in the suffix
case. Incomplete is usually better than incorrect, but it does depend
on the usecase.

> Furthermore the semicolon is already established
> and has been accepted for such special cases with multiple values.

So is the suffix, so this isn't a useful argument.


> **iD-Editor problem**
>
> unfortunately, the iD-editor is creating such prefixed tags and is
> training newbies to use them as a good tagging practice. When you use
> the raw-tag-editor and tries to add an already existing tag, iD does not
> throw any error or information but adds the tag with a suffixed number
> like _1 or higher.

That does sound like a pretty bad behavior.

> It suggests to the unexperienced mapper, that this is a usable method to
> add multiple values,

It is :)

> although this suffixing is only made to prevent the
> user of deleting data.
> We still couldn't convince the developer, that this suffixing method
> leads new mappers to bad practice
> (https://github.com/openstreetmap/iD/issues/2896).

I'm not a fan of the developer's decision here. Always avoiding
warnings complicates UI design a lot. Not sure what to propose to them
instead, I'm not an iD user and whatever I suggest probably would feel
odd in an iD context.

That said, it is an iD UI issue, not really on topic ? But if you
insist in using this example in the semicolon vs suffix debate, it's
an argument for keeping suffixes, because suffix-aware consumers will
be able to make some sense of a name_1 accidentally created by iD.

> **how the name_1 and alt_name_1 came to the wiki-heaven**
>
> But actually, my intention was to propose the removing or marking of
> name_1 and alt_name_1 tags in the wiki (the iD problem should be
> discussed in a new topic). Inititally, the alt_name_1 tag has been added
> by a Nominatim developer in Nov'14. The origin for this decision can be
> found in this discussion on talk
> (https://www.mail-archive.com/talk%40openstreetmap.org/msg50648.html)
> that took place in Sept'14.
>
> There, a member of the HOT team described a problem, that their manual
> massedit caused the tags alt_name:2 and alt_name_2. Now he wants to have
> a mechanical edit to change all alt_name:2 to alt_name_2, preferably
> worldwide. That also caused a readable discussion about the sense of
> suffixed tags. But already before starting that discussion, the author
> asked the nominatim team for adding the alt_name_x tags
> to the nominatim search. And the Nominatim developer did so and
> consequently added it two month later to the wiki.
> Today there are over 5500 alt_name_1 tags. But only a few of them
> outside of the mentioned HOT-area in western africa. Nearly half of
> them, are NOT combinated with alt_name!
>
> The tag name_1 was not proposed in any way, this one has only been added
> in Aug'15 because it exists in the database. By comment "Document
> de-facto name_N variant". That is true, currently there are about
> 800.000 tags with name_1. But when you look on the taginfo map, or the
> combinations, you can see that almost each of them results from the
> Tiger-Import (https://taginfo.openstreetmap.org/keys/name_1#map,
> https://taginfo.openstreetmap.org/keys/name_1#combinations). That
> tagging-scheme should not be proposed in the wiki for using.

So name_1 is a de-facto standard. So what ? The scheme should be
evaluated on its own merit and current usage (which is *not* just
TIGER even though that import has a lot of it), not on its genesis. At
least you can trace the suffix scheme's origin; the use of the
semicolon certainly pre-existed any wiki voting/approval process (?).


> It even makes less sense to have alt_name_1 AND name_1 because they do
> not differ in any way.

Agree on that point. If you've got more than two names, alt_name_1 is awfull.



> **tl;dr**
>
> I propose removing the name_1 and alt_name_1 from the Map Features or
> rather marking them and to explain that and why they should not be used.

Again, disagree.

> And after that we can convince iD Editor to stop creating them
> automatically :)

Probably agree, I'd need to use iD to really form an opinion :p



More information about the Tagging mailing list