[gdal-dev] GPKG Driver

Even Rouault even.rouault at mines-paris.org
Sun Oct 27 16:09:28 PDT 2013


Paul,

> Couple questions:
> 
> - Did anything happen on the summer of code suggestion, or any other
> independent development front?

No related activity on SoC side, and no public activity on it that I'm aware 
of (apart from some interest in doing so mentionned)

> 
> - On the "wrap it into the existing driver" recommendation, how strong
> is that? If am doing the driver, I'm loath to try and wrap it in,
> particularly since the current SQLite driver already includes so much
> optionality and different behaviour. 

Yes, I can understand that. The current state of SQLite driver is that it is 
crowded with various features specific to (different versions of) Spatialite. 
/me being largely culprit about the resulting messy appearance of it.

> Which is a long, whiny way
> of saying: I'd like to implement GPKG as a separate driver, not as
> part of SQLite, if that's acceptable (or, not completely
> unacceptable).

Actually, if I were to develop it, my idea would to take that as an 
opportunity to try to refactor a bit some classes (mainly OGRSQLiteTableLayer) 
to separate the generic SQLite stuff ( that would go in 
OGRSQLiteAbstractTableLayer : CreateFeature(), SetFeature(), DeleteFeature(), 
GetFeature(), ... ) from the specific Spatialite stuff ( OGRSPLiteTableLayer : 
spatial index, statistics, etc... ). 

The GPKG support could be a driver on its own ( it has its specific .gpkg 
extension, so we can quickly distinguish between sqlite/spatialite and gpkg), 
with dedicated OGRDriver and OGRDataSource, but it could benefit from the base 
SQLite classes.

But it would be certainly acceptable to start GPKG driver as separate code, 
with some copy & pasting of usefull existing SQLite driver code. And with 
hindsight, some refactoring could perhaps be done.

Now my turn for questions :
- From your questions, I suppose you only consider the vector side of GPKG ?
- Do you intend in writing everything from scratch, or did you consider using 
https://bitbucket.org/luciad/libgpkg ?  Which is, AFAIK, the equivalent of 
libspatialite for GPKG. Contains the SQL functions mandated by the spec, the 
triggers etc. 

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html


More information about the gdal-dev mailing list