@sinisterstuf

“as a user, I was unaware of how the app handles change sets.”
Well, that's by intentional design. So, suggestions of breaking that principle won't get far.

The remedy is, while still hiding the clockwork from users, making SC do the right thing for them. Plus, while avoiding details, better (more clearly) communicating (concepts) to them (users) and enabling them to achieve quality contributions while observing good practices.

“I'll start a discussion on the app's GitHub page to see if we can make this clearer for new app users.”
👍 do post the URL; I'd like to follow it (& probably join in).

@OSM_RogerWilco

“do you know how the App StreetComplete works?”

Short of being a developer; yes. My HDYC (via my profile) clearly shows that I've used it plenty (and more than you have, I note).

I also know that an OSM account (and changesets uploaded) is the user's responsibility. OSM is also a collaborative community project, and unwieldy bounding boxes affect many other mappers.

As sinisterstuf alluded to; my questioning the area of the bounding box led to insight about how to improve the design of SC.
On other occasions, I've discovered that some users were treating SC as a general editor (rather than for surveying) and were modifying places which they hadn't surveyed.

Asking questions leads to enlightenment. Remaining silent persists ignorance.

Occasionally I have pleasant surprises, like from sinisterstuf, who gladly engaged with competence, which led to fruitful information (for us both, I think).

“Does a session last 2 hours or what?”

By session, I meant collecting answers and uploading them. E.g. daily. The duration is up to you. Could be more than daily (multiple taxi rides, for example, with a meeting between; each taxi ride being a distinct session if one wishes).

The 2 hours refers to the timeout which OSM (backend) applies for auto-closing changesets when there's been no further additions to them. Changesets can (optionally) be immediately closed upon submission / commit, or left open (for adding more to).

In SC's auto-upload=always it keeps the (per-quest) set(s) open. Whereas in the other modes it immediately closes them.
If the timeout (2 hours) were longer (and personally I wish it was, but can imagine there being good reasons for it not being too long), then it would be less of a problem. However, what I encountered was, since I had nothing to add to that set (more answers for the same quest-type) for 2+ hours (I was answering other quests), it was auto-closed (by the OSM backend), so when I did then encounter another quest of the same type (as earlier, for the now-closed set) during that day's surveying session (I often do multi-hour ones; 12 hours being my longest so far), SC had to open (yet) another set; messy (for other mappers). Keeping manual control (auto-upload=never;manual) avoids this; they're all uploaded at the end of the day; only one set per quest-type per day. Much neater.

For context; I personally also don't encounter the problem of wide-spanning bounding boxes, because I only survey my local area (which is small to begin with). Were I to travel, then I'd have to take extra precautions (as you've now discovered 🙂).

Further info: osm.wiki/Changeset

“I've been looking for a “force upload” button and I would never have thought of turning off auto-upload to get it”

That's an insightful (usability & UI design) point. Gives me more thoughts re SC's development.

Now that I'm thinking about it, I don't inherently see why the button should be hidden when auto-upload=always. Originally the thinking may have been ‘it's pointless since there'll never be anything waiting in the queue to be uploaded’. However, the behaviour in that case could be modified to have SC close all existing sets; such as for when finished in one city and intending to survey the city one is about to travel to. The tool-tip could describe it as something like ‘I (am moving|have moved) to a different (far away) area’ (I'm reminded of old GPS receivers which had something similar, so that they would know to re-initialise (re-fetch the ephemeris catalogue) since their view of the sky had significantly changed since last used (else they're looking for satellites which are below the horizon).

Changing the icon would be most sensible, too. Though, I'm not sure to what; something to reflect the differing functionality.

“Maybe I'll open a GitHub issue for this or if you do then I'll join it, I'd like to contribute a code change if this can be improved, either with a UI change to make this button easier to find, or clarifying the consequences of the different upload options or adjusting the logic for when to upload what changes a bit.”

Oh, please do: http://www.github.com/streetcomplete/StreetComplete/issues
That's what I was intending to do, until it became clear that you're tech-savvy.
It would be much better coming directly from the user affected, rather than second-hand.
Cite this changeset there, for reference. Your comments are insightful to inform design. Especially since SC is intended for newbies and to not require knowing or understanding the underlying clockwork (which has evidently been broken / violated, in this case).
I'll gladly subscribe & chime in on the interaction-design front.

On the basis that you'll be opening the issue, my earlier thought for avoiding this case was to have SC (somehow) figure out, especially when in auto-upload=always, that the user has moved to a distant area and thus should close all previous changesets before further quest-answers are added to the queue.

While a pull-request would be welcomed by Tobias, the important thing is opening an issue for there to be a record of the problem and the ideas for a remedy. Code can come later.

Ah, I see. Thanks for the explanation; that gives me an idea for improving SC to avoid this in future. To that end, which auto-upload mode did you have enabled (I assume Always)?

Thanks for using SC properly, too. Some people abuse it as a general editor for things they haven't surveyed (hence my opening question). Thanks for the contributions, in that case.

One changeset per change would flood the CS list (and people would ignore or filter out those sets, preventing review). SC does a changeset per quest-type (for a given session).

In this case, uploading your changes somewhere between finishing in the UK, and starting in Hungary (so, at either airport) would have avoided this; would've used separate changesets (one (per quest type) for UK and another for Hungary).

When travelling in such ways, it would be best to set SC so that it's not always auto-uploading (since that removes the UI button to manually upload); either 802.11 (‘Wi-Fi’) -only (with caution; see below) or Never. Thus, when finished answering quests in one city, tell it to upload those before starting in the next city.

This way will close the UK changesets, thus quests in Hungary will be added to a new set.

Having used SC for a while, disabling auto-upload is the more efficient mode. Auto-upload uses more power, sometimes makes the changesets a bit messy (they're always closed after 2 hours since the last change, so can sometimes result in multiple CSs for the same area in the same day, rather than all in one), and (in cases like these) removes control from the user (to do the right thing).

“Is it possible to split up change sets after the fact?”
Nope; they're enduring. Hence the importance of things being done right, before committing the changes. There's also no wiki-like reversion; only making more changesets.

Smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

👍🙂.

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Related to changeset/113170026 .

Having tested, since, this is indeed helping routing algorithms 🙂.

Seeking review especially re parking:* tags.

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

You surveyed all of these elements in the same day?

Much smaller changeset areas, methinks: osm.wiki/Changeset#Geographical_size_of_changesets

You surveyed all of these elements in the same day?

Much smaller changeset areas, methinks: osm.wiki/Changeset#Geographical_size_of_changesets

You surveyed all of these elements in the same day?

Much smaller changeset areas, methinks: osm.wiki/Changeset#Geographical_size_of_changesets

The waterfall spans the Atlantic? Smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Since you also changed more than a waterfall, your changeset comment is misleading: what makes for osm.wiki/Good_changeset_comments

“National Agriculture Imagery Program”

Should be specified in imagery_used.

The ATM is still out of order (with the same sign taped over the display). I suspect that it will be for a while yet.

When (or if) it's restored to working order, then the tagging can be changed back.

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets