Opened 16 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


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)

gdal-ers-geotransform.patch (1.3 KB ) - added by agf 16 years ago.

Download all attachments as: .zip

Change History (5)

by agf, 16 years ago

Attachment: gdal-ers-geotransform.patch added

comment:1 by keithmoss, 15 years ago


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.

comment:2 by keithmoss, 15 years ago

Version: unspecified1.6.1

comment:3 by Even Rouault, 15 years ago

This is a duplicate of #3056

comment:4 by Even Rouault, 11 years ago

Resolution: duplicate
Status: newclosed

Closing as duplicate of #5075

Note: See TracTickets for help on using tickets.