Fahrweg beidseitig befahrbar

[Jan Bochmann]

Guten Tag,

Hallo,

das Problem dürfte wohl sein, dass eine Halbierung des Gleismittenabstandes noch nicht ausreicht, wenn man wirklich ganz exakt bauen will:

Derzeit ist ein Element 15,625m breit (Maßstab 1:64).
Vorgeschlagen wird eine Halbierung auf 7,8125m.
Realistisch ist in Bahnhöfen ein Gleismittenabstand von ca. 5m.

Bei regelspurigen Eisenbahnen mit typischem mitteleuropäischen Profil. In den USA und Rußland ist es mehr, in UK ist es weniger. Bei modernen Straßenbahn- oder Stadtbahnstrecken sind es 3m, bei älteren Strecken noch weniger.

Mit den 7.8m wäre man aber wohl schon so gut wie viele Modellbahn-Gleissysteme. Da ist der Abstand auch zu groß, damit sich in den viel zu engen Bögen auch Züge begegnen können.

Grüße
Jan B.

[Jan Bochmann]

Guten Tag,

Nochmal Hallo !!

Dass das nur auf eine 3D-Grafik hinauslaufen kann, ist dir aber klar?

Ja.

Schließlich müssten ja auch die Fahrzeuge diese freie Gleisgeometrie befahren

Da sehe ich erstmal keine Probleme. Das Programm errechnet sich schon jetzt aus den Seitenansichten die 45° Ansicht...

Dieser Kompromiß funktioniert aber nur bei Fahrzeugen mit flachen Kanten halbwegs, also bei mehr oder weniger bunten Schuhkartons. Auch da stimmen die Relationen nicht wirklich.

wo das Bild ruckelt, wenn mehr als 20 Bäume und 3 Züge auf dem Bildschirm sind...

Schlimmer kann es kaum noch werden. Das habe ich seit dem Umstieg auf Version 3.85 im Wandernetz mit meinem alten 1,5 GHz Rechner schon jetzt...

Hier unterschätzt Du die Komplexität. Es kann sogar noch sehr viel schlimmer werden. Von 3.84 auf 3.85 hat sich der Rechenaufwand beim Bewegen der Züge verdoppelt, aufgrund der Halbierung der Schrittweite. Eine Umstellung auf ein 3-D-Modell intern (noch unabhängig von der grafischen Ausgabe) würde weit mehr als nur eine Verdopplung erfordern.

"20 Bäume und 3 Züge" sind zwar etwas extrem formuliert, aber auch 5000 Bäume und 500 Züge sind eine Grenze, die ich für BAHN nicht akzeptiere. Ich muß mir zwar regelmäßig den Vorwurf anhören, daß ich mit BAHN immer wieder für eine Überlastung der Hardware sorgen würde, aber das Gegenteil ist der Fall: Ich bekomme jede Menge Vorschläge, die genau dazu führen würden, und ich blocke 90% davon ab bzw. verschiebe sie um Jahre, bis halbwegs geeignete Computer zur Verfügung stehen.

Grüße
Jan B.

[Jan Bochmann]

Guten Tag,

...
Jetzt zu den Elementen: Eine Halbierung der Elementgröße halte ich aus zwei Gründen nicht für sinnvoll:

1. Das Spielfeld wäre dann 64000 x 64000 Elemente groß, böte aber nicht mehr Platz, denn die geografische Relation der Städte bliebe die gleiche wie bisher.

D.h. alle bestehenden Netze würden weiter funktionieren und passen, ohne Änderung des Maßstabs. Die Forderung nach "mehr Platz" im Sinne der gesamten Ausdehnung ist im Moment nicht so häufig zu vernehmen, d.h. da besteht offenbar erstmal eine gewisse Sättigung.

Aber allein für die Koordinaten würde nun die vierfache Anzahl an Bytes benötigt werden.

