Search results

Reference to the part of the train from where the speed change is valid. Normally, a speed change with a speed that is higher than the permitted speed in

in railML® definiert. For change of the mileage direction by <mileageChange> see Remarks and open issues on mileage changes.

belegten Bahnhofsgleises powerSystemChange: Systemwechsel Stop caused by a change of power supply (e.g. to change pantograph) für Halte wegen Wechsels

of frame contracts yearly for LTP planning the regular timetable regular changes for STP planning, e.g. for engineering infrastructure works, special event

the train(part) changes the direction - no matter whether the formation changes, reverses or neither of both. trainReverse with change of formation = e

whereas local definitions are generally set in change-elements like <electrificationChange> and <speedChange> Not yet described. / Noch nicht beschrieben

bureaucracy, the beginning and ending of trains is regarded as “train order change”. <ocp id=… name=…> <propOperational operationalType='station' orderChangeable='true'

After publication, take care, that changes are incorporated into the wiki asap. New or changed attribute: Add or change the attribute in "attributes" providing

code example defines gauge change of the track that connects Arnsdorf West and Nord junctions. <gaugeChanges> <gaugeChange id='gac_80.6228_0' pos='0' absPos='942'

dayIndex). Whether a change of operating days during a train run actually happens can only be obtained by comparing the shifted bit masks. A change of <operatingPeriodRef>

<gaugeChange>, <geoMapping>, <gradientChange>, <levelCrossing>, <lock>, <mileageChange>, <ocp>, <operationModeChange>, <ownerChange>, <platformEdge>, <p

IS:states   Parent: (miscellaneous) – see Category:states Children: <state> [0..1] Container to define disabled/enabled pieces of infrastructure. None

exist? How often is data exchanged? What is the granularity? How does it change over time, if it does at all? Diagrams/images would be helpful to visualize

station name to a typical usage or give it a “right to exist”. But it does not change the behaviour of a railML® parser when decoding the file. So, if the file

physically signalised speed restriction or speed change, always both elements need to be modelled: the <speedChange> and the <speed> element of <signal>. In the

exist? How often is data exchanged? What is the granularity? How does it change over time, if it does at all? Diagrams/images would be helpful to visualize

train part in subsequent sections applies for instance if the operating days change at an intermediate station. For more information, please read Train coupling

Thus, it is mandatory to place a <gradientChange> at the beginning of a model or at a mileage direction change once for each direction. The gradient itself

additional information. While e. g. operating days or no. of vehicles may change during a train’s run, all such properties of a <trainPart> stay constant

IS:speedChangeRef   Parent: <speed_signal> Children: None [0..∞] Reference to a speed change. ref: reference is required because it's the purpose of the

(yards) X.Y, X.Z, X.J. Yard X.Y has a temporal part as soon as its properties change over time. <infrastructure> <operationControlPoints> <ocp id="X" name="X"

<xs:enumeration value="powerSystemChange"> + <xs:annotation> + <xs:documentation>Stop caused by a change of power supply (e.g. to change pantograph)</xs:documentation>

<IS:axleWeightChange> <clearanceGaugeChange> <electrificationChange> <gaugeChange> <ownerChange> <gradientChange> <powerTransmissionChange> <radiusChange> IS:016

overlap/safety zone/slip, timers, speeds), which is demanded by JBV. static (not changing) yearly big (station / yard) huge (region) whole data set (network) topology:

associated <category> element lastModified: allows to specify when the last change to this trainPart was done id: xs:ID, required a string, starting with a

