A strict read of GeoPackage v1.1 does not allow non-spatial attribute values. However, in practice data providers routinely need to deliver data that does not contain geometry properties. Requiring any GeoPackage that contains non-spatial tables to be declared and documented as an "Extended GeoPackage" is not reasonable and does not promote interoperability. Therefore, the specification has been modified to allow non-spatial attribute tables in a basic GeoPackage. This change is considered to be low-risk because it creates a new encoding option that would be ignored by previous versions of the standard.
It was determined that it is difficult, if not impossible, to comply with Req 69 "SQL functions that operate on GeoPackageBinary geometries as specified in other extensions SHALL operate correctly on the non-linear geometries specified in this extension." because the functions could have been loaded via an extension such SpatiaLite which cannot be changed, and does not support the non-linear geometries. The removal of this requirement will allow for interoperable storage and retrieval of the geometries, while not requiring but allowing existing functions to work with the geometries.
The GeoPackage SWG agreed to remove the “User Defined Geometry Types Extension of GeoPackageBinary Geometry Encoding” extension from the encoding standard for the following reasons:
-
The geometry encoding is not specified in the extension and therefore a supplemental document explaining the encoding would be required. In the absence of this document, there is no way for an application developer to support this extension and therefore it is not interoperable.
-
Multiple developers could implement the encoding of a new, but similar geometry type such as EllipiticalCurve in different ways.
-
Existing spatial functions will not work with the new geometry types and could potentially cause errors or skip data if used.
The SWG also agreed to remove two addition extensions, “Geometry Type Triggers” and “Geometry SRS ID Triggers”, from the encoding standard as they directly relate to User-Defined Geometry Types Extension and will no longer be required.
The SWG believes that content contained in these extensions would be better suited in a best practice document. This document could outline how to create a complete and interoperable User Defined Geometry Type Extension, including the details of the geometry encoding and how it can be used with existing spatial functions. This would allow two independent developers to create User-Defined Geometry Type extensions that follow the same template and make it easier for clients of the extensions to adopt.
After successful completion of the GeoPackage Elevation Extension Interoperability Experiment (see [B1]), the SWG agreed to add a new extension to the standard. The "Tiled Gridded Elevation Data" extension stores tiled gridded elevation data in a GeoPackage. The tiles contain elevation values and may be 16-bit PNG files or 32-bit TIFF files. The extension defines two ancillary data tables, one for coverages and one for tiles. When using the PNG encoding, a scale and offset may be applied. The extension also allows for a TIFF encoding but it constrains many of the TIFF options that are available to simplify development.
In GeoPackage 1.1 and earlier, Requirement 2 specifies an exact string as the application identifier. This string is also supposed to be added to SQLite’s magic.txt file ([B3]). The SWG determined that updating this file is unsustainable. Instead, GeoPackage will now use the original application ID (GPKG) and use the user_version header to indicate the version. In addition, it is reasonable to for clients designed to comply with a specific version of the standard to interoperate with GeoPackages that comply with a later version. In response, Requirement 2 was reworded to allow for version increments and the associated abstract test was updated. This change should improve interoperability as well as make it more reasonable for GeoPackage producers to pass CITE tests.
The “WKT for Coordinate Reference Systems” extension was designed to align to a new OGC Encoding Standard, OGC 12-063r5 (see [B2]). The text in GPKG 1.1 (including the column name) incorrectly references “12-163” instead. This change corrects all references to the proper “12-063”. The GeoPackage SWG regrets the error. This change is considered to be low-risk. At worst, implementers may need to populate a redundant column to satisfy clients that use this extension but only support GPKG 1.1.