Dev:changes/2.5: Difference between revisions
[checked revision] | [checked revision] |
(Updated definitions for the values of track@type) |
|||
Line 11: | Line 11: | ||
For changes with other version upgrades see [[Dev:changes]]. | For changes with other version upgrades see [[Dev:changes]]. | ||
==Timetable Subschema== | ==Timetable Subschema== | ||
===New {{@|onRequest}} for {{tag|TT|trainPart}}=== | ===New {{@|onRequest|TT:trainPart}} for {{tag|TT|trainPart|attr=onRequest}}=== | ||
{{change|fact=new attribute {{@|onRequest}} (bool) has been added in element {{tag|TT|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. | {{change|fact=new attribute {{@|onRequest}} (bool) has been added in element {{tag|TT|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|thumb]] | [[File:Anpassungen railML 2 -Bedarfszüge.pdf|thumb]] | ||
|trac={{ticket|372}}|nattr={{@|onRequest}}|uelem={{tag|TT|trainPart}}}} | |trac={{ticket|372}}|nattr={{@|onRequest}}|uelem={{tag|TT|trainPart}}}} | ||
===New value {{enum|other:anything}} for {{Tag|TT|category|@=trainUsage}}=== | ===New value {{enum|other:anything}} for {{Tag|TT|category|@=trainUsage}}=== | ||
{{change | {{change |
Revision as of 15:16, 21 September 2020
| ||||||||
|
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.
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. |
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> |
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:
|
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> |