# Django 6.0.7 ドキュメント

# GIS QuerySet API リファレンス

## 空間のルックアップ (Spatial Lookup)

このセクションの空間ルックアップは `GeometryField` と `RasterField` 用です。

For an introduction, see the spatial lookups introduction. For an overview of what lookups are compatible with a particular spatial backend, refer to the spatial lookup compatibility table.

### ラスターのルックアップ

以下のリファレンスにあるすべての例は地理情報フィールドおよび入力に対して提供されていますが、ルックアップはラスタの両側で同じように使用できます。ルックアップがラスター入力をサポートしていない場合、入力は ST_Polygon 関数を使用して必要に応じて自動的にジオメトリに変換されます。 ラスタルックアップの概要 も参照してください。

ルックアップで使用されるデータベース演算子は、以下の 3 つのカテゴリに分類できます:

- ネイティブラスターサポート (`N`): この演算子は、参照先としてラスターをネイティブに受け入れ、ラスター入力をジオメトリ入力と混在させることができます。

- 双方向ラスターサポート `B`: このオペレータは、ルックアップの両側がラスター入力を受け取る場合のみ、ラスターをサポートします。異なるルックアップの場合は、ラスターデータは自動的にジオメトリに変換されます。

- ジオメトリ変換サポート `C` 。ルックアップはネイティブのラスターをサポートしていないため、すべてのラスターデータは自動的にジオメトリに変換されます。

以下の例は、さまざまなタイプのラスターサポートにおけるルックアップに相当する SQL を示しています。同じパターンがすべての空間ルックアップに適用されます。

ケース | ルックアップ | 等価なSQL
--- | --- | ---
N, B | `rast__contains=rst` | `ST_Contains(rast, rst)`
N, B | `rast__1__contains=(rst, 2)` | `ST_Contains(rast, 1, rst, 2)`
B, C | `rast__contains=geom` | `ST_Contains(ST_Polygon(rast), geom)`
B, C | `rast__1__contains=geom` | `ST_Contains(ST_Polygon(rast, 1), geom)`
B, C | `poly__contains=rst` | `ST_Contains(poly, ST_Polygon(rst))`
B, C | `poly__contains=(rst, 1)` | `ST_Contains(poly, ST_Polygon(rst, 1))`
C | `rast__crosses=rst` | `ST_Crosses(ST_Polygon(rast), ST_Polygon(rst))`
C | `rast__1__crosses=(rst, 2)` | `ST_Crosses(ST_Polygon(rast, 1), ST_Polygon(rst, 2))`
C | `rast__crosses=geom` | `ST_Crosses(ST_Polygon(rast), geom)`
C | `poly__crosses=rst` | `ST_Crosses(poly, ST_Polygon(rst))`

ラスターを使った空間ルックアップは、PostGISバックエンド (この節ではPGRasterと表記) のみでサポートされています。

### `bbcontains`

利用可能なDB: PostGIS, MariaDB, MySQL, SpatiaLite, PGRaster (Native)

ジオメトリまたはラスタフィールドのバウンディングボックスが、ルックアップジオメトリのバウンディングボックスを完全に含むかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__bbcontains=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `poly ~ geom`
MariaDB | `MBRContains(poly, geom)`
MySQL | `MBRContains(poly, geom)`
SpatiaLite | `MbrContains(poly, geom)`

### `bboverlaps`

利用可能なDB: PostGIS, MariaDB, MySQL, SpatiaLite, PGRaster (Native)

ジオメトリフィールドのバウンディングボックスが、ルックアップジオメトリのバウンディングボックスと重なるかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__bboverlaps=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `poly && geom`
MariaDB | `MBROverlaps(poly, geom)`
MySQL | `MBROverlaps(poly, geom)`
SpatiaLite | `MbrOverlaps(poly, geom)`

### `contained`

利用可能なDB: PostGIS, MariaDB, MySQL, SpatiaLite, PGRaster (Native)

ジオメトリフィールドのバウンディングボックスがルックアップジオメトリのバウンディングボックスに完全に含まれるかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__contained=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `poly @ geom`
MariaDB | `MBRWithin(poly, geom)`
MySQL | `MBRWithin(poly, geom)`
SpatiaLite | `MbrWithin(poly, geom)`

### `contains`

利用可能なDB: PostGIS, Oracle, MariaDB, MySQL, SpatiaLite, PGRaster (Bilateral)

