Digitising Historical Maps: Testing AI-Assisted Contour Tracing in QGIS
Can an AI-assisted QGIS plugin actually speed up contour digitising, or does it just move the work around? We tested it on a small sand mine in Poland, comparing the present-day land surface with a survey from the first half of the 20th century of the same ground.
Digitising historical topographic maps is a familiar task for many GIS analysts. Tracing contour lines by hand from a scanned map can be slow, repetitive, and easy to get subtly wrong. A QGIS plugin promises to automate the tracing step using computer vision and, increasingly, AI assistance. ArchaeoTrace is one of them, and we used it to rebuild the terrain history of a small sand-mining site in Poland across roughly a century.
What ArchaeoTrace actually does
ArchaeoTrace is a QGIS plugin built for pulling vector lines out of scanned topographic maps, designed primarily for archaeological and historical cartography. It bundles several tracing methods rather than a single algorithm. Having several tracing methods matters because different scans respond better to different approaches.
- Ink Centerline, run at three scales (9, 15 and 31 pixels), follows a drawn line and stays on its centre.
- Live-Wire, a bounded, direction-aware path tool (320px reach) that snaps to the strongest nearby edge as you sketch.
- A cursor-to-path blend slider (0-100%) lets the operator decide how much to trust the automated trace versus their own hand movement, rather than accepting an all-or-nothing result.
- An optional Smart Recovery mode calls a lightweight segmentation model (EfficientSAM-Ti) to help bridge gaps where a contour line is faint or interrupted on the scan.
- Freehand drawing and a set of legacy and advanced methods (LSD, HED, MobileSAM, SAM ViT-B, Canny) are available for maps where none of the above behave well.
- Traced lines can carry elevation attributes and spot heights, and the plugin can generate an experimental linear-TIN DEM plus hillshade directly from the digitised contours.
All of this runs locally, with no data sent to a remote server for inference. The plugin’s baseline install targets QGIS 3.22 and Python 3.8 with no additional pip packages; the optional AI-assisted methods need a Python 3.10+ environment with extra dependencies installed, which is worth checking.
The case study: a sand mine in Poland, three time periods
To see what the plugin is actually good for, we picked a small sand-mining site. We reconstructed its surface at three stages – before mining, during extraction, and today – across roughly a century.
Before mining: the 1929-39 baseline. The earliest source is sheet P42 S32 H (also catalogued as 4232 H), part of the WIG (Wojskowy Instytut Geograficzny) 1:25 000 series, Mapa Szczegółowa Polski, surveyed in the interwar period. Sheets in this series were compiled from a mix of fresh Polish fieldwork and older base survey data in less-mapped areas, which is why some of the underlying linework on this sheet still carries Cyrillic place names from an earlier Imperial Russian survey.
Running ArchaeoTrace over this scan produced a set of digitised contours, which we then used to build a linear-TIN DEM of the ground before mining began.
Mid-century: when mining began. A Polish Geoportal topographic map from the 1960s-80s shows the same area once sand extraction was underway. Digitising this sheet and rebuilding a DEM from it gives a second surface, roughly midway through the site’s working life.
Today: satellite imagery and a modern LiDAR DEM. For the present-day surface, we didn’t need to digitise anything by hand. A Google satellite orthophoto shows the pit and surrounding land directly, while a 1-metre LiDAR-derived DEM provides an independent elevation model for checking the historical reconstructions.
Drag the slider: pick any two time slices
The interactive tool below holds all three DEMs on the same colour ramp: pre-mining (1929-39), mid-century (1960s-80s, once extraction was under way), and today. Use the dropdowns to choose which two to compare, then drag the divider. The depression left by extraction is unmistakable once any two surfaces sit side by side.
| Period | Source | Elevation model |
|---|---|---|
| 1929-39 | WIG 1:25 000 sheet P42 S32 H (4232 H) | Linear-TIN DEM from digitised contours |
| 1960s-80s | Geoportal topographic map | Linear-TIN DEM from digitised contours |
| Present day | Google satellite orthophoto; Geoportal 1 m LiDAR | LiDAR-derived DEM |
Where it struggles
None of the tracing methods worked equally well on both historical sheets straight out of the box. The oldest scan, with its finer, more irregular hand-drawn contour lines, needed a different combination of scale and blend settings than the cleaner, more mechanically-drawn mid-century Geoportal sheet. There is no single setting that suits every map, and the plugin does not pretend otherwise.
- New users have to experiment across the available algorithms (and the multi-scale settings within Ink Centerline) to find what works for their specific map; there is no shortcut to that trial-and-error step.
- The optional AI-assisted methods bring real dependency weight: a Python 3.10+ environment and extra packages beyond QGIS’s own baseline, which is friction for anyone trying to reproduce results on a locked-down institutional machine.
- The plugin’s own documentation is candid about this: as it puts it, “terrain outputs are reviewable hypotheses rather than archaeological ground truth.” That line is worth taking at face value rather than as boilerplate caution.
The automated traces we reviewed still required correction, whether that meant nudging a vertex back onto a contour it had slid off, or closing a gap the software had left where the historical ink had faded.
The verdict
ArchaeoTrace is a useful tool for speeding up the slow part of digitising old maps. It reduced the time needed to produce a first-pass set of contour vectors. For anyone rebuilding terrain history from archival maps as a recurring task rather than a one-off, that time saving adds up fast.
Manual review and correction are essential before relying on the resulting DEM for anything consequential. Automated tracing shaves hours off the first draft. It does not replace the second pair of eyes.
Sources
- ArchaeoTrace plugin (QGIS), GitHub: AI-Vectorizer-for-Archaeology README
- WIG 1:25 000 Mapa Szczegółowa Polski, sheet P42 S32 H (4232 H), 1929-39
- Geoportal.gov.pl: historical topographic map series and 1-metre LiDAR DEM
- Google satellite imagery
Did you like this post? Read more and subscribe to our monthly newsletter!
#Fun
Next article
Google has released the most substantial public evaluation yet of its experimental Geospatial Reasoning Agent. The headline is not simply that Gemini can operate geospatial tools. It is that Google has started to measure what happens when a language model is given domain-specific data, specialist models, explicit planning and a workspace for processing planetary-scale information.
The results support a growing belief across GeoAI: access to the right tools matters more than fluent conversation. They also reveal why geospatial agents are not ready to replace expert judgment.
From chatbot to analytical system
The agent links Gemini with 23 skills and 62 tools, according to Google’s technical report. These include Google Earth Engine, Maps Platform and Data Commons, alongside Earth AI capabilities for weather, floods, population dynamics and satellite embeddings.
Before execution, the full system creates a plan. It then processes large datasets in a separate spatial workspace instead of forcing coordinates, rasters and intermediate results into the model’s context window. Google says users can inspect the plan and sources, and can add private CSV, GeoJSON or cloud-table data.
That architecture is more consequential than the chat interface. It treats the language model as an orchestrator of spatial methods, rather than pretending the model already contains a GIS.
What the benchmarks show
Google compared four configurations: a standalone Gemini model, Gemini with basic search and maps tools, Gemini with Earth AI tools but no initial plan, and the complete agent.
On GeoExpertQueries, which contains open-ended tasks created by geospatial specialists, the full agent using Gemini 3.8 Flash scored 62.7. The tools-only configuration scored 52, while the basic baseline was close to 3. On GeoKTools, a more deterministic test requiring one to four tools, the full agent reached 85.9, versus 41 for the strongest baseline. Google also reports scores above 80 on the community-developed CBGB coding benchmark, where the baselines remained below 20.
Those are large gains. They suggest specialist capabilities are doing most of the work, with explicit planning adding value on longer, less structured analyses. Interestingly, the less expensive Gemini 3.8 Flash configuration outperformed Gemini 3.1 Pro across all four reported benchmarks. Google estimates token inference costs at about $0.20 per GeoExpertQueries task for Flash, excluding external data and computation.
The evaluation also deserves credit for exposing a saturated benchmark. A standalone model scored 93.6 on UnivEARTH, probably because source material and answers were already available online. That makes the benchmark a weak discriminator of real spatial reasoning.
The most important limitation
The 62.7 score is easy to overread. GeoExpertQueries contains 101 tasks, with 76 held out for testing. Its automatic evaluator compares the agent’s trace with expert-authored workflows. It explicitly does not establish whether the final numbers, arithmetic or conclusions are correct, and it does not penalize missing maps or charts.
In other words, the benchmark asks whether the agent followed a credible analytical route, not whether it arrived safely. Google itself describes the outputs as strong first drafts for expert review, not authoritative answers.
That distinction is critical in public health, disaster response and infrastructure planning. A plausible workflow can still use the wrong boundary, date, denominator or spatial resolution. Releasing only the development splits of the two new benchmarks also limits independent reproduction of the headline results.
A stronger competitive signal
The broader market is moving in the same direction. Esri is developing agents built around authoritative ArcGIS data and controlled workflows. CARTO has exposed platform capabilities through the Model Context Protocol. Academic projects such as GeoNatureAgent are testing open, fixed-tool environments with strict pass-or-fail checks.
Google’s advantage is the breadth of its proprietary planetary data and models. Its disadvantage is that many organizations will not want a single vendor to mediate their data, reasoning and infrastructure. Governance, reproducibility and portability may matter as much as benchmark performance.
Public discussion has so far focused more on access to the experimental Ask Google Earth experience and agent-to-agent API than on validation. That imbalance is telling. The most urgent question is not whether an agent can produce an impressive map quickly. It is whether another analyst can reproduce the result, inspect every assumption and know when the system is wrong.
Google has not solved that problem. But by publishing a comparative evaluation and stating the limits clearly, it has given the geospatial industry a more useful starting point than another polished demo.
Disclosure of claims: Benchmark values, partner examples and cost estimates are reported by Google and have not been independently reproduced for this article. Benchmark design details are confirmed in Google’s published technical report. Experimental access remains limited.
How do you like this article? Read more and subscribe to our monthly newsletter!
