Spatial Galaxy » Open Source

QGIS Users Around the World

Gary Sherman — Mon, 19 Dec 2011 17:21:09 +0000

One of the difficult things to track in the open source world is the number of people who actually use your software. In the proprietary commercial world you have licenses, invoices, and so forth. In the case of QGIS, we can track the total number of downloads from qgis.org, but this doesn’t represent the total installed base. It is impossible to accurately determine the actual number of people using QGIS, but we can get an approximation of the number and where they are in the world.

The analysis was done using the log files from the QGIS contributed repository:

The IP address of each entry that retrieved the plugin list from the server represents one or more users—these IPs were collected into a unique list
Using a Python script, each IP address in the log was geocoded to get the approximate latitude and longitude of the user
The IP address, country, latitude, and longitude were written to a CSV file
The CSV file was converted to a Spatialite layer to create the map of users

The map represents 35,603 unique IP addresses of users that accessed the repository between October 23, 2011 and December 17, 2011.

The geocoding process varies in precision—some IPs are located to the city level while others only return a general location for the country.

Some assumptions and observations:

Most (maybe all) users make use of Python plugins and therefore access the contributed repository at some point
Country-level points (blue) on the map represent more than one user
Some points represent organizations that use a single IP for all users accessing the Internet. These points will represent more than one user
Some users may access the repository from more than one IP address

So how many people use QGIS? At the very minimum, 35,000. We know that the downloads of just the Windows version exceeded 100,000. Given that there are 7,183 IP addresses that are generalized to a country location, we can safely assume that the number of actual users is much higher than that.

Considering the number of points that represent an organization and those that represent a country location, I think we can safely assume that the number of QGIS users easily exceeds 100,000 worldwide.

Developing QGIS Plugins with git

Gary Sherman — Tue, 25 Jan 2011 02:40:03 +0000

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

The repository feature allows you to create a central place to store your plugin code using git. Others can clone your repository and contribute through patches or pull requests.

Creating a Plugin

The chore of setting up the boilerplate for a plugin is made simple by using the Plugin Builder. Previously this was a web application but it has now been replaced by a QGIS plugin aptly named Plugin Builder. You can install Plugin Builder from within QGIS by selecting Fetch Python Plugins… from the Plugins menu.

Once Plugin Builder is installed you can quickly create a starter plugin that implements a simple dialog box with OK and Cancel buttons. The plugin created by Plugin Builder is fully functional—it will load in QGIS but not do anything useful until you customize it.

Setting up the Workflow

You have a couple of options for setting up your development directory and workflow:

Copy your plugin template to the QGIS plugin directory, initialize the git repository, and develop from there.
Work within your plugin template directory that was created by Plugin Builder (not within the QGIS plugin directory)

Option one is very convenient as long as you don’t test the uninstall feature of your plugin. This will delete your entire plugin directory and git repository—not what we really want.

Option two is safer, however to test your plugin you have to continually copy from your development area to your QGIS plugin directory. Alternatively you could make commits and pull from your development area to the copy (assuming it is a git repo) in the QGIS plugin directory. If you are on a unix based system you could also create a Makefile to deploy the plugin for you.

The best solution is to use option two and use the QGIS_PLUGINPATH environment variable to point to your development directory. When present, QGIS_PLUGINPATH tells QGIS to search additional directories for plugins. Going this route allows you to develop in the directory created by Plugin Builder and test your plugin without any copying or pulling. The upside to this is since your plugin wasn’t installed through the Plugin Installer it can’t be uninstalled accidentally. When you are ready to test the uninstall and unloading of your plugin you can copy it to the main QGIS plugin directory.

Note: If you are using Windows there was a problem specifying QGIS_PLUGINPATH with colons in the path. This issue is fixed in revision 15073 and will make it into the next release.

No matter how you implement your workflow I suggest creating a repository on the QGIS hub (http://hub.qgis.org) or github.com.

Summary

Here is a summary of the steps to get started. We’ll assume your new plugin is named zoomer:

Install Plugin Builder
Create a directory that will contain all your plugins, for example my_plugins
Create your plugin template using Plugin Builder. Be sure to select my_plugins when Plugin Builder asks where to create your plugin.
Change to your plugin directory (e.g. my_plugins/zoomer) created by Plugin Buidler and create a git repository using:
```
git init
```
Set the QGIS_PLUGINPATH evironment variable to point to the directory containing your plugin directory (my_plugins). Be sure to use the full path to my_plugins
Start QGIS and use the Plugin Manager (Manage Plugins… from the Plugins menu) to enable your plugin. If it doesn’t show up in the list of plugins check to make sure you have set QGIS_PLUGINPATH correctly.
Develop away, testing as you go. Make sure to commit changes regularly and push them to your repository on hub.qgis.org.

If you are new to git, take a look at the Pro Git book at http://progit.org/.

For help on developing QGIS plugins with Python, see the PyQGIS Cookbook.

Evolution of QGIS

Gary Sherman — Mon, 03 Jan 2011 17:27:23 +0000

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/

Contributing to QGIS Using Git

Gary Sherman — Mon, 27 Dec 2010 16:43:24 +0000

One of the challenges in any open source project is accepting contributions from people that don’t have, need, or want access to your centralized source code repository. Managing repository accounts for occasional or one-time contributors can be come a bit of an administrative issue. To date, the QGIS project has accepted one-time or occasional contributions through patches submitted via a help ticket.

To make it easier for you to contribute to QGIS, we have created a clone of the Subversion repository on GitHub. This allows you to “fork” the QGIS repository and have your own local copy of the source code. Through GitHub you can easily submit your enhancements and bug fixes for inclusion in the Subversion repository.

You will need to install git on your computer and create a GitHub account. Once you have done that, here is the process for creating your working copy and contributing to QGIS:

Login to GitHub
Fork the project at https://github.com/qgis/qgis by clicking “Fork”. This may take a while
Create a working copy, replacing g-sherman with your GitHub name:
git clone git@github.com:g-sherman/qgis.git

This will also take a while, depending on the speed of your network connection. My clone downloaded 162 Mb from GitHub.
Change to the directory containing your local clone and add a reference to the original QGIS repo:
git remote add upstream git://github.com/qgis/qgis.git

This gives you are reference named upstream that points to the repo you forked.
Now fetch from upstream:
git fetch upstream
Now you are ready to work with QGIS. Make your changes, commit them, and then push back to your fork on GitHub:
git push origin master
You can go to your repo on GitHub and you should see your commit message from the push
Now you want to tell the QGIS developer team there is something they should look at. You do this by issuing a pull request by clicking on the “Pull Request” button on your GitHub QGIS fork page.
Fill in a title and message for the request, review the commit(s) and file(s) involved and when satisfied, click “Send pull request”
Now sit back and wait for someone to review, comment on, and hopefully merge your request into the QGIS repo.
To keep in sync with the QGIS repo, use
git fetch upstream git merge upstream/master

Make sure to check out these resources for help and more information on working with repositories on GitHub:
- GitHub Help: http://help/github.com
- Forking: http://help.github.com/forking/
- Pull Requests: http://help.github.com/pull-requests/

GeoApt Spatial Data Browser

Gary Sherman — Thu, 16 Dec 2010 01:25:10 +0000

This is a project I have had lingering around for a while. It is a geospatial data browser written in Python using the PyQt and QGIS bindings. It allows you to navigate a tree structure and preview raster and vector datasets. Metadata extracted from the data can be viewed as well. It supports drag and drop for any target that accepts filenames (e.g. QGIS). For screenshots and more, see http://geoapt.com/geoapt-data-browser.

The code is now available on GitHub (see https://github.com/g-sherman/GeoApt) and ready for you to contribute. Take a look and if you want to get your hands dirty fork the project and start coding.

Lots of features are missing—consider this an alpha version…

GIS for the UN*X World

Gary Sherman — Thu, 07 Jan 2010 04:40:32 +0000

In a recent post on VerySpatial.com, Jesse was discussing the apparent dominance of U*nix and observed:

‘…the geospatial industry almost completely left behind support for UNIX-like OSes’

It is true that the proprietary GIS vendors have largely abandoned Unix and Unix-like operating systems and continue to do so. However the open source GIS community has embraced all major operating systems with software that runs on Linux, *BSD, Mac OS X, and yes, Windows. This support includes everything from the desktop to the server.

For those of us that prefer to operate in a Un*x environment, that’s good news.

The Shapefile – Reports of My Deprecation have been Greatly Exaggerated

Gary Sherman — Tue, 05 Jan 2010 03:43:00 +0000

The death of the shapefile has again been predicted—this time for 2010.

The technical description of the format has been around for going on 12 years. In that time it has become a sort of lowest common denominator for data exchange. They’re everywhere. Making them go away is going to require a revolution of sorts.

ESRI has been sounding the death knell for the shapefile for a while now. I agree that it isn’t a perfect format but it is nearly perfectly supported.

If ESRI really wants the shapefile to go away, they will produce a fully open API for the File Geodatabase—one that can be used outside the Arc* realm. One that can be obtained and used at no cost or license fee.

There is a raft of open source programmers waiting in the wings to code against it and provide support and interoperability for the open source GIS world.

We’re waiting…

What’s Holding Back the Adoption of Open Source GIS on the Desktop?

Gary Sherman — Sun, 03 Jan 2010 05:33:28 +0000

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. Take a look at the poll (right margin) and if you are a partial adopter, please vote or post a comment on what’s holding you back.

Migrating to Open Source GIS on the Desktop

Gary Sherman — Fri, 20 Nov 2009 14:41:34 +0000

I keep seeing more evidence that many people and organizations are migrating to open source GIS on the desktop. In many cases a mix of proprietary and open source GIS is in use.

I’m wondering about other’s experiences in this area. To gain some insight, I’ve created a poll (right margin). Please take a second and vote.

I Love Linux

Gary Sherman — Tue, 11 Aug 2009 04:24:18 +0000

$ uptime
20:20:56 up 434 days, 15:31, 2 users, load average: 2.32, 0.89, 0.53