Older History on a way is missing

I was working on adding and aligning some trails in the Desolation Wilderness near Lake Tahoe noticed that my previous work of using Strava heatmap data and aerial imagery was changed. When ever I’m working on a an area, I like to look at the history of the ways to get an idea of who been working on it and when was the last time. I noticed that all the history before this summer was gone.

The way ID # is 439973676 and is part of the PCT.

Everything prior to 8/30/16 is gone but on nodes within the way, dchiles, mades changes on 7/29/16. It appears that he may have used the Strava slide function to automatically aligned the trail with Strava heatmap data. Could this have removed all the history?

A node within the way: http://www.openstreetmap.org/node/969994138/history

Strava github editor link to the area:

If the Strava slide function is removing all the history, is this ok?


Most of the time history is lost because a way has been split. Otherwise, the user must have deleted the original way. I don’t see why Strava Slide would delete the original way, judging from edits that users have made with it which I’ve seen so far.

I sometimes user Strava Slide and almost always need to split the way to be able to use the Slide only where needed and in small enough sections to be able to monitor its progress on the screen. I then move onto the next section that requires improvement. At the end of the process, I combine all the sections to leave as originally provided. I don’t see why history should be lost doing a process like this. I would expect the history to be added to each section of a split and also all history to be included when recombined at the end.
Is this not so?

You can actually see the history indirectly by looking at the age of nodes in the way. For example, in http://www.openstreetmap.org/way/439973676 you can see nodes such as http://www.openstreetmap.org/node/969994138/history (originally added 6 years ago), http://www.openstreetmap.org/node/1852022761/history (from 4 years ago) and http://www.openstreetmap.org/node/4535169637/history from yesterday. In each case you can see who edited the area and when, and by looking at the changesets involved you can look at the history of older ways that have been replaced by newer ones.

OSM history is for the database object. If you split an object, you are creating a completely new object with no history and copying attributes, from the old object and removing nodes from it. Only the part that corresponds to the old object has any history.

From an attribution and copyright violation clean-up point of view, it would be much better if there were more details of the true history, however the data structures to represent this could get rather complex, and it would still require the cooperation of editors (software) and would not survive delete and re-add as practised by naive editors (wetware).

Thanks for the responses.

I was not aware that splitting a way to use the Strava slide function removed prior history of the way. It’s yet another reason that I do not like this feature. It does a terrible job on trails with tight turns and switch backs.

I’m going to email Strava development with my concerns. They provide some much useful information for OSM editors that it’s a shame they provide one tool that negatively impacts it.

There are so many reasons why people split roads: different maxspeeds, different number of lanes, turn:lanes, routes, etc. etc.
I do not see a reason why this slide function would have to be “punished” for requiring a split of roads.

The Strava slide function does not work on ways with too many nodes and must be split into smaller segments. In this case, it’s not a road a road that was being automatically adjusted to Strava data but a trail. It does a terrible job on switch backs and tight turns by shortening them. If the goal of OSM is to be as accurate as possible, the slide function allows a person with little knowledge of their actions, easily make OSM less accurate.

Josm by default uses the longest of the segments to attach history if a way is split, but does give you a choice of which segment you wish to carry the history. It is a pity that there is not an option to attach the history onto each piece of a split way.

The ‘age of nodes history’ is very useful as mentioned by SomeoneElse

From my experience Strava Slide is an excellent tool, though the switch backs and tight turns do need a more dedicated survey or satellite imagery. I think anyone riding mtb trails can accept that the actual track is going to be ‘smoothed’ on a map in comparison to what you actually ride. The Slide will improve with the better chips being used in new phones but we can’t expect perfection at turns on the track until well into the future I would guess.

If it helps anything, after joining the split ways again the history is joined again too (or rather, the history of the first selected way overwrites and deletes now permanently the interim-history of the others, but perhaps not all editors behave the same, better double-check).

And not sure if you’re aware (I sure was NOT for far too long), but there are some very handy tools out there for change monitoring!
The most basic, some editors can filter which nodes/ways were last uploaded by which user, e.g. show only yours or only those NOT by you.
Or see ways before and after a specific changeset-number, old and new state marked by color:

Or it’s possible to get an old version of a way or whole area, by date or by id-number, via overpass-query. Can be shown either on a map (e.g. with current mapnik tiles in background, always showing TODAYS map) or downloaded as osm-file into an editor…
There are many more history checker tools out there, to see differences between past and today, have seen a special wiki page for this… somewhere… Just as hint in case if not known, but others can explain that stuff much better anyway.

As I already said, the history is the history of the database object. The database has no concept of a way being split. The editor splits a way be outputting a revised, and shortened, version of a the original way and a completely new way. The database has no idea that the new way is in any way related to the original one.

Similarly, merges are done by updating one way and deleting the other.