#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 |
Cc: |
Description
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
Change History (2)
comment:1 by , 11 years ago
Component: | Utilities → OGR_SRS |
---|---|
Milestone: | → 2.0 |
Resolution: | → fixed |
Status: | new → closed |
comment:2 by , 10 years ago
Milestone: | 2.0 → 1.11.0 |
---|
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.