Id: Should iD just offer to upgrade tags?

[bhousel]

In #4585 we added a bunch of new Public Transport presets. iD will still recognize the legacy tags on a feature, but users really wouldn't know to change that preset to the newer Public Transport version.

Should we just add a button or something to let the user know if they are looking something that can be upgraded? Should we just silently upgrade the tags?

This would be for situations like in Public Transport and Healthcare tagging where there is an old tag and a new tag and it's totally clear how to do the upgrade..

e.g. highway=bus_stop -> public_transport=platform + bus=yes + highway=bus_stop

[manfredbrandl]

For new tagging schemes it should be as easy as possible to do the upgrade. But then everything could also be done with an (well discussed) automatic worldwide (or country by country) update.

[bhousel]

But then everything could also be done with an (well discussed) automatic worldwide (or country by country) update.

Yeah but let's keep this discussion just to within the scope of what iD can do.

[manfredbrandl]

Okay. iD should upgrade objects at the time of selection. Then the user should see that an upgrade has been made and can reject it. Starting to change the object or selecting another object will accept the automatic upgrade. Of course there should be the possibility to undo and redo.

[althio]

I would like to see a gentle notification, as a politeness of the software and for profit and learning of the human contributor.

[slhh]

Should we just silently upgrade the tags?

To do it silently, there needs to be overwhelming consent, much more than required for a mechanical edit.
Otherwise it's not fair to misuse the accounts of the editor users to do a large scale automated edit, which might be controversial.
In addition such a silent change in the editor is like running a botnet to make an automated edit, which makes it much more difficult to detect and revert any issues than in case of using a normal bot.

Should we just add a button or something to let the user know if they are looking something that can be upgraded?

A field with a button to upgrade seems be fine. The user would be aware and made responsible to check due to using it intentionally.
Nevertheless I wouldn't recommend to use it just as a replacement of an bot edit, there should be another reason to do it in the editor, for example:

• The upgrade is potentially required to continue mapping succesfully. E.g. upgrading stops and platforms might be required to assemble the routes, but this doesn't seem to be a valid reason yet, because iD doesn't allow to map the PTv2 routes by now anyway.
• A bot operation is not possible, because some user input or subsequent check/clean-up is required. E.g. we may offer two buttons to upgrade a bus_stop vertex, one to upgrade to stop position, and one to upgrade to platform. In other cases an upgrade wizard might be started, instructing the user what to check or clean-up.

[bhousel]

What about something like this?

[althio]

@bhousel wrote

What about something like this?

I like it, I think it is a good design.

I would only recommend changes to the wording and style of (old) / (new).
As it is, I find it a bit short or terse.
I mean, an average mapper may not realise what the (old) refers to?

• Is it an _old_ bus stop on the ground, like _ancient_ or _historic_ or _disused_ object in real life?
• Or is it the same object, but with an old mapping scheme?

I propose (if it fits typical iD vocabulary and English native usage):

Bus Stop / Platform (_old-style tags_)
Upgrade to _new-style tags_ ❔/ ℹ️

[bhousel]

I like it, I think it is a good design.

Thanks!

I would only recommend changes to the wording and style of (old) / (new).
As it is, I find it a bit short or terse.
I mean, an average mapper may not realise what the (old) refers to?

Is it an old bus stop on the ground, like ancient or historic or disused object in real life?
Or is it the same object, but with an old mapping scheme?

Yes these are good points.. We do need to keep the wording very terse to fit in the limited space (especially for longer languages like German), and iD doesn't assume that the user knows what tags are. I was thinking to add a tooltip explaining these things if they hover over the [?].

I also wouldn't want the user to think the "(old)" means "historic", but I hope that the "Upgrade to (new)" link below it should make it clear that this is about the feature in OSM and not the thing in real life.

[slhh]

How about using (outdated) instead of (old)?

If we call the link "Upgrade old mapping style" we might omit the (old) in the first line totally.

Is the [?] intended to link to something? The tooltip for explanation can be placed on the upgrade link.

Would the upgrade link be able to check for a connected road to safely change to stop_position or platform.

[manfredbrandl]

How about moving the "(old)" to the second line like "outdated, upgrade to new [?]" and give it a more intensive colour (e.g orange)? So we could share one translation for the old and the new scheme.

