Large Edit areas

I’m rather new to OSM, but one of the biggest annoyances I have so far is these rather large edit areas some people have. As you can see from the image below, I went to see what changes had been done in my area over the weekend before I started doing more edits, and there are a pile of changes (mine from Friday are on the 2nd page now), so I start to look at what was changed and I find the top 7 edits are no-where near me… In fact, most of them aren’t even on the same continent…

Tornado76’s edits are on 4 different continents.
Brook Waters added 2 business names, one in Antwerp (Netherlands), and one in Havana (Cuba).
Crete Greece added an ice rink in North Korea, and a nature reserve in California.
etc, etc.

Would I be out of line to reach out and ask these people to save their changes before switching regions?


I agree this is frustrating and limits the usefulness of the History displayed on the main page. At least some of these changesets are generated by and it may be something that happens in the background without users of the app even being aware of it. Arguably it is a limitation of the History tool rather than a problem of mapper behaviour.

You might want to look at some of the other tools available for monitoring changes - see For example there are a couple of “whodidit” pages that seem to be better at identifying changes that actually affect the area you are looking at. You could try saving a “permalink” to your area of interest as a bookmark, or set up an RSS feed to be regularly informed of changes. The latter is what I ended up doing after some trial and error - none of this is particularly intuitive for new users.


FYI, Antwerp is in Belgium :slight_smile:

:slight_smile: :smiley:

Wheelmap is or was a big source of consolidated edits.

You also seem to get people who created a bogus edit in one corner and the real edits in another.

Not if you’re polite about it, no!

You’d need to bear in mind of course that some new OSM users may not even know that history is even a “thing”, and some may be uploading a whole bunch of POIs from an app collected over a week or so together. You’ll probably need to look at which editor each one is using and explain to them how to avoid huge changesets in that editor. I normally top and tail requests like that with “I hope you don’t mind me mentioning this but” and “if there’s anything else I can do to help please ask” or similar.


It’s worth mentioning that there are other ways of looking at recent edits in your vicinity. Unfortunately a tool designed specifically to resolve the issue you describe, OWL, died a death some years ago.

  • A very simple overview (maybe ways only) is provided by ITO World: (centred on your area). Update frequency is a bit variable (so perhaps 7-14 days behind), but it’s good for a synoptic overview of recent edits in an area. There are numerous other thematic maps at that site which are useful for seeing gaps in the data (for instance roads without speedlimits).

  • You can run Overpass-turbo with a date difference parameter or newer. For instance this one ( finds ways changed since 20th July in the County of Brant.

  • More specialised tools (mainly changeset focussed) include OsmCha, Achavi and OSM History Viewer. These are largely used by people who spend a lot of time fixing problematical edits (including paid staff of companies such as MapBos, the DWG etc). They are powerful, but not particularly easy to get to grips with.

  • Regular QA tools (Osmose, KeepRight and OSM Inspector) may surface problematic edits, but often generate too much noise or too many false positives. In my experience they are most useful when deliberately seeing to resolve particular issues.




Personally, I feel it’s both.

Ideally, the history tab would only show changes actually affecting the viewed area. Some of the available alternative tools have already been mentioned. I have personally used RSS History Filter which filters a changeset feed to only show edits with a small bounding box (which is a crude workaround, of course, but works decently well).

But still, it’s good practice for mappers to avoid creating changesets with unnecessarily big bounding boxes. Even with better history tools, it would still be desirable to have logically grouped changes with meaningful changeset comments, which isn’t going to be easily achieved with changesets containing semantically and geographically unrelated changes. So I don’t think it’s out of line to mention this to other mappers as long as OP is friendly about it and cuts new mappers, in particular, some slack.

Oh, and welcome to the forum, Amaethon! :slight_smile:

1 Like

I still love it, the big changeset areas of Wheelmap: Changeset: 134578926 | OpenStreetMap

There is e.g. WHODIDIT: OpenStreetMap Changeset Analyzer - Unlike OSM history it only shows changesets, that actually affect entities in the region you are watching. Yet, when following one of the links it posts to other tools you may still end up with a stuck loading curser/erm cursor :frowning:


Yes, this has been mentioned before (see here). A comment there says “We know that these big changesets are annoying. We really want to optimize this, but unfortunately it takes longer than planned. The problem is on our to-do list. I ask for a little more patience”.


I see, thanks for your answer. It would be a really great win if wheelmap’s people would be able to solve that.

1 Like

Also from their Github issue, this was posted 4 days ago:

So looks like some progress.


Hey, Sebastian from Wheelmap here. Thanks for mirroring the GitHub issue here!

The code to fix the changeset size is written and tested. From what I see, most people who were affected by / discussing the issue seem to prefer atomic changesets – one changeset per edit. That’s what we’re going to have in a visible dev deployment very soon. We’ll post a branch deployment URL in the GitHub issue when it’s ready for testing.

Sorry for the long time that this took, and thanks for being so patient and positive <3


Update: A beta deployment on saves changesets with one change per edit. There are still some rough edges, when they are fixed this change will go live.


Update: The rough edges are almost smooth, this is now publicly available on

There’s a blog post that describes the changes.

We’re currently collecting feedback from the community - when it’s mostly positive, the new version with smaller changesets (and more accurate OSM planetfile syncing) will go live.


This seems to work reliably. Please reopen the GitHub issue if you see something that I might have missed. Thanks again for your patience! :pray:

1 Like