Galileo: a Rust map renderer that leaves tile schemas and CRS to you

General purpose means the caller owns the decisions

Galileo describes itself as a general purpose cross-platform geo-rendering library written in Rust. The word general purpose is doing real work in that sentence. The README explains that the architecture is designed to allow different modes of use: client GUI mapping applications, server modules and CLI tools.

That goal creates a problem the author names directly. Caching of loaded and rendered objects works completely differently in a server than in a client application, so a library that tries to serve both needs a caching story, and Galileo does not impose one. The README states it is designed so that the user of the library makes all the relevant decisions rather than being forced into one way.

The second half of the principle is about geography rather than software. Galileo makes no assumptions about tile layer schemas, CRS or datums. It does not ship an opinion about how your tile pyramid is indexed or which coordinate reference system your tiles were baked in. For a team whose data comes from a fixed provider and fits a common schema, that neutrality is overhead. For a team rendering several sources with different conventions, it is the whole point.

The people it is for are Rust developers building map software, not users of a finished mapping application. The repository carries galileo-egui for desktop toolkits and galileo-maplibre for Maplibre style handling, which tells you the intended application shape before you read a line of the API.

Rendering goes through wgpu and the backend is meant to be swapped

Everything Galileo draws ends up going through wgpu. The README states that this means the library can be used on any platform wgpu supports: Linux, MacOS and Windows on the desktop, Android and iOS on mobile, and the web by compiling to WASM and using either WebGL or WebGPU.

Two consequences follow. First, the platform list is inherited from a graphics abstraction rather than chosen by the project, so you inherit its driver and adapter requirements too. Second, and more interestingly, the README says the backend is not an integral part of the Galileo design and that the project will probably try other promising backends, naming vello as a possibility. A rendering library whose renderer is meant to be replaced is an unusual posture, and it has a practical meaning: code written against Galileo's own layer and renderer types should survive a backend change, but code that reaches into wgpu directly will not.

The repository shows the same layering in its crate structure. Cargo.toml defines a workspace with members galileo, galileo-maplibre, galileo-mvt, galileo-types, galileo-egui and web-example, with the core galileo crate pulled in with default-features off in the workspace dependency table, which is the pattern you would use to pick optional capabilities deliberately.

The README also lists high performance among the present features, alongside raster tile layers, vector tile layers with styling, vector geo-data layers with styling, 3d view and 3d object rendering, user input handling on layers with mouse support and touch work in progress, and support for different projections and tile schemes.

Feature layers re-project, tile layers do not

Here is the sharpest technical boundary in the project, and the README states it in one sentence. Feature layers support transparent re-projecting into the map CRS, while support for projecting tile layers is planned but not implemented yet.

Think about what that means in practice. If your map view is in Lambert Equal Area projection and your source data is a set of GeoJSON features in another CRS, Galileo can transform them on the fly and you get correct geometry without a preprocessing step. If your source is a raster or vector tile pyramid baked in Mercator, you get the tiles as they are. The web example that draws a country border dataset in Mercator into an LAEA map therefore works through the feature layer path, which is the same path the feature layers example uses.

The asymmetry catches people out because it is invisible until a map looks wrong. A layer of tiles in the wrong projection does not throw an error; it simply draws where the tile grid says, and the mismatch shows up as a distorted or misaligned map rather than a failed call. Anyone planning to serve their own tiles in a non-Mercator scheme has to handle that conversion outside Galileo for now.

The README is also candid that Galileo is an active work in progress and lists the features already present rather than claiming completeness. Touch input on layers is marked as work in progress, with mouse support the only finished path.

Rust only today, with FFI parked on the roadmap

The language story is not settled. The README says that at this point you can develop an application using Galileo only in Rust, and points to a proof of concept example of how the authors envision future development on other platforms.

The plan is FFI bindings to other languages using wasm-bindgen and uniffi, which would let you build applications in JS, Kotlin, Swift or Python against a common API. The condition the README attaches is explicit: when the main features are more or less stable, or when a need arises, those bindings will be added. On the roadmap that lands in the v0.5 milestone alongside a stabilised API for features and projections and interoperability with main UI frameworks.

The WASM story is separate and more immediate. The web examples run in a browser, which is possible because the library compiles to WASM and uses either WebGL or WebGPU. So a JavaScript front end can already host Galileo output, but through the compiled library rather than through typed bindings, which is a different thing from calling Galileo from JS directly.

For an organisation with a Kotlin or Swift client already in production, the practical consequence is that this is a Rust-only dependency today, and any cross-language plan has to be built on the WASM path until the FFI work lands.

Running the examples with just, wasm_pack and python3

The examples are the fastest way to judge the library, and the README documents how to run them. Rust examples live in galileo/examples, with the readme in that folder carrying the list, descriptions and run instructions.

For the browser examples you need wasm_pack, just and python3 installed, and the command is short:

just run_web_example <example_name>

After it finishes you open localhost:8000 in your browser. The justfile shows why that port appears: the run_web_example recipe builds the example and then serves the output directory with the Python standard library.

  cd target/web_examples/{{NAME}} && python3 -m http.server

The build step behind it compiles the web example with wasm-pack for a no-modules WASM target and copies the index.html and the vt_worker.js next to the generated pkg directory. The same recipe reads a VT_API_KEY environment variable and prints a warning when it is not set, because vector tile layers will not work without it. So the raster tile example runs with no key, and the vector tile example needs one.

Cross-compiling from Linux to Windows is also documented. You add the target first:

rustup target add x86_64-pc-windows-gnu

Then install the cross-linker on Debian or Ubuntu:

sudo apt-get install mingw-w64

And build:

cargo build --target x86_64-pc-windows-gnu

An Android example exists as well, in android_examples/raster_tiles, with its own readme describing how to run it.

A roadmap that admits what is missing, and a dual licence

The roadmap is unusually concrete, which makes the maturity picture easy to read. The v0.1 milestone, labelled usabilitification, is checked off in full: architecture and basic building blocks, styling of vector tile and feature layers, support for main source types such as TMS tiles, 2d geometries and MVT, and rendering in different projections.

Everything after that is unchecked. v0.2 is styling work. v0.3 is 3d work including a globe, terrain rendering, 3d models and advanced projection support. v0.4 is where the API for the main building blocks, named in the README as Map, Layer and Renderer, is meant to be stabilised, alongside support for open GIS standards such as PostGIS, WMS and WFS, more styling types and custom shaders. v0.5 covers the feature and projection API and FFI bindings. v0.6 is interoperability with MapBox styling. Only v1.0 carries testing, documentation and examples. The README even qualifies the stabilisation promise, noting that it does not rule out breaking changes, only that they will be tracked with upgrade instructions.

Against that, the version numbers and dates are modest. The workspace version is 0.2.1, and the published crates galileo-v0.2.1, galileo-types-v0.2.1 and galileo-mvt-v0.2.1 all date from 2025-07-11. The repository is not archived and the last push was on 2026-07-30. The workspace license field reads MIT OR Apache-2.0, and the repository carries both LICENSE-APACHE and LICENSE-MIT, so you pick the terms that suit your distribution.

The alternative worth naming is the browser mapping stack, and Galileo itself points at the gap. Its own web examples include a Maplibre vector tile layer with style switching, and MapBox styling interoperability is a v0.6 item on the roadmap. If you need mature style compatibility and stable APIs on day one, a browser mapping library remains the cheaper path. Galileo is the interesting option when you want one Rust codebase rendering on desktop, mobile and web, and are willing to track a project whose Map, Layer and Renderer API is not yet declared stable.

Editorial conclusion

Galileo suits a team that wants to render maps in Rust across desktop, mobile and web from one codebase, and that is willing to own styling, data sources and the gaps in the roadmap itself. It is the wrong choice for a product that needs MapBox style compatibility, stable APIs or open GIS service support today, because interoperability is a v0.6 item, API stabilisation is a v0.4 and v0.5 item, and the newest published crates are galileo-v0.2.1 from 2025-07-11. Before adopting, open galileo/examples and check which layer types and styling options are finished, and confirm that the wgpu backend runs on your target platform, since the last push was on 2026-07-30.

Frequently asked questions

Official sources

1. galileo-map/galileo on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases