| Addendum: [railML3] Time Dimension requirements from TT view [message #1480 is a reply to message #1479] |
Sat, 21 January 2017 13:42   |
Dirk Bräuer
Messages: 311
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.
|
|
|
|
Members
Search
Help
Login
Home
