Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#5188 closed defect (fixed)

different behavior for gdallocationinfo using -l_srs and -geoloc ?

Reported by: kempenep Owned by: warmerdam
Priority: normal Milestone: 1.11.0
Component: OGR_SRS Version: 1.9.2
Severity: normal Keywords: gdallocationinfo


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",



SPHEROID["GRS 1980",6378137,298.2572221010042,



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,



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

Change History (2)

comment:1 by Even Rouault, 11 years ago

Component: UtilitiesOGR_SRS
Milestone: 2.0
Resolution: fixed
Status: newclosed

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.

comment:2 by Even Rouault, 10 years ago

Note: See TracTickets for help on using tickets.