Repository navigation
Replies: 6 comments 3 replies
|
@Mavrick-F Thanks for bringing this up! This is how I envision GeoLibre and RustGIS evolving. I like to think of GeoLibre vs. RustGIS as Google Docs vs. Microsoft Word. Both serve similar purposes, but they take different approaches and are optimized for different workflows. Neither is intended to replace the other. GeoLibre is primarily focused on web and mobile GIS. Its strength lies in accessibility, cloud-native geospatial workflows, interactive visualization, and the ability to work with geospatial data from virtually anywhere. You can open a browser and start working without installing anything. GeoLibre is also relatively mature now, with a broad set of features. I expect its development to focus more on stability, performance, usability, and incremental improvements rather than major architectural changes. RustGIS, on the other hand, is primarily focused on desktop GIS, although it also runs in the browser. It provides a familiar Ribbon-style user interface, a native desktop experience, and an agent-centric architecture. One of its key design principles is that almost everything can be accomplished through commands, making it easier to automate workflows, write scripts, and allow AI agents to interact directly with the application. RustGIS is still in its early stages and is undergoing rapid development. Expect frequent updates, new capabilities, and potentially significant changes as the architecture and ecosystem evolve. Another important distinction is the underlying technology. GeoLibre is built primarily on web technologies, including React, TypeScript, and MapLibre, while RustGIS is built almost entirely in Rust. This gives us an opportunity to explore different architectures, rendering approaches, and ways of building GIS applications. My long-term vision is for GeoLibre and RustGIS to complement each other rather than compete with each other. Ideally, users should be able to create a project in GeoLibre, open it in RustGIS, and vice versa. Project file interoperability, shared data formats, and reusable geoprocessing tools would make it possible to move between the two applications depending on the task at hand. Ultimately, my goal is not to build two competing GIS applications. It is to explore different approaches to making geospatial technologies more accessible, powerful, and easier to use. GeoLibre prioritizes accessibility and web-first workflows. RustGIS prioritizes native desktop experiences, automation, and AI-agent integration. Both are free and open source, and both share the same broader mission of democratizing geospatial technologies. We can update the comparison page to clarify some of these points. |
|
Thanks, the Docs/Word comparison helps. I can rewrite the comparison page around it: your priorities for each project up front, and the current feature gaps in a dated section. A few specifics would help turn this into roadmap changes:
|
|
|
Thanks for starting this discussion. I’ve been thinking about the relationship between the two projects too, and the idea of them complementing each other makes sense to me. One direction I’d like to explore for GeoLibre goes a little further than web-first: a shared, cloud-first GIS workspace. Groups or organisations could have their own GeoLibre instance, with persistent projects, private data stores, and GeoLens and related tools connected to that environment. That could mean managed deployments or a server they host themselves—not necessarily a public cloud service run by the project maintainers. That would give GeoLibre a distinct role as the shared place where a team’s projects and data live, accessible through the browser. RustGIS would complement it as the native desktop workbench for deeper editing, analysis and automated workflows. Project interoperability would be especially valuable here, so moving between the two wouldn’t mean exporting everything and rebuilding the project. I see this as a possible longer-term direction, not something already settled here or a request to build all of it now. It would also mean development beyond stabilising the current app, particularly around project storage, access control and deployment. Could that organisational, server-backed workspace be a useful focus for GeoLibre alongside RustGIS’s desktop direction? I’m looking forward to hearing your thoughts. |
|
@deniial00, I'm going to shrug and give a firm "maybe". 🙂Or more like a magic 8 ball, "Ask again later" Pros
Cons
One architecture thought: much of this already exists as open software. PostGIS, OGC API servers, STAC catalogs and OIDC sign-in cover data, serving and logins. GeoNode is already a shared workspace for a team's data, maps and permissions. Mergin Maps and QFieldCloud store and sync projects, though for QGIS. Before writing a server, I'd check whether GeoLibre and RustGIS can use those and only build the missing piece: storing our own project files. For now, though, I'd keep this as a someday idea. There are only a few of us, and giswqs is already maintaining two GIS applications, plus other opengeos projects. The near-term steps that move toward it anyway:
If those land and people start asking where to put their team's projects, then we can start architecting real-time collaboration infrastructure. |
|
Thanks, @Mavrick-F. I agree with your caution about operating a server and reusing existing infrastructure rather than rebuilding it. The main distinction I have in mind is GeoLibre focusing on web-first workflows, and RustGIS focusing on professional desktop GIS. That doesn’t have to mean dropping either app’s other platform, but it would give each a clearer priority. For GeoLibre, I’d like to see that web-first focus develop more in an enterprise direction: organisations running their own instance, connecting private data stores, and giving their teams access through their existing identity system. GeoLibre already has a server, server-side configuration and OIDC configuration, so there are existing pieces to build on. The sidecar also supports the web-first approach by fetching data that the browser can’t access directly because of CORS, although that’s separate from organisational access control and storage. The goal would be to make private geodata accessible across large teams, including colleagues who aren’t GIS specialists. People could find, view, explore and share relevant data and projects through the browser, potentially alongside GeoLens and related tools. That would be useful without requiring simultaneous editing or version-conflict resolution. So I’m not suggesting we build an entirely new enterprise platform now. I’m suggesting that organisational deployment and private-data sharing could be a clearer long-term focus for GeoLibre, using existing services wherever possible, while RustGIS concentrates on the desktop workbench. Which gaps in GeoLibre’s current capabilities would matter most for that direction? I’m looking forward to hearing your thoughts. |
|
Yes, my long term vision is to have an open-source alternative to ArcGIS Enterpise that GeoLibre and RustGIS can consume. We could build on top of exsiting solutions like GeoNode and GeoLens or build from groud up. Something to think about after RustGIS reaches a stable status. 
|
|
That aligns well with what I had in mind. I like the idea of shared infrastructure that both GeoLibre and RustGIS can use, with GeoLibre providing an accessible web-first experience for teams and RustGIS focusing on the desktop workbench. Longer term, I could also see us extracting suitable parts of GeoLibre’s sidecar into a separate repository so both applications can reuse them, rather than maintaining overlapping functionality independently. Not everything in the sidecar would necessarily belong there, but it could be a gradual step towards that shared backend as concrete needs arise in both apps. I agree that this shouldn’t take priority over getting RustGIS stable. Building on existing solutions such as GeoNode and GeoLens, alongside the pieces we already have, sounds like a good direction to explore when the time is right. |
|
It sounds like we're broadly aligned: RustGIS stable first, reuse existing pieces, and a shared backend when there's a real need for one. @deniial00 has already built a lot of the groundwork in GeoLibre's server API, so that won't be starting from zero. Reading the thread back, "shared infrastructure" could still mean slightly different things, so we'll eventually need to settle a few questions:
No need to answer these now. RustGIS fundamentals come first, and early steps like having RustGIS open .geolibre projects are fairly non-committal. |
Uh oh!
There was an error while loading. Please reload this page.
The GeoLibre comparison page exists because people ask how RustGIS and GeoLibre differ, and it answers with a feature list, which makes it a snapshot of October 2026. I've been reading it next to both roadmaps. Most of what it lists under "Where GeoLibre is stronger" is already planned for RustGIS, on our roadmap and item by item in GEOLIBRE_PARITY.md. If both projects follow their plans, the feature gaps close and the page has little left to say. That leaves a bigger question: what is each project for?
I don't think there's one obvious answer, so below are several directions that each make sense. I think it would be good to hear what direction people want, or which mix of them. I apologize if this post is presumptuous, but it seems better to consciously chose a heading instead of drifting in one direction by default. That's especially true given that AI-driven development will meander in an unproductive and contradictory fashion without human steering.
What the two projects both have today
.rgis.geolibrerustgis(engine,rustgis.Map)geolibre(Jupyter widget)Neither app opens the other's project file, so moving a project between them means exporting the layers and restyling them.
What stays different whatever we choose
Many differences are choices either project could reverse. For example, GeoLibre could adopt sandboxed WebAssembly plugins, since browsers run WebAssembly natively. These are the three baked-in differences I can identify:
Where GeoLibre is
GeoLibre is at 3.5 and already covers most of what a web GIS does, and it has a large user base. What it needs next is part of this question: more features, or reliability, more maintainers and the plugin marketplace finished? Whichever direction we pick, someone has to look after its users, and the two projects share maintainers.
Possible Directions
A. Split by platform
RustGIS becomes the desktop app. GeoLibre covers the web and mobile, and in time stops shipping its Tauri desktop build. RustGIS keeps its web app as the desktop GIS from a link: a way to try RustGIS without installing it, to open a shared '?project=' link, and the engine behind the 'rustgis.Map' notebook widget. It stops growing towards what GeoLibre does in a browser, such as an SQL engine in an app or a touch layout.
B. Complements by job
Both stay on every platform but aim at different work. GeoLibre is for exploring, sharing and collaborating; RustGIS is for building and maintaining data, print-quality output and repeatable pipelines.
C. One brand, two editions
Keep both codebases but present them as one product: GeoLibre on the web and mobile, and a native desktop edition that is RustGIS. They would share one project format and one plugin registry.
D. GeoLibre matures, RustGIS carries new development
GeoLibre deliberately moves into a stable phase: fewer new features, more reliability, more maintainers, and the marketplace finished. New development happens in RustGIS.
Not choosing, and mixing
If we don't choose, both projects keep pursuing a full GIS independently, with parity as a guide. That costs nothing up front but means building the same features twice with the same few maintainers, and the choice for users stays unclear.
The directions also overlap. A and C are the same split with or without one brand, and D pairs with either. A could be part of a path that leads to C. Whatever we choose, RustGIS's desktop users mostly come from QGIS and ArcGIS Pro, so each direction should also answer why someone would pick RustGIS over other desktop clients.
My stance
Personally, I lean towards a soft mix of A & D. There's no reason to shift from a focus on parity to a hard split in functions overnight, but I would suggest focusing on stability, breadth of interoperability, and maintenance in GeoLibre, focusing the scope of rapid development in RustGIS on depth in desktop and agentic/scripting uses, and revisiting the subject in 6-12 months to see how things have developed.
Questions
All reactions