GeoDjango proporciona actualmente los siguientes backends de bases de datos espaciales:
django.contrib.gis.db.backends.postgis
django.contrib.gis.db.backends.mysql
django.contrib.gis.db.backends.oracle
django.contrib.gis.db.backends.spatialite
Django admite funciones espaciales que operan sobre geometrías reales disponibles en versiones modernas de MySQL. Sin embargo, las funciones espaciales no son tan ricas como otros backends como PostGIS.
RasterField se implementa actualmente solo para el backend PostGIS. Están disponibles consultas espaciales para campos raster, pero no se han implementado funciones y agregados de base de datos espacial para campos raster.
Aquí tienes un ejemplo de cómo crear un objeto de geometría (asumiendo el modelo Zipcode):
>>> from zipcode.models import Zipcode
>>> z = Zipcode(code=77096, poly="POLYGON(( 10 10, 10 20, 20 20, 20 15, 10 10))")
>>> z.save()
Los objetos GEOSGeometry también pueden usarse para guardar modelos geométricos:
>>> from django.contrib.gis.geos import GEOSGeometry
>>> poly = GEOSGeometry("POLYGON(( 10 10, 10 20, 20 20, 20 15, 10 10))")
>>> z = Zipcode(code=77096, poly=poly)
>>> z.save()
Además, si la GEOSGeometry está en un sistema de coordenadas diferente (tiene un valor SRID diferente) que el del campo, entonces se transformará implícitamente al SRID del modelo del campo, utilizando el procedimiento de transformación de la base de datos espacial:
>>> poly_3084 = GEOSGeometry(
... "POLYGON(( 10 10, 10 20, 20 20, 20 15, 10 10))", srid=3084
... ) # SRID 3084 is 'NAD83(HARN) / Texas Centric Lambert Conformal'
>>> z = Zipcode(code=78212, poly=poly_3084)
>>> z.save()
>>> from django.db import connection
>>> print(
... connection.queries[-1]["sql"]
... ) # printing the last SQL statement executed (requires DEBUG=True)
INSERT INTO "geoapp_zipcode" ("code", "poly") VALUES (78212, ST_Transform(ST_GeomFromWKB('\\001 ... ', 3084), 4326))
Por lo tanto, los parámetros geométricos pueden pasarlos usando el objeto GEOSGeometry, WKT (Texto conocido en bienes raíces [1]), HEXEWKB (específico de PostGIS – una geometría WKB en hexadecimal [2]) y GeoJSON (ver RFC 7946). En esencia, si la entrada no es un objeto GEOSGeometry, el campo geométrico intentará crear una instancia de GEOSGeometry a partir de la entrada.
Para más información sobre la creación de objetos GEOSGeometry, consulta el tutorial GEOS.
Cuando se crean modelos raster, el campo raster convertirá implícitamente la entrada en un GDALRaster utilizando evaluación relajada. El campo raster aceptará por tanto cualquier entrada que sea aceptada por el constructor de GDALRaster.
Aquí tienes un ejemplo de cómo crear un objeto raster desde un archivo raster volcano.tif (asumiendo el modelo Elevation).
>>> from elevation.models import Elevation
>>> dem = Elevation(name="Volcano", rast="/path/to/raster/volcano.tif")
>>> dem.save()
GDALRaster objetos también pueden usarse para guardar modelos de rasters:
>>> from django.contrib.gis.gdal import GDALRaster
>>> rast = GDALRaster(
... {
... "width": 10,
... "height": 10,
... "name": "Canyon",
... "srid": 4326,
... "scale": [0.1, -0.1],
... "bands": [{"data": range(100)}],
... }
... )
>>> dem = Elevation(name="Canyon", rast=rast)
>>> dem.save()
Nota que esto es equivalente a:
>>> dem = Elevation.objects.create(
... name="Canyon",
... rast={
... "width": 10,
... "height": 10,
... "name": "Canyon",
... "srid": 4326,
... "scale": [0.1, -0.1],
... "bands": [{"data": range(100)}],
... },
... )
Los tipos de búsqueda de GeoDjango pueden usarse con cualquier método de gestor como filter(), exclude(), etc. Sin embargo, los tipos de búsqueda únicos de GeoDjango solo están disponibles en campos espaciales.
Filtros en campos «normal» (por ejemplo, CharField) pueden combinarse con los de campos geográficos. Las consultas geográficas aceptan entrada de geometría y mosaico en ambos lados y se pueden mezclar libremente los tipos de entrada.
La estructura general de los consultas geográficas se describe a continuación. Una referencia completa se puede encontrar en la referencia de búsqueda espacial.
Consultas geográficas con geometrías toman la siguiente forma general (asumiendo el modelo Zipcode utilizado en la GeoDjango Model API):
>>> qs = Zipcode.objects.filter(<field>__<lookup_type>=<parameter>)
>>> qs = Zipcode.objects.exclude(...)
Ejemplo:
>>> qs = Zipcode.objects.filter(poly__contains=pnt)
>>> qs = Elevation.objects.filter(poly__contains=rst)
En este caso, poly es el campo geográfico, contains es el tipo de búsqueda espacial, pnt es el parámetro (que puede ser un objeto GEOSGeometry o una cadena de GeoJSON , WKT o HEXEWKB) y rst es un objeto GDALRaster.
La sintaxis de búsqueda raster es similar a la sintaxis para geometrías. La única diferencia es que se puede especificar un índice de banda como entrada adicional. Si no se especifica el índice de banda, se utiliza por defecto el primer banda (índice 0). En ese caso, la sintaxis es idéntica a la sintaxis para consultas de geometrías.
Para especificar el índice de banda, se puede especificar un parámetro adicional en ambos lados de la búsqueda. En el lado izquierdo, se utiliza la sintaxis de doble guión bajo para pasar un índice de banda. En el lado derecho, se puede especificar una tupla del raster y el índice de banda.
Esto resulta en la siguiente forma general para consultas que involucran rasters (asumiendo el modelo Elevation utilizado en la GeoDjango Model API):
>>> qs = Elevation.objects.filter(<field>__<lookup_type>=<parameter>)
>>> qs = Elevation.objects.filter(<field>__<band_index>__<lookup_type>=<parameter>)
>>> qs = Elevation.objects.filter(<field>__<lookup_type>=(<raster_input, <band_index>)
Ejemplo:
>>> qs = Elevation.objects.filter(rast__contains=geom)
>>> qs = Elevation.objects.filter(rast__contains=rst)
>>> qs = Elevation.objects.filter(rast__1__contains=geom)
>>> qs = Elevation.objects.filter(rast__contains=(rst, 1))
>>> qs = Elevation.objects.filter(rast__1__contains=(rst, 1))
En el lado izquierdo del ejemplo, rast es el campo raster geográfico y contains es el tipo de búsqueda espacial. En el lado derecho, geom es una entrada geométrica y rst es un objeto GDALRaster. El índice de banda se establece en 0 por defecto en las primeras dos consultas y se establece en 1 en las demás.
Si bien todas las búsquedas espaciales pueden usarse con objetos raster en ambos lados, no todos los operadores subyacentes aceptan nativamente la entrada raster. En casos donde el operador espera una entrada geométrica, se convierte automáticamente el raster a una geometría. Es importante tener esto en cuenta al interpretar los resultados de la búsqueda.
El tipo de soporte para rasters está listado para todas las búsquedas en la tabla de compatibilidad. Las consultas que involucran rasters están actualmente solo disponibles para el backend PostGIS.
Las calculaciones de distancia con datos espaciales son complicadas porque, desafortunadamente, la Tierra no es plana. Algunas consultas de distancia con campos en un sistema de coordenadas geográficas pueden tener que expresarse de manera diferente debido a las limitaciones de PostGIS. Consulte la sección Selección del SRID en la documentación de GeoDjango Model API para obtener más detalles.
Disponibilidad: PostGIS, MariaDB, MySQL, Oracle, SpatiaLite, PGRaster (nativo)
Las siguientes distancias de búsqueda están disponibles:
dwithin (excepto MariaDB y MySQL)
Nota
Para medir, en lugar de consultar distancias, utiliza la función Distance.
Las distancias de búsqueda toman un parámetro tupla que comprende:
A geometría o raster para cálculos de base; y
Un número o un objeto Distance que contiene la distancia.
Si se utiliza un objeto Distance, puede expresarse en cualquier unidad (el SQL generado utilizará unidades convertidas a las del campo); de lo contrario, los parámetros numéricos se asumen en las unidades del campo.
Nota
En PostGIS, ST_Distance_Sphere no limita el tipo de geometría para consultas de distancia geográfica. Sin embargo, estas consultas pueden tardar mucho tiempo, ya que las distancias de círculo grande deben ser calculadas en vivo para cada fila de la consulta. Esto se debe a que el índice espacial en campos de geometría tradicional no puede utilizarse.
Para una mejor rendimiento en consultas de distancia WGS84, considere utilizar columnas de geografía en su base de datos en lugar de las anteriores porque pueden usar su índice espacial en consultas de distancia. Puede indicar a GeoDjango que utilice una columna de geografía estableciendo geography=True en la definición del campo.
Por ejemplo, supongamos que tenemos un modelo SouthTexasCity (de los pruebas de distancia de GeoDjango ) en un sistema de coordenadas proyectado válido para ciudades en el sur de Texas:
from django.contrib.gis.db import models
class SouthTexasCity(models.Model):
name = models.CharField(max_length=30)
# A projected coordinate system (only valid for South Texas!)
# is used, units are in meters.
point = models.PointField(srid=32140)
Luego se pueden realizar consultas de distancia como sigue:
>>> from django.contrib.gis.geos import GEOSGeometry
>>> from django.contrib.gis.measure import D # ``D`` is a shortcut for ``Distance``
>>> from geoapp.models import SouthTexasCity
# Distances will be calculated from this point, which does not have to be projected.
>>> pnt = GEOSGeometry("POINT(-96.876369 29.905320)", srid=4326)
# If numeric parameter, units of field (meters in this case) are assumed.
>>> qs = SouthTexasCity.objects.filter(point__distance_lte=(pnt, 7000))
# Find all Cities within 7 km, > 20 miles away, and > 100 chains away (an obscure unit)
>>> qs = SouthTexasCity.objects.filter(point__distance_lte=(pnt, D(km=7)))
>>> qs = SouthTexasCity.objects.filter(point__distance_gte=(pnt, D(mi=20)))
>>> qs = SouthTexasCity.objects.filter(point__distance_gte=(pnt, D(chain=100)))
Las consultas raster funcionan de la misma manera, reemplazando el campo de geometría point con un campo raster, o el objeto pnt con un objeto raster, o ambos. Para especificar el índice de banda de una entrada raster en el lado derecho, se puede pasar un 3-tupla a la búsqueda como sigue:
>>> qs = SouthTexasCity.objects.filter(point__distance_gte=(rst, 2, D(km=7)))
Donde se utilizaría el tercer band (con índice 2) del raster rst para la búsqueda.
La siguiente tabla proporciona un resumen de los tipos de búsqueda espacial disponibles para cada backend de base de datos espacial. Las búsquedas PostGIS Raster (PGRaster) se dividen en las tres categorías descritas en el detalle de la búsqueda raster: soporte nativo N, soporte nativo bilateral B y soporte de conversión geométrica C.
Tipo de Búsqueda |
PostGIS |
Oracle |
MariaDB |
MySQL [4] |
SpatiaLite |
PGRaster |
|---|---|---|---|---|---|---|
X |
X |
X |
X |
:bboverlaps |
||
X |
X |
X |
X |
:bboverlaps |
||
X |
X |
X |
X |
:bboverlaps |
||
X |
X |
X |
X |
X |
B |
|
X |
B |
|||||
X |
X |
X |
X |
B |
||
X |
X |
X |
X |
B |
||
X |
X |
X |
X |
C |
||
disjoint |
X |
X |
X |
X |
X |
B |
X |
X |
X |
X |
X |
:bboverlaps |
|
X |
X |
X |
X |
X |
:bboverlaps |
|
X |
X |
X |
X |
X |
:bboverlaps |
|
X |
X |
X |
X |
X |
:bboverlaps |
|
dwithin |
X |
X |
X |
B |
||
equals |
X |
X |
X |
X |
X |
C |
exact <same_as> |
X |
X |
X |
X |
X |
B |
intersects |
X |
X |
X |
X |
X |
B |
isempty |
X |
|||||
isvalid |
X |
X |
X |
X |
||
overlaps |
X |
X |
X |
X |
X |
B |
relate |
X |
X |
X |
X |
C |
|
same_as |
X |
X |
X |
X |
X |
B |
:toca` |
X |
X |
X |
X |
X |
B |
:dentro de` |
X |
X |
X |
X |
X |
B |
:izquierda` |
X |
C |
||||
:derecha` |
X |
C |
||||
:superpone_izquierda` |
X |
B |
||||
:superpone_derecha` |
X |
B |
||||
:superpone_arriba` |
X |
C |
||||
:superpone_abajo` |
X |
C |
||||
:estrictamente_arriba` |
X |
C |
||||
:estrictamente_abajo` |
X |
C |
La siguiente tabla proporciona un resumen de las funciones específicas de geografía disponibles en cada backend espacial.
Función |
PostGIS |
Oracle |
MariaDB |
MySQL |
SpatiaLite |
|---|---|---|---|---|---|
|
X |
X |
X |
X |
X |
|
X |
X |
X |
X |
X |
|
X |
X |
X |
||
|
X |
X |
|||
|
X |
X |
|||
|
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|
|
X |
X (LWGEOM/RTTOPO) |
|||
|
X |
X |
X (≥ 5.1) |
||
|
X |
X |
X |
X |
X |
|
X |
X |
|||
|
X |
X |
X |
X |
X |
|
X |
X |
X |
X |
X |
|
X |
X |
X |
X |
X |
|
X |
X |
|||
|
X |
X |
X |
X |
X |
|
X |
X |
X |
X |
X |
X |
X |
X (LWGEOM/RTTOPO) |
|||
|
X |
||||
|
X |
X |
X |
X |
X |
|
X |
||||
|
X |
X |
X |
X |
|
|
X |
X |
X |
X |
X |
|
X |
X |
|||
X |
X (LWGEOM/RTTOPO) |
||||
X |
|||||
X |
X |
X |
X |
X |
|
X |
X |
X |
X |
X |
|
|
X |
X |
X |
||
|
X |
X |
X |
X |
|
X |
X |
X |
|||
|
X |
X |
|||
|
X |
X |
|||
|
X |
X |
X |
X |
X |
|
X |
X |
X |
||
|
X |
X |
|||
|
X |
X |
X |
X |
X |
La siguiente tabla proporciona una resumen de las funciones de agregado específicas de GIS disponibles en cada backend espacial. Ten en cuenta que MariaDB no admite ninguna de estas agregaciones, y por lo tanto se excluye de la tabla.
Función de agregado |
PostGIS |
Oracle |
MySQL |
SpatiaLite |
|---|---|---|---|---|
|
X |
X (≥ 8.0.24) |
X |
|
|
X |
X |
X |
|
|
X |
|||
X |
X |
|||
|
X |
X |
X |
Notas al pie
may 31, 2026