[OSM-talk] Import guidelines proposal update

[Lester Caine]

Frederik Ramm wrote:
> But besides the "content" aspect, there's also the technical or procedural
> aspect - things like where and how to document your import, or whether or not
> you need a separate import account, or whether it is acceptable to do
> large-scale imports with an account the name of which signals disdain for the
> project. I don't think these should be decided locally.

Seconded
There are perhaps three separate discussions here ...
1 - How fine a detail should be allowed?
2 - Is the style of raw imported data acceptable to OSM?
3 - Do we need to be able to identify a raw import?

The first is more of a problem than the other two?
People mapping at a macro level only using the same was as the road, boundary, 
edge of building, and so on make it difficult for those of us who are now adding 
the footpaths between that road and building. And some will always oppose adding 
some types of data - such as building. I have no problem with adding the coble 
stones but as an area tagged such, which may actually be the road! The automatic 
reduction of that area to a way for routing is another matter?

The second links to the first when we import a course dataset and it needs to be 
reworked to fit into the OSM 'guidelines'. It may be preferable NOT to import 
the raw data, but provide it as an overlay for tracing? Or rework the raw data 
prior to import to a suitable format.

The third then becomes a matter of 'is this the same data that as provided by 
the raw import'. Personally I think that identifying an element against a 
unique_id from the source data SHOULD be the standard, so that hopefully in 
years to come we can simply automatically scan a new dataset and flag everything 
that has changed? That includes objects that have disappeared! We then need to 
be able to identify those items that have not been modified (point 3) and update 
them if necessary. And those that have (point 2) so we can provide a 'manual 
merge' list.

The 'separate account' was a crude attempt to provide a short term fix for 2/3 
until a proper solution was put in place, and currently is still the best way to 
identify things until a more rugged solution is provided - centrally!

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