The Doming Myth: Photogrammetry's Most Fixable Weakness

The trade press has settled on a single sentence as the reason to buy Light Detection and Ranging (LiDAR) instead of photogrammetry. Wingtra (vendor) wrote, in a version of its LiDAR-vs-photogrammetry guide that was live in April 2026, that photogrammetry “offers excellent horizontal accuracy down to 1 cm, but due to the predominantly [nadir] nature of capture, the vertical accuracy will be half to a third as good.” The sentence names the right mechanism (nadir-only geometry) and draws the wrong conclusion. The mechanism is real. The conclusion is twelve years out of date. The photogrammetry doming fix has been in the peer-reviewed literature since 2014.

James and Robson 2014, in Earth Surface Processes and Landforms, published a workflow change that cuts doming error by up to two orders of magnitude. Nesbit and Hugenholtz 2019 found that adding 20–35 degree oblique imagery, with higher overlap, improved precision and accuracy by nearly 50 percent over nadir-only blocks, measured against a terrestrial laser-scan reference. Every major flight planner already ships the photogrammetry doming fix as a built-in mode: DJI Smart Oblique Capture (vendor), Pix4Dcapture Double Grid (vendor), DroneDeploy Crosshatch (vendor). The mechanism behind the trade-press argument is real. The argument that it’s an inherent ceiling on Structure from Motion (SfM) photogrammetry isn’t.

This is the doming rebuttal. The article that explains what doming is, why it happens, how to detect it, and the tolerance-by-job table lives in the existing pillar at drone map doming effect. The mechanism, detection, and tolerance content lives there, and this article doesn’t re-explain it. What follows is the case that the conventional anti-photogrammetry framing of doming is a workflow problem with a published, peer-reviewed, vendor-implemented fix.

The Claim the Industry Keeps Repeating

Wingtra’s framing is worth quoting in full because it’s the cleanest statement of the inherent-limitation argument in the trade press. Photogrammetry, the guide said, “offers excellent horizontal accuracy down to 1 cm, but due to the predominantly [nadir] nature of capture, the vertical accuracy will be half to a third as good.” The current version of the page is softer (“vertical accuracy is usually less robust than LIDAR in the same conditions”), but the mechanism it names is the same.

Read the second clause carefully. “Due to the predominantly nadir nature of capture” is the load-bearing phrase. It names the mechanism correctly: parallel-axis nadir imagery can’t mathematically separate radial lens distortion from surface curvature during bundle adjustment, which produces the bowl-shaped Digital Elevation Model (DEM) error practitioners call doming. Then the framing quietly converts a flight-plan choice into a sensor limitation. Photogrammetry’s vertical accuracy is half to a third as good, the sentence reads, because of how operators fly the camera.

That’s the move. Full stop. The fix has been in the literature since 2014.

The pillar at drone map doming effect covers what doming is and how to detect it. The argument here is narrower and sharper: the published evidence doesn’t support treating doming as inherent. It supports treating it as a planning artifact with a fix that costs zero capex and a few extra minutes of flight time.

What the Bundle Adjustment Cannot Do

The mechanism, in two sentences. When every photo in an image network is taken from a near-vertical viewing angle, the bundle adjustment’s Jacobian becomes ill-conditioned with respect to the radial-distortion coefficients (k1, k2, k3) of the Brown-Conrady camera model. The optimizer can’t tell the difference between a curved lens-distortion profile and a curved ground surface, so it absorbs the lens error into the terrain shape and produces a smoothly domed DEM that fits the reprojection residuals at the cost of fitting the actual ground.

That’s the entire mechanism. The four contributors (radial-distortion misestimation, EXIF GPS elevation drift, rolling shutter, and bundle-adjustment convergence failure), the Ground Control Point (GCP)-fixes-degeneracy explanation, the DJI risk ranking, and the tolerance-by-job table all live in the existing doming-effect pillar. What matters here is the next move: once the image network includes oblique views, the optimizer can geometrically separate distortion from surface shape, the radial-distortion coefficients converge to physically correct values, and the dome flattens. The math is well posed when the geometry is.

The Published Fix — James & Robson 2014

James and Robson 2014 is the paper the trade press has not caught up with.

