14.3 Spatial Indexing & Storage Structures: R-Tree, Quadtree, Geohash & Vector Tiles

Spatial Indexing & Storage Structures: R-Tree, Quadtree, Geohash & Vector Tiles

Quick Summary: Efficient spatial querying across millions of geospatial features is impossible without specialized spatial indexing and storage structures. Because standard relational B-Tree indexes are limited to one-dimensional scalar data, spatial databases utilize hierarchical multidimensional indexes—such as R-Trees and Quadtrees—alongside a two-step filtering process (Primary vs. Secondary filters). Furthermore, the emergence of Discrete Global Grid Systems (H3, Geohash) and cloud-native formats (FlatGeobuf, GeoParquet, Vector Tiles) has transformed how spatial data is partitioned, streamed, and queried.

---

The Mechanics of Spatial Indexing & B-Tree Limitations

In standard relational databases, the B-Tree (Balanced Tree) index is the undisputed standard. B-Trees operate by maintaining an ordered, balanced search tree of scalar values ($x_1 < x_2 < x_3$). When searching for a specific number or date, a B-Tree navigates from root to leaf in $O(\log N)$ time.

Why B-Trees Fail on Spatial Data

Spatial data is inherently multidimensional (2D, 3D, or 4D). Unlike real numbers, there is no natural, total linear ordering for points or polygons in geographic space:

• A geographic feature possesses multiple coordinates simultaneously ($X_{\text{min}}, Y_{\text{min}}, X_{\text{max}}, Y_{\text{max}}$).
• A point that is "less than" another point in the X dimension may be "greater than" that point in the Y dimension.
• Creating two independent B-Trees (one on $X$ and one on $Y$) forces the database to evaluate two separate candidate lists and perform an expensive index intersection, resulting in catastrophic full-table scans when querying large 2D bounding boxes.

                     THE TWO-STEP SPATIAL QUERY PROCESS

   [Spatial Query Envelope]
              |
              v
   +-------------------------------------------------------------------------+
   | STEP 1: PRIMARY FILTER (Index Scan / Coarse Filter)                     |
   | • Evaluates Minimum Bounding Rectangles (MBRs) using Spatial Index      |
   | • Eliminates 99% of non-matching geometries in O(log N) time            |
   | • Output: Candidate Set (Contains actual matches + "FALSE POSITIVES")   |
   +-------------------------------------------------------------------------+
              |
              | Candidate Feature IDs
              v
   +-------------------------------------------------------------------------+
   | STEP 2: SECONDARY FILTER (Exact Geometry Evaluation / Refinement)       |
   | • Reads full coordinate strings from disk for candidate features only   |
   | • Executes rigorous computational geometry algorithms (e.g., DE-9IM)    |
   | • Eliminates false positives                                            |
   | • Output: True Topological Result Set                                   |
   +-------------------------------------------------------------------------+

The Two-Step Filtering Architecture

To overcome multidimensional complexity, all spatial databases implement a two-step query execution model:

1. Primary Filter (Coarse Filter): The database tests the query bounding box against a precomputed Minimum Bounding Rectangle (MBR) (or bounding box) stored in the spatial index. This step is exceptionally fast because checking whether two simple rectangles overlap requires only four numerical comparisons:

   $\text{Overlap} \iff (A_{x\text{min}} \le B_{x\text{max}}) \land (A_{x\text{max}} \ge B_{x\text{min}}) \land (A_{y\text{min}} \le B_{y\text{max}}) \land (A_{y\text{max}} \ge B_{y\text{min}})$

   The primary filter returns a Candidate Set. This candidate set contains all true matches, but also includes false positives (features whose MBR overlaps the query box, but whose actual polygon boundary does not).

2. Secondary Filter (Refinement Filter): The database retrieves the full, high-precision vector geometries for only the candidate features identified in Step 1. It executes computationally heavy geometric algorithms (such as point-in-polygon ray casting or DE-9IM topological intersection) to discard false positives and return the exact spatial result set.

---

Hierarchical Indexing: R-Tree, R* Tree, and Quadtree

R-Tree and R* Tree Architecture

Introduced by Antonin Guttman in 1984, the R-Tree is a height-balanced, multi-dimensional search tree designed specifically for bounding boxes. In an R-Tree:

• Leaf Nodes: Store pointers to actual database records alongside the exact Minimum Bounding Rectangle (MBR) of each feature.
• Internal (Non-Leaf) Nodes: Store bounding boxes that encompass all the bounding boxes of their child nodes.

                           R-TREE HIERARCHY

                        [ Root MBR: R1, R2 ]
                             /        \
                            /          \
             [ Internal MBR: R1 ]   [ Internal MBR: R2 ]
                 /          \           /          \
                /            \         /            \
          [ Leaf MBR: A, B ] [ C, D ] [ E, F ]   [ G, H ]
               |       |       |  |     |  |       |  |
             GeomA   GeomB   ...     ...        GeomG GeomH

