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