Changes between Version 4 and Version 5 of GeoDjangoModelAPI
- Timestamp:
- Oct 30, 2007, 7:16:29 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GeoDjangoModelAPI
v4 v5 29 29 30 30 In addition to the regular [http://www.djangoproject.com/documentation/model-api/#field-options field options] available for Django models, Geographic-enabled models have the following additional options: 31 * {{{srid}}}31 * `srid` 32 32 * Sets the SRID (Spatial Reference System Identity) of geometry to the given value. Defaults to 4326 (WGS84). ''See'' Open GIS Consortium, Inc., ''[http://www.opengis.org/docs/99-049.pdf 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). 33 * {{{index}}}34 * 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.33 * `index` 34 * 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. 35 35 36 == !GeoMixin ==37 38 The [http://code.djangoproject.com/browser/django/branches/gis/django/contrib/gis/db/models/GeoMixin.py GeoMixin] is no longer necessary for all geographic-enabled models as of r6467. The mixin used to provide extra instance methods ([wiki:GeoDjangoDatabaseAPI#ExtraInstanceMethods discussed in the database api docs]) for geographic models without subclassing (aka ModelInheritance) -- which is not yet functional in Django.39 36 40 37 == !GeoManager == 41 38 42 In order to conduct geographic queries, each geographic model requires {{{GeoManager}}}. This [http://www.djangoproject.com/documentation/model-api/#managers 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:39 In order to conduct geographic queries, each geographic model requires `GeoManager`. This [http://www.djangoproject.com/documentation/model-api/#managers 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: 43 40 {{{ 44 41 #!python … … 59 56 >>> qs = Address.objects.filter(zip__poly__contains='POINT(-104.590948 38.319914)') 60 57 }}} 58 59 60 == !GeoMixin == 61 62 '''Update:''' The [http://code.djangoproject.com/browser/django/branches/gis/django/contrib/gis/db/models/GeoMixin.py GeoMixin] is no longer necessary for geographic models as of r6467. The mixin used to provide extra instance methods ([wiki:GeoDjangoDatabaseAPI#ExtraInstanceMethods discussed in the database api docs]) for geographic models without subclassing (aka ModelInheritance) -- which is not yet functional in Django.