GeoDjango tillhandahåller för närvarande följande rumsliga databasbackends:
\ndjango.contrib.gis.db.backends.postgis
django.contrib.gis.db.backends.mysql
django.contrib.gis.db.backends.oracle
django.contrib.gis.db.backends.spatialite
Django stöder rumsliga funktioner som arbetar med verkliga geometrier som finns tillgängliga i moderna MySQL-versioner. De rumsliga funktionerna är dock inte lika rika som andra backends som PostGIS.
\nRasterField är för närvarande endast implementerat för PostGIS-backend. Rumsliga uppslagningar är tillgängliga för rasterfält, men rumsliga databasfunktioner och aggregat är inte implementerade för rasterfält.
Här följer ett exempel på hur man skapar ett geometriobjekt (med utgångspunkt från modellen Zipcode):
>>> from zipcode.models import Zipcode\n>>> z = Zipcode(code=77096, poly="POLYGON(( 10 10, 10 20, 20 20, 20 15, 10 10))")\n>>> z.save()\nGEOSGeometry-objekt kan också användas för att spara geometriska modeller:
>>> from django.contrib.gis.geos import GEOSGeometry\n>>> poly = GEOSGeometry("POLYGON(( 10 10, 10 20, 20 20, 20 15, 10 10))")\n>>> z = Zipcode(code=77096, poly=poly)\n>>> z.save()\nOm GEOSGeometry dessutom befinner sig i ett annat koordinatsystem (har ett annat SRID-värde) än fältets, kommer det implicit att transformeras till SRID för modellens fält med hjälp av den rumsliga databasens transform-procedur:
>>> poly_3084 = GEOSGeometry(\n... "POLYGON(( 10 10, 10 20, 20 20, 20 15, 10 10))", srid=3084\n... ) # SRID 3084 is 'NAD83(HARN) / Texas Centric Lambert Conformal'\n>>> z = Zipcode(code=78212, poly=poly_3084)\n>>> z.save()\n>>> from django.db import connection\n>>> print(\n... connection.queries[-1]["sql"]\n... ) # printing the last SQL statement executed (requires DEBUG=True)\nINSERT INTO "geoapp_zipcode" ("code", "poly") VALUES (78212, ST_Transform(ST_GeomFromWKB('\\\\001 ... ', 3084), 4326))\nGeometriparametrar kan således skickas in med hjälp av objektet GEOSGeometry, WKT (Well Known Text [1]), HEXEWKB (PostGIS-specifikt - en WKB-geometri i hexadecimal [2]) och GeoJSON (se RFC 7946). Om indata inte är ett GEOSGeometry-objekt kommer geometrifältet att försöka skapa en GEOSGeometry-instans från indata.
För mer information om att skapa GEOSGeometry-objekt, se GEOS tutorial.
När rastermodeller skapas kommer rasterfältet implicit att konvertera indata till en GDALRaster med hjälp av lazy-evaluation. Rasterfältet kommer därför att acceptera all indata som accepteras av GDALRaster-konstruktören.
Här följer ett exempel på hur man skapar ett rasterobjekt från en rasterfil volcano.tif (med modellen Elevation):
>>> from elevation.models import Elevation\n>>> dem = Elevation(name="Volcano", rast="/path/to/raster/volcano.tif")\n>>> dem.save()\nGDALRaster-objekt kan också användas för att spara rastermodeller:
>>> from django.contrib.gis.gdal import GDALRaster\n>>> rast = GDALRaster(\n... {\n... "width": 10,\n... "height": 10,\n... "name": "Canyon",\n... "srid": 4326,\n... "scale": [0.1, -0.1],\n... "bands": [{"data": range(100)}],\n... }\n... )\n>>> dem = Elevation(name="Canyon", rast=rast)\n>>> dem.save()\nObservera att detta är likvärdigt med:
\n>>> dem = Elevation.objects.create(\n... name="Canyon",\n... rast={\n... "width": 10,\n... "height": 10,\n... "name": "Canyon",\n... "srid": 4326,\n... "scale": [0.1, -0.1],\n... "bands": [{"data": range(100)}],\n... },\n... )\nGeoDjangos lookup-typer kan användas med alla managermetoder som filter(), exclude(), etc. De uppslagstyper som är unika för GeoDjango är dock endast tillgängliga på rumsliga fält.
Filters on ’normal’ fields (e.g. CharField)\nmay be chained with those on geographic fields. Geographic lookups accept\ngeometry and raster input on both sides, and input types can be mixed freely in\nmost cases. However, unlike assignments to model fields, with lookups,\ntypes such as str, pathlib.Path, and dict must be wrapped by\nGDALRaster to signify that the potential for\nfile writing or network fetching is acceptable. For the rationale, see\nraster security considerations.
Den allmänna strukturen för geografiska uppslagsord beskrivs nedan. En fullständig referens finns i spatial lookup reference.
\n\nGeografiska frågor med geometrier har följande allmänna form (med antagande av modellen Zipcode som används i GeoDjango modell-API):
>>> qs = Zipcode.objects.filter(<field>__<lookup_type>=<parameter>)\n>>> qs = Zipcode.objects.exclude(...)\nTill exempel:
\n>>> qs = Zipcode.objects.filter(poly__contains=pnt)\n>>> qs = Elevation.objects.filter(poly__contains=rst)\nI det här fallet är poly det geografiska fältet, contains <gis-contains>` är den rumsliga lookup-typen, pnt är parametern (som kan vara ett GEOSGeometry-objekt eller en sträng av GeoJSON , WKT eller HEXEWKB) och rst är ett GDALRaster-objekt.
Syntaxen för rasteruppslagning liknar syntaxen för geometrier. Den enda skillnaden är att ett bandindex kan anges som ytterligare indata. Om inget bandindex anges används det första bandet som standard (index 0). I så fall är syntaxen identisk med syntaxen för geometriuppslagningar.
För att ange bandindexet kan en ytterligare parameter anges på båda sidor av uppslagningen. På vänster sida används syntaxen med dubbla understreck för att skicka ett bandindex. På den högra sidan kan en tupel av raster- och bandindex specificeras.
\nDetta resulterar i följande allmänna form för uppslagningar som involverar raster (förutsatt att modellen Elevation används i GeoDjango modell-API):
>>> qs = Elevation.objects.filter(<field>__<lookup_type>=<parameter>)\n>>> qs = Elevation.objects.filter(<field>__<band_index>__<lookup_type>=<parameter>)\n>>> qs = Elevation.objects.filter(<field>__<lookup_type>=(<raster_input, <band_index>)\nTill exempel:
\n>>> qs = Elevation.objects.filter(rast__contains=geom)\n>>> qs = Elevation.objects.filter(rast__contains=rst)\n>>> qs = Elevation.objects.filter(rast__1__contains=geom)\n>>> qs = Elevation.objects.filter(rast__contains=(rst, 1))\n>>> qs = Elevation.objects.filter(rast__1__contains=(rst, 1))\nTill vänster i exemplet är rast det geografiska rasterfältet och contains är den rumsliga lookup-typen. På höger sida är geom en geometriingång och rst är ett GDALRaster-objekt. Bandindexet är som standard 0 i de två första frågorna och är inställt på 1 i de andra.
Alla spatiala uppslag kan användas med rasterobjekt på båda sidor, men det är inte alla underliggande operatörer som accepterar rasterinmatning. I de fall där operatören förväntar sig geometriinmatning konverteras rastret automatiskt till en geometri. Det är viktigt att ha detta i åtanke när man tolkar uppslagsresultaten.
\nTypen av rasterstöd listas för alla uppslagningar i kompatibilitetstabell. Uppslagningar som involverar raster är för närvarande endast tillgängliga för PostGIS-backend.
\nAvståndsberäkningar med rumsliga data är knepiga eftersom jorden tyvärr inte är platt. Vissa avståndsfrågor med fält i ett geografiskt koordinatsystem kan behöva uttryckas annorlunda på grund av begränsningar i PostGIS. Se avsnittet Välja en SRID i dokumentationen GeoDjango modell-API för mer information.
\nTillgänglighet: PostGIS, MariaDB, MySQL, Oracle, SpatiaLite, PGRaster (inbyggd)
\nFöljande avståndsuppslagningar är tillgängliga:
\navstånd_lt
avstånd_lte
avstånd_gt
avstånd_gte
dwithin (utom MariaDB och MySQL)
Distansuppslagningar tar en tuple-parameter som består av:
\nEn geometri eller ett raster att basera beräkningarna på; och
Ett tal eller Distance-objekt som innehåller avståndet.
Om ett Distance-objekt används kan det uttryckas i valfri enhet (den SQL som genereras kommer att använda enheter som konverterats till fältets enheter); annars antas numeriska parametrar vara i fältets enheter.
Låt oss till exempel säga att vi har en SouthTexasCity-modell (från GeoDjango distance tests ) på ett projicerat koordinatsystem som gäller för städer i södra Texas:
from django.contrib.gis.db import models\n\n\nclass SouthTexasCity(models.Model):\n name = models.CharField(max_length=30)\n # A projected coordinate system (only valid for South Texas!)\n # is used, units are in meters.\n point = models.PointField(srid=32140)\nDå kan avståndsfrågor utföras på följande sätt:
\n>>> from django.contrib.gis.geos import GEOSGeometry\n>>> from django.contrib.gis.measure import D # ``D`` is a shortcut for ``Distance``\n>>> from geoapp.models import SouthTexasCity\n# Distances will be calculated from this point, which does not have to be projected.\n>>> pnt = GEOSGeometry("POINT(-96.876369 29.905320)", srid=4326)\n# If numeric parameter, units of field (meters in this case) are assumed.\n>>> qs = SouthTexasCity.objects.filter(point__distance_lte=(pnt, 7000))\n# Find all Cities within 7 km, > 20 miles away, and > 100 chains away (an obscure unit)\n>>> qs = SouthTexasCity.objects.filter(point__distance_lte=(pnt, D(km=7)))\n>>> qs = SouthTexasCity.objects.filter(point__distance_gte=(pnt, D(mi=20)))\n>>> qs = SouthTexasCity.objects.filter(point__distance_gte=(pnt, D(chain=100)))\nRasterfrågor fungerar på samma sätt genom att geometrifältet point ersätts med ett rasterfält, eller pnt-objektet med ett rasterobjekt, eller båda. För att specificera bandindex för en rasterinmatning på höger sida kan en 3-tupel skickas till lookupen enligt följande:
>>> qs = SouthTexasCity.objects.filter(point__distance_gte=(rst, 2, D(km=7)))\nDär bandet med index 2 (det tredje bandet) i rastret rst skulle användas för uppslagningen.
I följande tabell finns en sammanfattning av vilka rumsliga uppslagningar som är tillgängliga för varje rumslig databasbackend. PostGIS Raster (PGRaster)-uppslagningarna är indelade i de tre kategorier som beskrivs i raster lookup details: inbyggt stöd N, bilateralt inbyggt stöd B och stöd för geometrikonvertering C.
Typ av uppslag | \nPostGIS | \nOracle | \nMariaDB | \nMySQL [4] | \nSpatiaLite | \nPGRaster | \n
|---|---|---|---|---|---|---|
| \nX | \n\n | X | \nX | \nX | \nN | \n
| \n | X | \n\n | X | \nX | \nX | \nN | \n
| \nX | \n\n | X | \nX | \nX | \nN | \n
| \n | X | \nX | \nX | \nX | \nX | \nB | \n
| \nX | \n\n | \n | \n | \n | B | \n
| \nX | \nX | \n\n | X | \nX | \nB | \n
| \nX | \nX | \n\n | X | \nX | \nB | \n
| \nX | \n\n | X | \nX | \nX | \nC | \n
| \n | X | \nX | \nX | \nX | \nX | \nB | \n
| \nX | \nX | \nX | \nX | \nX | \nN | \n
| \nX | \nX | \nX | \nX | \nX | \nN | \n
| \nX | \nX | \nX | \nX | \nX | \nN | \n
| \nX | \nX | \nX | \nX | \nX | \nN | \n
| \n | X | \nX | \n\n | \n | X | \nB | \n
| \nX | \nX | \nX | \nX | \nX | \nC | \n
| \nX | \nX | \nX | \nX | \nX | \nB | \n
| \n | X | \nX | \nX | \nX | \nX | \nB | \n
| \n | X | \n\n | \n | \n | \n | \n |
| \n | X | \nX | \n\n | X | \nX | \n\n |
| \nX | \nX | \nX | \nX | \nX | \nB | \n
| \nX | \nX | \nX | \n\n | X | \nC | \n
| \nX | \nX | \nX | \nX | \nX | \nB | \n
| \n | X | \nX | \nX | \nX | \nX | \nB | \n
| \nX | \nX | \nX | \nX | \nX | \nB | \n
| \nX | \n\n | \n | \n | \n | C | \n
| \nX | \n\n | \n | \n | \n | C | \n
| \n | X | \n\n | \n | \n | \n | B | \n
| \n | X | \n\n | \n | \n | \n | B | \n
| \n | X | \n\n | \n | \n | \n | C | \n
| \n | X | \n\n | \n | \n | \n | C | \n
| \nX | \n\n | \n | \n | \n | C | \n
| \nX | \n\n | \n | \n | \n | C | \n
I följande tabell finns en sammanfattning av vilka geografiskt specifika databasfunktioner som finns tillgängliga i varje rumslig backend.
\nFunktion | \nPostGIS | \nOracle | \nMariaDB | \nMySQL | \nSpatiaLite | \n
|---|---|---|---|---|---|
| \n | X | \nX | \nX | \nX | \nX | \n
| \n | X | \nX | \nX | \nX | \nX | \n
| \n | X | \nX | \n\n | \n | X | \n
| \n | X | \n\n | \n | \n | X | \n
| \n | X | \n\n | \n | \n | X | \n
| \n | X | \nX | \nX | \nX | \nX | \n
| \n | X | \nX | \nX | \nX | \nX | \n
| \n | X | \n\n | \n | \n | X (LWGEOM/RTTOPO) | \n
| \n | X | \nX | \n\n | \n | X (≥ 5.1) | \n
| \n | X | \nX | \nX | \nX | \nX | \n
| \n | X | \n\n | \n | \n | X | \n
| \nX | \nX | \nX | \nX | \nX | \n
| \nX | \nX | \nX | \nX | \nX | \n
| \nX | \nX | \nX | \nX | \nX | \n
| \n | X | \n\n | \n | \n | X | \n
| \nX | \nX | \nX | \nX | \nX | \n
| \n | X | \nX | \nX | \nX | \nX | \n
| \n | X | \n\n | \n | X | \nX (LWGEOM/RTTOPO) | \n
| \n | X | \n\n | \n | \n | \n |
| \nX | \nX | \nX | \nX | \nX | \n
| \n | X | \n\n | \n | \n | \n |
| \n | X | \nX | \n\n | X | \nX | \n
| \nX | \nX | \nX | \nX | \nX | \n
| \n | X | \n\n | \n | \n | X | \n
| \n | X | \n\n | \n | \n | X (LWGEOM/RTTOPO) | \n
| \n | X | \n\n | \n | \n | \n |
| \n | X | \nX | \nX | \nX | \nX | \n
| \n | X | \nX | \nX | \nX | \nX | \n
| \n | X | \nX | \n\n | \n | X | \n
| \n | X | \nX | \nX | \n\n | X | \n
| \n | X | \nX | \n\n | \n | X | \n
| \nX | \n\n | \n | \n | X | \n
| \n | X | \n\n | \n | \n | X | \n
| \n | X | \nX | \nX | \nX | \nX | \n
| \n | X | \nX | \n\n | \n | X | \n
| \n | X | \n\n | \n | \n | X | \n
| \n | X | \nX | \nX | \nX | \nX | \n
I följande tabell finns en sammanfattning av vilka GIS-specifika aggregeringsfunktioner som finns tillgängliga på varje spatial backend. Observera att MariaDB inte stöder några av dessa aggregat och därför inte ingår i tabellen.
\nSammanslagna | \nPostGIS | \nOracle | \nMySQL | \nSpatiaLite | \n
|---|---|---|---|---|
| \n | X | \n\n | X (≥ 8.0.24) | \nX | \n
| \n | X | \nX | \n\n | X | \n
| \n | X | \n\n | \n | \n |
| \n | X | \n\n | \n | X | \n
| \n | X | \nX | \n\n | X | \n
Fotnoter
\n\n