OSM Importer: Automatisierter Nachbau mit OpenStreetMap

Die RAM Anforderungen betreffen das Thema Nachbau i.A. und habe ich hier geschätzt: Real-Nachbau in TPF 2 (wobei die Spalte hoch für OSM Import gedacht ist)

Es hängt logischerweise von der Kartengröße ab, aber auch von der Bebauungsdichte. Eine ländliche Region mit ein paar Dörfern braucht natürlich viel weniger als wenn man eine stark besiedelte Metropolregion nachbaut.

Das Ding ist natürlich, dass durch meinen Ansatz enorm viele Elemente ins Spiel kommen, die man beim normalen Spielen nie erreicht. Der Nachteil ist, dass man direkt nach dem Import mit dieser Menge an Elementen umgehen muss, während beim klassischen Bauen die Größe langsam anwächst und man entscheiden kann aufzuhören. Das hat andererseits den Vorteil, dass man direkt weiß wie die Anforderungen für den vollen Ausbau der Karte tatsächlich sind.

Nach meinen Erfahrungen sind für die RAM Auslastung die Anzahl Edges (Straßen/Schienen Segmente) entscheidend. Die verbrauchen durschnittlich 100KB pro Edge (wegen der reversiblen Terrainänderung). Die 3,7 Mio Bäume erzeugten nur ca. 1GB zusätzlich. Wie ich am Anfang des Threads schon beschrieben hab, gibt es für Frankfurt 500 000 Edges, welche ich im Härtetest gebaut habe. Zum Vergleich, Hans Dampfs 1. Karte hat 50k Edges. Man erreicht mit dem OSM Import bei größenwahnsinnigen Karten also Werte, die wahrscheinlich noch kein Spieler gemacht hat. Es ist also tatsächlich eine spannende und offene Frage, ob das Spiel unter solchen Umständen überhaupt lauffähig ist.

Wenn nicht, wird man die Anzahl der Edges wohl oder übel verringern müssen und auf kleinere Wege/Pfade verzichten.

Endlich ist es soweit!

Der OSM Importer ist Release fertig.

Das Tool ist hier auf Github verfügbar: https://github.com/Vacuum-Tube/OSM-TPF2-Importer

Dort finden sich Code und Dokumentation (englisch).

Die zu schreiben hat einige Zeit gekostet, ich hoffe aber es ist vollständig und verständlich. Insgesamt ist das doch sehr umfangreich geworden.

Ich wünsche viel Spaß damit bei zukünftigen Nachbauprojekten!

TPF2 ist ein teures Hobby, wenn man es drauf anlegt, aber moderne Hardware lohnt sich...

Ich kann nur jedem empfehlen klein anzufangen. Natürlich ist es schade das Gebiet abzugrenzen, aber so wird man nicht nur bessere Performance haben, sondern auch schneller zu Ergebnissen kommen.

So ist es, OSM ist als 2D Kartendarstellung gedacht. Die Höhendaten müssen von einer anderen Quelle kommen.

Der "ele" Tag ist nur sehr punktuell genutzt und daher nicht sinnvoll zu nutzen (wiki: "Dieser Wert ist hauptsächlich für Berggipfel vorgesehen")

Ich habe mir für die Frankfurtkarte damals ein DSM von opendem geholt, aber würde es heute wahrscheinlich anders machen. Siehe Real-Nachbau in TPF 2

Es gibt wohl keine Höhendaten, die so hoch aufgelöst sind, dass sie Dämme und Brückenrampen perfekt abbilden, auf denen der OSM Importer direkt die Straßen und Gleise bauen kann. Daher ist das Terrain tatsächlich ein Knackpunkt, da sich dieser Schritt nicht automatisieren lässt. Das muss man vor dem Import von Hand machen (siehe Map preperation).

Zitat von Rutel

Eine performance-mäßige Frage: ich versuche möglichst, Feldwege etc. von normalen Straßen für Fahrzeuge abzukoppeln (nur die violetten Verbindungen bei AltGr-L), um die Wegfindungsroutinen zu entlasten; Fußgänger laufen ja sowieso nicht so schrecklich weit. Meint Ihr, daß das was bringt, gerade auch im Zusammenhang mit so einem Monster-Import?

Klingt sinnvoll. Der Straßengraph wird damit vereinfacht, was die Wegsuche verkürzen sollte. Um genaueres zu wissen bräuchten wir allerdings den Quellcode oder UG müsste ein paar Hinweise geben, was konkret hilft.

Es gibt auch eine Option beim OSM Import, solche Wege wegzulassen, das spart auch RAM ein. Ich hatte auch überlegt, sie via Texturen nachzumalen, aber gibt keine API dafür.

