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 next 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>
Re: [railML2] Extension of annotations for passenger information within trains [message #2684 is a reply to message #2674] Mon, 22 March 2021 16:28 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 139
Registered: April 2007
Senior Member
Hi Thomas,

again, thanks for your valuable input.

First, let me respond to the part that is rather easy to respond to. Regarding an origin and destination text other than the last station we actually already have something in railML, that is being introduced with railML 2.5. For each train part you can specify this either as text (translatable), or code (to be resolved by the importing system) or ocpRef. Apart from a differentiation for various display types this should cover your requirements, from what I can see. Please review and let us know if that matches your expectations ( https://svn.railml.org/railML2/branches/railML2.5-dev/schema / - /railML/timetable/trainParts/trainPart/origin and /railML/timetable/trainParts/trainPart/destination).

Regarding the line of a train and its passenger info meta data we already have another post open, as far as I know, so we should discuss these points there ( https://www.railml.org/forum/index.php?t=msg&th=782& start=0&).

Regarding the current station, I have to admit I'm a bit confused. I would interprete your requirement here, that you need a way to determine a valid station name for displays and announcements of the next station. I would presume the next station itself would be determined by your system on its own. Regarding how to specify these aspects, I would propose to introduce a new root element below timetable (/railML/timetable/passengerInfoForInfrastructure - the name could be debated), that would reference the actual ocps of the infrastructure and provide the necessary passenger info details. From my point of view that would be a working theory at first. Once the actual structure of this was specified and discussed, we could ask the infrastructure group to incorporate that model into infrastructure itself, as in my opinion that is rather an infrastructure dependent content than a timetable dependent one.

<railML>
  <timetable>
    <passengerInfoForInfrastructure>
      <ocpPIs>
        <ocpPI ocpRef="..." code="...">
          <text xml:lang="...">...</text>
          <text xml:lang="...">...</text>
        </ocpPI>
      </ocpPIs>
      <platformPIs>
        <platformPI>...</platformPI>
      </platformPIs>
      <trackPIs>
        <trackPI>...</trackPI>
      <trackPIs>
    </passengerInfoForInfrastructure>
  </timetable>
</railML>

That would be the general outline of this new section. In contrast to your approach I would simply add this to the file and not reference it from neither trainPart nor ocpTT. Since ocpTT is referencing an ocp anyway, it should be possible to determine the mapped passenger information by checking for entries in passengerInfoForInfrastructure that refer to that ocp. If the infrastructure group decides to incorporate this description it would be even more clear but even if infrastructure does not follow up on this, I think that would be enough.

As you can see this would also be the place to provide the necessary info for platforms and maybe even tracks. Tracks however poses a bit of an issue here as it is possible in railMl 2.x to specify a track using the trackInfo attribute of the ocpTT, without the need for an microscopic infrastructure. That means that there is no reference of any infrastructure element, whatsoever. Judging from your use case, can we assume that a microscopic infrastructure is available anyway?

Regarding the target you are suggesting, could you provide us with a list of necessary values for that enumeration. For the annotations we have the option to specify one or more additionalNames. This could be used to classify texts as well. For example you could specify it like this:
      <ocpPIs>
        <ocpPI ocpRef="ocpHH" code="...">
	  <additionalName name="FrontDisplayText"/>
          <text xml:lang="...">...</text>
          <text xml:lang="...">...</text>
        </ocpPI>
        <ocpPI ocpRef="ocpHH" code="...">
	  <additionalName name="SideDisplayText"/>
          <text xml:lang="...">...</text>
          <text xml:lang="...">...</text>
        </ocpPI>
        <ocpPI ocpRef="ocpHH" code="...">
	  <additionalName name="InteriorDisplayText"/>
          <text xml:lang="...">...</text>
          <text xml:lang="...">...</text>
        </ocpPI>
      </ocpPIs>
Could you imagine using something like this here, too?

Regarding your example, could you explain, what the class is specifying, that is given for a track annotation?

I hope this input will further the discussions on this topic so that we can better discuss this in one of our next developer phone calls. Obviously input from the community would be very helpful for coming to a conclusion here quickly, too, so I would kindly ask anyone who is concerned with railML timetable or passenger information in particular to comment on this so we can consider it when discussion the actual modelling.

Thanks in advance.

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Mon, 22 March 2021 16:34]

Report message to a moderator

Re: [railML2] Extension of annotations for passenger information within trains [message #2685 is a reply to message #2684] Wed, 24 March 2021 13:47 Go to previous message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 59
Registered: March 2015
Member
Hello Milan and Thomas,

it was very helpful for me to see how the proposed extensions should be
used in an XML example. I agree with Milan on many points in this.

Am 22.03.2021 um 16:28 schrieb Milan Wölke:
> Regarding an origin and destination text other
> than the last station we actually already have something in
> railML, that is being introduced with railML 2.5.

Just one addition to this: The railML 2.5 elements <origin> and
<destination> mentioned by Milan are subelements of <trainPart> (not of
<train>). This is the right place from my point of view, because
different <origin>s and <destinations> can occur for a coupled/shared
<train> at the same time.

> Regarding the current station, I have to admit I'm a bit
> confused. I would interprete your requirement here, that you
> need a way to determine a valid station name for displays
> and announcements of the next station. I would presume the
> next station itself would be determined by your system on
> its own. Regarding how to specify these aspects, I would
> propose to introduce a new root element below timetable
> (/railML/timetable/passengerInfoForInfrastructure - the name
> could be debated), that would reference the actual ocps of
> the infrastructure and provide the necessary passenger info
> details. From my point of view that would be a working
> theory at first. Once the actual structure of this was
> specified and discussed, we could ask the infrastructure
> group to incorporate that model into infrastructure itself,
> as in my opinion that is rather an infrastructure dependent
> content than a timetable dependent one. > <railML>
>  <timetable>
>    <passengerInfoForInfrastructure>
>      <ocpPIs>
>        <ocpPI ocpRef="..." code="...">
>          <text xml:lang="...">...</text>
>          <text xml:lang="...">...</text>
>        </ocpPI>
>      </ocpPIs>
>      <platformPIs>
>        <platformPI>...</platformPI>
>      </platformPIs>
>      <trackPIs>
>        <trackPI>...</trackPI>
>      <trackPIs>
>    </passengerInfoForInfrastructure>
>  </timetable>
> </railML>
>
> That would be the general outline of this new section. In
> contrast to your approach I would simply add this to the
> file and not reference it from neither trainPart nor ocpTT.
> Since ocpTT is referencing an ocp anyway, it should be
> possible to determine the mapped passenger information by
> checking for entries in passengerInfoForInfrastructure that
> refer to that ocp.
Good suggestion.

What bothered me about Thomas' design was that sometimes the
<annotation> is referenced directly from the <trainPart> and sometimes
the <ocpTT> initially references the <ocp> and from there the
<annotation>. I would prefer a unified solution (direct reference from
the <trainPart> or <ocpTT> to the <annotation>), what is provided by
Milans proposal. Another argument for this is, that different trains may
use different <annotation>s at the same station, e.g. due to different
display sizes or requirements of the railway undertaking. I would
therefore rather avoid referencing <annotation>s from an <ocp>.

> Regarding the target you are suggesting, could you provide
> us with a list of necessary values for that enumeration. For
> the annotations we have the option to specify one or more
> additionalNames. This could be used to classify texts as
> well. For example you could specify it like this:
>
>      <ocpPIs>
>        <ocpPI ocpRef="ocpHH" code="...">
>       <additionalName name="FrontDisplayText"/>
>          <text xml:lang="...">...</text>
>          <text xml:lang="...">...</text>
>        </ocpPI>
>        <ocpPI ocpRef="ocpHH" code="...">
>       <additionalName name="SideDisplayText"/>
>          <text xml:lang="...">...</text>
>          <text xml:lang="...">...</text>
>        </ocpPI>
>        <ocpPI ocpRef="ocpHH" code="...">
>       <additionalName name="InteriorDisplayText"/>
>          <text xml:lang="...">...</text>
>          <text xml:lang="...">...</text>
>        </ocpPI>
>      </ocpPIs>

For this aspect, I would prefer the use of a "real" enum, as suggested
by Thomas ("target" attribute). This way, at least the most common
values can be defined in the schema.
As a consequence of this approach, we would need different annotation
types with different attributes, e.g.:
- annotation (standard, without further special attributes)
- ocpAnnotation (with additional attribute "target")
- trackAnnotation (with additional attribute "class")

So far my ideas.

Best Regards
Christian
--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
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: Fri Mar 29 12:12:40 CET 2024