<div dir="ltr"><div><div><div>HI Lester,<br><br></div>Many of the use cases for OHM feature data which has never appeared, and will never appear in OSM. OHM is not a historical repository for OSM data <i>per se</i>: at least not as currently envisaged and supported.<br><br></div>Regards,<br><br></div>Jerry<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 December 2014 at 14:06, Lester Caine <span dir="ltr"><<a href="mailto:lester@lsces.co.uk" target="_blank">lester@lsces.co.uk</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18/12/14 12:58, SK53 wrote:<br>
> Although OHM uses the OSM technology stack and most of us are OSMers, it<br>
> is functionally & organisationally (not that it has much of a formal<br>
> organisation) independent from OSM, and the OSMF.<br>
><br>
> So far in discussions over the past year I think our approach is<br>
> slightly different from OSM<br>
<br>
OSM is providing an ideal base to build on. With all of the historic<br>
mapping that is now available as a background to the data set, and the<br>
slowly growing inclusion of the correct tagging of historic elements<br>
like start_date and end_date. Even the change-log history is now<br>
accessible as another time axis for things like changes of names and the<br>
like going forward, but that now needs augmenting with the previous changes.<br>
<br>
The tools that need improving are those which allow secondary layers of<br>
data to be merged with the main database. I see little point trying to<br>
completely mirror a second copy of the master data which is so key as a<br>
base. It is not so easy to add additional layers though such as<br>
spreadsheets of population figures or many of the other geographically<br>
related data sets. I view cross references to the likes of geonames and<br>
wikipedia falling into this area, since it also allows the natural<br>
addition of a time related filter. Tracking the evolution of a locations<br>
TZ settings can be handled as a historic access to the geonames data, or<br>
similar database.<br>
<br>
While material that now has an end_date is purged from the main<br>
database, it's content needs to be maintained in a secondary layer onto<br>
which things like the now lost Roman roads, railway lines and other<br>
structures can be mapped in exactly the same way as OSM currently works.<br>
SO a mirror only needs to maintain material that has dropped out of<br>
interest to current day mappers? But a substantial amount of that data<br>
surfaces in the current day maps?<br>
<br>
--<br>
Lester Caine - G8HFL<br>
-----------------------------<br>
Contact - <a href="http://lsces.co.uk/wiki/?page=contact" target="_blank">http://lsces.co.uk/wiki/?page=contact</a><br>
L.S.Caine Electronic Services - <a href="http://lsces.co.uk" target="_blank">http://lsces.co.uk</a><br>
EnquirySolve - <a href="http://enquirysolve.com/" target="_blank">http://enquirysolve.com/</a><br>
Model Engineers Digital Workshop - <a href="http://medw.co.uk" target="_blank">http://medw.co.uk</a><br>
Rainbow Digital Media - <a href="http://rainbowdigitalmedia.co.uk" target="_blank">http://rainbowdigitalmedia.co.uk</a><br>
<br>
_______________________________________________<br>
Historic mailing list<br>
<a href="mailto:Historic@openstreetmap.org">Historic@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/historic" target="_blank">https://lists.openstreetmap.org/listinfo/historic</a><br>
</blockquote></div></div>