search

opengeospatial / geopackage

An asciidoc version of the GeoPackage specification for easier collaboration
https://www.geopackage.org
Other
264 stars 71 forks source link

SRS matching requirement between Contents and Tile Matrix Set or Geometry Columns #233

Closed bosborn closed 8 years ago

bosborn commented 8 years ago

Remove the SRS id matching requirement in the description column of the table definition for the SRS Id (1.1.3.1.1): Spatial Reference System ID:gpkg_spatial_ref_sys.srs_id; when data_type is features, SHALL also matchgpkg_geometry_columns.srs_id; When data_type is tiles, SHALL also matchgpkg_tile_matrix_set.srs_id

Contents, Tile Matrix Set, and Geometry Columns all foreign key to a SRS id. Forcing the SRS id to be the same between the same table name Contents-Tile Matrix Set or Contents-Geometry Columns entry is unnecessary.

See pull request #232

jyutzler commented 8 years ago

More discussion:

jyutzler commented 8 years ago

@bosborn We discussed this issue at the SWG today but we concluded that we need more information about why this is a problem. Please provide a justification of why the standard would be better if these values were allowed to be different. If you prefer, you could dial into the next SWG meeting (10AM 8/15) and discuss it then.

bosborn commented 8 years ago

It's not a huge problem we are just trying to get clarification on the spec and correct our GeoPackages as needed. Our implementation won't change other than maybe some validation.

When reading through the spec the SRS id match requirement appears to only be specified in the Contents table definition description column. The Contents table has a foreign key to the Spatial Reference System separate from the Tile Matrix Set or Geometry Columns tables. I would argue that basic database design principles indicate that the Contents SRS can therefore be different from the Tile Matrix Set or Geometry Columns SRS. An example would be to specify a Contents bounding box in WGS84 while the Tile Matrix Set tiles are defined as Web Mercator. If this is an allowable scenario then that requirement should be removed from the description column.

Is the desire to actually force the SRS Id to match between a Contents and Tile Matrix Set / Geometry Columns pair? Based upon the spec, it appears that only the Contents table should then foreign key to the SRS table. As foreign keying to the SRS table by the Tile Matrix Set or Geometry Columns is redundant when forced to match the Contents value. Every Tile Matrix Set and Geometry Columns already has a Contents value and every Contents references a SRS. If those must be the same, then why foreign key to the SRS in multiple locations? I understand this would be an implementation breaking change at this point so maybe not advisable to drop foreign keys. At a minimum I would recommend stating this as an actual requirement separate from a description column in the Contents table. I don't see a large benefit in forcing a GeoPackage to define it's Contents and Tile Matrix Set / Geometry Columns in the same projection. Especially considering the database schema allows for each to be defined according to its own SRS.

Reading the Tiled Gridded Elevation Data Extension I see that the Contents (data_type as 2d-gridded-coverage) SRS must be one with vertical datum. It doesn't say whether the Tile Matrix Set srs id must be the same or if it could be different in this case. If they can differ than this would be one argument for keeping multiple foreign keys.

I would like to see either:

  1. drop the following dialogue from the Contents description column "when data_type is features, SHALL also matchgpkg_geometry_columns.srs_id; When data_type is tiles, SHALL also matchgpkg_tile_matrix_set.srs_id"
  2. Add a stand alone requirement specifying this requirement outside of a description column (Requirement 16.2). If the spec was not already released, drop the SRS foreign keys from Tile Matrix Set & Geometry Columns.

I was originally asking for option 1 as the spec is already set up to support non matching SRS ids.

jyutzler commented 8 years ago

On August 15th the SWG voted to reject this change. We did not agree that the change was justified and in fact were concerned that allowing the SRS IDs to be different would cause confusion.

bosborn commented 8 years ago

The database schema through multiple foreign keys does not enforce this "requirement" and actually encourages the opposite. For this reason, I still think it should be made a more official requirement by numbering it as one in the spec.