whitebox_next_gen

Rust workspace for Whitebox next-generation backend libraries and tool crates.

The Whitebox Project

Whitebox is a suite of open-source geospatial data analysis software with roots at the University of Guelph, Canada, where Dr. John Lindsay began the project in 2009. Over more than fifteen years it has grown into a widely used platform for geomorphometry, spatial hydrology, LiDAR processing, and remote sensing research. In 2021 Dr. Lindsay and Anthony Francioni founded Whitebox Geospatial Inc. to ensure the project's long-term, sustainable development. Whitebox Next Gen is the current major iteration of that work, and this repository is its home.

Whitebox Next Gen is a ground-up redesign that improves on its predecessor in nearly every dimension:

• CRS & reprojection — Full read/write of coordinate reference system metadata across raster, vector, and LiDAR data, with multiple resampling methods for raster reprojection.
• Raster I/O — More robust GeoTIFF handling (including Cloud-Optimized GeoTIFFs), plus newly supported formats such as GeoPackage Raster and JPEG2000.
• Vector I/O — Expanded from Esri Shapefile-only to 11 formats, including GeoPackage, FlatGeobuf, GeoParquet, and other modern interchange formats.
• Vector topology — A new, dedicated topology engine (wbtopology) enabling robust overlay, buffering, and related operations.
• LiDAR I/O — Full support for LAS 1.0–1.5, LAZ, COPC, E57, and PLY via wblidar, a high-performance, modern LiDAR I/O engine.
• Frontends — Whitebox Workflows for Python (WbW-Python), Whitebox Workflows for R (WbW-R), and a QGIS 4-compliant plugin (wbw_qgis) are in active development.

Design Goals

Whitebox development is guided by a small set of core priorities that, taken together, make it meaningfully different from most other geospatial software packages.

Broad geospatial functionality with deep specialization

Whitebox aims to be a comprehensive general-purpose GIS and remote sensing toolset — covering raster analysis, vector processing, coordinate reference systems, and LiDAR — while maintaining particular depth in geomorphometry, spatial hydrology, and point-cloud processing. Breadth and depth are both first-class goals.

Full-stack architecture

Most geospatial software packages — open-source and commercial alike — are built on a common foundation of external C/C++ libraries such as GDAL, PROJ, and GEOS for low-level I/O, projection, and geometry. Whitebox deliberately does not follow that model.

Whitebox is full-stack: all foundational plumbing — GeoTIFF I/O, map projections, raster abstraction, vector I/O, LiDAR parsing, and topology — is implemented in this codebase rather than delegated to external libraries. This choice has several important consequences:

• Performance — Every interface between a library boundary introduces overhead and reduces the ability to optimize holistically. Owning the full stack means Whitebox can tune performance end-to-end without friction at foreign-function interfaces.
• Development velocity — There is no dependency on upstream library release cycles, no forced adaptation to breaking changes in third-party APIs, and no need to wait for upstream maintainers to prioritize features or fixes that Whitebox needs.
• Flexibility — Owning the stack allows Whitebox to make design decisions — data representations, memory layouts, codec choices — that would be impossible or impractical when adapting a general-purpose external library to a specialized use case.

Pure Rust, minimal dependencies

The full-stack architecture and the choice of pure Rust are deeply linked. Rust provides the performance headroom that makes it practical to implement things like LiDAR codecs, map projection engines, and raster I/O entirely from scratch without sacrificing speed. It also brings memory safety without a garbage collector, and excellent cross-platform compilation with no native toolchain requirements at build time.

External crates are used where they provide clear, well-contained value (compression codecs, serialization formats, etc.), but Whitebox avoids dependencies that would pull in C/C++ linkage or impose significant API coupling.

Innovation in spatial analysis

Whitebox is a research vehicle as much as a production tool. New spatial analysis algorithms — particularly in geomorphometry and spatial hydrology — are developed, tested, and published through Whitebox first, then made available to the wider community.

Human–AI collaborative development

Whitebox Next Gen embraces human–AI collaboration as a first-class part of the development process, using it to accelerate implementation, improve documentation, and explore algorithm design. This is reflected in development pace and project scope.

---

Project Model

Whitebox Next Gen follows an open-core model:

• All backend engine crates in this workspace are open source.
• The majority of the 500+ tools are open source in crates/wbtools_oss.
• A proprietary paid extension product exists outside this OSS workspace for additional commercial capabilities.

This structure is intentional. Revenue from the paid extension helps fund ongoing OSS development, maintenance, support, and long-term sustainability of the open project.

Workspace Crates

The following Rust crates are members of the Cargo workspace:

