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 , 17 years ago
Cc: | added |
---|---|
Keywords: | ecw added |
Owner: | changed from | to
comment:2 by , 17 years ago
Status: | new → 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?
comment:3 by , 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 , 17 years ago
Milestone: | → 1.5.0 |
---|
comment:5 by , 16 years ago
Priority: | normal → high |
---|
Boosting priority at the request of Jean-Claude Repetto.
comment:6 by , 16 years ago
Component: | default → GDAL_Raster |
---|
comment:7 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.