Why would you want to run the Windows version of QGIS on Linux? Because its there. Actually, it may be a useful way to test the Windows version without firing up the dusty old Win32 box. I did this more out of curiosity than anything else. I installed Crossover Linux (http://www.codeweavers.com/products/cxoffice) on an Ubuntu Dapper box. During the install process you are given the option to install Windows software. Of course QGIS isn’t in the list of supported software, but there is an option to install Unsupported Software.

I remember growing up and reading predictions for the new year developed by some prognosticator, supposedly in the know. Of course most of the time it was all wrong, but often made for interesting reading. With that in mind, here are my top 10 predictions for Open Source GIS (OS GIS) for 2007. Top Ten OS GIS Predictions (in no particular order) OSGeo will be a synergetic force, fostering new cooperation and collaboration between projects.

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.

In an effort to obtain a faster and lightweight solution, I decided to use Lighttpd (AKA Lighty) with FastCGI to power MapServer. Snooping around the MapServer site yielded no clues on how to configure Lighty. It turns out to be fairly simple. Here is the Lighttpd configuration: fastcgi.server = ( “/maps” => ( “localhost” => ( “socket” => “/tmp/mapserver-fastcgi.socket”, “check-local” => “disable”, “bin-path” => “/usr/lib/cgi-bin/mapserv”, “min-procs” => 1, “max-procs” => 6, “max-load-per-proc” => 4, “idle-timeout” => 20 ) ) )

It amazes me how people fail to communicate when speaking about technical matters. I’m sure you have heard this refrain: “My computer doesn’t work” or perhaps “Program XYZ blows up”. Ok, in the general sense there is some information being conveyed here. Often times the speaker is not merely providing a fact but asking for help in a very oblique manner. Before you think I’m picking on the poor newcomer, I’m not.

I’ve had to lower my expectations of the Open Source GIS user community. Now that I have your attention, I’ll explain. The OSGIS user community by and large is composed of a great bunch of folks. Its the few that have soured my outlook a bit. I repeatedly see posts to mailing lists blasting one application or the other (usually not to the project’s own list but another). The software stinks, doesn’t work right, the developers are stupid, its not as good as X, Y, or Z, and so forth.

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.

Lets face it, GIS systems are complicated. Typically there are multiple servers and applications that make up a “system”. Each of these represent a potential point of failure, thus creating a brittle system. Brittle systems break. The definition of the word brittle is: Brittle: Solid, but liable to break or shatter In other words, we can design solid systems that serve us well, but they can be brittle. We can push on them a bit and they perform well, but push too hard and the whole thing shatters.

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.

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.

One of the often overlooked support mechanisms for Open Source GIS applications is Internet Relay chat, better known as IRC. Many OS GIS projects maintain an IRC presence. Often times you will find the project developers hanging out on the channel and willing to answer questions (more about that in a bit). Speaking personally, the Quantum GIS project has used IRC for project coordination, communication, and user support for several years.

The MapServer Technical Steering Committee today approved an RFC that calls for MapServer to join the newly formed Open Source Geospatial Foundation. A poll has been put up on the MapServer site (login required) to collect the responses from the community. So far the vote is unanimously in favor of joining, although the poll has only been open for about an hour. Some thought it interesting that MapServer didn’t join immediately, given it was at the center of the failed MapServer Foundation attempt at the end of last year.

This is an unofficial recap of the OSGF meeting, based on my recollections having spent 10 hours on IRC and the phone. I’m sure the foundation will release an official version of the day’s events, so take my comments with a grain of salt. As I stated in an earlier post, the name was chosen early on and without an excessive amount of debate. OSGF rolls off the tongue rather easily and has a nice ring to it.

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.

I use Linux and OS X as my primary operating systems. Lately I have been using the Powerbook exclusively with ssh or FreeNx to work on the Linux machines on the network. I started off to simply repartition my Powerbook and then reinstall OS X and put Ubuntu on the new partition. That was two days ago. Things are pretty much back to normal now. I have a dual boot system that I can take with me and run my favorite GIS software on both platforms as needed.

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:

The Plugin Builder is a great tool for generating a working plugin project that you can customize. One of the main tasks in the development cycle is deploying the plugin to the QGIS plugin directory for testing. Plugin Builder comes with a Makefile that can be used on Linux and OS X to aid in development. Depending on your configuration, the Makefile may work on Windows. To help in managing development of your projects, we’ve come up with another option—a Python tool called pb_tool, which works anywhere QGIS runs.

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:

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.

When writing plugins or scripts it is often necessary to get information about the paths QGIS is using. For example, if we are writing a plugin that uses Python templates to create output based on user actions, we need to know the path to our installed plugin so we can find the templates. Fortunately the API provides an easy way to get at the information; here are a few examples: