BIM for Infrastructure Projects: Coordinating Buildings with Civil Works

Why your building BIM instincts do not transfer

Sooner or later a building BIM professional gets handed something that is not a building. A station box with 400 metres of track approaching it. A hospital campus with a new access road, a retaining wall, and a drainage network. A factory where the process building is the easy part and the yard, hardstanding, and utility corridors carry the risk.

The natural instinct is to treat this as a bigger version of what you already do. Model the thing, link the models, run Navisworks, issue the clash report. That instinct is wrong in a specific and expensive way, and it usually fails in the first week, at the moment the civil model lands in your federation and appears somewhere over the horizon.

Infrastructure BIM is not building BIM at a larger scale. It uses different geometry, a different coordinate philosophy, a different information framework, and until recently it had no shared open format worth the name. This guide covers what a building-side BIM professional needs to understand to work credibly across that boundary. It is deliberately written from the building side looking out. You do not need to become a highway designer. You do need to stop being the person who breaks the federated model.

Alignments, corridors, and geometry that has no storey

Building models are organised by level. Almost everything you do in Revit assumes it: view ranges, schedules, floor plans, workset strategy, the whole documentation model. Infrastructure has no levels. It has alignment and chainage.

An alignment is a horizontal path through the site, defined as a sequence of tangents, curves, and transition spirals. Pair it with a vertical profile and you have the three dimensional spine of a road, a rail track, a pipeline, or a channel. Position along that spine is expressed as chainage (called stationing in North America), a distance measured along the alignment rather than an X and Y pair. When a civil engineer says the culvert is at 2+340, they mean 2,340 metres along the alignment, and that single number is more useful on their project than a coordinate pair would be.

Geometry is then generated from the alignment. A corridor model in Civil 3D or OpenRoads is not modelled element by element. You define an assembly, which is the cross section of the road with its lanes, kerbs, verges, and side slopes. That assembly is applied along the alignment at intervals, targeting surfaces and feature lines, and the software generates the solid. Change the alignment or the profile and the entire corridor regenerates.

Three consequences matter to you:

• The civil model is parametric in a way yours is not. A small alignment change regenerates kilometres of geometry. Do not assume the geometry you clashed against last week is still there.
• Solids are often derived, not authored. Corridor solids are an extraction step. If the civil team has not run that extraction, the exported model may contain surfaces and linework but no solids to clash against.
• Surfaces are the real deliverable. Existing ground, formation level, and finished surface are TIN meshes, and much of the coordination question is about levels where your building meets their surface, not about objects intersecting.

Revit can hold its own topography (Toposolid in current releases replaced the older Toposurface) but it is not the authoring environment for earthworks, and pretending otherwise is how teams end up with two conflicting ground surfaces.

The coordinate problem that ruins most first attempts

This is the single biggest technical failure point, and it is worth understanding properly rather than treating as a settings checkbox.

Building models are usually modelled near the origin, with the internal origin, project base point, and survey point clustered close together. Civil models are modelled in a projected coordinate reference system, which means real world coordinates in the tens or hundreds of thousands, sometimes millions. British National Grid, UTM zones, State Plane, and Gauss-Kruger all produce numbers like 528340.221, 181250.885.

Hand a Revit model a coordinate like that carelessly and one of two things happens. Either everything is placed enormously far from the internal origin, or the model refuses outright. Revit has a hard tolerance of roughly 20 miles (about 32 kilometres) between geometry and the internal origin, and, more importantly, precision degrades long before you reach that limit. Snapping goes strange, joins fail, and elements drift by millimetres that were not in your model when you drew them.

The correct approach is to keep the building model near its own internal origin and use shared coordinates to express the relationship to the real world. In practice:

1. Get the survey control from the civil or survey team as a written document, not a verbal statement. It should give you the coordinate reference system, at least two control points with easting, northing, and level, and the direction of grid north.
2. Establish a project base point for the building at a sensible local origin, typically a grid intersection you can point to on a drawing.
3. Set the survey point to the real world coordinate of that known location, so the model knows where it sits on the earth without being modelled there.
4. Publish or acquire coordinates through one nominated host model rather than letting every discipline set its own. One model is the coordinate authority. Everyone else inherits.
5. Record the whole arrangement in the BIM Execution Plan, including the datum for levels, which is a separate question from the horizontal system and is missed constantly.

If Revit’s three positioning concepts are still fuzzy, our older primer on Revit coordinate system types covers internal origin, project base point, and survey point before you add a projected system on top.

Grid distance, ground distance, and the scale factor trap

Here is the detail that catches experienced building modellers, because nothing in building work prepares you for it.

