How can we make getting started in Open Source GIS easier? To begin with, it needs to be easier to Discover Install Use Discovery This is probably the least of the problems, but you would be surprised how many people “stumble” on OS GIS each day. Things are improving as more exposure is gained through books, blogs, conferences, and the media. The more we talk about it, the more well known it becomes.

In this day of GUI GIS, sometimes you can’t beat the good old command line for getting a job done, regardless of whether you use Linux/Unix, Mac OS X, or Windows. This may sound strange coming from someone heavily invested in a GUI project but its true. Case in point - I recently needed to create two seamless regional layers from over 100 individual shapefiles. The source shapefiles were stored in individual subdirectories two levels deep.

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).

The Quantum GIS (QGIS) project is happy to announce that the Asia Air Survey Co., Ltd (AAS), a Japanese international consulting company, has become a Gold Sponsor. AAS has committed to providing 9,000 EUR (~$11,000 US) each of three years, beginning in November 2012. The AAS sponsorship is yet another indication that QGIS is a mature and stable project which continues to provide innovative open source GIS software. The QGIS Project Steering Committee (PSC) wishes to thank AAS for their continuing commitment.

If you’re a developer, or have looked at the QGIS source code, you’ve likely noticed that most C++ classes in the project start with Qgs. Back before the dark ages of QGIS, Trolltech (now Digia) allowed you to reserve name prefixes for classes that used the Qt framework. Shortly afterwards, I reserved the gs prefix for my use, resulting in class names that start with Qgs. You might think this is based on some mangling of words like QGIS or perhaps GIS, but it was purely egocentric:

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.

In my last post I created a poll to get an idea of the extent of migration to open source GIS on the desktop. The results indicated that nearly 50% of the people using open source GIS were still using their proprietary software as well. You can view the results of the poll using the Polls Archive link below the current poll. This leads one to wonder if it is the state of the open source software or other reasons that prevent a full migration.

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).

I was interested to read that ArcGIS Image Server is now available. Now I admit that I haven’t had any advanced information about the product (has anybody?) but was disappointed to find that its only supported on Windows servers. Disappointed but not surprised. I was hoping for a more open API (specifically something other than ArcObjects and/or .Net) and the ability to use image server on Linux/Unix.

Is desktop GIS software a rusty old car with no wheels? Bouncing around the blogosphere sometimes leaves you with that impression. All the excitement these days seems to center around mashups, hacks, and mapping in your web browser. It’s definitely cool stuff. A number of folks think this is the future of GIS, even when it comes to doing analysis. Part of this trend stems from a desire to deliver mapping to the masses.

This post is for those of you that build QGIS on a regular basis and want to keep up with everything going on in the current release branches (1.7.2 and 1.8) as well as the master branch that will eventually become version 2.0. While you can do all your work in one clone, this method has a couple of advantages, at the expense of a bit of disk space: Quicker compiles compared to branch switching, especially if you are using ccache Less likelihood of making a merge mess when switching branches The basic steps are:

Writing a QGIS plugin is not overly complicated but represents a bit of work. Using git in conjunction with your development efforts can make sure your investment in coding time is preserved. Development Tools The QGIS project team has set up a central location for plugin development which includes pretty much everything you need to develop and support your plugins, including: Issue tracking Wiki Documents Repository

In this day of GUI GIS, sometimes you can’t beat the good old command line for getting a job done, regardless of whether you use Linux/Unix, Mac OS X, or Windows. This may sound strange coming from someone heavily invested in a GUI project but its true. Case in point - I recently needed to create two seamless regional layers from over 100 individual shapefiles. The source shapefiles were stored in individual subdirectories two levels deep.

GIS data is like an illicit drug. You can’t control it. It travels in secret and hides in the dark alleys of your organization. Its effect spreads and enslaves those that use it. In the end it can lead to ruin. Well maybe its not that bad but organizing and managing your GIS data is difficult. If you need to maintain canonical datasets, the spread of “temporary” and/or “working” copies is your enemy.

The Plugin Builder allows you to quickly create a skeleton Python plugin by generating all that boring boilerplate that every plugin requires. Here is a short video showing how to create, compile, and install a new plugin. For more information, see QGIS Workshop Documentation and the PyQGIS Cookbook.

It was ten years ago, on July 19, 2002, that QGIS was officially unveiled. That first release was primitive, supporting only PostGIS layers and having little in the way of navigation controls. Invoking the open source mantra of “release early and release often,” I announced it on Freshmeat and waited. Slowly it began to attract attention—not all of it positive. Some questioned why I was starting a new open source GIS project when there were others I could join.

Is desktop GIS software a rusty old car with no wheels? Bouncing around the blogosphere sometimes leaves you with that impression. All the excitement these days seems to center around mashups, hacks, and mapping in your web browser. It’s definitely cool stuff. A number of folks think this is the future of GIS, even when it comes to doing analysis. Part of this trend stems from a desire to deliver mapping to the masses.

The recent release of QGIS 1.0 provides an excellent opportunity for developers looking to create standalone mapping applications with Python. I recently posted an article on creating a very simple standalone application with Python and QGIS 1.0. Much of the Python efforts thus far have been devoted to creating QGIS plugins. I think now that we have a stable API, you’ll begin to see more custom applications that meet a specialized need.

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.

Well, I have been participating in the “GeoFoundation” Meeting since 5:30 am local time this morning. We’re two hours into the meeting and so far a name for the foundation has been agreed upon: Open Source Geospatial Foundation. The domain osgeo.org has been registered. I suppose most folks will refer to it as OSGF from this point on, although the term OsGeo was also mentioned in the discussions. I was concerned that the name of the foundation would become a major stumbling block in making progress during the meeting, however the groundwork and informal polll seems to have paid off in that regard.