A coordinate reference system belongs with the mapping files, not only in the email that announces delivery. Imagine a hypothetical large fixed-wing aircraft collecting a civil infrastructure planning area. The GIS team receives an orthomosaic, a point cloud and an elevation raster, while the survey team retains control coordinates elsewhere. The handover question is whether a recipient can interpret these products consistently without guessing which reference, units or transformation was intended.

Identify the horizontal reference and projection

The USGS Lidar Base Specification provides a concrete 3DEP example: it calls for advance agreement on the delivery CRS and documentation of the full horizontal and vertical definitions, including a Well-Known Text representation. It also addresses projects spanning areas where a single CRS would introduce unacceptable distortion. These are program-specific requirements, not universal prescriptions for civil UAV work. [3]

For this fixed-wing example, ask the receiving team to specify the reference frame and projection rather than a casual grid nickname. Preserve the relevant authority identifier where applicable together with the complete definition actually exported. If a project-local system is requested, document its relationship to the agreed geospatial reference and who supplied it. Do not invent an authority code for a custom engineering grid.

Units and axis conventions need inspection

USGS explicitly distinguishes foot definitions in its units requirements and discusses horizontal and vertical units as part of delivery. Its WKT section also addresses axis representation. The lesson for this hypothetical handover is to make unit and axis interpretation inspectable, not to assume every recipient uses one program’s defaults. [3]

Prepare a delivery note identifying coordinate order and horizontal and vertical units. Then open the exported files in the intended receiving workflow and examine their stored definitions. A filename ending in meters is not evidence that all coordinates were converted correctly. Conversely, changing a CRS label should not be accepted as proof that a coordinate transformation was performed. Ask the processor to explain which operation occurred and retain its record.

Carry vertical references and transformations

For the example civil project, request a separate statement of height reference and any geoid model used. Identify the source reference of navigation and control, the target reference of each output and the documented operations between them. If two products require different delivery systems, explain their relationship rather than describing the entire package with one ambiguous sentence.

The USGS deliverables section asks its lidar mapping report to record reference frame, projection, units, vertical datum and geoid height model for point output. It also requires horizontal and vertical information in or accompanying elevation rasters. This is a substantive documentation example drawn from 3DEP, not a claim that meeting that list alone establishes compliance or survey accuracy. [4]

Use machine-readable metadata and spot checks

The proposed fixed-wing handover would include file-embedded reference information where the chosen format supports it, a readable reference summary and a processing history. Assign a reviewer to compare those three records. If a raster, point cloud and control file disagree, pause that part of the delivery rather than expecting a GIS operator to choose the most familiar label.

For an independent spot check in this hypothetical review, use documented points supplied in the agreed output reference and inspect locations and elevations in the receiving application. Record what was checked and what remains unresolved. Such a check would test interpretation and export behavior; it would not replace the project’s full positional-quality assessment.

Keep the large fixed-wing acquisition block identifiers connected to the delivered files so any revised transformation can be traced through affected products. A useful acceptance statement says what reference the data actually use, how that was established and which exceptions remain. It does not promise that familiar-looking coordinates are correct simply because every file opens on the same map background.

Related reading

Sources

Visual summary

Concept illustration

Input references connect through documented transformation to exported metadata and receiving-workflow interpretation.
Conceptual handover chain: reference definitions and coordinate operations must survive export and be interpretable in the receiving workflow. Diagram only; not flight-test data.
Read diagram notes
  • Input reference definitions: Identify control, navigation and each product reference, units and axes.
  • Documented operation: Distinguish assigning a label from actually transforming coordinates.
  • Exported file definitions: Compare embedded reference information with summary and processing history.
  • Receiving-workflow check: Inspect documented points in the agreed output reference without claiming full accuracy.