ジオメトリフィールドにルックアップ ジオメトリが含まれているかどうかを調べます。

実装例:

    Zipcode.objects.filter(poly__contains=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Contains(poly, geom)`
Oracle | `SDO_CONTAINS(poly, geom)`
MariaDB | `ST_Contains(poly, geom)`
MySQL | `ST_Contains(poly, geom)`
SpatiaLite | `Contains(poly, geom)`

### `contains_properly`

利用可能なDB: PostGIS, PGRaster (Bilateral)

ルックアップ ジオメトリがジオメトリ フィールドの内部と交差し、境界 (または外部) と交差しない場合に true を返します。

実装例:

    Zipcode.objects.filter(poly__contains_properly=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_ContainsProperly(poly, geom)`

### `coveredby`

利用可能なDB: PostGIS, Oracle, MariaDB, MySQL, PGRaster (Bilateral), SpatiaLite

ジオメトリフィールドのどのポイントもルックアップジオメトリの外側にないかどうかをテストします。 [3]

実装例:

    Zipcode.objects.filter(poly__coveredby=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_CoveredBy(poly, geom)`
Oracle | `SDO_COVEREDBY(poly, geom)`
MariaDB | `MBRCoveredBy(poly, geom)`
MySQL | `MBRCoveredBy(poly, geom)`
SpatiaLite | `CoveredBy(poly, geom)`

Changed in Django 6.0:

MariaDB 12.0.1 以降のサポートが追加されました。

### `covers`

利用可能なDB: PostGIS, Oracle, MySQL, PGRaster (Bilateral), SpatiaLite

ルックアップされたジオメトリ内のどのポイントも、ジオメトリフィールドの外にないかどうかテストします。 [3]

実装例:

    Zipcode.objects.filter(poly__covers=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Covers(poly, geom)`
Oracle | `SDO_COVERS(poly, geom)`
MySQL | `MBRCovers(poly, geom)`
SpatiaLite | `Covers(poly, geom)`

### `crosses`

利用可能なDB: PostGIS, MariaDB, MySQL, SpatiaLite, PGRaster (Conversion)

ジオメトリフィールドがルックアップジオメトリと空間的に交差しているかをテストします。

実装例:

    Zipcode.objects.filter(poly__crosses=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Crosses(poly, geom)`
MariaDB | `ST_Crosses(poly, geom)`
MySQL | `ST_Crosses(poly, geom)`
SpatiaLite | `Crosses(poly, geom)`

### `disjoint`

利用可能なDB: PostGIS, Oracle, MariaDB, MySQL, SpatiaLite, PGRaster (Bilateral)

ジオメトリフィールドがルックアップジオメトリから空間的に分離しているかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__disjoint=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Disjoint(poly, geom)`
Oracle | `SDO_GEOM.RELATE(poly, 'DISJOINT', geom, 0.05)`
MariaDB | `ST_Disjoint(poly, geom)`
MySQL | `ST_Disjoint(poly, geom)`
SpatiaLite | `Disjoint(poly, geom)`

### `equals`

利用可能なDB: PostGIS, Oracle, MariaDB, MySQL, SpatiaLite, PGRaster (Conversion)

ジオメトリフィールドがルックアップジオメトリと空間的に等しいかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__equals=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Equals(poly, geom)`
Oracle | `SDO_EQUAL(poly, geom)`
MariaDB | `ST_Equals(poly, geom)`
MySQL | `ST_Equals(poly, geom)`
SpatiaLite | `Equals(poly, geom)`

### `exact`, `same_as`

利用可能なDB: PostGIS, Oracle, MariaDB, MySQL, SpatiaLite, PGRaster (Bilateral)

ジオメトリフィールドがルックアップジオメトリと "等しい" かどうかをテストします。Oracle、MySQL、SpatiaLite では空間的な等しさをテストし、PostGIS ではバウンディングボックスの等しさをテストします。

実装例:

    Zipcode.objects.filter(poly=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `poly ~= geom`
Oracle | `SDO_EQUAL(poly, geom)`
MariaDB | `ST_Equals(poly, geom)`
MySQL | `ST_Equals(poly, geom)`
SpatiaLite | `Equals(poly, geom)`

### `intersects`

利用可能なDB: PostGIS, Oracle, MariaDB, MySQL, SpatiaLite, PGRaster (Bilateral)

ジオメトリフィールドがルックアップジオメトリと空間的に交差しているかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__intersects=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Intersects(poly, geom)`
Oracle | `SDO_OVERLAPBDYINTERSECT(poly, geom)`
MariaDB | `ST_Intersects(poly, geom)`
MySQL | `ST_Intersects(poly, geom)`
SpatiaLite | `Intersects(poly, geom)`

### `isempty`

Availability: PostGIS, SpatiaLite

ジオメトリが空かどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__isempty=True)

Changed in Django 6.1:

SpatiaLite support was added.

### `isvalid`

利用可能なDB: MariaDB, MySQL, PostGIS, Oracle, SpatiaLite

ジオメトリが有効かどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__isvalid=True)

バックエンド | 等価なSQL
--- | ---
MariaDB, MySQL, PostGIS, SpatiaLite | `ST_IsValid(poly)`
Oracle | `SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(poly, 0.05) = 'TRUE'`

Changed in Django 6.0:

MariaDB 12.0.1 以降のサポートが追加されました。

### `geom_type`

New in Django 6.0.

利用可能なDB: PostGIS, Oracle 23c+, MariaDB, MySQL, SpatiaLite

Returns the geometry type of the geometry field.

実装例:

    Zipcode.objects.filter(poly__geom_type="POLYGON")

バックエンド | 等価なSQL
--- | ---
PostGIS | `GeometryType(geom)`
MariaDB | `ST_GeometryType(geom)`
MySQL | `ST_GeometryType(geom)`
Oracle | `SDO_GEOMETRY.GET_GTYPE(geom)`
SpatiaLite | `GeometryType(geom)`

### `num_dimensions`

New in Django 6.1.

Availability: PostGIS, SpatiaLite

Returns the number of dimensions used by the geometry.

実装例:

    Zipcode.objects.filter(geom__num_dimensions=3)

バックエンド | 等価なSQL
--- | ---
PostGIS, SpatiaLite | `ST_NDims(geom)`

### `overlaps`

利用可能なDB: PostGIS, Oracle, MariaDB, MySQL, SpatiaLite, PGRaster (Bilateral)

ジオメトリフィールドがルックアップ ジオメトリと空間的に重なっているかどうかをテストします。

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Overlaps(poly, geom)`
Oracle | `SDO_OVERLAPS(poly, geom)`
MariaDB | `ST_Overlaps(poly, geom)`
MySQL | `ST_Overlaps(poly, geom)`
SpatiaLite | `Overlaps(poly, geom)`

### `relate`

利用可能なDB: PostGIS, MariaDB, Oracle, SpatiaLite, PGRaster (Conversion)

Tests if the geometry field is spatially related to the lookup geometry by the values given in the given pattern. This lookup requires a tuple parameter, `(geom, pattern)`; the form of `pattern` will depend on the spatial backend:

#### MariaDB, PostGIS, SpatiaLite

On these spatial backends the intersection pattern is a string comprising nine characters, which define intersections between the interior, boundary, and exterior of the geometry field and the lookup geometry. The intersection pattern matrix may only use the following characters: `1`, `2`, `T`, `F`, or `*`. This lookup type allows users to "fine tune" a specific geometric relationship consistent with the DE-9IM model. [1]

ジオメトリの例:

    # A tuple lookup parameter is used to specify the geometry and
    # the intersection pattern (the pattern here is for 'contains').
    Zipcode.objects.filter(poly__relate=(geom, "T*T***FF*"))

PostGIS と MariaDB では下記の SQL と同等です:

    SELECT ... WHERE ST_Relate(poly, geom, 'T*T***FF*')

SpatiaLite では下記の SQL と同等です:

    SELECT ... WHERE Relate(poly, geom, 'T*T***FF*')

ラスターの例:

    Zipcode.objects.filter(poly__relate=(rast, 1, "T*T***FF*"))
    Zipcode.objects.filter(rast__2__relate=(rast, 1, "T*T***FF*"))

PostGIS では下記の SQL と同等です:

    SELECT ... WHERE ST_Relate(poly, ST_Polygon(rast, 1), 'T*T***FF*')
    SELECT ... WHERE ST_Relate(ST_Polygon(rast, 2), ST_Polygon(rast, 1), 'T*T***FF*')

#### Oracle

Here the relation pattern is comprised of at least one of the nine relation strings: `TOUCH`, `OVERLAPBDYDISJOINT`, `OVERLAPBDYINTERSECT`, `EQUAL`, `INSIDE`, `COVEREDBY`, `CONTAINS`, `COVERS`, `ON`, and `ANYINTERACT`. Multiple strings may be combined with the logical Boolean operator OR, for example, `'inside+touch'`. [2] The relation strings are case-insensitive.

実装例:

    Zipcode.objects.filter(poly__relate=(geom, "anyinteract"))

Oracle では下記の SQL と同等です:

    SELECT ... WHERE SDO_RELATE(poly, geom, 'anyinteract')

### `touches`

利用可能なDB: PostGIS, Oracle, MariaDB, MySQL, SpatiaLite

ジオメトリ フィールドがルックアップ ジオメトリに空間的に接しているかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__touches=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Touches(poly, geom)`
MariaDB | `ST_Touches(poly, geom)`
MySQL | `ST_Touches(poly, geom)`
Oracle | `SDO_TOUCH(poly, geom)`
SpatiaLite | `Touches(poly, geom)`

### `within`

利用可能なDB: PostGIS, Oracle, MariaDB, MySQL, SpatiaLite, PGRaster (Bilateral)

ジオメトリフィールドが空間的にルックアップジオメトリ内にあるかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__within=geom)

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Within(poly, geom)`
MariaDB | `ST_Within(poly, geom)`
MySQL | `ST_Within(poly, geom)`
Oracle | `SDO_INSIDE(poly, geom)`
SpatiaLite | `Within(poly, geom)`

### `left`

利用可能なDB: PostGIS, PGRaster (Conversion)

ジオメトリフィールドのバウンディングボックスが、ルックアップ ジオメトリのバウンディングボックスよりも厳密に左側にあるかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__left=geom)

PostGIS では下記の SQL と同等です:

    SELECT ... WHERE poly << geom

### `right`

利用可能なDB: PostGIS, PGRaster (Conversion)

ジオメトリフィールドのバウンディングボックスが、ルックアップ ジオメトリのバウンディングボックスの厳密に右側にあるかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__right=geom)

PostGIS では下記の SQL と同等です:

    SELECT ... WHERE poly >> geom

### `overlaps_left`

利用可能なDB: PostGIS, PGRaster (Bilateral)

ジオメトリフィールドのバウンディングボックスが、ルックアップ ジオメトリのバウンディングボックスと重なるか、または左にあるかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__overlaps_left=geom)

PostGIS では下記の SQL と同等です:

    SELECT ... WHERE poly &< geom

### `overlaps_right`

利用可能なDB: PostGIS, PGRaster (Bilateral)

ジオメトリフィールドのバウンディングボックスが、ルックアップ ジオメトリのバウンディングボックスと重なっているか、または右側にあるかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__overlaps_right=geom)

PostGIS では下記の SQL と同等です:

    SELECT ... WHERE poly &> geom

### `overlaps_above`

利用可能なDB: PostGIS, PGRaster (Conversion)

ジオメトリフィールドのバウンディングボックスがルックアップジオメトリのバウンディングボックスと重なっているか、または上にあるかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__overlaps_above=geom)

PostGIS では下記の SQL と同等です:

    SELECT ... WHERE poly |&> geom

### `overlaps_below`

利用可能なDB: PostGIS, PGRaster (Conversion)

ジオメトリフィールドのバウンディングボックスがルックアップジオメトリのバウンディングボックスと重なっているか、または下にあるかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__overlaps_below=geom)

PostGIS では下記の SQL と同等です:

    SELECT ... WHERE poly &<| geom

### `strictly_above`

利用可能なDB: PostGIS, PGRaster (Conversion)

ジオメトリフィールドのバウンディングボックスが、ルックアップジオメトリのバウンディングボックスの厳密に上にあるかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__strictly_above=geom)

PostGIS では下記の SQL と同等です:

    SELECT ... WHERE poly |>> geom

### `strictly_below`

利用可能なDB: PostGIS, PGRaster (Conversion)

ジオメトリフィールドのバウンディングボックスが、ルックアップジオメトリのバウンディングボックスの厳密に下にあるかどうかをテストします。

実装例:

    Zipcode.objects.filter(poly__strictly_below=geom)

PostGIS では下記の SQL と同等です:

    SELECT ... WHERE poly <<| geom

## 距離ルックアップ

利用可能なDB: PostGIS, Oracle, MariaDB, MySQL, SpatiaLite, PGRaster (Native)

距離クエリの概要については 距離クエリの概要 を参照してください。

距離ルックアップは次の形式を取ります:

    <field>__<distance lookup>=(<geometry/raster>, <distance value>[, "spheroid"])
    <field>__<distance lookup>=(<raster>, <band_index>, <distance value>[, "spheroid"])
    <field>__<band_index>__<distance lookup>=(<raster>, <band_index>, <distance value>[, "spheroid"])

距離ルックアップに渡される値はタプルであり、最初の2つの値は必須で、それぞれ、距離の計算対象のジオメトリと距離値 (フィールドの単位での数値、 `Distance` オブジェクト、または クエリ式) です。ルックアップにバンドインデックスを渡すには、2番目のエントリがバンドインデックスである3値タプルを使用します。

`dwithin` を除くすべての距離ルックアップには、オプションの要素として `'spheroid'` を含めることができます。これにより、測地座標系を持つフィールドにおいてより精度の高い回転楕円体距離計算関数を使用できます。

PostgreSQLでは、 `'spheroid'` オプションは ST_DistanceSphere の代わりに ST_DistanceSpheroid を使用します。投影座標系では、より単純な ST_Distance 関数を使用します。ラスタは回転楕円体ベースのルックアップ用にジオメトリに変換されます。

### `distance_gt`

指定された距離値よりも、ルックアップジオメトリからジオメトリフィールドへの距離が大きいモデルを返します。

実装例:

    Zipcode.objects.filter(poly__distance_gt=(geom, D(m=5)))

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Distance/ST_Distance_Sphere(poly, geom) > 5`
MariaDB | `ST_Distance(poly, geom) > 5`
MySQL | `ST_Distance(poly, geom) > 5`
Oracle | `SDO_GEOM.SDO_DISTANCE(poly, geom, 0.05) > 5`
SpatiaLite | `Distance(poly, geom) > 5`

