You have flown the site. The ortho looks good. The terrain model reconciles against your checkpoints. Then the client asks about the underside of the bridge deck, or the facade behind the trees, or the understorey the canopy swallowed.
That is not a flight-planning failure. It is a limit of looking at a site from above. No flying height puts points on a surface the aircraft cannot see. The fix is not a better sensor. It is a second platform at ground level, and a workflow that merges the two into one file.
We already wrote the why: fly the shell, walk the dead zone, same grid. This one is the how. Field order, bookkeeping, registration and the checks that catch a bad merge.
Why one platform never finishes the job
Point cloud data from a single platform hits the same three problems on almost every site.
Occlusion. The drone has near-ground blind spots by definition. Building faces, bridge undersides, anything under dense canopy or in permanent shadow.
Resolution. The height you chose for coverage is not the height that gives you facade detail. You cannot have both from one pass. They are opposite requirements.
Consistency. Two separate deliverables, captured at different times in different frames, become the client's reconciliation problem rather than yours. That is the version of the job that generates arguments.
Merging an airborne LiDAR pass with a ground-based SLAM walk is how you cover those three. The aircraft gives you broad coverage and dependable absolute position. The walk gives you the parts a client will actually measure.
What runs the workflow
The process is platform-agnostic in principle. Anything that outputs a georeferenced LAS or PLY will slot into it. In practice these are the combinations we document against.
Aerial. Matrice 400 with Zenmuse L3 is the loadout we quote. L2 on an M400 or an M350 you already fly still enters at the same point. A visible-light mapping camera such as a Zenmuse P1 works too: photographs through aerial triangulation in DJI Terra first, exported LAS into this workflow.
Ground. SHARE C1 Pro for mixed indoor and outdoor walks that have to join the drone block on AUSCORS NTRIP. SHARE C1 when the day's work never leaves cover and you already occupy control. C10 when the traverse is long or the site is a pit, a corridor or a multi-storey mix where C1-class units start to drift.
C1-class published figures, on a clean walk: relative under 1 cm, thickness within 1 cm, absolute under 5 cm with RTK. Manufacturer numbers under their stated conditions. Treat them as a specification, not a promise about your site.
Processing. DJI Terra for the aerial half. SHARE Point Cloud Studio for the ground half. CloudCompare or Trimble RealWorks for the mixed registration. Studio 2.6 can register two SHARE clouds. A Terra LAS sitting against a SHARE LAS still wants the third package.
The one requirement that matters: both devices write into the same coordinate system. RTK on the aircraft and on the scanner, same datum and projection, before you start capturing. Everything downstream is easier or harder depending on whether you did this.
The four stages
- Field capture. Fly the area complete, then walk the parts the aircraft could not see. RTK on both, the same coordinate system on both, and deliberate overlap between them.
- Preprocess separately. Aerial through Terra. Ground through Studio. Each comes out as a georeferenced LAS or PLY, cleaned, before either goes near the other.
- Register and merge. Coarse alignment on common points where you need one, then a fine registration. One merged cloud out.
- Check and deliver. Inspect the seams at full zoom, check against control, classify what the deliverable needs, export in the client's format.
The shape of the job never changes. What changes is how much work stage three costs you, and that is decided almost entirely by what you did in stage one.
Fly it first, and fly it as the reference frame
The aerial pass is normally the dataset everything else registers to, because a fixed RTK solution holds its absolute position across the whole site rather than drifting with distance.
Fly the full route. Do not thin it on the assumption that the ground walk will cover the gaps. It will not cover them evenly. Enable RTK and confirm a fixed solution before the first line. Set the coordinate system before capture, and write it down. AUSCORS NTRIP is the caster we put on most Australian kits.
While you are still on site, note where the aircraft could not see. That list is the plan for the walk.
Two decisions here cost you later. Flying on a float produces a cloud that looks fine and does not sit where the ground scan expects it. Choosing the coordinate system afterwards means every dataset needs a transformation, which is one more place for error to enter.
Then walk what the aircraft could not see
A SLAM walk is not a second survey of the whole site. It is a targeted capture of what the flight missed, plus enough overlap to tie the two together.
Plan the walk by area rather than wandering, in routes that close back on themselves. Turn RTK on. Select the same coordinate system as the flight. Cover the target list: under trees, building shadows, facades, road surface detail, undersides, interiors where the job needs them.
Then do the thing most people skip. Walk deliberately through the zones where both datasets already exist. An approach road, a car park, open ground beside a building. Those shared hard surfaces are what a registration algorithm has to work with. If the walk starts exactly where the flight stopped, there is nothing to agree on.
Three habits make registration quicker:
- Overlap on purpose. Shared hard surfaces. Kerbs, slabs, road edges. Vegetation is a poor witness because it moves and it looks different from above.
- Close your loops. A trajectory that returns to a known start drifts less than one that runs out and stops.
- Photograph your tie features. Corners, painted markings, manhole covers. Picking common points is faster when you know what you are looking at.
Field craft for the walk itself: handheld SLAM as-built checklist.
Registration: coarse only if you need it, fine always
Which path you take depends on whether both datasets carry a good RTK solution.
If both do, they usually land in near alignment on import. Zoom to a metre and check a hard surface first. Discrepancies invisible at site scale are obvious there. If it holds up, skip the coarse step and go straight to fine registration.
If one lacks RTK, or you see layering, do a coarse registration first. Select at least three sets of identical points that appear in both clouds, well distributed rather than clustered in one corner. Prefer corners of hard structures over vegetation. Add more evenly distributed pairs on top of that solution and re-run the calculation to tighten the fit.
Either way, finish with a fine registration, typically ICP. Set the RMS difference threshold, and set the expected final overlap to the area the clouds actually share, not a hopeful 100 percent. Telling the algorithm that two clouds share everything, when they share a car park, drags the solution towards a compromise that fits neither.
Studio 2.6 click-path for two SHARE clouds: register clouds, sit them on control.
The bookkeeping that decides whether it merges
Most failed merges are not registration failures. They are bookkeeping failures.
Record the horizontal datum and projection in full, including the zone. Record the vertical reference, and whether your figures are ellipsoidal or orthometric. Record the geoid model if one is applied, the base or NTRIP mount and how the rover was derived, and which device was the reference for the merge. All of it is trivial to note on the day and painful to reconstruct three weeks later when someone queries a level.
It also tells you what a misalignment actually is:
- Two clouds metres apart is a coordinate system problem, not a registration problem.
- A constant height offset is usually ellipsoidal against orthometric, or a geoid applied to one dataset and not the other.
- A merge that fits at one end and drifts at the other is SLAM drift across a long walk, or tie points clustered in one area.
Check it before you call it finished
A merged cloud almost always looks right at site scale. The failures show up close in, and they are the ones a client will find for you.
Look for layering on flat surfaces: two skins where a road or slab should have one. Look for doubled edges on structures, checked at several points around the site rather than only where you picked your tie points. Look for a fit that is excellent near your common points and drifts away from them. Look for gaps at the join, a band where neither dataset reached, which is cheaper to find while a short return walk is still possible.
Then check the merged cloud against independent checkpoints and record the residuals. Ground control points stay useful. RTK expands the jobs you can finish with fewer marks. It does not retire a check you have to defend. That residuals table is what answers how you know the surface is right.
Where the merge pays for itself
| Application | What the merge adds |
|---|---|
| Forest survey | Aerial captures canopy structure. The walk captures understorey and trunk sections. |
| Building renovation | Aerial extracts roofs and massing. The walk extracts facades, windows, doors and structural detail. |
| Urban road reconstruction | Aerial gives corridor structure. The walk completes lane markings, footpaths and manholes. |
| Overpass and overhead line | Aerial captures overall structure. The walk supplies undersides, pillars and obscured areas. |
| Cultural heritage recording | Aerial generates overall form. The walk supplies structural detail and carvings. |
Every job on that list used to be quoted either as two mobilisations with two deliverables the client had to reconcile, or as one deliverable with a caveat about what it does not cover. Merging removes the caveat. It is usually the caveat that loses the work.
Get the complete workflow
This post is the shape of the process. The PDF is the version you can take to site: step-by-step field procedure for both captures, processing notes for each package, the registration sequence, a coordinate-system reference, the quality checks and the full application table.
Leave an email in the card below. We send the PDF to that inbox. Same document our team works from.
C1 from $6,199. C1 Pro $7,999. In stock, available to buy now. Book a demo if you have a site one platform cannot finish. We will walk through how the merge would run, what it costs in field time, and where this workflow stops being worth the effort.
SHARE C1 Pro · SHARE C1 · Zenmuse L3 · C1 series
Read next: drone plus handheld, one site model · AUSCORS NTRIP · Studio 2.6
FAQ
C1, C1 Pro or C10 for the ground half?
C1 Pro when the walk has to join the drone block on AUSCORS as you go. C1 if you stay GPS-denied and occupy control yourself, or add the C1 RTK module. C10 when the site is a long traverse, a pit or a multi-storey mix where C1-class units start to drift. We pick that on the demo, not from the product name.
Do both platforms need RTK?
If you want stage three to be a check rather than a point-picking session, yes. Two fixed solutions in the same frame usually import already aligned. One without RTK is a manual registration. GCPs remain useful as independent checks either way.
What if I already process everything in DJI Terra?
Terra is the aerial seat. The handheld job still solves in SHARE Point Cloud Studio. Merge the two LAS files in CloudCompare or RealWorks. Do not import the SHARE walk into Terra and hope.
Why not 100 percent overlap in ICP?
Because the clouds do not share 100 percent of the site. The walk filled what the aircraft missed. Set expected overlap to the shared hard surfaces (car park, approach, slab). A 100 percent setting drags both clouds toward a compromise that fits neither.
What belongs in the site notes before you leave?
Horizontal datum and zone. Vertical reference (ellipsoidal or orthometric). Geoid if applied. AUSCORS mount or base derivation. Which cloud is the registration reference. Photos of the tie features you will pick later.
What is in the PDF?
Field procedure for the flight and the walk, Terra and Studio preprocess, the CloudCompare / RealWorks registration sequence, coordinate bookkeeping, quality checks and the application table. Hardware names in that edition still say S20 / S100 in places. The live catalogue is C1, C1 Pro and C10.
