IFC 4.3 for infrastructure: what changed

2. The History: Why IFC Was Building-Centric

2.1 The Origins of IFC and the Building Mental Model

The Industry Foundation Classes were conceived in 1994 at Autodesk, initially as a C++ class library to enable data sharing between building applications. The International Alliance for Interoperability (IAI, later renamed buildingSMART) took stewardship of the standard and published the first public release — IFC 1.0 — in 1997. The founding use case was unambiguous: share information between architectural, structural, and building services applications on construction projects. The conceptual anchor was the building storey. Everything else in the schema descended from that anchor.

IFC 2x3, published in February 2006 and ratified as ISO 16739:2005 in the same period, became the long-running interoperability baseline. Its spatial hierarchy reads: IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey → IfcSpace. Physical elements were subtypes of IfcBuildingElement: walls, slabs, beams, columns, doors, windows, curtain walls. The schema was rich and well-tested for its intended purpose. Certification against the Coordination View 2.0 MVD became the de facto requirement for BIM software across Europe and Asia.

For building projects, it worked. For infrastructure projects, the mismatch was apparent from the first attempt. A road does not have storeys. A bridge does not have rooms. A railway has neither, and it also has cant — a lateral tilt of the track designed into curves to counteract centrifugal force on passengers — which has no building analogue at all.

2.2 The Proxy Era: 2006–2015

Infrastructure teams, undeterred, found workarounds. The most common was IfcBuildingElementProxy, an escape-hatch entity introduced to hold any physical element for which no defined subtype existed. Practitioners mapped tunnel linings, pavement layers, retaining walls, drainage channels, and signalling gantries to proxies, then carried domain meaning in bespoke property sets. Some national BIM communities published guidance documents specifying which proxy names and property sets to use for particular asset types — a de facto shadow schema layered on top of the standard one.

The proxy approach had four compounding problems.

First, machine readability was lost. A viewer could render the geometry, but no software could automatically identify a tunnel lining segment as a tunnel lining segment. Clash detection had to be done by colour-code, manually assigned. Quantity take-off required hand-editing. Asset management imports needed custom mapping tables for every project and every receiving system.

Second, the building spatial hierarchy created absurdities. To place elements in an IFC file, they had to live inside an IfcBuildingStorey. Infrastructure practitioners either created a fictional storey — "Ground Level," applied to a twelve-kilometre road — or placed elements directly in the site, which was technically valid but produced strange results in downstream tools expecting the full hierarchy.

Third, coordinate reference system support was rudimentary. IFC 2x3 had no formal mechanism for specifying a projected coordinate reference system. Infrastructure projects span large areas where the difference between local and national coordinate systems is significant. Geolocation was handled through informal conventions that different software implemented differently, causing the Cartesian-offset problems that plagued federated model reviews.

Fourth, there was no alignment concept at all. An alignment — the three-dimensional reference curve that defines the centreline of a road or railway, from which all other elements are offset — is fundamental to how infrastructure engineers position and reference assets. IFC 2x3 had no entity that could represent it. Engineers embedded alignments as geometry-only polylines, losing all semantic connection between the curve and the elements that referenced it.

2.3 IFC 4 and the First ISO Ratification: 2013

IFC 4 (version 4.0.0.0) was published in March 2013 and ratified as ISO 16739:2013. It brought meaningful improvements to building BIM: richer geometry support including NURBS and tessellation, proper 4D and 5D exchange patterns, and better building services coverage. For infrastructure, it changed almost nothing. The spatial hierarchy remained building-centric. The proxy workaround remained necessary. No alignment concept was added.

One contribution from IFC 4 that would prove important for infrastructure: improved IfcCoordinateReferenceSystem and IfcMapConversion entities that allowed a model's local coordinate system to be formally referenced to a national grid. This gave infrastructure teams a standards-backed way to handle the large-scale geospatial positioning that road and rail projects require.

2.4 IFC 4.1 and the Alignment Step: 2015

IFC 4.1 (version 4.1.0.0) was the first release to address infrastructure needs directly. Its primary contribution was the introduction of IfcAlignment — a semantic entity that could represent a road or railway centreline as a combination of horizontal and vertical alignment components. It also introduced IfcLinearPlacement, enabling objects to be positioned by distance along an alignment curve rather than by Cartesian coordinates alone.

The alignment model in IFC 4.1 was deliberately minimal. It described horizontal and vertical geometry as simple composites. Cant geometry — essential for rail — was not included. The horizontal alignment was represented as a flat curve without the rich segment types (clothoid spirals, cubic spirals, Bloss curves) needed for high-speed rail design. The entity was explicitly described as "a basis for various infrastructure domain extensions currently being developed."

What IFC 4.1 demonstrated was that the technical community could reach agreement on the core alignment concept. That consensus unlocked the larger project that followed.

2.5 The Infrastructure Room and the Path to IFC 4.3: 2015–2022

buildingSMART's InfraRoom was established in 2013 to coordinate infrastructure-specific schema development. Over the following years, it launched a series of domain extension projects — IFC Road, IFC Rail, IFC Bridge, IFC Ports and Waterways — each bringing together asset owners, engineering consultants, software vendors, and standards bodies to define what the schema needed to include for each domain.

The harmonisation challenge was substantial. Each domain had its own vocabulary, its own spatial breakdown conventions, and its own geometry patterns. A road has carriageways, shoulders, and drainage channels. A railway has tracks, overhead electrification, signalling, and cant geometry. A bridge has superstructure, substructure, bearings, and deck — but a bridge also sits on a road or railway alignment. A port has quays, jetties, dredged channels, and floating structures. Finding a common structural language that worked for all four, without requiring so many compromises that it ceased to work well for any, took the better part of a decade.

A common schema for harmonisation was established by 2018. The buildingSMART Infrastructure Room worked with ISO/TC 59/SC 13 through the formal standardisation process. IFC 4.3 Release Candidate 1 appeared in 2021, covering railways, roads, ports, and waterways. The final version — IFC 4.3.2.0, containing 62 new occurrence entities and 294 new predefined types — was submitted to ISO and published as ISO 16739-1:2024 on 2 April 2024.

3. What IFC 4.3 Added Structurally

IFC 4.3 reorganised and extended the schema in ways that are both conceptual and technical. Understanding the structural changes matters because they affect how you set up a project, how you exchange data, and what your receiving systems can do with it.

3.1 The Facility Hierarchy: Infrastructure as a First-Class Citizen

The most fundamental change in IFC 4.3 is the promotion of IfcFacility to the central spatial container, replacing IfcBuilding as the primary child of IfcSite. In IFC 2x3 and IFC 4, the hierarchy was fixed: everything lived inside a building. In IFC 4.3, IfcBuilding has been demoted to a subtype of IfcFacility, alongside four new infrastructure-specific facility types:

• IfcRoad — A route built on land allowing travel from one location to another, including highways, streets, cycle paths, and footpaths (but excluding railways). Subtype of IfcFacility.
• IfcBridge — Civil engineering works affording passage to pedestrians, animals, vehicles, and services above obstacles or between two points at height. Defined with reference to ISO 6707-1:2014. Subtype of IfcFacility.
• IfcRailway — A route for guided passage of wheeled vehicles on rails. Aligned with ISO 6706:2017. Subtype of IfcFacility.
• IfcMarineFacility — Any major structure specific to the ports and waterways domain, including quays, jetties, shipyards, and breakwaters. Subtype of IfcFacility.

Each of these entities carries a PredefinedType attribute sourced from a domain-specific enumeration. IfcMarineFacilityTypeEnum, for example, includes BREAKWATER, JETTY, QUAY, REVETMENT, SHIPLOCK, SHIPYARD, and USERDEFINED. This means the high-level asset classification is machine-readable from the entity type alone — no property set parsing required.

