UC:TT:PassengerInformationAtStations: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
No edit summary
No edit summary
Line 7: Line 7:


This use case describes the exchange of data between a system for providing passenger information at a railway station and a timetable planning system. The PIS allows for display of the current schedule including information about the current state of operation such as delays, cancelation or additional trains. In order to do so the schedule as published to the passenger for the current day of operation is necessary. The completeness of this timetable information limits the accuracy of the information available to the passenger by means of the PIS. The mandatory data can be limited to the services run on the current operation day, including all stops of a train with the according arrival and departure times. Additional information for can be provided to model blocks of services (can be used to increase accuracy of forecast information), planned interconnection with other services, planned construction sites with impact on the services, etc.
This use case describes the exchange of data between a system for providing passenger information at a railway station and a timetable planning system. The PIS allows for display of the current schedule including information about the current state of operation such as delays, cancelation or additional trains. In order to do so the schedule as published to the passenger for the current day of operation is necessary. The completeness of this timetable information limits the accuracy of the information available to the passenger by means of the PIS. The mandatory data can be limited to the services run on the current operation day, including all stops of a train with the according arrival and departure times. Additional information for can be provided to model blocks of services (can be used to increase accuracy of forecast information), planned interconnection with other services, planned construction sites with impact on the services, etc.


'''Data Flows and Interfaces / {{Deu|Datenflüsse und Schnittstellen}} / {{Fra|Flux de données et interfaces}} '''
'''Data Flows and Interfaces / {{Deu|Datenflüsse und Schnittstellen}} / {{Fra|Flux de données et interfaces}} '''


A PIS is a pure railML consumer.
A PIS is a pure railML consumer.


Mandatory information imported from timetable system includes:
Mandatory information imported from timetable system includes:
Line 23: Line 18:
* <category>
* <category>
* <ocp>  
* <ocp>  


Optionally imported information includes:
Optionally imported information includes:
Line 36: Line 27:
* <connection> (in order to provide and manage connection information for internal or external services)
* <connection> (in order to provide and manage connection information for internal or external services)
* <statistics>
* <statistics>


If the topology is not imported from railML it is assumed that it is imported from a different source including an appropriate mapping to the ocp’s imported from railML.
If the topology is not imported from railML it is assumed that it is imported from a different source including an appropriate mapping to the ocp’s imported from railML.


'''Interference with other railML® schemas / {{Deu|Interferenz mit anderen railML®-Schemen}} / {{Fra|Interaction avec autres schemas railML®}} '''
'''Interference with other railML® schemas / {{Deu|Interferenz mit anderen railML®-Schemen}} / {{Fra|Interaction avec autres schemas railML®}} '''
Line 48: Line 35:


Optionally: rolling stock
Optionally: rolling stock


'''Characterizing Data / {{Deu|Charakterisierung der Daten}} / {{Fra|Caractérisation des données}} '''
'''Characterizing Data / {{Deu|Charakterisierung der Daten}} / {{Fra|Caractérisation des données}} '''


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


 
<u>How often do the data change (update)?</u>
 
How often do the data change (update)?  


yearly  
yearly  
Line 68: Line 49:




 
<u>How big are the data fragments to be exchanged (complexity)?</u>
How big are the data fragments to be exchanged (complexity)?  


Huge - whole data set  
Huge - whole data set  




 
<u>Which views are represented by the data (focus)?</u>
Which views are represented by the data (focus)?  


Mid term planning (eg. for yearly timetable disposition)  
Mid term planning (eg. for yearly timetable disposition)  
Line 85: Line 64:




Which specific timetable data do you expect to receive/send (elements)?  
<u>Which specific timetable data do you expect to receive/send (elements)?</u>


