For whom it may concern,
Paul Ramsey writes that Geoserver does not set application_id when it creates GeoPackages with the community module. Obviously it should.
http://news.gmane.org/gmane.comp.gis.gdal.devel
-Jukka Rahkonen-
Hey Jukka,
Yeah, I filed this ticket a few weeks back.
http://jira.codehaus.org/browse/GEOT-4816
I asked Paul to approach the gdal dev list about potentially being lenient here because fixing this one is tricky on the Java side. The sqlite driver we use uses an older version of sqlite that doesn’t have the ability to set the application_id through the driver itself. So the only option for us would be to manually rewrite those bytes of the file, which while possible I feel would be error prone. Cleaner would be to upgrade the driver to include a newer sqlite version. Which looks to be coming soon as a 3.8.5 pre release version was just posted last week.
Given that the application_id seems like a relatively obscure feature and that it is pretty common to find the sqlite installations that are older than 3.7.17 it didn’t seem like an unreasonable request. Also looking at the MBTiles driver it doesn’t check the application_id while MBTIles has an assigned number.
http://www.sqlite.org/src/artifact?ci=trunk&filename=magic.txt
-Justin
···
On Tue, Aug 12, 2014 at 6:51 AM, Rahkonen Jukka (Tike) <jukka.rahkonen@anonymised.com…1245…> wrote:
For whom it may concern,
Paul Ramsey writes that Geoserver does not set application_id when it creates GeoPackages with the community module. Obviously it should.
http://news.gmane.org/gmane.comp.gis.gdal.devel-Jukka Rahkonen-
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
VP Engineering | Boundless
jdeolive@anonymised.com
@boundlessgeo
