Ticket #1944 (closed defect: fixed)

Opened 2 years ago

Last modified 10 months ago

Raster Reprojection Sometimes Very Slow

Reported by: warmerdam Assigned to: warmerdam
Priority: high Milestone:
Component: GDAL Support Version: 5.0
Severity: normal Keywords:
Cc: rouault, dmorissette

Description (Last modified by 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)

Attachments

rd.map (295 bytes) - added by fwarmerdam on 10/20/06 14:59:51.
test map
mercator.png (185.5 kB) - added by fwarmerdam on 10/20/06 15:00:59.
input raster file for use with test map

Change History

10/20/06 14:59:51 changed by fwarmerdam

  • attachment rd.map added.

test map

10/20/06 15:00:59 changed by fwarmerdam

  • attachment mercator.png added.

input raster file for use with test map

10/20/06 15:09:03 changed by fwarmerdam

  • status changed from new to assigned.
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.

10/20/06 15:26:14 changed by fwarmerdam

  • status changed from assigned to closed.
  • resolution set to fixed.
Patch now applied in 4.10 branch and cvs head.

09/23/07 11:09:54 changed by warmerdam

  • status changed from closed to reopened.
  • cc set to rouault, dmorissette.
  • resolution deleted.
  • description changed.

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.

09/23/07 11:16:29 changed by warmerdam

  • status changed from reopened to closed.
  • resolution set to fixed.

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

09/23/07 11:39:34 changed by warmerdam

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

HISTORY.TXT fixed up.