When a way is split, does the history stays with both segments? I always thought so, but a few past interactions with other mappers doesn’t seem to indicate so.
This leads to confusions since suddenly there is an edit by out of state mapper drawing seemingly new highways (history shows version 1) with highway names on them (unlikely to be obtainable without ground survey or mapillary/openstreetcam). The history of the highway’s properties are not available unless contacting the mapper directly.
It’s kinda dissapointing though. A major interstate highway that I traced way back when currently only has history dated back to Dec 2019, credited to an out of state Indonesian mapper, which still has the source as GPS.
There are many more of course. A cursory look might have the viewer assuming that a major portion of highways in Malaysia were traced by the mighty Apple mappers and Indian Grabbers.
I agree it’s misleading and makes it harder to understand what was going on with those edits.
Perhaps instead of altering the versioning concept entirely, a feasible solution would be to have some place to store meta-data for the changeset where the editor could add the information “way X was split off from way Y”. Actually, we could use the changeset tags for that purpose – somewhat hacky, but it has the advantage that a few editor and changeset viewer authors could start building this feature without the massive coordination task involved in getting the API (and all the software interacting with it) changed first. If it catches on, we could always migrate it to a proper data model in a future API version.
When implementing that, there will be a lot of questions to answer, of course – such as what to do when the split way is then later merged with a different way, etc. There won’t be an easy way to summarize more complex editing operations in a machine-readable fashion. But in principle, it seems possible – you would just need to convince the devs of one of the major editors to start adding this kind of meta-data. Once it’s there, it’s likely that the changeset viewers will start making use of it.
Revisiting this topic as I was just about to ask the same question.
This is problematic because the history prior to the split is crucial for understanding context or identifying potential issues. The new split segments may appear as entirely new additions, masking their true history.
I assume the reason is because of the current schema limitation? e.g. a way retains the same id over multiple versions, and so versions cannot reference other way ids as part of their history?
Observed few cases where a particular mapper chooses a very short section cut off of ways to adopt the version history although the splitting by default goes to the largest of the split sections and then all of a sudden the whole main street but for that short section shows V1 as if that mapper created that street on OSM. Toe nails folding back in shoes. Many a time thought of a versioning that adds a tag to these split V1’s to show this was a split off from with origin reference, locked of course… a ‘split from way xyz’
This reminds me of the history tag that Potlatch 1 used to add to any element that you restore using its interactive Undelete mode. Mappers considered these tags cruft and eventually eliminated them from the database.
With enough effort, it’s usually possible to verify a split without relying on any special tagging:
Note the ID of the node at which a split is suspected.
Look up the changeset that saved version 1 of the way.
Search the changeset’s osmChange file for an edited way with similar tags that also contains the node in step 1.
Look up the way’s previous version and confirm that it got truncated by the changeset and used to contain most of the nodes of the newer way.
Conversely, you can track history across a merge by rummaging through the ways deleted by a changeset.
This process becomes more difficult if multiple splits or merges take place in the same changeset, uploaded in one go. iD only uploads the whole changeset together, without uploading each intermediate change. Potlatch 1 used to have a Live mode that would immediately upload every edit, making individual operations easier to identify.
A visual tool such as OSMCha or PeWu’s history viewer greatly simplifies these steps, especially in case of successive splits or merges. It should also be possible to automate the process using a script, though built-in website support would be a lot nicer.
You can automate part of this with an Overpass API query. Let us take for example the way 1257085209 touched by me a month ago and figure out where the lit=yes comes from.
Figure out the timestamp of version 1. Comes out of this straightforward URL where one only has to adjust the way id.
Bring the version1 to display in Overpass Turbo. Adjust way id and timestamp here.
way(1257085209);
node(w:1,-1);
make nodes refs=set(id())->.nodes;
retro("2024-03-03T06:03:13Z")
{
node({{bbox}})(if:lrs_in(id(),nodes.u(t["refs"])));
way(bn);
out geom;
}
Again you need to adjust way id and timestamp here, and the timestamp shall be one second earlier than the creation time of version 1. Admittedly, there is by-catch.
Now the visual comparison shows that way 1257085209 stems from way 241135851; for that way the usual tools show that the tag lit=yes has been set in changeset 132107563.
I’m in principle open to streamline that into a direct feature of Overpass API. For this purpose I encourage you to discuss the actual use cases for that feature. If for example the actual question to solve is rather “when and by whom has tag X been added or removed in this bounding box?” then a useful feature will look different as when the question is “can we extent the timeline of a way into the past by transitioning along the history of the used nodes?”.
Small test, the nodes in the V1 split way retain their origin and if moved, get a V2. Maybe that can be used in establishing the way history, way 12345-1. It’s one of the great things in JOSM, select an object and hit the history button for it to go out and fetch that data from the database and open a pane to include the CS’s, mappers etc.
The last overpass query is returning 4 ways though. Is there a way to adapt the query to only return ways that share at least 2 nodes with the split segment, to eliminate the other ways that are connected via a single node?
The last overpass query is returning 4 ways though. Is there a way to
adapt the query to only return ways that share at least 2 nodes with the
split segment, to eliminate the other ways that are connected via a
single node?
Yes. This may fail if for whatever
reason the nodes are no longer the original ones, but probably does work
in the majority of all cases.
way(1257085209);
node(w:1,-1);
make nodes refs=set(id())->.nodes;
retro("2024-03-03T06:03:13Z")
{
node({{bbox}})(if:lrs_in(id(),nodes.u(t["refs"])))->.firstlast;
way(bn.firstlast);
foreach
{
node.firstlast(w)->.nds;
if (nds.count(nodes) >= 2)
{
out geom;
}
}
}
I was hoping some online services like Pewu or osm-deep-history could make it easy for non-tech users to get that info with just a click, but it seems that’s not the case.
