The use of WMS/WMTS layers in a QGIS Cloud map project can significantly degrade the performance of the map display. I have already discussed how to counter this problem in an earlier post. One of the solutions is to load external WMS as background layers. The problem with this approach, however, is that only one WMS background layer can be loaded at a time. If further WMS layers are to be loaded into the map at the same time, this approach cannot be used.

We have a new website!

We recently launched our new website at QGIS.org. It is a ground-up overhaul and provides a fresh take on the first contact point for existing or potential users wishing to engage with the QGIS project and discover its value proposition.

A new strategy for QGIS.org websites

In this blog post, we would like to provide an overview of the goals that we had for building the new QGIS.org website and the bigger picture of how this website update fits into the broader strategy for our website plans for QGIS.

About two years ago, we started experimenting with building a new QGIS.org website based on Hugo. Hugo, as a technology choice, was less important than was our intent to develop a more modern site that addressed our strategic goals.

After some ‘in-house’ (i.e. volunteer-based) work to develop an initial version of the site, we received the go-ahead to use QGIS funds for this and put out a call in October 2023 for a company to support our work. This was ultimately won by Kontur.io, who, together with our volunteers, brought the work into high gear.

Goal 1: Speak to a new audience

Our primary goal was to speak to a new audience. We are confident that QGIS can compete with all of the commercial vendors providing GIS software. We didn’t convey that well on our old website. We feel that QGIS was too apologetic in how it presented itself. We wanted a website which inspires confidence while addressing the needs of a corporate or organisational decision-maker who is looking at the QGIS project during their GIS software selection process.

The old website was very focused on the developer and contributor community. Obviously, those aspects are important since, without our fantastic community, the QGIS project would not exist. The messaging around open source is also important. Yet these ideas are secondary to the idea that QGIS is one of the best (if not the best) desktop GIS applications out there on the market – open-source or otherwise. We need to present it in this professional perspective.

So, the first goal was to change the messaging to focus on QGIS’s value proposition and take a very professional approach to presenting ourselves on the website.

Goal 2: Harmonisation

The second goal was to start the process of harmonising all of our website properties. QGIS.org, over the years, has built many different web properties. For example, there’s the plugins website, the feed, the changelog, the sustaining members website, the lessons website and the certification website, the new resources hub website, the API documentation, the user documentation, the user manual, the training manual, various other documentation efforts, and more. Some of those are combined in one application, There are also some less well-known resources, like our analytics.qgis.org and another one for plugin analytics. In short, we’ve a lot of resources!

With so many different web properties, they’ve devolved over time: each has its own look and feel, navigation approach and how you interact with it. Some of them were translated, and some of them were not. We want to harmonise all of these sites so that the user does not notice any change in user experience when they move from one QGIS-related site to another.

Goal 3: Harmonising deployment

In the underlying process of these changes, we’re also redeploying all of the websites on new servers, which are more up-to-date and use better security and maintenance practices. Plenty of work is happening in the background to ensure that all of the servers are in a better-maintained state, document how they’re maintained, and so on.

Goal 4: A hub and spokes

The objective of the new site design is to allow quick movement between the QGIS auxiliary sites. The QGIS.org site will form a hub that effortlessly takes visitors to whichever QGIS-related site they need to complete the task they are busy with. If you’re moving between these sites, the experience should be seamless. You should not really even be aware that you’re moving between different websites. Other than looking at the URL bar, the user presentation and experience should be harmonious between all of them.

One way we are planning to achieve this is to have a universal menu bar and footer. You will see that in the new website’s design, there is a menu bar across the top. This menu bar has two levels: the top menu and the second level, where the search bar is.

In this second row, auxiliary sites will have their own sub-menu whilst keeping the shared top-level menu. So if you, for example, are moving around in plugins and want to review the plugin list or submit a new plugin, all of that navigation will be on the second line where the search bar is currently. Regardless of which subdomain you are on, the top-level menu bar will be the same, allowing you to easily navigate back to the hub or to another subdomain.

The footer will be unified and shared between all sites, and the cascading style sheets and styling will be unified across all of the QGIS websites.

In the next phase, we will work to achieve this coherence across all the websites, though we still have a few more tweaks to make to the qgis.org site first.

Goal 5: DOTDOTW – do one thing, do one thing well

