Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GetFeatureInfo returns non valid GML document with clustered layer #4082

mapserver-bot opened this issue Apr 4, 2012 · 4 comments


Copy link

Reporter: dr
Date: 2011/11/15 - 18:16
Trac URL:
Try to use GetFeatureInfo with clustered layer. Example of WMS server response:

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

                <gml:Box srsName="EPSG:900913">
                    <gml:coordinates>11687998.450672,11932751.091976 11687998.450672,11932751.091976</gml:coordinates>

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?

@ghost ghost assigned szekerest Apr 5, 2012
Copy link

ping @szekerest

Copy link

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

Copy link

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

Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants