Apologies, I've only just noticed your reply.

Thankyou for your response. That sounds sensible.

Though, just as an FYI, I read, recently, in one of SC's issues on GitHub, that there's concern over SC being used for non-surveying changes, and an idea was suggested to set survey=local knowledge when the user isn't actually on-site. Though, I dunno if this is actually being implemented in more recent versions (than the one you used).

So, it might become a non-problem in future. For now, though, SC should be used only for survey work, like you said. 🙂

In order to keep your changeset areas small, it'd be better to upload your workplace changes (quest answers) separately from those at home. This will result in separate changesets, which should be localised, rather than spanning a wide area.

In SC either connect to the office 802.11 (‘Wi-Fi’) for it to auto-upload, else tap the upload widget on the main (quest-map) UI to trigger a manual upload. Then changes at home will be separate.

Your mode of usage seems to be that auto-upload is set to perma-on. This works differently. Instead of closing the changeset(s) (SC uses one per quest-type, per batch of answers) immediately after uploading changes, it keeps the changeset(s) (one per quest-type) open. By default, OSM allows them to remain open for 2 hours since the last uploaded change.

So, either change SC's upload mode, or wait until the existing changesets have all auto-closed before uploading answers to quests in a different region.

Though, this behaviour inspires me to open an issue for SC so that it avoids country-spanning changesets. That it, it closes the existing set if the new change is more than N km away from the last.

However, this relates back to SC being intended for surveying, and making assumptions to that effect. It would ordinarily be unlikely that someone would cross such a great distance in the 2 hour window of the same changeset remaining open.

But, edge cares exist. Especially if SC is going to allow non-survey changes at some point in future.

Apologies for the delay; only just noticed your reply.

“it's the tagging recommended by the ID.”

