projected raster bad in CGI query mode

[rich@…]

A reprojected raster image (one that is not in the same coordinate system as the
map file coordinate system) does not display correctly in CGI query modes.  In
other words, the reprojected imagery displays correctly in normal browse and map
modes, but when mode=itemquery or mode=itemnquery the image is rendered to a
tiny portion of the returned map. The two URLs below illustrate the problem:

Image displays correctly, mode=browse
http://www2.tetonwyo.org/mapserver/map.asp?imgext=2400431.649485+1426420.544234+2424419.896907+1444458.218653&mapext=shapes&mode=browse&zoomsize=2&template=tc.html&layers=Roads+ownership+Water+none+utm&zoomdir=1&imgxy=467+365&imgbox=467+365+633+475&map_size=645+485&MAP_IMAGETYPE=jpeg&java=on

Image displays incorrectly, mode=itemnquery
http://www2.tetonwyo.org/mapserver/map.asp?imgext=2417799.884440+1426516.837421+2423973.603932+1431159.091613&mapext=shapes&mode=itemnquery&zoomsize=2&template=tc.html&layers=Roads+ownership+Water+none+utm&zoomdir=0&imgxy=492+348&imgbox=492+348+492+348&qlayer=join_region_spatial&qitem=pidn&qstring=22-41-17-14-4-00-001&map_size=645+485&MAP_IMAGETYPE=jpeg&java=on

More info:
The "map.asp" in the URLs above is just a wrapper around mapserv.exe 4.6.1
I've tested with versions 4.8 and 4.10 on various Windows servers.
I've tested with imagery in a couple different coordinate systems.

[fwarmerdam]

Rich,

I can't see the result since there seems to be a requirement for some sort of
plugin I don't have. 

I would be willing to try and track this down if you could attach a raster 
file and mapfile and corresponding comandline arguments to mapserv to demonstrate
the problem.

[rich@…]

For folks that don't have Java enabled in their browser, you can change the URLs
to java=off (at the very end of the URLs I provided previously). 

Or you can remove the check from the Java box at the bottom of the page and do
something to force a re-submit (pan, zoo, etc.)

[sdlime]

So is this a problem with the query itself or the resulting query map?

Steve

BTW The second URL gives me a query error (no query layer defined).

[rich@…]

Sorry, I renamed the qlayer since I posted this bug.

The corrected URL is:

http://www2.tetonwyo.org/mapserver/map.asp?imgext=2417799.884440+1426516.837421+2423973.603932+1431159.091613&mapext=shapes&mode=itemnquery&zoomsize=2&template=tc.html&layers=Roads+ownership+Water+none+utm&zoomdir=0&imgxy=492+348&imgbox=492+348+492+348&qlayer=ownership_spatial&qitem=pidn&qstring=22-41-17-14-4-00-001&map_size=645+485&MAP_IMAGETYPE=jpeg&java=on

The problem is with the query result.

[sdlime]

Whoa, that's an interesting effect. So is the image I'm looking at a querymap 
then? If so then I'm suprised since rasters are handed off to the same 
processing steps if it's a query or regular map draw. Could you post the 
mapfile?

Steve

[rich@…]

map file

[rich@…]

Remember that this only happens when the raster is in a different coordinate
system than the map's system. So possibly the extent being passed to the raster
processor isn't in the correct system when mode=itemquery and/or mapext=shapes.

In my example, the map's coordinate system is in feet, and the raster's system
is in meters, but I think there's more going on that just feet/meters.

[sdlime]

Ok, the problem lies somewhere in msDrawQueryMap, consider this URL:

http://www2.tetonwyo.org/mapserver/map.asp?map_querymap_style=normal&imgext=2417799.884440+1426516.837421+2423973.603932+1431159.091613&mapext=shapes&mode=itemnquery&zoomsize=2&template=tc.html&layers=Roads+ownership+Water+none+utm&zoomdir=0&imgxy=492+348&imgbox=492+348+492+348&qlayer=ownership_spatial&qitem=pidn&qstring=22-41-17-14-4-00-001&map_size=645+485&MAP_IMAGETYPE=jpeg&java=off

I changed the querymap style to normal which in turn basically calls msDrawMap
instead. The problem is that there are big differences now between msDrawMap and
msDrawQueryMap. Folks update one and not the other (for example, msDrawQueryMap
doesn't include WMS layers). Easy to see how it happens since query maps were a
hack to begin with. 

I think the problem lies in the fact msDrawMap calls msApplyMapConfigOptions and
msPrepareImage while msDrawQueryMap tries to do all that crap on it's own.
Obviously it's missing something that msDrawRasterLayer needs. 

So, my suggestion would be to scrap msDrawQueryMap altogether and add a
parameter (querymap=MS_TRUE|MS_FALSE) to the msDrawMap signature to toggle use
of the QUERYMAP object. I don't think it would add much, if any overhead. The
changes would be:

1) reassign map size to the querymap size if querymap=true
2) use msDrawQueryLayer instead of msDrawLayer if querymap=true AND
querymap->type != NORMAL

The msDrawQueryLayer function looks up-to-date and rolls over to msDrawLayer
anyway if a layer doesn't have a result set. You'd only pay that small
performance hit with querymaps and you're doing that anyway.

In the end this would fix this bug and give us less code to maintain. A few
tweaks to two methods in mapscript (map->draw and map->drawQuery) (all behind
the scenes) would also be necessary (but trivial). I don't think an RFC is
necessary. CC'ing Dan for his opinion.

Rich, you're still welcome to pay for this. ;-) You can work around the
projection issue by changing the querymap type as I mentioned earlier, but
you'll loose the hilight.

Steve

[fwarmerdam]

I had no clue there was an msDrawQueryMap()!  Yes, I would say it would be
best if the draw query map functionality be merged into msDrawMap().

[rich@…]

I have a little bit of money in a project budget that I might be able to commit
merging msDrawQueryMap()and msDrawMap(). If any of you are interested, shoot me
an email.

[sdlime]

Frank, you're not alone!

- Steve

[dmorissette]

FYI there is bug 774 also discussing this.

[sdlime]

Ok, I committed a merge to CVS HEAD. Works fine when tested with the workshop
demo which has query map examples. For now I went with the extra parameter to
msDrawMap instead of auto detecting the presence of query results as mentioned
in bug 774. It's just more straight forward that way. 

Rich, is there any way you can test your specific problem against the CVS code?

I can backport to 4.10 if you would confirm things. 

Steve

[rich@…]

Steve,

I just did a quick test using the nightly CVS and it appears to work perfectly.
I would suggest that the status of this bug, and #1463 (which is the same bug)
be changed to 'resolved'. But I'm not comfortable enough with Bugzilla protocol
to change the status myself. Thanks for your work on this. And you got a mailing
address?

Rich

[sdlime]

Thanks for testing. Any objections to back porting to 4.10?

Steve

(Rich, I sent an address over the weekend from my home account)

[dmorissette]

9 files were modified in this fix, are we sure that there is no chance of
breaking anything in backporting to 4.10?

[fwarmerdam]

If the change is getting rid of msDrawQueryMap then I think this is a way too
extreme change to backport.  It is almost the definition of the sort of 
re-engineering that doesn't belong in a stable branch!

[sdlime]

It's a minor change but I can live with not backporting. Folks have been living 
with this bug for years so I can't imagine it's encountered much (you have to 
be re-projecting rasters). Marking as fixed.

Steve