Reality capture, laser scanning, and scan-to-BIM field guide

Reality capture, and why you build to reality instead of assumptions

Reality capture is the work of recording what is physically on a site as a measurable digital record, not a drawing of what someone intended. The record is a point cloud: millions of 3D points, each one a real measured location on a real surface, captured by a lidar laser scanner firing and timing laser pulses, or built from overlapping photographs through photogrammetry. You can measure off it, model from it, and overlay it on a design. That is the difference between a photo and a scan. A photo shows you the room. A scan lets you measure the room.

The reason it matters comes down to one thing. It captures existing conditions accurately, so the team designs, coordinates, and builds to what is really there instead of to assumptions or a set of drawings that stopped being true years ago. The renovation gets a true starting point. The as-built can be checked against the model. The field deviation gets caught while it is still cheap to fix. On a data center, where the ceiling is packed and the equipment pads have no slack, building to a wrong assumption is how a job stops.

The work splits into a few honest pieces. Plan the scan to the same control the layout and the model use. Capture the cloud. Register the scans into one aligned whole. Then turn that cloud into a usable model or a QA check, with a deliverable accuracy everyone agreed to up front. The coordination side of that model lives in the companion BIM and VDC guide, and the survey control it all hangs from is the same control covered in the construction-layout guide.

Build to reality, not to the drawings

This is the whole point of reality capture, and it is worth saying plainly. The scan records what is actually there, so you build to reality and not to an assumption. Every other benefit follows from that one fact.

Drawings lie in small ways that add up. The original set was an intent, the field changed it during construction, and the record set rarely caught every change. A column is 2 in off where the plan put it. A slab is out of level. A duct main got rerouted and nobody updated the model. Design a tight fit against those drawings and the conflict shows up in the field, where it is expensive, instead of on the screen, where it is free. Scan first and you design against the surface that exists.

The framing the trade uses is verify before you build. On a renovation you capture the messy existing building and design to it. On new work you scan what got installed and check it against the model before the next trade buries it. Either way the scan is the truth source, and the assumption is what you were trying to get rid of. How accurate that truth source is depends on the method, the control, and the deliverable spec, so the rest of this guide is about getting those right.

What is reality capture and what is a point cloud?

Reality capture is the recording of real-world conditions as measurable 3D data. The primary output is the point cloud, and understanding the cloud is understanding the whole discipline. A point cloud is a dataset of millions, often billions, of individual points. Each point has an X, Y, and Z coordinate, usually a color value from a camera, and an intensity value from the return strength of the laser. Together they form a dense, dimensionally accurate shell of every surface the instrument could see.

Two technologies produce it. A lidar laser scanner is active: it fires laser pulses and measures the time or phase of the return to compute a precise distance, millions of times a second, sweeping the room. Photogrammetry is passive: it takes many overlapping photographs and uses structure-from-motion math to reconstruct 3D positions from the parallax between images. Both end in a point cloud. They differ in accuracy, cost, and what they are good at, which the methods section covers.

People call the result a measurable digital twin of what exists, and that phrase is fine as long as you remember what it is and is not. It is an accurate record of visible surfaces at the moment of capture. It is not a smart model with system data attached, and it is not a picture of what is behind the wall. The cloud is the raw measured reality. Turning it into something a designer or estimator can use is the modeling step, and the accuracy of the whole thing is only as good as the instrument spec and the control it was tied to.

The methods: terrestrial, mobile SLAM, photogrammetry, handheld

There is no single best way to capture a site. You pick the method by the accuracy the deliverable needs, the speed the schedule allows, and the kind of space you are in. The tradeoff is almost always accuracy against speed, and the honest move is to match the tool to the use rather than reaching for the same instrument every time.

Terrestrial laser scanning, the tripod scanner, is the high-accuracy choice and the slow one. Mobile SLAM, the walk-through scanner, is fast and lower accuracy. Photogrammetry uses a camera or a drone and is cheaper, with strong color and reach but softer geometry. Handheld scanners sit in between for small spaces and detail work. The accuracy figures below are typical ranges from the field and the manufacturers, quoted to give you the order of magnitude. Always confirm the actual specification for the specific instrument and the registered, real-world accuracy of the finished deliverable, which is usually looser than the raw instrument number.

The terrestrial laser scanner

