Opened 18 years ago
Closed 18 years ago
#1904 closed defect (fixed)
aspect ratio problem BBOX,HEIGHT,WIDTH
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | WMS Server | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description
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
Change History (2)
comment:2 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
Note:
See TracTickets
for help on using tickets.