We have been continuing our work with the Flagship sponsor of QGIS – Felt 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!

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  . This opens a floating catalog browser panel which allows you to interactively search Soar’s content while working on your map.

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.

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.

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:

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!

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:

• Felt’s Blog about the QGIS Plugin
• Installation Guide
• Getting Started for QGIS Users

North Road are proud to announce the official release of SLYR Community Edition, a new open-source version of our powerful SLYR ESRI to Open Source compatibility suite. The Community Edition is available for download from the official QGIS plugin repository today, for QGIS versions 3.4 and above. It supports automated conversion of ESRI .style symbol databases, including conversion of markers, fills, line styles and color ramps to their closest QGIS symbology equivalent, allowing users to instantly transition their style libraries into QGIS!

If you’ve followed our work in the past, it will come as no surprise to hear that North Road are passionate about open source geospatial, and for reducing the barriers which users encounter when moving to open-source software. We see our SLYR tool as an integral part of this process, and the licensed version of the plugin currently supports automated conversion of MXD, LYR, PMF, and other ESRI-specific formats to QGIS documents.

Our intention all along has been to make this tool freely available for all users of open-source geospatial software, and to release our work under a permissive, open-source license so that other projects can take advantage of our reverse engineering efforts. That’s why we made an “open source pledge” a fundamental part of our SLYR tool development! By the terms of this pledge, exactly six months after we hit staged preset funding levels we will open-source more components of the code and update the community version of the plugin accordingly. (This approach gives motivated organisations instant access to the full functionality of the SLYR tool via a license purchase, or free access to a subset of this functionality via the community edition of the plugin. It allows us to heavily invest in further reverse-engineering efforts and improvements to the plugin, to QGIS, and to the wider open-source geospatial community.)

If you’re keen to explore transitioning your workplace from ESRI to open-source, send us an email to discuss what we can offer! North Road staff have years of experience in implementing open-source geospatial solutions within commercial workplaces, and for setting up dual commercial-and-open-source friendly environments.

As we discussed in QGIS 3 is under way, the QGIS project is working toward the next major version of the application and these developments have major impact on any custom scripts or plugins you’ve developed for QGIS.

We’re now just over a week into this work, and already there’s been tons of API breaking changes landing the code base. In this post we’ll explore some of these changes, what’s motivated them, and what they mean for your scripts.

The best source for keeping track of these breaking changes is to watch the API break documentation on GitHub. This file is updated whenever a change lands which potentially breaks plugins/scripts, and will eventually become a low-level guide to porting plugins to QGIS 3.0.

API clean-ups

So far, lots of the changes which have landed have related to cleaning up the existing API. These include:

Removal of deprecated API calls

The API has been frozen since QGIS 2.0 was released in 2013, and in the years since then many things have changed. As a result, different parts of the API were deprecated along the way as newer, better ways of doing things were introduced. The deprecated code was left intact so that QGIS 2.x plugins would still all function correctly. By removing these older, deprecated code paths it enables the QGIS developers to streamline the code, remove hacky workarounds, untested methods, and just generally “clean things up”. As an example, the older labelling system which pre-dates QGIS 2.0 (it had no collision detection, no curved labels, no fancy data defined properties or rule based labelling!) was still floating around just in case someone tried to open a QGIS 1.8 project. That’s all gone now, culling over 5000 lines of outdated, unmaintained code. Chances are this won’t affect your plugins in the slightest. Other removals, like the removal of QgsMapRenderer (the renderer used before multi-threaded rendering was introduced) likely have a much larger impact, as many scripts and plugins were still using QgsMapRenderer classes and calls. These all need to be migrated to the new QgsMapRendererJob and QgsMapSettings classes.

Renaming things for consistency

Consistent naming helps keep the API predictable and more user friendly. Lots of changes have landed so far to make the naming of classes and methods more consistent. These include things like:

• Making sure names use consistent capitalization. Eg, there was previously methods named “writeXML” and “writeXml”. These have all been renamed to consistently use camel case, including for acronyms. (In case you’re wondering – this convention is used to follow the Qt library conventions).
• Consistent use of terms. The API previously used a mix of “CRS” and “SRS” for similar purposes – it now consistently uses “CRS” for a coordinate reference system.
• Removal of abbreviations. Lots of abbreviated words have been removed from the names, eg “destCrs” has become “destinationCrs”. The API wasn’t consistently using the same abbreviations (ie “dest”/”dst”/”destination”), so it was decided to remove all use of abbreviated words and replace them with the full word. This helps keep things predictable, and is also a bit friendlier for non-native English speakers.

