| Re: Wiki documentation for border <ocpTT> between two chained <trainPart> [message #1291 is a reply to message #1289] |
Fri, 24 July 2015 16:17  |
Christian Rößiger
Messages: 61
Registered: March 2015
|
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
|
|
|
|
Members
Search
Help
Login
Home
