Home » railML newsgroups » railml.timetable » Delay Causes Representation in RailML
| Delay Causes Representation in RailML [message #818] |
Mon, 08 October 2012 16:39  |
matteo.anelli
Messages: 1
Registered: October 2012
|
Junior Member |
|
|
Hi,
I'm Matteo Anelli and I'm working on the On-Time European Project (
http://www.ontime-project.eu/ )
on behalf of NTT Data.
The project aims to use RailML to model the base data structures of the
project, to allow easier
sharing of information and data by distributed systems.
Working on the data modeling of the delay, I noticed that the entity does
not include any field to model
the reason of delay.
Since the project want to integrate the FICHE UIC 450-2 delay causes (a
two-digit number) I'd like to
see some extended attributes on the Delay Entity. I think a generic
attributes field should be sufficient,
if not a string field for "causes". It's that possible?
Thanks
--
----== posted via PHP Headliner ==----
|
|
|
|
|
|
|
|
|
|
| Re: Delay Causes Representation in RailML [message #826 is a reply to message #824] |
Wed, 17 October 2012 20:35  |
Dirk Bräuer
Messages: 313
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.
|
|
|
|
| Re: Delay Causes Representation in RailML [message #828 is a reply to message #826] |
Thu, 18 October 2012 09:51 |
Susanne Wunsch railML
Messages: 180
Registered: January 2020
|
Senior Member |
|
|
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
|
|
|
|
|
|
| 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.
|
|
|
|
|
|
|
|
| Re: Delay Causes Representation in RailML [message #901 is a reply to message #851] |
Tue, 27 November 2012 12:40 |
Susanne Wunsch railML
Messages: 180
Registered: January 2020
|
Senior Member |
|
|
Hello Joachim, Matteo and others,
At the railML-conference in Zurich we agreed on discussing the aspect of
"actual/real-time" data in a work group after publishing the 2.2
release.
Nevertheless the current railML schemas provide some possibilities for
"actual" data - e.g. the ocpTT/times/@scope attribute.
<ocpTT ...>
<times scope="scheduled" arrival="10:15:00" departure="10:25:00"/>
<times scope="actual" arrival="10:20:17" departure="10:24:13"/>
</ocpTT>
That means that the train part arrived ca. five minutes too late and
departed ca. one minute too early.
coord(at)timetablerailmlorg (Joachim Rubröder) writes:
> 1. There is currently no entity for a 'delay' event in the timetable but
> several '...Delay' attributes within the statistic element
For simple arrival and departure delays the 'statistics' element is not
needed, as shown above.
> 2. A definit list of delay causes would be preferable, but is not
> obvious to define
We agreed on an free string field, that may be pre-defined by a separate
XML file from the railML domain and/or pre-defined by a customer
specific XML file. The UIC-Leaflet would be a good starting point.
> I would therefore suggest to provide an additional "any"-attribute for the
> elements with delay information (mean, median, standardDeviation) as
> immediate quickfix measure for the version 2.2
I would welcome an 'anyAttribute' in the 'times' element. As shown
above, the 'statistics' elements are not needed for this kind of
'actual' data.
As discussed at the railML-conference in Zurich there are strong
arguments against the exchange of 'statistics'-results because of the
lack of transferring its algorithms and covered data set.
> and keep the discussion
> running to get an idea of the appropriate way of describing current data
> and delays in a later version 2.3 or 3.0 of railML.
http://trac.assembla.com/railML/ticket/170
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Goto Forum:
Current Time: Sat Oct 17 02:34:21 GMT+2 2026
|
Search
Help
Members
Login
Home
