On This Page
Match the file to the receiving task
Ask the recipient to name the action: overlay a design, extract elevations,
rebuild a ground surface, inspect a structure visually, or reproduce a reported
volume. Record the application, version, import tool, and any required
extension. “Works with CAD” leaves too many decisions to the person opening the
delivery.
File request matrix
Scroll horizontally to compare all columns.
This is a request template synthesized from
Esri's export documentation,
Propeller's output descriptions,
and
Autodesk's LandXML import instructions.
It is not a claim that every listed file opens directly in every CAD or GIS
application.
For GIS imagery review, an orthomosaic and its quality documentation may be
sufficient. For earthwork design, request the agreed ground representation and
the files needed to inspect or rebuild it. For a visual stakeholder review, a
mesh may be useful without commissioning every analytical derivative.
Once those outputs are agreed, use the commercial drone mapping mission guide to
connect the delivery requirements to collection planning.
Specify what each export must contain
GeoTIFF: identify the pixel values
The OGC GeoTIFF standard describes how
TIFF imagery carries geographic referencing information. The format alone does
not tell the recipient whether pixels contain color values or elevations. Name
the product in both its filename and metadata: an RGB orthomosaic, a digital
surface model representing the selected surface, or a processed ground-terrain
grid.
Specify horizontal pixel spacing, raster dimensions, band meaning, data type,
units where applicable, and how missing data is encoded. An elevation of zero is
not automatically a missing observation. Ask for coverage and exclusion
boundaries so the recipient can distinguish valid terrain from gaps or
interpolation.
Keep a presentation preview separate from the analytical raster. Esri
distinguishes Site Scan's PNG orthomosaic preview from the TIFF used for raster
analysis. A screenshot with a scale bar is a useful illustration, but it should
not be the only delivery when the recipient needs georeferenced data.
LAS and LAZ: preserve the points and their meaning
LAS stores point-cloud data; LAZ provides compressed storage.
LASzip's documentation describes its compression as
lossless. This does not mean that an exported cloud is identical to an earlier
processing stage: filtering, thinning, coordinate conversion or classification
may have happened before compression. Ask which operations produced the
delivered cloud.
Agree the LAS version and point record format, the attributes to retain, and the
classification dictionary. Request a description of ground classification and
manual correction where a ground surface matters. The
ArcGIS Pro ground-classification documentation
describes classifying ground and reviewing or correcting problem areas. A
“classified” label should therefore be accompanied by the method and checks,
rather than treated as a quality certificate.
Specify how density is reported, which point classes contribute, and how sparse
areas are identified. A file-wide average can conceal the areas that matter to a
design. Preserve coverage exclusions and describe what the processing inferred
between observations.
The LAS extension also does not prove that the data came from a laser scanner.
If collection method changes the deliverable, settle that choice using the LiDAR
versus photogrammetry comparison before ordering the export.
DXF and LandXML: name the geometry you expect
Do not order “a DXF” without describing its contents. Propeller documents DXF
exports of model surfaces. That is a different request from a drawing containing
contour polylines, spot heights and named breaklines. Specify the geometry, Z
values, layer names and drawing units that the recipient will inspect.
A contour drawing can show terrain shape without supplying the editable surface
the civil-design team expects. If the team needs a surface exchange, request a
representative LandXML or agreed native delivery and demonstrate the intended
edit or analysis after import. Include supporting boundaries and breaklines
where the contract calls for them.
Autodesk's Civil 3D 2024 instructions say LandXML import handles unit conversion
but does not automatically transform coordinate systems beyond the specified
translation and rotation settings. A successful import is therefore no reason to
assume that two datasets share the same spatial reference.
A textured mesh request must include more than its main geometry file. For a
concrete example,
PIX4Dcloud's upload documentation
identifies OBJ, MTL, JPG and the applicable XYZ offset file together. It
explains that OBJ meshes are not georeferenced by default and that PIX4D's
offset file supports correct positioning. Its current importer also requires a
single JPG texture, illustrating why “supports OBJ” is an incomplete
compatibility statement.
Specify the receiving application's requirements for materials, textures,
coordinate offset and orientation. Agree any mesh simplification and preserve
the distinction between a visual model and the surface used for numerical
analysis. Test the delivered folder after moving it to a different location, so
missing dependencies become visible before acceptance.
Make coordinates and heights unambiguous
Put a coordinate-reference statement in the package and reconcile it with the
actual file headers. Identify the horizontal reference frame and realization,
projection and zone, axis order, horizontal units, vertical reference and height
units. If legacy data uses feet, specify which foot definition applies. Include
an epoch where the reference frame or project requires it, along with registered
identifiers and a machine-readable definition the receiving software accepts.
For heights, state whether values are ellipsoidal, orthometric, or tied to a
local project datum. Document any geoid model and transformation used. For a
local engineering grid, include its agreed origin, rotation, scale and
connection to the project control. Do not make the recipient infer these from a
filename such as site_final_meters.
The
USGS processing and handling specification
provides a useful model: agree the coordinate system before collection and
document both horizontal and vertical definitions. Its detailed requirements
apply to its lidar program; they are not universal defaults for every commercial
drone delivery.
As a receiving-team check, compare identifiable locations and elevations against
appropriate project control. If there is a shift, investigate the reference
system and transformation history. Dragging an overlay until it looks aligned
can conceal the underlying problem and make later deliveries inconsistent.
Separate resolution from accuracy evidence
Write separate requirements for image ground sampling distance, output raster
spacing, point density and positional accuracy. These describe different
properties.
PIX4D's accuracy guidance
distinguishes local reconstruction quality from placement in a reference frame
and recommends checkpoints for assessing absolute accuracy. A small pixel size
or dense cloud does not, by itself, establish the accuracy of the delivered
coordinates.
Request measurements against checkpoints withheld from calibration or
adjustment. Independence here means that the checkpoints did not help fit the
result; it does not automatically mean a separate company performed the survey.
The USGS specification explicitly separates calibration control from checkpoints
used to assess accuracy.
Ask for checkpoint IDs and locations, survey method and uncertainty, the tested
product revision, coordinate differences, relevant horizontal and vertical
statistics, and the treatment of excluded points. Identify the land-cover
conditions represented. A single summary number should not obscure where the
data is weak or untested.
If a contract invokes a standard, name its edition, applicable accuracy class,
sampling requirements and reporting method before collection. Do not invent a
universal checkpoint count or a centimeter limit from the drone's positioning
specification. The drone photogrammetry accuracy explainer covers the
acquisition and reconstruction variables behind those limits.
The reports should also connect back to the deliverables. USGS's
deliverables specification
calls for survey, acquisition, processing and product metadata, including
classification and raster-production methods. For a commercial package, use
those categories to request a concise, traceable record suited to the actual
job.
Write an annotated acceptance specification
Use the following clauses as a procurement template. The project team must fill
in actual software versions, spatial references and numerical limits before
collection. They are deliberately not universal accuracy or resolution promises.
Scroll horizontally to compare all columns.
These clauses are editorial recommendations drawn from the format and quality
documentation cited above. They turn documented failure modes into checks a
client can agree with a supplier.
For volume reporting, add the measurement boundary, base or comparison surface,
dataset dates, units and calculation method. Preserve those inputs alongside the
report so a later reviewer can understand what changed. A PDF total alone is
insufficient for that purpose.
Include a small handoff manifest
A manifest ties the delivery together. This illustrative manifest is a file-role
example, not a real survey or an acceptance result. The example filenames do not
represent attached datasets.
Scroll horizontally to compare all columns.
For an actual handoff, add a package revision, acquisition date, producer and
named receiving application. Record file sizes and computed checksums, including
each mesh companion. List optional files only when supplied. A checksum can help
detect a changed or incomplete transfer; it does not establish that the
underlying survey is accurate.
If the contract requires a surface exchange, add its file and dependencies
explicitly. Keep any quick-view images in a separately identified preview folder
so a recipient cannot confuse them with analytical products.
Accept the package in the receiving application
Run a small representative import before flight and repeat the agreed checks on
the final delivery. The early test proves the proposed export route; the final
check confirms what was actually handed over.
First reconcile files, revisions and dependencies. Then inspect coordinate
definitions, units and coverage. Perform the recipient's real task: read an
elevation, filter a point class, edit the requested geometry, load the textured
scene or reproduce a measurement. Review independent accuracy evidence
separately from these usability checks.
Record failures precisely. Missing textures call for a complete mesh package. A
height offset calls for an investigation of datums and transformations. Missing
independent accuracy evidence calls for the agreed assessment, even when the
files open correctly. Accept a reduced use only when the responsible recipient
explicitly agrees to that limitation.
The practical request is a short, task-specific file schedule plus the
information needed to interpret and check it. Agree that package before
collection, and the final delivery can be judged by whether the receiving team
can use and verify it.
Source notes
Last checked: September 9, 2026.
