I’ve been trying to develop code on my Windows box. It’s the machine I sit in front of, it’s fast, and I like WingIDE. I have a Linux box for “real work”, but think there’s some discipline in moving back and forth between the two systems.
For GeoDjango hacking I decided to run the PostGIS database on my Linux box and the Django webapp on my Windows box. I’d hoped this would avoid having to install a bunch of funky binaries on Windows. No such luck. The GeoDjango docs are a bit out of date and the official GeoDjango Windows installer binary is for an old version. Here’s what I’ve learned doing it myself.
The first step is getting regular Django working. Here’s what I did:
- Installed PostGIS + dependencies on Debian (testing) via
aptitude install postgresql-8.4-postgis
- Installed stock Python2.5 on Windows from Python.org
- Installed Django 1.2 on Windows. I forget how I did this, I think using easy_install, which in turn requires installation as well. It wasn’t hard, just followed the tutorial. Django 1.2 includes GeoDjango Python libraries.
- Installed psychopg2, the database driver, on Windows. There’s binaries at http://stickpeople.com/projects/python/win-psycopg/
GeoDjango is harder. It relies on a lot of C libraries, some of which don’t support Windows well. The main hurdle is a working GEOS DLL. The GEOS page itself doesn’t have binaries. I found binaries from three places: OSGeo4W, the GeoDjango Windows Installer, and PostGIS. Here’s a quickie test program I wrote to try them out:
geosPath = r'.\libgeos_c-1.dll' from django.conf import settings settings.configure(GEOS_LIBRARY_PATH=geosPath) from django.contrib.gis.geos import tests tests.run()
Unfortunately, both the OSGeo4W and GeoDjango versions of the DLL don’t pass the tests. Version skew? Bug? The underlying error seems to be in memory management, something like
ERROR: test02_wktwriter (django.contrib.gis.geos.tests.test_io.GEOSIOTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\Python25\lib\site-packages\django\contrib\gis\geos\tests\test_io.py", line 30, in test02_wktwriter self.assertEqual(ref_wkt, wkt_w.write(ref)) File "c:\Python25\Lib\site-packages\django\contrib\gis\geos\prototypes\io.py", line 147, in write return wkt_writer_write(self.ptr, geom.ptr) File "c:\Python25\Lib\site-packages\django\contrib\gis\geos\prototypes\threadsafe.py", line 55, in __call__ return self.cfunc(*args) File "c:\Python25\Lib\site-packages\django\contrib\gis\geos\prototypes\errcheck.py", line 87, in check_string free(result) WindowsError: exception: access violation reading 0x02F12494
The library that did work for me was the version that came with PostGIS. I didn’t even install PostGIS, just grabbed the DLLs out of their zipfile. Unfortunately GEOS is spread into two files: libgeos_c-1.dll and libgeos-3-2-2.dll. The latter needs to be in a directory where Windows can find it as a normal DLL, I put it in the working directory of my own code.
GEOS was enough for me to get the tests working and my simple GeoDjango program working correctly. There’s more work to be done: I believe you want both GDAL and PROJ.4 available to GeoDjango on the Windows side. Or does PostGIS do the work on the database server? I haven’t tested that yet.
In addition to basic GeoDjango on Windows setup, here’s notes specific to my code:
- Followed instructions on getting WingIDE to work with Django
- Sweated a lot over environment considerations, specifically Python path. I hate setting up new development environments, and Django with its mix of servers and applications and developer code and third party libraries is complicated.
- I’m trying to run a script directly, not via manage.py. To make that work you need to set the DJANGO_SETTINGS_MODULE system environment variable to point to the Python path of your settings.py
- settings.py needs to specify a special database engine:
There’s some more useful notes about Windows and GeoDjango in this blog post by Reinout van Rees.