Close changesets during upload

[andrewtwelch]

Idea

Changes don’t appear to automatically close following an upload, it would be ideal for this to happen especially if each stop is uploaded one at a time. It allows for comments to be made immediately as well.

Bug Relation

No response

Implementation

Once all change uploads have been done, send a close changeset request via the API.

Additional Info

No response

[Robbendebiene]

Hi, thanks for the feedback.

The current working principle is:

When uploading answers to a single element look for an open changeset nearby (created by OpenStop)

• If one exists reuse it by attaching the new changes and updating its message
• Else create a new changeset for the new changes

We want to directly upload answers/changes when a questionnaire is done. This means data can be published in short intervals at a similar location. To avoid spamming changesets we therefore do not create a new changeset on every upload and instead reuse existing ones. To reuse a changeset however they need to stay open (they are closed automatically after a certain period).

This basically allows us grouping changes per stop while still uploading the answers as soon as possible. Of course we could group the changes locally and decide to upload them after a certain time or when the user moves away from the stop. This however has the risk of losing answers (closing the app after answering some questions). It is also less explicit and immediate, wherefore we favoured the "reuse changeset" approach.

[andrewtwelch]

Hi, how close do they need to be? These two are fairly close but uploaded separately for me:

https://www.openstreetmap.org/changeset/147718595 https://www.openstreetmap.org/changeset/147718582

[Robbendebiene]

They need to be way closer. As I said we try to group changes by stop (or stop area).

The red loading circles you shortly see before the actual markers appear give you a rough estimation of the bbox in which features are fetched. If an existing changeset falls into this bbox we reuse that changeset (https://github.com/OPENER-next/OpenStop/blob/master/lib/api/osm_element_upload_api.dart#L81-L101)

The "red circles" (we call them stop areas) are built by fetching stops via overpass and combining stops to larger stop areas if they are not more than 100m apart. This is a little simplified but close enough to what is going on. In your case the stops are very simple (no stop on the other side of the street) which means the stop area will only be a circle with a 50m radius around the stop node. Also when visiting this area, only that stop node is fetched since there are no stairs, crossings, etc. nearby.

[andrewtwelch]

The only problem with that, is that you're somewhat going against what you said before about spamming changesets, since for example, this bus route you'd be doing a changeset per stop if you wanted to travel along and do the whole lot. Short of putting some kind of option in the app, there's no perfect solution unfortunately.

You've mentioned not wanting to go down the save and upload later method, however that method seems to work really well in the case of StreetComplete, is it worth looking into that more to see if there's a way to make that an option?

[Robbendebiene]

The only problem with that, is that you're somewhat going against what you said before about spamming changesets, since for example, this bus route you'd be doing a changeset per stop if you wanted to travel along and do the whole lot.

Yes in this scenario you are right.

StreetComplete goes a "quest first" approach while OpenStop uses a "stop/nearby first" approach. Neither is superior in my eyes. It highly depends on the mapping scenario.

StreetComplete's quest type grouping can also lead to:

• single element changesets https://www.openstreetmap.org/changeset/147758992

• not grouping of nearby changesets https://www.openstreetmap.org/changeset/147754490 https://www.openstreetmap.org/changeset/147754503

• large (cross-city) changesets https://www.openstreetmap.org/changeset/144974117 https://www.openstreetmap.org/changeset/147704724

while in other scenarios where one just answers the same quest over and over again by walking around in a city it does a great job at grouping these together.

You've mentioned not wanting to go down the save and upload later method, however that method seems to work really well in the case of StreetComplete, is it worth looking into that more to see if there's a way to make that an option?

Since the primary goal is grouping changesets we do not have to focus on the "save and upload later" point. Not saying that it can't be a piece of the puzzle, but the grouping could easily be done with our existing "reusable changesets" approach.

So if you have any concrete ideas that do not sacrifice the grouping of nearby changes please let us know. Easiest way would be something like "group by city" which again other people may dislike.

We could certainly have some logic like "this stop belongs to a route, check if there is already a changeset for a stop of this route". However I would like to avoid bounding the logic to the existence of public transport route relations.

[andrewtwelch]

I think the best answer, but also understandably not the most ideal answer from a developer/maintainer perspective, is give users a choice as to which way and allow it to be done that way. Personally I’d prefer uploads in bulk (and I also wish SC would let me upload my changes in one changeset instead of one per quest, even though it can be done later and is at least limited in number still).

[wielandb]

Even if it's off-topic, just out of curiosity: What is the benefit of having one big changeset? (In OpenStop and StreetComplete) Because I can see no real benefit and lots of negatives:

• Large BBoxes annoy mappers, what is why StreetComplete even recently implemented a system that will split a changeset if it gets too large following long demand for this feature.
• Having one big changeset would also neccesetate dropping the descriptive CS-Comments that at least SC makes. You would go from "Specify path surfaces" to "Did things"
  • Yes, in OpenStop, this impact would be minimal as the impact on CS comments would be simply dropping the name of the stop area. But still, I think it's nice to have
• Last but most important, both Keeping CSs small and using descriptive CS comments are OSM Best practices that any editor should not brake, let alone implement features to specifically enable users to brake them.

And wierdly, I cannot really understand your last comments in contrast to your first one. You were first advocating for closing CSs immediately, wich means iiuc many small (or even tiny) ones instead of a big one, and then you pivoted to proposing grouping all changes together to a big one.

While I think implementing a "upload-later" feature is a good idea (even if complicated and thus maybe not worth the effort), I think the way changes get grouped together in CSs is good as it is and should not be changed, neither should an option be implemented.

(Saying this as a private individual)

[andrewtwelch]

The issue was logged as a query about how changesets are currently handled, not me advocating for a specific way of handling.

And since it seems like the current handling is both intentional and desired by maintainers with no plans to change, this may as well be closed.