PART A
1. Evaluator:
Darrell Fuhriman
2. Submission:
OGC 12-128r1
OpenGIS® GeoPackage Implementation Specification
PART B
1. Requirement: Core, #13
2. Implementation Specification Section number: 8.2
3. Criticality: Minor
4. Comments/justifications for changes:
The geopackage_contents table includes four columns used for the bounding box,
but does not specify the units to be used, only the defaults. The spec should
be updated to specifically list the units.
Points for clarification:
1) are the values to always be in lat/long?
1a) If so, what datum? (Yes, I realized these values are not meant to be
exact, but it doesn't hurt be clear)
2) are the values to be in the SRID specified in the same row?
If the values are to be specified always in lat/long, then recommend renaming
columns to reflect this:
min_x -> min_long
max_x -> max_long
min_y -> min_lat
max_y -> max_lat
=======================================================================
1. Requirement: N/A
2. Implementation Specification Section number: N/A
3. Criticality: Major
4. Comments/justifications for changes:
I believe there should be an optional extension that allows for the inclusion
of user-defined styling information.
While, I do not believe that the Geopackage format should mandate a specific
styling language, such as SLD or CartoCSS, I do think there should be a standard
location where an application can look for such data.
The implementation should be highly generic, the intention is to allow
standards to evolve and gain experience before codifying anything, but still
having a single "go to table" for finding styling suggestions.
As an intro suggestion, I imagine there being a table, say "geopackage_styles"
consisting of four columns:
table_name text NOT NULL
style_name text NOT NULL
style_version text
style_data text NOT NULL
The primary key would be a composite key consisting of "table_name,
style_name", thus allowing for one table to have multiple styles associated
with in different styling languages.
For example, a table might contain:
| my_table | cartoCSS | NULL | "some carto css" |
| my_table | SLD | 1.1.0 | "<BIG string of XML/>"|
Any styling information included must apply to the named table/view, and only
that table/view. Including styling suggestions for a table/view is purely
optional, and the "geopackage_styles" table need not exist at all.
=======================================================================
1. Requirement: N/A
2. Implementation Specification Section number:9.6
3. Criticality: Major
4. Comments/justifications for changes:
I am concerned that the reference implementation SpatialLite, essentially
mandates the inclusion of the GEOS library. While I have nothing against the
GEOS library, quite the opposite, this presents real problems for people who
must statically link the libraries, something that is expressly forbidden by
the GEOS Library License (LGPL).
For reference, see: http://blog.burhum.com/post/38236943467/your-lgpl-license-is-completely-destroying-ios-adoption
I strongly encourage the OGC to create a minimal reference implementation,
contains *only* the core requirements, and makes use only of libraries which
can be statically linked.
