StreetComplete 43 and 44 does big changesets which are not liked by community

[agent-redd]

The OpenStreetMap community does not like big changesets, which span over several hundred kilometers. The general recommondation is: "Changesets should be local" (see https://wiki.openstreetmap.org/wiki/Changeset#Geographical_size_of_changesets).
These changesets often get comments to be asked for smaller ones in the future.

I checked the FAQs and it does not adress this behaviour yet. Therefore I consider this behaviour as unknown and not intented to the users of StreetComplete.

How to Reproduce
Reproduced in the past. See Changesets examples:

• https://www.openstreetmap.org/changeset/121963131
• https://www.openstreetmap.org/changeset/121930378 (commented)
• https://www.openstreetmap.org/changeset/121839578
• https://www.openstreetmap.org/changeset/121839564
• https://www.openstreetmap.org/changeset/121837494
• https://www.openstreetmap.org/changeset/121568962 (commented)

Versions affected
at least:

• v43
• v44

Edit: add more changesets and wether they are commented by community. Also added wiki link

[10992-osm]

I think this has already been discussed and (possibly) rejected (or at least put on hold…). I'll try to find some links, and edit this comment to add them…

See:

• Changesets sometimes do not get closed, which can lead to excessive large bounding boxes #3640
• Split changesets to prevent huge areas #2053
• Split changesets that would have large bounding boxes #2988
• Quests counted in wrong country #1940
• close changeset if user moved significantly #1100

[10992-osm]

I think the bottom line is that it has occurred in the past due to bugs when uploading, but I believe these have been fixed. If they haven't, then we need to identify what is going wrong now.

The other situation where it can occur is where a user makes changes that are not automatically uploaded, due to the user's settings. This can be either because the user has said that they only want quests to be uploaded on Wi-Fi, and they haven't connected to it, or they have said that they want to manually select when to upload, and have done this after making geographically disparate changes. This is ± intended behaviour, though the last one is unfortunate user behaviour.

[agent-redd]

thanks for the hint for Upload only on Wi-Fi. Why should somebody want this? Isn't downloading the map data much more data then the upload of a small changeset?

[matkoniecz]

thanks for the hint for Upload only on Wi-Fi. Why should somebody want this?

privacy reasons

With uploading on go you give live and accurate real-life location, for example https://www.openstreetmap.org/changeset/121899306 reveals where I was on 14:38 two days ago and it was published when I was there. Bundling edits reduces accuracy.

[matkoniecz]

In general, is there a case where:

• user was editing what they surveyed (no remote edits)
• user has not caused large bbox via deliberated delay
• edit is made is with v40 or later ( Changesets sometimes do not get closed, which can lead to excessive large bounding boxes #3640 (comment) )

?

Currently it seems to happen very rarely to people using SC before boarding plane that have no mobile internet on airports without sane wifi.

[matkoniecz]

I checked the FAQs and it does not adress this behaviour yet.

I added https://wiki.openstreetmap.org/wiki/StreetComplete/FAQ#Changeset_made_with_StreetComplete_covers_massive_area (feel free to edit and improve it)

[westnordost]

In a nutshell

It's as much up to the user as it is for other editor apps. Especially for StreetComplete, which should only be used on-site, very large bounding boxes may be an indicator that a user is not using the app as intended (only on-site), so my/our standpoint on that is that the app should not mask such potential misuse by splitting up the changeset if the bounding box gets too large.

Possible solution

Now, I figure what could be done is to do the splitting up after all but only if the user's real GPS location was actually close to each edited element because in this case, the edits are not suspicious (unless the user spoofs his GPS location, but hey...). E.g. in cases like where the user in this changeset was really in Marseille and later that day in San Jose (or the other way round) and only later regained internet connection.
Of course, if the user's GPS location is not near the element he tries to edit or he has GPS off/disabled/disconnected, the app will always already ask whether he is sure he checked it on-site. But as with any warning popup, it is possible to ignore it.

Implementation

So, to achieve the above, StreetComplete would need to record for each edit whether the GPS location was near at the time the user made the edit or whether he "only" stated he was near. During upload, if uploading a singular edit would make the bounding box bigger than a certain threshold, the new edit will only be put into a new changeset if the edit in question was made when the GPS location was near the edited element.

Benefit

So, there are currently three situations that can lead to big changeset bounding boxes:

1. user edits on-site at one place, travels, then edits on-site at another place and then uploads (either due to no network or due to a manually triggered upload)
2. same as above, but the user has GPS disabled or can't get a GPS fix in one of the places
3. user potentially misuses the app by solving quests wherever while not being on-site

While point 3 is the situation that should not be masked by StreetComplete because it hints at a potential misuse of the app, the implementation above would at least remove situations like point 1 from the OSM history.

All in all, I am not sure about the benefit, as it increases implementation complexity and I don't know how often such a thing really happens. After all, it does not produce wrong data, it is (just) a nuisance for people reviewing the OSM history in their region.

[BalooUriza]

At least on my phone (a Pixel 3XL) the performance and stability improvement from not automatically uploading in real time is substantial, especially in parts of America with bad data throughput. The other possible solution to this would be to allow user selectability to download all quests within a bounding box as a batch, so that the internet connection has some hope of keeping the upload queue clear (though that would be nice to have anyway for planned trips given the low reliability of mobile internet in general, and in the southern midwest specifically).

…

On Sun, Jun 5, 2022, 08:05 Redd ***@***.***> wrote: thanks for the hint for Upload only on Wi-Fi. Why should somebody want this? Isn"t downloading the map data much more data then the small changeset? — Reply to this email directly, view it on GitHub <#4081 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWDFBTZOGKBUVPP6JBHW6LVNSQZFANCNFSM5X474H4Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mnalis]

Related discussion (about detecting if user was really there on the ground according to GPS): #4017