We plan to break some auxiliary websites apart into separate pieces. So, for example, the changelog management, certification management, sustaining members management, and lessons management are all in one Django app. We will split them into small single-purpose applications using some common UX metaphors so that each is a standalone application that makes it easy for a potential contributor to understand everything the application does. This will also simplify management as we can upgrade each auxiliary site on separate development cycles. We will also finally have semantic URLs, e.g. certification.qgis.org, to take you to the different areas of interest on the site.

The plugins.qgis.org is also going to be refactored so that it just has plugins and not the resource sharing we’ve added in the last few years. The resource sharing will go into its own subdomain. Similarly, the Planet website will get split into its own website (the planet is a blog aggregator or RSS aggregator) that will be in its own managed instance. Some other components (like the analytics) are difficult to split out like this because they’re linked to the same database. We will try to make sure that those are more discoverable and theme them as much as possible to match the rest of the website experience.

Goal 7: Encapsulation

Another goal we had for the QGIS.org makeover was to make the site performant and self-contained. By self-contained, we mean that it should not ‘call’ out to CDN, Google or other platforms for resources like fonts, CSS frameworks, javascript libraries, etc. There were two reasons for this:

1. These platforms often use such resources to track users as they move around the Internet, which we want to avoid as much as possible.
2. We want to wholly manage our site, be able to fix any issues independently and generally follow a path of self-determination.

Our approach also facilitated the creation of a very performant website, as you can see here. We will try to adhere to these principles for the auxiliary site updates we do in the future, too.

What about translations?

The question has come up: Why did we not want to translate the new QGIS.org when it was translated before?

Firstly, we should make it clear that we do not plan to remove translations from the user documentation, the user manual, and so on, where we think they have the most value.

For the main QGIS.org site, we question whether there is a high value in translating it. Here are some reasons why:

1. Lingua franca: If you are an IT manager in a non-English-speaking country and you want to evaluate some software, you’re going to run into a product page that presents itself in English – it is the norm for IT procurement to work in English for reviewing software products and so on.

2. Automation: Automated translations inside browsers are getting better and better. While these translations are still not completely adequate, we think they will be in one or two years’ time.

3. Translation integrity: Our pursuit of Goal 1 means that we would no longer find it acceptable to have partial website translations. We also need to ensure that the wording and phrasing are consistent with the English messaging. We also have concerns about the QA process regarding trust and review – we want to ensure that any translation truly reflects the meaning and intent of the original content and has not been adjusted during the translation process.

4. Cohesion: Our most important point is raised if we go back to this idea of cohesion between the different websites like QGIS.org, plugins.qgis.org and so on. As well as having the same styling, we also don’t want to switch between languages as you hop between the sites. We aim to present them all as one site. If we translate QGIS.org and then take you to our auxiliary sites, e.g., plugins.qgis.org, the feed, or certification pages, which are in English only, the experience is jarring.

So we must either translate everything into all of the same languages, or work in English. Translating everything is a mammoth task for the translators and for us to retrospectively add translation support to each platform. Thus, we prefer the approach of harmonising everything to one language and then focusing our translation efforts on three areas:

1. The application itself,
2. the user manual and
3. the training manuals.

We can leave the rest of the experience in English and instead focus on harmonising, for now, both in terms of look and feel and the technology used.

When we consider everything as one big website and what the bigger plan is, it is hopefully clearer why we didn’t think translating the landing page and QGIS.org was the best approach.

Further funded work

We hope to use more QGIS funding to support this work in the future. We’re also hoping to work again with Kontur to start moving all these auxiliary sites into their own projects, applying our style guidelines to each. Independently of that, Tim (volunteer), Lova (QGIS funded), and others are already getting started with this process.

Helping out

Do you have strong opinions about the website? Contact Tim on the PSC mailing list if you would like to get involved as a volunteer. We would love to hear from designers, word smiths, marketers, information architects, SEO specialists, web developers and those who think they can help us achieve our goals.

Conclusion

We hope our goals and process make sense for everybody and that we were able to lay out a clear, logical argument about why we don’t want to translate the new website quite yet. We want to focus on these overarching goals and then return to them later if they are still a priority for people. Everything we have built is Open Source and available at this repo, where you can also find an issue tracker to report issues and share ideas relating to the new website.

Thanks for reading. Go spatial without compromise

Cheers, Tim, Marco and Anita

What's Changed

• Improve legend's parent/children visual representation
• Insure that exif tags from photo being sketched are transferred onto the resulting drawing
• Fix regression with addition of relationship children against geopackages with FOREIGN KEY constraints
• Fix missing elevation profile chart labels

