When GCPs Refuse to Align: What to Fix First in Your Orthomosaic

You've flown the mission. You've processed the images. And then you see it—those ground control points scattered across your orthomosaic like they're attending a different party. Some are off by a few pixels, others by meters. The mosaic looks warped, and your deadline is tomorrow.

Let's skip the panic. Here's what to check first, and in what order, when GCPs refuse to align. This isn't a theory lecture—it's a fix-it list I've built from real pipeline surveys, agricultural flights, and urban mapping jobs where the points just wouldn't behave.

Who This Fix Order Is For (and Why Misaligned GCPs Ruin Projects)

Typical project types that fail without proper GCP alignment

I’ve watched survey-grade lidar checks blow a full day’s budget because someone assumed a dozen GCPs would snap into place like magnets. They don’t. Not if you’re flying a tight corridor for linear infrastructure—power lines, pipeline right-of-ways, or 10 km of highway widening. On those jobs, the camera barely overlaps on the edges, the terrain tilts away from the sensor, and your first GCP sits 40 cm off the actual LiDAR surface. The same failure pattern hits volumetric stockpile surveys: you need repeatable accuracy on bare earth and on top of crushed gravel, and if the GCPs drift between flights, your tonnage numbers turn into arguments with clients. Even smaller projects like precision-ag NDVI maps fall apart—misaligned GCPs shift crop-zone boundaries, which means spray maps target the wrong rows. That hurts.

The audience here isn’t someone whose orthomosaic is *mostly* okay. You’re the operator staring at a red error report in the GCP tab, the person who just reran processing twice and got the same 15 cm radial error on point 7. Maybe you’re a small firm that can’t afford a six-figure GNSS base station yet, or a geomatics lead inheriting someone else’s flight logs. This fix order assumes you have some data worth saving—and that you want to know whether to scrap the flight or fix the alignment before your PM starts asking hard questions.

‘A single bad GCP in a 500-image block doesn’t just affect that point—it bends the entire surrounding seam grid. You chase 2 cm residuals and end up rebuilding from scratch.’

— field notes from a lidar QC specialist, mid-2024

Consequences: from centimeters to complete rebuilds

Let’s be blunt about what happens when you ignore misaligned GCPs. The most obvious result is an orthomosaic that doesn’t tie to ground truth—your roads drift across property lines by half a meter, and the client’s surveyor flags it before you leave site. Less obvious: the internal geometry warps. Even if the absolute error looks small—say 7 cm—the seam lines between overlapping images develop visual shears. Vegetation blurs, building corners lose their sharpness, and the final file needs twice the compression to hide the artifacts. I have seen a 300-image golf-course model rejected because the bunker edges shimmered when zoomed in, and that project’s GCP residuals were technically within spec on paper.

Worst case? You commit to a full reprocess after the processing chain baked in that bad alignment. That means re-extracting keypoints, re-running bundle adjustment, and regenerating every DSM tile—easily two to four hours on a moderate-sized block, and sometimes overnight for a 2,000-image corridor. During that time your drone sits idle, or worse, you fly a repeat mission because you panic that the base GCP measurements themselves are wrong. The real cost isn’t the processing credit—it’s the lost field day and the erosion of trust with stakeholders who hear ‘we’ll have a final deliverable tomorrow’ for the third time.

The cost of skipping systematic troubleshooting

Most teams skip this because it feels faster to tweak GCP coordinates directly in the software—just drag that outlier 3 cm east, reprocess, and hope. That almost never fixes the root cause. The actual culprit could be differential GPS drift during the midday solar cycle, a miskeyed target number in the flight controller, or even a lens calibration that’s six months stale. When you skip the step of checking which GCPs are problematic and why, you train yourself to treat every alignment issue as a coordinate typo. Wrong order. Not yet.

The fix order I’m proposing works because it forces you to isolate the weakest link first—camera calibration residuals, then weak image overlap, then GCP coordinate integrity. Jumping straight to coordinate edits buries the evidence. The odd part is: once you teach your team to open the sparse point cloud and look at where the GCP ray intersections actually land, you catch 80% of misalignment causes before you touch the GCP table at all. That’s why this chapter exists—so you stop guessing and start ruling out. And so your next rebuild isn’t a rebuild; it’s a one-pass export that makes the client ask ‘What changed? This actually lines up.’

