# RustGIS is a desktop GIS where every ribbon button is a scriptable command > RustGIS is an Apache-2.0 licensed Rust workspace for a GIS application that runs natively on Windows, macOS and Linux and compiles to WebAssembly, with geometry, data, map, analysis, render, engine and plugin crates, a command line, a Python package and a plugin registry. Its first tagged release was v0.1.0 on 2026-10-12 and v0.2.0 followed the next day. **opengeos/RustGIS** — A fast, free and open-source GIS in pure Rust. - Repository: https://github.com/opengeos/RustGIS - Website: https://rustgis.app - Stars: 2,427 · Forks: 363 - Language: Rust - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/opengeos-rustgis ## A GIS that is one native program with a GPU renderer RustGIS describes itself as a fast, free and open-source GIS in pure Rust for mapping, analyzing and sharing geospatial data, and the subheading sets the two promises. Native on Windows, macOS and Linux, and in your web browser. Your data stays on your machine unless you send it to an AI model you choose, and every action is a command you can script. The Why section expands that into six claims, and the first two are the ones that describe the engineering. Fast and small. One native program, drawn on the GPU, with no runtime to install and no server to run. Runs everywhere. The same app on Windows, macOS and Linux, and compiled to WebAssembly at web.rustgis.app with nothing to install. The rendering stack in the dependency list confirms the GPU claim. tiny-skia at 0.12 is the CPU rasteriser, ab_glyph at 0.2 is the font handling, and the image crate at 0.25 with default features off and only png enabled is a deliberately narrow image surface. The privacy claim is more specific than it first appears, and the README is careful about the exception. The network is used only when you ask for it, and the list of things that use it is web basemaps, plugins, the GeoLibre tools and the AI model you pick, which receives your questions and the data it reads to answer them. So the data stays local by default and the one component that deliberately sends data out is the one you choose a provider for. The fourth claim is the one that makes this project different from a desktop GIS. Every button in the ribbon is a command with an id. Script it from rustgis-cli, chain it in notebooks and models, or ask the AI Assistant to run it for you. That single design decision is what unifies the whole application. The ribbon, the CLI, the Python API and the AI assistant are four front ends over one command set, rather than a GUI with a separate automation story bolted on. ## The workspace is a set of crates with clear boundaries The Cargo.toml workspace shows the internal structure, and the crate names describe the layers. ```toml [workspace] resolver = "3" members = ["crates/*", "apps/*", "xtask"] default-members = ["crates/*", "apps/rustgis", "apps/rustgis-cli", "xtask"] ``` The internal crates are rustgis-geom for geometry, rustgis-data for data, rustgis-map, rustgis-analysis, rustgis-render, rustgis-engine, rustgis-ui-egui for the interface, rustgis-geolibre for the tool bindings, rustgis-plugins, rustgis-tiles, and rustgis-assistant for the AI assistant. So the desktop application is apps/rustgis, the command line is apps/rustgis-cli, and xtask is the task runner. The default-members line excludes the other apps from a plain workspace build, which is what keeps a full build of the desktop app, the CLI and the crates from dragging in the Python app and the web build. The foundation dependencies are small and worth noting. thiserror and serde for the data model, sha2 for hashing, log for logging, and web-time as the std::time replacement that also works in the browser, since std panics on wasm32-unknown-unknown. That single line is the kind of detail that shows the browser target is a first class case rather than an afterthought. The geospatial dependencies are mostly pure Rust. geo at 0.33 for the geometry types, shapefile at 0.9, csv at 1, tiff at 0.11 for GeoTIFF, proj4rs at 0.2 and crs-definitions at 0.6 for coordinate systems by EPSG code. The comments in the manifest are precise about the exceptions, that the raster stack is pure Rust except the Zstandard decoder that rustgis-data turns on, which is C that clang compiles for the browser build too, and that zstd at 0.13 is there for the tests, which use Zstandard-compressed GeoTIFFs. So the one piece of C in the stack is called out and justified, and it is needed for the test fixtures rather than for a user-facing format. ## Geoprocessing is delegated to a thousand existing tools The feature list makes an unusual claim and it is the clearest statement of what RustGIS is and is not. Extensible. Over 1,000 GeoLibre and Whitebox tools for terrain, hydrology, LiDAR and remote sensing, and sandboxed WebAssembly plugins that add commands, tools and ribbon tabs. So the geoprocessing catalogue is not written in this project. It is bound from GeoLibre and Whitebox, which are existing tool collections, and the plugin system adds more on top. The Analysis tour image describes it as a tool gallery, the Tools pane and a run history, guided workflows, ModelBuilder, and 1,000 plus GeoLibre and Whitebox tools. The plugin model is the part that is worth reading carefully, and the tour description is explicit. Browse and install sandboxed plugins from plugins.rustgis.app, each showing the permissions it asks for. Sandboxed WebAssembly, and a permission prompt. That is a considered design. A plugin is not native code with full access to the process, it is a WebAssembly module with a declared set of permissions, and the registry at plugins.rustgis.app is where they are listed. The tour also shows a Plugin Manager listing Basemaps, Hello RustGIS, Map Explorer and Vector Toolkit with their permissions beside them. For a desktop application whose whole point is that every action is a command, an extension mechanism is required, and the alternatives are all worse. Native plugins mean a crash in a plugin takes the app with it, and an unsigned binary plugin is a code execution hole. A WebAssembly sandbox with declared permissions is a defensible compromise, and the fact that the permissions are shown to the user at install time is the part that makes it reviewable. The AI Assistant is described as a pane where you ask about your data or tell the map what to do, and the assistant runs RustGIS commands for you, and each change can be undone. ## The tour covers the surface a desktop GIS is expected to have The tour section is a set of screenshots with captions, and the captions are effectively a feature list written by someone who knows what a GIS user does. Symbology and tables. Selecting a layer opens its contextual tabs, symbology, effects, labeling and data, and selection is synced between the map and the attribute table. Rasters. GeoTIFF and COG of any pixel type, reprojected on the fly, with stretch, RGB, classified and shaded-relief symbology. The tour image is a shaded-relief elevation model of the Sierra Nevada. Globe and projections. A 3D globe, Equal Earth, Robinson, polar and regional presets, or any EPSG code. The main screenshot is the world in the Equal Earth projection with countries shaded by population. Web basemaps. XYZ, TMS and WMS tiles, Mapbox Vector Tiles and MapLibre styles, on the flat map and the globe. Layouts. Map frames, legends, scale bars, grids, map series and PDF export, plus reports and presentations. The interface description is the other half. A ribbon laid out in the order of the work, Home, Data, Style, Edit, Analyze, View and Publish, with Layers and Browser panes, an attribute table, and undo for every change. And there is a familiar point made explicitly. The ribbon order follows the workflow rather than grouping features by type, which is the argument against the ribbon interface that GIS applications have had for a decade. The screenshot descriptions also reveal the data model in passing, since the AI Assistant example says it read the Countries table, selected them and zoomed to them. So the data is in tables with named columns, and the assistant operates on them through the same commands the GUI uses. ## Python, WebAssembly and the plugin registry are three distribution channels The badges at the top of the README point at four destinations, and they are four ways to reach the same engine. The desktop app comes from the GitHub releases, the web app is at web.rustgis.app, the documentation is at rustgis.app, and there is a PyPI package named rustgis alongside a Colab badge pointing at a getting-started notebook in the repository at apps/rustgis-python/examples/getting-started.ipynb. So the Python app is a first-class member of the workspace, not an afterthought, and the apps/ directory in the repository listing contains it alongside the desktop app and the CLI. A Colab notebook that runs the GIS is an unusual distribution choice and it is a good one for a research audience, since it removes the local install entirely. The plugin registry at plugins.rustgis.app is the fourth channel and the one with the most design behind it, since it is a distribution mechanism for third parties. The repository top level listing shows the supporting structure. There is a skills/ directory, which is a newer convention for shipping agent-facing instructions, an AGENTS.md, a ROADMAP.md, an ATTRIBUTION.md, a clippy.toml for lint configuration, a rustfmt.toml, a.pre-commit-config.yaml, a docs/ directory, a packaging/ directory, an xtask/ directory for the task runner, and a zensical.toml for the docs configuration alongside a requirements_docs.txt. The release history is the caveat. There are two tagged releases, v0.1.0 on 2026-10-12 and v0.2.0 on 2026-10-13, and the last push was on 2026-10-19. So the project is days old in its released form, and the version in the workspace package section is 0.2.0 on Rust edition 2024 with a rust-version of 1.90. ## Where RustGIS is the wrong choice The first wrong case is a team that needs a mature GIS product today. Two tagged releases, one of them the day after the other, means every workflow, every format edge case and every plugin you depend on is a moving target. The 1,000 plus geoprocessing tools come from GeoLibre and Whitebox, which is a strength, but the application that binds them, the format readers, the cartography and the layout engine are all new. The second wrong case is a team with an existing Python geospatial stack that does not want a rewrite. rasterio, geopandas, shapely, pyproj and fiona are mature and widely deployed, and replacing them with a Rust core that is two releases old is a large bet for a modest gain. The third wrong case is a deployment where a WebAssembly build is not acceptable. The web app is a headline feature, but a Wasm build has constraints, and the manifest comments show the team working around them, with web-time standing in for std::time and a C Zstandard decoder compiled by clang for the browser. The fourth wrong case is an organisation that cannot accept a pluggable, scriptable application with declared plugin permissions. A desktop GIS with a plugin registry, a command layer that the AI assistant can drive, and tools that act on your files is a large capability surface, and a security review of that surface is work the adopting team has to do. ## How it differs from QGIS The comparison worth making is with QGIS, because QGIS is the open source desktop GIS that this project is unambiguously in the space of, and the differences in approach are instructive. QGIS is a C++ and Python application built on Qt, with a huge plugin ecosystem, a Python console, and a Processing framework for geoprocessing that includes GRASS and SAGA algorithms. It has been the default open source desktop GIS for a long time, and it is capable of more than anything a new project can match on day one. Its costs are the ones a well known project has, a large install, a large memory footprint, a C++ core that is awkward to embed in a Rust service, and a plugin API that runs in the host process. RustGIS inverts the first of those costs. One native program, drawn on the GPU, with no runtime to install and no server to run, and the same app on three platforms and in a browser. The README's Fast and small claim is the response to QGIS's footprint. The second difference is the plugin sandbox. QGIS plugins are Python, running in the host process, with full access to the application. RustGIS plugins are sandboxed WebAssembly with declared permissions, which is a real security improvement and a real limitation, since a plugin that needs to do something undeclared cannot. The third difference is the command model. QGIS has a Python API and a Processing framework, so scripting means writing Python that talks to the application or invoking the processing algorithms. RustGIS makes the command layer the primary interface, with the ribbon, the CLI, the Python package and the AI assistant as peers over it. That is a different bet about how people will use a GIS, and it is the bet the project is making. The fourth difference is maturity, and it is not close. The geoprocessing catalogue is comparable because it is borrowed. Everything else is younger. ## Conclusion RustGIS fits a geospatial developer who wants a desktop GIS with a scriptable command layer, a plugin system and no server to run, and a Python user who wants the same engine through PyPI or a Colab notebook. It does not fit a team that needs an established GIS ecosystem today, since the project has only two tagged releases, v0.1.0 on 2026-10-12 and v0.2.0 on 2026-10-13, and it does not fit a team that cannot accept a WebAssembly build step in the browser path. Before adopting it, read the plugin permissions model in docs/plugins.md, since plugins are sandboxed WebAssembly and each declares what it asks for, and note that the workspace requires Rust 1.90 with edition 2024 and that the AI Assistant is the one component that sends your questions and the data it reads to a model you choose. ## FAQ ### What is RustGIS and what platforms does it run on? It is an Apache-2.0 licensed pure Rust GIS for mapping, analyzing and sharing geospatial data. The same application runs natively on Windows, macOS and Linux and is compiled to WebAssembly at web.rustgis.app, with no runtime to install and no server to run. ### How does RustGIS handle scripting and automation? Every button in the ribbon is a command with an id. You can script it from rustgis-cli, chain it in notebooks and models, or ask the AI Assistant to run it for you, with the ribbon, the CLI, the Python package and the assistant all sitting over one command set. ### What is the RustGIS plugin system like? Plugins are sandboxed WebAssembly that add commands, tools and ribbon tabs, browsable and installable from the registry at plugins.rustgis.app, with each plugin showing the permissions it asks for. Over 1,000 GeoLibre and Whitebox tools for terrain, hydrology, LiDAR and remote sensing are also available. ### Can RustGIS be used from Python? Yes. There is a rustgis package on PyPI, the repository contains an apps/rustgis-python directory with example notebooks, and there is a Colab badge pointing at a getting-started notebook, so the engine is reachable from Python without a local install. ### Is RustGIS data kept on the local machine? Yes, by default. The README says your files are read and written on your machine and nothing is uploaded on its own. The network is used only when you ask for it, and the one exception is the AI model you choose, which receives your questions and the data it reads to answer them. ## Sources - [License: Apache-2.0](https://github.com/opengeos/RustGIS/blob/main/LICENSE) - [opengeos/RustGIS on GitHub](https://github.com/opengeos/RustGIS) - [Project website](https://rustgis.app) - [README](https://github.com/opengeos/RustGIS/blob/main/README.md) - [Releases](https://github.com/opengeos/RustGIS/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opengeos-rustgis