[OSM-talk] Multiple Layers for OSM

[Lester Caine]

Jochen Topf wrote:
> In the recent discussion about the the imports in France and DWG governance
> the issue of multiple "layers" in OSM came up again. If we had some kind of
> layer system we could stage imports through them instead of adding all data
> to the OSM database directly and this would help finding problems etc.
>
> It turns out there are many other interesting uses of multiple layers but also
> many technical and social questions around them. I have written down my thoughts
> on this subject in a (rather lengthy) blog post:
>
> http://blog.jochentopf.com/2012-09-23-multiple-layers-for-osm.html
>
> If anybody wants to comment, I think this mailing list is the right place.

Seems to cover everything although there is only one bit I'd 'dispute' ... latter.

Personally I've been happy with potlatch for the sort of editing that I do, and 
the 'layers' of background imagery have improved greatly over the years. So we 
do already have some of the tools needed for this? What would be nice is if we 
could select a background layer when simply displaying - such as the contour data?

Over the weekend I'd finally fired up JOSM and needed QGIS to manipulate some of 
the datasources that I'm currently playing with. Again we have good tools there 
that already understand layers. In my own case the tool that is missing here is 
some sort of 'merge' which will take 'ways' from two layers and provides a 
merged layer with a clean set of unique ways. Actually there may be - and I just 
haven't found it? The 'problem' is where we need to combine ways from polyline 
shapes and create way segments where in my case 'boundaries' share a way. I'm 
sure that the same 'problem' is the basis of MOST imports of raw data? Shape 
files do have a nice database of objects which we can work against, and the 
merged data simply adds a 'way' table providing the relations to the original 
objects. Also processing these tables will allow additional tag information to 
be included if appropriate. I have no problem making data do what I want, the 
bit I need help with is processing and comparing the ways :)

The bit I have an issue with in your blog is 'different data at different zoom 
levels'. Although I suspect it is just a difference of terminology. There have 
been several discussions in the past about micro vs. macro mapping, and adding 
fine detail needs to be done without affecting the macro view of the data. If 
this is done on it's own layer but still links to the macro level of the data 
then it may actually be a sensible way forward? Turning the problem on it's 
head, many applications USING the data don't need the 'graphics' until it comes 
to time to display? So FILTERING the data to provide a view more appropriate to 
the task is probably more important than 'different data'? The conflict that I'm 
hitting at the moment is that of adding 'footway' details to a map that is 'road 
centric'. 'converting' details such as pedestrian access across a roundabout to 
extra tags on a 'data level' where only the roundabout level exists is where the 
problems start?

My own situation is that I HAVE the data sources to provide the overlays ... 
political boundaries ... and they georeference OSM nicely, but I now need to put 
the two together. In addition I need to be able to hot spot the areas to go down 
through the levels. This may be easier in the short term as simple snapshot 
views as images, but to be able to retain live OSM as a background?

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