A projected coordinate system flattens a curved earth onto a plane. That projection distorts distance. The distance between two points measured on the grid is not the distance a surveyor measures on the ground, and the ratio between them is the combined scale factor, which folds together the projection scale factor and the height above the reference ellipsoid.

The difference is small in percentage terms and large in absolute terms. A factor of 0.9996 sounds like nothing until you apply it across a two kilometre alignment and find yourself 800 millimetres out. On a building footprint the error is negligible. Across a site with a road, a bridge, and a station box, it is the difference between structures meeting and structures missing.

You are not being asked to compute this. You are being asked to know it exists, ask the survey team which convention the project is using, and make sure your model is not silently mixing a ground-distance building with a grid-distance civil model. Ask the question early. The answer belongs in the BEP alongside the coordinate reference system.

What IFC 4.3 added, and what it did not

Until recently, openBIM had a genuine hole. IFC was built around buildings, and it had no proper way to describe an alignment. Infrastructure exchange therefore ran on proprietary formats, LandXML, and a great deal of goodwill.

IFC 4.3 closed that gap, and it has since been published as an ISO standard (ISO 16739-1:2024). The additions that matter:

• IfcAlignment, a first class horizontal and vertical alignment, so the spine of a linear asset survives the exchange.
• Linear placement, which positions an element by chainage and offset from an alignment rather than by an absolute coordinate. This is how infrastructure actually thinks about location.
• New facility entities covering road, rail, bridge, and marine works, plus the parts that hang off them, so a culvert or a bearing is no longer forced into a building classification that never fitted.
• Better geo-referencing, so the coordinate reference system travels with the file instead of living in an email.

What it did not do is make everything work overnight. Tooling maturity is uneven and moves release by release. Some authoring tools export 4.3 well, some export it partially, and some viewers happily open the file while quietly ignoring the alignment. Do not write “IFC 4.3” into an information delivery agreement without testing the specific round trip on the specific versions the project will use. Export a sample, open it in the receiving tool, and confirm that the alignment, the geo-referencing, and the solids all survived. This is the same discipline described in our guide to Information Delivery Specifications, applied to a format that is still bedding in.

Exchange formats you will actually use

Real projects run on a mix. Here is what each format is good for and where it hurts.

Format	Carries well	Main weakness
IFC 4.3	Alignments, linear placement, geo-referencing, road and rail entities, properties	Tooling support is uneven, so test the round trip before committing
LandXML	Alignments, profiles, surfaces, parcels, points	No solids, no properties, geometry only, but universally supported
Navisworks (NWC and NWD)	Federated geometry from almost anything, review data, clash results	Review format, not an authoring or handover format
DWG	Linework, 2D deliverables, some 3D solids	No structured object data, easy to misuse as a model exchange
RVT and DWG linked into Revit	Direct reference into the authoring environment	Ties you to one vendor, and heavy civil models degrade Revit performance
Point cloud (RCP and E57)	Existing conditions with high fidelity	Large, and not a model, see our scan to BIM workflow guide

A practical pattern that works on most jobs: LandXML for surfaces and alignments into the building environment, IFC or NWC for federated review, and native formats only inside a discipline.

Setting up the federated model

Federation across building and civil scope needs one rule stated up front: nobody links a heavy civil model directly into a building authoring model unless they have a reason. Corridor exports and existing ground surfaces are enormous. Linking them into Revit for convenience is how a 400 megabyte model becomes a 2 gigabyte model that nobody can open. The general link hygiene in our guide to working with linked Revit models applies with more force here.

A workable setup:

1. Federate in a review environment, not in an authoring one. Navisworks, Solibri, or the cloud model coordination in Autodesk Construction Cloud all handle mixed geometry better than Revit does.
2. Link only what you need into authoring models. Usually that is the finished ground surface at the building interface and the alignment centreline, not the full corridor.
3. Agree a clipped interface zone. Define a boundary box around the building and its immediate context. Civil issues a cut down model for that zone. This one decision solves most performance problems.
4. Name and version every container consistently so the federation is reproducible. Infrastructure jobs have more parties and more issue cycles than a typical building job, and the naming discipline in our post on BIM naming conventions and file standards is what keeps it navigable.
5. Fix the exchange cadence. Weekly is normal in design, more frequent near a milestone. Because the corridor regenerates wholesale, a stale civil model is more misleading than a stale building model.

Information requirements on an infrastructure job

ISO 19650 covers infrastructure as well as buildings, so the framework you already know applies. What changes is who sets the requirements and how prescriptive they are.

Infrastructure clients tend to be asset owners with long horizons: national road authorities, rail operators, water utilities, port authorities. They operate the asset for decades, and their information requirements reflect that. Expect a formal asset data specification, mandated classification, and an asset breakdown structure you must model to rather than invent.