Nein. Eine Viertelung der Elemente ergäbe eine Verdopplung der Koordinaten in x- und y-Richtung. Die Koordinaten sind derzeit mit 16 bit kodiert, also wären 0..65535 genauso möglich wie 0..32767. Es gibt keine Hardware, die mit 15 bit oder 17 bit effektiv arbeiten kann. Der nächste Schritt wären daher 32 oder im Extremfall 24, aber es wäre für diesen Vorschlag noch gar nicht nötig.

Nun, könnte JanBo seinen Werbespruch ja modifizieren in "Jetzt mit immens viel Speicherbedarf".

Die Zahl der Elemente pro Netz würde sich vervierfachen (zumindest theoretisch; praktisch wären aber viele leere Elemente dabei, die zwar Hauptspeicher benötigen, aber wenigstens in den Netzdateien platzsparend unterzubringen sind). Dafür würde aber die Zahl der möglichen Elemente etwa gleich bleiben, d.h. die Kodierung der Elemente mit derzeit 16 bit könnte wohl beibehalten werden.

Bei der anderen Variante mit den vielen neuen Elementen bliebe die Zahl der Elemente pro Netz etwa gleich. Dafür würden aber 16 bit nicht mehr zur Unterscheidung der Elemente reichen und diese müßten auf 24 oder besser 32 erweitert werden. Von diesen 16 bit wird derzeit eines verwendet, um ein Element als Teil eines reservierten Abschnitts zu markieren. Bei zulässigen maximal 4 Zügen pro Element bräuchten wir da bereits 4 bit (nicht verwechseln: für 4 Zustände braucht man nur 2 bit, aber damit könnte man nur die Anzahl darstellen, aber nicht die Position im Element).

Gleichwohl bleibt u.a das Problem der Weichen:
Die Anzahl aller möglichen Kombination wird mehrere! Hundert betragen... das muss man erstmal sacken lassen.

Ja. Und dazu wäre zu bemerken, daß die Gedanken im anderen Thread "3-Schienen-Gleis" hierfür genauso gelten.

Eine Lösung sehe ich in einer Art Modulbaukasten: Die Grundformen der neuen Gleise werden ebenso wie die alten aus dem Statusfenster geholt - wie auch immer ermöglicht, sollten sie dann durch Teile aus dem Baukasten erweitert werden können...

Intern und grafisch ist das schon heute so. BAHN enthält nicht tausende handgezeichnete Fahrweggrafiken, sondern setzt diese aus Bauteilen zusammen wie Schienen, Schwellen, Schotter, Markierungspunkte. Die Regeln dazu sind aber fest im Programm kodiert und nicht flexibel einzugeben. Diese Eingabe wäre nicht ganz einfach. Außerdem müßte das dann im Streckennetz am betreffenden Element gespeichert werden, was den Speicherbedarf immens nach oben treiben würde.

Abgesehen davon ist zu bedenken, daß es hier erstmal nur um die Grafik geht. Diese hat aber absolut nichts mit der Funktion zu tun. Für einen Zug in BAHN ist das völlig egal, was für bunte Punkte da nun zu sehen sind. Er sieht sie sowieso nicht, sondern nur z.B. "Da kommt ein Element Nr. 1785". Nur der Mensch sieht statt der 1785 eine Grafik und denkt sich daraus eine Funktion aus. Diese Funktion muß er aber dem Computer beibringen. Auch diese Eingabe ist alles andere als einfach und daher z.Zt. fest im Programm kodiert.

Und um das Rad nicht immer neu erfinden zu müssen, wäre es schön, solcherart erstellte Symbole in einem separaten Menü zur Verfügung zu haben und durch Eingabe einer dreistelligen Zahl einbauen zu können (drei Ziffern reichen doch, hoffe ich?).

Es sieht eher nach 4 Ziffern aus, oder nach einer Kombination aus 3 Ziffern und anderen Zusatzinfos wie z.B. Fahrwegtyp.

Grüße
Jan B.

[GNock]

Guten Tag BAHN-Gemeinde,

erstmal herzlichen Dank an Jan für diese Informationen, die zudem dazu beitragen werden, dass diese Diskussion nicht allzu sehr ins Spekulative schwenkt.

Aber allein für die Koordinaten würde nun die vierfache Anzahl an Bytes benötigt werden.

Nein. Eine Viertelung der Elemente ergäbe eine Verdopplung der Koordinaten in x- und y-Richtung. Die Koordinaten sind derzeit mit 16 bit kodiert, also wären 0..65535 genauso möglich wie 0..32767. Es gibt keine Hardware, die mit 15 bit oder 17 bit effektiv arbeiten kann. Der nächste Schritt wären daher 32 oder im Extremfall 24, aber es wäre für diesen Vorschlag noch gar nicht nötig.

...

Die Zahl der Elemente pro Netz würde sich vervierfachen (zumindest theoretisch; praktisch wären aber viele leere Elemente dabei, die zwar Hauptspeicher benötigen, aber wenigstens in den Netzdateien platzsparend unterzubringen sind). Dafür würde aber die Zahl der möglichen Elemente etwa gleich bleiben, d.h. die Kodierung der Elemente mit derzeit 16 bit könnte wohl beibehalten werden.

Genau das meinte ich: Eine Verdopplung der Koordinaten in x-Richtung multipliziert mit der Verdopplung der Koordinaten in y-Richtung ergeben eine Vervierfachung der Bytes zur Verortung der Funktionselemente wie Weichen, Lafas etc. Für die reinen Streckenelemente wird Jan eine "komprimitivere" Methode nutzen.

Eine Lösung sehe ich in einer Art Modulbaukasten: Die Grundformen der neuen Gleise werden ebenso wie die alten aus dem Statusfenster geholt - wie auch immer ermöglicht, sollten sie dann durch Teile aus dem Baukasten erweitert werden können...

Intern und grafisch ist das schon heute so. BAHN enthält nicht tausende handgezeichnete Fahrweggrafiken, sondern setzt diese aus Bauteilen zusammen wie Schienen, Schwellen, Schotter, Markierungspunkte. Die Regeln dazu sind aber fest im Programm kodiert und nicht flexibel einzugeben. Diese Eingabe wäre nicht ganz einfach. Außerdem müßte das dann im Streckennetz am betreffenden Element gespeichert werden, was den Speicherbedarf immens nach oben treiben würde.

So ist es, denn alle Information, die z.B. für einen doppelten Gleiswechsel in West-Ost-Richtung für jetzt vier Elemente vorhanden sind, müssen dann einem Element zugeordnet werden.

Und um das Rad nicht immer neu erfinden zu müssen, wäre es schön, solcherart erstellte Symbole in einem separaten Menü zur Verfügung zu haben und durch Eingabe einer dreistelligen Zahl einbauen zu können (drei Ziffern reichen doch, hoffe ich?).

Es sieht eher nach 4 Ziffern aus, oder nach einer Kombination aus 3 Ziffern und anderen Zusatzinfos wie z.B. Fahrwegtyp.

Eine Kombination mit Buchstaben hat den unbestreitbaren Vorteil, dass sich aus einem Buchstaben 26 Variationen ableiten lassen.

Schöne Grüße
Gerd

[Han_Solo1981]

Moin zusammen,

da die Umsetzung der Fahrwegsymbole(neu) nicht so einfach zu sein scheint, kam mir die Idee
das man vielleicht als ersten step der Umsetzung, Nutzerdefinierte Fahrwegsymbole(Alt) mit ins Programm einbettet,
Ähnlich wie bei den Signalen. Die Funktion an sich würde im Hintergrund bleiben wie bisher nur die angezeigte Grafik könnte man sich dann so anpassen wie sie gebraucht wird.
Beispiele:

Zugewachsenen Prellbock
Feste Fahrbahn
etc.

das hat den Vorteil das man nach einiger Zeit sehen kann was die User an grafiken selbst entwickeln und wo der Bedarf ist.
Diese Symbole könnte man dann hinterher als Feste Symbole mit in Bahn einbauen.
Das wäre auf jedenfall im Bereich der Fahrwege ein großer Schritt nach vorne.

Gruß

Mark

[Rolf R]

@Han_Solo 1981:

da die Umsetzung der Fahrwegsymbole(neu) nicht so einfach zu sein scheint, kam mir die Idee
das man vielleicht als ersten step der Umsetzung, Nutzerdefinierte Fahrwegsymbole(Alt) mit ins Programm einbettet,

Prinzipiell wäre das wirklich ein 1. Schritt.

Das Problem besteht aber darin, dass Du hiermit natürlich nur das Angebot an Gleisen erhöhen kannst, das die Geometrie
des aktuellen System zu Grunde legt.

Also: schmalerer Gleismittenabstand oder 22,5 Grad Weichen könnten damit nicht gebaut werden. Somit wird man natürlich
nicht alle Kundenwünsche erfüllen können, wie gefordert:

das hat den Vorteil das man nach einiger Zeit sehen kann was die User an grafiken selbst entwickeln und wo der Bedarf ist.
Diese Symbole könnte man dann hinterher als Feste Symbole mit in Bahn einbauen.

Die Fahrwege sind ja Rechenleistungen von BAHN - damit auch z.B. Kurven oder Weichen. Und dazu müsste Jan Bochmann in
BAHN den Zügen veränderte Bewegungsbefehle mitgeben, was aber nur auf Programmierebene machbar sein wird.

Aber zum Verbessern des Angebotes mit Dingen wie den zugewachsenen Prellbock oder für die feste Fahrbahn wäre ein
benutzerdefiniertes Gleismaterial durchaus wünschenswert.

Grüße

Rolf

[MartinL]

"Die Genialität einer Konstruktion liegt in ihrer Einfachheit - Kompliziert bauen kann jeder." (Sergei Pawlowitsch Koroljow)

Ein Fahrwegsymbol doppelseitig zu befahren macht doch alles zu kompliziert, dazu wären eine Vielzahl neuer Fahrwegsymbole notwendig. Am einfachsten wäre es doch, die Möglichkeit zu schaffen, statt max. 90 Elemente/km auch einen anderen Maßstab wählen zu können. Dann wäre eine 2spurige Straße statt 22,2m (bei 90E/km) eben vielleicht nur noch 8m breit. Mit der neusten BAHN-Version lassen sich ja eh schon höhere und größere Symbole zeichnen.

War nur so eine Idee ...

[Zylvanyian]

Hoffe die Idee wurde nicht schon gepostet und abgelehnt: Vielleicht eine einfachere Variante: Jeder Zug kann einen Status "FRONTAL- (und NUR Frontal-) kollisionen ignorieren" haben, den man manuell im Edit/Erstellungsfenster, evtl. auch am DW ein- und ausschalten kann. Wenn man es ganz präzise möchte müsste man es natürlich so einrichten, dass dies nur bei Fahrzeugen des Fahrwegs "Straße" funktioniert.

MfG, Mike

[Rednael_186]

Guten Tag zusammen,

ich weiß, dieser Thread ist schon eine Weile alt, trotzdem ließ mich die Thematik nicht los, und ein Paar Gedankenspiele wurden ausprobiert.

Zu der prinzipiellen Idee, den Gleisabstand zu halbieren, wollte ich noch ein Bild hinzufügen: Hier wurden bisher nur "vertikale" Ansichten gezeigt, da das Problem dort am offensichtlichsten ist, bzw. dort wäre der halbierte Gleisabstand ohne Frage wünschenswert.
Nun wollte ich aber zur Diskussion stellen, ob denn auch in der Darstellung links-rechts diese Überlegung zielführend ist:

4-gleisige Strecke.jpg

Gerade bei 4- oder gar 6-gleisigen Strecken graust es mir vor der Aussicht, dass diese irgendwann so aussehen könnten; wie sollen denn da noch einigermaßen übersichtlich Signale, Schaltkontakte oder Weichen platziert werden?

