Id: adding already existing tag creates X_1

[Haikuch]

as described in https://github.com/openstreetmap/iD/issues/2043 you added a feature that puts a '_1' (or _n) to a newly created tag that already exists for a specific object. You said "This lets the user choose which one to keep." But this actually doesn't work, because the user wont recheck his tag but is trainde to accept it as well-tagged. This features produces data garbage that can't be read by most software.

[bhousel]

But this actually doesn't work, because the user wont recheck his tag but is trainde to accept it as well-tagged.

Maybe, but the old behavior of silently overwriting the tag was worse. Can you think of a better way? E.g. If a user types a new key name, and it changes to name_1 as soon as they are about to enter the value - this is a very visible clue to the user that the key they picked is already taken. I don't think they would miss it. They may choose to ignore it, and someone else can clean up their tag later, but at least nothing is lost.

This features produces data garbage that can't be read by most software.

That has never been a reason to keep data out of OSM.

[Haikuch]

this is a very visible clue to the user that the key they picked is already taken. I don't think they would miss it

Actually, there are over 800.000 name_1 tags in database. Iam waiting for an analysis that shows how much of them is created by ID mappers, so I think it doesn't work :) I guess the problem is, especially with the name tag, that the users think its a good way to add multiple name variants to an object. They dont understand this _1 as an "hey this tag is already used, you should check and find a better solution" but as an "hey, this tag has already been used, I put an _1 and everything is fine"

They may choose to ignore it, and someone else can clean up their tag later, but at least nothing is lost.

sorry, but training people to put garbage in the database and hope for others to clean up later is not a good way, and it actually does not work

So, I think we should work with a notification, maybe a red glowing or something like that. And some information text. There are different situations. Tagging of names is a little bit tricky, thats why there is so much name tags (loc_, old_, short_, alt_...).
Another motivation might be to put two elements in one object (bench and waste_basket) where it should be two objects. You cant put all this in a notification, put the user should know that the _1 is just an emergency method to keep the data.

Maybe it would even be better to have an error when you want to save "sorry there is a problem, I cant save it this way, there are two tags with the same name"

[bhousel]

Actually, there are over 800.000 name_1 tags in database. Iam waiting for an analysis that shows how much of them is created by ID mappers, so I think it doesn't work

Suffixing duplicate tags was an established practice long before iD started adding the _1 suffixes. The raw tag editor isn't even something that most iD users are using.

sorry, but training people to put garbage in the database and hope for others to clean up later is not a good way,

Please be nice. We don't train people to use the raw tag editor, but we make it available if they want to edit tags that way, and we do our best to not let them accidentally overwrite existing data while letting them type almost anything they want in there. I think the current UI is a good compromise.

[Haikuch]

sorry, I didnt want to be not-nice. Actually, I dont have any big experiences with the ID editor, so I didnt know that you try to keep the users away from the raw tag editor. But as long I know, most users of ID are unexperienced mappers. So far I understand that you want to prevent them from deleting values.

And the current solution might keep them from deleting data, but it also creates wrong data. And thats a problem unexperienced users wont recognize. I guess most of them will trust in the editor, that it creates a solution for the problem with alternative names or double amenitys etc. And it even looks like a good solution, because its even more nice for human eyes than the solution with semicolons.

I think, just preventing the users from deleting data and letting them create false data is not the holy grail. I find better to let them know if they are trying to create something that does not work (if the tag already exists).

Currently I dont know how far the _1-tagging correspond with the ID editor, I will try to make an analysis. But all random samples I found where created using ID.

[pnorman]

Actually, there are over 800.000 name_1 tags in database. Iam waiting for an analysis that shows how much of them is created by ID mappers, so I think it doesn't work :)

Almost all will name_1 tags will be in the US from the TIGER import, and it's arguably wrong there.

[Haikuch]

Almost all will name_1 tags will be in the US from the TIGER import, and it's arguably wrong there.
mh, yes, I read about this problem and thought I checked it, but I did it only for alt_name_1. The Taginfo map shows that this is true: https://taginfo.openstreetmap.org/keys/name_1#map

So, I obviously gave a bad example, but the problem is, that this is not limited to name_1. You can find a lot of other examples here: http://forum.openstreetmap.org/viewtopic.php?pid=497888#p497888

[bhousel]

For me personally, OSM got a lot easier to deal with once I embraced the idea that it's a big messy ball of mud and people are free to add whatever nonsense they want to it.

If the name_1's bother you, delete them. If they _really_ bother you, follow the automated edits code of conduct, write a bot, and remove them all en masse. OSM is a do-ocracy.

[Haikuch]

thats really no arguments for not fixing this

And its not only the name_1's as I told you! There are a lot of other really creepy examples that are produced by this Featurebug!

amenity=kindergarten
amenity_1=school

cuisine=italian
cuisine_1=pizza

shop=car
shop_1=car_repair

amenity=town_hall
amenity_1=toilets

amenity=bench
amenity_1=waste_basket

building=yes
building_1=house

[gileri]

OSM got a lot easier to deal with once I embraced the idea that it's a big messy ball of mud
and people are free to add whatever nonsense they want to it.

Data consumers should assume that data could be "loosely" tagged, but data producer should strive to use the best available means of describing entities. That's the only way to break the bad-tagging self-fullfilling profecy.

[SomeoneElseOSM]

@Haikuch @gileri Anything that allows more correct information to be transferred from the head of the mapper to the OSM database is a Good Thing.

If there really are two tags applicable for a place let's allow the mapper to record that information quickly and easily. Someone else might come along later and decide that there might be a better way of mapping it (perhaps that post office counter in a convenience store is best represented as a separate node within a closed way), but they won't necessarily know that there's a post office there if the original mapper didn't know how to record the fact.

As an example, recently I had a look at the tags and keys in use in the UK for shops, offices, commercial and industrial places (to decide how best to group and render different categories). The fact that people used different tags for the same value or different values for the same real-world item really isn't a problem - what is a problem is people using the same tag for different real-world things.

Keys such as "amenity_1" didn't occur frequently enough to bother me (the largest such combination in the UK is the 15 of "amenity_1=restaurant") but if it had, it would have been processed along with all of the other "things that mappers record". To twist Bryan said. it's the real world that's the big messy ball of mud - data consumers will manage just fine as long as there's enough information recorded.

[vincentdephily]

Firstly, I don't think that taking the typed tag as-is (and therefore overwriting an eventual existing value) would be such a bad thing :

• that's how I expect the editor to work
• it seems less damaging to the data than adding a tag that will rarely be consumed
• there's always the history to figure things out if the new value is wrong

But if you do want to avoid the accidental overwrite scenario, how about displaying a (passive, non-modal) popup next to the tag being added saying "this will replace the existing foo=bar tag" ? No obnoxious warning, no user-surprising and data-damaging _1 suffix, no unintended tag overwrite.

[slhh]

We have to differentiate between two situations potentially generating duplicate keys:

• Adding an additional tag using the "All Tags" section with an already existing key.
  This is likely the most frequent case. In this case the user is entering the key first. During editing the key should become red and blinking while it equals any key of an already existing tag, and the value field should show a warning "duplicate key". Changing the focus to the value field should delete the full row, scroll down the inspector window moving the row of the existing tag at the previous position of the deleted row, and set focus to the value of the already existing tag. Thus the user can edit the value of the existing tag at the sceen position where editing is expected. The scrolling movement makes editing of an existing tag more detectable.
• Editing the key of an existing tag (or new tag after setting the value.)
  This is likely a much less frequent issue because the editability of the key is not obvious.

[Haikuch]

@Haikuch @gileri Anything that allows more correct information to be transferred from the head of the mapper to the OSM database is a Good Thing.

disagree. Data thats just tagged without any knowledge about the intention or the source is just garbage. We should better motivate people to write notes in this cases

If there really are two tags applicable for a place let's allow the mapper to record that information quickly and easily. Someone else might come along later and decide that there might be a better way of mapping it (perhaps that post office counter in a convenience store is best represented as a separate node within a closed way), but they won't necessarily know that there's a post office there if the original mapper didn't know how to record the fact.

