MoversQGISHistory – Geodata History in QGIS
What did the foundation look like on 3 March? In QGIS, you know in two clicks.
MoversQGISHistory is a QGIS plugin that lets planners and reviewers call up the history of individual geo-objects directly in their familiar working environment. They select a feature and see how its geometry and attributes have changed over the planning phase, which aerial survey or field capture a state comes from, and who changed it. Nobody needs any knowledge of Git or database technology to do this.
MoversQGISHistory is a project solution. Data models, data sources and documentation requirements differ from project to project. We therefore set up the plugin and the historisation behind it for your environment in each case, rather than delivering it as a standard product.
In the geodata cycle the plugin supports phase 2, validate and prepare: every state of an object remains traceable before the data feeds into analyses and decisions.
Arrange an initial consultation →
Does this sound familiar?
- In the approval procedure, the authority asks for the planning state from last spring. It can only be reconstructed from old exports and emails.
- An attribute was corrected in the field, and nobody remembers which value applied before or why.
- Every aerial survey produces a new state, but comparing it with the previous one is manual work.
- Versioning tools exist, but they assume familiarity with terms such as commit, branch or check-out. The planners who need the history do not work with them.
Infrastructure projects run for months or years. Every aerial survey, every correction in the field and every extension of the data model creates a new state. Without history at object level, every audit turns into a search.
What you gain from it
- Traceable changes per object. For every feature you see its state at a given date, the origin of the data and who edited it, even across long, planning-intensive periods.
- Operation directly in QGIS. Your team works in its familiar interface and does not have to learn new software or versioning logic.
- Evidence for procedures and audits. The history of an object can be presented in a traceable way.
- Open interfaces. The historised data is also available to other applications via an OGC API, for example web viewers or specialist applications.
- Corrections without data loss. When a field capture is corrected, the previous state is retained and marked as superseded.
How it works
The data comes from aerial surveys, from field capture with MoversSurvey or from deliveries by your planning offices. It is stored in a data lake based on Apache Iceberg. Every state is kept there unchanged, and extensions of the data model only change the metadata, so older states remain readable.
Corrections are created as a new record that refers to its predecessor. This produces a complete chain for every object, which works the same way for aerial surveys, layers and questionnaires.
MoversQGISHistory accesses this history via pygeoapi as an OGC API. The plugin therefore does not need to know how the data is stored, and other applications use the same interface.
Why we developed the plugin ourselves
QGIS already offers pgversion and Kart for versioned geodata, and network operators know similar concepts from Smallworld GIS in asset documentation. These tools assume that GIS specialists edit the data interactively. In our projects the data is mostly generated automatically, and the history is needed above all by planners and reviewers. For this situation there was no suitable way in QGIS.
Where this experience comes from
For the planning office Raumtext we implemented the object-level historisation from which MoversQGISHistory emerged. Raumtext works on the same areas and objects over long planning periods and has to be able to demonstrate in procedures which planning state applied when. These requirements shaped the functions of the plugin: history per object, operation in QGIS without Git knowledge, and access to the history from other applications as well.
Frequently asked questions
Do our users need Git knowledge?
No. The plugin shows the history of an object as a sequence of states with date, origin and editor. Terms such as commit or branch do not appear in the interface.
How does MoversQGISHistory differ from Kart?
Kart applies the Git principle to geodata and comes with its own QGIS plugin. It is well suited when GIS specialists edit data interactively, maintain variants in branches and merge changes. MoversQGISHistory is intended for data that is mostly generated automatically from aerial surveys and field capture, and for users who want to see the history of an object without working with commits and branches.
How does MoversQGISHistory differ from pgversion?
pgversion versions PostGIS tables with check-out and commit and is designed for several editors in QGIS working on the same layers at the same time. The history is kept in the PostgreSQL database. MoversQGISHistory reads the history from a data lake based on Apache Iceberg. Even very large numbers of states are kept there outside the operational database, and changes to the data model leave older states untouched.
Which tool is right for us?
That depends on how your data is generated and how many changes occur. If several people edit the same layers interactively, pgversion or Kart is often the better choice. If the data comes mainly from automated pipelines and the history is needed above all by planners and reviewers, MoversQGISHistory plays to its strengths. We will work this out with you in the initial consultation.
Can we start small?
Yes. Because we adapt MoversQGISHistory for each project, we start with a single layer or a completed project section from your environment. This shows you what the history looks like in your data model before we extend the scope.
How this connects to our other services
The data whose history MoversQGISHistory shows is often captured in the field with MoversSurvey and kept up to date in ongoing operations and data maintenance. If a system change is ahead, for example replacing a legacy system with its own version management, it starts with requirements engineering and migration. For analysis there is Kermit GeoAI.
Further reading
Let's talk about your planning states
Tell us which evidence your procedures require and how you reconstruct old states today. In the initial consultation we will show you MoversQGISHistory using an example from your project context.
Arrange an initial consultation →
Geodata from field to decision – standardised, versioned & critical-infrastructure-ready.
InfoLayer Blog
View all-
How We Tell Whether Your Geodata Will Still Ans...
MovingLayersStandardisation, historisation and the AI Act look like three separate topics. They answer the same question. We bring them together and show why the result is a loop rather than...
How We Tell Whether Your Geodata Will Still Ans...
MovingLayersStandardisation, historisation and the AI Act look like three separate topics. They answer the same question. We bring them together and show why the result is a loop rather than...
-
How we bring AI to the alpine pasture with Virt...
MovingLayers GeoservicesMovingLayers at AAIC 2026 in Vienna: Virtual Shepherd brings AI from research to the alpine pasture, with generative AI against data scarcity, explainable anomaly detection and LoRaWAN connectivity.
How we bring AI to the alpine pasture with Virt...
MovingLayers GeoservicesMovingLayers at AAIC 2026 in Vienna: Virtual Shepherd brings AI from research to the alpine pasture, with generative AI against data scarcity, explainable anomaly detection and LoRaWAN connectivity.
-
GIS legacy system replacement for geodata: when...
MovingLayers GeoservicesReplacing a legacy system is first and foremost a matter of timing. How to recognise when a geographic information system is ready to be replaced, why the timing determines the...
GIS legacy system replacement for geodata: when...
MovingLayers GeoservicesReplacing a legacy system is first and foremost a matter of timing. How to recognise when a geographic information system is ready to be replaced, why the timing determines the...