GetFeatureInfo returns non valid GML document with clustered layer

[mapserver-bot]

Reporter: dr
Date: 2011/11/15 - 18:16
Trac URL: http://trac.osgeo.org/mapserver/ticket/4082
Try to use GetFeatureInfo with clustered layer. Example of WMS server response:

<?xml version="1.0" encoding="ISO-8859-1"?>

<msGMLOutput 
     xmlns:gml="http://www.opengis.net/gml"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <herbary_layer>
        <herbary_feature>
            <gml:boundedBy>
                <gml:Box srsName="EPSG:900913">
                    <gml:coordinates>11687998.450672,11932751.091976 11687998.450672,11932751.091976</gml:coordinates>
                </gml:Box>
            </gml:boundedBy>
            <Cluster:FeatureCount>1</Cluster:FeatureCount>
            <Cluster:Group></Cluster:Group>
        </herbary_feature>
    </herbary_layer>
</msGMLOutput>

But this document is not valid. Try to parse it within OpenLayers I get an error message: "XML Parsing Error: prefix not bound to a namespace". Is it possible to exclude Cluster:FeatureCount and Cluster:Group tags from server response?

[tbonfort]

ping @szekerest

[szekerest]

Hmmm. Looks like colons in field names are not really appreciated. It could probably handled in the WMS driver?

[tbonfort]

@szekerest colons in xml tags are illegal, there is no way we are going to be able to escape those. Can we change the clustering driver to output Cluster_Group instead of Cluster:Group?
As a workaround for the original issue, use the ows_incude_items metadata to only include the attributes that are needed.

[tbonfort]

With hindsight, choosing attribute names that are hardcoded to something that contains a colon was not a good choice as it prevents them from being included in any xml document, given that there's a very strict limitation on what characters are allowed for an entity.
Our options here are very limited:

• we could make the gml output code replace invalid characters by "_" but that's an ugly and error-prone workaround
• our xml outputting code detects these invalid attribute names and avoids outputting them at all
• the cluster code is reworked to create sanitized attributes and this is documented in the 6.4 migration guide.

I'm demilestoning this as this is definitely something that cannot happen in a point release