just mentioning that there is another discussion thread for this topic on the list:
http://gis.19327.n5.nabble.com/Please-don-t-think-name-1-tags-are-errors-td5864875.html On 10.01.2016 22:29, moltonel 3x Combo wrote: > On 9 January 2016 at 18:50, Hakuch <hak...@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 > -- BITTE BESORG DIR EINE NEUE EMAILADRESSE! Wenn du mit mir über eine Gmail Adresse schreibst, landet alles was wir kommunizieren bei Google und wird dort gespeichert, analysiert, bewertet, verwendet. Wenn dir das egal ist ok, deine Sache. Aber ich will da nicht mit reingezogen werden. Also schon aus Respekt deinen Kommunikationspartner-innen gegenüber, hol dir bitte eine Adresse von Posteo.de, Mailbox.org oder Riseup.net
0x3CBE432B.asc
Description: application/pgp-keys
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
