Dev:changes/2.5: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[checked revision][checked revision]
(track@mainDir: -unknown)
Line 60: Line 60:
===New Child {{tag|TT|announcementRef}} for {{tag|TT|stopDescription}}===
===New Child {{tag|TT|announcementRef}} for {{tag|TT|stopDescription}}===
{{change
{{change
|fact=New Child {{tag|TT|announcementRef}} for {{tag|TT|stopDescription}}
|fact=New Child {{tag|TT|announcementRef}} for {{tag|TT|stopDescription}} and {{tag|TT|trainPart}}
|reason=broad revision of annotations
|reason=broad revision of annotations
|recomendation=
|recomendation=
Line 72: Line 72:
|uelem={{tag|TT|stopDescription}}
|uelem={{tag|TT|stopDescription}}
}}
}}
===New {{@|type}} for {{tag|TT|annotation}}===
===New {{@|type}} for {{tag|TT|annotation}}===
{{change
{{change

Revision as of 14:40, 29 September 2020

RailML Trademark RGB V2.png
XML Railway exchange format
https://railML.org
Latest release: 2.5
(September 1st, 2021)
 
Main Menu
 
Subschemas
XML tree
UML diagrams
Use cases
Versions & Changes

railML® schema changes between railML® 2.4 and railML® 2.5
 

Sunrise.png This instance of Template:Future seems to be obsolete. Please check, if this article contains information that is only valid for future railML® versions. If this is not the case, feel free to remove this template. Don't forget to check Category:Future if there are more obsolete instances.

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.

Timetable Subschema

New @onRequest for <trainPart>

Fact: new attribute @onRequest (bool) has been added in element <trainPart> in order to allow for standardized modelling of onRequest journeys.
Reason: Required by railML partner. Also this should help avoiding modelling of onRequest journeys using special train categories.

File:Anpassungen railML 2 -Bedarfszüge.pdf

Related Development Tickets: #372
New attribute(s): @onRequest
Updated element(s): <trainPart>

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 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 child <originalTrackInfo> for <ocpTT>

Fact: New child <originalTrackInfo> for <ocpTT>
Reason: Allow for better communication of track changes
Related Development Tickets: #375
Related Commits: [1039] (Note on legacy SVN commits)
Updated XSD file(s): timetable.xsd
New element(s): <originalTrackInfo>
Updated element(s): <ocpTT>

New childs <origin> and <destination> for <trainPart>

Fact: New childs <origin> and <destination> for <trainPart>
Reason: allows for specifying information about the origin/destination of the train if it cannot be derived from its path (trains entering/leaving the operated area).
Related Development Tickets: #375
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <origin>, <destination> & their respective childs
Updated element(s): <trainPart>

New Child <announcementRef> for <stopDescription>

Fact: New Child <announcementRef> for <stopDescription> and <trainPart>
Reason: broad revision of annotations
Related Development Tickets: #375
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <announcementRef> & childs
Updated element(s): <stopDescription>

New @type for <annotation>

Fact: New @type for <annotation>
Reason: broad revision of annotations
Related Development Tickets: #375
Related Commits: [1039] (Note on legacy SVN commits)
New attribute(s): <annotation>@type
Updated element(s): <annotation>

New child <announcements> of <timetable>

Fact: New child <announcements> of <timetable>
Reason: broad revision of annotations
Related Development Tickets: #375
Related Commits: [1039] (Note on legacy SVN commits)
New element(s): <announcements>
Updated element(s): <timetable>

Interlocking Subschema

Infrastructure Subschema

New @trainProtectionSystem for <trainProtectionChange> and <trainProtection>

Fact: new attribute @trainProtectionSystem (string) has been added in elements <trainProtectionChange> and <trainProtection>.

@trainProtectionSystem shall reference values from codelist TrainProtectionSystems.xml.

Reason: <trainProtectionChange> and <trainProtection> were missing a parameter to reference the train protection system – compare the forum discussion (link to the railML® website).
Related Development Tickets: #356
Related Commits: [1039] (Note on legacy SVN commits)
New attribute(s): @trainProtectionSystem
Updated element(s):

@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>

New Attribute <levelCrossing>@offset

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>

Rollingstock Subschema