[OSM-talk] Request for Romano-British features

John F. Eldredge john at jfeldredge.com
Mon Jan 16 15:26:05 GMT 2012

Chillly <osm at raggedred.net> wrote:

> John Sturdy <jcg.sturdy at gmail.com> wrote:
> >On Tue, Jan 3, 2012 at 3:12 PM, Nathan Edgars II <neroute2 at 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

It would make sense to have a separate render, and also to have a way to toggle visibility of historical data in the editor.  It would be useful if the state of that toggle was saved, on a per-user basis, from one editing session to the next.

John F. Eldredge --  john at jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria

More information about the talk mailing list