We are working on a minor revision to the GeoPackage Encoding Standard. We propose three substantive changes to the standard.
- Making DATETIME more flexible. "Rules as Written," a GeoPackage DATETIME must have the format YYYY-MM-DDTHH:MM:SS.SSSZ. In practice, this has proven to be unnecessarily strict. Now we will accept anything that is compatible with ISO-8601 (or its non-ISO counterpart, RFC-3339) with a Zulu / UTC time zone.
- Relaxing Requirement 4. When GeoPackage 1.0 was published, Requirement 4 established a distinction between "GeoPackage" (a GeoPackage with no extensions) and "Extended GeoPackage" (a GeoPackage with at least one registered extension). While there was sound reasoning for this at the time, now that the standard has been out for 9 years, extensions have proven to be essential for non-trivial operations. Meanwhile, adjudication of this requirement created test skips in the Executable Test Suite. These skips were difficult to interpret. By relaxing this requirement, we remove the confusion.
- Changing some R-Tree spatial index triggers. We discovered that one of the triggers used to maintain the R-tree spatial index was incompatible with UPSERT statements. We corrected this problem by replacing ..._update1 with two new triggers, ..._update6 and ..._update7. By deprecating the old trigger, we make it easier for clients to determine whether the change has been applied. While we were at it, we made a similar change for the trigger that was patched as part of GeoPackage 1.2.1, deprecating ..._update3 in favor of ..._update5.
We just initiated a public comment period for this change. If all goes well, we plan to publish GeoPackage 1.4 as an adopted standard by the end of this calendar year.
