Add GeoPackage as a Provider #161
Comments
|
This one is in progress. @JivanAmara can you give us an update? |
|
Using go-sqlite, I'm writing a basic library to read gpkg files (and the wkbgeometry format used inside them) as a tegola provider. Have a rough version working on a particular gpkg that loads layers and doesn't throw any errors, but something is preventing tiles from showing up in the map. Once the branch is working at a basic level and I've cleaned up a bit I'll share. |
|
@fawick a bit more about this. Since Geopackage uses SQLite, we're waiting for an SQLite port to Go. In the mean time a bridge via cgo is necessary. There are two projects working on SQLite in pure go though, and we're watching those. |
|
Although I am well aware of the call overhead that CGO induces I would like to make a case for using the official SQLite library via CGO. The main advantage I see is that the official SQLite sources are rigorously tested. In fact, their testing suite suffices the very strict requirements of the DO-178 aviation standard for safety-critical software. As every aviation software creator is required by DO-178 to present and re-do these tests the folks behind SQLite sell this testing suite via a proprietary license. Nevertheless, any SQLite version they make is checked against it behind the curtains before it is released. It is mingboggingly to see such a thing in open-source (and even Public Domain) software and IMHO makes SQLite one of the (if not THE) most mature FOSS projects there are. I reckon they put tens of man years of engineering into coming to that point. Any attempt to come up with a SQLite package in pure Go will be having a hard time ensuring that same level of robustness. |
|
@fawick using CGO is the current strategy that @JivanAmara is working on for several of the reasons you have mentioned and the fact that it's the only way to leverage SQLite in Go. The pure Go projects we're watching:
Ultimately this is a data provider and it needs to be stable. I would prefer tegola be pure Go, but we're going to implement some cgo while other packages mature. |
|
…l logger format and updated logs in various server packages. fixed breaking tests. #161
#161 rewrite of the binary header code.
…Close / Cleanup #161 - gpkg connection pool concept was converted into a Close() method which will be called by a higer level connection manager. - travis had overlapping go version envrionments - gpkg Provider now has a Close method for closing database connections - gpkg Provider now has a Cleanup method for cleaning up database connection before tegola shuts down
There was a need for providers to have the ability to clean up when a program is ending, or is reloading configs.
The build matrix did not seprate out each entry. It made six entries instead of three.
The build matrix did not seprate out each entry. It made six entries instead of three.
The providers now have a clean up that needs to happen before the binary exits. This is handle by trapping terminal signals and running the clean up routines. The initial way we were doing this was not correct.
On go 1.7 we will use Close() which will just kill the connection. It's highly recommened that you use 1.8 or later, so that there is a graceful shutdown.
The test directory was misnamed to test_data. Fixed.
Additional changes and fixes requested by Jivan
(Somewhat related to #115 and #160)
I wonder whether it would be of interest for tegola to have a
mvt.Providerfor the GeoPackage format. To my knowledge, there is no GeoPackage library for Go, yet. But since it is an open standard maybe the time is right to kick off one under the tegola roof.The text was updated successfully, but these errors were encountered: