Related Plugins and Tags

QGIS Planet

Adding basemaps to PyQGIS maps

In the previous post, we investigated how to bring QGIS maps into Jupyter notebooks.

Today, we’ll take the next step and add basemaps to our maps. This is trickier than I would have expected. In particular, I was fighting with “invalid” OSM tile layers until I realized that my QGIS application instance somehow lacked the “WMS” provider.

In addition, getting basemaps to work also means that we have to take care of layer and project CRSes and on-the-fly reprojections. So let’s get to work:

from IPython.display import Image
from PyQt5.QtGui import QColor
from PyQt5.QtWidgets import QApplication
from qgis.core import QgsApplication, QgsVectorLayer, QgsProject, QgsRasterLayer, \
    QgsCoordinateReferenceSystem, QgsProviderRegistry, QgsSimpleMarkerSymbolLayerBase
from qgis.gui import QgsMapCanvas

app = QApplication([])
qgs = QgsApplication([], False)
qgs.setPrefixPath(r"C:\temp", True)  # setting a prefix path should enable the WMS provider
canvas = QgsMapCanvas()
project = QgsProject.instance()
map_crs = QgsCoordinateReferenceSystem('EPSG:3857')

print("providers: ", QgsProviderRegistry.instance().providerList())

To add an OSM basemap, we use the xyz tiles option of the WMS provider:

urlWithParams = 'type=xyz&url={z}/{x}/{y}.png&zmax=19&zmin=0&crs=EPSG3857'
rlayer = QgsRasterLayer(urlWithParams, 'OpenStreetMap', 'wms')  
if rlayer.isValid():
    print('invalid layer')

If there are issues with the WMS provider, rlayer.error().summary() should point them out.

With both the vector layer and the basemap ready, we can finally plot the map:


Of course, we can get more creative and style our vector layers:


And to switch to other basemaps, we just need to update the URL accordingly, for example, to load Carto tiles instead:

urlWithParams = 'type=xyz&url={z}/{x}/{y}.png&zmax=19&zmin=0&crs=EPSG3857'
rlayer2 = QgsRasterLayer(urlWithParams, 'Carto', 'wms')  
if rlayer2.isValid():
    print('invalid layer')

You can find the whole notebook at:

QGIS 3D Tiles – thanks to Cesium Ecosystem Grant!

We’ve recently had the opportunity to implement a very exciting feature in QGIS 3.34 — the ability to load and view 3D content in the “Cesium 3D Tiles” format! This was a joint project with our (very talented!) partners at Lutra Consulting, and was made possible thanks to a generous ecosystem grant from the Cesium project.

Before we dive into all the details, let’s take a quick guided tour showcasing how Cesium 3D Tiles work inside QGIS:

What are 3D tiles?

Cesium 3D Tiles are an OGC standard data format where the content from a 3D scene is split up into multiple individual tiles. You can think of them a little like a 3D version of the vector tile format we’ve all come to rely upon. The 3D objects from the scene are stored in a generalized, simplified form for small-scale, “zoomed out” maps, and in more detailed, complex forms for when the map is zoomed in. This allows the scenes to be incredibly detailed, whilst still covering huge geographic regions (including the whole globe!) and remaining responsive and quick to download. Take a look at the incredible level of detail available in a Cesium 3D Tiles scene in the example below:

Where can you get 3D tile content?

If you’re lucky, your regional government or data custodians are already publishing 3D “digital twins” of your area. Cesium 3D Tiles are the standard way that these digital twin datasets are being published. Check your regional data portals and government open data hubs and see whether they’ve made any content available as 3D tiles. (For Australian users, there’s tons of great content available on the Terria platform!).

Alternatively, there’s many datasets available via the Cesium ion platform. This includes global 3D buildings based on OpenStreetMap data, and the entirety of Google’s photorealistic Google Earth tiles! We’ve published a Cesium ion QGIS plugin to complement the QGIS 3.34 release, which helps make it super-easy to directly load datasets from ion into your QGIS projects.

Lastly, users of the OpenDroneMap photogrammetry application will already have Cesium 3D Tiles datasets of their projects available, as 3D tiles are one of the standard outputs generated by OpenDroneMap.


So why exactly would you want to access Cesium 3D tiles within QGIS? Well, for a start, 3D Tiles datasets are intrinsically geospatial data. All the 3D content from these datasets are georeferenced and have accurate spatial information present. By loading a 3D tiles dataset into QGIS, you can easily overlay and compare 3D tile content to all your other standard spatial data formats (such as Shapefiles, Geopackages, raster layers, mesh datasets, WMS layers, etc…). They become just another layer of spatial information in your QGIS projects, and  you can utilise all the tools and capabilities you’re familiar with in QGIS for analysing spatial data along with these new data sources.

One large drawcard of adding a Cesium 3D Tile dataset to your QGIS project is that they make fantastic 3D basemaps. While QGIS has had good support for 3D maps for a number of years now, it has been tricky to create beautiful 3D content. That’s because all the standard spatial data formats tend to give generalised, “blocky” representations of objects in 3D. For example, you could use an extruded building footprint file to show buildings in a 3D map but they’ll all be colored as idealised solid blocks. In contrast, Cesium 3D Tiles are a perfect fit for a 3D basemap! They typically include photorealistic textures, and include all types of real-world features you’d expect to see in a 3D map — including buildings, trees, bridges, cliffsides, etc.

What next?

If you’re keen to learn even more about Cesium 3D Tiles in QGIS, you can check out the recent “QGIS Open Day” session we presented. In this session we cover all the details about 3D tiles and QGIS, and talk in depth about what’s possible in QGIS 3.34 and what may be coming in later releases.

Otherwise, grab the latest QGIS 3.34 and start playing…. you’ll quickly find that Cesium 3D Tiles are a fun and valuable addition to QGIS’ capabilities!

Our thanks go to Cesium and their ecosystem grant project for funding this work and making it possible.

QField 3.0 release : field mapping app, based on QGIS

We are very happy and enthusiasts at Oslandia to forward the QField 3.0 release announcement, the new major update of this mobile GIS application based on QGIS.

Oslandia is a strategic partner of, the company at the heart of QField development, as well as the QFieldCloud associated SaaS offering. We join to announce all the new features of QField 3.0.

Get QField 3.0 now !

QField 3.0 screenshots


Shipped with many new features and built with the latest generation of Qt’s cross-platform framework, this new chapter marks an important milestone for the most powerful open-source field GIS solution.

Main highlights

Upon launching this new version of QField, users will be greeted by a revamped recent projects list featuring shiny map canvas thumbnails. While this is one of the most obvious UI improvements, countless interface tweaks and harmonization have occurred. From the refreshed dark theme to the further polishing of countless widgets, QField has never looked and felt better.

The top search bar has a new functionality that allows users to look for features within the currently active vector layer by matching any of its attributes against a given search term. Users can also refine their searches by specifying a specific attribute. The new functionality can be triggered by typing the ‘f’ prefix in the search bar followed by a string or number to retrieve a list of matching features. When expanding it, a new list of functionalities appears to help users discover all of the tools available within the search bar.

QField’s tracking has also received some love. A new erroneous distance safeguard setting has been added, which, when enabled, will dictate the tracker not to add a new vertex if the distance between it and the previously added vertex is greater than a user-specified value. This aims at preventing “spikes” of poor position readings during a tracking session. QField is now also capable of resuming a tracking session after being stopped. When resuming, tracking will reuse the last feature used when first starting, allowing sessions interrupted by battery loss or momentary pause to be continued on a single line or polygon geometry.

On the feature form front, QField has gained support for feature form text widgets, a new read-only type introduced in QGIS 3.30, which allows users to create expression-based text labels within complex feature form configurations. In addition, relationship-related form widgets now allow for zooming to children/parent features within the form itself.

To enhance digitizing work in the field, QField now makes it possible to turn snapping on and off through a new snapping button on top of the map canvas when in digitizing mode. When a project has enabled advanced snapping, the dashboard’s legend item now showcases snapping badges, allowing users to toggle snapping for individual vector layers.

In addition, digitizing lines and polygons by using the volume up/down hardware keys on devices such as smartphones is now possible. This can come in handy when digitizing data in harsh conditions where gloves can make it harder to use a touch screen.

While we had to play favorites in describing some of the new functionalities in QField, we’ve barely touched the surface of this feature-packed release. Other major additions include support for Near-Field Communication (NFC) text tag reading and a new geometry editor’s eraser tool to delete part of lines and polygons as you would with a pencil sketch using an eraser.

Thanks to Deutsches Archäologisches Institut, Groupements forestiers Québec, Amsa, and Kanton Luzern for sponsoring these enhancements.

Quality of life improvements

Starting with this new version, the scale bar overlay will now respect projects’ distance measurement units, allowing for scale bars in imperial and nautical units.

QField now offers a rendering quality setting which, at the cost of a slightly reduced visual quality, results in faster rendering speeds and lower memory usage. This can be a lifesaver for older devices having difficulty handling large projects and helps save battery life.

Vector tile layer support has been improved with the automated download of missing fonts and the possibility of toggling label visibility. This pair of changes makes this resolution-independent layer type much more appealing.

On iOS, layouts are now printed by QField as PDF documents instead of images. While this was the case for other platforms, it only became possible on iOS recently after work done by one of our ninjas in QGIS itself.

Many thanks to DB Fahrwgdienste for sponsoring stabilization efforts and fixes during this development cycle.

Qt 6, the latest generation of the cross-platform framework powering QField

Last but not least, QField 3.0 is now built against Qt 6. This is a significant technological milestone for the project as this means we can fully leverage the latest technological innovations into this cross-platform framework that has been powering QField since day one.

On top of the new possibilities, QField benefited from years of fixes and improvements, including better integration with Android and iOS platforms. In addition, the positioning framework in Qt 6 has been improved with awareness of the newer GNSS constellations that have emerged over the last decade.

Forest-themed release names

Forests are critical in climate regulation, biodiversity preservation, and economic sustainability. Beginning with QField 3.0 “Amazonia” and throughout the 3.X’s life cycle, we will choose forest names to underscore the importance of and advocate for global forest conservation.

Software with service and Oslandia provides the full range of services around QField and QGIS : training, consulting, adaptation, specific development and core development, maintenance and assistance. Do not hesitate to contact us and detail your needs, we will be happy to collaborate : [email protected]

As always, we hope you enjoy this new release. Happy field mapping!

QGIS Add to Felt Plugin – Phase 2

We have been continuing our work with the Flagship sponsor of QGISFelt to develop their QGIS Plugin – Add to Felt  that makes it even easier to share your maps and data on the web.

What is the ‘Add to Felt’ QGIS Plugin?

The ‘Add to Felt’ QGIS Plugin is a powerful tool that empowers users to export their QGIS projects and layers directly to a Felt web map. This update introduces two fantastic features:

  1. Single Layer Sharing: You can now share a single layer from your QGIS project to a Felt map. This means you have greater control over which specific data layers to share, allowing you to tailor your map precisely to your audience’s needs.
  2. Map Selection: With the updated plugin, you can choose which map on Felt to add your layer to – a new map, or an ongoing project. This flexibility simplifies your workflow and ensures that your data ends up in the right place.

Businesses that rely on QGIS love how these new features provide a seamless way to view and share results, ultimately allowing them to move more quickly and stay in sync:

“Felt helps us keep each other updated on what we’ve done, what we’ve modeled, how things are progressing.” – ICON Engineering

Why is this Update Important?

Web maps are invaluable tools for sharing data with a wider audience, be it colleagues, clients, or the public. They provide creators with the ability to control data visibility, display options, and audience access, all within an easily shareable digital format. However, creating web maps can be an arduous and complex task.

Here’s where the ‘Add to Felt’ QGIS Plugin update comes to the rescue:

1. Streamlining the Process: Creating web maps traditionally involves website development, data hosting, and map application development—tasks that require a diverse skill set. This complexity can be a significant barrier, especially for smaller operations with limited resources or budget constraints.

2. Felt Simplifies Web Mapping: Felt makes it effortless to create web maps, and share them as easily as you would a Google Doc or Sheet. Simply drag and drop your data, customize the symbology to your liking, and share the map with a link or by inviting collaborators. No need to send large data files or answer questions about the map’s data sources.

3. Integration with QGIS: Now, the ‘Add to Felt’ QGIS Plugin bridges the gap between QGIS and Felt. It seamlessly imports your QGIS data into Felt, eliminating the need for manual data transfers and reducing the complexity of web map creation.

In essence, the ‘Add to Felt’ QGIS Plugin update simplifies the process of sharing and collaborating on web maps. It empowers users to harness the full potential of web-based mapping, making it accessible to everyone, regardless of their technical expertise. The update makes it even easier to share progress updates or model re-run outputs without creating a new map, or sharing a new map link.

So, if you’re a QGIS user looking to enhance your map-sharing capabilities and streamline your workflow, make sure to take advantage of this fantastic update. Say goodbye to the complexities of web map creation and hello to effortless, data-rich web maps with Felt and the ‘Add to Felt’ QGIS Plugin.

How to install and upgrade

  • Open QGIS on your computer. You must have version 3.22 or later installed.
  • In the plugins tab, select Manage and Install Plugins.
  • Search for the ‘Add to Felt’ plugin, select and click Install Plugin.
  • Close the Plugins dialog. The Felt plugin toolbar will appear in your toolbar for use.
  • Sign into Felt and begin sharing your maps to the web.

If you want more features in this plugin, let us know or you’re interested in exploring how a QGIS plugin can make your service easily accessible to the millions of daily QGIS users, contact us to discuss how we can help!

Strategic partnership agreement between Oslandia and on QField

Who are we?

🤔 For those unfamiliar with Oslandia,, or even QGIS, let’s refresh your memory:

👉 Oslandia is a French company specializing in open-source Geographic Information Systems (GIS). Since our establishment in 2009, we have been providing consulting, development, and training services in GIS, with reknown expertise. Oslandia is a dedicated open-source player and the largest contributor to the QGIS solution in France.

👉 As for, they are a Swiss company specializing in the development of open-source GIS software. Founded in 2011, is the largest Swiss contributor to QGIS. is the creator of QField, the most widely used open-source mobile GIS solution for geomatics professionals. also offers QFieldCloud as a SaaS or on-premise solution for collaborative field project management.

😲 Some may still be unfamiliar with #QGIS ?

It is a free and open-source Geographic Information System that allows creating, editing, visualizing, analyzing, and publicating geospatial data. QGIS is a cross-platform software that can be used on desktops, servers, as a web application, or as a development library.

QGIS is open-source software developed by multiple contributors worldwide. It is an official project of the OpenSource Geospatial Foundation (OSGeo) and is supported by the association. See

A Partnership?

🎉 Today, we are delighted to announce our strategic partnership aimed at strengthening and promoting QField, the mobile application companion of QGIS Desktop.

🌟 This partnership between Oslandia and is a significant step for QField and open-source mobile GIS solutions. It will consolidate the platform, providing users worldwide with simplified access to effective tools for collecting, managing, and analyzing geospatial data in the field.

📱 QField, developed by, is an advanced open-source mobile application that enables GIS professionals to work efficiently in the field, using interactive maps, collecting real-time data, and managing complex geospatial projects on Android, iOS, or Windows mobile devices.

↔ QField is cross-platform, based on the QGIS engine, facilitating seamless project sharing between desktop, mobile, and web applications.

