[OSM-talk] stop deleting abandoned railroads

Lester Caine lester at lsces.co.uk
Wed Aug 19 08:11:36 UTC 2015

On 19/08/15 01:36, moltonel 3x Combo wrote:
> Be carefull not to mix up database history and real-world history.
> Database history keeps track of the mapping process, as geometry gets
> refined, details get added, and blunders get reverted. World history
> tracks what the world was like at a specific point in time. OHM has to
> keep track of both, but OSM is (at least for now) only concerned about
> db history.

98% of the history that we are looking to manage properly is currently
existing in OSM. All that is needed is to add start dates to the bulk of
the existing data. Personally I have no intention of managing THAT
separately to the main OSM database. The SMALL amount of material that
is a result of new development work invariably maps into currently
existing objects. Insisting that this data is only available for
rendering purposes in a second database is just wrong, and even worse,
the 98% of the supporting data exists in OSM so why maintain a second
copy of it. ALTHOUGH transferring material that for one user is a
'deletion' TO a backup copy on a second database is the alternative here
but that is far more complex than simply tidying up object history IN
OSM itself.

YES development history of the data is different to the evolution of the
objects on the ground, and in the FIRST instance it is those objects
which are being mapped in OSM. And new material should have it's
start_date and that is independent of when it was added to the map. THAT
is why the history contained in the change log is different to the
history of the evolution of an object on the ground!

Overlaying the physical model of the world is additional material which
like much of the secondary data is much better provided as overlays, and
I count things like shop names, contact details and the movement of some
military battle in that category so such material DOES need a clean ID
in OSM which can access the current state of the secondary data. The
history of changes to that are not a job for OSM although that may well
be contained in the change log ... but mixed up with the 'editing' history.

This part of the model does need fixing now since it IS broken and the
longer we go on adding material without also maintaining it's physical
history the more data is also being lost each day. Material such as
'abandoned railroads' is simply part of that evolution of physical data.
The volume of data involved is much less than some of the third party
data already swamping the database so what is the problem simply
properly tracking stop_date in existing rendering and leaving the
evolutionary data in tact with the current material?

Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

More information about the talk mailing list