serves to specify the required data regarding certain aspects. static (not changing) on demand big (station/yard) Energy Construction Number of elements (signals

tables are finished, these are delivered to the supplier, and it is in this change of information we detect that lack in communication might occur. To standardize

pos, absPos) <mileageChanges> (id, pos, absPos, absPosIn) Track elements <gradientChanges> (id, pos, absPos, Slope) <speedChanges> (id, pos, absPos, dir

IS:state   Parent: <states> Children: <designator> (introduced with version 2.5), <xs:any> [1..1] This is to define disabled/enabled infrastructure pieces

This section should be used for a header or introduction. The headline is made with Template: UC title (type {{UC title}}) This article shows and explains

interlocking systems. There are also changes possible or necessary due to operational findings, which force the change of specific parameters for track-sections

Geometry. The track geometry can be described in terms of <radiusChanges> and <gradientChanges>. Railway infrastructure elements enclose a variety of railway

graphical attributes of edges or nodes, i.e. no colours or line-styles. Changes occur on a irregular and unpredictable basis, usually associated with track

Timetabling; Fahrplan Each RU has to provide a timetable for their train- and shunting movements in a coming time period. Besides the RU itself the involved

Exchange of planning parameters for interlocking with suppliers; Austausch von Planungsparametern für Stellwerke mit Anbietern All the planning parameters

splitting from Through connections (connecting to) Through connections (change of service number) Details of transport services Stops with traffic restrictions

the operating status and the decommissioned assets). Regular / occasional changes: updating the model (dashed arrows in the schema) Realtime (seconds): providing

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". absDir (introduced with version 2.2): Defines

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". absPosIn: the mileage of the (incoming) line in

cancellations, extra trains Relevant changes to existing trains need to be represented in the export file. A complete list of changes needs to be defined. This will

railML® 2.1 Changes between railML® 2.1 and railML® 2.2 Changes between railML® 2.2 and railML® 2.3 Changes between railML® 2.3 and railML® 2.4 Changes between

ausgibt. It should also be pointed out that with version 2.5 of railML® a change was introduced to the enumeration available for @trainUsage. With this version

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

railML® schema changes between railML® 2.3 and railML® 2.4   This site is intended to collect the schema changes between railML® 2.3 and railML® 2.4. A

Children: <axleWeightChanges>, <bridges>, <clearanceGaugeChanges>, <electrificationChanges>, <gaugeChanges>, <geoMappings>, <gradientChanges>, <levelCrossings>

(optional) daily sometimes possibly several times on a day (short-term changes) The size of the data varies depending to the usage of the data. On the

where a train, which fulfills certain criteria, needs to stop in order to change passengers or because of other operational rules. id: XML-file-wide unique

Postcondition The train is changed within the validity of the change request, and unchanged outside. Change validity of a train Precondition: Import data

Interlocking module engineering data ; Stellwerksprojektierung The process of creating an interlocking is three-tiered. The manufacturer designs an interlocking

There should be one more error message. Change the count of error messages in the comment. Commit all changes (key, keyref, defectSample) together, if

Maintenance Planning; Wartungsplanung The application focuses the transfer of infrastructure data from an asset management source system (e.g. DfA in Switzerland)

CAD for railway signalling; CAD für Zugsignalisierung Engineers of the railway signaling discipline use a Computer-Aided Design (CAD) tool to model a railway

specify the required data regarding certain aspects. only on configuration changes big (station/yard) huge (region) Signaling Permission/operating zones: ID

serves to specify the required data regarding certain aspects. static (not changing) yearly big (station/yard) huge (region) whole data set (network) Geometry

to specify the required data regarding certain aspects. on demand or on changes of RS depending on the number of various vehicle types and train formations

required data regarding certain aspects. Bulk transfer: regular changes 5-6 times a year Daily changes for incremental transfers Granularity of data: macro-level

of existing equipment evaluation for weak points feasibility of network changes (time table, rolling stock, electrical equipment) investment strategy for

ÖBB-SCHIG-Reporting (NRE Reporting Austria); NRE Meldung Österreich ÖBB Infrastructure reports several properties of the line and track network periodically

<electrificationChange> of the track adjacent to Bft Bingen (Rhein) Vorbahnhof station. <electrificationChanges> <electrificationChange id="ec263011" dir="up"

characteristics, etc.), i.e. a change of the formation data does not affect the running times nor the path of the trains. Furthermore, a change of the formation data

