Clarify use of "GEOMETRY" for unknown or multiple geometry types

[jyutzler]

We are occasionally seeing GeoPackages that have, for example, both polygon and multipolygon geometries in a table registered in gpkg_geometry_columns as POLYGON. According to Requirement 31 this is not allowed and GEOMETRY must be used, but we can be more clear about this.

[jerstlouis]

Yet, in the context of vector tiles in particular (whether encoded as GeoJSON or MVT), where lines or polygons can be clipped out or split in two, it would be highly desirable to have a type allowing for both the single and multiple flavors of the same basic geometry type (a way to allow e.g. only MultiLineString and LineString).

[jyutzler]

While it would be useful, I don't see how we can get there without breaking things. Just use GEOMETRY for these.

[jerstlouis]

@jyutzler Well I do encourage clarifying the text as you suggest above. Just meant to highlight why people might be doing this, and still hoping something can be done in the context of the vector tiles extension :)

[cnreediii]

Jerome -

Just wondering. If a large meandering polygon is clipped in a tiled data store such that multiple pieces of that big polygon now exist in the tile I still do not see the need for using "multipolygon" as a geometry type. Reassembling the pieces from one or more tiles into the original polygon is an implementation issue and I do not see how using multipolygon helps. Are you thinking that the constituent pieces of the large polygon that is clipped into smaller pieces should be organized in the GeoPackage so that they are all "next" to each other storage-wise and hence should be labeled as multipolygon? Thanks

[jerstlouis]

@cnreediii The tiled data store use case (at least as implemented in the Vector Tiles Extensions) is different from the main geometry table case discussed in this issue.

If considering a single tile, e.g. encoded as GeoJSON, if multiple polygons are part of the same feature, with the same id and properties, they should be in the same MultiPolygon.
The natural way to encode the feature inside a tile which has a single polygon in GeoJSON would be with a Polygon, while a feature with multiple polygons would be a MultiPolygon.
Same with Mapbox vector tiles, which doesn't really have a Polygon/MultiPolygon distinction.

In the core untiled GeoPackage vector table, a feature only has a single geometry piece.
Potentially some features might require the use of MultiPolygon, while others could be described with Polygon. Requirement 31 however says that if they are mixed the proper type should be GEOMETRY, rather than POLYGON.

The earlier suggestion I made in the context of the vector tile extension was to introduce the concept of single+multi LINESTRING allowing both LineString and MultiLineString (for the vector tile extension only, where that would not break existing implementations, and because it is in the vector tiles nature to have a mix of single/multi geometry).

[jyutzler]

See 888094c.