UC:TT:TimetableInformation

From wiki.railML.org
Jump to: navigation, search
Note.png This page is mirrored from page UC:TT:TimetableInformation in the railML® 3 wiki.
Timetable Information
Subschema: Timetable and Rostering
 
Related subschemas: IS RS 
Reported by: HaCon
Stift.png                   (version(s) 2.4)
For general information on use cases see UC:Use cases


Use case / Anwendungsfall / Scénario d’utilisation

Timetable Information; Fahrplanauskunft; nom descriptif en Francais

Description / Beschreibung / Description

Timetable information may include a range of passenger information systems such as a journey planner and print material as well as ticketing and real-time information. This use case will focus on the definition of the minimum requirements for passenger information. The required data includes stations, timetables, service categories. Furhtermore, data regarding links among stops and interchange times can be provided if available. This data would be provided by the long term planning (LTP) or short term planning (STP) timetabling tool. For short term changes/updates the focus lies on the data relevant for passengers information only (commercial view).

Characterizing Data / Charakterisierung der Daten / Caractérisation des données

The data is provided according to the customer specific planning and subsequent publication processes. Usually fixed deadlines and timeframes exist for the typical planning horizons (please see below Which views are represented by the data (focus)?).

Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen / Interaction avec autres schemas railML®

  • infrastructure: <ocp>
  • rolling stock: <formation> (?)
  • interlocking: -

Characterizing Data / Charakterisierung der Daten / Caractérisation des données

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

  • yearly for LTP planning
  • regular changes for STP planning
  • daily for VSTP planning

How big are the data fragments to be exchanged (complexity)?

  • whole data set: provide the full timetable
  • full time window: provide full timetable for fixed time window (e.g. next 10 days only)
  • changes for time window: provide only updated elements for a fixed time window (e.g. next 30 days)

Which views are represented by the data (focus)?

  • LTP: the next yearly timetable - e.g. availability of the next yearly timetable 6 months ahead of time
  • STP: short term planning changes to the current timetable - e.g. updated timetable information is provided for days +2 to +60

There is no fixed process for the exchange of data with a passenger information system. Whether or not it makes sense to identify and supply updates to a previous export file strongly depends on the capabilities of the systems involved (further discussion needed). Possible export options could be:

  • Full: a full timetable is provided for a specific time window
  • Update: only changes to the last export are provided for a specific time window (for the update process all files need to be handled in the correct sequence!)

Which specific TT data do you expect to receive/send (elements)?

As a bare minimum the commercial view of a <train> can be reduced to one <trainPart> with a sequence of <ocpTT> elements with commercially relevant stops (<stopDescription> with commercial='true'). For the each stop the following data is shown:

  • published times: <times> element with scope='published'
  • connections: <connection> element(s) with connType='commercial'
  • stop description: only <stopDescription> elements with commercial='true' will be relevant including their <stopTimes> element

In addition the following data would be useful for passenger information:

  • platform
  • etc.

Further Issues

Handling of connections for partial exports

Depending on the process in the receiving system it might be necessary to provide only a single train with all the relevant connections. However, without the connected trains the current connection element is not valid and the referenced IDs cannot be used to map the connected trains/trainParts.

Referencing platforms in the timetable

Currently the track and platform information shall be provided via the trackRef attribute linking the corrosponding element in the infrastructure. However, this requires quite a detailed infrastructure export. It should be possible to provide the commercial stations and platforms needed for the timetable export only.

Handling of cancellations, partial cancellations, extra trains

Relevant changes to existing trains need to be represented in the export file. A complete list of changes needs to be defined. This will include the following changes:

  • full cancellation of a train
  • partial cancellation - i.e. of a trainPart
  • extra train or trainPart
  • cancelled stop
  • extra stop
  • etc.


Discussion

  • Minor changes to the <formationTT> are not necessarily relevant and could be ignored (only the category is relevant) or should the formationTT element be optional?


Terms and Expressions

  • LTP = long term planning: the yearly timetable(s)
  • STP = short term planning: changes to the current production timetable up to the point that changes can be published to downstream systems (passenger information, train control, train operators, etc.)