Proposal:Remove suffixed name-tags from wiki
Please note, that it is not proposed to remove the tags completely from documentation, please read the section "what this proposal wants to do"
| Remove suffixed name-tags from wiki | |
|---|---|
| Proposal status: | Approved (active) |
| Proposed by: | Hakuch |
| Tagging: | alt_name_x, name_x=* |
| Applies to: | |
| Definition: | DISCOURAGED, use other name-tags instead |
| Statistics: |
|
| Draft started: | 2016-05-01 |
| RFC start: | 2016-01-09 |
| Vote start: | 2016-01-25 |
| Vote end: | 2016-02-08 |
Proposal
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.
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 there is a name that does not fit in this scheme, alt_name can be used. If there are multiple names that do 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, that is 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 suffixed 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 (https://github.com/openstreetmap/iD/issues/2896). UPDATE: 3 years later iD choose to no longer add numbered suffixes.
How the tags 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). Initially, 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.
It even makes less sense to have alt_name_1 AND name_1 because they do not differ in any way.
Some points that came up in discussion
- There is no mechanical or any other massedit planned.
- This proposal is just about the wiki, where mappers should not be advised to use this tagging style and to clean up the confuse co-existence of different tagging styles and synonym tag keys.
- Some expected problems with semicolons in names. there is a solution for this in wiki: Semi-colon_value_separator#Escaping_with_.27.3B.3B.27
- Multiple values should always be avoided and semantic rich keys should be used.
- There were several reasons, that the semicolon should be preferred. Even if there might also exist reasons for the suffixed tagging, the semicolon is much more accepted and used
- Some feared, that the data could be read in wrong way by consumers and the suffixed tagging would provide at least one correct value. But suffixed keys might be missed easier by parsers, processing might be harder.
What this proposal wants to do if successful
- Remove name_1 and alt_name_1 from the table Template:Map_Features:name.
- Add a text to Key:name that discourages from using this tags, even if they exist in database. A link to this proposal will explain the reasons.
- (Pave the way to urge iD editor changing its behavior with existing key names.)
Find discussions here
https://forum.openstreetmap.org/viewtopic.php?id=53223 (german)
http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465.html
http://gis.19327.n5.nabble.com/Please-don-t-think-name-1-tags-are-errors-tp5864875.html
discussion page
Comments
Please comment on the discussion page.
Voting
Voting on this proposal has been closed.
It was approved with 38 votes for, 10 votes against and 1 abstention.
Approved due to >74% approval (79.167%).
I approve this proposal. --Geri-oc (talk) 08:13, 25 January 2016 (UTC)- I approve this proposal. --Dex2000 (talk) 11:17, 25 January 2016 (UTC)
- I approve this proposal. --Hakuch (talk) 00:25, 25 January 2016 (UTC)
I oppose this proposal. Existing tags should be documented on the wiki. Adding a suggestion to prefer other keys would be sufficient. --Lyx (talk) 03:06, 25 January 2016 (UTC)- I approve this proposal. --User 5359 (talk) 06:06, 25 January 2016 (UTC)
- I oppose this proposal. The wiki is a place to document what (thousands of) mappers do, not a place to hold votes about what mappers should be doing in the opinion of (one or two dozen) voters. --Frederik Ramm (talk) 06:50, 25 January 2016 (UTC)
- I approve this proposal. I consider this tagging a bug in OSMs data structure, dumping values instead of assigning them. If several values have to be assinged to the same key (what, IMHO, is more rarely the case as this kind of tagging can be found), they should be tagged as key=value1;value2;value3 instead of key=value1, key_1=value2 and key_2=value3 for easier automated data retrieval. --Kreuzschnabel (talk) 07:15, 25 January 2016 (UTC)
- I approve this proposal. --streckenkundler (talk) 07:18, 26 January 2016 (UTC)
- I approve this proposal. --Bjoern m (talk) 11:05, 25 January 2016 (UTC)
- I approve this proposal. --Basstoelpel (talk) 07:22, 25 January 2016 (UTC)
- I approve this proposal. Though I consider this proposal to focus too much on the minor part of the problem: the intended uses of these tags. The main problem, however, appears to be the automatic and presumely not (semantically) intended creation of these tags by iD and imports. --Meillo (talk) 08:08, 25 January 2016 (UTC)
- I oppose this proposal. I think these suffixes name tags still have a place. --Sdoerr (talk) 08:24, 25 January 2016 (UTC)
I have comments but abstain from voting on this proposal. The tags should be documented on the wiki, but strongly discouraged. --Gormo (talk) 08:51, 25 January 2016 (UTC)
- I approve this proposal. UPDATE: after it has been clarified, I now vote in favor of updating the documentation and discourage the usage of this kind of indexed tags. --Dieterdreist (talk) 11:13, 25 January 2016 (UTC)
- please note section "what the porposal wants to do", the existing of the tags shall still be documented on the names page! Hakuch (talk) 11:10, 25 January 2016 (UTC)
- I approve this proposal. --Hca (talk) 10:46, 25 January 2016 (UTC)
- I approve this proposal. I have exchanged mails with some OSM mappers which added name_1=* and similar tags. One of them did not even recognize that iD added name_1=* instead of just replacing the value of name=* (as he wanted to do). Two others added name_1=* manually and told me they thought that name_1=*, name_2=* etc. was the correct way to add alternative names in OSM, just because they saw name_1=* used in OSM data and documented in the Wiki; they were happy to learn that there are more meaningful ways for tagging alternative names (e.g. by old_name=*, long_name=*, short_name=*, offical_name=*, loc_name=* etc.). Because of these results, I think the wiki should emphasize these more meaningful tags; name_1=* etc. should be documented but discouraged, just like this proposal proposes. --Chrysopras (talk) 11:25, 25 January 2016 (UTC)
- I oppose this proposal. The wiki should document how people map, not try and enforce one point of view about how people should map. It's clear from the tagging discussions so far that there isn't a broad concensus about this and so continuing to document the current situation is the best way forward. If you believe that editor authors should make their editors behave differently, raise that issue in the tracker for the relevant editor and discuss there. In OSM as in life there isn't necessarily one "correct" point of view; it's often a judgement call. --SomeoneElse (talk) 11:44, 25 January 2016 (UTC)
- I approve this proposal. Most mappers don't distinguish in the Wiki between documentation of existing tagging and recommendation for good tagging practice. If they find it in the Wiki without warning comments (besides of finding it in the neighborhood), they think it's recommended. --Seichter (talk) 13:42, 25 January 2016 (UTC)
- I approve this proposal.New mappers expect key_X to be common use, but it isn't. It's just a tag to save some notices. That has to be clear to every user. Here the OSM database and the editors must offer a better solution to support multiple values on 1 key. At last the semicolon values should be visible on our official maps and not hided in the data jungle. The wiki should strongly discourage this usage.--Robybully (talk) 15:21, 25 January 2016 (UTC)
- I oppose this proposal. The wiki should give positive suggestions on who to tag. Additionally I don't believe there was a good argument made to remove the tags. Glassman (talk) 15:39, 25 January 2016 (UTC)
- I approve this proposal. --Thomas8122 (talk) 17:13, 25 January 2016 (UTC)
- I approve this proposal. --Fkv (talk) 18:14, 25 January 2016 (UTC)
- I approve this proposal. --Klumbumbus (talk) 18:31, 25 January 2016 (UTC)
- I approve this proposal. --Mondschein (talk) 19:40, 25 January 2016 (UTC)
- I approve this proposal. --IIVQ (talk) 20:17, 25 January 2016 (UTC)
- I oppose this proposal. I would actually prefer the opposite: deprecate semicolons in favor of name_1 tags. Plenty of detailed reasons in this and that mailing list threads. The iD editor issue should be fixed but is an editor issue, not a tagging issue. --Vincent De Phily (talk) 21:11, 25 January 2016 (UTC)
- I approve this proposal. --Waldhans (talk) 21:43, 25 January 2016 (UTC)
- I oppose this proposal. Despite what the tile says, this proposal is about introducing semicolon-separated names, not just about abolishing suffixed name tags. I think we should abolish both, and instead focus on continuing the idea behind old_name, loc_name etc.: Actually express the relationship between names ("this name is only used colloquially", "this is the Spanish name" etc.), instead of just listing them. --Tordanik 12:55, 26 January 2016 (UTC)
- I approve this proposal. --chris66 (talk) 13:31, 26 January 2016 (UTC)
- I approve this proposal. --Hfst (talk) 13:59, 26 January 2016 (UTC) I trink that name_1 etc. is a bad way of tagging. Maybe it would have been better to have changing of the wikipages of name_1 as part of this voting. But as this is ot the case I agrer to the proposal. Further on I think that this proposal is not a proposal about semicolon. However it is a good idea to show workarounds for the case that the proposal succeds.
- I oppose this proposal. This proposal seams to advocate the use of semicolon to split multiple values with an argument that computing time is somehow important to consider over human readability. I find it worse suggestion than _X syntax, though I agree this "_X" isn't totaly great either --sletuffe (talk) 14:28, 26 January 2016 (UTC)
- I oppose this proposal. per Tordanik - name_1 is terrible but semicolons are even worse. alt_name_2 is better than semicolons (I am against recommending "alt_name can be used with semicolons" and similar). Also, title of this page is misleading - it is rather "discourage suffixed name-tags and encourage semicolons" Mateusz Konieczny (talk) 16:17, 26 January 2016 (UTC)
- I approve this proposal. I approve deprecating _N suffix in favor of more specific tags where applicable, or semicolumn usage. Using such suffixes in a database (OSM) is non optimal, and I think current and future tools would deal better with specific tags or semicolumn --Gileri (talk) 17:20, 26 January 2016 (UTC)
- I approve this proposal. --Dr Centerline (talk) 19:39, 26 January 2016 (UTC)
- I approve this proposal. --IndyMapper (talk) 20:21, 26 January 2016 (UTC)
- I approve this proposal. WTF. --Zverik (talk) 20:38, 26 January 2016 (UTC)
- I approve this proposal. --Dooley (talk) 20:51, 26 January 2016 (UTC)
- I approve this proposal. --Lks1 (talk) 02:03, 27 January 2016 (UTC)
- I approve this proposal. --OPerivar (talk) 17:03, 27 January 2016 (UTC)
- I approve this proposal. I like the idea of semantically rich tagging when possible. And using semicolons for multiple names is better than name_N tags. I reckon it's easier to parse semicolon tags, and I also think it makes the data look more elegant. Using multiple keys (name, name_1, name_2, etc.) for multiple values instead of putting those values in the same key is a bit of a kludge to me. --GeoKitten (talk) 23:50, 27 January 2016 (UTC)
- I approve this proposal. It’s apparently a misconception of some opponents here, that the proposal would encourage the usage of semicolon-separated name keys. In fact, the opposite is the case: the proposal aims to encourage the use of semantic name keys like loc_name, old_name, short_name, alt_name and so on. The use of semicolon separated values is restricted as „ultima ratio“ when other keys should not fit. The developer of the iD editor might reconsider his opinion. To my impression many would appreciate a warning message, if users are likely to produce x_n keys.--geow (talk) 19:31, 28 January 2016 (UTC)
- I approve this proposal. --Michi (talk)
- I oppose this proposal. I second Tordanik's opinion --Peda (talk) 23:33, 28 January 2016 (UTC)
- I approve this proposal. While I agree with SomeoneElse that the wiki should be descriptive more than prescriptive, I think it makes sense, in the case of core structural elements such as how to represent lists of values, to promote a single standard. --Saintam1 (talk) 21:27, 29 January 2016 (UTC)
- I approve this proposal. Makes sense. —seav (talk) 00:52, 30 January 2016 (UTC)
- I approve this proposal. --Mueschel (talk) 13:51, 30 January 2016 (UTC)
- I approve this proposal. --Reneman (talk) 00:38, 3 February 2016 (UTC)
- I approve this proposal. --Jojo4u (talk) 09:41, 5 February 2016 (UTC)
- I approve this proposal. Don-vip (talk) 10:55, 7 February 2016 (UTC)