← Back to list

OxiGeo: The Day Geospatial Computing Stopped Needing C/C++/Python

How a 747,000-line, 76-crate Pure Rust rewrite of the GDAL idea — with four live browser demos to prove it — quietly changes what…

KitaSan · 2026-07-20 13:11 · 34 claps · 9.1 min read
#rust #gis #geospatial #open-source #web-development
Open on Medium ↗
Wiki topics: 🌐 · Web Development 🔧 · Data Engineering 🔓 · Open Source

OxiGeo: The Day Geospatial Computing Stopped Needing C/C++/Python

How a 747,000-line, 76-crate Pure Rust rewrite of the GDAL idea — with four live browser demos to prove it — quietly changes what “geospatial infrastructure” means

By KitaSan, COOLJAPAN OÜ — July 2026

If you have ever built anything with satellite imagery, elevation models, or vector maps, you have — knowingly or not — depended on GDAL. For a quarter of a century, the Geospatial Data Abstraction Library has been the invisible plumbing beneath QGIS, ArcGIS, PostGIS, Google Earth Engine’s ingestion pipelines, and thousands of research workflows. It is one of the great achievements of open source.

It is also a C/C++ monolith that drags PROJ, GEOS, libcurl, and a 2 a.m. configure fight behind it everywhere it goes. It does not run in a browser. It cross-compiles to mobile and embedded targets somewhere between painfully and not at all. Its APIs are thread-unsafe, its errors are C error codes, and even a minimal deployment ships a 50 MB+ binary.

On July 20, 2026, we released OxiGeo 0.2.0 — the first release under a new, permanent name for the project formerly known as OxiGDAL (v0.1.7 was the final release under the old name; 0.2.0 is the same codebase, renamed). It is a comprehensive geospatial data abstraction library written in 100% Pure Rust, with zero C, C++, or Fortran dependencies in its default build. Not a wrapper around GDAL. Not bindings. An independent reimplementation of the entire idea, from the TIFF byte layout up.

The numbers, as of this release:

  • ~747K lines of Rust across 2,448 source files and 76 workspace crates
  • 17 format drivers: GeoTIFF/COG, GeoJSON, GeoParquet, Zarr v2/v3, FlatGeobuf, Shapefile, NetCDF, HDF5, GRIB, JPEG2000, VRT, COPC/LAS, GeoPackage, MBTiles, PMTiles, KML, TopoJSON
  • 211+ embedded EPSG definitions and 20+ map projections, with SIMD-vectorized batch transforms
  • 16,232 passing tests (plus 409 doc tests), zero failures
  • Runs on Linux, macOS, Windows, WebAssembly, iOS, Android, and bare-metal no_std
  • A gzipped WASM bundle under 1 MB — versus GDAL’s “not supported”

A COCOMO estimate puts the equivalent development cost at $29.59M. It is Apache-2.0, and it is on crates.io today: cargo add oxigeo.

But statistics do not make a revolution. What the browser can now do, does. Let me show you.

Why the rename, briefly

A quick word before the demos, because the version number looks odd otherwise. OxiGDAL v0.1.7 — a production-hardening release that fixed 233 verified defects across 69 crates — shipped on the morning of July 20. OxiGeo v0.2.0 shipped the same day: functionally identical, but with every crate, binary, environment variable, and FFI symbol renamed from oxigdal to oxigeo.

A name borrowed from the library you are replacing eventually becomes a liability. New users assumed OxiGDAL wrapped or forked GDAL (it does neither); search results and package indexes conflated two unrelated codebases; and a name adjacent to someone else’s brand is a permanent open question. So the project now has a name that is fully its own. Old GitHub URLs redirect, the oxigdal-* crates stay published for existing users, and nothing was yanked. OxiGeo is an independent reimplementation, not affiliated with the GDAL project — and the name finally says so.

The proof is in the browser: four live demos

Every claim above would be marketing if you could not verify it yourself. So the README ships four hosted demos, and each one runs 100% client-side — Pure Rust compiled to WebAssembly, executing in your browser tab. No server-side processing, no accounts, no telemetry. This is the part GDAL categorically cannot do, and it is where the “revolution” framing stops being hyperbole.

1. GeoSentinel — satellite change detection with nobody watching

**cooljapan.tech/geosentinel**

The tagline: watch any place on Earth for change — and tell no one where you’re looking.

