Die Höhenlinien in meinen bisherigen Karten basierten auf SRTM-Daten und wurden mit Groundtruth ins OSM-Format umgewandelt. Das hat schon ganz gut funktioniert, hatte aber auch einige Nachteile. Um größre Karten zu erzeugen wie z.B. die von ganz Deutschland muss man riesige OSM-Dateien erzeugen und diese dann wieder mit dem mkgmap-Splitter aufteilen. Dabei entstehen zum Teil massive Artefakte, wenn man die extrem langen Ways nicht vorher in kleinere Teile zerlegt.

Außerdem beruht die Berechnung der Höhenlinien aus den Stützpunkten in den SRTM-HGT-Dateien immer auf linearer Interpolation, mit Splines würde sich wesentlich besser Qualität erreichen lassen..

Mittlerweile gibt es höher auflösende (1") SRTMv3 Dateien, bei denen die Löcher in den Daten ausgebessert wurden, sowie Daten aus den europäischen LIDAR Messungen, die eine sehr gute Qualität haben.

Vor einiger Zeit bin ich dann auf das kleine Tool SRTM2OSM Perl gestoßen. Dieses Tool benutzt Gnuplot für die Berechnung der Höhenlinien, braucht aber leider als Input ASC-Dateien. Das hat mich dann inspiriert, den ganzen Prozess der Erzeugung von Höhenlinien neu aufzusetzen.

Als Datenquelle dienen HGT-Dateien mit 1" Auflösung, je nach Verfügbarkeit LiDAR oder SRTMv3. Diese liegen in Dateien von 1°x1° Größe vor.

Die Umwandlung der HGT-Datein in Höhenlinien erfolgt mit Gnuplot. Das hat den Vorteil, dass man die HGT-Dateien direkt einlesen kann, und man kann B-Spline Interpolation benutzen. Der Output von Gnuplot ist eine CNT-Datei, welche sich leicht mit ein bißchen Perl in OSM-Format umwandeln läßt. Der Nachteil ist, dass Gnuplot für die Bearbeitung einer Kachel ca. 6 GB RAM braucht.

In den meisten Fällen konnte ich die entstandenen OSM-Dateien direkt mit Mkgmap in Garmin-IMG-Dateien umwandeln. Im Hochgebirge klappt das nicht, da muss man mit dem Mkgmap-Splitter aufteilen.

Probleme mit Artefakten hatte ich weder an den Grenzen der 1°x1°-Kacheln noch nach dem Splitten, da mein Perl-Tool keine sehr langen Ways erzeugt.

 Hier ein kleiner Vergleich, zwei Screenshots aus QMapShack alt / neu:

Alt: SRTM, lineare Interpolation	Neu: LIDAR, B-Spline

Layer:	Download:	Md5-Prüfsumme:
Höhenlinien 100 m:	germany_lidar100_2206.zip germany_lidar100_2206.zip (computer42.de)	007883cda1fb2bdca17698c0eb5cb7c6
Höhenlinien 20 m:	germany_lidar20_2206.zip germany_lidar20_2206.zip (computer42.de)	554f6152fb02f603017f596f4d2b71fb
Höhenlinien 10 m:	germany_lidar10_2206.zip germany_lidar10_2206.zip (computer42.de)	d50c53f9e1c66c1f6e3bb046f4f797cc

Update 06/2022:

Die Höhenlinien wurden neu in Kartenkacheln aufgeteilt. Die Daten sind exakt die selben wie vorher. Es sind aber jetzt weniger Kartenkacheln um die Gefahr zu reduzieren, dass man die Obergrenze von darstellbaren Kacheln im GPS-Gerät (bei vielen Geräten 500 Stück) überschreitet.



This page in english:

The contour line layers in my maps were based on SRTM data and were coneverted into OSM format using Groundtruth. That worked quite weill but had a few disadvantages. For the creation of large maps like Germany I had to make huge OSM files and split them with the mkgmap splitter. This process creates many artefacts unless you split the extremely long way objects.

Another problem is that the calculation of the contour lines is done using linear interpolation between the SRTM data points. Using splines for this would improve the quality a lot.

Now there are higher resolution (1") SRTMv3 data, with improved error handling, and data from the european LIDAR missions, that have a very good quality.

Some time ago I came across the tool SRTM2OSM Perl. This program uses gnuplot for the calculation of the contour lines, but unfortunately it uses ASC data files as input. This inspired me to make a new attempt at creating contour lines.

I used HGT files as the data source with 1" resolution, LiDAR or SRTMv3 depending on availability. These data come in tiles which have a size of 1°x1°.

Conversion of the HGT files was done using gnuplot. This has the advantage that it can read the HGT data directly and it can use B-Spline interpolation for the contour line calculation.The output of gnuplot is a CNT file which can easily be converted into OSM format with a few lines of perl. One disadvantage is that gnuplot needs about 6 GB RAM for one tile.

Most of the 1° tiles could be converted into garmin IMG format with mkgmap directly. In the alpine regions this does not work and I had to split them with the mkgmap splitter.

I never encountered artefacts, neither at the border of the 1° tiles nore after splitting, because my perl tool does not create long way objects.

Here is a little comparison, two screenshots from QMapShack old / new:

Old: SRTM, lineare Interpolation	New: LIDAR, Bi-Spline

Layer:	Download:	MD5 Checksum:
Contour lines 100 m:	germany_lidar100_2206.zip germany_lidar100_2206.zip (computer42.de)	007883cda1fb2bdca17698c0eb5cb7c6
Contour lines 20 m:	germany_lidar20_2206.zip germany_lidar20_2206.zip (computer42.de)	554f6152fb02f603017f596f4d2b71fb
Contour lines 10 m:	germany_lidar10_2206.zip germany_lidar10_2206.zip (computer42.de)	d50c53f9e1c66c1f6e3bb046f4f797cc

Update 06/2022:

The contour maps have been resplit into bigger map tiles. The data is exactly as before. There are fewer map tiles to reduce the danger of hitting the limit of displayed tiles of the GPS device (500 tiles for many devices).