OSM Importer: Automatisierter Nachbau mit OpenStreetMap

Willkommen in der Transport Fever Community

Welcome to the fan community of Transport Fever and Train Fever, the economic simulators of Urban Games. The community is free for you to share and inform yourself about the game. We cultivate a friendly and objective interaction with each other and our team will be happy to answer any questions you may have.

 

Registration and use is of course free for you.

 

We wish you a lot of fun and hope for active participation.

The Team of the Transport-Fever Community

  • 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.


    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.



    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!

  • :thumbup::thumbup::thumbup:   :!::!::!: Wow, da hast du ja ein Hammerding rausgehauen! Und dazu noch ein richtig professionelles Video. :thumbup:Das ist es auch wert. Es ist die beste Werbung für TPF2 überhaupt. Wäre schön, UG sähe das genauso.


    Die andere Frage ist, ob jetzt kleine Rauchwölkchen aus meinem Urzeitrechner hochsteigen ... :D

    ... don't know much trigonometry ... don't know much about algebra ... don't know what a slide rule is for ...

  • Ganz großes Kino, ich bin komplett überwältigt 8| . Wahnsinn. Ich hoffe es wird oft genutzt werden und ich wünsche mir nun noch mehr einen TpF2-tauglichen Rechner zu besitzen und nicht nur einen Laptop der bei winzigen Maps in TpF1 abschmiert.

    MrOnic na, willst du noch mal mit Kiel anfangen :D

  • 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.

  • aber moderne Hardware lohnt sich...

    nicht nur für TPF2, die Anforderungen zukünftiger Spiele werden das fordern.

    MfG elektronikfreak


    MB MSI MPG Z790 Edge WIFI - i7-14700K - Nvidia GeForce RTX 4080 Founders Edition 16GB - 192 Gb DDR5 Ram - 5x 2TB M.2 - Win11/64 - WsK - 60TB Ext. - TPF2 35732

    (Meine Screenshots dürfen weiter verwendet werden) - (Fixiert auf Berliner Mod's)

  • Darf ich mal ganz dreist fragen, wie gut die Höhenauflösung ist? Und woher kommen die Höhendaten?

    Wenn die Knoten in OSM auch bei ziemlich geraden Straßen und Bahnstrecken maximal 100 m auseinanderliegen und deren Höhe +/-10 cm exakt sind, ist das wahrscheinlich sehr viel besser als mit einem 25x25 m DEM erreichbar ist. Für einen Nachbau wird man ja ziemlich viel glätten müssen, aber wenigstens nicht großflächig 3 m abhobeln.


    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?

    13! = 13*12!

  • Darf ich mal ganz dreist fragen, wie gut die Höhenauflösung ist? Und woher kommen die Höhendaten?

    Dazu habe ich folgenden Abschnitt im ReadMe gefunden:

    OSM only consists of 2D data, there is no height information.
    Thus, the heights have to come from a heightmap or by manual terrain editing.
    Available heightmaps have horizontal resolutions of ~25m at best - this is not enough to represent embankments and bridges.
    Thus, the high terrain differences they create on short scale has to be modeled manually.

    Wenn ich das richtig verstehe, projeziert der Importer also die OSM Daten auf das TPF2 Terrain und nutzt dessen Höheninformation.


    Das OSM keine Höheninformation hat, stimmt aber nicht ganz. Hierzu ist der "ele"-Tag bestimmt. Dieser ist aber eher ein "Afterthough" und wird daher auch nur selten benutzt. (Im Anhang habe ich mal eine Overpass-Auswertung, auf welcher alle Nodes/Ways mit entsprechendem Tag markiert sind. In Zürich immerhin sämtliche Tram-Haltestellen)

  • 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).


    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.


BlueBrixx