I downloaded several DEMs for Bavaria as ASCII file from here: https://geodatenonline.bayern.de/geodatenonline/seiten/dgm_info
several of those files won ́t be loaded into QGIS. The error message is:
Invalid Data Source: D:/Geodaten/Bayern/ascii/52_549.asc is not a valid or recognized data source.
I looked into the file and by cutting, saving and testing it I can find the corrupt line but I cannot see what is wrong with it.
520050 5496650 392.28
520000 5496700 404.80
520050 5496700 387.88
520000 5496750 396.32
520000 5496800 385.74
520000 5496850 376.35
520600 5498150 448.26
520500 5498200 444.86
520550 5498200 447.19
520600 5498200 448.94
520650 5498200 450.19
Are there any tools or plugins which I can use to clean the file?
-
That's an xyz file not an ASCII fileIan Turton– Ian Turton2022年10月30日 15:22:11 +00:00Commented Oct 30, 2022 at 15:22
-
2This is an example of an XY Problem. It's unlikely that the ASCII is corrupt, it's just that it's not in the Esri raster ASCII format (there are an infinite number of potential ASCII formats, and scores of "standard" formats for ASCII, including CSV, pipe-delimited, and XYZ). Posting the data formatted with a bold line does not help identify the problem.Vince– Vince2022年10月30日 15:49:35 +00:00Commented Oct 30, 2022 at 15:49
2 Answers 2
It's confusing because some of the 50m ascii .txt files just work. This is because they are in the GDAL XYZ format. That is they have a point coordinate for every raster pixel (even if it's null/nodata) and are sorted correctly.
The ones that don't work are missing all the X Y Z values for the null/nodata values, i.e they only have points where there's data and QGIS/GDAL don't recognise them as rasters. They're not technically corrupt, though I presume the data provider has actually made an error and intended to provide gridded XYZ.
So to fix the ungridded ones, treat them as a point dataset in X, Y, Z format, not a raster. You don't need to remove any values, just generate a raster from the points.
Note the examples below use the 200m product, not the 50m product as you didn't specify you were using the 50m product so I downloaded the 200m data as it was smaller, but the process is the same for both resolutions, just substitute the appropriate resolution and extent values.
Option 1 - Use the QGIS gui
Import the data as a point layer using the Layer - Data Source Manager - Delimited Text, specifying field_1 as X, field_2 as Y and field_3 as Z with EPSG:25832 as Geometry CRS
Save the point layer as a shapefile or geopackage dataset (right-click the layer and select Export
Get the point dataset extents and calculate the extent of the raster, it must be min X & Y - 1/2 the cellsize and max X & Y + 1/2 the cell size. i.e for the 200m DEM points, the extent is (498200, 5235800), (855800, 5602000) so the extent of the raster needs to be (498100, 5235700), (855900, 5602100). The coordinates given here are (xmin, ymin), (xmax, ymax)
In the processing toolbox, use the Grid (Nearest neighbor) tool, use the new point shapefile or geopackage layer, set the radius parameters to 1 so only the nearest point in the cell is used to get the Z value (must be > 0), then add Additional command-line parameters
-tr cell_x_size cell_y_size -txe xmin xmax -tye ymin ymax
. In the 200m case this is-tr 200 200 -txe 498100 855900 -tye 5235700 5602100
calculated above.
Option 2 - Use the GDAL commandline tools ogr2ogr
and gdal_grid
:
ogr2ogr -a_srs EPSG:25832 -oo X_POSSIBLE_NAMES=field_1 -oo Y_POSSIBLE_NAMES=field_2 DGM200_UTM32.shp CSV:DGM200_UTM32.txt DGM200_UTM32
gdal_grid -l DGM200_UTM32 -a nearest:radius1=1.0:radius2=1.0:angle=0.0:nodata=-9999.0 -ot Float32 -of GTiff -co COMPRESS=LZW -tr 200 200 -txe 498100 855900 -tye 5235700 5602100 DGM200_UTM32.shp DGM200_UTM32.tif
Option 3 - use PDAL commandline pdal translate
tool with readers.text
and writers.gdal
:
pdal translate --readers.text.header="X Y Z" --writers.gdal.output_type=min --writers.gdal.resolution=200 --writers.gdal.gdalopts="COMPRESS=LZW" --writers.gdal.override_srs=EPSG:25832 --writers.gdal.bounds="([498100, 855900], [5235700,5602100])" DGM200_UTM32.txt DGM200_UTM32.tif
This is a XYZ raster format, which you can add in QGIS as a raster. Or, for much faster rendering, convert it to a GeoTIFF:
gdal_translate -a_srs EPSG:25832 DGM1_utm32_t01dgm_25832.txt DGM1_utm32_t01dgm_25832.tif
-
the DGM test data (at bottom of linked page) are certainly XYZ formats, and don't yield any error with gdalinfo (GDAL 3.5.0, released 2022年05月10日). Not sure where you found DGM200 from.Mike T– Mike T2022年10月31日 01:07:13 +00:00Commented Oct 31, 2022 at 1:07
-
I don't see any "200" or "free" products there, only samples of DGM1, DGM5 or DGM25.Mike T– Mike T2022年10月31日 02:17:08 +00:00Commented Oct 31, 2022 at 2:17
-
1Where it says DGM 50 OpenData (links to the 50 & 200m product, the OP is using the 50m product). The samples you based your answer on load fine in QGIS as ascii XYZ rasters. The 200m and several of the 50m .txt files aren't gridded, i.e. they only contain the data points, not the nodata points (sorted correctly as per the GDAL XYZ format). I've updated my answer to note this.user2856– user28562022年10月31日 03:03:25 +00:00Commented Oct 31, 2022 at 3:03