Why are there not requirements classes for GeoPackage and Simple Features WKT?

[cnreediii]

Just wondering. I probably missed the decision discussion. That said, given that just about every commercial and open source DB supports Simple Features and given that GeoPackage is getting more and more widely used, why no Requirements Classes? Future work maybe?

[jerstlouis]

@cnreediii The requirements classes included in the Standard are only some options of formats that implementations can provide.

The Standard says additional formats can be implemented, and says that the closest requirements class should be used as guidance for the other formats (i.e., GeoJSON and MVT for Vector data; netCDF and GeoTIFF for coverage formats; PNG and JPEG for map/imagery formats).

An implementation could provide support for GeoPackage, but GeoPackage is probably not ideal as a format for a single tile, with way too much overhead. Instead, being able to retrieve GeoPackages containing multiple vector tiles using the draft GPKG Vector Tiles Extension is likely preferable (related to a potential multi-tiles retrieval extension).

As for Simple Features WKT, that only allows to encode the geometry for a single feature, whereas vector tiles typically contain multiple features, as well as associated attributes.

Both of the example vector tile formats for which there are requirements classes (GeoJSON and MVT) encode geometry mostly according to the Simple Features model.

flatgeobuf is an example of another potential vector tile encoding, for which there likely already are implementations providing support.

We could write extensions for additional formats, but as far as map, coverage and vector tiles formats are concerned, I don't think this is really necessary. It is clear that implementations can provide any format they want, and clients use content negotiation to select their preferred format.

(apologies for all the uses of vector tile in this comment, I mean it in the non-vendor specific tiled vector feature data sense ;)).