How to specify a LiDAR survey deliverable
Most problems with LiDAR surveys come from a poorly written brief. Here is exactly what to specify — accuracy, format, coordinate system, deliverable — so the data is usable when it arrives.
Most of the problems people have with LiDAR surveys are not problems with the survey. They are problems with the brief. The scanner did its job, the registration is sound, the point cloud is accurate — but the data arrives in a format nobody downstream can open, in a coordinate system that does not match the design, or at a level of detail that is either far more or far less than the project needed. Every one of those failures is avoidable at the point of commissioning. Here is what to specify so the data is usable the day it lands.
Start with what the data is for
Before any technical specification, write down who will use the point cloud and what they will do with it. A façade restoration architect, a structural engineer designing a strengthening scheme, and a BIM coordinator building a federated model all need different things from the same building. The architect needs accurate elevations and surface detail. The engineer needs reliable geometry on specific members. The coordinator needs a registered cloud that imports cleanly into the modelling platform.
If you specify the deliverable without knowing the end use, you are guessing. A surveyor who is told the end use will scope the capture, the registration accuracy, and the deliverable to suit it. State the purpose in plain terms at the top of the brief.
Specify the accuracy you actually need
Accuracy is the field people most often get wrong, usually by asking for more than the project requires. A registered terrestrial scan of a typical building is accurate to within a few millimetres across the capture, and that is sufficient for the large majority of construction uses. Asking for tighter accuracy than that drives up the control effort and the cost without improving the outcome.
What matters more than a headline accuracy figure is being explicit about two things: the registration accuracy (how well the individual scans tie together) and the survey control (how the cloud relates to a known coordinate framework). Tell the surveyor whether the cloud needs to sit on a project grid, on Ordnance Survey National Grid, or simply on a local arbitrary system. If it needs to register to control already established on site, say so and provide the control data.
Name the coordinate system explicitly
A point cloud delivered on the wrong coordinate system is one of the most common and most frustrating brief failures. The cloud is correct in itself, but it does not align with the design model, and somebody downstream spends a day transforming it — or worse, builds on it without noticing the offset.
State the required coordinate system by name. If the project works on a site grid, provide the grid definition and the control points. If it works on National Grid, say which realisation and whether you need true heights. If the design team works in a particular software environment, ask whether the cloud should be delivered already aligned to the project base point. Do not leave this to assumption.
Specify the delivery format
The point cloud is the durable record; the format is how downstream users get at it. The common choices are:
- E57 — open, vendor-neutral, supported by every major platform. The safe default if you are unsure.
- RCP/RCS — directly importable into Autodesk Revit and related products. Specify this if the team works in Revit.
- LAS/LAZ, PTS, PLY — for specialist or large-scale uses.
Ask for the format your software actually reads, not the one that sounds most advanced. If different users need different formats, say so — most surveyors can deliver more than one. Also specify whether you need the cloud unified into a single file or split by scan, by floor, or by zone, as very large clouds can be unwieldy in one piece.
Be explicit about derived deliverables
The point cloud is one thing. Drawings and models derived from it are another, and they are where cost and time accumulate. If you need 2D floor plans, sections, or elevations drawn from the cloud, say which, at what scale, and to what drawing conventions. If you need a Revit model, specify the Level of Development and which elements are in scope — modelling every duct and bracket to a high LOD is a major exercise, and modelling only the structural shell is not.
Be honest about what you need. A common and expensive mistake is to commission a full BIM model when the project only needs the cloud and a handful of elevations.
Confirm scope, access and registration approach
Finally, the brief should pin down the physical scope: which floors, which elevations, internal only or internal and external, and whether hard-to-reach areas such as roof voids or plant rooms are included. Tell the surveyor about access constraints, occupied areas, and working hours, because these shape how the scans are planned and registered.
A short conversation at this stage prevents the survey returning with gaps. It is far cheaper to add an area to the brief than to remobilise a scanner.
A LiDAR survey is only as good as the brief that scoped it. Spend the time to state the purpose, the accuracy, the coordinate system, the formats, and the derived deliverables in writing, and the data will be usable the moment it arrives. Leave any of those to assumption and you are relying on luck.