| Re: [railML3] Time Dimension requirements from TT view [message #1479 is a reply to message #1462] |
Fri, 20 January 2017 16:53   |
Dirk Bräuer
Messages: 311
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.
|
|
|
|
Members
Search
Help
Login
Home
