QGIS Four Point Oh and the Question of When to Ask the Robot

Norrköping at the Bottom of the Window

On the sixth of March, two thousand and twenty-six, the QGIS project released its first major version in nearly eight years. The codename, picked as is the tradition after the place that hosted the most recent QGIS contributors meeting, is Norrköping. So when you check the version string at the bottom of the QGIS window now, it does not just say four point oh. It says four point oh, dash, Norrköping. There is a small Swedish industrial city baked into the metadata of every QGIS install on Earth.

That fact will not improve your map of Åre kommun by a single pixel. But it is a nice small detail for a Swede sitting in a hotel room in Mörkret with the program open.

The previous major version, three point oh, was codenamed Girona, after the Catalonian town. That was February of two thousand and eighteen. Between Girona and Norrköping, eight years passed. In software terms, that is forever. The project released, in those eight years, more than forty minor versions. Three point oh became three point two, which became three point four, which became all the way to three point forty-four, which is the long term release that most professional users are still running today. Each of those minor versions added features, fixed bugs, and kept the API mostly compatible.

So what changed on the sixth of March to justify cranking the major version up by one. The answer is mostly invisible, mostly correct, and mostly very important. The answer is Qt six.

The Qt Six Migration in One Sentence

QGIS, as the previous episode mentioned, is built on top of a cross platform toolkit called Qt. Qt is the engine that draws every menu, every button, every dialog, every tab. For most of QGIS's life, the engine in use has been Qt five. Qt five is a serious piece of software with about a decade of maturity behind it. It has also, slowly, been replaced upstream by Qt six. The Qt company has been pushing the migration for years. Most downstream Qt-based applications have made the jump. QGIS, being large and complicated and having a huge community of plugins to consider, took its time.

The four point oh release is the Qt six release. That is the whole headline. Everything else is a consequence.

The visible consequence for you, sitting in front of QGIS tomorrow, is mostly nothing. The team's stated goal was that existing users should hardly notice. The menus are in the same places. The buttons are the same shapes. The workflows you know still work. If anything, things feel a touch snappier on a modern Mac, because Qt six is better at making use of newer rendering APIs.

The invisible consequence is enormous. Qt six unlocks future development. It removes a slow leak of technical debt the project has been carrying. It improves performance, security, and access to modern libraries. It is the kind of move where, if it goes well, no one congratulates you. If it goes badly, everyone notices and complains.

It seems to have gone well.

What You Actually See on Day One

There are a hundred or so new user-facing features in four point oh. Most of them are small. A few will matter to you. Here are the ones worth noticing on day one.

The welcome page when you launch QGIS has been redesigned. It is now extensible, which means plugins can add content to it. For now, this means a tidier recent projects list and some better project thumbnails. Over time, it will probably mean that themes and learning resources get surfaced here as well.

User-defined menus and toolbars are new. You can right-click in the menu bar and start building your own menu out of any tools and actions in QGIS. If you find yourself clicking through the same six things every time you start work on the gruvor centerfold, you can make a menu called Gruvor with those six things in a row. This is the kind of feature that sounds small until you start using it, at which point it becomes hard to live without.

Themes have moved out of the core application and into plugins. The old Night Mapping and Blend of Gray themes are no longer shipped by default. If you want a dark interface, the plugin manager now has a Themes section where you install the look you want. This is a small annoyance the first time you upgrade and a small relief later, because it means new themes ship independently of new QGIS releases.

The attribute table has a small but lovely change. Double click an attribute table row, and QGIS now selects that feature and zooms to it in the map canvas. Before, you had to click select, then click zoom, in two separate operations. This will save you about a hundred mouse movements per gruvor session, and you will only notice when you accidentally open the old version somewhere and wonder why the table is broken.

The Python Console as the Third Door

There are three ways into QGIS. The first is the graphical interface, the menus and buttons and tabs you have been using. The second is external Python scripts, which is what your build script for the gruvor project does. The third is the Python console, and most people never open it.

You should open it. Plugins, then Python Console. Or control alt P. There is a small window with a prompt waiting for you. This is a live Python interpreter running inside QGIS, with full access to every object the program holds in memory. Whatever map is open right now, whatever layers are loaded, whatever symbology is applied, the console can see all of it and change all of it.

This matters because the console is the fastest possible feedback loop in QGIS. You can try a snippet, see the result, adjust, try again, in seconds. It is also the place where any conversation with an AI assistant about QGIS ends up landing, because the AI is going to suggest Python, and the console is where Python lives.

There is a small editor inside the console as well. Click the Show Editor button. You get a multi-line text area where you can write, save, and reload longer scripts without leaving QGIS. For anything more than a one-liner, use the editor side. For exploration, use the prompt.

One trick. Type underscore cookbook at the prompt and press enter. The console opens the PyQGIS Cookbook documentation, which is the official cheat sheet for almost everything you might want to do programmatically. It is the best place to look up syntax when you have forgotten it.

