Read the guest post and congratulate Francesco Bursi, who successfully completed GSOC 2021 project to add virtual raster provider for QGIS with help of mentors Martin Dobias and Peter Petrik.

In this year’s Google Summer of Code (GSoC), I decided to work on the native QGIS raster calculator. Martin Dobias and Peter Petrik volunteered to mentor my work. I’ve been studying Civil Engineering and GeoInformatics at the University of Padua; here I had the opportunity to work both with a lot of GIS software including QGIS. I enjoyed working with QGIS almost immediately because of the possibility to perform complex analysis with a few clicks or with few python commands. Being passionate about programming and enthusiastic about Open Source, I realized that having the possibility to work together with some experienced developers and with an active community was really a great and unique opportunity, so I decided to apply to the GSoC.

Virtual Raster Provider

The existing raster calculator is a powerful tool to perform map algebra that outputs a raster layer, before this work it was possible to take advantage of this tool only by saving the output of this operation as a file. The aim of this year GSoC was to allow users to perform their analysis without creating a new derived raster and taking up disk space and therefore have the result as an on-the-fly computational layer.

Let’s jump to an example and let’s say I want to compute the Chanopy Height Model (CHM), subtracting the Digital Terrain Model (DTM) from the Digital Surface Model (DSM).

I also want to perform some other analysis on the DTM since I want to compute the ideal elevation value for a particular tree planting (disclaimer: the elevation value used is example purposes only, moreover when planting trees you should take into account a lot of factors like slope, aspect, latitude. QGIS, by the way, can really be helpful in this kind of analysis). To do so I will start from the same data and I will create different on-the-fly layers for each calculation, in order to avoid the creation of different files I can take advantage of the new checkbox added to the raster calculator dialog. The computation of CHM is performed in the next screencast and the output layer name is, of course, CHM.

I’ll end up with a new raster layer (CHM) that can be styled as a normal raster and that is not written as an output file to the disk. For some further analysis, from the DTM, I want to obtain the portion of the area with an elevation between 150 and 350 metres above the datum. By applying the following expression to DTM I’ll end up with a raster that has a value of 1 where conditions specified by the expression is TRUE and it will have value of 0 otherwise.

("dtm@1" > 150) AND ("dtm@1" < 350)

I did not select the output layer name intentionally. The resulting layer will be named after the expression used to generate the layer.

Conditional Statement

I also had the opportunity to improve the raster calculator capabilities by adding the possibility to write expressions that involve conditional statements. Taking the already used example, let’s imagine I want to compute the CHM only for the areas of the DTM that are between 150 and 350 metres above the datum. It’s now possible to write an expression as the following one:

if ( ("dtm@1" > 150) AND ("dtm@1" < 350), CHM, -10)

This expression will output a raster with values of the CHM where the conditions are met and value of -10 if the conditions are not met. Since this is a final result of our analysis I’ll store this output as a file to the disk in the form of a GeoTIFF. I’d like to outline that the CHM used in the expression above and in the next screencast is an onn-the-fly computed raster, so it is possible to:

• Take advantage of the virtual raster provider (on-the-fly computed raster) in other analysis with the raster calculator (and with other analysis tools);
• Store the on-the-fly computed raster as a file.

Conclusion

I had fun and I struggled working with QGIS, but I learned a lot of new and interesting things. My pull requests were met with several constructive comments, suggestions and feedback. Some suggestions can be a starting point for future improvements.

• An enhancement for the feature I’ve developed can be the possibility to take advantage of OpenCL acceleration as it has also been suggested in the dev mailing list;
• Another enhancement that concerns the raster calculator and only partially the virtual raster provider would be the possibility to support the creation of output raster with multiple bands with the declaration of multiple formulas. I hope to continue to contribute to the QGIS project in the future.

Significant time saved when route maps distributed with Input and Mergin.

This case study was originally written in Czech. The Czech version can be found here.

Every year, teams of volunteers walk door-to-door through the Czech town of Litomyšl collecting charitable donations. Event organisers define routes for the various volunteer teams by marking-up paper maps with pens. The process has a number of issues both in the making and usage of the maps which organisers worked to overcome by making the maps digital using open source GIS software.

Maps were developed using QGIS and made available on volunteers’ phones using the Input app. Volunteers are now able to easily orientate themselves on maps which clearly show their routes. Organisers have reduced the time it takes to update routes and distribute these to volunteers.

Veronika Peterková works for the Litomyšl Parish Charity, a non-profit organisation providing health and social services to people in need since 1993.

Veronika describes the charity’s activities: “We provide home medical services and nursing care to the residents of Litomyšl and its surrounding villages. This includes helping families where the healthy development of a child is at risk and providing respite stays for clients who are otherwise cared for by their families at home. We provide care for about 1000 clients a year.”