The naming changes all need to be addressed to make existing scripts and plugins compatible with QGIS 3.0. It’s potentially quite a lot of work for plugin developers, but in the long term it will make the API easier to use.

Changes to return and argument types

There’s also been lots of changes relating to the types of objects returned by functions, or the types of objects used as function arguments. Most of these involve changing the c++ types from pointers to references, or from references to copies. These changes are being made to strengthen the API and avoid potential crashes. In most cases they don’t have any affect on PyQGIS code, with some exceptions:

• Don’t pass Python “None” objects as QgsCoordinateReferenceSystems or as QgsCoordinateTransforms. In QGIS 3.0 you must pass invalid QgsCoordinateReferenceSystem objects (“QgsCoordinateReferenceSystem()”) or invalid QgsCoordinateTransform (“QgsCoordinateTransform()”) objects instead.

Transparent caching of CRS creation

The existing QgsCRSCache class has been removed. This class was used to cache the expensive results of initializing a QgsCoordinateReferenceSystem object, so that creating the same CRS could be done instantly and avoid slow databases lookups. In QGIS 3.0 this caching is now handled transparently, so there is no longer a need for the separate QgsCRSCache and it has been removed. If you were using QgsCRSCache in your PyQGIS code, it will need to be removed and replaced with the standard QgsCoordinateReferenceSystem constructors.

This change has the benefit that many existing plugins which were not explicitly using QgsCRSCache will now gain the benefits of the faster caching mechanism – potentially this could dramatically speed up existing plugin algorithms.

In summary

The QGIS developers have been busy fixing, improving and cleaning up the PyQGIS API. We recognise that these changes result in significant work for plugin and script developers, so we’re committed to providing quality documentation for how to adapt your code for these changes, and we will also investigate the use of automated tools to help ease your code transition to QGIS 3.0. We aren’t making changes lightly, but instead are carefully refining the API to make it more predictable, streamlined and stable.

If you’d like assistance with (or to outsource) the transition of your existing QGIS scripts and plugins to QGIS 3.0, just contact us at North Road to discuss. Every day we’re directly involved in the changes moving to QGIS 3.0, so we’re ideally placed to make this transition painless for you!

With the imminent release of QGIS 2.16, the development attention has now shifted to the next scheduled release – QGIS 3.0! If you haven’t been following the discussion surrounding this I’m going to try and summarise what exactly 3.0 means and how it will impact any scripts or plugins you’ve developed for QGIS.

QGIS 3.0 is the first major QGIS release since 2.0 was released way back in September 2013. Since that release so much has changed in QGIS… a quick glance over the release notes for 2.14 shows that even for this single point release there’s been hundreds of changes. Despite this, for all 2.x releases the PyQGIS API has remained stable, and a plugin or script which was developed for use in QGIS 2.0 will still work in QGIS 2.16.

Version 3.0 will introduce the first PyQGIS API break since 2013. An API break like this is required to move QGIS to newer libraries such as Qt 5 and Python 3, and allows the development team the flexibility to tackle long-standing issues and limitations which cannot be fixed using the 2.x API. Unfortunately, the side effect of this API break is that the scripts and plugins which you use in QGIS 2.x will no longer work when QGIS 3.0 is released!

Numerous API breaking changes have already started to flow into QGIS, and 2.16 isn’t even yet publicly available. The best way to track these changes is to keep an eye on the “API changes” documentation.  This document describes all the changes which are flowing in which affect PyQGIS code, and describe how best they should be addressed by plugin and script maintainers. Some changes are quite trivial and easy to update code for, others are more extreme (such as changes surrounding moving to PyQt5 and Python 3) and may require significant time to adapt for.

I’d encourage all plugin and script developers to keep watching the API break documentation, and subscribe to the developers list for additional information about required changes as they are introduced.

If you’re looking for assistance or to outsource adaptation of your plugins and scripts to QGIS 3.0 – the team at North Road are ideally placed to assist! Our team includes some of the most experienced QGIS developers who are directly involved with the development of QGIS 3.0, so you can be confident knowing that your code is in good hands. Just contact us to discuss your QGIS development requirements.

You can read more about QGIS 3.0 API changes in The road to QGIS 3.0 – part 1.