John Sturdy wrote:
On Tue, Jan 3, 2012 at 3:12 PM, Nathan Edgars II<nerou...@gmail.com> wrote:
For something like this, where there is very limited overlap between past
and present, it makes sense to use a separate database. But in cases where
most of the features still exist, such as railways or Roman roads, it's
silly to duplicate the effort between databases (or somehow require everyone
improving a way in one to upload it to the other and fix all intersections).
Agreed.
As long as the tagging used is such that things that no longer exist
are not normally rendered (and only show as thin outlines on standard
editors) I think including historic data shouldn't be a problem.
Compared with the amount of modern ("current") data, there's not
really that much of it, anyway, so its effect on the storage
requirements is going to be fairly small; and we still meet the
requirement of the most accurate map of what is current.
This has been my argument all along. The majority of the historic mapping
locally is simply add the date when a road was constructed, but there are very
small sections of roads that have been re-routed and it does seem ridiculous to
have to go to a second database for just a few extra lines of data. We simply
need to apply the end_date tag consistently rather than looking at ways to move
that data to a second database?
There is data that is better supported by a secondary database, such as perhaps
the movements and location of troops during an engagement, but the historic
development of ground features is swamped by start_date information. This does
of cause leave a grey area with administrative boundaries. Something that
changes quite regularly in the UK at least. The history changes here are best
managed as secondary data, in which case, the 'current' view would just be
synchronised from that database and changes of country names, boundaries, and
other 'political' data would be edited in the secondary database first? I'm sure
that other examples would also make sense?
--
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//
Firebird - http://www.firebirdsql.org/index.php
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk