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.
TauDEM (Terrain Analysis Using Digital Elevation Models) is a set of Digital Elevation Model (DEM) tools for extracting and analysing hydrological information from the topography represented by a DEM. It was developed at Utah State University (USU) for hydrological analysis of digital elevation models and watershed delineation.
TauDEM has recently been integrated into QGIS as a SEXTANTE provider. This makes it possible to run TauDEM tools directly from QGIS, easily perform complex analysis workflows, and view the generated results.
In this post, I will show how to perform some hydrological analysis tasks in QGIS using TauDEM, namely how to delineate watersheds and extract stream networks.
SEXTANTE is a powerful and flexible platform for performing geospatial analysis in QGIS. It provides access to its own geoprocessing functions as well as algorithms implemented in third-party applications, making analysis easier and more productive.
Initially written in Java and only available to gvSIG users, SEXTANTE has gradually extended its presence to other GIS. In 2012, a Python version was developed for use with QGIS. It immediately attracted a lot of interest from users and developers alike, and in September 2012 SEXTANTE was integrated into QGIS as a core plugin.
SEXTANTE in QGIS allows you to use the main features of well-known third-party GIS tools (SAGA GIS, GRASS GIS, TauDEM, OrfeoToolBox…) and algorithms implemented directly in SEXTANTE (fTools, MMQGISX…) via a unified interface.
It also offers a wide range of possibilities for automating data processing: combining repetitive steps of applying algorithms to data in a custom analysis model, writing and using Python scripts, batch processing mode. Advanced users can further increase their productivity by using SEXTANTE algorithms and the Python console together.
As I wrote before, Oslandia kept their promise, and during the 8th QGIS developer meeting, the Atlas plugin was integrated into the QGIS print composer. This has been made possible thanks to the financial support (although not the full amount has been raised) of the following individuals and organisations:
Agence de l’eau Adour-Garonne
City of Uster, Switzerland
Spencer Gardner
Giovanni Allegri
John C. Tull
Bill Williamson
Ujaval Gandhi
The workflow remains the same: create a print layout and specify a coverage layer that will be used to generate the atlas. In addition, it is now possible to create complex labels using the full power of QgsExpression and the attributes of the coverage layer.
Let’s go through the process of making an atlas step by step.
Recently, there have been a lot of questions about working with CSV files in QGIS. So here is my attempt to shed some light on this complex and confusing topic. Be prepared for a longread.
In the post “Getting started with openModeller” I showed how to use openModeller Desktop to identify areas at risk from invasive species. Another task that can be done with openModeller is modelling the distribution of species under new climate conditions.
In the post about openModeller command-line tools, I have mentioned request files several times. When using openModeller from the command line, we have to deal with these files very often, as they allow us to perform almost all necessary actions and go from the input data to the results.
Last year I wrote “Getting started with openModeller” post which gave an overview of openModeller - a free open-source ecological niche modelling tool - and showed how to run experiments in the openModeller desktop GUI. However, it is often faster and easier to perform the necessary actions using command-line tools. This is the subject of this post.
With the release of QGIS 1.7.0 it was announced that a new official plugin repository has been created with many features (a rating system, lists of recommended and recently added plugins, etc.). In addition, a dedicated section for 3rd-party plugins has been created in the QGIS bug tracker, where plugin authors can create a homepage, wiki, bug tracker, and code repository for their plugins. The main goal of all this is to provide a single repository for plugins and a single place to report bugs for both plugins and QGIS itself.
And although the new repository has been put into production and added as the default repository in the QGIS 1.9.90, plugin developers are still holding back on using it (at the time of writing, there are only 35 plugins in the new repository, for comparison, there are 111 plugins in the old repository). This can probably be explained partly by ignorance and partly by the somewhat confusing procedure for adding a plugin to the new repository.
Let’s try to figure this out.
I assume that the plugin code has been published to one of the public code repositories, such as GitHub or BitBucket, and now we want to set up a bug tracker and wiki on hub.qgis.org. This will make life a bit easier for users: they will be able to use their existing account to file bug reports. To do this:
go to hub.qgis.org and log in
open the “Projects” section and click on the “New Project” button, or go to the “User Plugins” subsection and click on the “New Subproject” button
fill in the form (note that in the “Subproject of” list you should select “User plugins”): enter the name of the plugin, a short description, and a link to its homepage (if available). Here, you can also select the necessary components of the bug tracker (wiki, tracker itself, calendar…). Most settings can be changed later
once you have completed the form, click on the ‘Save’ button. That’s it, a new project has been created
The bug tracker and code repository are ready. All we need to do now is upload the plugin to the plugins repository.
Before creating an archive and uploading it to the server, we need to fill in the metadata in the plugin’s metadata.txt file, specifying the URLs of the bugtracker, repository and homepage (more details). Here’s an example:
[general]name=Cool Plugindescription=Does some useful actions with your datacategory=Vectorversion=1.0.0qgisMinimumVersion=1.7.2icon=icons/pluginicon.pngauthorName=usernametags=vector, bounding box, bufferexperimental=Truedeprecated=Falsehomepage=http://someserver.com/coolplugin.htmltracker=http://hub.qgis.org/projects/coolpluginrepository=http://github.com/username/coolplugin
Save the changes in the metadata.txt file and create an archive with the plugin. Now we are ready to upload the plugin to the new repository:
use the “Share a plugin” link in the sidebar to open the upload form
select the plugin archive, activate the “Experimental” checkbox if necessary, and click “Upload”
If the plugin is packaged correctly and the metadata contains no errors, the archive will be uploaded to the server. Otherwise, an error message is displayed, and the upload is cancelled. Once the errors have been corrected, the upload should be repeated.
The uploaded plugin gets an unapproved status and is not immediately available to all users. It will only be added to the list of publicly available plugins after approval from the administrator. This will happen every time you upload a new version, even if your plugin has already been approved. This policy may be changed in the future.
There is also a small script to upload the plugin archive to the server. For example, you can add it to the post-commit hook or Makefile and upload new versions without a browser.
As you can see, there is nothing complicated about using the new infrastructure.
Quite often, I have come across the question: How can I use the georeferenced rasters (raster + map file) from OziExplorer in QGIS? In order to use such data in a GIS, it is usually necessary to convert them first, e.g., with GlobalMapper. With the release of GDAL 1.7.1, there is no need for proprietary software, as GDAL now supports OZI map files.