Opened 17 years ago

Closed 16 years ago

#1935 closed defect (fixed)

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

Reported by: jcrepetto Owned by: Mateusz Łoskot
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 (7)

comment:1 by warmerdam, 17 years ago

Cc: warmerdam added
Keywords: ecw added
Owner: changed from warmerdam to Mateusz Łoskot

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.

comment:2 by Mateusz Łoskot, 17 years ago

Status: newassigned

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?

comment:3 by warmerdam, 17 years ago

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.

comment:4 by warmerdam, 17 years ago

Milestone: 1.5.0

comment:5 by warmerdam, 16 years ago

Priority: normalhigh

Boosting priority at the request of Jean-Claude Repetto.

comment:6 by warmerdam, 16 years ago

Component: defaultGDAL_Raster

comment:7 by warmerdam, 16 years ago

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.