gdal_translate: XYZ driver flips image vertically

[hkohr]

Using the XYZ driver directly and a detour via CSV import and interpolation produces different results: the XYZ flips the image vertically.

Steps to reproduce:

With XYZ driver

Statistics:

kohr@iam-ma-023 ~/dgm_test $ gdalinfo -stats -nomd test.xyz
Driver: XYZ/ASCII Gridded XYZ
Files: test.xyz
Size is 501, 501
Coordinate System is `'
Origin = (2585299.500000000000000,5457199.500000000000000)
Pixel Size = (1.000000000000000,1.000000000000000)
Corner Coordinates:
Upper Left  ( 2585299.500, 5457199.500) 
Lower Left  ( 2585299.500, 5457700.500) 
Upper Right ( 2585800.500, 5457199.500) 
Lower Right ( 2585800.500, 5457700.500) 
Center      ( 2585550.000, 5457450.000) 
Band 1 Block=501x1 Type=Float32, ColorInterp=Undefined
  Minimum=235.211, Maximum=355.767, Mean=286.486, StdDev=37.135

Translation to GeoTiff:

kohr@iam-ma-023 ~/dgm_test $ gdal_translate -of GTiff -ot byte -scale 235 356 test.xyz test_xyz.tiff

With gridded data

Using QGis -> CSV import -> interpolation -> output:test.tin

Statistics:

kohr@iam-ma-023 ~/dgm_test $ gdalinfo -stats -nomd test.tin 
Driver: AAIGrid/Arc/Info ASCII Grid
Files: test.tin
Size is 500, 500
Coordinate System is `'
Origin = (2585300.000000000000000,5457700.000000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Corner Coordinates:
Upper Left  ( 2585300.000, 5457700.000) 
Lower Left  ( 2585300.000, 5457200.000) 
Upper Right ( 2585800.000, 5457700.000) 
Lower Right ( 2585800.000, 5457200.000) 
Center      ( 2585550.000, 5457450.000) 
Band 1 Block=500x1 Type=Float32, ColorInterp=Undefined
  Minimum=235.260, Maximum=355.607, Mean=286.440, StdDev=37.055
  NoData Value=-9999

Translation to GeoTiff:

kohr@iam-ma-023 ~/dgm_test $ gdal_translate -of GTiff -ot byte -scale 235 356 test.tin test_tin.tiff

[hkohr]

Hillshading image from the original dataset

[Even Rouault]

I think the XYZ driver behaves consistently with the data you've provided. I suspect that your test.xyz has increasing y values. Which means that the lines at the beginning of the file correspond to the data at the "bottom" of the image. The driver takes that correctly into account since it reports a positive pixel height, whereas usually, for most image formats, pixel heights are negative to reflect that the scanlines in the files are from top to bottom of image.

I suspect that your image viewer doesn't handle correctly positive pixel height (if it is a regular image viewer, it certainly does not. if it is a geo-enabled viewer, it should), so you see it reversed.

In addition of gdal_translat'ing, you could use gdalwarp (before or after the gdal_translate) that would restore the image in the usual top-to-bottom order. I've just tried it successfully on a simple example.

Now, perhaps the XYZ driver could be improved to flip the data on-the-fly in this situation and present it to the GDAL user as if the lines were organized from top to bottom, but I'm not sure if it is really appropriate to do so.

[hkohr]

You're right, the data has increasing y values, and if I load the tiff into QGis, for instance, it is displayed correctly. And gdalwarp does the job, thanks for the hint.

I'm not sure if it would be better or not to flip the image on-the-fly. Depending on the implementation it might be more efficient for an image viewer not having to rearrange the image.

Of course a proper GTiff viewer should be able to display the data correctly, but there is "stupid" software out there which only has a simple GeoTiff import functionality not checking for positive or negative pixel height (e.g. map drawing software).

[Jukka Rahkonen]

Nothing wrong in GDAL, easy to re-organize with gdalwarp, works in GDAL based programs like QGIS and it feels unlikely that anyone would be willing to code so seldom needed vertical flip option for fun.