Extend the LayerGroupInfo interface and its implementations to vendor options, combined with a new vendor option to define a scale range for a layer (the same way it is done for style).

Kevin Smith

This feature was intended for GeoServer 2.8, but was delayed to GeoServer 2.9.

Choose one of:

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

Two motivations:

• The addition of a vendor option for interpolation method is awkward for layer groups. The vendor option for interpolation needs to know how many layers are in the layer group (a detail that is not visible from client code).

• The present way to control the visibility of a layer in a scale dependant way is to apply min and max scale denominator attributes to the rules within a style applied to it.

  When constructing a complex layer group, the scale ranges of the sublayers will be interdependant in a way that makes more sense to keep track of at the layer group level (the upper bound of one is likely to be the lower bound of another). This would also reduce the need for the creation and maintenance of multiple styles that exist only to apply different scale ranges while otherwise being identical. A layer used several times with the same style in different layer groups could have different ranges to suite each group.

While making the change we can do so in a way allowing for future improvements (via well established vendor options facility) without further API change to LayerGroup.

Prior to this proposal LayerGroupInfo declares the following methods:

List<PublishedInfo> getLayers();
List<StyleInfo> getStyles();
List<LayerInfo> layers();
List<StyleInfo> styles();

The get variants return the internal lists of layers and styles for those layers in a 1-1 correspondance.

The methods without the get prefix return lists that have been filtered and which have flattened any descendant layer groups.

This proposal would add:

A new class ScaleRange with attributes maxDenominator and minDenominator with the same semantics as they have on the a GeoTools style Rule. It would also provide methods for intersecting scale ranges.

LayerGroup and its implementations would then be extended with two new methods.

List<Map<String, Object>> getVendorOption();
List<Map<String, Object>> vendorOptions();

With the same 1-1 mapping to layers that styles have.

GetMap and GetLegendGraphic requests would be extended with a new vendor parameter visibleScales that restricts the scale at which layers are visible. Obviously a client could do the scale calculation itself and adjust the layers list but allowing this to be offloaded to GeoServer would still be a convenience even without the integration with layer groups.

Example: layers=largeScale,smallScale&visibleScales=10000:100000;100000:1000000 Layer largeScale is visible from 1:10000 to 1:100000 and layer smallScale is visible from 1:100000 to 1:1000000.

The LayerGroupHelper support class would be extended to process flatten the lists of maps, including intersecting scale ranges of descendant layer groups.

The KVP parsing of GetMap and GetLegendGraphic would be modified to do the filtering (Combining the LayerGroup specified scale visibility with any that were specified in the request) when they unpack the Layer Group into their respective Request objects.

In the initial implementation, only the visibleScales option would be handled when coming from a layer group. Implementing the others would be a later project.

• ScaleRange might make more sense being put up stream in the GeoTools styling module as an aid in doing similar manipulations of scale visibility.
• A more drastic change would be to replace the parallel lists with a single list of objects that reference the child, style, and options map. This would reduce the amount of logic being duplicated in LayerGroupHelper but would have more significant issues for backward compatibility.

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

The default scale range if none are specified would be universal (0, Infinity), which would replicate the current behaviour.

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

• [GEOS-7063] Easier way to control scale based visibility of layers
• [Email Discussion]