• crates/wbgeotiff — GeoTIFF/JPEG2000 I/O engine
• crates/wbprojection — map projection and CRS engine
• crates/wbraster — raster abstraction and I/O
• crates/wbvector — vector I/O (Shapefile, GeoPackage, FlatGeobuf, GeoParquet, and more)
• crates/wblidar — LiDAR I/O (LAS, LAZ, COPC, E57, PLY)
• crates/wbtopology — vector topology and spatial indexing
• crates/wbcore — shared runtime types and utilities
• crates/wblicense_core — license entitlement verification
• crates/wbtools_oss — open-source tool implementations (500+ tools)
• crates/wbw_python — Whitebox Workflows for Python frontend runtime
• crates/wbw_r — Whitebox Workflows for R frontend runtime

The following frontend lives in crates/ but is not a Cargo workspace member (it is a pure-Python QGIS plugin):

• crates/wbw_qgis — QGIS 4 plugin frontend; exposes Whitebox tools as a QGIS Processing provider, depends on the whitebox_workflows Python package built from wbw_python

Publication Status

The following six backend crates are published on crates.io and are useful as general low-level geospatial engines:

• wbgeotiff
• wbprojection
• wbraster
• wbvector
• wbtopology
• wblidar

The following six crates, also contained within this monorepo, are the core of Whitebox's frontend, that is the collection of 650+ spatial analysis tools:

• wbcore
• wblicense_core
• wbtools_oss
• wbw_python
• wbw_r
• wbw_qgis

This staged publishing model keeps the foundational backend stack available first while higher-level crates continue to stabilize.

Crate Relationship Diagram

graph TD
	wbgeotiff --> wbraster
	wbprojection --> wbraster
	wbprojection --> wbvector
	wbvector --> wbtopology
	wbprojection --> wblidar

	wbcore --> wblicense_core

	wbcore --> wbtools_oss
	wbraster --> wbtools_oss
	wbgeotiff --> wbtools_oss
	wbvector --> wbtools_oss
	wbprojection --> wbtools_oss
	wbtopology --> wbtools_oss
	wblidar --> wbtools_oss

	wbcore --> wbw_python
	wblicense_core --> wbw_python
	wbtools_oss --> wbw_python
	wbraster --> wbw_python
	wbprojection --> wbw_python
	wbvector --> wbw_python
	wblidar --> wbw_python

	wbcore --> wbw_r
	wblicense_core --> wbw_r
	wbtools_oss --> wbw_r

	wbtools_pro -. optional/external .-> wbw_python
	wbtools_pro -. optional/external .-> wbw_r

        wbw_python -. Python runtime .-> wbw_qgis

Loading

Legend:

• A --> B means crate B depends on crate A.
• wbtools_pro is optional and outside this workspace.
• wbw_qgis is a pure-Python QGIS plugin (not a Cargo workspace member); it depends on the whitebox_workflows Python package produced from wbw_python.

This repository is a Cargo workspace (monorepo). Each crate is developed in-place under crates/, but published independently on crates.io.

• Crates remain individually discoverable on crates.io by package name.
• Local development uses path dependencies.
• Published packages use version dependencies automatically when uploaded.

In this model, all crates share one repository URL in Cargo metadata, while each crate source lives at its own subdirectory URL:

• https://github.com/jblindsay/whitebox_next_gen/tree/main/crates/wbgeotiff
• https://github.com/jblindsay/whitebox_next_gen/tree/main/crates/wbprojection
• https://github.com/jblindsay/whitebox_next_gen/tree/main/crates/wbraster
• https://github.com/jblindsay/whitebox_next_gen/tree/main/crates/wbvector
• https://github.com/jblindsay/whitebox_next_gen/tree/main/crates/wbtopology
• https://github.com/jblindsay/whitebox_next_gen/tree/main/crates/wblidar

Current backend publish order:

1. wbgeotiff
2. wbprojection
3. wbraster
4. wbvector
5. wbtopology
6. wblidar

Run backend readiness checks from repo root:

bash scripts/check_backend_publish_readiness.sh

The readiness check validates package metadata and runs cargo package --allow-dirty --no-verify for each backend crate so dependency-order blockers are visible before publish.

Run publish-order dry-run checks (stop at first blocked crate):

bash scripts/publish_backend_dry_run.sh

Run maintainer-only internal workflows:

bash scripts/run_maintainer_workflows.sh list

Licensing in OSS

This repository includes crates/wblicense_core for open, auditable license entitlement verification and capability evaluation.

This does not make the project non-OSS. The crate contains public trust logic (verification and policy checks), not private commercial issuance logic.

See crates/wblicense_core/README.md for details on scope and architecture boundaries.

Binding-specific runtime licensing behavior (tier fallback, provider bootstrap, and policy controls) is documented in:

• crates/wbw_python/README.md ("Licensing and startup behavior")
• crates/wbw_r/README.md ("Licensing and startup behavior")

Note on floating licenses: lease lifecycle support is present, and automatic "floating license ID only" exchange on a brand-new machine is available when provider bootstrap is configured (WBW_LICENSE_PROVIDER_URL + WBW_FLOATING_LICENSE_ID) and the provider exposes the v2 floating activation endpoint. See the runbook sections in the Python/R READMEs.