[Geopackage] Req 30: A feature table SHALL have only one geometry column.

Patrick van Dijk patrick.van.dijk at gmail.com
Wed Oct 29 08:56:46 EDT 2014


Referring to:  OGC 12-128r10 of 'Approval Date:   2014-01-19'

Any reason why this limitation exists (Req 30:   A feature table SHALL have
only one geometry column.)?
Many spatial database systems like Oracle, SQL Server, Smallworld do not
have this limitation.
So why have a new standard which is limited this way?

There is an odd definition in:

CREATE TABLE gpkg_geometry_columns (
  table_name TEXT NOT NULL,
  column_name TEXT NOT NULL,
  geometry_type_name TEXT NOT NULL,
  srs_id INTEGER NOT NULL,
  z TINYINT NOT NULL,
  m TINYINT NOT NULL,
  CONSTRAINT pk_geom_cols PRIMARY KEY (table_name, column_name),
  CONSTRAINT uk_gc_table_name UNIQUE (table_name),
  CONSTRAINT fk_gc_tn FOREIGN KEY (table_name)
                         REFERENCES gpkg_contents(table_name),
  CONSTRAINT fk_gc_srs FOREIGN KEY (srs_id)
                         REFERENCES gpkg_spatial_ref_sys (srs_id))


Where the primary key is defined on table_name and column_name,
but there is an additional UNIQUE CONSTRAINT on table_name.

Having just a PRIMARY KEY (table_name) would be enough, isn't it?

Then again, I can live perfectly fine without the UNIQUE (table_name)
contraint
and have multiple geometry columns per feature.

I noticed some discussions about this on
https://github.com/opengeospatial/geopackage/issues/19

Regards,

Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20141029/66e6019b/attachment.html>


More information about the Geopackage mailing list