Home » railML newsgroups » railml.timetable » Extensions to railML for passenger information at stations
| Re: Extensions to railML for passenger information at stations [message #2189 is a reply to message #2182] |
Fri, 03 May 2019 15:07   |
Christian Rößiger
Messages: 62
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
|
|
|
|
Current Time: Mon May 06 06:41:08 CEST 2024
|
Members
Search
Help
Login
Home
