Home » railML newsgroups » railml.timetable » [railML2] Extension of annotations for passenger information within trains
[railML2] Extension of annotations for passenger information within trains [message #2674] Sun, 07 March 2021 21:10 Go to previous message
Thomas Kabisch is currently offline  Thomas Kabisch
Messages: 8
Registered: September 2020
Junior Member
(English below)

Hallo,

dieses Post soll Anforderungen für die visuelle Fahrgastinformation im Zug detaillieren und einen Modellierungsvorschlag als Diskussionsgrundlage vorstellen.

1. Anforderungen:
-----------------
Stadler benötigt ein Datenaustauschformat für die Fahrgastinformation im Zug.
Dieses Post konzentriert sich dabei auf die Anforderungen für optische Fahrgastinformation im Zug (bspw. für Zielanzeigen, Innenanzeigen)
Die zu transportierenden Informationen beziehen sich zum Großteil auf die befahrene Strecke und die aktuelle Fahrt, im Einzelnen werden folgenden Inhalte benötigt:
- Fahrtziel (idR. expliziter Stationsname, aber auch Abweichungen möglich wie z.B. "Ring")
- aktuelle Station ("nächster Halt")
- Stationsfolge ("Perlschnur")
- besondere Zwischenstationen (bspw. explizit definierte Viastationen)
- Fahrplan der eigenen Fahrt
- Linienbezeichner (kann numerisch oder alphanumerisch sein)
- Gleis-, Gleisabschnitts- bzw. Bahnsteigbezeichner
- Sonderanzeigen (bspw. "Nicht einsteigen")

Für alle genannten Informationen bestehen die folgenden Detailanforderungen:
1.1. Mehrsprachigkeit
1.2. Klassifizierung nach Ausgabekanälen (bspw. benötigt eine LED-Außenanzeige oft eine komprimiertere Darstellung gegenüber einem TFT-Monitor im Innenraum; "Hauptbahnhof" vs. "Hbf")
1.3. Zuordnung von Auslösetriggern (bspw: die Stationsanzeige "nächster Halt ..." muss 2min vor Ankunft am Halt ausgelöst werden).

2. Modellierungsvorschlag
-------------------------
Grundsätzlich kann die Modellierung als Erweiterung der hier bereits vorgestellten Lösung für die Fahrgastinformation am Bahnhof betrachtet werden.
Daher bauen die im folgenden vorgeschlagenen Erweiterungen auf das Grundkonzept <annotation> auf, welches einen Anzeigeinhalt repräsentiert,
die feinere Aussteuerung kann unterhalb in den zugeordneten <text>-Elemente erfolgen.
Die Attributstruktur von <annotation> kann bestehen bleiben wie bisher, wenn die untergeordneten Strukturen erweitert werden:
Das <text>-Element (tAnnotationText) ermöglicht bisher schon eine Mehrsprachigkeit (Anforderung 1.1.),
zur Abbildung der Ausgabekanäle (Anforderung 1.2) wird vorgeschlagen ein weiteres Attribut @target einzuführen, welches als Enum definiert werden sollte.
Die Zuordnung von Auslösetriggern (Anforderung 1.3) wird bei der Referenzierung abgebildet, wie auch bereits für <announcement> vorgeschlagen.

Die Liste der annotations kann am Beginn des Timetable-Schemas oder aber am Beginn des Infrastructure-Schemas aufgebaut werden.
Für die Einbindung in den Kontext (Fahrplan/Infrastruktur) sollen Referenzen zu den definierten Annotations dienen.
Im folgenden werden zwei Vorschläge für die Modellierung dieser Referenzen vorgstellt:

Vorschlag 1: Umsetzung komplett innerhalb der Fahrten (<train>/<trainPart>):

Unterhalb von <train>
- Referenz für Linienbezeichnung
- Referenz für Zielbezeichnung
Unterhalb <trainpart>/<ocptt>
- Referenz für Bezeichnung der aktuellen Station
- Referenz für abweichende Zielbezeichnung
- Referenz für Gleis-, Bahnsteig-, Abschnittsbezeichnung

Vorschlag 2: Umsetzung aufgeteilt in Abhängigkeit von Annotation-Typen:

Unterhalb von <ocp>
- Referenz für Stationsbezeichnungen
Unterhalb von <train>
- Referenz auf Linienbezeichnung
- Referenz auf Zielbezeichnung
Unterhalb <trainpart>/<ocptt>
- Referenz für abweichende Zielbezeichnung
- Referenz für Gleis-, Bahnsteig-, Abschnittsbezeichnung

Vorschlag 1 führt zu sehr viel Redundanz, da jeder Halt einer jeden Fahrt eine Referenz zu den entsprechenden Bahnhofsbezeichnern haben müsste, obwohl diese pro Bahnhof stets konstant sind. Daher wird Vorschlag 2 priorisiert.

Ein Beispiel folgt nach dem englischen Text.

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

(ENG)

Hello,

this post details requirements for visual passenger information within trains and introduces a modelling suggestion for further discussions.

1. Requirements:
----------------
Stadler requires a data exchange format to support the passenger information system within trains.
This post concentrates on visual information for devices such as interior TFT displays or front destination displays.

Information to be handled comprises mainly details of the current journey:
- Names of Stations to be displayed (destination station, next following station, station sequence, specialy tagged via stations)
- timetable information of the current journey
- designations of the current line
- track and platform designations at stations
- special texts such as ("do not board")

For all encounterd types of information the following detail requirements apply:
1.1. multi-language ability
1.2. assigment of a dedicated output channel (such as TFT-interior display)
1.3. assignment of atrigger to define the behavior of the system


2. Modelling suggestion
-----------------------
In general, these requirements built up on the already presented solution for passenger information within stations.
Thus, all suggested extensions are based on the concept <annotation> that contains the textual content to be processed within the information system.
The attribute structure of <annoation> may remain untouched if underlying structures are slightly adopted:
The element <text> (tAnnotationText) already supports multiple languages (requirement 1.1).
We suggest to add a new attribute @target in order to support output channels (requirement 1.2).
The assingment of triggers (requirement 1.3) can remain at the reference similarly as suggested for <announcements>.

The general list of all annotations may be located at the begin of either the timetable or the infrastructure subschema.
All relations to any context (timetable or infrastructure elements) are handled by references.

In the following, we give two options for the modelling of these references.

Suggestion 1: All references are placed within the timtetable schema below <train> and <trainpart>.

below <train>
- reference for line designator
- reference for destination designator
below <trainpart>/<ocptt>
- reference for designation of current station
- reference for diverting destination
- reference for track-, platform- and section designations

Suggestion 2: References are spread over infrastructure and timetable schema:

below <ocp>
- reference for station designation
below <train>
- reference for line designation
- reference for destination
below <trainpart>/<ocptt>
- reference for diverting destination
- reference for track-, platform and section designation

Suggestion 1 leads to a high level of redundance because of the extensive repeating of station designations at every trainPart, thus we prefer suggestion 2.


-------


Beispiel / Example
==================

<infrastructure>
<operationControlPoints>
<ocp code="HH" id="ocp_HH" name="Hannover Hauptbahnhof">
...
<!-- Referenz zu Bezeichnern fuer diese Station -->
<stationAnnotationRef ref = "anno_HH">
...
</ocp>
...
</operationControlPoints>
</infrastructure>
<timetable>
<!-- Liste von Bezeichnern für verschiedene Zwecke -->
<annotations>
<!-- Beispiel für Bahnhofsbezeichnung -->
<annotation id="anno_HH" name="HH Hbf">
<text xml:lang="de" target="FrontDisplay">Hannover</text>
<text xml:lang="de" target="InteriorDisplay">Hannover Hauptbahnhof</text>
<text xml:lang="de" target="SideDisplay">Hannover Hbf</text>
<text xml:lang="en" target="FrontDisplay">Hanover</text>
<text xml:lang="en" target="InteriorDisplay">Hannover Central station</text>
<text xml:lang="en" target="SideDisplay">Hannover C</text>
</annotation>
...
<!-- Beispiel für Gleisbezeichnung -->
<annotation id="anno_track_4" value="Gleis 4">
<text xml:lang="de" class="P" value="Gleis 4"/>
<text xml:lang="en" class="P" value="Track 4"/>
</annotation>
</annotations>

<trainparts>
<trainPart categoryRef="cat_S" id="tp_1" line="S3" name="34321" timetablePeriodRef="ttp_1"
trainNumber="34321">
<operatingPeriodRef ref="op_1"/>
<ocpsTT>
<ocpTT ocpRef="ocp_HH" ocpType="stop" sequence="1">
<times departure="11:34:00" scope="scheduled"/>
<sectionTT distance="1220" trackInfo="1"/>
<stopDescription commercial="true"/>
<!-- Referenz zu Gleisbezeichner -->
<trackAnnotationRef ref="anno_track_4"/>
</ocpTT>
...
</ocpsTT>
</trainPart>
</trainParts>
<trains>
....
<train id="trc_1" type="commercial" trainNumber="34321" scope="primary">
<!-- Beispiel fuer Referenz zu Zielbezeichner -->
<destAnnotationRef ref="anno_HH"/>
<trainPartSequence sequence="1">
<trainPartRef ref="tp_1" position="1"/>
</trainPartSequence>
</train>
</trains>
</timetable>
 
Read Message
Read Message
Read Message
Previous Topic: [railML2] Extensions of triggers for passenger information within trains
Next Topic: [railML3] Semantics of the attributes arrivalDay and departureDay
Goto Forum:
  


Current Time: Thu Apr 25 04:10:26 CEST 2024