Opened 16 years ago

Last modified 14 years ago

#2680 assigned defect

fix bounds for raster GetFeatureInfo HTML output

Reported by: tomkralidis Owned by: warmerdam
Priority: normal Milestone: 5.6 release
Component: WMS Server Version: svn-trunk (development)
Severity: normal Keywords:
Cc: sdlime, dmorissette

Description

Doing a GetFeatureInfo against a raster dataset returns an HTML document with an extent of 0,0,200,200.

It looks like the code is pulling these values from QUERYMAP.SIZE. If I change QUERYMAP.SIZE in tomk_workshop.map, this changes the output.

You can see this behaviour when running msautotest/wxs/run_test.py tomk_workshop.map (test is wms_get_feature_info_raster.html). The current output is expected/wms_get_feature_info_raster.html. A diff yields:

[devgeo:/home/tkralidi/foss4g/mapserver/trunk/msautotest/wxs]$ diff expected/wms_get_feature_info_raster.html result/wms_get_feature_info_raster.html 
26c26
<                                 <td>-179.640000,-179.640000,179.640000,179.640000</td>
---
>                                 <td>0.000000,0.000000,200.000000,200.000000</td>
46c46
<                                 <td>1.805427</td>
---
>                                 <td>1.000000</td>

(the other diff is the cellsize, which is derived/affected from the extent).

Note: this worked previously. Wondering whether the query / template changes have any affect.

Note sure whether this is 5.2 or 5.4 worthy.

Attachments (1)

extent.patch (2.0 KB ) - added by warmerdam 14 years ago.
Patch to fix minx/maxx/miny/maxy when nonsquare mode in effect, not suitable final patch though.

Download all attachments as: .zip

Change History (16)

comment:1 by tomkralidis, 16 years ago

Some more info: msautotest/wxs/templates/query_header.html is used as the header for this output, which is where the issue occurs:

...
<td>[minx],[miny],[maxx],[maxy]</td>
...

It looks as though the template processor is filling in minx/miny/maxx/maxy with QUERYMAP.SIZE instead of the bounds of the response.

comment:2 by warmerdam, 14 years ago

Cc: warmerdam removed
Milestone: 5.6 release
Owner: changed from mapserverbugs to warmerdam

Is there some reason to believe that [minx] is supposed to refer to the results set? The code in maptemplate.c gets it from map->extent.minx and I don't see any obvious reason to believe it ever has to do with the extents of the result of the query.

The values are pixel/line instead of real georeferenced because non-square mode is in effect. I didn't look into exactly why. I suspect that minx/maxx/miny/maxy should be transformed through the geotransform in the projectionObj if it is enabled (need_geotransform is set). I'll prepare a patch for this.

Steve, any thoughts on the proper semantics of the minx/maxx/miny/maxy template variables in this sort of situation?

Marking as 5.6 release milestone.

by warmerdam, 14 years ago

Attachment: extent.patch added

Patch to fix minx/maxx/miny/maxy when nonsquare mode in effect, not suitable final patch though.

comment:3 by warmerdam, 14 years ago

Status: newassigned

I have attached a preliminary patch that corrects this case, but it seems there is lots more code right after this which uses map->extent without care for non-square mode, so I don't see this as a final solution.

I'm rather worried now about breaking stuff if too many changes are made in this area. Waiting for some feedback from Steve or others.

comment:4 by sdlime, 14 years ago

Tom, did you try the rawext template tags in this context? They reference RawExt which was intended to preserve the original extent before any adjusting is done for drawing etc... and should be stable regardless of querymap size and shape. Question I would have is the raw extent preserved in the WxS calls... I bet not. Patch would involve doing just that.

We should probably be more explicit in keeping query and drawing extents separate.

Steve

comment:5 by sdlime, 14 years ago

Actually thinking about this I have a better idea. The new queryObj encompasses all possible query params. So, for all CGI and OGC services it stores the last query done (mode, type, spatial elements, etc...). So we could use map->query.rect to populate the rawext tags, or I could add a [qyext] tag or something like to be more explicit. Thoughts?

Steve

comment:6 by tomkralidis, 14 years ago

