Home » railML newsgroups » railml.timetable » Extensions to railML for passenger information at stations
| Re: Extensions to railML for passenger information at stations [message #2192 is a reply to message #2189] |
Tue, 21 May 2019 01:20   |
Milan Wölke PSI
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
|
|
|
|
Current Time: Mon May 06 08:23:23 CEST 2024
|
Members
Search
Help
Login
Home
