Solche „Basemaps“ stellen eine Alternative für Bodentexturen dar, deren Auflösung aufgrund der Datenstruktur bei Trainz begrenzt ist, wenn ganze Baseboards und ganze Streckenmodule mit Karten oder Luftbildern versehen werden sollen.
Wie bei fast allen Basemap-Lösungen verwendet TransDEM für seine UTM-Kacheln vorgefertigte Meshes als Texturträger, die von Natur aus eine große flache Ebene bilden. In bergigem Gelände ist dies weniger ideal, da die Kacheln auf die Höhe der tatsächlichen Geländeoberfläche am jeweiligen Arbeitspunkt angehoben oder gesenkt werden müssen.
Die Texturen sind für jede Kachel individuell, aber die Kachel-Meshes sind immer dieselben. 2010 kamen zu den ursprünglichen 1000m-Kacheln kleinere mit 500 m Kantenlänge hinzu, aber die sind an Berghängen immer noch reichlich unhandlich.
Für den Streckenbauer wäre es deutlich einfacher, würden die UTM-Kacheln die Textur für Karte oder Luftbild auf einer am tatsächlichen Gelände orientierten Oberflächenform wiedergeben. Das bedeutet natürlich, dass nicht mehr nur die Texturen individuell erzeugt werden, sondern auch die Texturträger, die Meshes selbst, individuell für jede Kachel gefertigt werden. Ein nicht ganz unbescheidener Rechenaufwand.
Vor etwa einem Jahr hat Trainz-Anwender ModelerMJ ein Projekt für solche individuellen Gelände-Basemaps gestartet, wobei sein Ansatz eng verflochten ist mit Google-Earth und anderen Google-Diensten. ModelerMJ hat jetzt angeboten und angekündigt, auf diesem Ansatz basierend ein Softwarewerkzeug für Streckenbauer zu entwickeln.
Langjährige TransDEM-Nutzer werden möglicherweise bemerkt habe, dass ich sehr zurückhaltend bin, wenn es um engere Kopplung mit Internet-Diensten von Google und anderen Anbietern geht. Die beiden Clients für Onlinedienste in TransDEM, WMS und Kachelkarten, arbeiten auf der untersten Ebene des HTTP-Protokolls, ohne Benutzerkonto, ohne API, ohne Cookies, ohne jede Übertragung persönlicher oder „statistischer“ Daten. Aus dem selben Grund ist auch die Kopplung mit Google-Earth eine sehr lose. Sie beschränkt sich auf den rein lokalen Transfer simpler JPEG- und Placemark-Dateien.
Unter Beibehaltung dieser Datenschutzpolitik bedeutet das, dass auch geländegeformte UTM-Kacheln auf jede Abhängigkeit von Google und Co. verzichten müssen. Bei genauerem Hinsehen sollte TransDEM eigentlich schon alles selbst bieten, was hierzu an Daten benötigt wird.
Diese Woche habe ich das nun näher untersucht und ein wenig probiert. Folgendes ist dabei herausgekommen, die erste individuell geformte UTM-Kachel in TransDEM, im wohlbekannten Tal der Wupper zu Müngsten:
Im Moment ist dies noch ein reiner Laborversuch, aber ich plane, diese Funktionalität in die nächste Version von TransDEM einzubauen. Sie wird „3D UTM-Kacheln“ getauft. Die bisherigen Kacheln werden als Alternative erhalten bleiben, zukünftig bezeichnet als „2D“. 2D- und 3D-Kacheln werden so kompatibel wie möglich werden, einschließlich der beiden Größen 1000 und 500m.
Wie einleitend bereits bemerkt, die Fertigung der 3D-Kachel wird rechenintensiv. Für jede Kachel fallen drei zusätzliche Schritte an:
- Die Höhen aus der Trainz-Streckendatei extrahieren, an der Position und für die gesamte Ausdehnung der jeweiligen Kachel. Der einfachste Weg in TransDEM dazu sind kleine individuelle DEMs für jede Kachel. Dieser Schritt ist mit minimalem Kodieraufwand verbunden, die Klassen dazu existieren alle schon.
- Die individuelle Datenstruktur für das Mesh aufbauen. Der Standardansatz in Trainz für 3D-Geometrie und Drittsoftware läuft über eine Klartextbeschreibung in einem Trainz-spezifischen XML-Dialekt. In diesem Schritt erzeugt TransDEM die Vertices, Normalen und Texturkoordinaten dieses Meshes in XML-Form, an Hand der Höhen des kacheleigenen DEMs. Das Mesh wird als komplettes 10m-Raster gebildet. Eine nachfolgende Optimierung mit Streichung überflüssiger Vertices scheint aus momentaner Sicht nicht erforderlich.
- Der letzte Schritt ist die Generierung des eigentlichen Trainz-Meshes, der .im-Datei. Das Importwerkzeug dazu wird von N3V/Auran bereit gestellt. Die Anwender werden sich dieses Werkzeug selbst herunterladen müssen, da die Lizenzbedingungen die Weitergabe nicht gestatten. Meine Vorstellung ist natürlich, das Importwerkzeug dann vollautomatisch aus TransDEM heraus aufzurufen.
Noch zwei Anmerkungen:
- In diesem Frühjahr habe ich für unsere amerikanischen Freunde die Importmöglichkeit für GeoPDF geschaffen. Hierbei nutzt TransDEM komplett unabhängige externe Software, die GDAL-Werkzeuge. Der dafür benutzte Ansatz sollte sich auf den Trainz-Mesh-Importer übertragen lassen, der ebenfalls als eigener Prozess gestartet werden soll, aber unter der Kontrolle des TransDEM-Prozesses bleibt.
- Die drei genannten zusätzlichen Schritte werden Rechenzeit kosten. Am notwendigen Ablauf selbst kann ich wenig ändern, deswegen müssen Möglichkeiten zur Parallelisierung untersucht werden, Ideen dazu habe ich. Schon die letzten beiden TransDEM-Versionen lassen bereits etliche Rechenalgorithmen parallel laufen, wobei dann alle verfügbaren CPU-Kerne genutzt werden. Die Aufgabe hier wird etwas abweichen, weil mehr Kontrolle über die Worker-Threads erforderlich sein wird, aber ich denke, das ist lösbar.