{| class="prettytable"
{| class="prettytable"

Revision as of 17:53, 21 May 2015

Use case / Anwendungsfall / :

Passenger information at stations / Fahrgastinformation am Bahnhof

Description / Beschreibung /

This use case describes the exchange of data between a system for providing passenger information at a railway station and a timetable planning system. The PIS allows for display of the current schedule including information about the current state of operation such as delays, cancelation or additional trains. In order to do so the schedule as published to the passenger for the current day of operation is necessary. The completeness of this timetable information limits the accuracy of the information available to the passenger by means of the PIS. The mandatory data can be limited to the services run on the current operation day, including all stops of a train with the according arrival and departure times. Additional information for can be provided to model blocks of services (can be used to increase accuracy of forecast information), planned interconnection with other services, planned construction sites with impact on the services, etc.

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

A PIS is a pure railML consumer.

Mandatory information imported from timetable system includes:

  • <train>
  • <trainPart>
  • <category>
  • <ocp>

Optionally imported information includes:

  • <track>
  • <formation>
  • <annotation>/<annotationRef>
  • <rostering>
  • <connection> (in order to provide and manage connection information for internal or external services)
  • <statistics>

If the topology is not imported from railML it is assumed that it is imported from a different source including an appropriate mapping to the ocp’s imported from railML.

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

Mandatory: infrastructure

Optionally: rolling stock

Characterizing Data / Charakterisierung der Daten /

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

How often do the data change (update)?

yearly

regular changes

daily


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

Huge - whole data set


Which views are represented by the data (focus)?

Mid term planning (eg. for yearly timetable disposition)

Short term planning (eg. for trackworks)

Passenger information


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

Element

Mandatory

Remarks

Infrastructure/operationControlPoints/ocp

X

Used for referencing with the PIS topology

<timetable>/<timetablePeriods>/<timetablePeriod>

X


<timetable>/<operatingPeriods>/<operatingPeriod>

X


<timetable>/<categories>/<category>



<timetable>/<annotations>/<annotation>



<timetable>/<trainParts>/<trainPart>/formationTT



<timetable>/<trainParts>/<trainPart>/operatingPeriodRef

X


<timetable>/<trainParts>/<trainPart>/ocpsTT

X


<timetable>/<trainParts>/<trainPart>/ocpsTT/times

X


<timetable>/<trainParts>/<trainPart>/ocpsTT/connections



<timetable>/<trainParts>/<trainPart>/ocpsTT/connections/connection



<timetable>/<trainParts>/<trainPart>/ocpsTT/connections/connection/annotationRef



<timetable>/<trainParts>/<trainPart>/ocpsTT/statistics



<timetable>/<trainParts>/<trainPart>/ocpsTT/sectionTT/runTimes



<timetable>/<trainParts>/<trainPart>/ocpsTT/stopDescription



<timetable>/<trainParts>/<trainPart>/ocpsTT/stopDescription/stopTimes



<timetable>/<trainParts>/<trainPart>/ocpsTT/stopDescription/annotationRef



<timetable>/<trainParts>/<trainPart>/annotationRef



<timetable>/trains/train

X


<timetable>/trains/train/trainPartSequence

X


<timetable>/trains/train/trainPartSequence/trainPartRef

X


<timetable>/rosterings/rostering/blockParts/blockPart



<timetable>/rosterings/rostering/blocks/block



<timetable>/rosterings/rostering/blocks/block/blockPartSequence/blockPartRef




Mit Blick auf den Usecase Fahrgastinformation im Fahrzeug sollte <annotation> u. U. erweitert werden, um das Zielsystem der Sonderinformation zu bestimmen. Ausserdem sollte m. E. nach im rostering der Übergangstyp hinterlegt werden. Das hat Einfluss auf die Prognoseberechnung, sowie die berechnung von Via Zieltexten.

Reminder: geocoordinaten am ocp sollten u.U. auch den Kodierungsstandard enthalten (WGS84, CHxxx).

Retrieved from "https://wiki2.railml.org/index.php?title=UC:TT:PassengerInformationAtStations&oldid=4056"