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:

• ticket:337 : Need a way to prevent layers from being served via WMS
• ticket:300 : Extend behavior of DUMP mapfile parameter for GML output
• ticket:1952 : Tileindex Layer and WMS Get Capabilities
• ticket:2582 : OWS GetCapabilities should skip layers with status == MS_DELETE

Mailing list discussions:

• This ​February 2009 mapserver-users thread started with ticket:2582 and turned into a long exchange with some interesting use cases

Use Cases

1. One needs the ability to hide tileindex layers to all OGC services

2. 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.

3. 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.

4. The copyright notice shall not appear in the GetCapabilities output and shall not be queryable.

5. ...

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.