Err, why?

Might be related to http://github.com/streetcomplete/StreetComplete/issues/3640

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

↑(puma515)👍

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

The parameters seem roughly correct (from what I recall from survey). Though, I didn't see any white segment, not even a thin one (only red & green). However, that was when looking up at the fixture from the pier, rather than from out at sea.

Couldn't have modified the existing elements, instead of deleting & re-adding?

osm.wiki/Keep_the_history

See also note/3013803

See also note/3013803

These might now be disused, but probably need to check with Jersey Water.

See also changeset/115753486

👍

Seconding bxl-forever. However, be aware: http://github.com/streetcomplete/StreetComplete/issues/3640

Possible SC bug. See http://github.com/streetcomplete/StreetComplete/issues/3640

“continent sized bounding boxes may be also caused by user mapping without survey or someone who enabled manual upload and traveled long distance without uploads, so not every large bounding box is a StreetComplete bug.”

Indeed; I've (unfortunately) encountered a few of each. Hence this one being more interesting.

Actually, @Mateusz Konieczny, was there ever a change made for when users are making changes far away from their current location? I recall reading a GH issue (but can't find it, again) in which the suggestion was to not hardcode source=survey but to set the value based on distance to the element. Survey when close, local knowledge when far.

If SC splits changes based on survey vs. local knowledge, then that would solve another common cause large bboxes.

I'm not sure much can be done about users failing to upload changes between areas.

Future reference: see changeset/116101839 & http://github.com/streetcomplete/StreetComplete/issues/3640

Future reference: see changeset/116101839 & http://github.com/streetcomplete/StreetComplete/issues/3640

Future reference: see changeset/116101839 & http://github.com/streetcomplete/StreetComplete/issues/3640

This may now be a solved problem.

See https://github.com/streetcomplete/StreetComplete/issues/3640 from changeset/116101839 . I suspect that it may be the same bug at work, in that case, and this one.

That turned out to be a whole lot more interesting than I was imagining.

Given the nature of the suspected cause, it might explain other instances of SC uploading changesets with large bboxes. Not only in the past, but recently.

I'm delighted that SC devs have such a positive attitude toward refinement. Particularly since I recommend SC to newbies.

Glad that my nudge of Darkhorse led to a resolution (hopefully) of a tricky bug. Thanks, Darkhorse, for enabling that 🙂. Not everyone does bother to report such problems (and I'm reluctant to do it for them, since I have no more details for devs, can't answer questions, and can't test if a commit fixes the problem).

Awesomeness 😏👍.