| TT:blockPart: Semantic Constraint [message #2888] |
Thu, 27 January 2022 19:48  |
Patrik Thoma
Messages: 2
Registered: January 2022
|
Junior Member |
|
|
Hallo,
meine Name ist Patrik Thoma von der Rhätischen Bahn (RhB) in der Schweiz und bin zuständig für Betrieb und Weiterentwicklung der Applikationen im Bahnbetrieb bei uns.
Bei der Realisierung unseres Projektes «Flügelzugbetrieb» vernetzten wir unsere Applikationen für Planung und Disposition im Bereich Fahrplan und Formationen neu.
Für den Austausch der Fahrplandaten ist das Format railML 2.5 vorgesehen bzw. bereits in Umsetzung. Für die Formationen/Umläufe war bis anhin geplant, ein spezifisches Format zu verwenden.
Bei der Umsetzung sind nun aber diverse Probleme aufgetaucht, vor allem das Referenzieren der Formationen (aus Formations-/Umlaufexport) zu den Zügen (Fahrplanexport) bereitet mit all den zeitlichen Abweichungen grosse Schwierigkeiten.
Aus diesem Grund prüfen wir die Integration der Formations- und Umlaufdaten in den railML-Fahrplan und wollen hier die zur Verfügung stehenden Elemente/Attribute nutzen. Bei einem Thema stehen wir allerdings vor einer Herausforderung: unsere Züge bestehen sehr oft aus einer Lok und Einzelwagen und die Formation verändert sich sehr oft auf einem Zuglauf. Mit dem gem. railML-Wiki definierten semantic constrains für das Element Blockpart (siehe Auszug unten) würde dies bedeuten, dass wir für jede veränderte Formation einen separaten trainPart definieren/generieren müssten, was erhebliche Auswirkungen auf Komplexität und Datenmenge hat.
Aus diesem Grund wollen wir anfragen, ob dieses Semantic Contraints so angepasst werden kann, dass ein trainPart von mehreren blockParts (mit verschiedenen Formationen) referenziert werden kann, immer unter Berücksichtigung der Anforderung, dass der gesamte trainPart von blockParts abgedeckt wird.
Die Idee wäre also den semantic constraint TT:003 so anzupassen, dass bei Referenzierung eines trainPart durch einen blockPart durchaus startOcpRef und endOcpRef abweichend zum referenzierten trainPart angegeben werden können, unter der Voraussetzung, dass erstens startOcpRef und endOcpRef auf Ocps verweisen, die im Zuglauf des trainParts enthalten sind, und zweitens andere blockParts auf den verbleibenden Teil des trainPart ohne Überlagerung referenzieren. Dies würde für unsere Betriebsfälle, also sehr häufige Formationswechsel auf der Strecke, die sich auch zeitlich nicht systematisieren lassen (also unregelmäßig auftreten) dazu führen, dass sich die Redundanz bezüglich der trainParts im railML Fahrplan massiv reduzieren würde. Wir könnten uns vorstellen, dass dies auch anderen Bahnen mit ähnlichen Bedürfnissen (abweichende Formatonen) sehr weiterhelfen würde.
Für eine Prüfung danken wir herzlich!
Patrik Thoma
siehe Semantic Constraint "TT:003":
https://wiki2.railml.org/wiki/TT:blockPart
[Updated on: Thu, 27 January 2022 19:56] Report message to a moderator |
|
|
|
Members
Search
Help
Login
Home
