|
|
Line 402: |
Line 402: |
| {| | | {| |
| |Fact: | | |Fact: |
| |The attributes {{attr|@switchable}}, {{attr|@signalBoxOcpRef}} and {{attr|@stationOcpRef}} have been depricated. The attributes {{attr|@controllerRef}} and {{attr|@ocpStationRef}} have been introduced. The elements {{IS:Tag|speed}} (plus its child {{IS:Tag|speedChangeRef}}, {{IS:Tag|etcs}}, {{IS:Tag|levelCrossing}}, {{IS:Tag|trainRadio}}, {{IS:Tag|catenary}}, {{IS:Tag|line}}, {{IS:Tag|milePost}} and {{IS:Tag|braking}} have been introduced. | | |The attributes {{attr|@switchable}}, {{attr|@signalBoxOcpRef}} and {{attr|@stationOcpRef}} have been depricated. The attributes {{attr|@controllerRef}} and {{attr|@ocpStationRef}} have been introduced. The elements {{IS:Tag|speed}} (plus its child {{IS:Tag|speedChangeRef}}, {{IS:Tag|etcs}}, {{IS:Tag|levelCrossing}}, {{IS:Tag|trainRadio}}, {{IS:Tag|catenary}}, {{IS:Tag|line}}, {{IS:Tag|milepost}} and {{IS:Tag|braking}} have been introduced. |
| |- | | |- |
| |Reason: | | |Reason: |
Line 416: |
Line 416: |
| |{{missing information|topic=Please, add an example.|user=[[User:Ferri Leberl|Ferri Leberl]] ([[User talk:Ferri Leberl|talk]]) 20:43, 5 June 2017 (CEST)}} | | |{{missing information|topic=Please, add an example.|user=[[User:Ferri Leberl|Ferri Leberl]] ([[User talk:Ferri Leberl|talk]]) 20:43, 5 June 2017 (CEST)}} |
| |} | | |} |
| | | ==={{IS:Doc|states}}, {{IS:Doc|state}}, {{IS:Doc|from}}, {{IS:Doc|to}}=== |
| | {| |
| | |Fact: |
| | |The elements {{IS:Tag|states}}, {{IS:Tag|state}}, {{IS:Tag|from}}, {{IS:Tag|to}} have been introduced at several places throughout the {{IS:Tag|infrastructure}} subschema. |
| | |- |
| | |Reason: |
| | |{{IS:Tag|state}} allows to declare, whether a piece of infrastructure is disabled or not (within the referenced operating period). Via its children {{IS:Tag|from}} and {{IS:Tag|to}} the statement can be constrained to a certain traject of the infrastructure piece. {{IS:Tag|states}} serve as a container so you can express different states e.g. within different operating periods or for different reasons. |
| | |- |
| | | Related Trac Tickets: |
| | | {{ticket|156}} |
| | |- |
| | | Related SVN Commits: |
| | | {{missing information|topic=Please, add the regarding SVN commit.|user=[[User:Ferri Leberl|Ferri Leberl]] ([[User talk:Ferri Leberl|talk]]) 20:54, 5 June 2017 (CEST)}} |
| | |- |
| | |Example: |
| | |{{missing information|topic=Please, add an example.|user=[[User:Ferri Leberl|Ferri Leberl]] ([[User talk:Ferri Leberl|talk]]) 20:54, 5 June 2017 (CEST)}} |
| | |} |
| {{Missing information|topic=all the additonal IS's changes in railML's version 2.2|user=[[Benutzer:Vasco Paul Kolmorgen|Vasco Paul Kolmorgen]] ([[Benutzer Diskussion:Vasco Paul Kolmorgen|Diskussion]]) 18:29, 11. Feb. 2016 (CET)}} | | {{Missing information|topic=all the additonal IS's changes in railML's version 2.2|user=[[Benutzer:Vasco Paul Kolmorgen|Vasco Paul Kolmorgen]] ([[Benutzer Diskussion:Vasco Paul Kolmorgen|Diskussion]]) 18:29, 11. Feb. 2016 (CET)}} |
|
| |
|
railML schema changes between railML® 2.1 and railML® 2.2
This site is intended to collect the schema changes between railML® 2.1 and railML® 2.2 by topics, that influence the XML output. As it starts as a stub please refer to railML forum and railML's ticket system too.
For changes with other version upgrades see CO:changes.
Timetable subschema
|
In this article there is information missing with respect to the all the TT's changes in railML's version 2.2. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Vasco Paul Kolmorgen (Diskussion) 18:29, 11. Feb. 2016 (CET)
|
|
Infrastructure subschema
Direction types
Fact:
|
The possible values for attribute dir have been reviewed and restructured.
|
Reason:
|
Depending on the type of element, where the attribute dir occurs, different values should be available. Most elements require a "strict direction" with possible values "up" and "down", e.g. elements <speedChange>, <gradientChange> or <radiusChange>. Other elements may additionally require a direction value "unknown", e.g. the element <levelCrossing>. Further, there are also elements that require a "lax direction" with possible values "up", "down", "unknown", "none" and "both", e.g. element <crossSection>. Last, but not least, there is the direction of the mileage, which should not be modelled using the values "up" and "down" due to misinterpretations, but which should be defined as an own mileage direction type with values "raising" and "falling".
|
Recommendation:
|
Use the attribute dir of each element according to its direction definition.
|
Related Trac Tickets:
|
#62
|
Related SVN Commits:
|
[377], [441] and [478]
|
Fact:
|
The elements <platformEdge> and <serviceSection> have been added as new child elements of <trackElements>.
|
Reason:
|
The elements <platformEdge> and <serviceSection> were missing and needed for more detailed (microscopic) operational modelling. Both elements derive from the same base data type and are modelled like other child elements of <trackElements>.
|
Recommendation:
|
Use the new <platformEdge> element to model a platform edge along a track, e.g. in a station. Use the new <serviceSection> element to model a service area along a track where fueling, watering etc. is done.
|
Related Trac Tickets:
|
#122
|
Related SVN Commits:
|
[440], [448], [474], [475], [498], [499], [500] and [566]
|
platformEdge sample:
|
<platformEdge id="pe263012" dir="up" pos="12197" absPos="103215" length="199" ocpRef="ocpKSPA" side="right">
<geoCoord coord="50.257208 7.646223" epsgCode="urn:ogc:def:crs:EPSG::4326"/>
</platformEdge>
|
serviceSection sample:
|
<serviceSection id="ss263019" dir="up" pos="50852" absPos="141869" length="122" ocpRef="ocpFNDH" side="left"
cleaning="true" fueling="true" loadingFacility="true">
<geoCoord coord="50.036540 7.804770" epsgCode="urn:ogc:def:crs:EPSG::4326"/>
</serviceSection>
|
Fact:
|
The <geoCoord> element has been (re-) introduced as child element of <mileageChange> element. Further, the optional parameter absDir with its possible values "raising" and "falling" has been added to element <mileageChange>. At the same time, the parameter dir with its values "up" and "down" has been marked DEPRECATED.
|
Reason:
|
The <geoCoord> element disappeared from element <mileageChange> with version 2.0. Now, it has been re-introduced as it was requested. Further, the new attribute absDir shall be used to define the direction of the mileage ("raising" or "falling") starting from here into the orientation direction of the track. At the same time, the existing optional attribute dir has been marked DEPRECATED as it is not needed for the <mileageChange>, but instead leads to misinterpretations regarding the direction of the mileage.
|
Recommendation:
|
Use the new <geoCoord> element in <mileageChange> in order to define the geographic position of a mileage change point on your track. Use the new attribute absDir in element <mileageChange> in order to define the new direction of the mileage starting from this point.
|
Related Trac Tickets:
|
#134
|
Related SVN Commits:
|
[430]
|
mileageChange sample:
|
<trackTopology>
<trackBegin id="tr01_tb" pos="0">
<geoCoord coord="50.350834 7.589025" epsgCode="urn:ogc:def:crs:EPSG::4326"/>
</trackBegin>
<trackEnd id="tr01_te" pos="61229">
<geoCoord coord="49.968768 7.889734" epsgCode="urn:ogc:def:crs:EPSG::4326"/>
</trackEnd>
<mileageChanges>
<mileageChange id="tr01_mc01" pos="31186" absPosIn="122384" absPos="122385" type="missing" absDir="raising">
<geoCoord coord="50.168017 7.687182" epsgCode="urn:ogc:def:crs:EPSG::4326"/>
</mileageChange>
</mileageChanges>
</trackTopology>
|
Fact:
|
The <geoCoord> element has been added as child element of <trackBegin> and <trackEnd> element.
|
Reason:
|
So far it was not possible to define the begin or the end of a track by their geographic coordinates.
|
Recommendation:
|
Use the new <geoCoord> element in <trackBegin> and <trackEnd>.
|
Related Trac Tickets:
|
#135
|
Related SVN Commits:
|
[433]
|
geoCoord sample:
|
<trackTopology>
<trackBegin id="tr01_tb" pos="0">
<geoCoord coord="50.350834 7.589025" epsgCode="urn:ogc:def:crs:EPSG::4326" />
</trackBegin>
<trackEnd id="tr01_te" pos="61229">
<geoCoord coord="49.968768 7.889734" epsgCode="urn:ogc:def:crs:EPSG::4326" />
</trackEnd>
</trackTopology>
|
Fact:
|
The optional attribute absDir has been added to the element <trackBegin>. Its possible values are "raising" and "falling".
|
Reason:
|
So far, it was not possible to determine the direction of the mileage ("raising" or "falling") at the beginning of a track without setting a separate <mileageChange> element.
|
Recommendation:
|
Use the new attribute absDir in element <trackBegin> in order to define whether the mileage (absPos) starts "raising" or "falling" into the orientation direction of the track.
|
Related Trac Tickets:
|
#159
|
Related SVN Commits:
|
[444]
|
absDir sample:
|
<trackTopology>
<trackBegin id="tr01_tb" pos="0" absPos="91199" absDir="raising">
<geoCoord coord="50.350834 7.589025" epsgCode="urn:ogc:def:crs:EPSG::4326" />
</trackBegin>
<trackEnd id="tr01_te" pos="61229" absPos="152428">
<geoCoord coord="49.968768 7.889734" epsgCode="urn:ogc:def:crs:EPSG::4326" />
</trackEnd>
</trackTopology>
|
Fact:
|
The optional attribute absPosIn has been added to the element <trackEnd>. Its possible values are of type tLengthM (meters).
|
Reason:
|
If the mileage (absPos) changes in the end of the track, it was not possible to model this change without an additional <mileageChange> element. This problem has been solved with the new attribute, which allows it to define two mileages (an "incoming" one and an "outgoing" one) for the <trackEnd>.
|
Recommendation:
|
Use the new attribute absPosIn in combination with the attribute absPos in element <trackEnd> if you want to model a mileage change in the end of the track.
|
Related Trac Tickets:
|
#159
|
Related SVN Commits:
|
[453]
|
absPosIn sample:
|
<trackTopology>
<trackBegin id="tr01_tb" pos="0" absPos="91199" absDir="raising">
<geoCoord coord="50.350834 7.589025" epsgCode="urn:ogc:def:crs:EPSG::4326" />
</trackBegin>
<trackEnd id="tr01_te" pos="61229" absPosIn="152428" absPos="152455">
<geoCoord coord="49.968768 7.889734" epsgCode="urn:ogc:def:crs:EPSG::4326" />
</trackEnd>
</trackTopology>
|
Fact:
|
@abbrevation and @number in the <ocp> element have been declared deprecated. @parentOcpRef and <designator> have been introduced. additionalName has been expanded by @type.
|
Reason:
|
There are multiple different abbreviations and numbers for single operation or control points. They can't be defined with one attribute. Use, depending on context, <designator> or additionalName instead. @parentOcpRef allows for grouping ocps. <designator> allows for more codes than the depricated @code, plus it can establish a relation with the codelist Registers.xml. additionalName/@type allowes to declare the context of a name: is it valid under operational or traffic aspects, or as a local name?
|
Recommendation:
|
Use the new <tsi> and/or <designator> elements instead.
|
Related Trac Tickets:
|
#112, #153
|
Related SVN Commits:
|
[335], [439]
|
Old sample (railML 2.1):
|
<ocp ... name="Passau Hbf." abbrevation="NPA"/>
|
New sample (railML 2.2):
|
<ocp ... name='Passau Hbf.' ...>
<tsi country="80"/>
<designator register='RL100' entry='NPA'/>
<designator register='ENEE' entry='80-26506-6'/>
<designator register='PLC' entry='DE18274'/>
<designator register='IBNR' entry='8000298'/>
<designator register='DB640' entry='Pa'/>
</ocp>
|
Fact:
|
The element <speedProfiles> plus its children have been introduced.
|
Reason:
|
<speedProfiles> serves as a container for an indefinite number of <speedProfile>-elements. A <speedProfile> defines a speed profile dependent on a number of factors like max loads, protection system and braking, of which some are attributes, others are children. A <speedProfile> may be labeled either increasing or decreasing with @influence. Notice, that <speedProfile> does not contain a speed, but intead declares, whether a certain <speedCange> is valid for a train.
|
Related Trac Tickets:
|
#41
|
Related SVN Commits:
|
|
In this article there is information missing with respect to Please, add the regarding SVN commit.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 17:37, 5 June 2017 (CEST)
|
|
|
Sample:
|
For a <track> the following profiles may be defined:
<speedProfile id="sp1" name="Basis" influence="increasing"/>
<speedProfile id="sp2" name="Tilting" influence="increasing"/>
<speedProfile id="sp3" name="Temporary" influence="reducing"/>
<speedProfile id="sp4" name="HeavyLoad" influence="reducing"/>
They might be referenced from the following <speedChange> elements:
<speedChange id="sc1" pos="12.34" profileRef="sp1" maxSpeed="120"/>
<speedChange id="sc2" pos="12.34" profileRef="sp4" maxSpeed="80"/>
<speedChange id="sc3" pos="13.45" profileRef="sp3" maxSpeed="40"/>
<speedChange id="sc4" pos="14.56" profileRef="sp2" maxSpeed="140"/>
Further examples can be found here.
|
Fact:
|
For <speedChange>, @trainCategory has been depricated, whereas the following attributes have been introduced: @ectsTrainCategory, @profileRef, @trainRelation, @mandatoryStop, @signalised
|
Reason:
|
@trainCategory has been replaced with @ectsTrainCategory as to standardize this information: use ETCS-code numbers instead of unnormed strings. @profileRef allowes to link a <speedChange> with a <speedProfile>. @trainRelation makes explicit, whether the <speedChange> is valid from the front, the middle or the rear of the train. @mandatoryStop marks whether the train has to halt, e.g. at a level crossing. @signalised declares, whether the speedChange is signalised, e.g. with a panel.
|
Related Trac Tickets:
|
#41, #100, #190, #193
|
Related SVN Commits:
|
|
In this article there is information missing with respect to Please, add the regarding SVN commit.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 18:25, 5 June 2017 (CEST)) 17:37, 5 June 2017 (CEST)
|
|
|
Sample:
|
See #speedProfiles.
|
Fact:
|
The elements <stopPosts>, <stopPost>, <stopPosts>, <signalRef> and <validForMovement> have been introduced.
|
Reason:
|
<stopPosts> is a container for <stopPosts> elements. The element <stopPosts> has been introduced to mark a position on a track, where a train, which fulfills certain criteria, needs to stop in order to change passengers or because of other operational rules. <validForMovement> specifies the train types for which the stop post is relevant. <signalRef>. As a <stopPost> may be valid for several signals, <signalRef> has been introduced to list relevant signals for a <stopPost>.
|
Related Trac Tickets:
|
#167, #198
|
Related SVN Commits:
|
|
In this article there is information missing with respect to Please, add the regarding SVN commit.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 18:41, 5 June 2017 (CEST)
|
|
|
Example:
|
|
In this article there is information missing with respect to Please, add an example.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 18:41, 5 June 2017 (CEST)
|
|
|
line/@infrastructureManagerRef
Fact:
|
The element line has been expanded by an attribute @infrastructureManagerRef.
|
Reason:
|
@infrastructureManagerRef allows to address a certain Template:CO:infrastructureManagerfrom the infrastructure manager codelist.
|
Related Trac Tickets:
|
#152
|
Related SVN Commits:
|
|
In this article there is information missing with respect to Please, add the regarding SVN commit.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 19:01, 5 June 2017 (CEST)
|
|
|
Example:
|
...
<trackGroups>
<line id="a48a6491-301a-4dcf-8293-56f79979e7be"
code="11801"
name="Ostbahn"
description="ehemals Wien-Raaber Bahn vom gschleiften Wiener Südbahnhof nach Hegyeshalom"
xml:lang="de-AT"
type="mainLine"
infrastructureManagerRef="33e19910-794d-4afc-88f3-b5f27a3f6a6a"
lineCategory="D4">
<additionalName name="Austrian East Railway"
description="former Vienna-Raab railway from abandoned Vienna South Station to Hegyeshalom"
xml:lang="en"/>
<trackRef ref="tr01"/>
</line>
</trackGroups>
...
|
Fact:
|
The element baliseGroup gets the attributes @id, @name, @code,
@description, @xml:lang and @type.
|
Reason:
|
The first five of the six new attributes make baliseGroups become identifiable objects so they can be addressed from a signal. @type refers to the technical principle (infill, signal, technicalFixed, technicalSwitchable).
|
Related Trac Tickets:
|
#174
|
Related SVN Commits:
|
|
In this article there is information missing with respect to Please, add the regarding SVN commit.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 19:45, 5 June 2017 (CEST)
|
|
|
Example:
|
|
In this article there is information missing with respect to Please, add an example.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 19:45, 5 June 2017 (CEST)
|
|
|
Fact:
|
The elements <trainProtectionElement> has been expanded by @trainProtectionSystem as to replace @system.
|
Reason:
|
<trainProtectionElement> addresses an elemen of the codelist TrainProtectionSystems.xml. This is more precise and facilitates the maintenance.
|
Related Trac Tickets:
|
#175
|
Related SVN Commits:
|
|
In this article there is information missing with respect to Please, add the regarding SVN commit.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 20:08, 5 June 2017 (CEST)
|
|
|
Example:
|
|
In this article there is information missing with respect to Please, add an example.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 20:08, 5 June 2017 (CEST)
|
|
|
Fact:
|
The elements <derailer>, <derailer> geoCoord have been introduced.
|
Reason:
|
<derailer> allows to represent, identify and specify derailers. Via ists child geoCoord it can be located. derailers serves as a container.
|
Related Trac Tickets:
|
#232
|
Related SVN Commits:
|
|
In this article there is information missing with respect to Please, add the regarding SVN commit.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 20:19, 5 June 2017 (CEST)
|
|
|
Example:
|
|
In this article there is information missing with respect to Please, add an example.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 20:19, 5 June 2017 (CEST)
|
|
|
Fact:
|
The attributes @switchable, @signalBoxOcpRef and @stationOcpRef have been depricated. The attributes @controllerRef and @ocpStationRef have been introduced. The elements <speed> (plus its child <speedChangeRef>, <etcs>, <levelCrossing>, <trainRadio>, <catenary>, <line>, <milepost> and <braking> have been introduced.
|
Reason:
|
The new children help standardizing the representation of signals within railML®, as the offer a frame for distinct signal types. As a consequence signal remains a sort of container. straightforwardly switchable has been passed down to the actual specification. @stationOcpRef has been replaced by @ocpStationRef, as the latter is defined more demanding (its valid only for ocps that are stations) — so if you get accross some old @stationOcpRef, you immediately know, that it does not necessarily address a station. @signalBoxOcpRef has been replaced by @controllerRef.
|
Related Trac Tickets:
|
#173
|
Related SVN Commits:
|
|
In this article there is information missing with respect to Please, add the regarding SVN commit.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 20:43, 5 June 2017 (CEST)
|
|
|
Example:
|
|
In this article there is information missing with respect to Please, add an example.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 20:43, 5 June 2017 (CEST)
|
|
|
Fact:
|
The elements <states>, <state>, <from>, <to> have been introduced at several places throughout the <infrastructure> subschema.
|
Reason:
|
<state> allows to declare, whether a piece of infrastructure is disabled or not (within the referenced operating period). Via its children <from> and <to> the statement can be constrained to a certain traject of the infrastructure piece. <states> serve as a container so you can express different states e.g. within different operating periods or for different reasons.
|
Related Trac Tickets:
|
#156
|
Related SVN Commits:
|
|
In this article there is information missing with respect to Please, add the regarding SVN commit.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 20:54, 5 June 2017 (CEST)
|
|
|
Example:
|
|
In this article there is information missing with respect to Please, add an example.. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Ferri Leberl (talk) 20:54, 5 June 2017 (CEST)
|
|
|
|
In this article there is information missing with respect to all the additonal IS's changes in railML's version 2.2. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Vasco Paul Kolmorgen (Diskussion) 18:29, 11. Feb. 2016 (CET)
|
|
Rollingstock subschema
|
In this article there is information missing with respect to the RS's changes in railML's version 2.2. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Vasco Paul Kolmorgen (Diskussion) 18:29, 11. Feb. 2016 (CET)
|
|
Common subschema
|
In this article there is information missing with respect to the CO's changes in railML's version 2.2. Please help improving the railML® wiki by filling the gaps. Possibly, you will find further details on the discussion page. Vasco Paul Kolmorgen (Diskussion) 18:29, 11. Feb. 2016 (CET)
|
|