-
Notifications
You must be signed in to change notification settings - Fork 2
HidingLayersInOGCWebServices
== 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:
- Start by collecting use cases
- Present and discuss possible solutions
- Write and vote/approve a RFC
- 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
- ticket:1632 : support for named group layers using wms_layer_group
- ticket:3608 : INSPIRE related suport
Mailing list discussions:
- This [http://lists.osgeo.org/pipermail/mapserver-users/2009-February/059944.html February 2009 mapserver-users thread] started with ticket:2582 and turned into a long exchange with some interesting use cases
== Use Cases ==
-
One needs the ability to hide tileindex layers to all OGC services
-
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.
-
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.
-
The [http://mapserver.org/faq.html#how-do-i-add-a-copyright-notice-on-the-corner-of-my-map copyright notice] shall not appear in the GetCapabilities output and shall not be queryable.
-
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)
-
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.
-
...
== 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 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.