Opened 17 years ago
Closed 11 years ago
#1632 closed enhancement (fixed)
support for named group layers using wms_layer_group
|Reported by:||Owned by:||mapserverbugs|
Currently, when using wms_layer_group, the group layers end up only with a <Title> in the WMS GetCapabilities, so they cannot be requested by a WMS client. We need support in order to be able to group layers together with mixed geometries (a POLYGON, LINE and POINT layer), under the strict condition that these layers have the same attributes. With this last condition I have to make 1 remark, since shapefiles normally have standard attributes like length or area which differ between geometry types. So the restriction would be: the layers share a common set of attributes as defined by the gml_include_items METADATA. The consequence of this would be: 1) there needs to be a mechanism to define a wms_layer_group as requestable (i.e. having a <Name> in the GetCapabilities). We could re-use the GROUP keyword for this, or introduce new metadata. The GROUP will define which level of the XPath expression is requestable, so in the case below you can request DIGITALTERRAIN. E.g.: "WMS_LAYER_GROUP" "/TOPOGRAPHY/DIGITALTERRAIN" .. GROUP "DIGITALTERRAIN" .. DATA "dt_points" .. DATA "dt_lines" .. DATA "dt_polygons" 2) The grouped layer needs to be queryable. The WMS GetFeatureInfo response will have 1 layer and multiple features if features exists in the point, line and polygon layer. 3) It should be possible to issue a GetLegendGraphic request for the group layer, Mapserver would need to create an image of all the legends of the sublayers of the group. Also, there should be a LegendURL advertized in the GetCapabilities. 4) It should be possible to assign a METADATAURL to the group layer. 5) When doing a DescribeLayer request, multiple typenames/queries can be returned (one for each sublayer). This is valid according to the schema, since 1 LayerDescription can have multiple queries. <!ELEMENT LayerDescription (Query*) >
Change History (8)
comment:1 by , 17 years ago
comment:2 by , 12 years ago
In order to allow maximum flexibility, a wms_group_layer should be a normal layer (with the ability to set NAME or omit). The metadata wms_group_layer should only be used when writing the capabilities.
comment:3 by , 12 years ago
- in msWMSPrintNestedGroups() check if groupname is a real layer and then use msDumpLayer() in stead
- additional parameter for msDumpLayer() which indicates it's called from msWMSPrintNestedGroups and so the <Layer> tag should not be closed and warnings may be omitted
- additional layer metadata which sets the LAYER.NAME not to be written in the capabilities (structural layer only)
by , 12 years ago
Using this patch, wms_layer_group can reference the name of a map layer which appears as the group layer in the capabilities. This patch needs some investigations in order to hide the referenced layer from the top level (currently it will be dumped twice) or use #1952 to hide it.
comment:4 by , 12 years ago
What about the possibility to use the GROUP element as discussed initially in the bug? referring to the doc at http://osgeo-org.1803224.n2.nabble.com/file/n5661761/MS_RFC_INSPIRE.pdf, the first example could be setup using:
LAYER "wms_layer_group" "/Hydrography/Hydrography_physical_waters/HY.PhysicalWaters.Waterbodies/Watercourse/Watercourse_Linestring" "GROUP" "Hydrography" "Hide layer to GetCapabilites, Make layer available for GetMap,GetFeatureInfo" ... END LAYER "wms_layer_group" "/Hydrography/Hydrography_physical_waters/HY.PhysicalWaters.Waterbodies/Watercourse/Watercourse_Polygon" "GROUP" "Hydrography" "Hide layer to GetCapabilites, Make layer available for GetMap,GetFeatureInfo" ... END LAYER "wms_layer_group" "/Hydrography/Hydrography_physical_waters/HY.PhysicalWaters.Waterbodies/StandingWater/StandingWater_Point" "GROUP" "Hydrography" "Hide layer to GetCapabilites, Make layer available for GetMap,GetFeatureInfo" ... END LAYER "wms_layer_group" "/Hydrography/Hydrography_physical_waters/HY.PhysicalWaters.Waterbodies/StandingWater/StandingWater_Point" "GROUP" "Hydrography" "Hide layer to GetCapabilites, Make layer available for GetMap,GetFeatureInfo" ... END LAYER "wms_layer_group" "/Hydrography/Hydrography_physical_waters/HY.PhysicalWaters.Waterbodies/StandingWater/StandingWater_Polygon" "GROUP" "Hydrography" "Hide layer to GetCapabilites, Make layer available for GetMap,GetFeatureInfo" ... END
This GROUP parameter set to Hydrography means that starting at that level and all it's children elements are treated as "real" layers: (the Name tag and bbox are added, thus making them available for GetMap, ... requests)
The "Hide layer ..." mechanism that is upcoming will be used to hide the actual layer from the capabilities document.
The current behavior with respect to the wms_layer_group is preserved if the GROUP parameter on the layer is not specified.
comment:5 by , 12 years ago
Great that this is being looked at! Unfortunately I have a couple of issues with the approach above, especially with respect to the INSPIRE services.
Firstly, I'm not sure how this would work with SLD's? I believe its correct that an SLD namedlayer cannot reference a wms service group layer (watercourse for instance), which is something that would be needed.
Secondly, ideally we wouldn't want the single geometry bottom layers (watercourse_point for instance) to be called in a getfeatureinfo request, we'd need the next layer (watercourse) up as this is the 'official' layer. I understand that with the approach proposed we could technically use the Watercourse layer in the getfeatureinfo request, but that'd be pretty pointless as it would contain no data. Perhaps getting this bit correct is absolutely not possible while mapserver sticks with the 1 geometry for 1 layer rule?
Lastly, unless there's a change to the group 'mechanism', I don't think we'd be able to have enough metadata in the capabilities document for the group layer. There are mandatory INSPIRE metedata elements that wouldn't be covered by name, title and abstract.
Unfortunately INSPIRE is very specific on what it requires because it is designed for interoperability, and because of the interoperability all mandatory requirements must be adhered to.
comment:6 by , 12 years ago
I think that this bug is just one part of what is needed for INSPIRE. It only addresses how the layers could be configure.
It is implied that layers that have a name will be available for GetMap (with SLD) and for GetFeatureInfo (unless configured other wise). So in this example Watercourse as a layer can be requested. Applying the SLD to several bottom layers need to be carefully defined. The initial though on this is to apply the SLD based on the symbolizers (apply point symbolizer to a bottom layer that if of point type, ...)
GetFeatureInfo should also work on the group layer. Here again the response needs to be defined properly, since It can come from several bottom layers.
I am not sure I understand your concerns about metadata and the grouped layers. Can you give specific examples of what would not work?
Note that we should take these discussion to bug #3608. Since this is only for grouped layers.
Baring in mind that all other issues INSPIRE issues are addressed, does the mechanism defined in this bug, enough to define a map file and have a valid output in the capabilities?
I have stared a wiki on this to summarize all the discussions (http://trac.osgeo.org/mapserver/wiki/INSPIRE). Please give it a look and update as needed. It is still incomplete and I am updating it as I go.
comment:7 by , 11 years ago
|Status:||new → closed|