Changes between Version 5 and Version 6 of HidingLayersInOGCWebServices

Timestamp:

Mar 2, 2009, 1:22:46 AM (15 years ago)

Author:

mko

Comment:

--

HidingLayersInOGCWebServices

@@ -42 +42 @@
 === Solution 1 ===
 
-Disable each request type per service. The metadata section of the layer object could be extended by a key {{{[service]_disable_request}}}. Each request type listet in this key will not be processed for the given service. The value {{{all}}} will disable a service completely. Examples:
+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:
 {{{
-    wfs_disable_request 'all'
-    wms_disable_request 'getcapabilities getfeatureinfo'
+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
 }}}
-
-The docs must contain clear warnings about the behaviour of the feature, esp. the value 'all', the 'ows' string for [service] and OGC compability.
 
 === Solution 2 ===
 
-Enable or disable a service by a new map file setting {{{SERVICE WMS|WFS}}}. The {{{DUMP TRUE}}} setting could be used to control GetFeatureInfo requests. In order to hide a layer a new metadata {{{[service]_hidden_layer}}} could be used.
+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 ==