[OSM-talk] Historical Data in OSM database
balrogg at gmail.com
Thu Nov 11 00:27:47 GMT 2010
On 11 November 2010 00:45, Frederik Ramm <frederik en remote.org> wrote:
> David Murn wrote:
>> OSM, by its nature, is excellent for retaining historic data, for
>> example if a road is realigned, you have a history that shows how it was
>> realigned, or if a road changes name, there exists a history of previous
> I think that you, just as almost everyone else in this discussion, are
> wrongly mixing OSM's revision history and true on-the-ground history.
> Revision history is there for the sole purpose of storing who has made a
> certain edit when. The time at which an edit was made has *nothing* to do
> with the time at which the object started or ceased to exist; the time at
> which an edit was made is the time when the existing object was first
> recorded, or when the object's destruction was recorded.
> While revision history is nice to create animations about how the OSM data
> set grows, it is unusable for animations about what happened in the real
> Properly modelling this would require adding an extra dimension to OSM where
> each property (tag, location) of an object could receive a validity
> timespan. Of course this would have to be in *addition* to the normal
> revision history - I would need to know that, for example, on the 11th of
> November, 2010, someone changed the validity timespan for the attribute
> surface=cobblestone on a certain roman road to be 350-200 BC rather than
> 350-250 BC.
> OSM revision history and on-the-ground history are orthogonal.
There is going to be some correlation between them though.
Additionally they could be organised very similarly in terms of the
database schema (something gets a new revision when it has changed
tags or lat/lon, new id when it has become a completely new object
So one possible way of handling "real" history that I can imagine (I'm
not saying this is that way it should be, I'm just thinking aloud) is
that revision history can somehow be made editable and then with a
special editor series of revisions such as edit wars can be squashed
or made invisible, and dates of revisions can be moved to their
historical dates, new revisions can be inserted in the middle of the
history, and so on.
Of course the edits history would still be valuable and should be kept somehow.
My point is that *if* OSM wants to realistically do historical
mapping, then perhaps we would get better effects by storing new edits
made by the "normal" mappers into both the edits history and the real
history under the current date, and later letting the
"history-conscious" mappers do their clean-ups and gardening in the
"real history" dimension, as opposed to keeping a separate database.
I would also oppose the idea of tagging deletion changesets with
information on whether the change is historical or fixing incorrect
data, as long as that information is not editable.
More information about the talk