different behavior for gdallocationinfo using -l_srs and -geoloc ?

[kempenep]

Is it normal that gdallocationinfo behaves differently when using option -l_srs compared to -geoloc? I'm using the same coordinate system in both cases (no re-projection). The difference is a shift of one pixel (in x).

Example: My image is in coordinate system epsg:26915

gdalsrsinfo image.tif

PROJ.4 : '+proj=utm +zone=15 +datum=NAD83 +units=m +no_defs '

OGC WKT : PROJCS["NAD83 / UTM zone 15N",

GEOGCS["NAD83",

DATUM["North_American_Datum_1983",

SPHEROID["GRS 1980",6378137,298.2572221010042,

AUTHORITY["EPSG","7019"]],

AUTHORITY["EPSG","6269"]],

PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4269"]],

PROJECTIONTransverse_Mercator, PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",-93], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000], PARAMETER["false_northing",0], UNIT["metre",1,

AUTHORITY["EPSG","9001"]],

AUTHORITY["EPSG","26915"]]

However, the following two commands are not equivalent:

gdallocationinfo -b 1 -l_srs epsg:26915 image.tif 272755 3290298 Report:

Location: (783P,136L) Band 1:

Value: 2448

as opposed to

gdallocationinfo -b 1 -geoloc image.tif 272755 3290298 Report:

Location: (784P,136L) Band 1:

Value: 2620

The problem seems to be the case when X and Y are located on the pixel edges. To reproduce this behavior, you could query the location info of the lower right corner of the upper left pixel of an arbitrary (georeferenced) image. The two commands result in

Location: (0P,1L) and Location: (1P,0L) respectively

I would have expected these two commands would be equivalent, similar to the cases -wgs84 and -l_srs epsg:4326 (which are indeed equivalent)

I am using GDAL 1.9.2 on a Linux machine (Ubuntu 12.04), but the same behavior occcurs with GDAL 1.10

[Even Rouault]

Fixed by trunk r26274 "OGRProj4CT: avoid using proj when the 2 projections are actually identical (#5188)"

This was due to rounding errors when converting between 2 identical projections. The above fix should avoid those errors.