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 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 element for each map layer offered. If desired, layers may be repeated
in different categories (i.e. enclosed in more than one parent ) when relevant.
If, and only if, a layer has a , 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 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