War zumindest mein erster Eindruck nach dem Ausprobieren der eventuellen Gleisgeometrie.
Eine wirkliche Lösung kann ich aber auch nicht anbieten; die erste Idee, die mir durch den Kopf schoss (den Betrachtungswinkel geringfügig zu versteilern) ist wohl wegen der benötigten Neuzeichnung aller Dachansichten der Fahrzeuge kaum umsetzbar.

Mehr Gefallen fand bei mir allerdings die Möglichkeit, benutzerdefinierte Gleissymbole zu erstellen. Interessant wäre dabei die Möglichkeit, (in einem neuen oder dafür angepassten Editor) unter frei zu zeichnende Grafiksymbole eine "Gleisfunktion" zu legen. Sprich in einer neuen Registerkarte o.ä. kann die Funktion als Gerade, Kurve, Weiche... eingestellt werden.
Das hätte den Vorteil, keinen Standartplatz im Programm zu belegen (als "Nutzerdefinierter Fahrweg"), die Funktion kann weiterhin fest im Programm verankert bleiben, und auch die Grafischen Möglichkeiten wären quasi unendlich, nur dass halt die Funktion und das Abknicken der Züge keine Änderung erfährt.

Zur Darstellung der Züge z.B. in fünf verschiedenen Ansichten 0°, 22,5°, 45°, 67,5° und 90° fällt mir nämlich auch nichts ein, was nicht einen immensen Mehraufwand an Rechenleistung bedeuten würde.

Denkbar wären mit diesem Mittel auch weite Kurven, die Zwar den Zügen nichts bringen, aber über mehrere einzelne Elemente 0° und 45° sanft verknüpfen, oder schlanke Weichen. Auch hier würden die Züge vorerst einfach an den beiden inneren Elementen zum nächsten Gleis "knicken", allerdings wäre eine nachträgliche verfeinerung der Darstellung ja immernoch möglich. Dazu das zweite und dritte Bild:

22,5°-Weiche.jpg

Eine solche schlanke Weichenverbindung macht halt optisch was her, auch wenn die Züge erstmal noch abknicken.

Weichenformen etc..jpg

Wobei Grau schlichtweg nutzerdefinierte Elemente sein sollen. Erstere graue Konstruktion entspricht der schlanken Weichenverbindung, zweitere einer sanften Kurve. In grün der tatsächliche Gleisverlauf.

Ich bin mir nicht sicher, in wie fern diese Überlegungen zielführend sind, aber ich wollte einfach noch einmal einen Denkanstoß in dieser Richtung liefern.

MfG Leander

[Rolf R]

Hallo Leander,

wenn Du eine Gleisgeometrie auf dem Markt wirfst, die auch 22,5°-Winkel berücksichtigt, hast Du natürlich noch ein Problem:

Du musst für jedes Element, dass in BAHN als Diagonale erhältlich ist (incl. Funktionsgleise, Signale etc.....) zusätzlich 8 mögliche Einsatzmöglichkeiten berücksichtigen, weil die Gleisdiagonalen mit dem 22,5°-Winkel ja auch unterschiedliche Ausgangslagen
berücksichtigen könnten.
Das würde natürlich auch schon ein enormer Aufwand sein.

Klar - eine schlanke Weichenverbindung als 45° macht was her - gerade auch noch in Verbindung mit einem engeren Gleismitten-
abstand -, aber auch viel Arbeit.
Außerdem stellt sich natürlich auch die Frage, wie es aussieht, wenn sich die Fahrzeuge auf kleinerem Abstand begegnen - ob sie
beispielsweise nicht zu wuchtig erscheinen. Die Relation von Fzg-Breite und Fzg-Abstand verändert sich dann auch.

Und die wichtigste Frage: Kann das mein Rechner noch verpacken?

Das wären so meine Gedanken/Bedenken zum Thema...

Viele Grüße
Rolf

[Rednael_186]

Guten Abend Rolf,

