Drone survey data recovery is not the same task as recovering footage: what is at risk is not a set of images. It is a georeferenced dataset whose value comes from the relationship between each photograph, the position it was taken from, and the camera’s orientation at that moment. A recovered folder of nine hundred ungeotagged JPEGs is not a deliverable. It is raw material for a re-flight.
The rule that follows is uncomfortable for anyone trained on photography: in a survey, the metadata matters more than the pixels, and most recovery tools are built to save pixels.
Why a survey card is not a camera card
A mapping sortie is not a photo shoot. A single flight produces hundreds to several thousand frames, captured on a fixed interval or a distance trigger at a constant altitude, with overlaps specified in advance. The result is deliberately redundant: 80 percent forward and 60 percent side overlap means every square meter of ground appears in at least nine images, which is what lets photogrammetry reconstruct depth.
That redundancy makes a survey dataset more robust to small losses than any other kind of photography, and it is why the loss that actually hurts is rarely a single file.
| Mission type | Typical frame count | Overlap | Consequence of a missing frame |
|---|---|---|---|
| Nadir mapping grid | 400–2,000 | 75/60 to 80/70 | Usually absorbed by neighbors |
| Corridor or linear inspection | 200–800 | 70/50 | Visible gap risk near low-texture surfaces |
| Facade or vertical inspection | 300–1,500 | 70/60 | Higher risk; fewer viewing angles per point |
| Oblique mapping block | 1,000–4,000 | 70/60 | Low risk per frame, high risk per flight line |
| Thermal or multispectral | 300–2,000 | 75/65 | No substitute: a missing band is a missing layer |
How imagery, POS data and IMU data fit together
Every frame in a modern survey dataset is accompanied by three separate records of where it was taken, and they live in different places. Recovery tools do not treat them equally, and that asymmetry is the heart of the problem.
| Data | Where it lives | Written by | Recoverable by carving? |
|---|---|---|---|
| GNSS position per frame | XMP block inside each JPEG | Camera firmware | Only if the whole JPEG including its tail is recovered |
| Orientation and timing | .MRK file, plus TimeStamp.MRK | RTK module | No; metadata file, not an image |
| Raw satellite observations | .obs / .bin RINEX files | RTK module or base station | Sometimes, as a block-level file |
| Camera attitude and velocity | Flight log (.txt, .DAT) at 10 Hz | Flight controller | Only from the aircraft or the app |
| Precise base station position | RINEX from the base, or an NTRIP log | Base receiver | Depends on the service used |
The first row is what makes this fragile. In DJI’s workflow a frame’s position is embedded in the image’s own XMP, so a full-fidelity recovery of the JPEG carries the position with it. A carver scanning by signature recovers from FF D8 FF to the first FF D9 it finds, and a JPEG whose XMP packet was damaged can be recovered as a valid image with no position at all. The scan reports success; the dataset reports a problem three hours later, when the processing software builds a model in arbitrary coordinates.
The second row has no image to hide in. A .MRK file is pure metadata, and there is no way to carve it out of a JPEG. If it is gone, the positions are gone with it unless they can be reconstructed from the flight log.
The counterintuitive part: your pixels do not need their tags
This is where the picture improves, and it is the most useful thing to understand about survey recovery.
Photogrammetry does not georeference using EXIF or XMP. It matches features between images by comparing pixels and solves for camera positions from those matches. Tags initialize the solution and fix the absolute coordinate frame. Strip the position tags from a thousand images and the bundle adjustment still runs, because the tie points come from the pictures themselves.
What you lose is the absolute reference. The point cloud and orthomosaic remain internally coherent, and they float in an arbitrary coordinate system with no relationship to the ground. That is a serious problem for a deliverable, and it is not a loss of image data.
It also means the repair path is well defined. Three options exist, in ascending order of cost:
- Rebuild absolute positions from the flight log. Flight controllers log position, attitude, and velocity at roughly 10 Hz, enough to assign an approximate position to every frame by timestamp. Accuracy will not match RTK, typically landing in the meter range rather than the centimeter range, but it re-establishes ground coordinates. The recovery of flight logs from the aircraft covers where those logs live, and the extraction procedure for log files is the mechanical step.
- Re-derive positions by PPK. If the aircraft recorded raw observations and the base station data survives, post-processed kinematic correction can rebuild centimeter-level positions without a re-flight. This depends entirely on whether the
.obsfiles and base RINEX were preserved. - Re-establish scale and reference with ground control. If control points existed on site and their coordinates are known, a model built from untagged images can be fitted to them. This requires the dataset to be geometrically complete, so it is not a substitute for recovering missing frames.
The consequence for recovery ordering: preserving the metadata files is worth more per byte than preserving the images. If you have limited time and a partially readable card, copy the small metadata files first. The .MRK, .obs, .bin, and .SRT files together are a rounding error in size next to the imagery, and they are the part that cannot be recreated.
What a missing image costs, and what a missing line costs
With 80/60 overlap, a single missing nadir frame is genuinely invisible in the output. The nine neighbors that already cover that ground are sufficient, and the bundle adjustment absorbs the loss.
The costs appear at the edges of the block and along linear features:
- One missing frame at the block edge or corner. Real cost. Edges are the least redundant part of any block, and this is where a hole in the orthomosaic appears first.
- A run of missing frames along a flight line. A strip of missing coverage, and in a corridor mission a gap in the deliverable rather than a minor artifact.
- A whole missing flight line. Interior accuracy degrades around the hole and the orthomosaic has a void. This is a re-flight in almost every case.
- Missing frames over a low-texture surface such as water, fresh asphalt, or a sanded roof. Neighbors that theoretically cover that ground frequently fail to match on it, so redundancy on paper is not redundancy in the solve.
When a re-flight is mandatory
The honest answer covers a shorter list than clients expect and a longer list than operators hope. The criteria are about the deliverable specification, not the file count.
| Situation | Re-flight needed? | Why |
|---|---|---|
| A few scattered frames missing inside a high-overlap block | No | Redundancy covers them |
| One or more frames missing at the block boundary | Usually | Boundary redundancy is lowest where it is most needed |
| A partial or full flight line missing | Yes | Coverage gap and internal accuracy loss |
| Positions lost, flight log and PPK data both available | No | Rebuild the georeferencing and reprocess |
| Positions lost, no log and no base data | Yes | No way to place the model on the ground |
| GCPs on site and dataset geometrically complete | No | Control points re-establish absolute reference |
| Thermal or multispectral band missing | Yes | No replacement source for that layer |
The rule worth stating plainly to a client is that a deliverable with a patched or interpolated hole is not the same deliverable. If a re-flight is chosen, say so. If a patch is chosen, disclose it. An orthomosaic with a synthetic fill that passes visual inspection can still fail a volume calculation, and that failure lands on the operator.
Working the recovery in the right order
The order of operations for a survey card differs from a normal photo card in one important way: metadata first.
- Stop flying the aircraft and stop writing to the card, and set the write-protect switch if the card has one.
- Image the card before anything else. Every subsequent attempt reads the image rather than the original, which matters because a survey card is expensive to reproduce. The rationale for imaging before recovery applies with more force here than anywhere else.
- Copy all metadata files first, before the images, because they are the irreplaceable part.
- Recover images with a tool that preserves folder structure and full file contents, including XMP, rather than a signature carver that stops at the first end-of-image marker.
- Check that the XMP positions survived by reading one recovered frame’s tags before processing the whole set.
- Reconcile frame count against the flight plan. The expected number of frames can be calculated from flight time and trigger interval, so a shortfall is measurable rather than approximate.
- Decide once, with the criteria above, whether to reprocess or re-fly, and communicate the decision to the client at that point rather than after a failed processing run.
If the sortie was interrupted rather than the card damaged, the picture is usually better. A battery that sagged below the recording threshold mid-flight produces a truncated last file rather than a corrupt card, and the behavior of recording under battery voltage sag explains how that failure differs from a media fault. For background on how the media and the file formats in a survey workflow interrelate, the overview of drone storage media is the reference, and if the shoot also included video for a client deliverable, the container and codec reference for drone video covers the clips.
If the recovered images will not open at all, the problem has moved from metadata to file integrity, and the workflow for recovering photos from a card is the direct route. If they open but carry no capture data, the metadata restoration guide covers what can be rebuilt from a neighboring frame and which tags should be left blank rather than reconstructed by guesswork.
Frequently Asked Questions
One photo is missing from a 900-image survey. Do I need to re-fly?
Almost certainly not. At 75 to 80 percent forward overlap, every point on the ground appears in several images, and the bundle adjustment handles a scattered missing frame without a visible difference. Re-flight decisions are driven by missing coverage at block edges, whole missing lines, or lost positioning data.
The images recovered but their positions are gone. Can the survey still be delivered?
Yes, if the flight log or the base station data survives. Positions can be rebuilt from the flight log at roughly meter accuracy, or in the centimeter range by PPK if the raw observations and base RINEX are intact. Without either, the model can be built but cannot be placed on the ground.
Why did my recovery tool return photos that are missing their geotags?
Because it recovered by file signature rather than by file system. A signature carver writes from the start-of-image marker to the first end-of-image marker it encounters, which can exclude a JPEG’s XMP packet if that portion was damaged or lies beyond the marker. A structure-aware recovery is the fix.
Is a partially recovered survey usable for volume calculations?
Only with a disclosed tolerance. Volume and area figures depend on the completeness and internal consistency of the point cloud, so a patched region produces numbers with unknown error. If the dataset has a coverage gap, state it, and let the client decide whether a re-flight is cheaper than the uncertainty.