How can you use TerraLab AI Agent in QGIS, and can you really trust it with actual geographic analyses? Through 32 practical tests conducted with QGIS 4.2, this article evaluates the capabilities of this artificial intelligence agent: data exploration, spatial processing, cartography, PostGIS queries and GIS workflow automation. The numerical results were manually checked, providing a practical assessment of the possibilities, performance and limitations of AI in QGIS.
TerraLab AI Agent: 32 Tests of an AI Agent in QGIS 4.2
Artificial intelligence assistants are gradually finding their way into GIS software. Beyond simple question-and-answer interactions, some agents can explore project data, search for data sources, run geospatial processing operations, query a PostGIS database and create output layers.
But what can we actually entrust to them? Are the results correct? Does the agent choose the right data and processing methods? And how much verification is still required from an experienced user?
To answer these questions, I carried out a series of 32 tests of the TerraLab AI Agent plugin in QGIS 4.2, using practical examples involving spatial analysis, data management and cartography.
The aim was not simply to check whether the agent could execute commands, but also to assess the quality of its results, how it handles errors, its ability to document the operations performed, and the influence of the instructions it receives.
TerraLab AI Agent is part of a broader development in AI-powered tools integrated into QGIS. I previously reviewed the various solutions available in my article, AI Assistants Available in QGIS. This new evaluation builds on that overview.
1. An AI Agent Integrated into GIS Workflows
An AI agent designed for QGIS differs from a conventional conversational assistant because it can interact directly with a geographic working environment.
Depending on the available tools and permissions, it can:
- inspect layers and their attributes;
- search for and load data;
- perform selections and extractions;
- calculate statistics and areas;
- run spatial processing operations;
- query spatial databases;
- create output layers;
- prepare cartographic representations.
These capabilities change the way users interact with a GIS. Instead of building every processing step themselves, users can describe their objectives in natural language.
However, a request expressed in natural language is not necessarily a complete specification. Terms may be ambiguous, the available data sources may not be the ones the user has in mind, and a visually convincing result does not guarantee that the processing method is appropriate for the question being asked.
That is why these tests focused as much on the operations performed as on the results themselves.
2. Discovering TerraLab AI Agent
To discover the plugin, its interface and how it works, I recommend this introductory video by Hans van der Kwast:
The video is very clear and provides a quick understanding of how to use the plugin. It is an excellent practical introduction and saves me from having to describe its interface and features in detail here.
This allows me to focus the rest of the article on what matters most: an independent evaluation based on 32 tests conducted in QGIS 4.2, with manual verification of the numerical results.
3. Test Methodology
The 32 tests covered several categories of operations:
- data exploration and attribute statistics;
- area and density calculations;
- creation and improvement of map layouts;
- external data discovery;
- spatial analysis using cadastral and urban planning data;
- access to PostGIS and execution of SQL queries;
- data quality checks;
- comparison of different ways of phrasing the same prompt.
The datasets included municipal layers for the Mulhouse urban area, population data, pharmacies from OpenStreetMap, cadastral parcels and urban planning zones.
All numerical results produced during the tests were manually checked and found to be correct. Some operations were also subjected to additional reproducibility checks, including comparisons between QGIS and PostGIS.
This validation does not mean that every aspect of the work can automatically be trusted. Numerical accuracy, methodological relevance, data provenance and cartographic quality are separate criteria.
4. An Experimental Dossier for Reviewing and Reproducing the Tests
To make this evaluation as transparent as possible, I am providing a PDF dossier documenting all 32 tests.
For each test, the document includes the prompt used, a screenshot of the agent’s execution, a screenshot of the QGIS project showing the result, and the textual report produced by the plugin. Observations from the manual validation of numerical results are also documented.
Important: The English version of this dossier is not a translation of the original French PDF. All 32 tests were run again from scratch, using the English versions of both QGIS and TerraLab AI Agent. The prompts were also submitted in English. This means that the screenshots, execution sequences and results document actual test runs in the English-language environment, rather than translated reproductions of the French tests. Some results and processing steps may therefore differ between the two versions.
I am also providing the two layers from the initial project, allowing readers who wish to do so to repeat the tests in their own QGIS environment.
This material goes beyond a simple presentation of the plugin’s features: readers can examine the instructions, follow the operations shown in the screenshots, review the results and, where the necessary technical requirements are met, repeat the procedures themselves.
Full reproduction may require Internet access, an appropriately configured environment and, for some tests, a connection to a database or to the services used. The reproduction requirements are specified in the dossier.
Documents and data:
Download the initial project and its two layers
Download the PDF dossier containing all 32 tests
5. Data Exploration and Statistics
The first tests focused on a municipal layer covering the Mulhouse urban area.
The agent began by inspecting the layer structure, identifying the available fields and taking into account a population filter. Using this data, it calculated statistics, extracted municipalities exceeding a population threshold and created a field to store areas in hectares.
These are common operations in a GIS project, but the sequence is revealing. The agent must understand the layer structure, choose the appropriate fields, apply a criterion and produce a usable result.
The tests also covered population density calculations. Density was calculated by dividing the population by the area of each municipality, measured using a geodesic method.
The agent then produced thematic maps and map layouts comparing total population and population density.
Correct Results and Cartography That Can Be Improved Through Iteration
The numerical results were successfully validated. However, the initial map layouts had a few shortcomings, including insufficient contrast for some labels, elements of the legend that could be improved, and information that needed clarification regarding units and data year.
I then asked the agent to improve its cartographic outputs in response to these observations. It made changes to the layouts, particularly to the presentation of titles, units and legends.
This illustrates an interesting aspect of using an AI agent in QGIS: work can proceed through successive iterations. The user reviews the result, identifies areas for improvement and provides further instructions, which the agent translates into changes to the project.
Cartographic quality therefore does not depend solely on the first response. It can be improved through dialogue, without the user necessarily having to make every change manually in the QGIS interface. However, it remains important to check that the changes actually meet the map’s readability and communication requirements.
6. Error Handling and Processing Sequences
Another test involved requesting a statistic for a field that did not exist in the layer.
The agent did not invent a value. It reported the problem and suggested using available numeric fields instead.
A further test combined a valid operation with an invalid request. The agent performed the calculation that was possible, then stopped at the step that could not be executed correctly.
This behaviour is important: a GIS agent must not only know how to perform an operation, but also recognise situations in which the available data do not allow it to fulfil the request.
These two tests are nevertheless specific cases. They are not sufficient to establish that the agent will handle every possible error correctly, particularly geometry errors, unsuitable coordinate reference systems or ambiguous interpretations of spatial criteria.
7. Data Discovery: An Example Using OpenStreetMap
The next tests focused on finding pharmacies in the Mulhouse urban area.
The agent searched OpenStreetMap data, created a point layer containing 71 pharmacies and retained various descriptive attributes: name, address, opening hours, telephone number, website and accessibility information, where available.
It then counted the pharmacies in each municipality. The result included all 39 municipalities in the municipal layer, 16 of which had no pharmacy recorded in the data used.
This example illustrates an important advantage of agents integrated into GIS software: they can combine data discovery, data loading and subsequent analysis in a single workflow.
However, it is important to distinguish the date on which the data were extracted from the date on which each OpenStreetMap object was last modified. A recent extraction does not guarantee that all information is up to date or complete.
The quality of the analysis therefore also depends on the source’s coverage and currency.
8. Cadastral Analysis and Urban Zoning
The most extensive part of the tests concerned the Mulhouse cadastral data and the US1 and US4 urban zoning areas.
The aim was to identify large cadastral parcels intersecting specific urban zoning areas, then verify the results and compare different calculation methods.
8.1. Identifying the Town Hall Parcel
The agent searched for the cadastral parcel corresponding to the address of Mulhouse Town Hall.
It produced a layer containing a parcel identified by cadastral reference 68224000KO0140, with a reported cadastral area of 9,147 m² and an urban zoning designation of US4.
The geometric analysis returned a geodesic area of approximately 9,148.85 m².
The difference between these two values is small. Nevertheless, it illustrates that the cadastral area and the area calculated from the geometry are not necessarily identical.
The agent also examined the overlap with the US4 zone. This geometric check does not, of course, replace consultation of the applicable planning documents to determine the regulations in force.
8.2. Checking Cadastral Data Quality
Another series of tests focused on the 22,828 cadastral parcels in Mulhouse loaded into QGIS.
The checks covered:
- the presence of null or empty geometries;
- geometry validity;
- the attributes required to identify parcels;
- possible duplicates based on cadastral identifiers;
- missing or null cadastral areas;
- cadastral area statistics.
The checks identified one missing cadastral area value, with no null, empty or invalid geometries in the dataset examined. No duplicates were detected using the cadastral key selected for the check.
The agent then extracted parcels with a cadastral area greater than or equal to 10,000 m². The result contained 230 parcels, with a total cadastral area of 6,579,796 m².
These tests show that the agent can handle a relatively long workflow, from data inspection through to the production of a subset for further analysis.
9. Intersecting Cadastral Parcels with US1 Zones
The next step was to identify large parcels intersecting a US1 zone in Mulhouse.
The criteria were as follows:
- cadastral area greater than or equal to 10,000 m²;
- intersection with at least one US1 zone;
- partial intersection accepted: the parcel did not have to be entirely within the zone.
The result was 23 parcels, with a total cadastral area of 866,775 m², or 86.6775 hectares.
It is important to understand what this total represents. It is the cadastral area of the 23 parcels as a whole, not the combined area of the portions located within US1 zones.
This distinction is essential in any analysis combining cadastral parcels and urban zoning.
The selection, intersection and area calculation operations used in these tests are standard GIS processes. To explore these techniques further, you can also refer to my other tutorials on spatial processing with QGIS, such as QGIS: Running an SQL Query from a Layer’s Context Menu.
9.1. Calculating the Areas Actually Located within US1 Zones
A further test calculated the area of each parcel located within the US1 zones.
To do this, the six selected US1 zones were merged, and their intersection with each of the 23 parcels was calculated. The intersection areas were measured geodesically.
The total intersection area was approximately 334,818.95 m², or 33.48 hectares.
This result is very different from the total cadastral area of 866,775 m². It represents a different measurement: the geometric area covered by US1 zoning within the selected parcels.
Some parcels intersected the zone over only a very small area. Five intersections measured less than one square metre. These cases deserve particular attention, as such small areas may correspond to very limited geometric overlaps or differences in boundary delineation between datasets.
It is important to report these cases rather than automatically remove them. How they should be handled depends on the purpose of the study and the required level of accuracy.
9.2. Verifying the Results with PostGIS
To check the reproducibility of the calculations, a second processing workflow was run in PostGIS using the data imported into the database.
The intersection area results agreed with those obtained in QGIS to within 0.001 m².
| Parcel | AI Agent area (m²) | PostGIS area (m²) | Difference |
|---|---|---|---|
| LT 23 | 82,938.63 | 82,938.630895 | Less than 0.001 m² |
| LS 44 | 43,405.59 | 43,405.593682 | Less than 0.001 m² |
| IN 120 | 38,584.92 | 38,584.916023 | Less than 0.001 m² |
| KC 97 | 6,992.67 | 6,992.671316 | Less than 0.001 m² |
| LV 96 | 403.57 | 403.564706 | Less than 0.001 m² |
| LT 2 | 0.52 | 0.521420 | Less than 0.001 m² |
| LP 32 | 0.21 | 0.205157 | Less than 0.001 m² |
| ME 84 | 0.06 | 0.060270 | Less than 0.001 m² |
This agreement increases confidence in the results for this case study. It does not constitute a fully independent validation in the strict sense, since the two environments may share geometric libraries and calculation conventions. Nevertheless, it is a useful additional check.
This example illustrates a good practice: when a result is important, it is better not to rely solely on the report provided by the agent. The calculation can be reproduced, the criteria checked and the resulting values compared.
Using PostGIS makes it possible here to reproduce the spatial operations directly in the database. If you would like to explore this approach further, you can also consult my tutorials on PostgreSQL and PostGIS, particularly those covering spatial queries and geometric functions.
10. Three Ways of Phrasing the Same Prompt
The final tests focused on a seemingly simple question:
Which large parcels in Mulhouse are located within US1 zones?
This request can be phrased in several ways. However, the wording does not necessarily specify all the criteria required for reproducible processing.
10.1. The Minimal Prompt
The first version was:
Find the large parcels in Mulhouse within US1 zones.
The agent searched for cadastral data in its catalogue, loaded 230 features and created an output layer containing 23 parcels.
It indicated that some parcels might only be partially covered by US1 zoning.
The numerical result was correct. However, the request did not explicitly specify the threshold defining a large parcel, which cadastral data source should be preferred, or what checks should be performed.
10.2. The Intermediate Prompt
The second version made the area threshold and spatial criterion explicit:
Select parcels with a cadastral area greater than or equal to 10,000 m² that intersect a US1 zone in Mulhouse. Report the number of parcels and the sum of their cadastral areas.
This time, the agent explored the available database connections, loaded all 22,828 parcels from PostGIS and used SQL queries and Python code.
It identified the same 23 parcels and calculated a total cadastral area of 866,775 m².
The result was identical, but the technical workflow differed from that of the first test.
10.3. The Detailed Prompt
The third version explicitly requested that the agent inspect the available data sources, specify the selection criteria, create a new layer without modifying the source data, check the results and document any limitations.
The agent produced a GeoPackage layer containing the 23 parcels. It also reported that one source parcel with a missing cadastral area could not be assessed, that the licences for the PostGIS tables were not specified, and that the area actually located within US1 zones had not been calculated as part of this workflow.
10.4. What Does This Comparison Tell Us?
All three tests produced the same number of parcels. The two more explicit prompts also returned the same total cadastral area.
The main differences concerned the technical workflow and the resulting report:
- the minimal prompt led to a search in the TerraLab catalogue;
- the intermediate prompt led to an exploration of PostGIS and the use of SQL and Python;
- the detailed prompt explicitly requested checks and documentation of limitations.
Comparison of the Three Tests
| Criterion | Minimal prompt | Intermediate prompt | Detailed prompt |
|---|---|---|---|
| Selected parcels | 23 | 23 | 23 |
| Total cadastral area | Not provided | 866,775 m² | 866,775 m² |
| Data discovery | TerraLab catalogue | PostGIS database | PostGIS database |
| Output layer | Yes | Selection in the cadastral layer | Exported GeoPackage |
| Checks explicitly reported | Limited detail | Numerical result | Identifiers, threshold and intersections |
| Limitations reported | Partial intersection | Areas of entire parcels | Missing cadastral area, unknown dataset date and licences |
This experiment does not demonstrate that a more detailed prompt will always produce a more accurate result. Rather, it shows that more precise instructions make it possible to express the expected criteria more clearly and request a more complete account of the work performed.
When comparing different prompt formulations, it is also important to start from the same initial project and avoid reusing the results of a previous test. Otherwise, the experiment also measures the agent’s ability to retain and reuse the conversation context.
11. Limitations to Keep in Mind
The 32 tests demonstrated some interesting capabilities, but several points deserve particular attention.
Data Provenance
The agent can search for and load data sources, but the exact dataset edition, update date or licence is not always available in its report.
This information should be verified whenever the output is intended for professional use or public distribution.
The Difference Between a Result and Its Verification
A report may state that a check has been performed. Ideally, it should be possible to identify the criterion applied and, where necessary, reproduce the verification.
In this series of tests, the numerical results were manually validated. This should not be confused with a general guarantee that the agent will always be reliable in every situation.
Cartographic Quality
The agent can produce an initial map or layout, but choices of representation, label readability, legend design and documentation may still require adjustments.
Domain-Specific Interpretation
A correctly executed geometric operation does not necessarily answer every domain-specific question.
A parcel that intersects a zoning area is not necessarily entirely located within that zone. Similarly, a geometric overlay alone is not sufficient to establish the planning regulations applicable to a parcel.
The quality of the analysis therefore still depends on how the problem is defined and how the results are interpreted.
12. Conclusion: A Capable Assistant, Not a Replacement for GIS Expertise
These 32 tests show that TerraLab AI Agent can handle a significant range of operations in QGIS: data exploration, statistics, spatial processing, data discovery, SQL queries, layer creation and cartographic production.
The numerical results obtained during the tests were manually validated. The comparison between QGIS and PostGIS for calculating US1 intersections also confirmed the reproducibility of the results in this specific case.
The value of the agent therefore lies not only in its ability to produce a response in natural language. It can perform several technical operations in sequence and help speed up GIS workflows.
However, automation does not remove the fundamental requirements of geomatics: data quality, appropriate method selection, consistency of coordinate reference systems, source traceability and interpretation of results.
The user still has an essential role in defining the criteria, checking the operations performed and validating the relevance of the results for the intended purpose.
The best way to use an AI agent in QGIS is therefore not to delegate an analysis blindly, but to entrust it with part of the work while retaining control over the methodology and the results.
This article is based on a series of 32 tests conducted with QGIS 4.2. The evaluation covers the operations observed and the results checked as part of these tests; it does not constitute a general guarantee of performance across all GIS projects.
Transparency statement: This evaluation was conducted as part of a paid engagement agreed with TerraLab. The observations and conclusions presented here are based on the tests performed and their validation, and are not guaranteed or endorsed by the provider.
Resource: TerraLab AI Agent
