|
|
Line 440: |
Line 440: |
| |uelem={{tag|is|infrastructure}}, {{tag|is|controller}} and others | | |uelem={{tag|is|infrastructure}}, {{tag|is|controller}} and others |
| }} | | }} |
| | ==={{tag|is|track}} extended by child {{tag|is|impairmentSections}}=== |
| | {{change |
| | |fact={{tag|is|track}} has been extended by child {{tag|is|impairmentSections}} (container) and childs. |
| | |reason=Element {{tag|IS|impairmentSection}} is designed to address sections with impaired railway operations. |
| | |recomendation=Employ {{tag|is|impairmentSection|@=areaRef}} to reference a {{tag|is|genericArea}} and {{tag|is|impairmentSection}}>{{tag|is|additionalRunningTime|@=value}} to indicate the delay. |
| | |trac={{ticket|395}} |
| | |svn= |
| | |example= |
| | |xsd= |
| | |nattr= |
| | |uattr= |
| | |nelem={{tag|is|impairmentSections}} & recursive childs |
| | |uelem={{tag|is|track}} |
| | }} |
| | |
| ==={{@|startDateTime|IS:state}} and {{@|endDateTime|IS:state}} have been added to {{tag|is|state}}=== | | ==={{@|startDateTime|IS:state}} and {{@|endDateTime|IS:state}} have been added to {{tag|is|state}}=== |
| {{change | | {{change |
Revision as of 11:30, 3 December 2021
railML® schema changes between railML® 2.4 and railML® 2.5
This site is intended to collect the schema changes between railML® 2.4 and railML® 2.5.
A complete diff comparison will soon be available under Dev:changes/2.5/diff.
Changes are also marked on the element pages with (introduced with version 2.5) for introduced components and (deprecated with version 2.5) for components that became obsolete. All occurances of these tags are listed in Category:Intro/2.5 respectively Category:Depr/2.5.
For changes with other version upgrades see Dev:changes.
Common Subschema
Timetable Subschema
New value other:anything for <category>@trainUsage
Fact:
|
<category>@trainUsage has been extended to allow for custom values
|
Reason:
|
The demand for more distinguished categories appeared in this discussion (link to the railML® website)
|
Related Development Tickets:
|
#375
|
Related Commits:
|
[1039] (Note on legacy SVN commits)
|
Updated XSD file(s):
|
railwayBaseTypes.xsd
|
Updated attribute(s):
|
<category>@trainUsage
|
Updated element(s):
|
<category>
|
New values conceptual and offered for <trainPartSequence>@pathStatus
Fact:
|
<trainPartSequence>@pathStatus has been extended to allow for the values conceptual and offered to improve how to express the state of an slot order
|
Reason:
|
The demand for clearer modelling of the states for slot ordering showed up in [this discussion this discussion] (link to the railML® website)
|
Related Development Tickets:
|
#378
|
Related Commits:
|
[1039] (Note on legacy SVN commits)
|
Updated attribute(s):
|
<trainPartSequence>@pathStatus
|
Updated element(s):
|
<trainPartSequence>@pathStatus
|
New @type for <annotation>; changed multiplicity for <text>
Fact:
|
In order to allow communication of changes to certain train parts a new optional attribute was added to <trainPart>. With this it is possible to specify the last change date for a trainParts change.
|
Reason:
|
Requirement from the community.
|
Related Development Tickets:
|
#471
|
Related Commits:
|
[1039] (Note on legacy SVN commits)
|
New attribute(s):
|
@lastModified
|
Updated element(s):
|
<trainPart>
|
Fact:
|
In order to allow specification of alternative ways to reach the next OCP in an microscopic infrastructure model a new element was added to the <ocpTT> called <alternativeSectionsTT>. It serves as a container for a number of <alternativeSectionTT> elements that can each be annotated with a priority in order to describe the priority of their use by a managing TMS. It is important to note that the arrival and departure times of the following ocpTT must not be dependent on which way actually is chosen.
|
Reason:
|
Requirement from the community.
|
Related Development Tickets:
|
#381
|
Related Commits:
|
[1039] (Note on legacy SVN commits)
|
New element(s):
|
<alternativeSectionsTT>
|
Updated element(s):
|
<ocpTT>
|
New enumeration value expected for <times>/@scope
Fact:
|
Support for forcasted arrival and departure times.
|
Reason:
|
Requirement from the community.
|
Related Development Tickets:
|
#472
|
Related Commits:
|
[1039] (Note on legacy SVN commits)
|
Updated attribute(s):
|
@scope
|
Infrastructure Subschema
@dir deprecated for many elements
Fact:
|
For many Elements @dir gets deprecated according to the following guidelines:
- Rule 1: @dir is usefull as application direction.
Applies for elements without extent (without @length attribute) examples: balise, border, derailer, signal, stopPost... usage: @dir describes the direction of travel, for which the element applies. Possible values are "up", "down" and "both". A missing @dir attribute means that the application direction of this element is unknown.
- Rule 2: (short) linear elements 🡪 no usage of @dir.
Elements with extent (with @length attribute) examples: bridge, levelCrossing, platformEdge, serviceSection... By standard, the elements' orientation (not their application direction!) shall be always in direction of track orientation (from trackBegin towards trackEnd). E.g.: <levelCrossing>, <platformEdge>. The position value @pos defines the center point of the linear element.
- Rule 3: (long) linear elements 🡪 use @dir if modelling „portals“ (usually Changes), where the elements' orientation can differ from track orientation.
Refers to Elements that describe a change. Examples: axleWeightChange, clearanceGaugeChange, electrificationChange, gaugeChange, speedChange... By standard (except for speedChange), the change elements' orientation (not their application direction!) shall be always in direction of track orientation (from trackBegin towards trackEnd). E.g. <tunnel>: locate tunnel portal with @pos and point @dir towards center.
|
Reason:
|
There are some elements, where the @dir attribute does not make much sense. Either, because the element is valid for both directions of travel or because the element shall be only defined for one direction. So, the task is to identify elements where the @dir attribute shall be marked DEPRECATED.
|
Related Development Tickets:
|
#357
|
Related Commits:
|
[1039] (Note on legacy SVN commits)
|
Updated attribute(s):
|
@dir
|
Updated element(s):
|
<trackCircuitBorder>, <brigde>, <levelCrossing_levelCrossings>, <platformEdge>, <serviceSection>, <tunnel>, <axleWeightChange>, <clearanceGaugeChange>, <electrificationChange>, <gaugeChange>, <ownerChange>, <powerTransmissionChange>, <radiusChange>
|
Fact:
|
New optional attribute <levelCrossing>@offset
|
Reason:
|
Attributes @pos and @absPos shall describe by default the location of the (geometric) middle of the level crossing. Half the @length is before @pos and the other half is after.
In order to define a different setting, the new optional attribute <levelCrossing>@offset can be used. It describes how many metres of the @length is before @pos. If @offset is not given, the default value shall apply.
|
Related Development Tickets:
|
#374
|
Related Commits:
|
[1039] (Note on legacy SVN commits)
|
New attribute(s):
|
@offset
|
Updated element(s):
|
<levelCrossing>
|
Updated definitions for the values of <track>@type
Fact:
|
The definitions of the values of <track>@type have been updated
|
Reason:
|
Definitions of track types in railML 2 wiki differ from consensus in forum and best practices in wiki → to be consolidated.
|
Related Development Tickets:
|
#376
|
Related Commits:
|
[1039] (Note on legacy SVN commits)
|
Updated attribute(s):
|
@type
|
Updated element(s):
|
<track>
|
Value unknown of <track>@mainDir removed
Fact:
|
The value unknown of <track>@mainDir has been removed.
|
Reason:
|
unknown has the same meaning as a missing @mainDir.
|
Recommendation:
|
Despite the value unknown still exists in older schemas, consider it deprecated retroactively.
|
Related Development Tickets:
|
#324
|
Related Commits:
|
[1039] (Note on legacy SVN commits)
|
Updated attribute(s):
|
@mainDir
|
Updated element(s):
|
<track>
|
Fact:
|
Element <genericAreas> and its recursive Children have been introduced
|
Reason:
|
This element is a new high-level grouping element. The element describes several different types of areas, e.g. specification of specially controlled areas within the network.
|
Related Development Tickets:
|
#373
|
Related Commits:
|
#393
|
New element(s):
|
|
Updated element(s):
|
<infrastructure>, <controller> and others
|
Rollingstock Subschema
Fact:
|
Several instances of <segmentTable> have been introduced.
|
Reason:
|
There was demand for an alternative to <valueTable>
|
Related Development Tickets:
|
#385
|
Related Commits:
|
#393
|
New element(s):
|
Several instances of <segmentTable>
|
Updated element(s):
|
The respective parents, comp. <segmentTable>
|