note/2911211

See comments on changeset/105922510

The sign actually has just the hostname, but that's not a valid (fully-qualified) URL.

Actually, would setting https://www.jersey.police.uk/ satisfy your bot? If I recall, from reading the documentation, it only matches values which don't start with https:// .

Personally, I'd prefer it to ignore all of Jersey, but that's still a work-around.

However, I thought that the script was only manually-invoked? So, I'm a tad confused about it being run before you're able to “get to it in the next week”.

Better would be a tagging-based equivalent of the Robots Exclusion Standard ( /robots.txt ), for cases which such bots should leave alone.

The basis of my concern is accuracy & verifiability, plus that a key's value is changed without changing (or removing) the corresponding source:[key]=survey(;sign) .

In the end, security is a problem which must be addressed by users (instead of everyone trying to bubble-wrap them); for example by using HTTP User-Agents which implement EFF's HTTPS-Everywhere (or at least HSTS). Some users may prefer unencrypted (they're running analysis bots, and want the benefits of caching & less processing-overhead), and while encryption should be made available to them it shouldn't be thrust upon them (lest newbies become complacent).
Beyond that, the whole concept of a different (pseudo-)protocol scheme, using a different port-number (which, to do that for each service effectively halves the available port count) all just for encryption (instead of it being negotiated over the same original port).
So, in the end, m/^https/ (for URLs) is somewhat moot & temporal.

I could also comment about hostnames vs. domain-names (viz the www. prefix), and the semantics of which HTTP redirects you're handling (temporary vs. permanent).

Thus, back to accuracy & verifiability of OSM data trumping concerns over how the data might be used.

It's not just this node (there are other similar CCTV locations around town, even if I haven't yet got around to adding them to OSM); plenty other (local) elements have seen similar changes by this bot, though.

So; a mechanism by which to signal the bot to ignore a key (or entire element), please.
There should also be some kind of emergency-stop link, on the bot's info page (compare Wikipedia bots).

“I did upload both of my tracks, a clockwise and an anti-clockwise lap of the island.”

Good; thankyou. Difficult to associate the lines in the overlay tiles, and the uploaded GPX files. Seems that a data-layer for them would be helpful.

I originally meant if you return for another tour.

“Is the campsite still there?”

There's a few of them. Which part of the island?

“I cycled down from Bristol to Poole and got the ferry over. That would still be fun.”

Quite the trek. Reminds me of a similar 2-wheeled trip in Northern France during my youth.

I think the island cycle-routes have expanded since then. There's certainly a lot more cycling-related amenities (especially bicycle_parking).

See note/2725141 & comments on changeset/107505644

“disused:amenity=post_box”
“collection_times=closed”

changeset/113011333

Future reference (post box):
▪︎note/2725141
▪︎node/1867154881
Crossing at Highlands:
▪︎node/8898444921
▪︎note/2649628

Besides the purpose of the bot being dubious (but that's a different discussion), in this case it changed the hostname from what was on the (surveyed) signage.

I've corrected this, again (see changeset/112997846 ), but please update the bot('s code) to avoid such false-positives in future.

Unless there's a tagging-based mechanism to prevent it interfering?

During some surveying, today, I was reminded of a tip which is relevant here.

Punchline: leave a descriptive note(:complete)=[…], in future.

I've found this technique useful in a number of ways.
▪︎as a reminder of WHY something was mapped as such
▪︎when there isn't a clear way to tag some properties which should be noted, so that the info is preserved (for the future when a tagging scheme is decided upon); amenity=charging_stations are a good example of this
▪︎being able to do the basics (given limited survey time), but including enough info as a prompt for next time else for other (armchair) mappers to refine it further
▪︎enabling future mappers to make informed decisions when some tag no longer applies (or is outdated)

I feel like I'm missing a few, but you get the idea.

For future reference, see also changeset/11839122

“Nice work.”

Ta, but that was easy compared to some of the surveying I've done.

Lots of clean-up (from the input of armchair mappers) is needed.

“I hope to visit again and confirm in person 😉”

Oh, you're welcome to. Some GNSS traces while you're pedalling would be good, since we're lacking those.

You might struggle to find a decent hotel for a reasonable price, next time. Much has changed in 9 years.

I'm curious how the mapping of the island has changed from your earlier visit. There's only a handful of locals contributing.

note/1281988

note/2616839

note/2616842

+source: note/2616828

Since iWowik chooses to ignore comments on his other changesets …

“Choose better tools to monitor changes in specific area or send a message to authors of the tool you use with wishes for improvement of monitoring feature”

See http://github.com/openstreetmap/openstreetmap-website/issues/3242#issuecomment-923799105

“Monitoring software is still bad.
It should obviously be improved.”

A tool-dev has stated that “Today there's no workable solution available to analyze large changesets.” (see GitHub issue for source & attribution).

In the end, since the solution you (@iWowik) dismissively suggest isn't available (especially that you're expecting volunteers to solve the problem (which you're causing) for you), to continue outputting enormous changesets is unreasonable. Especially in defiance of best practice guidelines.

Tools first, then you might have a case for jumbo-sets.

As usual, I'm reminded of the wisdom of Rick Moen: http://linuxmafia.com/~rick/faq/crybaby.html

Based on habi's examination, I went to mark this mess of a set as bad in OSMCha, but see that someone's already done so. Good.

Very much sounds like it should be reverted.

For a potentially-controversial change, specifying a source=* would have been good.

changeset/112969060

Thanks for the confirmation. Will update the way.