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.
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.
Translated PyQGIS Developer Cookbook into Ukrainian. Soon it will be available on the QGIS documentation portal.
Comments and constructive criticism are welcome. Or even better, create an account and edit directly in Transifex
(although I personally don’t like it much and translate locally: git + Qt Linguist are the best).
At last! QGIS has finally got support for multithreaded rendering, the corresponding changes were merged into master by Martin Dobias just an hour ago. This is basically a revival of the 2010 GSoC project “QGIS on steroids” (successfully completed, but never merged into master), taking into account the latest changes to the QGIS codebase.
By default, multithreaded rendering is disabled, one can enable it in the QGIS settings “Settings → Options → Rendering → Render layers in parallel using all available CPU cores”. It is also possible to set canvas refresh interval during rendering (0 means real-time updates).
Not long ago I wrote about the raster calculator in GDAL. It is a useful tool and has enough functionality to solve most tasks. But as it turns out, it is not without its bugs.
I was playing with this calculator and looked at the code. Almost immediately I noticed that it reads data “as is”, which was something to worry about, as I had already stepped on that rake some time ago (/me is immersed in memories for a few minutes. It was a fun time: two parallel projects, both related to GDAL; lots of new stuff to learn…). A little test confirmed my fears. Here is the result of an NDVI calculation for a Byte raster, performed with RasterCalc and saved as Float32.
NDVI calculated with RasterCalc for inputs with Byte data type
And this is the result of the same operation performed by gdal_calc
NDVI calculated with gdal_calc for inputs with Byte data type
You can’t get this across with an image, but the white areas aren’t really white at all — they contain a NODATA value.
What can I say, the results are very interesting. But the explanation is simple: since the data is read “as is”, when performing arithmetic operations, you can run into things like integer overflow and rounding of the result (in Python, the result of dividing two integers is also an integer).
Obviously, this is a bug. So let’s write to the author, report the issue and propose a patch.
If you are using this tool, you may not want to wait for the next version of GDAL and fix the bug yourself. To do this, open gdal_calc.py in your favourite text editor and lines 230–232
TinyOWS is a lightweight and fast WFS-T server. OSGeo4W is an installer for various free GIS software. What do they have in common? Until today, the correct answer was “nothing”.
From today, OSGeo4W users can install and use the latest version of TinyOWS 1.0.0rc1. Previously, the only reasonably easy way to get the TinyOWS server running on Windows was to use MS4W installer, but it provides the old 0.9.0 version.
I have also written a guide on how to build TinyOWS on Windows.
A small tutorial on how to build the current version of TinyOWS (the so-called trunk) under Windows XP Professional using Microsoft Visual C++ 2008 Express Edition and libraries from OSGeo4W.
Having a raster calculator in QGIS is cool, but if you need to process a lot of rasters, it won’t be much help. There is no batch mode in the calculator (neither in the plugin nor in the QGIS core). Well, there is an entry about it in my TODO. But knowing that won’t help if you have hundreds of images for which you need to calculate, e.g., NDVI, or perform pixel replacement by a tricky condition.
This is where GDAL and Python come to the rescue. It literally takes 10 minutes to write a script, as there is nice and detailed documentation. But again, writing almost identical scripts for every task is not very practical.
Let me tell you a little secret. GDAL 1.8.0 has a wonderful tool, modestly named gdal_calc.py. This small (about 300 lines) Python script works with rasters of the same size (no check for mismatching CRS is performed) and supports basic arithmetic and logical operations. It is easy to use:
# sum of two rastersgdal_calc.py -A input1.tif -B input2.tif --outfile=result.tif --calc="A+B"# average of two rastersgdal_calc.py -A input1.tif -B input2.tif --outfile=result.tif --calc="(A+B)/2"# difference of raster bandsgdal_calc.py -A input.tif --A_band=1 -B input.tif --B_band=2 --outfile=result.tif --calc="A-B"
It accepts up to 26 images as input, which should be sufficient for most use cases. As you can see from the examples, there is support for parentheses, you can access individual bands, and the console nature makes it easy to use the script for batch processing. It still lacks some features, but even in its current state, it is a great console calculator.