She added: “We also coordinate the activities of volunteers who visit the elderly, help with tutoring children and with various leisure and cultural activities.”

One of the parish charity’s biggest fundraising events is the “Tříkrálová sbírka” (Three Kings Collection), a door-to-door carol-singing collection taking part around the 6th of January each year.

Volunteers participating in the Three Kings Collection.

“The Three Kings Collection is the largest national volunteer event in the Czech Republic. In the Litomyšl region alone, nearly 300 volunteers are involved each year with the carol-singers collecting over 500,000 Czech crowns (~20,000 EUR) in sealed boxes. The proceeds are intended to help the sick, the disabled, the elderly, mothers with children in need and other in-need groups in the local area.” Veronika explains.

The Three Kings Collection is organised by Caritas Czech Republic and at least 10% of its proceeds are allocated for humanitarian aid abroad.

The Challenge

Veronika is responsible for planning routes for the carol-singers so they efficiently visit households in the Litomyšl area. Singers are split into groups and paper maps are provided which show groups which households to visit.

An example of previous paper maps, image courtesy of Farní charita Litomyšl.

The above maps were produced by printing screenshots from a national web mapping provider and marking-up printouts for each of the 50 teams using marker pens.

This method proved to have a number of issues as Veronika describes: “On maps of larger areas, house numbers were not always visible due to the scale. This made it even harder for coordinators not familiar with the area to orient themselves, leading to confusion. Coordinators also found it hard to keep the maps dry and undamaged during unfavourable weather. If new groups signed-up afterwards or others opted-out, we’d have to redo/redivide the areas which would be very time-consuming as the maps would need to be marked-up manually once again.”

The Solution and Implementation

Veronika wanted to try a new solution for organising the 2021 Three Kings Collection with the goal of making volunteer tasks clearer and less reliant on paper maps. She wanted the new solution to allow her to:

• reduce work through the reuse of maps in future Three Kings Collection events
• easily update maps if new groups sign in/out and areas need editing
• allow carol singers to see exactly where they are on the map
• gradually replace paper maps while still allowing the use of paper maps where preferred
• group and colour buildings to be visited on the computer
• record a building’s use (e.g. commercial) to direct volunteers more effectively
• clearly show how areas are assigned so anyone can see who is responsible for a given area

In addition, Veronika wanted the solution to be affordable and work offline without volunteers needing internet connectivity in the field.

Peter Petrík, a regular participant of the Litomyšl Three Kings Collection suggested Veronika try using the Input app for coordinating the collection in 2021. Peter works for Lutra Consulting, the company behind Input and Mergin.

He showed Veronika how to create the maps in QGIS, a free and open source mapping software. Using map data from OpenStreetMap, they created a project showing the buildings to be visited, coloured by their associated volunteer group number.

Houses grouped by team in QGIS, image courtesy of Farní charita Litomyšl.

The styled map was uploaded to Mergin, a collaborative mapping platform, making it readily available for viewing interactively on volunteer’s phones using the Input mobile app. Both QGIS and Input integrate closely with Mergin which meant that maps could be adjusted in QGIS with the resulting changes being visible to volunteers shortly thereafter.

Outcomes

Veronika reflects on the solution: “The solution met all our requirements and the maps we’ve prepared can easily be reused in upcoming events, saving us time. The fact that the new maps were made publicly accessible means volunteers can just download them using Input which makes distributing and updating them very easy.”

Volunteer routes and position information shown in Input, screenshot courtesy of Farní charita Litomyšl.

She adds: “All the districts we wanted to visit were distinguished from each other by colour and we were also pleased to be able to clearly mark the areas not to be visited like industrial areas by colouring them in grey.”

Unfortunately COVID meant that Veronika’s plans changed as she explains: “Using these new methods we were able to prepare for the 2021 Three Kings Collection in a short time. Unfortunately however, the COVID situation meant we could not go out on the streets to use the new maps as intended. We hope that in 2022 we’ll be able to more closely evaluate the positives and negatives of the field aspect of the project.”

She adds: “We already see it’s now much easier to allocate areas of the town to our volunteers in a clear and fair manner using QGIS. Producing printed maps for those who prefer them is also now easy and the maps look much more professional. Those who only wanted to use the Input app could see the same information as on the paper maps, but had the advantage of being able to pinpoint their exact location and clearly see the house numbers of each building.”

Example printed map created for volunteers wanting also paper maps, image courtesy of Farní charita Litomyšl.

She concludes: “Overall we found the solution user-friendly, and appreciated being able to discuss the process with Lutra Consulting who helped us solve issues as required. About a third of our volunteers are interested in using Input, which I consider positive.”

The Litomyšl Parish Charity are on Facebook and Instagram.

Download Mergin Maps Today

