Ticket #1944 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

Raster Reprojection Sometimes Very Slow

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

Description (last modified by warmerdam) (diff)

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 Download (295 bytes) - added by fwarmerdam 7 years ago.
test map
mercator.png Download (185.5 KB) - added by fwarmerdam 7 years ago.
input raster file for use with test map

Change History

Changed 7 years ago by fwarmerdam

test map

Changed 7 years ago by fwarmerdam

input raster file for use with test map

Changed 7 years ago 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.

Changed 7 years ago by fwarmerdam

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

Changed 6 years ago by warmerdam

  • cc rouault, dmorissette added
  • status changed from closed to reopened
  • resolution fixed deleted
  • description modified (diff)

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.

Changed 6 years ago 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.

Changed 6 years ago 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.

Note: See TracTickets for help on using tickets.