Geodata Needs a Memory: Why Historization and Versioning Are Foundational to Modern GIS
A GIS shows the current state – and usually only that. But geodata never stands still: a pipeline is rerouted, a foundation is refurbished, a planning status is advanced, an incorrectly captured attribute is corrected. The moment someone asks “What did this look like two years ago?” or “Who made this change, and when?”, many systems run out of answers. The usual workarounds – backups, copied layers, saved interim states – do not answer the question at the object level and become unwieldy over time.
What historization and versioning actually mean
The two terms are often mentioned in the same breath, yet they mean different things. Versioning records that an object has several successive states – each change creates a new version instead of overwriting the old one. Historization makes those states queryable along the time axis: you can jump to any date and see the data as it stood back then. Together they turn a static snapshot into a traceable history.
It is not the layer that matters, but the individual object
The decisive point in practice: an auditor does not want to see the history of an entire dataset, but that of a single object – this foundation, this pipeline, this parcel. A sound model has to be built for exactly that. Every feature carries its own story: with geometry, attributes and metadata such as “created on/by” and “modified on/by”. Corrections overwrite nothing; they create a new, immutable version. Every state remains exportable in its own right – complete and audit-proof.
Why this is a foundation, not a nicety
For critical-infrastructure operators, network documentation and public administration, traceability is not optional. Audits demand a provable history of individual objects. Asset data must be maintained consistently over years. And in spatial planning, planning statuses are versioned by nature – from working draft to legally binding plan. Anyone who takes the geodata lifecycle seriously has to think about its time axis too: from capture in the field, through maintenance at the desktop, to long-term accountability.
How we are implementing it
This is exactly where we come in – bringing the principle to two concrete points in the lifecycle in the fourth quarter of 2026.
In MoversSurvey, field work already becomes part of a complete object history: when a field worker corrects an attribute or a geometry on site, a clean new version is created – instead of a silent overwrite. Every survey in the field slots into the traceable history of the object.
As a QGIS solution, we anchor historization and versioning directly in the database – queryable in the familiar QGIS environment, without domain users needing special knowledge of how the data is stored: jump to a point in time, open an object’s previous version, trace changes. Capture in the field and history in the database mesh seamlessly.
At a glance: Historization & Versioning
Goal: object-level, audit-proof traceability across the entire geodata lifecycle
Principle: a new version instead of overwriting – every state is preserved
Core functions: view previous versions · jump to a point in time · change metadata
Where: as a QGIS solution and in MoversSurvey · in progress for Q4 2026