The setup: Simulated UAV image networks (illustrated with one real ground-based example from their 2012 work), with bundle adjustment plus self-calibration enabled. The researchers constructed image networks with varying degrees of nadir-vs-oblique content, then measured the residual DEM systematic error against control. In the paper’s words, the magnitude of doming error “shows a linear relationship with radial distortion.” That is a published, characterized relationship that makes the failure mode predictable.

The headline number, paraphrased from the abstract: systematic DEM error can be significantly reduced by adding oblique images to the image network, with practical flight plans for fixed-wing or rotor UAVs that reduce DEM error by up to two orders of magnitude in the absence of control points. Two orders of magnitude. Without GCPs.

Doming is real. James and Robson 2014 also demonstrated that adding oblique imagery to a nadir grid reduces doming-induced DEM error by up to two orders of magnitude. Doming is a planning artifact, not an inherent SfM ceiling.

The same relationship is why the fix also reaches existing datasets. James and Robson show that characterizing how dome magnitude varies with the radial-distortion estimate gives an improved distortion estimate, which can then be used to reprocess a nadir-only project optimally. The fix isn’t strictly a planning fix. It’s also a processing fix that can be applied retroactively.

How Much Oblique Imagery Is Enough for Cross-Hatch Drone Mapping — Nesbit & Hugenholtz 2019

James and Robson 2014 established that the fix works. Nesbit and Hugenholtz 2019 measured the specific dose that delivers it.

The site was badlands in Dinosaur Provincial Park, southeastern Alberta, high-relief terrain validated against a terrestrial laser scanner reference. The methodology was unusual in the literature for its scale: more than 150 UAV-SfM scenarios across the full range of camera tilt from 0 degrees (nadir) to 35 degrees off-nadir, with overlap and flight-line configuration varied alongside tilt.

Nesbit and Hugenholtz 2019 tested 150-plus flight configurations against terrestrial laser scanner reference. The headline number: higher overlap plus 20–35 degree oblique camera angles improved precision and accuracy by nearly 50 percent relative to nadir-only image blocks.

That’s the second-most-quotable number in the literature, after James and Robson’s two orders of magnitude, and the more practitioner-useful one. It tells operators where the gains showed up: 20 to 35 degrees off-nadir, with the obliques added to nadir imagery rather than replacing it. A cross-hatch pass at 25 degrees off-nadir, added to a standard nadir grid, puts the oblique imagery inside that band.

One honest caveat: Nesbit and Hugenholtz surveyed a single high-relief site, so their 50 percent figure is a high-relief number. The paper doesn’t test flat ground, and the size of the gain elsewhere will depend on the site. Nor is steeper always better: the authors found that higher tilts in combination datasets “generally increase precision, but may have an adverse effect on accuracy.” Treat 20–35 degrees as the range where the gains appeared, not a dial to max out. The fix itself doesn’t vanish on flat sites, since James and Robson 2014 simulated flat as well as sloping terrain.

The Alternative Lever — GCP Distribution (Sanz-Ablanedo 2018)

Oblique imagery is the most effective fix. GCP distribution is the second lever, and Sanz-Ablanedo et al. 2018 is a large-scale GCP study (102 targets, 3,465 combinations).

The site: a 1,225-hectare coal mine in León, Spain, 2,514 photos, 102 measured targets. The methodology: 3,465 different GCP-and-checkpoint combinations evaluated, with GCP counts varied and the balance used as independent checkpoints.

The headline finding has two parts. First, the curve. With 10–20 GCPs, checkpoint error (all three axes combined) was still over ±31 cm. With 50–60, it improved to about ±16 cm (3 GSD). With 90–100, it converged slowly toward ±12 cm. On a much smaller site the numbers are smaller: Agüera-Vega 2017 measured 5.8 cm vertical Root Mean Square Error (RMSEV) at 15 GCPs and 4.7 cm at 20 GCPs on a 17.64-hectare field at 120 m Above Ground Level (AGL).

Second, the distribution finding — load-bearing. The paper found that concentrating points on the periphery, or in the center, does not give good accuracy; they need to cover the block. With perimeter-only control, the bundle adjustment is anchored at the edges and free to curve in the interior, which is why the existing doming-effect pillar recommends at least one GCP near the project center.

For step-by-step guidance on the GCP layout that satisfies both the count and distribution requirement, see how to set your own ground control points.

The Before-After Evidence Table

This is the article’s spine. Five rows of published comparison.

