Technical Ramblings

After climbing Table Mountain yesterday, I’m somewhat beat, but was able to make it up at 0730 to give a GeoDjango workshop with Josh. After spending the first hour running around attempting to get power for everyone and get DVDs copied, we got started.

Overall, the workshop went well. We had a variety of users — including two people who were relatively successful with running GeoDjango from their own (mac) laptops. I’ve learned a few things about using VMWare — for example, I was reminded that there is no real VMWare option for PPC Macs, and that installing VMWare on Mandriva is not as trivial as it maybe should be.

I was able to get two of my machines working with the VMWare DVD we had and distributed (link later once I talk to Josh and we fix some of the missing things), and gave them out to people. With our 25 people, we had about 15 laptops running, with others sharing.

Learned a few key points: For one, our documentation on the workshop was insufficiently explanatory of how to do things like “edit files”, “open a terminal”, etc. A number of people were facing significant problems towards the start because of that. (Also, not installing vim on the VMWare image was problematic for me, and Erik had the same problem with emacs.) Due to the somewhat staggered start, we got a little bit lost in the weeds pretty quickly, and didn’t get a chance to really explain what GeoDjango was about to start, which I think was a lack in the workshop.

Overall, we got through setting up the VMWare image (though not installation from scratch), starting a project, creating a model, setting up the admin (with this being one of the more difficult parts, specifically because almost no one had internet access within the VM), generating KML, viewing the KML on an OpenLayers map, and using the GDAL tools (LayerMapping) to import polygon data from a shapefile and view/edit that. A couple people got ahead through creating a Ward view as well, which was nice.

There are a number of aspects of the workshop that need more polish, but overall, I think people who were interested got to see GeoDjango in admin, and see why it’s pretty cool. Hopefully we can clean up our workshop docs to make it smoother for the next person to walk through it, and get more people interested in GeoDjango and learning about Django in general through that.

Earlier today, a coworker was trying to work out a diagram for the models in the Django app that I’ve been working on internally, to visualize the relationships between them. I did a quick Google, and found a reference to DjangoGraphviz, a super-handy little chunk of code.

DjangoGraphviz did exactly what I needed it to, with no problems at all. (My only complaint is that it requires the DJANGO_SETTINGS_MODULE to be defined in order to get the –help output, somewhat unintuitive.) The software quickly generated a .dot file which I was able to turn into a lovely PDF, and print. I’ve now got a copy on the desk of each of the developers using the codebase, and I think it’ll prove a lovely piece of reference.

So, if you want a quick visualization of your Django models, and you can install graphviz, I highly recommend DjangoGraphviz to do it.

(Note that the wiki page itself recommends a couple other things more ‘built in’ to Django, which are new to me: I didn’t try these, I just stuck with DjangoGraphviz, which did what I wanted.)

So, I’ve just made some updates to spatialreference.org:

• Added comments to EPSG reference pages
• Added human readable wkt output
• Added pagable listing of EPSG codes
• Searching of spatial reference titles
• Searching of WKT

With this, I think I have removed my need to ever have to touch /usr/share/proj/epsg again. The reasons I touched it in the past were usually to search based on title or to add a new projection. Once the new GDAL/OSR is out and installed where I need it, I will be able to use SR.org as references rather than needing to edit proj/epsg to add my own.

Also, for the record, I love Django. This has been the easiest web coding of my life. I spent yesterday porting a half-baked app that was spread over 4 different SVN directories into one Django app. Took me a day, but now instead of a bunch of half-baked stuff that can only be put together by me, I can actually hand the code to someone else and have them run it. (It’s still a bit hard to get up and running on some platforms, because it depends on PostGIS, Python bindings for Postgres, MapScript, OGR, and GDAL. Which are non-trivial on non-Linux platforms.)

It’s great. Thanks to hobu for getting me started with it.

From a post by Howard Butler to gdal-dev:

Chris Schmidt and I have been working on a website that reflects the EPSG spatial reference codes database and user-contributed codes in a variety of output formats. The EPSG code database is never as up to date as you would like, and we frequently tell people to hack their /usr/share/proj/epsg database file with made up codes to support alternative projections. If we could consume URL-based spatial references with OSR, all that would be required is someone adds the custom coordinate system definition to the site and then everyone could refer to it at that location (hopefully indefinitely).

As for the website itself, if it has uptake and people find it useful, we will work to put it somewhere it can live for a very long time — for example OSGeo. The source code (it’s written in Django) will be made available so anyone can stand up their own version of the site.

I’ve been having a lot of fun: this is my first real foray into Django, and I wish I’d done it long ago.