New templating mechanism does not work with WMS GetFeatureInfo-Request

[nhermann]

I configured the mapfile according to the references:

http://mapserver.org/development/rfc/ms-rfc-36.html ​http://lists.osgeo.org/pipermail/mapserver-dev/2009-January/008168.html

to generate a JSON string out of a WMS GetFeatureInfo-Request. I specified: &INFO_FORMAT=application/json&

which leads to an exception( msWMSFeatureInfo(): WMS server error. Unsupported INFO_FORMAT value (application/json) ) respectively the new template is not used.

A short sample how to use the new mechanism would be helpful in any cases.

[sdlime]

Seems like this could be a relatively easy addition to the WMS code although I'm not that familiar with it. If someone more familiar could point me in the right direction I'd be happy to work on it.

Steve

[dmorissette]

Here is a quick hack that disables the error message and lets you pass INFO_FORMAT=json in the URL

[dmorissette]

I played wit this a bit. The patch above is a quick hack that disables the error message and lets you pass INFO_FORMAT=json in the URL given the following OUTPUTFORMAT:

 OUTPUTFORMAT
    NAME 'json'
    DRIVER 'TEMPLATE'
    MIMETYPE 'application/json'
    FORMATOPTION 'FILE=popplace.js'
 END

Note that with this patch you have to pass the format name and not its mime-type in the INFO_FORMAT.

TODO before we can have a complete fix:

• Advertize valid template formats in GetCapabilities
• Re-enable the test in msWMSFeatureInfo() (mapwms.c) to validate that the INFO_FORMAT parameter is a valid value (the hack above just lets anything go through)
• Make it so that passing the mime-type instead of the format name does work (currently doesn't work because msReturnTemplateQuery() accepts format names only but not mime types... why?)

I also noticed that if the template doesn't contain the magic "MapServer Template" line, the error/exception is returned in the specific EXCEPTIONS format *after* the content-type header for the template has already been returned... so we end up with two content-type header and an invalid response in this case. Not sure how easy/important that will be to fix.

[sdlime]

Mime-types are not necessarily unique. I have instances where I have multiple text/html templates returned via the same mapfile. Summary vs. detailed versions of many formats with the same mime-type could be common. Same issue we'd have with image formats in some cases.

Could support lookup by mime-type but would need a way to resolve duplicates (first hit?).

Steve

[sdlime]

I've updated msReturnTemplateQuery() to use the format search function in mapoutput.c (r9167). If you use a mime-type and there are duplicates the first hit is returned. Format names are definitely more reliable.

Steve

[dmorissette]

We worked with Steve on the problem of duplicate mime-types vs the lookup of output formats by mime-type and figured that the best solution was the use of additional parameters in the mime-type. For instance, the imagemap mime type was changed to "text/html; driver=imagemap" in r9434 (5.6.0-beta4) and this solved the main conflict which was causing WMS GetFeatureInfo in text/html format to return imagemap output instead.

The lookup of output formats by mime type had already solved the issue of supporting templated output formats such as INFO_FORMAT=application/json, so we can call this bug fixed.