Five separate teams, four field sites plus simulations, methodologies ranging from controlled image-network simulations to terrestrial laser scanner (TLS)-referenced field surveys. The reduction direction is consistent. Magnitudes vary with site relief, overlap, and starting accuracy, but no row in this table shows nadir-only outperforming a properly oblique-augmented capture on a site where oblique imagery is geometrically meaningful.

The Taddia et al. row deserves a separate callout. A short sequence of 31 oblique images added to a nadir PPK block, with zero GCPs, gave a vertical RMSE of 2.5 cm, about half the 5.2 cm of the nadir-only block with one GCP. Horizontal (East) error got worse, so 3D RMSE stayed near 7 cm. The marginal cost of the fix: a few dozen extra photos.

Your Flight Planner Already Implements This

The vendor stack has already conceded the argument. Three major flight-planning apps ship cross-hatch or oblique modes, and their camera-angle settings reach the 20–35 degree band Nesbit and Hugenholtz found most effective.

DJI Smart Oblique Capture (vendor)

DJI’s Smart Oblique Capture on the Zenmuse P1 (mounted on the Matrice 300, 350, and 400 platforms) swings the gimbal through up to five angles on each pass, nadir plus four obliques, with fewer at the edges of the area. DJI gives the oblique tilt range as -45° to -90°, which is 0 to 45 degrees off-nadir, so the whole Nesbit and Hugenholtz band is in reach. The Mavic 3 Enterprise (M3E) gained its own Smart Oblique mode in a firmware update; it flies two perpendicular S-shaped routes and shoots in three directions. Either way, one flight delivers an oblique block that would otherwise take several separate missions.

Pix4Dcapture Double Grid (vendor)

Pix4Dcapture’s Double Grid mission flies two perpendicular passes at the same altitude. Camera angle is measured from horizontal and is configurable from 45 to 80 degrees (10 to 45 degrees off-nadir), so a 70-degree setting is 20 degrees off-nadir. You set the front overlap (70 to 90 percent) and the app sets side spacing automatically at about twice the front spacing. The picture trigger defaults to Fast mode; Safe mode stops the drone for every photo. Pix4D has since put Pix4Dcapture on end-of-support. For deep doming work on featureless sites, operators can manually tilt to 55–60 degrees (30–35 degrees off-nadir). Double Grid shoots every frame at one tilt, and Nesbit and Hugenholtz found single-angle sets at 30–35 degrees “can produce reliable results if combination datasets are not possible.”

DroneDeploy Crosshatch and Enhanced 3D (vendor)

DroneDeploy’s Crosshatch pattern doubles the plan lines, flies them in both directions, and captures oblique imagery at a 65-degree camera angle: 25 degrees off-nadir if the angle is read from horizontal, inside the band Nesbit and Hugenholtz found most effective. Enhanced 3D extends Crosshatch with a Perimeter 3D circuit at oblique angle. Live Map must be disabled during Crosshatch, and DroneDeploy recommends a 1,000-image ceiling per Enhanced 3D mission.

When DJI ships Smart Oblique Capture and Pix4Dcapture and DroneDeploy ship cross-grid oblique modes that reach the 20–35° band, the vendor stack has already conceded the argument. The doming fix is in the products you already own.

The mission-planning workflow that ties all three vendor modes together, including the cross-hatch toggle, the GCP layout, and the checkpoint-validation step, is covered in the drone mapping mission planning checklist.

Self-Calibration — Software Defaults and When to Override

The flight pattern is half the fix. Software settings are the other half. All three major processors enable self-calibration by default; each has documented mitigations when the dataset still domes.

Pix4Dmapper (vendor)

Pix4Dmapper’s internal camera database supplies optimal starting parameters, radial and tangential distortion included, for many cameras. Rolling shutter correction is set per camera model (Image Properties Editor > Camera Model > Edit > Shutter Model: Linear Rolling Shutter). Pix4D recommends it when the vertical pixel displacement, which you work out from flight speed, readout time, and the camera and height geometry with Pix4D’s calculator, is bigger than 2 pixels.

The doming-remediation override: load the optimized parameters from a known-good project on the same camera body (Image Properties Editor > Camera Model > Load Optimized Parameters), then rerun with Internal Parameters Optimization set to None to hold them fixed, or All Prior to keep them close to those values. Pix4Dmapper can’t lock individual coefficients; the choices are All, None, Leading, and All Prior. This works when an earlier project on the same airframe produced a clean DEM and the current dataset on the same body is doming. The calibration values transfer.

Agisoft Metashape

Metashape self-calibrates by default, estimating f, cx, cy, k1, k2, k3, p1, and p2; b1, b2, and k4 stay fixed, and adaptive camera-model fitting is off unless you turn it on. The workflow order is load-bearing: mark GCPs in images first, then run Tools > Optimize Cameras (or the Optimize button on the Reference pane). Agisoft says to run optimization again after adding or editing GCPs. A project optimized before the GCPs went in, and never re-optimized, keeps a distortion estimate the control never constrained.

For pre-calibration, Metashape has built-in chessboard calibration: Tools > Camera > Show Chessboard, photograph it, then Tools > Camera > Calibrate Camera. The result appears in Tools > Camera Calibration, where you can save it, and the Fixed parameters selector there keeps k1, k2, and k3 unchanged during Align Photos and Optimize Cameras.

OpenDroneMap (ODM) and WebODM (ODX engine)

WebODM is a separate project from OpenDroneMap. It processes with ODX, its own engine forked from ODM, and both engines expose the same camera options covered here. Both self-calibrate the camera by default, with --camera-lens auto picking the lens model from image metadata, or Brown when there is none. Rolling shutter correction is the --rolling-shutter flag, optionally paired with --rolling-shutter-readout [ms]. Each engine ships a built-in readout table keyed by camera model; a camera missing from it falls back to a guessed 30 ms with a warning in the log. The RSCalibration project (WebODM’s copy, OpenDroneMap’s) documents how to measure the readout yourself.

The critical gotcha: an incorrect rolling shutter readout time can make results worse, not better. Verify the readout for the specific camera body before enabling the flag.

Both engines have two remediation options, and both appear in WebODM’s task options panel as well as on the command line. --cameras loads the calibration from another dataset, either a path to a cameras.json file or its JSON contents (WebODM’s field has a button to import the file, and WebODM’s download menu includes a Camera Parameters file, which is that cameras.json). --use-fixed-camera-params turns off camera parameter optimization during bundle adjustment; its help text says it “can be sometimes useful for improving results that exhibit doming/bowling.” On its own, --cameras only supplies starting values and priors (the engine still passes optimize_camera_parameters: yes to OpenSfM), so to hold a known-good calibration fixed, use both together. There is no per-coefficient lock; the calibration is fixed or optimized as a whole. On nadir-only datasets, ODM and ODX are as susceptible to doming as any commercial pipeline. The same fix (cross-hatch plus five distributed GCPs) applies.

Worked Example — Same Site, Two Workflows

The before-after table is the literature. This is what the same operator on the same site would see by changing only flight pattern and GCP layout. Both scenarios are composed from the published literature. They aren’t a single proprietary AeroCartwright measurement.

Scenario A — Site X, 10-hectare flat agricultural field, DJI Mavic 3E, 100 m AGL, nadir-only single grid, self-calibration on, four corner GCPs. Expected RMSEV 30–45 cm with a center-dome residual of 20–30 cm. Horizontal RMSE (RMSEH) 4–6 cm. The orthomosaic looks clean; the DEM is wrong by roughly a foot at the project center. In line with the ~0.2 m domes James and Robson 2014 simulated for nadir-only blocks.

Scenario B — Same site, same hardware, same overlap, DroneDeploy Crosshatch at its 65-degree camera angle (25 degrees off-nadir if read from horizontal), self-calibration on, five GCPs including one near the project center. Expected RMSEV 3–5 cm with no detectable doming residual. RMSEH 3–5 cm. Comparable to Agüera-Vega 2017’s 15-GCP open-field result (5.8 cm RMSEV) and consistent with Nesbit and Hugenholtz 2019’s 20–35 degree finding.

The choice between Scenario A and Scenario B is workflow, not platform. Same drone, same processor, same flight altitude, same overlap setting. The only differences: the cross-hatch toggle in the flight planner and the GCP layout. The literature says the second workflow is roughly an order of magnitude more accurate on the deliverable that matters. Cost differential: one extra battery and one extra GCP target. For the broader treatment of drone survey accuracy budgets, see the drone survey accuracy reference.

When Doming Persists (Honest Counter-Cases)

The published fix is not universal. Five scenarios put the cross-hatch-plus-oblique workflow out of bounds or render it insufficient. The rebuttal only holds if the boundary is honest.

1. Single-strip nadir corridors. Powerline, pipeline, narrow-road, and rail-corridor missions flown as a single 30-metre-wide strip lack enough cross-track image diversity for oblique additions to help much. A perpendicular cross-flight at corridor width is geometrically constrained; the corridor itself is too narrow for the bundle adjustment to gain meaningful new convergence angles. Dedicated corridor mapping uses a 3-strip parallel plus oblique fan-out (possible, but rarely flown outside specialist corridor missions).

2. Very high-altitude small-object datasets. When the imaged object spans a small fraction of the image frame and the platform is high enough that even oblique angles produce only narrow convergence, the bundle adjustment cannot gain enough geometric leverage from oblique imagery to fully resolve the distortion-vs-surface ambiguity. This is close-range industrial photogrammetry territory more than mainstream drone mapping, but it bites high-altitude tower or chimney inspections.

3. Wrong intrinsic camera model. Fisheye lenses processed as perspective, or perspective lenses processed as fisheye. The bundle adjustment cannot recover from a fundamentally wrong distortion model regardless of how much oblique content sits in the network. Verify the intrinsic model matches the lens before processing.

4. Geomorphic change detection. James, Antoniazza, Robson and Lane 2020 (Earth Surface Processes and Landforms, DOI 10.1002/esp.4878) looked at change detection specifically and found that off-nadir imagery is not a guarantee. A gently inclined (under 15 degree) camera can reduce accuracy by correlating decentring and radial distortion terms, and in their Swiss field surveys a 10-degree-inclined camera over lower-relief ground still produced vertical doming errors greater than 0.3 m. When the deliverable is change between repeat surveys, the remaining systematic error has to be checked and corrected, not assumed away.

5. Stale pre-calibration on consumer DJI cameras. Lens distortion shifts with sensor temperature. A pre-calibration done on a cold airframe and locked through a warm flight reintroduces a residual that oblique imagery cannot remove. Either recalibrate at operating temperature or stay with thermally stabilized self-calibration on a well-conditioned image network.

A 2025 ISPRS International Journal of Geo-Information study (Phojaem et al.) added a sixth case as honest counter-evidence: on a road test site set up to simulate an accident scene, flown at 30 m AGL, a straight-down (90 degree) camera delivered the lowest RMSE (1.7 cm), and tilting the camera to 75 or 60 degrees did not improve it. Two caveats: it measured horizontal distances between GCPs rather than elevation, and its tilted runs replaced the nadir images rather than adding to them. Still, when the site is small, the GCPs are dense, and the altitude is low, the bundle adjustment can be constrained enough without oblique geometry. The fix is dose-dependent; some sites have already received the dose by other means.

For sites where leaf-on or leaf-off conditions complicate the oblique-imagery rationale (vegetation can obscure tie points at low gimbal angles) see leaf-on vs leaf-off drone mapping. And where vertical structure (towers, façades, bridge undersides) drives the oblique-imagery requirement past the simple cross-hatch case, vertical structure drone mapping covers the extended flight patterns.

Decision Tree

Two cases. Pick the one that matches the position you are in.

Case 1: You are planning a flight and need a doming-free DEM.

• Use Cross-Hatch / Double Grid / Smart Oblique mode in your flight planner. Set gimbal tilt to 25–30 degrees off-nadir. Maintain 75 percent front overlap and 65 percent side overlap.
• Lay out 5 GCPs minimum (four corners plus one near project center), with +1 GCP per 25 acres beyond the first 25. Do not corner-only.
• Withhold surveyed checkpoints from processing for independent residual validation. ASPRS Positional Accuracy Standards, Edition 2 (2023; Version 2, 2024) call for at least 30 checkpoints, capped at 120. A small project can use fewer as an informal check, but any accuracy statement must then say the test was performed using ONLY that many checkpoints.
• In Metashape: mark GCPs first, then Tools > Optimize Cameras. In Pix4D: verify Vertical Pixel Displacement before enabling rolling shutter. In ODM or WebODM: check the processing log for the rolling shutter readout the engine picked, and set --rolling-shutter-readout yourself if it warns that your camera isn’t in its table.

Case 2: You inherited a nadir-only dataset that is doming.

