RTK and PPK for Drone Mapping: Choosing a Georeferencing Workflow

Start with when positioning is solved

RTK and PPK use GNSS measurements and suitable reference information. An important workflow difference is timing: RTK solves during measurement, while PPK processes recorded data afterward. This affects communication, files, and staffing. Neither automatically guarantees map accuracy. Results also depend on references, observations, timing, integration, and photogrammetric or LiDAR processing. Define outputs and required evidence first. Then check that the offered configuration supports the complete chain. Choosing a method label without that review can leave essential recording or processing responsibilities unresolved.

Understand the RTK correction path

Identify correction origin, delivery, and available monitoring. Receiver status alone does not describe the reference used. Communication and environment belong in configuration assessment. Record relevant changes throughout measurement. Handling changed status must follow operator procedures and the intended method, not generic actions from an article. The aim is connecting devices, corrections, records, and results. Clear evidence allows the team to explain what happened across the mission rather than relying on one favourable display captured at a particular moment before acquisition began.

PPK requires complete recordings

Post-processing needs the required receiver observations, time coverage, formats, and sensor-event data. A coordinate file is not necessarily a substitute. Test an example before a large job. PPK allows later processing review but cannot create observations that were never recorded. Agree a delivery list between operators and processors. Check completeness while the team can still address recoverable omissions. This makes the method practical and avoids treating flexible processing as a promise that every recording error or missing input can be repaired later.

Define the base reference

Both workflows need a known reference source. Base coordinates, datum, time, and determination method matter. An unclear reference can affect results even when processing appears successful. Services and reference files should not be assumed equivalent without checking suitability. Obtain relevant information from the provider or survey lead and keep it with the project. Traceability is a quality requirement, not paperwork to complete after delivery. It lets another processor repeat the work and understand the origin of the resulting positions.

Connect camera events with positions

Good positioning must be matched with the correct imaging event. Trigger commands, exposure time, and stored files need a documented relationship. Ask the integrator what is recorded and tell the processor what the data represents. Check samples across the sequence, not only the first image. Missing files must not silently shift subsequent matching. The RTK or PPK workflow becomes meaningful when observations remain connected to the sensor through to the final product. Otherwise, accurate positions can be attached to the wrong records without the interface revealing the underlying mismatch.

Understand antenna and sensor geometry

GNSS relates to an antenna reference that may not coincide with the sensor centre. Document the geometric relationship, axes, units, and measurement source. Review changes to mounts or equipment. Do not copy another configuration's values without assessment. Numbers without definitions can be interpreted differently by another analyst. Clear records distinguish position measurement issues from errors applying the sensor relationship during processing. Timing and geometry should be assessed as separate elements of the same workflow, each requiring suitable evidence for the installed configuration.

Test final accuracy separately

Image quality, acquisition geometry, sensor modelling, control, and processing affect the product beyond camera positioning. Use suitable independent checkpoints and distinguish horizontal and vertical assessment with defined references. A solution status is not a checkpoint report. Investigate the complete chain before assigning a cause to disagreement. This makes method comparison fair: both are judged against the needed product rather than one component specification. State test coverage and limitations so a result from one example is not presented as proof for every project condition.

Compare staff workload and support

PPK needs capable post-processing staff and software. RTK needs a prepared correction workflow during measurement. Some configurations can retain additional records, but backup capability must be demonstrated rather than assumed. Rehearse transfer from field team to processor to expose weak links. Clear responsibilities often matter more than declaring one method universally superior. Include time for checks and documentation in the comparison. A method that is theoretically suitable may still be impractical if the organisation cannot consistently capture and manage its required inputs.

Choose through repeatable evidence

Use a representative area with agreed files, processing, checkpoints, and report. Record aircraft, payload, reference, and software. If the result is insufficient, locate the weak element through evidence instead of immediately changing method. Different projects may justify different choices because communication and reference availability vary. Preserve traceability: users should know where positions originated, how they were matched with sensors, and how the map was assessed. That explanation is more useful than a bare RTK or PPK label when the deliverable will support real geospatial decisions.

Illustrative case: choosing georeferencing for a remote corridor

Suppose a hypothetical corridor project includes sections where the planned correction delivery arrangement has not yet been demonstrated. The team does not settle the RTK-versus-PPK question from a preference for a familiar label. It lists the actual reference source, communication dependencies, raw observations, camera events, and processing responsibilities for each proposed workflow. The operator and processor rehearse the delivery of representative records before the main acquisition is scheduled. If post-processing is proposed, the review confirms that required observations are recorded rather than assuming they can be reconstructed from simple coordinates. If real-time corrections are proposed, the team documents the source and the evidence needed to evaluate their use throughout the relevant period. Independent checkpoints remain part of final-product assessment in either case. This scenario is hypothetical and promises no accuracy or range. Its decision record explains which method is supported by the available configuration and staff, which assumptions still need testing, and what files the user will receive. It therefore avoids calling one approach universally superior. A later project can revisit the choice using its own access and reference conditions while keeping the same requirement for traceable georeferencing evidence.

A verified real-time workflow may be appropriate where its dependencies are satisfied, while a demonstrated post-processing workflow may suit another part of the programme. The team records the choice per configuration and task rather than applying an unexplained fleet-wide preference. Handoff evidence includes the reference source, relevant observations, event definitions, processing instructions, and independent assessment results. If backup recording is described, its existence is checked rather than assumed from a feature list. This gives the user a repeatable account of how positions were obtained and connected to the sensor, including the limitations that remain for the selected method.