The results of the project selection for GSoC 2015 have been announced. This year, the requirements for the projects were stricter and the number of slots was much smaller. Therefore, the fact that QGIS has been selected is even more gratifying. Marcus Santos will work on multithreading support in Processing, and Victor Olaya and I will be his mentors.
When viewing TMS layers in QGIS, as well as in any other GIS, the background map may be blurred if the current map scale does not match the scale of the tiles. The reason for this is a feature of TMS, namely the use of a fixed set of so-called “zoom levels”: tiles are generated only for certain scales defined by the data provider.
So to get a sharp image, you should only use the scales that correspond to the zoom levels of the selected TMS service. For OpenStreetMap, the formula for calculating the scale for each zoom level can be found on this page, and a similar approach can be used for other services.
Some time ago I added a special widget to QGIS to select a map scale from a given set. Later, it became possible to edit this list and define a set of scales on a global level as well as on a project level. So if your project uses TMS layers, you can create your own list of scales and switch between them. At the same time, you still have the option of using any intermediate scale values.
Another option is to install the Tile Map Scale plugin. This plugin allows you to easily connect popular TMS layers (remember about ToS!). It also monitors map scale changes and automatically sets the nearest correct TMS scale. Note that you will not be able to use intermediate scale values in this case.
Finally, QGIS has a built-in widget for changing the scale according to the layer’s scale list. It can be found in “View → Panels → Tile scale” or from the toolbar context menu.
When displaying spatial information, it is desirable to have a “context” — some additional data to help you navigate and make the information more readable. This can include administrative boundaries, hydrology, road networks, etc. Such additional layers are called “basemaps”. The term “basemap” is often used to refer exclusively to services such as Google Maps, BING Maps, OpenStreetMap and so on, but this is not correct.
So what is a basemap? It is a background layer (such as a digital elevation model or topographic map) on which thematic layers are overlaid. The basemap is often used for geographic reference and may include elements of the geodetic network. Very often, aerial or satellite imagery is used as a basemap.
At the same time, the widespread use of different map services as basemaps is explained by their accessibility: all that is needed to use them is an Internet connection and minimal GIS skills, whereas the use of other types of data may require some preparatory work, such as georeferencing.
Let’s see how we can use different map services in QGIS.
Imagine you could order books. Do you want a book about QGIS? If so, what level of knowledge do you think the reader should have and what topics should the book cover? Any other suggestions?
I have released a new version of the Photo2Shape plugin. This is a QGIS plugin that allows you to create a point vector layer from a set of geotagged photos.
Users now have the ability to recursively process directories and the option to append data to an existing file. The code has also been refactored, and instead of EXIF.py the more convenient and reliable exifread is now used.
I’m pretty sure that the heterogeneity of the Processing plugin’s graphical interface is not something that many people (if any) pay attention to. And it is very likely that the code responsible for the generation of the interface has never been seen by anyone other than the developers. Since everything works as expected, everyone is happy with it. And it does not matter what the windows or buttons look like. Let alone the code. In fact, both are important. A unified interface looks professional, is more convenient and pleasant to use, while clean, well-structured code is easier to maintain and extend.
My first thought was to do a crowdfunding campaign like Matthias, but then I changed my mind. So now I am slowly fixing it in my spare time. I’m hoping to get this done in time for the 2.8 release, which will be a long-term supported release.
The 12th QGIS developers meeting, which took place in Essen (Germany), has ended.
In my previous posts (day 1, day 2, and day 3), I have already covered the main points, and now I will go into a little more detail about the most interesting results.
Certification
Four types of certificates are planned: QGIS User, QGIS Professional, QGIS Trainer, and QGIS Developer. Also, PSC will issue so-called “grandfather” certificates. The TAO online platform will be used for assessments.
New geometry class
A complete update of the QgsGeometry class, which is responsible for the spatial component of objects, is planned:
support for an extended set of geometric primitives
support for Z (altitude) and M (measurement) values
support for curves
new extensible architecture
an extensive set of unit-tests
The first batch of changes has already been implemented, and new functionality is expected to be included in the QGIS 2.7 code base. The work was supported by the Canton of Solothurn.
In fact, there were many more interesting and active discussions, and some topics appeared on the agenda spontaneously (for example, support for SAGA and OTB in Processing on Debian builds). In addition to broad discussions, there were also “narrow” discussions where specialized problems were solved (such as downloading data from the Portuguese iGeo portal), and participants periodically organized into groups to solve problems together and/or find and fix bugs.
Also during the meeting:
we discussed changes to the release schedule: it is proposed to maintain the LTS release with a 1 year lifecycle
support for Python plugins for the QGIS Server was proposed and partially implemented. This way, one can significantly expand the functionality of the server without the need to make changes to its code
we discussed the prospects of fTools (vector data) and GDALTools (raster data) plug-ins and their possible replacement with Processing
PSC completed process of the trademark registration and developed guidelines for its use
we started work on integrating contextual help into the documentation
lots of bugs were fixed
documentation was updated
Many thanks to the organizers and LinuxHotel staff for their hospitality.
Today was a very busy day. A smaller number of commits from developers (20 today vs. 40 yesterday) was compensated by active discussions:
the future of the fTools plugin (GDALTools in trouble too)
new release preparation policy
adding plugins support to QGIS Server
updating QgsGeometry class (support for Z/M values and curves)
docker capabilities for QGIS developers and users
trademark registration and protection
Work on updating the documentation and the website also continued. We decided to skip the documentation update for QGIS 2.4 and focus on writing documentation for the upcoming QGIS 2.6 instead.
The second day of the QGIS hackfest is coming to an end.
The documentation team has continued to update the documentation and website, with over 30 commits today. The developers have not lagged behind - the number of commits is approaching 40. As always, Martin is a delight: thanks to his efforts, the rendering speed of a simple symbol renderer has increased significantly. Depending on the data, the speed increase ranges from 19 to 31%.
The first day of the 12th QGIS Developer Meeting in Essen has passed. Actually, it’s not really correct to consider it a full-featured day of the meeting, because most of the attendees were just arriving today. Moreover, today Linuxhotel was hosting an event and we were not able to fully use its infrastructure.
But all this did not prevent us from getting to know each other, communicating and even (there were such maniacs) doing something. For example, Otto, Richard, and Yves started documentation update. The day ended with a joint dinner at Haus Großjung.