Smaller changeset areas, please.

Close (‘save’) the current set before moving on to a different area or making unrelated changes.

Smaller changeset areas, please. Especially when the set includes more changes than is described in the comment.

“so it's not a lack of proper tools but a lack of willingness to use a tool that's actually fit for the purpose (finding out whether a change set affects your area of interest or not) then?”

No (that is: incorrect). This is fallacious in multiple ways. The question isn't even factually correct.

Besides other factors, I'm in a similar boat as s_SoNick, who articulated the problem more clearly than my own attempt: “Very few others in the area ever touch the maps, and changesets covering gigantic geographical areas have rendered the history for my area unusable”.
For me, using OSM's native UI, the vast majority of what I see are global changesets, compared to a small count of local ones which I must then hunt for.

Further, when I must resort to filtering out any changesets larger than my jurisdiction, as I explained (perhaps poorly) earlier, this also matches some large changesets which do make local-to-me changes. So, I'm in a no-win situation.

This becomes yet more frustrating because there are only a small handful of locals contributing to the area.

“Check those two links I posted above (they are from dev version of overpass run by user mmd).”

Dismissively directing me to proof-of-concept prototype implementations (which isn't a criticism of their author(s), or the tools) that either are troublesome to use on a nano-computer, and/or which have banners stating that they're not intended for production-grade usage, misses the point (and previously stated criteria), as well as being disingenuous if not (intellectually-)dishonest.

If participants aren't gonna be (intellectually-)honest, then this whole topic is already at stalemate.

mmd already addressed the obvious technical problems with such a (‘brave’) proposal, and is more qualified to do so. Thus, I'll defer to him instead of making my own attempt.

“They do not have time to manually construct links, jump from one tool to another.”

Especially when out surveying, or otherwise using a limited device. Even checking the history of an element is a pain in the butt. Reading documentation is also sometimes challenging; stood outside (in front of whatever I'm trying to determine how to add) after a lengthy walk (to reach (or even discover) it), when it's dark, cold, and otherwise less than comfortable …. Often I either simply don't add something, or drop a note, or only do the minimum, because that's preferable to making a silly mistake due to adverse environment.

This is part of why, sometimes, quality surveying takes so damn long.

My overall point, here, is that many of the arguments made in this discussion appear to assume the considerations and/or perspective of armchair-mapping. Plus, neglecting that survey-time is precious.

“Today there's no workable solution available to analyze large changesets.”

@mmd
For those with a tech background, is there an existing write-up of the problems from a tool-dev perspective?

It certainly seems a non-trivial task, but I don't know enough about what'd be involved (being a relative newbie to OSM), and wish to learn & comprehend.

Definitely smaller changeset areas, please.

Also, what makes for osm.wiki/Good_changeset_comments 🙂.

See (also) note #2766493

While I entirely agree with preserving the full & proper names (of roads and whatever else), since doing otherwise seems very much like osm.wiki/Tagging_for_the_renderer since any kind of shortening (abbreviations, omitting prefixes, etc.) is a matter for software rather than data.

However, in order to avoid edit-wars it might be best to make use of a variety of keys (official_name, short_name, loc_name, (possibly) alt_name, …).

That way, if name=* is changed then official_name still holds the proper form in full. It also makes it even easier for software to select which name to use (depending on each user's preferences).

I noticed that for some roads (like at Anne Port) which have multiple (alt_)names, that the semicolon to delimit values is missing.

Plus, if the variation is merely one of including or omitting the Le/La prefix, I would leave the full version in place of both, since abbreviations and shortening are a software problem rather than a data problem.

The only obvious issue I notice is that node #9041271902 (ATM) very much seems to be a duplicate of node #1258166321 .

Does iD not show elements tagged as disused:* ?

“If everyone does large geographical changesets, then no one will want to review local changes in osmcha”

This is one of the troubles I have. While I do use OSMCha to filter-out changesets with large bounding boxes (because, otherwise, for my locality, the noise (irrelevant changesets) exceeds the signal (locally-relevant changesets)), this then means that large-area changesets which do change something local to me are also filtered-out. Thus, I'm not aware of them in order to review them.

“limitation of tools”

I notice that this dismissal frequently arises. Regardless of whatever ideal of how things should be, they're not currently that way. Until they are (capable tools being readily available) then it's a moot and/or academic point. We have to work with what we've got, until what we've got is improved.

More capable tools, besides being hosted at all, will require more resources (both from developers (time, experience, complexity), and the computing variety).

Various lessons from computing history suggest that it is preferable to keep algorithms simple, and for whatever necessary complexity to be in data (as opposed to the inverse). This is based on human cognitive capabilities regardless of any particular development environment (or whatever other technical concerns).

If people rose from their armchairs and went outside to do more surveying, then giant changesets would be less of a problem in the first place.

Also, what makes for osm.wiki/Good_changeset_comments

You could submit changes during your travels, rather than all in a single changeset once you return home.

Else, use an editor which exhibits more granular behaviour.

“Jersey updates”

Care to be more specific? 😋

There's a handful of locals to whom such a comment is meaningless.

Why?

This changeset altered nothing about the seamark itself (i.e. any seamark:* tag), and merely seems to be a delayed revert of my surveying efforts from changeset #108840685 (which was discussed at the time) which now makes the origin of some data misleading. Thus, the comment of this changeset is also misleading, both in subject and action taken.

Is this a case of osm.wiki/Tagging_for_the_renderer ?

I would think that accuracy & verification of representing the real world would matter more than the appearance of uniformity or treating a paperwork source as more credible. What if my survey findings disagreed with the cited catalogue?

There are several unmapped seamarks around the marinas in St. Helier (and other harbours), which I presume don't appear in the paper source seemingly preferred here. If I added those, would they end up being deleted?

What makes for osm.wiki/Good_changeset_comments

Smaller changeset areas, please.

Thanks for the flagpole additions. I'll use them (especially the wikidata Q-numbers) as reference in future.

However, unless the UK flag is flown from a ship, then it's called the Union Flag, not the Union Jack.

Spiffy; enjoy.

I had assumed that this was armchair-mapping, since source != survey.

Thanks; we're rather lacking on the building-outline front (among many other features).

“Jersey updates”

Care to be more specific? Looks like you mostly added several buildings.

@GuyToronto

This is a (notorious) bot; you'll go unheard.

What makes for osm.wiki/Good_changeset_comments