Id: Prevent edits to large features

[bhousel]

This recent changeset caused big problems for us at Mapbox.

It makes me sad, but I now think we should prevent users from editing all large features. Where "large" roughly means, "visible from space". iD already contains special code to prevent most operations on features that extend past the viewport, but we still allow:

• [ ] deletes
• [ ] tag changes
• [ ] relation membership changes
• [ ] edits to child nodes

Some of this is tricky because we would need to disable the sidebar, and we don't have code to do that just yet. I had started work on a restrictions branch to do this a long time ago, and need to reboot that work to fit with the new iD v2 modular code.

[slhh]

We should improve protection against acidential edits, but preventing edits of large objects in general seems to be a bad idea. JOSM users make errors too, preventing iD users from editing means that the majority of users cant fix the error. This can led to long lasting errors on large features, especially in regions with a low density of users.
Preventing most users from editing would also led to bad maintainace of the features in general.

In addition we can't define well which size is too large. A size which could have high impact in a city, could just be a small part of a wood or a river in sparsely populated areas. Especially in sparsely populated areas OSM needs every user, and nobody should be prevented from editing large feature, which are quite common there.

Errors of small features can also have a high impact on applications like routing.

Causing big problems at Mapbox seems to indicate that Mapbox is using the OSM data the wrong way. Don't assume that the database is sufficiently correct for a professional application at any specific time.
Sufficient validation should have shown the data issue, and fixing it was likely not a real problem. So why big problems?

[bhousel]

JOSM users make errors too

What JOSM users do is somebody else's problem. I really only have the personal bandwidth to minimize breakage caused by iD users.

That a person trying to make real contributions to OSM was able to break Lake Michigan so easily (within 30 minutes of signing up, their second changeset, and they were trying to add actual footpaths along its edge), well that's shitty. I think we can do better.

preventing iD users from editing means that the majority of users cant fix the error.

I would not trust the "majority of users" to be able to fix errors in great-lake-sized multipolygons, especially using iD. I wouldn't even attempt it myself.

In addition we can't define well which size is too large.

I can define it however I want, see: https://github.com/openstreetmap/iD/pull/2442#issuecomment-269270580
We can always change it later.

Causing big problems at Mapbox seems to indicate that Mapbox is using the OSM data the wrong way.

You may be right.

Sufficient validation should have shown the data issue, and fixing it was likely not a real problem.

We fixed it within a few hours, but when OSM looks bad, we look bad.

[Abbe98]

Two reasons why I don't believe in this solution:

1. The core issue does not lie within iD.
2. Small edits to large features are still valuable.

I'm by the impression that Mapboxs frequency for pulling data from OSM compared to its validations efforts are way off.

The best solution both for Mapbox and the community would probably be to set up something like Wikipedias ORES system, but simpler(without any ML stuff). Check for large diff areas, broken polygons etc and only do this for large features. No need to train it as with ORES. Then turn down how frequent you pull data from OpenStreetMap to maybe an hour and you/the community would be able to catch all major accidental or vandal edits(at least in my perfect world :see_no_evil:).

If implemented others should be able to disable it when initializing iD.Context().

[slhh]

That a person trying to make real contributions to OSM was able to break Lake Michigan so easily (within 30 minutes of signing up, their second changeset, and they were trying to add actual footpaths along its edge), well that's shitty. I think we can do better.

Yes, we can and we should do better, but without preventing intended contributions. I will add some issues and comments how to do it later.

I would not trust the "majority of users" to be able to fix errors in great-lake-sized multipolygons, especially using iD. I wouldn't even attempt it myself.

Wasn't it just a tagging incident? In this case most iD users are likely able to fix it, or don't you trust iD itself?
In case of a polygon stucture error I absolutely agree, but this is not due to the absolute size of the feature but more due to its complexity. I would support preventing structure breaking edits on multipolygons, maybe except of very small ones, but we have to offer editing methods which are not breaking the structure instead.

I can define it however I want, see: #2442 (comment)

That Manhatten size seems to be too small even in densely populated countries.
Protecting Lake Michigan size would be less of a problem, but of course not really protective.

but when OSM looks bad, we look bad.

Mapbox can do better and prevent this.

[slhh]

@bhousel Here is my recommendation to protect large features:

• Delete: #3700 .
• Primary tags: #3693
• Secondary tags: No special protection for large objects required. Secondary Tag issues of large features doesn't seem to have much more impact than such issues of small objects. Routing applications are most sensitive in view of secondary tags, but can be broken by tagging errors of tiny feature too, with similar impact.
• Memberships of the large object: No protection because the possible impact of issues seems to be small.
• Members of the large object: Prevent structure breaking edits of multipolygons, but provide non-structure-breaking editing methods. Similar for routes, but a somewhat protected method for structure breaking needs to remain, because routes can be broken in the real world.

3692 and #3699 can provide additional protection if desired. Warnings in case of large feature edits may help to protect too. I know you don't like warnings, but a warning is much better than preventing a user contribution.

[skylerbunny]

Large as in 'Visible from space' isn't really the problem here as much as large as in 'high number of members'. This number is tunable and server resource dependent, and can probably be set by looking at how long we consider an 'acceptable wait' after hitting 'Save'. I can run into this kind of problem with plenty of other objects, such as highways with huge numbers of members, or NHD water multipolygon import edits.

This changeset ( https://www.openstreetmap.org/changeset/45728492 ) took on the order of 30 minutes to save, which is why I went looking in iD issues to see if it was being discussed. My guess is that the iD backend server either dug deep into swap or had some other kind of I/O resource constraint. Simply trying to look at https://www.openstreetmap.org/relation/4039486 (Lake Superior, and that specific query is probably not done by iD ) routinely produces a 500 error (probably running out of time to run the query).

This is a two ended problem: huge enormous relations that no editor, iD, JOSM, whatever can sanely deal with (the solution there is breaking up the relations into ones with fewer members and supporting superrelations in rendering if need be); and where to draw the line for iD in particular to stop a user from making the attempt at edit time. The latter is something iD can do.

[yaugenka]

Here are a couple of cases when editing large objects is needed.

1. waterway lines of wide rivers, e.g. you cannot fix the waterway line of Dniper river because the river bed is so wide that it does not fit into your screen and thus you cannot determine the central position for the line. https://www.openstreetmap.org/edit?way=24588426#map=16/50.7595/30.4577
2. antarctic coastline is constantly moving, and it does not make sense to draw it large sсale
3. adminitrative boundaries in some countries need to be drawn roughly at small scale, e.g. in Belarus we do not have administrative boundaries level 4-8 data available from government authorities and have to draw them roughly at small scales.

I would suggest to allow editing at small scales at least the currently selected object.

[maxerickson]

For the Great Lakes, preventing deletion of junction nodes vs other nodes is a big win for safety without adding much restriction. Lake Ontario has ~400 outer ways, so ~400 nodes where deletion causes a problem, and a total of about 75,000 nodes. The others are similar.

[planemad]

Found a good example of an edit that could be prevented with such checks. In this changeset a new user tagged a city relation as a building.

This was the contributors first edit and had started the iD walkthrough, but clearly was not ready to edit relations yet.