[Announcement] OxiGDAL v0.1.0: A 100% Pure Rust, Cloud-Native Alternative to GDAL

announcements
1

Hey Rustaceans!

If you’ve ever built geospatial applications, you know that GDAL is the undisputed king. But you probably also know the pain of wrestling with gdal-sys, dealing with complex C/C++ toolchains, and ending up with bloated Docker images just to read a GeoTIFF.

Today, we are super excited to announce the v0.1.0 release of OxiGDAL — a production-grade Geospatial Data Abstraction Library written entirely in 100% Pure Rust.

No C/C++ dependencies. No Fortran. Just a clean cargo add oxigdal and you're good to go.

:crab: Why we built it & What it does:
We wanted a modern, memory-safe geospatial engine designed for the cloud-native era. OxiGDAL spans over 68 workspace crates and includes:

  • Zero-Dependency Build: Compiles to a statically linked binary. Our production Docker images are under 50MB.
  • Blazing Fast SIMD: We heavily utilize AVX2/NEON for coordinate transformations and raster math. (e.g., transforming 1M points takes < 10ms).
  • Arrow-Native Vector Data: Reads GeoParquet natively. It's built on top of the Rust Arrow ecosystem, bypassing traditional serialization overhead.
  • WASM First-Class Support: Because it's pure Rust, you can parse Cloud Optimized GeoTIFFs (COGs) and run heavy geospatial algorithms directly in the browser.
  • Enterprise / Cloud-Native: Built-in pure Rust crypto (rustls, ring), Raft-based clustering, and native streaming integration (Kafka, Pub/Sub).

:laptop: Quick example (CRS Transformation):

use oxigdal_proj::{Crs, Transformer};

// No C-bindings involved!
let wgs84  = Crs::from_epsg(4326)?;
let utm54n = Crs::from_epsg(32654)?;   
let tf     = Transformer::new(&wgs84, &utm54n)?;

// SIMD-vectorized batch transform
let (easting, northing) = tf.transform(139.7671, 35.6812)?;

We just published a Medium article detailing the architecture and motivation behind the project:
:open_book: Introducing OxiGDAL: The Pure Rust, Cloud-Native Successor to GDAL

You can check out the source code and documentation here:
:star: GitHub: https://github.com/cool-japan/oxigdal
:package: Crates IO: cargo add oxigdal

We’d love to hear your feedback, issues, or PRs. Let's make the future of GIS memory-safe! :globe_showing_europe_africa::rocket:

2

I'm not very familiar with this field so what does this library actually do?

Suppose I wanted to select a random point on the Earth's surface and detect what continent (or ocean) it belongs to. The point generation would be done with rand and I'd have (latitude, longitude) pair ; how would I call your lib for continent detection then, and what additional files would be required?

3

hi,

had a quick look at the README and have few questions:

  1. do you support GeoPackage format? if yes, can you point to an example usage.
  2. do you implement JTS like algorithms, similar to geo topology algorithms? e.g. crosses, intersects', etc...
5

Thanks for taking a look at the README, and those are two very important questions for anyone working with vector data

Here is where OxiGDAL currently stands on both fronts in the v0.1.0 release:

1. GeoPackage Support

For this initial v0.1.0 release, our primary vector focus has been on cloud-native and streaming-friendly formats. Because of this, GeoParquet and FlatGeobuf (.fgb) are our first-class citizens, alongside legacy Shapefiles.

A 100% pure Rust implementation of GeoPackage (.gpkg) is highly requested and is on our near-term roadmap (likely leveraging rusqlite under the hood to maintain the zero-C-dependency rule). For the time being, if you need a single-file spatial database format, we heavily recommend using our FlatGeobuf or GeoParquet integrations, which offer incredible read performance.

2. JTS-like Topology Algorithms

When it comes to the DE-9IM topological relationships , our philosophy is not to reinvent the wheel. The Rust geo ecosystem (specifically the geo and geoarrow crates) has already done a phenomenal job implementing these JTS-style algorithms.

Instead of building a competing topology engine, OxiGDAL is designed to seamlessly interoperate with them:

  • During I/O (Pushdown Filters): OxiGDAL handles basic spatial filtering while reading to avoid loading unnecessary data into memory. For example, our GeoParquet reader supports bounding box filters natively (as shown in the README), and we are expanding this to basic Intersects to filter chunks at the file level.
  • In-Memory (The geo ecosystem): Once the data is loaded by OxiGDAL, we expose it using standard Arrow arrays or Rust structs that easily convert into geo::Geometry types. From there, you can directly use the standard geo crate algorithms (.crosses(), .intersects(), .contains(), etc.) for complex, in-memory topological analysis.

We handle the heavy lifting of I/O, CRS transformations (oxigdal-proj), and raster math (oxigdal-algorithms), and let the broader Rust ecosystem handle the pure vector topology!

6

thanks.

i probably will have more questions after i take a closer look at your WMS server source. if/when i do i'll post those on your project's github page.

cheers;

7

Can you share how much of this project was written by LLMs?