Home » railML newsgroups » railml.timetable » [railML3] Time Dimension requirements from TT view
[railML3] Time Dimension requirements from TT view [message #1462] Fri, 23 December 2016 14:37 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 45
Registered: January 2016
Member
Dear railML TT community,

within the ongoing development process of the new railML v3 model and
schema, the topic "Time Dimension" is currently in the focus. The aim is
to provide a model of time aspects that fulfills all the requirements
from the different fields of application.

The timetable use cases already deal with with a lot and specific time
related information and railML.org would like to integrate this long
lasting knowledge into the railML3 development process, which is up to
now dominated by railway infrastructure managers and their view.
Therefore, I will be very happy if you provide answers and comments on
the following questions:
  1. What are the time scales that are used in railML TT use cases
    (seconds, minutes, days, ...)?
  2. How are time aspects in railML TT applications usually structured?
    Shall the bitmask structure be considered within the joint time
    dimension model?
  3. Do you use patterns for repeating events?
  4. How do you deal with changes in infrastructure? Which changes of
    infrastructure are relevant for TT? See also post from Mico Micic about
    topology reference data [1].
  5. Which infrastructure changes are especially important for timetabling?
    E.g. Removed switches, new switches, decommissioned tracks, relocated
    signals etc.
  6. What requirements do you have for the precision of infrastructure
    positioning?
  7. Besides timetable periods do you require additional timestructures
    like project phases of construction work?
  8. What kind of metadata (descriptive data) about the actual
    infrastructure data could be helpful for timetabling?
Any comments appreciated...
Thank you very much for your help and Merry Christmas everyone!

Christian

[1] http://www.railml.org/forum/index.php?t=msg&th=476&s tart=0&

--
Christian Rahmig
railML.infrastructure coordinator

[Updated on: Thu, 19 January 2017 14:51] by Moderator

Report message to a moderator

Re: [railML3] Time Dimension requirements from TT view [message #1472 is a reply to message #1462] Mon, 09 January 2017 10:09 Go to previous messageGo to next message
Philip Wobst is currently offline  Philip Wobst
Messages: 36
Registered: November 2013
Location: Hanover, Germany
Member
Dear Christian,

I have added this topic to the agenda of the next TT developer meeting and the results will be posted in the forum afterwards.
For all those who will not take part in the meeting in Dresden in two weeks, please provide the answers to Christian directly via the forum.

Philip

--
Philip Wobst
railML.timetable coordinator
Re: [railML3] Time Dimension requirements from TT view [message #1479 is a reply to message #1462] Fri, 20 January 2017 16:53 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 212
Registered: August 2008
Senior Member
Dear Christian,

we discussed the matter of your question yesterday during the TT
developer meeting. And here are the results of the international jury:

> * What are the time scales that are used in railML TT use cases
> (seconds, minutes, days, ...)?

We have times in xml:time format with hours, minutes, seconds, and parts
of seconds, whereas usually seconds and their parts are optional.

It may also be possible to use other parts of xml:time format (such as
time zones).

We use integer values to describe times after midnight, times of the
following day in the attributes
<timetable>...<trainParts>...<ocpTT>...<times arrivalDay=...
departureDay=.../>
(see remarks later).

We have dates in xml:date format.
We have bit-masks (strings of digits 0/1) for the dates following a
given start date.
We have no special solution for the double hour when switching from
Daylight Saving Time to standard time and we do currently see no demand
for it.

> * How are time aspects in railML TT applications usually structured?
> Shall the bitmask structure be considered within the joint time
> dimension model?

We cannot say much of a joint time model since we do not know the
demands on infrastructure. However, the bit-masks are used for repeating
weekdays as well as for the whole timetable period. We can imagine that
there is a wish to model opening/closing times of signal boxes or
stations or maintaining periods on a weekday basis or during a timetable
period. This would fit to the background of bit-masks we use.

Also, it may be more difficult to model time structures in a <common>
(joint) section and then to inherit these structures for <timetable>.
So: Yes, probably they should be considered within the joint time
dimension model.

> * Do you use patterns for repeating events?

Yes, mainly bit-masks. See previous answers.

In the current (railML 2.x) schemes, see
<timetable>.<operatingPeriods>.<operatingPeriod>
which is the main container for calendar information whether repeating
or not.

> * How do you deal with changes in infrastructure? Which changes of
> infrastructure are relevant for TT? See also post from Mico Micic about
> topology reference data [1].

So far, changes of <infrastructure> are only considered marginally. We
consider the infrastructure to be constant for one railML file, or with
other words: The <infrastructure> in a timetable-related railML file
describes the infrastructure used for that timetable, independently from
whether it really existed at any time or not.

The SBB's (Mico's) new attributes is one solution to handle the problem
in a more structured way.

> * Which infrastructure changes are especially important for timetabling?
> E.g. Removed switches, new switches, decommissioned tracks, relocated
> signals etc.

In general: All. Currently: Rather none, concerning the previous answer.

Since you ask for "especially" important: Blockings of tracks, lines
and/or stations due to maintenance or regular (scheduled) blockings
(opening times of signal boxes, may be swing bridge opening times) are
most common to be considered in timetabling.

> * What requirements do you have for the precision of infrastructure
> positioning?

One metre. (For Americans: One meter.)

> * Besides timetable periods do you require additional timestructures
> like project phases of construction work?

From timetabling, we of course look for exact dates (with no delays!)
rather than "planned phases"... So, for this there currently no demand
from us.

However, it should be possible to describe "virtual days" even within
the <timetable> structure - and therefore also outside. These "virtual
days" are typical for long-term planning and then describe for instance
"working day", "holiday", "summer-day". There are combinations of day
descriptions such as "holiday when summer-day", "Monday to Friday when
holiday, but not summer-day" or "The day after Sunday or holiday when
working day".

This is possible rudimentary in the current scheme but there is also a
suggestion to improve this for railML 3.0 (a suggestion by IVU). We
possibly can provide the suggestion during the next months.

> * What kind of metadata (descriptive data) about the actual
> infrastructure data could be helpful for timetabling?

There is no more demand for metadata from us then what is possible in
railML 2.x.

There may be demand on (more) infrastructure versioning metadata, even
maybe the <infrastructure> element shall be allowed several times in a
railML file with disjunct versions or validity dates. What do you mean
exactly with metadata?

With best regards,
Dirk.
Addendum: [railML3] Time Dimension requirements from TT view [message #1480 is a reply to message #1479] Sat, 21 January 2017 13:42 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 212
Registered: August 2008
Senior Member
Dear Christian and all "along-readers",

in my last post I wrote "(see remarks later)" but it seems that I forgot
to write the remarks later... Sorry. Here are the remarks concerning
midnight-overrun:

When modelling validity times of infrastructure elements, I recommend
thinking about the midnight-overrun phenomenon. In <timetable>, this
phenomenon led to the attributes
<timetable>...<trainParts>...<ocpTT>...<times arrivalDay=...
departureDay=.../>

Firstly, these attributes only dis-burden us from the necessity to name
a second <operatingPeriod> after a train has passed midnight. Since
infrastructure normally does not move (in contrast to trains), it seems
that there is no need to do so for the validity of infrastructure. For
instance:

[1] <is:maintenanceWorks validFrom="2017-03-21 21:00:00"
validTo="2017-03-23 05:00:00" />

seems to be identical (and easier) than

[2] <is:maintenanceWorks validFrom="2017-03-21 21:00:00"
validToDay="+2" validToTime="05:00:00" />

But, if you have repeating times as

[3] <is:maintenanceWorks
validFromOperatingPeriodRef="op_FridaysInMarch2017"
validToDay="op_SundaysInMarch2017" />

would lead to create two nearly identical <operatingPeriod>s which only
differ by two days. And you open up discrepancies if the two
<operatingPeriod>s do not have the same number of days. Therefore, it
may be easier to say

[4] <is:maintenanceWorks
validFromOperatingPeriodRef="op_FridaysInMarch2017" validToDayOffset="+2" />

And lastly, if you have "virtual days" which do not have a date (yet)
sometimes you cannot say what are the following days:

[5] <is:maintenanceWorks
validFromOperatingPeriodRef="op_WorkingDaysBeforeHolidaysInMarch "
validToDayOffset="+2" />

In this example, you cannot say (more exactly) which days are "two days
after working days before holidays in march" of each year without
knowing a certain year, calendar and holiday rule. This may be a bad
example for maintenance works (since probably nobody plans maintenance
works such regularly in advance) but imagine signal box opening times or
swing-bridge opening times or such...

Conclusion: I would recommend the following rule:

When modelling (possible repeating) time periods, _never_ enforce naming
a start and an end date (=operating period). Only use _one_ date (=one
operating period) and a relative day offset!

(Please understand as a recommendation only.)

With best regards,
Dirk.
Re: [railML3] Time Dimension requirements from TT view [message #1500 is a reply to message #1479] Wed, 15 February 2017 14:46 Go to previous messageGo to next message
Gerben Schut is currently offline  Gerben Schut
Messages: 2
Registered: September 2016
Junior Member
Dear RailML TT community,

First I'd like to introduce myself: I'm Gerben Schut, part of the Infra
Structure WG for RailML for about 2 years, Information Architect @
ProRail (NL), and have almost 10 years experience with the Dutch
Infrastructure software (Infra Atlas), where the time dimension on
infrastructure is managed now for about 15 years.

I would like to thank you for the answers from Dirk Bräuer. They are
really helpful in understanding the needs of the TT community regarding
the time dimension and what it means for the infrastructure information.

As you mentioned it is important to understand the different time
dimension dynamics: Time Tabling always requires a stable
Infrastructure, and changes in Infrastructure will almost always lead to
a changed timetable. So a specific time table will be based on one
stable infrastructure situation.

Time dimension in Time tabling is not the same as Time dimension in
Infrastructure.

These different situations require a different model, although off
course some base elements could and should be shared (like xml:time).
Therefore it is good to get to know each other needs and use cases, so
we can be clear about the different parts and about the shared parts.

It will be very interesting to discover the grey zone: There where the
Infrastructure is less stable (IE bridge closing times, opening hours of
tracks/stations), the Time Table will depend on those variations. At
least there where the changing times on the Infrastructure are stable
(bridge is always open from 7:00 - 7:15 pm) the interfacing between
infrastructure and time table should be defined and information
exchangeable, so these should be clearly formatted in the RTM to get
them properly into RailML.

We have planned to meet with the Infrastructure time dimension subgroup
on 21th of February in Frankfurt. We will try to understand both worlds,
and post any remaining questions in this forum topic. Thanks for your
kind understanding and support!

Kind Regards,
Gerben Schut



On 20-1-2017 16:53, Dirk Bräuer wrote:
> Dear Christian,
>
> we discussed the matter of your question yesterday during the TT
> developer meeting. And here are the results of the international jury:
>
>> * What are the time scales that are used in railML TT use cases
>> (seconds, minutes, days, ...)?
>
> We have times in xml:time format with hours, minutes, seconds, and parts
> of seconds, whereas usually seconds and their parts are optional.
>
> It may also be possible to use other parts of xml:time format (such as
> time zones).
>
> We use integer values to describe times after midnight, times of the
> following day in the attributes
> <timetable>...<trainParts>...<ocpTT>...<times arrivalDay=...
> departureDay=.../>
> (see remarks later).
>
> We have dates in xml:date format.
> We have bit-masks (strings of digits 0/1) for the dates following a
> given start date.
> We have no special solution for the double hour when switching from
> Daylight Saving Time to standard time and we do currently see no demand
> for it.
>
>> * How are time aspects in railML TT applications usually structured?
>> Shall the bitmask structure be considered within the joint time
>> dimension model?
>
> We cannot say much of a joint time model since we do not know the
> demands on infrastructure. However, the bit-masks are used for repeating
> weekdays as well as for the whole timetable period. We can imagine that
> there is a wish to model opening/closing times of signal boxes or
> stations or maintaining periods on a weekday basis or during a timetable
> period. This would fit to the background of bit-masks we use.
>
> Also, it may be more difficult to model time structures in a <common>
> (joint) section and then to inherit these structures for <timetable>.
> So: Yes, probably they should be considered within the joint time
> dimension model.
>
>> * Do you use patterns for repeating events?
>
> Yes, mainly bit-masks. See previous answers.
>
> In the current (railML 2.x) schemes, see
> <timetable>.<operatingPeriods>.<operatingPeriod>
> which is the main container for calendar information whether repeating
> or not.
>
>> * How do you deal with changes in infrastructure? Which changes of
>> infrastructure are relevant for TT? See also post from Mico Micic about
>> topology reference data [1].
>
> So far, changes of <infrastructure> are only considered marginally. We
> consider the infrastructure to be constant for one railML file, or with
> other words: The <infrastructure> in a timetable-related railML file
> describes the infrastructure used for that timetable, independently from
> whether it really existed at any time or not.
>
> The SBB's (Mico's) new attributes is one solution to handle the problem
> in a more structured way.
>
>> * Which infrastructure changes are especially important for timetabling?
>> E.g. Removed switches, new switches, decommissioned tracks, relocated
>> signals etc.
>
> In general: All. Currently: Rather none, concerning the previous answer.
>
> Since you ask for "especially" important: Blockings of tracks, lines
> and/or stations due to maintenance or regular (scheduled) blockings
> (opening times of signal boxes, may be swing bridge opening times) are
> most common to be considered in timetabling.
>
>> * What requirements do you have for the precision of infrastructure
>> positioning?
>
> One metre. (For Americans: One meter.)
>
>> * Besides timetable periods do you require additional timestructures
>> like project phases of construction work?
>
> From timetabling, we of course look for exact dates (with no delays!)
> rather than "planned phases"... So, for this there currently no demand
> from us.
>
> However, it should be possible to describe "virtual days" even within
> the <timetable> structure - and therefore also outside. These "virtual
> days" are typical for long-term planning and then describe for instance
> "working day", "holiday", "summer-day". There are combinations of day
> descriptions such as "holiday when summer-day", "Monday to Friday when
> holiday, but not summer-day" or "The day after Sunday or holiday when
> working day".
>
> This is possible rudimentary in the current scheme but there is also a
> suggestion to improve this for railML 3.0 (a suggestion by IVU). We
> possibly can provide the suggestion during the next months.
>
>> * What kind of metadata (descriptive data) about the actual
>> infrastructure data could be helpful for timetabling?
>
> There is no more demand for metadata from us then what is possible in
> railML 2.x.
>
> There may be demand on (more) infrastructure versioning metadata, even
> maybe the <infrastructure> element shall be allowed several times in a
> railML file with disjunct versions or validity dates. What do you mean
> exactly with metadata?
>
> With best regards,
> Dirk.
Re: [railML3] Time Dimension requirements from TT view [message #1501 is a reply to message #1500] Fri, 17 February 2017 13:07 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 212
Registered: August 2008
Senior Member
Dear Gerben,

thank your for your reply.

I understand that you opt for only a small amount of shared time-related
structures between <infra> and <timetable> sub-schemes of railML.

This may be the easiest way but I am currently not convinced of it being
the best way.

As you wrote, there is a "grey zone" which is not exactly defined.
(There may be different opinions about where the responsibility of an
infrastructure department ends and where a "timetable" begins.) Also,
from my experience, the grey zone becomes larger each year with more and
more infrastructure work influencing the timetables (less "stable"
infrastructure).

So, I think there should be a common solution. Since <timetable> has
naturally more time-related elements than infrastructure, it could be
advisable to adopt <timetable> structures for <infrastructure>.

Unfortunately, the appointment of 21th of February (of the year 2017, I
presume) comes a little bit too quick for me to join. However, if I can
help anyway with experience or structures please don't hesitate to
contact me.

With best regards,
Dirk Bräuer.


---
Am 15.02.2017 um 14:46 schrieb Schut, GD (Gerben):
> Dear RailML TT community,
>
> First I'd like to introduce myself: I'm Gerben Schut, part of the Infra
> Structure WG for RailML for about 2 years, Information Architect @
> ProRail (NL), and have almost 10 years experience with the Dutch
> Infrastructure software (Infra Atlas), where the time dimension on
> infrastructure is managed now for about 15 years.
>
> I would like to thank you for the answers from Dirk Bräuer. They are
> really helpful in understanding the needs of the TT community regarding
> the time dimension and what it means for the infrastructure information.
>
> As you mentioned it is important to understand the different time
> dimension dynamics: Time Tabling always requires a stable
> Infrastructure, and changes in Infrastructure will almost always lead to
> a changed timetable. So a specific time table will be based on one
> stable infrastructure situation.
>
> Time dimension in Time tabling is not the same as Time dimension in
> Infrastructure.
>
> These different situations require a different model, although off
> course some base elements could and should be shared (like xml:time).
> Therefore it is good to get to know each other needs and use cases, so
> we can be clear about the different parts and about the shared parts.
>
> It will be very interesting to discover the grey zone: There where the
> Infrastructure is less stable (IE bridge closing times, opening hours of
> tracks/stations), the Time Table will depend on those variations. At
> least there where the changing times on the Infrastructure are stable
> (bridge is always open from 7:00 - 7:15 pm) the interfacing between
> infrastructure and time table should be defined and information
> exchangeable, so these should be clearly formatted in the RTM to get
> them properly into RailML.
>
> We have planned to meet with the Infrastructure time dimension subgroup
> on 21th of February in Frankfurt. We will try to understand both worlds,
> and post any remaining questions in this forum topic. Thanks for your
> kind understanding and support!
>
> Kind Regards,
> Gerben Schut
>
>
Re: [railML3] Time Dimension requirements from TT view [message #1506 is a reply to message #1501] Mon, 20 February 2017 16:12 Go to previous message
Gerben Schut is currently offline  Gerben Schut
Messages: 2
Registered: September 2016
Junior Member
Dear Dirk,

Thanks for your reply.

I do agree with you in the common approach as much as possible.
Thats why I'm very curious about which structures and elements the TT
group nominates for reuse / adopting in Infrastructure.

As Infrastructure changes with "projects" (in any kind), the
Infrastructure time dimension is concentrating around that topic.

If you can provide us with a model or structure of the TT scheme
regarding time elements, it would be very helpful for us. This gives us
the opportunity to compare both structures and see which elements could
be marked as common or reused.
It is a pity you can not join our meeting tomorrow but we appreciate
your help! Thanks!

Kind regards,
Gerben Schut

[Updated on: Tue, 21 February 2017 09:40]

Report message to a moderator

Previous Topic: Schnittstelle railML zu VDV452
Next Topic: Minutes for railML TT meeting 17nd January 2017
Goto Forum:
  


Current Time: Wed Jun 28 07:22:36 CEST 2017