Home » railML newsgroups » railml.timetable » Published station track vs actual station track
Re: Published station track vs actual station track [message #2319 is a reply to message #2310] Sat, 25 January 2020 14:29 Go to previous messageGo to previous message
Tobias Bregulla is currently offline  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?
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: Facultative trains / Bedarfszüge
Next Topic: Production interfaces with further limitations
Goto Forum:
  


Current Time: Thu May 02 01:17:00 CEST 2024