Adresse des Updates zum Herunterladen: Auf meiner Seite unter Download. Oder auch direkt:
Für Zusi:
Update TransDEM 2.6.2+ - 2.6.6.1 (64bit)
Dies ist ein kostenloses Update, das die installierte Vollversion von 2.6.* voraussetzt. Achtet auf das richtige Update für Eure Installation, wenn Ihr über die Download-Seite geht: Zusi und 64 bit!
Das Update ist wieder kumulativ, d.h. Voraussetzung ist nur die Minimalversion, bei TransDEM 64 bit für Zusi "TransDEM 2.6.2" und höher. Welche exakte Version vorliegt, findet das Update dann heraus. Wenn für eine oder mehrere Dateien angezeigt wird, dass die bereits auf dem neusten Stand sind, so ist das nur eine Information, kein Fehler.
Das Update für Zusi funktioniert auch für Zusi3-Steam-Kunden.
TransDEM-Version 2.6.6.1
- Unterstützung für das Koordinatensystem DB_Ref der Deutschen Bahn (auf ETRS89 angepasste Gauß/Krüger-Potsdam-Projektion), EPSG 5682 - 5685 (bzw. 5832 – 5835).
- XYZ-Import
- Unterstützung für Gauß/Krüger-Daten mit vorangestelltem Meridianstreifen (Zone) im Ostwert.
- Temporäre Speicherung der über Dialog eingegebenen Projektionsparameter.
- Schätzwert für die Gitterweite auf der Basis der eingelesenen Daten.
- GeoTIFF-DEM
- GeoTIFF-DEMs, denen das Tag GEOKEYDIRECTORY fehlt, werden nicht länger abgewiesen, sondern als geogr. WGS84-Koordianten interpretiert. (Ermöglicht das Einlesen von indonesischen DEMNAS-Dateien.)
- Das nicht genormte, aber weit verbreitete Tag GDAL_NODATA wird ausgelesen. Bestimmt die Codierung für nicht vorhandene Werte.
Hintergrund zu den Neuerungen DB_REF und XYZ-Import
Als ich mit TransDEM vor 20 Jahren (!) anfing, hatte ich mich von Anfang an für das UTM-Koordinatensystem als natives System entschieden. Carsten hat das für Zusi3 dann später übernommen. Erst ein paar Jahre danach wurde in Deutschland die amtliche Vermessung von Gauß-Krüger/Potsdam auf UTM/ETRS89 umgestellt. Ich hatte sozusagen den richtigen Riecher – nein, das war absehbar, entsprechende Verordnungen der EU waren bereits in Bearbeitung.
Wer nicht mitmachte, war die Deutsche Bahn. Die blieben bei Gauß-Krüger/Potsdam, nannten es jetzt DB_Ref und justierten die Parameter der Helmert-Transformation ein wenig, so dass sie auf ETRS89 besser passten. Die ursprünglichen Helmert-Parameter für Gauß-Krüger/Potsdam galten für WGS84, d.h. ohne Berücksichtigung der Drift der Kontinentalplatten. Der Unterschied beträgt in der Praxis aber weniger als einen Meter. DB_Ref bezieht sich also weiterhin auf den Bessel1841-Ellipsoiden und dürfte damit einen ziemlichen Exoten darstellen, denn praktisch alle anderen modernen Koordinatensysteme beziehen sich auf den GRS80-Ellipsoiden.
Damals, als ich zum ersten Mal von DB_Ref hörte, hatte ich entschieden: Brauchen wir nicht separat. Abweichung zu Gauß-Krüger/Potsdam ist zu vernachlässigen. Jetzt ist es nun doch drin. Nennt es Pedanterie. Was zusätzlich halt mit einfließt, sind die EPSG-Codes. Die DB hat sich die Meridianstreifen (Zonen) für DB_Ref registrieren lassen. Diese Codes hätte ich zwar einfach als Alias für Gauß-Krüger/Potsdam ergänzen können, aber nun ist es akkurat. Das spielt für alle Geodaten-Formate eine Rolle, die EPSG als Codierung nutzen, z.B. GeoTIFF.
Die Beispieldaten, die ich jetzt zur Verfügung hatte – dazu weiter unten mehr – waren jedoch im hierzulande allseits beliebten xyz-Textformat. Und da es weiterhin Gauß-Krüger ist, blieb auch die alte Notation erhalten, die den Meridianstreifen (die Zone) als führende Ziffer dem Ostwert voranstellt. (Zur Erinnerung: Gauß-Krüger-Zonen umfassen 3 Längengrade, UTM-Zonen 6. Beides sind transversale Mercatorprojektionen.) Der XYZ-Import für TransDEM kannte eine solche Ostwert-Manipulation bisher nur für UTM. Die 1m-Daten aus NRW beispielsweise kommen so daher. In der neuen TransDEM-Version funktioniert diese Ostwert-Aufspaltung nun auch für Gauß-Krüger.
Gleichzeitig nervte mich bei meinen Tests die jedesmal zu wiederholende Eingabe der sonstigen Importparameter. Daher werden die jetzt zwischengespeichert. Achtung: Die gespeicherten Parameter haben Vorrang vor aus den xyz-Daten hergeleiteten.
Ebenfalls neu ist ein Schätzwert für die Gitterweite. Der Schätzwert ist aber nur dann akkurat, wenn die Matrix vollständig besetzt ist. Bei zu wenigen oder zu vielen Werten für das aufgespannte Rechteck ist der Wert falsch. Meine 1m-Testdaten der DB waren zu dünn besetzt, die Gitterweite wird dann zu hoch geschätzt. Muss man manuell im Importdialog nachjustieren.
Jetzt wird es spannend: Die DB_Ref-Testdaten habe ich von einem Zusianer der Anfangszeit bekommen. Hier im Forum ist er heute als Thomas Ritz unterwegs, damals noch unter anderem Nick: viewtopic.php?p=47572#p47572. Über seinen sehr interessanten Werdegang möge er selber berichten, aber man mag bereits erahnen, dass er fachlich vorbelastet ist. Er hat mir in jener Frühphase von TransDEM Anfang 2004 Dokumentation und Beispieldaten zu einem der etwas ungewöhnlicheren nationalen Koordinatensysteme in Europa zur Verfügung gestellt. Ist also einer der allerersten TransDEM-Anwender überhaupt gewesen!
Bilder zu DB-Höhendaten und sonstigen 1m-Daten
Der XYZ-Import, mit 1m Gitterweite. Westlich vom Bahnhof Aschaffenburg. Man sieht, dass es eine Rohaufnahme ist, das Raster ist nicht vollständig besetzt:
Nach dem Auffüllen mit der eingebauten TransDEM-Funktion:
Eingebettet in klassische bayrische 50m-Daten:
Und hier in die neuen bayrischen 1m-Daten, die es ja seit diesem Jahr kostenlos gibt (wie an anderer Stelle schon beichtet wurde und worüber Michael dann fast vom Glauben abfiel):
Selbst herangezoomt sieht man keine Übergangskante, was dafür spricht, dass erstens die Abbildung von DB_Ref auf UTM funktioniert (oder DB_REF und TransDEM den selben Fehler machen) und zweitens auch der Höhenbezug übereinstimmt:
Noch haben nicht alle Bundesländer ihre 1m-Daten freigegeben, so dass für externe Quellen, hier DB, durchaus noch Anwendungspotential vorhanden ist.
Zum Abschluss des Kapitels xyz-Import und 1m-Daten hier noch welche aus Hessen, auch inzwischen frei verfügbar (weil 1m-Daten einfach Spaß machen):
Hintergrund zu Neuerungen GeoTIFF:
TransDEM unterstützt GeoTIFF seit 2006. Allerdings hatte ich nie eine GeoTIFF-Spezifikation gelesen. Das war auch nicht nötig, die verfügbaren Anwendungsbeispiele reichten aus. Das änderte sich jetzt durch meinen Hauptjob, wo ich mich auch seit Jahren nebenbei ein wenig mit Geodaten beschäftigte, dort aber in C#, nicht in C++ wie bei TransDEM. Und da wurden o.a. 1m-Bayern-Daten zum Anlass, GeoTIFF auch in C# umzusetzen. Gibt es nämlich nicht fertig für .Net, sondern „nur“ die TIFF-Lib (libtiff.net auf GitHub). Die GeoTIFF-Spez. ist aber nicht wirklich kompliziert. GeoTIFF wird über wenige zusätzliche TIFF-Tags bestimmt. Der wichtigste davon heißt GEOKEYDIRECTORY und ist als Liste von diversen sog. GeoKeys ausgebildet. Fehlt dieses Tag, ist es zumindest nach der Spez eigentlich gar kein GeoTIFF. Manche Anbieter liefern normales TIFF mit zugehörigen World-File .tfw. Das würde auch funktionieren.
Ein TransDEM-Anwender aus Indonesien – da gibt es durchaus einige, aus dem Trainz-Umfeld – machte mich auf heimische Daten aufmerksam: DEMNAS (Anmeldung erforderlich und ggf. Übersetzungstool). Und diesen GeoTIFF-Daten fehlt nun das entscheidende Tag mit seinen GeoKeys. Es gibt auch kein World-File. Nachdem ich dank Spez. die Zusammenhänge herausgefunden hatte, mache ich jetzt eine tolerantere Prüfung. Ist besagtes Tag nicht vorhanden, gehe ich von geographischer Pseudoprojektion aus, also Daten mit Länge und Breite. So eine Art Rückfallebene. Das passt dann für DEMNAS.
Beispiel GeoTIFF DEMNAS, Indonesien
Meerenge zwischen Java und Bali, der Region entsprechend mit Vulkan. Die nominelle Gitterweite beträgt 0.27 Bogenminuten, etwa 8m, die tatsächliche Auflösung allerdings scheint geringer:
Überlagerung mit OpenTopoMap – für diejenigen Bali-Urlauber, die stilgerecht quer durch Java mit der Bahn reisen und hier die Fähre nehmen:
Hintergrund zu GeoTIFF: Fehlende Werte
Bei der Analyse der bayrischen 1m-Daten bin ich auf ein weiteres TIFF-Tag gestoßen: GDAL_NODATA. Das steht in keiner offiziellen Spezifikation, ist aber weit verbreitet. Alle Höhendaten in Matrixform benötigen einen Kennung für einen ungültigen, d.h. nicht vorhandenen Wert. Sehr weit verbreitet ist 32767. GDAL, die eierlegende Wollmilchsau unter den Geo-Softwarebibliotheken – ich mag sie nicht wirklich, zu komplex und unhandlich, habe aber für das undurchschaubare ERDAS-Imagine-Format doch auf Extrakte von GDAL zurückgegriffen – produziert seine eigene Variante von GeoTIFF. Und hat ein eigenes Tag für die Codierung fehlender Werte. Durchaus ein Lapsus in der offiziellen Spez. der OGC. Wird jetzt von TransDEM mit ausgelesen und angewandt.
Beispiel GeoTIFF: Fehlende Werte
1m-Daten aus Belgien, Rangierbahnhof Montzen und Moresneter Viadukt. Fehlende Werte werden mit -9999 codiert. Die bisherige TransDEM-Version erkennt das nicht. Man kann es auch schlecht durch nachträgliches Löschen reparieren, weil die Daten nicht im nativen UTM daher kommen, sondern in belgischer Lambert-Projektion. Durch die Konvertierung zu UTM wird dann interpoliert, die -9999-Werte gingen mit ein:
Neue TransDEM Version 2.6.6.1. GDAL_NODATA wirkt:
Ist jetzt ein recht langer Text geworden, aber mir war mal wieder nach ein wenig Erläuterung.
PS: Wer sich gewundert hat, dass ich nicht in Braunschweig war: Ich hatte frühzeitig bei einem anderen Eisenbahnfreundestreffen zugesagt, lange bevor das Zusi-Treffen überhaupt angekündigt wurde.