The full inheritance chain for all five facility subtypes follows the same path:

IfcRoot → IfcObjectDefinition → IfcObject → IfcProduct
  → IfcSpatialElement → IfcSpatialStructureElement
    → IfcFacility
      → IfcBuilding | IfcRoad | IfcBridge | IfcRailway | IfcMarineFacility

This hierarchy is significant because it means building and infrastructure models share a common structural foundation. A mixed project — a hospital with road access, a rail station with a concourse building — can be expressed in a single coherent IFC file without proxy abuse.

Each facility type decomposes into facility parts using domain-specific subentities. An IfcRoad decomposes into IfcRoadPart elements, which carry a UsageType attribute describing whether the part is a longitudinal segment, a lateral zone (carriageway, shoulder, footway), or a vertical subdivision. An IfcBridge decomposes into IfcBridgePart elements (superstructure, substructure, foundation). An IfcRailway decomposes into IfcRailwayPart elements. An IfcMarineFacility decomposes into IfcMarinePart elements. Each part type carries its own enumeration of predefined usage types, enabling fine-grained spatial decomposition without custom property sets.

3.2 IfcAlignment: The Backbone of Linear Infrastructure

IfcAlignment is the entity that makes IFC 4.3 genuinely useful for infrastructure work. An alignment is the three-dimensional reference curve from which all other infrastructure elements derive their position. In IFC 4.3, IfcAlignment is a subtype of IfcLinearPositioningElement, which is itself a spatial element that can be related to an IfcFacility or IfcSite.

A complete IFC 4.3 alignment carries three geometric components, each composed of typed segments:

Horizontal alignment (IfcAlignmentHorizontal): The plan-view geometry of the route. Segments include straight lines (LINE), circular arcs (CIRCULARARC), and transition curves — clothoids (CLOTHOID), cubic spirals (CUBIC), Helmert spirals (HELMERTCURVE), Bloss spirals (BLOSSCURVE), and others. Each segment is represented as an IfcAlignmentSegment carrying an IfcAlignmentHorizontalSegment design parameter object.

Vertical alignment (IfcAlignmentVertical): The longitudinal gradient profile. Segments are either constant-gradient tangents (CONSTANTGRADIENT) or parabolic vertical curves (PARABOLICARC). This is the data that drives earthwork calculations.

Cant alignment (IfcAlignmentCant): The transverse rotation of the track cross-section across a curve, expressed as a linear variation from zero cant at the beginning of a transition to full cant at the start of a circular arc. Cant is unique to rail; road designs do not typically require it in the IFC model, though superelevation can be expressed similarly.

The geometric representation of an IfcAlignment is expressed through curve types:

• IfcCompositeCurve for a 2D horizontal alignment
• IfcGradientCurve for a combined horizontal + vertical alignment (the 3D centreline)
• IfcSegmentedReferenceCurve for a 3D curve incorporating cant, referenced to a gradient curve
• IfcOffsetCurveByDistances for offset alignments — useful for centrelines of individual tracks in a multi-track section, or for kerb lines offset from a road centreline

The IfcCurveSegment entity is the primitive that makes this work. Each segment in a horizontal, vertical, or cant alignment is an IfcCurveSegment carrying a ParentCurve (the geometric primitive defining the segment shape), a Placement (the start point and direction of the segment in local coordinates), and SegmentStart / SegmentLength parameters defining where along the parent curve the segment begins and how long it runs. This parameterisation allows exact analytical geometry to be stored — no tessellation required — so receivers can re-derive coordinates to arbitrary precision.

3.3 IfcLinearPositioningElement and IfcReferent: Linear Referencing

IfcLinearPositioningElement is the supertype of IfcAlignment. Its purpose is to provide the curve against which other elements are linearly referenced. In infrastructure practice, you do not say "this sign post is at coordinate (385,422.7, 6,141,088.3)." You say "this sign post is at chainage 1+247.5 on the A23 northbound carriageway centreline, offset 3.5 m to the left." Linear referencing is a fundamental operational convention across road, rail, and pipeline asset management. IFC 4.3 encodes it directly in the schema.

IfcReferent is the entity that marks a specific position along an alignment. A referent can represent a station marker, a mileage post, a level crossing location, a road sign position, or any other point of interest that infrastructure operators need to reference by chainage. Referents are nested into their parent alignment using IfcRelNests, so the relationship is structural, not just a property value.

IfcLinearPlacement is the placement type that positions physical elements by distance along an alignment curve, with optional lateral and vertical offsets. A road sign modelled with IfcLinearPlacement will automatically update its computed Cartesian coordinates if the underlying alignment is revised — the parametric relationship is preserved in the data.

3.4 IfcSpatialZone: Non-Hierarchical Spatial Subdivision

Not all spatial decomposition in infrastructure is hierarchical. A clearance envelope on a railway is not a subdivision of a particular track section — it is a volumetric constraint that overlaps multiple track elements and station structures. A noise impact zone on a road does not sit neatly inside a IfcRoadPart. A construction working zone may span multiple disciplines and cannot be assigned to a single facility.

IfcSpatialZone addresses this. It is a spatial element that participates in the project's spatial model but is explicitly non-hierarchical — it can overlap other spatial elements and need not be contained within any particular parent. It carries its own placement and shape representation, distinguishing it from the older IfcZone entity, which was purely a grouping mechanism with no geometry of its own.

Practical infrastructure uses of IfcSpatialZone include: construction access corridors, environmental assessment zones, traffic management areas, temporary works zones, right-of-way boundaries, and spatial clearance envelopes for overhead electrification.

3.5 Geometry for Infrastructure: IfcSectionedSolidHorizontal and IfcLinearPlacement

Two geometry entities deserve specific attention because they resolve problems that made IFC unusable for infrastructure cross-section modelling in earlier versions.

IfcSectionedSolidHorizontal generates a solid by sweeping cross-sections along a directrix curve, maintaining the cross-section's local y-axis in the global z-direction (vertical). This is exactly how road and railway engineers define corridor elements: a cross-section template is swept along the alignment horizontal plane, maintaining vertical orientation regardless of the horizontal curvature of the route. The entity supports varying cross-sections at specified chainage positions, with linear interpolation between them — so a road that widens from two lanes to three across a 200-metre taper is representable exactly.

IfcLinearPlacement is the placement counterpart. It positions an element by specifying an alignment, a distance along that alignment (the chainage), and optional lateral and vertical offsets. The element's local coordinate system is derived from the tangent to the alignment at the specified chainage. This means elements like sign gantries, overhead line supports, and drainage inlets can be placed parametrically, not Cartesianly.

3.6 Domain Physical Elements

Beyond the spatial structure, IFC 4.3 introduced a large number of physical element entities for infrastructure components. The 62 new occurrence entities and 294 new predefined types span all four domains. Selected examples that are particularly significant in practice:

Road domain:

• IfcCourse (with PredefinedType options including PAVEMENT, BALLASTBED, FILTER, CORE) for pavement layer modelling
• IfcEarthworksFill (subtypes EMBANKMENT, BACKFILL, SUBGRADE) and IfcEarthworksCut
• IfcKerb for kerbing elements
• IfcPipeSegment used for open ditches and closed drainage

Rail domain:

• IfcTrackElement (subtypes including RAIL, SLEEPER, RAIL_JOINT, CHECK_RAIL) for track component modelling
• IfcSignal for railway signalling elements
• IfcElectricFlowStorageDevice used for traction power substations

Bridge domain:

• IfcBearing for bridge bearing elements
• IfcDeepFoundation for pile and caisson foundations

Marine domain:

• IfcMooringDevice for bollards and mooring fittings
• IfcNavigationElement for navigation aids and lighting

Cross-domain:

• IfcGeotechnicalStratum for soil layer modelling — a long-standing gap that forced engineers to use proxy elements or export ground models outside IFC entirely
• IfcGeotechnicalAssembly for grouping geotechnical data

