Registered point clouds: what the approval should mean

Registration joins scan positions. Review determines whether that relationship is credible for the stated project use.

Registration in one sentence

Point-cloud registration places scans captured from separate instrument positions into a shared spatial relationship. The result may use a project-local coordinate system, a building grid, survey control, a national reference framework, or another agreed basis.

The word registered describes a processing state. It does not, by itself, tell the recipient how the relationship was created, reviewed, controlled, or approved.

Common relationship methods

Artificial targets

Spheres, checkerboards, or other recognized targets can create explicit relationships between scan positions. Their placement, visibility, distribution, identification, and stability matter. A strong target network is not merely a high target count; it provides useful geometry and redundancy throughout the work.

Shared surface geometry

Cloud-to-cloud methods compare overlapping scene geometry. They can be effective where the environment provides distinctive, stable surfaces and sufficient overlap. Long corridors, repeated bays, vegetation, moving objects, low-feature areas, or surfaces concentrated in one plane can weaken the geometry even when software produces a result.

Survey control

Control can relate the scan network to an external coordinate basis or strengthen project-wide behavior. The scope must define who establishes control, its authority and datum, units, transformation method, instruments, tolerances, documentation, and responsibility. Calling a dataset “survey-grade” without those details is not useful.

Combined workflows

Many projects combine targets, cloud geometry, control, visual checks, field pre-registration, and office review. The appropriate combination depends on the site and decision.

Why one number is not enough

Registration software often reports residuals, overlap measures, correspondence statistics, or a mean error. These indicators can help identify a problem, but no single value proves that every area is correct.

A mean can hide local variation. A network can also be internally consistent yet incorrectly placed relative to control, scale, units, level, north, or a required project datum. Conversely, one difficult relationship may have a larger residual without invalidating areas that are independently constrained and reviewed.

A defensible review asks whether the evidence is appropriate to the network, the site, and the decisions the dataset must support.

A more complete review

A processing and QA record may consider:

  • whether planned areas and connections were captured;
  • the geometry and redundancy of the scan network;
  • target residuals and the distribution of targets;
  • cloud relationships in decision-critical areas;
  • survey-control residuals and transformation behavior, when control applies;
  • movement between or during scans;
  • repeated geometry, symmetry, or low-feature zones;
  • registration groups, locked relationships, exclusions, and manual interventions;
  • coordinates, units, orientation, levels, and test features;
  • representative visual slices or comparisons;
  • unresolved gaps, exceptions, or conditions that affect use.

The project does not always need the same evidence. A compact room used for routing has different network risks from a multi-floor tower tied to control or a long industrial corridor.

Field pre-registration and final approval

Real-time or near-real-time field feedback is valuable. It can show whether scan positions appear connected and whether coverage should be added before leaving the site. That capability reduces avoidable gaps.

Field feedback should still be distinguished from final processing and approval. Office review may use additional computation, control, filtering, grouping, documentation, or software. The project plan should name the point at which the dataset is considered ready for export or derived work.

Controlled versus local datasets

A local coordinate system can be completely appropriate. Not every project needs survey control. If the data will be coordinated with civil, geospatial, structural, or other controlled information, however, the coordinate basis must be resolved early.

Questions to settle include:

  1. Is the need relative fit, absolute position, or both?
  2. Who supplies and warrants control?
  3. Which datum, projection, geoid, grid, benchmark, level, and units apply?
  4. Is a coordinate transformation required?
  5. How will large coordinate values affect receiving software?
  6. Which checkpoints or comparisons will be retained?

What “approved” should communicate

Approval should be tied to a defined review method and intended use. It can communicate that specified checks were completed, exceptions were documented, and the dataset is released for the agreed next step. It should not silently expand into a promise that every point is equally accurate, every visible object is complete, or the data is suitable for uses outside the contract.

Handoff questions for recipients

When receiving a point cloud, ask for the coordinate and unit statement, format and version, scan or region organization, imagery status, known exclusions, registration/control summary appropriate to the scope, and a small compatibility test if the downstream environment is sensitive.

FARO’s current Focus knowledge base describes supported capture and processing tools. Product features can assist the workflow; the project’s QA plan determines what evidence is needed for approval.

Next coordinatePROJECT / SCOPE

Define the site. Define the output. Then plan the capture.

Tell us what your team needs to decide, the conditions you need documented, and the software the information must enter.