[Tagging] Removing name_1 and alt_name_1 from Wiki

Hakuch hakuch at posteo.de
Sat Jan 9 18:50:03 UTC 2016

I propose, to remove the tagging of name_1 and alt_name_1 from the wiki.
Most mappers reject tagging with _x suffixes and it makes no sense to
have them in the wiki as a scheme for good mapping.

[I also started a discussion in the wiki:

**better use diverse name-tags**

Mappers should be motivated to use semantic more rich name-tags like
loc_name, old_name, short_name and so on. If theere is a name that does
not fit in this scheme, alt_name can be used. If there are multiple
names that does not fit, alt_name can be used with semicolons.

**semicolons instead of _1 suffixes**

Semicolons for multiple values have already been established even though
some mappers don't like them. Precise tags should always be preferred
(like the mentioned diverse name-tags), but we should
not use _1 suffixed tags instead of semicolons. 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. Furthermore the semicolon is already established
and has been accepted for such special cases with multiple values.

**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.
It suggests to the unexperienced mapper, that this is a usable method to
add multiple values, 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

**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
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.

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


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.
And after that we can convince iD Editor to stop creating them
automatically :)

german readers can also take a look into this discussion in forum:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x3CBE432B.asc
Type: application/pgp-keys
Size: 3187 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20160109/2b2d337b/attachment.key>

More information about the Tagging mailing list