Thanks Ari,
I wasn't aware of that. Naively assumed that GDAL would just keep the
geotransform in a gdal_translate, no matter what. Good to know, thanks!
Cheers,
SImon
On Thu, Nov 19, 2015 at 10:03 AM, Ari Jolma <ari.jo...@gmail.com> wrote:
> 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 <
> <sil...@gmail.com>sil...@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
> listgdal-dev@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
