Opened 15 years ago
Closed 11 years ago
#2612 closed defect (duplicate)
[PATCH] ERS georeferencing off by 1 pixel when RegistrationCell tags are used
Reported by: | agf | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL_Raster | Version: | 1.6.1 |
Severity: | normal | Keywords: | ers |
Cc: |
Description
Georeferencing is off by 1 pixel for ers files that include the RegistrationCellX
and RegistrationCellY
header tags, apparently due to incorrectly indexing pixels from 1 instead of 0.
Using the ers file attached to ticket 2598 as an example, part of the header is:
CellInfo Begin Xdimension = 0.025 Ydimension = 0.025 CellInfo End RegistrationCellX = 0 RegistrationCellY = 0 RegistrationCoord Begin Longitude = 143:35:46.500000000 Latitude = -39:22:52.500000108 RegistrationCoord End
and gdalinfo returns:
Pixel Size = (0.025000000000000,-0.025000000000000) Corner Coordinates: Upper Left ( 143.6212500, -39.4062500) (143d37'16.50"E, 39d24'22.50"S)
Since 143.62425 = 143deg35'46.5" + 0.025deg, the reference longitude according to gdalinfo has been shifted eastward by 1 pixel (0.025deg) and similarly the reference latitude has moved south by the same amount.
This appears to be due to GDAL indexing pixels from 1 when interpreting the header, whereas the ers format apparently indexes from zero (it's not exactly a formal spec, but this page mentions that the registration cell is indexed from zero).
After applying the attached patch, the bounds reported by gdalinfo (and the geotransform) match those from ArcGIS's ERS plugin.
When the registration pixel is (0,0), as in this file, the correct behavior can also be obtained by deleting the RegistrationCell
tags from the header.
Patch is against the 1.5 branch.
Attachments (1)
Change History (5)
by , 15 years ago
Attachment: | gdal-ers-geotransform.patch added |
---|
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Version: | unspecified → 1.6.1 |
---|
comment:4 by , 11 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Closing as duplicate of #5075
+1
I too would be interested in seeing this one get fixed.
I've run up against the same pixel shifting problem in working on an automated data cutting script using the gdal_translate.exe binary (1.6.0). I need to run it against a large pile of archival data, so any sort of manual correction of the registration info is out of the question.