#393 closed defect (fixed)
ECW, GetGeoTransform returns posetive fCellIncrementY
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL_Raster | Version: | unspecified |
Severity: | minor | Keywords: | ECW |
Cc: | gaopeng, rprinceley, Mateusz Łoskot |
Description (last modified by )
Trying to display some sample ECW datasets, using Mapserver/GDAL failed, but the ECW files worked with some mapInfo product using a .tab file with georefrence info. The problem was that the images was ignored due to a posetive fCellIncrementY returned from GetGeoTransform. The following fix, was done on the GDAL CVS version from 16 June 03. I added the following code to ECWDataset::GetGeoTransform, line 466 if (padfTransform[5] > 0.0) padfTransform[5] = -padfTransform[5]; And if (adfGeoTransform[5] > 0.0) adfGeoTransform[5] = -adfGeoTransform[5]; To GDALDataset *ECWCreateCopy, before line 671. The the problem was solved. I dont know if this is a problem in the ECW driver, or if the problem is caused by a malformed ECW georeferencing info.
Change History (13)
comment:2 by , 13 years ago
Description: | modified (diff) |
---|---|
Resolution: | invalid |
Status: | closed → reopened |
I reopen this ticket as we have many cases where fCellIncrementY has positive value. We have cases reported by the following offices in different regions:
GISTEC, SHARJAH ESRI KOREA INC, SEOUL ESRI CANADA LIMITED, TORONTO ESRI AUSTRALIA PTY LTD, BRISBANE LOCUS LTD, DEVONSHIRE (Bermuda)
I'd suggest the following fix, which should be safer:
adfGeoTransform[5] = -fabs(psFileInfo->fCellIncrementY);
comment:3 by , 13 years ago
Keywords: | ECW added |
---|---|
Priority: | low → normal |
Gao,
Can you provide a sample file? Do you have any idea why some files have a positive fCellIncrementY? I'd like to take the issue up with ERDAS to see if they have any advice.
comment:4 by , 13 years ago
I uploaded one sample at ftp://GDAL@ftp.esri.com/ECW/. I can get more if needed.
comment:5 by , 13 years ago
Cc: | added |
---|
comment:6 by , 13 years ago
I have examined the file, and unfortunately it is not practical to do any ground truthing to determine if flipping the sign of the y cell increment would give a proper result. I have emailed Erdas to see if they have any advice on the topic.
comment:7 by , 13 years ago
Here is my understanding of how Erdas Imagine use this parameter. If the ecw file is raw (no map-projection info), then fCellIncrementY is positive (i.e., pixelSize->height) If the ecw file has map-projection info, then fCellIncrementY is negative (i.e., -pixelSize->height)
Best regards! Haiyan Qu
comment:8 by , 13 years ago
Based on this, I'm going to apply the proposed patch. I can confirm that the file in question is RAW; however, it has an origin so it seems likely that it is in some coordinate system but the coordinate system is just not described in the file. I'm concerned that flipping the sign might still not place the file appropriate.
There is also a risk that this will screw up legitimately south up images though I can't say that I've knowingly encountered such a thing.
comment:9 by , 13 years ago
As I'm tentative about this fix, I have only placed it in trunk (r21598) so far. Do you need this in 1.6-esri?
comment:11 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:12 by , 8 years ago
Cc: | added |
---|