John Sturdy <jcg.stu...@gmail.com> 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.
>
>__John
There is an abandoned railway line near me which has become reused as a cycle
trail. The cycle trail had a name so someone who wanted to add a name to the
railway created a separate way with the railway tags on it and its name. The
modern cycleway and abandoned railway are the same physical structure, so two
ways is, IMHO, one too many. If the naming issue (and any other repeated tags )
can be resolved having historical data in the db seems fine to me. Road naming
could suffer the same issue with a modern name and, say, a roman name. Named
relations may be over the top.
Rendering such historic data on the default Mapnik render is another thing.
Displaying historic stuff that is not visible now deserves its own separate
render.
Cheers, Chris
User chillly
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