These entities are not just labels. Each carries domain-specific property sets (Pset_*) that standardise which properties should be present, what units apply, and what values are acceptable. A Pset_KerbCommon property set, for example, specifies kerb height, material, and whether the kerb is mountable — data that a highway authority needs for asset register population.

/* IFC STEP snippet: IfcRoad + IfcAlignment + IfcLinearPositioningElement */
/* Illustrative extract; GUIDs shortened for readability */
 
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('IFC 4.3 Infrastructure Example'),'2;1');
FILE_NAME('road_alignment_example.ifc','2026-06-03T09:00:00',
  ('BIM Mobius'),(''),
  'IfcOpenShell 0.8','','');
FILE_SCHEMA(('IFC4X3_ADD2'));
ENDSEC;
 
DATA;
 
/* Project context */
#1 = IFCPROJECT('3mFne2$vT6GxyzAB001',#2,'A23 Road Widening',
  $,$,$,$,(#20),#30);
#2 = IFCOWNERHISTORY(#3,#4,$,.ADDED.,$,$,$,1717401600);
#3 = IFCPERSONANDORGANIZATION(#5,#6,$);
#4 = IFCAPPLICATION(#6,'2026','Civil Design Suite','CDS2026');
#5 = IFCPERSON($,'Engineer','J.',$,$,$,$,$);
#6 = IFCORGANIZATION($,'BIM Mobius',$,$,$);
 
/* Unit assignments */
#20 = IFCUNITASSIGNMENT((#21,#22,#23));
#21 = IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#22 = IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#23 = IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
 
/* Coordinate reference system - projected CRS */
#30 = IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,1.E-05,#31,$);
#31 = IFCAXIS2PLACEMENT3D(#32,$,$);
#32 = IFCCARTESIANPOINT((0.,0.,0.));
#33 = IFCPROJECTEDCRS('EPSG:27700','OSGB 1936 / British National Grid',
  $,$,$,$,#34);
#34 = IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#35 = IFCMAPCONVERSION(#30,#33,385422.70,6141088.30,45.20,
  0.99999820,0.00000000,$,1.0);
 
/* Site */
#40 = IFCSITE('3mFne2$vT6GxyzAB002',$,'A23 Project Site',
  $,$,#41,$,$,.ELEMENT.,$,$,$,$,$);
#41 = IFCAXIS2PLACEMENT3D(#42,$,$);
#42 = IFCCARTESIANPOINT((0.,0.,0.));
#43 = IFCRELAGGREGATES('3mFne2$vT6GxyzAB003',$,$,$,#1,(#40));
 
/* IfcRoad - the primary infrastructure facility */
#50 = IFCROAD('3mFne2$vT6GxyzAB004',$,'A23 Northbound Widening',
  $,'Road',#51,$,.ELEMENT.,.USERDEFINED.);
#51 = IFCAXIS2PLACEMENT3D(#52,$,$);
#52 = IFCCARTESIANPOINT((0.,0.,0.));
#53 = IFCRELAGGREGATES('3mFne2$vT6GxyzAB005',$,$,$,#40,(#50));
 
/* IfcAlignment - the primary linear positioning element */
#60 = IFCALIGNMENT('3mFne2$vT6GxyzAB006',$,'A23 Centreline',
  $,'Alignment',#61,$,$);
#61 = IFCAXIS2PLACEMENT3D(#62,$,$);
#62 = IFCCARTESIANPOINT((0.,0.,0.));
 
/* IfcAlignmentHorizontal with two segments:
   LINE from 0+000 to 0+450, then CIRCULARARC to 0+750 */
#70 = IFCALIGNMENTHORIZONTAL('3mFne2$vT6GxyzAB007',$,
  'Horizontal Layout',$,$,#61,$,$);
#71 = IFCRELNESTSALIGNMENT($,$,$,$,#60,(#70));
 
/* Horizontal segment 1: Straight */
#80 = IFCALIGNMENTSEGMENT('3mFne2$vT6GxyzAB008',$,
  'HS-001',$,$,$,$,#81);
#81 = IFCALIGNMENTHORIZONTALSEGMENT($,$,
  #82,0.,0.,450.,.LINE.,$,$);
#82 = IFCCARTESIANPOINT((0.,0.));
 
/* Horizontal segment 2: Right-hand circular arc, R=800m */
#90 = IFCALIGNMENTSEGMENT('3mFne2$vT6GxyzAB009',$,
  'HS-002',$,$,$,$,#91);
#91 = IFCALIGNMENTHORIZONTALSEGMENT($,$,
  #92,0.,0.,300.,.CIRCULARARC.,800.,0);
#92 = IFCCARTESIANPOINT((450.,0.));
 
/* IfcReferent - chainage station marker at 0+500 */
#100 = IFCREFERENT('3mFne2$vT6GxyzAB010',$,'Station 0+500',
  $,'ChainageMarker',#101,.STATION.,$);
#101 = IFCLINEARPLACEMENT(#60,#102,$);
#102 = IFCDISTANCEEXPRESSION(500.,$,$,$,$);
#103 = IFCRELNESTS('3mFne2$vT6GxyzAB011',$,$,$,#60,(#100));
 
/* IfcRoadPart - lateral zone: carriageway */
#110 = IFCROADPART('3mFne2$vT6GxyzAB012',$,'Carriageway - Northbound',
  $,'RoadPart',#111,$,.ELEMENT.,.CARRIAGEWAY.,$);
#111 = IFCLINEARPLACEMENT(#60,#112,$);
#112 = IFCDISTANCEEXPRESSION(0.,$,$,$,$);
#113 = IFCRELAGGREGATES('3mFne2$vT6GxyzAB013',$,$,$,#50,(#110));
 
ENDSEC;
END-ISO-10303-21;

4. Practical Adoption

4.1 The Current Landscape: Partial and Uneven

The honest picture of IFC 4.3 tool adoption in mid-2026 is: several authoring tools have introduced IFC 4.3 export for infrastructure, but coverage is partial, round-trip capability is limited, and no single tool exports the full schema breadth that IFC 4.3 makes possible. Receiving-side support — viewers, validators, and data management platforms — lags behind authoring, though the gap is closing.

The structural cause of this lag is familiar to anyone who has tracked IFC adoption: there are no ratified Model View Definitions (MVDs) for IFC 4.3 infrastructure workflows yet. An MVD is the formal specification that defines which schema subsets a software tool must support for certification against a particular exchange use case. Without MVDs, vendors implement what their customers request, in the order their customers request it. The result is fragmented support across tools and versions.

The aIFC4Rail project (Applying IFC 4.3 for Rail), led by buildingSMART's Railway Room with participation from SBB, CRBIM, Trafikverket, FTIA, MINnD, SNCF, and RFI, is currently working to develop formal requirements and test cases for rail-specific IFC 4.3 usage — a process that should eventually produce the MVDs that enable certification. Similar work is needed for road, bridge, and marine domains.

4.2 Autodesk Civil 3D

Autodesk's approach has been to deliver IFC 4.3 infrastructure support through a downloadable extension rather than embedding it in the core product. The IFC 4.3 Extension for Civil 3D 2025 (and earlier versions back to 2022) is available through Autodesk Access. It is not loaded by default.

Once installed, the extension adds IFCINFRA-prefixed commands to the Civil 3D command line and dedicated buttons in the Add-ins ribbon tab. The current extension (Update 1 for the 2025 product) supports:

• Export of corridors and alignments to IfcRoad and IfcAlignment entities
• Export of alignments to tessellated polyline approximation (for downstream tools that cannot process analytical geometry)
• Export of station labels to IfcReferent
• Export of alignment section / sample lines
• 3D representation of alignments using IfcGradientCurve