Practical differences from a building job:

• Level of information need is often stricter than level of geometry. A drainage manhole may need only crude geometry, but its diameter, invert levels, material, and asset reference are contractual.
• Classification is not optional. Uniclass covers infrastructure directly, and most national frameworks name a system explicitly. Our guide to BIM classification systems covers the mechanics of applying codes.
• Asset handover is rarely plain COBie. Infrastructure owners often run their own asset data template feeding a maintenance system, and it will not look like a building handover.
• Spatial breakdown follows the alignment. Sections, chainage ranges, and structures rather than levels and rooms.

Clash and constructability across the boundary

Clash detection between a building and civil works finds fewer hard geometric hits than an MEP coordination round, and the ones it finds tend to be serious. Watch for these:

• Building substructure against buried services and drainage. Piles, basements, and attenuation tanks against the utility corridor.
• Retaining structures against foundations. Who is holding back the ground, and does the assumed line of the retained face match on both sides?
• Level mismatches at the threshold. Finished floor level against finished road or pavement level, and whether both parties are using the same vertical datum.
• Temporary works and access. Crane positions, site haul routes, and construction sequence conflicts. This is where linking to 4D sequencing pays off, because a road that is fine in the final condition may be unbuildable in the right order.
• Surface conflicts rather than solid conflicts. A building sitting below the finished ground surface will not always report as a clash. Section cuts catch what clash rules miss.

Run rule based checks, but do not trust them alone across this boundary. A scheduled review of sections through the interface zone finds problems that no clash rule was written for. The wider QA discipline in our model quality assurance workflow applies unchanged.

Who owns what

Unclear ownership at the interface causes more rework than any software limitation. Settle these questions in writing at project start:

• Who owns the survey control and the coordinate reference system? Usually the civil or survey lead. One party publishes, everyone else acquires.
• Who owns the ground surface at the building interface? One model holds the authoritative surface. The other references it.
• Who owns the threshold level? Architecture sets finished floor level, civil sets external levels, and someone has to own the joint.
• Who federates? On infrastructure work this is often a dedicated information manager rather than the architectural BIM lead.
• Who checks the exchange? Every civil delivery needs a receiving check for coordinates and geo-referencing before it enters the federation. Five minutes here saves a week later.

If you are weighing whether to move toward this kind of work, it is a genuine specialisation with a shortage of people who can speak both languages. Our BIM career roadmap covers where the coordination and information management roles sit.

Common mistakes

• Modelling the building at real world coordinates. The most common and most damaging error. Use shared coordinates and keep the geometry near its internal origin.
• Accepting survey control verbally. If the coordinate reference system, control points, and vertical datum are not in a document, they are not agreed.
• Ignoring the vertical datum. Horizontal alignment gets all the attention and levels cause the failures. Confirm the datum explicitly.
• Linking the full corridor into Revit. It works for a week, then nobody can open the model. Clip the interface zone.
• Assuming IFC 4.3 support because a version number says so. Test the specific round trip on the specific releases before it goes into an agreement.
• Clashing against a regenerated model. Corridors rebuild wholesale, so an old export can be entirely wrong rather than slightly out of date.
• Treating surfaces as background. The ground surface is a live coordination object, not a picture.
• Applying building LOD thinking. Infrastructure clients often want modest geometry with rigorous data, which is the opposite of the habit most building modellers bring.

How to start

1. Learn to read an alignment and profile drawing. Chainage, tangents, curves, transitions, and vertical curves. You do not need to design one, but you need to follow the conversation.
2. Open a real Civil 3D or OpenRoads model in a viewer and find the alignment, the surfaces, and the corridor. Seeing the structure once removes most of the mystery.
3. Practise the coordinate handshake on a sandbox project. Acquire coordinates from a geo-referenced file, verify a known point, and export back out. Do it until it is boring.
4. Export an IFC 4.3 file from whatever authoring tool you have and open it somewhere else. Note what survived and what did not. That test is the honest measure of the current tooling.
5. Volunteer for the interface on your next mixed project. The building and civil boundary is where the work is, and it is chronically under-owned.
6. Get the underlying model data and coordination skills solid first, because everything above is a specialisation of them rather than a replacement.

Infrastructure BIM is less alien than the vocabulary makes it look. Strip away chainage and corridors and it is the same discipline you already practise: an agreed coordinate framework, a clean federation, explicit information requirements, and someone accountable at every interface. What changes is that the errors scale with the site. A coordinate mistake on a building is annoying. The same mistake across two kilometres of alignment is a claim. If you want to build the Revit and coordination foundations that this work sits on, the courses at Archgyan Academy cover the workflows firms actually run, all in one subscription.