The R* Tree Enhancement

A critical challenge in R-Trees is determining how to split a node when it overflows. The standard R-Tree uses linear or quadratic split algorithms that minimize total area. However, this often leads to large overlapping bounding boxes between sibling nodes, forcing spatial queries to traverse multiple search paths simultaneously.

The *R Tree (R-Star Tree)**, developed by Beckmann et al. (1990), substantially optimizes performance by:

• Minimizing the overlap between adjacent bounding rectangles.
• Minimizing the total perimeter (margin) of the bounding box to favor square-like boxes rather than long, thin rectangles.
• Utilizing forced re-insertion: When a node overflows, rather than immediately splitting, the R* tree removes a portion of the entries and re-inserts them into the tree, allowing dynamic rebalancing.

PostGIS implements spatial indexing via GiST (Generalized Search Tree), which utilizes R-Tree principles for spatial columns.

Quadtree Architecture

A Quadtree is a tree data structure in which each internal node has exactly four children. In a 2D spatial context, the quadtree recursively divides a bounded rectangular space into four equal quadrants:

• NW (Northwest)
• NE (Northeast)
• SW (Southwest)
• SE (Southeast)

                        QUADTREE DECOMPOSITION
   +-----------------------+-----------------------+
   |                       |           |           |
   |                       |    NW     |    NE     |
   |          NW           |-----------+-----------|
   |                       |    SW     |    SE     |
   |                       |           |           |
   +-----------------------+-----------------------+
   |                       |                       |
   |          SW           |          SE           |
   |                       |                       |
   +-----------------------+-----------------------+

Point-Region (PR) Quadtrees

In a Point-Region (PR) Quadtree, spatial subdivision is adaptive. If a quadrant contains more features than a predefined capacity threshold (e.g., $N > 100$ points), that quadrant is recursively subdivided into four child quadrants. Dense urban areas receive deep quadtree branching, while sparse rural zones remain at shallow levels. Quadtrees are heavily used in spatial tile rendering engines, web map caching pyramids, and raster data compression.

Spatial Grid Indexes

A Spatial Grid Index overlays a uniform grid of fixed-dimension square cells across the coordinate extent of a dataset. When features are indexed, the database records which grid cells each feature's MBR intersects.

• Multi-Level Grid Indexes: Systems such as Esri File Geodatabases and Microsoft SQL Server support up to three grid levels (Grid 1, Grid 2, Grid 3) with progressively larger cell sizes. Small features (points, small parcels) are indexed in Grid 1, while regional features (rivers, transmission lines) are indexed in Grid 2 or 3 to prevent a single feature from registering in thousands of small cells.

---

Discrete Global Grid Systems (DGGS), Geohash & Uber H3

As spatial databases scale to planetary dimensions, planar coordinate projections break down due to extreme geometric distortions at poles and across UTM zone boundaries. To solve this, spatial data architectures utilize Discrete Global Grid Systems (DGGS).

Geohash: Interleaved Space-Filling Curves

A Geohash is a public domain hierarchical spatial index that encodes geographic coordinates (latitude and longitude) into a compact alphanumeric string using Base32 characters (0-9, b-z, excluding a, i, l, o to avoid confusion).

1. Binary Interleaving: The globe is divided into bounding boxes. Longitude and latitude are converted into binary bitstrings by repeatedly halving coordinate intervals. The binary bits for longitude and latitude are then interleaved (e.g., lon_0, lat_0, lon_1, lat_1, ...).
2. Base32 Encoding: The interleaved bitstream is grouped into 5-bit chunks, each mapped to a Base32 character.
3. Prefix Proximity: Geohash strings share common prefixes for nearby locations. For example, dr5ru and dr5rv are adjacent cells in New York City.

[!CAUTION] The Geohash Edge Discontinuity Trap: While points sharing a common prefix are guaranteed to be close, points that are physically adjacent can have completely different prefixes if they lie across a major quadrant boundary! For example, two points separated by only 1 meter across an equator or meridian boundary may share zero common characters. A robust Geohash query must always evaluate the target cell plus its 8 neighboring bounding cells.

H3: Hierarchical Discrete Global Grid

H3 partitions the globe into hierarchical cells across resolutions 0 through 15. Most cells are hexagons with six edge-sharing neighbors, which is often more convenient for neighborhood and movement analysis than a square grid with edge and corner neighbors.

The globe cannot be tiled entirely by perfect regular hexagons. H3 therefore contains 12 pentagons at every resolution, and projection from an icosahedron onto the sphere introduces distortion. Cell areas vary within a resolution, as do exact center-to-center distances and edge lengths. Published resolution tables report average areas and lengths; they are not guarantees for every cell.

