Your Road Is Living in a Building Storey

Open an infrastructure IFC file that came back from a client with corrections. Before you look at the geometry, look at the tree on the left.

There is a good chance you will find something like this.

A road, sitting inside a building. Chainage 000-010 m as a storey, like the second floor of an office block. Surface courses exported as IfcSlab, because in this schema there is nothing better to call them.

This is not sloppy modelling. The engineer who produced that file did nothing wrong. The schema simply had nowhere else to put a road.

Why IFC 2x3 does this

IFC 2x3 was published in 2006. It was written for buildings, and for buildings it works well. Infrastructure was not part of the picture, and would not be for another decade.

So when an exporter has to write a road into IFC 2x3, it does the only thing it can. It finds the nearest available container and uses it. A road becomes a building. A section becomes a storey. A pavement course becomes a slab. A kerb, a barrier, a drainage structure - anything without a clear building equivalent - becomes IfcBuildingElementProxy.

The file opens. The geometry looks correct. Coordination meetings run fine, because everyone in the room is looking at the same picture.

The problem appears later, when someone needs the data rather than the picture.

Six things IFC 2x3 cannot say about your road

1. Where the centreline actually goes

IFC 2x3 has no alignment. The centreline that carries your entire design - the geometry every other object is positioned against - is exported as a polyline.

A polyline is a list of points. It draws the right shape and carries nothing else. The lines, arcs, clothoids and parabolas that define the road are approximated away.

IFC 4.3 introduces IfcAlignment, split into three parts: IfcAlignmentHorizontal for the plan, IfcAlignmentVertical for the profile, and IfcAlignmentCant for superelevation on rail. Each segment is described as what it is, with its own parameters.

One rule worth remembering: an alignment must carry at least one IfcReferent. That is the object anchoring your stationing. Without it, chainage is text in a name field, not data.

2. Where anything sits along the route

Follow the previous point to its conclusion. Once the alignment is gone, so is every position defined against it.

Linear referencing is how infrastructure describes location. Not “x, y, z” but “at 2+340, 3.5 m left of centreline”. IFC 2x3 has no concept for it. IFC 4.3 does, and it is what makes machine control, sectional quantity take-off and as-built comparison possible from the model itself.

3. That this is a road at all

The spatial structure of IFC 2x3 knows sites, buildings and storeys. Infrastructure does not decompose that way. A road breaks into segments, roundabouts, intersections, carriageways, shoulders and pavement courses. A railway breaks into tracks, sections and structures.

IFC 4.3 gives each of them a real entity.

Under IfcRoad sit road parts - IfcRoadPart.ROADSEGMENT, IfcRoadPart.ROUNDABOUT and others - and the physical elements are contained inside them. The tree finally matches how the asset is actually built and handed over.

4. What each object really is

This is the quiet one, and in my experience the most damaging.

In IFC 2x3 an object’s meaning usually ends up in its name. Someone types “Stone mastic asphalt (SMA) surface courses” into a text field and the information is technically there - for a human reading a viewer, one object at a time.

IFC 4.3 puts the meaning into the type. IfcCourse.BALLASTBED. IfcSlab.SIDEWALK. IfcSlab.APPROACH_SLAB. IfcEarthworksFill.EMBANKMENT. IfcElementAssembly.ABUTMENT. IfcPile.DRIVEN. IfcRail.RAIL. IfcTrackElement.SLEEPER. IfcWall.PARAPET.

The difference is that a machine can read the second version. You can filter it, count it, validate it against a requirement, and hand it to an asset management system that has never heard of your naming convention.

5. How the geometry should be described

Geometry in IFC is a choice, not a fixed output. IFC 4.3 offers several representations, and they are not interchangeable.

Boundary representation describes every face explicitly. Exact, heavy, and painful when the faces do not close. Swept area solid pushes a profile along a path - light and precise for anything with a constant cross-section. Swept disk solid sweeps a circle along a curve, made for pipes and cables. Sectioned solid horizontal interpolates between cross-sections placed along an alignment. That last one exists specifically for corridors, and it needs an alignment to work - which brings us back to point one.

An 800 MB corridor exported as boundary representation is not a detailed model. It is an export setting nobody changed.

6. Where the model sits in the world

Georeferencing is the quietest failure of all. A model with no coordinate reference system opens perfectly and coordinates perfectly, because everyone shares the same wrong assumption.

Then survey opens it, or someone overlays it on GIS, or it meets the neighbouring contract. IFC has carried projected CRS and map conversion since IFC4. In infrastructure, a model that does not know where it is on earth is not finished.

The point that ties all six together

None of this is visible in the viewer.

Geometry is one layer of an IFC file. Underneath sit the objects, their types, their relationships, their properties and the spatial structure holding them together. That is the part your client’s software reads, your quantity surveyor queries and your asset system inherits.

When a model “looks fine” and still comes back for corrections, the problem is almost always in a layer nobody opened.

Check your own file in ten minutes

You do not need to take my word for it. Open your last delivered IFC in a free viewer and answer five questions.

Five searches, one file. Most people have never looked.

What IFC 4.3 does not fix

Want to see this on a real file?