aspect ratio problem BBOX,HEIGHT,WIDTH

[tbonfort]

Reporter: dnadeau@pop600.gsfc.nasa.gov Date: 2006/09/07 - 20:34

Image are not render when WIDTH & HEIGHT have the same aspect ratio as the BBOX.

In these two examples, the only thing that changes is Height from 245 to 240
pixels.  The first renders fine, the second one does not render and returns a
blank image back.

I am accessing data with postGIS and the image is coming through a VRT file.

Denis

This QUERY "does" render properly.
export
QUERY_STRING="SERVICE=WMS&VERSION=1.1.1&REQUEST=Getmap&layers=TRMM_3B42RT_DAILY&BBOX=-180.125,-60,180,60&TIME=2006-09-06&HEIGHT=245&WIDTH=720"

./mapserv QUERY_STRING=$QUERY_STRING  > a.png

[Thu Sep  7 13:49:44 2006].293126 msWMSLoadGetMapParams(): enabling non-square
pixels.[Thu Sep  7 13:49:44 2006].299647 msDrawMap(): kicking into non-square
pixel preserving mode.[Thu Sep  7 13:49:44 2006].299739
msDrawRasterLayerLow(TRMM_3B42RT_DAILY): entering.
[Thu Sep  7 13:49:44 2006].377920 msResampleGDALToMap in effect: cellsize = 0.250000
[Thu Sep  7 13:49:44 2006].387510 msDrawGDAL(TRMM_3B42RT_DAILY): using
RAW_WINDOW=0 0 1440 480
[Thu Sep  7 13:49:45 2006].926105 msDrawGDAL(TRMM_3B42RT_DAILY): scaling to
8bit, src range=0,300
[Thu Sep  7 13:49:45 2006].966256 msDrawMap(): Layer 10 (TRMM_3B42RT_DAILY), 1.667s
[Thu Sep  7 13:49:45 2006].966359 msDrawMap(): Drawing Label Cache, 0.000s
[Thu Sep  7 13:49:45 2006].966384 msDrawMap() total time: 1.669s
g0dup05{dnadeau}[242]->

This QUERY does "not" render properly.

export
QUERY_STRING="SERVICE=WMS&VERSION=1.1.1&REQUEST=Getmap&layers=TRMM_3B42RT_DAILY&BBOX=-180.125,-60,180,60&TIME=2006-09-06&HEIGHT=120&WIDTH=720"

./mapserv QUERY_STRING=$QUERY_STRING  > a.png

[Thu Sep  7 13:54:16 2006].728620 msWMSLoadGetMapParams(): enabling non-square
pixels.[Thu Sep  7 13:54:16 2006].733815 msDrawMap(): kicking into non-square
pixel preserving mode.[Thu Sep  7 13:54:16 2006].733889
msDrawRasterLayerLow(TRMM_3B42RT_DAILY): entering.
[Thu Sep  7 13:54:16 2006].965495 msResampleGDALToMap in effect: cellsize = 0.250000
[Thu Sep  7 13:54:16 2006].974984 msDrawGDAL(TRMM_3B42RT_DAILY): using
RAW_WINDOW=0 1 1440 479
[Thu Sep  7 13:54:18 2006].516552 msDrawGDAL(TRMM_3B42RT_DAILY): scaling to
8bit, src range=0,300
[Thu Sep  7 13:54:18 2006].551444 msDrawMap(): Layer 10 (TRMM_3B42RT_DAILY), 1.818s
[Thu Sep  7 13:54:18 2006].551546 msDrawMap(): Drawing Label Cache, 0.000s
[Thu Sep  7 13:54:18 2006].551575 msDrawMap() total time: 1.819s

[tbonfort]

Author: dnadeau@pop600.gsfc.nasa.gov Date: 2006/09/08 - 18:28

Frank,

I created a tar file to reproduce this bug.  You have to set MAPSERV to your
path and run ./run_test.sh

Regards,
Denis

The recipients have 30 days from this date : 09-08-2006 to download the file(s)

Please give the following address to them:

https://webdrive.gsfc.nasa.gov/longauth/600/denis.nadeau/RQGaEoC39KUAACmy1ZE

Along with:

username = warmerda
password = warmerda

to enable them to download the files.

Thank you for using WebDrive!

[tbonfort]

Author: fwarmerdam Date: 2006/09/24 - 04:50

Denis, 

It seems the problem relates to 3B42RT_daily.2002.02.02.6.vrt
having a geotransform that is "upside down".  That is, where the
north edge is the bottom of the image. 

The "simple" case of MapServer logic cannot handle this properly and
it ends up drawing nothing.  But the "complex" case which goes through
the general resampling/reprojection logic can handle this.  This complex
case also gets used for non-square pixels. 

I have put some special logic in the code to address this case - basically
to force things through the complex case when the image is upsidedown (or
right-left flipped).  The fix should appear in the 4.10 RC1 to be released
this coming week.