| forgotten attribute <operatingPeriod> @dayOffset and its future [message #1602] |
Fri, 09 June 2017 12:02  |
Dirk Bräuer
Messages: 313
Registered: August 2008
|
Senior Member |
|
|
Introduced with railML 2.2, there should be a new attribute @dayOffset at <operatingPeriod>.
It now turned out that this attribute seems simply to have been forgotten.
(The attribute with the same name at <blockPartSequence> is already there since railML 2.0 and therefore no mistake.)
So obviously nobody has missed this attribute and the question arises, whether we should still introduce it and/or transfer it into railML 3.x.
There is a lengthy explanation of this attribute in [1] including several reasons for its introduction. So my suggestion is to introduce @dayOffset at <operatingPeriod> from r2.4 AND transfer it into r3.x.
@Stefan Jugelt: I know several infrastructure managers who do not allow "departureDay=1" at the first <ocp> in their data models. How does ERA deal with this issue? Is there a kind of "dayOffset" in TAP/F TSI, too, or is there "departureDay=1" allowed from the start?
Best regards,
Dirk.
[1] http://wiki.railml.org/index.php?title=TT:Midnight_overrun
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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: 313
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
|
|
|
|
| Re: forgotten attribute <operatingPeriod> @dayOffset and its future [message #2387 is a reply to message #2372] |
Tue, 10 March 2020 13:15 |
Thomas Nygreen
Messages: 74
Registered: March 2008
|
Member |
|
|
Den 09.03.2020 10:08, skrev Dirk Bräuer:
>> 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>.
There will always be data models out there that differ from the railML
data model. As long as we can reflect the information that those data
models need, I don't see a problem. In this case, a system with a native
data model that differs from railML can simply add/subtract/shift on
import/export. Creating redundancy in the model to be closer to more
native data models makes import interfaces more complicated for everyone.
Best regards,
Thomas Nygreen - Common schema coordinator, railML.org
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
