Getting Drone Deliverables Into the System You Already Run

A drone survey arrives as a set of files. Whether it turns into anything useful depends on a question that often goes unasked until the data is already on the server: can the people who need this actually open it in the software they already have?

This goes wrong more often than accuracy does. The capture is fine, the measurement is fine, and the client cannot load the layer, or loads it and finds it sitting in the wrong place. From the client's chair those two outcomes are indistinguishable from a bad survey. They are not. They are configuration problems, and nearly all of them are preventable with four or five sentences in the scope before the flight.

What the deliverables actually are

Three products cover most commercial work, and each one behaves differently once it reaches your system. The full list and what each is for is set out in drone survey deliverables explained.

• An orthomosaic is a georeferenced image. In GIS terms it is a raster. It usually arrives as a GeoTIFF, which carries its own georeferencing inside the file, or as tiles. It is the easiest product to load and the largest one.
• A surface is elevation. It arrives either as a raster of the same kind, where every pixel holds a height, or as a triangulated surface for CAD. The raster form goes into GIS; the triangulated form goes into civil design software. Which one you need depends entirely on what you are doing with it, and the difference between a surface of the top of everything and a surface of the ground is the DSM and DTM distinction.
• A point cloud is the raw measured geometry, usually delivered as LAS or its compressed form LAZ. It is the most flexible product, the largest, and the one most likely to defeat an office computer.

Contours, volumes, polygons and annotated findings sit on top of those three and are usually small and easy. The friction is in the three above.

Name your software in the scope

The single most useful sentence a buyer can put in a drone survey scope is which program the output has to open in, by name and version. Not "GIS compatible" and not "CAD ready", because those phrases are satisfied by formats that will not help you.

Some pairings worth knowing:

• Esri products and QGIS take GeoTIFF rasters, shapefiles and GeoPackage vectors, and LAS or LAZ point clouds. Shapefile is the universal lowest common denominator for vectors and has real limits on field names and file size; GeoPackage is the better modern choice if your software takes it.
• Civil design software such as Civil 3D, MicroStation or 12d wants a triangulated surface and CAD linework rather than a raster of heights. Ask for the surface in the exchange format your package imports, and for the linework as DWG or DXF at a stated version, because a DWG written for a newer release will not open in an older one.
• Asset and work order systems usually do not take any of it. What they take is a link, a coordinate and a document reference. For those, ask for the capture to be published to a viewer and give the asset record the link rather than the file.
• Office software takes PDF and images. A one page PDF plan and a set of labelled JPEGs is a legitimate deliverable for the people who only need to see the finding, and it costs nothing to add.

Matching the deliverable to the people who will open it is a separate decision from choosing the accuracy, and it is covered from the staffing side in who on your team can open the deliverable.

Ask for the projection by name, and ask for the file

A georeferenced product carries instructions about where on earth it belongs. If those instructions are missing, or are written in a system your software does not expect, the layer lands somewhere else. The fix is to be specific in the scope about three things:

• The horizontal coordinate system, named. Not "UTM" but the specific zone and realisation, or the 3TM meridian, or the site grid your drawings are on. Which one is right for an Alberta project, and what happens when the wrong one is chosen, is the subject of which coordinate system your drone survey should be in.
• The vertical datum, named, with the geoid model stated. Heights are the half of the problem that gets forgotten, and the mechanics are in vertical datum and geoid.
• A projection definition alongside every product. For rasters this is usually embedded, but ask anyway. For shapefiles it is a separate small companion file that is easy to lose in a zip, and a shapefile without it is a layer with no home. For point clouds, ask that the coordinate reference be written into the file header.

The matching request to make of your own side is to find out what your existing data is on before the scope is written. The target is to match what you already have, not to receive the most modern thing available.

When the layer lands in the wrong place

This is the most common support call after a delivery, and the symptom tells you the cause. Before assuming the survey is wrong, read the pattern:

• The layer is thousands of kilometres away, or near zero latitude and longitude. The projection definition is missing or unread. Your software is treating projected coordinates as degrees or vice versa. Nothing is wrong with the data.
• The layer is a consistent distance from everything else, in a consistent direction, with correct internal shape and scale. A horizontal datum or zone mismatch. Reprojectable.
• Everything is consistently high or low by the same amount, with correct slopes and correct volumes. A vertical datum or geoid mismatch. This is the pattern that produces a cut and fill map showing uniform underbuild across the whole site, including on ground nobody touched, and it is described in detail in comparing an as-built against a design surface.
• The offset varies across the site, or the shape is distorted. Now it may be a real accuracy problem, or control that was held on the wrong points. This is the one worth escalating.

Real error is noisy and varies. A clean uniform offset is a bookkeeping problem, and the data behind it is usually fine.

The file size problem

Nobody warns buyers about this one. A full resolution orthomosaic of a large site and a dense point cloud are both capable of making a normal office computer unusable, and the staff member who is told to open it concludes the data is broken.

Three requests that solve it:

• Ask for overviews or tiles on the raster. A raster built with internal overview levels, or delivered as a tiled set, draws at the zoom level you are looking at rather than loading everything. It is a processing option, not an extra product, and it costs the contractor almost nothing to produce.
• Ask for a thinned point cloud for daily use. A decimated copy for browsing alongside the full density copy for measurement. Keep both; use the small one for anything that is not a measurement.
• Ask for a published viewer for everybody else. Most of the people who want to see a capture want to look at it, scroll around it and maybe measure one distance. A browser-based view serves them without putting a single large file on anybody's desktop, and it is the right answer for executives, councils, lenders and subcontractors.

Making it stick after the first delivery

A capture that gets loaded once and then lost is a recurring cost with no accumulating benefit. Four habits that prevent it, none of them technical:

• One known location for the data. Not an email attachment and not a personal drive.
• A naming convention with the date in it. Site, date, product. This becomes the entire difference between a time series and a pile of folders when the third capture arrives.
• A saved project or map file. The person who successfully loaded the layers should save the project that has them loaded, so the next person does not repeat the configuration work.
• A named custodian. One person who knows where it is and that it is still there, which is also what makes a repeating program work, as set out in building an annual aerial capture program.

What to settle before the flight

Five lines in the scope prevent nearly all of this. Which programs and versions the output must open in. The horizontal coordinate system by name. The vertical datum by name, with the geoid model stated. Which products are wanted and in which formats. And whether a browser viewer is included for the people who only need to look.

A sixth is worth adding if the capture is part of a series: say that these choices are fixed for the life of the program. Changing projection or datum midway through produces an apparent step in the data that is a bookkeeping change rather than a physical one, and tracking that down a year later is considerably more expensive than writing the line now.