Zippity Doo Dah

Back in mid 2003 NVision had just a handful of geospatial programmers and we were relatively unknown outside of the NASA Stennis Space Center incubator which housed our tiny office. So I was surprised when a stranger who had googled us called asking about a adding a zipcode store finder to his website. "Simple enough," I thought.

I quickly did the calculations in my head for labor and data preparation of an HTML iframe containing a form with an ArcIMS map. I put the stranger on hold and ran my estimate by my boss. It sounded reasonable to him. So I took the stranger off hold and said, "Yes sir, we can do that for about $2,000." He repeated the figure back to me in disgust, "Two-THOUsand dollars? Are you kidding me?" He hung up. I was caught off guard. Didn't this guy realize what he was asking for? Geocoding stores, running those points against polygons, returning a distance to the would-be customer - and all on the Internet of all places. This was before GoogleMaps mind you.

Of course the point of all this is to show how far we've come in 6 years. Now zipcode calculators are a nifty hack people blog about using their cell phone on the way to the airport. And there are plenty for Python.

Here's several Python zipcode calculators in order of complexity.

This one uses a database built in MySQL:;
http://jehiah.cz/archive/spatial-proximity-searching-using-latlongs

This one provides a python interface to geonames.org:
http://www.zindep.com/news/interface-python-pour-geonames/?searchterm=geonames

Here's one using SQLObject to store the data
http://www.zachary.com/s/blog/2005/01/12/python_zipcode_geo-programming

And just to show how common this concept has become - it's now a casual entry in the Python Cookbook alongside other bits of trivial python code:
http://code.activestate.com/recipes/393241/

Granted some of these scripts are distance calculators but I have to concede the stranger who called me in 2003 was absolutely right but maybe a little ahead of his time. It was really more of a $200 problem than $2000.

Spectral Python - Hyperspectral that is...

Spectral Python or "SPy" for short is a labor of love by Thomas Boggs. It is also one of the .001% of Python

projects that make this GeospatialPython.com and not PythonWebMapping.com or SomePythonScriptsforGISDataConversion.com.

SPy has been around for about 7 years for remote sensing using hyperspectral (or multispectral) data. Amazingly SPy has only one dependency - NumPy. This lone dependency means Thomas wrote his own drivers for the supported raster formats! I mean who does that? Besides Frank Warmerdam, I thought everyone just plugged in GDAL/OGR. Seriously though - it makes sense.

In the GIS world data needs to be reasonably put together to do some useful GIS analysis whereas in true remote sensing every pixel counts and even minor errors in the data can lead to large errors in the end product. So SPy uses pure Python drivers to load the following file types into NumPy: AVIRIS, ERDAS .LAN, ENVI headers and data, pure BSQ, BIL, and BIP files.

SPy performs a variety of remote sensing operations including supervised and unsupervised classifications, NDVIs, hypercube renderings, and more.

At NVision our work often leads into precision agriculture. In 2003 we built a large, web-based precision Ag system for InTime Inc. in Cleveland, Miss. We were working with a lot of NDVIs and classified NDVIs using InTime's prototype system and the flashy, new, web-based processing system we were building for them. Our deadline was the growing season in 2003 and the development pace was frantic. We were testing the remote sensing output of the two in-house systems against the output of as many tools developed by other people that we could.
During this time I found SPy and used it as part of our test suite.

Our software worked, we shipped it on time, and InTime is now one of the most successful companies in their industry. But I never forgot SPy and sent Thomas an e-mail after the project ended. I was surprised to find it back then because it didn't show up in the usual forums or Google searches. Even now it lingers in obscurity. Try searching for "Python remote sensing" or "Python ndvi" and you won't see it readily. I was happy to see Thomas is still updating the software as late at Feb. 2008 so here's another Google hook for it.

Mapnik - Maybe the best Python Mapping Platform Yet

The vast majority of geospatial libraries are written in either C or C++ for two reasons: 1) Speed and 2) Many of these libraries have began development when C/C++ were the languages du jour.

Over the years Python bindings have appeared for many of these libraries to make them more easier to use. These bindings are extremely helpful as so much of geospatial work involves one-off data conversions or quick map production. Over the last few years several Python libraries have emerged developed from the ground up for Python and these are downright fun!

One of the most notable examples is Mapnik started by Artem Pavlenko. Mapnik caught my eye when it first started because it promised to have a great Python API. Mapnik also had a sharp focus on attractive maps using anti-aliasing and some relatively new graphics libraries. When I checked in on Mapnik recently I was really impressed.


View Larger Map



Mapnik fills all the checkboxes for a great python tool and it's a great geospatial library as well. It has pre-compiled binaries for python 2.5 so there's no need to go back and forth to the mailing list just to get it to compile before you see if you like it or not. Most opensource libraries have troubles keeping documentation current with the rapid pace of development. Mapnik addresses this problem by heavy use of example/test scripts and a busy wiki with lots of examples from users and developers.

Another interesting feature of Mapnik is its straightforward xml dialiect for styling maps allowing you to cleanly separate map appearance from programming logic. And not to forget one of the core values of the library the rendering is truly great. There are several output options including svg and pdf using either the Agg or Cairo graphics libraries. The developers openly compare the rendering quality to GoogleMaps and rightfully so. Mapnik goes beyond antialiasing and rouned line joints to address even more interesting rendering challenges. One striking example of the rendering quality is the new "BuildingSymbolizer" which creates a nifty "pseudo 3D building effect" on polygons.

Mapnik was designed from the start for both web and desktop use. OpenStreetMap uses the library to render it's map. Go to OpenStreetMap.org and zoom into London to see it in action. From its trendy Django website and Trac Wiki to its slick rendering, xml map descriptors, and ready-to-run pythonic API Mapnik is a modern geospatial python library that will certainly add users to the geospatial python community.