There are notable gaps. The default export format is the ISO version of IFC4x3_ADD2. The extension does not yet support export of bridge geometry to IfcBridge or of rail cant geometry. Round-trip capability is explicitly documented as not providing 100% fidelity — Civil 3D objects exported to IFC 4.3 cannot all be reimported to recover the original Civil 3D model. The extension treats IFC 4.3 export as a one-way handover format, not a round-trip exchange.

A known limitation worth calling out specifically: it is not possible to export 3D solid objects to the IfcRoad or IfcAlignment categories using Civil 3D. 3D solids, when included, are created under IfcBuildingElementProxy — the old workaround persists for solid geometry even inside the new extension.

4.3 Bentley OpenRoads Designer

Bentley's OpenRoads Designer has long been a primary tool for road infrastructure design, and Bentley has been an active participant in buildingSMART's infrastructure standards work. The IFC export capability in OpenRoads has evolved across product versions.

The 2025 release of OpenRoads Designer promoted the IFC Export tool from technology preview status to general availability — a significant maturity milestone. The tool exports corridor geometry and alignment data to IFC format, and Bentley's documentation covers two primary export paths: "Export Corridor to IFC" (for mesh-based corridor elements) and "Export to IFC" (for a broader range of elements).

The critical constraint in mid-2026 is that OpenRoads Designer's IFC alignment export has historically targeted IFC 4.1 alignment semantics rather than the updated IFC 4.3 alignment model. A feature request for full IFC 4.3 alignment support (IFC4x3_ADD2) has been raised in Bentley's OpenCivil Ideas Portal and is under active development. This matters because IFC 4.1 and IFC 4.3 alignment representations are not identical — a receiver expecting IFC 4.3 alignment segments may not correctly parse IFC 4.1 alignment structures.

Bentley has published an IFC Recap document for the US Transportation Industry that acknowledges recent IFC developments and outlines the vendor's implementation roadmap. Infrastructure practitioners using OpenRoads should verify the specific schema version their export produces before issuing files to counterparties expecting IFC 4.3.

4.4 Allplan Engineering (Nemetschek)

Allplan, now marketed under the Allplan Engineering brand as part of the Nemetschek Group, has made IFC 4.3 infrastructure export a prominent feature across the 2024 and 2025 product generations.

Allplan 2024 introduced parametric road intersection modelling (T and X types) with IFC 4.3 export. Allplan 2025 extended this to include export of 3D intersection objects in IFC 4.3 format, covering the substructure geometry and isoline representations. Allplan Civil — the bridge and infrastructure engineering component of the platform — supports IFC 4.3 alignment export for bridge BIM models, a capability that contributed to a US market pilot under the FHWA's TPF-5 programme.

Allplan's documentation claims full support for openBIM standard IFC 4.3, with automatic updating of IFC objects and attributes when geometry changes. For road design specifically, this means corridor objects modelled parametrically in Allplan are coupled to their IFC 4.3 representations — a change to the road cross-section template propagates through to the exported IFC file without requiring a manual re-export workflow.

The areas of strongest Allplan IFC 4.3 support are road intersections, bridge decks, and linear infrastructure elements. Signalling, drainage systems, and electrification are less thoroughly covered.

4.5 Trimble Novapoint

Trimble's Novapoint has been identified in buildingSMART case studies as an authoring tool capable of generating IFC 4.3 road models. A published case study demonstrates a road model with a typical cross-section running through embankment and cut areas, with pavement structures, shoulders, and ditches, all exported using Novapoint to IFC 4.3 format using the full spatial breakdown: IfcProject → IfcSite → IfcRoad → IfcRoadPart (longitudinal and lateral) → physical elements.

Novapoint's strength in this context is its native understanding of road cross-section templates and corridor modelling conventions. The alignment-to-IFC mapping is more complete than in general-purpose BIM tools because the authoring software was built around the alignment concept from the start.

4.6 Bentley ProjectWise and the CDE Landscape

On the Common Data Environment and design review side, Bentley's ProjectWise (now part of Bentley Infrastructure Cloud, powered by iTwin) supports collaboration on IFC files alongside its native DGN-based formats. It provides multi-discipline web-based design review capabilities and supports IFC as a contractual deliverable format alongside PDFs and native CAD files.

ProjectWise's IFC support is format-version-agnostic at the file management level — it can ingest and version-control any IFC file regardless of schema version. Discipline-specific model checking within the platform depends on the underlying analysis tools configured for a project.

Catenda Hub (formerly Bimsync) and other cloud CDE platforms have been quicker to add IFC 4.3 specific parsing capabilities, including property set browsing for infrastructure entity types. If you are choosing a CDE for an infrastructure project, verify whether the platform can resolve IfcRoad and IfcAlignment entities in its property browser — several platforms still list them as unrecognised entities in their UI.

4.7 Validation Tools

Solibri. Version 24.5.0 introduced initial IFC 4.3 support, explicitly characterised by Solibri as "initial support" — meaning the schema is recognised and basic model import works, but not all features of IFC 4.3 may behave correctly. Infrastructure-specific rule sets for IFC 4.3 are still emerging. The buildingSMART IDS (Information Delivery Specification) format is supported in recent Solibri versions, which provides a path to contract-level validation of infrastructure data requirements.

FZKViewer. The FZKViewer from the Karlsruhe Institute of Technology (KIT) has long been used by IFC experts as a neutral schema-level viewer. FZKViewer version 5.3 introduced support for the IFC4X3 schema. It is particularly useful for diagnosing schema-level problems — incorrect entity types, missing required attributes, broken relationships — that a geometry-focused viewer would not expose. FZKViewer is freeware (not open source) and requires no installation; download and run. For infrastructure practitioners validating IFC 4.3 exports, FZKViewer should be in the standard QA toolkit.

IfcOpenShell + Python. For automated validation and data extraction, IfcOpenShell provides complete parsing support for IFC4x3_ADD2. The library's alignment API (ifcopenshell.api.alignment) includes functions for creating and reading alignment geometry, converting station values to distances along curves, and retrieving specific layout types (horizontal, vertical, cant). The following example demonstrates parsing an IFC 4.3 file to extract road and alignment entities:

