Skip to content

features: use the GeoPackage spatial index for spatial predicates - #618

Merged
azahnen merged 4 commits into
masterfrom
gpkg-spatial-index
Aug 25, 2026
Merged

features: use the GeoPackage spatial index for spatial predicates#618
azahnen merged 4 commits into
masterfrom
gpkg-spatial-index

Conversation

@cportele

Copy link
Copy Markdown
Contributor

Closes ldproxy/ldproxy#1758.

A spatial predicate on a GPKG provider was encoded as a bare ST_Intersects(geom, ...). Unlike PostGIS, where ST_Intersects embeds the && bounding box operator and GiST applies by itself, SQLite cannot infer from a spatial operator that the R-Tree of the geometry column is relevant: unless the query names the rtree_<table>_<column> virtual table, the operator is evaluated for every row.

The dialect now contributes a bounding box predicate over that table, added as a conjunct to the exact predicate. The conjunct is only added where it is implied by the exact predicate, so that it can change neither the result nor the meaning of the predicate under negation:

  • only for operators whose match implies that the bounding boxes intersect, which excludes S_DISJOINT
  • only for a geometry column of the main table, since the semi-join form of a joined property would need the predicate inside its subquery
  • only for a column that an R-Tree is known for, determined once per provider on startup
  • never below a negation, because a NULL geometry has no entry in the R-Tree while the exact predicate is NULL for it, and negating those two is not the same

The changes also include a fix for another bug:

  • MinMaxDeriver seeded the maxima with Double.MIN_VALUE, which is the smallest positive value rather than the most negative one, so every Math.max against it won on an axis whose coordinates are all negative and the maximum stayed at 4.9E-324. Spatial extents are derived from this, so the extent of data west of Greenwich or south of the equator came out wrong.

MinMaxDeriver seeded the maxima with Double.MIN_VALUE, which is the
smallest positive value rather than the most negative one, so every
Math.max against it won on an axis whose coordinates are all negative
and the maximum stayed at 4.9E-324.

Spatial extents are derived from this, so the extent of data west of
Greenwich or south of the equator came out wrong.
A spatial predicate on a GPKG provider was encoded as a bare
ST_Intersects(geom, ...). Unlike PostGIS, where ST_Intersects embeds the
&& bounding box operator and GiST applies by itself, SQLite cannot infer
from a spatial operator that the R-Tree of the geometry column is
relevant: unless the query names the rtree_<table>_<column> virtual
table, the operator is evaluated for every row.

The dialect now contributes a bounding box predicate over that table,
added as a conjunct to the exact predicate. On a 41.6 GB GeoPackage with
24.6 million rows, a bbox request for ten features goes from 149 s to
0.3 s while returning the same features.

The conjunct is only added where it is implied by the exact predicate, so
that it can change neither the result nor the meaning of the predicate
under negation:

- only for operators whose match implies that the bounding boxes
  intersect, which excludes S_DISJOINT
- only for a geometry column of the main table, since the semi-join form
  of a joined property would need the predicate inside its subquery
- only for a column that an R-Tree is known for, determined once per
  provider on startup
- never below a negation, because a NULL geometry has no entry in the
  R-Tree while the exact predicate is NULL for it, and negating those two
  is not the same

The index is joined on the primary key of the feature table rather than
on rowid. A GeoPackage feature table is required to have an INTEGER
PRIMARY KEY, which SQLite makes an alias of rowid, but a file that does
not follow that requirement would otherwise match the wrong rows.
A spatial predicate on a GPKG provider was encoded as a bare
ST_Intersects(geom, ...). Unlike PostGIS, where ST_Intersects embeds the
&& bounding box operator and GiST applies by itself, SQLite cannot infer
from a spatial operator that the R-Tree of the geometry column is
relevant: unless the query names the rtree_<table>_<column> virtual
table, the operator is evaluated for every row.

The dialect now contributes a bounding box predicate over that table,
added as a conjunct to the exact predicate. On a 41.6 GB GeoPackage with
24.6 million rows, a bbox request for ten features goes from 149 s to
0.3 s while returning the same features.

The conjunct is only added where it is implied by the exact predicate, so
that it can change neither the result nor the meaning of the predicate
under negation:

- only for operators whose match implies that the bounding boxes
  intersect, which excludes S_DISJOINT
- only for a geometry column of the main table, since the semi-join form
  of a joined property would need the predicate inside its subquery
- only for a column that an R-Tree is known for, determined once per
  provider on startup
- never below a negation, because a NULL geometry has no entry in the
  R-Tree while the exact predicate is NULL for it, and negating those two
  is not the same

The index is joined on the primary key of the feature table rather than
on rowid. A GeoPackage feature table is required to have an INTEGER
PRIMARY KEY, which SQLite makes an alias of rowid, but a file that does
not follow that requirement would otherwise match the wrong rows.
@azahnen
azahnen merged commit be66382 into master Aug 25, 2026
3 checks passed
@azahnen
azahnen deleted the gpkg-spatial-index branch August 25, 2026 13:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GeoPackage: spatial queries slow on large tables

2 participants