From Shapefile to GeoPackage: keep the survey intact

Imagine a small survey team handing over a season's sampling locations. The points appear on the map, but the recipient also needs to join laboratory results, read place names, and distinguish a missing measurement from a recorded zero. Moving that archive from Shapefile to GeoPackage with GDAL's ogr2ogr is a useful migration only if those relationships survive. The conversion command is the middle of the job; agreement about what each record means comes first.

GeoPackage offers a practical destination. The Open Geospatial Consortium defines it as an open format built on SQLite, with conventions for storing spatial features, attributes, and other geospatial content. Multiple layers can travel in one database file. Its appeal for a field team is straightforward: a deliverable can carry its tables and spatial reference information together.[1]

There is institutional experience behind that promise. In December 2021, the USGS announced GeoPackage distribution for its hydrography products, citing open-format requirements and use across commercial and open-source software. The same announcement documented changes to the delivered data, including extra columns explaining coded values. That historical example supports a useful migration principle: portability includes making meaning legible to the next reader.[2]

A USGS hydrologist holds a GPS survey pole and handheld controller in rocky desert terrain below low mountains. — A USGS hydrologist collects GPS locations during a near-surface geophysics survey in 2007. Credit: USGS Office of Groundwater, Branch of Geophysics; public domain.[3]

Preserve a baseline before improving anything

For the illustrative survey, begin by retaining the complete original delivery. A Shapefile layer normally includes .shp, .shx, and .dbf files; accompanying .prj and .cpg files can supply coordinate-system and encoding information. GDAL reads those companions when interpreting the data.[4]

Put a copy aside, then inspect the working copy:

ogrinfo -ro -al -so -mdd SHAPEFILE survey_points.shp

Here, -ro opens the source read-only, -al selects all layers, and -so reports summary information, including schema, feature count, extent, and coordinate reference system. The metadata request exposes the Shapefile driver's interpretation of the source encoding.[4][5]

Save this output with the handoff notes. It gives the team something more precise than a screenshot to compare after conversion. Also choose a few records whose meaning is known from field notes: a site with an accented name, an identifier beginning with zero, an unusually large measurement, and an observation with missing data. These are suggested acceptance examples, not a claim about the contents of any particular survey.

Encoding deserves attention before export. GDAL tries the .cpg declaration and then the DBF code-page marker; an incorrect declaration can produce incorrect text. An ENCODING open option can override that interpretation when the actual encoding is established. Merely moving unreadable names into a new container will not explain what they were supposed to say.[4]

Make one conversion easy to explain

Assume the source is a simple point layer with a verified coordinate system and correctly decoded attributes. Use a fresh destination filename:

ogr2ogr -f GPKG survey_delivery.gpkg survey_points.shp \
  -nln survey_points

ogrinfo -ro -al -so survey_delivery.gpkg

ogr2ogr takes the destination before the source; -nln fixes the output layer name. This example changes the container without requesting reprojection. It also leaves out -skipfailures, which would allow conversion to continue past failed features.[6]

GDAL's GeoPackage driver creates a spatial index by default. The output format version also depends on the GDAL release: its documentation records a default change from GeoPackage 1.2 to 1.4 beginning with GDAL 3.11. Record the tool version and check the receiving application's supported format version before standardizing the export.[7]

Keep the first pass deliberately modest. Renaming fields, correcting observations, and transforming coordinates at the same time makes a discrepancy harder to explain. Once the baseline transfer is accepted, a separate revision can introduce clearer names or corrected values with an explicit change record.

A coordinate label cannot repair a coordinate

GDAL separates two operations that can look similar in an export dialog. -a_srs assigns an output spatial reference without transforming coordinates. -t_srs transforms coordinates into the requested reference system, using the source definition or an explicit -s_srs override.[6]

For example, labeling coordinates measured in a projected system as longitude and latitude leaves the original numbers untouched. The metadata has changed while the location has become misdescribed. If the source reference is unknown, recover it from survey documentation before deciding on an output system. A file extension cannot answer that question.

For an unchanged-coordinate transfer, compare the reported extents and inspect known sites against an independently trusted reference. Treat agreement as evidence about the migration, while retaining the survey's original uncertainty about measurement accuracy.

Keep the observation's identity separate from its row

The sampling site's identifier should remain usable when the file is reopened, edited, or joined to another table. A Shapefile's internal feature identifiers are a weak substitute: GDAL documents that repacking a Shapefile renumbers its FIDs.[4] GeoPackage has an integer primary key, normally named fid in GDAL output, but that database key does not itself define the team's sampling scheme.[7]

My recommendation for this example is a separate, verified site_id attribute. Check uniqueness, missing identifiers, and the join to laboratory results before accepting the delivery. Decide explicitly how revisits are represented: a location identifier may repeat across observations even when each observation needs its own unique key. That decision belongs in the data dictionary.

The container also cannot reconstruct information already absent from the source. DBF field names have a ten-character limit; any expanded names should come from documented definitions rather than guesses about abbreviations.[9]

Rehearse the recipient's next task

Open the delivered layer in the receiving application, inspect the chosen records, and run the actual laboratory-data join. Compare feature counts and schema with the baseline, then check unmatched identifiers and unexpected duplicates. A matching count can coexist with a broken join. ogrinfo supplies useful summaries; reading those summaries is not a geometry-validity or GeoPackage-conformance test.[5]

The Library of Congress's independent format assessment highlights use on mobile devices with limited connectivity.[10] For a small team with an accountable data steward, that makes GeoPackage a useful local working and delivery format. Keep a known-good source, a documented conversion, and an accepted export. That workflow needs enough operational discipline to identify which copy is authoritative.

Concurrent editing changes the decision. SQLite permits one writer at a time per database file, though writers can take turns. Its own guidance recommends client/server storage when many writers cannot queue and cautions against simultaneous direct access across network filesystems.[8] A team needing that coordination should assess a server database while keeping GeoPackage available for portable deliveries.

The migration earns its keep when another person can locate the site, interpret the attributes, and reproduce the join. Those are the actions that turn a smaller pile of files into a trustworthy handoff.

cronfeed.work