[bhousel]

Is the [?] intended to link to something? The tooltip for explanation can be placed on the upgrade link.

It would be a thing the user can hover or click on for more info.

Would the upgrade link be able to check for a connected road to safely change to stop_position or platform.

Yeah I think so.. If I build support for upgrade paths into the preset definitions, they can be geometry-aware.. something like:

"upgrade": {
   "vertex":  "public_transport/stop_position_bus",
   "point": "public_transport/platform_bus"
}

(see also https://github.com/openstreetmap/iD/issues/4139#issuecomment-314964313 for some more ideas about preset links)

How about moving the "(old)" to the second line like "outdated, upgrade to new [?]" and give it a more intensive colour (e.g orange)? So we could share one translation for the old and the new scheme.

Sounds ok, I could move it to the second line. I do want to leave it as a clickable link, which is why it shows in the standard iD link color.

[ghost]

I'm a bit afraid.

• If you give the user a choice:

  • a lot of them will be confused. “What's old about that mapping style? It looks the same!”
  • some will start systematically going everywhere and convert old schemes to new ones. As has been pointed out above, this is worse than a bot.
    

• If you don't give the user a choice, you're doing a covert mechanical edit, as has been pointed out above as well.

And either way, the user will be blamed for any mistakes and won't have a clue what's going on. Messing with other people's work is less accepted than adding garbage.

[bhousel]

Messing with other people's work is less accepted than adding garbage.

Hey be nice, what we're talking about here is neither of those things.

[tordans]

@bhousel I like your wireframe (https://github.com/openstreetmap/iD/issues/4591#issuecomment-349844009). What I would improve is …
(a) add a clear call to action, so people are triggered to use it – but make it optional and an easy but manual click
(b) add a link to where I can learn more – eg to prevent the issues described by https://github.com/openstreetmap/iD/issues/4591#issuecomment-354509780 . This link should also describe what the change is.

_Wireframe:_

(Wording needs to be changed to follow the current wording "styleguide"/pattern.)

Reference: http://www.openstreetmap.org/edit#map=19/52.47743/13.44902 / http://www.openstreetmap.org/node/3849495026

_For the link for (b):_
Is there something like a changelog, where changes like you describe in your initial post get documented and communicated to the mappers? This would be an ideal link target.

If this does not exists, I wonder what the solution with the least effort is. The goals are in my opinion:

• Tell people what happened: the presets changed for the editor, this element uses the old presets
• Tell people what the change is: List the current vs. new presets
• Tell people what they should to: Use the button to update the presets, then review the tags and commit the changes. But only for edits they do anyway, no manual mass-editing which is a different task.
• Tell people what will happen: The button will only update the tags but nothing will be saved, all can be "undone"

[bhousel]

@tordans I don't want to over think this. The wireframe you posted looks scary and serious. These tag upgrades are dumb and uninteresting to 99% of users.

Honestly the public transport / healthcare / deprecated tag upgrades should really be done by a mechanical edit, and I am kind of embarrassed to bother my users with this stuff. I don't want to waste their time with what the changes are actually are, or ask them to "review" them, or have them look through the details in our changelog.

Ideally if we are doing a great job on iD, users don't even need to know about tags.

I'm ok with dropping this idea if OSM is really not ready for it.

[tordans]

@bhousel I understand your point. I think the best way is to drop it then!

The thing is, users need to trust the editor. Once the editor does stuff the user does not see or understand, this trust is gone. Users need to feel in control about whats happening.

Therefore the only solutions are IMO

• mass edits as you described
• make it part of the UI but explicit, make it a nice experience at the same time

I don't know the tag upgrades. If all are better served with a mass update, then this should be solved at that front (where ever that is …), not here.

PS: Scary is more of design issue IMO. For example a different color makes it look nicer …

[manfredbrandl]

@tordans I support @bhousel with his aim of "... doing a great job on iD, [so] users don't even need to know about tags. So I would like to either make it very easy to upgrade the tagging scheme ("Upgrade all further viewed items of this type to the new scheme") or to do a mechanical upgrade/edit (after discussion and approval of course). It think with the introduction of a new tagging scheme the mechanical upgrade should be discussed and approved together with the new scheme.

[tordans]

@manfredbrandl My point on "trust" and "user need to feel in control" still stands, doesn't it?
So I still thing those changes should be done somewhere else, not (automatically) in the editor.

[Marc-marc-marc]

I like the idea even though it's been abandoned.
couldn't we provide a user parameter ? or a one-shoot request
like " allow the automatic change of depreciated tags by their replacements ?"
the list of depreciated tags to be changed automatically could be based on the one existing on the wiki.
the change should only happen for modified objects.
another editor has a list of tags that are automatically deleted (for example created_by), it doesn't shock anyone.

[bhousel]

I like the idea even though it's been abandoned.

I like the idea too, but in the end everybody needs to trust iD to do the right thing..

@tordans @M1dgard and @slhh raise valid points and if they don't trust iD to upgrade tags, then we don't need to do it. Someone else can write a tool to do it or kick off a manual challenge to perform the upgrades. We earn trust in the software by listening to everyone, both iD's fans and critics alike.

[tordans]

I have a new view on this now: Based on the information from "Wochennotizen 392" (the englisch Version weeklyOSM 392 does not include this part) there is a concept of "Discardable_tags" already. Which is also part of iD (Code).

The discussion in the german OSM forum has a very interesting point: The opinion is, that automatically updating (in the discussed case deleting) tags is a bad idea, since it clutters the DB and suggests something is updated by a user when in fact it was just a rename. This way we loose the "note last updated at" feature as a reference for "a user was there and worked on it".
More: https://forum.openstreetmap.org/viewtopic.php?pid=681490#p681490

I agree with this point of view. So auto updating feels more ok now since mass-updating has also some problems.

But I still think that the editor should show the user whats going on. The same forum question above shows the confusion that the initial author felt about the editor deleting stuff without his knowledge.
It's bad interface design and feels wrong, that the users needs to go to a forum to learn what any of those editors are doing.

New approach

The main goal is "user can figure out what the editor is doing in the background".
The first approach was to make it explicit by giving the user the choice.
But maybe its more about the step after I commited the changes. In most cases I will not care about the auto-delete and auto-update. But when I see them, I need to understand what happened.

Is there maybe a way to add an information text on the change-set-view?
Something like "Every changeset where created_at was deleted or highway=bus_stop was changed gets a text saying 'Learn more about automated deletions and updates of tags in iD Editor' which explains whats going on."
This text will have false positives since we don't know if the change was by the user or editor. But in both cases, the "learn more" text is correct (just less relevant when the change was by the user himself).

[bhousel]

@tordans It's not clear what has changed in your position. It sounds like you still don't trust OSM editor software to adjust tags for the user, and you want more visibility into what the editor software is actually changing. iD might not be the right editor for you (maybe level0 is?)

The person I primarily design iD for does not care about tags. I'm happy if they don't even know that tags are a thing.

A link like 'Learn more about automated deletions and updates of tags in iD Editor' is the opposite of what we're trying to achieve with iD.

And anyway, iD doesn't _need_ to do this tag upgrading stuff. There are like 260 other issues right now that would make the editing experience better for casual users, or would enable casual users to contribute useful stuff to OSM that they currently can't contribute without reading volumes of osm wiki pages.

[bhousel]

I've been thinking more about this, and I think we should do it anyway.

[tordans]

OK :-). Then lets go and make this more concrete. I tried to create a summary below, HTH.

---

I read through https://github.com/openstreetmap/iD/issues/5430 and agree, this is a perfect case for auto-changing tags. Especially, since it will remove complexity of that issue to link to a helpful documentation.

There are two questions IMO:

• a. In what cases does it happen. What is the trigger.
• b. How do we inform the user.

a: In what cases does it happen. What is the trigger.

a1. Only when the user edits the specific item in a way to match the new tagging-schema. In #5430: If the user adds the substation=* type, we know the new tagging is known and can auto update to substation. Which is also, what the wiki recommends "take the opportunity to review the object and add useful information. In particular it is very desirable to add the voltage=* and/or the substation=* type if those tags are missing."

• Advantage: We can be fairly sure that this change was meant to be; its more of a service.
• Disadvantage: Feels like the most complex to work out (relation graph "if tag X was added, auto-change Y").

a2. Retag as soon as the node is changed by the user.

• Advantage: Less complex to do than a1.
• Disadvantage: Might include more changes that dont follow the new intend of the tags. But I dont know enough about eg. the transport changes. For the substation that would be fine IMO.

a3. Retag as soon as the node is touched by the user.

• Advantage: Probably less complex to do.
• Disadvantage: User changesets will probably include changes that she doesnt know about. Also a2.

a4. Retag everything in the viewport.

• Disadvantage: As a2 and a3 but more so.

a5. Other?

b: How do we inform the user.

We have been through a lot of them. In general I see three categories:

b.1: Let the user choose to update https://github.com/openstreetmap/iD/issues/4591#issuecomment-349844009, https://github.com/openstreetmap/iD/issues/4591#issuecomment-354594388

• Advantage: High feel of control
• Disadvantage: This only helps if user understand it. But we only want to change things that are no-brainer anyways. And explaining it is not easy. So the wireframes are either too complex/scary or to invisible/not enough affordance.

b.2: Dont show anything to the user anywhere. This is the way the discardable tags seem to work in iD ATM (see https://github.com/openstreetmap/iD/issues/4591#issuecomment-361048146).

• Advantage: Easies, probably
• Disadvantage: Whoever does see the change will likely feel like she loses control about what the tool does which in consequence will reduce her trust in the tool since it does stuff he does not understand and cannot control. (Like the liked forum-discussion above hints at.)

It sounds like you still don't trust OSM editor software to adjust tags for the user

For me, it's not about (my) trust in the editor, but about the interface design (or psychological) effect "to feel in control" - like this article goes into more details.

b.3: Show a "FYI" information about the automatic change.

• Advantage: Its automatic (better than b1), but provides some context for those who notice (other than b2).
• Disadvantage: I dont see any. Some might notice this info but feel confused?

For b.3 the question is IMO, where to show it.

• inside the all tags group? Cause this is where more advanced users would look?
• on the post-commit-page?
• on the commit-message-page?
• as a tag in the changeset? (so one could re-construct the information on the changeset later…)

---

My take:

• Either a1 + b2
• Or a2 + b3

[slhh]

@tordans
Variant a1 seems to be too complex.

Variants a2+b3 seems to be ok for indisputable changes, which can be safely performed automatically.
I would show the information in three places:

• The all tags section: The user might not look there, but in case of looking at the tags the user should be aware that they don't match with the database until saving. Maybe, we can just highlight unsaved tags in the all tags section which have been modified manually or automatically.
• Post-commit-page or commit-message-page to make the user aware of the change.
• In a changeset tag to make other users aware of the automatic change, but this should be limited to non-trivial and infrequent changes. If nearly every changeset were marked with the changeset tag, the tag wouldn't provide any useful information.

In case iD really needs to update the tags to display the element or to make it reasonably editable, variants a3+b3 might also be acceptable.

Otherwise variant a3 doesn't make sense for updates, which can be made fully automatically. Variant a3 would revise the elements in the database just to upgrade the tags. If this is desirable, a mechanical edit independent of iD would be the better way to upgrade. If it is not desireable, there isn't a reason for iD to do it.

[bhousel]

I think I'm just going to do something similar to what I suggested in https://github.com/openstreetmap/iD/issues/4591#issuecomment-349844009 - but the link can go on the new link bar that I just added for #5169 . The link will only show up if the preset is upgradeable, and we can define that however we want. Also the link can have a tooltip to explain what tags will be changed.

Hope that helps. I'm not talking about doing anything automatic, the user needs to click something to perform the upgrade.

[slhh]

@bhousel
I like the idea of an upgrade link in the new link bar.
This does allow to offer a reasonable upgrade without requiring it to be totally indisputable in the whole world.
In addition this can supprt cases, where the update can't be performed fully automatically. In this case the link could open an upgrade wizard, which is asking for additional information or instructing the user to do some manual cleanup or checks. For example upgrading a way with highway=ford to ford=yes needs asking for the highway class as the new value of the highway tag.

I'm not talking about doing anything automatic, the user needs to click something to perform the upgrade.

Acceptable usecases of a silent update would be quite limited anyway, and would likely be the least important ones to be performed in the editor.