Coordinating GNSS logs for drone PPK workflows

Map the required files before the flight

A PPK workflow depends on compatible observations and a reliable connection between the positioning solution and image capture events. List the files required by the actual equipment and processing software before mobilising. These may include base observations, rover GNSS data, event records and imagery. Use manufacturer documentation rather than assuming every drone exports the same file structure.

Create a file checklist and test it with a short trial collection. Confirm that the processing software can read the logs and associate the intended images. A folder containing photographs and a file labelled GNSS is not sufficient evidence that the complete PPK workflow is available. Discovering a missing event record after the flight may leave no way to reconstruct the intended association reliably.

Continue learning Preparing GNSS data for PPK processing

Record the base reference completely

Document the base coordinates, reference system, coordinate epoch where relevant, antenna type, antenna reference point and height. The base position influences the derived rover solution. A precisely processed relative trajectory can still inherit an incorrect reference if the base coordinates or height convention are wrong. Keep the source and approval status of the adopted base coordinate.

Record the base observation interval, start and stop times and any interruptions. Preserve the original observation file before conversion. If a service supplies base data, retain its station identifier, download source and metadata. Do not treat a nearby station as automatically suitable without checking compatibility, coverage and the project’s processing requirements.

Continue learning Keeping useful time records in GNSS field surveys

Coordinate observation time coverage

Ensure the required base and rover observations cover the flight period according to the equipment and processing workflow. Record timing using clearly defined time systems and preserve original timestamps. GNSS time, UTC and local civil time should not be assumed identical. Let the documented software workflow handle required conversions, and retain enough metadata to investigate a mismatch.

Check that recording actually started before the production collection and continued as planned. A controller display showing a connected receiver does not necessarily prove that raw observations are being stored. Review file existence and basic coverage in the field where practical. A small verification step can prevent a complete flight from depending on a log that was never written.

Continue learning Handing GNSS survey coordinates to CAD teams without losing meaning

Preserve exposure event relationships

The image event record connects a camera exposure to the trajectory. Keep filenames, event identifiers and original image metadata intact until the workflow is complete. Renaming images prematurely can break an association that processing software expects. If a documented rename is necessary, preserve a mapping from original to new names.

Do not infer event timing from a file modification timestamp without evidence that the equipment workflow supports that interpretation. File copy times and camera clock settings can differ from actual capture events. Follow the manufacturer’s documented event handling and inspect the processed association. A good GNSS trajectory linked to the wrong exposure times can still produce an unsatisfactory mapping result.

Continue learning Designing a GNSS ground control point layout for drone mapping

Validate formats without losing provenance

When converting raw observations to RINEX or another required format, record the converter and version. Check station metadata, antenna information and observation time coverage after conversion. Preserve the original file and the converted output together. A successful conversion message does not prove that every field or signal needed by the intended processing method was retained.

Use the format version supported by the chosen processing tools and document any limitations. Do not edit observation values manually to force a file to load without understanding the effect. If a conversion issue appears, keep a clear issue record and use an approved correction or alternative. Provenance matters because later reviewers may need to distinguish a processing decision from an original observation.

Continue learning Preparing GNSS data for PPK processing

Review the processed trajectory and image positions

Inspect solution status, gaps and changes through the flight rather than accepting only a final success message. Check the reference and height type of the output positions. Confirm that the intended antenna-to-camera relationship and event association were applied through the documented workflow. Preserve processing settings and reports with the result.

Examine areas affected by weak observations or interruptions with particular care. The appropriate response may involve reprocessing, additional ground evidence or a repeat collection. Do not assign uniform confidence to all image positions if the evidence varies. A clear review connects trajectory quality to the mapping product without pretending the positioning report alone validates the final orthomosaic or surface model.

Continue learning Keeping useful time records in GNSS field surveys

Test the map with independent ground evidence

Use suitable control and independent checkpoints according to the project design. Keep checkpoint coordinates out of the calibration they are intended to test. Compare compatible horizontal and vertical references, and inspect spatial patterns in the differences. This tests the complete workflow, including event association, image geometry and processing choices.

Investigate systematic shifts or vertical bias through the full chain of base coordinates, antenna heights, reference transformations and camera positioning. Avoid applying an unexplained final offset simply because it improves a checkpoint average. If a correction is justified, document its cause and reassess the released product. The evidence should explain why the final result is trustworthy.

Continue learning Handing GNSS survey coordinates to CAD teams without losing meaning

Archive a reproducible PPK package

Store original base and rover files, imagery, event records, conversion outputs, processing settings and reports in a structured archive. Include the reference definitions and adopted base coordinate source. Use a manifest linking each flight to the files needed to reproduce its processing. Keep a release version for the derived image positions and mapping products.

Test the archive by reopening a representative flight through the documented workflow. Confirm that filenames, relative paths and metadata still connect correctly. A PPK handover is useful when another qualified operator can understand what was processed and why. The goal is a traceable chain from satellite observations to image positions and then to an independently assessed map.

Continue learning Designing a GNSS ground control point layout for drone mapping

Resolve a time-coverage mismatch before processing

Suppose the base file appears to start an hour after the flight log. First identify the time systems and display conventions in both records. A local time display may differ from a UTC-based record without any missing observations. Compare the underlying documented timestamps and software interpretation before concluding that the data are unusable or editing file headers.

If a genuine coverage gap exists, record it and assess the available alternatives within the approved workflow. Do not manufacture observations or silently shift timestamps. A clear issue record lets the processing team decide whether another compatible base source, a limited product or a repeat collection is appropriate. Preserving original files protects the evidence while that decision is made.

When documenting the mismatch, include a short coverage plot or table showing the interpreted base, rover and image-event intervals. State the time convention used for the comparison. This helps another operator review the issue without manually reopening every file. Keep the original file headers unchanged in the archive, and store any converted representation separately. A readable coverage record also supports future reprocessing, because it makes clear which observations were available and which assumptions the original processing decision depended on.

Continue learning Preparing GNSS data for PPK processing