Welcome.

Presets it is; good to know (and I've starred the repo you cite, for future reference).

Glad that it'll be fixed in a forthcoming update.

Thanks; quite a few of these were ones I added from before I had an account.

Awesome, thanks.

This was on my personal to-do list, but didn't have the (OSM) experience or (know where to find) the data.

maxstay=* makes clear that the value for maxstay requires a specific syntax, with a space between numerals & unit, and the unit not abbreviated. Same goes for maxstay:conditional .

Pro-Tip™:

OSMCha is already capable of filtering out the noise of large bounding boxes. I've been tinkering with it.

Besides selecting location of interest, also set the BBOX parameter to cover the area you care about, and set the BBOX factor to something close to 1 (that is, filter out anything with a BBOX larger than N times the BBOX you just specified above).

The matching changesets count went down from 4-5k to ~1k (for the date-range and other parameters I had input). Only local changes listed, all the noise (e.g. wheelmap) had been filtered out.

Enjoy.

@trial

Most interesting. Thanks for that explanation. I had wondered why I was seeing colour spelled with a U, and so on.

👍

Smaller changeset areas, please.

Smaller areas covered by the same changeset, please.

@trial

“sending in chunk would split the changeset into different changesets”

I imagine that this isn't done so that contributors can have control over when one set ends and another begins.

It does seem better to not penalise responsible use by pandering to the clueless.

I actually wish there was a way to keep a set open longer than 2 hours. It would've helped me avoid submitting similar sets (when all the changes in one would've been better).

But, there's always trade-offs.

“I don't know if you have fibre”
Oh yes; much fanfare was made about that becoming the norm.

Even though it only happened because the incumbent telco got a phat subsidy from the state (or, rather, our tax money), and liked the idea of lower-maintenance meaning that they could fire a bunch of engineers.

As long as you're willing to shell out for it, you can have a FttP (read: low-latency) link with capacity up to 1Gbps ingress and (if I recall) 100Mbps egress.
Of course, the _minimum_ tariff also just happened to go up from what it used to be via DSL (read: £17.50 per month) to something that is overkill for anyone tech-savvy who knows how to do things efficiently (I grew up on dial-up, which should say enough about that) which just so happens to come at the price of more like £25 per month.

Also, lots of capacity, but very modest byte-count quotas (but then, being an island, submarine cables are expensive). Though, I'll admit that the speed (low-latency) is quite nice.

For the details, the webshite of the incumbent is http://www.jtglobal.com/

“at least you write it the British way!”
Well, given where I am …

Though Jersey isn't technically / officially part of Britain (though still under the Crown); Rule Britannia and all that. Besides, I speak English, not Yankish.

“OSMcha can be improved, for instance by checking the BBOX of each modified/added/deleted object instead of the global BBOX. It would be more computation intensive but for large BBOX with sparse data like this it would be very helpful.”
Ah, I see. I did imagine that there'd be a reason why, involving some trade-off.

More compute resources; a bag which no-one wants to be left holding.

Oh well, more nagging of thoughtless newbies it is.

“Well, https://resultmaps.neis-one.org/osm-change-viz?c=106393896#2/27.2/3.8 shows it fast”
Thanks for the pointer; being an OSM novice I'm still discovering the various funky tools.

@SekeRob

“ID editor has a colour changing counter right top. When turning Orange certainly time to switch to comments, fix any flagged issue[s] and save.”

Ah, I know exactly what you're describing (having never used iD); Vespucci has a similar feature. Good to know.

I had never thought about it in this context; I imagined that it was for the benefit of the systems, to avoid uploading an enormous amount in one go (rather than spreading the (e.g. re-rendering) load over time).

Apparently, newbies ignore the warning colours. Sigh.

“For self it makes the resolutions manageble. Allows a quicker review then [j]ust start a new one if not done.”

I make a point and/or habit of avoiding that in the first place. I (try to) keep my changesets semantic & containing changes related to each element. Examples:
* (all) shops in the same market
* various PoIs along the same stretch of road or in the same building
* a particular site (e.g. a hotel resort, or hospital)
* all benches in a park
* if they do span a non-tiny area, then the elements are all of the same type (e.g. the tagging of multi-storey carparks, or public parks; sort of like how StreetComplete groups quests by type when uploading changes; one changeset for each quest type)
* sometimes, I'll make very small changesets, such as for adding an electricity substation / transformer I've happened upon; I don't know when I'll find the next (given the 2 hour limit on keeping a changeset open), and they tend to be spaced apart. Several small(er) changesets doesn't seem to raise any objections.

This way, I tend to leave unrelated things for another (possibly the next) changeset, since they'd be outside the scope of the current set.

This also makes it easier for anyone wishing to comment on a changeset. Firstly I hope that the set is easier to comprehend in the first place (as opposed to appearing an assortment of random edits), and because the scope is already inherently limited. They don't have to start by stating which element they're commenting about; it should be obvious from context, even with only a brief mention of the common name of it.

Plus, for my own future benefit, based on experience. It's already served me well (when I had to find the ID of a node a had to undelete; descriptive comments meant that I didn't need to inspect every changeset, which greatly reduced the time spent finding the right set). It's then almost like a personal (descriptive) log of what I've done.

But, then, I see commit comments as a valuable asset, rather than some pesky thing to satisfy in order to submit my changes. In future, the context which may have seemed obvious at the time, won't be once the task is stale. Comments are forever, so best make them good.

Though, in thinking about it, while out surveying I'm limited in how much I can reliably change (per hour, or however one wishes to measure) by my walking-rate. So, this probably also keeps things in check, compared to panning across the globe and adding whatever, wherever from various data sources (imagery, notes, and whatever else armchair-mappers use).

Re verbosity of comments; when the scope is limited, I find that it's acceptable to give less than a blow-by-blow description in the comment.
Many of mine are along the lines of ‘updated (tagging) [place] at [address]’. If it's only a few changes, then I'll specify them. Otherwise it seems excessive. The details are in the changeset itself.
Whereas, with a large changeset, this wouldn't really work (and probably explains some of the very vague comments we see in the list of recent changes).

Thanks for the explanation.

Especially that more editors / QA tools will handle a fixme but ignore a todo, I'll endeavour to use fixme instead, in future.

I'll have to see about cleaning up all the other todo entries I've made, elsewhere.

Hmm, this is what Vespucci set, but the wiki concurs with the underscore being inserted.

In order to know what needs to be fixed (and where to direct the bug report); would this be due to Vespucci itself, or the JOSM presets I point it to?

Smaller changeset areas, please.

You removed the entire todo tag, which included multiple tasks, yet only addressed the first of them.

Should've edited the value, instead.

Why, exactly?

Both are recognised and they're semantically different.

👍

Vespucci didn't know this info for auto-populating the fields (unless it comes from presets anyway, which should be updated), and while out surveying I seldom have the spare resources to run a browser along with everything else.

@SekeRob
👍

I'm interested in only a small jurisdiction (since I do surveying, not ‘armchair-mapping’), and quite frequently there are changesets with bounding boxes that span my island which contain zero relevant changes for my area (much like this changeset).

Would be nice if the likes of OSMCha could filter them out.

Alas; people muddle through (instead of reading documentation first). At least they're contributing here, and not to Google.

It's a social problem, not a technical one; just keep badgering them.

Though, the common editors could do something to discourage newbie contributors from making wide-spanning changesets early on. iD has a tutorial, for example. Or, there should be warnings in the UI re setting the source=* comment=* and likewise encouraging smaller areas per changeset.

The likes of WheelMap seem to be going for efficiency, over concision.

While I certainly sympathise (especially since I'm interested only in a small location, myself), I think the problem here is the nature of the account. It's not intentional.

As explained in the account's profile, it's a proxy for all the changes made by anonymous users on the source site. I gather that the changes are uploaded in batch (for efficiency?).

I suggest contacting the site itself, to ask if there's a way that they could limit the area of any given changeset.

In this case, they could at least limit it to different landmasses, rather than spanning the Atlantic.

Please keep the areas affected by any single changeset small, rather than global.