again, Iam really convinced that we shouldn't motivate people to tag garbage because someone else will fix it. We should motivate them to write notes and fixmes

[DaveF63]

As I said in the Tagging forum: Why can't a "This key already exists, please edit the existing..." dialog be displayed?

That has never been a reason to keep data out of OSM.

It's not an excuse to put it in their either. Two wrongs don't make a right.

For me personally, OSM got a lot easier to deal with once I embraced the idea that it's a big messy ball of mud and people are free to add whatever nonsense they want to it.

That sounds like an attempt at a cop-out to me. I thought the origins of iD was, through use of presets, to keep new users within certain tagging guide lines. It's strange the raw editor predefines random, unused, tags (Do any renderers make use of X_n?).

Shame the owner closed this topic without any kind of resolution.

[Klumbumbus]

Adding ..._1 keys to the database is not a good solution in my eyes. Please change this behavior. Better solutions were already proposed.
Either display a message that the key already exists and can not added again or replace the old value and display a message that the key already existed and was overwritten (with a direct link to undo this).

It is a main principle in OSM that every key can only exist once. I see no reason that new users should not learn this.

[bhousel]

I am not adding a warning message to tell the user that the key they entered is already in use. They can see that the key is in use because the tags are all right there for them to see. We expect that a person using the raw tag editor knows what tag they want to pick.

I do encourage everyone commenting on this issue to actually try iD out for themselves before deciding that they hate what it does.

[vincentdephily]

I've now experimented with the feature in question, and I find it very easy to unwittingly add a *_1 tag. Just start typing your tag, press tab to autocomplete and focus on the value, type your value, enter. You have about one second to notice that you're adding a key you weren't expecting to, it's very easy to miss. And it isn't too hard to find existing changesets that seem to have fallen into that trap.

Even if you expect people to notice the _1 and choose which tag to add, the workflow isn't great: use the mouse to find the original key (hopefully there aren't too many tags in this object), delete it, go back to your own tag, rename its key.

Lastly, the fact that you expect people to correct this double-tagging shows that you agree that they are generally not what you would want to upload. In that case, why make it easy to create that kind of data ?

If you don't want to display a warning, there's a very simple UI you can use: when an existing key is entered and the value field is focused, focus the value field of the existing tag instead. And select the whole field so that 1) the user sees the existing value 2) (s)he can start typing immediately, changing the value of the tag.

Adding a foo_1=* tag is still possible if that's what the user actually intended.

[bhousel]

Hey @vincentdephily thanks for actually trying out the raw tag editing control.

The main underlying issue is that the UI is data bound to a javascript object, and javascript objects do not allow duplicate keys.

As I mentioned in https://github.com/openstreetmap/iD/issues/2043#issuecomment-43391660, the old behavior was really bad. As soon as the user left focus of the key field, iD silently deleted the old key/value pair (which contained real data).

the fact that you expect people to correct this double-tagging shows that you agree that they are generally not what you would want to upload

That's not really true, I think it's fine for users and editors to add suffixed keys when they are unsure of what the correct value should be.

I would interpret the existence of name and name_1 as _"I don't know what the correct value should be but I have a slight preference for name"._

I would not interpret it as _"name and name_1 are both equally valid"_ or _"name is ordered before name_1"_ or anything like that.

[vincentdephily]

Fair enough, the previous behaviour was worse and the framework you use make it hard to improve the UI (although I find it that you can detect a collision and rename, but not detect a collision and switch to the older key ?). But in a way, that's the developer's problem not the user's :)

Your interpretation of "I don't know what the correct value should be but I have a slight preference for name" might be correct when name_1 was added by this feature (although I'd like to add "I actually wanted to add a 'name' key I don't know what happened" to the alternative interpretations).

But the problem is that 'name_1' (and other foo_N variations) is a proper tag that people use on purpose (a discussion about these tags on the tagging mailing list is what triggered the renewed interest in this iD issue). So the db contains foo_1 tags that probably need to be fixed along with foo_1 tags that are correct. This makes QA harder and this is why I'd like to see this UI improved, despite not being much of an iD user.

In some ways, if your anti-collision code renamed 'name' to 'name_fixme_key_already_set_1' instead of 'name_1', there wouldn't be as much of an issue (it'd only be of concern to iD users, not to all OSM consumers and contributors).

