Django site development

This summer one of my major preoccupations was taking a mapping interface and integrating it into a Django framework. I had developed the former with a MySQL database backend, with PHP scripts accessing that database and serving up a dynamically loaded KML file (Google Earth’s file format) to an OpenLayers viewer. One could add data through PHP scripts as well. We decided on this approach instead of Google Maps in order to utilize open-source technology and to retain “ownership” of the data (unless I’m mistaken, data generated in Google Maps belongs to the behemoth, not the creator of the data). Also, the biggest reason we went this direction is because we wanted to enable commenting, which is only available through clunky workarounds in GM.

My project this summer, then, was to migrate this interface to (Geo)Django in order to enable user authentication and take advantage of Django’s built-in functionalities. Unfortunately, Django uses Python as it’s language, necessitating a complete disposal of all PHP code from before. Also, I quickly realized that a MySQL database is very, very limited relative to PostGRES (since it’s not OGC-compliant).

So I’m now at the stage where comments, feature addition, and user management are all working on my site. Data is served to OpenLayers via a KML dynamically-generated in Django. I had to write the KML script manually because MySQL does not allow Django to create that (in contrast with PostGRES, which does allow it). Given more time and development experience, I probably would have chosen to develop with an IDE, but that would have meant needing to learn yet another technology, which I found prohibitive.

There remain some issues that I suspect will be unresolvable given my time and ability constraints. It would be nice to have the user choose their own symbology. Currently, since I manually scripted the KML-generator, I have hard-coded the symbologies. Also, I intend to put a “delete point” option on the screen for administrators, but it would be nice if the points were loaded into a list in the admin page of the site.

On the one hand this speaks to the incredible capabilities of software: it can allow a sort of “digital storytelling” that can be empowering to a degree. On the other hand this highlights the challenges faced by those wishing to develop with open-source technologies, particularly those with little prior programming experience or time. A non-profit organization, for instance, may find it prohibitively time-consuming and, ultimately, expensive to develop their own mapping platform. Included in costs are labor, IDE software, server/hosting costs, and costs associated with learning new technologies; whereas with Google Maps, most of this is free and the learning curve is significantly more manageable.

One more final point is that this project highlights the need for technical skills. This need comes in two forms. First, technical skills are necessary even for non-technical researchers. Technology’s potential in the digital humanities and social sciences is enormous, but to fully leverage them often requires a high degree of programming literacy. Second, this project demonstrates how much the digital humanities and social scientists need access to computer programmers. We need fewer institutional barriers to bringing in technical expertise and programming abilities.

Later this month I will give part of a keynote address at a conference. I will present a similar talk there, stressing the issues I noted above. The conference is the Association of Washington Geographers, and to support my points above, I was told to focus more on the teaching potentials this platform offers, rather than the ‘techie’ stuff. In other words, they don’t want to hear about the challenges of integrating different open source programs. Oh well, I guess that’s what I’m here for.