[Geopackage] How should we register GeoPackage versions inside the SQLite database?

Brad Hards bradh at frogmouth.net
Thu Nov 3 15:59:49 EDT 2016

> What we do know is that updating the application_id (SQLite magic.txt) each
> release is not sustainable. I'm also not a big fan of duck-typing and would 
> much
> rather providers disclose up front what they are doing. The fact that we 
> have to
> do duck-typing at all is a symptom that we don't have robust versioning and
> conformance yet.
I still think that the requirement for versioning is implicit, and the right 
solution (or right-ness of a potential solution) to that requirement won't be 
clear until  it is explicit.

What are we expecting that consumers will do with the version information?

What is the objection to duck-typing? (which is essentially dealing with the 
information as presented). Should we just have some implementation guidance on 
how to deal with extra tables and columns? If the SWG plans to keep making 
changes, then there needs to be some migration strategy for older producers 
and older consumers.

> I submit that conformance does matter. (You wouldn't want
> someone to provide a file to a GeoJSON reader that doesn't pass GeoJSONLint,
> for example.)
I am not arguing that conformance doesn't matter, but rather that if the only 
reason you are putting a version in is for the conformance checker, then that 
is a low priority need.

> A wild-west approach could lead to problems in production
> systems.
Maybe we are getting somewhere here. What kind of problems could occur? If we 
understand those (potential) problems - at least at some high level - then we 
can find the right versioning solution.

> I would consider Even's suggestion (which was also brought up independently
> during Monday's meeting) of a simple table dedicated to that purpose and
> abandoning the use of application IDs inside the SQLite headers.
The advantage of the application ID is that it is easy to check without 
dedicated tools (e.g. the file(1) utility in unix). So I can tell if I can 
handle without doing a lot of work.
Maybe it is enough to keep the GPKG flag, with a "major" version id.
That could be combined with a dedicate table, ideally identifying feature 
capabilities and not just a version number.


More information about the Geopackage mailing list