[OSM-talk] Request for Romano-British features
lester at lsces.co.uk
Wed Jan 4 09:54:11 GMT 2012
Felix Hartmann wrote:
>>>> If someone does this in my area, I'll revert the deletion as vandalism.
>>> Funny. I also consider adding non-existing stuff as "vandalism". I
>>> hope we will never contribute on the same areas...
>> This is the current reason *I* have been unable to contribute to OSM in the
>> last few years. All of the material I am gathering relates to historic mapping
>> and I want somewhere that I can share it with other like minded users. Perhaps
>> now is the time simply to fork a version that is only intended for historic
>> mapping. There does not seem to be any agreement on a cross database API as an
>> alternative to destroying data as it is superseded by changes on the ground.
>> But one of the rules that does apply is that data that has been generated by
>> others SHOULD NOT simply be destroyed unless it is inappropriate.
> The thing is - historic data that doesn't exist anymore is inappropriate because
> it is confusing for anyone contributing to OSM. For the same reason we don't
> want to have anything that is in the air. E.g. if people would trace
> flight-routes into OSM, they would add lots of confusion, as they are not on the
> ground. Flight routes
I tend to agree - also sea routes
THESE are another working example of the need for secondary data layers.
> or historic AND not existing on ground anymore objects is
> simply confusing. Adding tags to a current street/way that states that it was
> once a Roman street on the other hand is of course okay (as long as it was
> important and is currently in a broader sense touristically important), because
> it is still on the ground.
From my point of view that is just a matter of rendering.
There are two areas here and they are getting merged which is part of the
confusion. Adding data on when an object APPEARED on the ground is something
that the main database should be retaining, so a specialist rendering stage
could create a map at any time in the past. For the large majority of existing
objects that is all that is required. So tidying up 'start_date' is all that is
required, and should be encouraged. NEW objects appearing now can have the
correct start_date which may well be in the future.
This just leaves the problem of objects which no longer exist ...
If they cease to exist in the future, then the data has already be captured, and
worse case, the edit history will always retain that material. Some features
will still be present, but their original use may have changed at some point -
railway track beds that are currently being used as footpaths - the date at
which that change occurred would be useful to retain - somewhere. And again edit
history may actually have that information. Although around here, the track is
being relaid, so the change is from footpath back to railway.
This just leaves the mater of how to handle all this newly created 'history',
and I would be quite happy if that was a secondary data layer, so that rather
than deleting data is simply gets archived. This layer would also then allow
those of us who have the data to expand on it to fill in the gaps. The only
thing that I find irritating is that all of the 'new history' will also be
present in the edit history of the main database, and THAT edit history is just
as important as the actual appearance and disappearance of an object. So that
should also be duplicated on the 'historic' archive. Which doubles the amount of
Simply providing mechanisms to view, add and hide this 'live history' makes a
lot more sense to me, and filling in the gaps on that history is what we are
actually discussing, so how does one decided what data stays in the main
database and what is archived? Just retaining all where it is currently stored
just seems the logical way forward to me ... although if a mechanism can be
added for secondary layers ...
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//
Firebird - http://www.firebirdsql.org/index.php
More information about the talk