• If oblique imagery from any later flight over the same site exists, add it to the same project and reprocess with self-calibration on.
• If a known-good camera calibration from another flight on the same body exists, lock k1, k2, k3 from that calibration and reprocess.
• If neither exists and a return-to-site is impossible, last-resort polynomial trend-surface removal can remove the systematic component. This treats the symptom, not the cause; flag the deliverable as having received post-processing detrending.

The Real Argument

Doming gets repeated as inherent because it’s load-bearing for the LiDAR sales pitch. If photogrammetry has a structural vertical-accuracy ceiling, the 2–3× cost premium for drone LiDAR is justified across most of an operator’s job book. If the ceiling is a workflow artifact, the premium only applies to the specific job types where LiDAR earns it: canopy penetration, bare-earth Digital Terrain Models (DTMs) under vegetation, textureless surfaces, low-light environments, multi-return wire-versus-vegetation separation. The full set of those scenarios is bounded and named in the lead piece, where photogrammetry beats LiDAR on accuracy: the open-terrain evidence, and adjacent siblings cover the free orthomosaic LiDAR-only flights leave behind and the stockpile case where LiDAR doesn’t pay.

The published evidence doesn’t support the inherent-ceiling framing: Wackrow and Chandler 2008 on the mechanism, James and Robson 2014 on the two-orders-of-magnitude fix, Nesbit and Hugenholtz 2019 on adding 20–35 degree obliques to nadir blocks, Sanz-Ablanedo 2018 on the GCP-distribution alternative. The vendor stack doesn’t support it either. The fix is shipped, the angles reach the right range, and the software has documented overrides for the cases where self-calibration needs help. The trade-press argument that photogrammetry has half-to-a-third the vertical accuracy of LiDAR due to the predominantly nadir nature of capture names a fixable workflow choice and dresses it up as an inherent property.

The mechanism is real. The argument that it justifies a 2–3× hardware premium across general open-terrain mapping isn’t. The full head-to-head on this point — when LiDAR earns its premium and when it doesn’t — sits at the LiDAR vs photogrammetry pillar.

Frequently Asked Questions

Can doming actually be fixed with flight planning?

Yes. James and Robson 2014 (Earth Surface Processes and Landforms 39(10):1413–1420) showed in simulation up to a two-orders-of-magnitude reduction in DEM error when oblique imagery is added to a nadir grid — published, peer-reviewed, repeatedly replicated. Nesbit and Hugenholtz 2019 quantified the practitioner number: 20–35 degree oblique camera angles, together with higher overlap, improved precision and accuracy by nearly 50 percent relative to nadir-only image blocks. Every major flight planner — DJI Smart Oblique, Pix4Dcapture Double Grid, DroneDeploy Crosshatch — already implements the fix as a built-in mode.

What is the difference between this article and the existing doming effect pillar?

The pillar at drone map doming effect describes what doming is, why it happens, how to detect it, and the job-by-job tolerance table. This article is the rebuttal to the framing that doming is inherent to photogrammetry. The mechanism content lives in the pillar; the published-fix evidence and the vendor-default cross-check live here.

How much oblique imagery is enough?

Nesbit and Hugenholtz 2019 tested 150-plus flight configurations against a terrestrial laser scanner reference in the Dinosaur Provincial Park badlands and found that adding 20–35 degree obliques to nadir blocks, with higher overlap, improved precision and accuracy by nearly 50 percent relative to nadir-only blocks. Steeper tilts within those combinations tended to raise precision but could lower accuracy. DroneDeploy Crosshatch shoots at a 65-degree camera angle (25 degrees off-nadir if read from horizontal), and DJI Smart Oblique (Zenmuse P1) and Pix4Dcapture Double Grid both accept a tilt inside that band. A perpendicular cross-hatch pass at 25 degrees, added to a nadir grid, matches the combinations the paper tested.

Does adding more GCPs eliminate doming without oblique imagery?

Partially. Sanz-Ablanedo et al. 2018 measured the curve on a 1,225 ha mining site: with 50–60 GCPs the checkpoint error (all three axes combined) was about ±16 cm, and with 90–100 it converged slowly toward ±12 cm. Distribution matters as much as count: points bunched on the periphery or in the center gave poor accuracy, and a perimeter-only layout leaves the interior free to dome. Add at least one GCP near the project center, then add oblique imagery for the strongest combined fix.

