Some time ago, I have become a freelancer worker. For this reason, I decided to move away from wordpress.com and this kind of hobby blog and make a bit more professional website. It took some time, but it’s ready now!
I have move all the blog content to the new website. When it makes sense, I will try to update it to newer versions of QGIS and create new content regularly. Please follow me there. If you were following me using the RSS Feed, you can start using the following URL.
At OPENGIS.CH, we’ve been working lately on improving the DXF Export QGIS functionality for the upcoming release 3.38. In the meantime, we’ve also added nice UX enhancements for making it easier and much more powerful to use!
Let’s see a short review.
DXF Export app dialog and processing algorithm harmonized
You can use either the app dialog or the processing algorithm, both of them offer you equivalent functionality. They are now completely harmonized!
Export settings can now be exported to an XML file
You can now have multiple settings per project available in XML, making it possible to reuse them in your workflows or share them with colleagues.
All settings are now well remembered between dialog sessions
QGIS users told us there were some dialog options that were not remembered between QGIS sessions and had to be reconfigured each time. That’s no longer the case, making it easier to reuse previous choices.
“Output layer attribute” column is now always visible in the DXF Export layer tree
We’ve made sure that you won’t miss it anymore.
Possibility to export only the current map selection
Filter features to be exported via layer selection, and even combine this filter with the existing map extent one.
Empty layers are no longer exported to DXF
When applying spatial filters like feature selection and map extent, you might end up with empty layers to be exported. Well, those won’t be exported anymore, producing cleaner DXF output files for you.
Possibility to override the export name of individual layers
It’s often the case where your layer names are not clean and tidy to be displayed. From now on, you can easily specify how your output DXF layers should be named, without altering your original project layers.
We’ve also fixed some minor UX bugs and annoyances that were present when exporting layers to DXF format, so that we can enjoy using it. Happy DXF exporting!
We would like to thank the Swiss QGIS user group for giving us the possibility to improve the important DXF part of QGIS
Thanks to our generous donors and sustaining members, we are in the wonderful position to be able to further extend our 2024 Grant Programme and to fund an additional project that came in very close 6th in the voting results:
On behalf of the QGIS.ORG project, I would like to thank the Danish User Group who stepped up and increased their support to Flagship level, joining or recurring Flagship member Felt and all our wonderful sustaining members and donors.
with € 4,500 missing to be be funded to make it possible to store encrypted credentials in a PostgreSQL database. This improvement targets QGIS Server, particularly multi-instance setups using kubernetes, with potential QGIS Desktop improvements down the road.
If you want to help make this improvement a reality, please get in touch.
Of course, the same applies if you want to help fund any of the remaining proposals:
Trajectools continues growing. Lately, we have started expanding towards public transport analysis. The algorithms available through the current Trajectools development version are courtesy of the gtfs_functions library.
There are a couple of existing plugins that deal with GTFS. However, in my experience, they either don’t integrate with Processing and/or don’t provide the functions I was expecting.
So far, we have two GTFS algorithms to cover essential public transport analysis needs:
The “Extract shapes” algorithm gives us the public transport routes:
The “Extract segments” algorithm has one more options. In addition to extracting the segments between public transport stops, it can also enrich the segments with the scheduled vehicle speeds:
Here you can see the scheduled speeds:
To show the stops, we can put marker line markers on the segment start and end locations:
The segments contain route information and stop names, so these can be extracted and used for labeling as well:
With the QGIS Grant Programme 2023, we were able to support four proposals in the first round and an additional two proposals through the second round that are aimed to improve the QGIS project, including software, infrastructure, and documentation. The following reports summarize the work performed in the proposals.
– 162 bugreports and feature requests which were already fixed or implemented – 29 bugreports and feature requests which are invalid (data issues, wrong use of functionality, etc) – 57 duplicate bugreports and feature requests – 5 won’t fix bugreports – 5 bugreports were converted to feature requests – 33 tickets were closed (does not contain steps to reproduce, test data and no feedback was provided within several month)
Additionally we ensured that all tickets has correct tags assigned to to make them easier to find.
Existing Processing algorithms Voronoi Polygons and Delaunay Triangulation have been ported to C++ and now use GEOS instead of the unmaintained Python module. Both algorithms have been given additional parameters to disable post-processing step (adding attributes of input points for Voronoi polygons and adding feature IDs of the 3 points forming a triangle for Delaunay triangulation) and thus improve algorithm performance. The Concave Hull algorithm has been ported to C++ and uses GEOS for QGIS builds with GEOS >= 3.11, while a port of the existing implementation based on Delaunay triangulation is used for builds with older GEOS versions.
Two algorithms for generating XYZ tiles (directory and MBTiles variants) have been ported to C++ using a safer and cleaner multi-threading approach.
The Align Rasters tool (available from the Raster → Align Rasters menu), which was not exposed to Processing, has been removed and a new Processing algorithm with the same functionality has been added. To make this possible, we have added a new QgsProcessingParameterAlignRasterLayers parameter type to Processing, which provides an adapter to QList<QgsAlignRaster::Item>. The “Raster” menu item now opens the Processing algorithm. We have also added a separate, simplified modeler-only version of the algorithm that accepts a single raster to align and returns a single raster layer output.
The existing Raster Calculator algorithm has been ported to C++. The algorithm now has two variants: a toolbox version that works the same way as before, and a modeler version that uses the same approach to input naming as the GDAL raster calculator (in the formula, you should use letters instead of layer names). The old algorithm implementation has been retained for compatibility with existing models and will be removed in QGIS 4. We have also added a separate raster calculator algorithm for creating virtual raster layers.
Improve test result handling on QGIS CI #268– Report While the original proposal was explicitly stated to be a research project with no guarantees of success, the end result is predominantly a success (with some limitations!). You can see the new failure handling in action in this PR.
What we have now is that any tests which fail a rendering comparison will write a descriptive comment to the PR, as shown in the above link. The comment details which render tests failed, where they are in the code, and includes some helpful pointers to downloading the full test report and the QGIS developer documentation.
Originally, I hoped to link directly to the full test report or include it as an attachment to the comment. Unfortunately this is NOT possible given the current Github API. There’s a bunch of notes I’ve added to the initial comment which link to the limitations / feature requests on Github’s side, so we can monitor the situation and further improve the reports if/when Github add this functionality.
As well as the above described improvements on the CI side, I’ve also implemented lots of improvements in running the tests locally and how the render test reports are generated and presented to developers!
Unification of all geometric and topological verification methods #236 – Report Our efforts are primarily focused on two main aspects of the proposal: 1. Unification of Algorithms: This component entails both refactoring existing algorithms and introducing new ones. While the refactoring phase did not reach the level of ambition initially envisioned, considerable cleanup has been achieved, particularly in eliminating code duplications, as evidenced by the PR submitted [1][2][3]. Other deduplications could be considered, but the main issue is not to break the small optimizations or adaptations to the logic of the existing code. 2. Integration of Geometry Checker Algorithms: Following the discussions within the QEP framework, we have decided to transition algorithms to those already present in the geometry checker. These algorithms encompass topological considerations. Unfortunately, due to timing constraints with the year-end and the feature freeze period, this integration was not yet completed. [4][5]
Processing Integration: Efforts have been made to incorporate the geometry checker’s algorithms into the processing framework [6][7][8]. Regrettably, these efforts have not yet been fully realized. We encountered challenges in aligning processing with the logic of the geometry checker. However, the ongoing PR by Jacky shows promising progress in overcoming these obstacles. We are optimistic about achieving the integration of geometry (and topology) checker algorithms into processing for the upcoming version. This integration aims to streamline ETL processes for verification and correction tasks, thereby enhancing codebase cleanliness.
The remaining project reports will be added as the projects wrap up.
Thank you to everyone who participated and made this round of grants a great success and thank you to all our sustaining members and donors who make this initiative possible!
If you prefer using text mode for relations instead of the gallery mode, add “nogallery“ text to your relation editor title. The mobile app will then display text mode instead of gallery. The fix is now released in 2024.1.0.
Added a new feature allowing you to identify nearest features on the map by clicking and holding. Upon holding the click, you now receive a list of the nearest features. Click one to identify it!
Released as a part of the latest mobile app (2024.1.0)
QGIS Cloud Support is repeatedly asked: ‘Why is my QGIS Cloud map so slow and what can I do to make it faster?’ Basically, the bottlenecks can be traced back to poor data management and/or a slow internet connection. In this short blog article, I would like to give you a few tips on what you can do to speed up a slow loading map.
Optimise the data Make sure that your database is optimised and that you only use the necessary data in your web map.
The QGIS.ORG Grant Programme aims to support work from our community that would typically not be funded by client/contractor agreements. This means that we did not accept proposals for the development of new features. Instead proposals focus on infrastructure improvements and polishing of existing features.
Voting to select the successful projects was carried out by our QGIS Voting Members. Each voting member was allowed to select up to 6 proposals. The full list of votes are available here (on the first sheet). The following sheets contain the calculations used to determine the winner (for full transparency). The table below summarizes the voting tallies for the proposals:
A couple of extra notes about the voting process:
Voting was carried out based on the technical merits of the proposals and the competency of the applicants to execute on these proposals.
No restrictions were in place in terms of how many proposals could be submitted per person / organization, or how many proposals could be awarded to each proposing person / organization.
Voting was ‘blind’ (voters could not see the existing votes that had been placed).
We received 39 votes from 21 community representatives, 17 user group representatives, and the OSGeo voting member.
On behalf of the QGIS.ORG project, I would like to thank everyone who submitted proposals for this call!
Today’s post is a QGIS Server update. It’s been a while (12 years ) since I last posted about QGIS Server. It would be an understatement to say that things have evolved since then, not least due to the development of Docker which, Wikipedia tells me, was released 11 years ago.
There have been multiple Docker images for QGIS Server provided by QGIS Community members over the years. Recently, OPENGIS.ch’s Docker image has been adopted as official QGIS Server image https://github.com/qgis/qgis-docker which aims to be a starting point for users to develop their own customized applications.
The following steps have been tested on Ubuntu (both native and in WSL).
Once Docker is set up, we can get the QGIS Server, e.g. for the LTR:
docker pull qgis/qgis-server:ltr
Now we only need to start it:
docker run -v $(pwd)/qgis-server-data:/io/data --name qgis-server -d -p 8010:80 qgis/qgis-server:ltr
Note how we are mapping the qgis-server-data directory in our current working directory to /io/data in the container. This is where we’ll put our QGIS project files.
If you instead get the error “<ServerException>Project file error. For OWS services: please provide a SERVICE and a MAP parameter pointing to a valid QGIS project file</ServerException>”, it probably means that the world.qgs file is not found in the qgis-server-data/world directory.
Focused on stability and usability improvements, most users will find something to celebrate in QField 3.2
Main highlights
This new release introduces project-defined tracking sessions, which are automatically activated when the project is loaded. Defined while setting up and tweaking a project on QGIS, these sessions permit the automated tracking of device positions without taking any action in QField beyond opening the project itself. This liberates field users from remembering to launch a session on app launch and lowers the knowledge required to collect such data. For more details, please read the relevant QField documentation section.
As good as the above-described functionality sounds, it really shines through in cloud projects when paired with two other new featurs.
First, cloud projects can now automatically push accumulated changes at regular intervals. The functionality can be manually toggled for any cloud project by going to the synchronization panel in QField and activating the relevant toggle (see middle screenshot above). It can also be turned on project load by enabling automatic push when setting up the project in QGIS via the project properties dialog. When activated through this project setting, the functionality will always be activated, and the need for field users to take any action will be removed.
Pushing changes regularly is great, but it could easily have gotten in the way of blocking popups. This is why QField 3.2 can now push changes and synchronize cloud projects in the background. We still kept a ‘successfully pushed changes’ toast message to let you know the magic has happened
With all of the above, cloud projects on QField can now deliver near real-time tracking of devices in the field, all configured on one desktop machine and deployed through QFieldCloud. Thanks to Groupements forestiers Québec for sponsoring these enhancements.
Other noteworthy feature additions in this release include:
A brand new undo/redo mechanism allows users to rollback feature addition, editing, and/or deletion at will. The redesigned QField main menu is accessible by long pressing on the top-left dashboard button.
Support for projects’ titles and copyright map decorations as overlays on top of the map canvas in QField allows projects to better convey attributions and additional context through informative titles.
Additional improvements
The QFieldCloud user experience continues to be improved. In this release, we have reworked the visual feedback provided when downloading and synchronizing projects through the addition of a progress bar as well as additional details, such as the overall size of the files being fetched. In addition, a visual indicator has been added to the dashboard and the cloud projects list to alert users to the presence of a newer project file on the cloud for projects locally available on the device.
With that said, if you haven’t signed onto QFieldCloud yet, try it! Psst, the community account is free
The creation of relationship children during feature digitizing is now smoother as we lifted the requirement to save a parent feature before creating children. Users can now proceed in the order that feels most natural to them.
Finally, Android users will be happy to hear that a significant rework of native camera, gallery, and file picker activities has led to increased stability and much better integration with Android itself. Activities such as the gallery are now properly overlayed on top of the QField map canvas instead of showing a black screen.
Today’s post is a quick introduction to pygeoapi, a Python server implementation of the OGC API suite of standards. OGC API provides many different standards but I’m particularly interested in OGC API – Processes which standardizes geospatial data processing functionality. pygeoapi implements this standard by providing a plugin architecture, thereby allowing developers to implement custom processing workflows in Python.
I’ll provide instructions for setting up and running pygeoapi on Windows using Powershell. The official docs show how to do this on Linux systems. The pygeoapi homepage prominently features instructions for installing the dev version. For first experiments, however, I’d recommend using a release version instead. So that’s what we’ll do here.
As a first step, lets install the latest release (0.16.1 at the time of writing) from conda-forge:
Next, we’ll clone the GitHub repo to get the example config and datasets:
cd C:\Users\anita\Documents\GitHub\ git clone https://github.com/geopython/pygeoapi.git cd pygeoapi\
To finish the setup, we need some configurations:
cp pygeoapi-config.yml example-config.yml # There is a known issue in pygeoapi 0.16.1: https://github.com/geopython/pygeoapi/issues/1597 # To fix it, edit the example-config.yml: uncomment the TinyDB option in the server settings (lines 51-54)
As you can see, writing JSON content for curl is a pain. Luckily, pyopenapi comes with a nice web GUI, including Swagger UI for playing with all the functionality, including the hello-world process:
It’s not really a geospatial hello-world example, but it’s a first step.
Finally, I wan’t to leave you with a teaser since there are more interesting things going on in this space, including work on OGC API – Moving Features as shared by the pygeoapi team recently: