Opened 13 years ago
Closed 9 years ago
#3986 closed enhancement (wontfix)
gdal_translate: XYZ driver flips image vertically
Reported by: | hkohr | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | default | Version: | 1.8.0 |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
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
Attachments (3)
Change History (9)
by , 13 years ago
Attachment: | test_tin.tiff added |
---|
by , 13 years ago
Attachment: | test_xyz.tiff added |
---|
by , 13 years ago
Attachment: | hillshade.tiff added |
---|
comment:1 by , 13 years ago
Description: | modified (diff) |
---|
comment:2 by , 13 years ago
Milestone: | → 1.8.1 |
---|
comment:3 by , 13 years ago
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.
comment:4 by , 13 years ago
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).
comment:5 by , 13 years ago
Milestone: | 1.8.1 |
---|---|
Type: | defect → enhancement |
comment:6 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
Hillshading image from the original dataset