Buchfahrplan-DLL mit CSV-Zwischenebene

[Alwin Meschede]

Es wäre überraschend, wenn im Gegengleis ein anderer Zugfunkkanal gelten würde Deswegen druckt das Vorbild nur den oberen Eintrag an.

[F. Schn.]

Neu in Version 3.0.9.24: https://pkeus.de/~philipp/Zusi/3/Zusatz ... 0.9.24.zip" target="_blank

Neu: Zugdateien können in Fahrplandatei enthalten sein (Präprozessor)
Neu: Konfigurierbarkeit von Linien in Grafiken und des TextRenderingHint
Change: Gegengleiszuordnung km-Sprünge mit Nicht-km-Sprüngen verboten
Fix: Einträge ohne Kilometrierung (klassischerweise ZBF-Einträge) konnten im Regelfall ihren Gegengleispartner nicht finden.

[F. Schn.]

Neu in Version 3.0.9.25: https://pkeus.de/~philipp/Zusi/3/Zusatz ... 0.9.25.zip" target="_blank

Change: Fußnoten anstatt Gegengleisklammern
Noch mal intensiv nach kleinkram Gesucht:
Fix: Kombiniertes XML+CSV hat CSV ersetzt
Change: Schmales Leerzeichen vor Fußnoten
Fix: Verarbeitung fast-Leerer XML-Dateien (also ohne eine einzige Zeile)
Fix: Verarbeitungsabbruch bei fehlender Kilometrierung im Gegengleis
Change: Interne Selbstchecks verbessert
Fix: Einstellung DrawingLines wirkte nicht auf LZB-Rahmen und diverse Größenkontrollen
Fix: Workaround Klammer konnte zu zu klein berechneten Breiten führen
Fix: Verarbeitungsabbruch bei zu langen Zahlenketten im Dateinamen
Fix: Doppelt Vorkommende Dateien: Dateiname wird beim Verarbeitungsabbruch angegeben

[Jan]

Zweites subtiles Problem: Leider hat die Bahnschrift offenbar nur proportionalbreite Ziffern an Bord, und gerade bei den Kilometerangaben, insbesondere in der Spalte 3b, fällt das dann doch etwas auf (z.B. 106,1 und 105,4). Leider liefert Bahnschrift wie gesagt offenbar keine Tabellenziffern mit, sodass eine Lösung dafür wohl etwas komplizierte werden könnte…

Zur Info – Bahnschrift 2.06 (vermutlich ab Windows Version 2004) soll auch Tabellenziffern als OpenType-Feature mitbringen. Wäre es möglich, das im Fontrendering entsprechend anzufordern?

[F. Schn.]

Uff.... Du hast nicht Zufällig irgendwo Hinweise auf eine API, (am besten von GDI oder GDI+) entdeckt, die Font Variationen für Programmierer zugänglich macht?

[Jan]

Hmm, in der Hinsicht hatte ich mich damit auch überhaupt nicht beschäftigt, gute Frage… Ich kann also keine Garantie auf Vollständigkeit geben, aber in Richtung GDI/GDI+ scheint es in der Tat eher schlecht auszusehen. Alles was ich auf die Schnelle gefunden habe, deutet auf WPF (aber keine Ahnung, ob man da nur das Textrendering sinnvoll in eine nicht WPF-Anwendung entführen kann?), DirectWrite, Uniscribe? oder Bibliotheken von Dritten à la FreeType oder sonstige Eigenkreationen hin.

[F. Schn.]

So, ich habe mir einige Gedanken zu dem Thema gemacht, konnte mich aber letztenendes nicht dazu durchringen, dort umfangreich umzubauen. Ich denke, ich werde es erst mal so lassen. Wenn ich zufällig Lust habe, reiche ich dort vielleicht noch etwas nach, andernfalls lasse ich es so.

Ich habe jetzt nur noch kleine Änderungen gemacht. Unter anderem kann man jetzt große Sammel-PDFs drucken.
https://pkeus.de/~philipp/Zusi/3/Zusatz ... 0.9.26.zip" target="_blank

(Nicht ernst gemeinter) Hinweis: Man kann die Buchfahrplan-DLL nur mit .timetable.xml-Dateien und .csv-Dateien füttern, nicht mit .bmp-Dateien, weil das Tool ja noch ein Neuling ist, und die sind ja bekanntlich völlig ungeeignet dafür, an den Bestand anzuschließen.

