I need to convert a bunch of xyz tiles in a folder into a single GeoTIFF file using GDAL on Ubuntu 22.04.1 (CLI).

I first tried to use gdal_translate -if XYZ -of GTIFF *.xyz test.tif on a bunch of input .xyz tiles, but I faced the following error:

ERROR 6: Too many command options 'DTM1UTM_25050_53740.xyz'

So I tried to build a VRT first:

$ ls *.xyz > input_files.txt
$ gdalbuildvrt -input_file_list input_files.txt output_dtm.vrt

But this raises one warning per input .xyz file, e.g. as follows:

Warning 1: gdalbuildvrt does not support positive NS resolution. Skipping DTM1UTM_25050_53740.xyz
More than 1000 errors or warnings have been reported. No more will be reported from now.
.80...90...100 - done.

And no GeoTIFF file was created.


How could I avoid this warning and build the GeoTIFF file properly?

This is what `gdalinfo` gives on a single tile:
$ gdalinfo DTMUTM_25050_53740.xyz
Driver: XYZ/ASCII Gridded XYZ
Files: DTM1UTM_25050_53740.xyz
Size is 1001, 1001
Origin = (25049.500000000000000,53739.500000000000000)
Pixel Size = (1.000000000000000,1.000000000000000)
Corner Coordinates:
Upper Left  (  25050.500, 53739.500) 
Lower Left  (  25050.500, 54740.500) 
Upper Right (  26050.500, 53739.500) 
Lower Right (  26050.500, 54740.500) 
Center      (  25550.000, 54240.000) 
Band 1 Block=1001x1 Type=Float32, ColorInterp=Undefined
  Min=289.770 Max=2211.350

Tiles are given in EPSG:25832 according to an .xml sidecar file.

It seems that the value of the "Upper" y-coordinate is lower than the "Lower" y-coordinate, which is indeed not what one would expect with a right-hand rule XY coordinate frame!

Maybe there is a simple 'invert y-axis' conversion to revert those values so that they become decreasing downwards / increasing upwards?

Version info:

OS: Ubuntu "22.04.1 LTS (Jammy Jellyfish)"

$ gdalinfo --version
GDAL 3.7.0dev-52baae270831bca68d751ce37f5e9f9c9c76a70d, released 2022/12/16
  • 2
    Usually you would see Pixel Size = (1.000000000000000,-1.000000000000000) so these seem to have been produced "wrong". Where did you get them from
    – Ian Turton
    Jan 19, 2023 at 16:56
  • Hmm, indeed... I have been given these tiles by a a third party german institution. This "ASCII gridded XYZ" file format isn't standardized is it? Jan 19, 2023 at 17:39

2 Answers 2


From https://gdal.org/drivers/raster/xyz.html#raster-xyz

For a same Y coordinate value, the lines in the dataset must be organized by increasing X values. The value of the Y coordinate can increase or decrease however.

So the kind of XYZ file that you have is good for the GDAL XYZ driver. However, the gdalbuildvrt utility does not support some sort of GeoTransforms as can be seen from the source code https://github.com/OSGeo/gdal/blob/master/apps/gdalbuildvrt_lib.cpp#L543.

 if (bGotGeoTransform)
        if (padfGeoTransform[GEOTRSFRM_ROTATION_PARAM1] != 0 ||
            padfGeoTransform[GEOTRSFRM_ROTATION_PARAM2] != 0)
            return "gdalbuildvrt does not support rotated geo transforms.";
        if (padfGeoTransform[GEOTRSFRM_NS_RES] >= 0)
            return "gdalbuildvrt does not support positive NS resolution.";

I would try if gdal_merge https://gdal.org/programs/gdal_merge.html would work for those files. If it does not work and there is a need to do the process just once then I would just convert all the source images into north-up GeoTIFFs with gdalwarp first and continue with gdalbuildvrt.


So if I understand correctly the part of the gdalbuildvrt source code that @user30184 quoted in his answer, it's only a matter of column ordering in the XYZ file, especially the second one, holding the y-coordinates.

Therefore, this small bash script should do the job:


cd "/path/to/xyz/parent/dir/"

mkdir fix

for file in "*.xyz;
    echo "Processing ${file}";
    sort -gk2r,2r -gk1 "${file}" -o "fix/${file}";

Apparently, after that, the pixel size value reported by gdalinfo seems correct:

$ gdalinfo fix/DTMUTM_25050_53740.xyz
Driver: XYZ/ASCII Gridded XYZ
Files: fix/DTM1UTM_25050_53740.xyz
Size is 1001, 1001
Origin = (25049.500000000000000,54740.500000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Corner Coordinates:
Upper Left  (  25050.500, 54740.500) 
Lower Left  (  25050.500, 53739.500) 
Upper Right (  26050.500, 54740.500) 
Lower Right (  26050.500, 53739.500) 
Center      (  25550.000, 54240.000) 
Band 1 Block=1001x1 Type=Float32, ColorInterp=Undefined
  Min=289.770 Max=2211.350

and indeed, gdalbuildvrt now stopped complaining when used on those fixed files.

  • 2
    There was nothing wrong with the original pixel size per se. Positive pixel size means that the rows in the raster are increasing the y coordinate. That is the case when the first cell of data is at the lower left corner. It is much more common that the first cell is at the top left corner and GDAL does not handle the lower left case everywhere. Mostly it does because lower left is not so rare. Most NetCDF files are written in lower left first. But you did find a pretty good workaround for you gdalbuildvrt problem.
    – user30184
    Jan 20, 2023 at 9:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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