The case study presents the C++ development of QGIS Desktop to support rendering of 3D results produced by TUFLOW’s 3D capable solver: TUFLOW FV (10 minute read)

Introduction

TUFLOW is a suite of advanced 1D/2D/3D computer simulation software for flooding, urban drainage, coastal hydraulics, sediment transport, particle tracking and water quality. With over 30 years of continuous development, TUFLOW is internationally recognised as one of the industry leaders for hydraulic modelling accuracy, speed and workflow efficiency.

Lutra Consulting Ltd is a leader in software development for pre- and post-processing of hydraulic and meteorological results in open-source QGIS. We also work on mobile data collection Input App and GIS data synchronization service Mergin

In 2019 the TUFLOW team commissioned us to develop post-processing support for their TUFLOW Flexible Mesh format for QGIS 3.12. The format is 3D stacked mesh, which consists of multiple stacked 2D unstructured meshes each extruded in the vertical direction (levels) by means of a vertical coordinate.

At that time QGIS only supported 2D meshes that defined results on vertices and faces. We had been keen to extend the capabilities of the software stack to support 3D mesh data for a long time so this was an exciting opportunity. Part of the task was also to include rendering support for TUFLOW model results on the QGIS 3D view. The delivery of the project was within one QGIS release cycle (less than 6 months time for users to use it on their projects!)

Contact us at info@lutraconsulting.co.uk if you’d like to discuss the benefits of integrating your flood modelling software more tightly with QGIS or you have some custom QGIS development in mind.

C++ Development Process: From requirement to delivery

Communicate project with the community first

When doing a substantial change in the QGIS codebase, the developer needs to write a technical specification of the QGIS changes for community discussion. QGIS Core Developers (which Lutra is a part of) can give valuable feedback to the overall technical approach and the wider community can raise some usability issues or enhancement proposals. Most importantly, each part of the QGIS code has its lead maintainers, for example Martin Dobias, our CTO, is the maintainer of QGIS 3D code and Peter Petrik is the maintainer of the Mesh layer code. It is a good practice to address the maintainers’, users’ and other developers’ concerns and feedback to ensure the feature can be implemented in QGIS.

So after a thorough discussion about the requirements with the TUFLOW team and analysis of the existing tools for post-processing and display of the TUFLOW FV format we came up with the QGIS Enhancement: Support of 3D layered meshes

The community reaction was very positive and supportive. Time to start coding!

MDAL to support TUFLOW FV NetCDF format

Mesh Data Abstraction Library MDAL is a C++ library for handling unstructured mesh data. It provides a single data model for multiple supported data formats. MDAL is used by QGIS for data access for mesh layers. If you want QGIS to support your data format, you need to have a driver in MDAL that implements it.

We added support for 3D stacked meshes and the TUFLOW FV format in MDAL. When we develop features in MDAL, we focus on quality code, so

• all changes have a proper code review,
• all code has fully automated tests with more than 90% coverage target
• the documentation and manual testing is done after coding

To implement the TUFLOW FV driver for 3D stacked meshes, we added a new API/interface in MDAL, so we needed to follow up with the QGIS changes in QgsMeshLayer and MDAL data-provider.

QGIS C++ Development to support stacked meshes and visualization in 3D

The implementation of large feature changes is best to split into smaller but self-consistent parts. For example the first pull request added the basic support for the new 3D stacked meshes. Each pull request we do has a screenshot or gif/video with the new functionality preview, follows QGIS Coding Standards, has unit tests where necessary and includes the documentation for the functions/classes added in the public interface. Once the request is merged, the features are next day available in nightly builds on all platforms for testing!

Final Steps: feedback, testing, documentation and presentation

When all the features were in QGIS master, the TUFLOW team used windows nightly builds to test the new features and provide feedback. After a small number of iterations, all issues were resolved and implementation signed.

Shortly the new official QGIS release was published and we started promotion of the new features on our social media channels. Also, the features developed under this contract were promoted in the visual QGIS changelog.

• Mesh Layer in 3D
• Mesh Reference Time
• Mesh Vector Streamlines

Benefits for TUFLOW to support QGIS Core C++ Development:

• Reduced development and maintenance costs for tools such as the TUFLOW Viewer QGIS Plugin since the new features are part of the QGIS core
• By being part of the QGIS ecosystem it provides opportunities to approach QGIS users in the flooding and coastal modeling industry to use TUFLOW software
• As a project sponsor, the requirements of the new features meet the present and future needs of the TUFLOW user base.
• At the beginning of the project Lutra showed all the current relevant capabilities of QGIS ecosystem, allowing TUFLOW to be aware of the latest and greatest features
• Allowed TUFLOW to solve upstream bugs in QGIS or MDAL due to the open-source nature of the projects

