User:Christian Rößiger: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 48: Line 48:


<u>Which specific timetable data do you expect to receive/send (elements)?</u>
<u>Which specific timetable data do you expect to receive/send (elements)?</u>
''Fill in your application-specific data structure elements, which you are using and want to see modelled in railML 3.''<br>
''Please describe also structures which should be modeled in another way (so called "code refactoring") in railML 3.''<br>
''Attention: This is the most important part of this questionaire. Please define as detailed as possible, the length isn't limited here.''


Used elements:
Used elements:
Line 102: Line 98:
Additional requirements:
Additional requirements:


It must be possible to chain all <trainPart> elements that model one run through group of vehicles. Each of this sequences of <trainPart> elements must have a key that is unique in the railML data as well as in the target system.In the current implementation of railML 2.x it is not clearly defined how this has to be done.  
It must be possible to chain all <trainPart> elements that model one run through group of vehicles. Each of this sequences of <trainPart> elements must have a key that is unique in the railML data as well as in the target system.
One approach is to chain all <trainPart> elements with the same key (code, name, etc.) in an order that the last referenced <ocp> of the current <trainPart> is the same as the first <ocp> of the following <trainPart>.  
 
A better modeling for this aspect is in my opinion to use the concept of commercial trains in another way as described in the wiki: Each commercial train should model exactly on sequence of <trainPart> elements. Today it may contain several "parallel" sequences of <trainPart> elements at the same time, which makes it impossible to figure out which <trainPart> elements of two succeding <trainPartSequence>s must be linked together.
Improvements for further versions:
 
In the current implementation of railML 2.x it is not clearly defined how two <trainPart> elements in succeding <trainPartSequence>s must be chained, to model a run through group of vehicles. One approach is to chain all <trainPart> elements with the same key (code, name, etc.) in an order that the last referenced <ocp> of the current <trainPart> is the same as the first <ocp> of the following <trainPart>. A better modeling for this aspect is in my opinion to use the concept of commercial trains in another way as described in the wiki: Each commercial train should model exactly on sequence of <trainPart> elements. Today it may contain several "parallel" sequences of <trainPart> elements at the same time, which makes it impossible to figure out which <trainPart> elements of two succeding <trainPartSequence>s must be linked together.

Revision as of 15:41, 12 February 2015

Use case / Anwendungsfall / :

Exchange of formation data; Austausch von Wagenreihungen/Behängungsdaten;

Description / Beschreibung /

What is the application behind the use case? Which data are required? Who or which tool/application provides these data? Which data are not included (if not obvious)? Define the boundaries of the use case and the relevant data. (max. 200 words, English)

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

The usecase covers the exchange of the following data:

  • the composition of <trainPart>s of <vehicle>s (using <formation>s)
  • <operatingPeriod>s of <trainPart>s
  • commercial and technical properties of <trainPart>s/<formation>s
  • added and removed <trainPart>s within a <train>

The usecase does not cover the exchange of data concerning the <train>, in particular:

  • changes of the train path or times (<ocpsTT>)
  • added or removed <train>s

As a consequence, it is assumed that both source and target system of the exchanged data must refer to the same set of <train>s, i.e. the <train>s in both system must have the same external identifier and identical (macroscopic) train paths. Since the usecase mainly modifies existing objects in the target system, it is necessary that the railML data can be assigned to the correspoding objects in the target system. This applies for the following railML object types:

  • <train>
  • <trainPart>
  • <ocp>
  • <vehicle>

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

infrastructure, 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)?

weekly-yearly

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

  • infrastructure: big
  • timetable: small (operatingPeriod: tiny)
  • rolling stock: big (formation: tiny)

Which views are represented by the data (focus)?

Mid and short term planning

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

Used elements:

Element Mandatory Remarks
<infrastructure><operationControlPoints><ocp> x
<infrastructure><operationControlPoints><ocp><designator>
<rollingstock><formations><formation> x
<rollingstock><formations><formation><trainOrder><vehicleRef> x
<rollingstock><vehicles><vehicle> x
<rollingstock><vehicles><vehicle><classification><operator>
<rollingstock><vehicles><vehicle><classification><manufacturer>
<timetable><timetablePeriods><timetablePeriod>
<timetable><timetablePeriods><timetablePeriod><holidays><holiday>
<timetable><operatingPeriods><operatingPeriod> x
<timetable><categories><category>
<timetable><trainParts><trainPart> x
<timetable><trainParts><trainPart><formationTT> x
<timetable><trainParts><trainPart><formationTT><passengerUsage><places>
<timetable><trainParts><trainPart><formationTT><passengerUsage><service>
<timetable><trainParts><trainPart><operatingPeriodRef> x
<timetable><trainParts><trainPart><ocpsTT><ocpTT> x
<timetable><trains><train> x
<timetable><trains><train><trainPartSequence> x
<timetable><trains><train><trainPartSequence><trainPartRef> x

Additional requirements:

It must be possible to chain all <trainPart> elements that model one run through group of vehicles. Each of this sequences of <trainPart> elements must have a key that is unique in the railML data as well as in the target system.

Improvements for further versions:

In the current implementation of railML 2.x it is not clearly defined how two <trainPart> elements in succeding <trainPartSequence>s must be chained, to model a run through group of vehicles. One approach is to chain all <trainPart> elements with the same key (code, name, etc.) in an order that the last referenced <ocp> of the current <trainPart> is the same as the first <ocp> of the following <trainPart>. A better modeling for this aspect is in my opinion to use the concept of commercial trains in another way as described in the wiki: Each commercial train should model exactly on sequence of <trainPart> elements. Today it may contain several "parallel" sequences of <trainPart> elements at the same time, which makes it impossible to figure out which <trainPart> elements of two succeding <trainPartSequence>s must be linked together.