The terrestrial laser scanner is the tripod-mounted instrument, and it is the gold standard for accuracy. You set it on a stable point, level it, and let it sweep a full dome of the space, capturing a dense scan from that one position before you pick it up and move to the next. Modern units commonly reach single-digit-millimeter accuracy at working ranges, but the figure that matters is the manufacturer's stated accuracy for that model at that distance, not a round number off a spec sheet.

The strength is precision and the cost is time. Each setup is a few minutes of scanning plus the move, the level, and the line-of-sight check, and a building takes many setups. You place targets or rely on overlapping geometry so the setups can be registered together later. This is the instrument you reach for when the deliverable has to hold a tight tolerance: QA against a design model, an as-built that feeds prefab, structural or MEP work where a centimeter of error would put a hanger or a connection in the wrong place.

On a data center the terrestrial scanner earns its slowness in the mechanical and electrical rooms, around the gear pads, and anywhere a prefabricated assembly has to land on existing steel or existing pipe. Those are the places where the difference between 2 mm and 2 cm is the difference between a part that fits and a part that gets cut on site.

Mobile and SLAM scanning

Mobile scanning, usually built on SLAM, trades accuracy for speed. SLAM stands for simultaneous localization and mapping: the scanner figures out where it is by tracking its own motion against the geometry around it while it captures, so you simply walk the space and the cloud builds as you go. There is no tripod and no setup. A walk that takes minutes can cover a floor plate that would take a tripod scanner a full day.

The cost is accuracy. SLAM and handheld mobile units commonly land in the 1 to 5 cm range, and the error can drift over a long walk because each position is referenced to the last rather than to a fixed setup. That is fine for a great deal of work and wrong for some of it. Confirm the accuracy against the manufacturer's spec and against control, and be honest about whether the deliverable can live with centimeter-level error.

The right uses play to the speed. Progress capture, where you scan the floor every week to track install. Large, open areas where the tolerance is loose. A rough as-built for space planning or quantity takeoff. The trap is using a mobile scan for a job that needed a terrestrial one, then discovering at fit-up that the cloud was never tight enough to trust. Match the method to the tolerance the use actually requires.

Photogrammetry from a camera or a drone

Photogrammetry builds a point cloud from photographs instead of laser pulses. You take many overlapping images, and software reconstructs 3D geometry from the differences between them. It is the cheap entry point, since the hardware can be a good camera or a drone rather than a five-figure scanner, and it produces excellent true-color results because the cloud is built from the photos themselves.

Geometry is the weak spot relative to lidar. Photogrammetric accuracy commonly runs in the 5 to 15 mm range for close work, looser for aerial, and it depends heavily on image overlap, lighting, and good ground control. Featureless or reflective surfaces give it trouble, where a laser scanner just measures the distance. Confirm the achievable accuracy against the workflow and the control rather than assuming a single number.

Where photogrammetry shines is the outside and the high. Facades, roofs, and the site around the building are captured fast and in color by a drone, which is exactly the reach a tripod scanner does not have. A common pattern on a real project is the hybrid: drone photogrammetry for the exterior, site, and roof, terrestrial laser scanning for the high-accuracy interior, both tied to the same survey control so the two datasets merge into one coordinate system. The drone side of that capture is its own discipline, covered in the drone and aerial guide; here the point is that the photogrammetric cloud and the lidar cloud have to share control to live together.

The scan plan

A scan is only as complete as the plan behind it, and the failure mode is the area you missed and the trip back to the site to re-shoot it. The scan plan is where you decide setup locations, the overlap between them, the line of sight into every space that matters, the target placement, and the resolution and quality settings for each scan.

Coverage and line of sight drive the setup count. The laser only measures what it can see, so every column shadow, every alcove, every congested pocket behind a duct needs a setup that looks into it or it comes back as a hole in the cloud. Overlap between adjacent setups is what lets them register together later, commonly on the order of 20 to 40 percent of shared geometry for cloud-to-cloud work, more is safer. Targets get placed where multiple scans can see them and where they tie to control.

Resolution is the time lever. A higher point density and quality setting captures finer detail and takes longer per setup, so a whole building scanned at maximum resolution is a budget problem. The skill is scanning the QA-critical and detail areas dense, and the open, loose-tolerance areas coarse, instead of one blanket setting everywhere. Plan it on the drawings before you mobilize, walk it against reality on arrival, and adjust. The plan that survives contact with the actual building is the one that came from someone who walked it.

Why the scan has to tie to the control

This is the accuracy fact that governs everything, so it gets stated hard. The scans must tie to the control, the same surveyed control network the layout and the BIM model are built on. Skip it and the cloud drifts. You get a dataset that is internally pretty and globally wrong, sitting in the wrong place or rotated off the building grid, useless for overlaying on a model that lives on the project coordinate system.

Here is the mechanism. Registration aligns scan to scan, but scan-to-scan alignment only makes the cloud self-consistent. It does not put the cloud in the right place in the world. Tying the scan to surveyed control points, through targets shot by a surveyor or through the same benchmarks layout uses, is what georeferences the cloud onto the project coordinate system. Without that, small registration errors also accumulate across a long building with nothing fixed to pull them back, and the far end of the cloud walks away from reality.

Treat the control as the surveyor's product and your responsibility, exactly as the construction-layout guide describes it. A licensed surveyor establishes and certifies the network. The scan crew ties into it, places targets against it, and confirms the registered cloud holds to it within the spec'd tolerance. A scan with no control is a pretty picture you cannot trust against a model. The required accuracy of that tie is set by the deliverable specification and the project survey requirements, so agree on it before the crew shows up, not after the cloud is delivered.

Registration: stitching the scans into one cloud

Registration is the office step that stitches the individual setups into a single, aligned point cloud. Each terrestrial setup captures the world from its own position. Registration computes how those positions relate and merges them, so a column scanned from four setups becomes one column instead of four ghosts of itself.

Two methods do it. Target-based registration aligns the scans using physical targets, spheres or checkerboards, placed in the overlap and shot by every setup that can see them; done well it commonly aligns adjacent scan pairs to a couple of millimeters. Cloud-to-cloud registration aligns scans by matching their overlapping geometry directly, no targets, which is faster to set up in the field but typically a touch looser and dependent on enough shared, distinctive geometry. Many projects use both: targets where accuracy matters, cloud-to-cloud to fill in.

The number that matters is the registration error, the residual misalignment after the fit, and a real deliverable reports it. A clean registration tied to control is a cloud you can measure against confidently. A loose one, or one that never tied to control, hides error that surfaces later as a part that does not fit. Check the registration report, confirm it meets the spec'd tolerance, and confirm the whole aligned cloud sits on the project coordinate system. The acceptable registration error is set by the deliverable spec and the LOA, not by what the software was willing to accept.

What is scan-to-BIM?

Scan-to-BIM is the process of building a BIM model from the point cloud, an existing-conditions model that represents what is actually there. The cloud by itself is millions of dumb points. Scan-to-BIM is a modeler tracing intelligent objects, walls, columns, pipe, duct, gear, onto that cloud so the result is a usable model that carries data and can be coordinated, not just measured.

It is mostly manual, with automation helping. A modeler works in the cloud, fits geometry to the points, and builds the model element by element. Software increasingly auto-extracts planes, pipe runs, and structure, but a human still checks and finishes it, because the cloud is noisy and real buildings are irregular. How far the modeler takes it is a deliverable decision, set by the level of development for completeness and the level of accuracy for how tightly the model has to match the cloud.

The output feeds straight into coordination. An accurate existing-conditions model is what new design and prefab get coordinated against, which is the subject of the BIM and VDC guide. The two disciplines meet here: reality capture produces the truthful existing model, and coordination uses it to clash the new work against what is genuinely on site. Agree the LOD and LOA of the scan-to-BIM deliverable up front, because a model built tighter than the project needs costs money, and one built looser than it needs fails at fit-up.

As-built verification: did we build it right?

This is the use that pays for the scanner. As-built verification overlays the scan of what got built onto the design model and shows you where the two disagree, while the disagreement is still cheap to fix. You scan the installed work, register it to control, drop it against the coordinated model in the same coordinate system, and the deviation jumps out.

The output most people want is the deviation heat-map: a color map of the scanned surface against the design, green where it matches and red where it has moved, with the magnitude attached. The anchor bolts that landed off the template. The embed that drifted before the pour. The slab that is out of level over the equipment pad. The wall that is bowed where a prefabricated rack was supposed to fit flat. You see it as data, not as an argument, and you see it before the next trade buries it.

That timing is the killer. A deviation caught by a scan after the deck is poured is a coordination problem you solve at a desk. The same deviation caught when the prefab assembly will not land is a stopped crew and a refabrication. Scan the critical work as it goes in, overlay it, and catch the field deviation early. The accuracy of the verification is bounded by the scan accuracy and the control, so a tight QA check needs a terrestrial scan tied hard to control, not a quick walk-through.

What reality capture is actually used for

Reality capture earns its keep across the project, not in one place. The thread through all of it is the same: an accurate record of what exists, used to design, verify, fit, or settle. The table lists the main uses and what the scan delivers for each. On a data center most of these show up on the same job, from the renovation of an existing shell through the QA of the installed mechanical and electrical work.

Renovation and retrofit: capture the existing first

Renovation is where reality capture is least optional. You are working in an existing building, the original drawings are old and were never fully accurate, and the field changed things over decades that nobody recorded. Hand-measuring it is slow and full of holes. A scan captures the messy existing condition accurately in a fraction of the time and lets the designer work against the real geometry.

The value is the surprise you do not get. Design a new mechanical room against a scan and the new equipment fits the real space, the new pipe clears the real existing structure, and the replacement unit lands where the old one was because you measured the actual connections, not the ones on a drawing from 1998. Skip the scan and you find the surprises during construction, one change order at a time.

On a data center retrofit, where new high-density gear is going into an existing shell, the scan of the existing power, cooling, and structure is the foundation the whole design sits on. The deliverable LOA for that scan should match how tight the new work has to fit, which is usually tight, so it is a terrestrial job tied to control, not a quick mobile pass.

QA and QC: flatness, plumb, and the deviation map

Reality capture turns QA from a spot check with a level into a wall-to-wall measurement. Instead of checking a slab for flatness at a handful of points, you scan the whole floor and compute the deviation across every square foot of it. The result is measurable, complete, and hard to argue with.

The common checks are floor flatness and levelness against the design and the spec, wall plumb, and the position of embeds and anchor locations against where the model put them. A raised-floor or equipment-pad area in a data center has tight flatness requirements, and a scan shows the high and low spots as a heat-map before the floor or the gear goes in, while grinding or shimming is still an option. Anchor and embed position the same way: scan, overlay, and find the ones that drifted before the steel or the rack tries to land on them.

Keep the QA accuracy honest. A flatness or position check is only as good as the scan that produced it, so the instrument accuracy and the control tie have to be tighter than the tolerance you are checking against. Checking a 1/8 in flatness spec with a centimeter-accurate mobile scan tells you nothing useful. Match the method and the LOA to the tolerance, and tie it to control, or the heat-map is a colorful guess.

Prefab fit: make sure it fits before it ships

Prefabrication only pays off if the assembly fits when it arrives, and a scan is how you know before it leaves the shop. You scan the existing conditions where the prefabricated piece will land, model the connection points, and confirm the rack, the skid, or the spool will fit the real opening, the real existing pipe, and the real existing steel.

Data centers run on prefab. Mechanical skids, electrical racks, busway, and overhead modules get built off site and craned in, and they have to land on conditions that already exist. If the existing slab is off, the existing structure has moved, or the connecting pipe is not where the drawing said, a 40 ft prefabricated rack becomes an expensive field rework instead of a fast install. The scan checks the fit against measured reality.

This ties straight to coordination. The prefab is detailed off the coordinated model, and the scan confirms the model matched the field before the part is committed to fabrication. The BIM and VDC guide covers the coordination and prefab handoff; the reality-capture job is to make sure the conditions the prefab assumes are the conditions that actually exist. Scan it, overlay it, and fix the fit on the screen, not on the crane.

Level of accuracy (LOA) and what the deliverable promises

LOA, level of accuracy, is the spec that says how accurate the scan and the model actually are, and it is the field that keeps a reality-capture deliverable honest. The U.S. Institute of Building Documentation publishes an LOA specification, with five levels commonly running from LOA 10 to LOA 50 at a 95 percent confidence level, covering a tolerance range on the order of a millimeter up to around 50 mm. The exact level definitions and the current version are set by the published USIBD specification, so cite it rather than a number from memory.

LOA and LOD answer different questions and you need both. LOD, level of development, says how complete and detailed the model is, what is in it. LOA says how correct it is, how tightly the model and the cloud match real-world conditions. A model can be richly detailed and dimensionally wrong, which is exactly the trap LOA exists to close.

The practical move is to agree the LOA to the use before anyone scans. A facility space-planning model does not need the tolerance an MEP fit-up demands, and paying for the tightest LOA everywhere wastes money. Many high-end scan-to-BIM projects settle around a middle level to balance precision and budget, but the right number is the one the use requires, written into the deliverable spec. Match the accuracy to the use, name the standard, and put the agreed LOA in the contract so the deliverable can be measured against something.

The data: file size, processing, and software

Reality capture generates large datasets, and managing them is part of the job, not an afterthought. A building scanned at useful density is gigabytes to tens of gigabytes of point cloud, sometimes more, and that has real consequences for the hardware that processes it, the network that moves it, and the storage that holds it.

Processing turns raw scans into a registered, usable cloud, and it is hardware-hungry. Registration, cleaning, and decimation want a strong workstation and time, and the scan-to-BIM modeling on top of it is its own effort. Plan the processing schedule into the deliverable timeline, because a fast capture followed by a slow office turnaround still arrives late.

The cloud lives in formats the downstream tools read. Point clouds commonly export to formats like .rcp and .rcs for import into a model authoring tool, alongside open and vendor formats for exchange. Cloud-hosted viewers let the field and the office walk the scan in a browser without the full dataset on a laptop, which is how most people actually use the cloud day to day. The deliverable format, the hosting, and who keeps the data long term should be agreed in the scope, because an orphaned cloud nobody can open is a record that quietly stops existing.

The reality-capture workflow, end to end

The sequence is the same whether the job is a renovation scan or a QA check, and following it in order is what keeps the deliverable trustworthy. Skip a step and the error it would have caught shows up later, more expensive.

Plan the scan to the coverage and the use. Set and tie to control, place the targets. Capture the scans, terrestrial where it is tight, mobile or photogrammetry where it can be faster. Register the scans into one cloud and confirm the registration error and the control tie meet the spec. Deliver the cloud, then model it to the agreed LOD and LOA or run the QA overlay against the design. Hand off the deliverable in the agreed format, with the registration and accuracy reported.

The order is not arbitrary. Control before capture, capture before registration, a checked registration before any modeling or QA. The single most common way the whole chain fails is starting the capture before the control is set, then trying to bolt accuracy on afterward. You cannot. The accuracy is built in at the front, at the control and the scan plan, or it is not there at all.

• Plan the scan: coverage, line of sight, overlap, targets, resolution per area.
• Establish and tie to the surveyed control, the same control as layout and BIM.
• Capture: terrestrial for tight tolerance, mobile or photogrammetry for speed and reach.
• Register the scans into one cloud and confirm registration error and control tie meet the spec.
• Deliver the cloud, then model to the agreed LOD and LOA or run the QA overlay.
• Hand off the deliverable format with the accuracy and registration reported.

What reality capture cannot do

Here is the honest part, and it matters more than any feature. The scan captures only the surface it can see. It does not see behind the wall, inside the chase, above the hard ceiling, or under the slab. A point cloud of a finished room is a perfect record of the finishes and nothing about the pipe and conduit buried behind them. If you need what is hidden, you scan before it gets covered, or you do not have it.

The cloud is also a snapshot in time. It is true the day it was captured and slowly stops being true as the building changes, so a scan from last year is a record of last year, not of today. Date every deliverable and re-scan when the conditions that matter have moved.

Two more limits keep crews honest. Registration error is real, and a cloud that did not tie to control drifts, so accuracy is something you verify and report, not something you assume. And garbage in is garbage out: a poorly planned scan with gaps, a loose registration, or the wrong method for the tolerance produces a model that looks convincing and measures wrong. The scan informs the work. It does not replace the field verification, and a model built from a bad scan is more dangerous than no model, because people trust it. Match the method and accuracy to the use, tie it to control, and verify the result against reality.

The people and the value

Reality capture is a skill, not a button. The scan tech plans the coverage, sets and ties the control, runs the instrument, and does the registration, and the quality of those decisions is the quality of the cloud. The modeler does the scan-to-BIM, fitting accurate geometry to a noisy cloud and knowing when the auto-extraction is wrong. A qualified provider owns the accuracy of the deliverable against the spec'd LOA, which is why the scope should name who is responsible for the tie to control and the reported accuracy.

The value is straightforward once you have been burned without it. Accurate existing conditions avoid the rework that comes from building to a wrong assumption. The dispute gets a dated, measurable record instead of two parties arguing from memory. Scanning beats hand-measuring a complex space on both speed and completeness. And the renovation gets designed with confidence instead of a margin for surprises. The cost of the scan is small next to the cost of one prefabricated assembly that did not fit because nobody captured the existing conditions first. That is the trade the budget is really making.

