Home » railML newsgroups » railml.timetable » Extensions to railML for passenger information at stations
Extensions to railML for passenger information at stations [message #2182] Thu, 25 April 2019 00:04 Go to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 4
Registered: March 2018
Junior Member
[English text below]

Hallo zusammen,

im Rahmen eines Projektes mit der Rhätischen Bahn, dass sich mit dem
Upgrade der IT-Infrastruktur von railML 1.0 auf railML 2.X befasst, sind
eine Reihe von Anforderungen aufgekommen, die derzeit noch nicht mit
railML erfüllt werden können. Dabei geht es im Wesentlichen darum
verschiedene Fahrgastinformationen in railML abzubilden um diese
standardisiert zwischen den Systemen austauschen zu können. In den
verlinkten PDFs sind die Anforderungen erklärt und mögliche Lösungswege
skizziert. Um zu entscheiden, wie eine optimale Abbildung in railML
Aussehen sollte, wäre es super, wenn ihr euch das Dokument unter
http://forum.railML.org/userfiles/2019-04-24_psi_fahrgastinf ormation-bahnhof-railml25.pdf
(Seiten 1-11) mal anschauen könntet und Feedback geben könntet. Haben
auch andere Interesse an einer Abbildung dieser Informationen in railML?
Welche Aspekte sollten zusätzlich oder anders berücksichtigt werden? Ich
freue mich über jedes Feedback.

Hello, everybody,

Within the scope of a project with the Rhaetian Railway dealing with the
upgrade of the IT infrastructure from railML 1.0 to railML 2.X, a number
of requirements have arisen which cannot yet be met with railML. The
main goal is to map different passenger information in railML in order
to exchange it between the systems in a standardized way. The linked
PDFs explain the requirements and outline possible solutions. In order
to decide how an optimal representation in railML should look like, it
would be great if you could have a look at the document at
http://forum.railML.org/userfiles/2019-04-24_psi_fahrgastinf ormation-bahnhof-railml25.pdf
(pages 12-22) and give feedback. Are there others interested in having
this information mapped to railML? Which aspects should be considered
additionally or differently? I am looking forward to any feedback.

Best regards, Milan
--
Milan Wölke
Dipl.-Inf. (FH)
Technischer Projektleiter

PSI TransCom GmbH
Dircksenstraße 42-44
10178 Berlin
Deutschland
Re: Extensions to railML for passenger information at stations [message #2189 is a reply to message #2182] Fri, 03 May 2019 15:07 Go to previous messageGo to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 34
Registered: March 2015
Member
[English text below]

Hallo Milan, hallo Forum

ich habe mir Deine Erweiterungs-Vorschlag angesehen und finde ihn
grundsätzlich sehr gelungen. Im folgenden einige Anmerkungen:

- Aufzähltypen würde ich generell individuell erweiterbar definieren
(mittels "other:anything"), so wie das z.B. bei "processStatus" der Fall
ist. Dies betrifft in Deinem Vorschlag z.B. <annotation type="..."> und
<trigger event="...">

- Bei <origin> / <destination> würde ich überlegen, auf die ocpRef zu
verzichten. Wenn die Ausgangs-/Ziel-Betriebsstelle eines Zuges in den
Infrastrukturdaten der railML-Datei enthalten ist, dann sollte es auch
möglich sein, den Zuglauf auf diesen Betriebsstellen anzugeben.

- Zur Erweiterung des <blockPart> um einen Aufzähltyp
(ShortTurn|LongTurn|ContinueInSameDirection):
Ich denke, diese Informationen sind (in indirekter Form) bereits jetzt
abbildbar. In der letzten Telefonkonferenz hatten wir ja bereits darüber
gesprochen, dass die Unterscheidung ShortTurn <> LongTurn sich im
Umlaufplan auch mit einem eingeschobenen <blockPart> ohne referenzierten
Zugteil (mission="shunting" o.ä.) realisieren ließe. Die Information
"ContinueInSameDirection" könnte man über einen commercial <train>
(Komplett-Fahrzeug-Durchlauf auf anderen betrieblichen Zug) abbilden.
Somit könnte man auf die Erweiterung des <blockPart> verzichten. Ich
gebe zu, dass diese Informationen bei dieser Lösung im Vergleich zu
Deinem Vorschlag sehr verstreut sind. Generell sehe ich den Umlaufplan
aber primär als innerbetriebliche Unterlage an, so dass ich aus
"struktureller" Sicht dort eher keine Daten der Fahrgastinformation
ergänzen würde.

- Ich würde mich Philips Vorschlag anschliessen, die
<passengerInfoLanguages> als Unterelement der <annotationRef>
abzubilden. Der einzige Einwand dagegen wäre der Fall, dass man die
Info-Sprachen eines <trainPart> ohne eine konkrete Annotation angeben
möchte.

Soweit von mir. Insgesamt finde ich die Umsetzung dieser Anforderungen
sehr gut.

Viele Grüße
Christian Rößiger


Hello Milan, hello Forum

I have looked at your extension proposal and find it basically very
useful. In the following some remarks:

- I would generally define enumerated types as individually extensible
(using "other:anything"), as is the case with "processStatus", for
example. This applies in your suggestion e.g. <annotation type="...">
and <trigger event="...">

- With <origin> / <destination> I would consider to not use the ocpRef.
If the origin/destination point of a train is contained in the
infrastructure data of the railML file, then it should also be possible
to specify the train run on these points.

- Concerning the extension of the <blockPart> by one enumeration type
(ShortTurn|LongTurn|ContinueInSameDirection):
I think this information can already be modelled (in indirect form). In
the last telephone conference we had already talked about the fact that
the distinction ShortTurn <> LongTurn could also be implemented in the
rostering with an inserted <blockPart> without a referenced train part
(mission="shunting" or similar). The information
"ContinueInSameDirection" could be mapped via a commercial <train>
(complete vehicle run-through on another operational train). Thus one
could do without the extension of the <blockPart>. I admit that this
information is very scattered compared to your suggestion. In general,
however, I see the circulation plan primarily as an internal document,
so that from a "structural" point of view I would rather not supplement
any passenger information data there.

- I would agree with Philip's proposal to map the
<passengerInfoLanguages> as a sub-element of the <annotationRef>. The
only objection to this would be if you wanted to specify the info
languages of a <trainPart> without a concrete annotation.

So far from me. Generally I find the implementation of these
requirements very good.

Kind regards
Christian Rößiger

Am 25.04.2019 um 00:04 schrieb Milan Wölke:
> [English text below]
>
> Hallo zusammen,
>
> im Rahmen eines Projektes mit der Rhätischen Bahn, dass sich mit dem
> Upgrade der IT-Infrastruktur von railML 1.0 auf railML 2.X befasst, sind
> eine Reihe von Anforderungen aufgekommen, die derzeit noch nicht mit
> railML erfüllt werden können. Dabei geht es im Wesentlichen darum
> verschiedene Fahrgastinformationen in railML abzubilden um diese
> standardisiert zwischen den Systemen austauschen zu können. In den
> verlinkten PDFs sind die Anforderungen erklärt und mögliche Lösungswege
> skizziert. Um zu entscheiden, wie eine optimale Abbildung in railML
> Aussehen sollte, wäre es super, wenn ihr euch das Dokument unter
> http://forum.railML.org/userfiles/2019-04-24_psi_fahrgastinf ormation-bahnhof-railml25.pdf
> (Seiten 1-11) mal anschauen könntet und Feedback geben könntet. Haben
> auch andere Interesse an einer Abbildung dieser Informationen in railML?
> Welche Aspekte sollten zusätzlich oder anders berücksichtigt werden? Ich
> freue mich über jedes Feedback.
>
> Hello, everybody,
>
> Within the scope of a project with the Rhaetian Railway dealing with the
> upgrade of the IT infrastructure from railML 1.0 to railML 2.X, a number
> of requirements have arisen which cannot yet be met with railML. The
> main goal is to map different passenger information in railML in order
> to exchange it between the systems in a standardized way. The linked
> PDFs explain the requirements and outline possible solutions. In order
> to decide how an optimal representation in railML should look like, it
> would be great if you could have a look at the document at
> http://forum.railML.org/userfiles/2019-04-24_psi_fahrgastinf ormation-bahnhof-railml25.pdf
> (pages 12-22) and give feedback. Are there others interested in having
> this information mapped to railML? Which aspects should be considered
> additionally or differently? I am looking forward to any feedback.
>
> Best regards, Milan


--
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
Re: Extensions to railML for passenger information at stations [message #2190 is a reply to message #2182] Wed, 08 May 2019 16:51 Go to previous messageGo to next message
Tobias Bregulla is currently offline  Tobias Bregulla
Messages: 17
Registered: June 2017
Junior Member
[English text below]

Guten Tag,

wir stellen auch eine Vielzahl von Infrastrukturdaten für
Fahrgastinformationssysteme bereit. Daher halten wir diese Erweiterung
auch für sinnvoll, würden dazu bereits jetzt folgende (erste)
Anmerkungen aus Infrastruktursicht machen:

- Der Ansage-Zeitpunkt (Trigger) wird bei vielen Systemen nicht nur
alleine über die Zeit vor einem Ereignis bestimmt, sondern auch über die
Entfernung (Weg); weitere Trigger (wie Uhrzeit) sind denkbar.
Von daher sollte bei der Modellierung die Aufzählung des Attributes
@event um folgende Trigger erweitert werden:
- Strecke & Kilometer (z.B. beim Erreichen von km 71,880 ansagen "Wir
erreichen Disentis")
- Betriebsstelle (z.B. beim Erreichen von von Disentis ansagen "10
Minuten Aufenthalt zum Lokwechsel")
- Geokoordinate und Fangradius
- ggf. auch reine Uhrzeiten (z.B. Ansage "Ab jetzt Happy Hour im
Speisewagen; 3 Bier zum Preis von 2!")

- Die Modellierung der Triggerpunkte sollte vielleicht etwas
strukturiert und klarer beschrieben werden (z.B. Unterschied "Arrival"
und "ScheduledArrival"? Ist das in der Schweiz nicht immer identisch?
;-)). Da kommen bestimmt noch weitere Trigger dazu im Laufe der Zeit.

- Fehlt dem @periodic nicht noch ein Intervall und eine Beschreibung,
was mit dem Rest nach dem letzten Intervall (mathematischer Rest des
Bruchs) passieren soll?

- Für die Ansagen sollten Prioritäten vergeben werden können, wenn
mehrere Ereignisse gleichzeitig stattfinden. Irgendwie muss das Systeme
ja entscheiden können, welcher Ansage dann der Vorrang gegeben wird.

Beste Grüße,
--
Tobias Bregulla
Bahnkonzept Dresden/Germany


Dear all,

we also provide a variety of infrastructure data for passenger
information systems. Therefore, we consider this extension to be useful
and would like to make the following (first) comments from an
infrastructure point of view:

- In many systems, the announcement time (trigger) is not only
determined by the time before an event alone, but also by the distance
(distance); further triggers (such as time) are conceivable.
For this reason, the enumeration of the @event attribute should be
extended by the following triggers during modelling:
- Distance & Mileage (e.g. when reaching km 71,880 announce "We reach
Disentis")
- Service station (e.g. when reaching Disentis announce "10 minutes
stop at this station to change locomotive")
- Geocoordinate and snap radius
- if necessary also pure times (e.g. announcement "From now on Happy
Hour in the dining car; 3 beers for the price of 2!")

- The modelling of the trigger points should perhaps be more structured
and clearly described (e.g. difference between "Arrival" and
"ScheduledArrival"? Isn't this always the same in Switzerland? ;-)).
There will certainly be more triggers in the course of time.

- Doesn't @periodic still lack an interval and a description of what
should happen to the rest after the last interval (mathematical
remainder of the fraction)?

- It should be possible to assign priorities to the announcements if
several events take place simultaneously. Somehow the system must be
able to decide which announcement is given priority.

Best regards,
--
Tobias Bregulla
Bahnkonzept Dresden/Germany
Re: Extensions to railML for passenger information at stations [message #2192 is a reply to message #2189] Tue, 21 May 2019 01:20 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 4
Registered: March 2018
Junior Member
[English text below]

Hallo zusammen,

erstmal vielen Dank für die bereits eingegangenen Hinweise. Ich habe
versucht, diese in das Dokument einzuarbeiten:
https://forum.railml.org/userfiles/2019-05-20_psi_fahrgastin formation-bahnhof-railml25.pdf
(Seiten 1-12)

Zu den einzelnen Anregungen:
- Aufzählungstypen sollten erweiterbar sein
Sehe ich auch so. Habe ich im Dokument vervollständigt.
- Verzicht auf ocpRef bei <origin>/<destination>
Tatsächlich habe ich das auf Anregung von HaCon aufgenommen. Ich kann
deine Sicht nachvollziehen, habe aber auch kein Problem, wenn die
Möglichkeit erhalten bleibt auf einen Ort als Ursprung oder Ziel zu
verweisen, der nicht Teil des Laufwegs ist. Gerade wenn man daran denkt,
dass OCPs ganz prinzipiell hierarchisch aufgebaut sein können, kann das
Sinn machen.
- Erweiterung von <blockPart>
Sehe ich mittlerweile auch so. Habe ich im Dokument gestrichen.
- Weitere Ereignisse, die Ansagen auslösen können
Ich habe die Anregung aufgenommen und zusätzlich zum Fahrtevent
(Ankunft, Abfahrt, etc.) auch die logische Position, die physikalische
Position und Zeitpunkte aufgenommen.
- Fehlendes Intervall bei periodischen Ansagen
Das fehlende Intervall wurde ergänzt. Danke für den Hinweis.
- Priorität von Ansagen
Habe ich auch übernommen.


Hello, everybody,

first of all many thanks for the already received hints. I have tried to
include them in the document:
https://forum.railml.org/userfiles/2019-05-20_psi_fahrgastin formation-bahnhof-railml25.pdf
(pages 13-23)

To the individual suggestions:
- Enumeration types should be extendable
I agree. I have corrected it in the document.
- No ocpRef for <origin>/<destination>
In fact, I included this at the suggestion of HaCon. I can understand
your point of view, but I also have no problem, if the possibility
remains to refer to a place as origin or destination, which is not part
of the route. Especially if you think of the fact that OCPs can be
structured hierarchically in principle, this can make sense.
- Extension of <blockPart>
I feel the same way now. I deleted it from the document.
- More events that can trigger announcements
I took up the suggestion and in addition to the trip event (arrival,
departure, etc.) also added the logical position, the physical position
and time points.
- Missing interval for periodic announcements
The missing interval was added. Thanks for the hint.
- Priority of announcements
I adopted that too.

Best regards, Milan
--
Milan Wölke
Dipl.-Inf. (FH)
Technischer Projektleiter

PSI TransCom GmbH
Dircksenstraße 42-44
10178 Berlin
Deutschland
Am 03.05.2019 um 15:07 schrieb Christian Rößiger:
> [English text below]
>
> Hallo Milan, hallo Forum
>
> ich habe mir Deine Erweiterungs-Vorschlag angesehen und finde ihn
> grundsätzlich sehr gelungen. Im folgenden einige Anmerkungen:
>
> - Aufzähltypen würde ich generell individuell erweiterbar definieren
> (mittels "other:anything"), so wie das z.B. bei "processStatus" der Fall
> ist. Dies betrifft in Deinem Vorschlag z.B. <annotation type="..."> und
> <trigger event="...">
>
> - Bei <origin> / <destination> würde ich überlegen, auf die ocpRef zu
> verzichten. Wenn die Ausgangs-/Ziel-Betriebsstelle eines Zuges in den
> Infrastrukturdaten der railML-Datei enthalten ist, dann sollte es auch
> möglich sein, den Zuglauf auf diesen Betriebsstellen anzugeben.
>
> - Zur Erweiterung des <blockPart> um einen Aufzähltyp
> (ShortTurn|LongTurn|ContinueInSameDirection):
> Ich denke, diese Informationen sind (in indirekter Form) bereits jetzt
> abbildbar. In der letzten Telefonkonferenz hatten wir ja bereits darüber
> gesprochen, dass die Unterscheidung ShortTurn <> LongTurn sich im
> Umlaufplan auch mit einem eingeschobenen <blockPart> ohne referenzierten
> Zugteil (mission="shunting" o.ä.) realisieren ließe. Die Information
> "ContinueInSameDirection" könnte man über einen commercial <train>
> (Komplett-Fahrzeug-Durchlauf auf anderen betrieblichen Zug) abbilden.
> Somit könnte man auf die Erweiterung des <blockPart> verzichten. Ich
> gebe zu, dass diese Informationen bei dieser Lösung im Vergleich zu
> Deinem Vorschlag sehr verstreut sind. Generell sehe ich den Umlaufplan
> aber primär als innerbetriebliche Unterlage an, so dass ich aus
> "struktureller" Sicht dort eher keine Daten der Fahrgastinformation
> ergänzen würde.
>
> - Ich würde mich Philips Vorschlag anschliessen, die
> <passengerInfoLanguages> als Unterelement der <annotationRef>
> abzubilden. Der einzige Einwand dagegen wäre der Fall, dass man die
> Info-Sprachen eines <trainPart> ohne eine konkrete Annotation angeben
> möchte.
>
> Soweit von mir. Insgesamt finde ich die Umsetzung dieser Anforderungen
> sehr gut.
>
> Viele Grüße
> Christian Rößiger
>
>
> Hello Milan, hello Forum
>
> I have looked at your extension proposal and find it basically very
> useful. In the following some remarks:
>
> - I would generally define enumerated types as individually extensible
> (using "other:anything"), as is the case with "processStatus", for
> example. This applies in your suggestion e.g. <annotation type="...">
> and <trigger event="...">
>
> - With <origin> / <destination> I would consider to not use the ocpRef.
> If the origin/destination point of a train is contained in the
> infrastructure data of the railML file, then it should also be possible
> to specify the train run on these points.
>
> - Concerning the extension of the <blockPart> by one enumeration type
> (ShortTurn|LongTurn|ContinueInSameDirection):
> I think this information can already be modelled (in indirect form). In
> the last telephone conference we had already talked about the fact that
> the distinction ShortTurn <> LongTurn could also be implemented in the
> rostering with an inserted <blockPart> without a referenced train part
> (mission="shunting" or similar). The information
> "ContinueInSameDirection" could be mapped via a commercial <train>
> (complete vehicle run-through on another operational train). Thus one
> could do without the extension of the <blockPart>. I admit that this
> information is very scattered compared to your suggestion. In general,
> however, I see the circulation plan primarily as an internal document,
> so that from a "structural" point of view I would rather not supplement
> any passenger information data there.
>
> - I would agree with Philip's proposal to map the
> <passengerInfoLanguages> as a sub-element of the <annotationRef>. The
> only objection to this would be if you wanted to specify the info
> languages of a <trainPart> without a concrete annotation.
>
> So far from me. Generally I find the implementation of these
> requirements very good.
>
> Kind regards
> Christian Rößiger
Re: Extensions to railML for passenger information at stations [message #2209 is a reply to message #2192] Mon, 24 June 2019 11:46 Go to previous message
Joachim Rubröder is currently offline  Joachim Rubröder
Messages: 89
Registered: April 2007
Member
Ticket for this issue was created at https://trac.railml.org/ticket/358.
Ein Ticket für diesen Vorgang wurde unter https://trac.railml.org/ticket/358 angelegt.
Previous Topic: Hi! / Timing links
Next Topic: UIC train transport id
Goto Forum:
  


Current Time: Sun Jul 21 08:31:06 CEST 2019