🕸 QFieldCloud (, the collaborative web platform for QField project management, will also benefit from this partnership and will be enhanced to complement the range of tools within the QGIS platform.


❤ At Oslandia, we are thrilled to collaborate with on QGIS technologies. Oslandia shares with a common vision of open-source software development: a strong involvement in development communities, work in respect with the ecosystem, an highly skilled expertise, and a commitment to industrial-quality, robust, and sustainable software development.

👩‍💻 With this partnership, we aim to offer our clients the highest expertise across all software components of the QGIS platform, from data capture to dissemination.

🤝 On the side, Marco Bernasocchi adds:

The partnership with Oslandia represents a crucial step in our mission to provide leading mobile GIS tools with a genuine OpenSource credo. The complementarity of our skills will accelerate the development of QField and QFieldCloud and meet the growing needs of our users.

Commitment to open source

🙏 Both companies are committed to continue supporting and improving QField and QFieldCloud as open-source projects, ensuring universal access to this high-quality mobile GIS solution without vendor dependencies.

Ready for field mapping ?

🌏 And now, are you ready for the field?

So, download QField (, create projects in QGIS, and share them on QFieldCloud!

✉ If you need training, support, maintenance, deployment, or specific feature development on these platforms, don’t hesitate to contact us. You will have access to the best experts available: [email protected].


Analyzing and visualizing large-scale fire events using QGIS processing with ST-DBSCAN

A while back, one of our ninjas added a new algorithm in QGIS’ processing toolbox named ST-DBSCAN Clustering, short for spatio temporal density-based spatial clustering of applications with noise. The algorithm regroups features falling within a user-defined maximum distance and time duration values.

This post will walk you through one practical use for the algorithm: large-scale fire event analysis and visualization through remote-sensed fire detection. More specifically, we will be looking into one of the larger fire events which occurred in Canada’s Quebec province in June 2023.

Fetching and preparing FIRMS data

NASA’s Fire Information for Resource Management System (FIRMS) offers a fantastic worldwide archive of all fire detected through three spaceborne sources: MODIS C6.1 with a resolution of roughly 1 kilometer as well as VIIRS S-NPP and VIIRS NOAA-20 with a resolution of 375 meters. Each detected fire is represented by a point that sits at the center of the source’s resolution grid.

Each source will cover the whole world several times per day. Since detection is impacted by atmospheric conditions, a given pass by one source might not be able to register an ongoing fire event. It’s therefore advisable to rely on more than one source.

To look into our fire event, we have chosen the two fire detection sources with higher resolution – VIIRS S-NPP and VIIRS NOAA-20 – covering the whole month of June 2023. The datasets were downloaded from FIRMS’ archive download page.

After downloading the two separate datasets, we combined them into one merged geopackage dataset using QGIS processing toolbox’s Merge Vector Layers algorithm. The merged dataset will be used to conduct the clustering analysis.

In addition, we will use QGIS’s field calculator to create a new Date & Time field named ACQ_DATE_TIME using the following expression:

to_datetime("ACQ_DATE" || "ACQ_TIME", 'yyyy-MM-ddhhmm')

This will allow us to calculate precise time differences between two dates.

Modeling and running the analysis

The large-scale fire event analysis requires running two distinct algorithms:

  • a spatiotemporal clustering of points to regroup fires into a series of events confined in space and time; and
  • an aggregation of the points within the identified clusters to provide additional information such as the beginning and end date of regrouped events.

This can be achieved through QGIS’ modeler to sequentially execute the ST-DBSCAN Clustering algorithm as well as the Aggregate algorithm against the output of the first algorithm.

The above-pictured model outputs two datasets. The first dataset contains single-part points of detected fires with attributes from the original VIIRS products as well as a pair of new attributes: the CLUSTER_ID provides a unique cluster identifier for each point, and the CLUSTER_SIZE represents the sum of points forming each unique cluster. The second dataset contains multi-part points clusters representing fire events with four attributes: CLUSTER_ID and CLUSTER_SIZE which were discussed above as well as DATE_START and DATE_END to identify the beginning and end time of a fire event.

In our specific example, we will run the model using the merged dataset we created above as the “fire points layer” and select ACQ_DATE_TIME as the “date field”. The outputs will be saved as separate layers within a geopackage file.

Note that the maximum distance (0.025 degrees) and duration (72 hours) settings to form clusters have been set in the model itself. This can be tweaked by editing the model.

Visualizing a specific fire event progression on a map

Once the model has provided its outputs, we are ready to start visualizing a fire event on a map. In this practical example, we will focus on detected fires around latitude 53.0960 and longitude -75.3395.

Using the multi-part points dataset, we can identify two clustered events (CLUSTER_ID 109 and 1285) within the month of June 2023. To help map canvas refresh responsiveness, we can filter both of our output layers to only show features with those two cluster identifiers using the following SQL syntax: CLUSTER_ID IN (109, 1285).

To show the progression of the fire event over time, we can use a data-defined property to graduate the marker fill of the single-part points dataset along a color ramp. To do so, open the layer’s styling panel, select the simple marker symbol layer, click on the data-defined property button next to the fill color and pick the Assistant menu item.

In the assistant panel, set the source expression to the following: day(age(to_date('2023-07-01'),”ACQ_DATE_TIME”)). This will give us the number of days between a given point and an arbitrary reference date (2023-07-01 here). Set the values range from 0 to 30 and pick a color ramp of your choice.

When applying this style, the resulting map will provide a visual representation of the spread of the fire event over time.

Having identified a fire event via clustering easily allows for identification of the “starting point” of a fire by searching for the earliest fire detected amongst the thousands of points. This crucial bit of analysis can help better understand the cause of the fire, and alongside the color grading of neighboring points, its directionality as it expanded over time.

Analyzing a fire event through histogram

Through QGIS’ DataPlotly plugin, it is possible to create an histogram of fire events. After installing the plugin, we can open the DataPlotly panel and configure our histogram.

Set the plot type to histogram and pick the model’s single-part points dataset as the layer to gather data from. Make sure that the layer has been filtered to only show a single fire event. Then, set the X field to the following layer attribute: “ACQ_DATE”.

You can then hit the Create Plot button, go grab a coffee, and enjoy the resulting histogram which will appear after a minute or so.

While not perfect, an histogram can quickly provide a good sense of a fire event’s “peak” over a period of time.

Soar.Earth Digital Atlas QGIS Plugin

Soar banner

Growing up, I would spend hours lost in National Geographic maps. The feeling of discovering new regions and new ways to view the world was addictive! It’s this same feeling of discovery and exploration which has made me super excited about Soar’s Digital Atlas. Soar is the brainchild of Australian, Amir Farhand, and is fuelled by the talents of staff located across the globe to build a comprehensive digital atlas of the world’s maps and images. Soar has been designed to be an easy to use, expansive collection of diverse maps from all over the Earth. A great aspect of Soar is that it has implemented Strong Community Guidelines and moderation to ensure the maps are fit for purpose.

Recently, North Road collaborated with Soar to help facilitate their digital atlas goals by creating a QGIS plugin for Soar. The Soar plugin allows QGIS users to directly:

  • Export their QGIS maps and images straight to Soar
  • Browse and load maps from the entire Soar public catalogue into their QGIS projects

There’s lots of extra tweaks we’ve added to help make the plugin user friendly, whilst offering tons of functionality that power users want. For instance, users can:

  • Filter Soar maps by their current project extent and/or by category
  • Export raw or rendered raster data directly to Soar via a Processing tool
  • Batch upload multiple maps to Soar
  • Incorporate Soar map publishing into a Processing model or Python based workflow

Soar will be presenting their new plugin at the QGIS Open Day in August so check out the details here and tune in at 2300 AEST or 1300 HR UTC. You can follow along via either YouTube or Jitsi.

Browsing Soar maps from QGIS

One of the main goals of the Soar QGIS plugin was to make it very easy to find new datasets and add them to your QGIS projects. There’s two ways users can explore the Soar catalog from QGIS:

You can open the Soar Browser Panel via the Soar toolbar button  Soar browser . This opens a floating catalog browser panel which allows you to interactively search Soar’s content while working on your map.

Soar browser panel

Alternatively, you can also access the Soar catalog and maps from the standard QGIS Data Source Manager dialog. Just open the “Soar” tab and search away!

When you’ve found an interesting map, hit the “Add to Map” button and the map will be added as a new layer into your current project. After the layer is loaded you can freely modify the layer’s style (such as the opacity, colorization, contrast etc) just like any other raster dataset using the standard QGIS Layer Style controls.

Sharing your maps

Before you can share your maps on Soar, you’ll need to first sign up for a free Soar account.

We’ve designed the Soar plugin with two specific use cases in mind for sharing maps. The first use case is when you want to share an entire map (i.e. QGIS project) to Soar. This will publish all the visible content from your map onto Soar, including all the custom styling, labeling, decorations and other content you’ve carefully designed. To do this, just select the Project menu, Import/Export -> Export map to Soar option.

Upload via Project to Soar

You’ll have a chance to enter all the metadata and descriptive text explaining your map, and then the map will be rendered and uploaded directly to Soar.

Soar Metadata

All content on the Soar atlas is moderated, so your shared maps get added to the moderation queue ready for review by the Soar team. (You’ll be notified as soon as the review is complete and your map is publicly available).

Alternatively, you might have a specific raster layer which you want to publish on Soar. For instance, you’ve completed some flood modelling or vegetation analysis and want to share the outcome widely. To do this, you can use the “Publish dataset to Soar” tool available from the QGIS Processing toolbox:

Upload product to Soar via processing tools

Just pick the raster layer you want to upload, enter the metadata information, and let the plugin do the rest! Since this tool is made available through QGIS’ Processing framework, it also allows you to run it as a batch process (eg uploading a whole folder of raster data to Soar), or as a step in your QGIS Graphical Models!

Some helpful hints

All maps uploaded to Soar require the following information:

  • Map Title
  • Description
  • Tags
  • Categories
  • Permission to publish

This helps other users to find your maps with ease, and also gives the Soar moderation team the information required for their review process.

We’ve a few other tips to keep in mind to successfully share your maps on Soar:

  • The Soar catalog currently works with raster image formats including GeoTIFF / ECW / JP2 / JPEG / PNG
  • All data uploaded to Soar must be in the WGS84 Pseudo-Mercator (EPSG: 3857) projection
  • Check the size of your data before sharing it, as a large size dataset may take a long time to upload

So there you have it! So simple to start building up your contribution to Soar’s Digital Atlas. Those who might find this useful to upload maps include:

  • Community groups
  • Hobbyists
  • Building a cartographic/geospatial portfolio
  • Education/research
  • Contributing to world events (some of the biggest news agencies already use this service i.e. BBC)

You can find out more about the QGIS Soar plugin at the QGIS Open Day on August 23rd, 2023 at 2300 HR AEST or 1300 HR UTC. Check here for more information or to watch back after.

If you’re interested in exploring how a QGIS plugin can make your service easily accessible to the millions of daily QGIS users, contact us to discuss how we can help!

‘Add to Felt’ QGIS Plugin

The gift economy of Open Source is community driven and filled by folks with ideas that just go for it!

We at North Road are blessed that we get to join these creatives on their journey in order to get their products to you. Recently, the first QGIS flagship sponsor, Felt, engaged us to further strengthen their support for the up to 600,000 daily QGIS users to integrate their workflows between QGIS and Felt.

The result is the “Add to Felt” QGIS Plugin, which makes it super-simple to publish your QGIS maps to the Felt platform.

To get started, install the Add to Felt Plugin from the QGIS Plugin manager.

If you don’t have a free Felt account, you’ll need to sign up for one online (or from the Add to Felt plugin itself once you have installed it).

Within QGIS, users can easily publish their maps and layers to Felt. You can either:

  • Publish a single layer by right-clicking the layer and selecting “Share Layer to Felt” from the Export sub-menu
  • Publish your whole QGIS project/map by selecting the Project Menu, Export, “Add to Felt” action

Whilst Felt is loading up your map, you can continue working and it will let you know once your map is ready to open on Felt and share with others.

We are happy to let you know that the collaboration does not stop there! As with our SLYR tool, there is ongoing development as the requirements of the community and technology grow.  So install the Add to Felt Plugin via the QGIS Plugin manager, and let us know where you want it to go via the Add to Felt GitHub page.

Read more about it here:

Unterstützung für WMTS im QGIS Swiss Locator

Das QGIS swiss locator Plugin erleichtert in der Schweiz vielen Anwendern das Leben dadurch, dass es die umfangreichen Geodaten von swisstopo und zugänglich macht. Darunter ein breites Angebot an GIS Layern, aber auch Objektinformationen und eine Ortsnamensuche.

Dank eines Förderprojektes der Anwendergruppe Schweiz durfte ihr Plugin um eine zusätzliche Funktionalität erweitern. Dieses Mal mit der Integration von WMTS als Datenquelle, eine ziemlich coole Sache. Doch was ist eigentlich der Unterschied zwischen WMS und WMTS?


Zuerst zu den Gemeinsamkeiten: Beide Protokolle – WMS und WMTS – sind dazu geeignet, Kartenbilder von einem Server zu einem Client zu übertragen. Dabei werden Rasterdaten, also Pixel, übertragen. Ausserdem werden dabei gerenderte Bilder übertragen, also keine Rohdaten. Diese sind dadurch für die Präsentation geeignet, im Browser, im Desktop GIS oder für einen PDF Export.

Der Unterschied liegt im T. Das T steht für “Tiled”, oder auf Deutsch “gekachelt”. Bei einem WMS (ohne Kachelung) können beliebige Bildausschnitte angefragt werden. Bei einem WMTS werden die Daten in einem genau vordefinierten Gitternetz — als Kacheln — ausgeliefert. 

Der Hauptvorteil von WMTS liegt in dieser Standardisierung auf einem Gitternetz. Dadurch können diese Kacheln zwischengespeichert (also gecached) werden. Dies kann auf dem Server geschehen, der bereits alle Kacheln vorberechnen kann und bei einer Anfrage direkt eine Datei zurückschicken kann, ohne ein Bild neu berechnen zu müssen. Es erlaubt aber auch ein clientseitiges Caching, das heisst der Browser – oder im Fall von Swiss Locator QGIS – kann jede Kachel einfach wiederverwenden, ganz ohne den Server nochmals zu kontaktieren. Dadurch kann die Reaktionszeit enorm gesteigert werden und flott mit Applikationen gearbeitet werden.

Warum also noch WMS verwenden?

Auch das hat natürlich seine Vorteile. Der WMS kann optimierte Bilder ausliefern für genau eine Abfrage. Er kann Beispielsweise alle Beschriftungen optimal platzieren, so dass diese nicht am Kartenrand abgeschnitten sind, bei Kacheln mit den vielen Rändern ist das schwieriger. Ein WMS kann auch verschiedene abgefragte Layer mit Effekten kombinieren, Blending-Modi sind eine mächtige Möglichkeit, um visuell ansprechende Karten zu erzeugen. Weiter kann ein WMS auch in beliebigen Auflösungen arbeiten (DPI), was dazu führt, dass Schriften und Symbole auf jedem Display in einer angenehmen Grösse angezeigt werden, währenddem das Kartenbild selber scharf bleibt. Dasselbe gilt natürlich auch für einen PDF Export.

Ein WMS hat zudem auch die Eigenschaft, dass im Normalfall kein Caching geschieht. Bei einer dahinterliegenden Datenbank wird immer der aktuelle Datenstand ausgeliefert. Das kann auch gewünscht sein, zum Beispiel soll nicht zufälligerweise noch der AV-Datensatz von gestern ausgeliefert werden.

Dies bedingt jedoch immer, dass der Server das auch entsprechend umsetzt. Bei den von swisstopo via publizierten Karten ist die Schriftgrösse auch bei WMS fix ins Kartenbild integriert und kann nicht vom Server noch angepasst werden.

Im Falle von QGIS Swiss Locator geht es oft darum, Hintergrundkarten zu laden, z.B. Orthofotos oder Landeskarten zur Orientierung. Daneben natürlich oft auch auch weitere Daten, von eher statischer Natur. In diesem Szenario kommen die Vorteile von WMTS bestmöglich zum tragen. Und deshalb möchten wir der QGIS Anwendergruppe Schweiz im Namen von allen Schweizer QGIS Anwender dafür danken, diese Umsetzung ermöglicht zu haben!

Der QGIS Swiss Locator ist das schweizer Taschenmesser von QGIS. Fehlt dir ein Werkzeug, das du gerne integrieren würdest? Schreib uns einen Kommentar!

Cesium Ecosystem Grant Win for QGIS 3D Tiles!

Success! Lutra and North Road have been rewarded a Cesium Ecosystem Grant to provide access to 3D tiles within QGIS. We will be creating the ability for users to visualise 3D Tiles in QGIS alongside other standard geospatial sources in both 3D and 2D map views.
3D Tiles Cesium integration ecosystem diagram
3D Tiles Cesium integration ecosystem
We are very excited about it, but to be included in the first cohort of awardees is also an added honour! We share this distinction with 3 other recipients:
The opportunity was brought to our attention by our friends over at Nearmap, which, along with the existence of this grant, shows how the geospatial community is working together by evolving the Open Source Economy. A movement close to our hearts and our core business. Working between commercial software and open-source, Cesium’s business model recognises the legitimacy of Open Source Software for use as a geospatial standard operating procedure by promoting openness and interoperability.
Our team of Nyall Dawson and Martin Dobias will create a new layer type, QgsTiledMeshLayer, allowing for direct access to Cesium 3D tile sources alongside the other supported geospatial layer types within QGIS. This will include visualisation of the tile data in both 3D and 2D map views (feature footprints). It will fulfill a critical need for QGIS users, permitting access to 3d data provided by their respective government agencies to work alongside all their other standard geospatial layers (vector, raster, point clouds). By making 3D Tiles a first class citizen in QGIS we help strengthen the case that those agencies should be providing their data in the Cesium format (as opposed to any proprietary alternatives).
Proposed Technical Architecture Cesium QGIS
Proposed Technical Architecture for Cesium 3D Tiles in QGIS
Here’s a breakdown of what we will be doing:
  • Develop a new QGIS layer type “QgsTiledMeshLayer”
  • Develop a parser for 3D Tiles format, supporting Batched 3D Model (with a reasonable set of glTF 2.0 features)
  • Develop a 3D renderer which dynamically loads and displays features from 3D Tiles based on appropriate 3D view level of detail. (A similar approach has already been implemented in QGIS for optimised viewing of point cloud data).
  • Develop a 2D renderer for 3D Tiles, which will display the footprints of 3D tile features in 2D QGIS map views. Just like the 3D renderer, the 2D renderer will utilise map scale information to dynamically load 3D tiles and display a suitable level of detail for the footprints.
  • Users will have full control over the appearance of the 2D footprints, with support for all of QGIS’ extensive polygon symbology options.
  • By permitting users to view the 2D footprints of features, we will promote use of Cesium 3D Tiles as a suitable source of cartographic data, eg display of authoritative building footprints supplied by government agencies in the Cesium 3D Tile format.

Through past partnerships, North Road and Lutra Consulting have developed and extended the 3D mapping functionality of QGIS. To date, all the framework for mature, performant 3D scenes including vector, mesh, raster and point cloud sources are in place. We are now ready to extend the existing functionality with Cesium 3D tiles support as QGIS 3D engine already implements most of the required concepts, such as out of core rendering and hierarchical level of detail (tested with point clouds with billions of points).

So there we go! Working together collaboratively with Lutra Consulting on another great addition to QGIS 3D Functionality thanks to Cesium Ecosystem Grants. Stay tuned on our social channels to find out when it will be released in QGIS.

Cesium Ecosystem grant Badge


SLYR Update — June 2023

Welcome back, SLYR enthusiasts! We’re thrilled to share the latest updates and enhancements for our SLYR ESRI to QGIS Compatibility Suite that will dramatically streamline the use of ESRI documents within QGIS (and vice versa!). Our team has been hard at work, expanding the capabilities of SLYR to ensure seamless compatibility between the latest QGIS and ArcGIS releases. We’ve also got some exciting news for users of the Community Edition of SLYR! Let’s dive right in and explore the exciting new features that have been added to SLYR since our previous update

Converting Raster Layers in Geodatabases

We’re pleased to announce that SLYR now offers support for converting raster layers within Geodatabases. With this update, users can effortlessly migrate their raster data from ESRI’s Geodatabases to QGIS, enabling more efficient data management and analysis.

This enhancement is only possible thanks to work in the fantastic GDAL library which underpins QGIS’ raster data support. Please ensure that you have the latest version of QGIS (3.30.3 or 3.28.7 at a minimum) to make the most of this feature.

Annotation and Graphic Layer Improvements

Text Annotations along Curves

For those working with curved annotations, we’ve got you covered! SLYR now supports the conversion of text annotations along curves in QGIS. With this enhancement, you’ll get accurate conversion of any curved text and text-along-line annotations from MXD and APRX documents. This has been a long-requested feature which we can now introduce thanks to enhancements coming in QGIS 3.32.

ArcGIS Pro Graphics Layer Support

SLYR now supports the conversion of ArcGIS Pro graphics layers, converting all graphic elements to their QGIS “Annotation Layer” equivalents. If you’ve spent hours carefully designing cartographic markup on your maps, you can be sure that SLYR will allow you to re-use this work within QGIS!

Curved text graphic conversion

Enhanced Page Layout Support

We’ve further improved the results of converting ArcGIS Pro page layouts to QGIS print layouts, with dozens of refinements to the conversion results. The highlights here include:

  • Support for converting measured grids and graticules to QGIS map grids
  • Enhanced dynamic text conversions:  Now, when migrating your projects, you can expect a smoother transition for dynamic text ensuring your layouts correctly show generated metadata and text correctly
  • Support for north arrows, grouped elements, legends and table frames.

Rest assured that your carefully crafted map layouts will retain their visual appeal and functionality when transitioning to QGIS!

Improved QGIS to ArcGIS Pro Conversions

SVG Marker Exports and Symbology Size

SLYR has introduced initial support for exporting SVG markers from QGIS to ArcGIS Pro formats. SVG graphics are a component of QGIS’ cartography, and are frequently used to create custom marker symbols. Unfortunately, ArcGIS Pro doesn’t have any native support for SVG graphics for marker symbols, instead relying on a one-off conversion from SVG to multiple separate marker graphics whenever an SVG is imported into ArcGIS Pro. Accordingly, we’ve implemented a similar logic in SLYR in order to convert SVG graphics to ArcGIS Pro marker graphics transparently whenever QGIS symbology is exported to ArcGIS. This enhancement allows for a seamless transfer of symbology from QGIS, ensuring that your converted maps retain their visual integrity.

Furthermore, the update includes support for exporting QGIS symbology sizes based on “map unit” measurements to ArcGIS Pro, resulting in ArcGIS Pro symbology which more accurately matches the original QGIS versions.

Rule-Based Renderer Conversion

The “Rule Based Renderer” is QGIS’ ultimate powerhouse for advanced layer styling. It’s extremely flexible, thanks to its support for nested rules and filtering using QGIS expressions. However, this flexibility comes with a cost — there’s just no way to reproduce the same results within ArcGIS Pro’s symbology options! Newer SLYR releases will now attempt to work around this by implementing basic conversion of QGIS rule-based renderers to ArcGIS Pro layers with “display filters” attached. This allows us to convert some basic rule-based configuration to ArcGIS Pro formats.

There’s some limitations to be aware of:

  1. Only “flat” rule structures can be converted. It’s not possible to convert a nested rule structure into something representable by ArcGIS Pro.
  2. While the QGIS expression language is very rich and offers hundreds of functions for use in expressions, only basic QGIS filter expressions can be converted to ArcGIS Pro rules.

Improved Conversion of Raster and Mesh Layers

Based on user feedback, we’ve made significant improvements to the conversion of QGIS rasters and mesh layers to ArcGIS Pro formats. Expect enhanced accuracy when migrating these types of data, ensuring a closer match between your QGIS projects and their ArcGIS Pro equivalents.

New tools

The latest SLYR release introduces some brand new tools for automating your conversion workflows:

Convert LYR/LYRX Files Directly to SLD

To facilitate interoperability, SLYR has introduced algorithms that directly convert ESRI LYR or LYRX files to the “SLD” format (Styled Layer Descriptor). This feature simplifies the process of sharing and utilizing symbology between different GIS software, allowing for direct conversion of ESRI symbology for use in Geoserver or Mapserver.

Convert File Geodatabases to Geopackage

We’re thrilled to introduce a powerful new tool in SLYR that enables a comprehensive conversion of a File Geodatabase to the Geopackage format. With this feature, you can seamlessly migrate your data from ESRI’s File Geodatabase format to the versatile and widely supported GeoPackage format. As well as the raw data conversion, this tool also ensures the conversion of field domains and other advanced Geodatabase functionality to their GeoPackage equivalent, preserving valuable metadata and maintaining data integrity throughout the transition. (Please note that this tool requires QGIS version 3.28 or later.)


All these exciting additions to SLYR are available today to SLYR license holders. If you’re after one-click, accurate conversion of projects from ESRI to QGIS, contact us to discuss your licensing needs.

As described on our SLYR page, we also provide some of the conversion tools for free use via the SLYR “Community Edition”. We’re proud to announce that we’ve just hit the next milestone in the Community Edition funding, and will now be releasing all of SLYR’s support for raster LYR files to the community edition! This complements the existing support for vector LYR files and ESRI style files available in the community edition. For more details on the differences between the licensed and community editions, see our product comparison.

Analyzing video-based bicycle trajectories

Did you know that MovingPandas also supports local image coordinates? Indeed, it does.

In today’s post, we will explore how we can use this feature to analyze bicycle tracks extracted from video footage published by Michael Szell @mszll:

The bicycle trajectory coordinates are stored in two separate lists: xs_640x360 and ys640x360:

This format is kind of similar to the Kaggle Taxi dataset, we worked with in the previous post. However, to use the solution we implemented there, we need to combine the x and y coordinates into nice (x,y) tuples:

df['coordinates'] = df.apply(
    lambda row: list(zip(row['xs_640x360'], row['ys_640x360'])), axis=1)
df.drop(columns=['xs_640x360', 'ys_640x360'], inplace=True)

Afterwards, we can create the points and compute the proper timestamps from the frame numbers:

def compute_datetime(row):
    # some educated guessing going on here: the paper states that the video covers 2021-06-09 07:00-08:00
    d = datetime(2021,6,9,7,0,0) + (row['frame_in'] + row['running_number']) * timedelta(seconds=2)
    return d
def create_point(xy):
        return Point(xy)
    except TypeError:  # when there are nan values in the input data
        return None
new_df = df.head().explode('coordinates')
new_df['geometry'] = new_df['coordinates'].apply(create_point)
new_df['running_number'] = new_df.groupby('id').cumcount()
new_df['datetime'] = new_df.apply(compute_datetime, axis=1)
new_df.drop(columns=['coordinates', 'frame_in', 'running_number'], inplace=True)

Once the points and timestamps are ready, we can create the MovingPandas TrajectoryCollection. Note how we explicitly state that there is no CRS for this dataset (crs=None):

trajs = mpd.TrajectoryCollection(
    traj_id_col='id',  t='datetime', crs=None)

Plotting trajectories with image coordinates

Similarly, to plot these trajectories, we should tell hvplot that it should not fetch any background map tiles (’tiles’:None) and that the coordinates are not geographic (‘geo’:False):

If you want to explore the full source code, you can find my Github fork with the Jupyter notebook at:

The repository also contains a camera image of the intersection, which we can use as a background for our trajectory plots:

bg_img = hv.RGB.load_image('img/intersection2.png', bounds=(0,0,640,360)) 

One important caveat is that speed will be calculated in pixels per second. So when we plot the bicycle speed, the segments closer to the camera will appear faster than the segments in the background:

To fix this issue, we would have to correct for the distortions of the camera lens and perspective. I’m sure that there is specialized software for this task but, for the purpose of this post, I’m going to grab the opportunity to finally test out the VectorBender plugin.

Georeferencing the trajectories using QGIS VectorBender plugin

Let’s load the five test trajectories and the camera image to QGIS. To make sure that they align properly, both are set to the same CRS and I’ve created the following basic world file for the camera image:


Then we can use the VectorBender tools to georeference the trajectories by linking locations from the camera image to locations on aerial images. You can see the whole process in action here:

After around 15 minutes linking control points, VectorBender comes up with the following georeferenced trajectory result:

Not bad for a quick-and-dirty hack. Some points on the borders of the image could not be georeferenced since I wasn’t always able to identify suitable control points at the camera image borders. So it won’t be perfect but should improve speed estimates.

This post is part of a series. Read more about movement data in GIS.

(Nederlands) Communicatie is een beetje… lastig?

Sorry, this entry is only available in Dutch.

QGIS User Conference 2023

Get your QGIS-ass to ‘s-Hertogenbosch!

How Oslandia invests in OpenSource

You may be wondering where Oslandia’s name is coming from ? Or maybe you already know ? In this article we focus on the “OS” part of Oslandia : OpenSource !

Oslandia positions itself as IT expert in the field of OpenSource geographical information systems. QGIS is namely one of the proheminent opensource softwares for the geospatial industry. This position is a key element of our business model.

But do you know how we work behind the scene ? This article will give you an opportunity to discover some of our contributions to the OpenSource ecosystem.


Our general business model is based on projects we carry out for our clients. They fund us to design and implement solutions adapted to their needs and requirements. Part of these developments consist in core development of Opensource software. This allows us to contribute actively to FOSS4G components.

But this funding method makes it complicated to fund maintenance, or new exploratory developments, as well as communication, community management or other tasks necessary for healthy opensource projects.

As a consequence, we introduced at Oslandia a mechanism of internal OpenSource project grants.

These grants constitute self-investment from the company into the OpenSource ecosystem, and can be applied to new projects, research and development or existing projects.

This mechanism has multiple interests :

  • For opensource projects : maintenance and new contributions
  • For Oslandia : image and potential new business opportunities
  • For the team : work on projects that matter to them

These OpenSource grants consist in a large range of possible tasks, as we often say : “Opensource projects are not only code”. Instead of developers, we prefer the term contributors. Development, code review, maintenance, documentation, community management, communication, each collaborator can choose the type of task to focus on.

We differentiate software maintenance grants and opensource project grants. We call the latter “OpenSource mini-projects

Software maintenance consists in refactoring, bugfixing, packaging, release management… All these tasks need dedicated time which is difficult to fund directly on client’s project.

Opensource mini-projects grants are specific opensource proposal which can be submitted by any collaborator on any subject. We then vote on the best proposal and the team can start working on the subject within the allocated budget.

Some numbers

We allocate around 5% of the global production time to software maintenance grants. Our Opensource maintenance grant for 2022 is therefore approximately 190 days of work. It mainly focus on QGIS, PostGIS, QWC2, Giro3D and a few other components we actively maintain.

We also allocate 5% of the global production time to opensource mini-projects grants. It represents an additional 190 days of work for 2022.

Oslandia therefore invests almost 400 days of work into the OpenSource ecosystem, outside of direct contributions for client’s projects.

Opensource Mini-projects

OpenSource mini-projects grants are submitted by Oslandia’s collaborators and focus on various task and thematics : innovation, development, design, prototyping, communication or any other kind of Opensource contribution.

Proposals have to define goals, deliverables, planning, team and needed budget. Then we evaluate the proposals given the following criteria :

  • proposal coherency ( e.g. deliverables vs budget )
  • alignment with Oslandia’s strategy
  • innovation level
  • business opportunities
  • fun and motivation
  • impacts in terms of communication
  • links with other projects at Oslandia
  • possibility of extra R&D funding

We then vote on best proposal and manage these mini-projects just as a client project.



The maintenance grant on QGIS allowed us to work on the following tasks :

  • Bugfixing
  • Code review for PRs submitted by other developers
  • Code refactoring
  • Documentation
  • Packaging pipeline
  • OSGeo4W improvement

OpenSource mini-projects grants

During the year of 2022, we worked on the following mini-projects :

In 2023 we will continue to work on these projects, and others ! for example pg_featureserv, py3dtiles, infoclimat website, MapProxypgRouting


This investment mechanism allows Oslandia to be an opensource “pure player” and contribute actively to these OpenSource projects and to the OpenSource ecosystem as a whole.

Should you be interested in our contribution model, or if you have any question regarding our internal OpenSource grant program, do not hesitate to contact us : [email protected] !

Tracking geoprocessing workflows with QGIS & DVC

Today’s post is a geeky deep dive into how to leverage DVC (not just) data version control to track QGIS geoprocessing workflows.

“Why is this great?” you may ask.

DVC tracks data, parameters, and code. If anything changes, we simply rerun the process and DVC will figure out which stages need to be recomputed and which can be skipped by re-using cached results.

This can lead to huge time savings compared to re-running the whole model

You can find the source code used in this post on my repo

I’m using DVC with the DVC plugin for VSCode but DVC can be used completely from the command line, if you prefer this appraoch.

Basically, what follows is a proof of concept: converting a QGIS Processing model to a DVC workflow. In the following screenshot, you can see the main stages

  1. The QGIS model in the upper left corner
  2. The Python script exported from the QGIS model builder in the lower left corner
  3. The DVC stages in my dvc.yaml file in the upper right corner (And please ignore the hello world stage. It’s a left over from my first experiment)
  4. The DVC DAG visualizing the sequence of stages. Looks similar to the QGIS model, doesn’t it ;-)

Besides the stage definitions in dvc.yaml, there’s a parameters file:

  n: 10
  size: 0.5

And, of course, the two stages, each as it’s own Python script.

First, which reads the random-points.n parameter to create the desired number of points within the polygon defined in qgis3/data/test.geojson:

import dvc.api

from qgis.core import QgsVectorLayer
from processing.core.Processing import Processing
import processing


params = dvc.api.params_show()
pts_n = params['random-points']['n']

input_vector = QgsVectorLayer("qgis3/data/test.geojson")
output_filename = "qgis3/output/random-points.geojson"

alg_params = {
    'INPUT': input_vector,
    'MIN_DISTANCE': 0,
    'POINTS_NUMBER': pts_n,
    'SEED': None,
    'OUTPUT': output_filename
}'native:randompointsinpolygons', alg_params)

And second, which reads the buffer-points.size parameter to buffer the previously generated points:

import dvc.api
import geopandas as gpd
import matplotlib.pyplot as plt

from qgis.core import QgsVectorLayer
from processing.core.Processing import Processing
import processing


params = dvc.api.params_show()
buffer_size = params['buffer-points']['size']

input_vector = QgsVectorLayer("qgis3/output/random-points.geojson")
output_filename = "qgis3/output/buffered-points.geojson"

alg_params = {
    'DISSOLVE': False,
    'DISTANCE': buffer_size,
    'END_CAP_STYLE': 0,  # Round
    'INPUT': input_vector,
    'JOIN_STYLE': 0,  # Round
    'MITER_LIMIT': 2,
    'SEGMENTS': 5,
    'OUTPUT': output_filename
}'native:buffer', alg_params)

gdf = gpd.read_file(output_filename)


With these things in place, we can use dvc to run the workflow, either from within VSCode or from the command line. Here, you can see the workflow (and how dvc skips stages and fetches results from cache) in action:

If you try it out yourself, let me know what you think.

PyQGIS Jupyter notebooks on Windows using Conda

The QGIS conda packages have been around for a while. One of their use cases, for example, is to allow Linux users to easily install multiple versions of QGIS.

Similarly, we’ve seen posts on using PyQGIS in Jupyter notebooks. However, I find the setup with *.bat files rather tricky.

This post presents a way to set up a conda environment with QGIS that is ready to be used in Jupyter notebooks.

The first steps are to create a new environment and install QGIS. I use mamba for the installation step because it is faster than conda but you can use conda as well:

(base) PS C:\Users\anita> conda create -n qgis python=3.9
(base) PS C:\Users\anita> conda activate qgis
(qgis) PS C:\Users\anita> mamba install -c conda-forge qgis=3.28.2 
(qgis) PS C:\Users\anita> qgis

If we now try to import the qgis module in Python, we get an error:

(qgis) PS C:\Users\anita> python
Python 3.9.15 | packaged by conda-forge | (main, Nov 22 2022, 08:41:22) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import qgis
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'qgis'

To fix this error, we need to get the paths from the Python console inside QGIS:

import sys
['H:/miniconda3/envs/qgis/Library/./python', 'C:/Users/anita/AppData/Roaming/QGIS/QGIS3\\profiles\\default/python', ... ]

This list of paths can be configured as the defaults for our qgis environment using conda develop:

(qgis) PS C:\Users\anita> conda activate base
(base) PS C:\Users\anita> mamba install conda-build -c conda-forge
(base) PS C:\Users\anita> conda develop -n qgis [list of paths from qgis python console] 

With this setup, the import should now work without errors:

