Technical Ramblings

иконописSo, on Sunday, we released the new version of OpenLayers, with updated mobile support. This included the ability to do dragging and panning and even editing of features on mobile devices, including Android and iOS.

Last week, I finished up a quick project, called olhttp. olhttp is a demo of how to use the OpenLayers HTTP protocol to create a simple, straightforward UI for editing features — but one that is easily customizable.

This afternoon, I decided to make an attempt to put these two things together — specifically, to make it possible to demo feature editing on a mobile device like my new tablet, saving the features and then being able to display them on my Nexus S or a laptop. So, I wanted a quick and easy deployment plan for a GeoDjango app — after my experience with DotCloud, I’ve come to the realization that hosting my own shit is for chumps (unless I really need some specific high-level SLAs for uptime, which I almost never do for personal projects).

Luckily, I happened to be at a table full of FOSS4G Django Hackers, so they were able to suggest DjangoZoom, which recently added support for GeoDjango/PostGIS. I was able to apply for an invite, and later that afternoon, I had one, and was able to start playing with it.

Now, at the time, I was in a talk, so the only thing I had with me was my tablet; I figured I’d set my account up, and see how it went. Turned out, the answer was “really well”.

The way DjangoZoom works by default is that you give it a Github repository URL, and it will automatically fetch the code for you, and set up a Django database, appserver, etc., deploying your application’s code to the DjangoZoom servers. What does this mean in practice? Well, for me, it meant that I was able to continue with the setup process for DjangoZoom — all the way up through actually getting a working application deployed, without even switching from the tablet to the laptop. I provided my Django app to the platform, and it worked right out of the box.

After getting my application deployed in just minutes, I then moved onto modifying my app to specifically target touch devices. This included modifying the UI to be more touch friendly — larger editing icons, for example, since the defaults are very difficult to hit on a tablet or phone screen, with 200 ppi. This work (in a new github repo for the time being, olhttp-django) complete, I now have a simple, easy to use tablet editing UI. It works on phones like iOS and Android, it works in all browsers on the desktop, and it provides an easy to use data-input mechanism — and I never had to touch an Apache config.

That’s what I call “success”.

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.