Expand the layer group from being just a tool to create base maps to a tool to handle layer trees in the GetCapabilities document.

Andrea Aime

2.3.0

Choose one of: Under Discussion, In Progress, Completed, Rejected, Deferred

The WMS GetCapabilities contents section contains a tree of layers, which can be used for both brevity and organizational purposes.

Currently GeoServer has a root layer supporting all the possible CRSs, to avoid repeating them for each layer, and then an entry for each published layer. Layer groups in this structure are entries just like any other simple layer.

The layer configuration has a “wms path” property to locate a layer in a particular position in the WMS tree structure, but unfortunately it is not quite usable:

• its support always lagged, and it was broken solid by the last large WMS refactor
• it allows to position a layer in a single place in the layer tree, whilst a layer can actually be published multiple times in different positions of the tree according to the WMS standard

The idea is simple: drop “wms path” and use layer groups as a tool to organize the layer tree in the WMS capabilities. This will work for one level hierarchies, but we envisage also extending the layer group to contain both layers and other layer groups in the short term, thus providing full control over the layer tree structure.

Limited to this proposal we are going to add a new field called groupMode to LayerGroupInfo controlling how the group is exposed to the outside world, with these four tentative values:

• single: the layer group as today, a single exposed layer with a name
• named tree: the layer group retains a Name in the layer tree, but also exposes its nested layers in the capabilities document
• container tree: the layer group is exposed in the tree, but does not have a Name element, showing structure but making it impossible to get all the layers at once. This is called “containing category” in the WMS specification.
• Earth Observation tree: a special type of group created to manage the earth observation requirements (described layer)

In case a layer is included in a any non single group it won’t be listed anymore in the flat layer list, although it will still be possible to include the same layer in different layer groups.

The use case of having a layer in the flat list and also in groups does not seem significant, but it is allowed by the WMS spec: if we notice that this is important we can add an extra flag to the layer configuration forcing its presence in the flat list.

The Earth Observation tree is a special mode created to support the WMS EO requirements, in which a Earth Observation product needs to be exposed in its previous form as a layer, and then provide all its detailed contents as new layers that are children of said layers (and using a particular naming convention). When the root of the group is chosen the result is the preview layer, which is normally not the sum of all contained sub-layers.

When the Earth Observation tree mode is chosen, a new field “root layer” will be exposed in the configuration UI, allowing the administrator to choose the “preview” layer sitting in the root of the group.

LayerGroupInfo will have a new “renderingLayers ()” method that returns the list of layers to be used to render the group, in particular:

• in single and named tree mode it will return the same value as calling “getLayers ()”
• in container tree mode it will throw an exception, since the group is not meant to be called directly
• in Earth Observation tree mode it will return the root layer

This section should contain feedback provided by PSC members who may have a problem with the proposal.

If the mode is not set the layer group will behave in “single” mode, preserving backwards compatibility for people upgrading GeoServer.

Alessio Fabiani: +1 Andrea Aime: +1 Ben Caradoc-Davies: Christian Mueller: +0 Gabriel Roldan: Jody Garnett: +1 Jukka Rahkonen: +1 Justin Deoliveira: +1 Phil Scadden: +1 Simone Giannecchini: +1

Chair: Chris Holmes: +1

JIRA Task Email Discussion Wiki Page