DRONE EMOTIONS RESEARCH · RESEARCH PROTOCOL 002

RTK, GCP and Checkpoint Accuracy Validation in Agisoft Metashape

A structured protocol for separating control from independent validation, reviewing reference-data quality and documenting whether an Agisoft Metashape project has demonstrated the required positional accuracy.

Review the Protocol Discuss Your Project

02
RESEARCH PROTOCOL

6 VALIDATION STAGES

Reference · Control · Checkpoints
Optimization · Evidence · Reporting

DEVELOPED BY DRONE EMOTIONS

Last reviewed: September 2026

TRANSPARENT CONTENT CLASSIFICATION

This is an independent validation protocol developed by Drone Emotions Srl. It is not a customer case study, a report from a measured dataset or official Agisoft LLC documentation. It does not claim a specific accuracy. Every result must be established from project-specific reference data, processing records and independent checkpoints.

THE CORE PRINCIPLE

Control builds the solution; checkpoints test it

An accuracy value is meaningful only when its origin is clear. RTK or PPK camera coordinates can strengthen direct georeferencing. Ground Control Points can constrain the bundle adjustment. Neither automatically provides independent evidence of final-product accuracy when the same observations have influenced the solution.

Checkpoints remain outside the adjustment and are compared with the reconstructed result. Their residuals, spatial distribution and relationship to the project specification provide a more defensible basis for assessing positional accuracy.

✓ Define the required accuracy before processing

✓ Keep control observations separate from validation evidence

✓ Use realistic observation accuracies and coordinate definitions

✓ Report limitations, not only the smallest residual

VALIDATION QUESTIONS

What must be demonstrated?

Reference integrity
Are coordinates, units, accuracies, point identifiers and datums reliable?

Network geometry
Do control and checkpoints represent the site, boundaries and elevation range?

Independence
Were validation points excluded from optimization?

Acceptance
Do the reported results satisfy a written project requirement?

REFERENCE ROLES

Three observations with different responsibilities

The same coordinate source should not be described simultaneously as control and independent validation. Define the role of each observation before optimization begins.

01

RTK or PPK camera positions

Coordinate observations associated with camera centres. They can support direct georeferencing and constrain the adjustment when enabled and weighted appropriately.

Primary question: what do the GNSS status, correction method, datum and stated uncertainty actually represent?

02

Ground Control Points

Surveyed markers enabled as control in the reference adjustment. Their coordinates and image projections influence the estimated transformation, camera parameters and geometry.

Primary question: are the control points accurate, identifiable and well distributed rather than simply numerous?

03

Independent checkpoints

Surveyed markers measured in the imagery but disabled as control. Their known coordinates are compared with model-derived positions after adjustment.

Primary question: do they provide sufficient independent coverage to support the accuracy statement?

VALIDATION SEQUENCE

Six stages from specification to evidence

Treat accuracy validation as a traceable process. Each stage should leave a record that can be reviewed before the final claim is accepted.

01

Specify

Write the coordinate system, required deliverable, accuracy tolerance, confidence or reporting convention and acceptance authority.

02

Audit

Inspect GNSS metadata, survey records, point descriptions, coordinate reference information and stated measurement uncertainty.

03

Design

Assign control and validation roles, evaluate point distribution and protect independent checkpoints from accidental use.

04

Configure

Apply the correct CRS and vertical reference, assign defensible accuracies and verify marker projections before optimization.

05

Optimize

Run a controlled adjustment, inspect residual patterns and document changes instead of tuning only for a smaller headline error.

06

Validate

Evaluate independent checkpoint errors, bias, outliers and coverage against the written requirement and report the limitations.

DETAILED RESEARCH PROTOCOL

Nine checks for a defensible accuracy statement

Expand each stage and record the decision, source evidence and unresolved uncertainty. The protocol is intentionally value-neutral: project tolerances and observation accuracies must come from the actual survey specification and equipment records.

01 — Define the accuracy requirement and acceptance rule

Begin with the decision the final product must support.

  • Identify the deliverable being validated: camera solution, point cloud, orthomosaic, DEM, mesh, measured feature or another product.
  • State whether the requirement concerns absolute position, relative geometry, repeatability or change detection.
  • Separate horizontal and vertical requirements where the project specification does so.
  • Record the required units, reporting statistic, confidence convention and maximum allowable error where applicable.
  • Identify the contractual, survey, scientific or internal standard governing acceptance.
  • Define who is qualified and authorized to approve the result.
  • Avoid deriving the acceptance threshold after seeing the processing result.

Required record: a written accuracy and acceptance specification linked to a defined deliverable.

A consistent numerical result can still be wrong if the reference definition is inconsistent.

  • Confirm the coordinate reference system used by camera positions, GCPs and checkpoints.
  • Verify EPSG or custom CRS definitions rather than relying only on a project name.
  • Determine whether heights are ellipsoidal, orthometric or referenced to a local datum.
  • Identify the geoid model or vertical transformation required for the project area.
  • Check units, axis order, decimal separators and coordinate-column mapping during import.
  • Confirm antenna, sensor or lever-arm offsets when they are relevant to the coordinate source.
  • Test at least one known point after transformation and before interpreting residuals.

Required record: source, project and output CRS definitions, including vertical datum and transformation resources.

Do not treat every coordinate tagged as RTK as equally reliable.

  • Record the aircraft, camera, GNSS receiver and correction workflow used.
  • Distinguish RTK, PPK, autonomous GNSS and coordinates modified by another application.
  • Inspect solution status, timestamps, base or network information and any quality fields available.
  • Confirm the datum, height convention and coordinate epoch where relevant.
  • Verify whether coordinates refer to the antenna, camera centre or another physical point.
  • Review whether per-camera accuracy estimates are available and meaningful.
  • Look for systematic offsets by flight, altitude, direction, battery or acquisition session.
  • Retain the original metadata and any processing log that produced corrected coordinates.

Required record: a camera-reference audit stating coordinate source, correction status, datum, offsets and adopted uncertainty.

Spatial coverage and geometric strength matter more than a point count in isolation.

  • Distribute control points across the site rather than concentrating them near the centre.
  • Represent boundaries, corners, elevation range and areas where accuracy matters operationally.
  • Reserve checkpoints before optimization and keep their role documented.
  • Avoid locating every checkpoint close to a GCP or in only one portion of the project.
  • Use stable, unambiguous targets that can be identified at the image resolution available.
  • Consider terrain, vegetation, occlusion, reflective surfaces and access constraints.
  • For corridor, façade, vertical or mixed aerial-terrestrial projects, design the network for the actual capture geometry.
  • Document points that were excluded and the technical reason for exclusion.

Required record: a map and point register showing control/check roles, distribution, survey source and point condition.

A precise survey coordinate cannot correct an imprecise image observation.

  • Confirm each marker identifier matches the correct surveyed point.
  • Inspect target visibility, sharpness, contrast and obstruction in every relevant image.
  • Review projections at sufficient zoom and correct misplaced observations.
  • Use several geometrically useful images rather than relying on repeated views from a similar direction.
  • Check for motion blur, rolling-shutter effects, shadows or target deformation.
  • Remove uncertain projections rather than forcing a measurement where the target is not identifiable.
  • Document manual changes and maintain consistent operator rules where several people mark points.
  • Reinspect markers showing unusual residual magnitude or direction after optimization.

Required record: a reviewed projection set with traceable corrections and notes for ambiguous or excluded observations.

Accuracy settings express trust in the observations; they are not a target result.

  • Base camera and marker accuracy values on survey method, equipment records and coordinate provenance.
  • Use separate horizontal and vertical values when the measurement process supports different uncertainty.
  • Avoid unrealistically small values that force the solution to fit reference observations beyond their credible precision.
  • Avoid broad default assumptions when project-specific evidence is available.
  • Apply individual accuracies where certain observations differ materially from the rest.
  • Record every change to reference accuracy settings and why it was made.
  • Evaluate sensitivity when uncertainty in the adopted weighting could materially affect the result.
  • Do not alter weights solely to make the reported residual appear smaller.

Required record: an observation-accuracy table supported by survey evidence and a change log.

Preserve a baseline and understand what each adjustment changes.

  • Save or duplicate a baseline project before reference and calibration changes.
  • Review camera alignment, tie-point distribution and weakly connected areas before interpreting reference error.
  • Confirm calibration groups and sensor models reflect the actual equipment and acquisition sessions.
  • Enable only the intended control observations; verify checkpoints remain excluded from adjustment.
  • Apply one documented group of changes at a time and compare the result with the previous stage.
  • Inspect camera, marker and reprojection residual patterns rather than only aggregate values.
  • Investigate systematic direction, flight-line grouping or elevation trends.
  • Avoid excessive parameter freedom that is unsupported by image geometry or calibration evidence.
  • Record software version, relevant settings and the operator responsible for approval.

Required record: a staged optimization log with baseline, changes, observations and approved final state.

Interpret the distribution of errors, not only one summary value.

  • Confirm checkpoints were disabled as control throughout the final adjustment.
  • Review horizontal, vertical and three-dimensional residual components as appropriate.
  • Calculate or report the statistic required by the project specification.
  • Inspect mean error or directional bias that may be hidden by an aggregate magnitude.
  • Identify maximum residuals and investigate outliers without automatically deleting them.
  • Compare interior, boundary, high, low and operationally critical areas.
  • Assess whether the number and spatial distribution of checkpoints support the scope of the conclusion.
  • Distinguish a failed checkpoint measurement from evidence of a local model problem.
  • Repeat the analysis after any change that affects alignment, calibration, reference or geometry.

Required record: checkpoint residuals, summary statistics, distribution map, outlier decisions and comparison with acceptance criteria.

State exactly what has—and has not—been demonstrated.

  • Identify the validated deliverable, project area and coordinate reference system.
  • List the control and checkpoint observations used, including survey source and stated accuracy.
  • Report horizontal and vertical results separately when relevant.
  • Include the statistic, units, point count and any confidence convention used.
  • Provide maps or tables sufficient to reveal the spatial distribution of residuals.
  • Describe excluded points, outliers, manual edits and deviations from the planned protocol.
  • Record the Metashape version and processing state to which the result applies.
  • Disclose weak coverage, limited elevation range, small validation samples or other constraints.
  • Avoid extending a local validation conclusion beyond the area and products actually tested.

Required record: a signed or approved validation statement with results, scope, evidence and limitations.

VALIDATION CONFIGURATIONS

Choose evidence according to the project—not by habit

These configurations describe roles, not guaranteed performance. The appropriate design depends on acquisition geometry, survey specification, risk and available independent reference.

CONFIGURATION A

RTK/PPK only

Camera coordinates support direct georeferencing, but no independent ground evidence is available.

Conclusion: report the limitation; do not present camera residuals alone as independent product validation.

CONFIGURATION B

RTK/PPK + checkpoints

Camera coordinates control the solution while surveyed markers remain independent.

Conclusion: checkpoint evidence can test the directly georeferenced result within its represented area.

CONFIGURATION C

GCPs + checkpoints

Ground control constrains the adjustment and a separate marker set provides validation.

Conclusion: evaluate checkpoint evidence independently from the fit achieved at GCPs.

CONFIGURATION D

Hybrid control

RTK/PPK camera coordinates and selected GCPs both contribute to the solution; other markers remain checkpoints.

Conclusion: document weighting and test whether each control source introduces or resolves systematic bias.

REPORT THE EVIDENCE

Accuracy information to include

Checkpoint count and role
Total observations, points used, excluded points and confirmation that checkpoints were not control.

Residual components
East/X, North/Y, elevation/Z and combined horizontal or 3D values where appropriate.

Summary statistics
The project-required metric, together with mean bias, maximum error and units.

Spatial evidence
Map or diagram showing control, checkpoints, project boundary and residual patterns.

Acceptance decision
Explicit comparison with the predefined requirement—not a subjective “good” or “accurate” label.

REPORT THE CONTEXT

Information needed for interpretation

Reference framework
CRS, datum, geoid or height reference, units and transformation process.

Acquisition and survey
Sensors, RTK/PPK method, GCP survey equipment, capture dates and relevant field conditions.

Processing state
Metashape version, calibration grouping, reference settings and final optimization stage.

Traceable decisions
Point-role changes, removed observations, outlier handling and manual interventions.

Limitations
Weak areas, incomplete elevation range, small sample, local bias or conclusions that cannot be generalized.

EVIDENCE-BASED CONCLUSION

Validated, conditional or not demonstrated

Use language that reflects the evidence actually available. A technically honest limitation is more authoritative than an unsupported accuracy claim.

VALIDATED

The evidence supports the claim

Independent checkpoints represent the project sufficiently, the required statistic meets the predefined tolerance and limitations are documented.

CONDITIONAL

The conclusion has a limited scope

Results may satisfy the tested points, but distribution, sample size, height range or local anomalies restrict generalization to the full product.

NOT DEMONSTRATED

Independent evidence is insufficient

No suitable checkpoints exist, the reference framework is unresolved, the network is unrepresentative or the defined tolerance is not met.

LIMITATIONS AND RESPONSIBLE USE

A protocol improves traceability; it cannot manufacture evidence

The achievable and demonstrable accuracy of a photogrammetric project depends on image scale and geometry, sensor behaviour, scene characteristics, survey quality, coordinate reference definitions, marker identification, camera modelling, software settings and the intended deliverable.

This protocol does not prescribe universal point counts, accuracy values or acceptance thresholds. Where legal, cadastral, engineering, safety or regulated survey requirements apply, the validation design and final statement must be reviewed by appropriately qualified professionals.

✓ No project accuracy is claimed

✓ No universal GCP count is prescribed

✓ Independent validation remains project-specific

✓ Evidence and limitations must be reported together

Agisoft and Metashape are trademarks of their respective owner. This independent resource is developed by Drone Emotions Srl, an Agisoft Authorized Reseller and Training Center, and is not official Agisoft LLC documentation.

PRIMARY TECHNICAL REFERENCES

Continue with current Agisoft documentation

Consult the current Metashape manual and official Agisoft guidance for software-specific commands, settings and version-dependent behaviour.

AGISOFT HELPDESK

Control and Check Points

Official guidance covering marker accuracy, control/check roles and the Reference pane.

Open Official Guide
AGISOFT HELPDESK

DJI RTK Data Processing

Official workflow guidance for processing DJI imagery with RTK camera-coordinate data.

Open Official Guide
AGISOFT HELPDESK

Aerial Processing with GCPs

Official workflow guidance for importing and using ground control in an aerial project.

Open Official Guide

CONTINUE EXPLORING

Connect validation with planning and professional support

TECHNICAL TOOL 001

Project Readiness Checklist

Review dataset, accuracy, reference-system, hardware and delivery requirements before full processing begins.

Open the Checklist
TECHNICAL SCENARIOS

Explore Workflow Decisions

Review transparent illustrative scenarios involving professional photogrammetry requirements and implementation choices.

Explore Scenarios
PROFESSIONAL SUPPORT

Review Your Validation Plan

Discuss reference data, licensing, computing resources and Metashape workflow requirements with Drone Emotions.

Contact Support

QUESTIONS

About accuracy validation

The answers below describe general validation principles. The appropriate design and acceptance criteria remain project-specific.

RTK or PPK camera positions can improve direct georeferencing, but they do not automatically prove the accuracy of the final deliverable. Independent checkpoints are recommended when the project requires a defensible external accuracy assessment.

Both may be represented as reference markers, but their roles differ. A GCP is enabled and influences the adjustment. A checkpoint is measured but disabled as control, so its known coordinate can be compared with the reconstructed result independently.

There is no universal number suitable for every project. The design depends on site shape, elevation range, acquisition geometry, required accuracy, survey specification and risk. Spatial distribution and independence are essential; a point count alone is not a validation strategy.

Not automatically. GNSS, total-station, levelling and other survey methods can have different horizontal and vertical uncertainty. Use evidence from the actual measurement process and report the components separately where appropriate.

No. GCPs influence the adjusted solution, so a close fit at those points is not independent proof. Checkpoint results, spatial patterns, coordinate consistency and the required output must also be evaluated.

Possible causes include acquisition geometry, limited elevation control, vertical-datum mismatch, GNSS height uncertainty, camera calibration, marker measurement or systematic reference offsets. The pattern must be investigated rather than attributed to a single cause without evidence.

No. It is an independent professional protocol developed by Drone Emotions Srl. Always consult current Agisoft documentation and the applicable survey, contractual or regulatory standard for your project.

DRONE EMOTIONS RESEARCH

Build an accuracy claim on independent evidence

Describe your acquisition, RTK or PPK workflow, control survey, coordinate system and required deliverables. Drone Emotions can help identify the validation questions that should be resolved before final processing and delivery.

Email the Technical Team

Drone Emotions Srl
Agisoft Authorized Reseller & Training Center