Draw an area of interest anywhere on the planet. GeoSentinel queries the public Earth Search STAC API for a cloud-filtered pair of Sentinel-2 scenes, then streams only the byte ranges it needs — the red and near-infrared band windows of Cloud-Optimized GeoTIFFs — via HTTP range requests from AWS’s open-data bucket. The entire change-detection pipeline then runs inside your tab: NDVI differencing, fixed or Otsu thresholding, polygonization, Karney geodesic area computation, GeoJSON export.

Your coordinates never leave your machine, because there is no backend to send them to. For journalists monitoring deforestation, NGOs tracking conflict damage, or analysts who simply cannot leak their area of interest, that property is not a feature — it is the entire point. Conventional change-detection pipelines require either a cloud platform that sees every query you make, or a local GDAL/Python stack that takes an afternoon to install. GeoSentinel is a URL.

And it is honest about accuracy: the built-in Lahaina wildfire preset detects 713 hectares of burn scar against roughly 880 ha of ground truth — from just 9.0 MB of streamed imagery.

2. GeoVault — analysis that can prove what it did

**cooljapan.tech/geovault**

GeoVault is a clean-room workstation for sensitive terrain data. Load a DEM, run hillshading and statistical anomaly detection (Z-score, IQR, modified-Z) — and every operation is appended to a blake3 hash chain, rolled up into a Merkle root, and sealed with an Ed25519 signature. You download a JSON attestation that an independent verifier page (or a native Rust example) re-checks with no private key and no network round-trip. Meanwhile, a strict Content-Security-Policy forbids every external connection for the duration of the session.

The trust model is stated exactly as it is: log integrity is cryptographically proven; zero-egress is enforced and observed (CSP plus in-page fetch/XHR/beacon hooks), because no browser page can mathematically prove what other software on the machine did. That candor matters, because the audience for this demo — defense, critical infrastructure, regulated industries — is precisely the audience that reads trust models carefully. Tamper-evident, verifiable geospatial analysis in a disposable browser tab did not exist as a category before this.

3. GeoParquet Live — querying 5.9 GB with no database

**cooljapan.tech/geoparquet**

The browser points at a single remote GeoParquet file: Japan’s VIDA building footprints — 5.9 GB, 47.66 million rows, 9,533 row groups. You drag a query box over Tokyo. OxiGeo’s pushdown planner reads the Parquet footer metadata, prunes row groups against the spatial and attribute predicates before fetching a single data byte, and then downloads only the surviving column-chunk byte ranges.

The Shinjuku preset: 9,533 row groups pruned to 7 survivors, 4.7 MB fetched, exact matches refined in 13 milliseconds. The UI wears its honesty badges on its sleeve: dataset: 5.9 GB · fetched: a few MB · uploaded: 0 · server: none.

Think about what usually stands between a user and that query: a PostGIS instance, an ETL pipeline, a tile server, an ops team. Here the “infrastructure” is a static file on object storage and an HTTP server that understands range requests. For open-data publishers — governments, research institutions — this collapses the cost of making nation-scale vector data interactively queryable to nearly zero.

4. GeoLab — real-time terrain analysis on streamed rasters

**cooljapan.tech/geolab**

The original demo, and still the clearest one: a Cloud-Optimized GeoTIFF viewer where GeoTIFF decoding, multidirectional hillshading, and colormap rendering all happen in the tab. Drag the sun-azimuth or vertical-exaggeration slider over the San Francisco DEM and watch the hillshade re-render in real time — client-side, on data streamed via range requests. The same algorithms run natively from Rust with no browser at all; the README’s terrain gallery is rendered by the repository’s own code, reproducible with a single cargo run command.

What “revolution” actually means here

Buzzwords aside, OxiGeo changes the geospatial field along five concrete axes.

1. The deployment revolution: geospatial anywhere. GDAL’s platform matrix ends where the C toolchain ends. OxiGeo’s ends where Rust ends — which today means everywhere: a sub-1MB WASM bundle, Swift FFI on iOS, Kotlin/JNI on Android, no_std on microcontrollers, and a Docker image under 50 MB where GDAL-based images routinely exceed a gigabyte. cargo add oxigeo replaces an entire dependency archaeology session. Cross-compilation is a target flag, not a project.

2. The privacy revolution: computation moves to the data’s viewer. Every one of the four demos embodies the same inversion: instead of uploading your data (or your query, or your area of interest) to someone’s server, the analysis engine downloads to you and runs locally. Client-side geospatial processing at this fidelity was simply not on the menu when the reference implementation could not compile to WASM. Now it is the default architecture.