specifying when the <trainPart> last was changed in the exporting system. May be used by importing systems to detect changed <trainPart>s. id: xs:ID, required

infrastructure restrictions allow computation of itineraries, including changes of direction Vehicle information should include validity reference length

(weekly/daily) Schedule attributes: daily, with realtime changes Vehicle attributes: occasional changes (event-driven) huge (region) Train regulation Energy

pos, absPos) <mileageChanges> (id, pos, absPos, absPosIn) Track elements <gradientChanges> (id, pos, absPos, Slope) <speedChanges> (id, pos, absPos, dir

Speed directory; VzG – Verzeichnis zulässiger Geschwindigkeiten The VzG Process is the central interface between infrastructure business processes (building

railML® for RINF Reporting; railML® für RINF Meldung This use case aims at providing a railML3 file, fulfilling the functional requirements published by

<speedChanges> <speedChange id="sc26301" dir="up" pos="15613" vMax="110" absPos="106663" signalised="true" trainRelation="headOfTrain"/> <speedChange id="sc26302"

Positioning and Map-Matching; Positionierung und Kartenabgleich With a train-borne positioning system, which is a multi-sensor on-board positioning device

Long Term Strategic Timetabling; Langfristfahrplanerstellung The timetable data prepared in this use case is not formally linked to the production process

specify the required data regarding certain aspects. infrastructure: regular changes (Existing infrastructure is updated on a daily basis. But due to todays

<clearanceGaugeChanges> <clearanceGaugeChange id="cs263011" pos="182"> <clearanceGauge code="GA"/> </clearanceGaugeChange> </clearanceGaugeChanges> </trackElements>

serves to specify the required data regarding certain aspects. static (not changing) in cases of error-corrections: weekly .. daily in rare cases during a

along the track) superelevation of outer rail relative height and height changes especially at switches list of reference points with their geo-coordinates

for all project members, independent of ETCS Level) Interlocking Regular changes The frequency for updates should be low. The updates depends on reconstructions

ownerChange   Parent: <ownerChanges> Children: <additionalName> (introduced with version 2.1), <any>, <geoCoord>, <states> [0..∞] A <ownerChange> defines

powerTransmissionChange   Parent: <powerTransmissionChanges> Children: <additionalName> (introduced with version 2.1), <any>, <geoCoord>, <states> [0.

The changed type of extension attribute SAP-Number in the element timetable has no influence into the XML Instance document. (line 3) The changed type

Simulation; Simulation Infrastructure Managers simulate traffic on increasingly realistic models of their networks to design and test timetables. Alternative

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

rail:lang, xsi:type <macroscopicNode> flowDirection, ocpRef <mileageChanges> <mileageChange> absDir, absPos, absPosIn, absPosInOffset, code, description, dir

IS:radiusChange   Parent: <radiusChanges> Children: <additionalName> (introduced with version 2.1), <any>, <geoCoord>, <states> [0..∞] A radiusChange defines

coordinate the work on this page. Recognize that the content of this page may change quickly. Vivian Augele (Diskussion) 08:14, 30. Jun. 2016 (CEST)

axleWeightChange   Parent: <axleWeightChanges> Children: <additionalName> (introduced with version 2.1), <any>, <geoCoord>, <states> [0..∞] A <axleWeightChange>

master branch directly if the changes your are commiting are complete in themselves and don't change the syntax of railML®. Changes to the syntax of railML®

reference to a <trainPart> within a roster, as well as services without change of location (without reference to a <trainPart>). These 3 basic types are

dc:format and/or dc:identifier. As above mentioned the XML namespace does also change with the railML® version. The following table shows this relationship for

<trainProtectionChange> can be set at the position of a track in which the train protection method changes. The direction to which the change is valid, protection

Asset Status Representation for TMS Traffic Management Systems (TMS) consider various sorts of input data for the calculation of the current traffic situation

Especially, employ template:external for external links. If you want to change or extend some content on a specific railML element page, do the following:

Timetable (Common) (Codelists) XML tree UML diagrams Use cases Versions & Changes

@trackContinueCourse is bound to the continuation of the track, and you cannot change which leg it refers to without also swapping the connections. So you should

the Czech Republic and DB InfraGO ( 🇩🇪) in Germany, meaning there is a change in infrastructure managers. Mileage of the border was obtained from Variabler

supplements etc. become incorrect by this practice. Also, it can only be used to change between a certain stop and run through but not to switch between two different

Timetable (Common) (Codelists) XML tree UML diagrams Use cases Versions & Changes

operationModeChange   Parent: <operationModeChanges> Children: <additionalName> (introduced with version 2.1), <any>, <geoCoord>, <states> [0..∞] A <operationModeChange>

referenced from the following <speedChange> elements: <speedChange id="sc1" pos="12.34" profileRef="sp1" vMax="90"/> <speedChange id="sc2" pos="12.34" profileRef="sp4"

clearanceGauge   Parent: <clearanceGaugeChange> Children: None [1..1] The element <clearanceGauge> (introduced with version 2.3) contains all data with

gradientChanges   Parent: <trackElements> Children: <gradientChange> [0..1] A gradientChanges is a container for all elements of gradientChange. They are

radiusChanges   Parent: <trackElements> Children: <radiusChange> [0..1] radiusChanges is a container for all elements of radiusChange. An unlimited number

clearanceGaugeChanges   Parent: <trackElements> Children: <clearanceGaugeChange> [0..1] A clearanceGaugeChanges is a container for all elements of clearanceGaugeChange

version 2.5) Possible values are: planned actual calculated toBeChecked changed imported other:anything: Any value that does not fit any value from the

IS:trainRadioChange   Parent: <trainRadioChanges> Children: <additionalName>, <any>, <geoCoord>, <states> [0..∞] Start of section with certain train radio

train part in subsequent sections applies for instance if the operating days change at an intermediate station. For more information, please read Train coupling

file path to a local copy of the XML schema set. This technology does not change the <railml> attributes as above mentioned. Remote URI <railml xsi:sche

ownerChanges   Parent: <trackElements> Children: <ownerChange> [0..1] A ownerChanges is a container for all elements of ownerChange. An unlimited number

gaugeChanges   Parent: <trackElements> Children: <gaugeChange> [0..1] A gaugeChanges is a container for all elements of gaugeChange. They are used to determine

electrificationChanges   Parent: <trackElements> Children: <electrificationChange> [0..1] A electrificationChanges is a container for all elements of

trainProtectionChanges   Parent: <trackElements> Children: <trainProtectionChange> [0..1] A trainProtectionChanges is a container for all elements of

mileageChanges   Parent: <trackTopology> Children: <mileageChange> [0..1] A mileageChanges is a container for all elements of mileageChange. They are used

powerTransmissionChanges   Parent: <trackElements> Children: <powerTransmissionChange> [0..1] A powerTransmissionChanges is a container for all elements

axleWeightChanges   Parent: <trackElements> Children: <axleWeightChange> [0..1] A axleWeightChanges is a container for all elements of axleWeightChange. They

Timetable (Common) (Codelists) XML tree UML diagrams Use cases Versions & Changes

<radiusChange> can have an unlimited number of <additionalName> elements. name: Established, human-readable short string, giving the <radiusChange> object

additionalName   Parent: <electrificationChange> Children: None [0..∞] The element <additionalName> provides additional names with descriptions in other

<gaugeChange> can have an unlimited number of <additionalName> elements. name: Established, human-readable short string, giving the <gaugeChange> object

<ownerChange> can have an unlimited number of <additionalName> elements. name: Established, human-readable short string, giving the <ownerChange> object

reading software reading it as kph not knowing this change. The element <dc:identifier> will not be changed if new data are added to a scheme. This is the main

additionalName   Parent: <powerTransmissionChange> Children: None [0..∞] The element <additionalName> provides additional names with descriptions in other

additionalName   Parent: <trainProtectionChange> Children: None [0..∞] The element <additionalName> provides additional names with descriptions in other

additionalName   Parent: <clearanceGaugeChange> Children: None [0..∞] The element <additionalName> provides additional names with descriptions in other

<axleWeightChange> can have an unlimited number of <additionalName> elements. name: Established, human-readable short string, giving the <axleWeightChange> object

<maxTrainCurrent>   Parent: <electrificationChange> Children: None [1..1] (introduced with version 2.4)Maximum allowed train current maxCurrent: maximum

Timetable (Common) (Codelists) XML tree UML diagrams Use cases Versions & Changes

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: (deprecated with version 2.5) This defines

<xs:element name="speedChanges" type="rail:eSpeedChanges" minOccurs="0" /> - <xs:element name="gradientChanges" type="rail:eGradientChanges" minOccurs="0" />

speedChanges   Parent: <trackElements> Children: <speedChange> [0..1] A speedChanges is a container for all elements of speedChange. They are used to determine

operationModeChanges   Parent: <trackElements> Children: <operationModeChange> [0..1] A operationModeChanges is a container for all elements of operationModeChange

IS:trainRadioChanges   Parent: <ocsElements> Children: <trainRadioChange> [0..1] The element <trainRadioChanges> is a container for track-side equipment

since special displays and announcements are required when a track is changed compared to the target track published in printed timetables in order to

<speedChange> can have an unlimited number of <additionalName> elements. name: Established, human-readable short string, giving the <speedChange> object

<gradientChange> can have an unlimited number of <additionalName> elements. name: Established, human-readable short string, giving the <gradientChange> object

<mileageChange> can have an unlimited number of <additionalName> elements. name: Established, human-readable short string, giving the <mileageChange> object

<trainRadioChange> can have an unlimited number of <additionalName> elements. name: Established, human-readable short string, giving the <trainRadioChange> object

additionalName   Parent: <operationModeChange> Children: None [0..∞] The element <additionalName> provides additional names with descriptions in other

Wagenuntersuchung gaugeChange Umspurung für Halte wegen Wechsels der Spurweite Stop caused by a change of gauge (e.g. to change or convert axles) 0009: Change gauge —

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: This defines the validity of border along

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". ocpStationRef: This refers to the id attribute

supplements etc. become incorrect by this practice. Also, it can only be used to change between a certain stop and run through but not to switch between two different

org/wiki/IS:gaugeChanges" /> </xs:annotation> </xs:element> + <xs:element name="clearanceGaugeChanges" type="rail:eClearanceGaugeChanges" minOccurs="0">

bridges) <border>#tarif (intended to describe fare tariff zones) <mileageChange>#raising (intended to describe direction of increasing mileage, i.e. "rising")

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". ocpStationRef: This refers to the id attribute

