Writing GNSS survey metadata that explains the coordinates

Metadata answers practical questions

A coordinate table is incomplete if a new user cannot tell what the numbers represent. GNSS survey metadata explains the reference system, physical point definition, observation method and processing history behind the values. It should answer practical questions that arise during use: which height is supplied, which units apply, how the reference was established and which parts of the dataset have different limitations.

Write metadata as the work progresses rather than reconstructing it entirely at the end. Field events and configuration changes are easier to record accurately when they occur. A project template can help, but it must be completed with actual information. A polished generic description that does not match the equipment or reference arrangement used is less useful than a concise, accurate account of the campaign and its exceptions.

Continue learning Accuracy, precision and uncertainty in GNSS reports

Define the coordinate reference

Identify the horizontal reference system, projection where used, units and axis order. Include reference frame and epoch when relevant to the project. A broad label such as GPS coordinates may leave several important interpretations unresolved. If a local transformation is used, describe its source, control and applicable area. Preserve the parameters or the controlled configuration needed to reproduce it under the project workflow.

Describe heights separately. State whether delivered values are ellipsoidal, orthometric or another defined quantity, and identify the vertical reference or model used. Include units and any known limitations. Avoid assuming that the horizontal coordinate system name explains the height field. A client may import the table successfully while assigning the wrong vertical meaning unless the metadata makes that distinction explicit.

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

Describe what was physically measured

Explain the point definition for important feature types. A coordinate may describe a cover centre, a wall corner, a pole tip contact or a point derived through an offset. The feature code alone may not be enough for a user unfamiliar with the field dictionary. Link the dictionary and examples where needed. This prevents a precise number from being applied to the wrong part of a physical asset.

For control and reference setups, include mark descriptions, antenna identification and height measurement conventions. Keep setup specific details linked by identifiers rather than burying them in a long general paragraph. A user investigating one observation should be able to reach its physical setup record efficiently. The metadata structure should support both a quick overview and a focused review of a particular point or session.

Continue learning Using GNSS antenna calibration information correctly

Record equipment and methods

List receiver and antenna models, relevant firmware or software versions and the measurement methods actually used. Distinguish real time observations from later processed results or points connected by another approved method. If equipment changed during the campaign, identify the affected dates or work zones. A single equipment list without those boundaries may hide differences that matter to interpretation or reproducibility.

Describe the correction arrangement and reference coordinate source. For a service, preserve the technical identification without exposing private credentials. For a local base, link the approved coordinate and setup history. Explain any fallback workflow used after communications failures. This helps a reviewer understand why two nearby points may have different processing records even though they appear in one final coordinate table.

Continue learning Maintaining CORS station metadata and equipment history

Explain quality evidence honestly

Summarize independent checks, repeat occupations and the acceptance criteria used. Keep internal receiver estimates distinct from external comparisons. A statement that every point was fixed does not describe the complete quality assessment, and a single average check difference may conceal important exceptions. Link detailed results where appropriate and explain which environments or work zones were covered by the verification.

State limitations in concrete terms. An area measured under canopy, an unavailable independent check or a provisional reference connection should be identified with its consequence for use. Avoid vague claims of survey grade accuracy without a method and evidence. Metadata is most valuable when it helps the next user decide whether the dataset is suitable for a particular task, including tasks different from the original collection purpose.

Continue learning Accuracy, precision and uncertainty in GNSS reports

Preserve processing and revision history

Record conversions, transformations and processing steps that materially affect the delivered values. Identify source files and software configurations through stable references. If coordinates were revised, explain the reason and distinguish superseded outputs from the approved deliverable. Do not rewrite the history to make the final dataset appear to have been correct from the first export. A transparent correction record supports confidence more effectively than an unexplained final label.

Keep observation time conventions and important equipment events with the processing record. These details help align raw files, photographs and correction logs during a later review. If an external service supplied a result, identify the service and available report rather than implying that the team retains every processing input. The metadata should describe the evidence actually preserved and make any reproducibility boundary clear.

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

Choose accessible formats and locations

Provide a concise human readable overview and machine readable fields where the destination workflow benefits from them. Keep metadata beside the deliverables and include stable links to supporting records. A reference to a temporary folder on one operator's computer is unlikely to survive handover. Test the package from the location the client or next team will actually use, including the availability of linked documents and photographs.

For a simple coordinate export, a well structured accompanying text document may be sufficient. A larger GIS delivery may need dataset level and feature level metadata. Scale the structure to the use, but do not omit essential coordinate definitions because the file format appears familiar. A successful import into software is a syntax test, not proof that the user has interpreted the reference, units and point meaning correctly.

Continue learning Using GNSS antenna calibration information correctly

Review through a new user's eyes

Ask a colleague unfamiliar with the fieldwork to identify the coordinate system, height type, approved version and quality limits from the handover package. If they must guess, revise the metadata. This review tests usability rather than merely checking that a form has been filled. It can reveal missing explanations that seem obvious to the original crew because they remember decisions never written into the archive.

For example, a drainage dataset should make clear whether heights refer to cover levels, accessible inverts or another defined feature, and which points were not observed directly. That information can change how the data are used in analysis. Good metadata preserves the relationship between coordinates, physical features and evidence. It allows the survey to remain understandable after the original controller, crew and project conversations are no longer available.

Include a contact role for questions about the dataset and an organization reference where the project requires it. The metadata should remain useful when an individual operator moves on. Keep this separate from private account access details; technical provenance and support responsibilities can be documented without distributing passwords or unrelated personal information.

Continue learning Maintaining CORS station metadata and equipment history