Tuesday, November 1, 2016

Internal Versioning for GeoPackage Files

We have a tricky situation and I need some feedback from the community to make sure we do it right. What we need is a way to identify the exact version of the GeoPackage in use in a particular file. We have tried to maintain compatibility between versions as much as possible, but there are subtle differences between one version to the next. Most applications handle these differences through duck-typing but conformance tests (like the emerging GeoPackage 1.0 ETS) do not have that option.

A recently opened ticket presents a possible way forward here. The recommendation is to for GeoPackage 1.2 to go back to using the SQLite application_id "GPKG" and to use the SQLite user_version to indicate the GeoPackage version. This would be an improvement over where we were heading - registering a series of application_id values (GP10, GP11...), suggesting completely different and incompatible versions.

There are two possible problems with this approach. The first is that GeoPackage providers are already using the user_version for their own uses. The other possible issue is that early versions of SQLite software don't support that field. We don't know of anyone that would be troubled by either. If you do, please let us know!