[OSM-talk] stop deleting abandoned railroads

[moltonel 3x Combo]

On 18/08/2015, Lester Caine <lester at lsces.co.uk> wrote:
> On 18/08/15 13:04, moltonel 3x Combo wrote:
>> Remember that deleted osm objects *are* kept in the osm history and
>> can even be undeleted (finding the old object id is currently a pain,
>> but I certainly hope that this'll become easyer someday). Deleting an
>> object is hardly different from editing it as far as osm history is
>> concerned. Russ singled out actual deletion as something specific, but
>> disagreement on if/how to map something happen all the time in OSM
>> (thankfully rarely with that level of drama), not just when deletion
>> is involved.
>
> On OHM these objects need to co-exist ... if OSM is going to create yet
> another version of the historic object if recovering from the change log
> we are going to get into even more of a mess. This is why 'delete' *IS*
> the wrong concept for objects that CAN be authenticated historically.
> The whole problem here is that objects like railways are going to evolve
> over time, and while some elements may no longer be visible, maintaining
> the sequence IS important even if some people think that there is no
> place for that information is OSM.

Are you implying that OSM should do what it can to be easily merged in
OHM ? Currently OHM is a completely different db, with its own object
ids. There's no link between OSM ids and OHM ids to keep track of. The
OSM data model would make that tracking very difficult (way
splits/joins, etc) but maybe it could work. More pragmatically, OHM
could have OSM data as an ever-evolving present day data layer, with
its own ids.

Or are you saying that OSM should take on OHM techniques (and thereby
become OHM) ? With OSM's data model, if you want to keep track of both
today's world and yesterday's, you're going to need to track two sets
of objects, not just two versions of the same object (because of
splits and such). Tracking this using tags is horribly messy at scale.
A better solution would require some data model changes and editor
support, but OHM currently has neither. So we currently say "no
thanks" to historical data in OSM.

In OSM's data model, deletion is not different from modification. If
your historical project can't deal with that, you need to get back to
the drawing board.


> I repeat what I have said many times before ... we are documenting that
> very history today, ad while the information is available from the
> change log, it ALSO needs to be directly accessible from the OHM view so
> why not simply maintain that information in a format that the CURRENT
> rendering tools can show and the current editing tolls can improve on.
> The change log is simply the wrong place for this data to exist in ...

Be carefull not to mix up database history and real-world history.
Database history keeps track of the mapping process, as geometry gets
refined, details get added, and blunders get reverted. World history
tracks what the world was like at a specific point in time. OHM has to
keep track of both, but OSM is (at least for now) only concerned about
db history.