"""
Parse IFC 4.3 infrastructure file and extract road + alignment data.
Requires: pip install ifcopenshell
Compatible with: IFC4x3_ADD2 schema
"""
import ifcopenshell
import ifcopenshell.util.element
 
 
def extract_infrastructure_summary(ifc_path: str) -> dict:
    """
    Extract roads, alignments, and referents from an IFC 4.3 file.
    Returns a structured summary suitable for QA reporting.
    """
    model = ifcopenshell.open(ifc_path)
 
    # Verify schema version
    schema = model.schema
    if "IFC4X3" not in schema.upper():
        print(f"Warning: expected IFC4X3, got {schema}")
 
    summary = {
        "schema": schema,
        "roads": [],
        "railways": [],
        "bridges": [],
        "marine_facilities": [],
        "alignments": [],
        "referents": [],
    }
 
    # Extract IfcRoad entities
    for road in model.by_type("IfcRoad"):
        road_data = {
            "guid": road.GlobalId,
            "name": road.Name,
            "predefined_type": road.PredefinedType,
            "long_name": road.LongName,
            "parts": [],
        }
        # Collect IfcRoadPart children
        for rel in road.IsDecomposedBy:
            for part in rel.RelatedObjects:
                if part.is_a("IfcRoadPart"):
                    road_data["parts"].append({
                        "name": part.Name,
                        "usage_type": getattr(part, "UsageType", None),
                    })
        summary["roads"].append(road_data)
 
    # Extract IfcRailway entities
    for railway in model.by_type("IfcRailway"):
        summary["railways"].append({
            "guid": railway.GlobalId,
            "name": railway.Name,
            "predefined_type": getattr(railway, "PredefinedType", None),
        })
 
    # Extract IfcBridge entities
    for bridge in model.by_type("IfcBridge"):
        summary["bridges"].append({
            "guid": bridge.GlobalId,
            "name": bridge.Name,
            "predefined_type": getattr(bridge, "PredefinedType", None),
        })
 
    # Extract IfcMarineFacility entities
    for marine in model.by_type("IfcMarineFacility"):
        summary["marine_facilities"].append({
            "guid": marine.GlobalId,
            "name": marine.Name,
            "predefined_type": getattr(marine, "PredefinedType", None),
        })
 
    # Extract IfcAlignment entities with segment counts
    for alignment in model.by_type("IfcAlignment"):
        alignment_data = {
            "guid": alignment.GlobalId,
            "name": alignment.Name,
            "horizontal_segments": 0,
            "vertical_segments": 0,
            "cant_segments": 0,
            "referents": [],
        }
 
        for rel in alignment.IsNestedBy:
            for child in rel.RelatedObjects:
                if child.is_a("IfcAlignmentHorizontal"):
                    for seg_rel in child.IsNestedBy:
                        alignment_data["horizontal_segments"] += len(
                            seg_rel.RelatedObjects
                        )
                elif child.is_a("IfcAlignmentVertical"):
                    for seg_rel in child.IsNestedBy:
                        alignment_data["vertical_segments"] += len(
                            seg_rel.RelatedObjects
                        )
                elif child.is_a("IfcAlignmentCant"):
                    for seg_rel in child.IsNestedBy:
                        alignment_data["cant_segments"] += len(
                            seg_rel.RelatedObjects
                        )
                elif child.is_a("IfcReferent"):
                    alignment_data["referents"].append(child.Name)
 
        summary["alignments"].append(alignment_data)
 
    # Standalone referents (not nested in alignments — flag as potential issue)
    for referent in model.by_type("IfcReferent"):
        summary["referents"].append({
            "guid": referent.GlobalId,
            "name": referent.Name,
            "predefined_type": getattr(referent, "PredefinedType", None),
        })
 
    return summary
 
 
def check_proxy_abuse(ifc_path: str) -> list[dict]:
    """
    Flag IfcBuildingElementProxy instances — likely a sign of incomplete
    IFC 4.3 migration. Returns list of suspect proxies with names and types.
    """
    model = ifcopenshell.open(ifc_path)
    proxies = []
 
    for proxy in model.by_type("IfcBuildingElementProxy"):
        psets = ifcopenshell.util.element.get_psets(proxy)
        proxies.append({
            "guid": proxy.GlobalId,
            "name": proxy.Name,
            "object_type": proxy.ObjectType,
            "has_custom_pset": len(psets) > 0,
            "pset_names": list(psets.keys()),
        })
 
    if proxies:
        print(f"Warning: {len(proxies)} IfcBuildingElementProxy found.")
        print("These may represent infrastructure elements not yet mapped to IFC 4.3 entities.")
 
    return proxies
 
 
if __name__ == "__main__":
    import json
    import sys
 
    if len(sys.argv) < 2:
        print("Usage: python parse_infra_ifc.py <path_to_ifc_file>")
        sys.exit(1)
 
    path = sys.argv[1]
    summary = extract_infrastructure_summary(path)
    print(json.dumps(summary, indent=2))
 
    proxies = check_proxy_abuse(path)
    if proxies:
        print(f"\nProxy audit: {len(proxies)} proxy elements found.")

4.8 Workflow Patterns for Mixed Building and Infrastructure Federations

Most real projects are not purely infrastructure or purely buildings — they are both. A hospital campus has a road access junction and a service yard. A railway station has a concourse building and a track alignment. A university is a collection of buildings connected by landscaped paths and an internal road network. Federating IFC models that span both schema contexts is where many of the practical difficulties arise.

The key structural point: in IFC 4.3, buildings and infrastructure facilities coexist under the same IfcSite parent. An IfcSite can contain both IfcBuilding and IfcRoad instances as direct children through IfcRelAggregates. There is no schema-level barrier to federation.

The practical barrier is coordinate alignment. Infrastructure models are typically authored in a national coordinate reference system (e.g., OSGB 1936 / British National Grid, EPSG:27700). Building models are typically authored in a local coordinate system, with the building origin set to a convenient point on the site. Federating these requires that both models correctly declare their coordinate reference system using IfcProjectedCRS and IfcMapConversion — and that the receiving platform resolves these declarations rather than treating all models as sharing the same local origin.

Step 1: Confirm CRS declarations in both model types

Before federating, open each IFC file in a text editor or FZKViewer and confirm that IfcProjectedCRS and IfcMapConversion are present and correctly populated. A building model missing IfcMapConversion will land at coordinate origin, not at its correct location on the site.

Step 2: Establish a shared alignment reference

Even if the project has no road infrastructure, establishing a shared IfcAlignment for any linear feature (the primary site access road, the building setback line, the service corridor) gives all disciplines a shared spatial reference that linear referencing can attach to.

Step 3: Manage IfcRoad vs IfcBuilding spatial containment

Elements should be contained in the most specific applicable spatial structure. Road furniture (signs, barriers) should be contained in IfcRoadPart. Building elements should be contained in IfcBuildingStorey. Avoid placing elements directly in IfcSite unless no more specific container applies.

Step 4: Validate the federated model at entity level

Do not rely on visual federation inspection alone. Use IfcOpenShell or FZKViewer to confirm that infrastructure entities (IfcRoad, IfcAlignment, IfcReferent) are present and correctly related in the federated file, not flattened to IfcBuildingElementProxy by a federation tool that does not understand IFC 4.3.

Step 5: Define schema version contract per model

Federated models may come from tools exporting different IFC versions. Document explicitly in the BEP which schema version each discipline model targets. Do not assume all IFC files in a federation are the same version — a federation tool that expects IFC 4.3 may behave incorrectly when processing an IFC 2x3 building model.

4.9 Export-Import Round-Trip Behaviour

Practitioners attempting round-trip exchange — export from Tool A, import back into Tool A, or export from Tool A and import into Tool B — will encounter gaps. This is not unique to IFC 4.3, but the infrastructure extensions introduce new categories of round-trip loss:

Alignment geometry. IfcCurveSegment with analytical curve types (clothoids, cubic spirals) may be tessellated by receiving tools that support IFC 4.3 geometry but have not implemented the exact analytical curve solver. The tessellated output is geometrically close but not identical to the original, and the analytical parameters are lost on import.

Linear placement. Tools that cannot resolve IfcLinearPlacement against the referenced alignment curve will either skip linearly-placed elements or fall back to a Cartesian representation. The parametric relationship between element position and alignment is destroyed.

Property sets. Domain property sets (Pset_KerbCommon, Pset_RoadPartCommon, etc.) are schema-defined in IFC 4.3, but authoring tools may not read them back as native properties. They appear in the file correctly, but the receiving application may not map them to editable fields.

Spatial decomposition. IfcRoadPart with UsageType attributes may be collapsed to generic spatial containers by receiving tools that implement only the core IfcFacility hierarchy without the road domain extensions.

The pragmatic approach is to treat IFC 4.3 infrastructure exports as one-way handover files for coordination, checking, and asset management use. Bidirectional exchange of live design data remains a native format capability in most toolchains.

4.10 Sample IDS for Road Infrastructure

An Information Delivery Specification (IDS) is a machine-readable XML file that defines what information a model must contain to meet a specific exchange requirement. The following sample IDS excerpt demonstrates requirements for a basic IFC 4.3 road infrastructure handover:

