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)
Change History (16)
comment:1 by , 16 years ago
comment:2 by , 14 years ago
Cc: | removed |
---|---|
Milestone: | → 5.6 release |
Owner: | changed from | to
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 , 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 , 14 years ago
Status: | new → assigned |
---|
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 , 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 , 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 , 14 years ago
Steve: when I try rawext
, I get -1, -1, -1, -1 (which, coincidentally, was an issue in #2679). Any other suggestions?
follow-up: 9 comment:7 by , 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 'land_shallow_topo_2048'. 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 , 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
comment:9 by , 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 'land_shallow_topo_2048'. 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 , 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 , 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 , 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 , 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
follow-up: 15 comment:14 by , 14 years ago
Cc: | added |
---|
Sounds like this last error is related to #1842...
comment:15 by , 14 years ago
Replying to dmorissette:
Sounds like this last error is related to #1842...
Looks like it (see my comment there)
Some more info: msautotest/wxs/templates/query_header.html is used as the header for this output, which is where the issue occurs:
It looks as though the template processor is filling in minx/miny/maxx/maxy with QUERYMAP.SIZE instead of the bounds of the response.