Importing XYZ ASCII Grid Data Into QGIS: Why does GDAL resize the raster?

Question

Question: Why does GDAL import of XYZ gridded data in QGIS modify the dimensions of a raster and can this be avoided?

I'm importing XYZ ASCII gridded data that conforms to GDAL XYZ Gridded Data Standard into QGIS v 2.18.7. The data set represented by the XYZ file has 30 X 30 dimensions where X,Y dimensions of each cell is 0.125 X 0.5 for a total dimension in cells of 240 X 60. X and Y coordinates start at 0.0625 and 0.25, so the outside edges of the cells should span from exactly 0 to 30.

Importing this data through Layer->Add Layer->Add RasterLayer, by drag and drop from the Browser Panel, directly from the OS file browser, or adding via the Georeferencer tool all perform the same task and seemingly import the data properly. However, instead of a 240 X 60 cell raster with 30 X 30 dimensions, these approaches produce a 175 X 175 cell raster with sides measuring 30.012325, and a square cell size of 0.171499.

If I take one of these slightly-off rasters and save it as a GTIFF, the properties within QGIS indicate it is the same, but holding a cursor over the file in an OS file browser window indicates it's 240 X 60, as it should be (see below).

Can someone explain what is going on here and how to avoid it?

Data Example Here

GDALInfo of original ASCII XYZ Grid File: Import_Test_Data.txt

QGIS Properties Metadata of ASCII XYZ Grid File: Import_Test_Data.txt

Answer 1

This seems to be a bug in QGIS, utilizing some odd behaviour of the gdalwarp utility. If gdalwarp does not like the input raster (in this case due to the y axis positive down), it creates a new raster with a square cell size by default.

On the command line, you can override this with

gdalwarp -tr 0.125 0.5 -s_srs EPSG:4326 -t_srs EPSG:4258 import_test_data.txt warped.tif

which gives an output corresponding to the points read as delimited text in QGIS:

Direct import:

warped import:

The gdalinfo output changes from

Driver: XYZ/ASCII Gridded XYZ
Files: Import_test_data.txt
Size is 240, 60
Coordinate System is `'
Origin = (0.000000000000000,0.000000000000000)
Pixel Size = (0.125000000000000,0.500000000000000)
Corner Coordinates:
Upper Left  (   0.0000000,   0.0000000)
Lower Left  (   0.0000000,  30.0000000)
Upper Right (  30.0000000,   0.0000000)
Lower Right (  30.0000000,  30.0000000)
Center      (  15.0000000,  15.0000000)
Band 1 Block=240x1 Type=Float32, ColorInterp=Undefined
  Min=-991.760 Max=3333.000

to:

Driver: GTiff/GeoTIFF
Files: warped.tif
Size is 240, 60
Coordinate System is:
GEOGCS["ETRS89",
    DATUM["European_Terrestrial_Reference_System_1989",
        SPHEROID["GRS 1980",6378137,298.2572221010042,
            AUTHORITY["EPSG","7019"]],
        TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6258"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4258"]]
Origin = (0.000000000000000,29.999999999999996)
Pixel Size = (0.125000000000000,-0.500000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (   0.0000000,  30.0000000) (  0d 0' 0.01"E, 30d 0' 0.00"N)
Lower Left  (   0.0000000,  -0.0000000) (  0d 0' 0.01"E,  0d 0' 0.00"S)
Upper Right (  30.0000000,  30.0000000) ( 30d 0' 0.00"E, 30d 0' 0.00"N)
Lower Right (  30.0000000,  -0.0000000) ( 30d 0' 0.00"E,  0d 0' 0.00"S)
Center      (  15.0000000,  15.0000000) ( 15d 0' 0.00"E, 15d 0' 0.00"N)
Band 1 Block=240x8 Type=Float32, ColorInterp=Gray

Note that the pixel size Y is now negative, and the coordinate origin has moved from Upper Left to Lower Left (where you would expect it in a North-up degree coordinate system).

---

Another choice is to load the data into LibreOffice Calc, and let it sort for column B decreasing, and column A increasing. Despite of http://www.gdal.org/frmt_xyz.html noting:

The value of the Y coordinate can increase or decrease however.

it should better decrease.