Home » railML newsgroups » railml.timetable » [railML3] Time Dimension requirements from TT view
| Re: [railML3] Time Dimension requirements from TT view [message #1500 is a reply to message #1479] |
Wed, 15 February 2017 14:46   |
Gerben Schut
Messages: 4
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.
|
|
|
|
Current Time: Thu May 02 04:45:02 CEST 2024
|
Members
Search
Help
Login
Home
