Great, another [un]Friendly_Ghost 🙄🤦‍♂️.

I have to concur entirely with gurglypipe.

@grin

Why should anyone tolerate their local list of changesets being spammed with globe-spanning bounding-box CSs when said sets make exactly zero changes in the mapper's own country?

Especially when count of said globe-spanning sets EXCEEDS the count of locally-relevant sets?(!)

Explaining that quality work takes effort … well, yeah, of course it does (I say that as an on-foot surveyor, who has sometimes spent multiple hours at the same site). That's not an excuse to be lax or cause other members of the community to suffer the externality of your convenience.

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

What makes for osm.wiki/Good_changeset_comments

“edits based on personal experience.”

source=* = local knowledge

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

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

Seconding Ze0zohk1's comments.

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

Much smaller changeset areas (bounding boxes), please: osm.wiki/Changeset#Geographical_size_of_changesets

“Will remember to sync early and often from now on!”
👍🙂 thankyou.

“Ideally the app would divide these into separate changesets automatically based on distance”
I had a similar thought based on a similar instance of what seems to be the same problem in a different changeset. The author of said changeset stated that he would raise the problem on SC's GitHub repository.

“I don't think it can really be helped with StreetComplete. Correct me if I'm wrong though.”

It can; close existing sets (tell it to upload answers) before starting work on a new area.

StreetComplete is for surveying, anyway, so it's suspicious when changesets span a continent.

Users are responsible for their own account & changesets. A poor workman always blames his tools. If the tools really are broken, then stop using them until they're fixed. Help by submitting bug reports.

I'm tickled that the name typo still exists 😋.

osm.wiki/Keep_the_history

Why so many ways tagged with oneway=no ? See: http://overpass-turbo.eu/s/1cC5

note/2339146

http://www.gov.je/News/2021/Pages/GovernmentOfficeDevelopment.aspx

note/2616804

“I'm missing a few”

A common one is note:lit=[description] while surveying during daylight. E.g., are there even any light sources (street lamps) at all?

This is something of a temporal version of the earlier point re preserving observations for which there isn't yet a way of doing so via tagging.

@Ltrlg

“‘imagery_used’ is neither automatically set nor easy to fill in JOSM”

That's a problem with JOSM's implementation, then; file a bug report. Other editors populate the field automatically.

“I see no point in duplicating in ‘imagery_used’ what is already in ‘source’.”

Doesn't mean that there isn't one.

Each tag serves a different purpose.

Off the top of my head, one would be analytics (‘find all changesets which match …’).

You seem to have assumed a human-readable context, and ignored the machine-readable one (semantic data).