Jochen Topf wrote:
I think it is rather difficult do exactly define what an "automated edit" is and what not. And trying to define this better and better is just an invitation to language lawyers to argue about minutiae.
I've deliberately take this out of context because I'm beginning to see plan coming together - at least in my shrinking brain.
The starting point is the discussion on 'Multiple Layers' I'd like to propose that every import is made available as a complete geo-referenced that we can all select and view. Layers will all be date stamped, so that we can select particular point in time. Registering the layer will also record all of the licensing details and where the material has come form. Along with documenting the steps taken to process the source into the correct format and alignment.
This will give us a 'layer number' which will be used as part of any unique object ID's and when merging that data into other layers, the 'source' tag simply contains the layer number - automatically.
I am seeing tools in qgis to run diffs between layers? But basically when a new version of an import arrives we can copy the conversion details from the existing version, and generate a new layer. Then diff tools allow easy identification of new elements that can simply be imported into a 'staging layer' ... HOW that is imported is something that needs to be fine tuned, but potentially could simply be an automatic import? But all of this is 'automated edit' process.
Since the original source element can be identified, MANUAL edits can be referenced back. And deletes simply tag 'end_date=xxx' so information is still accessible. However I would anticipate that the manual processing is simply grouping and identifying ways from the source layer and tagging each created object with a source of the layer number and either an inherited id or one generated within the staging layer. At this stage I'm sure that 'source' layer should be read only, but there should be an additional object table which provides a cross reference to any merged data?
I'm sure that we do not need to break things down as much as http://wiki.openstreetmap.org/wiki/OSM_Layers proposes, since selecting a view of the data that just has a particular sub set of objects is not difficult, but I can see the advantage of secondary caches of data in a layer framework.
-- 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 [email protected] http://lists.openstreetmap.org/listinfo/talk
