Ticket #1935 (closed defect: fixed)

Opened 8 months ago

Last modified 4 months ago

GDAL ignores the calibration data when the ul,lr corner is (0,0)

Reported by: jcrepetto Assigned to: mloskot
Priority: high Milestone: 1.5.1
Component: GDAL_Raster Version: 1.4.2
Severity: major Keywords: ecw
Cc: warmerdam

Description

I have downloaded a bitmap file of the world (http://veimages.gsfc.nasa.gov//2433/land_shallow_topo_2048.tif)

I have translated the south-earth quarter of this map to ECW :

gdal_translate -of ECW -co TARGET=88% -co DATUM=WGS84 -co PROJ=GEODETIC -a_ullr 0 0 180 -90 -srcwin 1024 512 1024 512 land_shallow_topo_2048.tif south_east.ecw

The ECW file is correct. But GDAL fails to read the calibration data (origin and pixel size) :

$ gdalinfo south_east.ecw 

Driver: ECW/ERMapper Compressed Wavelets
Size is 1024, 512
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9108"]],
    AXIS["Lat",NORTH],
    AXIS["Long",EAST],
    AUTHORITY["EPSG","4326"]]
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0,  512.0)
Upper Right ( 1024.0,    0.0)
Lower Right ( 1024.0,  512.0)
Center      (  512.0,  256.0)
Band 1 Block=1024x1 Type=Byte, ColorInterp=Red
  Overviews: arbitrary
Band 2 Block=1024x1 Type=Byte, ColorInterp=Green
  Overviews: arbitrary
Band 3 Block=1024x1 Type=Byte, ColorInterp=Blue
  Overviews: arbitrary

Patch proposal (for GDAL 1.4.2): 

--- frmts/ecw/ecwdataset.cpp.orig	2007-10-24 11:35:44.000000000 +0200
+++ frmts/ecw/ecwdataset.cpp	2007-10-24 11:41:59.000000000 +0200
@@ -1539,9 +1539,9 @@
 
     if( psFileInfo->fOriginX != 0.0 
         || psFileInfo->fOriginY != 0.0 
-        && (psFileInfo->fCellIncrementX != 0.0 && 
+        || (psFileInfo->fCellIncrementX != 0.0 && 
             psFileInfo->fCellIncrementX != 1.0)
-        && (psFileInfo->fCellIncrementY != 0.0 && 
+        || (psFileInfo->fCellIncrementY != 0.0 && 
             psFileInfo->fCellIncrementY != 1.0) )
     {
         bGeoTransformValid = TRUE;

BTW, there may be a similar bug in other drivers, for example the TIFF driver (please read <http://lists.maptools.org/pipermail/gdal-dev/2007-July/013497.html>). The source code of the other drivers should be reviewed.

Change History

10/25/07 09:38:08 changed by warmerdam

  • keywords set to ecw.
  • owner changed from warmerdam to mloskot.
  • cc set to warmerdam.

Mateusz,

Could you look into this? The only scenario that should be treated as not a valid geotransform is an origin at 0,0 and an increment of 1/1.

10/29/07 08:15:16 changed by mloskot

  • status changed from new to assigned.

Frank,

This ticket has been omitted for 1.4.3, probably because unintentionally it's not assigned to any milestone. Should it be assigned to 1.4.3?

10/29/07 09:26:27 changed by warmerdam

This was deliberately not request in 1.4. The problem is relatively minor, and the risk of screwing stuff up is significant if there is an unexpected side effect to a change.

10/29/07 09:27:50 changed by warmerdam

  • milestone set to 1.5.0.

02/06/08 11:53:26 changed by warmerdam

  • priority changed from normal to high.

Boosting priority at the request of Jean-Claude Repetto.

02/06/08 11:53:43 changed by warmerdam

  • component changed from default to GDAL_Raster.

03/14/08 10:15:08 changed by warmerdam

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

Agreed, patch applied in trunk (r14008) and 1.5 branch (r14009) just in time for 1.5.1RC2.

I have not created any regression test for this issue, nor actually tried it out. I'm applying the code change based on just a visual review.