<balises>, <trainProtectionElements>, <stopPosts>, <derailers>, <trainRadioChanges>, <locks> (introduced with version 2.4), <any> [0..1] The element <ocsElements>

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: (deprecated with version 2.5) This defines

mileageChanges --> - <!-- +- mileageChange --> - <!----> - - <xs:complexType name="eMileageChanges"> - <xs:sequence> - <xs:element name="mileageChange" ty

another train. meet The train meets another train. Passengers/goods may change trains in both directions. IsWaitingFor The train is waiting for another

electrificationChange IS:additionalName gaugeChange IS:additionalName genericArea IS:additionalName geoMapping IS:additionalName gradientChange IS:additionalName

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: This defines the validity of <derailer> along

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: This defines the validity of <balise> along

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: (deprecated with version 2.5) This defines

top of the TN vector is forwarded to train number field 11 and the TN is changed to 5678. File:Poex023.jpg <tdStepping> <type>PATH</type> <origin> <trainNumberField>

Posession Management   Possession is a takeover of responsibility for a part of railway network from the “train operator” to the PICOP (Person In Charge

Parent: <track> Children: <borders>, <connections>, <crossSections>, <mileageChanges>, <trackBegin>, <trackEnd> [1..1] The element <trackTopology> works as a

IS:connection switch IS:electrification IS:electrificationChange vMax isolatedSection IS:gauge IS:gaugeChange IS:levelCrossing length length angle angle protection

railML® schema changes between railML® 2.0 and railML® 2.1   This site collects sources helping you to compare railML® 2.0 and railML® 2.1. Changes are also

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: (deprecated with version 2.5) This defines

ship services (e. g. passenger changing on a ship) bus: if true, the ocp offers bus services (e. g. passenger changing on a bus) airport: if true, the

value="crewChange"> <xs:annotation> - <xs:documentation>Stop to change engine or train crew</xs:documentation> + <xs:documentation>Stop to change engine crew

railML® schema changes between railML® 2.2 and railML® 2.3   This site is intended to collect the schema changes between railML® 2.2 and railML® 2.3 by

the milepost, e.g. for documenting a mileage gap mileageChangeRef: reference to a mileageChange element lineRef: reference to a line, for which the milepost

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: (deprecated with version 2.5) This defines

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". type Possible values are: station An area defined

reading software reading it as kph not knowing this change. The element <dc:identifier> will not be changed if new data are added to a scheme. This is the main

reading software reading it as kph not knowing this change. The element <dc:identifier> will not be changed if new data are added to a scheme. This is the main

reading software reading it as kph not knowing this change. The element <dc:identifier> will not be changed if new data are added to a scheme. This is the main

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: (deprecated with version 2.5) This defines

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: This defines the validity of lock along the

rail:lang, xsi:type <macroscopicNode> flowDirection, ocpRef <mileageChanges> <mileageChange> absDir, absPos, absPosIn, absPosInOffset, code, description, dir

<checkedBy>, <approvedBy> [0..1] Describes changes from a previous revision and the authors and auditors of these changes. (introduced with version 2.5) id: XML-file-wide

rail:lang, xsi:type <macroscopicNode> flowDirection, ocpRef <mileageChanges> <mileageChange> absDir, absPos, absPosIn, absPosInOffset, code, description, dir

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". id: xs:ID, required a string, starting with a

attribute for further descriptions. trainReverse: This is true if the train changes its direction of travel at this station which is sometimes shown by a sign

IS:trainProtectionElement Attribute trainProtectionSystem of IS:trainProtectionChange Attribute trainProtectionSystem of IS:trainProtection Attribute type of

stick to the markup guidelines. As a privileged user, please review the changes continously; comp. Help:Page validation. Please, follow the structuring

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: This defines the validity of <trainProtectionElement>

Timetable (Common) (Codelists) XML tree UML diagrams Use cases Versions & Changes

website). To learn about the version history and the changes between the respective versions see Dev:changes. →Main Article: Dev:Guides complete railML® 2 trees

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: This defines the validity of <trackCondition>