Benefits for TUFLOW users:

Key benefits made available to TUFLOW users include:

• Being able to work with TUFLOW models using open source GIS on all major operating systems
• A full GIS application to support their data pre-processing
• Logical and intuitive workflows
• Visualisation and post-processing of TUFLOW results natively in QGIS via mesh layer
• The development allows interactive plotting features for 3D results, such as 3D profiles and curtains that can be easily extracted, providing an improved user experience
• Ability to use all native QGIS support and development channels in addition to TUFLOW support
• Integration of internal workflows with powerful native QGIS features including projection support, GDAL/OGR integrations, background maps support (e.g. vector tiles) and printed flood maps.

Further Reading

• TUFLOW webpage
• MDAL and Mesh Layer
• TUFLOW Viewer QGIS Plugin

Do you have any questions or would like to see a demo of the QGIS Mesh Layer? Contact us at info@lutraconsulting.co.uk or schedule a demo call calendly.com/saber-razmjooei/15min

Key words

QGIS, migration, optimised, speed up, fast, hydraulic modelling, water, 2D, 3D, open-source, cost reduction, software development, TUFLOW, TUFLOW FV

You may also like...

Mergin Maps, a field data collection app based on QGIS. Mergin Maps makes field work easy with its simple interface and cloud-based sync. Available on Android, iOS and Windows.

Mesh Data Abstraction Library MDAL proudly joins the OSGeo Community program

We would like to share the excellent news that the OSGeo incubation committee kindly accepted the MDAL project into its Community Program. MDAL is an MIT Licensed C++ Library which integrates into your QGIS installation and is backed by the Lutra Consulting team and the wider community.

MDAL is a low-level library which allows reading unstructured mesh data from various formats. If you’ve never seen a QGIS Mesh Layer, then check out my presentation at FOSS4G 2019.

We kicked-off the MDAL project at the time we were migrating the Crayfish plugin to QGIS version 3. The Crayfish project started in late 2012, has more than 120,000 downloads and opened the way engineers and data scientists to visualize their hydro and meteo-data in QGIS.

QGIS uses MDAL to visualize, analyze and even modify data on unstructured meshes which are used by many hydraulic / numercial modelling solvers. In addition to providing abstraction for complex mesh data structures, MDAL also allows vectoral (e.g. wind speed) and temporal data to be visualised effectively and easily in QGIS.

The MDAL project (and therefore the wider community) has benefitted from generous sponsors such as TUFLOW, 3Di, Hydrotech, DHI, FLO-2D, Artelia, Federal Ministry of Austria for Agriculture, Regions and Tourism and many others. If you’d like to see your formats or workflows supported by QGIS then please consider becoming a sponsor or contact Peter at peter.petrik@lutraconsulting.co.uk

Right now we’re working on some new mesh frame editing tools for QGIS 3.22 (due for release in autumn 2021) and of course support for additional result file formats.

You may also like...

Mergin Maps, a field data collection app based on QGIS. Mergin Maps makes field work easy with its simple interface and cloud-based sync. Available on Android, iOS and Windows.

We’d like to share some exciting news with you about our cloud-based geo-data synchronisation service, Mergin.

In this post we’ll talk both about Mergin the online managed service (Mergin Cloud) and also about the software stack that powers it (the Mergin Software Stack).

Mergin CE

The Mergin Software Stack has been developed and maintained at Lutra Consulting over the past 3 years to power our Mergin Cloud service and has been maturing nicely in production.

We believe a sync service for supporting field-based GIS activities has been a missing piece of the open geospatial puzzle, and as strong advocates of open source software, we’re now sharing the Mergin Software Stack with the community. Therefore, on the 14th of June we released Mergin CE on GitHub. The CE stands for Community Edition.

The release means a fully open solution for field data collection and synchronisation is now possible using QGIS, Input app and Mergin CE.

Mergin CE is released under the AGPL licence and we are open to contributions from others. Looking forward to seeing what the open source community has to offer!

Mergin CE gives you the freedom to deploy, host and manage your own Mergin server on your own infrastructure, giving you complete control over your data. Mergin CE comes without commercial support.

Our main efforts are still very much focussed on the continuous improvement of Mergin Cloud, making it an awesome fully managed service for our customers.

We also now provide Mergin EE (Enterprise Edition) for those who want an on-premises deployment but with extra features like Active Directory integration, commercial support, and/or prefer a licence other than AGPL.

Changes to Mergin Cloud

Releasing Mergin CE got us taking another look at Mergin Cloud’s Community (free of charge) tier. That’s why from today we’re updating Mergin Cloud’s Terms of Service so its free tier can no longer be used to store projects for commercial use. Mergin accounts storing projects for commercial use should now purchase a paid subscription after their initial 14 day evaluation period.

