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