Key takeaways
- Your deliverables are not your data history. A folder of PDFs and orthos does not let a new contractor continue a measurement series; the surfaces, control and datum behind them do.
- The single highest-risk item is the coordinate reference: datum, realisation, epoch and geoid model. A new vendor using a different one produces a surface that looks fine and sits at a different elevation.
- For stockpiles, the base surface is the asset. If the incoming contractor builds a new base, the next volume is not comparable to any previous one, and the difference is base definition rather than material movement.
- Ask for the base station setup, not just the data: the published coordinate used, how it was derived, and whether the site has a permanent mark. An uncorrected averaged position shifts every survey tied to it.
- Raw imagery plus flight logs plus ground control coordinates is the reprocessable set. With it a new contractor can rebuild history on their own pipeline; without it, history is frozen as pictures.
- Processing project files are usually the one thing you will not get, and that is normal. Design the handover around open formats and raw inputs instead of fighting for a vendor's working files.
- Time the switch to a measurement cutoff, and if the stakes are high, have both contractors fly the same day once. One overlap flight converts an unexplainable step change into a known offset.
Changing drone contractors is a straightforward commercial decision and it happens for ordinary reasons: price, responsiveness, a vendor that outgrew small jobs, a procurement cycle that requires a retender. The part that goes wrong is not the new contractor's work. It is the join.
The usual symptom appears a month or two after the switch. A stockpile that has been tracking sensibly for two years reports a volume that does not fit the pattern. Nothing on the ground explains it. Production records say one thing and the new survey says another, and now someone has to decide which number goes in the report. The cause is almost never bad flying. It is that the new survey was built on a different foundation than the old one, and nobody wrote the foundation down.
That is preventable with a handover list, and the list has to be asked for before the outgoing contractor's final invoice is paid, because afterwards there is no leverage and often no one to ask.
What actually breaks at a vendor change
Four things carry a measurement series across time, and all four are invisible in the deliverable:
- The coordinate reference the survey is tied into, including the vertical datum and geoid model.
- The ground truth: surveyed control, how it was established, and whether the site has reusable marks.
- The base surface that volumes are computed against.
- The method conventions: toe definition, boundary, what gets excluded, and the density factor used to convert a volume to a tonnage.
A new contractor given only orthomosaics and PDF reports has to re-derive every one of those from scratch, and each re-derivation is a defensible decision that differs slightly from the last one. Stack four of them and you get a volume step that looks like material appeared or vanished.
The handover list
Ask for these in writing, as files, before the relationship ends.
Raw inputs
- Raw imagery for the most recent surveys, with the camera's original file names and embedded position tags intact. This is the one item that makes history reprocessable rather than frozen.
- Flight logs for those same missions.
- Base station observation files if a local base was used, in a readable format, one set per survey date.
- The coordinate of the base, the value that was actually entered, plus a plain statement of how it was obtained. A published mark, a post-processed solution and a two-minute averaged position are three very different pedigrees, and only one of them is repeatable.
Control and datum
- Ground control coordinates as a text or CSV file, with the datum and vertical reference named in the file or alongside it.
- Named datum, realisation, epoch and geoid model. Not "NAD83". The specific realisation and epoch, and the specific geoid used to convert ellipsoidal height to the orthometric height the project works in.
- Whether the control marks are still in the ground. Semi-permanent marks on a long-running site are worth more than the file, because they let a new contractor tie into the same points rather than a copy of them.
- Check point results from previous surveys, which tell the new contractor what accuracy the series has actually been holding.
If any part of that is unclear, the coordinate system article explains why a datum mismatch shows up as a clean, constant and entirely invisible shift in every elevation on the job.
Surfaces and volumes
- The base surface as a file, not a screenshot and not a description. A triangulated surface, a point set or a DEM with its coordinate system embedded.
- The boundary or stockpile footprint polygons used for each pile, with their names.
- How the toe was defined, and whether it was redrawn each survey or held fixed.
- The density factor applied to convert volume to tonnage, and where it came from.
- Point clouds in LAS or LAZ with the coordinate reference embedded, for at least the recent history.
On an aggregate site this section is the whole ballgame. A reconciliation against the scale house only works if the base surface and the density factor stay put, which is the point the volume versus tonnage article turns on.
Deliverables in formats that outlive the vendor
- Orthomosaics as GeoTIFF with the coordinate system written into the file.
- Surfaces and contours in an exchange format your engineer can read, not only in the format of whichever desktop package the vendor happens to own.
- Processing reports for each survey, which record the camera, the overlap, the control used and the residuals.
- Anything shared only through a web portal, downloaded. Portal access ends with the contract. If three years of history lives in a vendor's cloud viewer, it lives there until the day the account closes. Get it onto your own storage while the account is still live.
The deliverables article covers what each of these files is for; here the point is simply that formats tied to one vendor's software are a liability at handover.
The one thing you probably will not get
Photogrammetric project files, meaning the processing software's internal working state, are usually not handed over, and it is reasonable that they are not. They encode the contractor's methodology, they are often tied to a licensed product the new contractor does not run, and they are large.
This is not a loss worth fighting over, because raw imagery plus control plus a processing report lets a competent new contractor rebuild the result on their own pipeline, which is better than inheriting a project file they cannot open. Write the handover clause around raw inputs and open-format outputs and the project file stops mattering.
Time the switch at a cutoff
Switching mid-period is where the unexplainable number comes from. A cleaner sequence:
- Close the period with the outgoing contractor. Take the final survey on the old setup, with the old base surface, and let it be the closing balance.
- Hand over before the next flight, not after. The new contractor needs the datum, the base surface and the control before they plan, because those are inputs to their flight, not post-processing choices.
- Have the incoming contractor state in writing what they are adopting. Same datum, same geoid, same base surface, same footprints, same density factor. If they intend to change any of them, that is a decision to take deliberately and document, not to discover.
- Overlap once if the stakes justify it. Both contractors fly the same site within a day or two. The difference between the two results is then a measured offset rather than a mystery, and you can decide whether to carry it, correct for it, or re-baseline the series.
- Re-baseline openly if you re-baseline at all. Sometimes the new contractor's setup is genuinely better and the right call is a fresh baseline. That is fine, as long as the report says so and the series is marked at the break, rather than presenting a discontinuity as a month's production.
Writing the next contract so this does not recur
The handover problem is cheap to solve in advance and expensive to solve afterwards. Four clauses do most of the work:
- Raw data delivery on a schedule, not on request at termination. Raw imagery, logs and base observations delivered with each survey, to your storage, means there is no handover event at all.
- Named coordinate reference in the contract, including geoid model, so it is a specification rather than a vendor preference.
- Base surfaces and footprints as client property, delivered as files in named formats.
- A handover obligation with a deadline, listing the items above, triggered by notice of termination or non-renewal.
Those are different clauses from the ownership and retention terms that govern who may keep and publish the imagery, which the data ownership article covers. Ownership tells you the data is yours. The clauses above are what make it usable by somebody else.
If you are partway through a retender now, the useful move is to ask the incumbent for the handover list this week, while they are still invested in a good reference. It is a short email, and it is the difference between a vendor change and a restarted measurement history.