| Re: forgotten attribute <operatingPeriod> @dayOffset and its future [message #2372 is a reply to message #2367] |
Mon, 09 March 2020 10:08   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Thomas,
thank you for your good analysis of my posts on this topic over several years. I still think there is a misunderstanding:
- It is true that in 2012, I argued for throwing away of the attribute @dayOffset at <operatingPeriod> for the sake of less redundancy.
- In [1], there are arguments against the usage of shifted <operatingPeriod>s in the section "Why not use shifted/rotated <operatingPeriod>s".
- So what to do after midnight when there is no attribute @dayOffset at <operatingPeriod> and shifting of the <operatingPeriod> is not wanted? The only solution left is using departureDay<>0 at first <ocpTT>. And for this, I already wrote on 09.06.2017 and 21.06.2017:
> No problem of technology from my side, but as I said, there are several infrastructure managers who do not allow it in their data models.
So again: We can life without the attribute @dayOffset at <operatingPeriod>, but that means allowing departureDay<>0 at first <ocpTT>. This is less redundancy but more incompatibility to other data models of infrastructure managers who expect departureDay=!0 at first <ocpTT>.
Unfortunately my direct question to Stefan Jugelt of ERA, how is it done in TAP/F TSI, was not answered yet.
So as there seems to be no current problem, I think we can leave it for now and can come possibly back to that discussion in railML 3.x timetable operating periods.
Best regards,
Dirk.
[1] http://wiki.railml.org/index.php?title=TT:Midnight_overrun
|
|
|
|
Members
Search
Help
Login
Home
