UC:TT:TAF/TAP TSI: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
No edit summary
No edit summary
Line 8: Line 8:
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] includes the timetable data exchange between the railway undertakings, public authorities and third parties for passenger information systems such as a journey planner or print 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.
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] includes the timetable data exchange between the railway undertakings, public authorities and third parties for passenger information systems such as a journey planner or print 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 esxchange 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."''
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:
This use case will focus on the definition of the minimum requirements for passenger information. The required data includes:

Revision as of 13:17, 22 September 2015

Use case / Anwendungsfall / :

TAP TSI static timetable Information; Fahrplanauskunft;


Description / Beschreibung /

Timetable information for the TAP TSI (EC 454/2011) [1] includes the timetable data exchange between the railway undertakings, public authorities and third parties for passenger information systems such as a journey planner or print 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 is 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: <ocp>

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.