1. Generalization in GPKG (Compusult)
Geopackage SWG Telecon
16 June 2016

2. GPKG Approach Very simple data model.
Original feature geometry is maintained in feature table.
Other generalized versions of the geometry for that table are maintained in a linked table. Scale range determines which generalized geometry is valid.
Original feature geometries are used in the scale range from 0-x, generalized features are used from scales x->y

3. Data model example

4. Instances Original Geometry is used for large scales Hydrography_AreasId
Attr1
Attr2
Geom 1 x y
300pts
Hydrography_Areas_geometries id
Feature_id
Min_scale_denom
Max_scale_denom
geom 45 1
25000
49999
200pts 46
50000
249999
100pts 47
250000
999999
60pts 48
20pts

5. Something new : Feature Splitting
One of the main goals of generalization is to improve performance.
When we have a large scale, we are looking for the highest resolution data. Looks good, but affects performance.
The impact of loading a high resolution vector geometry is that we retrieve the whole geometry, often into memory only to render a small amount of data because of the scale. This can affect performance when reading in large features.
Is feature splitting a reasonable solution? Vector tiles makes use of this idea as well.
If required, features would be split, and stored in the geometries table, linked back to the original feature
These split features would have the same resolution as the original geometry
Clients would have to know how to deal with split features esp in the polygon case.
How do we decide to split?
Fixed “tile” boundaries – artificial vertices
Fixed number of vertices e.g at a time
How do we close split polygons?