Using GeoPackage for a structured GNSS survey archive

Define the package’s role in the project

GeoPackage is a standards-based SQLite container for geospatial information. It can be useful for organising multiple related layers in one portable file, but the file format alone does not create a complete survey archive. Decide whether the package is a working database, an accepted-position delivery or a long-term exchange snapshot. Each role needs clear update and release rules.

List the geometry layers, non-spatial tables and supporting files required by the project. Keep raw GNSS observations and specialised equipment logs in their appropriate original formats where necessary. A GeoPackage can index or reference that evidence without pretending to replace it. The archive should preserve both the spatial products and the information needed to understand how they were produced.

Continue learning Exporting GNSS data to GIS without losing its meaning

Design layers around physical meaning

Separate control points, observations, assets, breaklines and derived products according to their purpose. Use stable identifiers and explicit relationships rather than relying on layer order or matching coordinates. One asset may have several observation records, and a control mark may have a history of accepted coordinate releases. The schema should support those distinctions.

Document geometry types and required attributes for each layer. Avoid storing unrelated objects in a generic points table solely because they share a geometry type. Clear layer semantics make validation and later updates easier. A recipient should be able to tell which records are direct observations, accepted positions or interpretations without asking the original author to explain every table.

Continue learning Organizing GNSS project folders for reliable processing and handover

Preserve reference definitions and provenance

Store the appropriate CRS for each spatial layer and provide the wider survey metadata needed to interpret it. Include datum realisation, coordinate epoch, local grid parameters and vertical reference where relevant. A standard CRS identifier may not capture every operation applied during survey processing. Record transformation and geoid model versions in the project metadata.

Keep source observations or traceable source identifiers when coordinates are transformed. Do not overwrite the only original coordinate record during a delivery conversion. If different layers use different references, state why and test their relationship. A single container can hold multiple layers, but that convenience should not conceal incompatible spatial or height definitions.

Continue learning Shapefile limitations that matter in GNSS survey handovers

Use attributes and relationships deliberately

Define field types, units, coded values and unknown states. Keep identifiers as text when needed to preserve leading zeros or long codes. Separate feature identity from observation identity. Use the capabilities supported by the chosen software and verify that important relationships survive transfer. A database design that works in one application may rely on extensions another tool does not understand.

Test constraints and joins with representative records, including revisits and superseded observations. Preserve review status and correction reasons. Avoid a schema that requires deleting old evidence whenever a new coordinate is accepted. The archive should allow a later reviewer to understand how the current position was selected and what observations preceded it.

Continue learning GNSS GeoJSON export quality: coordinates, geometry and provenance

Handle attachments and external evidence explicitly

Decide whether photographs and documents are embedded through a supported mechanism or stored externally with stable references. Record the chosen convention and test it in the receiving workflow. A relative path may be portable when the directory structure is preserved, while an absolute personal path often breaks on another computer. Do not assume the database file automatically contains every linked image.

Create a manifest for raw files, reports and other evidence that remain outside the package. Link them through stable feature or observation identifiers. Test a delivered copy from its final directory. The recipient should be able to locate supporting evidence without guessing which folder name or camera filename corresponds to a particular point.

Continue learning Exporting GNSS data to GIS without losing its meaning

Protect working data and release snapshots

Use a clear backup process appropriate to the tools and file state. Avoid copying an actively changing database blindly and assuming the result is a coherent release. Follow the software’s supported method for completing edits and creating a transferable snapshot. Keep working and issued versions distinguishable so recipients do not unknowingly use an unfinished file.

Record the package version, observation coverage and effective release date. Preserve earlier releases when updates are issued. If several people need simultaneous editing, assess whether a file-based workflow suits the project or whether another managed database arrangement is more appropriate. Portability is valuable, but it does not remove the need for coordinated ownership and update rules.

Continue learning Organizing GNSS project folders for reliable processing and handover

Validate the package and its contents

Check standards conformity using suitable tools, then validate the survey meaning separately. Review layer counts, geometry types, CRS definitions, identifiers, attributes and relationships. Compare representative coordinates and records against the source. A technically valid GeoPackage can still contain a wrongly assigned reference or a point linked to the wrong asset.

Open the package in the intended receiving application and test important workflows. Confirm that layers, field values and attachment references are available. Inspect unknown values, dates and long identifiers. If a simplified export is created from the package, validate that export independently rather than assuming it inherits every quality property of the source container.

Continue learning Shapefile limitations that matter in GNSS survey handovers

Deliver documentation with the portable file

Provide a data dictionary, layer guide, reference definitions, source manifest, review status rules and unresolved issues. State which layers are authoritative for the release and which are derived. Explain how later observations should be added and how accepted positions are revised. A portable file is most useful when another team can maintain it without reverse-engineering its schema.

Archive the issued package with its supporting evidence and validation results. Retain the process used to create it. GeoPackage can make a GNSS survey handover easier to organise, but dependable archival value comes from a documented data model and traceable observation history. The container supports that work; it does not perform it automatically.

Continue learning GNSS GeoJSON export quality: coordinates, geometry and provenance

Test a package on a second workstation

Before release, copy the intended delivery structure to a separate test location and open it without access to the author’s working folders. Check layers, joins, photographs and metadata. This reveals dependencies hidden by the original computer’s paths or application state. Include a revisit and a superseded observation in the test so history relationships are exercised, not only current positions.

Record and resolve missing dependencies through the package design or manifest. If a receiving tool cannot interpret a nonstandard extension, provide an agreed interoperable view while preserving the full archive. Repeat only the affected checks after correction. This practical portability test makes the handover reviewable and reduces the chance that a well-organised file becomes an incomplete archive as soon as it leaves the authoring workstation.

Include the test location and receiving application version in the validation note where useful. The test should demonstrate the intended handover workflow rather than merely prove that the file opens somewhere. If external evidence remains outside the package, verify its manifest and relative paths after copying. A portable container and a portable archive are related but different achievements. The complete delivery is ready when the recipient can locate the required evidence and understand the authoritative layers without access to the author’s private workspace.

Continue learning Exporting GNSS data to GIS without losing its meaning