On 19/08/2015, Lester Caine <les...@lsces.co.uk> wrote: > 98% of the history that we are looking to manage properly is currently > existing in OSM. All that is needed is to add start dates to the bulk of > the existing data.
What do you do when a road gets upgraded, widened, straightened, renamed, or some combination thereof at various points in time ? start/end_date tags are way too crude, they can't capture any evolution (as opposed to construction/demolition) of the real world, making their use very limited. > The SMALL amount of material that > is a result of new development work invariably maps into currently > existing objects. That's just not true, by definition new developments are new objects (and often a lot of old objects relegated to the past). And the amount of evolution in the real world is by no mean small. > Insisting that this data is only available for > rendering purposes in a second database is just wrong, and even worse, > the 98% of the supporting data exists in OSM so why maintain a second > copy of it. I would actually love to be able to map the past in OSM. But if all you have to offer me is start/end tags and some renderer/editor workarounds, I'll say no thanks. To me OHM's value is not so much in its data as in being a sandbox to experiment with tooling to map the past, which can eventually be merged back into OSM. I suppose the OSM data model itself has to be modified to support a nonlinear history, but this is tricky. _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
