Forum - RDF feed
https://www.railml.org/forum/index.php
Published station track vs actual station track
https://www.railml.org/forum/index.php?t=rview&goto=2310&th=702#msg_2310
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ölke2020-01-08T17:14:27-00:00Re: Published station track vs actual station track
https://www.railml.org/forum/index.php?t=rview&goto=2319&th=702#msg_2319
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?]]>Tobias Bregulla2020-01-25T13:29:29-00:00Re: Published station track vs actual station track
https://www.railml.org/forum/index.php?t=rview&goto=2327&th=702#msg_2327
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ölke2020-02-12T16:52:22-00:00Re: Published station track vs actual station track
https://www.railml.org/forum/index.php?t=rview&goto=2334&th=702#msg_2334
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ölke2020-02-19T11:29:54-00:00