Building a GNSS survey acceptance checklist

Begin with the intended use

An acceptance checklist should express what the project needs from the survey and what evidence supports that decision. It is not simply a list of receiver status messages. A dataset used for approximate asset location may have different requirements from one used to transfer control or support height sensitive design. Define the horizontal, vertical and attribute requirements separately so the review does not collapse several different questions into one vague accuracy claim.

Agree the criteria before production where possible. The crew needs to know which observations require repeats, which checks are independent and how exceptions will be handled. A checklist created only after the data are collected can expose gaps, but it cannot always replace missing field evidence. Keep the acceptance plan connected to the collection method rather than treating final review as a separate office activity that repairs every earlier omission.

Continue learning A practical GNSS field checklist before recording points

Verify the reference foundation

Confirm the coordinate reference system, units, axis order and height definition. Review the source of base or control coordinates and any local transformation. Check that the approved revision was actually used during each work period. A coordinate file may be internally tidy while referring to the wrong system, so reference verification should come before statistical summaries or cosmetic formatting.

Trace the antenna geometry as part of the same foundation. The reviewer should find antenna identification, height measurement method and setup records for relevant sessions. If a component changed, identify the affected interval. Do not assume that a receiver model in an equipment list establishes the physical geometry of every occupation. The checklist should ask for evidence that can be linked to observations, not merely a general statement that equipment was used correctly.

Continue learning Writing a GNSS survey report that supports the coordinate deliverable

Review field quality evidence

Inspect independent check results and repeat occupations according to the project plan. Compare horizontal and vertical components, examine spatial patterns and retain exceptions. A small overall average does not justify ignoring a large discrepancy at one end of a project. Confirm that points used to fit a transformation are distinguished from points reserved to test it, since those roles provide different evidence.

Review solution states, correction interruptions and difficult observation environments alongside the external checks. Internal receiver estimates can support the assessment, but their meaning depends on the equipment and model. Keep them distinct from demonstrated agreement with control. If the planned checks were not completed, record the gap and decide what additional work is required rather than replacing the missing evidence with a more confident adjective in the report.

Continue learning Completing a GNSS project handover that others can use

Examine completeness and meaning

Check that the required area and feature types were covered. A precise coordinate is not useful if the intended asset or breakline was omitted. Compare field records with the work plan, maps and feature dictionary. Verify mandatory attributes and make unknown values explicit. The acceptance review should preserve uncertainty where the crew could not observe a feature rather than rewarding invented values that merely fill every cell.

Inspect point identifiers and relationships between repeated occupations, photographs and final features. Confirm that duplicates were resolved through a documented process and that renaming did not break evidence links. For linework and polygons, check connectivity and physical interpretation as well as coordinate values. A file can contain valid geometry while joining the wrong sequence of observed points or describing a different part of a feature than the client expects.

Continue learning Designing a GNSS project quality dashboard

Check processing and revision history

Review material conversions, transformations and coordinate corrections. Preserve the source files and the basis for each accepted revision. If an error was corrected, verify the affected scope and the checks on the revised result. A final label should not erase the difference between observations collected correctly and observations later repaired through an approved process. Both can be usable, but their evidence histories should remain understandable.

Confirm that provisional and superseded outputs are clearly marked. If raw observations await processing, keep them outside the accepted coordinate delivery unless the status is explicit and appropriate to the handover. The checklist should prevent a file from becoming approved merely because it sits in a folder called final. Approval belongs to a defined dataset and revision supported by a recorded review.

Continue learning A practical GNSS field checklist before recording points

Test the delivery format

Open the deliverable in the intended destination software and inspect representative records. Check coordinate placement, heights, units, identifiers, attributes and character encoding. A successful import confirms that the program accepted the syntax; it does not prove that the data mean what the user assumes. Compare known points and features after import to test interpretation as well as file readability.

Verify metadata and supporting links from the handover location. A photo index pointing to a temporary local drive is not a complete delivery. For GeoJSON or other standardized formats, follow the format requirements rather than assuming any coordinate tuple is acceptable. Preserve the export settings and identify the approved output files in a manifest so the client can distinguish them from working files and alternate formats.

Continue learning Writing a GNSS survey report that supports the coordinate deliverable

Handle exceptions explicitly

Create a concise exception register with affected identifiers, reason, consequence and resolution. Some exceptions may be acceptable within the project scope; others require additional measurement or processing. The reviewer should be able to see the basis for that decision. Avoid hiding unresolved points in a general disclaimer that gives no practical way to locate them in the dataset.

If an exception changes the suitability for a particular use, state that consequence clearly. For example, an unobserved drainage invert should not be treated as a measured height in later analysis. The acceptance process should connect evidence to use, including limitations. It is better to release a clearly bounded, honest dataset than to imply uniform confidence across points collected under materially different or unverified conditions.

Continue learning Completing a GNSS project handover that others can use

Record the approval decision

Identify the reviewer, dataset revision, review date and supporting records according to the project workflow. Include unresolved actions and any conditions on use. Keep the checklist concise enough to apply consistently, with links to detailed evidence rather than duplicated reports. A completed form should represent an actual assessment, not a signature added because every box can be ticked without opening the files.

As a practical test, ask whether another colleague can identify the approved coordinate system, relevant checks and exceptions without speaking to the field crew. If not, improve the package before release. Survey acceptance is a reasoned decision based on reference definitions, observations, processing and intended use. The checklist succeeds when it makes that decision concrete, reproducible and understandable to the people who will depend on the coordinates.

Check that all deliverable formats represent the same approved revision. A corrected GIS layer and an older spreadsheet can both look final while disagreeing. Compare representative identifiers and coordinates across exports, then list the released files in one manifest. This prevents a resolved survey issue from reappearing through a superseded alternate format.

Continue learning Designing a GNSS project quality dashboard