nur kurz zu deinen Einwänden:
Diese hatte ich auch, weshalb ich schrieb (oder es zumindest versuchte ), dass ich keine Möglichkeit sehe für 22,5°-Weichen und Elemente; außerdem wollte ich ja die Idee des engeren Gleismittenabstands eher kritisch hinterfragen mit dem ersten Bild.
Ich wollte mehr auf die Möglichkeit einer Umsetzung nutzerdefinierter Fahrwege raus, ohne die von Jan Bochmann beschriebene feste Einbindung der Funktionen in das Programm aufheben zu müssen.

Gut möglich, dass ich manchmal etwas wirr schreibe, daher das nochmal zusammengefasst .

MfG Leander

Edit: habe das letzte Bild im obigen Beitrag getauscht, um die Sache evtl. etwas klarer zu machen.

[GNock]

Hallo Leander und Rolf,

ohne jetzt schon in die Diskussion über eine erweiterte Geometrie eintreten zu wollen, möchte ich zu bedenken geben, dass es keine Kurve 0° - 22,5° - 45° - 67,5° - 90° geben wird, weil es kein in die Geometrie passendes Kurvensymbol gibt, dass eine Veränderung des Winkels von 22,5° auf 45° bzw. von 45° auf 67,5° erlaubt . jedenfalls in Zoom 1:1 oder höher. Da nützt es auch nichts, dass sich dieser Verlauf im abstrakten Modus wunderbar darstellen ließe.

Natürlich befürworte ich eine Erweiterung um 22,5°- und 67,5°-Gleise, aber wenn ich eine 90°-Kurve bauen will, müsste ich mich entscheiden, ob ich sie mittels 45°-Diagonale oder 22,5°-/ 67,5°-Schräge realisiere.

Schöne Grüße
Gerd

[Jan Bochmann]

Guten Tag,

Guten Tag zusammen,

ich weiß, dieser Thread ist schon eine Weile alt, trotzdem ließ mich die Thematik nicht los, und ein Paar Gedankenspiele wurden ausprobiert.

Zu der prinzipiellen Idee, den Gleisabstand zu halbieren, wollte ich noch ein Bild hinzufügen: Hier wurden bisher nur "vertikale" Ansichten gezeigt, da das Problem dort am offensichtlichsten ist, bzw. dort wäre der halbierte Gleisabstand ohne Frage wünschenswert.
Nun wollte ich aber zur Diskussion stellen, ob denn auch in der Darstellung links-rechts diese Überlegung zielführend ist:

4-gleisige Strecke.jpg

Gerade bei 4- oder gar 6-gleisigen Strecken graust es mir vor der Aussicht, dass diese irgendwann so aussehen könnten; wie sollen denn da noch einigermaßen übersichtlich Signale, Schaltkontakte oder Weichen platziert werden?

Indem man immer nach 2 Gleisen einen größeren Abstand läßt. Das macht man beim Vorbild auch so, wenn es der Platz irgendwie ermöglicht. In dieser Lücke stehen dann Signale, Fahrleitungsmasten etc. Sie ist außerdem wichtig, damit sich dort auch jemand sicher aufhalten kann, wenn auf mehreren benachbarten Gleisen Züge vorbeikommen. "Jemand" meint Leute, die dort aus beruflichen Gründen zu tun haben.

Wenn der Platz nicht reicht, dann ist die zweitbeste Lösung die Anordnung von Signalen auf Signalbrücken und Fahrleitungen an Quertragwerken. In BAHN ist das allerdings schwieriger.

Mehr Gefallen fand bei mir allerdings die Möglichkeit, benutzerdefinierte Gleissymbole zu erstellen. Interessant wäre dabei die Möglichkeit, (in einem neuen oder dafür angepassten Editor) unter frei zu zeichnende Grafiksymbole eine "Gleisfunktion" zu legen. Sprich in einer neuen Registerkarte o.ä. kann die Funktion als Gerade, Kurve, Weiche... eingestellt werden.
Das hätte den Vorteil, keinen Standartplatz im Programm zu belegen (als "Nutzerdefinierter Fahrweg"), die Funktion kann weiterhin fest im Programm verankert bleiben, und auch die Grafischen Möglichkeiten wären quasi unendlich, nur dass halt die Funktion und das Abknicken der Züge keine Änderung erfährt.

