rstar is the R*-tree spatial index most Rust geospatial work ends up depending on

An index, not a geometry library, and that boundary is the design

rstar is described as a flexible, n-dimensional R*-tree implementation for the Rust ecosystem, suitable for use as a spatial index.

The important word is index. The README explains what an r-tree is: a data structure containing spatial data, optimized for nearest neighbor search, where spatial data refers to an object that has the notion of a position and an extent, for example points, lines and rectangles in any dimension.

That definition is the whole scope. There is no coordinate system handling here, no projection, no geometry parsing and no file format support. What you get is the data structure and the query operations over it.

The n-dimensional part matters more than it first appears. Most spatial indexes in use assume two dimensions, because the data usually comes from maps. rstar is written for any dimension, so the same structure serves a 2D map query and a 3D or higher dimensional nearest neighbour problem.

The R* tree variant itself is the algorithmic choice, and it is worth knowing that the README links the definition to the Wikipedia article on the R* tree rather than explaining the insertion heuristic differences from a plain R-tree. If you need to know how the tree rebalances on insert, that reference is where the detail lives.

The repository README is deliberately a pointer. It says to refer to the crate README for more information, which tells you that the crate documentation on docs.rs, and the rstar/README.md in the repository, are the real documentation.

Primitives for points, lines and rectangles, and geo builds on top

Primitives are provided for point, line and rectangle geometries, and the second point of the README is about how the ecosystem uses them.

The geo crate uses rstar as an efficient spatial index, and it provides RTreeObject implementations for storing complex geometries such as linestrings and polygons. That is the key architectural relationship in the project: rstar is the storage layer, geo is the geometry layer on top of it.

The trait that makes this work is RTreeObject, which is how a geometry declares that it can live in the tree. A point implements it trivially. A linestring or a polygon implements it by exposing its bounding extent, so the tree can index it while the caller keeps the real shape.

This is a deliberate split rather than an accident. It means you can use rstar alone with your own types, as long as they implement the trait, and you do not pull in a full geometry stack for what is a nearest neighbour query. The cost is the same in the other direction: if you want polylines, buffers and coordinate transforms, rstar is not going to give them to you, and that is what geo is for.

The documentation link in the README points at the RTreeObject trait page, which is a good sign about where the real API surface is. The trait is the extension point, and the primitives are just the built-in implementations of it.

A three crate workspace where the patch section keeps things honest

The repository is a Cargo workspace with three members, the rstar crate itself, rstar-demo and rstar-benches, and the workspace uses resolver 2.

The patch section is the detail worth knowing. The comment says to ensure any transitive dependencies, for example via geo, use the local rstar crate, and the patch entry points rstar at the path rstar. In practice that means the benchmark crate and the demo measure the code in this checkout rather than a published version from crates.io, which is the difference between a benchmark that means something and one that measures the wrong code.

The rstar-demo member is what the README's Demo section describes: to run the rstar-demo, checkout the repository and run cargo run rstar-demo in the repository root. The demo directory at the root is called rstar-demo, matching the workspace member name, and the README includes a screenshot of the result.

The benches member is rstar-benches, and its presence at the workspace level rather than inside the crate is the usual Rust convention for a crate that ships its own benchmark suite.

The published crate is what docs.rs serves, and the version badge points at crates.io for rstar, so the published artifact and the repository are the same project with the repository holding the workspace, the demo and the benchmarks around it.

Install it as a dependency, and read the crate README for the API

There is no install command in the README, because rstar is a library and the README is the repository overview rather than a getting started guide. The crate is on crates.io as rstar, with documentation on docs.rs.

The practical first step is the one the README keeps pointing at: the crate README, which is where the usage detail lives. Everything in the repository README is either a definition of what an r-tree is, a pointer to the crate README, a note about the geo relationship, or the demo instructions.

