[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
> 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
> writes GEOMETRYCOLLECTION.
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
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 22.214.171.124.2 but I'm
> afraid this is a bit too abstract for me to fully understand by myself...
Just reread section 126.96.36.199.2. 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