Skip to content
Spatial.Properties

What is a Spatial Pack

Geospatial data is hard to share. Files scatter across FTP servers, cloud buckets, and local drives. Formats vary — shapefiles, GeoJSON, GeoTIFF — and nobody agrees on the version they are using. A colleague sends you “parcels_final_v3_FIXED.shp” and you have no idea when the data was captured, what coordinate system it uses, or whether you are allowed to redistribute it.

Spatial.Properties solves this with Spatial Packs — self-contained, versioned bundles of spatial data with built-in metadata and governance.

What is a Spatial Pack?

Section titled “What is a Spatial Pack?”

A Spatial Pack is a directory containing everything a consumer needs to work with a collection of spatial data:

  • Data layers in cloud-native formats: GeoParquet (columnar vector data optimized for analytics) and PMTiles (single-file vector tile archives for fast map rendering)
  • A manifest file (spatialpack.json) describing what the pack contains
  • Metadata including provenance, license, bounding box, and coordinate reference system (CRS — the math that maps coordinates to locations on Earth)
  • A version string following semantic versioning

Think of a Spatial Pack like a container image for geodata. Everything needed to consume the data ships together. You do not need to chase down separate downloads, reconcile coordinate systems, or guess at licensing terms.

Why these formats?

Section titled “Why these formats?”

Traditional GIS formats have serious limitations for modern workflows. Shapefiles split data across multiple files, lack support for long field names, and cap out at 2 GB. GeoJSON works well for small datasets but bloats quickly and lacks indexing.

Spatial Packs use GeoParquet for analytics and PMTiles for visualization. GeoParquet stores vector geometries in Apache Parquet’s columnar format, enabling fast filtered queries without reading entire files. PMTiles packs pre-rendered vector tiles into a single file that clients can fetch via HTTP range requests — no tile server required.

Both formats are designed for cloud storage. A client can request exactly the rows or tiles it needs over the network, making Spatial Packs efficient to consume at any scale.

The manifest

Section titled “The manifest”

The spatialpack.json manifest is the source of truth for a pack. It declares what layers exist, where they came from, and what license governs their use.

spatialpack.json
{
  "pack_id": "spatial.properties:wa:solar-feasibility:v1",
  "version": "2025.01.31",
  "theme": "solar-feasibility",
  "geography": "wa",
  "bbox": [115.65, -32.15, 116.15, -31.65],
  "crs": "EPSG:4326",
  "license": {
    "id": "CC-BY-4.0",
    "name": "Creative Commons Attribution 4.0"
  },
  "layers": [
    {
      "id": "cadastre",
      "type": "vector",
      "title": "Cadastre Boundaries",
      "parquet": "./cadastre.parquet"
    },
    {
      "id": "basemap",
      "type": "vector",
      "title": "Basemap Tiles",
      "pmtiles": "./basemap.pmtiles"
    }
  ]
}

Every field in the manifest is defined by a JSON Schema, so tooling can validate packs automatically before they ship.

Immutable versioning

Section titled “Immutable versioning”

Every version of a Spatial Pack publishes to a unique path. Version 2025.01.31 and version 2025.03.15 coexist side by side — the platform never silently overwrites an earlier version.

This means consumers can pin to a specific version and trust that the data behind it will not change. Reproducibility is guaranteed: the same version always returns the same data. If a dataset is updated (new parcels surveyed, boundaries redrawn), a new version is published alongside the old one. Consumers upgrade on their own schedule.

packs/
  spatial.properties:wa:solar-feasibility:v1/
    2025.01.31/
      spatialpack.json
      cadastre.parquet
      basemap.pmtiles
    2025.03.15/
      spatialpack.json
      cadastre.parquet
      basemap.pmtiles

Pack structure

Section titled “Pack structure”

The diagram below shows how the pieces of a Spatial Pack fit together.

graph TB
  Pack["Spatial Pack v1.0.0"] --> Manifest["spatialpack.json"]
  Pack --> Layers["Data Layers"]
  Layers --> L1["cadastre.parquet"]
  Layers --> L2["zoning.parquet"]
  Layers --> L3["basemap.pmtiles"]
  Manifest --> Meta["name, version, license"]
  Manifest --> Region["bbox, CRS"]

The manifest references each layer by a relative path. Layers use GeoParquet for analytical queries and PMTiles for map visualization. Both formats are cloud-native, meaning clients can read just the bytes they need without downloading the entire file.

Governance built in

Section titled “Governance built in”

Every Spatial Pack carries its governance metadata. The license field records the SPDX license identifier and attribution requirements. The provenance section traces each layer back to its source dataset, including download URLs, versions, and SHA-256 hashes.

This makes compliance auditable. Before a pack publishes, the CLI validates that every layer has a declared license and that integrity hashes match the data on disk. Packs that fail governance checks do not publish.

Next steps

Section titled “Next steps”

Ready to build your own pack? Follow the getting-started guide or dive into the schema reference.