User:RailML Coord Documentation/IS:serviceSection

From railML 2 Wiki
Jump to navigation Jump to search
🗒️ this is a preview of page IS:serviceSection as to circumvent Template:Unlock. The preview is made with Template:Frame.

Is anymething missing?
purge this page.
purge the framed page.



serviceSection
 


Scheme description / Schemenbeschreibung

Position of serviceSection in the XML-Tree / Position von serviceSection im XML-Baum

Multiplicity / Anzahl

[0..∞]

Semantics / Bedeutung

A <serviceSection> defines the border line between a railway service area and a railway track, where the service for the train takes place. A service section is always connected with exactly one railway track.

Attributes of serviceSection / Attribute von serviceSection

  • id: XML-file-wide unique, machine-interpretable identity, required for later referencing that element internally. For a detailed explanation see Dev:identities.
    XML-Datei-weit eindeutige, maschineninterpretierbare Identität, die fßr die spätere interne Referenzierung dieses Elements erforderlich ist. Fßr eine detaillierte Erklärung siehe Dev:identities.
  • code (introduced with version 2.1): Machine-interpretable string (e.g. an abbreviation) used for identification of the object across exchange partners, usecase specific uniqueness constraints may apply. Please see our description of the differences between id, code and human-readable identifiers.
    Maschineninterpretierbare Zeichenkette (z.B. Abkßrzung), die zur Identifizierung des Objekts auch bei Austauschpartnern verwendet wird, wobei spezifische Eindeutigkeitsbeschränkungen gelten kÜnnen. Bitte beachten Sie unsere Erläuterung zu den Unterschieden zwischen id, code and menschenlesbaren Kennzeichnungen.
  • name: Established, human-readable short string, giving the object a name. Not intended for machine interpretation, please see our notice on human interpretable data fields.
    Etablierte, menschenlesbare kurze Zeichenkette, die das Objekt benennt. Nicht zur maschinellen Interpretation bestimmt, siehe Hinweise zu menschenlesbaren Datenfeldern.
  • description: Human-readable, more detailed description as addition to the name. It should give additional explanations or hints to the contents of this element. Not intended for machine interpretation, please see our notice on human interpretable data fields.
    Menschenlesbare, detailliertere Beschreibung als Ergänzung zu name. Sie soll zusätzliche Erläuterungen oder Hinweise auf den Inhalt dieses Elements geben. Nicht zur maschinellen Interpretation bestimmt, siehe Hinweise zu menschenlesbaren Datenfeldern.
  • xml:lang (introduced with version 2.1): This is a unique identifier of language. It uses basically the language standard IETF BCP 47 (external link) which may be different to ISO 639-1 (external link) or ISO 639-2 (external link). For mapping hints see relation to other standards (external link).
    This defines the language used for name and description. Use Template:Ra:Tag to provide a name and/or description in other languages.


  • pos: This is the position on a track defined as distance from its start (trackBegin) regardless the "absolute mileage" in @absPos.
    Das ist die Position des Elements auf einem Track i.S. der realen Entfernung zum trackBegin. Sie ist damit unabhängig von der mit absPos modellierten Strecken-Kilometrierung.
🗒️ For an explanation of the differences between @pos and @absPos see <mileageChange>
  • absPos: This is the position on a track as absolute mileage/chainage.
    Das ist die Position des Elements im Referenzsystem der Strecken-Kilometrierung.
🗒️ For an explanation of the differences between @pos and @absPos see <mileageChange>
  • absPosOffset (deprecated with version 2.1): The semantics of this attribute 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 the validity of <serviceSection> along the track. Possible values are:
  • none: <serviceSection> has no direction restriction.
  • up: This denotes the direction from the <trackBegin> to the <trackEnd> (increasing relative position values).
  • down: This goes opposite to up (decreasing relative position values).
  • both: <serviceSection> is valid in both directions.
  • unknown: <serviceSection> is restricted to a certain direction, but this direction is not known.
  • ocpRef: reference to the OCP, where the platform edge / service section belongs to
  • length: length along the track in meters
  • height: height above the rails in millimeter
  • side: side as seen from the oriented track, e.g. left or right
  • parentServiceSectionRef: reference to a parent service section for grouping service section parts together
  • ramp: defining the service section as being a ramp
  • maintenance: defining the service section as being a maintenance area
  • loadingFacility: defining the service section as being equipped with loading facilities
  • cleaning: defining the service section as being a cleaning area
  • fueling: defining the service section as being a fueling area
  • parking: defining the service section as being a parking area
  • preheating: defining the service section as being a preheating area
  • rampType: (introduced with version 2.5) specifies the specific construction of the ramp. can be:
    • flat: a flat ramp
    • metalBridge: a metal bridge used as car ramp
    • other:anything: Any value that does not fit any value from the previous enumeration list, fulfilling the constraint: at minimum two characters, whitespace is not allowed. Please, apply Dev:usingAny accordingly.

Syntactic Constraints / Syntaktische Beschränkungen

  • id: xs:ID, required
    a string, starting with a letter (a..zA..Z) or an underscore (_),
    followed by a non-colonized and non-spaced string consisting of letters, digits, points (.), dashes (-) or underscores (_)
  • code: xs:string, optional
  • name: xs:string, optional
  • description: xs:string, optional
  • xml:lang: xs:language, language identification, optional

Best practice & Examples / Empfohlene Anwendung & Beispiele

Modelling a car ramp

  • A car ramp shall be modelled using the existing railMLÂŽ element <serviceSection> together with boolean attribute @ramp="true".
  • A car ramp at the side of a track should be described with @length > 0, a @pos between 0 and length of <track> and a @side={"left", "right"}.
  • A car ramp at the end of a track should be described with no @length, a @pos of either "0" or the length of <track> (depending if the car ramp is at the <trackBegin> or at the <trackEnd>) and no @side.
  • A car ramp that is situated both, at the side and at the end of a <track>, shall be modelled with two <serviceSection> elements:
  • The optional @rampType (introduced with version 2.5) can be used to specify the specific construction of the ramp with possible values "flat" and "metalBridge"... (extendable enumeration)

Notes / Anmerkungen

General information on positioning

Positive pos values describe the distance from the track's begin. The track length is derived from the pos value in <trackEnd>.

The absolute mileage refered to by absPos is usually found on technical drawings of the track layout or on mileage posts next to the track.

Open issues / Offene Punkte/Pendenzen

Not yet described. / Noch nicht beschrieben.