Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • railML 2 railML 2
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Graph
    • Compare revisions
  • Issues 50
    • Issues 50
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Releases
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • railML.orgrailML.org
  • railML 2railML 2
  • Issues
  • #394
Closed
Open
Issue created Oct 05, 2020 by Organisation@organisation.GOVOwner

Extend <state> element for use in area

Description

The time aspects of the state are not modelled properly: a <state> can be linked with an <operatingPeriod> that is specified by a begin and an end DATE. The <state> itself has additional parameters to reference a begin and end TIME and a day offset. All in all, this model does not meet all the requirements from the railML community.

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.

This ticket was raised by Norway as part of the standardization in Norway and shall be used commonly in the future.

The element <state> should be enhanced to be able to function as a sub-element of <operatingPeriod> in the Norwegian sector.

In railML2.4, the usage of @startDate and @endDate in <operatingPeriod> is restricted by:

  • The timeframe must be closed. I.e. both @startDate and @endDate 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.

Due to these requirements railML2.4nor requires the usage of the following for:

• Single time period: <state>@startDate and/or <state>@endDate (open or closed time periods)
• Recurring time periods: <state>@operatingPeriodRef with <operatingPeriod>@startDate and <operatingPeriod>@endDate

For more details see document “railML2.4nor Infrastructure Documentation“ (https://www.jernbanedirektoratet.no/railML), version 1.3, 03.07.2020, point 4.14.

Sub-elements:

  • <additionalRunningTime>

For description of sub-elements see document above, point 4.14.3 and ticket #395.

Links

  • Forum discussion:
    • Torben Brand, 08.03.2021: [https://www.railml.org/forum/index.php?t=msg&th=800&goto=2676&#msg_2676]
  • Trac tickets:
    • #394
  • Wiki documentation:
    • IS:state (with length): [https://wiki2.railml.org/wiki/IS:state_(with_length)]
    • IS:state: [https://wiki2.railml.org/wiki/IS:state]

Proposed solution in railML 2.5

The element <state> shall be enhanced with two optional attributes:

  • @startDateTime (xs:dateTime) to specify begin date AND time for the state
  • @endDateTime (xs:dateTime) to specify end date AND time for the state

In addition, the following semantic rules need to be considered and added to the wiki:

  • use @startDateTime and/or @endDateTime to specify an open or closed timespan for the state's validity that is not linked with an <operatingPeriod>
  • use @startTime and/or @endTime (and @endDayOffset) to specify an open or closed timespan for the state linked with an <operatingPeriod> where @startDate and/or @endDate are defined
Edited Apr 04, 2025 by IS Coordination
Assignee
Assign to
Time tracking

railML.org e.V. (Registry of Associations: VR 5750) Phone: +49 351 47582911 Altplauen 19h; 01187 Dresden; Germany