Full Changelog: v3.3.6...v3.3.7

In the month of June, 23 new plugins were published in the QGIS plugin repository.

Here follows the quick overview in reverse chronological order. If any of the names or short descriptions catches your attention, you can find the direct link to the plugin page in the table below:

If you downloaded Trajectools 2.1 and ran into troubles due to the introduced scikit-mobility and gtfs_functions dependencies, please update to Trajectools 2.2.

This new version makes it easier to set up Trajectools since MovingPandas is pip-installable on most systems nowadays and scikit-mobility and gtfs_functions are now truly optional dependencies. If you don’t install them, you simply will not see the extra algorithms they add:

If you encounter any other issues with Trajectools or have questions regarding its usage, please let me know in the Trajectools Discussions on Github.

We've integrated the Android Fused Location Provider into our app for enhanced location accuracy and efficiency. This update leverages all available location sources to provide faster and more precise location data while optimizing battery usage, ensuring your device stays powered longer. It is currently an opt-in feature, so you will need to enable it in the app settings under Manage GPS Providers. Enable this feature to enjoy improved location-based services and a longer-lasting battery with our latest enhancement!

We brought back the option for centring to GPS position when entering the recording mode. Additionally, we added a new entry into the application settings to disable this behavior if desired.

Between April and May there were 33 new plugins published in the QGIS plugin repository.

Highlights

We would like the use this opportunity to highlight two plugins, Viper (QGIS snake Clone) and Active Break.

Viper allows to emulate in QGIS canvas the popular game Snake, providing a fun time and a bit of nostalgia for the “older” users. However it goes further than that, as it serves the purpose of teaching about geospatial concepts such as geometry objects (points, polygons) with their properties and methods, spatial indexing in the form of R-Tree, but also programming in QGIS, as well as other aspects.

On a more serious tone, if it can be said that, we present Active Break, a plugin that “simply” presents messages at specific time intervals, which can be personalized by the user and range from the more technical such as “save your project”, personal or motivational like quotes from hundreds of people on multiple subjects, or perhaps the most important, routinely reminders to take a break, relax or go have lunch. This considering the long hours we spent daily in front of the computer, with all the physical and mental health, as well as social implications. Congratulations on both authors!

Overview

Here follows the quick overview in reverse chronological order. If any of the names or short descriptions catches your attention, you can find the direct link to the plugin page in the table below:

QField Rapid Mapper is a project for the QField mobile app, which allows emergency responders, civil protection, military, and citizens to assess and report damages from natural catastrophes by quickly sharing geolocated images, videos and audio. QField Rapid Mapper offers real-time data collection, mapping and sharing to help enhance disaster response and coordination.
QField and QFieldCloud are open-source, and OPENGIS.ch is donating the needed QFieldCloud infrastructure and expertise to help map the floods in Ticino in 2024

OPENGIS.ch Supports Flood Mapping Efforts in Ticino

After discussing with the Protezione Civile Locarno e Valle Maggia and the Centro di Competenza per la geoinformazione (CCGEO), we are proud to announce that OPENGIS.ch is donating the necessary QFieldCloud infrastructure and dedicated projects for a rapid crowdsourcing POC to aid in mapping the 2024 floods in Ticino. This crowdsourcing initiative aims to provide essential support to professionals and volunteers working on flood and landslide assessment and recovery.

https://www.rsi.ch/play/embed?urn=urn:rsi:video:2191880&subdivisions=false

Empowering Response with Advanced Technology

What is needed?

Photographing damaged houses and infrastructure is the most critical aspect of this mapping initiative. These images provide crucial information for assessing the extent of the damage, planning rescue and reconstruction operations, and ensuring that resources are allocated effectively. It’s also important to document any submerged or damaged vehicles, as they offer additional insights into the disaster’s impact. During these activities, it’s essential to be careful and respect the privacy and property of others, avoiding capturing license plate numbers or entering destroyed buildings without permission. Using QField Rapid Mapper can contribute to a faster and more coordinated emergency response while ensuring respect for those affected.

The QFieldCloud infrastructure enables efficient, real-time data collection and sharing, ensuring that accurate and up-to-date information is available to all stakeholders involved in the flood response. This effort underscores our commitment to leveraging technology for social good and environmental resilience.

How You Can Get Involved

1. if you don’t have a QFieldCloud account yet, sign up at https://app.qfield.cloud/accounts/signup/
2. fill out the quick participation form at https://forms.gle/dkjZsSWdmCzr9xic8

