Home » railML newsgroups » railml.timetable » Wiki documentation for border <ocpTT> between two chained <trainPart>
Wiki documentation for border <ocpTT> between two chained <trainPart> [message #1286] Tue, 21 July 2015 17:28 Go to next message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 14
Registered: March 2015
Junior 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
Re: Wiki documentation for border <ocpTT> between two chained <trainPart> [message #1288 is a reply to message #1286] Thu, 23 July 2015 14:01 Go to previous messageGo to next message
Burkhard Franke is currently offline  Burkhard Franke
Messages: 4
Registered: October 2014
Junior Member
Hello Christian

thanks for this input. I agree on your point but would not call it a
"recommendation" or "best practice": is there any reason why the border
properties should differ? I cannot think of any.
And how should importing programs deal with contradicting properties
(different station tracks, arrival later than departure, ...) in border
ocps?

So I´d like to raise your point: Exporting programs MUST ensure that
border <ocpTT> do not contain contradictionary information. Otherwise
the railML-file is not (semantically) valid.

Or is this too harsh?

Best regards
Burkhard

--
Burkhard Franke

trafIT solutions gmbh
Heinrichstrasse 48
8005 Zürich

T: (+41)44/271 16 06
F: (+41)44/271 16 08
E: franke(at)trafitch
W: www.trafit.ch

Timetable Stability Analysis: www.OnTime-rail.com
Validation and Visualization of railML data: www.railoscope.com
Re: Wiki documentation for border <ocpTT> between two chained <trainPart> [message #1289 is a reply to message #1288] Fri, 24 July 2015 12:54 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 36
Registered: November 2013
Location: Hanover, Germany
Member
Hello Christian,

did you have a use case where the data for the two ocpTTs was not the
same although it should have been the same?

Maybe there are some use cases where the data would not be the same and
I can think of one customer scenario where this might be the case (not
using railML yet - unfortunately).

If we create the MUST criteria for the exporting system to define which
ocpTT attributes must be identical at a border ocpTT then we also define
must have rules for the importing system and all other railML tools.
On the Wiki page for the ocpTT an example for such a scenario exists and
possibly a description of the 'border ocpTT' and the clarification of
the term makes sense. Together with this we could outline that the
attributes a, b, c do not change at a border ocpTT in all known 'normal'
train operation scenarios. Furthermore, no importing system is expected
to handle/interpret changes if different attributes a, b, c were provided.


Best regards,

Philip Wobst

--
Philip Wobst
Consultant
Planning and Dispatching Systems
HaCon Ingenieurgesellschaft mbH
Lister Str. 15
30163 Hannover
Germany/Deutschland

Tel. +49 511 33699-498
Fax. +49 511 33699-99
mailto: philipwobst(at)haconde
http://www.hacon.de

Registry Court/Amtsgericht: Hannover HRB 1712
Managing Directors/Geschäftsführer:
Michael Frankenberg, Werner Sommerfeld, Peter Talke
Re: Wiki documentation for border <ocpTT> between two chained <trainPart> [message #1291 is a reply to message #1289] Fri, 24 July 2015 16:17 Go to previous message
Christian Rößiger is currently offline  Christian Rößiger
Messages: 14
Registered: March 2015
Junior Member
Hello Philip,

Am 24.07.2015 um 12.54 schrieb Philip Wobst:
> Hello Christian,
>
> did you have a use case where the data for the two ocpTTs was not the
> same although it should have been the same?

I got a railML file with different data in two border ocpTTs, but I
don't believe that this was intended by the creator. Of course I can
imagine usecases where we need different arrival / departure tracks,
stop posts and so on, but my intention was to answer the question: Are
border ocpTTs the right place to model different arrival and departure
locations? I considered the existance of border ocpTTS as a potentially
unwanted and completely redundant consequence of the current railML
timetable structure, so I wanted to "forbid" using them for things that
cannot modeled with non-border-ocpTTs.
If there is consensus under the railML developers that is okay to do so
then I exclude all subordinated attributes of ocpTT for locating a
trains from my initially request, but I expect all other attributes of
border ocpTTs not to be contradictionary. They may be left out e.g.
"departure" in the first ocpTT and "arrival" in the second ocpTT, but if
present in both elements, they must be equal.

> If we create the MUST criteria for the exporting system to define which
> ocpTT attributes must be identical at a border ocpTT then we also define
> must have rules for the importing system and all other railML tools.

What do you mean with "must have rules for the importing system"? I, as
a developer of a importing system look for something like: "The
importing system can trust, that border ocpTT do not contain
contradictionary information(, except for infrastructure references). It
should evaluate both ocpTT elements and merge its data".

> On the Wiki page for the ocpTT an example for such a scenario exists and
> possibly a description of the 'border ocpTT' and the clarification of
> the term makes sense. Together with this we could outline that the
> attributes a, b, c do not change at a border ocpTT in all known 'normal'
> train operation scenarios. Furthermore, no importing system is expected
> to handle/interpret changes if different attributes a, b, c were provided.

I tried to figure out, which attributes come in consideration for a, b,
c and I came to the conclusion, that all attributes (if given) should be
equal, as mentioned above. So I would rather define the exception for
this rule: infrastructure references.

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
Previous Topic: Different wiki documentation for rs:places and tt:places
Next Topic: Unclear wiki description of attribute operationalStopOrdered
Goto Forum:
  


Current Time: Wed Jun 28 21:22:50 CEST 2017