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
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
