Introduction
Documentation
Syntax
Autoexport from the XML-Schema for element RTM:spotLocation of railML ® version 3.3
|
Documentation
|
defines the concept of punctual location on a net element of a logical topology of a network.
|
Subschema
|
Rtm4railml
|
Parents*
|
balise,
baliseGroup,
border,
bufferStop,
crossing,
derailerIS,
detector,
electrificationSection,
etcsArea,
etcsLevelTransition,
genericArea,
geometryPoint,
gradientCurve,
horizontalCurve,
keyLockIS,
levelCrossingIS,
line,
linesideElectronicUnitIS,
loadingGauge,
loop,
mileageChange,
operationalPoint,
overCrossing,
platform,
platformEdge,
radioBlockCentreBorder,
restrictionArea,
roadSideBarriers,
roadSideLights,
serviceSection,
signalIS,
speedSection,
stoppingPlace,
switchIS,
track,
trackBed,
trackGauge,
trainDetectionElement,
trainProtectionElement,
trainRadio,
tunnelGateIS,
underCrossing,
weightLimit
|
Children
|
geometricCoordinate (0..1), linearCoordinate (0..1)
|
Attributes:
- applicationDirection: direction in which the element is applied, related to the orientation of the <netElement> (optional;
xs:string )
- Possible values:
- both: from intrinsicCoordinate=0 to intrinsicCoordinate=1 AND from intrinsicCoordinate=1 to intrinsicCoordinate=0
- normal: from intrinsicCoordinate=0 to intrinsicCoordinate=1
- reverse: from intrinsicCoordinate=1 to intrinsicCoordinate=0,
- intrinsicCoord: location on the <netElement> in normalized form (value in range 0..1) (optional;
xs:double ; minInclusive: 0; maxInclusive: 1),
- netElementRef: reference to a railway topology <netElement> element or a <netConnector> element (obligatory;
xs:IDREF ),
- id: the identifier of the object; this can be either of type xs:ID or UUID (obligatory;
xs:ID ); compare: Dev:Identities
|
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this Wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
Autoexport from the XML-Schema for element RTM:spotLocation of railML ® version 3.2
|
Documentation
|
defines the concept of punctual location on a net element of a logical topology of a network.
|
Subschema
|
Rtm4railml
|
Parents*
|
balise,
baliseGroup,
border,
bufferStop,
crossing,
derailerIS,
detector,
electrificationSection,
etcsArea,
etcsLevelTransition,
genericArea,
geometryPoint,
gradientCurve,
horizontalCurve,
keyLockIS,
levelCrossingIS,
line,
loadingGauge,
mileageChange,
operationalPoint,
overCrossing,
platform,
platformEdge,
radioBlockCentreBorder,
restrictionArea,
serviceSection,
signalIS,
speedSection,
stoppingPlace,
switchIS,
track,
trackBed,
trackGauge,
trainDetectionElement,
trainProtectionElement,
trainRadio,
tunnelGateIS,
underCrossing,
weightLimit
|
Children
|
geometricCoordinate (0..1), linearCoordinate (0..1)
|
Attributes:
- applicationDirection: direction in which the element is applied, related to the orientation of the <netElement> (optional;
xs:string )
- Possible values:
- both: from intrinsicCoordinate=0 to intrinsicCoordinate=1 AND from intrinsicCoordinate=1 to intrinsicCoordinate=0
- normal: from intrinsicCoordinate=0 to intrinsicCoordinate=1
- reverse: from intrinsicCoordinate=1 to intrinsicCoordinate=0,
- intrinsicCoord: location on the <netElement> in normalized form (value in range 0..1) (optional;
xs:double ),
- netElementRef: reference to a railway topology <netElement> element (obligatory;
xs:string ; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}),
- pos: a distance from the edge of a net element (optional;
xs:decimal ),
- id: the identifier of the object; this can be either of type xs:ID or UUID (obligatory;
xs:string ; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
|
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this Wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
Autoexport from the XML-Schema for element RTM:spotLocation of railML ® version 3.1
|
Documentation
|
This element is not documented in the schema!
|
Subschema
|
Rtm4railml
|
Parents*
|
balise,
border,
bufferStop,
crossing,
derailerIS,
electrificationSection,
geometryPoint,
gradientCurve,
horizontalCurve,
keyLockIS,
levelCrossingIS,
line,
loadingGauge,
operationalPoint,
overCrossing,
platform,
restrictionArea,
serviceSection,
signalIS,
speedSection,
stoppingPlace,
switchIS,
track,
trackBed,
trackGauge,
trainDetectionElement,
trainProtectionElement,
trainRadio,
underCrossing,
weightLimit
|
Children
|
geometricCoordinate (0..1), linearCoordinate (0..1)
|
Attributes:
- netElementRef: reference to a railway topology <netElement> element (obligatory;
xs:IDREF ; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}),
- intrinsicCoord: location on the <netElement> in normalized form (value in range 0..1) (optional;
xs:double ),
- applicationDirection: direction in which the element is applied, related to the orientation of the <netElement> (optional;
xs:string )
- Possible values:
- pos: generic type for length values measured in metres (optional;
xs:decimal ),
- id: the identifier of the object; this can be either of type xs:ID or UUID (obligatory;
xs:ID ; patterns: (urn:uuid:)?[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}}); compare: Dev:Identities
|
*Notice: Elements may have different parent elements. As a consequence they may be used in different contexts. Please, consider this as well as a user of this Wiki as when developing this documentation further. Aspects that are only relevant with respect to one of several parents should be explained exclusively in the documentation of the respective parent element.
|
Changes 3.1→3.2
There exists an overview of all changes between railML® 3.1 and railML® 3.2 on page Dev:Changes/3.2.
The element documentation has been changed.
The parents have been changed.
The children have been changed.
The attributes have been changed.
Changes 3.2→3.3
There exists an overview of all changes between railML® 3.2 and railML® 3.3 on page Dev:Changes/3.3.
The parents have been changed.
The children have been changed.
The attributes have been changed.
Semantics
In terms of RailTopoModel®, spotLocation refers to netElement. This means that the functional infrastructure is located on this netElement and its applicationDirection refers to the netElement orientation.
- Enumeration values of @applicationDirection visualized
The applicationDirection in this case is "both", since the crossing is valid from intrinsicCoordinate = "0" to intrinsicCoordinate = "1" AND from intrinsicCoordinate = "1" to intrinsicCoordinate = "0".
The applicationDirection in this case is "normal", since the signal is valid from intrinsicCoordinate = "0" to intrinsicCoordinate = "1".
The applicationDirection in this case is "reverse", since the signal is valid from intrinsicCoordinate = "1" to intrinsicCoordinate = "0".
|
Proposed Semantic Constraint "IS:012": @pos should have only positive values because its a distance, thus -1 is not a valid value – Compare #567 Proposed on March 04th 2024
Please, recognize our guidelines on semantic constraints
|
|
Best Practice / Examples
Additional Information
Notes
(introduced with version 3.3) Please note that as of version 3.3 of railML® the children of <spotLocation>, <linearCoordinate> and <geometricCoordinate> are organized in a xs:choice in the schema. This means that either a <linearCoordinate> or a <geometricCoordinate> may be specified. It is syntactically not possible anymore to specify both for the same <spotLocation>.
Open Issues