Konzept UTM-Zonen-Sprünge

[Carsten Hölscher]

Wir kommen jetzt an Stellen, wo Strecken durch mehr als eine UTM-Zone laufen. Nun könnte man ja ein Modul noch in eine Nachbarzone referenzieren, aber das ist doch eher eine Krücke als dass man hier eine rundrum funktinierende Lösung hätte. Wir brauchen hier also irgendein Konzept.
Erste Frage: Wie machen dass denn andere Simulatoren (muss nicht auf Bahn beschränkt sein).
Zweite Frage: Wer hat die beste Idee für das Problem?

Carsten

[Alwin Meschede]

Es gab mal die Idee, dass man den Simulator so umbaut, dass die Simulation nicht mehr singlethreaded laufen muss, um moderne CPUs besser auszunutzen. Dann wäre es naheliegend, dass zum Beispiel die Streckenmodule in UTM-Zone 32 im ersten Thread laufen, und die aus Zone 33 in einem zweiten Thread. In der st3 definiert man dann "Sprungpunkte". Wenn ein Zug so einen Sprungpunkt erreicht, wird er vom einen in den anderen Thread übergeben. Beim Spielerzug hätte das dann einen Ladebildschirm zur Folge. Ich halte es für vertretbar, dass man auf dem Weg von Hannover nach Berlin einmal bei Stendal so eine Ladepause wegen Wechsel der 3D-Grafik in den anderen Thread hat.

[Carsten Hölscher]

So ganz verstehe ich das nicht. Nennen wir die Module mal A und B, zwischen denen ein Sprung in die andere Zone stattfindet. An der Grenze zwischen A und B hab ich dann ja einen optischen Sprung in der Strecke, also einen Versatz in der Landschaft und Strecke. Laden kann ich das aber alles ganz normal wie jetzt auch. Also was genau soll in einem anderen Thread gerechnet werden?

Eine Lösung ohne Ladeschirm während der Fahrt sollte aber möglichst das Ziel sein.
Um wleche Abweichungen in Metern geht es eigentlich so ganz grob der Grenze zwischen A und B?

Carsten

[Alwin Meschede]

Naja, ich will dir komplett ersparen dass Du irgendwas transformieren musst. Daraus folgt, dass die Module A und B nicht im selben Kontext laufen können, denn sie sind (und bleiben) geometrisch unkompatibel. Man kann aber die Landschaft ja so bauen, dass der Übergabepunkt nicht aussieht wie das Ende der Welt. Also hat jedes der beiden beteiligten Module noch etwas "Dummy-Landschaft". Konkretes Beispiel: In beiden Modulen A und B würde es jeweils eine Elbebrücke Hämerten geben. Jeweils vor Brücke liegt der Sprungpunkt. Dort dann Wechsel des Zuges in den anderen Thread und Wechsel der 3D-Grafik zu den Modulen der anderen UTM-Zone.

[Alwin Meschede]

Um wleche Abweichungen in Metern geht es eigentlich so ganz grob der Grenze zwischen A und B?

Also ich habe in Schönhausen/Elbe dahingehend etwas experimentiert. Die UTM-Transformation bringt nicht nur Verschiebungen, sondern auch Verdrehungen mit sich. Das mag noch handhabbar sein, solange ein Streckennetz nur an einer Stelle eine UTM-Grenze überschreitet. Sobald allerdings weitere Module im selben Fahrplan die UTM-Grenze überschreiten, würde ich vermuten dass dann dort der Drehwinkel nicht passt.

[Maik Feller]

Wie ist das eigentlich aktuell wenn mein zwei Module von Zone 32 und 33 verknüpft,
kann man da jetzt schon ins Nachbar Modul fahre, würde der Zug von ein ins andre Streckenelement springen?

Wenn ja, währe ja da nur das Problem mit der Landschaft. Da könnte mang ja ein Modul als Dummy Landschaft in die andrer Zone transformieren.

[Carsten Hölscher]

Meine Überlegung wegen der Längenabweichung war, ob man eine Übergangs-/Anpassungszone einbaut, in der man in einer unkritischen Umgebung, am besten freie Strecke mit kurvigem Streckenverlauf, mit etwas Kreativität die Differnezen zweischen A und B ausgleicht, ohne dass es groß auffällt. Geht natürlich nicht, wenn wir von größeren Abständen reden.

Carsten

[Alwin Meschede]

Die andere Idee wäre also: Man schafft eine Möglichkeit, Streckenmodulen einen zweiten UTM-Referenzpunkt in einer anderen Zone mitgeben zu können.
Der Arbeitsstand meiner damaligen Experimente in Schönhausen ist noch im Oneshot-Repo.


Dieser Kegel hier steht genau auf dem UTM-Referenzpunkt des Streckenmoduls: Zone 33U; 301000 Ost / 5831000 Nord.
Transformiert in Zone 32 müsste sich laut Umrechner des Bundesamts für Geodäsie ergeben: 32U / 707394,08 Ost / 5831349,44 Nord.
Man könnte diesen Punkt in Zone 32 also im Streckenmodul hinterlegen. Er muss halt genügend Nachkommastellen haben.



Jetzt kommt der Elchtest: Dieser Kegel steht genau auf dem Punkt 33U / 297500 Ost / 5831500 Nord
Transformiert in Zone 32 müsste sich ergeben: 32U / 703864,54 Ost / 5831556,81 Nord.
Ob das allein durch Translation und z-Drehung des Streckenmoduls hinzukriegen ist, müsste man ausprobieren. Wenn man Pech hat, geht es nur mit Stauchung oder Zerrung.

[Carsten Hölscher]

Also der gelbe Kegel in den beiden Bildern zeigt den Versatz durch die andere UTM-Zone - richtig verstanden? Scheint ja durchaus ein respektabler Abstand zu sein - kannst das man grob ausmessen?

Carsten

[Alwin Meschede]

Also der gelbe Kegel in den beiden Bildern zeigt den Versatz durch die andere UTM-Zone - richtig verstanden?

Nein, die Kegel zeigen nicht den Versatz, sondern sollen nur der Überprüfbarkeit dienen, dass eine eventuelle Transformation auch hinreichend korrekte Werte ergibt.

Anleitung, um das Modul Schönhausen versuchsweise in die Zone 32 zu bringen:

• In der st3-Datei den neuen UTM-Punkt setzen: <UTM UTM_WE="707" UTM_NS="5831" UTM_Zone="32" UTM_Zone2="U"/>
• z-Drehung von Strecke und Landschaft um ca. +4,79°
• Da UTM-Referenzpunkte von Streckenmodulen derzeit nicht mit Nachkommastellen angegeben werden können, müssen Strecke und Landschaft noch um x = +394,08 und y=+349,44 verschoben werden.

Prüfung anhand der beiden Referenzkegel ergibt dann, dass das einigermaßen exakt ist. Die x-Koordinate des zweiten Prüfkegels liegt auf wenige Zentimeter exakt im Ziel, die y-Koordinate allerdings um 1,437 Meter daneben.

Wie sich das auswirkt, sieht man hier: Ich habe ein rudimentäres Modul "Hämerten" in Zone 32 geschaffen, das eigentlich nach bestem Wissen und Gewissen exakt an Schönhausen anschließen müsste. Es ergibt sich folgender Versatz:

[Jan]

Eine Idee: Für die logische Verknüpfung zwischen den Streckenmodulen (Hintergrundsimulation des Fahrplans) sollten irgendwelche Klaffungen in der 3D-Welt ja egal sein, die Züge fahren einfach die Streckenelemente ab und gut ist.

Für den optischen Übergang in der 3D-Welt könnte man die vereinfachte Transformation (also möglichst nur Schiebung und z-Drehung) dann einfach auf den aktuellen Kamerastandort (falls die Kamera einem Zug folgt, könnte man auch den zukünftigen Fahrweg des Zuges irgendwie auswerten – man weiß ja dann bereits im Voraus, wo ungefähr die nächste Querung der Zonengrenze stattfindet) optimieren. Wenn dann mit der gewählten Transformation am parallelen Streckenübergang 10 km weiter eine leichte Klaffung auftritt, ist das nicht weiter schlimm, da das ja niemand sieht. Wenn man dann mit der Kamera dorthin rüberspringt (oder später mit einem anderen Zug dort entlang fährt), kann man die Transformation entsprechend wieder auf den neuen Übergangsblickpunkt hin anpassen.

Ist vielleicht auch nicht die ganz ideale Lösung (könnte es passieren, dass mit wechselnder Transformation irgendwelche Berge am Horizont auf einmal merkbar springen? Was macht man mit Streckenführungen die eher parallel zur Zonengrenze verlaufen?), aber nur mal so laut in den Raum nachgedacht…

[F. Schn.]

@Carsten: Erst mal die grundlegende Frage: Wo hast du denn Funktionen im Einsatz, über die wir uns überhaupt Gedanken machen müssen?
* Einmal bei der Hauptlandschaft.
* Dann das der Vorladeradius die Landschaft rechtzeitig läd.
* Dann die graphische Position der Züge und Signale.
* Dann die Fahrplan-Spezialaktion "Abstand Zug". Da würde ich einfach sagen, dass die nicht für UTM-Übergreifende Aktionen unterstützt wird.
* Dann die ETCS-Funkzentralen. Da findet man auch eine Lösung.
* Edit: Den Sonnenstand

Das müsste es doch so ziemlich gewesen sein, oder? Physik der Züge läuft ja vermutlich direkt auf Basis der Länge von Streckenelementen ab, nicht von der Position von Streckenelementen.

Ich weiß nicht, mir scheint es, als hätte Alwin in den letzten paar Beiträgen da schon ein Konzept angenommen, das ziemlich identisch zu dem klingt, was ich vorschlagen würde:
* Zusi zeichnet immer nur eine UTM-Zone. Abstände über UTM-Zonen hinweg werden nicht berechnet, Landschaften nicht über UTM-Zonen hinweg angezeigt, ETCS-Funkabstände und Fahrplan-Abstände nicht berechnet.
* Es gibt ein Grenzmodul. Das wird zwar auch nur in einer UTM-Zone gebaut, aber bekommt einen Vektor und einen Winkel, wie man die Hauptlandschaft verschieben und drehen muss, damit sie in der anderen UTM-Zone ist. Damit diese Werte klein bleiben, bekommt er auch einen zweiten UTM-Punkt in der anderen Zone, auf den sich dieser Vektor dann bezieht.
* Wenn Zusi die "Nomale" UTM-Zone des Moduls zeichnet, zeichnet Zusi die Landschaft und den Vorladeradius wie bisher.
* Wenn Zusi die "Reserve-UTM-Zone" zeichnet,
** tut Zusi so, als hätte das Modul den Reserve-UTM-Punkt (auch bezügich Laden und Boundign-Radius)
** verschiebt/dreht Zusi zusätzlich zum UTM-Thema das Modul um den angegebenen Vektor.
** Die Verschiebung gilt für die Hauptlandschaft, Fahrzeuglandschaften und Singallandschaften.

Wann schaltet Zusi die UTM-Zone um? Man könnte dazu zwei Grenzmodule machen: Eines, das "Normalerweise" in der alten UTM-Zone liegt und eines, das "Normalerweise" in der neuen UTM-Zone liegt.
Den Vektor und den Winkel kann man bei dieser geringen Zahl an Modulen von Hand ausrechnen und in der St3-Datei hinterlegen. Den muss Zusi nicht während der Laufzeit bestimmen.

Zu Alwins Einwand mit den Zerrungen: Es müsste ja ausreichen, wenn der Prüfkegel an der Modulgrenze korrekt ist. Dass der zweite Prüfkegel in der Modulmitte ebenfalls korrekt ist, würde man in meinen Augen eh nie merken.

[Carsten Hölscher]

Ach so war das gedacht. Die ganzen Berechnungen könnte Zusi für die st3 auch schon beim Start der Simulation machen. Die Landschaft muss dann beim Laden noch transformiert werden, was in dem sowieso laufenden Ladethread passieren kann. Ist die Frage, ob man das wirklich so genau hinbekommt, dann es beim Übergang von A nach B nicht zuckt oder leichte Fehler in der Landchaft gibt. Und das Problem einer 2. Verbindung der Zonen im gleichen Fahrplan sehe ich auch.

Wie machen das denn anderen Simulatoren?

Carsten

[Maurice S.]

Wie machen das denn anderen Simulatoren?

Der Train Simulator legt beim Erstellen einer Strecke einen Referenzpunkt an. Von dort aus werden 1024x1024 Kacheln generiert, welche dann aufsteigenden/absteigenden nummeriert werden. Diese sind dann alle relativ zu einem Punkt der in einer UTM Zone liegt. Ich habe mal versucht über eine UTM-Zone zu bauen und es gab, wie zu erwarten, keine Probleme. Wie diese Abmessungen der Kacheln allerdings genau berechnet werden, kann ich dir nicht sagen. Genauso wenig weiß ich, ob man irgendwelche Streckungen und Stauchungen erfährt, je weiter man in den Norden/Süden vordringt.

Ob man das auf Zusi übertragen kann, weiß ich natürlich nicht, da man im Train Simulator nicht in Modulen baut und man sich deswegen theoretisch nur in einer Zone aufhält.

[jonathanp]

In Microsoft Train Simulator ist das Problem einfach nicht gelöst. Man kann nicht ohne große grafische Fehler über ein UTM Grenze bauen.

In DTG Train Simulator hat jede Route Package ein Anfangpunkt, und Tiles von ein anderes Route kann nur reingermerged(?) wenn das Anfangpunkt identisch ist. Also vermutlich das ganze Route benutzt die Zone dieser Punkt.

Ich glaube das Zusi equivalent wäre zu sagen, dass z.b. alle Deutsche Strecke benutzt ein bestimmtes UTM Zone, und für andere Länder oder grenzüberschreitenden Strecke jemand muss einfach entschieden welches Zone am sinnvollsten ist für das Netz. Nicht geographische schön, aber viel einfacher als Alternativen.

[F. Schn.]

Ich kenne mich leider bei keiner anderen Simulationen, die UTM-Basiert so etwas macht, aus, in so fern kann ich da wenig sagen.

Eine 2. Verbindung zwischen zwei anderen Modulen außerhalb der Sichtweite, der UTM-Grenze wäre IMHO unproblematisch, weil es Zusi ja egal seien müsste, ob die Grenzmodule in der einen UTM-Zone den gleichen Abstand zueinander haben, wie in der anderen UTM-Zone und beide Module individuelle Verschiebungen haben können.
Eine 2. Verbindung im selben Modul innerhalb der Sichtweite sehe ich auch als unproblematisch, weil alles ja um den selben Vektor/Winkel verschoben wird.

Das Problem, das beim Laden der Landschaft zu machen ist, dass die Landschaft für beide Zonen beide im Grafikkartenspeicher zur Verfügung stehen muss, in dem Moment, wo die UTM-Zone gewechselt wird. Wenn man hier zur Laufzeit einfach eine andere Matrix nimmt, wäre das der Landschaft ja egal. Wenn man das beim Laden macht, muss man da aufpassen.

[Christian Sch.]

Hallo,

mir erschließt sich gerade nicht, wie es zu der Drehung kommt.

Wir haben zwei 360km breite Streifen kariertes Papier (Zonen 31U und 32U) mit einem kartesischen Koordinatensystem. Dann suchen wir uns auf beiden einen gemeinsamen Punkt, z.B. den gelben Kegel. Wir falten beide Streifen an einer Nord-Süd-Linie durch den gemeinsamen Punkt und legen die Streifen nebeneinander...

Schlussfolgerung: Translation reicht. Und das dürfte auch nur die Ost-West-Lage betreffen.

Oder übersehe ich was?

Worst Case für Gedankenexperimente wäre dann eine Strecke, die über die Zonengrenze hinweg schlängelt.

Anderer Ansatz: UTM Zone 1 -> WGS84 -> UTM Zone 2

Gruß
Christian

[F. Schn.]