### `distance_gte`

ルックアップしたジオメトリからジオメトリフィールドまでの距離が、指定した距離の値以上であるモデルを返します。

実装例:

    Zipcode.objects.filter(poly__distance_gte=(geom, D(m=5)))

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Distance/ST_Distance_Sphere(poly, geom) >= 5`
MariaDB | `ST_Distance(poly, geom) >= 5`
MySQL | `ST_Distance(poly, geom) >= 5`
Oracle | `SDO_GEOM.SDO_DISTANCE(poly, geom, 0.05) >= 5`
SpatiaLite | `Distance(poly, geom) >= 5`

### `distance_lt`

ルックアップしたジオメトリからジオメトリフィールドまでの距離が、指定した距離の値よりも小さいモデルを返します。

実装例:

    Zipcode.objects.filter(poly__distance_lt=(geom, D(m=5)))

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Distance/ST_Distance_Sphere(poly, geom) < 5`
MariaDB | `ST_Distance(poly, geom) < 5`
MySQL | `ST_Distance(poly, geom) < 5`
Oracle | `SDO_GEOM.SDO_DISTANCE(poly, geom, 0.05) < 5`
SpatiaLite | `Distance(poly, geom) < 5`

### `distance_lte`

ルックアップされたジオメトリからジオメトリフィールドまでの距離が、指定された距離の値以下であるモデルを返します。

