Alignment and its representation - UICrail/CDM-IFC GitHub Wiki

Context: respective responsibilities of ontologies under the CDM

In railway infrastructure applications, linear entities (tracks, multi-track lines, tunnels...) are predominant. Tracks and lines composing a network are represented in the CDM by various aspects, such as:

  • topology (reflecting the function "guiding rolling stock");
  • geographic positioning (geometry with respect to the surface of the earth);
  • geometry (for the purpose of track layout, kinematic analysis of circulating rolling stock on the track, or placement of infrastructure objects with respect to each other);

Currently, topology is illustrated by RSM with, essentially, linear elements. Geographic positioning is taken care of by GeoSPARQL. IFC4.3 ADD2 provides all necessary representations of railway track "alignment" (parametric geometry), in particular thanks to the contributions of the IFC Rail project. Moreover, using IfcAlignment ensures a smooth interfacing will all other BIM-related aspects of railway infrastructure description, which is why the LinX4Rail project included IFC4.3 in the CDM federation.

The proposed linking of IfcAlignment with other CDM model elements is further described in this page.

Track alignment in IFC

Relevant IFC Concepts

The title "track alignment" would be roughly understood by domain experts ("tracks have an alignment that can be described by horizontal alignment" etc.), but the design principles of IFC 4.3 ADD2 (IFC 4.3.2.0) are different.

First of all, there is no special entity for "track" in IFC, which is a sound design choice as "track" is quite polysemic.

The nearest concepts, in IFC, are:

  • Ifc_BuiltSystem: with no subtypes but enumerated, pre-defined types that include:

    • RAILWAYLINE: "A set of functional tracks with explicit terminals. It is usually composed of a set of tracks with continuous track parts and alignments."
    • RAILWAYTRACK: "Railway track system. It is usually composed of continuous sequences of track parts and alignments."

  • Pset_BuiltSystemRailwayTrack: a property set composed of properties track ID, track track number, track usage, track characteristic, i.e. related to both the physical track (including accessories such as third rail) and its operational use.

  • IfcTrackElement: "A track element is a built element used specifically in the track domain in railway"

    • subtype of IfcBuiltElement < IfcElement < IfcProduct;
    • being a subtype of IfcProduct, it accepts geometric representations; we quote:

      The IfcProduct is an abstract representation of any object that relates to a geometric or spatial context. An IfcProduct occurs at a specific location in space if it has a geometric representation assigned.

    • IfcTrackElement in turn has enumerated, pre-defined types: BLOCKINGDEVICE, DERAILER, FROG, HALF_SET_OF_BLADES, SLEEPER, SPEEDREGULATOR, TRACKENDOFALIGNMENT, VEHICLESTOP, USERDEFINED, NOTDEFINED.

Relationships between IFC concepts

Track system and its elements

In IFC, a "Railway Track" is an Ifc BuiltSystem, hence a subclass of IfcGroup. An IfcGroup is a container with no pre-defined contents; its content is identified via an instance of IfcRelAssignsToGroup (an "association class" in UML parlance, or "association table"in RDBMS talk). The contents of an IfcGroup must be of type IfcObject, an abstract type quite up in the IFC type hierarchy; quoting from the IFC 4.3.2.0 online documentation:

An IfcObject is the generalization of any semantically treated thing or process. Objects are things as they appear - i.e. occurrences. Examples of IfcObject include physically tangible items such as wall, beam or covering, physically existing items such as spaces, or conceptual items such as grids or virtual boundaries. It also stands for processes such as work tasks, for controls such as cost items, or for actors such as persons involved in the design process.

A "Railway Track", being a group, has no direct representation in the sense of IFC. Its elements may have a representation though, if these are of type IfcProduct.

A track element (instance of IfcTrackElement) is such an IfcProduct; by definition it may be associated with a representation. From the point of view of railway engineering, an IFC Railway Track is likely to group IFC Track Elements, rails (of type IfcRail), fasteners (of type OfcFastener), sleepers (of type IfcStructuralMember), cable ducts (of type IfcDistributionElement), etc.

An alignment is also an IfcProduct and could be part of at most one "Railway Track", since IfcRelAssignsToGroup admits exactly one relating Group. But again, IFC does not mandate a railway track to group one (or more) alignments.

IFC Representation may be assigned to any IfcProduct

IfcRepresentation is an abstract class defined as follows, quoting from IFC 4.3.2.0 online documentation:

Definition from ISO 10303-43: A representation is a collection of one or more representation items that are related in a specified representation context. The relationship of representation item to representation context is the basis for distinguishing which representation item entities are related. A representation item can be related to a representation context directly, when it occurs as an element is a representation, or indirectly, when it is referenced through any number of intervening entities, each of type representation item.

Alignment representation