[F(R)S-Bauer]

@F.Schon,

gestatte dem Tool doch Internet und Nutz das: https://www.onlineocr.net/de/" target="_blank ( )?

[F. Schn.]

Waaas? Da kritisiert jemand, dass es eine lange Schlange an erfahrenen Streckenbauern gibt, die alle danach brennen, die zehntausenden Bitmap-Fahrpläne im offiziellen Bestand zu erweitern??? Das ist ja unerhört....

[F. Schn.]

So, doch noch mal eine neue Version:

Neu in Version 3.0.9.29:
* Dokumentation
* Eine einfachere Benutzeroberfläche um Buchfahrpläne nachzubearbeiten, die DLL ist dafür entfallen.
* Nachtrag: Version 3.0.9.30: Fehlerhafter Filter im BuchfahrplanBereiniger

https://pkeus.de/~philipp/Zusi/3/Zusatz ... Ersatz.zip

[Alwin Meschede]

Ich spiele gerade mit der Ersatzfahrplan-DLL herum. Das Ding ist schon ein großer Wurf. Es freut mich, dass meine vor Jahren getroffene strategische Entscheidung, in den Rgl/Ggl-Ereignissen die La-Streckennummer anstatt der VzG-Streckennummer zu hinterlegen, hier Früchte trägt Da kommt dann natürlich der Wunsch auf, dass die Streckenbauer, die das bisher nicht so gehandhabt haben, ihre Streckennummern ändern

[Johannes]

Wie gleisscharf sind denn diese La-Streckennummern? Wenn ich an Göttingen – Rosdorf denke, gibt es sowohl die zweigleisige Strecke Göttingen – Abzw. Grone – Rosdorf (3600) als auch die eingleisige Strecke Göttingen – Abzw. Grone (1800). Haben die dann auch unterschiedliche La-Streckennummern?

[Alwin Meschede]

Die eingleisige Kurve nach Rosdorf hätte die La-Streckennummer 23A (mit großem A). Das bringt uns direkt zu einem ersten Problem: Und zwar ist es bei den La-Nummern eigentlich üblich, dass man mit klein a und b angibt, in welche Richtung die Strecke befahren wird. Das habe ich auch so in meinen Streckenmodulen hinterlegt. Die Ersatzfahrplan-DLL filtert den Buchstaben bislang aus. Das ist für einige, aber nicht für alle Regionalbereiche von DB Netz das korrekte Verhalten. Damit kommen wir so langsam zum zweiten Problem: Ab dem Jahr 2013 wurde die Nummerierung der Ersatzfahrpläne umgestellt von La-Streckennummern auf sogenannte Strukturnummern. Diese Strukturnummern wurden eingeführt für die Funktion "Fplo in EBuLa". Die Idee ist: Wenn man kurzfristig eine Fahrplananordnung bekommt, dann tastet man die dort genannten Strukturnummern ins EBuLa ein, und das Gerät stückelt dann einen passenden Streckenfahrplan zusammen, bei dem man allerdings die Fahrzeiten aus der schriftlichen Fahrplananordnung entnehmen muss. Seitdem herrscht allerdings je nach Netz-Regionalbereich völliger Wildwuchs bei den Überschriften von Ersatzfahrplänen:

RB Nord: Verweigert sich obstinent der modernen EBuLa-Technik und schreibt weiter die La-Streckennummer ohne a/b hin, so wie sie es schon immer gemacht haben - Strecke 429 Padborg - Neumünster
RB West: Schreibt wie früher die La-Streckennummer, aber mit a/b, und zusätzlich die Strukturnummer - Strecke 129a 312910 Bft Do-Dorstfeld - Dortmund West
RB Ost: Schreibt die Strukturnummer, und zusätzlich die La-Streckennummer ohne a/b in Klammern hinter dem Startbahnhof - Strecke 121423 Rehna (214) - Schwerin Hbf
RB Südost: Schreibt nur die Strukturnummer - Strecke 450023 Theuern - Erfurt Pbf
RB Mitte: Schreibt die La-Streckennummer, aber mit Unterstrich a/b, und zusätzlich die Strukturnummer mit einem seltsamen Buchstaben - Strecke 123_a H592610 Frankenberg - Sarnau – Cölbe
RB Südwest: Ähnlich wie RB Ost, mit La-Streckennummer in Klammern ohne a/b, aber vor dem Startbahnhof - Strecke 621910 (219) Mannheim Hgbf - Mannheim Hbf Ost
RB Süd: Wie RB Südost - Strecke 730012 Mottgers - Würzburg Hbf

Also ich möchte nicht anregen, diesen Unsinn auch in Zusi nachzuturnen, aber wollte mal zeigen: Die aktuelle Realität ist kompliziert.

[Carsten Hölscher]

Das Problem der La-Nummern ist, dass sie nicht so exakt streckengenau sind wie die VZG-Nummern. Z.B. Sowas wie Himmighausen-Langeland-Altenbeken wäre ein Kandidat für Abschnitte, die wegen der einmündenden Strecken in mehreren La-Nummern enthalten sind. Daher halte ich die VZG-Nummern für die bessere Wahl, da das ja modul- und damit auch autorübergreifend abgestimmt sein muss.

Carsten

[Alwin Meschede]

Für den Anwendungsfall, dass man automatisiert betriebliche Unterlagen aus dem Zusi-Bestand generieren will, scheint die La-Streckennummer die günstigere Startvoraussetzung zu sein, weil der Tool-Autor sie wie man sieht in den meisten Fällen einfach nur auslesen und andrucken muss. Bei der VzG-Nummer bräuchte man hingegen in 99 % der Fälle eine komplexe und wohl nur manuell pflegbare Übersetzungstabelle zwischen Streckennummern, Betriebsstellen und Streckenabschnitten, weil die VzG-Nummer in kaum einer betrieblichen Unterlage für das Zugpersonal jemals direkt auftaucht (und ja, ich weiß dass es im La-Bereich Süd einige wenige Fälle gibt, wo La-Nummer = VzG-Nummer ist).

[Carsten Hölscher]

Zwei Punkte muss die Nummer erfüllen:
1.) Alle Autoren müssen es gleich machen, damit die Modulel ohne Fehler zu ganzen Netzen zusammengefügt werden können.
2.) Die Nummern müssen ein Knoten-Kanten-Modell strikt erfüllen.

Punkt 1 kann man halten wie man will, solange es alle gleich tun. Die VZG-Nummer ist aber eigentlich m.E. das etablierte Verfahren.
Punkt 2 schafft die La nicht sauber.

Insgesamt wär also die Umrüstung auf VZG sinnvoll, wo das bisher nicht der Fall ist, auch wenn man für Erweiterungen dann eine Übersetzung La <-> VZG braucht.

Carsten

[Wolfgang Hüttner]

Ich wäre auch für die Beibehaltung der VZG-Nummer für die bisherigen Ereignisse Regelgleis und Gegengleis kennzeichnen.
Man könnte sich ja überlegen ein weiteres Ereignis für die La-Nummer einzuführen, da könnten dann u.U. auch mehrere Nummern hinterlegt werden.
Weiterhin stellt sich mir als Nichteisenbahner die Frage, wie ich an die entsprechenden La-Nummern komme?
Die VZG ist ja eindeutig dem IVL-Plan zugeordnet, der ja in der Regel die Basis für den Gleisplaneditor bildet.

Gruß
Wolfgang

[Alwin Meschede]

Naja, wie kommt ein Nichteisenbahner an einen IVL-Plan?

[Michael_Poschmann]

Historische Pläne gibt es bisweilen in Landesarchiven.
Auch sind örtliche Eisenbahnvereine zuweilen gute Quellen.

Grüße
Michael

[Johannes]

Die VzG-Nummer findet sich auch in https://geovdbn.deutschebahn.com/isr

Die Streckennummern werden meines Wissens nur für die Gegengleisermittlung bei der Buchfahrplanerzeugung herangezogen. Wichtig ist meines Wissens nur, dass es von einem beliebigen Bahnhof ausgehend dieselbe Nummer exakt 1x (eingleisige Strecke) oder 2x (dann als Regelgleis + Gegengleis) gibt. Insbesondere kann durchaus in Bahnhöfen ein Streckennummernwechsel stattfinden, ohne dass das zu Problemen führt. Aber eine Konstruktion wie Göttingen–Grone braucht zwei verschiedene Nummern, da es drei Gleise sind.