Huge changesets (spanning large bbox)

[mnalis]

Use case
It seems that SC will happily create changesets covering large area. It is problematic for anyone watching the map as it will inform anyone in that bbox who is watching, and parsing/checking such a changeset is time consuming.

For example I've stumbled upon this one: https://www.openstreetmap.org/changeset/103921399

It should not be a problem during normal usage, but since SC allow users (after warning) to solve quests that are not related to their GPS position, it can produce such results.

Proposed Solution
Perhaps the changesets can be force-closed when:

• quest answers change to another country
• or when user answers the quest that is not close to their GPS coordinates?
• or when top-left quest is too far away from bottom-right quest ?

[westnordost]

That would require StreetComplete to know what elements are already in the changeset. It doesn't memorize which edits went into which changeset. I reckon that with some implementation effort, StreetComplete could memorize per edit into which changeset id it went. But then, the position of the edit that is about to be uploaded must be compared to the position of every single edit that has already been uploaded and if the smallest distance to any other edit is greater than X, create a new changeset.

But this adds a lot of complexity, really. You can create a large spanning bbox in every other editor as well. This kind of issue, that an extremely large bbox is created, should be extremely rare. Maybe occur once if someone is travelling and forgot to upload his contributions. So I don't see the necessity to solve this in the app.

Besides, large bboxes may point to that the particular user is misusing the app, i.e. using it not as a surveyor tool but contributing here and there. Thus, especially if it happens more often, it is better to contact him about it and instruct him. Like it has been done in the linked changeset. If SC would cut these kind of contributions into single changesets, then this information (about possible misuse) would be lost.

[FloEdelmann]

see also #2053