“I'll try to find some time to search for any existing issues about the same problem / request.”

Just had a very brief look, and there does seem to be (other) demand for negation of multiple fields:
http://www.github.com/mapbox/osmcha-frontend/issues/507
http://www.github.com/mapbox/osmcha-frontend/issues/246

“about the "other guideline", […] it is more or less derived from ACID properties in databases and good practices when pushing commits in codebases.”

I'm familiar. It's a good point.

The problem is a result of multiple factors.

Ideally, yes, a single changeset when making country-wide changes of the same type (e.g. to the same key on multiple elements). Unfortunately, especially for Jersey, the ‘noise’ of large irrelevant changesets then exceeds the ‘signal’ of locally-relevant ones. With no viable solution, it seems.

However, tagging the changeset is a good idea; much simpler than anything else I've seen discussed.

“about OSMCha, but maybe it's something that its developers would accept to consider?”

I would certainly hope so. Shouldn't be difficult to implement. The developers seem to have been thinking in terms of finding specific changesets, rather than filtering out non-local sets. So, it likely just hasn't occured to them to implement negation; it does what they currently need.

I'll try to find some time to search for any existing issues about the same problem / request.

However, it would be much more compelling if whole-France sets were already being tagged #France in order to show real-world need for the change (and to give developers something to test against).

Otherwise it may simply be ignored as a wish-list feature.

Bit of a chicken-and-egg problem, as is common with tech 😋.

“The filtering could be done on a polygon (that would work on all changesets) or on a regexp on the comments (that would require some effort from French contributors).”

Currently I use polygon-based filtering. The problem with that, is that in order to exclude enough noise to be worthwhile, it also ends up excluding large sets which DO make locally-relevant changes. For example, when someone updates the tagging of a chain of shops across the whole British Isles; filtering excludes that set because it's much larger than Jersey, yet the set makes local changes.
Otherwise, back to the original problem; more irrelevant sets (that have a bounding box which includes Jersey) which make zero local changes are still included in the local list of changesets, and overwhelmingly outnumber the locally-relevant sets.

Hence being most interested in your suggestion of simply tagging such sets in a way which makes them easy to filter out. Anything else is a lot more complicated (and even if possible, won't be implemented for a long time).

Your suggestion is simple enough that it should be possible to automate the tagging of changesets, rather than requiring all French mappers to change their habits (which leaves the problem of there always being newbies who don't yet know to add #France).

“I sincerely hope you and contributors who are more expert than me will be able to find and implement a solution that works.”

As do I. Yours is the most promising suggestion, so far. Thankyou for your thoughtful ideas.

Just for my own understanding; how much do you estimate would be involved in having all whole-France changesets tagged with #France? Besides avoiding of guesswork, I'm also completely unfamiliar with the French OSM community.

“Otherwise, you'll just need a vote from your fellow citizens to change the geography 🙂”

Ha! 😁
I won't hold much hope for that. Our politicians struggle with much more basic concerns.

Maybe if the outcome of the Battle of Jersey had been different, than this would be a moot point and we'd be conversing in French.

It would certainly make the current dispute re fishing (post-Brexit) a whole lot simpler, too 😄.

Welcome. Noticed that you're very new, hence the tips / advice.

Re source=* ; OSM isn't simply a produce-a-map project. Even so, the map is the database / dataset (rather than any rendering derived from it). OSM is also a collaborative data-management project. Besides principle & good practice, there are very practical reasons why it is important to have data be traceable (in terms of where it came from), and otherwise having a trail & verifiability.

Sometimes there is well-meaning errors, and/or outright vandalism. Or people copying from proprietary sources.

I wouldn't regard myself as ‘king’, but thanks.

The syntax you used in changeset/114440857 is (to my awareness) correct; semi-colon to separate multiple values for the same key. Keeps it machine-readable, too.

Be wary of osm.wiki/Tagging_for_the_renderer

▪︎What makes for osm.wiki/Good_changeset_comments
▪︎source=* ?

colour should be set to black;yellow, for multiple values. Though, it's mostly black, with only a bit of yellow trim (having driven past it many times).

Why delete & re-add, with no significant changes (to geometry or tagging), instead of simply modifying the existing outline?

Re changes to Cenotaph & related: osm.wiki/Keep_the_history

Modify, instead of delete & re-add.

Might I suggest, then, using a non-surveying editor which would allow you to set

source = local knowledge

instead. StreetComplete is intended for on-site surveying (hence source=survey).

I'm all for accurate changes & improvements, but OSM being a collaborative project also needs verifiability & an audit trail of where data came from.

Besides principles, I say this from experience of having encountered situations for which lacking e.g. source info left me stuck as to what changes were appropriate.

Setting
source=local knowledge
would make this clear, in addition to using separate changesets for each side of the Atlantic.

These were all surveyed recently?

Even so; much smaller changesets, please: osm.wiki/Changeset#Geographical_size_of_changesets

With SC, disable auto-upload and tell it to upload before crossing the Atlantic. That'll generate separate changesets for each continent.

These were all surveyed recently?

Even so; much smaller changesets, please: osm.wiki/Changeset#Geographical_size_of_changesets

With SC, disable auto-upload and tell it to upload before crossing the Atlantic. That'll generate separate changesets for each continent.

These were all surveyed recently?

Even so; much smaller changesets, please: osm.wiki/Changeset#Geographical_size_of_changesets

With SC, disable auto-upload and tell it to upload before crossing the Atlantic. That'll generate separate changesets for each continent.

Hold on. In changeset/114322065 you moved the original addr:housenumber=70 node and tagged it as tourism=apartment . In this set, you made a new node at the original location of what is now the Tetra PoI and then also tagged this new one as addr:housenumber=70 (and as an advertising agency).

How can two entirely different businesses be operating at the same address?

osm.wiki/One_feature,_one_OSM_element

addr:country=GB might be true for the UK, but neither Bailiwick is part of the UK or GB; they're crown dependencies. Independent (self-governing) nations.

For Jersey: *:country=JE
For Guernsey: *:country=GG

“importance”

osm.wiki/Proposed_Features/Importance

“I'm inspired to do some tinkering with OSMCha this afternoon.”

Seems that OSMCha is not able to exclude sets by such parameters. ☹

Since it's relevant: admin_level=*

I get the impression that the numbers should be sequential (viz. not skipping any). Though the wiki doesn't make explicit either way.
Probably have to go digging in the archives for any relevant decision.

changeset/114040294

Correction: Union Street, not Union Road.

Then a changeset comment like “Added buildings, St. (Peter|Lawrence), Jersey.” would've been much more descriptive.

Besides there being imagery_used & source for specifying where the outlines came from (especially since the imagery date & time is (helpfully) included), the remainder (“Jersey”) is utterly meaningless to local mappers.
Please don't use island nations to clock up the country list on HDYC, at least not without doing things properly.