[jfirebaugh]

I'm keen to see further exploration of @vincentdephily's idea:

when an existing key is entered and the value field is focused, focus the value field of the existing tag instead

• How would this work precisely in various scenarios:
  
  
  
  • User enters existing key, presses tab key
  
  
  • User enters existing key, clicks on empty value input next to it
  
  
  • User enters existing key, clicks on some other value input
  
  
  • User enters existing key, clicks somewhere else entirely or closes the feature editor
  
  
• How difficult would this be to implement?

[bhousel]

(a discussion about these tags on the tagging mailing list is what triggered the renewed interest in this iD issue).

I think you have it backwards. Somebody (who is neither an iD user nor a data consumer) saw the suffixed tags, didn't like them, and wanted to make iD into a scapegoat. They opened this issue to get me to change iD's behavior and I refused because:

1. Suffixed tags existed long before iD
2. The tags don't bother anybody
3. What iD does currently is really not so terrible (what it did before, overwriting data, was)
4. Raw tag editing is a feature that isn't used much and only by experts who know what tags they want to enter
5. Changing our internal data structure to support duplicate tags would be a pain
6. Displaying warnings is annoying to the user
7. Some tags (e.g. fuel:octane_91) have suffixes anyway that will trip up a validator.
8. The current behavior protects us from users adding keys like __proto__ which is a reserved key in javascript

Unhappy with my refusal to change what iD does, they _then_ went into ballistic mode on the mailing list and opened proposals to vote on wiki stuff, etc etc.

There is now a huge discussion on the list that conflates suffixes (this issue) with storing multiple values for things in OSM (which suffixes were never about, afaik).

In some ways, if your anti-collision code renamed 'name' to 'name_fixme_key_already_set_1' instead of 'name_1', there wouldn't be as much of an issue

I doubt that very much.

What @jfirebaugh said, exploring this idea:

when an existing key is entered and the value field is focused, focus the value field of the existing tag instead

Sure we can do that, but I still see this as a very low priority issue.

[vincentdephily]

Sorry if I got the chronology mixed up between this iD issue and the ML threads. I agree that iD has been used as a scapegoat in the proposal against name_N, and have pointed out in the ML that they were separate issues.

There's just two things from your message I disagree with, and they are the sticking point behind all my comments on this issue:

• Suffixed tags like name_1 have always been about storing multiple values for things in OSM. Whether you like this scheme or not, or even agree that a multi-value scheme has its place in OSM, it has been in use for years and is frequent enough in the db.
• As a result, the fact that an editor creates suffixed tags for reasons other than storing MV bothers quite a few people.

It's not my place to set your priorities and I don't think that this issue is urgent. But IMHO a UI issue that trips users into entering bad data should be somewhere above "very low priority".

[jojo4u]

The proposal Remove suffixed name-tags from wiki was successful and name_1 is explicitly now discouraged on the wiki

[simonpoole]

Commenting on this post close because there is a new raft of problems.

While the opinions may differ on using numeric suffixes on secondary tags (name and so on) and on objects where two distinct functions use the same key (happens now and then with amenities), we now have pokemon go players adding secondary highways keys (highway_1=footway and so on).

I believe most will agree that such tagging cannot make sense,, could we perhaps limit the suffixed key functionality to keys which can meaningfully be present multiple times?

[bhousel]

could we perhaps limit the suffixed key functionality to keys which can meaningfully be present multiple times?

Guessing "which keys can be present multiple times" sounds harder than actually changing the suffixing behavior. iD adds the suffix only to prevent data loss while the user is typing - it has nothing to do with multi-value keys.

[bhousel]

For anyone following this issue still:

when an existing key is entered and the value field is focused, focus the value field of the existing tag instead

I changed it to work like this in 640730d38 - no more key suffixing 🎉

[DaveF63]

Good to see this problem finally resolved.