2011-06-15

Fix for Quantum GIS and Python bindings mismatch in Ubuntu 10.10

I'm one version behind on my Ubuntu distro (I've decided to wait until the next LTS before upgrading again, since I really need the time to get work done), so this may not be applicable to the latest version of Ubuntu (11.04). In any case, I recently noticed that Quantum GIS (QGIS) installed from the Ubutnu GIS 'unstable' repository was unable to link to the "Python/C++ bindings generator runtime library" (python-sip).  The reported error when starting QGIS is as follows:


Traceback (most recent call last):
  File "", line 1, in RuntimeError: the sip module implements API v8.0 but the qgis.core module requires API v7.1


This shouldn't be a big surprise, since QGIS is being installed from a repository deliberately labelled 'unstable'. However, I was not interested in downgrading QGIS and/or any of the other packages that I draw from the Ubuntu GIS repository, and as far as I can tell, 'unstable' for this repository usually just means 'up-to-date', considering that the projects delivered through this repository are high quality as far as I am aware.  Although, using this repo does require a bit of care; you may have to account for significant changes in new software versions in any dependent applications you have (e.g., MapServer brought a number of changes in the latest 6.0 release, which would have required users/web developers to update their mapfiles and/or scripted code).


After a bit of googling around, I eventually found that I needed to downgrade two packages to maintain compatibility with QGIS: python-sip and python-qt4. I don't recall the original source (this was a few months ago), but if you a) want the latest Open Source GIS packages, and b) want to be able to use python-based capabilities/plug-ins on Ubuntu 10.10, then here's the steps:

1. If you don't have it already, setup the Ubuntu GIS unstable repo, and install the latest QGIS package (1.7.0 at the time of this writing):


    # sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable
    # sudo apt-get install qgis


2. Downgrade python-sip and python-qt4:

    # sudo apt-get install python-sip=4.10.5-0ubuntu1 python-qt4=4.7.4-0ubuntu1

3. If this works for you, you can consider 'pinning' the versions of these two packages so they don't get replaced the next time you install updates.  You can choose whichever method is most appropriate for you here: https://help.ubuntu.com/community/PinningHowto

