This is a proposal for adding a notion of Style to LayerGroups. By style is meant not an sld but different LayerGroup named configurations, each comprising different sets of layers' styles and eventually layers, in addition to the default one. From a client point of view this will be like choosing a different style for a layer through the styles parameter. The functionality will be available for layer group with mode SINGLEor OPAQUEonly, since TREEgroups can show only one sub-tree in capabilities.

• Marco Volpini

This proposal is for:

• Geoserver 2.20.1
• GeoServer 2.19.x

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

The new feature will allow a uniform behaviour of layers and layer groups, from a client point of view, with respect to the styles parameter in WMS operations. We will indeed allow any OGC compliant client to choose among new sets of named styles in the capabilities document to get different views of a layer group.

We propose to add a new property as a List of LayerGroupStyle. A LayerGroupStyle will have a name and a list of layers and styles (each one applying to a layer). Eg.

public class LayerGroupStyle {
   private String name;
   private List<PublishedInfo> publishable;
   private List<StyleInfo> styles;
   
   // getters and setters for class attributes.
   ...

   // returns the list of all layers comprising also those contained in nested groups.
   public List<LayerInfo> layers(){
      ...
   }
   
   // returns the list of styles for rendering.
   public List<StyleInfo> styles(){
      ...
   }
}

The currently available list of layers and styles defining a layer group will be kept as the default, while the new ones will be used in case the styles parameter values match one of the named configuration. In this way we don't modify the existing properties constituting the LayerGroup representation. As a result LayerGroupInfo interface will need to be modified to add:

• Getter and setter for the new property
• New methods layers(String styleName) and styles(String styleName) in order to retrieve layers and styles according to a named configuration. Eg.

public interface LayerGroupInfo extends PublishedInfo {
  ...

  List<LayerGroupStyle> getLayerGroupStyles();

  void setLayerGroupStyles(List<LayerGroupStyle> styles);
  
  // return publishable objects
  List<PublishedInfo> getLayers(String groupStyleName);
  
  // get StylesInfo of contained layers
  List<StyleInfo> getStyles(String groupStyleName);

  // return only layers expanding contained groups if present
  List<LayerInfo> layers(String groupStyleName);

  // all styles for rendering
  List<StyleInfo> styles(String groupStyleName);
  
  ...
}

Moreover modifications to the following classes are foreseen: ``

• XStreamPersister a new converter will be added to handle the new configuration object (LayerGroupStyle) marshalling and unmarshalling.
• GetMapKvpRequestReader to resolve the style names to the proper group style/configuration.
• LayerGroupHandler addition of some utility methods to retrieve the layers and styles from a configuration.
• WMS GetCapabilities translators will be modified to list the named configurations as styles of a layer group.
• GetLegendGraphic will need to be modified. In particular the new styles/configurations will need to be handled properly in the GetLegendGraphicKvpParser when retrieving layer and styles.
• GetFeatureInfo support should not require any additional modification since the GetFeatureInfoKvpReader extends the GetMap one.

UI wise in the Publishing tab a new section will allow defining such configurations if selected mode is SINGLE or OPAQUE. We have foreseen two possible way to organize the UI section.

The new UI component will show a table with a list of existing configurations with buttons to add and delete them. By clicking on the name the style/configuration will be available for editing. On addition/modification of a configuration a table, as the one already being used for normal configuration, will be provided allowing selecting drawing order, layer, styles.

The new UI component will show only a list of sequential table each one showing the style/configuration, each one allowing to select drawing order, layer and styles.

Option 2 looks the preferred way to implement the UI since this will make it simplier for the user, as well as code wise, to add multiple styles/configurations in a single session.

The List property will be optional and none of the preexisting properties will be modified.

Even if a core configuration object will be modified, the new configuration property will be optional, thus the modification is backward compatible.

Project Steering Committee:

• Alessio Fabiani: +1
• Andrea Aime:
• Ian Turton:
• Jody Garnett: +1
• Jukka Rahkonen:
• Kevin Smith:
• Simone Giannecchini:+0
• Torben Barsballe:
• Nuno Oliveira: +1

• Jira Ticket
• pull request