GetFeatureInfo for raster queries

[tomkralidis]

Hi,

Can we enable GetFeatureInfo output for raster data?  This would involve:

- making sure layer is shown as queryable in WMS Capabilities (queryable="1")
- outputting GML/XML document of pixel value

Apparently, it's not too much work, given the work done in bug 199.

[fwarmerdam]

Tom,

Did you try it out and see if it works now?

I am taking this bug for now. 

[tomkralidis]

Initially, I did not try this, as raster layers are advertised as queryable=0. 
At any rate, I tried shortrouting the process and ran a GetFeatureInfo against a
raster layer and got a Service Exception saying "the requested layer is not
queryable" (request URL below).

http://devgeo.cciw.ca/cgi-bin/mapserv/ecows?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&SRS=EPSG%3A4326&BBOX=-79.48810000001764,43.60823124998897,-79.27859999998235,43.73916875001103&WIDTH=560&HEIGHT=350&LAYERS=toronto&STYLES=,&FORMAT=image%2Fpng&BGCOLOR=0xFFFFFF&TRANSPARENT=FALSE&QUERY_LAYERS=toronto&INFO_FORMAT=text%2Fhtml&X=224&Y=139&FEATURE_COUNT=5

[fwarmerdam]

Tom,

For raster queries to work you need a TEMPLATE defined on the layer in
question.  Also, if you are requesting text/html format, you will need to 
put meaningful contents in the query template.  Please read over the raster
query wiki topic. 

Finally, I would encourage you to first try making a FeatureInfo request
in the native projection of the data so we can narrow down whether any problems
are specific to reprojected requests (it appears there is no support for this
case in the mapwms getfeatureinfo code) or if they don't even work for "same
coordinate system" requests. 

I realize I am pushing the bulk of the initial bug isolation on to you, but
then that is your punishment for having a good idea.  My punishment for 
responding is to make it work once you have setup a minimal case that *should*
work. 

You can assume I still have the toronto_500_nc.tfw/tif files, but you 
should provide any other supporting files I will need to reproduce the 
problem (the map file, query templates, symbol/font files, etc). 

[tomkralidis]

Frank,

Fair enough.  I should have noted this URL instead, which asks for GML instead
of HTML.  Here's the request for the raster data in it's native projection and
asking for application/vnd.ogc.gml:

http://devgeo.cciw.ca/cgi-bin/mapserv/ecows?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo&SRS=EPSG%3A26917&BBOX=546567.879822572,4788674.874115,653434.590981612,4855466.5685894&WIDTH=560&HEIGHT=350&LAYERS=toronto,hydroshedg&STYLES=,&FORMAT=image%2Fpng&BGCOLOR=0xFFFFFF&TRANSPARENT=FALSE&QUERY_LAYERS=toronto&INFO_FORMAT=application/vnd.ogc.gml&X=224&Y=174&FEATURE_COUNT=5

[fwarmerdam]

Tom,

Note, that you *still* need to provide a TEMPLATE in the layer to mark
it as queriable.  I will try and test with localized variants of this new URL.

[fwarmerdam]

Tom,

With LAYERS= trimmed to the toronto layer, and a template on that layer to 
mark it as queriable, your last query worked for me here locally.  I got the 
following response:

<?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">
	<toronto_layer>
		<toronto_feature>
			<x>589100</x>
			<y>4822350</y>
			<value_0>118</value_0>
			<value_1>125</value_1>
			<value_2>84</value_2>
			<values>118,125,84</values>
			<red>118</red>
			<green>125</green>
			<blue>84</blue>
			<gml:boundedBy>
				<gml:Box srsName="EPSG:4326">
					<gml:coordinates>
						-1.000000,-1.000000 -1.000000,-1.000000
					</gml:coordinates>
				</gml:Box>
			</gml:boundedBy>
			<gml:Point srsName="EPSG:4326">
				<gml:coordinates>589100.000000,4822350.000000</gml:coordinates>
			</gml:Point>
		</toronto_feature>
	</toronto_layer>
</msGMLOutput>

So it seems we have the outstanding problem that the query logic is not
reprojecting the passed in query location into the SRS of the layer based
on the SRS keyword.  I will dig into that somewhat deeper, but it is 
reassuring that the basic GetFeatureInfo is working for rasters within the
usual query constraints (eg. needing a template). 

[fwarmerdam]

Reviewing msWMSFeatureInfo() it would appear that SRS is never consulted, and
no effort is made to reproject the provided X/Y based on it.  I think this 
is a general problem with GetFeatureInfo then, not specific to the raster support.

I'm going to raise the issue on the mapserver-dev list, and see if anyone
knows if this is a bug, or if anyone wants to fix it. 

[fwarmerdam]

On further review, it now looks like the generic WMS parameter loader is
updating the map "projection" based on the SRS definition, and my 
raster query code is supposed to be reprojecting from map to layer coordinate
system on the fly as part of normal operation.  So the problem is raster specific
and I will work on a fix. 

[tomkralidis]

It works for me (the native projection request) if I set in the mapfile LAYER
object:

TEMPLATE "why"

...which is good, and I get the response as you do below, but it leads me to
question why one needs to enable a dummy flag (i.e. something which does not
provide much) via TEMPLATE in the LAYER object to make this happen.

[fwarmerdam]

Tom,

This is the general rule for query in MapServer. Query is enabled by 
providing a query template (whether it is used or not).  Not my idea, I'm just
following the existing convention. 

I presume you would find the 

[fwarmerdam]

... 

the same thing with any of the vector based GetFeatureInfo's. 

[fwarmerdam]

Committed changes to reproject points back to the map projection before
doing distance testing needed by querybypoint case.  (maprasterquery.c)

This also ensures that results are returned in the map coordinate system, 
not the layer coordinate system. 

Also added tests to rqtest.py that verify the reprojection case.