[Geopackage] Call for Public Review of NSG GeoPackage Implementation Profile Draft
bradh at frogmouth.net
Sun Apr 12 18:51:52 EDT 2015
On Mon, 23 Mar 2015 11:54:41 AM Paul Daisey wrote:
> The latest profile draft is attached FYI. I'm retiring and Jeff
> Yutzler has taken over as GPKG SWG Chair. Roy Rathbun will be managing
> the NGA profile approval process.
In 6.2, the Introduction says "Every GeoPackage must contain either tiles or
features per Req 17". That might be better with the words "or both" added
In 7.1, do we really need all the vertical options? Just using depth as a
negative height would reduce the number of CRS options significantly. Even if
they are required, they shouldn't be included in Table 5, because it says you
can do a tiles table in (for example) NGA 8056, which makes no sense at all.
It might be easer to read if there was "heading row repeat" for table 5.
Also, there is a missing closing quote mark (") in "Extension Type" body.
The WKT definition in table 6 is wrong. GEOCCS should be GEOGCS.
The NSG Req 35 in Section 8.3 should refer to v1.0 of PROJRAS. Later in that
section "nga-tile-size" should be "nga_tile_size". More generally, this text
is not a GeoPackage extension, and should be an informative annex/appendix.
The tile matrix extent in section 8.5 is confusing and, as written, is
probably the most likely part to cause interoperability problems. I'd suggest
adding a set of explanatory table entries that describe each of the cases in
the unreferenced diagram in 8.5. There probably should also be some logic for
how to calculate presence/absence/mixed bounding boxes, especially for ugly
cases like the mixed-tiles diagonal.
Also, the definition of "complete" should probably read "for the entire table
for every tile" instead of "for the entire tile for every tile"
In section 9.2, typo: "z an m" should be "z and m" (or perhaps Z and M).
In section 9.3, the SQL functions table has a typo: ST_GeomCollFromTxt should
be ST_GeomCollFromText. Consider removing ST_AsGML and ST_GeomFromGML, for
lack of general support and use.
It won't be possible to support arbitrary user-defined geometry - that is
fundamentally not interoperable. Suggest prohibiting it. Also recommend
removing non-linear geometry types.
Annex A: Add "Informative" to the heading. Also typo: implied, not impliled.
The whole "we'll change the definition of the CRS when ISO gets around to it"
is a bad idea, and really complicates testing. I don't have a good answer
though. The least worst idea I can come up with is to just keep the old CRS
and have implied vertical levels rather than using WKT to express it.
More information about the Geopackage