Das wird es in gewissen Grenzen in Zukunft geben.

Grüße
Jan B.

[Jan Eisold]

Hallo !

Gerade bei 4- oder gar 6-gleisigen Strecken graust es mir vor der Aussicht, dass diese irgendwann so aussehen könnten; wie sollen denn da noch einigermaßen übersichtlich Signale, Schaltkontakte oder Weichen platziert werden?

Indem man immer nach 2 Gleisen einen größeren Abstand läßt. Das macht man beim Vorbild auch so, wenn es der Platz irgendwie ermöglicht. In dieser Lücke stehen dann Signale, Fahrleitungsmasten etc. Sie ist außerdem wichtig, damit sich dort auch jemand sicher aufhalten kann, wenn auf mehreren benachbarten Gleisen Züge vorbeikommen. "Jemand" meint Leute, die dort aus beruflichen Gründen zu tun haben.

Wenn der Platz nicht reicht, dann ist die zweitbeste Lösung die Anordnung von Signalen auf Signalbrücken und Fahrleitungen an Quertragwerken. In BAHN ist das allerdings schwieriger.

Prinzipiell wird auch beim Vorbild der Gleismittenabstand vergrößert, wenn man Signale, Fahrleitungsmasten oder Sicherheitsräume (für Personen nach jedem zweiten Gleis) unterbringen muss. Allerdings bewegt man sich da in einem Bereich, der in BAHN eigentlich gar nicht darstellbar ist. Als Beipiele mal ein paar Mindestwerte gemäß Planungsrichtlinie:

Gleismittenabstand zweigleisige Strecke: 4,00m (normale Verhältnisse, keine HGV-Strecke)
Gleismittenabstand zwischen zwei Gleisen, um Signale aufzustellen: mindestens 4,50m
Gleismittenabstand für Sicherheitsraum zwischen zwei Gleisen bei v=160km/h: 5,80m
Gleismittenabstand für Aufstellen von Masten, sogenannte Mastgasse: 6,40m

Wenn der Maßstab derzeit 64 Elemente pro Kilometer ist, wäre ein Element ca. 15,6m breit. Bei einer Halbierung der Elementgröße also noch ca. 7,8m. Der Bereich, indem sich die Unterschiede o.g. Gleismittenabstände bewegen, macht aber gerademal 2,4m aus. Das wäre etwa ein Drittel Element. Übrigens sehen mehrere hintereinander liegende Gleise beim Vorbild von schräg oben auch nicht anders aus als eine breite Schotterfläche. Die größeren Abstände nach jedem zweiten Gleis fallen höchstens durch dezenten Bewuchs auf.

Meiner Meinung nach gibt es aber in der BAHN-Ansicht noch ein größeres Problem: Derzeit sieht man bei einem Gleis in Ost-West-Richtung den Zug quasi fast genau von der Seite. Das Gleis jedoch von schräg oben. Wobei das Problem der Zug ist: Den müsste man auch von schräg oben sehen, also die Höhe der Seitenfront leicht verkürzt. Dafür müsste das Dach zu sehen sein, so wie bei Gebäuden. Alle Fahrzeuggrafiken auf diese Pseudo-3D-Ansicht umzuzeichnen ist aber wohl auch nicht zu schaffen. Solange dieses Problem nicht gelöst ist, sollten optische Irritationen durch zu geringen Gleisabstand eigentlich nebensächlich sein...

MfG Jan

[Dierk Nüchtern]

Vor ein paar Jahren gab es ja einige User, die diese "Pseudo-3D-Fahrzeuge" gezeichnet haben. Ich weiß gar nicht, ob es diese noch gibt.

Gut, in der Umstellungsphase mti den Front-/Heckansichten gab es ja auch beides. Von daher wäre sowas sicher nicht ganz so kritisch zu sehen.