<div dir="ltr"><div><div><div><div><div><div><div>Hi Richard,<br><br></div>I've always presumed that you would create different ways for surface=clay, surface=asphalt with appropriate time intervals. This gets potentially very messy for city streets which may go surface=dirt =>gravel =>compacted=>cobblestone=>asphalt along with changes in lighting, width, lanes etc. (Not to mention names). I deliberately avoided this type of issue when I looked at <a href="http://sk53-osm.blogspot.co.uk/2014/05/editing-historical-road-layouts.html">Derby Road as an example</a>.<br><br></div>These changes are far more frequent than the actual geometry of the way.<br><br></div>One way one could think about this is separating temporal tagging of geometry from temporal tagging of features of the geometry. (In the OSM model this would require introducing a table for features which would contain the tags column; and way_features, node_features, relation_featues; quite how one would handle this with editors etc is another matter).<br><br></div>With respect to dates, I like the stuff suggested by Trevor.<br><br></div>Last thought would be: Would it be feasible to introduce some feature to support temporal queries in the Overpass stack?<br><br></div>Jerry<br><br></div>PS. This is worth mentioning in your talk to show that examples are the way to discover issues/ways of doing things.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 29 April 2015 at 21:59, Richard Welty <span dir="ltr"><<a href="mailto:rwelty@averillpark.net" target="_blank">rwelty@averillpark.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>On 4/29/15 3:08 PM, Richard Welty
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div>On 4/29/15 2:39 PM, Jeff Meyer wrote:<br>
      </div>
      <blockquote type="cite">
        <div dir="ltr">
          <div>- Dates</div>
          <div>  -- Handling approximate date ranges</div>
          <div><br>
          </div>
        </div>
      </blockquote>
      we need to do this anyway, there are lots of cases where we<br>
      need to deal with this.
    </blockquote>
    following myself up, which some people tell me is bad form...<br>
    <br>
    my work on track documentation suggests a need for more than<br>
    just start_date and end_date; tracks drift in and out of operation<br>
    over time and end up with multiple start/stop dates. on top of<br>
    that, there are tracks that were clay then paved or paved then<br>
    clay, and in one supremely novel case, there is an inactive<br>
    track not far from where i live that had pavement in the corners<br>
    and clay on the straights for its first year of operation (not
    enough<br>
    money to pay for pavement all the way around.)<br>
    <br>
    right now i don't really know how to model something like that<br>
    in OSM terms.<span class="HOEnZb"><font color="#888888"><br>
    <br>
    richard<br>
    <pre cols="72">-- 
<a href="mailto:rwelty@averillpark.net" target="_blank">rwelty@averillpark.net</a>
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search</pre>
  </font></span></div>

<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>
<br></blockquote></div><br></div>