A drone orthomosaic can look sharp in a browser and still create problems when it reaches the office. The image may arrive without a usable coordinate reference, omit part of the project limits, or contain a seam through the feature your technician needs to trace. A file that opens is only the beginning of acceptance.
For a survey firm, a useful orthomosaic needs three things: documented spatial reference, image quality appropriate to the work, and a delivery package that behaves correctly in the receiving software. Agree on those requirements before collection, then check the exported deliverable against them.
Our guide to orthomosaics and orthorectification explains how these images are produced. Here, the focus is the next step: deciding whether the finished file is ready for your team to use.
Start with the intended task. An image for progress communication may need a different review from one supporting planimetric feature extraction. Write down the project limits, required capture date, target pixel size, horizontal reference system and units, positional accuracy requirement, and delivery format. Identify the CAD or GIS application and version that will receive it.
Also specify what must be visible. If a client needs pavement edges or drainage structures, a general promise of complete coverage is too vague. Shadows, vegetation, vehicles, and buildings can obscure features within an otherwise complete image. Define how those areas will be flagged and whether supplemental fieldwork is needed.
Keep pixel size separate from positional accuracy. A small ground sampling distance does not establish how closely mapped locations agree with independently surveyed locations. Request the validation method and results appropriate to the project. For a horizontal accuracy assessment, use suitable independent checkpoints that were withheld from adjustment; do not substitute the processing report's control residuals for that independent check.
Review the full extent first, then inspect representative areas at the scale your staff will use. Check the perimeter, narrow corridors, elevation transitions, and locations important to the scope. A quick view of the center of the site can miss problems at the edges.
Look for blur, doubled features, abrupt tonal changes, voids, and seams that interrupt visible geometry. Pay particular attention to road markings, curb lines, fence corners, and other distinct features crossing image boundaries. Raised objects can show displacement or distortion depending on the imagery and surface model used during orthorectification. A clean-looking roof does not establish a correct ground location.
Review each issue against the intended task. A change in image appearance and a problem that prevents reliable feature interpretation can have different consequences.
Save the review locations and decisions. A short issue log with a screenshot, location, reason, and disposition gives the processor something specific to fix and gives the receiving technician a record of remaining limitations.
GeoTIFF stores georeferencing information within the TIFF framework. That makes it useful for geospatial exchange, but the file format does not certify accuracy or tell you whether its bands represent imagery or elevations. Inspect the contents and metadata.
For an RGB orthomosaic, the delivery note should identify:
A world file can describe pixel placement, but it does not by itself provide the full CRS definition. Keep any required companion files with their matching raster names. Avoid bundling stale world files or auxiliary files from earlier revisions: software can use external georeferencing, and conflicting metadata can change how a raster is interpreted.
For large deliverables, agree on a compatible large-file format or tiling strategy and test it with the recipient. Preserve a clear master version so a reduced preview or recompressed copy is not mistaken for the accepted deliverable. This is one reason to evaluate mapping software around the final CAD/GIS handoff, alongside processing speed.
Use the delivery folder for the receiving check, rather than relying only on the processor's working project. Confirm that the imagery, coordinate information, and companion files fit the software your team already uses, whether that is QGIS, ArcGIS Pro, Civil 3D, or Trimble Business Center. These are examples of receiving environments; the checks below apply across applications.
Assigning a different CRS label and reprojecting coordinates are different operations. Do not relabel the source CRS by trial and error to make an image appear to line up. Establish the correct source definition first, then apply a documented transformation if needed. Alignment with an online basemap is a useful visual clue, but it does not replace independent project accuracy checks.
An RGB orthomosaic supplies visual context. Its color bands are not terrain elevations. An elevation GeoTIFF is a different product, even though both may have a .tif extension. Inspect the data contents and intended use before choosing an import method.
That distinction follows the handoff into CAD, survey, and GIS tools. Civil 3D and Trimble Business Center, for example, document workflows that use an image with a separate surface. The image can help staff interpret visible features while the surface supplies elevation information. Receiving software does not remove the need to validate each product.
For CAD or survey handoffs, confirm the project's coordinate setup and units, the chosen imagery workflow, and the elevation product's horizontal and vertical references. If a surface is delivered, review its source data, boundaries, breaklines where applicable, and validation separately. Image alignment does not validate surface elevations.
That distinction matters when a project progresses to cut-and-fill verification: visual context and a checked terrain surface serve different purposes. Agree on both deliverables when the scope needs both.
Before delivery, confirm that the correct revision opens, covers the agreed limits, contains consistent spatial-reference information, and has documented image and positional checks. Keep the issue log and receiving-software record with the accepted files. Record exceptions instead of letting them disappear into an email chain.
A repeatable acceptance process gives field staff, processors, and office technicians the same definition of finished. It also makes the next project easier to scope: the team knows which files to request, which checks to perform, and which limitations require additional work.
Discuss your next project's delivery requirements with SmartDrone. Bring your receiving software, coordinate setup, required outputs, and acceptance criteria so the workflow can be evaluated around the files your team actually needs.