Visualising changes

When someone edits OSM their changes get rendered quickly so they can see their handiwork. That's really good feedback and is valuable in attracting new mappers. When it comes to checking what has changed in an area, just looking at the rendered map is rarely enough to spot any changes. Looking at changesets is the next option.

Changesets were introduced with the API version 0.6. They group together edits by a mapper made over a short period of time. They can be open for up to 24 hours, but changesets are normally closed within an hour of being created and often changesets are opened, edits uploaded to the API and the changeset closed within seconds. Changesets have a bounding box that covers the area the edits are made in. You can request a list of changesets from the API that cover a specific bounding box. Edits by a mapper are normally wrapped in a changeset that covers a small area, but some edits range across very large areas even across the whole world. These are known as big edits. These are usually some sort of mass-edit or bot edit. These will show up in a request for changesets even though no actual changes are made in the requested area.

Looking at changesets can be useful, but apart from trying to work out which of the so-called big edits to ignore, there's the bigger problem of knowing what has actually changed. If you see an added node or way that's easy, but the modified nodes or ways is a bit harder to understand and looking at some relations can be a long job to work out the changes. Has a node been moved? Has a way's nodes been moved? Has a way had nodes removed or added? Has a node or way had its tags changed? Is there some combination of all this?  Deleted nodes and ways are also a bit of a problem as they no longer render and seeing what has gone can be hard to visualise, especially as some people delete a way and add a new one to replace it, losing the way's history. What would be nice is to see a before and after view of a changeset.

I looked at the problem, initially for nodes and ways, and quickly realised that the way the API delivers information about ways makes things harder than you'd want. When you request the details of a way from the API it returns the way with attributes like ID, version, changeset etc, a list of tags and a list of nodes as node ids. This fine for the current state of the way. The nodes in the list are the most recent version of the node. You need the nodes to find the geometry of the way as longitude and latitude are only stored on nodes. As soon as you look at an older version of a way the list of nodes is suddenly not clear at all. Which version of each node does it refer to?

I think the timestamp on each API object can be used to work out which version of a node matches each version of a way. That assumes that I have, or download, all of the versions of every node in the area I'm interested in. Another idea is to store the data for the area I'm interested in from a snapshot, such as Geofabrik's, and apply every changeset for the area on from there. In that way I could store the geometry of the way with the way rather than in nodes, which sounds much more practical. I can then show the before and after view of every changeset, but only from the date of my snapshot and only if I apply every changeset. I'll think about this some more.