[OSM-talk] Multiple Layers for OSM

Lester Caine lester at lsces.co.uk
Tue Sep 25 19:40:06 BST 2012


Matt Amos wrote:
> On Mon, 2012-09-24 at 09:36 +0200, Jochen Topf wrote:
>> >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
> what do you think of the Potlatch 2 vector backgrounds [1] and "snapshot
> server" [2] as steps in the direction of fixing this?

> [1]http://wiki.openstreetmap.org/wiki/Potlatch_2_merging_tool
> [2]http://wiki.openstreetmap.org/wiki/Snapshot_Server

Certainly the 'problem' can be broken down into several elements.

The editing tools certainly have most of what is needed to display multiple 
layers, and merge data between layers. JOSM is obviously geared to handling 
multiple layers and it looks like potlatch2 is heading down the same path?

But what is really needed is a viewer that can combine layers from different 
sources in the same way? Problem here is I think that it does need to be able to 
handle vector as well as raster layers? But isn't that what 
http://layers.openstreetmap.fr/ does anyway? So IS there any development work 
needed here? Other than making the base layers and overlays configurable?

I'd like to set up my own 'server' although 'rails' puts me off as it's 
something else I'd have to learn. Being PHP based, having to cope with java and 
python simply to repair the tools I'm using is bad enough! I've been running 
mapserver for years so perhaps I need to look at that, or is there an alternatively?

OK LAYERS
http://wiki.openstreetmap.org/wiki/OSM_Layers lists 'pluses and minuses' but I'm 
not sure I agree with many of the points on that. 
http://blog.jochentopf.com/2012-09-23-multiple-layers-for-osm.html seems more 
down the right line.

Lets split the problem into three.

Private secondary layers simply need to be geo-referenced and perhaps provide a 
'limit' to the pan function? This is just a rendering problem in the viewer.
An example of this would be 'bird-migrations' overlay which would not use ways 
and nodes from the base layers.

Public secondary layers would be such things as 'low water/highwater/marine' or 
'contour' which are essentially ways that do not 'naturally' need to be 
constructed using the SAME way segments that construct the main map data. 
Actually I don't see the advantage of splitting up even border ways into 
hundreds of small segments simply because a border segment may consist of 
numerous small bits of existing ways? A boundary like 'The cotswolds' is to my 
mind a complete nightmare to edit and consists of hundreds of 'little fixes' to 
join up elements that don't naturally join themselves. So I think that 
boundaries fit more naturally at this level with their own ways!

The base map is essentially a single layer, and some of the 'Why have layers' 
points simply require improved filtering of the data. Perhaps only downloading a 
subset of the raw data. Much as the renderers only display selective subsets. 
Import datasets are essentially stand alone base map layers from which data is 
either extracted and merged directly, or just used as a tracing source.

Having said that boundaries should have their own ways, I don't see any problem 
with the likes of JOSM importing from several layers and managing those layers 
'in parallel' rather than flattening to a single layer. One can switch layers on 
and off easily, and perhaps tag between layers where track details should be 
locked between 'layers' so that editing can handle changes that need to affect 
all layers using the SECTIONS of the same way. The important thing to bear in 
mind here is "Do you actually ALLOW editing of the details of an import?" While 
we may be able to provide updates in advance of that appearing in a later 
import, retaining the historic data may be better managed by tagging the 
relevant elements of an update as 'end_date=xxx' and adding new segments that 
provide the correction. THIS also fits in better with also maintaining the fine 
detail underlying a change ... but begs the question 'is this a fix to faulty 
data' or @an historic change to the object'

While I accept that the change log does maintain this data, accessing it can be 
problematic, while a major API change may be that 'delete' simply mirrors the 
details to the 'historic' database with the correct end_date flag, and changes 
to details result in a copy of the original being archived. Having just written 
that, I am thinking that we need two mechanisms for this. One takes everything 
flagged with a end_date and moves it to a linked historic database, while the 
other simply adds the correct end_date flag. SO for border layers you have the 
option to select a date - past or future - for the rendering we want?

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



More information about the talk mailing list