実装例:

    Zipcode.objects.filter(poly__distance_lte=(geom, D(m=5)))

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_Distance/ST_Distance_Sphere(poly, geom) <= 5`
MariaDB | `ST_Distance(poly, geom) <= 5`
MySQL | `ST_Distance(poly, geom) <= 5`
Oracle | `SDO_GEOM.SDO_DISTANCE(poly, geom, 0.05) <= 5`
SpatiaLite | `Distance(poly, geom) <= 5`

### `dwithin`

ルックアップしたジオメトリからジオメトリフィールドまでの距離が、指定した距離以内のモデルを返します。 `Distance` オブジェクトを指定できるのは、対象となるジオメトリが投影システムの場合のみであることに注意してください。地理ジオメトリの場合は、ジオメトリフィールドの単位を使用する必要があります (例えば `WGS84` の場合は度)。

実装例:

    Zipcode.objects.filter(poly__dwithin=(geom, D(m=5)))

バックエンド | 等価なSQL
--- | ---
PostGIS | `ST_DWithin(poly, geom, 5)`
Oracle | `SDO_WITHIN_DISTANCE(poly, geom, 5)`
SpatiaLite | `PtDistWithin(poly, geom, 5)`

### 集計関数

Django はいくつかの GIS 固有の集計関数を提供しています。これらの集計関数の使い方の詳細については、 集計に関するトピックガイド を参照してください。

キーワード引数 | 説明
--- | ---
`tolerance` | This keyword is for Oracle only. It is for the tolerance value used by the `SDOAGGRTYPE` procedure; the Oracle documentation has more details.

例:

    >>> from django.contrib.gis.db.models import Extent, Union
    >>> WorldBorder.objects.aggregate(Extent("mpoly"), Union("mpoly"))

#### `Collect`

class Collect(geo_field, filter=None)

利用可能なDB: PostGIS, MariaDB, MySQL, SpatiaLite

ジオメトリ列から `GEOMETRYCOLLECTION` または `MULTI` ジオメトリオブジェクトを返します。これは `Union` 集計の簡略版に似ていますが、ジオメトリをコレクションまたはマルチオブジェクトにまとめ、境界の解消を気にしないため、ユニオンを実行するよりも数桁高速です。

Changed in Django 6.0:

MariaDB 12.0.1 以降のサポートが追加されました。

#### `Extent`

class Extent(geo_field, filter=None)

利用可能なDB: PostGIS, Oracle, SpatiaLite

`QuerySet` 内のすべての `geo_field` の範囲を表す、左下の座標と右上の座標からなる4値タプルを返します。

例:

    >>> qs = City.objects.filter(name__in=("Houston", "Dallas")).aggregate(Extent("poly"))
    >>> print(qs["poly__extent"])
    (-96.8016128540039, 29.7633724212646, -95.3631439208984, 32.782058715820)

#### `Extent3D`

class Extent3D(geo_field, filter=None)

利用可能なDB: PostGIS

`QuerySet` 内のすべての `geo_field` の 3D 範囲を、左下の座標と右上の座標 (それぞれ x、y、z 座標を持つ) からなる 6 要素のタプルとして返します。

例:

    >>> qs = City.objects.filter(name__in=("Houston", "Dallas")).aggregate(Extent3D("poly"))
    >>> print(qs["poly__extent3d"])
    (-96.8016128540039, 29.7633724212646, 0, -95.3631439208984, 32.782058715820, 0)

#### `MakeLine`

class MakeLine(geo_field, filter=None)

利用可能なDB: PostGIS, SpatiaLite

`QuerySet` 内のポイントフィールドジオメトリから構築された `LineString` を返します。現在、クエリセットの順序は意味がありません。

例:

    >>> qs = City.objects.filter(name__in=("Houston", "Dallas")).aggregate(MakeLine("poly"))
    >>> print(qs["poly__makeline"])
    LINESTRING (-95.3631510000000020 29.7633739999999989, -96.8016109999999941 32.7820570000000018)

#### `Union`

class Union(geo_field, filter=None)

利用可能なDB: PostGIS, Oracle, SpatiaLite

このメソッドは、クエリセット内のすべてのジオメトリの結合を含む `GEOSGeometry` オブジェクトを返します。大きなクエリセットでは、`Union` を使用すると処理が集中し、かなりの時間がかかる可能性があることに注意してください。

注釈

もしこの方法を使った計算に時間がかかりすぎる場合は、代わりに `Collect` を使用することを検討してください。

例:

    >>> u = Zipcode.objects.aggregate(Union(poly))  # This may take a long time.
    >>> u = Zipcode.objects.filter(poly__within=bbox).aggregate(
    ...     Union(poly)
    ... )  # A more sensible approach.

脚注

[1]

参考 OpenGIS Simple Feature Specification For SQL, at Ch. 2.1.13.2, p. 2-13 (The Dimensionally Extended Nine-Intersection Model).

[2]

参考 Oracle Spatial and Graph Developer's Guide の SDO_RELATE documentation 。

[3] (1,2)

この処理の説明については、PostGIS 開発者の Martin Davis による Quirks of the "Contains" Spatial Predicate を参照してください。