Identify in WMS: allow GeoJSON as INFO_FORMAT

[brentfraser]

Currently GM requires the WMS server to return feature info in GML format. The "remote" WMS server I'm using for testing only supports:

<GetFeatureInfo>
<Format>application/vnd.esri.wms_raw_xml</Format>
<Format>application/vnd.esri.wms_featureinfo_xml</Format>
<Format>application/vnd.ogc.wms_xml</Format>
<Format>application/geojson</Format>
<Format>text/xml</Format>
<Format>text/html</Format>
<Format>text/plain</Format>

So it would be nice to extend GM to allow user-settable param in the map-source to allow something like: <param name="INFO_FORMAT" value ="application/geojson" />

similar to setting the outputFormat in a WFS map-source. See vector.js, lines 60 to 70.

[tchaddad]

This feels like a dumb question, but why would you return geojson as opposed to json for a WMS getfeatureinfo request?

As a separate issue, at least with Mapserver 7.6, the 3 formats supported for GetFeatureInfo are text/plain, text/html and application/vnd.ogc.gml. Not sure about other server types..

For WFS it is actually different, because A WFS is used to retrieve actual data, and outputformat is used to set the data format being requested, and so geojson makes sense as a data format...

Getfeatureinfo isn't really intended for retrieving data, so not sure if this is relevant at all..

[brentfraser]

GeoJSON would include the geometry useful for highlighting the feature. I had mentioned the WFS code 'cuz it shows how to allow GML or GeoJSON. So a little bit of code could solve this issue. The need to display other formats (HTML, plain, etc) might be a little harder as the GM functions pass around a JSON-friendly JavaScript object. Hmm, now that I've described that, I guess it could pack all the returned text into a "dummy" JavaScript object and just render it.

[tchaddad]

So, I'm not questioning that this sounds useful, but I don't think it is what GetFeatureInfo is for, and it would technically not be supported by the WMS standard, so anything done along these lines would be heavily custom, and not widely used.

Supporting Geojson for GetFeatureInfo also implies that you would have to have a server capable of serving what you would want GeoMoose to consume, and it is not clear what servers would support this - If you have examples, that would be interesting to hear.

All this just makes it seem like If you want the features, then you really want to be using WFS, and not WMS.

[brentfraser]

I think the spec is somewhat quiet on the acceptable (and accepted) values of INFO_FORMAT. GeoServer WMS and ArcGIS Server (MapServer-WMS) seem to support GeoJSON.

And for the one WMS test server I found (https://gis.stlouiscountymn.gov/server2/services/GeneralUse/PublicLands/MapServer/WMSServer?request=GetCapabilities&service=WMS), it returned GeoJSON but not GML(!). So that prompted me to file this issue thinking it could be a common case.

At any rate it was just for testing; I have no specific need. Addressing #325 might be a better use of resources (but more coding).

[brentfraser]

Got caught on this again. Server lists Identify Formats:

application/vnd.esri.wms_raw_xml application/vnd.esri.wms_featureinfo_xml application/vnd.ogc.wms_xml application/geojson text/xml text/html text/plain

But no gml.

[tchaddad]

Yeah I agree that if the esri servers are doing this frequently, we may as well consider supporting it at some point.

For reference, the relevant WMS 1.3.0 spec sections say the following, so it really is very open-ended (and GML is not specified anywhere):

Output formats

The response to a Web Map Service request is always a computer file that is transferred over the Internet from the server to the client. The file may contain text, or the file may represent a map image. As stated in 6.4, the type of the returned file shall be indicated by a MIME type string.

Text output formats are usually formatted as Extensible Markup Language (XML; MIME type text/xml). Text formats are used to convey service metadata, descriptions of error conditions, or responses to queries for information about features shown on a map.

GetFeatureInfo

GetFeatureInfo is an optional operation. It is only supported for those Layers for which the attribute queryable="1" (true) has been defined or inherited. [..] The actual semantics of how a WMS decides what to return more information about, or what exactly to return, are left up to the WMS provider. [..] The mandatory INFO_FORMAT parameter indicates what format to use when returning the feature information. Supported values for a GetFeatureInfo request on a WMS server are listed as MIME types in one or more <Request><FeatureInfo><Format> elements of its service metadata. The entire MIME type string in <Format> is used as the value of the INFO_FORMAT parameter. In an HTTP environment, the MIME type shall be set on the returned object using the Content-type entity header. If the request specifies a format not supported by the server, the server shall issue a service exception (code = InvalidFormat). [..] EXAMPLE The parameter INFO_FORMAT=text/xml requests that the feature information be formatted in XML. [..] The server shall return a response according to the requested INFO_FORMAT if the request is valid, or issue a service exception otherwise. The nature of the response is at the discretion of the service provider, but it shall pertain to the feature(s) nearest to [the point in question].

[brentfraser]

Now that v3 has embraced the concept of an admin writing app.js, and potentially writing other JavaScript (e.g. plugins), perhaps the solution to parsing and rendering Identify results is to implement some kind of JavaScript function "hooks".

For example Geomoose would do the identify and get the results, then if a function named WMSidentify(results) exists, call it. The admin would write a plugin containing that function (parsing the result in whatever format requested via the mapbook setting, and generating the desired HTML). GM would then put the HTML returned in the appropriate spot (e.g the SuperTab).

Or maybe the function would just convert it to GML so the existing templating mechanism would still be used.

[brentfraser]

While a work-around might be to use query-as to a corresponding WFS service, there might not be one.