TL;DR
A point cloud is only as good as its registration — the process of aligning individual scans into one accurate coordinate system. Point cloud services cover the full pipeline between a scanner and a dataset your team can actually trust: capture, registration to survey control at ±5mm, documented QA with reported residuals, cleanup, classification, and delivery in E57, RCP, or LAS. We also register, clean, and rescue point clouds other teams have already captured.
A point cloud is only as good as its registration — the process of aligning individual scans into one accurate coordinate system. Point cloud services cover the full pipeline between a scanner and a dataset your team can actually trust: capture, registration to survey control at ±5mm, documented QA with reported residuals, cleanup, classification, and delivery in E57, RCP, or LAS. We also register, clean, and rescue point clouds other teams have already captured.
When do you need a point cloud instead of a BIM model?
When the question is dimensional, not design-driven. A BIM model exists to design and coordinate new work — walls with properties, systems you can clash-check, elements that carry data. A point cloud exists to *measure what's already there*: verifying a clearance, checking whether equipment fits through an opening, archiving condition, or giving a trade a real dataset to coordinate against without paying for modeling they don't need. See our full breakdown of point cloud vs. BIM model for the complete decision.
Why does registration matter this much?
Registration aligns hundreds of individual scan setups into one coordinate system. Done well, the resulting cloud measures accurately everywhere. Done poorly, it produces a dataset that *looks* fine on screen but is subtly wrong — and every deliverable built on top of it, the Revit model, the floor plans, the clash report, inherits whatever error registration left behind. It's the step in a scanning project that decides whether everything downstream can be trusted.
How do you actually verify a registration is correct?
| Step | What it confirms |
|---|---|
| Scans constrained to surveyed control | The whole dataset ties to a real, external coordinate reference |
| Loop closures verified | Individual scan setups agree with each other where paths overlap |
| Residuals documented and reported | The registration's actual error is stated, not hidden or implied |
| Independent check measurements | The registered cloud is confirmed against physical reality, not just internal consistency |
Our standard for interiors is ±5mm registered accuracy, stated in the deliverable — not implied by a spec sheet.
A real project: 12 buildings, one coordinate frame
A campus documentation program covering 480,000 sq ft across 12 buildings and 18 acres is only useful if every scan lands in one verified coordinate system — otherwise you're doing per-building coordinate gymnastics forever. Control-network registration closed at ±6mm campus-wide, with per-building residuals documented individually. The federated cloud fed Revit, Civil 3D, and facilities workflows from a single frame. (This is the same project covered in our university campus case study — 12 academic buildings captured across 9 field days.)
Can you fix a point cloud someone else already captured?
Yes, and it's a real portion of our work. Firms buy scanners, capture buildings, and then discover that registration, cleanup, and classification are their own separate disciplines from operating the hardware. We register raw datasets to control, rescue misaligned projects where the underlying captures genuinely support it — and are direct when they don't. Some data can't be saved, and finding that out early, before more time is invested, is worth a great deal.
What does cleanup and classification actually add?
Filtering scan artifacts, removing transient objects like people and vehicles, and separating systems into classes (process piping vs. structure vs. utility, for instance) turns a raw capture into a dataset someone can actually work in quickly. Delivered formats follow your pipeline: E57 as the open master, RCP/RCS for Autodesk workflows, LAS for civil and geospatial analysis, PTS where legacy tools still require it.
Who commissions point cloud services specifically?
- Design firms consuming clouds directly in Revit or CAD without needing a model built for them
- Survey and engineering teams who need documented, verifiable accuracy
- Teams holding raw scan data they captured but can't yet use
- VDC groups requiring classified, clash-ready clouds
- Owners archiving facility documentation in open, durable formats
How does a point cloud project actually run, step by step?
- Assess. A new capture is scoped from scratch — or an existing dataset you already hold is evaluated for what's realistically achievable with it.
- Register. Scans are aligned to control with target constraints and loop closures, the process that determines whether the final accuracy claim is real.
- Verify and clean. Residuals are documented, independent checks are run against physical reality, and artifacts are removed.
- Deliver. Classified, correctly formatted data ships together with the QA report that proves the accuracy claim rather than just stating it.
What's the difference between a dataset with QA and one without it?
Two point clouds can look identical on screen and be worlds apart in reliability. The only way to tell the difference is documentation: does the deliverable come with reported residuals, a record of which control points it was checked against, and evidence of an independent verification measurement — or does it come with just a stated accuracy figure and nothing to back it up? A dataset without that paper trail might be accurate, but there's no way to know without redoing the check yourself. That's the entire reason "documented QA" is the operative phrase in every point cloud deliverable here, rather than a spec-sheet number nobody can verify.
Whether you need a new capture registered to survey-grade standards or an existing dataset made usable, point cloud services deliver the QA documentation that lets your team build on the data with confidence — accuracy you can verify is the actual product; everything else is just points.