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
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.
@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?
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.