Version 4 (modified by jbronn, 10 years ago) (diff)

GeoMixin no longer necessary


Model API

This section explores the details of the GeoDjango Model API. Throughout this section, we'll be using the following geographic model of a Zip code as our example:

from django.contrib.gis.db import models

class Zip(models.Model):
  code = models.CharField(maxlength=5)
  poly = models.PolygonField()

  objects = models.GeoManager()

Field Types

The following geometry-enabled fields are available:

  • PointField
  • LineStringField
  • PolygonField
  • MultiPointField
  • MultiLineStringField
  • MultiPolygonField
  • GeometryCollectionField

Each of these fields correspond with OpenGIS Simple Features.

Field Options

In addition to the regular field options available for Django models, Geographic-enabled models have the following additional options:

  • srid
    • Sets the SRID (Spatial Reference System Identity) of geometry to the given value. Defaults to 4326 (WGS84). See Open GIS Consortium, Inc., OpenGIS Simple Feature Specification For SQL, Document 99-049 (May 5, 1999), at Ch. 2.3.8 (Geometry Values and Spatial Reference Systems, pg. 39).
  • index
    • Defaults to True. Creates a GiST index for the given geometry. Update the index with the PostgreSQL command VACUUM ANALYZE (may take a while to execute depending on how large your geographic-enabled tables are). Please note that this is different from the db_index field option since geographic indexes are created in a different manner than regular indexes.


The GeoMixin is no longer necessary for all geographic-enabled models as of r6467. The mixin used to provide extra instance methods (discussed in the database api docs) for geographic models without subclassing (aka ModelInheritance) -- which is not yet functional in Django.


In order to conduct geographic queries, each geographic model requires GeoManager. This manager allows for the proper SQL construction for geographic queries; thus, without it, all geographic filters will fail. It should also be noted that a GeoManager will be required even if the model does not have a geographic field itself, i.e.,in the case of a ForeignKey to a geographic model. For example, if we had an Address model with a ForeignKey to our Zip geographic model:

from django.contrib.gis.db import models

class Address(models.Model):
    num = models.IntegerField()
    street = models.CharField(maxlength=100)
    city = models.CharField(maxlength=100)
    state = models.USStateField()
    zip = models.ForeignKey(Zip)

    objects = models.GeoManager()

The geographic manager is needed to do spatial queries on related Zip objects, for example:

>>> qs = Address.objects.filter(zip__poly__contains='POINT(-104.590948 38.319914)')
Back to Top