When does doming persist despite the published fix?

Five honest counter-cases: single-strip nadir corridor mapping (powerlines, narrow roads); very high-altitude small-object datasets where the convergence angle stays narrow; wrong intrinsic camera model (fisheye processed as perspective); geomorphic change detection, where James et al. 2020 found systematic error can persist even with off-nadir imagery; and stale pre-calibration where lens distortion has shifted with temperature. For practitioner cm-level survey work outside those cases, James and Robson’s published fix is sufficient.

How do I reprocess an existing nadir-only dataset to remove doming?

If you have oblique imagery from a later flight over the same site, add it to the same project and rerun bundle adjustment with self-calibration on. If you only have nadir imagery but a known-good camera calibration from another flight, lock k1, k2, and k3 in your camera optimization settings (Pix4D Load Optimized Parameters with Internal Parameters Optimization set to None, Metashape Tools > Camera Calibration > Fixed parameters, ODM or WebODM via --cameras plus --use-fixed-camera-params). If you have neither, polynomial trend-surface removal is the last-resort option — but it treats the symptom, not the cause.

What rolling shutter readout do I use for ODM or WebODM?

Both ODM and WebODM’s ODX engine look up the readout time in a built-in table keyed by camera model. If your camera isn’t in it, the log warns that it is using a guessed 30 ms default; measure the real value with the RSCalibration method (github.com/WebODM/RSCalibration) and pass it with --rolling-shutter-readout. An incorrect readout can make the result worse, not better.

Sizing a survey workflow against a specific deliverable, or trying to figure out whether a doming-prone legacy dataset can be reprocessed with new oblique imagery before you re-fly the site? Reach out. AeroCartwright runs paid flight-plan and processing-workflow reviews for drone operators and engineering teams.

References

Research and standards cited in this article.

• Agüera-Vega, F., Carvajal-Ramírez, F., & Martínez-Carricondo, P. (2017). Assessment of photogrammetric mapping accuracy based on variation ground control points number using unmanned aerial vehicle. Measurement, 98, 221–227. doi:10.1016/j.measurement.2016.12.002
• ASPRS. (2024). ASPRS positional accuracy standards for digital geospatial data (Edition 2, Version 2.0). American Society for Photogrammetry and Remote Sensing. doi:10.14358/ASPRS.PAS.2024
• James, M. R., et al. (2020). Mitigating systematic error in topographic models for geomorphic change detection: Accuracy, precision and considerations beyond off-nadir imagery. Earth Surface Processes and Landforms, 45(10), 2251–2271. doi:10.1002/esp.4878
• James, M. R., & Robson, S. (2014). Mitigating systematic error in topographic models derived from UAV and ground-based image networks. Earth Surface Processes and Landforms, 39(10), 1413–1420. doi:10.1002/esp.3609
• Nesbit, P. R., & Hugenholtz, C. H. (2019). Enhancing UAV–SfM 3D model accuracy in high-relief landscapes by incorporating oblique images. Remote Sensing, 11(3), 239. doi:10.3390/rs11030239
• Nikolakopoulos, K. G., & Kyriou, A. (2023). Evaluating a nadir and an oblique camera for 3D infrastructure (city) model generation. International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, XLVIII-1/W3-2023, 131–136. doi:10.5194/isprs-archives-XLVIII-1-W3-2023-131-2023
• Phojaem, T., et al. (2025). Evaluating UAV flight parameters for high-accuracy in road accident scene documentation: A planimetric assessment under simulated roadway conditions. ISPRS International Journal of Geo-Information, 14(9), 357. doi:10.3390/ijgi14090357
• Sanz-Ablanedo, E., et al. (2018). Accuracy of unmanned aerial vehicle (UAV) and SfM photogrammetry survey as a function of the number and location of ground control points used. Remote Sensing, 10(10), 1606. doi:10.3390/rs10101606
• Taddia, Y., Stecchi, F., & Pellegrinelli, A. (2020). Coastal mapping using DJI Phantom 4 RTK in post-processing kinematic mode. Drones, 4(2), 9. doi:10.3390/drones4020009
• Wackrow, R., & Chandler, J. H. (2008). A convergent image configuration for DEM extraction that minimises the systematic effects caused by an inaccurate lens model. The Photogrammetric Record, 23(121), 6–18. doi:10.1111/j.1477-9730.2008.00467.x