This document explores the details of the GeoDjango Model API. Throughout this\nsection, we’ll be using the following geographic model of a ZIP code and\nof a Digital Elevation Model as our examples:
\nfrom django.contrib.gis.db import models\n\nclass Zipcode(models.Model):\n code = models.CharField(max_length=5)\n poly = models.PolygonField()\n\nclass Elevation(models.Model):\n name = models.CharField(max_length=100)\n rast = models.RasterField()\nSpatial fields consist of a series of geometry field types and one raster field\ntype. Each of the geometry field types correspond to the OpenGIS Simple\nFeatures specification [1]. There is no such standard for raster data.
\nGeometryFieldLink para este cabeçalho#The base class for geometry fields.
\nPointFieldLink para este cabeçalho#Stores a Point.
LineStringFieldLink para este cabeçalho#Stores a LineString.
PolygonFieldLink para este cabeçalho#Stores a Polygon.
MultiPointFieldLink para este cabeçalho#Stores a MultiPoint.
MultiLineStringFieldLink para este cabeçalho#Stores a MultiLineString.
MultiPolygonFieldLink para este cabeçalho#Stores a MultiPolygon.
GeometryCollectionFieldLink para este cabeçalho#Stores a GeometryCollection.
RasterFieldLink para este cabeçalho#Stores a GDALRaster.
RasterField is currently only implemented for the PostGIS backend.
In addition to the regular Opções de campos available for\nDjango model fields, spatial fields have the following additional options.\nAll are optional.
\nsridLink para este cabeçalho#Sets the SRID [2] (Spatial Reference System Identity) of the geometry field to\nthe given value. Defaults to 4326 (also known as WGS84, units are in degrees\nof longitude and latitude).
\nChoosing an appropriate SRID for your model is an important decision that the\ndeveloper should consider carefully. The SRID is an integer specifier that\ncorresponds to the projection system that will be used to interpret the data\nin the spatial database. [3] Projection systems give the context to the\ncoordinates that specify a location. Although the details of geodesy are\nbeyond the scope of this documentation, the general problem is that the earth\nis spherical and representations of the earth (e.g., paper maps, Web maps)\nare not.
\nMost people are familiar with using latitude and longitude to reference a\nlocation on the earth’s surface. However, latitude and longitude are angles,\nnot distances. In other words, while the shortest path between two points on\na flat surface is a straight line, the shortest path between two points on a curved\nsurface (such as the earth) is an arc of a great circle. [4] Thus,\nadditional computation is required to obtain distances in planar units (e.g.,\nkilometers and miles). Using a geographic coordinate system may introduce\ncomplications for the developer later on. For example, SpatiaLite does not have\nthe capability to perform distance calculations between geometries using\ngeographic coordinate systems, e.g. constructing a query to find all points\nwithin 5 miles of a county boundary stored as WGS84.\n[5]
\nPortions of the earth’s surface may projected onto a two-dimensional, or\nCartesian, plane. Projected coordinate systems are especially convenient\nfor region-specific applications, e.g., if you know that your database will\nonly cover geometries in North Kansas, then you may consider using projection\nsystem specific to that region. Moreover, projected coordinate systems are\ndefined in Cartesian units (such as meters or feet), easing distance\ncalculations.
\n\nAdditional Resources:
\nspatialreference.org: A Django-powered database of spatial reference\nsystems.
The State Plane Coordinate System: A website covering the various\nprojection systems used in the United States. Much of the U.S. spatial\ndata encountered will be in one of these coordinate systems rather than\nin a geographic coordinate system such as WGS84.
spatial_indexLink para este cabeçalho#Defaults to True. Creates a spatial index for the given geometry\nfield.
There are additional options available for Geometry fields. All the following\noptions are optional.
\ndimLink para este cabeçalho#This option may be used for customizing the coordinate dimension of the\ngeometry field. By default, it is set to 2, for representing two-dimensional\ngeometries. For spatial backends that support it, it may be set to 3 for\nthree-dimensional support.
\n\ngeographyLink para este cabeçalho#If set to True, this option will create a database column of\ntype geography, rather than geometry. Please refer to the\ngeography type section below for more\ndetails.
The geography type provides native support for spatial features represented\nwith geographic coordinates (e.g., WGS84 longitude/latitude). [6]\nUnlike the plane used by a geometry type, the geography type uses a spherical\nrepresentation of its data. Distance and measurement operations\nperformed on a geography column automatically employ great circle arc\ncalculations and return linear units. In other words, when ST_Distance\nis called on two geographies, a value in meters is returned (as opposed\nto degrees if called on a geometry column in WGS84).
Because geography calculations involve more mathematics, only a subset of the\nPostGIS spatial lookups are available for the geography type. Practically,\nthis means that in addition to the distance lookups\nonly the following additional spatial lookups are\navailable for geography columns:
\nIf you need to use a spatial lookup or aggregate that doesn’t support the\ngeography type as input, you can use the\nCast database function to convert the\ngeography column to a geometry type in the query:
from django.contrib.gis.db.models import PointField\nfrom django.db.models.functions import Cast\n\nZipcode.objects.annotate(\n geom=Cast('geography_field', PointField())\n).filter(geom__within=poly)\nFor more information, the PostGIS documentation contains a helpful section on\ndetermining when to use geography data type over geometry data type.
\nNotas de rodapé
\n\n