search

openstreetmap / iD

🆔 The easy-to-use OpenStreetMap editor in JavaScript.
https://www.openstreetmap.org/edit?editor=id
ISC License
3.35k stars 1.2k forks source link

Prevent accidential feature type change #3693

Closed slhh closed 7 years ago

slhh commented 7 years ago

This is related to the Lake Michigan incident (#3681), where the user has changed Lake Michigan into a highway. In order to prevent such accidential changes of the feature type, we should do:

bhousel commented 7 years ago

Make more clear what the user is doing. Changing the feature type of an existing object is only indicated by the hover text before clicking the inspector header box. After that click it doen't seem to be clear for new users what the feature type list means.

I don't know, I kind of disagree that it is confusing. The hover text says "Change feature", and then they're presented with the familiar list of presets to pick from (We train them how to choose a preset several times in the walkthrough). The user can back out of this selection any number of ways (pressing esc, clicking the forward button, or clicking literally anywhere else on the screen except for choosing another preset). Even if they do change the preset.. The rendering of the feature will change, the preset text will change. They can change it back via the same method, or undo.

Don't offer all feature types for existing objects from the database, but offer similar types only. It seems to be quite rare that an existing feature needs to be totally changed in type.

This is a harder problem than it seems, and building a bunch of knowledge about the idiosyncrasies of OSM tagging into iD itself would make things more confusing and we'd still never get things completely right. For example, adding logic like "you should never change a lake to a highway" means that we have to code how lakes are tagged (coastline or lake?) how highways are tagged, what all this stuff means, and keep up with tag trends that change frequently. The tags themselves are invented on the fly by non-experts. And that's just one rule. People would want thousands of these mini validations built into iD. Instead, our flexible preset system covers 99% of cases pretty well.

An easy fix here would be to just say that the thing the user is trying to edit is too big and that they should use another editor (or some advanced iD mode) to edit it.

slhh commented 7 years ago

I don't know, I kind of disagree that it is confusing.

Clicking more or less accitentially on the header within the first few steps in iD I think it could be confusing. Later it is likely ok. And we are not talking about something that would be misunderstood by most users, but about removing some little remaining risks. I think the rendering change might have been not very obvious in the Lake Michigan incident due to incompletely loaded/shown multipolygon.

This is a harder problem than it seems

It seems to be worth to think about it, because it can also simplify normal feature type retagging, and making the user aware of nearby feature type options can increase tagging quality. Offering a button to show the full list in a second step would allow us to be somewhat incomplete. My idea to do it: Let the OSM community define feature groups in the Wiki. Source this into iD on build. Show all feature types of all groups containing the current type, provided they are matching preset rules.

slhh commented 7 years ago

An easy fix here would be to just say that the thing the user is trying to edit is too big and that they should use another editor (or some advanced iD mode) to edit it.

Directing users to use editors which they are unfamilar with doesn't seem to be a good idea for the safety of the big features.

Requiring a special mode to edit large features seems to be acceptable, but having this mode on should not generate significant additional risk for other edits.

Doesn't a large feature edit warning stating size, name, old type, and new type provide sufficient protection?