A QGIS workflow for reviewing GNSS survey data

Begin with a protected source package

Keep the original GNSS export, reference information and field notes together before opening a working copy in QGIS. Identify whether the records are raw observations, accepted positions or derived asset locations. Obtain a data dictionary where possible. A project file can organise layers, but it does not replace the source files or the evidence explaining what each coordinate represents.

Create a clear workspace for source, working and released data. Record the date and source of incoming files. Avoid editing the only copy of a coordinate table while investigating an import problem. A protected source package allows the reviewer to repeat the workflow and distinguish an original observation from a change introduced during GIS processing.

Continue learning Exporting GNSS data to GIS without losing its meaning

Import with explicit field and reference choices

For a coordinate table, identify the correct geometry columns, delimiter, encoding and field types. Confirm axis order and units from the source documentation. Preserve identifiers as text when leading zeros or long codes matter. A point plotted somewhere near the project is only a preliminary check, not proof that every import setting is correct.

Assign the source CRS that describes the existing coordinate values. Do not assign the desired output CRS to unchanged values. QGIS can display layers through on-the-fly transformation, so layers appearing together in one map does not mean their stored coordinates have been converted. Keep the distinction between layer reference, project display reference and exported output reference clear.

Continue learning Designing a geodatabase schema for GNSS point observations

Review the reference chain and transformations

Check datum realisation, coordinate epoch where relevant, local grid parameters and vertical reference. A standard CRS code may not describe a project-specific calibration. If transformation is needed, select the appropriate operation for the area and available reference information. Record required grids or models and their versions. Avoid accepting an unexplained fallback operation without understanding its suitability.

Test representative known points through the workflow. Compare horizontal and vertical components separately, since a common horizontal display does not establish elevation compatibility. Preserve original heights and document any geoid or vertical operation. Assigning a different CRS label changes interpretation; a documented transformation changes values. This distinction is central to a dependable GIS survey workflow.

Continue learning A clear vertical datum handover for GNSS survey projects

Inspect attributes before spatial analysis

Review identifiers, dates, codes, null values and units. Check for duplicates and impossible combinations using the project’s definitions. A duplicate feature identifier may represent a valid revisit or a data error, so investigate rather than deleting automatically. Keep observation identifiers separate from asset or plot identifiers where the data model supports repeated visits.

Confirm that quality fields retain their documented meaning. An instrument precision estimate should not become a generic independent accuracy claim. Preserve direct, offset-derived, provisional and rejected statuses. If supporting photographs or notes are linked externally, test a sample of those links from the working location. The map’s geometry is only one part of the observation evidence.

Continue learning A traceable ellipsoidal height workflow for GNSS surveys

Review geometry against field evidence

Inspect the extent, known locations and unexpected outliers. Use a suitable reference layer for context while recognising that a basemap is not necessarily survey control. Compare selected points with approved control or clearly identified physical features. Check line connections and polygon boundaries where the GNSS points have been assembled into more complex objects.

Look for geometry that is technically valid but semantically wrong, such as a line joining unrelated assets or a polygon representing a centroid rather than a boundary. Use field photographs and notes to resolve ambiguous features. Do not move points by eye to improve their appearance over background imagery. Any coordinate correction should have a documented cause and evidence.

Continue learning Exporting GNSS data to GIS without losing its meaning

Keep analysis and accepted observations distinct

Create derived layers for buffers, interpolated surfaces or interpreted connections rather than overwriting the accepted observation layer. Name them according to their purpose and source version. A terrain model or inferred utility line is not the same evidence as the original GNSS points. Preserve the distinction in both layer names and metadata.

When a processing operation changes geometry or coordinates, record its parameters and relevant software version. Test a small representative subset before running a large conversion. Review the output feature count and attributes. A successful processing message confirms execution, but it does not establish that the result still represents the intended physical objects or reference system.

Continue learning Designing a geodatabase schema for GNSS point observations

Export and reopen the delivery dataset

Choose a format suited to the recipient and the information being delivered. Review limitations in field names, types, geometry and reference metadata. If a simplified exchange file is required, keep the complete working dataset separately. Apply any intended coordinate transformation explicitly during export and document the source and target references.

Reopen the exported file in a clean project or the receiving application. Compare identifiers, coordinates, units, dates and attachment links with the source. Check a few known positions and inspect the extent. This round-trip review catches problems that remain hidden while the original layers are still present in the authoring project.

Continue learning A clear vertical datum handover for GNSS survey projects

Deliver a reproducible project record

Provide the released data, reference definitions, data dictionary, transformation history and unresolved issues. Include the QGIS project where useful, but ensure its paths and dependencies are understood. A project that points to personal folders may not work for another team. Package supporting files through a deliberate handover process and test the result from its delivered location.

Archive the protected source package and working history. Future updates should repeat the documented process or explain changes to it. A reliable QGIS workflow preserves the meaning of GNSS observations while making them useful for mapping and analysis. The strongest evidence is a traceable source-to-release sequence, not simply a map that looks correct on the author’s screen.

Continue learning A traceable ellipsoidal height workflow for GNSS surveys

Check a display-versus-storage misunderstanding

Suppose a layer appears in the desired project CRS on screen, but the recipient finds its coordinate values are still geographic degrees. Review whether the layer was only displayed through on-the-fly transformation. The project display reference does not necessarily change the stored layer values. Export the layer through the intended transformation if projected coordinates are required.

Reopen the exported file and inspect its stored reference and representative coordinate values. Keep the original geographic layer and document the derived projected output. This avoids confusing a correct visual display with a completed data conversion. It also helps the recipient understand why two files describe the same features with different numbers and which one belongs in their intended analysis or survey workflow.

If a project includes layers stored in several references, provide a layer guide explaining their purpose and stored CRS. A recipient should not have to infer this from the current map canvas. Name derived exports clearly and keep the source layer available in the archive. When a processing operation requires a particular projected reference, verify the actual input values or operation settings rather than relying only on how the layer is displayed. This prevents a display convenience from becoming an unnoticed assumption in distance or area analysis.

Continue learning Exporting GNSS data to GIS without losing its meaning