I should note that QGIS will run without downgrading these python packages (albeit, after reporting the Python API errors on each startup).  However, it will be necessary if you want to use plug-ins that require Python (e.g., the OpenLayers plugin - I've been using this version: https://github.com/TheGeoist/qgis-openlayers-plugin/).

I'd be interested to know if anyone has run into this problem with Ubuntu 11.04.


2011-02-28

Converting WKT projection info to Proj4 (and back) - the PHP edition

As noted in a previous post, it is fairly easy to utilize the language bindings for the GDAL project to work with projections. However, if you're working in PHP, the corresponding GDAL bindings are not maintained and currently do not work as-is from the GDAL project. As-of GDAL 1.8.0, a bit of tinkering will get the PHP modules to compile, but they still do not work as expected.

However, you can get the php_osr.so module to work with some basic functions using the patch posted at http://pastebin.com/SXKKfe6v. Save this to a file, and apply the patch to the gdal 1.8.0 source like so:

cd /path/to/gdal/src
 patch -p0 < /path/to/patch
Then build and install the gdal code as follows:
./configure --with-php
 make
 make install
 sudo cp swig/php/php_osr.so /usr/lib/php5/20090626/
 sudo su -c \
  'echo extension=php_osr.so > /etc/php5/conf.d/osr.ini'
 sudo service apache2 restart
The above assumes: - You're doing this on a typical/recent Ubuntu installation - You already have Apache and PHP configured - You already have all the required dependencies for building gdal and the swig bindings installed (if not, run "
sudo apt-get build-dep libgdal-1.x.x
", and also you may need to install php5-devel and php5-cli packages). Once you've got gdal and the php_osr.so module compiled and installed, try the following PHP script:
<?php
 include("/path/to/gdal/src/swig/php/osr.php");
 $sr = new SpatialReference();
 $sr->ImportFromProj4('+init=epsg:4326');
 echo $sr->ExportToProj4();
?>
The result from that script should be the following Proj4 string:
+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs

Clearly, this is not as good as having all of the GDAL/OGR libraries accessible from PHP, but it's a start. You can review the swig/php/osr.php file to see what objects/functions are available through the php_osr.so module.

2011-02-05

A web page hit counter that plots your visitors on a globe.

While reading someone's NASA blog, I came across this neat little widget that plots all of your visitors as points on a revolving globe (or flat static map if you prefer): http://www.revolvermaps.com

It's free to use, and you can select from a variety of options to choose the coloring and style so that it fits into the layout of your website, and it can run using Flash or it will fail-over to Java (or neither if you choose a static map).  I'm sure this isn't entirely new to everyone, as the site has been around for over two years, but it's fairly impressive regardless.  I also gather that it collects visitor information for your site in their own database somewhere (it's not clear from the info available how this is done), so if privacy is a concern for users on your site, you may not want to add this to your site.

I've added a sample below - I imagine the dots will remain fairly sparse for this blog. :)



2011-01-13

Creating a global control in OpenLayers for specific key combinations

This is largely a follow-up to a previous post I made discussing how to effectively capture right clicks on an OpenLayers map object.  That had been related to another objective that I had, which was to have a global control that always responds to the right click in order to display a basic context menu on the map.  It's easy enough to get this working on the right-click, with all other controls working using the left click event - but what about Mac users, or people suffering from some kind of right-click impairment?  This needs a modifier key to go along with the left-click, but then there needs to be some way to prevent other controls from being triggered at the same time.

In OpenLayers, there is a common property that can be passed to handlers/controls, called keyMask.  It is used in a bitwise comparison in the checkModifiers method of the OpenLayers.Handler class.  The main issue I had was that it currently only works to allow a given control to be restricted to a specified key combination.  It also does not allow you to have a single control that responds to different keys.  Rather, any event keys added to the keyMask property of a control/handler must ALL be present in order for checkModifers to return true.  However, here's the situation I wanted:

  1. Global control (context menu): triggers on right click, or left-click + alt, or left-click + ctrl (this allows users with a one-button mouse to still access the menu), and
  2. All other controls: trigger on any left-click event that excludes the alt or ctrl keys.
So to accomplish what I needed, I added a bit of code the checkModifiers function in the OpenLayers.Handler class to make it also check for a keyIMask property (i.e., an inverse key mask...though maybe that's not the best name for it).  Where the current keyMask must match all keys included in the event in order for checkModifiers function to return true, if the keyIMask matches any keys included in the event, then checkModifiers returns false.  Here's what it looks like:

checkModifiers: function (evt) {
if(this.keyMask == null && this.keyIMask == null) {
return true;
}
/* calculate the keyboard modifier mask for this event */
var keyModifiers =
(evt.shiftKey ? OpenLayers.Handler.MOD_SHIFT : 0) |
(evt.ctrlKey  ? OpenLayers.Handler.MOD_CTRL  : 0) |
(evt.altKey   ? OpenLayers.Handler.MOD_ALT   : 0);
/* if it differs from the handler object's key mask,
bail out of the event handler */
return ((this.keyMask == null || keyModifiers == this.keyMask)
&& (this.keyIMask == null || (keyModifiers & this.keyIMask) == 0));
}

With the Handler modified in this way, I can tell any control to not respond if any key in an event matches keyIMask.  In my global control, it internally checks if the event is either right-click, or if it's a left-click with either the ctrlKey or altKey present.  All of my other controls are set with the property "keyIMask = OpenLayers.Handler.MOD_CTRL | OpenLayers.Handler.MOD_ALT;", which prevents controls from being triggered when the menu is displayed, and still leaves room for MOD_SHIFT to be used either as a keyMask, or to internally modify the behaviour of control's events (e.g., the freehand toggle in the OpenLayers.Handler.Path class).

2010-11-21

Capturing right-click events in OpenLayers

I've been looking at using OpenLayers as the mapping API for an application I've been working on for some time.  One of the key features of the application requires capturing mouse click events on the map.  This is fairly normal with OpenLayers for many of its controls, but when the right-click event is involved, I would always get the default context menu from the browser, and OpenLayers didn't seem to capture the rightclick event on its own.  There are a few workarounds posted on the web...but I found they were not easily adaptable, or didn't quite work the way I wanted.  So here's what I came up with - paste the code below at the end of the init() function in any of OpenLayers' examples:


===================================================

// Get control of the right-click event:
document.getElementById('map').oncontextmenu = function(e){
 e = e?e:window.event;
 if (e.preventDefault) e.preventDefault(); // For non-IE browsers.
 else return false; // For IE browsers.
};


// A control class for capturing click events...
OpenLayers.Control.Click = OpenLayers.Class(OpenLayers.Control, {                

defaultHandlerOptions: {
'single': true,
'double': true,
'pixelTolerance': 0,
'stopSingle': false,
'stopDouble': false
},
handleRightClicks:true,
initialize: function(options) {
this.handlerOptions = OpenLayers.Util.extend(
{}, this.defaultHandlerOptions
);
OpenLayers.Control.prototype.initialize.apply(
this, arguments
); 
this.handler = new OpenLayers.Handler.Click(
this, this.eventMethods, this.handlerOptions
);
},
CLASS_NAME: "OpenLayers.Control.Click"

});


// Add an instance of the Click control that listens to various click events:
var oClick = new OpenLayers.Control.Click({eventMethods:{
'rightclick': function(e) {
alert('rightclick at '+e.xy.x+','+e.xy.y);
},
'click': function(e) {
alert('click at '+e.xy.x+','+e.xy.y);
},
'dblclick': function(e) {
alert('dblclick at '+e.xy.x+','+e.xy.y);
},
'dblrightclick': function(e) {
alert('dblrightclick at '+e.xy.x+','+e.xy.y);
}
}});
map.addControl(oClick);
oClick.activate();

===================================================



The first bit overrides the oncontextmenu event that causes the browser to display a context menu when the right-click event happens.  The next bit creates a simple control class for handling the click events, with the handleRightClicks option enabled.  After that, an instance of the control class is created, with functions for the four different click event types included in the eventMethods option.  Finally, this control is added to the map and activated...any better solutions are welcome.


EDIT: This has been corrected to utilize the 'handleRightClicks' property in the OpenLayers class. Other than this, all that is essentially needed is the overridden oncontextmenu function, which uses preventDefault (for non-IE browsers), or returns false (for IE browsers).

Converting WKT projection info to Proj4 (and back)

I've had many occasions where I've had WKT-style projection text (e.g., the contents of the *.prj files that normally accompany ESRI Shapefiles, or the srtext field in the spatial_ref_sys table in PostGIS), and I needed to get that to an equivalent Proj4-compatible projection string (and vice versa).  I've known for some time there had to be an automated way to do this...as the GDAL/OGR libraries have been doing this internally for some time.  I ran into the issue again today, so I decided to poke around a bit, and found the API functions that are available to do this...I wrote my first ever Python scripts that use the GDAL/OGR python bindings (specifically, OSR).  These scripts simply convert WKT projection text to Proj4 (wkt2proj.py) and back (proj2wkt.py).  Maybe there are some better examples elsewhere...but I didn't quite find what I was looking for.  Since my work is mostly in PHP right now, I'd love to see the GDAL/OGR PHP bindings maintained someday, but this will do for now:

================== wkt2proj.py =======================
#!/usr/bin/env python

import os
import sys
import string
import osgeo.osr

if (len(sys.argv) <> 2):
        print 'Usage: wkt2proj.py [WKT Projection Text]'
else:
        srs = osgeo.osr.SpatialReference()
        srs.ImportFromWkt(sys.argv[1])
        print srs.ExportToProj4()
======================================================

================== proj2wkt.py =======================
#!/usr/bin/env python

import os
import sys
import string
import osgeo.osr

if (len(sys.argv) <> 2):
        print 'Usage: proj2wkt.py [Proj4 Projection Text]'
else:
        srs = osgeo.osr.SpatialReference()
        srs.ImportFromProj4(sys.argv[1])
        print srs.ExportToWkt()
======================================================

On Ubuntu, provided you have the python-gdal package installed, the above files executed by python will accept the first argument as a wkt/proj projection string, and return the proj/wkt equivalent.  For proj2wkt.py, you can also take advantage of known EPSG numbers.  For example, the WKT for the Spherical Mercator projection used by most free online mapping services (e.g., Google Maps, OpenStreetMap, etc) will be returned by: proj2wkt.py '+init=epsg:3857'

I haven't tested this on Windows - but as long as the Proj library is installed and the GDAL Python modules are installed and accessible to the Python environment, I imagine they will work the same.