geopackage.md

Ah, GeoPackage. Comments on the current spec.

Base

• Hooray, C extensions were removed. Hope that idea is gone for good.
• Spatial Reference Systems Ah yes. This is a broken system, based on hoping that no SRS systems ever get invented after now, and in the meantime sticking it all together with a big CSV file that nobody wants to think about. Anyway, this is a bad idea but a ubiquitous bad idea, so won't blame that on GPKX.
• 1.1.3.1.1. Table Definition Exposes the problem of projecting everything: if you don't have proj4 handy, you won't even be able to get the extent of a data file. This radically de-simplifies simple metadata.

Core Geometry Model

Okay, so maybe we aren't discussing this, but: why? Like, SQLite has its own geospatial geometry encoding, Spatialite has a needlessly incompatible version of that, and now it's time to invent a third?

• Core Geometry Model includes unusual primitives like MultiCurve

A 1-dimensional geometry is a geometry that has a length, but no area.

That sounds like a 2D line.

• To implement this new geometry encoding, you'll need ISO/IEC 13249-3:2011. Cost of specification just increased to $225 USD
• Geometry supports Z values (yay) but doesn't specify what they mean: what are the units?

Tiles

Unfortunately, no applicable existing consensus, national or international specifications have standardized practices in this domain.

Except for the custom used by every major web map service. I wish these intros weren't so flip about prior art: saying "no consensus, national, or international specifications" is kind of a cop-out: most useful specs aren't.

• 2.2.3. Zoom Levels: Looks like the zooms-that-aren't-powers-of-two-or-even-constant-between-numbers thing survived the draft process. This will be implemented by <1%.
• 2.4.2. Metadata Table: That is a lot of standards and a lot of XML.
• 3.1.3. RTree Spatial Indexes: because, from above, we aren't using SQLite's built in geometry encoding, so we can't use SQLite's built in R*Tree module

Reading between the lines it looks like what you would have preferred is a least-common-denominator approach that requires all data to be in wgs-84 for vector data and web mercator for imagery.

I'd say that's an oversimplistic reading.

Basically, my problem is that GeoPackage is primarily a container format, like MBTiles. So, it contains things: and in this case, they are vector and raster features. You have two choices: you can either contain existing things, like MBTiles contains XYZ tiles, or you can invent new things. GeoPackage did the latter - it baked up a new way to encode geometries, and a new tile spec - and I don't think anyone spent nearly enough time thinking about these things. Instead of solving one problem well, it's creating two new problems and solving three problems poorly.

If there was already a great way to encode geometries - one that didn't cost two hundred bucks to access and didn't have multiple incompatible variants and was compact and had all the wonderful bells and whistles. And if there was already a tile system that did projections right and also somehow supported non-power-of-two zoom levels, then sure: I would support a container format that wrapped those well-thought out, battle-tested strategies.

SQLite does not have a geometry encoding. Not sure where you're getting that from.

See the GDAL ogr driver, and mapnik's support, and also the part in the private mailing list where I demonstrated the two.

---

For those at home who don't know the backstory, the stuff about non-power-of-two zoom levels might seem weird. Why such focus? Why that feature? To clarify: the main sponsors of GeoPackage are military, and non-power-of-two zoom levels are useful mainly for data "coming off the bird" in non-multilevel form.

This mismatch between the funders intent and the public face of a standard is one of the things that bothers me: why should a general format have vestigial features of a military usecase?

Fair enough on the over simplistic bit :)

The intention of the things in GeoPackage was actually to not invent anything new (to the extent possible). Features is reusing the work from SQL/MM and SF/SQL. Tiles is reusing the work from WMTS. You can argue whether those are good starting points or not of course, but that's the rationale behind it.

I fully agree that WKB is not the greatest geometry encoding imagineable, but its the only thing out there that's already standardized. We could have opted to come up with something better but decided not to. The header bit was made to be a prefix for ogc wkb. Just to be clear that's the same 'raw OGC WKB' that the mapnik docs mention and which OGR supports. SQL/MM is actually the place where this is normatively specified. The idea behind using wkb unmodified is that you can skip over the header and use an existing wkb parser to read the geometry. That's exactly what Justin Deoliveira did in geotools for instance. I did the same in our codebase fwiw. I would expect Paul Ramsey did the same for the OGR geopackage driver.
The other alternatives out there in the context of SQLite are FDO RFC16 and spatialite. Neither are defined by SQLite itself. They use the same strategy of encoding a geometry as a blob in sqlite as geopackage does. We ended up not using spatialite's encoding since it modifies certain bytes of standard wkb (without any tangible benefit imo). The FDO RFC16 is something completely custom that isn't in wide spread use as far as I know.

There are non-military use cases for non-power-two tilesets btw. See http://www.ngi.be/NL/NL1-19-1.shtm for instance. We wanted to be able to use geopackage to cache whatever you can serve via wmts. The only thing that was dropped was variable top-left corner; partially based on a comment from Even Rouault.
I don't think the 'coming off the bird' use case is actually feasible anymore. Putting a single 20kx20k image as a single tile in a tile matrix is a bad idea and definitely not the intended use case anymore. I think (hope) we reached consensus on this quite some time ago. This was one of the arguments to drop NITF from the spec as well. It just doesn't make sense to have something with the complexity of NITF in a format that's trying to cache RGB(A) imagery tiles.

@pepijnve in your first comment it looks like some words under the "Geometry Encoding" header got lost.

@rajsingh fixed. markdown didn't like the angle brackets.