The PyQGIS Programmer’s Guide is now available in both paperback and PDF. A sample chapter is also available for download. The book is fully compatible with the QGIS 2.x series of releases. See locatepress.com for details.

Well it was a short summer here. Or perhaps we have defeated global warming. This is the view from the deck on Thursday evening: and this is the view Saturday morning: Of course nearly everyone in the country has removed their snow tires in anticipation of the upcoming May 1 deadline. As they say “Life is tough in the far north”. The good news is that now we can go directly from winter to summer…

Everybody who gets an Eee PC has to write about it–it’s required. I don’t really have much to add to the raft of reviews, except for one small point. I found myself wanting to print something and, based on my last experience, prepared for the ordeal of setting up a printer. I about fell out of the chair when I opened the Printer configuration and found that the Eee had already found the CUPS printer on my network and added it.

Using the git log leading up to the 1.7 release (June 2011) I put together a graphic that shows the growth of committers working on the project. In 2002 we had two people (me alone up until October). You can see significant jumps in developer interest in 2004 and 2008: In 2004 there were a number of releases that added significant functionality Following an announcement at FOSS4G 2007 in Victoria we released 0.

I’ve come to the conclusion that storing rasters in a database is of dubious value, particularly from a data warehouse perspective. If you manage a collection of rasters that are updated on a frequent basis, storing them in a relational database with ArcSDE quickly becomes a pain. I’m not talking about a dozen or so rasters, but rather tens of thousands. The overhead of the database and middleware just doesn’t seem to be worth it.

Matthew Perry poses the question: Why is the command line a dying art?. Funny how these things go–I was thinking about posting on this same topic just the other day, although I may be repeating myself. The efficiencies of the command line cannot be overstated. I too have seen that deer in the headlights look when a GUI-only user is first exposed to a command prompt. I have also seen people spend days on a data conversion project that could easily be accomplished in hours (or less).

In Beyond the RDBMS Sean references Martin’s post which in turn points us to a paper (gotta love the web in action) promoting “The End of an Architectural Era”. This paper advocates the complete rewrite (well trashing actually) of current RDBMS code in favor of specialized “engines”. It’s an interesting read with some good points until I got to this: Our current favorite example of this approach is Ruby-on-Rails. This system is the little language, Ruby, extended with integrated support for database access and manipulation through the “model-view-controller” programming pattern.

The Pragmatic Programmers have announced the upcoming Desktop GIS title.

This is an experience report–your mileage may vary_ I decided to give JUMP another try today. So I downloaded the latest release (1.2) and unzipped it into a directory. Looking at the JUMP Installation Guide reveals the document is written totally for Windows users. No problem, but I’m using a Mac. Looking in the bin directory there is a shell script named JUMPWorkbench-mac.sh. OK, make that executable and give it a go:

The forum (http://forum.qgis.org) has been closed for new registrations and marked read-only. Users have been encouraged to use http://gis.stackexchange.com instead. If you have an thoughts on the closure, good, bad, or otherwise, please comment.

I use my MacBook as my “command center”, connecting to the other machines I need to work on using ssh and Nx. After a bit of tuning, I had this working nicely under Tiger. Enter Leopard. I upgraded my machine rather than a clean install — I’m in the middle of too many things to start from zero. Being cautious, I waited a few days to see what kind of issues might arise (such as the Blue Screen of Death).

This week we look at the OpenLayers plugin for QGIS. This plugin allows you to add a number of image services to your map canvas: Google Physical Streets Hybrid Satellite OpenStreetMap Yahoo Street Hybrid Satellite Bing Road Aerial Aerial with labels Installing the Plugin The OpenLayers plugin is installed like all other Python plugins. From the the Plugins menu in QGIS, choose Fetch Python Plugins.

An interesting visualization of QGIS development over the last eight years: http://woostuff.wordpress.com/2011/01/03/generating-a-gource-source-commit-history-visualization-for-qgis-quantum-gis/

Following the instructions for a “hard” upgrade in Chapter 2. Installation of the PostGIS manual results in large objects not being restored to the database. If you create a dump using pg_dump -Fc –oids and then use the postgis_restore.pl script, the oids will be restored but not the large objects. This is not really a PostGIS issue, it can happen when dealing with any PostgreSQL database. To remedy this situation I found that the pg_dumplo utility has the answer.

We’ve released version 3.1 of the Plugin Builder for QGIS 3.x. This version contains a number of bug fixes and performance enhancements. Here are some of the changes included since version 3.0.3: Fix issue with reload on generated plugins Move dialog creation to run method to improve startup performance Move help file generation files to proper method Include missing tags file Attempt to compile resources.qrc when plugin is generated (requires pyrcc5 in path) Set deployment directory in Makefile based on user OS (pb_tool is recommended over make) Check for valid URL format for tracker and repository Compiling Resource File If you have the resource compiler pyrcc5 in your path, the resource file will be compiled automatically when you generate your new plugin.

QGIS data providers are written in C++, however it is possible to simulate a data provider in Python using a memory layer and some code to interface with your data. Why would you want to do this? Typically you should use the QGIS data providers, but here are some reasons why you may want to give it a go: There is no QGIS data provider The generic access available through OGR doesn’t provide all the features you need You have no desire to write a provider in C++ No one will write a C++ provider for you, for any amount of money If you go this route you are essentially creating a bridge that connects QGIS and your data store, be it flat file, database, or some other binary format.

I guess Ubuntu must be popular. I’m just trying to upgrade my Feisty install so I can do the upgrade to Gutsy. Looks like it’s going to take a while…

There’s been several posts to GIS StackExchange along the lines of: Where’s my .qgis3 folder? Prior to QGIS 3, the .qgis/.qgis2 folder was found under your home directory. At version 3, the folder has moved to a more standard profile location for your operating system. There are a couple of ways to determine where the folder is located: Use the Settings->User Profiles->Open active profile folder menu item Use QgsApplication.qgisSettingsDirPath from Python or the console Here are the “standard” locations for Linux, Mac, and Windows, as found under your HOME directory:

This minor update to the Plugin Builder allows you to choose where your plugin menu will be located. Previously your menu was placed under the Plugins menu. At version 2.8.1 you can choose from the following main menu locations: Plugins Database Raster Vector Web Plugins is the default choice when you open Plugin Builder. The value you choose is also written to the category field in your metadata.txt file.

Here is the process I used to quickly build (OK, but it was faster than usual) QGIS HEAD on Feisty Fawn. What’s QGIS HEAD? It’s the current development version that includes the tasty Python bindings that allow you to write both QGIS plugins and stand-alone mapping applications. With apt-get or synaptic, install the following: bison fftw3 fftw3-dev flex g++ libgeos-c1 libgeos-dev libgeos2c2a libpq-dev libpq5 libqt4-core libqt4-dev libqt4-gui libqt4-qt3support libqt4-sql libreadline5-dev libsqlite3-dev libtiff4-dev proj pyqt4-dev-tools python-qt4 python-qt4-dev python-sip4 python-sip4-dev qt4-designer qt4-dev-tools qt4-doc qt4-qtconfig sip4 sqlite3 tcl8.