
Spatial data, from coordinates to source ranges.
Spiral gives geometry, imagery, point clouds, time, and provenance a shared model. A spatial predicate can become a physical plan that selects the shapes, pixels, and source ranges a workload actually needs.
Versioned sources and coordinate frames
Spiral keeps immutable sources on typed coordinate frames and can resolve the whole project at a chosen revision with asof(T).
Typed geometry
Vortex geometry exposes typed coordinates, nested offsets, CRS metadata, and WKB/GeoArrow interoperability.
Cross-modal planning
Raster and point-cloud range selection, spatial statistics, and joins stay in the same plan as geometry, time, and scalar predicates.
01 · The data model
One place, several representations.
The same area can be a polygon, a multispectral scene, a point cloud, a terrain surface, and a sequence of observations. Spiral does not reduce those sources to a set of URIs. It keeps the coordinate frame, bounds, acquisition time, source structure, and lineage available to the project.

Geometry
Coordinates · offsets · bounds · CRS
Typed Vortex children stay visible to compression and compute.
Raster
Overviews · tiles · bands · byte ranges
The spatial plan chooses the physical window instead of returning a URI.
Observations
Position · valid time · accuracy · source
Project history keeps the coordinate and processing state reproducible.
02 · Representation
Geometry as typed columnar data.
In Spiral, geometry is not repeatedly reparsed from an opaque WKB cell. Vortex keeps the logical type and its physical children together, giving encoding and vectorized operations typed structure to work with.
03 · The physical plan
Query geometry determines I/O.
A compact window, a corridor, and a broad polygon can return comparable output while touching very different spatial partitions. Spiral uses the request's shape, bounds, and statistics to narrow candidate partitions before exact predicates or payload reads begin.

04 · Time and registration
Coordinate systems need time and lineage.
A CRS explains how to interpret coordinates; it does not prove that two observations are aligned or current. Spiral's versioned project state can reproduce the source and coordinate frame selected by asof(T), trace which transform produced a result, and identify derived products affected by a registration change.


A scene, its acquisition time, the transform used to register it, and any derived products form one lineage question, not four files with matching names.
NASA Earth Observatory · Landsat / USGS05 · The query boundary
From an area of interest to source ranges.
A geometry footprint only identifies a candidate source. A useful result still requires a resolution, overview, tile or chunk set, bands, exact predicate, output representation, and lineage. Spiral keeps those choices in one plan rather than rebuilding the query in application code.
// Query a spatial region
project.asof(revision)
.scenes.where(intersects(footprint, area))
.where(acquired_at.between(t0, t1))
.select(
image.window(area, resolution="2m"),
points.within(area),
provenance
)Resolve the project revision and coordinate frame.
Prune candidate geometry partitions.
Choose source overviews, chunks, bands, and ranges.
Materialize native output with source lineage attached.
| Source role | Structure that matters | Spiral plan |
|---|---|---|
| Vortex geometry | Typed coordinates, offsets, CRS, interchange | Encode and compute over native geometry |
| COG / Zarr raster | Overviews, tiles or chunks, bands, ranges | Choose resolution, chunks, bands, and ranges |
| COPC point cloud | Hierarchy, node bounds, density, ranges | Traverse bounded nodes and selective ranges |
Talk to us