A common surveying setup is a single paid account (providing extra storage for projects) and a handful of free tier accounts used by surveyors for collecting field data. This is still possible because the new Terms only require that the Mergin account hosting/storing/owning the commercial project has a paid subscription.

For example, consider two users: Fred (who uses a free account) and Penny (who uses a paid account). Penny is permitted to use the project Penny/Survey for commercial purposes as it resides on her paid account. Fred (who uses a free account) is permitted to collaborate on the commercial project Penny/Survey as it resides on Penny’s paid account. However, Fred may not use the project Fred/Survey2 for commercial use as it resides on his free account.

In light of the release of Mergin CE, we feel it is fair to encourage those using Mergin Cloud’s free tier for commercial gain to support us with one of our affordable subscriptions. The link also has a number of frequently asked questions relating to this change.

You may also like...

Mergin Maps, a field data collection app based on QGIS. Mergin Maps makes field work easy with its simple interface and cloud-based sync. Available on Android, iOS and Windows.

We are excited to announce that the geodiff library has finally reached version 1.0. We have started to develop geodiff back in 2019 as a part of our efforts to allow synchronisation of changes between the Input mobile app and Mergin platform.

At the core, geodiff library provides functionality to:

• compare a pair of GeoPackage databases and create “diff” files containing changes between them
• apply a “diff” file to a GeoPackage database
• rebase changes in a “diff” file
• invert, concatenate diffs and other utility functions

Thanks to the above low-level operations, any changes to data stored in spatial/non-spatial tables in GeoPackages can be easily transferred to others and applied. And thanks to the “rebase” functionality - inspired by source code management systems like git - we can automatically merge changes from multiple users capturing data offline in Input/Mergin (see our recent blog post that covers rebasing for more).

The library is written in C++, providing stable C API and offering Python bindings as well (look for pygeodiff package in pip). It also comes with a command line interface tool geodiff covering all major features. The whole package has a very permissive MIT license.

Support for drivers

Initially, geodiff library only worked with SQLite / GeoPackage files. This has changed with the version 1.0 - geodiff supports drivers, allowing use of different database backends to compare and apply diffs. In the 1.0 release we have added PostGIS driver in addition to SQLite/GeoPackage driver.

This means that users can compare tables or apply diffs in PostGIS databases using the same APIs as with GeoPackages. And not only that - diff files are compatible across different drivers. That means it is possible to take a diff file from a GeoPackage and apply it to PostGIS database!

Using the PostGIS driver we were able to create mergin-db-sync tool as a companion to Mergin platform. With DB sync, one can keep a local PostGIS database always in sync with a project in Mergin, supporting automatic transfer of changes from Mergin to PostGIS and the other way round as well - from PostGIS to back Mergin.

Try it

The library is hosted on GitHub in lutraconsulting/geodiff repository. We would love to hear your feedback!

Stay tuned for more!

As announced earlier, next week we will be open sourcing Mergin, our platform for easy sharing of spatial data in teams (whether they are in office or in the field). If you have not heard about Mergin platform yet, please have a look at the Mergin website, try Mergin plugin for QGIS and Input app, a mobile app based on QGIS for iPhone/iPad and Android devices. Since the initial release in early 2019, Mergin and Input have been used by thousands of users around the world.

At Lutra Consulting, we are dedicated to improving free and open source software for geospatial. We will be releasing Mergin as open source to solve another missing piece in the puzzle, providing open source end-to-end solution for mobile data capture for QGIS users. Watch our blog and Twitter for further updates!

People often ask whether the Mergin service and the Input app can deal with multiple team members doing edits at the same time.

They happily find out that the answer is yes - it is one of the core features that greatly simplifies life of our users. In this post we will shed some light on how things work behind the scenes.

Getting started

Let’s think of a simple project directory that needs to be synchronised between multiple desktop or mobile users, containing just two files:

• a QGIS project file my-project.qgz that sets up map layers, styling, …
• a GeoPackage file my-data.gpkg containing all GIS data

Our sample GIS data will contain a tree survey table, containing location, species and age of various trees:

When users edit data in my-data.gpkg, the traditional cloud storage solutions (such as Dropbox, Google Drive, Microsoft OneDrive and others) simply copy the modified files there. They do not understand the file content though - so if two people modify the same file, they have no way of knowing how to merge changes together. In the worse case, when two versions of the same file are uploaded, they keep just the version which was synchronised last. Or slightly better, they resort to creation of conflicting copies which need to be manually merged later. As one can imagine, merging and consolidating modifications from multiple GeoPackages back to one copy is a slow, tedious and error-prone job.

the Mergin service has been designed to understand spatial data, especially GeoPackages that are becoming the most popular format to store vector & attribute data. This is thanks to the open source geodiff library that we have developed while working on Mergin.