Ah (I've never used iD). The (JOSM-based) presets used by Vespucci need to be updated, it seems.

“[Union (Jack|Flag)] are interchangeable”

That may be descriptive of common usage, but not necessarily correct prescriptive usage.

If they're interchangeable, then would be better to use the more accurate term.

“big changeset […], saw you got the notification too. Probably the reason why you added a comment to this changeset 😉”

That, actually, is exactly what prompts me to comment on such changesets; because they appear in the list when viewing my island (yes, mine; I'm as local as it gets).

Ideally I'd comment on all of them, but I don't check daily. So some are missed.

This seems to be sensible in a few ways;
▪︎only the problem ones get negative attention (and often not just from me)
▪︎when problem changesets cease appearing in my ‘local’ list, then I'll have none to complain about in terms of irrelevancy (spanning my island without making any local changes)

Thus, it's self-selecting & self-limiting. When the problem goes away, so too will my nagging (for those making huge changesets; can't make any promises about non-locals making a mess of Jersey's data 😋).

For all the griping which some folks do (whining about failure to use non-existent filtering tools, saying that nagging newbies is fruitless) there have been enough times when attentive & responsive newbies have actually thanked me or others for pointing out the problem, and vowed to avoid it in future (and I've not seen any more changesets by them in my local list, since). So, the effect is non-zero.

Funny how the ‘use better tools’ crowd have the time to argue, but not to work on said better tools.

Anyway, enough ranting from me, for today 🙂.

I'll look forward to issue #142 being closed as fixed / resolved.

Also only noticed today that I took about 2 months to reply in this discussion. Sorry about that; recently started going through changesets which I commented on, for replies I missed. So wasn't aware until yesterday.

Got there eventually, though.

Good to know re existing issue report. Thanks for the pointer to it; subscribed to notifications 🙂.

Yup, the bounding box just includes my jurisdiction. Yet another changeset adding to the overwhelming noise in the list of changesets when checking local activity.

See for yourself; zoom into Jersey, and then have the Web-UI display changesets within that viewport bounding-box. Most of them will be entirely irrelevant to the island (the noise exceeds the signal), and the majority of irrelevant ones are giant continent-spanning changesets. Sigh.

I'd mind less if they did actually make local changes, but they don't. Plus, in trying to use tools (like OSMCha) to filter out the noise, it ends of excluding the rare ones which are huge but do make local changes. So, lose-lose; screwed either way.

It really doesn't help when software itself contributes to the problem, not just newbies or carelessness.

Alas.

Re changeset comments: osm.wiki/Good_changeset_comments

Avoid comments which assume familiarity with the context. Describe not only how you changed things, but what you changed, and where. Unless already obvious, describe why the changes were made, too.

Imagine a list of changesets. Ideally, the comment of each should enable a reader to know if each is relevant to him, and what it's about, without having to examine each changeset individually. Thus, enabling the decision of which to ignore, and which are of interest.

Besides helping other mappers, at some point in future it'll help you; eventually you'll have need to find one of your own old changesets, and you'll appreciate descriptive comments to identify the correct one more easily.

Now that I think about it, I'm sure I've walked through this estate while surveying, before. I recall thinking that it would benefit from some attentive work.

There were a bunch of features missing, as well as tagging being only basic (e.g. building=yes) lacking detail.
In that case, StreetComplete would help greatly in identifying what's lacking.
House numbers / names would be a good start.

“Can see the issues.
Will revise ways and join them correctly.”

👍 I noticed your 3rd changeset appears (from the comment=*) to address this.

“New to this.”

Indeed, I noticed, and you set review_requested=yes.

Welcome, and thanks for your contributions; not many locals working on OSM.

It can be a bit of a rabbit hole, at first, with a moderate learning curve, especially when starting with an editor like iD.

I'd actually recommend that newbies start with StreetComplete, which doesn't require knowing the clockwork beneath the surface, and asks simple questions (e.g. what is the surface of this road?) in the form of quests while out & about (surveying, not sat in an armchair looking at imagery). From there, one can examine the changesets it outputs, to learn the concepts behind tagging, and build from there.

When in doubt (which will happen, even with experience) leave a note and/or ask questions.

Else, in a changeset, do the minimum and then invite discussion on the less clear parts.

For context (since you're literally brand new); for road names the best approach would be to determine which roads have what name by surveying (that is, going outside & looking) the road name signs.

However, I'll guess that this is your local area, and you're already quite familiar & confident with the changes.

Though, as you discovered, a degree of diligence is required to represent reality (as accurately as possible) in OSM's schema. To that end, focus not on osm.wiki/Tagging_for_the_renderer but on getting the data right (correct, accurate, not misleading, not guesswork or assumptions, etc.); rendering is a secondary problem (especially since there are many ways to render the data).

Another general pointer (given where newbies often trip up) is to osm.wiki/Keep_the_history

“forgot to uncheck "reuse changeset". Yes the default value is stupid!”

Sounds like this “Osmose Editor” needs a bug report filed against it. Does sound like a bit of a daft default.

Makes me more glad that Vespucci has sane defaults.

Evidently he's non-responsive. Though, no newer changesets either.

Why? Just because it doesn't have name=* doesn't mean that it hasn't been given a name officially.

Even if it is unnamed (noname=yes), that doesn't mean it doesn't exist.

You don't cite a source for your changes.
For deleting an island, I would expect that its non-existence to be determined by survey.

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

“Including Jersey (running joke 😉)”

Quite! 😋

One airport (EGJJ) is enough, here.

“All the member elements of the "collection-type" relation […] are now having the same tag”

Even if so, a relation (as a means of grouping related ways & nodes) still has value. As you said; they're all part of a collection (so similar tagging is to be expected).

It's not a case of either-or. What may appear as duplication (or redundancy) may be intentional; either for the convenience of human contributors, or data-parsers (or both).

I can imagine it also being a means of preventing hasty deletion. Imagine only the relation was tagged, while the member ways were not. Then imagine a novice discovering one of the untagged ways, assuming that it's a mistake, not thinking to check the relation, and deleting the way.

Apologies, I had not noticed your reply until now.

To clarify, I'm not commenting on how many elements were changed, but the area of the bounding box.

Besides other countries, in my case it also spans the Channel Islands (which haven't been French territory for nearly a millennium, now).

For Channel Islanders, a recurring problem is that the changeset list is flooded with many more large-area changesets than locally-relevant ones. There's only a handful of (local) mappers for each island. This makes it difficult (even with tools to filter changesets) to keep track of local changes without being bombarded by all the large-area changesets that are entirely irrelevant to the islands.

Might I suggest grouping changes by region, rather than nationally?

Well, when the bounding box includes jurisdictions which host zero Aldis, then it's polluting the changeset list of many people.

“tweaks to the Devils Hole and surrounding paths.”

👍 the area needs some attention.

Hell, the whole northern coast needs surveying.

osm.wiki/Keep_the_history

In this instance, the PoI node could've been detagged and used as one of the nodes of the building outline.

Else, tag the building generically, and leave the PoI node, since often while level=0 (ground) may be commercial, level=1 (and above) may (likely) be residential.

However, if it's a flat for the operators, to which the public will never have access, then one night argue that it's irrelevant (even if not an accurate reflection of reality).

One could also use different ways; one for the building outline, another (which shares / uses the same nodes as the building outline if it occupies the entire floor) for the commercial operation on level=1, and other ways for different floors / features of the building.

When in doubt, do the minimum and seek review.
Jersey already has plenty of messy data, which needs attention.

osm.wiki/Keep_the_history