On 20/08/15 14:06, moltonel 3x Combo wrote: > 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 same applies today to mapping the fine detail of what you describe. Many of the footpaths around here have been improved and expanded but there is currently no easy way to map the current state ... but simply adding a date when the footpath first appeared is better than nothing, and that has nothing to do with OHM, it is simply adding current data to the current map. >> 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. Some parts of the world are demolishing large areas of 'history' but on the whole, the increase in volume of currently valid data considerably outstrips the small amount of historic data it replaces. >> 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. Totally agree! The current problem *I* have is that the OHM is a complete waste of space since the material I have a growing amount of is the start_date for the CURRENT objects on OSM. All that I am allowed to add is that start and end date tag, but YES there is room to improve the model ... but it's not just improving management of object evolution, it's adding EXISTING fine detail to current objects. > 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. There is no point my even looking at OHM at the present. Unless I can import all of the existing data from OSM since that is what I want to work on. Along with managing the evolution of the road system in the UK, where very few roads get 'abandoned', while the railway system has not survived quite as well. Just up the road from here one of the military depots is now a new housing development. We have the existing railway structure and can track it's destruction as the new development progresses, and the historic view is already well mapped so there is no work needed to record that ... ONLY tag it's end_date as sections get removed, leaving the elements that are to be retained since restoration of the line down to Broadway is still a potential target. The Broadway bypass was built with a railway bridge 'capable of handling electrification' despite the fact that there is no track bed currently. The route still forms part of the 'protected' network which may be required in the future. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
