[Geopackage] [SpatiaLite-Users] GeoPackage (GPKG) support in 4.2.0
Pepijn Van Eeckhoudt
pepijn.vaneeckhoudt at luciad.com
Thu May 22 03:36:17 EDT 2014
On 22-05-14 00:33, a.furieri at lqt.it wrote:
> On Thu, 22 May 2014 00:11:06 +0200, Even Rouault wrote:
>> But... the string GeomCollection appears at a few occurrences in the
>> GeoPackage specification, so CC'ing the GeoPackage list so that they
>> share some
>> light. Looks like there is an inconsistency
> Yes, I noticed that the GPKG specs are rather obscure / unclear
> about this topic; anyway I received the personal impression that
> GEOMCOLLECTION was someway the preferred name.
> (being probably based on the more recents "top secret" ISO
> SQL/MM specs)
For better or worse, it's the most specific spec on the topic out there.
It defines all the types and how the functions on them should behave.
Even SFS defers to SQL/MM for the details of most things.
Anyway, in SQL/MM the string 'GEOMETRYCOLLECTION' is only used in the
WKT encoding. The type name for the same thing is 'ST_GeomCollection'.
In SFS it's exactly the same, expcet ST_ is stated as being optional
(see OGC 06-104r4 table 4 and section 220.127.116.11). To make things more
confusing though the same type is shown as 'GeometryCollection' in
figure 4. :D
For GeoPackage specifically I think we should stick to the specs:
geometrycollection in wkt, geomcollection everywhere else. the
GeoPackage spec itself is unfortunately, as you pointed out, quite
inconsistent on the matter. We should get this fixed asap. Paul, what's
the process to get things started on this?
> I suppose than when reading from a GPKG being prepared to support
> both alias names indifferently should probably be the safer approach.
That's probably what's going to happen yes. My own code did it
incorrectly as well; fixing that as we speak :)
> ... a further doubt: it looks like every GPKG table shall necessarily
> have a Primary Key declared as "INTEGER AUTOINCREMENT"
> What's happen e.g. while exporting form an origin table presenting
> a multi-column PK ?
> we could eventually ignore the original PK, then defaulting to
> some other INTEGER AUTOINCREMENT id; but this will obviously
> kill any possible relationship based on Foreign Keys referencing
> the original multi-column PK
IIRC we added that requirement in order to be able to define references
to specific rows in the spec itself. metadata_reference and the rtree
index for instance both use an integer value to refer to specific rows.
We couldn't use rowids for this directly since those can change when
vacuum is used. Adding the 'integer pk autoinc' requirement resolves this.
Requiring an 'integer unique' column is one possible alternative, but
you can't get autoinc behaviour on those. Requiring manual id assignment
would make the db a bit cumbersome to use imo.
Does spatialite have a better way of dealing with this?
More information about the Geopackage