Testbed-12 NSG GeoPackage Profile Assessment Engineering Report

Section 6.1 (File Names) of the NSG GeoPackage Profile[2016-07-01] provides guidance on how to name files so that ad-hoc naming conventions are avoided. Our evaluation suggests that the current section 6.1 does not provide adequate details and will most likely result in ad-hoc naming.

The sample pattern provided "{producer}{data product(acronym)}{geo area coverage (acronym)}{scale(s)}{version}_{date}" fails to indicate what each element should look like and will produce filenames that are difficult to read. For example, using the following values:

producer: CSLT
data product: CDRG
geo area coverage: CA
scales: 1-27
version: 1.0
date: 08-02-2016

This will produce the filename CSLTCDRGCA1-271.0_08-02-2016. As you can see, it is hard to distinguish between the elements. Therefore, providing specific convention rules is a better approach. For example, filenames should:

A sample pattern could be:

{producer}_{data product}_{geographic coverage area}_{scale(s)}_{version}_{date}.gpkg

Using the values listed above, this will produce the filename CSLT_CDRG_CA_1-27_V1-0_2016-08-02.gpkg. This approach makes it easier to distinguish between the elements that comprise the file name.

Section 6.2 (Extensions) of the NSG GeoPackage Profile[2016-09-02] indicates that any tables, which are not part of the GeoPackage standard, need to be registered in the gpkg_extensions table. This is a misuse of that table. The gpkg_extensions table is used to indicate that a particular extension applies to a GeoPackage and the standard details how to document these extensions. A GeoPackage may contain tables that are not intended to be part of an extension and can be safely ignored. Application providers commonly store application-specific data in their GeoPackages.

Section 7.1 (Coordinate Reference Systems) of the NSG GeoPackage Profile[2016-09-02] outlines what CRSs should be used for 2D/3D tiled data and 2D/3D vector data. The technical guidance sections provided in the annexes should indicate how to fill out the gpkg_tile_matrix table for each CRS. Additionally, some guidance on when to choose EPSG 3395 or EPSG 5041/EPSG 5042 would be useful. EPSG 3395 and EPSG 5041 overlap by > 20 degrees in the north and similarly EPSG 3395 and EPSG 5042 overlap by > 20 degrees in the south. Therefore it is not clear which CRS to choose in case of overlap, or if tiles should be generated for both overlapping CRSs.

Section 7.2 (Well Known Text) of the NSG GeoPackage Profile[2016-09-02] specifies that OGC 12-063 Well Known Text representation of Coordinate Reference Systems shall be used for the definition column in the gpkg_spatial_ref_sys table. This requirement will break support for any clients that are currently following version 1.0 or 1.1 of the GeoPackage standard and expect to find OpenGIS 01-009 Well Known Text.

We recommend that the OGC GeoPackagage Encoding Standard 1.1 Registered Extension F.10 (WKT for Coordinate Reference Systems) be used. This extension adds an additional column "definition_12_063" that contains the new OGC 12-063 WKT representation, while still providing an OpenGIS 01-009 WKT representation in the original "definition" column when possible. This extension is a temporary measure that will allow the use of the new WKT representation while maintaining compatibility with existing client implementations. This extension will be removed in the next major version of the GeoPackage standard because the definition column will be updated to support the current version of the WKT specification.

Table 20 in Section 7.3 (Metadata) of the NSG GeoPackage Profile[2016-09-02] indicates that the gpkg_metadata table requires an entry with an id of 1. This entry is the NSG Metadata Implementation Specification (NMIS) v2.2 metadata document that is associated with the complete GeoPackage. GeoPackage creators may already be populating metadata into the gpkg_metadata table. This forces them to use the id 1 which is an unnecessary complication. The id can be determined by using a query that joins the gpkg_metadata and gpkg_metadata_reference tables on id where the reference_scope is 'geopackage' and the md_standard_uri is 'http://metadata.ces.mil/dse/ns/GSIP/nmis/2.2.0/doc'. The restrictions on any additional NMIS metadata entry ids should also be relaxed. This change would also require rewording of data validity constraints 18 - 29 in the profile. Additionally there should be data validity constraints added to deal with the case of adding NMIS metadata that describes particular tables or table row, column or row/column values.

In accordance with Table 20 the column "md_scope" should have a value of 'series' or 'dataset'. A similar restriction can be found in Table 22 and Table 25. It is not clear when one value should be selected over the other.

Providing a sample minimal NMIS v2.2 metadata xml in the Annex section would be beneficial. The profile does a good job of explaining what elements / values are required in the metadata specifically related to GeoPackage. However for someone unfamiliar with NMIS metadata it could be difficult to understand what elements and values are required in general.

