[mapserver-users] WMS Layer Ordering

[Daniel Morissette]

Guys,

I agree with Rob's argument that one should not rely on the ordering of
layers in WMS capabilities, but I also agree with Paul that some simple
client implementations will tend to offer that as a default.

So I filed Paul's suggestion in bugzilla since it proposes a better way
to present layers without breaking anything else and without making
major changes to the system:
 http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=155

However, I'm not sure if we'll have time to address that before the 3.6
release though, so it may be only in 3.7.

Daniel


Paul Ramsey wrote:
> 
> Rob Atkinson wrote:
> >
> > The WMS has no concept of "absolute" cartographic ordering
> > relationships precisely because it is designed to share data from
> > multiple sources. Typically a client would use an external
> > configuration to select which layers from which servers appear in what
> > order.
> 
> This seems a little retrograde, to say the least. It almost completely
> forstalls the usefulness of a WMS with more than a handful of
> non-interfering layers. It is nice to provide clients with the ability
> to 'reorder' their layers, but it is also nice to provide them with a
> cartographically sensible default view.
> 
> > FYI some proposed future capabilities schemas allow for multiple
> > presentation hierarchies which would allow for this use case.
> 
> Am I completely out-to-lunch in thinking that people will use the
> capabilities order as an implied layer order? Hell, it is the easiest
> thing to do, foreach(<Layer>){add(layerWidget)} it is happening right
> now through computational inertia...
> 
> > Regards
> >
> > Rob Atkinson
> >
> > Daniel Morissette wrote:
> >
> > > Paul Ramsey wrote:
> > >
> > >> What is the algorithm which determines the relationship between
> > >> layer
> > >> ordering in the map file and the layer ordering in the WMS
> > >> capabilities?
> > >> They do not appear to match up 1:1.
> > >>
> > > Hi Paul,
> > > Unless you have uncovered a bug, which is always possible, then the
> > > order of the layers in the capabilities should be:
> > > 1- First all layers that do NOT belong to any group are listed in
> > > the
> > > order that they appear in the mapfile
> > > 2- Then the layers that belong to a group are listed by group.  The
> > > order of the groups should be based on the order of first of
> > > occurence
> > > of each group when scanning the layers in the mapfile.
> > > If this is not the behavior that you witnessed then please file a
> > > bug
> > > about this with a sample mapfile and I'll have a look.
> > >
> > >> This is not an unimportant problem,
> > >> since the layer order passed in the GetMap request seems to be
> > >> respected
> > >> by the renderer (so if I say LAYERS=roads,lakes my water features
> > >> will
> > >> be rendered on top of my roads features). So if I read my layers
> > >> out of
> > >> GetCapabilities, and then apply those layers in a GetMap in
> > >> exactly the
> > >> same order I get them, the result may be quite different from the
> > >> result
> > >> if I did the same query using the mapserver interface instead of
> > >> the WMS
> > >> interface.
> > >>
> > > I agree that if you have some layers with a group value and some
> > > without
> > > group values then following the order of layers in the capabilities
> > > could lead to cartographically invalid results.
> > > Suggestions of better ways to handle this are welcome.
> > > Thanks,
> > > Daniel
> > >