[WMS] Client GetFeatureInfo support with cascaded layers

[chris@…]

[Problem]

When acting as a WMS client, the use of GetFeatureInfo() requests are not re-transmitted to the cascaded layers.

See: ​http://mapserver.gis.umn.edu/docs/howto/wms_client/

"GetFeatureInfo is not fully supported since the output of getFeatureInfo is left to the discretion of the remote server. A method layer.getWMSFeatureInfoURL() has been added to MapScript for applications that want to access featureInfo results and handle them directly."

[Request]

To add support (and overcome the problem above) for GetFeatureInfo's, i suggest adding a new metdata switch such as "wms_featureinfo_format" to each layer definition. This would leave configuration up to the central server mapfile, removing any problems with Mapserver trying to negotiate what INFO_FORMAT to request.

As far as i can tell, this issue is no different than negotiating what image or exception format to request. Both of these issues are overcome by specifying wms_format and wms_exceptions_format parameters.

[Reasoning]

There is little use (short of proof of concept) in using Mapserver as a WMS client when it cannot pass on the featureinfo to the servers.

[dmorissette]

You're right that GetFeatureInfo is kind of useless in the context of cascaded
servers, but that's not specific to MapServer, that's a problem that any
cascading WMS server would have.

Unfortunately there is no defined format for a GetFeatureInfo response and until
this is fixed in the spec (if it's ever fixed) there is no way that MapServer
can ingest a GetFeatureInfo response from a remote server and do something
meaningful with it (in order to cascade it).

The message I get from OGC is that WFS should be used for queries and not
GetFeatureInfo. I only partly agree with that, here is an interesting article
proposing a solution to the problem:

Part 1:
http://www.digitalearth.com.au/2006/01/03/improving-wms-getfeatureinfo-part-1/

Part 2:
http://www.digitalearth.com.au/2006/01/05/improving-wms-getfeatureinfo-part-2/

And the related thread on the wms-dev list:
http://lists.eogeo.org/pipermail/wms-dev/2006-January/000772.html

[chris@…]

I understand your concerns Daniel but in our case, every single cascaded server
we will be using is on the same architecture, all using mapserver and all
controlled by us.

In this situation i would argue that the "central" mapserver need not worry
about the "common" getFeatureInfo to use, because all of the layers will support
the same format(s).

Since our situation for using cascaded layers is a bit different from most, any
pointers at which bit of code to look at would be appreciated.

[tomkralidis]

I think the easiest thing to do (for those interested) would be for MapServer to simply be a proxy/broker for cascaded GetFeatureInfo requests. This, I think, is all we can really achieve given how wide open GetFeatureInfo response formats can be. It would then be up to the client to process accordingly.

[tomkralidis]

• when doing the remote request, do we simply do an HTTP Location redirect, or do we actually perform the request, swallow the response and return to the client? Note that we do the former for SOS DescribeSensor requests

[mko]

Cascaded WMS are often located in the intranet and single MapServer provides these WMS for the Internet. An http redirect would not be sufficient. Will this work for MapScript, too?

[dmorissette]

This will be in 6.2. See ticket #3764.