db-api.txt 20 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430
  1. ======================
  2. GeoDjango Database API
  3. ======================
  4. .. _spatial-backends:
  5. Spatial Backends
  6. ================
  7. .. module:: django.contrib.gis.db.backends
  8. :synopsis: GeoDjango's spatial database backends.
  9. GeoDjango currently provides the following spatial database backends:
  10. * ``django.contrib.gis.db.backends.postgis``
  11. * ``django.contrib.gis.db.backends.mysql``
  12. * ``django.contrib.gis.db.backends.oracle``
  13. * ``django.contrib.gis.db.backends.spatialite``
  14. .. module:: django.contrib.gis.db.models
  15. :synopsis: GeoDjango's database API.
  16. .. _mysql-spatial-limitations:
  17. MySQL Spatial Limitations
  18. -------------------------
  19. Before MySQL 5.6.1, spatial extensions only support bounding box operations
  20. (what MySQL calls minimum bounding rectangles, or MBR). Specifically, MySQL did
  21. not conform to the OGC standard. Django supports spatial functions operating on
  22. real geometries available in modern MySQL versions. However, the spatial
  23. functions are not as rich as other backends like PostGIS.
  24. .. versionchanged:: 3.0
  25. Support for spatial functions operating on real geometries was added.
  26. .. warning::
  27. True spatial indexes (R-trees) are only supported with
  28. MyISAM tables on MySQL. [#fnmysqlidx]_ In other words, when using
  29. MySQL spatial extensions you have to choose between fast spatial
  30. lookups and the integrity of your data -- MyISAM tables do
  31. not support transactions or foreign key constraints.
  32. Raster Support
  33. --------------
  34. ``RasterField`` is currently only implemented for the PostGIS backend. Spatial
  35. lookups are available for raster fields, but spatial database functions and
  36. aggregates aren't implemented for raster fields.
  37. Creating and Saving Models with Geometry Fields
  38. ===============================================
  39. Here is an example of how to create a geometry object (assuming the ``Zipcode``
  40. model)::
  41. >>> from zipcode.models import Zipcode
  42. >>> z = Zipcode(code=77096, poly='POLYGON(( 10 10, 10 20, 20 20, 20 15, 10 10))')
  43. >>> z.save()
  44. :class:`~django.contrib.gis.geos.GEOSGeometry` objects may also be used to save geometric models::
  45. >>> from django.contrib.gis.geos import GEOSGeometry
  46. >>> poly = GEOSGeometry('POLYGON(( 10 10, 10 20, 20 20, 20 15, 10 10))')
  47. >>> z = Zipcode(code=77096, poly=poly)
  48. >>> z.save()
  49. Moreover, if the ``GEOSGeometry`` is in a different coordinate system (has a
  50. different SRID value) than that of the field, then it will be implicitly
  51. transformed into the SRID of the model's field, using the spatial database's
  52. transform procedure::
  53. >>> 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'
  54. >>> z = Zipcode(code=78212, poly=poly_3084)
  55. >>> z.save()
  56. >>> from django.db import connection
  57. >>> print(connection.queries[-1]['sql']) # printing the last SQL statement executed (requires DEBUG=True)
  58. INSERT INTO "geoapp_zipcode" ("code", "poly") VALUES (78212, ST_Transform(ST_GeomFromWKB('\\001 ... ', 3084), 4326))
  59. Thus, geometry parameters may be passed in using the ``GEOSGeometry`` object, WKT
  60. (Well Known Text [#fnwkt]_), HEXEWKB (PostGIS specific -- a WKB geometry in
  61. hexadecimal [#fnewkb]_), and GeoJSON [#fngeojson]_. Essentially, if the input is
  62. not a ``GEOSGeometry`` object, the geometry field will attempt to create a
  63. ``GEOSGeometry`` instance from the input.
  64. For more information creating :class:`~django.contrib.gis.geos.GEOSGeometry`
  65. objects, refer to the :ref:`GEOS tutorial <geos-tutorial>`.
  66. .. _creating-and-saving-raster-models:
  67. Creating and Saving Models with Raster Fields
  68. =============================================
  69. When creating raster models, the raster field will implicitly convert the input
  70. into a :class:`~django.contrib.gis.gdal.GDALRaster` using lazy-evaluation.
  71. The raster field will therefore accept any input that is accepted by the
  72. :class:`~django.contrib.gis.gdal.GDALRaster` constructor.
  73. Here is an example of how to create a raster object from a raster file
  74. ``volcano.tif`` (assuming the ``Elevation`` model)::
  75. >>> from elevation.models import Elevation
  76. >>> dem = Elevation(name='Volcano', rast='/path/to/raster/volcano.tif')
  77. >>> dem.save()
  78. :class:`~django.contrib.gis.gdal.GDALRaster` objects may also be used to save
  79. raster models::
  80. >>> from django.contrib.gis.gdal import GDALRaster
  81. >>> rast = GDALRaster({'width': 10, 'height': 10, 'name': 'Canyon', 'srid': 4326,
  82. ... 'scale': [0.1, -0.1], 'bands': [{"data": range(100)}]})
  83. >>> dem = Elevation(name='Canyon', rast=rast)
  84. >>> dem.save()
  85. Note that this equivalent to::
  86. >>> dem = Elevation.objects.create(
  87. ... name='Canyon',
  88. ... rast={'width': 10, 'height': 10, 'name': 'Canyon', 'srid': 4326,
  89. ... 'scale': [0.1, -0.1], 'bands': [{"data": range(100)}]},
  90. ... )
  91. .. _spatial-lookups-intro:
  92. Spatial Lookups
  93. ===============
  94. GeoDjango's lookup types may be used with any manager method like
  95. ``filter()``, ``exclude()``, etc. However, the lookup types unique to
  96. GeoDjango are only available on spatial fields.
  97. Filters on 'normal' fields (e.g. :class:`~django.db.models.CharField`)
  98. may be chained with those on geographic fields. Geographic lookups accept
  99. geometry and raster input on both sides and input types can be mixed freely.
  100. The general structure of geographic lookups is described below. A complete
  101. reference can be found in the :ref:`spatial lookup reference<spatial-lookups>`.
  102. Geometry Lookups
  103. ----------------
  104. Geographic queries with geometries take the following general form (assuming
  105. the ``Zipcode`` model used in the :doc:`model-api`)::
  106. >>> qs = Zipcode.objects.filter(<field>__<lookup_type>=<parameter>)
  107. >>> qs = Zipcode.objects.exclude(...)
  108. For example::
  109. >>> qs = Zipcode.objects.filter(poly__contains=pnt)
  110. >>> qs = Elevation.objects.filter(poly__contains=rst)
  111. In this case, ``poly`` is the geographic field, :lookup:`contains <gis-contains>`
  112. is the spatial lookup type, ``pnt`` is the parameter (which may be a
  113. :class:`~django.contrib.gis.geos.GEOSGeometry` object or a string of
  114. GeoJSON , WKT, or HEXEWKB), and ``rst`` is a
  115. :class:`~django.contrib.gis.gdal.GDALRaster` object.
  116. .. _spatial-lookup-raster:
  117. Raster Lookups
  118. --------------
  119. The raster lookup syntax is similar to the syntax for geometries. The only
  120. difference is that a band index can be specified as additional input. If no band
  121. index is specified, the first band is used by default (index ``0``). In that
  122. case the syntax is identical to the syntax for geometry lookups.
  123. To specify the band index, an additional parameter can be specified on both
  124. sides of the lookup. On the left hand side, the double underscore syntax is
  125. used to pass a band index. On the right hand side, a tuple of the raster and
  126. band index can be specified.
  127. This results in the following general form for lookups involving rasters
  128. (assuming the ``Elevation`` model used in the :doc:`model-api`)::
  129. >>> qs = Elevation.objects.filter(<field>__<lookup_type>=<parameter>)
  130. >>> qs = Elevation.objects.filter(<field>__<band_index>__<lookup_type>=<parameter>)
  131. >>> qs = Elevation.objects.filter(<field>__<lookup_type>=(<raster_input, <band_index>)
  132. For example::
  133. >>> qs = Elevation.objects.filter(rast__contains=geom)
  134. >>> qs = Elevation.objects.filter(rast__contains=rst)
  135. >>> qs = Elevation.objects.filter(rast__1__contains=geom)
  136. >>> qs = Elevation.objects.filter(rast__contains=(rst, 1))
  137. >>> qs = Elevation.objects.filter(rast__1__contains=(rst, 1))
  138. On the left hand side of the example, ``rast`` is the geographic raster field
  139. and :lookup:`contains <gis-contains>` is the spatial lookup type. On the right
  140. hand side, ``geom`` is a geometry input and ``rst`` is a
  141. :class:`~django.contrib.gis.gdal.GDALRaster` object. The band index defaults to
  142. ``0`` in the first two queries and is set to ``1`` on the others.
  143. While all spatial lookups can be used with raster objects on both sides, not all
  144. underlying operators natively accept raster input. For cases where the operator
  145. expects geometry input, the raster is automatically converted to a geometry.
  146. It's important to keep this in mind when interpreting the lookup results.
  147. The type of raster support is listed for all lookups in the :ref:`compatibility
  148. table <spatial-lookup-compatibility>`. Lookups involving rasters are currently
  149. only available for the PostGIS backend.
  150. .. _distance-queries:
  151. Distance Queries
  152. ================
  153. Introduction
  154. ------------
  155. Distance calculations with spatial data is tricky because, unfortunately,
  156. the Earth is not flat. Some distance queries with fields in a geographic
  157. coordinate system may have to be expressed differently because of
  158. limitations in PostGIS. Please see the :ref:`selecting-an-srid` section
  159. in the :doc:`model-api` documentation for more details.
  160. .. _distance-lookups-intro:
  161. Distance Lookups
  162. ----------------
  163. *Availability*: PostGIS, Oracle, SpatiaLite, PGRaster (Native)
  164. The following distance lookups are available:
  165. * :lookup:`distance_lt`
  166. * :lookup:`distance_lte`
  167. * :lookup:`distance_gt`
  168. * :lookup:`distance_gte`
  169. * :lookup:`dwithin`
  170. .. note::
  171. For *measuring*, rather than querying on distances, use the
  172. :class:`~django.contrib.gis.db.models.functions.Distance` function.
  173. Distance lookups take a tuple parameter comprising:
  174. #. A geometry or raster to base calculations from; and
  175. #. A number or :class:`~django.contrib.gis.measure.Distance` object containing the distance.
  176. If a :class:`~django.contrib.gis.measure.Distance` object is used,
  177. it may be expressed in any units (the SQL generated will use units
  178. converted to those of the field); otherwise, numeric parameters are assumed
  179. to be in the units of the field.
  180. .. note::
  181. In PostGIS, ``ST_Distance_Sphere`` does *not* limit the geometry types
  182. geographic distance queries are performed with. [#fndistsphere15]_ However,
  183. these queries may take a long time, as great-circle distances must be
  184. calculated on the fly for *every* row in the query. This is because the
  185. spatial index on traditional geometry fields cannot be used.
  186. For much better performance on WGS84 distance queries, consider using
  187. :ref:`geography columns <geography-type>` in your database instead because
  188. they are able to use their spatial index in distance queries.
  189. You can tell GeoDjango to use a geography column by setting ``geography=True``
  190. in your field definition.
  191. For example, let's say we have a ``SouthTexasCity`` model (from the
  192. :source:`GeoDjango distance tests <tests/gis_tests/distapp/models.py>` ) on a
  193. *projected* coordinate system valid for cities in southern Texas::
  194. from django.contrib.gis.db import models
  195. class SouthTexasCity(models.Model):
  196. name = models.CharField(max_length=30)
  197. # A projected coordinate system (only valid for South Texas!)
  198. # is used, units are in meters.
  199. point = models.PointField(srid=32140)
  200. Then distance queries may be performed as follows::
  201. >>> from django.contrib.gis.geos import GEOSGeometry
  202. >>> from django.contrib.gis.measure import D # ``D`` is a shortcut for ``Distance``
  203. >>> from geoapp.models import SouthTexasCity
  204. # Distances will be calculated from this point, which does not have to be projected.
  205. >>> pnt = GEOSGeometry('POINT(-96.876369 29.905320)', srid=4326)
  206. # If numeric parameter, units of field (meters in this case) are assumed.
  207. >>> qs = SouthTexasCity.objects.filter(point__distance_lte=(pnt, 7000))
  208. # Find all Cities within 7 km, > 20 miles away, and > 100 chains away (an obscure unit)
  209. >>> qs = SouthTexasCity.objects.filter(point__distance_lte=(pnt, D(km=7)))
  210. >>> qs = SouthTexasCity.objects.filter(point__distance_gte=(pnt, D(mi=20)))
  211. >>> qs = SouthTexasCity.objects.filter(point__distance_gte=(pnt, D(chain=100)))
  212. Raster queries work the same way by simply replacing the geometry field
  213. ``point`` with a raster field, or the ``pnt`` object with a raster object, or
  214. both. To specify the band index of a raster input on the right hand side, a
  215. 3-tuple can be passed to the lookup as follows::
  216. >>> qs = SouthTexasCity.objects.filter(point__distance_gte=(rst, 2, D(km=7)))
  217. Where the band with index 2 (the third band) of the raster ``rst`` would be
  218. used for the lookup.
  219. .. _compatibility-table:
  220. Compatibility Tables
  221. ====================
  222. .. _spatial-lookup-compatibility:
  223. Spatial Lookups
  224. ---------------
  225. The following table provides a summary of what spatial lookups are available
  226. for each spatial database backend. The PostGIS Raster (PGRaster) lookups are
  227. divided into the three categories described in the :ref:`raster lookup details
  228. <spatial-lookup-raster>`: native support ``N``, bilateral native support ``B``,
  229. and geometry conversion support ``C``.
  230. ================================= ========= ======== ============ ========== ========
  231. Lookup Type PostGIS Oracle MySQL [#]_ SpatiaLite PGRaster
  232. ================================= ========= ======== ============ ========== ========
  233. :lookup:`bbcontains` X X X N
  234. :lookup:`bboverlaps` X X X N
  235. :lookup:`contained` X X X N
  236. :lookup:`contains <gis-contains>` X X X X B
  237. :lookup:`contains_properly` X B
  238. :lookup:`coveredby` X X X B
  239. :lookup:`covers` X X X B
  240. :lookup:`crosses` X X C
  241. :lookup:`disjoint` X X X X B
  242. :lookup:`distance_gt` X X X N
  243. :lookup:`distance_gte` X X X N
  244. :lookup:`distance_lt` X X X N
  245. :lookup:`distance_lte` X X X N
  246. :lookup:`dwithin` X X X B
  247. :lookup:`equals` X X X X C
  248. :lookup:`exact` X X X X B
  249. :lookup:`intersects` X X X X B
  250. :lookup:`isvalid` X X X (≥ 5.7.5) X (LWGEOM)
  251. :lookup:`overlaps` X X X X B
  252. :lookup:`relate` X X X C
  253. :lookup:`same_as` X X X X B
  254. :lookup:`touches` X X X X B
  255. :lookup:`within` X X X X B
  256. :lookup:`left` X C
  257. :lookup:`right` X C
  258. :lookup:`overlaps_left` X B
  259. :lookup:`overlaps_right` X B
  260. :lookup:`overlaps_above` X C
  261. :lookup:`overlaps_below` X C
  262. :lookup:`strictly_above` X C
  263. :lookup:`strictly_below` X C
  264. ================================= ========= ======== ============ ========== ========
  265. .. _database-functions-compatibility:
  266. Database functions
  267. ------------------
  268. .. module:: django.contrib.gis.db.models.functions
  269. :synopsis: GeoDjango's database functions.
  270. The following table provides a summary of what geography-specific database
  271. functions are available on each spatial backend.
  272. ==================================== ======= ============== =========== ==========
  273. Function PostGIS Oracle MySQL SpatiaLite
  274. ==================================== ======= ============== =========== ==========
  275. :class:`Area` X X X X
  276. :class:`AsGeoJSON` X X (≥ 5.7.5) X
  277. :class:`AsGML` X X X
  278. :class:`AsKML` X X
  279. :class:`AsSVG` X X
  280. :class:`Azimuth` X X (LWGEOM)
  281. :class:`BoundingCircle` X X
  282. :class:`Centroid` X X X X
  283. :class:`Difference` X X X X
  284. :class:`Distance` X X X X
  285. :class:`Envelope` X X X X
  286. :class:`ForcePolygonCW` X X
  287. :class:`GeoHash` X X (≥ 5.7.5) X (LWGEOM)
  288. :class:`Intersection` X X X X
  289. :class:`IsValid` X X X (≥ 5.7.5) X (LWGEOM)
  290. :class:`Length` X X X X
  291. :class:`LineLocatePoint` X X
  292. :class:`MakeValid` X X (LWGEOM)
  293. :class:`MemSize` X
  294. :class:`NumGeometries` X X X X
  295. :class:`NumPoints` X X X X
  296. :class:`Perimeter` X X X
  297. :class:`PointOnSurface` X X X
  298. :class:`Reverse` X X X
  299. :class:`Scale` X X
  300. :class:`SnapToGrid` X X
  301. :class:`SymDifference` X X X X
  302. :class:`Transform` X X X
  303. :class:`Translate` X X
  304. :class:`Union` X X X X
  305. ==================================== ======= ============== =========== ==========
  306. Aggregate Functions
  307. -------------------
  308. The following table provides a summary of what GIS-specific aggregate functions
  309. are available on each spatial backend. Please note that MySQL does not
  310. support any of these aggregates, and is thus excluded from the table.
  311. .. currentmodule:: django.contrib.gis.db.models
  312. ======================= ======= ====== ==========
  313. Aggregate PostGIS Oracle SpatiaLite
  314. ======================= ======= ====== ==========
  315. :class:`Collect` X X
  316. :class:`Extent` X X X
  317. :class:`Extent3D` X
  318. :class:`MakeLine` X X
  319. :class:`Union` X X X
  320. ======================= ======= ====== ==========
  321. .. rubric:: Footnotes
  322. .. [#fnwkt] *See* Open Geospatial Consortium, Inc., `OpenGIS Simple Feature Specification For SQL <http://www.opengis.org/docs/99-049.pdf>`_, Document 99-049 (May 5, 1999), at Ch. 3.2.5, p. 3-11 (SQL Textual Representation of Geometry).
  323. .. [#fnewkb] *See* `PostGIS EWKB, EWKT and Canonical Forms <https://postgis.net/docs/using_postgis_dbmanagement.html#EWKB_EWKT>`_, PostGIS documentation at Ch. 4.1.2.
  324. .. [#fngeojson] *See* Howard Butler, Martin Daly, Allan Doyle, Tim Schaub, & Christopher Schmidt, `The GeoJSON Format Specification <http://geojson.org/geojson-spec.html>`_, Revision 1.0 (June 16, 2008).
  325. .. [#fndistsphere15] *See* `PostGIS documentation <https://postgis.net/docs/ST_DistanceSphere.html>`_ on ``ST_DistanceSphere``.
  326. .. [#fnmysqlidx] *See* `Creating Spatial Indexes <https://dev.mysql.com/doc/refman/en/creating-spatial-indexes.html>`_
  327. in the MySQL Reference Manual:
  328. For MyISAM tables, ``SPATIAL INDEX`` creates an R-tree index. For storage
  329. engines that support nonspatial indexing of spatial columns, the engine
  330. creates a B-tree index. A B-tree index on spatial values will be useful
  331. for exact-value lookups, but not for range scans.
  332. .. [#] Refer :ref:`mysql-spatial-limitations` section for more details.