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\n\nclass Zipcode(models.Model):\n code = models.CharField(max_length=5)\n poly = models.PolygonField()\n\n\nclass Elevation(models.Model):\n name = models.CharField(max_length=100)\n rast = models.RasterField()\n空間フィールドは一連のジオメトリフィールド型と1つのラスターフィールド型で構成されます。各ジオメトリフィールド型は OpenGIS Simple Features 仕様 [1] に対応しています。ラスターデータに対するこのような標準は存在しません。
\nGeometryFieldLink to this heading#ジオメトリフィールドの基本クラス。
\nPointFieldLink to this heading#Point を格納します。
LineStringFieldLink to this heading#LineString を格納します。
PolygonFieldLink to this heading#Polygon を格納します。
MultiPointFieldLink to this heading#MultiPoint を格納します。
MultiLineStringFieldLink to this heading#MultiLineString を格納します。
MultiPolygonFieldLink to this heading#MultiPolygon を格納します。
GeometryCollectionFieldLink to this heading#GeometryCollection を格納します。
RasterFieldLink to this heading#GDALRaster を格納します。
RasterField は現在、PostGIS バックエンドのみで実装されています。
Django のモデルフィールドで利用できる通常の フィールドオプション に加えて、空間フィールドには以下の追加オプションがあります。すべてオプションです。
\nsridLink to this heading#ジオメトリフィールドの SRID [2] (Spatial Reference System Identity) を指定した値に設定します。デフォルトは 4326 (別名 WGS84 、単位は緯度経度)。
\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 in\nthe 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) are\nnot.
\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 a\nflat surface is a straight line, the shortest path between two points on a\ncurved surface (such as the earth) is an arc of a great circle.\n[4]
\nThus, additional computation is required to obtain distances in planar units\n(e.g., kilometers and miles). Using a geographic coordinate system may\nintroduce complications for the developer later on. For example, SpatiaLite\ndoes not have the capability to perform distance calculations between\ngeometries using geographic coordinate systems, e.g. constructing a query to\nfind all points within 5 miles of a county boundary stored as WGS84. [5]
\nPortions of the earth's surface may projected onto a two-dimensional, or\nCartesian, plane. Projected coordinate systems are especially convenient for\nregion-specific applications, e.g., if you know that your database will only\ncover 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\n追加のリソース:
\nspatialreference.org: Djangoを使用した空間参照システムのデータベース。
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 to this heading#Defaults to True. Creates a spatial index for the given geometry\nfield.
ジオメトリフィールドには追加オプションがあります。以下のすべてのオプションは任意です。
\ndimLink to this heading#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 to this heading#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.
max_geom_collectionsLink to this heading#This option is forwarded to the form field generated for this model\nfield, bounding how many geometry collections may be contained in submitted\nWKB/WKT inputs before raising ValueError. Since spatial field\nassignments are lazy, it is also checked when values are accessed, e.g. when\nsaving an instance, but not when read from a database. It defaults to 198.
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).
地理計算にはより多くの数学が関わるため、地理型に対して使用できる PostGIS 空間ルックアップのサブセットが限られています。具体的には、距離ルックアップ に加えて、ジオグラフィカラム用に利用可能な追加の 空間ルックアップ は以下のみです。
\n入力としてジオグラフィ型をサポートしていない空間ルックアップや集計を使用する必要がある場合、 Cast データベース関数を使用して、クエリの中でジオグラフィカラムをジオメトリ型に変換できます:
from django.contrib.gis.db.models import PointField\nfrom django.db.models.functions import Cast\n\nZipcode.objects.annotate(geom=Cast("geography_field", PointField())).filter(\n geom__within=poly\n)\nFor more information, the PostGIS documentation contains a helpful section on\ndetermining when to use geography data type over geometry data type.
\n脚注
\n\n