<?xml version="1.0" encoding="UTF-8"?>
<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
         xmlns:xs="http://www.w3.org/2001/XMLSchema"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://standards.buildingsmart.org/IDS
           http://standards.buildingsmart.org/IDS/1.0/ids.xsd">
 
  <ids:info>
    <ids:title>Road Infrastructure Handover - Stage 3 Design</ids:title>
    <ids:copyright>BIM Mobius</ids:copyright>
    <ids:version>1.0.0</ids:version>
    <ids:description>
      Minimum information requirements for IFC 4.3 road infrastructure
      handover to highway authority asset register. Applies to:
      IfcRoad, IfcRoadPart, IfcAlignment, IfcKerb, IfcCourse.
    </ids:description>
    <ids:date>2026-06-03</ids:date>
    <ids:milestone>Stage 3 Design Handover</ids:milestone>
  </ids:info>
 
  <ids:specifications>
 
    {/* All IfcRoad instances must have a Name and LongName */}
    <ids:specification name="Road facility naming"
                       ifcVersion="IFC4X3_ADD2"
                       minOccurs="1">
      <ids:applicability>
        <ids:entity>
          <ids:name><ids:simpleValue>IFCROAD</ids:simpleValue></ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:attribute>
          <ids:name><ids:simpleValue>Name</ids:simpleValue></ids:name>
        </ids:attribute>
        <ids:attribute>
          <ids:name><ids:simpleValue>LongName</ids:simpleValue></ids:name>
        </ids:attribute>
      </ids:requirements>
    </ids:specification>
 
    {/* All IfcAlignment instances must have horizontal and vertical layouts */}
    <ids:specification name="Alignment completeness"
                       ifcVersion="IFC4X3_ADD2"
                       minOccurs="1">
      <ids:applicability>
        <ids:entity>
          <ids:name><ids:simpleValue>IFCALIGNMENT</ids:simpleValue></ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:attribute>
          <ids:name><ids:simpleValue>Name</ids:simpleValue></ids:name>
        </ids:attribute>
      </ids:requirements>
    </ids:specification>
 
    {/* IfcRoadPart must declare UsageType */}
    <ids:specification name="Road part usage classification"
                       ifcVersion="IFC4X3_ADD2"
                       minOccurs="1">
      <ids:applicability>
        <ids:entity>
          <ids:name><ids:simpleValue>IFCROADPART</ids:simpleValue></ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:attribute>
          <ids:name><ids:simpleValue>PredefinedType</ids:simpleValue></ids:name>
        </ids:attribute>
      </ids:requirements>
    </ids:specification>
 
    {/* Kerb elements must have Pset_KerbCommon populated */}
    <ids:specification name="Kerb asset data"
                       ifcVersion="IFC4X3_ADD2"
                       minOccurs="0">
      <ids:applicability>
        <ids:entity>
          <ids:name><ids:simpleValue>IFCKERB</ids:simpleValue></ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:property dataType="IFCLABEL">
          <ids:propertySet>
            <ids:simpleValue>Pset_KerbCommon</ids:simpleValue>
          </ids:propertySet>
          <ids:baseName>
            <ids:simpleValue>KerbHeight</ids:simpleValue>
          </ids:baseName>
        </ids:property>
        <ids:property dataType="IFCLABEL">
          <ids:propertySet>
            <ids:simpleValue>Pset_KerbCommon</ids:simpleValue>
          </ids:propertySet>
          <ids:baseName>
            <ids:simpleValue>Material</ids:simpleValue>
          </ids:baseName>
        </ids:property>
      </ids:requirements>
    </ids:specification>
 
    {/* Pavement courses must identify their layer type */}
    <ids:specification name="Pavement layer typing"
                       ifcVersion="IFC4X3_ADD2"
                       minOccurs="0">
      <ids:applicability>
        <ids:entity>
          <ids:name><ids:simpleValue>IFCCOURSE</ids:simpleValue></ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:attribute>
          <ids:name><ids:simpleValue>PredefinedType</ids:simpleValue></ids:name>
          <ids:value>
            <ids:restriction base="xs:string">
              <ids:enumeration value="PAVEMENT"/>
              <ids:enumeration value="BALLASTBED"/>
              <ids:enumeration value="FILTER"/>
              <ids:enumeration value="CORE"/>
              <ids:enumeration value="USERDEFINED"/>
            </ids:restriction>
          </ids:value>
        </ids:attribute>
      </ids:requirements>
    </ids:specification>
 
    {/* No IfcBuildingElementProxy should be present in infrastructure model */}
    <ids:specification name="No proxy abuse"
                       ifcVersion="IFC4X3_ADD2"
                       minOccurs="0"
                       maxOccurs="0">
      <ids:applicability>
        <ids:entity>
          <ids:name>
            <ids:simpleValue>IFCBUILDINGELEMENTPROXY</ids:simpleValue>
          </ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        {/* Zero occurrences required: any proxy found is a failure */}
      </ids:requirements>
    </ids:specification>
 
  </ids:specifications>
</ids:ids>

5. Anti-Patterns

Understanding IFC 4.3 is as much about knowing what not to do as what to do. The following anti-patterns are endemic among teams transitioning from building BIM workflows to infrastructure, and each one has a specific consequence that will surface downstream.

5.1 Exporting Infrastructure as IfcBuildingElementProxy

What it looks like. The IFC file opens in Solibri and everything renders. But the entity browser shows 847 instances of IfcBuildingElementProxy. The name attributes carry values like "ROAD_SURFACE_AC14", "DRAIN_CH340", "RETAINING_WALL_TYPE_A" — domain meaning encoded in text strings that no tool can parse automatically.

Why it happens. The authoring software's IFC export does not support IFC 4.3 infrastructure entities, or the operator has not installed/activated the infrastructure export extension. The software silently maps all civil elements to proxy because that is the only entity type it knows how to write.

The consequence. The downstream tool — whether it is a clash detection platform, an asset management system, or a cost estimation tool — cannot distinguish a road surface from a retaining wall from a drainage channel. Every automated process that relies on entity type classification fails. Manual workarounds add days of effort on every downstream deliverable. The asset register cannot be populated automatically. The file fails any IDS validation that prohibits proxies.

The fix. Verify your authoring tool has IFC 4.3 infrastructure export capability and that the correct export mode is activated. If your tool does not support IFC 4.3 entity mapping for a particular element category, document this as a known gap in the BEP and flag it in the file's accompanying data validation report. Do not issue a proxy-laden file as if it were a compliant IFC 4.3 export.

5.2 Ignoring Linear Referencing

What it looks like. The IFC file contains an IfcAlignment and correctly structured IfcRoad and IfcRoadPart entities. But all physical elements — the kerbs, the traffic signs, the drainage outlets — are placed using IfcLocalPlacement with Cartesian coordinates. The IfcReferent entities that should mark chainage stations are absent.

Why it happens. The authoring tool supports enough IFC 4.3 to produce the spatial hierarchy but does not implement IfcLinearPlacement or IfcReferent. The operator may not know these entities exist, or may have assumed that Cartesian placement is equivalent.

The consequence. Asset management systems that query elements by chainage cannot locate elements. When the alignment is revised — as it will be on any live infrastructure project — elements placed by Cartesian coordinates do not update. The relationship between the design alignment and the physical elements is broken at the data level, even though it is visually intact in a viewer. Traffic management plans, maintenance orders, and inspections that reference locations by chainage cannot be automatically linked to model elements.

The fix. Confirm with your authoring tool vendor whether IfcLinearPlacement and IfcReferent are supported. If they are, mandate their use in the BEP for all elements that should be referenced by chainage. If they are not, this is a schema compliance gap that should be documented — not silently worked around with Cartesian placement.

5.3 Treating IFC 4.3 as Backward-Compatible with IFC 4

What it looks like. A project team issues IFC 4.3 files to a counterparty using a CDE or validation tool that was configured for IFC 4. The files are accepted without complaint. Later, it becomes apparent that the IFC 4.3-specific entities (IfcRoad, IfcAlignment, IfcReferent) were silently ignored by the receiving system, which only parsed the IFC 4-compatible elements it recognised.

Why it happens. The IFC 4.3 schema is approximately 98% backward-compatible with IFC 4 — meaning most IFC 4 entities are still valid in IFC 4.3, and an IFC 4.3 file can be opened by a tool expecting IFC 4 without throwing a parse error. But the new IFC 4.3 entities are simply unrecognised by the older tool. The receiving system does not crash; it just silently drops the infrastructure-specific content.

The consequence. The issuing team believes they have delivered an IFC 4.3 infrastructure model. The receiving team believes they have received an IFC model. But the spatial hierarchy, alignment, and linear referencing data that distinguish an IFC 4.3 infrastructure model from a generic proxy soup have not been transmitted. The model is functionally equivalent to an IFC 4 file with proxies — which is what the proxy era looked like.

The fix. Confirm, explicitly and in writing, that the receiving tool version supports IFC4X3_ADD2 schema parsing. Do not infer this from the tool being labelled "IFC 4.3 compliant" — check the specific version and the specific entity types supported. Run the received model through FZKViewer or IfcOpenShell and confirm that infrastructure entities are present after round-trip.

5.4 Omitting the Coordinate Reference System Declaration

What it looks like. The IFC 4.3 file contains a well-structured IfcRoad and IfcAlignment, but has no IfcProjectedCRS or IfcMapConversion. The model appears correct in isolation. When federated with building models, the infrastructure and building geometries either coincide at an arbitrary point or are wildly offset from each other.

Why it happens. The authoring tool exports infrastructure geometry without a CRS declaration, or the operator has not configured the survey coordinate system correctly before export.

The consequence. Every federated model review is unreliable. Clash detection across the building/infrastructure boundary produces incorrect results. GIS integration fails because the model cannot be positioned on a map without manual coordinate offsets. The problem is invisible in single-model reviews.

The fix. Declare IfcProjectedCRS and IfcMapConversion in every IFC file, for every discipline. Make CRS declaration a mandatory check in your IFC export audit process, verified before the file leaves your organisation.

5.5 Conflating IfcRailway with IfcRoad for Mixed Rail/Road Infrastructure

What it looks like. A tram project has embedded tracks in shared road surfaces. The modeller maps the entire shared corridor as a single IfcRoad because the geometry looks like a road, then places tram track elements inside it.

Why it happens. The spatial structure distinction between IfcRailway and IfcRoad is schema-level, and it is not always obvious which should be the parent facility when the physical asset overlaps both domains.

The consequence. Rail asset management systems that query by IfcRailway spatial containment do not find the tram track elements. Road authority queries for carriageway condition do not get the correct spatial extent because the carriageway includes tram track zones that should be in a different ownership and maintenance regime.

The fix. For genuinely mixed rail/road corridors, model two overlapping spatial structures — an IfcRailway and an IfcRoad — each containing the elements in their respective jurisdictions. Use IfcSpatialZone for the shared physical space. This is more work but produces a file that downstream asset management systems can correctly partition.

6. Case Studies

The following are composite case studies based on the documented experience of the infrastructure BIM community. Names and specific project details are representative rather than from individual disclosed projects.

6.1 Hospital Campus with Road Access Junction

Context. A new regional hospital is being delivered under a D&B contract. The scope includes the hospital building (12 storeys, 45,000 m²), a car park structure (3 levels), landscaping, and a new at-grade signalised junction connecting the campus to the adjacent classified road. The employer specifies openBIM and IFC for all handover deliverables.

The challenge. The building models come from Revit (architecture, structure, MEP). The junction design comes from Civil 3D. The car park superstructure comes from Tekla. Three tools, three IFC versions being targeted (IFC 2x3 from legacy Revit export, IFC 4 from Tekla, IFC 4.3 from the Civil 3D extension). The federated review platform is a cloud CDE with stated IFC 4.3 support.

What went wrong initially. The Civil 3D export activated the IFC 4.3 extension correctly and produced a file with IfcRoad, IfcAlignment, and IfcRoadPart entities for the junction approach roads. But the junction itself — the intersection geometry, the kerb lines, the signal pole bases — was exported as IfcBuildingElementProxy because the 3D solid geometry of the junction box could not be mapped to an IFC 4.3 entity by the extension (see the Civil 3D 3D solid limitation noted above). The CDE's federated view showed the junction geometry, but the entity browser labelled it as "Building Element Proxy" and property inspection produced no domain data.

Resolution. The BIM coordinator ran the IfcOpenShell proxy audit script and identified 134 proxy elements in the junction model. The Civil 3D team re-examined their modelling approach: the junction geometry was re-created as surfaces and corridor elements (rather than 3D solids) that the IFC 4.3 extension could correctly map. The kerb lines were exported as IfcKerb elements. Signal pole bases were exported as IfcFooting (a standard structural entity). Pavement layers were exported as IfcCourse with PredefinedType=PAVEMENT.

The remaining proxy count after remediation: 12 elements, all documented as intentional (temporary works elements with no IFC 4.3 equivalent). These were accepted by the employer with a written explanation.

Lesson. Mixed building and infrastructure federations need an explicit entity mapping table produced before any export is attempted — which IFC entity will carry each Civil 3D object type, and which Civil 3D object types have no IFC 4.3 equivalent. The table forces early discovery of gaps and prevents late-project surprises.

6.2 Urban Light Rail Extension

Context. A 6.2 km urban light rail extension includes 4 km of street-running embedded track, 2 km of viaduct through a constrained urban corridor, a new depot facility, and two interchange stations with existing heavy rail. The project is procured under an ECI contract. The rail authority mandates ISO 19650-compliant information management and openBIM handover.

The IFC strategy. The project team defines two top-level facility types in the IFC model: IfcRailway for the rail corridor and track infrastructure, and IfcBuilding for each station building and the depot. The viaduct is modelled as IfcBridge, decomposed into IfcBridgePart elements for the superstructure (deck and beams), substructure (piers and abutments), and foundations (piles).

The alignment model is central to the coordination strategy. A single IfcAlignment for the route centreline is established, with the horizontal layout carrying the complex urban geometry (multiple short transitions, sharp curves through heritage areas) and the vertical layout carrying the gradient profile. IfcReferent entities mark every 50 m chainage station, every platform start/end point, and every structure interface.

Track elements — rails, sleepers, switch machines, overhead line supports — are positioned using IfcLinearPlacement, so every element in the track design carries a chainage reference that the rail authority's asset management system can query directly without coordinate transformation.

The cant geometry challenge. The street-running section includes curves requiring cant. The rail design software (a specialist railway design tool with IFC 4.3 export capability) generates IfcAlignmentCant geometry for these sections. The structural analysis tool for the viaduct does not understand IfcAlignmentCant and reads the imported alignment without cant. The viaduct team manually applies the cant rotation to their cross-section template. This is documented as a known workflow gap in the project's BEP — a manual step that removes the parametric cant relationship between rail design and structural design.

Station building interface. At interchange stations, the station building (IfcBuilding) and the rail platform (part of IfcRailway) share a physical boundary. The interface is managed using IfcSpatialZone for the shared concourse area, with elements assigned to either the building or railway spatial structure based on which discipline owns them, and the concourse zone used for spatial checking of interface clearances.

Result. The IFC 4.3 model federation enabled automated clash checking across structure, track, and overhead electrification using Solibri's IFC 4.3 import. Infrastructure-specific rule sets had to be written manually (no standard rulesets for IFC 4.3 rail elements existed in Solibri at project commencement). The chainage-based referencing enabled the rail authority's asset management team to link maintenance procedures to model elements during the design phase — a capability that had not been achievable on the authority's previous projects.

6.3 Container Port Terminal Expansion

Context. An existing container terminal is expanding with two new berths, 400 m of new quay wall, a deepened navigation channel, a paved stacking area, and a new gate complex. The port authority operates an integrated asset management system and wants BIM-to-asset-register integration from the outset.

Infrastructure entity mapping.

The marine domain gap. IfcMarineFacility with PredefinedType=QUAY provides the high-level container, and Pset_QuayCommon / Pset_QuayDesignCriteria property sets carry design data such as design vessel class, fender design load, and deck live load. However, the IFC 4.3 marine domain does not yet include dedicated entities for subsurface dredge geometry, floating dock units, or underwater inspection data. These elements were handled using IfcGeotechnicalAssembly for the dredge prism and IfcBuildingElementProxy for floating dock components, with documented schema gaps in the BEP.

Asset management integration. The port authority's asset management system was updated to parse IfcMarineFacility and associated property sets directly. Mooring bollards modelled as IfcMooringDevice with Pset_MooringDeviceCommon populated were linked to maintenance inspection intervals in the asset register without manual data entry — the first time the authority had achieved direct BIM-to-CMMS linkage on a capital project. The time saving in asset register population was estimated at approximately 120 hours compared with the previous manual process on a comparable berth extension.

7. Limits and Caveats

7.1 Adoption Remains Uneven

The publication of ISO 16739-1:2024 does not mean that IFC 4.3 is usable on every infrastructure project today. It means the standard exists. The gap between standard existence and widespread, reliable tool support is measured in years on every previous IFC version, and IFC 4.3 is no different.

As of mid-2026, the honest summary is:

• Road design. IFC 4.3 road export is available in several mainstream tools (Civil 3D with extension, Allplan, Trimble Novapoint) but with tool-specific gaps and no full round-trip capability.
• Rail design. IFC 4.3 rail export — including cant geometry — is available in specialist rail design tools but not yet in general-purpose civil tools. The aIFC4Rail project is developing the MVDs and test cases that will drive vendor implementation.
• Bridge design. IFC 4.3 bridge export is available in bridge-specific tools (Allplan Civil, some Bentley products) but coverage of the full IfcBridge decomposition hierarchy is partial.
• Marine/port. The marine domain is the least mature for tool support. IfcMarineFacility and its subtypes are present in the schema; software implementations are sparse.

7.2 Tunnels Are Not in IFC 4.3

IfcTunnel does not exist in IFC 4.3. The tunnel domain was explicitly deferred to a planned IFC 4.4 extension. As of mid-2026, IFC 4.4 has not been published. Tunnel modellers must continue using IfcBuiltElement subtypes and proxy workarounds for tunnel-specific elements. This is the most significant functional gap in IFC 4.3 for infrastructure practitioners, given that tunnels are among the most complex and high-value infrastructure assets.

7.3 MVDs Are Not Yet Ratified for Infrastructure

No buildingSMART-certified Model View Definition exists for IFC 4.3 infrastructure exchange as of mid-2026. This means there is no formal certification baseline against which tool vendors can demonstrate compliance. The three implementation levels defined in the IFC 4.3 validation work (Reference View, Alignment Based Reference View, Design Transfer View) provide a framework, but they have not been formalised as certifiable MVDs. Without MVDs, "IFC 4.3 support" means different things in different tools, and procurement specifications that mandate "IFC 4.3 compliance" have no technically binding definition to enforce.

7.4 IDS Profiles for Infrastructure Are Emerging

The buildingSMART IDS standard provides the mechanism for encoding project-specific information requirements in a machine-readable format. Infrastructure-specific IDS templates and profiles are under development but are not yet widely available as ready-to-use, community-validated resources. Teams must currently write their own IDS files — as illustrated in Section 4.10 — without the benefit of community-agreed baseline specifications.

7.5 Geotechnical Coverage Is Partial

IfcGeotechnicalStratum and IfcGeotechnicalAssembly represent a first step toward incorporating ground model data in IFC, but the coverage is limited. Borehole logs, lab test results, ground investigation reports, and probabilistic ground models are not representable in IFC 4.3. Integration between IFC infrastructure models and geotechnical data formats (AGS, gINT) remains a file-transfer problem solved outside the IFC standard.

8. Sources and Further Reading

The following sources were consulted in the preparation of this article and are recommended for practitioners who want to go deeper.

Primary standards and schema documentation

1. ISO 16739-1:2024 — Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — Part 1: Data schema. The definitive standard document. iso.org/standard/84123.html

2. buildingSMART IFC 4.3.2.0 HTML Documentation — Complete schema reference for all IFC 4.3 entities including IfcRoad, IfcBridge, IfcRailway, IfcMarineFacility, IfcAlignment, IfcReferent, IfcLinearPositioningElement. standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/

3. IFC 4.3 Formally Approved and Published as ISO Standard — buildingSMART International announcement, April 2024. buildingsmart.org/ifc-4-3-formally-approved-and-published-as-an-iso-standard/

4. IFC Release Notes — buildingSMART Technical: full version history from IFC 2x through 4.3. technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ifc-release-notes/

Practitioner resources

5. All You Need to Know About IFC 4.3 for Infrastructure — BIM Corner: practical breakdown of spatial structure, alignment model, and physical elements with diagrams. bimcorner.com/ifc-4-3-for-infrastructure/

6. IFC 4.3 in Road Projects — Case Study — BIM Corner: step-by-step modelling walkthrough using Trimble Novapoint. bimcorner.com/ifc-4-3-for-roads-case-study/

7. Key Changes in IFC Schema Shaping OpenBIM for Infrastructure — BIM Corner: summary of the seven major schema changes including CRS, TIN, alignment, and spatial organisation. bimcorner.com/key-changes-in-ifc-schema-shaping-openbim-for-infrastructure/

8. IFC for Infrastructure — AEC Magazine: history, limitations of earlier IFC versions, IFC 4.3 additions, and early software adoption status. aecmag.com/collaboration/ifc-for-infrastructure/

Tool-specific documentation

9. Autodesk IFC Manual — Civil 3D IFC 4.3 Support — Autodesk: extension installation, commands, and known limitations. autodesk.ifc-manual.com/civil3d/ifc-4.3-support

10. Adopting IFC 4.3 for Infrastructure Projects — Trimble: workflow benefits, entity overview, adoption strategy. trimble.com/blog/construction/en-US/article/adopting-ifc-4-3-for-infrastructure-projects

11. Paving the Way for Advanced Infrastructure Delivery with ALLPLAN 2024 — Allplan: road intersection, IFC 4.3 export, bridge capabilities. allplan.com/blog/paving-the-way-for-advanced-infrastructure-delivery-with-allplan-2024

Standards and frameworks

12. Applying IFC 4.3 for Rail Project (aIFC4Rail) — buildingSMART International: project goals, participating organisations (SBB, CRBIM, Trafikverket, FTIA, MINnD, SNCF, RFI), work packages, and business cases. buildingsmart.org/standards/domains/railway/applying-ifc-4-3-for-rail-project/

13. IDS — Information Delivery Specification — buildingSMART Technical: standard for machine-readable exchange requirement definition. technical.buildingsmart.org/projects/information-delivery-specification-ids/

14. IfcOpenShell Alignment API Documentation — Reference for the alignment API used in the Python examples in this article. docs.ifcopenshell.org/autoapi/ifcopenshell/api/alignment/index.html

15. The Status of IFC 4.3 and the Benefit of Further Extensions as IFC 4.4 — buildingSMART: roadmap including tunnel domain and IFC 5 foundations. buildingsmart.org/the-status-of-ifc-4-3-and-the-benefit-of-further-extensions-as-ifc-4-4/

16. Solibri IFC Standards Support Documentation — Version 24.5.0 IFC 4.3 initial support details. help.solibri.com/hc/en-us/articles/23779405208855-IFC-Standards-Supported-by-Solibri