Recently I was asked to present my evaluation of a geospatial web framework called GeoDjango. This was in the context of a job interview with a center for geographical analysis at a local university.
I had to come up with a presentation based on benefits or features relative to a proposed system that the center wanted to develop for allowing users(researchers presumeably) to upload and manage map related data for geospatial analysis. Not knowing anything about GeoDjango or much about the whole geospatial research domain outside of my limited WorldWind exposure this was quite a test. As part of this presentation and my own attempt to show my skills for the interview, I set up a demo installing GeoDjango locally following some basic tutorials. The following is a summary of my analysis taken from my presentation.
GeoDjango - Summary
• Built as extension to the Django web framework written in Python.
• Open Source
• Includes related Geospatial Python libraries: GDAL/OGR(subset of full GDAL features, vector only), GEOS (geometry operations), PROJ.4(map coordinate projections)
• Support for spatial databases, PostGIS, Oracle, MySQL, etc…
• Extends Django Admin Site for directly editing models
• Built in cmd-line utilities for importing data into your database
GeoDjango – Some Useful Features
Based on the requirements I was given I took a look at the various features you get out of the box by using this framework over any of the other general frameworks of which there countless numbers these days or other “similar” products written in Java, Ruby, etc.
You do get some useful features, mostly the big draw that Django provides is it’s default CRUD administration interface where you can directly modify database records or just view them. In addition to CRUD representation for your “Models” (essentially a Model is the Django representation of a db table), you get a user admin interface for adding/updating user accounts as well as groups of users. The Django framework includes a basic permission model, where you can assign users or groups to the pre-defined permissions. The permissions allow you to grant users the ability to add records, update records or delete records. These permissions are enforced by the admin UI, though you would have the methods to check user’s permissions when creating your own UI pages. One missing privilege in my opinion is a “view” permission.
Beyond the front end the Django model provides various libraries set up for some common features of any web framework such as user authentication, a comment framework with automated moderation. On the geospatial side there seems to be the useful inclusion of the various geospatial libraries. What seems to be useful, not being an expert, were the inclusion of libraries for simplifying queries to the spatial database, supposedly no SQL required. There is also good support for conversion of your spatial data into various output formats such as the GML or KML formats.
Analysis of GeoDjango supporting requirements
These were some of the requirements the center had, and my evaluation of them.
User to upload spatial data (Shape, GeoTiff at a minimum)
• Shape Files
▫ Possible, Python utilities exist for importing Shape files
▫ Different Shape file attributes require coding Python models
• Geotiff
▫ Raster formats are not supported in GeoDjango
▫ Possible other 3rd party libraries could be leveraged (WKTRaster for PostGIS)
User to control visibility of data (who can see my data, public, private, shared)
• Django administration UI allows configuring permissions for user access to a Model type, but not by “owner” or “creator” of instances of Models.
• Only administrators have ability to add or remove permissions from other users. No way to specify which permissions they could grant or take away.
• Would require some extension of Django security model to provide this feature as well as change to UI screens.
User to control access to who can interact with their data
• Can restrict who could see or edit through the admin UI by Models but not by a user’s own content.
• Permissions not granular enough for mark-up / edit distinction in admin screen.
• Would require extension of security model and rework of current admin UI.
Conclusion
• Some of the central requirements are not available in GeoDjango off the shelf.
• Implementing the required features could still be done in GeoDjango framework.
• Most useful features of GeoDjango seem to be on server-side relating to interacting with the geospatial data.
• Django itself provides useful framework for dynamic website creation.
References
Couldn’t possibly list every site I visited to find all this data, and some of it came from my own observations. Here are few useful sites for more information
· http://geodjango.org/presentations/
· http://groups.google.com/group/geodjango
· http://docs.djangoproject.com/en/1.2/ref/contrib/gis/install/#windows-xp
· http://www.ohloh.net/p/geodjango
· A day with GeoDjango - Thinking in GIS
· http://www.geowebguru.com/articles/99-overview-geodjango
No comments:
Post a Comment