The Holy Trinity of PyQGIS Objects

When you start writing PyQGIS, three objects come up over and over. Knowing them by name is half the battle.

The first is iface. This is the interface to the running QGIS application. It knows about the map canvas, the active layer, the menus, the message bar, all the windowy things. If you want to do something to the visible state of QGIS, you almost always start with iface. Type iface dot in the console and let autocomplete show you the surface. The most commonly used one is iface dot activeLayer, which returns whichever layer is currently highlighted in the layers panel.

The second is QgsProject dot instance. This is the running project. It knows about every layer, the project coordinate reference system, the project variables, the layouts. If you want to add a layer, remove a layer, save the project, or change the project settings, you go through QgsProject dot instance.

The third is processing dot run. This is the gateway to the entire Processing Toolbox, which is the catalog of about a thousand algorithms QGIS ships with. Buffer, clip, intersect, dissolve, every raster algebra, every vector overlay, every routing algorithm. All of them are callable from Python with one function. You give processing dot run the algorithm name, a dictionary of parameters, and it returns the result. If you can do something via the Processing menu, you can do it via processing dot run.

There are dozens of other Qgs classes you will meet over time. QgsVectorLayer for vector data. QgsRasterLayer for raster. QgsCoordinateReferenceSystem for projections. QgsExpression for the expression engine. QgsLayoutExporter for print layouts. You do not need to learn them all up front. Meet them as the work demands.

Where Claude Code Earns Its Keep

You have three AI surfaces available to you. Claude dot AI in a browser tab, Claude Code in a terminal, and the Python console in QGIS itself. Each is best at different things. Knowing which to reach for is most of the productivity gain.

Claude Code earns its keep when the work is file-shaped. Modifying the build script for the gruvor project to add a hillshade layer with the right symbology. Refactoring the three pipeline scripts so they share a common configuration. Adding error handling around the Lantmäteriet STAC pull. These are tasks where the answer is "open this file, change these lines, save, maybe run a test." Claude Code lives in the file system, can run commands, can see your project structure. It is the obvious tool when the deliverable is committed code.

The pattern that works well is to tell Claude Code what you want at the level of intent, not implementation. Not "add a line at line forty-two that says layer dot setRenderer of QgsHillshadeRenderer." Just "add a hillshade layer under the existing layers, styled so it shows terrain through the marktäcke colors above it." Claude Code figures out the right line, the right syntax, the right multi-step changes.

Claude Code is less useful when you do not yet know what you want. If the question is "how should the centerfold look," that is a cartographic conversation, not a coding conversation. Claude Code will write you code, because that is what it does, but it will not push back on the design.

Claude Code is also less useful when the answer involves clicking somewhere in the QGIS interface. It cannot see your screen. It cannot move your mouse. It can tell you the menu path, but it cannot verify the result. For GUI-shaped tasks, this is the wrong tool.

Where Claude Dot AI Earns Its Keep

Claude dot AI in the browser is the cartographic conversation partner. The strategic conversation. The "I have these twenty layers, what should the visual hierarchy be" conversation. The "this looks wrong, here is a screenshot, what is going on" conversation. The "explain to me why my SWEREF layer is not aligning with my WGS eighty-four layer" conversation.

Three patterns are particularly strong.

First, screenshot-driven debugging. You take a screenshot of the QGIS canvas, paste it into the chat, and describe what you expected to see and what you actually see. The model is good at recognising cartographic problems. Symbology too loud. Labels colliding. Coordinate system mismatch making one layer huge and the other tiny. A scale that does not match the data density. These visual diagnoses are hard for Claude Code, which cannot see the canvas, and easy for Claude dot AI, which can.

Second, planning before doing. Before you write the build script for a new layer type, describe the goal in chat. Ask for an outline. Ask for the gotchas. Sometimes the model will mention a Processing algorithm you did not know existed, or warn you about a coordinate system trap, or suggest a much simpler way involving an existing plugin. Five minutes of planning conversation often saves an hour of coding.

Third, the explainer for an error message. When QGIS throws a PyQGIS exception with a stack trace, paste the whole thing. The model is good at this. Often the actual cause is three frames up from where the error fires, and a human reading the trace would scan past it. The model reads carefully every time.

The pattern to avoid is asking Claude dot AI to remember a long sequence of clicks. The model can describe a workflow, but it has no idea whether your version of QGIS has the same menu in the same place. Verify the click path yourself.

Where the Python Console Beats Both

There is a third option that often beats both AI surfaces. The Python console itself.

If you want to know whether a layer has a certain attribute, do not ask an AI. Open the console, type iface dot activeLayer dot fields dot names, and look at the list. The answer is one line of code away.

If you want to know how many features are in a layer, type iface dot activeLayer dot featureCount. If you want to know the layer's coordinate reference system, type iface dot activeLayer dot crs dot authid. If you want to know how many of those features are selected, type iface dot activeLayer dot selectedFeatureCount.

These are not big code. They are diagnostic queries against the live state of the running program. There is no faster way to get the answer.

The trick that makes the console pleasant is autocomplete. Type the first few letters of a function or property, press Tab, and the console shows you the available completions. This is the moment when PyQGIS starts to feel discoverable rather than memorised. You do not have to know the name of every method. You just need to know the name of the object, and the autocomplete shows you what the object can do.

One pattern that pairs nicely with AI is the Print and Show pattern. Ask Claude dot AI to write you a snippet that prints some diagnostic info about your project. Paste the snippet into the console. Run it. Read the output. Decide what to do next based on what the snippet revealed. This is a tight, fast loop. Much faster than asking the AI to predict the answer.

The Training Data Time Lag

Here is a trap to watch for. Almost all training data for AI models is QGIS three point x. Four point oh just released two months ago. There are gotchas.

PyQt five versus PyQt six imports. In QGIS three, you import from PyQt five. In four, from PyQt six. If you paste old code into the console and get a module not found error, this is almost always the cause.

Some deprecated APIs from three point x have been removed in four point oh. The project documentation warns that not all legacy APIs are guaranteed to survive the four point x series. Older snippets from blog posts and Stack Overflow may simply not run.

The Processing API from QGIS two is officially not supported in four point oh. If you find very old scripts, treat their syntax as suggestive rather than authoritative.

The defensive move is simple. If a snippet does not run, do not assume the AI hallucinated. Check whether the import is PyQt five or PyQt six. Check whether the class name exists in current PyQGIS by typing it in the console and seeing if it autocompletes. Check the official PyQGIS Cookbook for the four point oh version. The cookbook is published as part of the QGIS docs and is the authoritative reference.

If you have the bandwidth, install QGIS three point forty-four long term release alongside four point oh. They can coexist. For production work on the gruvor centerfold, three point forty-four is the safer bet. For exploring new features and the Qt six era, four point oh is the right call.

Plugins, Themes, and the Things That Might Be Broken

The plugin community is the part of QGIS most affected by the Qt six migration. A plugin built for Qt five will not load in QGIS four point oh unless its author has updated the code. The Qt company provides a compatibility shim that helps, and most well-maintained plugins have already been updated, but some have not.

The QGIS plugin repository now marks plugins as either Qt six compatible or not. Before installing, glance at the compatibility tag. If a plugin you depend on is not yet Qt six compatible, that may be a reason to stay on three point forty-four for that workflow.

Two plugins worth knowing about that are already four point oh ready and that will help with the gruvor work.

QuickMapServices gives you one-click access to dozens of background map services. OpenStreetMap, satellite imagery, terrain, all available without configuring anything. For prototyping a centerfold layout, having a quick base map underneath the data layers helps you orient. You do not have to keep it for final print, but it speeds the early decisions.

QGIS Resource Sharing lets you pull in shared style collections, symbol libraries, and SVG icons from public repositories. For a gruvor map, the QGIS Hub has Swedish geological symbology that someone has already done the work of. No need to draw your own triangle from scratch.

A third tool worth flagging is Atlas, except Atlas is not a plugin. It is built into the print layout system. We will cover it in the next episode, because it is genuinely transformative for the centerfold workflow.

A Day with the Mining Database

Tomorrow morning, in the hotel in Mörkret, the most useful first move is probably this. Open QGIS four point oh. Load the existing gruvor project. Open the Python console.

In the console, type. layers equals QgsProject dot instance dot mapLayers. That returns a dictionary of every layer in the project, keyed by layer ID. Look at the names. Confirm what you have.

Then for each interesting layer, ask the console what it knows. The coordinate reference system, the feature count, the field names, the geometry type. Build a mental map of the data, not from the layers panel, but from the actual objects in memory.

Then re-run the build script that has been stale. The one that loads the Lantmäteriet hillshade and marktäcke and kommun boundaries. See what the current state of the project is after the rebuild. Where things have moved. Where the symbology needs to change because there is now a hillshade underneath. Where labels are colliding. Where the print layout needs to be re-tuned.

That is the day. Iteration. Console, edit script, run, look, repeat. Claude Code for the script changes. Claude dot AI for the cartographic decisions. The console for the live diagnostics. Three tools, three different jobs.

The mining engineer in Alaska who started this whole thing has retired. The tool he built has spent twenty-four years getting better at what it does. Tomorrow it will get a tiny bit better still, because someone in a tiny dark town in Dalarna is going to push it through the specific shape of one particular newspaper centerfold, and notice the small things that need adjusting, and adjust them.

That is, in the end, all open source software is. Many people, each pushing the tool through the specific shape of their own particular problem, and noticing what needs adjusting, and adjusting it.

Welcome to your day with QGIS four point oh.