[OSM-talk] Proposal for import guidelines

[Lester Caine]

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