QGIS Expressions

Robert Crowther Feb 2023
Last Modified: Aug 2023

What are expressions?

They are a place offered where a user can type in commands like a programmable interface. I say ‘like a programmable interface’—it is a programmable interface. Except it is partly offered through the GUI/App.

Where to use expressions

A banal answer is ‘Wherever QGIS needs to calculate or format to perform an action’. But I say the answer is banal, because it doesn’t capture what QGIS has enabled. A full commandline is available. Some software with programming interfaces only offers a few configuration options. QGIS goes further than this, much further. The expression interface is heavily coded into the QGIS GUI. So expression handling is offered whenever possible.

This makes the QGIS expressions/programming interface far more potent than most similar offerings. For example, to do a batch clip of all layers, QGIS will need a filepath for the clipped data. For every layer. Typing and modifying filepaths in for every single layer of a fifteen‐layer map project will rapidly become tedious. Not to mention, likely to error. But the ‘batch clip’ operation offers a ‘fill’ option from an expression. Fill every layer filepath with one application of an expression. Sounds good, but the expressions are not easy to handle.

Basics

Some syntax

Far as I know, this interface is Python. In Python single inverted commas can be switched with double inverted commas—both mark a string. However, the QGIS parser clearly has some modifications/customisations,

String

’string’ (not double inverted commas)

value (of say, a field)

”fieldname”

Concatenate string

||

QGIS reference

@INPUT (ampersand for references)

Numbers do not need quoting. Neither do fields, as alternative.

Construction

Especially if you’re not used to this, look at the expression builder commands. The help is not often useful, but the categorisation of what can be done is. The builder commands are annoying, but may give clues and will help avoid mistakes. Believe me, if you think QGIS expression builders are annoying, you should see other coding GUIs.

Expression Display

In expression builders, the result string is shown at the bottom. If the expression fails i.e. will not parse, the parser will mark the failure point with a red underline. The displays are worth looking at, don’t skim them.

Advanced

You can create your own Python functions. Who cares, when it’s not clear how to write an expression for a modifying filepath, or insert a table into a GeoPackage?

Clipping Example

You need to generate a destination for every layer in a project. You would like the resulting layers to be neatly packaged into a GeoPackage. To do this, you need a destination in this form,

ogr:dbname="/targetPath/targetFileName.gpkg" table="targetTableName" geom()

The OGR library is QGIS way of reading writing formats. I don’t know where this form is documented, or why the parser can handle it, or if there alternatives. But the parser can handle it. Anyway, if this text can be generated, it will spare us handwriting fifteen paths, one per layer. Which is tedious. An expression will fill the paths in one sweep.

However, unless you have practised a little, this expression is not easy. To generate the above paths needs an expression like the following. This defines everything as a string that is a simple string, then concatenates the strings with ‘@INPUT’ using the concatenation operator ‘||’,

'ogr:dbname="/targetPath/targetFileName.gpkg"' || ' table="' || @INPUT ||'"geom()'

Further clipping expression example

If you’re new to this, the example of a clipping expression is nightmarish. Yet the example may benefit from further work. For example, if the target directory is the same as the source GeoPackage, the path can be expressed using a builtin variable, like this,

'ogr:dbname="' || @project_folder || 'targetFileName.gpkg"'...

There is more. The resulting layer names will be expressed as whatever @INPUT returns. If a map is clipped a couple of times, QGIS will protect a user from name clashes by adding to layer names. This can quickly give vanishingly long names. If they exist, it may be better to use a layer property as the new table name,

...' table="' || layer_property(@INPUT, "name") || '"geom()'

And so on.

Thoughts

Expressions are a ‘powerful’ feature in QGIS. They can make editing quick. The QGIS expression builder is extended and the parser helpful. Usually, I find this half‐interaction with computer code to be no use at all. What happens is people say“It’s powerful”, because you have the code flexibility and parsing, but what ‘powerful’ means is ‘lousy graphic interface’. So in many programmable interfaces, this is a failure, but not here.

QGIS expressions not only make some kinds of edits quick. They can do edits that would be not practical without them. For example, they could hide all features lower than a given height in a map. Try do that by feature and you may need to do one hundred or more edits on a layer. That said, the power of the language, and the lack of documentation, means it can be a struggle to enable the most basic of actions.

Refs

Video tutoral, good pace, lacks expression info,

https://www.youtube.com/watch?v=YFRy90anJ0M

Older QGIS manual. Too much information (lists of functions), too little information (no syntax),

https://docs.qgis.org/2.8/en/docs/user_manual/working_with_vector/expression.html

Newer QGIS manual improved to a lack,

https://docs.qgis.org/3.22/en/docs/user_manual/expressions/expression.html#the-expression-string-builder