version 2.5) type: Specify the type of connection. Possible values are: direct changeDrivingDirection crossesContraflowTraffic requiresShunting other:anything:

aren't very clear. It seems to be redundant to the definitions with mileageChanges in "overlapping regions". dir: This defines the validity of trainDetector

elements: Infrastructure subschema <clearanceGauge>, child of <clearanceGaugeChange> <clearanceGauge>, child of <infraAttributes> Rollingstock subschema <trainClearanceGauge>

for the purpose of exchange. If you have any questions or requests for changes, please contact the relevant, named register owner. railML.org will be happy

version 2.5) Possible values are: planned actual calculated toBeChecked changed imported other:anything: Any value that does not fit any value from the

railML® profile). This version number changes if the interpretation of the schema by the writing software changes. A reading software should check whether

Dev:usingAny accordingly. orderChangeable: if true, the ocp is capable of changing the train sequence on the open track. That means that the ocp has at least

None A train runs all year Mo–Fr labelled as 111-01 and Sa, Su (with minor changes) under the label 111-02 Due to construction activities, lasting the complete

in handling between elements, attributes, enumeration values, occurence changes... In railML® 3, the template will generally not be used, as the differences

additional semantic constraints apply like for the <speedChange>: • Only applies if speedChanges (ownerChange) are exported at all [as they are not required by

and fully validating without any error or warning messages Dev:Codelists Changes sorted by released versions

measurement points in the general sense (such as stations, stops, line changes, signals, etc.). Each infrastructure reference point required by the timetable

<clearanceGaugeChanges> <clearanceGaugeChange id="cs263011" pos="182"> <clearanceGauge code="GA"/> </clearanceGaugeChange> </clearanceGaugeChanges> </trackElements>

arrival/departure track scheduled arrival/departure track in case it was changed stop posts information areas for passenger information Using the element

<revision> Children: <objectRevised> [0..1] Container for references to objects changed in this revision.(introduced with version 2.5) None None Not yet described

in the track end (pos = length of track). Thus, a switch always marks a change of track, no matter if the main or the branching way is chosen. Additionally

actuating the car body tilting (active/passive) tiltingSpeed: speed of changing the tilting angle in degrees per second maxTiltingAngle: xs:decimal, 6

tiltingSpeed: This is the speed in degrees per second the tilting angle changes in normal operation. maxTiltingAngle xs:decimal, 6 digits and 3 fraction

with a signal. orderChangeable='true' means that the train sequence can be changed, eg via a passing loop <propService>: The element declares service aspects

some information of the object identified by the enclosing identifier is changed. timetableYear: Refers to the timetable period in which the business is

Children: None [0..∞] This element allows the detailed specification of changes in the track and platform designations for one <ocpTT> of the <train> run

train 2 in Bf_C and from there continue as train section "tp1_2" (without changing traffic days). Abbildung in railML® mit 2 betrieblichen Zügen: Bf_A – Bf_C

<objectsRevised> Children: none [1..∞] Reference to an object that was changed in this revision. (introduced with version 2.5) ref: This refers to the

least one <speedChange> at the track begin with parameters @pos="0" and @dir="up"; • every line track has to have at least one <speedChange> at the track

x Letter indicating the type of Train (e. g. "R") status speedType, speedChangeType string x Meaning? protection levelCrossingType string x kind bridgeType

infrastructure and rollingstock data is not changing very often. Also, the amount of data exchanged here will not change a lot between data deliveries. It is

rt%20Replace.pdf?rev=1.1 (external link) : The CESuRa System: Allowing Changes in a Rail Track Profile While Maintaining Full Vertical Support; in: Urban

child of <infraAttributes> Element <clearanceGauge>, child of <clearanceGaugeChange>

of <electrification> Element <maxTrainCurrent>, child of <electrificationChange>

railML® profile). This version number changes if the interpretation of the schema by the writing software changes. A reading software should check whether

railML® profile). This version number changes if the interpretation of the schema by the writing software changes. A reading software should check whether

railML® profile). This version number changes if the interpretation of the schema by the writing software changes. A reading software should check whether

of UUIDs. This ID is unique within the whole railML® scheme and may not changed within the lifetime of this object. One creating instruction is: The first

Dev:categoryUsage Dev:changes/2.1 Dev:changes/2.1/diff Dev:changes/2.2 Dev:changes/2.2/diff Dev:changes/2.3 Dev:changes/2.3/diff Dev:changes/2.4 Dev:changes/2.4/diff

required data regarding certain aspects. How often do the data change (update)? static (not changing) in cases of error-corrections: weekly .. daily in rare cases

website)): rail:tMileageChange/@absPos rail:aAbsPosition/@absPos rail:eTrackEnd/@absPosIn rail:tMileageChange/@absPosIn rail:tMileageChange/@absPosInOffset r

Timetable (Common) (Codelists) XML tree UML diagrams Use cases Versions & Changes

each case, replacing an existing one. Another use case is the exchange of changed planning data. For example, if a route cannot be travelled due to construction