Synchronising data using “diffs”

The first trick is that synchronisation of GeoPackage files between Mergin server and clients (Input app, QGIS or other apps) only transfers actual changes in tables (“diffs” in technical jargon).

Our Mergin project with the tree survey has been prepared and downloaded by users. Jack did a field survey and he added or updated some rows in the survey table (changes highlighted in yellow and green):

After pressing sync button, his changes are detected and uploaded to Mergin, encoded as a list of changes to the survey table:

Another user, Jill, also downloaded the tree survey project to her mobile device prior to Jack’s changes. When Jill synchronises the project to get the latest version, the changes as uploaded by Jack are downloaded and applied to her local copy of the project, getting the same data as seen by Jack.

At this point, the advantage of uploading/download only changes in tables may not seem obvious besides saving some network bandwidth… Read on to learn how this is used to support multi-user editing.

Merging changes from multiple users

So far we have expected that Jill does not have any pending changes to sync, so that was easy. Now let’s assume that Jill has also done some changes on her device:

Here comes the more tricky part - how do we merge changes from Jack and Jill back to a single table:

In Mergin, cases that require merging changes from multiple users are handled by the “rebase” operation, a concept we have borrowed from version control systems for source code.

Let’s assume that Jack has synchronised his changes first. Later, when Jill synchronises her changes, a couple of things happen on her device before uploading the changes: Jill’s changes will be temporarily undone, Jack’s changes get applied, and finally Jill’s changes are re-applied after being rebased on top of Jack’s changes.

What does it mean to rebase someone’s changes? There are a couple of possible edit conflicts that could happen between rows of a database table with matching IDs (insert/insert, update/delete, delete/delete, update/update). These edit conflicts need to be resolved in order to be able to merge changes from multiple users.

In our example, both Jack and Jill have added a row with ID = 4. This is not allowed, and therefore Jill’s new row ID will get changed to ID = 5 (any unused ID would do). As a result, here’s how the merged table will look at the end - combining changes of both users:

If both Jack and Jill modified the same row (the update/update edit conflict), we can only accept one edit automatically. The conflicting edit of the other user is written to a special conflict file and uploaded to Mergin, so no data gets lost, and the conflict can be later inspected by the project admin. Fortunately, this kind of conflict does not happen often if the survey work is well planned to avoid users simultaneously modifying the same features within the GeoPackage data.

What if conflict files appear

There are some cases when automatic merging is not supported. In those cases, Mergin is unable to find out details about changes in the data file(s) and has to resort to creation of a conflicting copy which gets uploaded to Mergin project along the original data file(s). In particular the problems may appear when:

• Other format than GeoPackage is used for data storage (e.g. shapefiles)
• Database or table structure is changed (e.g. adding new columns or new tables)

In the future, these limitation may be removed, but at this point it is good to keep them in mind.

If you plan to change structure of the survey tables and the project is already being used on multiple devices, it may be a good idea to create a new Mergin project with the modified database structure and instruct users to switch to the new project. Otherwise conflict files may start popping up as long as some users have older version of the project, adding more manual work to collate data.

You may also like...

Mergin Maps, a field data collection app based on QGIS. Mergin Maps makes field work easy with its simple interface and cloud-based sync. Available on Android, iOS and Windows.

It happens that when you collect data and then checking it in the office on your desktop using QGIS, the points are misplaced and shifted. This blog post explains the possible root cause of this issue? (Read time 5 min)

This article follows the help document about the projections and coordinate reference system handling in QGIS.

The accuracy of the captured points is affected by two main factors

• GPS receiver and accuracy
• Selection of coordinate reference systems used in the project

Lets take a closer look at both problems in context of field surveys.

GPS accuracy

GPS accuracy depends on the quality of your GPS receiver and the number of visible GPS satellites your receiver can use at the moment of capturing the point.

When you load the map in Input app, the bottom bar contains the GPS marker with a coloured dot. The dot can have the following three colours:

• green: The actual accuracy is below the threshold
• orange: The actual accuracy is above the threshold
• red: The GPS is unavailable

For different use cases, acceptable accuracy is different. So the threshold for the colour scheme could be adjusted in the Input app settings. Always adjust the settings based on your project needs and check the GPS accuracy when capturing data.

The GPS receiver itself can be either improved by usage of device with a better internal hardware or usage of powerful external GPS receivers If you want to use the external GPS receiver, read the following help article for setup.

Projection problems

First of all, there could be multiple problems with setup of coordinate reference systems and transformations. To solve it, you need to load the project in QGIS, using Mergin Plugin and check for various situations as described in this help article.

Input app checks for missing datum shift files or other transformation problems and notify you once at the project load by following message.

To be able to use the datum grid shift in your mobile app:

