UC:TT:TAF/TAP TSI

From railML 3 Wiki
Jump to navigation Jump to search
TAP TSI static timetable Information
Subschema: Timetable and Rostering
 
Related subschemas: IS 
Reported by: ERA
Stift.png DRAFT railML®
For general information on use cases see UC:Use cases


Use case / Anwendungsfall

TAP TSI static timetable Information; Fahrplanauskunft;

Description / Beschreibung

Timetable information for the TAP TSI (EC 454/2011) http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:123:0011:0067:EN:PDF (external link, pdf) includes the timetable data exchange between the railway undertakings, public authorities and third parties for passenger information systems such as a journey planner or printed material. The main goal of this use case is the process description and the minimum data content for the timetable data exchange. The used data format is EDIFACT. The use case shall cover the fact that it should be possible to create those data from a railML-data set.

The legal defintion for the data exchange in chapter 4.2.1 of the TAP TSI is: "The railway undertaking shall make available all of its timetable data for which the railway undertaking is responsible as sole or joint carrier and which are related to transport services which are available for purchase by the public by guaranteeing access to all railway undertakings, to third parties and to public bodies. The railway undertaking shall ensure that the timetable data are accurate and up-to-date. The timetable data shall be kept available at least for 12 months after such data have expired."

This use case will focus on the definition of the minimum requirements for passenger information. The required data includes:

  • Basic principles of train variants
  • Representation of a train
  • Different possible ways of representing days of operation
  • Train category/service mode
  • Transport service relationships
  • Coach groups attached to trains
  • Joining to, splitting from
  • Through connections (connecting to)
  • Through connections (change of service number)
  • Details of transport services
  • Stops with traffic restrictions
  • Overnight trains
  • Crossing of time zones
  • Pricing regime and reservation details
  • Information provider
  • Reservation provider
  • Service facilities
  • Accessibility of the train (including scheduled existence of priority seats, wheelchair spaces, universal sleeping compartments)
  • Service extras
  • Connecting — Timing between transport services
  • Station list.

Data Flows and Interfaces / Datenflüsse und Schnittstellen

The data has to be provided by the railway undertaking to other railway undertakings, public authorities and third parties (e.g. ticket vendors). The railway undertaking shall make available the annual timetable at least 2 months before that timetable comes into force. Any changes to the annual timetable shall be made available in a series of timetable updates at least 7 days before those changes take effect.

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

  • infrastructure: <operationalPoint>

Characterizing Data / Charakterisierung der Daten

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

How often do the data change (update)?

  • yearly for LTP planning, to be published by the railway undertaking at least 2 months before the annual timetable enters into force
  • regular changes for STP planning, to be published by the railway undertaking at least 7 days before those changes take effect.

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

  • whole data set: provide the full timetable
  • changes: provide only updated elements (e.g. trains)

Which views are represented by the data (focus)?

To be specified

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
  • services in a train (e.g. dining car)
  • etc.

Such a dataset has to exchanged according to the TAP TSI in the EDIFACT data format. The following files have to be created from the railML-data content:

  • TSDUPD.EDI: Content of the <operationalPoint>-element
  • SKDUPD.EDI: content of the <TT:Tag|timetable>-element
Retrieved from "https://wiki3.railml.org/index.php?title=UC:TT:TAF/TAP_TSI&oldid=7766"