On a general note, it’s worth mentioning that if anyone wants to contact the DWG then an email to data@openstreetmap.org will always be the fastest way.
For general discussion about these sort of issues, this forum will always be better than a private channel somewhere else - it’s more visible and it’s more accessible
Is there are way to re-render the affected areas (and probably purge cdn caches for affected areas)? @Firefishy, that’s a question for you
Problem:
As this vandalism was much worse on the osm db data state than the previous vandalism waves it’s hard to grasp atm if all those vandalism deletions got caught up as the tiles don’t update well in that area so far. (And I still see lot’s of problems in the area on osm tiles as well as on tiles by external tile providers like osm-fr etc.)
E.g. here is a comparison of the data state of Friday (left) vs. today (right):
(you may drag the slider to see the difference - right side is tiles as delivered via the OSM cdn tile.openstreetmap.org while left side tiles should not have the recent vandalism). Ymmv while you hit different caches of the fastly cdn for tiles by osm.
Is there a way to see the status and progress of handling the reverts?
One of the vandals, vecago7283, was able to submit 99 changesets before the account was blocked. Clearly, it takes a lot of time and effort to revert all of them.
@zstadler as these reverts are way more complicated (and several blocked users doing different vandalism deletes or sometimes data changes) it’s probably best not to edit in the affected areas currently as not to complicate things further for SomeoneElse and the DWG. Maybe you could carry this information into the Israel mapping community via telegram group etc?
I can send tile cache purge requests, but please be aware cache purge requests are extremely heavy and only best done once all the required changes are made. I have submitted a few requests now.
Apparently, the vandalism targeted at Israel affected not only Israel, but also Lebanon, Syria, Turkey, Greece, Cyprus, Egypt, and Gaza(!)
It had impacted uninvolved nations, nations that support the Hamas in Gaza, and Gaza itself.
Sadly, there is a parallel with the terror attacks in the real world.
The query does not show elements that were modified in any way after the vandals’ edits.
As of the last vandal changeset, this query returns 190328 nodes, 1662 ways, and 288 relations.
At the start of the SomeoneElse_Revert activity this query returns 190040 nodes, 973 ways, and 221 relations.
Currently, it shows that 95848 nodes, 0 ways, and 50 relations are still pending revert.
A rough estimate based on the above is that the revert will be completed at around 20:30 UTC on October 26.
We (the DWG) need to have a think about the best way forward**, I think. The complex revert log is here, and that had (for example) 86k node revert fails it. In some cases that’ll be because someone actually fixed the data, but in many it’s because a well-meaning partial revert was made, for example here - note that the “revert” in v7 is only to the vandal’s v5. In this case the revert would have failed anyway because of another vandal change at v6.
One thing that would be useful to have would be the last editing users and changesets of each of the node revert fails in that complex error log - or even a random sample.
Edit: I’m now creating that list, for the 66k unique nodes that “failed to revert” (most of which I suspect “failed” because they had already been reverted).
