| Re: Delay Causes Representation in RailML [message #828 is a reply to message #826] |
Thu, 18 October 2012 09:51   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
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.
> 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').
+1
I feel uncomfortable with implementing the actual delays in another way
than the actual times.
>> <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?
No, I think that this sub-structure can semantically only be used with
"actual" timetable data.
<train processStatus="actual" ...>
> So, <delayCause>.date has to be one from the <operatingDay> of the
> higher structure?
No, the delay cause does not in any event rely on the train run itself.
Though the delay cause may be dated by some external event that happened
sometimes earlier than the actual run time. In most cases it happened on
the same day as the train runs.
> Is <delayCause>.time redundant to arrivalTime + arrivalDelay, isn't
> it? (If so, please do not tell Andreas!)
No, it depends on the delay cause event, not actually on the actual
train run time or position.
But another aspect would be redundancy of the delay causes for
subsequent stops. Maybe they shouldn't be that deep in the tree but
defined separated and referred to.
> Can I describe a delay (time) without knowing the cause?
Yes. The delay cause characteristics should be optional and extensible.
>> 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!
> ;-)
Thanks. ;-)
Some ideas from the UIC 450-2 for the above event:
- Activation of the emergency alarm by or for a third party
- Ejection of passengers from the train
- Police intervention in the train
- Intervention of emergency or medical services
- Intervention by fire service
- Collision with road vehicles
- Bomb alarm, suspect luggage
- Escaped animals
- Death or birth in the train
- Arson
- Malicious acts
- Demonstrations
- Vandalism
- Embankment fire
> 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!
That didn't come out of my head, it is summarized from the UIC 450-2
leaflet. There are special codes for these categories that some software
should re-calculate if needed.
I didn't want to go the easiest way with introducing an attribute
"uicDelayCauseCode" for two digits. ;-)
Kind regards...
Susanne
|
|
|
|
Members
Search
Help
Login
Home
