[Geopackage] [SpatiaLite-Users] GeoPackage (GPKG) support in 4.2.0

Pepijn Van Eeckhoudt pepijn.vaneeckhoudt at luciad.com
Fri May 23 03:39:01 EDT 2014

On 22-05-14 21:16, Even Rouault wrote:
> just to be sure to fully understand what your position would be : do you mean
> that a table with geom[etry]collection should be registered with
> "GEOMCOLLECTION" as the value of geometry_type_name in gpkg_geometry_columns
> and table 44 would be amended to display "GEOMCOLLECTION" ?
Yes, that's what I think it should be based on reading the sql/mm and 
sfs specs. The name of the SQL type is listed as geomcollection 
everywhere in those specs. In SFS 'geometrycollection' is only mentioned 
once in the UML class diagram in figure 4. In SQL/MM 
'geometrycollection' only occurs in sections 5.1.58 and 5.1.59 which 
specifies geometry WKT and WKB.

My intention is to file a change request to make this clearer in the 
geopackage specification.
> I think I'll change the OGR GPKG driver to accept both on the reading side,
> but it would be good to know what the writing side should do. Currently OGR
That's what I've done in libgpkg as well yesterday. It used to use 
'GeometryCollection' as the column type and as the value for 
gpkg_geometry_columns.geometry_type_name. I've changed this to use 
'GeomCollection'. To be on the safe side I've made the code accept both 
for reading.

When parsing WKT only 'GeometryCollection' is accepted as per the 
specification in sql/mm.
> Another related question is : what is the SQLite data type that should be
> indicated for a geometry column in a user feature table. Example C.4 / Table
> 27 shows "geometry GEOMETRY". Is it GEOMETRY because the "geometry" column
> might contain any type of geometries ? Or if geometry would be a point-only
> column (declared as geometry_type_name = 'POINT' in gpkg_geometry_columns),
> would that be "geometry POINT" ? This must be discussed in but I'm
> afraid this is a bit too abstract for me to fully understand by myself...
Just reread section It doesn't really say what you're 
supposed to do. Only speaks about gpkg_geometry_columns. As far as I can 
tell there's no test case that covers this either.

In the examples in SQL/MM 17.2 st_geometry_columns is a view derived 
from the information_schema tables. The set of columns in that view is 
determined by the declared type of the table columns. It selects all 
columns whose is ST_Geometry or a subtype of ST_Geometry. In other 
words, the table definition is the master from which the 
st_geometry_columns view is derived.

SQLite doesn't provide the information_schema tables (sqlite_master kind 
of approximates it) so gpkg_geometry_columns can't be implemented as a 
view. I would be inclined to follow the same strategy though and ensure 
that the declared type of a geometry column and the value in 
gpkg_geometry_columns.geometry_type_name are the same.

Paul, do you think should this be a requirement? I can file another 
change request to add it and an accompanying test case if you believe it 


More information about the Geopackage mailing list