Seit einiger Zeit beschäftige ich mich mit dem Nachbau von realen Städten in TPF2. Viele haben es mal angefangen, oft geht aber nach einiger Zeit die Motivation aus, einfach aufgrund des großen Aufwands so eines Projekts und der schieren Menge an zu bauenden Straßen, Gleisen, Bäumen, Gebäuden usw., was monoton werden kann. Allerdings besteht mit OpenStreetMap (OSM) bereits eine umfangreiche, detaillierte und offen zugängliche Quelle für Kartendaten. Ich habe mir gedacht: Warum nicht die hier bereits gemappten Straßen, Gleise und weitere Daten verwenden und automatisiert in TPF2 bauen lassen?
So beschäftigte ich mich zunächst mit OpenStreetMap, welche Daten es gibt und wie sie dort dargestellt sind. Hierzulande ist der Detailgrad und die Genauigkeit der Straßen, Gleise, Flächen usw. relativ hoch. Viele der Informationen lassen sich für TPF2 nutzen. Ich fing an, einen Konverter zu schreiben und entwickelte eine Toolchain, mit der die Daten in TPF2 eingelesen und über die Modding API automatisiert gebaut werden können.
Das Ganze mache ich am Beispiel von Frankfurt und Umgebung, wozu ich auch eine entsprechende Karte plane (mehr dazu unten). Der aktuelle Konverter ist schon in einem sehr fortgeschrittenen Stadium, allerdings fallen immer noch kleinere Probleme auf. Die finale Version wird zu gegebener Zeit veröffentlicht, mit entsprechender Anleitung.
OpenStreetMap
OpenStreetMap (OSM) ist ein erfolgreiches Projekt seit 2004 zur Etablierung einer freien, offenen Kartenbasis, an der jeder mitwirken kann. Die Datenbank besteht aus Straßenverläufen, Eisenbahnanlagen, Gebäudeumrissen, Stromleitungen, Landnutzung (z.B. Wald) bis hin zu Objekten wie Mülleimern. Auf der Hauptseite osm.org werden nicht alle Daten dargestellt; manche kennen vielleicht auch OpenRailwayMap, was dieselbe Datengrundlage nutzt, nur mit anderer Visualisierung (z.B. auch abgerissene Gleise).
In OSM gibt es grundsätzlich 3 Arten von Elementen: Nodes (Punkte mit Koordinaten), Ways (Verbindung von Punkten) und Relations (Zusatzinfos zu Nodes und Ways). In den zugehörigen Tags sind weitere Informationen als Attribute enthalten (XML). Prinzipiell können hier beliebig viele Tags vorhanden sein, die Mapping Detailtiefe variiert allerdings. Genauer anschauen kann man sich das ganze auch über die Objekteabfrage via Rechtsklick.
z.B. https://www.openstreetmap.org/way/48905770
Auch wenn in TPF Straßen & Gleise ebenfalls via „Nodes“ und „Edges“ darstellt werden, gibt es einige Unterschiede. So stellt nämlich im Spiel eine Edge immer eine Verbindung zwischen genau 2 Nodes dar, während ein Weg in OSM über sehr viele Nodes verlaufen kann. Außerdem gibt es in OSM (wie auch in Google Maps) keine echten Kurven! Wenn man genau hinschaut, sieht man, dass Kurven praktisch nur aus vielen kleinen (geraden) Segmenten bestehen. Das ist für Karten ausreichend, aber in einem Spiel wie TPF nicht.
Die OSM Daten sind nur 2-dimensional und enthalten keine Höheninformationen. D.h. wir brauchen nichtsdestotrotz eine vernünftige Heightmap. Diese muss natürlich von der Position an den Kartenausschnitt kalibriert werden. Für flachere Gegenden kann man sich den Aufwand einer Heightmap ggf. sparen. In jedem Fall empfiehlt sich ein OSM Overlay.
Welche Daten können genutzt werden?
Der primäre Fokus liegt auf den Straßen und Gleisen. Gerade das monotone Bauen von Straßen könnte vermieden werden, da diese in enormer Zahl vorhanden sind. Die nächste Frage ist natürlich, welcher Straßen-/Gleistyp gebaut wird. Die OSM-Daten enthalten oft Infos zu Art der Straße, Höchstgeschwindigkeit, Anzahl Fahrspuren, Bodenbeschaffenheit usw. Mithilfe diesen Informationen kann ein geeigneter Typ bestimmt werden, sodass direkt die entsprechende Geschwindigkeit oder Straßenart (Bürgersteig, Landstraße, Autobahn, Feldweg) verwendet wird.
Da Wälder in den Landnutzungsdaten direkt als Polygon verfügbar sind, lag eine Nutzung der Förster Mod nahe. Hierfür war eine kleine Anpassung nötig, sodass der Förster über eine Schnittstelle nun die Wälder der OSM Daten bauen kann. Sogar die Information über Waldart (Laub/Misch/Nadel) kann berücksichtigt werden.
Mit den Koordinaten von Städten/Stadtteilen können entsprechende „Labels“ erstellt werden (Fake Städte, nicht funktional).
Weiterhin gibt es ein paar punktuelle Objekte (z.B. Poller, Litfaßsäule), welche mit geeigneten Assets dargestellt werden können. Für viele andere Elemente wie Gebäude, Stromleitungen, Zäune gibt es zu wenige Informationen, als dass eine Automatisierung sinnvoll wäre.
Die Toolchain
Die OSM-Daten zu einem Kartenausschnitt kann man sich ziemlich einfach über die Webseite exportieren. Die Daten sind zunächst in einem XML-Format gegeben. Da ich mir die ganze Konvertierung nicht in Lua antun wollte, finden die Schritte zur Zwischenverarbeitung in Python statt. Das Python Script liest die XML-Daten zum entsprechenden Kartenausschnitt ein, filtert diese nach den relevanten Daten und erzeugt eine Lua Datei in einem geeigneten Format für TPF2.
In der Zwischenkonvertierung findet zum Beispiel die Transformation der Weltkoordinaten zu Map-Koordinaten statt. Das allein war ein längerer Spaß, weil man feststellt, dass die Erdkrümmung bei einer Größe von 24x24 km in der Tat auffallen kann^^. Weitere Verarbeitungsschritte sind die Optimierung der Edges und das Hinzufügen von Tangenteninformationen bei Gleiswegen, damit diese auch passend kurvig ineinander übergehen. Bei geraden Segmenten wäre die Zugfahrt sonst sehr zackig^^
Auf der TPF2-Seite steht praktisch eine Script Mod, die über die Konsole angesprochen wird. Die zuvor erzeugten Daten werden dann eingelesen, sodass über die TPF2-API die Objekte automatisiert gebaut werden können. Hier sind nur ein paar minimale händische Eingaben nötig. Bei großen Kartenausschnitten kann das Bauen eine Weile dauern, aber man kann es auch vorher mit kleineren Teilausschnitten testen.
Für Straßen und Gleise wird die buildProposal Funktion genutzt. Theoretisch kann man hier beliebig viele Nodes und Edges auf einmal angeben, was ich anfangs versucht habe. Bei einem critical Error (Bau nicht möglich), also mehr als eine einfache Kollision (bei einem großen Proposal sehr wahrscheinlich), hat man allerdings keine Möglichkeit, die problematische Stelle zu erkennen oder zu beheben. Daher müssen alle Edges nacheinander mit einzelnen Proposals gebaut werden. Deswegen kann das natürlich etwas dauern bei etwa 5 Commands/s.
Beispiel Frankfurt Karte
Wie oben erwähnt, plane ich eine Karte zum Nachbau von Frankfurt und Umgebung. Ein 1:1 Maßstab ist für mich, spätestens seit der Kopplung mit OSM, unabdingbar. Ich wollte nicht erstmal klein anfangen, sondern habe eine größenwahnsinnige Karte (24x24 km), womit leider trotzdem nicht allzu viel RMV Gebiet bleibt: Der Kartenausschnitt reicht von Langen im Süden, dem Flughafen, über Kronberg im Taunus, knapp zum Altkönig, bis Oberursel und Bad Vilbel im Norden und Mühlheim im Osten.
Heightmap fürs Terrain habe ich mir geholt, ebenso ein OSM Overlay. Leider ist die Heightmap nicht von bester Qualität, weshalb ich aktuell hauptsächlich mit Erdarbeiten beschäftigt bin. Wichtig ist, dass alle Dämme, z.B bei Brücken vorhanden sind und das Terrain bei Straßen und Gleisen halbwegs glatt ist BEVOR man den OSM Bau ausführt. Anpassungen im Nachhinein sind nämlich aufwändiger. Daher kann ich auch erst NACH dem erfolgreichen Import mit Bahnhöfen, Gebäuden, Linien usw. weitermachen und kann aktuell noch nichts allzu spannendes zeigen.
Ich habe einfach mal einen Härtetest durchgeführt und den OSM Importer für die gesamte Karte angewandt. Aktuell bin ich noch auf Build 35049, weil ich mir die zusätzlichen Probleme des aktuellen Updates gerne noch sparen möchte und es Performance mäßig ja auch nicht gerade viel reißt. Bisher habe ich nur Teilausschnitte getestet, was für einen Stadtteil mit etwa 20 000 Edges (1h Bauzeit) kein Problem war. Das Gesamtgebiet hat allerdings 500 000 Edges, was 30h gedauert hat. Die Savegamegröße ist von 30 MB auf 3 GB angestiegen und das Speichern der Autosaves ist auf 20 min angestiegen (vermutlich wegen der RAM Auslagerung). Die Speicherauslastung lag laut Ressourcenmonitor bei 100 GB! Nach dem Neuladen warens 68 GB, leider mit erheblichen Rucklern. Aber gut, was will man bei einer vollgebauten, größenwahnsinnigen Karte auch erwarten? Es wurden immerhin 3,7 Mio Bäume, 10500 km Straße und 1000 km Gleise gebaut.
Von oben ist durchaus ein Wiedererkennungseffekt gegeben. Von Nahem sieht es noch nicht so ideal aus, vor allem wenn viele Edges auf kleinem Raum sind mit vielen Kreuzungen. Daher gibt es teilweise Lücken, weil bei manchen Edges der Bau nicht möglich ist. Aber der Großteil der Struktur von Straßennetz und Gleisen ist so schonmal vorhanden.
Man sieht, dass die Nodes manchmal einfach nicht so akkurat gemappt sind, was bei der Kartendarstellung nicht auffällt, in TPF aber schon
Die Kurven und Steigungen der Gleise sind leider nicht immer direkt perfekt. Wie man sieht, hängt viel vom Terrain ab. Es wird eine gewisse Nachbearbeitung geben müssen. Das ist aber im Endeffekt immer noch deutlich schneller als es komplett selbst bauen. Die Tools von WernerK wie z.B. der Rampenvergleichmäßiger sind hierfür hervorragend geeignet.