| Re: Delay Causes Representation in RailML [message #831 is a reply to message #828] |
Fri, 19 October 2012 11:18   |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Am 18.10.2012 09:51, schrieb Susanne Wunsch:
> Hi Dirk, Matteo and others,
>
> Dirk Bräuer<dirkbraeuer(at)irfpde> writes:
>>> I just realized that there is no position to define the
>>> "real/actual/current" delays. Whereas the "real/actual/current"
>>> arrival and departure times (and days) are categorized by
>>> scope="actual"'.
>
>> In general, concerning 'scope="actual"':
>>
>> I have some problem with these 'actual' (running) information in a
>> schema called 'timetable'. I think the term 'timetable' implements
>> that it is about planning only, not about 'actual' (running)
>> information.
>
> I would expect that the whole railML file either covers planning data or
> "actual" (running) data. AFAIK the SBB saves all "actual" timetable data
> of a day in a single railML file.
>
Dear all,
just my 2ct:
I don't know what exact use case the original poster has in mind. I can
imagine two:
- either, like the mentioned SBB use case, the information for a
complete day is saved in one file, ex post, e.g. for statistics
- or, more or less real-time, fragmentary information is transmitted.
For the first purpose, I think that the timetable schema could be used
(even if Dirk is right that it is not its intention). However, I would
not use the OperatingPeriod construct to describe every single day.
Rather I would allow to use the original operating periods from the
planning data (e.g., "daily") and provide an additional attribute
"runDay" that identifies the instance the delay refers to. This way, one
could just "enrich" a timetable with actual run information.
At least for the second use case, I vote for reduced redundancy ;-) :
Here, delay information should go into its own hierarchy. A delay
information should
- refer to a trainPart from the planning data
- refer to an OCPTT of the train run
- carry the ocptt-specific delay information.
- optionally, refer to a delay cause.
Once more (see the discussion on connections), this would imply that the
OCPTT need their own IDs.
<delayInfos>
<delayInfo trainPartRef = ... runDay=...>
<delay ocpttref=zzz current=...>
<delayCauses><delayCauseRef ref=.../><delayCauseRef ref=.../></delay>
<delay ... />
</delayInfo>
</delayInfos>
<delayCauses>
<delayCause id=... />
....
About terminology: I would prefer <delayEvent> to <delayCause>.
--Andreas.
|
|
|
|
Members
Search
Help
Login
Home