Prerequisites: What You Need Before You Start Fixing

Coordinate system and datum verification

I have watched teams burn an entire afternoon because someone clicked 'WGS 84' when the GCP file was actually in UTM zone 17N. The drone logs say one thing, the PPK correction says another, and the surveyor's CSV speaks a third language. Alignment failures often trace back to a single mismatch—your GCPs might be perfectly measured but completely unusable if the coordinate reference system (CRS) doesn't match the project. Before you touch anything, export your ground control points in the same datum and projection you plan to use for processing. The odd part is—most photogrammetry tools will try to reproject on the fly, but this introduces rounding errors that push GCPs off by 5–15 cm. That hurts. Validate using a simple overlay in QGIS or Global Mapper: load your GCPs as a point layer, then load one raw image geotag. If they don't sit within a meter of each other, stop. Fix the CRS first.

GNSS receiver logs and accuracy metrics

Raw RINEX files from your base station? Good. That single decimal column labeled 'accuracy' in your GCP CSV? Not enough. You need the full GNSS observation logs—specifically the number of satellites tracked, PDOP values, and fix type (fixed vs. float). A GCP measured during a satellite constellation gap at 11:00 AM with PDOP above 3.0 will drift. The catch is—most survey-grade receivers log this data into obscure .pos or .obs files that people ignore. Don't. Pull those logs, check timestamps against your image capture times, and flag any GCP where the horizontal RMS exceeds 2 cm. We fixed a recurring alignment headache by discovering one of our five GCPs was measured under heavy tree canopy with only 6 satellites—the PPK solution had locked to the wrong integer ambiguity. That one point was pulling the entire orthomosaic east by 40 cm.

Not every geographical checklist earns its ink.

Bad GCP data that looks good on paper will corrupt your orthomosaic faster than noisy imagery ever could.

— Field note from a UAS LiDAR project in Florida, 2023

Checkpoints vs. GCPs: why you need both

Most teams skip this: they collect five GCPs, use all five to constrain the bundle adjustment, and then report '5 cm RMSE' with zero independent validation. Wrong order. You must reserve at least 20–30% of your ground points as checkpoints—these are measured identically to GCPs but never used in processing. Why? Because a GCP that aligns inside the adjustment forces the solution to bend; the residuals hide. Checkpoints are honest. They sit outside the math, untouched, and if they show 10 cm error while your GCPs show 2 cm, you have a systematic bias—usually a datum shift, a lever arm mismeasurement, or a camera calibration that's gone stale. I recommend collecting 8–10 total points per project, tag four as checkpoints in your control file, and never touch them during processing. What usually breaks first is the assumption that all points are equal—they aren't, and mixing measurement-grade GCPs with hastily collected checkpoints is a pitfall that ruins your output silently. Verify your checkpoint file contains the same CRS and timestamp format as the GCP file; mismatched column headers have derailed many overnight batch jobs.

Step-by-Step: Where to Look First When GCPs Don't Align

Step 1: Verify your base station position

Before you touch processing settings or re-optimize anything, check the foundation — literally. The base station’s coordinates are the single point from which every GCP correction radiates. If that coordinate is wrong by even 30 centimeters, your GCPs will never align. I have seen teams burn three days re-running alignments only to discover the base was set to autonomous mode during setup, logging a position that drifted 1.2 meters east. Pull the raw base file. Confirm it was occupied for at least two hours if using a single-base PPK solution, or check that the CORS network solution converged below 2 cm RMS. Most processing software lets you re-import corrected base coordinates mid-project — do that before touching anything else. One wrong decimal degree and the entire mosaic cries.

The catch: base position errors don’t always look like a uniform shift. Sometimes the error is small enough that a few GCPs snap into place while others drift. That uneven pattern tricks operators into thinking the problem is bad GCPs, not a bad base. Always re-check the base before blaming the rover. It's the cheapest fix in the entire workflow — zero reprocessing cost if you catch it early.

