Just a quick post to let everyone know that I’ve updated django-geo to version 1.1. This adds a number of enhancements, foremost of which are in the geocoding components.

Previously, to save myself time and effort I had used the excellent geopy‘s geocoders to lookup co-ordinates for a place. This worked well; as long as all you need is co-ordinates. What if you need to get the precision of the result? You don’t want to be zooming down to street-level if you’ve got a city-level geocoding response. It’s near impossible to deduce from a latitude/longitude (in the way they were stored) how precise a result was. So, I’ve written my own suite for geocoding that makes it ridiculously easy to get all kinds of juicy data from any XML geocoder you can throw a stick at, and make new geocoders in only a few lines of code.

How results are stored

With this geocoding goodness, comes a bit of change to how the results are stored. As I’ve learned with a side-project I’ve been hacking away at in the (small amount of) free time I have, it’s useful to be able to access lots of attributes a geocoder may give to you. If they return structured address data (as Google’s does [among others]), then why should you not be allowed to get at it. Thus, I took the design decision to allow full access to the returned XML (along with a parsed version to make it ridiculously quick).

In your Location model, now there is an additional attribute called result. This is a Python class that stores all manner of cool data from the response from the geocoder. This includes, an class for coords, which stores latitude & longitude as well as elevation and result precision (granularity). Result precision is always represented as a Google Maps zoom level (0 to 21; I believe), this is because I find they are the most granular (and easiest to deal with) precision levels I could find (plus they’re commonly used). If you need them in another format, there should be something in django-geo.misc to help you.

It’s worth noting, however, that if a geocoder does not return a precision level this will be set to 0.

In addition to this, there is a response attribute which has the raw data, as well as a data dictionary, containing every tag found in the document along with their content (text) and attributes (attrs). I’m not going to go into great detail about all of this, if you need to see how this works, take a look at the code in django-geo.geocoding — it’s all pretty self-explanatory.

Other geocoders

I’ve only included Google, Yahoo! and GeoNames geocoders. These are the ones I’ve found to be the most useful; but if you find you’d like to have others, it really couldn’t be simple. Simply subclass django-geo.geocoding.XMLGeocoder (all my geocoders already do this; look to them for sample code) and everything should work out just peachy. If you do make one, send it across and I’ll include it in the SVN release straight away and the next release when it’s out.

What’s next?

For this release, I had planned to have some mapping functionality built-in. However, this has proved a little harder than I would have hoped (I’m including a lot of map types), and I’ll release this in 1.2 — it shouldn’t take too long, though, as this release lays a lot of the groundwork needed. If you’re desperate for this functionality before then, don’t hesitate to shout.

Happy geotagging!