Vandalism and blocks in Israel

These are the most recent user accounts that we know about:

changesets=> select distinct user_id,user_name from osm_changeset where tags -> 'comment' like '%Free Palestine%';
 user_id  | user_name  
 20486647 | dawekiv148
 20492576 | vecago7283
 20492590 | febevi3666
 20492952 | kasiva6740
 20493004 | tewer84412
 20493043 | nodofi9184
 20493307 | tajoced719
(7 rows)








Some reverts are still ongoing. See also here.


I have asked the Israeli community to stop reverting the vandal edits in order to allow the DWG to perform the complex revers required.

Please feel free to join the OSM Israel Telegram channel at Telegram: Contact @OSM_Israel


On a general note, it’s worth mentioning that if anyone wants to contact the DWG then an email to 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 :wink:


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):

Visual comparison of recent vandalism area

(you may drag the slider to see the difference - right side is tiles as delivered via the OSM cdn while left side tiles should not have the recent vandalism). Ymmv while you hit different caches of the fastly cdn for tiles by osm.

Please wait until the revert is complete.

1 Like

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?

Not easily

Here are their first few changesets:

    id     |     created_at      | num_changes
 142928156 | 2023-10-21 14:56:34 |        1116
 142928165 | 2023-10-21 14:56:47 |        1482
 142928178 | 2023-10-21 14:56:59 |         834
 142928231 | 2023-10-21 14:57:31 |        1074
 142928251 | 2023-10-21 14:57:49 |        2655
 142928271 | 2023-10-21 14:58:05 |        1135
 142928286 | 2023-10-21 14:58:17 |        2189
 142928300 | 2023-10-21 14:58:29 |         166
 142928320 | 2023-10-21 14:58:42 |          18
 142928326 | 2023-10-21 14:58:48 |           0
 142928528 | 2023-10-21 15:04:21 |        5763
 142928584 | 2023-10-21 15:05:41 |       10000
 142928597 | 2023-10-21 15:06:06 |       10000
 142928610 | 2023-10-21 15:06:22 |        4927
 142928630 | 2023-10-21 15:07:01 |        7000
 142931521 | 2023-10-21 16:21:05 |        3612
 142931556 | 2023-10-21 16:22:04 |       10000
 142931568 | 2023-10-21 16:22:17 |       10000
 142931577 | 2023-10-21 16:22:25 |        2165
 142931998 | 2023-10-21 16:32:51 |       10000
 142932010 | 2023-10-21 16:33:06 |       10000

It would make sense to stop people doing quite so much damage quite so quickly

The relevant OSM website ticket is here.

Would it be possible to add a comment in the discussion of reverted changesets?
Perhaps similar to the comment in Changeset: 142887284 | OpenStreetMap

DWG revert

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.

Yes, as SomeoneElse states, please lets wait for the him and DWG to get through this mess first.

1 Like

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.

See this overpass query, run it, and zoom-in on the coast lines.

1 Like

This Overpass Turbo query finds the remaining elements that were last modified by the vandals listed above.

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.

Based on the current progress rate, I expect the revert to complete by 11:00 UTC today

It looks like the latest changeset was closed.

It is a good time to discuss the next steps?
Every bit of guidance from the DWG will be highly appreciated

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.

** which might be complicated by timezones etc.

I have some ideas about such cases and I would be interested to join the discussion.

Perhaps now is a good time to launch that cache purge. Please note the extend of the vandalism:

No , there are still serious issues. It would be a waste of time to do it now.

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).

Edit 2: about half way down that list…


There are currently 46 relations that were last modified by one of the vandals listed above.

What would be the best approach to restore them?