IFC Terrain Export for Coordination Workflows
A terrain model can look correct in the authoring file and still cause coordination problems the moment it enters a federated model. It may arrive kilometres from the building, sit at the wrong elevation, display as an opaque block, or make the coordination viewer unworkably slow. A useful IFC terrain export for coordination is therefore not simply a terrain file saved as IFC. It is a deliberately prepared model that retains its location, communicates the right level of detail, and behaves predictably in the receiving platform.
What the coordination model actually needs
The coordination team rarely needs every surveyed point or every contour break from the source dataset. They need enough terrain information to test interfaces: finished floor levels against existing ground, retaining walls, external access, drainage falls, service routes, road levels and excavation extents.
That changes how terrain should be exported. The goal is not a visually perfect landscape model. The goal is a dependable reference object that can be positioned against architecture, structures and civil information without ambiguity.
An IFC terrain model should answer three questions immediately: where is it, what vertical reference does it use, and how accurate is its geometry intended to be? If those answers are absent, another discipline may make assumptions that are expensive to unwind later.
Prepare terrain before exporting IFC
Start with the source coordinate system, not the modelling software. Confirm the horizontal coordinate reference system, the units, and the vertical datum used by the elevation data. A model in British National Grid with heights relative to Ordnance Datum Newlyn is not interchangeable with a local project grid or arbitrary model elevations. The same principle applies to sites in the United States, Denmark, Norway or elsewhere: horizontal coordinates and height reference must be stated, not inferred.
Next, decide whether the coordination export represents existing terrain, proposed terrain, or both. Keep them as separate, clearly named objects where possible. A receiving team must not mistake a proposed grading surface for surveyed existing ground when checking basement walls, drainage runs or access routes.
Clean the terrain boundary to the area that matters. Including a vast surrounding landscape often adds thousands of faces without improving a design decision. For a building coordination model, extend the terrain far enough to include likely interfaces such as roads, adjacent thresholds, outfalls and retaining conditions. For masterplanning or infrastructure work, the relevant boundary may be wider, but it should still be intentional.
Then reduce the geometry appropriately. Point-cloud-derived terrain can contain more detail than an IFC coordination model needs. Decimation should retain critical breaks in slope, kerb lines, ditches, embankments and drainage routes while removing unnecessary points from broad, consistent areas. A flat field does not require the same density as a steep or heavily engineered edge.
A practical IFC terrain export workflow
1. Establish a shared coordinate strategy
Agree the project coordinate approach before exporting. This may be a georeferenced model using a projected coordinate reference system, or a local coordinate system with a documented relationship to real-world coordinates. Either can work, but the whole team must use the same approach.
For georeferenced IFC, include the projected coordinate reference information and map conversion data when the exporting application supports it. In IFC4 workflows, this provides a clearer route for exchanging real-world placement. In older IFC2x3-based workflows, georeferencing is less consistently handled, so careful use of the project origin, site placement and accompanying coordinate documentation becomes more important.
Avoid placing geometry at extremely large coordinate values if the receiving software is known to have precision limitations. A common solution is to model close to a sensible local origin while retaining a documented transformation to survey coordinates. This is only safe when every discipline applies the same transformation.
2. Choose geometry that survives the receiving system
Triangulated terrain is usually the most dependable geometry for IFC coordination. A triangulated face set represents irregular ground efficiently and maps well to terrain meshes generated in BIM, civil and visual modelling applications.
Exporters vary. One application may write terrain as an IFC4 triangulated face set, while another may create faceted geometry, a generic proxy, or a collection of separate elements. None is automatically wrong, but the receiving coordination platform must be tested. If the terrain is merely visible but cannot be selected, classified or switched off independently, it will be difficult to manage in a live federation.
Use a sensible object name, such as “Existing Terrain - Survey Date” or “Proposed Terrain - Planning Issue”. Place it under the correct site context where the authoring software allows. Add a short description containing the source, coordinate reference, vertical datum and intended use. That information is far more useful than a generic object labelled “Topography”.
3. Keep the file light enough to use
IFC coordination models should open quickly and remain navigable. Excessively dense terrain can dominate file size, slow clash review and obscure building elements. There is no universal triangle count because site area, slope complexity and viewer capability differ, but the principle is consistent: export only the resolution required for the current decision.
For early coordination, a simplified existing-ground surface may be sufficient. Before construction-stage setting-out, drainage or earthworks coordination, provide a more detailed issue where the design team requires it. Treat terrain detail as an information-delivery decision, not a one-off export setting.
Coordinate and elevation checks that prevent false clashes
Before issuing the IFC, check a known point. This might be a survey benchmark, a road centreline spot level, a building grid intersection or a site corner. Compare its easting, northing and elevation in the source data, authoring model and exported IFC. One confirmed point is useful; two or three points at different areas of the site are better.
Do not rely on visual alignment alone. A terrain surface can appear to meet the building in a perspective view while being offset by a metre horizontally or by a datum difference vertically. These errors later appear as false clashes, impossible ramp gradients or unexplained cut-and-fill volumes.
Also check units. An IFC interpreted in millimetres rather than metres can produce a terrain model 1,000 times too large or too small. This is usually obvious, but it wastes coordination time and can be avoided through a quick pre-issue review.
Validate the export in an independent viewer
Open the exported IFC outside the authoring application. This is the fastest way to identify exporter-specific behaviour that the native model hides. Check that the terrain is visible, selectable, named correctly and placed relative to the project model.
Review the following before issue:
- The terrain aligns with agreed building grids, roads or survey control points.
- Existing and proposed surfaces are clearly distinguishable.
- Elevations match known spot levels and the stated vertical datum.
- The file opens at a practical speed and does not overwhelm the federation.
- Object names and classifications make the terrain easy to filter during review.
If the receiving team uses a particular common data environment or coordination viewer, validate in that environment rather than assuming generic IFC compatibility. IFC is an exchange standard, not a guarantee that every application will interpret every geometry type and coordinate method identically.
Generate terrain with export in mind
The best coordination export begins with clean, editable terrain data. Topo-grapher provides XYZ terrain datasets in real-world coordinates from official mapping, LiDAR and photogrammetry sources, allowing teams to create the terrain surface in their preferred BIM or modelling environment before exporting an appropriate IFC issue.
For Revit, keep the Toposolid manageable before export and retain only the points needed for the intended coordination level. In Rhino or Grasshopper, create a controlled mesh rather than passing through an unfiltered high-density surface. In Archicad, verify that the Mesh has the intended site placement before issuing IFC. The same data can support each workflow, but the modelling and export decisions should reflect the receiving team's needs.
A well-prepared terrain IFC should make the next coordination meeting less about locating the model and more about resolving the real site decisions. That is the useful test: if another discipline can trust the ground beneath the building, they can start coordinating the work that depends on it.