What to document

A scan deliverable that nobody can find, open, or trust later is a record that does not exist. The point of capturing reality is to have it when the question comes up, so the record has to carry enough to be defended and reused. Tie the scan, the control, the registration report, the LOA, and the deliverable together, and keep them where the field and the office can reach them, the same way a field tool like FieldOS keeps the capture attached to the job instead of lost on a hard drive.

Capture what lets a reviewer trust and reproduce the result: the scan date, the method and instrument, the control the scan tied to, the registration error, the agreed and achieved LOA, the deliverable format and where it lives, and who is responsible for the accuracy. If the scan was a QA overlay, record the design model version it was checked against and the deviations found. The table lists the core items.

Common mistakes

• Scanning without tying to surveyed control, so the cloud drifts and cannot be trusted against the model.
• Gaps in coverage from no scan plan, found only when the missed area is needed back at the desk.
• Specifying the wrong level of accuracy for the use, too loose to fit prefab or too tight for the budget.
• Assuming the scan shows what is behind the walls; it captures only the visible surface.
• Accepting a loose registration the software allowed instead of the tolerance the spec required.
• Using a fast mobile or photogrammetry scan for a tight QA or fit-up that needed terrestrial accuracy.
• Capturing a scan and never overlaying it on the model to actually verify the as-built.
• Treating last year's scan as current; the cloud is a snapshot and the building moved.

Field checklist

Standards and references

The accuracy of a reality-capture deliverable is governed by a few things, and naming them correctly is what separates a real spec from a wish. For the deliverable accuracy itself, the U.S. Institute of Building Documentation LOA specification gives the framework, with levels at a stated confidence, and you cite the published edition rather than a remembered number because the version and the level definitions are revised over time.

The instrument accuracy is the manufacturer's, full stop. Each scanner has a published accuracy at range, and the registered, real-world accuracy of the finished cloud is looser than that raw figure, so quote the manufacturer's spec for the instrument and report the achieved registration error separately. The control is the surveyor's product, established and certified to the project survey requirements, the same network the construction-layout and BIM work tie to. For data center work specifically, the dense-MEP and equipment context that makes the scan worth doing connects to the broader datacenter design references like the ASHRAE TC 9.9 thermal guidelines, Uptime Institute Tier requirements, and TIA-942, which the coordination guide carries.

Three things to hold onto. Reality capture lets you build to reality instead of assumptions, which is the entire reason to do it. The scan has to tie to the control or the cloud drifts, and accuracy is built in at the control, not bolted on after. And you match the method and the LOA to the use, then actually verify the as-built against the model, because a scan that never gets overlaid is a cost with no return. Hedge the accuracy, the control, and the LOA to the standard, the manufacturer, and the project specification, and confirm them before the crew mobilizes.

Units and terms

Reality capture borrows terms from surveying, BIM, and lidar, and the same idea shows up under different names across a scope, a manufacturer sheet, and a software menu. The definitions below are the ones that carry the meaning on a jobsite.

Reality capture

Recording real-world conditions as measurable 3D data, the truth source you design and verify against

Point cloud

A dataset of millions of measured 3D points (X, Y, Z, often color and intensity) forming a dimensional shell of every visible surface

Lidar laser scanner

An active instrument that fires laser pulses and times the return to measure precise distances and build a point cloud

Terrestrial vs mobile / SLAM

Terrestrial is the high-accuracy tripod scanner, setup by setup; mobile / SLAM is the fast lower-accuracy walk-through that tracks its own motion

Photogrammetry

Building a point cloud from many overlapping photographs, cheaper and full color, with softer geometry than lidar

Registration

Stitching individual scans into one aligned cloud, target-based or cloud-to-cloud, reported with a registration error

Scan-to-BIM

Modeling the point cloud into an existing-conditions BIM model, mostly manual with automation help

As-built verification

Overlaying the scan of installed work on the design model to find deviation, often as a heat-map

Level of accuracy (LOA)

The spec'd accuracy of the scan and model, per the USIBD specification; LOA says how correct, LOD says how complete

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is BIM coordination?
• What is construction layout?
• Why do you scan concrete before drilling or coring?
• What is grade control in construction?
• What is a laser screed?