Hi From: elvin ibbotson <[EMAIL PROTECTED]>
> This topic reminded me of some thoughts I had about time-based tagging but > did not pursue. I have a professional interest in planned features but a > leisure interest in historic features such as > ancient roads. The OSM database could include both these types of feature but > for general purposes the map should only show what is there now, not what > used to be there but has gone or what > may be there in the future. My thought was that there could be a time-based > tag which would show the time-span of a feature. It might be called 'epoch=' > and could indicate when a feature > existed/will exist. Anything with an epoch which did not include today would > not appear as standard, but a time-based viewer might allow users to 'scroll > through time' seeing features > appear/disappear as the viewer's epoch entered/left that of the features. The same strain of thought occurred to me. I attended a digital humanities conference last weekend in DC, and spoke with many historians about OpenStreetMap. There's real interest. This weekend a couple of American Civil War historians are journeying out to a battlefield with their GPS to record the ebbs and flows of the front line there. > A difficulty is that there will usually be some uncertainty about the dates, > so the tag grammar would need to take account of this. Sometimes the > beginning or the end date will be unknown or there > will be only the most approximate knowledge of a date, so the tag grammar > must allow for various levels of accuracy and for incomplete epochs. One > approach might be to use a grammar like > from to so a road due to open in December this year could be tagged > epoch=12/2008> or an ancient track that fell out of use and disappeared in > the 16th century might be tagged epoch=>C16. > A feature that was known to exist for much of the 1700s but probably not > before or after could be tagged epoch=C18 (implying from/to dates of 1700 and > 1799) whereas a temporary path > existing just for the duration of a construction project might be tagged > epoch=12/03/2006>23/12/2006. The difficulty I see isn't the nature of the time tagging actually. I'd suggest using two tags, "startdate" and "enddate". RFC3339 [http://www.ietf.org/rfc/rfc3339.txt] formatted dates can be adjusted to arbitrary precision. That wouldn't account for vague epochs, but that could be worked out I'm sure. The real issue I see is the problem described previously in the thread -- every part of the tool set would need to become cognizant of time in order to avoid an avalanche of past, present, and possibly future map data. That's all the editors, renderers, and transformation tools. Essentially, it would require a non-backwards compatible update of the API. And that's not a small effort! :) Historic mapping data could be branched off onto it's own install, as suggested for planning data. Each historic epoch could simply keep it's own data set. That would cleanly not require deep changes in the stack. But it does lead to huge duplication, of data and code. Another option is to start a single historic branch of OSM, and start coding in the necessary changes in the core tools for handling start and end dates, with a long term aim to merge support back into trunk and the entire ecosystem of tools. For the moment, I may just suggest that the civil war historians set up their own OSM install, where we can start hacking on these general issues. -Mikel
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
