The [http://code.djangoproject.com/browser/django/branches/gis gis] branch intends to add a contrib app implementing geographic support.

= What's GIS? =
 * [http://cfis.savagexi.com/articles/category/gis Series of blog posts] giving intro to GIS; choice quote from [http://cfis.savagexi.com/articles/2006/04/20/on-coordinate-systems#comments an early post]: "If you feel like ending a conversation with a developer then simply bring up the topic of character encodings ... [o]r ... coordinate systems. ... So in the spirit of Tim Bray's and Joel Spolsky's wonderful writeups of character encodings, I thought I'd put together a basic survival guide to coordinate systems over my next few posts and then tie it back to Google Maps."
 * More on [http://en.wikipedia.org/wiki/Map_projection map projections], including why people can't agree on just one (utf-8).
 * [http://en.wikipedia.org/wiki/Geodesy geodesy] the field of science for this stuff.

= Useful code =
 * [http://postgis.refractions.net/ PostGIS], the [http://www.opengis.org/docs/99-049.pdf OpenGIS SQL Types (pdf)] implementation for Postgresql
 * [http://geos.refractions.net/ GEOS], low-level C++ port of [http://www.jump-project.org/project.php?PID=JTS Jave Topology Suite], used by PostGIS
   * [http://zcologia.com/news/14/python-geos-module/ PyGEOS, now outdated due to PCL, below], and shedloads more stuff on "python, geospatial, and the web"
   * [http://gispython.org/ Python Cartographic Library] - [http://trac.gispython.org/projects/PCL actively maintained], huge GIS package, GPL.
   * There are direct SWIG Python bindings in GEOS 3.0.0RC1 and above.  In other words, the entire GEOS API may be called directly from Python.
 * [http://www.initd.org/tracker/psycopg/wiki/GeoTypes GeoTypes] is a type (and conversion) library for PostGIS via psycopg.
 * [http://exogen.case.edu/projects/geopy/ Geopy] 
   * Calculates distances using (very accurate) [http://www.movable-type.co.uk/scripts/LatLongVincenty.html Vincenty], and uses the [http://en.wikipedia.org/wiki/World_Geodetic_System WGS 84] datum by default.
   * Has utility functions for unit of measurement (UOM) conversions (e.g. meters -> kilometers, kilometers -> miles, etc.)
   * Excellent GeoCoding capabilites.  Has interfaces for Google, Yahoo, Microsoft Live, MediaWiki, and [http://www.geocoder.us/ Geocoder.us].
 * [http://www.gdal.org/ GDAL/OGR], a library for fiddling with raster geo images.
   * Has a Python interface.  A SWIG interface is in development, but not yet stable (no access to ''full'' API).
 * [http://search.cpan.org/~sderle/Geo-Coder-US/ Geo::Coder::US] An excellent ''Perl'' library for GeoCoding that powers [http://www.geocoder.us/ Geocoder.us].  Users can create their own Geographic databases using the Census Bureau's TIGER/Line data (see below).
 * [https://svn.greenpeace.org/projects/custard/browser/doc/geodata GeoRosetta], CC-BY-SA licensed, quality-controlled, collection of geocoding data.  Not yet released to public(?).
 * [http://mapserver.gis.umn.edu/ MapServer]: University of Minnesota (UMN) "open source development environment for building spatially-enabled internet applications."
 * [http://www.mapnik.org/ MapNik]: C++ and Python toolkit for developing mapping applications.  Claimed benefits over MapServer: "It uses the AGG library and offers world class anti-aliasing rendering with subpixel accuracy for geographic data. It is written from scratch in modern C++ and doesn't suffer from design decisions made a decade ago." ''See'' [http://www.mapnik.org/faq/ MapNik FAQ].

= Questions =
 * When dealing with points (say, degrees) from, do they need to be converted to be useful on the back-end data, assuming -that- data is in degrees?  Is it enough to have the same datum and origin?  (Reading the intro above is likely to answer the question.)
   * My (JDunck) reading indicates yes.  Given the same coordinate system (i.e. datum, origin, and axes), degrees are useful without conversion.

= Implementation =

== Phase 1 ==
  Assume existing data and columns, and that the UOM given is same as backing data.
  Support a custom manager (and queryset) to support lookups.

=== GeoTypes ===
  GeoTypes 0.7 supports both psycopg1 and psycopg2.  Upside is conversion from type params to SQL.  Simplifies (avoids?) QuerySet modification.  Maintainer of GeoTypes has been responsive as of Feb 26 2007 on the psycopg mailing list.
  Example code, where point and box are types from GeoTypes.OG*:
{{{
from django.db import models
from django.contrib.gis import db as gis_db

class School(meta.Model):
  name = ...
  objects = gis_db.Manager()

Assume a location column has already been added to the DB, e.g.
select addgeometrycolumn('','schools_school','location',-1, 'POINT', 2);

Then this would work:
from django.contrib.gis.geometry import Point
x = Point(-95.36819458007812, 30.2184318620219)
School.objects.geo_near('location', point=x, radius=1.0)

This could construct a LinearRing approximating the circle around x
and issue something like:

poly = "POLYGON (...points from curve approximation...)"
_where.append("""
where schools_school.location && %s and
within(schools_school.location, %s)
""")
_params.append(poly, poly)
}}}

=== Geos ===
  I'm not sure how we can use GEOS without also doing something like GeoTypes down in the QuerySet.  Ideas?



== Phase 2 ==
=== Field Types ===
 * To allow update through ORM, new fieldtypes would be needed.


=== GIS utilities ===
wrapper for geos, have the ability to do something like

{{{
from django.contrib.gis import area
area(bbox.geom)
}}}