Steve: when I try rawext, I get -1, -1, -1, -1 (which, coincidentally, was an issue in #2679). Any other suggestions?

comment:7 by sdlime, 14 years ago

Ok, I guess I'm confused as you could probably tell from my last two comments. It turns out that the larger template processing code wasn't trapping an error when generating the query map and associated images and blew silently through them. Somewhere the extent gets changed after that and I've not tracked that down yet. The error is:

<?xml version='1.0' encoding="ISO-8859-1" standalone="no" ?>
<!DOCTYPE ServiceExceptionReport SYSTEM "http://schemas.opengis.net/wms/1.1.1/exception_1_1_1.dtd">
<ServiceExceptionReport version="1.1.1">
<ServiceException>
msDrawMap(): Image handling error. Failed to draw layer named &#39;land_shallow_topo_2048&#39;.
msDrawQueryLayer(): Query error. Unable to draw raster layers (such as land_shallow_topo_2048) as part of a query result.
</ServiceException>
</ServiceExceptionReport>

Basically you can't draw raster query results. That's nothing new (I didn't put that exception in place). Whether we should throw an error or do something else is another matter. My conclusion at this point is that the test is invalid with a query map.

Steve

comment:8 by sdlime, 14 years ago

The munging of the extent is happening in msPrepareImage() which is called from msDrawMap()... Should a query map referenced in a template be expected to use non-square pixels? I'd say no since that process has nothing to do with the WMS spec.

-Steve

in reply to:  7 comment:9 by tomkralidis, 14 years ago

Replying to sdlime:

Ok, I guess I'm confused as you could probably tell from my last two comments. It turns out that the larger template processing code wasn't trapping an error when generating the query map and associated images and blew silently through them. Somewhere the extent gets changed after that and I've not tracked that down yet. The error is:

<?xml version='1.0' encoding="ISO-8859-1" standalone="no" ?>
<!DOCTYPE ServiceExceptionReport SYSTEM "http://schemas.opengis.net/wms/1.1.1/exception_1_1_1.dtd">
<ServiceExceptionReport version="1.1.1">
<ServiceException>
msDrawMap(): Image handling error. Failed to draw layer named &#39;land_shallow_topo_2048&#39;.
msDrawQueryLayer(): Query error. Unable to draw raster layers (such as land_shallow_topo_2048) as part of a query result.
</ServiceException>
</ServiceExceptionReport>

Steve: how did you get to this error?

Basically you can't draw raster query results. That's nothing new (I didn't put that exception in place). Whether we should throw an error or do something else is another matter. My conclusion at this point is that the test is invalid with a query map.

This used to work before. Having said this, doing the same GetFeatureInfo but asking for GML instead returns an extent in the GML response. I know the result of the GetFeatureInfo HTML in this case is more CGI/template-ish, though, but it still originates from an OGC:WMS request.

comment:10 by sdlime, 14 years ago

Hi Tom: I got the error by properly trapping image drawing errors from msGenerateImage() in msReturnTemplateQuery(). I've not committed that change yet.

Your template *should* work but not for raster layers which can't be used in a query map. So I see two problems:

1) What to do with raster images in query map context? Could throw an error like we do now. Could draw normally. Could write a msRasterDrawQuery() function and use that. For 5.6 I'd leave the error in place...

2) In cases where a query map is legit (i.e. with vector layers) we'd need to decide if that map should use non-square pixels or not. I need to track down the extent munging and how that's happening to tell you what the current behavior is.

Steve

comment:11 by sdlime, 14 years ago

Tom: I should clarify it's not the template that's the problem it's the mapfile with query map STATUS ON... Turn that off and the template should process as expected. I tried that locally and results seem more reasonable.

Steve

comment:12 by warmerdam, 14 years ago

Whew, I'm pretty confused about all this. One thing I don't understand is why calling WMS GetFeatureInfo results in a msDrawQueryLayer() call. Is this used even for non-image results?

I put the error in for this a while ago because it did not seem to make sense to do this, and it caused other problems further down, but if this is the function that "draws" query results using gml or html templating then I should remove that error and dig into the underlying issue.

I'd rather not create a lot more custom raster cases if avoidable.

comment:13 by sdlime, 14 years ago

Hi Frank: When you return a template there is a check to see if there's a query map that also needs to be created. This is done so that with one call you can create the template output and all the images (map, scalebar, etc...). That's how we end up in msDrawQueryLayer(). Personally I'd just turn the query map off or change the type to normal for that test. The error is appropriate and really only applies when trying to draw certain types of query maps. I'm more curious how a query map works with vector data in a templated getInfo request.

Steve

comment:14 by dmorissette, 14 years ago

Cc: dmorissette added

Sounds like this last error is related to #1842...

in reply to:  14 comment:15 by tomkralidis, 14 years ago

Replying to dmorissette:

Sounds like this last error is related to #1842...

Looks like it (see my comment there)

Note: See TracTickets for help on using tickets.