[gdal-dev] GeoTransform confusion

[Ari Jolma]

Simon,

If you set the configuration option GTIFF_POINT_GEO_IGNORE to "TRUE" 
instead of the default "FALSE" the offset will not happen.

I've tested this and it works. The configuration option needs to be set 
in code, it is not a GTiff creation option.

I'm not quite sure why you need to do that. Anyway it happens when the 
destination geotiff is created and its fields are set. The 
geotransformation of the geotiff file are set indirectly using 
geotiepoints using the geotransformation of the source (which is correct).

Ari

On 19.11.2015 10:24, Simon Lyngby Kokkendorff wrote:
> Basically it seems to be an issue with interpreting "center" 
> directives when doing the gdal_translate. Consider:
>
> ncols 2
> nrows 2
> xllcenter 0.0
> yllcenter 0.0
> cellsize 1.0
> nodata_value -999
> 2 2
> 2 2
>
> gdalinfo on this file, will give the expected GeoTransform:
>
> In [2]: ds = gdal.Open("center.asc")
>
> In [3]: ds.GetGeoTransform()
> Out[3]: (-0.5, 1.0, 0.0, 1.5, 0.0, -1.0)
>
> Seems OK to me.
>
> If I then do a gdal_translate: gdal_translate center.asc center.tif, I 
> get another interpretation:
>
> In [4]: ds = gdal.Open("center.tif")
>
> In [5]: ds.GetGeoTransform()
> Out[5]: (0.0, 1.0, 0.0, 1.0, 0.0, -1.0)
>
> And, if I do a roundtrip: gdal_translate -of AAIGRID center.tif 
> center_back.asc, I get:
> ncols        2
> nrows        2
> xllcorner    0.000000000000
> yllcorner    -1.000000000000
> cellsize     1.000000000000
> NODATA_value -999
>  2 2
>  2 2
>
> Which is definitely not the same GeoTransform as my input center.asc, 
> but shifted half a cellsize from what I would expect...
>
> In [6]: ds = gdal.Open("center_back.asc")
>
> In [7]: ds.GetGeoTransform()
> Out[7]: (0.0, 1.0, 0.0, 1.0, 0.0, -1.0)
>
>
>
> GDAL version:
> GDAL 1.11.2, released 2015/02/10
>
> Cheers,
> Simon
>
>
> On Wed, Nov 18, 2015 at 9:38 PM, Simon Lyngby Kokkendorff 
> <silyko at gmail.com <mailto:silyko at gmail.com>> wrote:
>
>     Hi List,
>
>       I have a geoid in AAIGRID-format, with the following header:
>
>     ncols 1001
>     nrows 731
>     xllcenter 400000.0
>     yllcenter 6045000.0
>     cellsize 500.0
>     NODATA_value 9999
>
>     GDAL will read this just fine, and report:
>
>     Driver: AAIGrid/Arc/Info ASCII Grid
>     Files: dkgeoid13b.utm32
>     Size is 1001, 731
>     Coordinate System is `'
>     Origin = (399750.000000000000000,6410250.000000000000000)
>     Pixel Size = (500.000000000000000,-500.000000000000000)
>     Metadata:
>       AREA_OR_POINT=Point
>     Corner Coordinates:
>     Upper Left  (  399750.000, 6410250.000)
>     Lower Left  (  399750.000, 6044750.000)
>     Upper Right (  900250.000, 6410250.000)
>     Lower Right (  900250.000, 6044750.000)
>     Center      (  650000.000, 6227500.000)
>     Band 1 Block=1001x1 Type=Float32, ColorInterp=Undefined
>       NoData Value=9999
>
>     As expected, the upper left corner is shifted half a pixel. It is
>     my understanding, that GDAL (GetGeoTransform) always uses the
>     xulcorner, yulcorner (pixel) interpretation. However, I was
>     suprised to see that after a
>
>     gdal_translate dkgeoid13b.utm32 hello.tif,  I get:
>
>     >gdalinfo hello.tif
>     Driver: GTiff/GeoTIFF
>     Files: hej.tif
>     Size is 1001, 731
>     Coordinate System is `'
>     Origin = (400000.000000000000000,6410000.000000000000000)
>     Pixel Size = (500.000000000000000,-500.000000000000000)
>     Image Structure Metadata:
>       INTERLEAVE=BAND
>     Corner Coordinates:
>     Upper Left  (  400000.000, 6410000.000)
>     Lower Left  (  400000.000, 6044500.000)
>     Upper Right (  900500.000, 6410000.000)
>     Lower Right (  900500.000, 6044500.000)
>     Center      (  650250.000, 6227250.000)
>     Band 1 Block=1001x2 Type=Float32, ColorInterp=Gray
>       NoData Value=99
>
>     The GeoTransform is not shifted half a pixel, and is not the same
>     as the AAIGRID i ran gdal_translate on?? So, I would have to
>     interpret now the GeoTransform as xulcenter and yulcenter. This
>     came as a suprise, and led to some bugs in our processing software.
>
>     Is this to be expected??
>
>     Cheers,
>     Simon Kokkendorff
>
>
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20151119/653d0db3/attachment-0001.html>