6

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). enter image description here

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

  • 2
    It would help if you could point to a sample dataset that is online somewhere. – AndreJ May 6 '17 at 5:27
  • 1
    Add also gdalinfo report to your question. – user30184 May 6 '17 at 8:13
  • Thanks for the suggestion to examine gdalinfo. This allowed me to see that the real issue here is a disparity between QGIS Properties Metadata information and the actual file. I've posted the original XYZ data file, GDAL Info report and QGIS Metadata at the end of the post. Unfortunately, the slightly resized version QGIS reports in metadata appears to be what I'm working with in QGIS. – Lance May 6 '17 at 18:57
  • It appears this has been noticed in the past. In this bug report, they too started with rectangular pixels and QGIS restates these as squares changing both X and Y pixel dimensions as well as the total number of rows and columns. – Lance May 6 '17 at 19:11
4

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: enter image description here

warped import: enter image description here

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.