[railML2] extension suggestion for the element <state> for open time period [message #2676] |
Mon, 08 March 2021 11:50 |
Torben Brand
Messages: 158 Registered: March 2016
|
Senior Member |
|
|
Background:
The element <state> is part of railML2.4 and is used to define the status of infrastructure pieces with a given time frame for a certain duration. It is a sub-element that can be placed under nearly all infrastructure elements.
Suggestion:
The element <state> should be enhanced to be able to function outside the range of <operatingPeriod>.
In railML2.4, the timeframe for state is defined for days with the usage of @startDate and @endDate in <operatingPeriod> and more refined for the time within those days with the @startTime, @endTime and @endDayOfset in <state> . This model is restricted by:
- The timeframe must be closed. I.e. both @startDate and @endDate in <operatingPeriod> must be used.
- A timeframe of the <timetablePeriod> must be set.
- The timeframe of <operatingPeriod> must be within the timeframe of the <timetablePeriod>.
- The <timetablePeriod> can be as short or as long as required.
This restricts the UC requirements for:
- open time period: only a start date or end date is set
- time period outside the <timetablePeriod> and thus outside the <operatingPeriod>
For more details see document "railML2.4nor Infrastructure Documentation" (https://www.jernbanedirektoratet.no/railML), version 1.4, 17.12.2020, point 4.14.
Jernbanedirektoratet suggest adding in railML2.5 the attributes to <state>:
@startDate: First day the stated status is valid for. If no @startTime is set the status is valid from the beginning of the day.
@endDate: Last day the stated status is valid for. If no @endTime is set the status is valid until the end of the day.
Suggestion for syntactic constraint:
@operatingPeriodRef: shall only be used in cases of recurring time periods, e.g. a certain element is closed each Tuesday
What does the community think?
|
|
|