Keep changeset bbox small

[westnordost]

Use case
A user has auto-upload off and keeps solving a lot of quests offline in a lot of different places, e.g. on a vacation. Then later, he uploads them all at once. All the quests get sorted into changesets that span very large areas.

This is somewhat inconvenient for people keeping track of changes in their area because changesets are sorted by bbox in the osm.org UI for looking at local changesets. I.e. the list of changesets displayed for a local area always also includes changesets whose bbox spans the whole continent because e.g. one edit in the same changeset was made on the westernmost verge and the other on the easternmost verge of the continent.

This sometimes leads to clashes between StreetComplete users and those monitoring the changes. The former are oblivious about how this works internally. See also https://news.ycombinator.com/item?id=33035946

Proposed Solution
When adding another edit to a changeset, check if it would enlarge the bounding box of the current changeset over a certain threshold (5 km?). If yes, open another changeset instead and close the previous one.

However, do this only if the edit made is guaranteed to have been made on-site! I.e. 1. location on and 2. the app did not need to ask the user whether he has really checked it on-site.

This requires also persisting this information on creating an edit. The reason for this is that we do not want to hide misuse of this app that should only be used for on-site edits by users who solve quests all over the place while not really being there.

[mnalis]

(related #2053, #2908, #3640 and many linked issues, and FAQ: A changeset made with StreetComplete covers a massive area, why is this? How can it be prevented?)

[mcliquid]

the app did not need to ask the user whether he has really checked it on-site.

One objection: I'm often asked if I am really there when I am traveling by bus or as a passenger and answer several questions for one single POI (e.g. a bus stop) but the bus is already moving on.

[Helium314]

This is somewhat inconvenient for people keeping track of changes in their area because changesets are sorted by bbox in the osm.org UI for looking at local changesets

Actually I get the impression that this UI should be improved to require that edits were made inside this bbox...

However, do this only if the edit made is guaranteed to have been made on-site! I.e. 1. location on and 2. the app did not need to ask the user whether he has really checked it on-site.

This needs to deal with some cases to no wrongly flag edits as misuse. E.g when you're on a car and answer quest for a roundabout that has been cut into many segments. There is basically no chance that you answer some 25 quests while you're close enough, but it's still very easy to remember e.g. all asphalt, no cycleway, all lit and enter the answers while you're "far away".

[mnalis]

E.g when you're on a car and answer quest for a roundabout that has been cut into many segments

This is true, but perhaps it can still work? i.e.:

check if it would enlarge the bounding box of the current changeset over a certain threshold (5 km?).

so, if you add many such small segments of the road that you remember, each one of them would only enlarge the bbox by small amount (few hundreds meters?).Their cumulative enlargements could indeed be hundreds of km for a long trip of course, but as it was done in small increments, that still would not trigger that condition, and thus a changeset would be a subject for auto-splitting

The reason for this is that we do not want to hide misuse of this app that should only be used for on-site edits by users who solve quests all over the place while not really being there.

However, maybe alternatively we could always split the changeset, but mark the potentially non-survey edits by not adding source=survey changeset tag instead? (e.g. #298, #3248 (comment) and others)

[Helium314]

so, if you add many such small segments of the road that you remember, each one of them would only enlarge the bbox by small amount (few hundreds meters?).Their cumulative enlargements could indeed be hundreds of km for a long trip of course, but as it was done in small increments, that still would not trigger that condition, and thus a changeset would be a subject for auto-splitting

But I really don't want to either frequently edit from inside the car just to avoid "misusing" the app, or to remember not editing after I had a 3 minute chat during which the car moved 5 km.

[westnordost]

Don't get hung up on the details. It's not as if the situation would deteriorate for cases where you really were on site but the app did not recognize this automatically.

[westnordost]

Also, keep in mind that the "user has been near the object edited" detection is something that could be improved by taking into account the blue gps track line as displayed to the user.

For example.

But that is a separate thing that could be done.

[crackwitz]

I just saw a changeset of SC 57.1 that spans half of Europe. Does this feature work as intended?

https://www.openstreetmap.org/changeset/149644179#map=5/52.922/16.765

[westnordost]

Yes, I tested it. The changeset is not kept small if the users's GPS location was not near the edited location.

[westnordost]

So, rather than asking the user in the changeset comment to not create big changesets, tell him to only do edits on-site, because with the former, he certainly doesn't know what you are talking about.

[crackwitz]

That user claims to have visited those places over the span of the last three months. That user certainly was not aware that this would cause a single changeset spanning half of Europe, or why that is a bad thing.

I don't know if the user kept those changes in the "buffer" for this time...

This is not about individual users. This is about SC.

I don't care to read up on the years and years of debate over this, and who dug which trenches in this war. That alone is a terrible thing to even have happened and it does not bode well for the future. I did see discussion over differing behavior depending on where the user's GPS location was. I honestly don't see the point in that check. No casual beginner user will understand this distinction, nor the consequences of a prompt. They'll tap "yes sure fine now go away" on whatever dialog, if there was a dialog at all.

The default behavior should be to not be annoying to the community. SC's user base does not consist of people that want to annoy the community but they accidentally do.

The point is: it's never-ending work to educate all those casual users of this app that can cause such changesets without being aware of it. It is less work to tweak this app into forming changesets that span a reasonable geographical area.

If you think you need to defend this granularity of changesets, fine. This user was not properly educated by SC on what they were about to do.

[westnordost]

What war? I think you are assuming a hyperbole that doesn't exist. The current behavior is result of careful consideration after discussion of the options. If you want to contribute something to the discussion, you have to read the reasons for why it works this way. Conveniently (for you), I described the reasons for the current behavior in the starter post (last sentence).

I am fine with changing this if the community at large thinks this is a good idea, feel free to create a forum discussion. But the forum folks should know about the dangers (=possible resulting data quality issues) I would like to prevent with this behavior, so if you do this, please, do present the reasons and caveats in a neutral, objective manner.

Note, that no other OSM editor app is gamified like this app. I fear that gamification may inspire some users inclined as such to not take the in-app warning dialog about that the app should only be used on-site on a survey too seriously and start to remotely add data that they did not actually really check, to get more points and go up in the rankings. "Yeah yeah, it's a road in a city, it will 99% be an asphalt road anyway!".
The current behavior can expose such user conduct, as the changesets are only kept small if the app knows that the user was actually on-site. If the changeset bbox was always kept small, it would be invisible to people doing changeset Q&A. But isn't this the point of doing changeset Q&A, to find changesets that possibly have issues content-wise?

[goldfndr]

More explicitly: that changeset (created 2024-04-06T08:27:34Z) occurred after another StreetComplete 57.1 upload (149642955) from less than an hour earlier (created 2024-04-06T07:46:18Z). The normal behavior of StreetComplete is to upload all answers since last upload. So, unless more than one device was used with one OSM account, keeping those changes in the "buffer" was quite limited, less than an hour.

[matkoniecz]

it's never-ending work to educate all those casual users of this app that can cause such changesets without being aware of it

It will create such changesets only if they ignore clear instructions. SC is for in-place survey.