And if you want to shine while demonstrating your GIS system you should find a different tile provider as the tiles you currently use are prone to those attacks (see above).
Notwithstanding that doing that is really easy, are you sure that you aren’t just seeing things in your browser cache?
I’ve just clicked your original problem link again, and saw problem tiles (because they were in my browser cache from yesterday), done a shift-refresh in Firefox, and saw no problem after that.
If you do not want to use a third party solution, e.g. commercial tile provider (which will probably involve some nasty things like invoices) than that would be your only solution (but that one may be more expensive than using a third-party provider).
Well they didn’t because updates aren’t instant when such a large number of edits are made - when the revert started the original edits were still being applied and were then followed by the reverting edits.
On some of the render servers it took six hours before all the edits and reverts were applied and during that time there would have been a mix of edited and reverted objects in the render database.
That makes it read, like a lot of tiles in the cache never showed the vandalism, just because nobody bothered to look at them.
If tiles that originated from before the vandalism started were not dirtied, that might reduce the load on the renderers?
UPDATE: Of course, that would also hide legitimate changes to those tiles in between the two dates. But I’d say the price is fair in cases like this one, not showing the vandalism to the unsuspecting. Also, it will just delay the loading of the renderers – as evidently the special rule has to be un-applied some time, but they would spin up after the revert, so that might be preferable too. Anything I missed?
Tiles served from culebre look good for me, you’re probably being served by ysera, where the (Meta)tile is still marked as expired (2004) but not re-rendered yet:
Actually, it’s a shorter time period than that. The second wave of vandalism started at 22:34 and finished at 22:37. I got notified at 22:35 UTC and applied the first block at 22:36, and the second and third at 22:37. I started the revert at 22:49 and it finished within 12 seconds.
Both times everything got reverted within 20 minutes, so with signalation and cleaning up are not an issue. But the annoying thing is that it looks like it stays there for a while because the tiles aren’t updated…
I think that if we want OSM to be even more mainstream in the future, we will have to prevent vandalism like this from even happening, or at least be able to not have it still shown in tiles that were loaded in while the vandalism was there.
Otherwise we might encounter these issues more often. (I hope I’m wrong here).
OSM’s “Standard” map, the “OSM Carto” style, is designed as a mapper feedback layer and to look “vaguely nice” (to show what can be done with OSM data). Whilst we do want OSM data to be mainstream we certainly don’t want those OSM Carto tiles to be, for a few reasons:
The map style isn’t designed as a background map. Someone who wants “a map on their website” likely wants to highlight one thing - their shop, perhaps. For that they need a background map, not the highly feature-rich OSM Carto.
It has too many … “foibles” to be mainstream in 2024 (e.g. gaps where busways should be)
It’s updated on the fly, which someone who “just wants a background map” absolutely does not want - they want to be sure that what it shows at 22:45 is vaguely what it showed at 22:25, until they decide to press a button to update with, say, they new housing estate that was completed last month.
Finally, it does not make financial sense for OSM as a project to serve map tiles to every data consumer under the sun who is simply too cheap to pay for their own map. The OSM data comes at a cost of volunteer time, and so does serving a tile layer to the world.