Opened 10 years ago
Closed 10 years ago
#5493 closed defect (fixed)
ERMapper ERS RegistrationCellX/Y bug
Reported by: | wilsonwaters | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.11.1 |
Component: | GDAL_Raster | Version: | 1.11.0 |
Severity: | normal | Keywords: | ERS, ERMapper, RegistrationCellX, RegistrationCellY |
Cc: |
Description
Hi,
We had an issue with the ERS driver where coordinates were incorrect after updating an ers file. The original file contains specific RegistrationCellX/Y values (see attachment orig.ers). After opening and closing in GDAL the file contains updated Eastings/Northings AND the original RegistrationCellX/Y values.
I think what is happening is the driver works under the assumption the origin cell is always 0,0. When opening the file with RegistrationCellX/Y values the geo transform is modified to reflect an origin cell of 0,0. When the geo transform is written to file it still reflects an origin cell of 0,0 but the original RegistrationCellX/Y are also written.
The fix as far as I can tell is to update the RegistrationCellX/Y values in file to indicate the new origin (i.e. 0,0).
A patch is attached which works for us, but I'm not sure if I completely understand the problem so any advice would be good.
Thanks
Attachments (3)
Change History (6)
by , 10 years ago
by , 10 years ago
Updated ERS file with original RegistrationCellX/Y AND modified Eastings/Northings
comment:1 by , 10 years ago
I've moved your suggested code into SetGeoTransform() instead. Tell me if it works for you.
trunk r27418 "ERS: reset RasterInfo.RegistrationCellX/Y if setting a new geotransform on an updated .ers file (based on patch by wilsonwaters, #5493)"
comment:2 by , 10 years ago
I can confirm this change works on the simple test case we have.
Thanks again Even
comment:3 by , 10 years ago
Milestone: | → 1.11.1 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Backported in 1.11 in r27433
Original ERS file with RegistrationCellX/Y values