• Copy the proj folder from your QGIS working directory (see help page for different platforms)
• Paste the folder to your survey project downloaded fromt he Mergin server
• Sync the changes

For our example with the British national grid on Windows, the grid file is called OSTN15_NTv2_OSGBtoETRS.gsb and if the Mergin project is in C:\users\qgis\myproject then it should be copied to C:\users\qgis\myproject\proj directory and synchronised by the Mergin service to the Input app.

Notes:

• This is one-off process. Input app will transfer the grid shift datum to its own working directory on your mobile device.
• There might be more than one datum grid shift in your QGIS working directory. Use the appropriate one for your survey project.

You can find a short summary of this article on the Input app help pages

In this post, we will explore the new feature in the Input app which allows you to record and display photo’s geotag information (e.g. direction, longitude and latitude).

Photos’ metadata

When users take photos in the field, they often would like to record extra information which can help convey a better understanding and awareness of the surroundings. Recent mobile devices allow users to record photo direction, location, time stamp, camera settings, etc when taking photos. This information is often optional or restricted by default (due to privacy) within the mobile settings.

For surveying and data collection, this information can add extra dimension and context. For example, if you are surveying a bat nesting, it is useful to know the directions of the photos you have taken. This will help identifying the site easily in the subsequent site visit.

Geotag information is also useful metadata to have attached to your photos. There are other GIS or non-GIS applications which can read and interoperate the information.

In the recent version of the Input app, we have added a feature which allows you record and display the geotag information. Combined with QGIS styling, you can create a very informative symbology to display the information while you are capturing it in the field.

Before you start

To be able to capture geotag information, you need to enable your Camera app to use location. For that:

• in Android, from Settings > Apps and notifications > (see all) Camera and under Permission ensure you allow Location

  

• in iOS, from Settings > Privacy > Location Services > Camera and the Precise Location is enabled.

  

Quick start

If you want to record photos with directions as shown below, you can follow the following steps:

• Log into Mergin (or sign up if you have not yet registered)
• Brows to photo survey project
• On the top right-click on Clone to make a copy of your project in your account. You can choose a different project name:

• Download and install the Input app

• Select My projects and log in using your Mergin credentials

• Download the newly created project from the earlier step

• Start recording points and add photos, you should see photo direction

More details

The project configuration is done in QGIS. The form has been set up to allow you take photos using Attachment widget. To learn more about different form edit tools in Input app and how to set the up in QGIS, see the Input app help pages.

There are multiple fields to extract geotag information from the photo, as soon as you add the photo either using the camera or the gallery:

• Direction: read_exif_img_direction(@project_home + '/' + "photo")
• Latitude: read_exif_latitude(@project_home + '/' + "photo")
• Longitude: read_exif_longitude(@project_home + '/' + "photo")

As noted, all the above functions take the path to the photo (@project_home + '/' + "photo") and return different metadata related to the image.

In addition to the form, the layer styling has been modified to resemble the direction of the camera and field of view.

To set the camera icon and direction of the camera:

• For the point styling, select SVG Marker
• From the list of SVGs, select the camera icon. (ensure to embed the SVG to the project, otherwise it will appear as a question mark in the Input app.)
• For the Rotation, select direction field

To add field of view:

• Add another symbol layer to your point
• For Symbol layer type select Geometry Generator
• For Geometry type select Polygon / MultiPolygon
• For the expression, type: wedge_buffer(center:=$geometry,azimuth:= "direction",width:=45,outer_radius:=0.0008)
• For Symbol layer type, select Shapeburst Fill

Feedback and suggestions

Input, a field data collection app based on QGIS. Input makes field work easy with its simple interface and cloud-based sync. Available on Android and iOS.

If you would like to add a new feature or suggestions to improve the app, do not hesitate to contact us on info@lutraconsulting.co.uk

Just few weeks ago, QGIS 3.18 has been released - the first version to include support for point cloud data, thanks to the great support from the QGIS community in our joint crowdfunding campaign with North Road and Hobu.

We have received a lot of feedback from users and we would like to summarise the most common problems people have faced, and add a couple of tips on useful features that are otherwise easy to overlook.

1. I am unable to load LAS/LAZ files

If your QGIS installation does not recognize .las or .laz files (which are the two point cloud formats that we currently support in QGIS), the most likely source of the problem will be that the PDAL library needed for reading LAS/LAZ is missing in your installation. Unfortunately not all installers include it at this point. Particularly on Windows, there are several options how to install QGIS, and only one choice is the right one for PDAL support. At the time of writing (April 2021), you need to download installer from section called “Standalone installers from OSGeo4W testing packages (MSI)”, here’s a screenshot of what to look for:

On macOS the official all-in-one installers include point cloud support. On Linux, PDAL support depends on the particular distribution/packages, but probably most of them include point PDAL library.

