Published station track vs actual station track [message #2310] |
Wed, 08 January 2020 18:14 |
Milan Wölke
Messages: 146 Registered: April 2007
|
Senior Member |
|
|
Hi all,
in the last developer telco a question was raised regarding how to model a published station track in contrast to the actual station track at a station. This is useful information for the use case passenger information, when for example the yearly timetable, which is the basis for the published timetable and track usage information, refers to a track different from the one planned for a train in short term (eg. construction work at the track and such). In order to inform the passengers about this trackchange both station tracks would need to be provided for a stop.
During the telco it turned out that it is not possible to model that at the moment. I would like to suggest to include that possibility in the extensions for railML 2.5. What is your opinion? Would you need a possibility to express this in railML?
--------------
Bei der letzten Entwickler-Telefonkonferenz wurde die Frage aufgeworfen, wie man ein veröffentlichtes Bahnhofsgleis im Gegensatz zum eigentlichen Bahnhofsgleis an einem Bahnhof modellieren kann. Dies ist eine nützliche Information für den Anwendungsfall Fahrgastinformation, wenn sich z.B. der Jahresfahrplan, der die Grundlage für die veröffentlichten Fahrplan- und Gleisnutzungsinformationen bildet, auf ein anderes Gleis bezieht, als das, das für einen Zug kurzfristig geplant ist (z.B. Bauarbeiten am Gleis und dergleichen). Um die Fahrgäste über diesen Gleiswechsel zu informieren, müssten beide Bahnhofsgleise für einen Halt vorgesehen werden.
Im Laufe der Telefonkonferenz hat sich herausgestellt, dass es derzeit nicht möglich ist, dies zu modellieren. Ich möchte vorschlagen, diese Möglichkeit in die Erweiterungen für railML 2.5 aufzunehmen. Was ist eure Meinung? Braucht ihr eine Möglichkeit, dies in railML auszudrücken?
Best regards, Milan
Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
Re: Published station track vs actual station track [message #2319 is a reply to message #2310] |
Sat, 25 January 2020 14:29 |
Tobias Bregulla
Messages: 20 Registered: June 2017
|
Junior Member |
|
|
Good afternoon,
thank you for this suggestion, it is a good idea and should be
implemented in railML 2.5. (However, some areas remain in railML 2.x
which cannot be solved with the current modelling is real-time data
(e.g. <ocpTT>@ocpType); this should definitely be tackled in railML 3.x).
I would suggest two additional properties regarding data quality:
@timestamp [xs:dateTime, optional]
--> the time when this data was generated originally by the
reporting system or reporter; empty means unknown
@reporter [restriction of xs:string, optional]
"TCS","GNSS","TVD","manual", other:)
(TimetableConstructionSystem/TrafficManagementSystem,
GlobalNavigationSatelliteSystem, TrackVacancyDetection, by a human)
--> the type of the reporting system or reporter; empty means unknown
(maybe extended by a optional string of exact name of reporter or
any field)
What do you think about?
Best regards,
--
Tobias Bregulla
Bahnkonzept Dresden/Germany
Am 08.01.2020 um 18:14 schrieb Milan Wölke:
>> in the last developer telco a question was raised regarding
> how to model a published station track in contrast to the
> actual station track at a station. This is useful
> information for the use case passenger information, when for
> example the yearly timetable, which is the basis for the
> published timetable and track usage information, refers to a
> track different from the one planned for a train in short
> term (eg. construction work at the track and such). In order
> to inform the passengers about this trackchange both station
> tracks would need to be provided for a stop.
> During the telco it turned out that it is not possible to
> model that at the moment. I would like to suggest to
> include that possibility in the extensions for railML 2.5.
> What is your opinion? Would you need a possibility to
> express this in railML?
|
|
|
Re: Published station track vs actual station track [message #2327 is a reply to message #2319] |
Wed, 12 February 2020 17:52 |
Milan Wölke
Messages: 146 Registered: April 2007
|
Senior Member |
|
|
Hi Tobias,
first off, thanks for your reply. If I understand you correctly you suggest to not only add some modelling for expressing that the train stops at a different platform but also when this was decided and where this decision came from, right? I would assume that this data is only to be provided (and if possible should also be modelled so that it only can be provided) if the track actually was changed.
Based on the use case you are trying to fulfill, is it necessary to track all inbetween changes along with their source and timestamp or would the last change be sufficient for you?
--------------------------------------------
Zunächst einmal vielen Dank für deine Antwort. Wenn ich dich richtig verstehe, schlägst du vor, nicht nur eine Modellierung hinzuzufügen, um auszudrücken, dass der Zug an einem anderen Bahnsteig hält, sondern auch, wann dies bestimmt wurde und woher diese Entscheidung kam, richtig? Ich würde davon ausgehen, dass diese Daten nur dann zur Verfügung gestellt werden sollen (und wenn möglich auch so modelliert werden sollten, dass sie nur dann zur Verfügung gestellt werden können), wenn das Gleis auch tatsächlich geändert wurde.
Ist es auf der Grundlage des Anwendungsfalles, den du zu erfüllen versuchst, notwendig, alle Zwischenänderungen zusammen mit ihrer Quelle und ihrem Zeitstempel zu verfolgen, oder würde die letzte Änderung für dich ausreichen?
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: Wed, 12 February 2020 17:52] Report message to a moderator
|
|
|
Re: Published station track vs actual station track [message #2334 is a reply to message #2327] |
Wed, 19 February 2020 12:29 |
Milan Wölke
Messages: 146 Registered: April 2007
|
Senior Member |
|
|
I would like to merge this discussion with the one regarding deprecation or replacement of the attribute @processStatus. Please post any messages regarding track change there.
Background is, that the timetable developer community agreed that an individual modelling to describe track changes is not a good idea. Instead a modelling of some element describing the state of a train is preferred. That way a published train could be included in railML as well as a scheduled one (just an example of possible states that could be described like this).
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: Wed, 19 February 2020 12:32] Report message to a moderator
|
|
|