Hobu, Inc.

One of the newer Open Source GIS technologies I’ve been playing with lately is GeoDjango, and I really like where it’s going. While I’m barely passable as a web developer, I do have a lot of experience with Zope/Plone, and GeoDjango fills some big holes in the Zope stack when it comes to geospatial stuff that I don’t see ever being filled. In this weblog post, I’ll give you a little introduction to GeoDjango and why you might be interested in taking a look at it.

GeoDjango is Justin Bronn and Travis Pinney’s effort to geoify the Django project. Django has been gaining a lot of momentum in the Python space, with ex Zope Corp employee Guido Van Rossum pronouncing it as *the* web framework for Python, and high profile deployments like EveryBlock attracting attention has given folks an excuse to take a look at it. While every great web framework comes with great compromise, Django does a number of things right, and GeoDjango takes things even further. In addition, GeoDjango expects to gain quite a bit of profile in the next few months, especially with its prominent placement at Where 2.0, and it’s one bandwagon that I’ve been happily jumping on.

What does GeoDjango offer that isn’t available in other frameworks?

GeoDjango’s power comes from its ORM that helps you abstract away the (geo) database. It doesn’t take the DB entirely away, and there are some limitations, but it makes for an excellent 80/20 solution. When combined with the development momentum sweeping through the rest of Django, it provides a developer with a lot of power. But, as they say in the informercial, that’s not all…

Another advantage of an approach like GeoDjango is you *still* have your database. A distinct disadvantage of Zope is that you are pretty much married to the ZODB. While there are options to be able to pull stuff from something like PostGIS, it’s neither the preferred nor popular approach — you’re on your own. Most of the other applications in the open source geo space can all speak to PostGIS, but hardly any can speak to ZODB. This means you are out in the cold if you want to use other applications (say MapServer for fast rendering or QGIS for desktop visualization) in the spaces that they excel at.

Finally, the nature of Django’s views practically forces you to take a RESTian view of the web development world. My first experience with this was working with Chris on the development of spatialreference.org. I had been playing with Django, and it was natural to have the distinct SRS output types as URL-based resources. This connection is what precipitated the website’s development.

Some areas where GeoDjango could stand to improve

GeoDjango has a health dose of NIH syndrome. It maintains its own custom ctypes bindings to GEOS and GDAL instead of leveraging existing work in those areas (Shapely and my official GDAL Python bindings). Short term, I can’t argue that this approach has really hurt the project, but longer term, duplicate efforts like this have a chance of leaving GeoDjango lagging as the efforts with more developers and momentum continue to march on. I think it would be a long term benefit to combine these efforts where possible.

There are a number of work items that need to be done to merge the GeoDjango stuff into the main Django branch. GeoDjango exists as its own little world right now, and it doesn’t track Django exactly. I think this issue is just a manpower one, but it will be great to have geo stuff be first class in Django.

Mateusz and I have been diligently working on a new open source (BSD licensed) library for reading the venerable LAS LiDAR format in C/C++. The library, called libLAS, exists to provide stream-based access to LAS 1.0/1.1 files. It builds on work by Martin Isenburg, but it attacks the problem with a software engineering tact, rather than aspiring to be functional academic software. Martin’s library, for example, just printed all of its errors to stderr, and it was expected to be used in the context of command line utilities for the most part — not embedded as a library in other software.

It is expected that we will eventually hook libLAS up to something like OGR to provide access to LiDAR data in the context of a GIS processing library. LAS data is typically very big (millions of points), so there will definitely be some challenges to overcome to make it useful in a library like OGR, but it should be useful for straight-ahead translation operations. There would be nothing preventing you from using libLAS in your own software development, however, and Mateusz and I are looking for collaborators to help polish the library and cover the usages that most people would want. Consider this weblog post as your call to participation!