Progress photos argue; point clouds measure. On a mid-size Singapore construction project, the coordination team wanted a monthly record that could settle questions about what was actually built, where, and when, without waiting for a dispute to make the question urgent. We scan the site on a fixed cadence: the same walk path, the same processing, the same exports, once a month, every month.
Why scan monthly instead of photographing?
A photo records what a scene looked like from one viewpoint; a point cloud records where every visible surface actually was, in three dimensions, to a measurable tolerance. That difference matters most on a live site. When two parties disagree about whether a wall was cast before a given date, or whether services were installed on their modelled route, a dated, georeferenced point cloud replaces the argument with a measurement. Repeating that capture on a fixed monthly cadence turns individual snapshots into a time series: each scan is an epoch, and every epoch can be compared against the last one, the next one, and the design model. That is the whole logic of the workflow described below.
The repeatable walk path
The value of monthly scans comes from comparability, and comparability comes from discipline. We fixed a walk path in the first month and have repeated it ever since:
- The same start point at the site entrance, beginning in open sky so RTK fixes before the walk.
- The same route through each level, corridor by corridor, in the same order.
- The same loop closures at stair cores, so each month’s trajectory stays internally tight.
- A short checklist noting hoarding moves, new obstructions, and areas that could not be walked, so the next scan explains its own gaps.
The loop closures deserve a word, because they are what keeps a SLAM capture honest. A handheld SLAM scanner estimates its own position continuously as it moves; over a long walk, small estimation errors accumulate as drift. Returning through a space that has already been scanned, at the stair cores in this case, gives the processing software a hard constraint: it recognises the revisited geometry and pulls the whole trajectory back into alignment. Planning those closures into the route, rather than hoping for them, is the difference between a walk path that produces the same quality of data in month twelve as it did in month one and a walk path that slowly degrades.
A full walk of the accessible works takes under an hour of capture. Because the scanner is handheld and captures while walking, the scan slots between trade activity without stopping work, and a delayed pour or a blocked corridor just becomes a note in our log rather than a rescheduled survey.
Keeping every epoch in one coordinate frame
Month-over-month comparison only works if every scan lands in the same coordinate system. We use two anchors for this. The first is RTK georeferencing: starting each walk in open sky lets the scanner’s GNSS receiver establish absolute coordinates before the trajectory heads into the structure, where SLAM carries those coordinates forward. The second is fixed site references, stable, well-defined features that persist between epochs, which act as a sanity check that each month’s cloud has landed where the last one did. Between the two, the alignment is verified rather than assumed. On a site where sky view is poor or the specification is tighter, the same logic extends naturally to surveyed control points and post-processed (PPK-style) checks, but for a coordination record the RTK-plus-references approach has held up.
Processing each month’s scan
The processing routine is deliberately identical every month, because a comparison is only as clean as the less consistent of its two datasets. Each epoch goes through the same steps: copy the raw capture off the scanner, run the SLAM optimisation and registration in the processing software, apply the georeferencing, crop the cloud to the site boundary, and filter the transient noise that a live site always contributes, workers, plant, and vehicles that walked through the scan. The cleaned cloud is then exported in the formats the downstream tools expect: .las for the archive, .rcp for referencing inside the Revit coordination environment, and .e57 where a vendor-neutral exchange copy is needed. Export settings, naming conventions, and folder structure are frozen; the only thing that changes month to month is the geometry.
Comparing month over month
Each month we process the walk into a registered point cloud and drop it into the same project coordinate system, using the RTK georeferencing plus fixed site references to keep every epoch aligned. From there the comparisons are direct: this month’s cloud against last month’s shows what was erected, cast, or removed; cloud-to-cloud distances flag anything that moved when it should not have; and a slice through any gridline shows the state of the structure on a known date.
Coordination with the BIM overlay
The monthly cloud also gets overlaid on the coordination model. Built-vs-designed deviations show up while they are still cheap to fix: services installed off their modelled routes, openings formed slightly off-position, screed levels drifting from design. We treat the overlay as a coordination reference rather than a certified survey, and flag anything contractual to the project surveyor, but most issues never need to go that far because they are caught within a month of appearing.
Why a monthly cadence works
A progress record is only useful if it actually gets made, every month, without anyone having to decide to make it. Fixing the cadence removes that decision: the scan is booked as a standing slot, the walk path is already written, and the processing is a routine rather than a project. The site team does not operate equipment, learn software, or maintain anything between epochs, which is what usually kills an in-house progress-scanning habit by month three. Every dataset belongs to the project team; we supply the capture, the processing and the consistency.
Lessons worth stealing
Looking back across the epochs, the practices that mattered most were the unglamorous ones. Writing the capture log properly from the first month, not from the month a gap first needed explaining. Treating the walk path document as versioned, when hoarding or sequencing forces a change, the change is dated and noted rather than improvised. And resisting the urge to tweak processing settings when a new software release offers something shinier; a progress record rewards boring consistency over optimisation. Starting again, the only real change would be to formalise all of this on day one instead of converging on it over the first few epochs.
What the record is worth
A year in, the project holds a month-by-month, measurable history of the site: every claim about progress can be checked against geometry, every as-built question has a dated answer, and the eventual handover package includes a progress archive no photo log could match.
Tracking progress on an active site?
Nothing in this cadence is specific to one project. Fix a walk path, plan the loop closures, freeze the export settings, and put the scan on a standing monthly slot. See how it fits construction and coordination workflows, read what 3D laser scanning covers, or send the site, the cadence you want and what you are comparing against. We reply with scope and a quote within one business day.
