|
|
| Line 1: |
Line 1: |
| {{useCase|TT||title=Timetable Information|IS=1|RS=1|RL=1|reporter=HaCon}} | | {{mirror}} |
| | |
| {{UC title}}
| |
| Timetable Information; {{Deu|Fahrplanauskunft}}; {{Fra|nom descriptif en Francais}}
| |
| | |
| {{UC 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).
| |
| | |
| {{UC data}}
| |
| 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)?'').
| |
| | |
| {{UC interference}}
| |
| * infrastructure: {{IS:Tag|ocp}}
| |
| * rolling stock: {{RS:Tag|formation}} (?)
| |
| * interlocking: -
| |
| | |
| {{UC data}}
| |
| This section serves to specify the required data regarding certain aspects.
| |
| | |
| {{UC update}}
| |
| *''yearly'' for LTP planning
| |
| *''regular changes'' for STP planning
| |
| *''daily'' for VSTP planning
| |
| | |
| {{UC 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)
| |
| | |
| {{UC 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!)
| |
| | |
| {{UC elements|TT}}
| |
| As a bare minimum the commercial view of a {{TT:Tag|train}} can be reduced to one {{TT:Tag|trainPart}} with a sequence of {{TT:Tag|ocpTT}} elements with commercially relevant stops ({{TT:Tag|stopDescription}} with commercial='true'). For the each stop the following data is shown:
| |
| * published times: {{TT:Tag|times}} element with scope='published'
| |
| * connections: {{TT:Tag|connection}} element(s) with connType='commercial'
| |
| * stop description: only {{TT:Tag|stopDescription}} elements with commercial='true' will be relevant including their {{TT:Tag|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 {{TT:Tag|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 = '''l'''ong '''t'''erm '''p'''lanning: the yearly timetable(s)
| |
| * STP = '''s'''hort '''t'''erm '''p'''lanning: 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.)
| |