OGC Geopackage for Data Storage Back-End

I’m not sure if GeoPackage was ever tested/considered during development of ODM as the data storage back-end, but I think it might have a few characteristics that may make it worth considering.

  1. Dependencies, Dependencies, Dependencies
  2. Single-File database for Raster/Vector
  3. Already in-use in the code for vector product storage

This talk gives a decent summary, and even exposes some nice GDAL code to load/save from PG to GPKG.

Please let me know if you already considered this and other factors (clustering, etc.) made it insufficient as a back-end storage.

1 Like

GPKG is great; but what would be its application (what would it replace)?

1 Like

I was envisioning it as a replacement for PostgreSQL that is used currently to reduce install footprint, complexity, maintenance/integration burden, and external dependencies as GPKG seems to already be used elsewhere in ODM.

Would be an interesting experiment for sure. Not sure how nicely GPKG works with Django though.

1 Like

Does this suit the purpose?

I really hope geopackage could help simplify things… Setting up the PostgreSQL database after (for instance) upgrading LiveODM out of 16.04LTS was a nightmare, and keeping it back on v9 was a non-option as it ruined other dependencies.