wiki:HidingLayersInOGCWebServices

Hiding/Enabling/Ignoring? Layers in OGC Web Services

Introduction

Everybody recognizes the need to be able to hide layers from a given mapfile from some or all OGC Web Service (OWS) requests. Some tickets about this are as old as 6 years old. Unfortunately we have been unable to come up with a solution because there are several angles to consider in approaching the problem.

The goal of this page is to organize the resolution of this issue as follows:

  1. Start by collecting use cases
  2. Present and discuss possible solutions
  3. Write and vote/approve a RFC
  4. Implement the solution and enjoy!

References

Tickets:

Mailing list discussions:

Use Cases

  1. One needs the ability to hide tileindex layers to all OGC services
  1. In a WMS mapfile where multiple scale-dependent layers are in a common group, we want only the group to appear in GetCapabilities? and not the individual layers. However the layers should not be completely turned off since we want them to be visible in GetMap? and queryable with GetFeatureInfo? when the group is selected. This use case is common for WMS and may (or may not) apply to other OGC services.
  1. One may want to offer a given layer via WMS but not via WFS (or any combination of services). In other words, we need the ability to select in which OGC services a given layer is exposed.
  1. The copyright notice shall not appear in the GetCapabilities? output and shall not be queryable.

  1. Not about hiding a full layer, but setting the ability to say that one wants a certain layer to return the geometry as gml in a wms-getfeatureinfo-response (at this moment it is never returned)
  1. Handle wms_group_layers as real layers (relevant for INSPIRE), but move the rendering part into hidden layers in order to avoid redundant style configurations in the group layer and the sub layer.
  1. ...

Proposed Solutions

Solution 1

Maybe the most risky one concerning interoperability. MapServer gets a new metadata key [service]_disable_request. Each request type listed in this key will not be processed for the given service. This metadata can be applied on layer sections but also on the web section. In the latter case, the given requests types are disabled for any layers in a map file and for a mapscript object respectively. Disabled requests types may not appear in the GetCapabilities? document. Layers which have the GetCapabilities? request type disabled may not appear in the capabilitiy documents <Layer> subtree. Handling of the GetCapabilities? request type and others may be an inconsistency in this solution. The idea is that a capability document has to be offered as long as the service type is 'alive' – even if any layers and all other request types are disabled.

In order to disable a service (hence OWS exception when called), the value all may be used. In this case the metadata has to be applied in the web section. Having [service]_disable_request 'all' applied on the layer level, it will only disable all requests types for this single layer. This behaviour has to be well documented.

This is probably the most flexible solution to combine request rules for different service types on a single layer. In order to enable a service the document pre-conditions (metadata, data types, settings) still apply. The all value in the web section is only intended to disable a service type if it is enabled for some reason (e.g. not carefully configured) and/or so that the user can be sure a service type is disabled.

Examples:

WEB
   METADATA
      sos_disable_request 'all'             # SOS service completely disabled
      wms_disable_request 'GetFeatureInfo'  # no WMS-GetfeatureInfos at all
      ows_disable_request 'all'             # no services today
   END
END

LAYER
   METADATA
      wcs_disable_request 'all'             # no WCS on this layer
      wfs_disable_request 'GetCapabilities' # layer does not appear in the WFS capability document
      wms_disable_request 'GetCapabilities GetFeatureinfo' # hidden layer and no GetFeatureinfos
   END
END

Solution 2

Enable or disable a service by a new map file setting like SERVICE WMS|WFS. The DUMP TRUE setting could be used to control GetFeatureInfo? requests. In order to hide a layer a new setting or metadata [service]_hidden_layer could be used.

Solution 3

Combination of solution 1 and 2. MapServer uses the SERVICE WMS|WFS|WCS setting in order to enable a service type for a given layer (or other way around to disable a service type?). A second new setting DISABLE GetFeatureInfo|GetStyles (or ENABLE?) controls which request types have to be served. In this solution enabled/disabled requests types apply to all enabled SERVICE types.

Conclusion / Final Solution

The final solution will be the object of a RFC... link to this RFC here when we get there.

Last modified 6 years ago Last modified on Jan 13, 2011 3:28:18 AM