While railway tracks are geographical features "in the landscape", the geometry of which can be described with usual GIS data (coordinates and their reference systems) and conventions (defining "track centerline" for instance), railway vehicles are guided and for most use cases except derailments, the linear coordinates of vehicles along a certain path fully characterizes their position, as well as most common safety-critical parameters (such as distance to End of Movement Authority or to a fouling point).

Obviously, other spatial distances and angles play important roles, such as lateral position of a vehicle with respect to a platform edge, or vertical distance between the locomotive roof and the contact wire, or carbody inclination with respect to the vertical. Here we limit the discussion to linear coordinates along the travel path.

IFC 4.1 and further versions include IfcAlignment and other EXPRESS types closely following and explicitly referencing ISO_19148 [Iso01]. In particular, the definition of IfcAlignment results from joint efforts of (inter alia) six railway infrastructure managers in order to represent railway track geometries in the usual, parametric way, by defining a horizontal alignment, a vertical alignment, and a cant alignment, the conjunction of which results in the design geometry of a track centerline and of track rails. IfcAlignment also accepts other geometric representations, e.g. from survey points.

It is therefore advisable to use IfcAlignment "as is", in conjunction with other, previously available IFC types relative to linear referencing. Consistency with concepts and data arising from other parts of the CDM is necessary: in particular, GeoSPARQL (used by sRSM, ERA Vocabulary and others) must be considered.

GeoSPARQL [Ogc01] provides two geometry datatype properties, geo:asWKT and geo:asGML, using WKT and GML strings.

GeoSPARQL extends WKT encoding by allowing the CRS (Coordinate Reference System) to be explicitly specified as part of the WKT literal [Ogc01, clause 10.3.3]. This is achieved by prefixing the WKT string with a CRS URI, separated by a semicolon. For example, this would be a point in WGS84, at longitude = 10 degrees East and latitude = 30 degrees North: <http://www.opengis.net/def/crs/EPSG/0/4326>; POINT(30 10). WKT literals without an explicit CRS default to http://www.opengis.net/def/crs/OGC/1.3/CRS84 (equivalent to WGS84 with longitude-first order). Apache JENA also supports this WKT extension [Apa01].

Note: WKT also allows to identify CRS (WKT-CRS extension) but this identification is not used for annotating coordinates.

With this extension, WKT is broadly equivalent to GML. More details are provided below where relevant.

By "grassroots", we mean that we are not trying to deal, in a section dedicated to linear referencing, with semantic misalignment between BIM and GIS systems, but only with the representation of elementary data: lines, etc. About the challenges of semantic misalignment, tooling, etc., see for instance this publication.

Aspect	WKT LineString	GML (Geography Markup Language)	GeoJSON (RFC 7946)	IFC Polyline
Standard	OGC Simple Features	OGC (XML-based)	OGC RFC 7946	buildingSMART IFC
Domain	GIS, spatial databases	GIS, web mapping, spatial data exchange	Web, GIS, mobile apps	BIM, AEC
Syntax	Text string (e.g., LINESTRING (x y, ...))	XML (e.g., <gml:LineString>...)	JSON (e.g., {"type": "LineString", ...})	STEP/EXPRESS (object list)
CRS in geometry	Can be embedded in string (WKT extension by GeoSPARQL), defaults to CRS84	Can be embedded via srsName	Implicit (WGS84/EPSG:4326)	Not embedded; defined by project context
Supported CRSs	Any (geographic, projected, custom)	Any, explicitly referenced	WGS84 (EPSG:4326) only	Typically local Cartesian, can refer to any CRS
2D, 3D, 4D support	2D, 3D (Z), 4D (Z, M)	2D, 3D (via coordinate lists)	2D, 3D (Z)	2D, 3D (Z)
Dimensionality	Explicit in geometry type (Z, M, ZM)	Explicit in coordinate list	Implicit (coordinates array length)	Implicit, based on point definitions/context
Measures (M)	Supported (optional)	Not supported	Not supported	Not supported
Empty geometry	Supported (LINESTRING EMPTY)	Supported (<gml:Null/>)	Not directly supported (omitted/nullable)	Not supported
Multi-geometries	Supported (e.g., MULTILINESTRING)	Supported (e.g., <gml:MultiLineString>)	Supported (e.g., MultiLineString)	Not directly supported
Transformation	Not specified in geometry string	CRS transformation via srsName	Requires reprojection (WGS84 only)	Handled via transformation parameters
Coordinate Order	X, Y [, Z, M]	X, Y [, Z] (depends on CRS)	Longitude, Latitude [, Z]	Local Cartesian (X, Y, Z)

Other implementations of ISO 19148, or parts thereof, have been considered.

• the former RTM/RSM positioning package included both coordinate reference systems (CRS) and linear referencing systems (LRS) descriptions. Since the CRS description migrated to GeoSPARQL via a minimal adapter, keeping only the LRS part was not appealing when IFC had to be adopted anyway.
• DATEX is:

An RDF/OWL vocabulary to represent SRTI (= Safety-related traffic information) DATEX II profile (according the Commission Delegated Regulation (EU) No 886/2013) within the European LOD-RoadTran18 action "Supporting the cross-border use of Road Traffic Data with Linked Open Data based on DATEX II (LOD-RoadTran18)" (Agreement No: INEA/CEF/ICT/A2018/1803421, Action No: 2018-EU-IA-0088). The vocabulary is used for mapping between DATEX II vers. 3 and LOD formats.

DATEX II inter alia transposes parts of ISO 19148. Again, given the use of IFC, it did not seem useful to add this complex vocabulary for only using its ISO_19148-related parts already provided by IFC.

[Apa01]: Apache JENA Geosparql documentation

[bsi01]: IFC 4.3 Addendum 2, published by buildingSMART International, 2024

[Iso01]: ISO 19148:2021, "Geographic information — Linear referencing"

[Ogc01]: OGC GeoSPARQL 1.1, April 2023