2. Point cloud is completely flat in 3D

It may happen that you load a point cloud layer, then open the 3D map view and the point is displayed as a flat surface like on this screenshot:

The reason for this is that the 3D renderer is not enabled for your point cloud layer. To enable 3D renderer, open the Layer Styling panel (there’s F7 shortcut to open it!), then switch to the second tab (“3D View” - with a cube icon) and change the “No Rendering” option to some other option - for example “Classification” in case your point cloud is classified. You should then see your point cloud in 3D.

3. Point cloud is rendered twice - in 3D and in 2D (“flat”)

Commonly when people open 3D view with a point cloud, they may see the point cloud rendered twice, like in the following screenshot:

The reason is that both 3D rendering and 2D rendering of point cloud is enabled, and therefore the layer is also rendered as a 2D map texture on top of terrain (which is flat by default). An easy way how to fix this is to set 2D rendering of the point cloud layer to “Extent Only” in Layer Styling panel (in the first tab):

If the dashed rectangle marking the extent is still bothering you, it is possible to change the line symbol to use white (or transparent) colour.

Hopefully in near future we would address unexpected behaviour and layers with a 3D renderer defined would not be rendered as 2D.

4. I still can’t see my point cloud in 3D view

It could happen that if your point cloud is for a small area, yet the elevation of points is relatively high: when you first open 3D view or when you click “Zoom Full” button, the view may get zoomed too close and the actual point cloud data may be behind the camera. Try zooming out a bit to see if it helps. (This is a bug in QGIS - at this point “zoom full” ignores extra entities and only takes into account terrain.)

5. Enable “Eye Dome Lighting” in 3D view

For a much better 3D perception of your point cloud, try clicking the “Options” button (with a wrench icon) in the toolbar of 3D view and enable “Show Eye Dome Lighting” in the pop-up menu. This will apply extra post-processing that adds slight shading based on the positions of nearby points, and adds silhouettes when there is a sudden change in depth:

As soon as you zoom into your point cloud more, to the point when individual points can be seen, the eye dome lighting effect will start to disappear. You can try experimenting with the point size (in Layer Panel, 3D View tab) - increasing the point size will help.

- A view with point size 2.0 pixels

- The same view with point size 6.0 pixels

6. Try the new camera navigation mode in 3D view

In QGIS 3.18 we have added a new “Walk Mode” camera navigation mode that is much better suited for inspection of point clouds (compared to the default “Terrain Based” camera navigation mode). Open 3D map view configuration dialogue, pick “Camera & Skybox” tab and set it here:

7. Use elevation scaling and offset to your advantage

Sometimes it is useful to modify offset and/or scale of the elevation of points (Z values). For example, if the point elevations do not match your other 3D data, or maybe you have source data where X,Y coordinates are in meters and Z coordinate is in feet!

Another case when this can be useful, is when your point cloud data are further away from the terrain and the default “Terrain Based” navigation mode does not work nicely - it expects that data are near the terrain, and the camera rotates around a point terrain, which may feel strange when browsing point clouds. A workaround is to apply offset to the point cloud layer to move the points near the terrain. For example, this is a point cloud which is roughly at 200 meters elevation (the grey plane is the terrain):

When an offset of -200 is applied to the point cloud in Layer Styling panel, data show up much closer to the terrain and camera navigation feels more natural:

8. Try circular points in 2D maps

By default QGIS draws points as squares as this is the fastest option. But for higher quality output you may want to change point symbol style to circle in Layer Styling panel, which makes things look a little less jagged:

– using squares – using circles

At this point we always use square points in 3D views - in the future we will likely offer circular points in 3D views as well.

9. Give us your feedback

We would love to hear from you about your experience with point clouds in QGIS so far, what features you are missing or what problems you have encountered - feel free to drop us a mail at info@lutraconsulting.co.uk. If you think you have found a bug, best to file an issue for it in the QGIS GitHub repository.

With the QGIS 3.18 release, we know we are only at the beginning of a long journey to provide great point cloud support to the users. The decreasing cost of laser scanning (LIDAR) hardware and increasing availability of photogrammetric methods means that we will be be seeing point cloud data in GIS more and more often. There is still a lot of functionality missing for efficient work with raw point clouds, for easy processing of data and we are still using only a fraction of what the PDAL point cloud library offers. We are dedicated to provide first class support for point clouds in QGIS - however this cannot be done without funding. Therefore, if you would like to help us to push point clouds in QGIS to the next level, please do not hesitate to contact us at info@lutraconsulting.co.uk.

You may also like...

Mergin Maps, a field data collection app based on QGIS. Mergin Maps makes field work easy with its simple interface and cloud-based sync. Available on Android, iOS and Windows.