Re: Delay Causes Representation in RailML [message #826 is a reply to message #824] |
Wed, 17 October 2012 20:35 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to previous message](/forum/theme/default/images/down.png) |
Dirk Bräuer
Messages: 311 Registered: August 2008
|
Senior Member |
|
|
Dear Susanne and all others,
> 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"'.
>
> I would not recommend using the 'mean' element therefore, no matter
> that
> the mean value of one value is the same as the value itself. ;-)
I agree.
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 am not sure whether it is possible to describe the aspects of 'actual'
(running) information in a proper way with current RailML. We have some
information about that but they are more dead bodies from RailML1...
But, this should not mean that such information should not be possible in
RailML. I just feel a little bit uncomfortable if we now extend the
'actual' information in such a considerable way before discussing the
general matter. As Andreas Tanner wrote: There would be necessary more to
describe 'actual' information in the current timetable schema. Especially,
there would be a need to describe the actual day. At least, this means to
document that <trains>/<trainParts> which a 'scope="actual"' do need an
<operatingDay> for only one day (bitMask with only one '1').
> <current arrivalDelay="PT2M">
> <delayCauses>
> <delayCause id="dc1" time="17:12:00Z" date="2012-10-14"
Well, I see that you want to code the actual day in a <delayCause>? Does
this mean that you want to add this structure as a sub-structure of the
'planned' train?
So, <delayCause>.date has to be one from the <operatingDay> of the higher
structure?
Is <delayCause>.time redundant to arrivalTime + arrivalDelay, isn't it?
(If so, please do not tell Andreas!)
Can I describe a delay (time) without knowing the cause?
--
> description="Something really special happened">
> <otherResponsible>
> <external subject="outsideInfluence"/>
I do not see the reason for the element name "external" but anyway, I
confess I do not understand all of it. I do not need to. I trust you! ;-)
--
> subject="timetableCompilation"/
The "subject" attribute of <management>, <infrastructureInstallations>,
<civilEngineering> a. s. o. is just what I meant with
>> I would suggest to allow multiple reasons in a kind they could easily
>> be extended later (e. g. enumerable element).
So: Very good. I would not see a need to group them at <management>,
<infrastructureInstallations>, <civilEngineering> a. s. o. From my side,
it would be enough just to enumerate them all in one attribute. I think
currently and in near, middle future nobody will know the reasons in such
a detailed way... But of course it is theoretically ok!
Best regards,
Dirk.
|
|
|