Raster Reprojection Sometimes Very Slow

[warmerdam]

The attached mapfile and data file with the command:

  shp2img -m rd.map -o out.png

takes far longer than it should. 

(as reported by Jan Hartmann)

[fwarmerdam]

test map

[fwarmerdam]

input raster file for use with test map

[fwarmerdam]

The problem turns out to be a logic error in the "approximate transformer"
in mapresample.c.  The problem is that if the first linear approximation
is not within the error threshold, then the logic would revert to exact
reprojection all along the line instead of using the approximate transformer
along halves of the line. 

The problem has presumably existed as long as mapserver has supported 
raster reprojection.

The patch looks like:
*** mapresample.c.~1.67.~	2006-03-15 15:31:18.000000000 -0500
--- mapresample.c	2006-10-20 14:51:55.447937048 -0400
***************
*** 1162,1169 ****
      if( dfError > psATInfo->dfMaxError )
      {
          bSuccess = 
!             psATInfo->pfnBaseTransformer( psATInfo->pBaseCBData, nMiddle, 
!                                           x, y, panSuccess );
              
          if( !bSuccess )
          {
--- 1162,1168 ----
      if( dfError > psATInfo->dfMaxError )
      {
          bSuccess = 
!             msApproxTransformer( psATInfo, nMiddle, x, y, panSuccess );
              
          if( !bSuccess )
          {
***************
*** 1173,1182 ****
          }
  
          bSuccess = 
!             psATInfo->pfnBaseTransformer( psATInfo->pBaseCBData, 
!                                           nPoints - nMiddle, 
!                                           x+nMiddle, y+nMiddle, 
!                                           panSuccess+nMiddle );
  
          if( !bSuccess )
          {
--- 1172,1179 ----
          }
  
          bSuccess = 
!             msApproxTransformer( psATInfo, nPoints - nMiddle, 
!                                  x+nMiddle, y+nMiddle, panSuccess+nMiddle );
  
          if( !bSuccess )
          {

I will apply it in 4.10 branch as well as cvs head.

[fwarmerdam]

Patch now applied in 4.10 branch and cvs head.

[warmerdam]

Unfortunately, it appears that I neglected to apply the actual code fix for this in 4.10 branch, even though I did add the note about fixing it in HISTORY.TXT, and now 4.10.3 has gone out.

I will apply the fix in 4.10 branch so if there is a 4.10.4 release (a bit iffy?) it will be there.

[warmerdam]

Fix applied in 4.10 branch as r6904. If there is a 4.10.4 release it should appear there.

[warmerdam]

Actually, it appears 1944 was never claimed fixed in 4.10.3, it was #2180 which was actually fixed.

HISTORY.TXT fixed up.