H3 indexes support parent-child traversal and neighborhood operations, but applications must handle pentagon distortion and the fact that finer cells do not always have perfectly nested geometric boundaries. For analysis, select a resolution suited to the phenomenon and report aggregation sensitivity instead of implying that hexagonal indexing makes the grid perfectly equal-area or distance-preserving.

---

Modern Cloud-Native Geospatial Vector Storage

Traditional vector formats (such as Shapefiles or File Geodatabases) were designed for local disk storage, requiring entire files to be downloaded before a client can query them. In modern cloud architectures, datasets reside on cloud object stores (Amazon S3, Google Cloud Storage, Azure Blob Storage). Cloud-native formats leverage HTTP Range Requests (bytes=start-end) to read partial file segments without downloading the entire dataset.

+-----------------------------------------------------------------------------------+
| CLOUD-NATIVE VECTOR STORAGE ECOSYSTEM                                             |
+-------------------+--------------------+--------------------+---------------------+
| Format            | Underlying Engine  | Spatial Indexing   | Primary Purpose     |
+-------------------+--------------------+--------------------+---------------------+
| **FlatGeobuf**    | Binary FlatBuffers | Packed Hilbert     | High-speed vector   |
|                   |                    | R-Tree             | streaming via HTTP  |
|                   |                    |                    | Range Requests.     |
+-------------------+--------------------+--------------------+---------------------+
| **Vector Tiles**  | Protocol Buffers   | Slippy Map Tile    | Client-side dynamic |
| **(MVT)**         | (PBF)              | Pyramid (Z/X/Y)    | web map rendering & |
|                   |                    |                    | GPU styling.        |
+-------------------+--------------------+--------------------+---------------------+
| **GeoParquet**    | Apache Parquet     | Parquet Row Group  | Big-data analytical |
|                   | Columnar Storage   | Bounding Boxes     | queries, DuckDB,    |
|                   |                    | (WKB Geometries)   | Spark, Trino.       |
+-------------------+--------------------+--------------------+---------------------+

1. FlatGeobuf (.fgb)

FlatGeobuf is an open, binary vector encoding format based on FlatBuffers. It includes a packed Hilbert R-Tree spatial index directly at the front of the file. A web client or GIS application reads the small index header via an HTTP Range Request, identifies the precise byte offsets of the geometries matching the query bounding box, and fetches only those specific bytes over the network.

2. Mapbox Vector Tiles (MVT / PBF)

Vector tiles package vector geometries into a standard Web Mercator tile pyramid ($z/x/y$). Encoded using Google Protocol Buffers, vector tiles clip features to tile boundaries and simplify geometries according to the zoom level. The client browser uses its local GPU (via WebGL/WebGPU in MapLibre or Mapbox GL) to dynamically render and style the vectors on the fly, enabling instant restyling without re-requesting server tiles.

3. GeoParquet

GeoParquet standardizes geospatial vector data within Apache Parquet, the industry-standard columnar storage format for big data analytics. Features include:

• Columnar Storage: If a query selects only parcel_id and tax_value from a 100-column table, Parquet reads only the physical disk blocks for those two columns, ignoring all other data.
• Predicate Pushdown & Row Group Skipping: Parquet files group rows into chunks (Row Groups) and store bounding box statistics in the file footer. Distributed query engines (such as DuckDB, Trino, or Apache Spark) evaluate these bounding boxes to skip entire row groups from disk without decompressing raw vector geometries.

---

Comparison Table: Spatial Indexing & Storage Structures

---

Summary of Common Exam Traps

[!CAUTION] Exam Trap 14.3.1: The Primary Filter False Positive Trap. A spatial index scan (the Primary Filter) never guarantees exact topological results. It evaluates only Minimum Bounding Rectangles (MBRs). A feature whose bounding box overlaps the query window will be returned by the Primary Filter even if its actual geometry does not touch the query window. The Secondary Filter (exact geometry evaluation) is mandatory to eliminate false positives.

[!CAUTION] Exam Trap 14.3.2: Assuming Geohashes Guarantee Physical Proximity by Prefix Length. While features sharing a long Geohash prefix are physically close, two points located just millimeters apart across an equator, prime meridian, or major quadrant boundary will possess completely different Geohash strings. Software must always evaluate the central cell plus its 8 adjacent neighbors.

[!CAUTION] Exam Trap 14.3.3: Conflating Vector Tiles with Raster Web Map Tiles. Vector tiles do NOT contain pre-rendered image pixels. They contain raw vector coordinates and attributes encoded in Protocol Buffers. Rendering, symbology, and labeling occur dynamically on the client's GPU, allowing on-the-fly theme adjustments without server re-rendering.