Ja. Die zwei Streifen haben schon einen Winkel, bevor du anfängst zu falten, weil das UTM-System die x-Achse beider Streifen nach Norden zeigen lassen will. Und da die Streifen durch die Kugelform der Erde entstehen, ist der Winkel schon da. Analogie: Du willst einen Kreis in 8 Linien-UTM-Zonen einteilen. Du willst, dass jede UTM-Zonen-Linie in etwa den selben Abstand zum Zentrum hat. Also brauchst du ein regelmäßiges Achteck. Und das hat nun mal Winkel.

[Jan]

* Dann die Fahrplan-Spezialaktion "Abstand Zug". Da würde ich einfach sagen, dass die nicht für UTM-Übergreifende Aktionen unterstützt wird.

Da wäre die Frage, über was für Abweichungen wir bei dieser Art von vereinfachter Transformation reden? Während man für den optischen Übergangspunkt ja schon eine relativ hohe Genauigkeit braucht, kommt es beim Fahrplanthema nicht auf den letzten Meter an.

Wenn sich wenigstens einer der Züge im Bereich der Übergangsmodule mit der doppelten UTM-Punkt-Definition befindet, kann man ja die Koordinaten entsprechend umrechnen und so zumindest näherungsweise einen Abstand bestimmen. Wenn beide Züge außerhalb des Übergangsbereich und in jeweils unterschiedlichen Zonen sind, und niemandem noch was besseres einfällt (irgendeine vereinfachte, global gültige Transformation, die idealerweise auch nicht zu rechenaufwändig ist? Solange der prozentuale Fehler bei der Abstandsberechnung nicht zu extrem wird, muss es ja nicht supergenau sein…), gibt der Simulator dann nur in dem Fall als Ersatzwert den im jeweiligen Zahlenformat maximal möglichen Abstand aus.

Wann schaltet Zusi die UTM-Zone um? Man könnte dazu zwei Grenzmodule machen: Eines, das "Normalerweise" in der alten UTM-Zone liegt und eines, das "Normalerweise" in der neuen UTM-Zone liegt.
Den Vektor und den Winkel kann man bei dieser geringen Zahl an Modulen von Hand ausrechnen und in der St3-Datei hinterlegen. Den muss Zusi nicht während der Laufzeit bestimmen.

Je nach Modulzuschnitt und wie markant und bewegt die Streckentopographie ist, bräuchte man im Einzelfall vielleicht auch ein Modul extra auf einer oder beiden Seite der Zonengrenze? Die Flexibilität sollte der Ansatz dann vielleicht auch noch erlauben…

Das Problem, das beim Laden der Landschaft zu machen ist, dass die Landschaft für beide Zonen beide im Grafikkartenspeicher zur Verfügung stehen muss, in dem Moment, wo die UTM-Zone gewechselt wird. Wenn man hier zur Laufzeit einfach eine andere Matrix nimmt, wäre das der Landschaft ja egal. Wenn man das beim Laden macht, muss man da aufpassen.

Ist der UTM-Punkt nicht sowieso dynamisch, weil man mit großen Streckennetzen und fixem UTM-Punkt für die 3D-Welt an die Rechengenauigkeit der Zahlenformate gekommen ist?

[F(R)S-Bauer]

Hallo,

nur mal zu Berücksichtigung,

wir haben ja nicht nur 32U und 33U, Richtung Frankreich kommt noch 31U dazu. Also ein Sprung alleine ist es nicht.

Das UTM System behilft sich zum Krümmungsausgleich mit 3-Eck Stücken, die entweder Abschnitten oder angefügt werden.

Hier mal ein Verweis: http://kartenkunde-leichtgemacht.de/han ... tensysteme

Daher müsste meiner Ansicht nach das Randmodul entsprechen gekürzt werden, und ähnlich wie schon angesprochen ein Zwischenstreifen gebaut werden.
Und damit laufen wir auf das Problem, das die Längen nicht passen.

Das ganze klappt nur, wenn wir das Gelände auf eine Kugel aufziehen. Fraglich, ob das Simulationstechnich Händelbar ist.

Erste Frage wäre, wenn wir die Zonengrenzen von Nord nach Süd betrachten, wie hoch sind die Differenzmaße?
Reden wir über Strecken < 1Km dürfte das machbar sein.

Kann der Roland Ziegler hier nicht mal in seine Unterlagen schauen, worüber wir da eigentlich reden?

Gruß

Ralf