One constant area of confusion is the notion of "GeoPackage" vs. "Extended GeoPackage". The idea is that a file using just core elements would be a GeoPackage and that one including extensions would be an Extended GeoPackage. However, this has caused problems in practice and we have had to adapt. A couple of months ago I wrote about non-spatial tables. Recently we got rid of the clause that allowed Extended GeoPackages to use the .gpkx extension (no one was). It turns out that this wasn't enough.
We have been getting some push-back on the WKT for Coordinate Reference Systems extension because it adds a column to the gpkg_spatial_ref_sys table. While we feel that we were justified in this decision, it does affect some design decisions. For one thing, Object Relational Mappings are more complicated when a column might or might not exist. However, we have gotten feedback from other developers that adding columns to tables as part of extensions is a reasonable and necessary technique. What to do?
I propose to tweak a few requirements to get past this. To summarize, the GeoPackage designation acts as a sort of compatibility mode. At the expense of extensions, you get maximum interoperability. If you produce a GeoPackage with extensions (by definition an Extended GeoPackage) then your risk of interoperability issues increases (though hopefully is still small). We hope that applications and libraries will grow to deal with extensions gracefully but in the meantime, avoiding unnecessary extensions does provide the greatest interoperability.
Does this work for you? Let me know here, on the mailing list, or on Twitter.