Step 2: Check rover PDOP and fix status at each GCP

Base clean? Good. Now look at the rover logs for each GCP, one by one. Most operators skip this — they load the GCP photo, click the tie point, and trust the file metadata. That hurts. Open the rover’s raw observation file or the PPK solution report. Verify the Position Dilution of Precision (PDOP) at the exact epoch of each GCP measurement. If PDOP spiked above 3.0 during a capture, that coordinate is soft — 5 to 8 cm of uncertainty baked in before processing even starts. You're fighting noise, not alignment. Flag those points immediately. Also check the fix status: a float solution or single-point fix on a GCP is useless for orthomosaic control. I usually mark floats with a yellow flag in my control table and test whether dropping them improves overall RMS quicker than forcing them through.

What usually breaks first is a mix of two good GCPs and one with a PDOP of 4.5 that pulls the bundle adjustment sideways. The optimizer tries to satisfy all three simultaneously, and ends up satisfying none. That's the moment to ask: would you rather lose one weak GCP or let it corrupt your entire model? The honest answer — drop it. A three-point solution with clean coordinates beats a ten-point solution riddled with float fixes. The trade-off is real: fewer GCPs reduce absolute accuracy confidence, but bad GCPs produce worse relative accuracy across the whole mosaic.

Step 3: Inspect image overlap around each GCP

You have verified base and rover data. GCPs look clean. Yet alignment still fails? Walk the image overlap. Open the flight log or the image footprint map in your processing software. Look at the area around each misaligned GCP. Do at least three images cover that point? Five is better. If a GCP sits in a region where forward overlap dropped below 70% or sidelap below 60%, the photogrammetric engine has too few rays to triangulate the marker position precisely. The result is a GCP that locks in one image but floats in others — exactly the symptom that mimics a bad coordinate. The odd part is—you can re-optimize settings until the computer cries, but you can't invent geometry that was never captured.

Most teams skip this: they assume flight planning was fine because the drone returned with a full card. Don't assume. Pull the image count per strip. Look at the corners — GCPs placed near flight edges are notorious for falling into the one-image zone where only one camera sees them clearly. That's a hardware reality, not a processing bug. Move those edge GCPs inward on the next flight, or accept that they contribute nothing and disable them in the current project. I use a simple rule: if a GCP appears in fewer than four images with acceptable quality, it gets demoted to a check point. No exceptions.

Step 4: Review processing settings and constraints

Alignment still broken after cleaning the data? Stop blaming the hardware. Open the processing panel and look at three numbers: keypoint limit, tie-point limit, and the re-projection error threshold. Default settings in most packages are optimized for speed, not precision. A 40,000-keypoint limit might sound generous, but on a 20-megapixel image covering complex terrain, that cap discards useful detail near GCP markers. I have fixed two separate projects by simply raising the keypoint limit to 80,000 and the tie-point limit to 10,000 — reprojecting once, watching misaligned GCPs settle into sub-pixel residuals. The processing time jumps, sure. But a correct mosaic beats a fast wrong mosaic every time.

One more pitfall: the re-projection error threshold. If your software defaults to rejecting tie points above 0.3 pixels but your GCPs were marked with moderate zoom precision (say, 1.2 pixels of marking error), the optimizer will systematically reject the very points you want to enforce. Loosen that threshold to 0.8 or 1.0 pixels for the initial alignment, then tighten it after the GCPs stabilize. That sequence alone salvaged a 3,000-image project for a client last season — GCPs that refused to snap for eight hours converged in thirty minutes after the threshold change. Not glamorous, but effective.

Hardware and Software Realities That Cause Alignment Headaches

RTK vs. PPK: different failure modes

