As you can see this hedge has been incorrectly edited with its start/end point (accidentally?) moved into the wrong location some distance away from the actual hedge location.
When I go to edit the way in iD, it shows it was edited 37 hours ago:
However, when I view the Way history on the OSM website, there is no mention of this edit and it looks like the hedge has always been like this since it was created 11 years ago.
Could be that the new way was created by splitting an existing way. The current way got V1 and the original way (with the complete history) has been deleted?
Changing the geometry of a node does not change the way version. The way version changes when a new node is added to it, a node is deleted, or the tags change. If a node’s info gets changed (geometry or tags), and that node is part of a way, that way will not change the way’s version number.
Side note: this seem like an odd decision to have been made. The way is changed when its underlying node geometry is edited, so for it not to be reflected in its version numbering seems counterintuitive.
The way literally doesn’t change when you just move a node (and yes editors could bump the way version “voluntarily” but is convention not to do that). See the discussions on a potential data model change to giving ways their own geometry and the consequences of that Study on the Evolution of the OSM Data Model — Jochen Topf
Yep, got it now. In the OSM data model, a “way” is a term for a collection of nodes and the way itself isn’t modified if the only change is moving (editing the location data of) a node.
That’s a bit different from what a non-specialist user might expect of a “way” i.e., a linear feature where moving a node changes the topology of the way and therefore the way itself is changed.
Thanks for the reading!
Presumably it would be possible, without changing the OSM data model (or bumping the way version number), for the “Way history” page to show if edits have been made to the nodes contained within the way? I guess it might be quite resource intensive though, especially for ways with a large number of nodes.
Yes, but in general way (and relation fwiw) history is a very mixed bag with lots of kinks. The upside is that the current practice stops the history from exploding (and if you look at some relations you wouldn’t believe me, but it would be much much much worse if we propagated geometry changes upwards).
OSMCha (osmcha.org, a third-party changeset viewer) attempts to show changesets in a way that matches the intuitive notions of which OSM elements were “affected” by an edit, even if some of those elements weren’t literally modified in the database and thus did not have their version numbers bumped.
External tools that add additional entries in the object history with a “minor version” for indirect geometry changes are OSMesa, osm-wayback, OSHDB and its succesors ohsome-planet & ohsomeDB:
Slightly editing an existing object’s geometry (move the nodes around in a way)
[…] We call these changes minor versions. To account for these edits, we add a metadata field to an object called minor version that is 0 for newly created objects and > 0 for any number of minor version changes between a major version. When another major version is created, the minor version is reset to 0.
Note
The @contributionChangsetId can be different from the general @changesetId in cases where a contribution stems from changes child elements referenced by an OSM element, e.g. when only the nodes of an OSM way are rearranged or moved. This is sometimes called a “minor version”.
"name": "osm_minor_version",
"doc": "minor version of the OSM element which considers all geometric changes, starts from `0` for each (major) OSM version"
Example old ohsome API
As the OSHDB is not up-to-date, I use another, older example of a dragged node:
way 1255919295 is shown in OSM with version 1 from 2 years ago
node 9860298397 (pewu history) was dragged away and reverted 7 months ago.
The Contributions Extraction endpoint of the old ohsome API (based on OSHDB) also includes those indirect geometry changes in the way history (excerpt):
The visualization in Ulra allows to find the node-dragging changeset by the @contributionChangesetId property in the popup when clicking on a misplaced segment.
New ohsome API
There will be a new ohsome API based on a different backend, see Moving to ohsomeDB. It was scheduled to be available from 1 May 2026, but I haven’t seen anything about it yet.
Isn’t all of that already laid out in the augmented diff format? Or put differently the reason why they exist in the first place? osmcha is simply consuming them.
Yes, augmented diffs encode this information (whereas normal osmChange files from the openstreetmap.org API do not). But OSMCha builds its own augmented diffs when changesets are created in OSM (see adiffs.osmcha.org and https://github.com/OSMCha/osmx-adiff-builder/), and then the osmcha.org web frontend fetches them when users view those changesets. The issue I linked to is about formalizing the definitions used by OSMCha’s augmented diff creation system.
