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:

1. Copy your plugin template to the QGIS plugin directory, initialize the git repository, and develop from there.

2. 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:

1. Install Plugin Builder

2. Create a directory that will contain all your plugins, for example my_plugins

3. Create your plugin template using Plugin Builder. Be sure to select my_plugins when Plugin Builder asks where to create your plugin.

4. Change to your plugin directory (e.g. my_plugins/zoomer) created by Plugin Buidler and create a git repository using:

git init

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

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

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

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/

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/

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:

1. Login to GitHub
2. Fork the project at https://github.com/qgis/qgis by clicking “Fork”. This may take a while
3. Create a working copy, replacing g-sherman with your GitHub name:
   git clone [email protected]: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.

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

5. Now fetch from upstream:
   git fetch upstream

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

7. You can go to your repo on GitHub and you should see your commit message from the push
8. 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.
9. Fill in a title and message for the request, review the commit(s) and file(s) involved and when satisfied, click “Send pull request”
   

10. 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/
      
      by Gary Sherman at 4:43 PM under git , open source , qgis , quantum gis (Comments)

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:

1. Login to GitHub

2. Fork the project at https://github.com/qgis/qgis by clicking “Fork”. This may take a while

3. Create a working copy, replacing g-sherman with your GitHub name:

     git clone [email protected]: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.

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

5. Now fetch from upstream:

     git fetch upstream
   

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

7. You can go to your repo on GitHub and you should see your commit message from the push

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

9. Fill in a title and message for the request, review the commit(s) and file(s) involved and when satisfied, click “Send pull request”

10. 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/

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…

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…

In any sufficiently aged bureaucracy, process overshadows product.

In any sufficiently aged bureaucracy, process overshadows product.

Using Git with Subversion makes adding new features easy. Here are the metrics for my latest QGIS hack:

• SVN revisions by others while working on my branch: 177
• Time to complete merge with latest SVN revision: 1 second
• Conflicts: None

Coincidence? Maybe not.

Using Git with Subversion makes adding new features easy. Here are the metrics for my latest QGIS hack:

• SVN revisions by others while working on my branch: 177

• Time to complete merge with latest SVN revision: 1 second

• Conflicts: None

Coincidence? Maybe not.

The application deadline for the Google Summer of Code is nearing (April 9).

If you are interested in working on QGIS as part of GSOC and need ideas, please see Quantum GIS Wiki.

We are waiting for your proposal!

If you use Vim you probably know you can use the make command to build your project. The make command looks for a Makefile in your current directory. If you are editing a file that is not in the current directory (meaning you use some Vim magic to change to the directory containing your edit buffer), make will start below the top-level of your build directory. This is often the case when doing an out-of-source build with CMake.

To get around this, you can use the makeprg command:

:set makeprg=make\ -C\ ~/development/qgis/build

The -C switch tells make to change to development/qgis/build in your HOME directory. Once makeprg is set, start the build using:
:make

As errors are encountered they are added to the Quickfix window. This allows you to easily navigate to the problem lines and make corrections, all within Vim.

If you want the build to continue even if it encounters errors, add the -k switch to the makeprg command. Remember to escape all spaces in the makeprg command with a backslash.

If you aren’t familar with Quickfix, get started by checking out the following in the Vim help system:
:h quickfix
:h cope
:h ccl
:h cn

Caveat: This requires GNU make (gmake) and is known to work on Linux and OS X. Your mileage on Windows may vary depending on your compiler…

At the ESRI Developer Summit there was news of the File Geodatabase (FGDB) API. Based on the tweets from the summit it appears:

• The API will be C++ only
• API works on Windows and Unix/Linux (specifically RedHat, Solaris, SuSE) operating systems
• Rudimentary support only—features such as annotation, relationships, topologies, etc. are lacking

Since ESRI is releasing a targeted API and a not a specification, support for Mac OS X is out of the question.

How well open source GIS applications will be able to support the FGDB (if at all) remains to be seen.

The other question is: Will the API be made freely available or will it require an ArcGIS license?

Will the release of the FGDB API be the “Shapefile-killer”? I have my doubts…

It’s true—everything you have ever done is wrong. If you are a developer, look at the code you wrote five years ago—it’s wrong. If you collect and store data—it’s wrong.

This is the nature of human endeavor. The world used to be flat. The earth used to be the center of the universe.

Discovery and development is an iterative process. What we do today will likely be replaced tomorrow. Just because we can’t be perfect at the outset doesn’t mean we shouldn’t try.

Just because our data doesn’t represent the “truth” doesn’t mean we shouldn’t use it. We take our best shot at it and refine it as we better understand the problem. Otherwise we sit in an empty room holding a blank slate…