[OSM-talk] Request for Romano-British features

Lester Caine 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 
data stored.

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 mailing list