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

Reply via email to