(base) PS C:\Users\anita> conda activate qgis
(qgis) PS C:\Users\anita> python
Python 3.9.15 | packaged by conda-forge | (main, Nov 22 2022, 08:41:22) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import qgis

The example Jupyter notebook covers running a QGIS Processing algorithm and visualizing the results in the notebook using GeoPandas:

Head over to Github to find the full instructions:

User defined field names in export from QGIS

Thanks to the sponsoring of the Swiss QGIS User Group, starting from QGIS 3.26 is it possible to override field names in the layer export dialog. Previous to that, QGIS would always export with the technical names from the database, whereas now it’s possible to override with the alias defined in QGIS or any custom name. One use for this in Switzerland — a highly polyglot country — is an export with translated names.

This is done via an additional column “Export name”. For convenience we also added a tri-state checkbox to toggle export names to their alias defined in the layer configuration or back to the field name. If a name is changed by hand the checkbox shows a mixed state.

How to contribute to QField

QField is a community-driven open-source project. It is free to share, use and modify and it will stay like that. The very essence of a community is to help and support each other. And that’s where YOU come into play. To make it work we need your support!

For those who don’t know much about the concept of open source projects, a bit of background. Investing in open-source projects is a technical and ethical decision for Open source is a technological advantage, as we receive input from many developers worldwide who are motivated to work out the best possible software. It prevents our customers from vendor lock-in and allows complete ownership and control of the developed software. And finally, not only financially independent businesses and people should benefit from professional software but also those who might not have the financial means to pay for features, and licences. 

You are not a developer, but you still like to use QField and support it? Good news. You don’t have to be a developer to use, contribute or recommend the app. There are plenty of things that need to be done to help QField to remain the powerful software it is right now and become even better. Here are a few suggestions on how you can give something back.

  1. Review the app ★★★★★ in google’s play store or apple’s app store
  2. Let the world know about it! It doesn’t matter if you’re on Twitter, LinkedIn, Instagram or any other social media platform. Show and tell about where QField helped you. We appreciate every post and we promise to like, share and comment.
  3. Write about your experience and please let us know. Be it in your blog or as a new success story. Insights into field projects are extremely valuable. It helps us to make the app even more efficient for your work, and it helps others to understand the range of applications for QField.
  4. Register for a paid QFieldCloud account. QFieldCloud allows to synchronize and merge the data collected in QField. QFieldCloud is hosted by the makers of QField and by getting an account you help QField too.

Do you want to do something that is more hands-on and directly linked to the app? No problem. 

  1. Help with the documentation. You can document features, or improve the documentation in English. Read the how-to guide to get started.
  2. And if you are multilingual you might consider translating the documentation or the app in your language.
  3. Become a beta tester and be the first to report a bug! When something doesn’t work properly it might be a bug. The quicker we know about it, the faster it can be resolved.
  4. You can ask and answer questions on gis.stackexchange and help others on the user discussions platform.
  5. If you are a developer and you want to get involved in QField development, please refer to the individual documentation for QField, QFieldCloud and QFieldSync.

And now finally for those of you who have the financial means, you can either sponsor a feature or subscribe to one of the monthly sponsorships. By doing so you help get freshly baked QField versions straight to everyone’s devices.

Nothing in it for you? In that case, just drop by to say thank you or have a hot or cold beverage with us next time you meet at a conference and you might make our day!
Want to know more about the idea of community-driven open-source projects and the QGIS project in particular? Check out Nyall Dawson’s blog post about how to effectively get things done in open source!

QGIS Relations, their Widgets and the Plugins of them

This blog post is about QGIS relations and how they are edited in the attribute form with widgets in general, as well as some plugins that override the relations editor widget to improve usability and solve specific use cases. The start is quite basic. If you are already a relation hero, then jump directly to the plugins.

QGIS Relations in General

Let’s have a look at a simple example data model. We have four entities: Building, Apartment, Address and Owner. In UML it looks like this:

  • A building can have none or multiple apartments, but an apartment must to be related to a building. This black box on the left describes the relation strength as a composition. An apartment cannot exist without a building. When a building is demolished, all apartments of it are demolished as well.
  • An apartment needs to be owned by at least one owner. An owner can own none or more apartments. This is a many-to-many relation and this means, it will be normalized by adding a linking (join) table in between.
  • A building can have an address (only one – no multiple entrances in this example). An address can refer to one building.
    Why not making one single table on a one-to-one relation? To ensure their existence independently: When a building is demolished, the address should persist until the new building is constructed.

Creating Relations in QGIS

In QGIS we have now five layers. The four entities and the linking table called “Apartment_Owner”.

Open Project > Properties… > Relations

With Discover Relations the possible relations are detected from the existing layers according to their foreign keys in the database. In this example no CASCADE is defined in the database what means that the relations strength is always “Association”.

Where would “Composition” make sense?

Of course in the relation “Apartment” to “Building”, to ensure that when a feature of “Building” is deleted, the children (“Apartment”) are deleted as well, because they cannot exist without a building. Also a duplication of a feature of “Building” would duplicate the children (“Apartment”) as well.

But as well on the linking (join) table “Apartment_Owner” and its relation to “Apartment” and “Owner” a composition would make sense. Because when a feature of “Apartment” or “Owner” is deleted, the entry in the linking table should be deleted as well. Because this connection does not exist anymore and otherwise this would lead to orphan entries in the linking table.

Walk through the widgets

To demonstrate the relation widgets Relation EditorRelation Reference and Value Relation we make a walk through the digitizing process.

Relation Editor

First we create a “Building” and call it “Garden Tower”. Then we add some “Apartments”.

The “Apartments” are created in the widget called Relation Editor. This shows us a list (similar to the QGIS Attribute Table) of all children (“Apartment”) referencing to this “Building”. We have here activated the possibilities to adddelete and duplicate child-features.

In the widget settings (Right-click on the layer > Properties… > Attribute Form) we see that there are other possibilities to link and unlink child-features as well as zoom to the current child-feature (what only would make sense when they have a geometry).

As well we can set here the cardinality. This will become interesting when we go to the “Owner” to “Apartment” relation. But let’s first have a look at the opposite of what we just did.

Relation Reference

When we open now a feature of “Apartment”, we see that we have a drop down to select the “Building” to reference to.

On the right of this drop down we can see some buttons. Those are for the following functionalities (from left to right):

  • Open the form of the current parent feature (in our case the “Building” feature called “Garden Tower”)
  • Add a new feature on the parent layer (in our case “Building”)
  • Highlight the parent layer (in our case “Building”) on the map
  • Select the parent feature (in our case “Building”) on the map to reference it

In the settings (Right-click on the layer > Properties… > Attribute Form) we see that we choose the configured relation to connect the child (“Apartment”) to the parent (“Building”). This won’t be needed with the widget Value Relation.

Value Relation

The Value Relation does not require a relation at all. We simply choose the “parent” layer (“Building”) its primary key as the key (“t_id”) and a descriptive field as the value (“Description”).

The result shows us a drop down as well to select the parent.

It is much easier to configure, but you can see the limitations. There are no such functionalities to control the parent feature like addidentify on map etc. As well you need to be careful to fulfill the foreign key constraint (you have to choose the correct field to link with). All this is given, when you build a Relation Reference on an existing relation.

Many-to-Many Relations

Now we link some “Owner” to our “Apartment”. We could create new ones like we did it for the “Apartment” in “Building” or we can link existing ones. For linking we choose the yellow link-button on the top of the Relation Editor.

This dialog looks similar to the Relation Editor widget. You have just to select the “Owner” you want to link to the “Apartment” by checking the yellow box. It’s a very powerful tool, but people are often confused about the load of functionality here and the selection that can be difficult to get used to (yellow boxes vs. blue index selection). For this case we extended the Relation Editor widget with a plugin.

Anyway after that we linked our features of the layer “Owner”.

Have you seen the linking table in between? Well, me neither. It’s completely invisible for the end user. This because of the cardinality setting I mentioned already. When we choose the linked table “Owner” instead of “Many to one relation”, then we can create and link the other parent (“Owner”) directly.

One-to-One Relation

A one-to-one relation like we have here between “Building” and “Address” is created in the database more or less like a normal one-to-many relation. This means one of the tables (in our case “Address”) has a foreign key pointing to the parent table (“Building”). There are tricks to fulfill the one-to-one maximum cardinality (like e.g. by setting a UNIQUE constraint on this foreign key column) but still in the QGIS user interface it looks like a one-to-many relation. It’s displayed in a normal Relation Editor widget.

Solutions could be so called “Joins”. Go to the settings (Right-click on the layer > Properties… > Joins)

Here you can join a layer of your choice and add the fields of this other layer (in our case “Address”) to your current feature form (of “Building”). So it appears to the user that it’s the same table containing fields of “Building” and “Address”.

Negative point about those joins are, that they are fault prone. You have to be careful with default values (e.g. on primary keys) of the joined layer. You cannot expect a fully reliable feature form like you have it in the Relation Editor. Here as well, we extended the Relation Editor widget with a plugin.

Plugins for Relation Editor Widgets

Since QGIS 3.18 the base class of the Relation Editor Widgets became abstract, what opened the possibility to use it in PyQGIS and derive it to super nice widgets handling specific use cases and improving the usability.

Linking Relation Editor Widget

As mentioned before, the QGIS stock dialog to link children is full of features but it can be overwhelming and difficult to use. Mostly because of the two selection possibilities in the list. A blue selection is for the currently displayed feature, and a yellow checkbox selection is for the features to be actually linked.

In collaboration with the Model Baker Group we wanted to improve the situation. But as we where unsure how the end solution should look like, so we decided to experiment in a plugin. The result is a link manger dialog, in which features can be linked and unlinked by moving them left and right. The effective link is created or destroyed when the dialog is accepted.

Find more information on the repository

Ordered Relation Editor Widget

Sometimes the order of the children play a role on the project, and you want to have them displayed following that. For that there is the Ordered Relation Editor Widget. You can configure a field in the children to be used to order them. In the given example the field Floor was used to order Apartments. Reordering the fields by Drag&Drop would change the value of the configured field. Display name and optionally a path to an icon to be shown on the list can be configured by expression in the Attribute Form tab in the layer properties (Right-click on the layer > Properties… > Attribute Form).

Find more information on the repository

Document Management System Widgets

Often in QGIS projects there is the need to deal with external documents. This could be for example pictures, documentations or reports about some features. To support that we added two new tables in the project:

  • Documents each document is represented by a row in this table. The table has following fields:
    • id
    • path is the filename of the document.
  • DocumentsFeatures this is a linking (join) table and permits to link a document with one or more features in more layers. The table has following fields:
    • id
    • document_id id of the document.
    • feature_id id of the feature.
    • feature_layer layer of the feature.

Thanks to a QGIS feature named Polymorphic Relations we can link a document with features of multiple layers. The polymorphic relation can evaluate an expression to decide in which table will be the feature to link. Here a screenshot of the relation configuration:

After this configuration in the layers “Apartment” and “Building” it will be possible to link children from the “Documents” table. The document management plugin provides two widgets to simplify the handling of the relation. In the feature side widget the documents are displayed as a grid or list. If possible a preview of the contend is shown and you can add new documents via Drag&Drop from the system file manager. Double-click on a document will open it in the default system viewer.

The second widget is meant to be used in the Feature Form of the “Documents” table, and it permits to handy see, for each document, with which feature from which layer it is linked.

Find more information on the repository

That’s it

Well then. We hope that all the beginners reading this article received some light on QGIS Relations and all the advanced user some inspiration on the immense possibilities you have with QGIS ?

  • Page 1 of 43 ( 841 posts )
  • >>
  • qgis

Back to Top

Sustaining Members