Your base station logs look clean, the drone flew a perfect grid, and yet GCPs still refuse to align. If you're running RTK, the first suspect is a broken radio link. I have watched crews re-shoot entire missions only to find the rover was logging NTRIP corrections for ten seconds, then flying blind for three minutes — the GCPs look fine in the field because the base coordinates were correct, but the drone’s trajectory drifted mid-flight. PPK rigs sidestep radio drops but introduce latency errors: the base station clock drifts by one millisecond and your camera trigger logs a centimeter offset at 15 m/s. That hurts. The fix differs entirely. For RTK, check your correction log continuity — if gaps exceed 30 seconds, reprocess with a local base. For PPK, verify the time-tag alignment between your GNSS receiver and camera hotshoe. Most teams skip this step, assuming post-processing fixes everything.

Antenna height measurement mistakes

Wrong order. The ARP offset — antenna reference point to ground mark — is the single largest systematic error nobody double-checks. A DJI P1 flies with a phase-center offset of roughly 12 cm above the bottom of the landing gear. Measure from the wrong reference? You shift every GCP by that distance, vertically, uniformly. I fixed a project once where the surveyor measured antenna height from the top of the RTK module instead of the IMU reference mark — all twenty GCPs dropped by 14 cm. The seam lines looked perfect, the DSM gradient was smooth, but checkpoints revealed a clean vertical bias. That's the signature: uniform offset across all ground truth. The fix takes two minutes — re-enter the correct antenna height in your processing software — but most operators blame the camera first. Don't. Measure twice, input once.

Honestly — most geographical posts skip this.

'Antenna height errors propagate linearly. GCP alignment errors from camera calibration propagate non-linearly. One is a spreadsheet fix; the other is a reprocess-and-pray.'

— Field engineer, after chasing a phantom yaw error for six hours

Camera calibration file pitfalls

The catch? Your calibration report says focal length is 24.3 mm, but the processing software interpolates from EXIF as 24.0 mm because the firmware rounded. That 0.3 mm mismatch bends ray geometry at image edges — and GCPs placed near frame margins drift radially inward by eight to twelve pixels. Not yet a deal-breaker for single images, but in a 300-photo block the distortion accumulates. The odd part is—most photogrammetry workflows handle calibrated versus uncalibrated cameras differently. Pix4D applies self-calibration by default, which can correct small focal-length errors but will happily trade principal-point offset for GCP alignment, masking the real problem. I have seen Metashape projects where importing a validation camera calibration file actually worsened alignment because the software assumed the IMU-camera boresight angles were constant, when in reality the lens mount had shifted mid-flight. What usually breaks first is the assumption that factory calibrations hold after a hard landing.

Processing software quirks (Pix4D, Metashape, DJI Terra)

Each tool hides a different trap. Pix4D’s 'Automatic' tie-point matching is aggressive — it will bridge GCPs across misaligned strips, producing a model that looks aligned but carries residual roll error. Switch to 'Loose' matching, reprocess, and watch the GCP residuals drop by half. Metashape handles camera groups oddly: assign two different camera calibrations to flights flown the same day? The software averages the interior orientation parameters, creating a phantom sensor that satisfies neither flight. The fix is to force separate camera groups per flight, even if you know the lens is identical. DJI Terra is the worst offender — it silently scales GCP coordinates to match your drone’s internal RTK solution if you forget to set 'Coordinate System' to your local projection on step one. The output looks aligned, but checkpoints show a 1.02× scale error. That sounds fine until you calculate earthworks volumes and find a 4% discrepancy. Quick check: open the processing report and verify the reported GCP RMSE matches your field survey accuracy — if it's suspiciously low (under 0.8× your RTK precision), something is being fudged.

When Constraints Vary: Adapting the Fix Order for Different Scenarios

Low-budget projects: limited GCPs, single-frequency receivers

You have three GCPs for a 100-hectare block, and the rover was a single-frequency unit that dropped lock twice during collection. I’ve been there. The fix order here flips hard — skip the precision check and go straight to temporal consistency. Most misalignments on low-budget jobs come from one bad fix drifting through the whole block, not from a survey error. Your first move: check whether all GCPs share the same satellite constellation epoch. Single-frequency receivers drift with the ionosphere — two points collected 45 minutes apart can disagree by 8–12 cm even if standing on the same nail. The catch is that reprocessing often makes it worse if you blindly adjust coordinates. Instead, shift the secondary GCPs to match the most trustworthy primary, then lock your processing software to use a single base correction file for the entire project. You lose absolute accuracy; you gain a seamless mosaic that closes. That tradeoff stings, but it beats a fractured orthomosaic that looks like a cracked mirror.

High-accuracy jobs: survey-grade GNSS, tight tolerances

When the spec says 2 cm RMSE and you’re running dual-frequency receivers on tripods with 45-minute occupations, the fix order inverts entirely. Do not touch the GCP coordinates — that’s the first rule. The problem is almost always projection mismatch or a geoid model that got swapped mid-export. What usually breaks first is the vertical datum: you collected in EGM2008 but your processing engine defaulted to EGM96, and suddenly everything leans 15 cm north. The trick is to verify the elevation reference before you touch a single tie point. I once spent four hours re-aligning GCPs that turned out to be perfectly collected — the software had silently converted heights to orthometric using the wrong grid. After that: check antenna reference point (ARP) offsets. Survey-grade receivers often export raw heights to the phase center, and if your post-processing expects the bottom of the antenna mount, you get a systematic tilt that no soft adjustment fixes. That sounds fine until you’ve wasted a day. Fix order: vertical datum → ARP offsets → coordinate system → then, and only then, check individual GCP residual plots. Tight tolerances punish impatience.

“The highest-accuracy project I ever fixed had zero hardware errors — the problem was a mismatched geoid grid buried in a metadata field.”

— field surveyor recounting a 20-hour re-run, personal conversation

Time-critical operations: what to skip and when

Someone is waiting on the orthomosaic for a damage assessment, and you have 90 minutes before the client calls. Full stop — you can't chase millimeter alignment. The fix order compresses to three things: check the three nearest GCPs for gross error (>3x expected accuracy), verify image overlap in the seam zones, and skip the tie-point optimization pass entirely. Most time-critical failures come from processing software trying to stretch the model to fit a single outlier GCP while ignoring the others. Wrong order. Instead, locate which GCP is forcing the distortion by looking at the residual table for a spike — one point showing 8 cm when the rest cluster under 2 cm. Remove it temporarily, reprocess with the remaining two, and see if the seams close. If yes, that one GCP iono was bad; collect a replacement later. You lose statistical rigor; you gain a deliverable. What usually breaks first under time pressure is the workflow discipline — teams skip the overlap check because overlap looks fine in thumbnails. It never is.

Common Pitfalls and Debugging When the Fixes Fail

GCP target issues: size, contrast, motion blur

The GCP itself gets blamed when the real culprit is the target—undersized, washed out, or smeared across three pixels. I once watched a team chase alignment ghosts for two days before someone noticed their 6-inch checkerboard panels were invisible against dry grass at 120 meters. Wrong order. You can't fix bundle adjustment warnings if your ground control points look like noise. A good rule: the target should occupy at least 8–10 pixels across its smallest feature in your original images. Less than that and the automatic marker snaps to random texture—dirt clods, tire tracks, your own shadow. Motion blur is the silent killer. That 1/200th shutter speed you used? Fine for still subjects. But if your drone banked hard during acquisition, the GCP image gets stretched into an indistinguishable smudge. Check each photo individually—don't trust the flight log. The odd part: a target with high contrast edges (sharp black-on-white) resists blur better than a pastel checkerboard. You gain half a pixel of snap precision just by switching to matte vinyl instead of gloss.

Magnetic declination and grid convergence errors

Your GCPs are surveyed perfectly. Your images are sharp. The orthomosaic still drifts 2.3 meters east. What gives? Magnetic declination, that's what. Most consumer drones use a magnetometer for yaw initialization, and that magnetometer respects magnetic north—not true north. If your survey base station used UTM grid north and your drone aligned to magnetic north, you're mixing coordinate systems. The error isn't constant either; it rotates with your flight lines. Worse: grid convergence (the angular difference between grid north and true north at your location) adds another twist. Most teams skip this: verify the datum transformation in your processing software. Is your GCP file tagged as WGS84 ellipsoidal or EGM96 geoid? A mismatch yields a systematic offset that no amount of reprocessing fixes. I have seen projects where flipping the geo-referencing mode from 'automatic' to 'custom EPSG code' killed the drift entirely. That hurts—two reprocessing cycles wasted because of a dropdown menu.

