[Geopackage] Geopackage Digest, Vol 18, Issue 4
jeffy at imagemattersllc.com
Sun Dec 27 23:02:28 EST 2015
I don't think I understand what you are getting at regarding #132. Perhaps
the issue is that I never got around to updating Requirement 2 to bump the
version number. (I just added that as issue 188 / pull request 189.) A
1.0/1.0.1 implementation would have extension names as annexes and a 1.0.2
implementation would have them as sub-annexes. We haven't been rigorous
about avoiding SHALL statements outside of enumerated requirements.
Addressing this could get complicated and could easily do more harm than
Regarding #137, I like the idea of an additional column. I opened up issue
190 <https://github.com/opengeospatial/geopackage/issues/190> for that
purpose. However, this issue is too complicated for me to resolve
I haven't heard specifically, but I assume there will be a 30 day review
period or something like that before 1.0.2 can go up for adoption vote. I
am just trying to get that clock started. We are still able to fix issues
On Sun, Dec 27, 2015 at 12:00 PM, <
geopackage-request at lists.opengeospatial.org> wrote:
> Send Geopackage mailing list submissions to
> geopackage at lists.opengeospatial.org
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> geopackage-request at lists.opengeospatial.org
> You can reach the person managing the list at
> geopackage-owner at lists.opengeospatial.org
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Geopackage digest..."
> Today's Topics:
> 1. Re: Preparing for GeoPackage 1.0.2 (Brad Hards)
> Message: 1
> Date: Sun, 27 Dec 2015 12:25:24 +1100
> From: Brad Hards <bradh at frogmouth.net>
> To: geopackage at lists.opengeospatial.org
> Subject: Re: [Geopackage] Preparing for GeoPackage 1.0.2
> Message-ID: <1632978.lgvbIJsYWT at saxicola>
> Content-Type: text/plain; charset="us-ascii"
> On Sat, 26 Dec 2015 11:21:04 AM Jeff Yutzler wrote:
> > All,
> > The SWG has recently voted to recommend to the OGC Technical Committee to
> > adopt the working version of the GeoPackage specification as Version
> > For more details, please see my blog post:
> > http://geopackage.blogspot.com/2015/12/preparing-for-geopackage-102.html
> There are two issues that you aren't considering in that text.
> The first is that the change in #132 means that any implementation that has
> extensions will be generating non-compliant gpkg files (since "The
> column value in a gpkg_extensions row for those extensions SHALL contain
> sub-annex name and as a reference "). That isn't likely to cause problems
> then, it probably could be "should") but it would be worth noting.
> The other is that #137 is a breaking extension, which isn't what extensions
> should be for (extend, not change). There is a warning (even in bold!) but
> there is no way that the producer can possibly check that all consumers
> how to handle new-style CRS WKT. It might have been possible in a network
> scenario, with some kind of protocol negotiation, but it doesn't work in a
> mass-market offline tool.
> I do have a suggestion, and that is that the extension should add a new
> to the gpkg_spatial_ref_sys table (srtext2, or whatever name the committee
> would like to agree on), so that consumers that can handle the new-style
> if available, but would still be able to use the old WKT if they haven't
> I know you want to get 1.0.2 out, but I think a little more work on that
> extension is warranted.
> End of Geopackage Digest, Vol 18, Issue 4
Image Matters LLC <http://www.imagemattersllc.com/>
Mobile: (703) 981-8753
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Geopackage