The representation of track alignment (curves, slopes, cant variations) is an essential part of the IFC Rail project, and is now published as part of IFC 4.3 ADD2. It is a kind of "parametric geometry", where 3D curves in space are represented via their horizontal projection (IfcAlignmentHorizontal) and vertical projection (IfcAlignmentVertical). See the IfcAlignment documentation.

In addition, since railroad tracks (or roads...) are "ribbons" rather than infinitely thin lines in space, IfcCant will provide the corresponding "twist" information.

IfcAlignment is generalized by IfcLinearPositioning, an "entity describing positioning according to a curve". Under IfcLinearPositioning, there is no restriction to the description of such a curve, while IfcAlignment provides a wide but limited catalog of curve segments (line, circular arc, clothoid, etc.) for the user to assemble. IfcAlignment reflects current railway infrastructure design practice and gets the focus here, while the more general IfcLinearPositioning should not be ignored.

Alignment nesting

Chosen variant

IFC offers various nested structures to document alignment. The variant we illustrate is documented here. For readers' convenience, we may sum it up here, using UML-like conventions regarding multiplicities:

---
title: IfcAlignment details (as UML) - for illustration only
---
classDiagram
    IfcLinearPositioningElement <|-- IfcAlignment 
    IfcAlignment "1" -- "0..*" IfcRelNests
    IfcRelNests : Description [0..1]
    IfcRelNests "1"-- "1" IfcAlignmentHorizontal
    IfcRelNests "1"-- "0..1" IfcAlignmentVertical
    IfcRelNests "1"-- "0..1" IfcAlignmentCant
    IfcLinearElement <|-- IfcAlignmentHorizontal
    IfcLinearElement <|-- IfcAlignmentVertical
    IfcLinearElement <|-- IfcAlignmentCant
    IfcLinearElement <|-- IfcAlignmentSegment
    IfcAlignmentHorizontal "1" -- "0..*" IfcRelNests_copy
    IfcRelNests_copy : Description [0..1]
    IfcRelNests_copy "1" -- "1..*" IfcAlignmentSegment
    IfcAlignmentSegment "1" --> "1" IfcAlignmentHorizontalSegment : DesignParameters

Meaning of the nesting

As shown above, the nesting is implemented by using IfcRelNests class instances that have no predefined meaning: only the (text) value of the optional property Description of the concerned IfcRelNests instance may tell you more, e.g. "originally planned alignment" and "alignment variant avoiding high-density areas" or the like.

The multiplicity [1:?] of property Related object is subject to interpretation. Following the initial sentence in the referenced page, we assume that an IfcAlignment (the relating object) is associated with exactly one horizontal alignment and, optionally, one vertical and one cant alignment (reflecting common practice) but nothing forbids to instantiate more IfcRelNests, associating the same IfcAlignment instance with other horizontal, vertical, and cant alignments: indeed, property isNestedBy of class IfcAlignment has multiplicity [0:?].

The same questions arise concerning the link (via IfcRelNests instances) between, say, IfcAlignmentHorizontal and its segmentation. IFC offers the possibility to provide several segmentations with different meanings, to be documented by properly annotating the IfcRelNests instances that links them.

Alignment: dealing with an ordered list (a sequence) of segments

The segments composing a [horizontal, or vertical, or cant] alignment are an ordered list in EXPRESS. Not sure how the order is managed in EXPRESS though. In its IfcOwl translation, the authors designed a particular ontology for creating sequences: see the LIST ontology by Pieter Pauwels and Walter Terkaj. The segment list is therefore set up, in RDF/OWL, as a linked list: each segment holds a pointer to the next segment.

The last (non-empty) element in the list is a zero-length element, as required by IFC. Property StartPoint of this segment will effectively provide the end point of the alignment, this probably being the reason for requiring it: IFC does not define any EndPoint property for segments.

Finally, the LIST ontology requires the list to be explicitly terminated by an instance of EmptyList. It is the element following the zero-length element. Here is an illustration:

---
title: Linked list of segments (object diagram)
---
classDiagram
    Segment1 --> Segment2: hasNext
    Segment2 --> SegmentN: hasNext
    SegmentN: SegmentLength=0
    SegmentN --> EmptyList: hasNext

A better IfcAlignment representation in UML

IfcAlignment illustration

Serialization of a sample set

The Scheibenberg (Germany) area was provided by the System Pillar as a sample set, using the CCS/TMS data model. The data are available in XML format. Alignment-related data are provided by the CCS/TMS model under the "Geometry Area". The elements found in the geometry area are very similar to those under IfcAlignment, so the Scheibenberg sample set was used as a testbed for the RSM-IFC coupling.

The Scheibenberg data import results are available in the SemanticRSM GitHub; see in particular the code and the results (ttl file) under the corresponding folder.

The results look satisfactory. The overwhelming file size is not due to the chosen format, but rather to the fact that the original data encoded are survey data rather than alignment data: essentially, a succession thousands of short straight segments. Alignment data normally encompass sections, the length of which typically lies in the 100m - 10,000m range, so sections are never that numerous on such short line sections.