The LiDAR deliverable lands at the civil engineering team. The point cloud opens, the DTM imports, the contours render. Then the engineering team quietly spends two weeks rebuilding the surface in Civil 3D because the TIN they received doesn't carry the breaklines they need, the contours weren't generated with their interval, and the surface model wasn't structured for the design workflow they actually run. The rebuild is invisible to the survey team and pure cost to the design team. Avoiding it is mostly briefing.
If you've ever received a clean LiDAR deliverable, watched the civil engineering team accept it without complaint, and then noticed two weeks later that they're working off a surface they re-built in-house from the point cloud, you've met the design-handoff problem. The deliverable wasn't wrong. It just wasn't useful enough to skip the rebuild step. The engineering team absorbed the cost quietly and moved on; nobody fed the lesson back to the survey team; the next project produces the same deliverable and the same rebuild.
The civil engineering workflow has different format expectations, different surface conventions and different fidelity requirements than the GIS workflow covered in the earlier GIS-handoff article. A deliverable optimised for GIS ingestion isn't automatically optimised for civil design ingestion; treating both consumers as if they want the same thing is the structural cause of the rebuild.
This article is the civil-engineering counterpart. What Civil 3D / OpenRoads / 12d Model / MAGNET teams actually want, the surface decisions that matter, the breakline conventions, and the briefing pattern that prevents the silent rebuild.
Most civil engineering work in Australia runs through one of four platforms. Each consumes LiDAR-derived deliverables slightly differently.
The dominant platform in Australian civil consultancies for road, subdivision, drainage and earthworks design. Native surface format is the Civil 3D TIN surface, constructed from points, breaklines and boundaries. Civil 3D can ingest:
The Civil 3D team's preferred deliverable is a LandXML surface plus the source point cloud. The LandXML is the design surface; the point cloud is the reference for spot-check verification.
Common in transport authority and large infrastructure work. Native surface is the Digital Terrain Model (DTM) in Bentley's i-Model format, with TIN structure similar to Civil 3D but different metadata conventions. Consumes:
Bentley teams prefer LandXML + LAS/LAZ combination, with the LandXML being the engineering surface and the LAS the QA reference.
Specialist civil platform with significant Australian market share, particularly in earthworks and drainage design. Native surface is the 12d TIN, with strong breakline handling and the most demanding fidelity expectations of the four platforms. Consumes:
12d Model teams prefer LandXML with explicit breakline attribution (Type = Continuous Break or Type = Standard Break flagged at string level) so the TIN reconstruction in 12d respects the breakline semantics.
Used in some survey-consulting firms and increasingly in transport projects. Native surface is the MAGNET TIN. Consumes LandXML, DXF, LAS/LAZ.
MAGNET teams have generally similar requirements to Civil 3D teams but with stronger preference for survey-grade fidelity in breakline definition.
The TIN (Triangulated Irregular Network) surface is the fundamental data structure for civil design work. It's not just a DEM raster — it's:
The civil design tools all build TIN surfaces from this data structure. The key insight: breaklines change surface geometry. The TIN built from points alone is different from the TIN built from the same points plus breaklines along ridges, top-of-bank features and structure edges.
A LiDAR deliverable that includes the point cloud and a GeoTIFF DEM but no breaklines has supplied the data; the engineering team has to build the TIN themselves, including manually digitising or extracting the breaklines from the point cloud.
A LiDAR deliverable that includes a LandXML TIN with properly-attributed breaklines is supplying the design surface directly — substantial work already done.
Six categories of breakline civil engineering teams need on a typical deliverable:
1. Top and bottom of bank. For streams, drains, batters and any feature where the slope changes discontinuously. Without these breaklines, the TIN smooths over the discontinuity and the design surface shows a sloped transition where reality has a step.
2. Top and bottom of kerb. For road corridors and urban environments. Critical for stormwater modelling and pavement design — the kerb is a real flow-control feature that needs to be present in the surface, not averaged into the road camber.
3. Edge of pavement / shoulder. Where the sealed surface transitions to gravel or grass. Different roughness, different hydraulics, different earthworks implications.
4. Crest and toe of batter. For embankments and cuttings. Defines where the slope starts and stops; the TIN without these breaklines treats batters as continuous slopes rather than constrained surfaces.
5. Building footprints. Where buildings sit on the surface. Civil 3D and 12d both handle building voids in the TIN if the boundary is supplied; without it, buildings show as conical artefacts of triangulated ground returns.
6. Hard hydro-enforcement features. Bridges, weirs, culverts, low-level crossings. The bare-earth DTM should reflect the hydraulically-significant features not the bridge deck. Without explicit hydro- enforcement, flood modelling and drainage design produce wrong answers.
The deliverable that includes these six breakline categories is ready for design. The deliverable that includes none of them is raw material requiring 1-3 weeks of in-house surface preparation.
(See LAS / LAZ article for the underlying point format details.)
Most engineering deliverables include contours derived from the DTM. Three things to specify:
1. Interval. 0.25 m or 0.5 m for engineering design (roads, drainage, earthworks); 1.0 m or 2.0 m for planning-grade work. The contour interval should match the DTM resolution and the accuracy spec — generating 0.1 m contours from a 50 mm RMSE DTM is asking the contours to claim more than the underlying data supports.
2. Index interval and labelling. Every 1.0 m or 2.0 m contour bolded and labelled; intermediate contours unlabelled. Mathematical convention but worth specifying in the brief.
3. Smoothing. Civil 3D and 12d Model both apply smoothing to contours derived from TIN surfaces. The smoothing parameter affects how the contour reads — heavy smoothing produces flowing lines that may not honour ridge features; no smoothing produces angular contours that follow triangle edges literally.
The right smoothing is usually moderate (Civil 3D's default tension settings work for most engineering purposes); worth confirming what the engineering team expects rather than defaulting.
Civil engineering teams operate in MGA or local site grid coordinates more frequently than GIS teams do. Three coordinate considerations:
1. Site grid vs MGA. Many road and infrastructure projects work in a project-specific site grid (rotated or translated MGA). The deliverable should be in either the site grid (if applicable) or MGA, with explicit declaration. Worst case: deliverable in geographic coordinates (lat/lon) when the design tool expects projected coordinates.
2. Vertical datum. AHD is the engineering default; ellipsoidal heights are sometimes delivered without flagging and create systematic 20-30 m offsets when the design team assumes AHD. Match what the design specification requires.
3. Coordinate precision. Engineering tools work in metres to millimetre precision. Deliverables in geographic coordinates (degrees) or in coordinate systems requiring on-the-fly transformation can lose precision in the round-trip. Project-coordinates from processing through delivery preserve fidelity.
(See AHD / GDA2020 article for the datum specifics.)
The deliverable manifest for civil engineering use is narrower than the GIS-team version but more specific:
Surface specification:
Contour specification:
Hydro-enforcement scope:
Accuracy summary:
Source provenance:
The civil engineering team usually doesn't need the full GIS manifest content; what they need is the surface-specific information above, presented in a way that lets the design tool import the surface without further preparation.
Five things to specify in the brief between survey and civil design team before capture, not at delivery:
1. The design platform and version. Civil 3D 2024, OpenRoads Designer 2023, 12d Model 15.5. Each has specific import expectations.
2. The required surface deliverables. TIN in specific format, contour interval, hydro-enforcement scope, breakline categories.
3. The site coordinate system. Site grid (with definition) or MGA Zone NN; AHD vertical.
4. The downstream design intent. Road alignment design vs subdivision drainage vs major earthworks vs flood modelling. Each implies different breakline priorities and surface fidelity expectations.
5. The validation surface. What independent control / checkpoint information the engineering team will use to validate the deliverable before adopting it for design.
Five emails before capture saves the rebuild after delivery.
Three patterns we see when survey-to-design handoff fails:
Treating LandXML as a checkbox. "LandXML included" on the deliverable list isn't enough. LandXML with TIN + breaklines + boundary + attribution is different from LandXML with TIN-only. Specify the contents.
Defaulting to the survey team's surface conventions instead of the design team's. Different categories of operator have different defaults. The brief should specify the design team's preferences explicitly.
Skipping the hydro-enforcement conversation. Most problematic for projects involving drainage or flood modelling. The bare-earth DTM "as captured" produces wrong answers at structures; the design team needs explicit enforcement, not assumption.
Civil engineering teams using Civil 3D, OpenRoads, 12d Model and MAGNET have different deliverable expectations than GIS teams. The deliverable optimised for GIS ingestion isn't automatically right for civil design; treating both consumers as if they want the same thing generates a silent in-house rebuild.
Preferred format combinations:
The TIN surface — points + edges + breaklines + boundary — is the fundamental design data structure. Breaklines change surface geometry; supplying them or not is the make-or-break for deliverable usability.
Six breakline categories matter on a typical project: top/bottom of bank, top/bottom of kerb, edge of pavement, crest/toe of batter, building footprints, hard hydro-enforcement features.
Contour spec needs interval, index interval and smoothing parameter explicit. Coordinate system needs site grid vs MGA confirmation, AHD vertical, project- coordinates throughout for precision.
Five-thing briefing pattern (platform + surface deliverables + coordinate system + design intent + validation surface) prevents the rebuild. Three common mistakes (LandXML as checkbox, default conventions, skipped hydro-enforcement) cause it.
If you're scoping a project where the deliverable lands at a Civil 3D, OpenRoads, 12d Model or MAGNET workflow, we'll structure the surface, breakline scope and format choice in conversation with the design team rather than to a generic default. The pre-capture conversation saves the post-delivery rebuild; happy to include the design lead in the scoping call.
The GIS-team companion to this civil-design piece. Same handoff problem, different consuming workflow — useful pairing to understand why one deliverable rarely fits both teams.
How the source LAS becomes the design-ready surface — the processing steps where breaklines, hydro-enforcement and TIN structure are decided.