| Wiki documentation for border <ocpTT> between two chained <trainPart> [message #1286] |
Tue, 21 July 2015 17:28  |
Christian Rößiger
Messages: 60
Registered: March 2015
|
Member |
|
|
Hello everyone,
due to some problems while importing railML timetable data I thought
about some rules concerning border <ocpTT> between two chained
<trainPart> elements. Example:
<trainParts>
<trainPart id='_tp1'>
<ocpsTT>
<ocpTT ocpRef='_ocp_A'/>
<ocpTT ocpRef='_ocp_B'/>
<ocpsTT>
</trainPart>
<trainPart id='_tp2'>
<ocpsTT>
<ocpTT ocpRef='_ocp_B'/>
<ocpTT ocpRef='_ocp_C'/>
<ocpsTT>
</trainPart>
</trainParts>
(Both train parts are referenced by the same <train> using two
consequent <trainPartSequence> elements)
The <ocpTT> data for "_ocp_B" is included in both train parts. Therefore
it's evident that both <ocpTT> nodes should not contain contradictionary
information.
So I came to following rules which I would like to transfer to the "Best
practice" section of the <ocpTT> wiki page if anyone agrees:
- Exporting programs should ensure, that border <ocpTT> do not contain
contradictionary information. All properties concerning the stop or the
passing of the train (e.g. ocpType, stopDescription, trackRef) should
have the same values.
- Importing programs should read attributes concerning arrival from the
<ocpTT> element of the previous <trainPart>, attributes concerning
departure from the <ocpTT> of the next <trainPart>
- It is not recommended to use border <ocpTT> to model a stop or passing
in a ocp with different properties for arrival and departure, e.g. a
different <trackRef> for the arrival and departure track
Kind regards
Christian Rößiger
--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
|
|
|
|
Members
Search
Help
Login
Home