3. The correctness revolution: memory safety plus honest engineering. Rust eliminates the whole class of memory-corruption CVEs that periodically visit C-based format parsers — a serious matter for software that routinely parses untrusted files from the internet. But the 0.1.7 hardening campaign went further than the language guarantees: 233 verified defects fixed, including a GeoTIFF floating-point predictor that had been silently corrupting data, a JPEG2000 decoder brought to ITU-T T.800 conformance, a FlatGeobuf writer rewritten to the genuine FlatBuffers wire format for interoperability with GDAL itself, and an RBAC pattern-matching bypass closed. The project’s stated bar is that “it compiles” and “it is correct” are two separate tests — and that a library should return a typed error rather than fabricate a plausible-looking output.

4. The cloud-native revolution: range requests as a first-class primitive. COG tiles, GeoParquet row groups, PMTiles archives, STAC catalogs — OxiGeo treats “fetch only the bytes the query needs, from S3/GCS/Azure or plain HTTP” as the core I/O model, with first-class async throughout. That is the architecture the cloud-native geospatial community has been converging on for years; here it is implemented coherently across 17 formats in one dependency-free stack.

5. The sovereignty revolution: an auditable supply chain. OxiGeo is one pillar of the larger COOLJAPAN ecosystem — 35M+ lines of Pure Rust replacing C and Fortran foundations across scientific computing. Its CRS engine is OxiProj; HDF5 and NetCDF run on oxih5 and oxinetcdf; TLS is OxiTLS, compression is the OxiArc family, ML tensor math is SciRS2. No hidden libsomething.so anywhere in the tree means the entire stack is buildable, auditable, and reproducible from source with one toolchain — which is precisely what governments and enterprises now mean when they say "digital sovereignty."

For the skeptics — as it should be

Is OxiGeo a drop-in GDAL replacement for every workflow today? No, and the README says so with unusual bluntness: HDF5 write has no chunking or compression yet; GeoPackage write covers point feature tables only; zstd-compressed GeoParquet is unsupported because no pure-Rust Parquet zstd path exists yet; LERC encoding returns an honest typed error rather than a fake blob. GDAL’s quarter-century of accumulated format edge cases is not something anyone rewrites in a year — and 211 embedded EPSG codes is a curated set, not the full EPSG registry (100+ projections are on the v0.2 roadmap, with a v1.0 LTS targeted for Q4 2026).

But that documented-limitations culture is itself part of the argument. A dependency that tells you exactly what it cannot do is worth more than one that fails silently — a lesson the 0.1.7 defect hunt taught the project about its own earlier releases, in public.

Try it in the next five minutes

No installation required — open any of the four demos:

Or in Rust:

[dependencies]
oxigeo = "0.2"                                    # GeoTIFF + GeoJSON + Shapefile
# oxigeo = { version = "0.2", features = ["full"] }  # all 17 drivers
use oxigeo::Dataset;
fn main() -> oxigeo::Result<()> {
    let dataset = Dataset::open("world.tif")?;
    println!("Format : {}", dataset.format());
    println!("Size   : {}x{}", dataset.width(), dataset.height());
    println!("CRS    : {}", dataset.crs().unwrap_or("unknown"));
    Ok(())
}

Python (pip install oxigeo), Node.js (npm install @cooljapan/oxigeo), a CLI (oxigeo info, convert, warp, dem hillshade), and Jupyter support are all first-class citizens of the same workspace.

Repository: github.com/cool-japan/oxigeo · Apache-2.0

For 25 years, geospatial software has been built on the assumption that serious raster and vector processing requires a C toolchain, a server, and someone else’s infrastructure. OxiGeo’s four browser tabs are a standing demonstration that all three assumptions have quietly expired. The map layer of the software world just became portable, private, and provable — and it fits in a megabyte.

— KitaSan, COOLJAPAN OÜ (Team Kitasan)


메타데이터
post_id
675575b8bed9
slug
oxigeo-the-day-geospatial-computing-stopped-needing-c-675575b8bed9
url
https://medium.com/@kitasanio/oxigeo-the-day-geospatial-computing-stopped-needing-c-675575b8bed9
canonical_url
https://medium.com/@kitasanio/oxigeo-the-day-geospatial-computing-stopped-needing-c-675575b8bed9
author_url
https://medium.com/@kitasanio
status
ok
fetched_at
2026-07-21 04:28:33