Ich plane aber sowieso möglichst wenig Autoverkehr, um mir die Performance nicht direkt zu versauen. Der Plan ist, Gebäude nur mit Fußgänger Anschluss zu setzen und vereinzelt Automagneten zu setzen, dann aber mit hoher Kapazität (in der Hoffnung dass die Wegsuche nur einmal für alle Bewohner gemacht wird, aber auch hier nur eine Vermutung).

Ich traue mich aktuell noch nicht den finalen Import durchzuführen und das liegt an den Kurven. Wie schon im ersten Post beschrieben liegt das Problem darin, dass Nodes in OSM nicht immer mit der höchsten Genaugikeit platziert werden, was in Karten zwar nicht so auffällt. Da Gleise hohe Kurvenradien erfordern, die auch noch möglichst konstant sein sollten, kann das aber im Spiel sehr wohl zum Problem werden, wenn wackelige Kurven mit geringen Radien entstehen.

Aktuell berechne ich mir zwar Tangenten damit es keine Knicke in den Gleisen gibt, aber das war etwas improvisiert.

Daher beschäftige ich mich gerade intensiver mit dem Thema Kurvendarstellung in TPF2.

Vielen Dank an WernerK für die Aufarbeitung des Themas im Lexikon.

Kurven werden in TPF2 als Hermite-Kurven modelliert. Das sind kubische Splines, also einfache Polynome.

Ich habe etwas gebraucht, um zu verstehen, dass Hermite einfach nur heißt, dass man die Tangenten an allen Punkten vorgibt. Im allgemeinen Fall kann man das kubische Polynom aber auch anders bestimmen.

Polynome sind einfach zu berechnen und geeignet für Computerdarstellungen.

Die Geometrie von Eisenbahnstrecken folgt aber eigentlich einer ganz anderen Logik.

Kleiner Exkurs: Geometrie bei Planung von Eisenbahnen

Im Prinzip gibt es nur 3 Arten von Geometrien: Geraden, Kreisbögen und Übergänge dazwischen.

Die Übergänge werden gerne mit Klothoiden modelliert, weil diese die schöne Eigenschaft haben, dass die Krümmung (Kehrwert von Kurvenradius) linear mit der Kurvenlänge zu- oder abnimmt. D.h. wenn man mit konstanter Geschwindigkeit entlang der Bahnlinie fährt, von Gerade zu Kurve, nimmt die Krümmung nicht schlagartig, sondern linear zu. Ansonsten würde die Fliehkraft einen Sprung machen, was einen Ruck verursacht und nicht angenehm wäre.

Dasselbe passiert übrigens auch bei Straßen: Der Übergangsbogen sorgt dafür, dass ich linear das Lenkrad einschlagen kann und erst wenn der Kreisbogen erreicht ist, bleibt der Einschlag konstant.

Diese Darstellung ist viel intuitiver, da sie (im Gegensatz zur Koordinatenbetrachtung der kubischen Splines) aus der Sicht des Fahrzeugs entlang der Kurve gemacht wird. Leider ist diese Modellierung mathematisch aber schwieriger zu handhaben.

Daher werde ich mit kubischen Splines arbeiten. Trotzdem dachte ich, wäre es schön, wenn ich die Eigenschaft kontinuierlicher Krümmungen (mathematisch: 2fache Differenzierbarkeit) beibehalten kann. Das geht und heißt Natural cubic splines!

Vorher habe ich nur dafür gesorgt, dass die Tangenten an den Nodes gleich sind. Jetzt gehen aber auch die Kurvenradien stetig ineinander über. Damit haben wir Geometrien, die besser sind, als man sie beim normalen Bauen in TPF2 hat! Eine Gerade bauen und dann ein Kreisbogen - das würde in der Realität zu einem heftigen Ruck führen.

Die Herausforderung jetzt ist eben nur noch, schlecht gemappte Nodes zu erkennen und die Kurve zu korrigieren. Dank der Spline Darstellung kann ich mir den Kurvenradius an jeder Stelle der Kurve exakt berechnen. Nur wie ich die Korrektur mache, weiß ich noch nicht genau.

Das galt jetzt alles für die x-y Ebene (2D). Eigentlich habe ich dasselbe Problem aber auch in der z Ebene für die Höhen. Die Höhe entlang der Kurve ist zum Glück nur 1 dimensional. Es ist trotzdem ein bisschen anders, weil die Höhen ja erst im Spiel festgelegt werden und daher die z Werte und Tangenten in Lua berechnet werden müssen. Falls ich hier noch einen Geistesblitz bekomme, wie man den Verlauf geschickt glätten kann, erhält man vielleicht direkt passende Steigungen und muss nicht überall den Ramp Equalizer anwenden. Vielleicht muss ich das Terrain auch zwischen den Nodes abtasten. So müsste man sich ggf auch weniger Mühe in der Terrain Vorbereitung geben.