Key takeaways
- Decide who the end reader is before the format list is agreed. A superintendent, an estimator, a surveyor and a lawyer need different products from the same flight, and only one of them has CAD on the desktop.
- Two things make a deliverable unopenable: software nobody has, and a file too large for the machine or the pipe. Both are predictable before the flight and both are cheap to design around.
- Point clouds and full-resolution orthomosaics are the heavy items. A web viewer link, a decimated point cloud and a reduced-resolution image cover most of the people who only need to look.
- Ask for a PDF or web companion alongside every technical file. The technical file is for the one person who works in it; the companion is for the ten people who need to see it.
- A file that opens but carries no projection is still unusable. Ask for the coordinate reference in a sidecar or embedded, plus a short read-me naming every file.
- Request the native project file as well as the exchange formats. It is worthless to you today and it is the thing you need if you ever change contractors.
- Put the software your staff actually run into the RFP. A contractor who knows you are on a particular GIS or CAD platform can ship a file that opens the first time.
A client once paid for a full drone survey of a gravel operation, received every file on the scope list, and three weeks later had still not looked at any of it. Nothing was wrong with the data. The point cloud was 11 GB, nobody at the site had software that would open it, and the one person who did was at head office and had not been copied on the handover email. The survey was correct, delivered on time, and useless.
This is the least glamorous failure mode in aerial capture and one of the most common. It is also entirely preventable, because the question of who will open the files has a known answer before the drone leaves the ground.
Start with the reader, not the format list
Most scopes are written as a list of file types, because that is what a contractor's quote looks like. It is the wrong starting point. The same flight produces products for several different people, and each of them has a different tolerance for software.
- The superintendent or site manager. Wants to look at the site, point at something and measure roughly. Has a laptop, a phone and no specialist software. Needs a web viewer or a PDF.
- The estimator or engineering tech. Wants surfaces and volumes to work with. Has CAD or a civil package. Needs an exchange format that package reads.
- The surveyor or GIS analyst. Wants the full-resolution products with their projection intact. Has the software and the hardware. Needs the heavy files and the metadata.
- The accountant, the lawyer or the board. Wants a number and a dated picture supporting it. Needs a report, not a dataset.
Name those people during scoping and the deliverable list writes itself. The products themselves are described in drone survey deliverables explained; what follows is which of your own machines can open each one.
What each product needs to be opened
Roughly in order of how much software each one demands:
- Report and annotated imagery. A PDF. Everyone can open it, it is the most-read deliverable on almost every job, and it is the one most often left off the scope. What separates a usable one from a decorative one is covered in how to tell a good drone inspection report from a bad one.
- Web viewer link. A browser, and in some cases a login. No install, works on a phone, and it is usually the single highest-value item for the people who only need to look. Worth asking how long the link stays live and what happens when it expires.
- Orthomosaic. A georeferenced image, usually GeoTIFF. Any GIS or CAD platform will open it. General-purpose image viewers often will not, because of the size and the format, and even when they do they discard the geography. If somebody only needs to look at it, ask for a reduced-resolution JPEG or PDF alongside the GeoTIFF rather than sending a surveyor's file to a superintendent.
- Contours. DXF or SHP. These are the friendliest technical product: almost every CAD and GIS package reads them, the files are small, and a site person can be walked through one.
- Surface model. A triangulated surface. The exchange format matters here more than anywhere else, because civil packages differ in what they import cleanly. Name the package in the scope and let the contractor choose the format that lands in it.
- Point cloud. LAS or LAZ, and the heaviest item on most jobs. Free viewers exist and they are adequate for looking. Doing anything with a dense cloud needs real software and real hardware. If nobody on your team works in point clouds, ask whether you need one at all, or ask for a decimated copy for review and keep the full cloud archived.
- Video and raw imagery. Trivially openable and surprisingly large. Raw imagery is the input to the processing rather than a deliverable for most buyers, and it is mostly worth having for archival reasons.
File size is the other half of the problem
A format your software supports can still defeat you on volume. Three constraints bite in practice, and none of them are the contractor's to discover.
- The machine. Memory, not processor, is what stops a laptop opening a dense point cloud or a large ortho. A site laptop chosen for email will not do it.
- The transfer. A link to a download is fine from an office. From a camp with a satellite connection it is not, and the practical answer is sometimes a physical drive.
- Where it lives afterwards. If your document system has a per-file cap, or your IT policy blocks the sharing service the contractor uses, the data never reaches the people who need it. Ask for the delivery method before the job, not after the first email bounces.
The useful habit is to ask for an approximate total size at quoting time. A contractor who has flown comparable sites can give you a range, and the range tells you whether this is an email, a link or a drive.
Files that open and still do not work
Two near-misses are worth naming because they look like success.
The first is a file with no stated projection. A DXF of contours will open in any CAD package and sit at the wrong place on the earth, or at no place at all, if the coordinate reference was never carried or recorded. The fix is to require the coordinate reference system to be stated in writing and embedded or supplied as a sidecar for every georeferenced file. Which system it should be in, for Alberta work, is the subject of the coordinate system article.
The second is a folder nobody can navigate. Thirty files with processing-tool names, no read-me, and no indication which surface is the ground and which is the top of the pile. Ask for a one-page file manifest listing every file, what it is, its projection and its units. It takes a contractor ten minutes and it is the difference between a dataset and an archive.
Units deserve their own line in the scope. Metres and feet both appear on Alberta sites, sometimes on the same project, and a surface imported under the wrong assumption produces a plausible, wrong number.
The free-viewer answer, and its limit
You do not need to buy software to look at drone data. Free and open tools will open orthomosaics, contours, surfaces and point clouds, and for a buyer who needs to see rather than compute they are enough. The practical constraint is rarely the licence; it is that installing anything on a corporate laptop requires IT, and that takes longer than the survey did. If your environment is locked down, the web viewer and the PDF are not a convenience, they are the deliverable.
Where a viewer stops being enough is anything that has to be combined with your own data: comparing against a design surface, loading into an asset register, or measuring to a contract tolerance. That is work in your own platform, and it needs the exchange format chosen for that platform.
Ask for the native project too
Separately from anything you will open this month, ask for the native processing project or at minimum the raw imagery and the processing report. You will not use it. Its value is that it is the thing that makes the next contractor able to continue from where this one stopped, and the moment you need it is the moment the relationship has already ended. The handover mechanics are set out in switching drone contractors, and whether you are entitled to it at all depends on terms covered in data ownership and retention.
The three lines to put in the scope
Everything above reduces to three requirements a buyer can write without knowing anything about photogrammetry:
- Name your software. State the GIS, CAD or civil package your staff run, by name and version if you know it, and require deliverables in formats that open in it.
- Require a companion for every technical file. A PDF or web viewer version of each product, so the people who only need to look are not waiting on the one person with the licence.
- Require the metadata. Coordinate reference system and units stated in writing, embedded or in a sidecar, plus a one-page manifest naming every file.
Those three lines belong alongside the accuracy and compliance clauses in what to put in a drone survey RFP. They cost nothing and they are the difference between a survey that gets used and a survey that sits on a share.
If you are not sure which of your systems will take what, the fastest route is to tell a contractor what you run and let them propose the format list. That is a five-minute conversation at quoting time and it removes the most avoidable disappointment in the whole process.
