The general approach sounds reasonable to me. I would quibble a bit on the
names though - I'd prefer not to have to explain what it means to request
an opaque layergroup with transparency enabled :)
How about:
- Single: works as today, the user does not know there is structure inside
- Group and Single: works as today, but the group structure is exposed in
the capabilities document
- Group Only: 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.
--
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Dec 10, 2012 at 6:47 AM, Andrea Aime
<[email protected]>wrote:
> 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
>
>
------------------------------------------------------------------------------
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
