GML document produced is not valid

[assefa]

GML producded as a result of a GetFeatureInfo request produces an "ivalid" 
GML. The validation was done using the OGC cite validator.

Here is URL that produces a problem : http://www2.dmsolutions.ca/cgi-
bin/mswms_ogc_cite?
Y=60&LaYeRs=Lakes&X=60&VeRsIoN=1.1.1&ReQuEsT=GetFeatureInfo&FoRmAt=image/gif&Wi
DtH=200&BbOx=0,-
0.0020,0.0040,0&QuErY_LaYeRs=Lakes&HeIgHt=100&StYlEs=&SrS=EPSG:4326&InFo_fOrMaT
=application/vnd.ogc.gml


 Here is the GML produced :

 <?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">
	<Lakes_layer>
		<Lakes_feature>
			<FID>101</FID>
			<NAME>Blue Lake</NAME>
			<gml:boundedBy>
				<gml:Box srsName="EPSG:4326">
					<gml:coordinates>
						0.000600,-0.001800 0.003100,-
0.000100
					</gml:coordinates>
				</gml:Box>
			</gml:boundedBy>
			<gml:MultiPolygon srsName="EPSG:4326">
			</gml:MultiPolygon>
		</Lakes_feature>
	</Lakes_layer>
</msGMLOutput>

[tomkralidis]

Can we reuse the same approach when doing a WFS GetFeature?  i.e. the schema is
generated on the fly.

Other issues:

- decide which GML to use (I'm guessing a simple 3.0.0?)
- in terms of the instance document, the output format would have to change
(slightly) to accomodate a valid XMLSchema

[tomkralidis]

Now that valid GML is outputted for both GML2 and GML3L0 via OGC:WFS, we can
probably ref via xsi:schemaLocation the DescribeFeatureType call with
outputFormat XMLSCHEMA for GML2 and outputFormat SFE_XMLSCHEMA for GML3L0.

[hobu]

This one dead?

[tomkralidis]

Depends on how you look at it. From an XML point of view, the document is not valid, as it does not point to a valid W3C XML Schema document. And testing again with trunk gives me back the geometry with a gml:boundedBy element (what about the actual data?).

On the other hand, GetFeatureInfo is an optional operation of WMS. As well, because WMS GetFeatureInfo is optional and has no perscribed schema, different WMS server software use their own formats. Which has resulted in WMS client software to handle GetFeatureInfo differently (i.e MapServer-ish, CubeWerx-ish, ESRI-ish, etc.).

There's a few ways to solve this one:

• have mapwms.c have a GetSchema operation to return a correct schema for GetFeatureInfo requests, to produce a valid document for the _existing_ format of GetFeatureInfo

• have mapwms.c pass the request (in C code, not HTTP) to mapwfs.c GetFeature passing featureid along and return a response which look like what WFS GetFeature would look like. This would be less development but _guaranteed_ heartache for clients.

Any other ideas?

Setting to 5.2

[sdlime]

Tom: Just to clarify atrributes are governed by the same transformation (e.g. gml_include) as WFS...

Steve

[tomkralidis]

Replying to sdlime:

Tom: Just to clarify atrributes are governed by the same transformation (e.g. gml_include) as WFS...

Steve

Thx. That's what I thought, and have set in my mapfile:

http://devgeo.cciw.ca/cgi-bin/mapserv/ecows?version=1.1.1&service=WMS&request=GetFeatureInfo&layers=obs&query_layers=obs&format=image/png&info_format=GML.1&srs=EPSG:4326&transparent=TRUE&exceptions=application%2Fvnd.ogc.se_xml&bbox=-87.205939,38.706640,-70.016061,49.029094&width=500&height=300&x=334&y=108&radius=5&feature_count=10&styles=

...which brings me back the attributes as expected. But shouldn't the geometry be returned as well. Is it always returned in a gml:boundedBy?

[tomkralidis]

sample xsd document

[tomkralidis]

sample instance document output

[tomkralidis]

As per option 1 of comment:6, I've attached .xsd and .gml examples of the output which would cause as little disturbance as possible and produce a validating document. Of course, the way the namespace and which attributes are output depend on user configuration, data, etc.

So we need to decide on how to proceed as per comment:6. Any comments?

[bartvde]

Tom, I am really in favour of just using the WFS output here. Imagine the following use case: a client first does a WMS GetFeatureInfo, and then wants to retrieve the full geometry using WFS. The most logical way to do this is using featureid, but currently the msGMLOutput does not contain this. Ofcourse you can add this, but why not straigthen things out and use the same output.

I know this will break a lot of WMS GetFeatureInfo clients out there, but that is inevitable IMHO.

[tomkralidis]

Bart: I agree in principle, but am worried about breaking GetFeatureInfo parsers out there, which are tied to scanning for MapServer-ish output.

The unified GetFeature logic would have to support raster query as well, which would require a change in mapwfs.c (i.e. moving, or pointing to, the raster query functionality).

Having said this, my vote would be +1 on using the WFS output instead.

I'd be interested in hearing what other have to say here.