NiVO / BY TECHNOGISGermany · Indonesia
Geospatial

Preparing Portable GeoPackage Deliverables With Reliable Field Types

Package related vector layers with clear schemas, identifiers, coordinate references, and transfer checks so a single GIS file remains useful beyond its creator's workstation.

Preparing Portable GeoPackage Deliverables With Reliable Field Types

Define the package contents

A GeoPackage can hold related geospatial layers in a SQLite-based container, making it convenient for handing over an asset inventory or survey interpretation. Decide which layers, tables, and relationships belong together before export. A single filename is useful only if its contents are understandable. Avoid mixing draft and approved layers without clear names, status fields, and a manifest explaining their intended use.

Design a stable attribute schema

Choose field types from the information being stored. Asset identifiers with leading zeros often need text rather than numeric treatment; measurements need explicit units; dates need a documented convention. Distinguish missing values from meaningful zero or an empty string. Keep stable project identifiers separate from software-generated row identifiers so subsequent exports or edits do not break references between inspection records and mapped assets.

Hands annotating a paper map at a Development Seed mapping event
Hands annotating a paper map at a Development Seed mapping event.Source: Development Seed · CC BY 2.0

Check geometry and coordinate definitions

Confirm geometry types, dimensionality, coordinate definitions, and validity after writing. A layer expected to contain polygons should not silently become a mixed collection that the recipient cannot edit. Inspect whether elevation values are stored as geometry coordinates, attributes, or both, and explain any difference. Verify the package in the receiving software rather than assuming that a successful export preserves every application-specific interpretation.

Separate stored data from application styling

Rendering rules, forms, external photographs, and project settings may depend on software-specific extensions or files outside the package. Identify those dependencies explicitly. A coloured layer on the creator's desktop may reopen with plain symbols elsewhere while the underlying data remain intact. Decide whether to supply a separate project file and media folder, keeping relative links portable and documenting the required application support.

Close and test the transferable file

In a hypothetical inspection handover, finish edits and close writing applications before making a clean copy. Open that copy from a new folder, query known asset identifiers, inspect null values and dates, and test links to evidence photographs. Check feature counts and representative geometries against the source. Validate the container where suitable tooling is available and resolve compatibility issues before the recipient starts operational edits.

Provide a compact data dictionary

Deliver a concise layer catalogue and data dictionary defining identifiers, units, status codes, coordinate references, source dates, and external dependencies. Include the checked application versions and any restrictions on extensions used. Acceptance should establish portable, correctly typed data and reconstructable relationships. GeoPackage simplifies packaging, but it does not automatically supply correct classification, authoritative ownership, or an audit trail that the project never recorded.

Technical references

  1. GDAL GeoPackage vector driver documentation ↗
  2. OGC GeoPackage standard overview ↗
← All articles

Related articles

All articles ↗
LET’S TAKE FLIGHT

Your next mission
starts with a conversation.

Talk to our team