Hi,
so far GeoServer did not support well the concept of layer nesting (there
was wms_path but
it was never working ok, we should remove it).
Most likely too accustomed to layer groups behavior I've made some
assumptions that
on a deeper read do not seem to be warranted.
Here is an excerpt of the WMS 1.3 specification on layer nesting:
----------------------------------------------------------------------------------------
Each available map is advertised by a <Layer> element in the service
metadata. Conceptually, each Layer is a
distinct entity. However, as a means of classifying and organizing layers,
and as a means of reducing the size of
the service metadata, a single parent Layer may enclose any number of
additional layers, which may be
hierarchically nested as desired. Some properties defined in a parent layer
are inherited by the children it
encloses. These inherited properties may be either redefined or added to by
the child. Subclause 7.2.4.8
summarizes whether or how each property is inherited.
A server shall include at least one <Layer> element for each map layer
offered. If desired, layers may be repeated
in different categories (i.e. enclosed in more than one parent <Layer>)
when relevant.
If, and only if, a layer has a <Name>, then it is a map layer that can be
requested by using that Name in the
LAYERS parameter of a GetMap request. A Layer that contains a <Name>
element is referred to as a “named
layer” in this International Standard. If the layer has a Title but no
Name, then that layer is only a category title for
all the layers nested within. A server that advertises a Layer containing a
Name element shall be able to accept
that Name as the value of LAYERS argument in a GetMap request and return
the corresponding map. A client
shall not attempt to request a layer that has a Title but no Name.
A containing category itself may include a Name by which a map portraying
all of the nested layers can be
requested at once. For example, a parent layer "Roads" may have children
“Interstates” and “State Highways” and allow the user to request either
child individually or both together.
---------------------------------------------------------------------------------------
First thing, a named layer can appear multiple times in the capabilities
document.
This is a bit weird, in that the same layer could be nested under different
parents and inherit
different base settings (say for example one parent declares a time
dimension, and another does not,
this would be inconsistent...).
Then, there is a thing we do not support called "containing category" which
is just a way to organize layers, but that cannot be requested directly.
Finally, a category can have a name allowing all the nested layers to be
requested at once, which
sounds a lot like our layer groups, and seems to confirm that having a
layer group with a
"layer in the root" was not intended by the original WMS spec (but it's
clearly demanded by
the WMS EO one).
Given this, my proposal for handling WMS EO would be the following.
First off, add a new field called "type" in layer group with the following
possible values:
- opaque: works as today, the user does not know there is structure inside
- named category: works as today, but the group structure is exposed in the
capabilities document
- containing category: the group structure is exposed in the caps document,
but the layer group
is not given a name and thus cannot be used as a layer
- earth observation group: in this case the structure is exposed in the
caps document, but
we also show a new "root layer" field allowing to configure the root
layer.
A new option, "root layer" will be made available in the configuration,
allowing the
WMS EO root layer.
The LayerGroup will have a new renderingLayers() method that will be used
by code
to get the list of layers to be used for rendering.
In case of opaque and named category without root it will just return the
layers,
in case of containing category it will throw a service exception, and in
case
of earth observation group, it will return the root layer.
Seems to me this gives most of the benefit without getting users into too
much confusion,
it also labels the EO specific usage quite clearly, hopefully people not
knowing what
that is will stay away from it.
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
