SEXTANTE will soon become part of QGIS: the code freeze in the old repository and the migration are scheduled for 20th August. After the migration, only the Java-related part will remain in the old repository, while QGIS will get a new core plugin.
In this context, I have decided to revise the fTools provider code, synchronise it with the original utilities, and generally prepare for migration and code removal in any way possible. I will be happy if someone helps with testing and is willing to publish plugin package with the latest fixes.
One type of data used in GIS is geotagged photos, i.e., photos whose metadata includes the coordinates of the location where the photo was taken. But there are not many tools for working with such photos in QGIS: all that comes to mind are eVis, photo2shape and its little-known ideological parent, ImagesToShape. In principle, these two modules are sufficient for many tasks. You can use photo2shape to map the locations of photos and use eVis to view geotagged photos and link them or other documents to features of a vector layer. Sooner or later, however, a task will arise for which the capabilities of the existing tools are not sufficient.
Geotag and Import Photos is a new QGIS plugin developed for NaturalGIS. It allows you to process geotagged photos, geotag them and create a point shapefile from them.
Key features:
batch geotagging photos using a point shapefile or manually defined coordinates
add custom tags and/or modify existing tags in batch mode
create a point shapefile with a fully customisable list of attributes from a set of geotagged photos
Today, 19 July, Quantum GIS celebrates its 10th birthday. Over the years, QGIS has grown from a simple PostGIS data viewer developed by one person to a full-featured, extensible, cross-platform desktop GIS with support for multiple data formats, extensive analysis and design capabilities, which is developed by programmers from around the world and used successfully by individuals and organisations.
There is a software called TauDEM (Terrain Analysis Using Digital Elevation Models). It provides a free (GNU GPL v2) set of tools for extracting and analysing hydrological information from digital elevation models. TauDEM is developed by David Tarboton of the Water Research Laboratory at Utah State University.
The tools are written in C++, are cross-platform, and have a console interface. Users of ArcGIS 9.3.1 and 10.0 can install an add-on that allows them to run the tools from ArcToolbox using simple dialogs. For others, the only way to use TauDEM is the “scary” command line.
Recently, QGIS also got a powerful and convenient framework that allows easy integration of various tools and libraries (yes, I’m talking about SEXTANTE). Thanks to this framework, QGIS users who need hydrology tools now have a way to use TauDEM directly from QGIS.
Of course, you need to have TauDEM installed in order to use the plugin. While the installation on Windows is quite simple (there are compiled files and detailed installation instructions on the site), Linux users will have to build TauDEM themselves.
Almost a year has passed since the release of QGIS 1.7.0 “Wrocław”. It was supposed to be the last release of the 1.x branch, but time has taken its toll. The developers simply do not have enough resources to maintain several branches simultaneously, so it was decided to abandon the division into “stable” and “development” branches. All future releases will be based on the master branch. The result of these revised plans is the release of QGIS 1.8.0 “Lisboa” today.
This release contains many bug fixes and a significant number of new features. In addition, QGIS 1.8.0 has some minor API changes that affect the print composer. If you are using this part of the API in your plugin and are experiencing problems, the developers will be happy to help you adapt your code.
You can find a detailed description of the new features in the official announcement. I will only mention the most interesting ones:
QGIS Browser is both a standalone application and a dockable panel within QGIS. It simplifies navigation through the file system and connected data sources (PostGIS, WMS, WFS…), allows you to view metadata and preview data, add layers to the map using drag and drop
DB Manager is a new database management plugin. It supports PostgreSQL/PostGIS and SQLite/SpatiaLite, support for other databases can easily be added if needed. The plugin allows you to view tables (including those containing spatial information), add tables to a map or import layers from other data sources into the database, run queries, and display the results as layers
Heatmap plugin — a new core plugin for creating raster heat maps from point vector data
the functionality of the Terrain Analysis plugin has been updated and extended: in addition to calculating slope, exposure, and roughness index, the ability to create shaded and colour relief maps has been added
interface customisation tool — a dialogue that allows you to hide different parts of the QGIS interface (panels, buttons, widgets…)
reorganisation of plugins — new menus “Vector”, “Raster”, “Internet”, “Database” have been added. All core plugins and some third-party plugins have been updated and now create their own menus in the corresponding top-level menus
MSSQL Spatial support — added a new data provider to connect to Microsoft SQL Server spatial tables
support for compressed datasets — transparent opening of raster and vector data from zip/gzip archives
two new tools in the “Vector” menu: “Densify geometries” and “Create spatial index”
“Export/add geometry column” tool can perform calculations on an ellipsoid and in the layer or project CRS
Inspired by some forum topics and the general attitude of some users (observed in IRC, bugtracker, mailing lists and personal emails). I actually wrote a bit about this a few months ago. One more time and that’s it, I won’t go back to it.
Disclaimer
Everything that follows is the author’s personal (and possibly incorrect) opinion and does not claim to be the ultimate truth.
The random user is perplexed and outraged because the developers refuse to implement the feature (which gradually becomes a set of loosely connected features) that the user needs for his specific task. Really, why? First of all, the requested functionality looks strange not only to the developers, but also to many other users who, by the way, have a certain weight and influence in the community (more on this below). This means that the importance and necessity of the requested functionality are highly questionable. The second point that the user persistently ignores is the existence of a third-party plugin that does virtually everything they need. It is enough to make a minimal modification to the plugin yourself or to contact the author (an adequate and responsive person who responds promptly to comments and polite, reasoned requests).
The software is made for everyone, there is a roadmap and a vision for future development. And it makes no sense to add something to the core that only a single user needs, especially if there is a plugin with similar functionality. If the feature is really important and should be in the core — justify it. Developers cannot physically know and foresee everything, so if you can explain to them why it should be this way and not that way, changes will be made. After all, they want the program to be convenient and useful. Just remember that reasons along the lines of “I use your software in my company, so you have to…” look silly as an argument.
Another user complains that developers “resist when bugs are clearly pointed out to them”. Obviously, resistance should be understood as a polite request to describe the nature of the problem and the proposed solution in more detail. By the way, it is at least not nice to reply to a stranger with “wise will understand”. It may well turn out that this person is much wiser than you are.
It’s not unreasonable to repeat a few very simple things here:
open source software is usually developed by enthusiasts in their spare time, primarily to solve their own problems
developers are people too (unexpectedly, yes). They have jobs, personal lives and some needs
strange as it may seem, even a fairly large project like QGIS was developed by a very limited number of people. Now, the number of active developers does not exceed 8 people. For comparison, the number of open issues in redmine is 1155. So you should not expect everyone to rush to fix this particular bug as soon as you file it
from what has been said above, you can understand that there is more than enough work to do. If you want a response — respect other people’s work and value other people’s time: spend a few minutes writing a clear description of the problem rather than throwing out scattered links to a dozen sites. Nobody wants to collect and analyse information in such a form, which is also accompanied by an arrogant “wise men will understand”
Also don’t resent the fact that some bugs are fixed when
the problem will “hit” one of the developers or people who have influence over them
It’s expected and normal. Let me try to explain why this happens.
The reason people get into development is almost always the same: they need a convenient tool to solve their problems. As a result, people first work on what they need/are interested in. In other words, people make software for themselves. It is logical that the bugs that hinder the developer personally will be fixed first. The same goes for adding new features.
Furthermore, in any relatively large project, each developer has their own area of responsibility. Some developers are responsible for one subsystem, others for two or three. And no one is going to dive into someone else’s code without a real need: it takes time. And as I have already mentioned, developers tend to be enthusiasts and spend their own free time on it. Do you think there will be many people willing to dig into someone else’s code, with a vague description of the problem and no way to reproduce the bug, instead of doing something more interesting?
Now about “people who have influence over them”. Usually, these are not just some abstract John or Jane. Developers are influenced by people who are recognised in a field, who have knowledge and authority, and who are doing something useful. Both recognition and influence do not just appear, they are well-earned. These people have already proven that their opinions count for something; they not only take from the community but also support it (not necessarily financially, though it can be financial support too). Of course, we shouldn’t ignore the factor of personal sympathy: I don’t think anyone would argue that people are more likely to help their friends than complete strangers.
All of the above applies to “volunteer-based” development. If you are not satisfied with such an arrangement — find your own way to motivate people. When the canton of Solothurn needed annotations, they didn’t moan “Do it for us, we use QGIS”. Instead, they approached Marco, described the problem, got him interested, and soon got what they wanted. When Andreas finds a bug, he reports it with a detailed description and a test dataset. In urgent cases, he always finds a developer willing to help solve the problem. And these are not isolated examples.
Perhaps you should reconsider your attitude to opensource?
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.
We all face problems from time to time. Here are a few recent ones from my personal collection.
QGIS and SpatiaLite
Those who build QGIS themselves know that not so long ago there was a move to use external spatialindex and SpatiaLite instead of internal bundled copies. The former has been completely removed, but SpatiaLite is still there because it is either missing or too old in some distributions (namely Debian Squeeze, as well as Ubuntu Lucid, Maverick, Natty and Oneiric). The problem occurs when building QGIS with an external version of the library.
For historical reasons, the SpatiaLite can be compiled in two different ways:
as a loadable extension module for the system version of SQLite
as a standalone all-in-one library that combines the SQLite engine with the spatial capabilities of SpatiaLite
So. If you have SpatiaLite built as an all-in-one library, you can kiss SpatiaLite support in QGIS goodbye. You will not be able to create a new layer or open an existing one. What spices things up is that both configuration and compilation go smoothly: no missing files, no errors. The solution is to rebuild SpatiaLite as a loadable module and then rebuild QGIS. However, at this point you may face another problem.
SpatiaLite and dynamic linker
If the configure script constantly fails to find SQLite, GEOS and PROJ.4 when building a loadable SpatiaLite module on Linux, even though all these libraries are installed and have the correct version number, it is likely that your distribution has a policy of using unmodified source code (i.e., sources are only patched when absolutely necessary).
It should help to run configure as shown below
LDFLAGS=-ldl ./configure
PyQt4 and a new style of signal-slot connections
Since PyQt 4.5 there is a “new” style of signal-slot connection available in addition to the old style (more details). The new style is more Pythonic, and it is highly recommended to use it instead of the old style. The only thing is… if the interface was generated in Qt Designer and then converted to code using pyuic4, and the new style signal-slot connections are used in the code, then when you try to disconnect the signal from the slot, you may get a message that the operation cannot be performed. The situation has been clarified after contacting the developers:
PyQt allows connections to be made to any Python callable.
With old style connections a proxy slot is created under the covers whenever a callable is used (as opposed to when SLOT() is used to refer to a C++ slot). Therefore, in your example, a proxy is always created for the connection to Dialog.reject even though that refers to the object that wraps the C++ slot (as there is no Python reimplementation of reject()).
New style connections are a bit smarter in that they treat slot objects that refer to a wrapped C++ slot and objects that refer to some real Python code differently – a proxy is only created in the latter case.
So the rule is that if you make a connection old style then you must disconnect old style as well and the same for new style. You also need to be aware that pyuic4 uses old style connections.
It’s actually a bug, but they won’t fix it.
I accept that this is a bug, but I don’t want to fix it. The reason is that the changes required to the old style support code would be quite significant and I don’t think the risk to the stability of that code is worth it at this stage of the life of PyQt4 particularly as the workaround is straightforward.
The mentioned workaround is to create a dummy slot that simply calls the corresponding slot of the parent object. I.e., if you wanted to disconnect the reject() slot of a dialogue from the rejected() signal, using the old style, it was enough to write
Statist. My first plugin for QGIS. That was a long time ago: 2009, QGIS 1.0.0, start of discussions about including fTools in the core (yes, fTools was a regular plugin that had to be installed manually), only a few third-party plugins, and almost no instructions on how to write Python plugins… And I was younger and didn’t know much (to be fair, I still have a lot to learn).
The last major update of the plugin was also in 2009: I was happy with the functionality, and there were no critical bugs. Later, as I gained knowledge and experience, I thought about refactoring several times, but it didn’t work out. And recently, something came over me, so I sat down and did it.
Users will probably not notice any difference, as there are not that many changes visible to them: only support for getting statistics on joined fields has been added. But there are many more changes under the hood:
the code to check for the presence of matplotlib has been rewritten
new signal-slot connection syntax is used
completely rewritten code for calculating statistics
unused and duplicate code was removed and classes were moved into separate files
system font is used for histogram labels
The plugin now lives in my repository, please report bugs and feature requests by mail or in the bugtracker (preferred).