Id: "Autofix" for very close nodes validation

[quincylvania]

In testing, I've found almost no cases where merging the nodes wasn't the desired solution for the "very close nodes" validation warnings. We should allow fixing these en masse via the issues pane. For extra safety, we can specify an even smaller distance threshold for allowing autofix than for flagging the issues (e.g. 10cm instead of 20cm). Note that merging two nodes could affect issues with adjacent nodes, so it's non-trivial to run multiple sequential merges.

[BjornRasmussen]

This could damage existing data if the order of deletion is not fixed: Imagine an imported park with a curving boundary with way too many nodes. At that curving boundary, iD will (with this new feature) merge the two nodes closest the the viewport, and then merge the result with the next node, and so on. This will trigger a cycle that will turn the entire overnoded curve into a single straight line, which would be bad.
I suggest that when the user presses the "fix all" button at the top of the issues list, these close node fixes should be fixed in the closest together nodes to farthest apart nodes order, updating this order after every node-merge.
This will ensure that this new quickfix doesn't destroy existing OSM data.

Here is a place where this would be very useful if the order of fixing was managed, and very dangerous if not: http://preview.ideditor.com/master/#id=w120652374&map=22.28/38.55457/-121.51943

Thanks for opening this issue!

[BjornRasmussen]

If anyone doesn't understand the issue I explained above,
1) Follow this link
2) Try clicking the fix options on the building 50 times.
3) Watch as part of the building slowly gets ruined.

[BjornRasmussen]

In testing, I've found almost no cases where merging the nodes wasn't the desired solution for the "very close nodes" validation warnings.

I've found just one, but can't seem to find it :disappointed:

[BjornRasmussen]

Hmm, I actually found one other case as well: my own house. I had previously gone around it with a measuring tape and added the footprint (at the ground) to OSM as accurately as possible. This included a 5 inch indent at one point which exists in the real world. iD flags this as a false positive.

I still think it's worth adding an autofix for this, though, since fewer than 1% of the cases i've come accross are false positives, and even if they are, it's not like the data is being completely destroyed.

[bhousel]

Another idea is that the min distance could depend on the feature type..
I don't think we need nodes 5 inches apart on highways, but you should be allowed to map your house in detail if you want to.

[Nakaner]

An screen shot illustrating the first example provided by @BjornRasmussen:

Maybe the fix should only be applied (or the validation rule apply) if both neighbours of the node are too close?

@bhousel wrote:

Another idea is that the min distance could depend on the feature type..
I don't think we need nodes 5 inches apart on highways, but you should be allowed to map your house in detail if you want to.

Seems to be a good idea at the first glance but it is more difficult when I imaging how I decide if a way has too many nodes.

While decimetre precision can be achieved by indoor mapping with measurement tape, the mapped outline of a forest cannot have this precision because its boundary is defined/verifiable with that resolution (it's more in the range between 1 and 10 m). Setting up such a list of sharp and less sharp features is a lot of work. It does not only depend on the tags but also on the available sources as well. If you trace landuse from Landsat, one node every 10 metres is too much. But if you trace from high-res aerial imagery, 10 metres are appropriate in many cases.

In addition, the density of mapping in the surrounding should be taken into account as well. If flowerbeds are mapped in a settlement, precise buildings are less an issue as overnoded forest outlines in remote areas of Canada or overnoded areas coming from automated feature recognition (hello Scanaerial).

I think it's wise to flag only very small distances to keep the number of false positives low. Most overnoded geometries come from imports or – in the past – JOSM users converting GPX tracks, don't they? Usually, overnoded geometries are a systematic mistake of an import and not an issue of iD users as far as I can tell from multiple years of reviewing iD edits. And if overnoded geometries are an issue, they are spot easily by other users reviewing the changesets. I think that the time is better invested into other improvements of iD instead of building a ruleset for appropriate mapping resolution depending on the tags.

[BjornRasmussen]

Another issue with this: if issues of this type are automatically fixed _outside_ of the downloaded area, nodes belonging to other ways might get deleted, disconnecting previously connected features. Only close nodes inside of the downloaded area should be fixed automatically to avoid widespread destruction of OSM data.

[BjornRasmussen]

How about if the way with close nodes has a building tag, no autofix is available, but if not, one is?
All of the false positives I've come across are with imported high detail buildings, so this would fix that problem.

[quincylvania]

Thanks for this discussion! I adjusted the validation so buildings, paths, and indoor features have lower thresholds than others. We can still be even more discriminate for the autofix.

[quincylvania]

Closing this since the "autofix" feature has been removed.