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

Jeff Yutzler jeffy at imagemattersllc.com
Thu Nov 3 09:25:13 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 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.) A wild-west approach could lead to problems
in production systems.

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.

On Wed, Nov 2, 2016 at 4:40 AM, Brad Hards <bradh at frogmouth.net> wrote:

> What is the actual problem you are trying to solve?
> That is, why do you want to identify something specific?
> If it is just for conformance tests, then we're optimising the wrong part
> of
> the problem...
> Brad

Jeff Yutzler
Image Matters LLC <http://www.imagemattersllc.com/>
Mobile: (703) 981-8753
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20161103/a00eb108/attachment.html>

More information about the Geopackage mailing list