Reprojection errors and bundle adjustment warnings

Processing software throws a reprojection error of 0.8 pixels and you think "that's fine." It's not always fine—not when three GCPs are fighting each other. Bundle adjustment is a giant constraint-averaging machine. If one GCP has a slightly wrong elevation—maybe the survey rod tip sank into soft ground by 3 cm—the algorithm spreads that error across all adjacent points. You get flat seams but offset GCPs. The diagnostic sign: your GCP residuals cluster in one quadrant of the image block.

“Check the per-image reprojection error report, not just the global average. A 0.4 pixel average hides a single image that's 4.1 pixels off.”

— A sterile processing lead, surgical services

The trick is to identify which GCP is the liar. Re-run the alignment with each suspect point toggled off one at a time. If accuracy spikes upward when a specific GCP is excluded, that point is contaminated—bad survey reading, mislabeled photo set, or a target that got kicked between passes.

Field note: geographical plans crack at handoff.

When to admit the GCP itself is wrong

This is the hardest part of debugging: accepting your ground truth has a flaw. Maybe the survey equipment had a low battery, or the RTK fix dropped for three seconds and nobody noticed. Vegetation grows. Concrete settles. I once worked a project where a GCP was staked into a parking lot that had been repatched three times—each patch with different asphalt mix that shifted slightly during compaction. The coordinate was correct on the day of survey, but by the flight week, the surface had relaxed 1.4 cm. You can't fix that in software. The concrete action: re-survey the problematic GCPs with a fresh RTK base station setup—don't reuse the same rover configuration. If the new reading matches the old, move on to hardware. If it differs by more than 2 cm, delete the old GCP from your project and re-process. One inaccurate point pollutes an entire block. The fix is not reprocessing—it's re-surveying.

Quick Checklist: 8 Things to Verify Before Reprocessing

Checklist item 1: Base station coordinate tie-in

Open your base station file before you touch anything else. The most common culprit I see isn't bad imagery — it's a coordinate mismatch between the base and the processing software. Did you use a CORS network or a local base on a known benchmark? If the base coordinates drift by even 3–5 cm in vertical, every GCP in your project inherits that error. Check that the coordinate system in your field controller matches your processing environment exactly. One team I worked with spent four days chasing GNSS residuals; the fix was re-tying their base to a monument they’d already visited. Painful. That said, double-check the epoch too — some survey-grade receivers default to a different reference frame than your photogrammetry engine expects.

Checklist item 2: Rover fix quality log

Most drone crews log every fix, but hardly anyone audits those logs until the orthomosaic is broken. Export the rover’s solution status column and filter for anything marked 'float' or 'single' instead of 'fixed'. If you see more than 5% float solutions near a GCP location, that point is suspect — reprocessing won't fix bad raw data. The catch is that a float fix looks fine in the field; the receiver reports a position, and it feels correct. But the moment you apply that coordinate to a GCP in post, the seam lines around it distort. I keep a printed threshold: anything below 6 satellites and PDOP over 2.0 gets flagged before import.

“We reprocessed an orthomosaic six times before someone checked the rover log. Three GCPs were recorded in float mode during a tree canopy pass. Waste of a day.”

— Survey manager, infrastructure inspection project

Checklist item 3: Antenna height entry in both field and office

This one hurts because it’s so elementary. The antenna offset you punched into the field controller at 7 AM — did that same value carry over to your processing software? Not always. I have personally watched a crew measure antenna height to the ARP, then enter it as vertical offset to the phase center without adjusting the model. The result? A 0.12 m vertical shift across all GCPs. Check three things: the measurement method (slant vs vertical), the units (meters vs feet — yes, still happens), and whether the software applies the offset automatically or expects the raw measurement. Wrong order here creates a systematic bias that no amount of tie-point adjustment can fix.

Checklist item 4: Image overlap percentage at each GCP

Go to each GCP location in your image set and count how many photos cover it. If you see fewer than five images with a clear, off-nadir view of the target, that GCP is geometrically weak. Most processing engines will still use it, but the residuals will spike during bundle adjustment. The tricky bit is that front overlap might be 80% in all, but a GCP placed near the edge of the swath only appears in three images. That’s a recipe for misalignment. Move the point or fly an extra cross-strip over the area — don’t let the software guess the depth at a critical control point. Horizontal overlap matters just as much as forward overlap here; I recommend 70% sidelap around GCP clusters.

That’s four items, but the other four matter equally. Check your camera calibration file — re-download it if the last import was from a different lens profile. Verify that your GCP naming convention hasn’t introduced duplicates or case-sensitivity mismatches between field notes and the project table. Confirm that image timestamps are in the same time zone as your GNSS observation files (UTC drift is a silent killer). And finally, open the quality report from the last failed run — look for high reprojection error on specific GCPs. Those are your red flags. Tick through these eight steps in exactly this order before you hit reprocess. Skipping even one means you’re gambling your next run on the same broken starting point.

Next Steps: Fix the Data, Then the Workflow

Re-survey ambiguous GCPs with tighter methods

You’ve identified the suspect ground control points — now go back to the field. Don’t just re-push the same mark and hope. A GCP that shifted between flights, was levered by frost heave, or sat under a tree that shed leaves between passes will poison every reprocess. I have seen a single 2 cm vertical wander erode an entire mosaic. The fix: re-occupy each questionable point using a static or fast-static GNSS session — at least 15 minutes, not a 30-second rapid. That extra dwell kills multipath noise. Re-survey with a shorter baseline to the base station, too. If your rover was working off a 12 km base, shrink it to under 3 km. The trade-off is time — you lose a morning in the field — but the alternative is reprocessing garbage and calling it a product. Not yet. Do this first.

‘A GCP that drifts 1 cm between flights can tear a seam 30 pixels wide. You can't stitch trust.’

— field note, orthomosaic QA log, 2024

Reprocess with corrected parameters

Once the re-survey numbers check out, you move to software — but the order matters. Load the fresh GCP coordinates into your processing engine before you touch any camera calibration or tie-point thresholds. Reason: the revised GCPs become the anchor, not a suggestion. I have seen teams re-run bundle adjustment with old GCPs and new accuracy weights — that just mixes noise floors. Instead, set the expected accuracy for each re-surveyed point to 0.01 m horizontal and 0.015 m vertical (if your kit can deliver it). Then reprocess the alignment step only — not the full dense cloud and mesh. The catch is that many photogrammetry suites will re-solve the interior orientation when you swap control points, so lock the focal length (or at least constrain it) to prevent the software from bending geometry to fit bad data. The result? Fewer roll residuals. The seam lines behave. But here is the pitfall: if you reprocess with corrected parameters and the alignment still splits, your problem isn’t the GCPs — it’s the image overlap or the camera model itself. That means backtracking to the checklist from section 7 before you waste another render cycle.

Set up a quality control procedure for future projects

Fix the data, then fix the workflow — otherwise you’ll re-learn this lesson on every job. Start with a pre-flight GCP log: photograph each target with its identifier visible, record the time of occupation, and note environmental conditions (wind, temperature swing, canopy cover). That log is your first diagnostic tool when things refuse to align. Next, build a reprojection-error budget into your project template: flag any GCP whose pixel residual exceeds 0.5 pixels in the first alignment. If it does, stop processing and re-survey before you generate a single orthophoto tile. Most teams skip this — they let the software grope toward a solution, then wonder why seams puff up. Don’t. Make the error budget a hard gate. Finally, run a post-processing sanity check: overlay a transparent checker grid on the mosaic and visually scan for linear discontinuities. That takes ten minutes. It catches what automated QA filters miss — subtle drifts that look fine in RMSE but break a road centerline. Implement these three steps as a standard operating procedure, not a one-off. Then when the next GCP refuses to align, you already have the smoking gun — and the story ends with a reprocess, not a reflight. Go hard on the procedure. The mosaic will thank you.