On Wed, Aug 19, 2009 at 6:28 AM, Mikel Maron<mikel_ma...@yahoo.com> wrote: > Agreed! > > "start_date" and "end_date" are best. Suppose for Burning Man, I can just go > ahead and use these tags, and whatever bad result comes out can be used as > motivation for the main rendering systems to tweak their processing (ie add > an osmosis step) to deal with this. Or with updated stylesheets. Whatever > works best for the renderers. > > That may result in overlapping Burning Man maps .. that could be ok for OSM > itself. For Burning Man, and possibly for Flickr, I've set up another > rendering system.
A couple of thoughts: 1) start_date and end_date are fine if you only want to indicate when a node or way *exists*. For nodes/ways that *change* over time, e.g. an unpaved road becomes paved, or the name changes, etc., you would need to create an entirely new node/way with the new start_date equal to the old end_date. This is probably fine, but is something to acknowledge. The alternative is to use tag-specific start/end dates in addition to node/way-specific start/end dates. 2) viewing the map will require a "slide-bar to change the temporal view", but so will *editing*. Imagine 100 years from now, there will be an incredible amount of overlapping data. Possibly the easiest way to deal with this is, when fetching data from the API for editing, rather than specifying a 2-D bounding box to specify the bounds of data (i.e. longitude min/max, latitude min/max), we will instead need to specify a 3-D bounding box (i.e. longitude min/max, latitude min/max, time min/max), where the node/way is fetched if its start_date and/or end_date are within the time range. _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