For the demo, the sequence is the one the README gives. Check out the repository and run cargo run rstar-demo in the repository root, and the screenshot in the README shows what the result looks like. That is a reasonable way to see the structure behave before wiring it into your own types.

The build prerequisites are the standard Rust toolchain, since the workspace uses Cargo with no other tooling mentioned. The workflow badge in the README points at a test workflow named test.yml, so the test suite runs in CI on every change, which is the practical reassurance for a data structure that other crates depend on.

There is no configuration file, no feature flag documented and no environment variable in the README, and for a spatial index that is the expected shape: the API is the data structure, and the choices you make are about your own geometry types rather than about the tree.

Where a spatial index is the wrong answer

The first limit is scope, and it is a good one to state clearly. rstar does not do spatial queries in the geographic sense. It has no notion of latitude, no map projection, no spatial predicates like contains or intersects, and no geometry serialization. If your problem is which polygons contain this point, rstar is the wrong crate and you want a geometry library instead.

The second limit is dimensionality versus distribution. The tree assumes a metric space in which distance is meaningful, and it works in any dimension. That is a strength for high dimensional nearest neighbour search and a weakness for the case where your coordinates are on a sphere. A tree built over longitude and latitude treats degrees as a flat plane, and the distortion near the poles is a property of the data, not of the index. If your data is spread over the globe, that is a problem you inherit whatever index you pick.

The third is the shape of the R*-tree itself. R* trees are built for spatial data with meaningful extent, where objects occupy regions. A dataset of points with identical coordinates, or objects with wildly varying sizes, is a poor fit, because the tree's rebalancing heuristics are tuned for the case where extent carries information.

The alternative to weigh is the k-d tree, which is what many nearest neighbour implementations in Rust reach for first, and which is simpler and often faster for low dimensional uniform point data. The difference in approach is the data structure's premise. A k-d tree partitions the space, so it is natural for point clouds in a small number of dimensions. An R*-tree groups objects by their extent, so it stays efficient when the data is mixed shapes with real area, which is what a spatial index in a geometry library is dealing with. If your data is a uniform cloud of points in two or three dimensions, a k-d tree may well be the better structure; if it is rectangles and linestrings, rstar is the one that holds up.

A permissive licence and a repository with no release history

The licence is the permissive double option. The README says licensed under either of the Apache License, Version 2.0, referring to LICENSE-APACHE, or the MIT license, referring to LICENSE-MIT, at your option.

Both files are at the repository root, alongside the README, the Cargo.lock, the.github/ directory, the rstar/ crate directory, the rstar-demo/ and rstar-benches/ members, and the rtree-example.png image.

The maintenance picture is current on the code side. The last push was on 2026-10-22 and the repository is not archived, and the workflow badge shows the test workflow running.

The version record is where the detail is thin. The repository has no GitHub releases, so there is no tag history to read and no changelog to diff. The crates.io version badge is the only version pointer, and the Cargo.lock at the root is the only pinned state. For a library that other crates depend on, that is a limitation of the record rather than of the code, and it is a good reason to pin a version in your own manifest rather than tracking the branch.

For anyone deciding whether to depend on rstar, the ecosystem position is the strongest evidence available, and the README states it plainly: the geo crate uses rstar as an efficient spatial index. A geometry crate choosing an index and building its RTreeObject implementations on top of it is a much stronger signal than any release cadence, and it means the trait contract is exercised by a real, widely used consumer of the library rather than only by its own tests.

Editorial conclusion

Adopt rstar if you are doing nearest neighbour or range queries over geometry in Rust and want a spatial index rather than a full geometry framework, since it is the index layer and nothing more. Do not adopt it as a standalone geometry library, because it holds no projection, no CRS handling and no parsing, and the geo crate is what supplies that alongside the index. Verify first which Rust version your toolchain allows, since the crate is used by projects with long upgrade cycles, and read the crate README rather than the repository README, because the repository README defers to it for the actual usage detail.

Frequently asked questions

Official sources

1. georust/rstar on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README