EQUATOR GNSS / BY TECHNOGISGermany · Indonesia
Data & quality

Writing a GNSS survey report that supports the coordinate deliverable

A useful GNSS report explains the coordinate framework, field method, processing choices, independent checks and limitations behind the delivered files.

Writing a GNSS survey report that supports the coordinate deliverable

Lead with the purpose and accepted result

Begin the report by stating what was surveyed, where the work occurred and what the delivered coordinates are intended to support. Identify the accepted dataset and its version. A reviewer should understand the outcome before encountering equipment lists or processing statistics. Avoid a vague claim that the survey is accurate; explain the acceptance basis and refer to the measured checks that substantiate the conclusion.

State important limitations early enough to influence use. These can include approximate features, restricted access, a limited check sample or an unresolved relationship to legacy control. The report should help the client make appropriate decisions, not simply document that fieldwork happened. Keep preliminary results and accepted results clearly distinguished so an earlier coordinate list is not mistaken for the final issue.

Continue learning Accuracy, precision and uncertainty in GNSS reports

Define the coordinate and height frameworks

Identify the horizontal reference frame, realization where relevant, coordinate epoch, projection, units and axis order. Describe the vertical reference separately, including ellipsoidal or orthometric height, geoid model and any local transformation. A project name or phrase such as GPS coordinates is not sufficient for reproducibility. Use the authoritative definitions adopted by the project and retain their identifiers.

If a local grid or localization was used, explain how it was established and verified. Identify the control points used to determine it and the independent points used to test it. Preserve transformation parameters or the supported configuration file in the technical archive. The report should make clear whether agreement was independently checked or partly created by fitting the same points being quoted as evidence.

Continue learning Completing a GNSS project handover that others can use

Describe control and mark identification

Summarize the control sources, provenance, stability checks and physical mark definitions. Include descriptions or references that allow another crew to recover the marks. A coordinate is only useful when its associated physical point is understood. Where control was supplied by the client, state what verification was performed and which aspects remain dependent on that supplied information.

For newly established control, describe the observation design, connections and acceptance process. Identify weaker or provisional marks explicitly. A network diagram can help a reviewer understand redundancy and geometry more quickly than a long list of station names. Keep detailed mark photographs and setup records in an organized annex or archive rather than scattering them through the main narrative without clear identifiers.

Continue learning Writing GNSS survey specifications that can be verified

Explain the field method in reproducible terms

Describe the equipment configuration, correction or reference sources, antenna setup procedure and relevant observation strategy. Include dates, session information and meaningful configuration changes. Focus on details that affect interpretation or reproduction of the measurement. A long inventory of accessories is less useful than a clear statement of antenna reference point height, correction framework and how independent occupations were collected.

Explain how difficult sites and interruptions were handled. Identify where another measurement technique was used and how it connects to the GNSS control. If provisional observations were later accepted or replaced, summarize the review path. The report should show a controlled method across varying conditions rather than imply that every point was collected under identical circumstances simply because one receiver model appears in the equipment list.

Continue learning Writing GNSS survey metadata that explains the coordinates

GNSS receiver mounted on a survey tripod.
GNSS receiver mounted on a survey tripod. · Rowan Johnson / USGS / Public Domain

Document processing inputs and decisions

Name the software and relevant version, observation formats, reference data and supporting products used. Describe important model choices, adjustments and transformations without reproducing every default setting in the main text. Retain the full configuration in the archive. Another analyst should be able to identify the inputs that actually contributed to the accepted solution, not just the files that happened to be present in a folder.

Record significant editing, exclusions and reprocessing decisions with reasons. A clean final report should not erase the quality review history. Where an observation was rejected, link it to the evidence and accepted replacement if applicable. Summarize the practical effect of major changes, especially when they altered many downstream coordinates or superseded an earlier issued dataset.

Continue learning Accuracy, precision and uncertainty in GNSS reports

Present quality evidence with its meaning

Separate internal diagnostics from independent verification. Adjustment residuals, formal uncertainty and repeated occupations answer different questions from checks against external control. State the confidence conventions and units where statistical values are reported. Do not combine incompatible measures into one attractive number or imply that a receiver's displayed precision represents every component of the delivered coordinate uncertainty.

Use tables for check points, signed coordinate differences, observation conditions and review status where they improve clarity. Summarize horizontal and vertical findings separately. Include sample size and the distribution of tested conditions. A small set of open site checks can support a limited statement without proving uniform performance at every obstructed feature in a large project. The conclusion should match the evidence actually collected.

Continue learning Completing a GNSS project handover that others can use

Explain exceptions and intended use limits

List significant exceptions, unresolved issues and restrictions that affect downstream work. Approximate coordinates, inaccessible features and unverified legacy references should be identifiable in both the report and data files. Avoid relying on a paragraph that users may overlook while the exported dataset contains no corresponding status. The quality information should travel with the coordinates wherever practical.

State what additional work would resolve an important limitation. That may include independent height control, recollection or a framework reconciliation. Do not present a speculative fix as completed verification. A candid limitation is more useful than an unsupported assurance, especially when the client will use the data for design, construction or later change detection.

Continue learning Writing GNSS survey specifications that can be verified

Describe the deliverable package

Provide a manifest of coordinate tables, GIS or CAD files, control descriptions, reports and relevant supporting records. Identify authoritative versions and file formats. Explain units, coordinate definitions and key attributes where the format cannot carry them clearly. If both original and transformed coordinates are delivered, distinguish their roles so a downstream user does not import the wrong file into a project template.

Include a readable folder structure and a route to the technical archive. Protect credentials and unnecessary personal information; they do not belong in a client deliverable. Check that links, filenames and referenced annexes actually exist. A technically sound report loses value when the recipient cannot locate the dataset it approves or determine which of several similarly named exports is final.

Continue learning Writing GNSS survey metadata that explains the coordinates

Close with a reviewable acceptance statement

The final acceptance statement should identify the dataset, method and checks supporting its intended use, together with material limitations. Name the responsible review role according to the organization's process. Avoid claiming guaranteed performance for future observations or applications outside the tested scope. The report is evidence for this deliverable under documented conditions, not a universal certification of the equipment.

A strong GNSS report connects physical marks, observations, processing and verification in a coherent chain. It gives a client enough clarity to use the data appropriately and gives another surveyor enough detail to assess or reproduce the work. That is more valuable than either an unexplained coordinate list or a large collection of software printouts with no clear conclusion.

Continue learning Accuracy, precision and uncertainty in GNSS reports

Practical checklist

Practical checklist

  1. Lead with the purpose and accepted result.
  2. Describe the deliverable package.
  3. Close with a reviewable acceptance statement.
EQUATOR GNSS

Plan your GNSS setup

Compare the EQ10 and EQ20 receiver specifications, then discuss the configuration and support your project needs.

Compare GNSS receivers

References

  1. NOAA NGS — User Guidelines for Single Base Real Time GNSS Positioning
  2. ESA — GNSS Data Processing, Volume I: Fundamentals and Algorithms
  3. IGS CORS Guidelines — Metadata