OSM Importer: Automatisierter Nachbau mit OpenStreetMap

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


    Also du willst Gleise von Hand legen und Straßen automatisiert?
    Viel kann ich nicht sagen, ohne weitere Details zu dem genauen Vorhaben zu kennen.

    Empfohlen ist eigentlich eine blanke Map nur mit Terrainanpassungen und Vegetation. Weil gebaute Objekte evtl im Weg sind oder es von der örtlichen Genauigkeit dann nicht exakt zusammenpasst.

    Sicher, den zu bauuenden Bereich kann man frei mit den gewünschten Koordinaten wählen. Das muss nicht mit dem Kartenausschnitt der gesamten Map übereinstimmen.


    Den Bahnhofsbereich muss man allerdings weiträumig abreißen und von Hand bauen.

    Wie gut Gleisvorfelder erstellt werden, muss ich selbst erst noch rausfinden. Das hängt wahrscheinlich auch stark vom OSM Detailgrad ab.

    Es können Doppelkreuzweichen automatisiert gebaut werden, wenn das in den Daten drinsteht.

    Die ersten Tests zeigten allerdings dass bei Vorfeldern oft Lücken bleiben, weil nicht alles gebaut werden kann wegen Kollisionen.

    Nach längerer Pause meinerseits mal eine Zwischenstandsmeldung!


    Ich bin inzwischen wieder an der Frankfurt Karte dran um die letzten Vorbereitungen für die Anwendung des OSM Imports vorzunehmen. Das betrifft vor allem das Terrain, welches unbedingt vor dem Anwenden bearbeitet werden sollte. Das Anpassen der Höhen dauert leider auf einer größenwahnsinnigen Karte seine Zeit. Typische Heightmap Daten sind bestenfalls bei 20m Auflösung, was einfach nicht detailliert genug ist, dass sie Bahndämme, Brücken, usw. metergenau abbilden würden. Zusätzlich muss ich die Nachteile eines Oberflächenmodells (DSM) erfahren: Meine Heightmap zeigt am Waldrand immer Steigungen von 10-15 Meter, wo es in echt flach ist. Hier zeigen sich die Vorteile eines echten Geländemodells (DGM/DTM).


    Im OSM Importer habe ich z.B. noch die Möglichkeit hinzugefügt, vorgefertigte osm/pbf Dateien von einem größeren Kartenausschnitt zu nutzen, zB von Geofabrik

    Das hat den Vorteil, auch ältere Versionen von OSM Karten zu nutzen (gibt keine andere Möglichkeit, historische Kartenzustände zu erstellen). Der (traurige) Grund ist, dass ich das Overlay schon vor 2 Jahren erstellt habe, aber OSM ja kontinuierlich verändert wird (neue Objekte, aber auch Korrekturen von Positionen), was dann zu Differenzen zwischen Overlay und vom OSM Import gebauten Straßen/Gleisen führt.


    Außerdem wollte ich noch Signale in die Automatisierung einbauen. Die sind nämlich oft sehr detailliert gemappt, außerdem gibt es ja schon viele verfügbare Signale aus Mods. Hier zeigt sich allerdings wieder ein architektonischer Unterschied zwischen OSM und TPF: In OSM werden Signale als Nodes definiert, die auf den Ways, also den Gleisen liegen, zwischen einzelnen Edge Stücken. In TPF wiederum liegen Signale als "EdgeObjects" direkt auf einer Edge zugeordnet. Das zu konvertieren sieht soweit machbar aus. Ich hatte erst noch Probleme beim Hinzufügen von EdgeObjects in Proposals, da mir die Api abschmiert... die Dokumentation ist hierzu dürftig. Dank einer schnelle Antwort von UG ist das Problem aber schon gelöst.


    Dann fehlt nur noch die Dokumentation, woran ich schon am schreiben bin. Gleichzeitig arbeite ich an der Frankfurt Karte, bis ich den Import endgültig machen kann. Dann kann es richtig losgehen mit dem Nachbau.


    Zitat von WernerK

    abgesehen von den "falschen" Parallelgleisabständen

    Das Gute am Import ist auch dass die Gleise einzeln mit Gleisbett und in näheren Abstand gebaut werden, je nach Mapping in OSM:

    (unbearbeitet nach OSM Import)

    Zitat

    Das Gute am Import ist auch dass die Gleise einzeln mit Gleisbett und in näheren Abstand gebaut werden, je nach Mapping in OSM:

    Jetzt müsste man nur noch UG dazu bewegen, die Oberleitungsmasten dann symmetrisch zu platzieren und dem toten Abstandsparamater in den Gleisdateien Leben einzuhauchen. :-( Die Brücken wären noch das geringste Problem, da könnte man Halbelemente bauen.

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

    Bei Sebbe sind das ja alles vorgefertigte Signale. Bei der Modwerkstatt kannst du beispielsweise Vorsignale in Form von Wegpunkten mit leichtem Vorschub, an die Hauptsignale einzeln anbauen, damit das Menü nicht voll mit Kombinationen ist. Du hast auch mehrere Höhen und mehr Zusatzanzeiger zur Auswahl. Hier hast du dann auch umfangreiche Assets mit ausgeschalteten Zusatzanzeigern, ausgekreuzten Signalen, usw.

    Wir haben hier quasi sämtliche Versionen von den Signalen - sogar Bahnsteigssignale ^^

    Zitat von VacuumTube

    Nach längerer Pause meinerseits mal eine Zwischenstandsmeldung!

    Hey Vacuumtube und Frohe Weihnachten,

    ich denke, so gut die Idee mit den Singalen ist, dass man das nicht machen sollte. Denn im Idealfall wäre ja, wenn man mit Vanilla Methoden Karten erstellen könnte. Auch deine Aussage zu den Bahnhöfen finde ich nun nicht wirklich schlimm, wir wollen ja noch was an Arbeit haben.

    Aber ich versuche mich derzeit mal wieder an S-H. Deswegen würde ich zu gerne wissen, ob du ggf noch eine Anleitung für den OSM Importer schreibst. Du zeigst ja einen groben Weg auf, aber irgendwie fehlt mir da ein Puzzleteil, um zur Fertigen Map zu kommen.
    Mein Scriptwissen zu Python ist dann doch eher rudimentär.


    Ich werde mich mal nach den Feiertagen hinsetzen und schauen, was dein Tool so alles kann. Eine Karte wie S-H sollte am Ende den Vorteil haben, dass man Aufgrund des Maßstabes nicht 100% Detailgetreu werden kann und muss.

    Kann man deinen Importer eigentlich auf jede Kartengröße anwenden?

    Ach zu den HV Signalen, was Weisssi so sagte, ich werde langfristig auch eher wieder mit HV von Modwerkstatt arbeiten, da man hier einfach mehr Optionen, bei gleichzeitig weniger angezeigten Kombinationen hat.

    MySystem: R5 3600, 32 GB Ballistix DDR3200, GTX 3060Ti
    TPF2 und ETS2 Spieler

    Daumen hoch 2

    Euch auch frohe Weihnachten.


    Wie die meisten Features, wird natürlich auch das Bauen von Signalen mit einer einfachen config Variable optional.


    Die Anleitung muss noch geschrieben werden, da bin ich wie gesagt dran. Das kostet halt leider auch Zeit, wenn das ganze am Ende verständlich sein soll. Ich kann nur schwer einen Zeitplan angeben, aber hoffe dass es in den nächsten Monaten fertig ist. Ggf kann ich im Januar schonmal einen Zwischenstand hochladen.


    Das mit Vanilla Methoden hab ich nicht verstanden. Es ist so dass ich mittlerweile schon einige Mods eingebunden habe, da ja das Ziel ist, größtmöglichen Realismus zu erreichen (zumindest mein Ziel). Ich habe dabei sehr sorgfältig ausgewählt, welche Mods nützliche Straßen, Gleise, Brücken bieten. Nichtsdestotrotz kann man dies in den Dateien leicht anpassen. Ich denke aber das ist eine der großen Stärken vom OSM Importer, dass man die OSM Informationen direkt mit den passenden Mods verknüpft. Um ein paar Beispiele zu geben:

    -Die Gleise haben meist die Geschwindigkeitsangabe. Damit kann direkt der richtige Gleistyp mit der Geschwindigkeit gebaut werden (NEP). Wenn ich hier einfach die Standardgleise nehmen würde, müsste man ja im Nachhinein überall drüber gehen und anpassen.

    -In OSM sind Straßen, Wege, Autobahnen und zusätzlich Infos über Spurenanzahl, Bürgersteige, Straßenbeleuchtung, Oberflächenbeschaffenheit vorhanden. Dies wird genutzt um eine möglichst passende Straße zu finden. Hierfür gibt es eine wunderbare Menge an Mods die hier zum einsatz kommen können. Inner- außerortstraßen, Fußgängerzonen, Waldwege, sogar Flüsse als Straßen...

    -Wälder enthalten die Information ob Nadel, Misch oder Laubwald. Dementsprechend wird eine andere Baumauswahl an den Förstermod gegeben.


    Kartengrößen sind natürlich nicht hardcoded also kann man einen beliebig großen Kartenausschnitt nehmen. Eine beliebige andere Skalierung als 1:1 sollte möglich sein, jedoch bin ich da zwiegespalten wie hier angesprochen. Für ländliche Bereiche mit geringen Kurven wird das hinkommen. Dichte Bereiche werden aber schon bei 1:2 derart komprimiert, dass du Bahnanlagen wahrscheinlich weitgehend neu bauen musst.

    Zitat von Unrockstar-HH

    HV von Modwerkstatt arbeiten, da man hier einfach mehr Optionen, bei gleichzeitig weniger angezeigten Kombinationen hat.

    Gut finde 1576 Signaldateien jetzt nicht gerade wenig, aber Signal Konstruktionen sind ein (Wunsch)Thema für sich...

    VacuumTube

    Danke dir für das Feedback.
    Dann hatte ich da was missverstanden ;)
    Ich hab mir mal die ziehbaren Oberleitungen angeschaut, also die Methode wie sie Hans Dampf und Co nutzen, deswegen fragte ich nach der Vanilla Nummer.
    Aber ich befürchte, ich hatte dich da missverstanden. Sorry meinerseits. Und ja die Asset Lösung für die Signalbilder ist halt umfangreich.. Da fehlt eig sowas wie ein Editor.
    Das mit der Anleitung klingt ja schon mal nicht verkehrt, gut Ding will weile haben

    MySystem: R5 3600, 32 GB Ballistix DDR3200, GTX 3060Ti
    TPF2 und ETS2 Spieler

    In den letzten Wochen komme ich gut voran, die Dokumentation ist fast fertig.


    Spontan ist mir noch eine weitere (und wahrscheinlich letzte) Automatisierung eingefallen. Brücken sind oft problematisch, da die Höhe der Nodes ja praktisch nur durch das Terrain ermittelt wird. Besteht die Brücke nur aus einem Segment, hängt sie schön gerade in der Luft, wenn die Brückenenden ordentlich geformt wurden. Sind allerdings zwischendrin Nodes, so kleben diese am Boden.


    Hier eine Auswahl typischer bis extremer Fails:


      


    Bisher hatte ich dieses Thema der Nachbearbeitung zugeordnet, da man ja mit dem Rampenvergleichmäßiger mit wenigen Klicks daraus eine gerade Verbindung machen kann:


    ----->


    Dann dachte ich mir, dass ich die Nodes dazwischen auch einfach mithilfe der Anfangs- und Endnode Höhe interpolieren kann. War schneller implementiert als gedacht.



    Das hier nun direkt nach dem Import.

    Was man leider auch sieht, dass auf meiner Karte Overlay und OSM Koordinaten Abweichungen von bis zu 5m haben, was nervig werden kann. Daher achtet sehr präzise auf die Anpassung!


    -----------------------------


    Außerdem habe ich mir Gedanken zum Thema Häuser gemacht. Eine ziemlich herausfordernde Aufgabe zur Automatisierung, wenn man unterschiedliche Haustypen und Formen berücksichtigen muss. Ich werden Häuser erstmal Stück für Stück manuell ohne Kapazitäten setzen und schauen wie ich voran komme. Es gibt ja auch Mods mit Straßen wo automatisch Häuser sind, vielleicht ist das praktisch.


    Stellt sich natürlich auch die Frage, ganz klassisch mit TPF2 Städten und Gebäudegenerierung zu arbeiten, wobei ich das eigentlich aufgegeben habe. Man würde sich so auf einer großen Karte, die nicht nur ländliche Kleinstädte hat, innerhalb kürzester Zeit die Performance ruinieren. Vielleicht möchten manche aber bei einem kleineren Nachbau doch damit arbeiten und man kommt ja auch schneller zu Ergebnissen so. Mittlerweile gibt es ja mit den Parcels/Zones der CommonAPI auch Möglichkeiten den Bauwahn etwas einzudämmen. Das Problem was ich noch sehe, ist allerdings dass die "KI" mit aktiven Stadtwachstum die nachgebauten Straßen umwandeln kann und neue bauen wird. Die vom Tool gebauten Straßen sind nicht gesperrt, da ich das playerOwned Feld bei Proposals irgendwie nicht setzen kann.

    Also das mit den playerOwned in SegmentAndEntity hatte ich auch.

    UG Scheint da etwas geändert zu haben und möchte wohl jetzt ein component haben.


    Früher meinte ich, das es nur die Player Entity Id angenommen hat.


    Dieser Code sollte funktionieren, ungetestet,ich kopiere mir ja beim NodeEditor die EntityId für den Player aus den vorhanden Daten...

    Code
    local eo = api.type.SegmentAndEntity.new()
... 
local playerOwnedComponent = api.type.PlayerOwned.new()
playerOwnedComponent.player = game.interface.getPlayer()
eo.playerOwned = playerOwnedComponent

    Hab ich übrigens schon gesagt, dass Flüsse/Bäche als Wassertexturstraßen gebaut werden?

    Die werden praktischerweise 1m abgesenkt im Terrain.



    eis_os Danke hat geklappt. Straßen gehören jetzt dem Spieler.



    Ich arbeite kontinuierlich an der Frankfurt Karte weiter, bin aber noch nicht ganz fertig mit den Terrain Vorbereitungen. Parallel bin ich dann immer am Testen mit Teilausschnitten. Dadurch ergaben sich zuletzt noch eine ganze Reihe kleiner Fixes/Optimierungen. Der Plan war eigentlich, erst nach dem kompletten Import eine finale v1.0 hochzuladen, aber ich werde das jetzt vorziehen. Änderungen wird es wahrscheinlich sowieso geben.


    Aber bald sollte es dann soweit sein und dann geht es hoffentlich mit dem Nachbau vorran. Wird dann einen eigenen Thread geben natürlich. Aber alles zu seiner Zeit. Auch wenn das Ergebnis von OSM Importer auf den ersten Blick gut aussieht, sind im Detail noch Anpassungen nötig (Postprocessing).


    Und dann war da ja noch die Performance Frage... RAM ist bestellt ich hoffe 32+64 reichen aus ^^ mal schauen ob es dann flüssig läuft... bin gespannt

BlueBrixx