By participating, you will have access to powerful tools for field data collection and can contribute valuable information to the ongoing efforts in Ticino. All the data collected will be released under the Creative Commons CC0 1.0 public domain license.

Join the Effort

Using QField and QFieldCloud, you can help create detailed maps crucial for understanding the impact of the floods and planning effective recovery strategies. Your contributions will make a significant difference in managing and mitigating the effects of this natural disaster.

Visit our QField Rapid Mapper project page for more information on how QField and QFieldCloud can assist in flood mapping and other field data collection projects.

Together, we can make a difference. Join us in mapping the floods in Ticino and support the community’s recovery efforts.

Last week, I had the pleasure to meet some of the people behind the OGC Moving Features Standard Working group at the IEEE Mobile Data Management Conference (MDM2024). While chatting about the Moving Features (MF) support in MovingPandas, I realized that, after the MF-JSON update & tutorial with official sample post, we never published a complete tutorial on working with MF-JSON encoded data in MovingPandas.

The current MovingPandas development version (to be release as version 0.19) supports:

• Reading MF-JSON MovingPoint (single trajectory features and trajectory collections)
• Reading MF-JSON Trajectory
• Writing MovingPandas Trajectories and TrajectoryCollections to MF-JSON MovingPoint

This means that we can now go full circle: reading — writing — reading.

Reading MF-JSON

Both MF-JSON MovingPoint encoding and Trajectory encoding can be read using the MovingPandas function read_mf_json(). The complete Jupyter notebook for this tutorial is available in the project repo.

Here we read one of the official MF-JSON MovingPoint sample files:

traj = mpd.read_mf_json('data/movingfeatures.json')

Writing MF-JSON

To write MF-JSON, the Trajectory and TrajectoryCollection classes provide a to_mf_json() function:

The resulting Python dictionary in MF-JSON MovingPoint encoding can then be saved to a JSON file, and then read again:

import json
with open('mf1.json', 'w') as json_file:
    json.dump(mf_json, json_file, indent=4)

Similarly, we can read any arbitrary trajectory data set and save it to MF-JSON.

For example, here we use our usual Geolife sample:

gdf = gp.read_file('data/demodata_geolife.gpkg')
tc = mpd.TrajectoryCollection(gdf, 'trajectory_id', t='t')
mf_json = tc.to_mf_json(temporal_columns=['sequence'])

And reading again

import json
with open('mf5.json', 'w') as json_file:
    json.dump(mf_json, json_file, indent=4)
tc = mpd.read_mf_json('mf5.json', traj_id_property='trajectory_id' )

Conclusion

The implemented MF-JSON support covers the basic usage of the encodings. There are some fine details in the standard, such as the distinction of time-varying attribute with linear versus step-wise interpolation, which MovingPandas currently does not support.

If you are working with movement data, I would appreciate if you can give the improved MF-JSON support a spin and report back with your experiences.

What's Changed

• Expose functions for plugin authors to handle global, project, and layer variables

What's Changed

• Provider users with visual feedback when adding a child feature a slow/remote layer
• Avoid double-storing photos taken by QField when using the native camera
• Stabilize value map editor widget filtering
• Fix hard to read QFieldCloud server error reporting details
• Fix wrongly sized raster image decorator
• Fix missing cacert.pem to improve support for gdal's /vsicurl/ dataset access

With the release of GeoPandas 1.0 this month, we’ve been finally able to close a long-standing issue in MovingPandas by adding support for the explore function which provides interactive maps using Folium and Leaflet.

Explore() will be available in the upcoming MovingPandas 0.19 release if your Python environment includes GeoPandas >= 1.0 and Folium. Of course, if you are curious, you can already test this new functionality using the current development version.

This enables users to access interactive trajectory plots even in environments where it is not possible to install geoviews / hvplot (the previously only option for interactive plots in MovingPandas).

I really like the legend for the speed color gradient, but unfortunately, the legend labels are not readable on the dark background map since they lack the semi-transparent white background that has been applied to the scale bar and credits label.

Speaking of reading / interpreting the plots …

You’ve probably seen the claims that AI will help make tools more accessible. Clearly AI can interpret and describe photos, but can it also interpret MovingPandas plots?

ChatGPT 4o interpretations of MovingPandas plots

Not bad.

And what happens if we ask it to interpret the animated GIF from the beginning of the blog post?

So it looks like ChatGPT extracts 12 frames and analyzes them to answer our question:

Its guesses are not completely off but it made up the facts such as that the view shows “how traffic speeds vary over time”.

The problem remains that models such as ChatGPT rather make up interpretations than concede when they do not have enough information to make a reliable statement.

From February to March of this year, 58 new plugins were published in the QGIS plugin repository.

Here follows the quick overview in reverse chronological order. If any of the names or short descriptions catches your attention, you can find the direct link to the plugin page in the table below:

Swiss elevation profiles

Get high-precision elevation profiles in QGIS right from Swisstopo’s official profile service, based on swissALTI3D data!

Thanks to this integration, you can take advantage of existing QGIS features, such as exporting 2d/3d features or distance/elevation tables, as well as displaying profiles directly in QGIS layouts.

Tip: Swiss elevation profiles will be available as long as the Swiss Locator plugin is installed and active. Should you need to turn Swiss elevation profiles off to create other profiles with your own data, go to the Plugin manager and deactivate the plugin in the meantime.

For developers

We’re paving the way for adding custom elevation profiles to QGIS. For that, we’ve added a QGIS profile source registry so that plugin developers can register their own profile sources (e.g., based on profile web services, just like we did here) and make them available for QGIS end users. The registry is available from QGIS 3.38. It’s your turn!

Thanks to the QGIS user group Switzerland for funding this feature!

Swiss vector tiles base maps

Loading Swiss vector tiles is now easier than ever. Just go to the locator bar, type the prefix “chb” (add a white space after that) and you’ll get a list of available and already styled Swiss vector tiles layers. Some of them will even load grouped auxiliary imagery for reference.

Vector tiles will be loaded at the bottom of the QGIS layer tree as base maps, so you will see all your data on top of them.

Vector tiles are optimized for local caching and scale-independent rendering. This also makes it a perfect fit for adding it to your QField project.

There are a couple of different vector tile sets available:

leichte-basiskarte

Light base map

Similar to the leichte-basiskarte layer, but using an older version of the data source and adjusted styles.

leichte-basiskarte-imagery (with WMTS sublayer)

Imagery base map (with WMTS sublayer)

This layer is similar to the leichte-basiskarte-imagery layer, but it uses an older version of the data source and adjusted styles.

Base map

See the official services documentation for details on data sources and styles.

Fixes

Thanks to your feedback, we’ve also fixed some issues. Don’t hesitate to reach out to us at GitHub if you’d like to suggest or report something related to the Swiss Locator plugin.

Happy (and now more powerful) mapping!

Between December 2023 and January 2024, 45 new plugins were published in the QGIS plugin repository. On top of those, we also included another 4 from the last week of November.

Here follows the quick overview in reverse chronological order. If any of the names or short descriptions catches your attention, you can find the direct link to the plugin page in the table below:

What's Changed

• Fix value map editor widget's toggle buttons interface wrongly using value as button label description

Full Changelog: v3.3.3...v3.3.4

What's Changed

• Fix stylus usage on value relation list
• Fix @cloud_* expression variables
• Fix @current_parent_* default value not saved on child creation
• Make value map filtering case insensitive
• Many other small fixes

Full Changelog: v3.3.2...v3.3.3

We are introducing a new type of workspace role and project permission called "Editor". Editors in your workspace will be able to work on your projects without the risk of breaking your GeoPackage layers and QGIS project files.

How does it work?

✅ Editors can:

• Add, update, and delete features in your projects

• Use the mobile app and the QGIS plugin

• Add new files, except for QGIS project files

• Edit files, except for QGIS project files and GeoPackages (without changing the layer schema)

• Remove files, except for QGIS project files and GeoPackages

⛔️ Editors cannot:

• Manipulate QGIS project files, including changing symbology, adding/removing layers, or updating forms. Any changes to a QGIS project file will not be synchronized and will be overridden if the server version of the QGIS project file changes.

• Remove GeoPackages

• Make changes in GeoPackages that would result in creating conflicted copies, such as adding new columns or layers

Who is this new permission type suitable for?

This permission type is ideal for surveyors and others who need to add data without manipulating layer schemas and QGIS project settings.

Next steps

Please upgrade your QGIS plugin to the latest version and head to our dashboard

Editor permission is available on Cloud and Enterprise edition servers.

Read more details in the blog post or in our documentation.

Feeling unheard in GIS work? Mergin Maps streamlines data collection, collaboration, and sharing QGIS projects with a new Editor role for field surveyors.