In the NSG GeoPackage Profile[2016-07-01] and in accordance with Table 26 ID# 13 and ID# 18, the zoom_level needs to be > 0. We are unclear if this is a typo or intentional. The GeoPackage standard states that zoom_level shall be >= 0. In Annex C, table 30 of the profile, the Zoom Level starts at 0 while in Annex D, table 34 the Zoom Level starts at 1.

In the NSG GeoPackage Profile[2016-07-01] and in accordance with Table 26 ID# 13 and ID# 18, the zoom_level needs to be <= 27. The GeoPackage standard states that zoom_level shall be <= max_level. Our recommendation is to follow the standard and not to cap the possible precision of the data.

According to OGC GeoPackage Requirement 3, a GeoPackage SHALL have the file extension name ".gpkg". However the standard then RECOMMENDs that Extended GeoPackages use the file extension “.gpkx” but this is NOT a GeoPackage requirement.

Inline with NSG Requirement 1, which states that the ".gpkx" file extension SHALL NOT be used to indicate an Extended GeoPackage, we recommend the removal of the .gpkx file extension from the standard for the following reasons:

Inline with NSG Requirement 24, which states "The (min_x, max_x, min_y, max_y) values in the gpkg_tile_matrix_set table SHALL be the maximum bounds of the CRS specified for the tile pyramid data table and SHALL be used to determine the geographic position of each tile in the tile pyramid data table", we recommend a new requirement in the GeoPackage standard that states the same. Currently we have the following descriptive text "The maximum bounding box (min_x, min_y, max_x, max_y) for all possible tiles in a tile pyramid user data table. All tiles present in the tile pyramid SHALL fall within this bounding box. However, the bounding box MAY be larger than the minimum bounding rectangle around the actual tiles in that pyramid." The issue with this text is that it is not a requirement and it is open to interpretation. For example, a GeoPackage creator may create a GeoPackage containing one tile with no intention of adding any other tiles, and index it as follows:

If a second creator were to take this GeoPackage and try to add another tile to it, they may have to re-index the entire GeoPackage as follows:

The specification requirements should be modified to avoid the potential of having to reindex tiles. If we follow the wording of NSG Req 24, the first creator would have created and indexed the GeoPackage as follows:

If a second creator were to take this GeoPackage and add another tile to it, they would no longer be required to re-index the tiled data:

Requirement 11 in the GeoPackage standard provides a minimal listing of rows that shall be contained in the gpkg_spatial_ref_sys table. These rows may not be necessary for the content of the GeoPackage and should therefore not be required. The rows cause issues for possible profiles of the GeoPackage standard because these profiles may restrict the allowed CRSs, this restriction may not include EPSG:4326. Furthermore, since the allowed CRSs are defined, the value of srs_id of -1 for undefined Cartesian coordinate reference systems and the srs_id of 0 for undefined geographic coordinate reference systems will never be required. We recommend updating this requirement so that the gpkg_spatial_ref_sys table MAY contain these entries.

Inline with NSG Requirement 27, which states that the User-Defined Geometry Types Extension SHALL NOT be implemented, we suggest that this Extension be removed from the standard for the following reasons:

The extensions for Geometry Type Triggers and Geometry SRS ID Triggers should also be removed from the standard, as they directly relate to User-Defined Geometry Types Extension and will no longer be required.

The content contained in this extension and the related extensions would be better suited in an OGC Best Practice document. This document could outline how to create a complete and interoperable User Defined Geometry Type Extension, which also contains the geometry encoding and deals with the issues of 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 and be interoperable.

The Non-Linear Geometry Types extension is similar to the User-Defined Geometry Types extension mentioned above, with one major exception. The extended non-linear geometry types are already defined in OGC Well Known Binary (WKB), therefore a supplemental document is not required to detail the geometry encoding. We see no reason to remove this extension from the standard. However we do recommend dropping GeoPackage Requirement 69.

Complying with Requirement 69 is almost impossible. The requirement states "SQL functions that operate on GeoPackageBinary geometries as specified in other extensions SHALL operate correctly on the non-linear geometries specified in this extension". Implementation of this requirement is almost impossible because the functions could have been loaded via an extension such as 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.

Section 7.1 (Coordinate Reference Systems) of the NSG GeoPackage Profile[2016-09-02] will require minor updates to state that Table 6: Vector Feature Coordinate Reference Systems also be used for Vector Tiles.

Section 7.2 (Well Known Text) of the NSG GeoPackage Profile[2016-09-02] will not require any changes as no CRSs were added in section 7.1.

Section 7.3 (Metadata) of the NSG GeoPackage Profile[2016-09-02] will not require any changes.

Table 26 in Section 7.4 (Data Validity Constraints) of the NSG GeoPackage Profile[2016-09-02] will require the following changes: