If the underlaying data is fixed (I believe it’s all been reverted), they’ll re-render soon, once someone has viewed the tile.
4 Likes
Andy on the moon
Mott the Hoople and the Game of Life, yeah, yeah, yeah, yeah
Andy Townsend in the wrestling match, yeah, yeah, yeah, yeah
Monopoly, twenty-one, checkers, and chess, yeah, yeah, yeah, yeah
Mister Fred Blassie in a breakfast mess, yeah, yeah, yeah, yeah
Let’s play Twister, let’s play Risk, yeah, yeah, yeah, yeah
I’ll see you in heaven if you make the list yeah, yeah, yeah, yeah
Now, Andy, did you hear about this one?
Tell me, are you locked in the punch?
Andy, are you goofing on Elvis?
Hey baby, are we losing touch?
If you believed they put a man on the moon
Andy on the moon
If you believe there’s nothing up his sleeve
Then nothing is cool
Lyrics by R.E.M. Michael Stipe © Kobalt Music Publishing Ltd., Sony/ATV Music Publishing LLC, Universal Music Publishing Group
4 Likes
I’ve been called worse 
What I suspect might have happened is that following a series of complaints to the DWG, I reverted a large number of mechanical edits yesterday. The mapper concerned didn’t appreciate this, and sent various messages to me immediately after that block and revert. The “new account” performing this vandalism then appeared immediately afterwards. This may of course be a coincidence, but it’s not the first time that this particular scenario has played out with this individual.
The bad news is that they’ll probably try again with another “new account” from another throwaway provider. The good news is that, as here, it’ll all get reverted pretty quickly, and limits on the creation of “new accounts” and what new accounts can do is more limited than previously to prevent damage.
Edit: Actually there are at least 3 accounts (blocked); as noted above I’m sure we’ll see more.
19 Likes
I think the underlaying problem should be fixed, i just saw that these tiles are still junked…
Only to be sure that this is also fixed.
Thank you so much for your work!
The DWG have had a number of reports about this vandalism (as you’d expect). In most (at the time of writing, probably all) cases, it has already been reverted**.
However, if you see something on a rendered map such as at https://www.openstreetmap.org you’ll want to check that the problem has actually been fixed. In order to do that, go to https://www.openstreetmap.org and zoom right in to where there was a problem. Use the “?” button at osm.org and click on the map where the problem was. A list of “nearby features” will appear. If one of them looks wrong, please tell the DWG about it. If nothing looks wrong any more, then the data has been fixed and you don’t need to report it.
However, once the data is fixed, various maps and applications based on OSM data will still take time to get updated. If you think that a map or app displays incorrect data, please raise that issue with whoever is responsible for that map or app. If you are unsure how to contact whoever it is, then asking a question in the forum here is a good place to start.
** Edit: Some relations may still have some issues (at first glance this may be due to people trying to do reverts using buggy software), but the scale of the problem should be manageable. I’ll update here later.
Edit: I was only able to find one problem relation that needed fixing, and that’s now fixed. Another DWG member found one other. If there are more, please email data@openstreetmap.org to let the DWG know.
Another edit (9 days later) someone reported one more broken relation to us yesterday.
6 Likes
Even after the reverts the defamations remain in the data base (history). Are there plans to redact these changes, too?
1 Like
Browser cache - OpenStreetMap Wiki has info how to request fresh tiles, which typically helps if vandalism was reverted already
1 Like
I’m seeing posts on Mastodon about this issue. Really bad that there are people out there wanting to make fuss in public so hard against specific people…if those vandals read these comments, I hope you realize that you aren’t doing anything notable with these extreme actions, it just makes you look like the loser, and not the one you fighting against for.
3 Likes
@SomeoneElse Thank you for your support!
I noticed that the tiles that still show the wrong data are loaded from cache: See X-Cache HIT and expiry date of 17 of april in the attached screenshot. This would mean that some users will see the wrong tiles until the 17th of april.
We’ve tried clearing all the browser caches, also tried using different browsers and different computers. The wrong tiles seem to show or not depending on the location. Therefor I understand this is not browser cache but CDN cache issue.
Is there any chance the CDN cache can be invalidated sooner?
Maybe it’s worth considering some kind of manual invalidation of cdn cache when these things happen.?
Thank you!
2 Likes
That would be an issue for the OWG, not the DWG and SomeoneElse.
@Firefishy we summon you here to collect all reports on stale Fastly cdn caches that show vandalised tiles.
But on the technical side I assume that odin (the tileserver mostly serving tiles to the caches here in the Netherlands and Germany) is overloaded, see e.g. queue length of odin and ysera here: Grafana that shows a queue length of >8000 and dropped tile requests/sec >150 for both). E.g. I’m seeing the vandalism on zoom 14 and 15 in the Rotterdam harbor, but not on zoom 13. @pnorman maybe it is a good time to look into Shift more Europe traffic to newer machines · Issue #1030 · openstreetmap/operations · GitHub again?
Our cache invalidation is not perfect. There are edge cases where some things get missed.
Low zooms are force re-rendered overnight to fix some of the invalidation misses.
1 Like
Understood, esp. with streets being moved way out of their normal base.
But looking at those prometheus graphs I see culebre and nidhogg not having any problems in re-rendering tiles, but odin and ysera have, so maybe even if those tiles are invalidated at e.g. odin, that machine is currently not able to catch up on all those invalidation jobs?
The backlog in the dirty queue gets rendered in the evening, see the “Queue Lengths” panel:
Queue Lengths panel for renderers serving Europe (click “dirty” bottom left)
As I understand, if the dirty queue is full (8K requests), like on odin and ysera during the day, additional tile requests get dropped and are re-issued with the next request, but may land in the queue or get dropped again.
Earlier today, the status of the z15 tile for odin was expired, but now it is rendered:
Last rendered at Sun Apr 11 08:14:19 2004.Last rendered at Thu Apr 11 09:46:41 2024.
https://odin.openstreetmap.org/15/16786/10839.png/status
https://tile.openstreetmap.org/15/16786/10839.png
So a hard refresh with Ctrl-F5 should not only update the tiles in the Browser cache, but also at least your current CDN instance as it sends no-cache headers with the request.
1 Like
At this point, maybe more than just 12 months would seem appropriate
5 Likes
I’ve redacted the changes by the 3 vandal accounts used so far. That doesn’t cover “partial revert” ones, of which there are a few (such as https://www.openstreetmap.org/node/434940423/history - no offensive name there but you can see that the “initially reverted location” was incorrect).
2 Likes
HI, I just stumbled into this issue by chance, just browsing the map around Busto Arsizio, Italy:
Exact location is: OpenStreetMap
Also, “alien” highways are visible in the surroundings of that area, and only if zoom factor is set to 16 (if I change it to 15 or 17, they disappear)
Hope this can be fixed soon.
Best things,
Max