Geometry-Datentyp
| Name | Beschreibung |
|---|---|
GEOMETRY |
Geodaten-Entität |
Der Datentyp GEOMETRY wird verwendet, um geometrische Objekte wie Punkte, Linien und Polygone zu speichern und zu bearbeiten.
Der Typ GEOMETRY war Teil der Erweiterung spatial, wurde aber in DuckDB v1.5 zu einem eingebauten Datentyp. Die meisten Vorteile von GEOMETRY als eingebautem Typ (z. B. Speicheroptimierungen, Statistiken usw.) stehen daher nur in Datenbanken mit Speicherversion v1.5 und höher zur Verfügung. Fast alle zugehörigen Funktionen für die Arbeit mit Geometrien (z. B. Berechnen von Distanzen, Flächen, Schnittmengen) sind jedoch weiterhin Teil von spatial.
Arten von Geometrien
Konzeptionell folgt der Typ GEOMETRY dem zentralen Datenmodell, das im Standard Simple Features definiert ist und in Geodatenbanken und GIS-Software weit verbreitet ist. Ein GEOMETRY-Wert kann daher 7 Arten von Formen darstellen:
| Geometrie-Typ | Beschreibung |
|---|---|
| Point | Ein einzelner Ort im Raum, definiert durch seine Koordinaten (z. B. Längen- und Breitengrad). |
| LineString | Eine Folge von Punkten, die durch gerade Linien verbunden sind und einen Pfad oder eine Route darstellen. |
| Polygon | Eine Menge geschlossener Ringe, definiert durch eine Folge von Punkten, die eine Fläche darstellen, etwa eine Landesgrenze oder den Grundriss eines Gebäudes. Der erste Ring ist die „Hülle“, „innere“ Ringe stellen Löcher im Polygon dar. |
| MultiPoint | Eine Sammlung von Punkten. |
| MultiLineString | Eine Sammlung von LineStrings. |
| MultiPolygon | Eine Sammlung von Polygonen. |
| GeometryCollection | Eine Sammlung unterschiedlicher Geometrie-Typen, die komplexe Geometrien erlaubt, die Punkte, Linien und Polygone oder sogar weitere verschachtelte Geometrie-Sammlungen kombinieren. |
Die textuelle Darstellung von Geometrien verwendet das Format „Well-Known Text“ (WKT). Geometrien können in WKT-Zeichenketten und aus ihnen gecastet werden, sodass Sie String-Literale verwenden können, um Geometrien direkt in SQL-Anweisungen zu erzeugen.
Im folgenden Beispiel legen wir eine GEOMETRY-Spalte mit den 7 unterstützten Geometrie-Typen an:
CREATE TABLE geometries ( id INTEGER, geom GEOMETRY);
INSERT INTO geometries VALUES (1, 'POINT (30 10)'), (2, 'LINESTRING (30 10, 10 30, 40 40)'), (3, 'POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))'), (4, 'MULTIPOINT ((10 40), (40 30), (20 20), (30 10))'), (5, 'MULTILINESTRING ((10 10, 20 20, 10 40), (40 40, 30 30, 40 20))'), (6, 'MULTIPOLYGON (((30 20, 45 40, 10 40, 30 20)), ((15 5, 40 10, 10 20, 5 10,15 5)))'), (7, 'GEOMETRYCOLLECTION (POINT(40 10), LINESTRING(10 10,20 20,10 40), POLYGON((40 40,20 45,45 30,40 40)))');
SELECT * FROM geometries;----┌───────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────┐│ id │ geom ││ int32 │ geometry │├───────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤│ 1 │ POINT (30 10) ││ 2 │ LINESTRING (30 10, 10 30, 40 40) ││ 3 │ POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10)) ││ 4 │ MULTIPOINT (10 40, 40 30, 20 20, 30 10) ││ 5 │ MULTILINESTRING ((10 10, 20 20, 10 40), (40 40, 30 30, 40 20)) ││ 6 │ MULTIPOLYGON (((30 20, 45 40, 10 40, 30 20)), ((15 5, 40 10, 10 20, 5 10, 15 5))) ││ 7 │ GEOMETRYCOLLECTION (POINT (40 10), LINESTRING (10 10, 20 20, 10 40), POLYGON ((40 40, 20 45, 45 30, 40 40))) │└───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────┘Mehrdimensionale Geometrien
Der Typ GEOMETRY wird in erster Linie verwendet, um Formen in zwei Dimensionen zu modellieren (z. B. X/Y oder longitude/latitude), unterstützt aber auch Formen mit zusätzlichen Vertex-Dimensionen wie Z für Höhe oder M für „Measure“ oder beides.
Die Vertex-Dimensionen eines GEOMETRY-Werts müssen über alle Vertices hinweg konsistent sein. Hat ein Vertex beispielsweise X-, Y- und Z-Koordinaten, müssen alle anderen Vertices in dieser Geometrie ebenfalls X-, Y- und Z-Koordinaten haben. Das bedeutet, dass Sie innerhalb derselben Geometrie keine Mischung aus 2D- und 3D-Vertices haben können. Das gilt auch für Sammlungen von Geometrien wie MULTIPOINT oder GEOMETRYCOLLECTION, in denen alle Geometrien in der Sammlung dieselben Vertex-Dimensionen haben müssen.
Funktionen, die auf GEOMETRY-Werten arbeiten, ignorieren typischerweise alle zusätzlichen Dimensionen jenseits von X und Y, sofern nicht explizit angegeben, aber sie können trotzdem gespeichert und bei Bedarf abgerufen werden.
Im folgenden Beispiel legen wir eine GEOMETRY-Tabelle mit 2D-, 3D(Z)-, 3D(M)- und 4D(ZM)-Punkten an:
CREATE TABLE points ( id INTEGER, geom GEOMETRY);
INSERT INTO points VALUES (1, 'POINT (30 10)'), (2, 'POINT Z (30 10 5)'), (3, 'POINT M (30 10 1)'), (4, 'POINT ZM (30 10 5 1)');
SELECT * FROM points;----┌───────┬──────────────────────┐│ id │ geom ││ int32 │ geometry │├───────┼──────────────────────┤│ 1 │ POINT (30 10) ││ 2 │ POINT Z (30 10 5) ││ 3 │ POINT M (30 10 1) ││ 4 │ POINT ZM (30 10 5 1) │└───────┴──────────────────────┘
-- But we cannot mix different vertex dimensions within the same geometry!INSERT INTO points VALUES (5, 'MULTIPOINT (POINT (30 10), POINT Z (30 10 5))');----Invalid Input Error:Geometry has inconsistent Z/M dimensionLeere Geometrien
Geometrien können auch „leer“ sein (z. B. POINT EMPTY, LINESTRING EMPTY, MULTIPOLYGON EMPTY usw.), das heißt, sie enthalten keine Vertices. Leere Geometrien sind trotzdem gültige Geometrien und können in räumlichen Operationen verwendet werden, sind aber vor allem nützlich, um das Ergebnis topologischer Operationen darzustellen, die keine gültige geometrische Darstellung haben (z. B. ist der Schnitt zweier nicht überlappender Geometrien eine leere Geometrie).
Geometrie-Speicherung
Intern werden GEOMETRY-Werte als Bytefolge gespeichert, ähnlich den BLOB-Typen von DuckDB. Das genaue Binärformat ist noch nicht stabilisiert und kann sich in einer zukünftigen Version ändern, aber ab DuckDB-Speicherversion v1.5 basiert es auf Little-Endian Well-Known Binary (WKB), einer standardisierten Binärkodierung für Geometrien. In älteren Speicherversionen wurden Geometrien in einem anderen, von der Erweiterung spatial verwendeten eigenen Binärformat gespeichert; diese Umwandlung erfolgt automatisch auf der Speicherschicht und ist für die Ausführungsmaschine und den Benutzer nicht sichtbar.
Shredding und Kompression
Der Typ GEOMETRY unterstützt eine Speicheroptimierung namens „Shredding“, die die Kompression für Geometrie-Spalten verbessert, in denen alle Werte denselben Geometrie-Typ und dieselben Vertex-Dimensionen haben.
Wenn eine Row Group die Voraussetzungen erfüllt, zerlegt DuckDB das Geometrie-Segment innerhalb der Row Group in primitive STRUCT-, LIST- und DOUBLE-Segmente, die unabhängig mit Lightweight-Algorithmen komprimiert werden können – deutlich effizienter als das Speichern von Binär-Blobs variabler Größe.
Das geshreddete Layout hängt vom Geometrie-Typ ab:
POINT- STRUCT(X DOUBLE, Y DOUBLE) (und/oder Z, M)LINESTRING- STRUCT(X DOUBLE, Y DOUBLE)[]POLYGON- STRUCT(X DOUBLE, Y DOUBLE)[][]MULTIPOINT,MULTILINESTRING,MULTIPOLYGON- wie oben, mit einer zusätzlichen Ebene der Listenverschachtelung
Row Groups werden nicht geshreddet, wenn sie GEOMETRYCOLLECTIONs, beliebige EMPTY-Geometrien oder mehrere Geometrie-Subtypen enthalten.
Zusätzlich werden Row Groups nicht geshreddet, wenn sie unter der Mindestgrößenschwelle liegen (Standard: ~25 % der maximalen Row-Group-Größe, d. h. 30.000 Zeilen).
Diese Schwelle ist über die Einstellung geometry_minimum_shredding_size konfigurierbar. Setzen Sie sie auf 0, um immer zu shredden, oder auf -1, um Shredding vollständig zu deaktivieren.
-- Disable shredding for geometry columnsSET geometry_minimum_shredding_size = -1;
-- Always shred geometry columns regardless of row group sizeSET geometry_minimum_shredding_size = 0;Der primäre Vorteil von Shredding ist eine deutlich verbesserte Kompression; in Zukunft planen wir jedoch, Wege hinzuzufügen, die geshreddete Darstellung der Ausführungsmaschine direkt zugänglich zu machen, ohne die Geometrie wieder in Binärform „zusammenzusetzen“.
Das folgende Beispiel veranschaulicht die Auswirkungen von Shredding auf den Speicherbedarf einer GEOMETRY-Spalte.
-- Attach a persistent database with storage version v1.5ATTACH 'geometry_db.db' as geometry_db (STORAGE_VERSION 'v1.5.0');
USE geometry_db;
-- Disable shredding completely and create a table with 1 million 2D pointsSET geometry_minimum_shredding_size = -1;
CREATE OR REPLACE TABLE points AS SELECT printf('POINT (%d %d)', x, y)::GEOMETRY AS geomFROM range(0, 1000) AS rx(x), range(0, 1000) AS ry(y);
-- Checkpoint the database to persist the data and storage layout to diskCHECKPOINT;
-- Attach a second databaseATTACH 'shredded_db.db' as shredded_db (STORAGE_VERSION 'v1.5.0');
USE shredded_db;
-- This time, set the minimum shredding size to 0 to always shred geometry columns,-- and create the same table with 1 million 2D pointsSET geometry_minimum_shredding_size = 0;
CREATE OR REPLACE TABLE points AS SELECT printf('POINT (%d %d)', x, y)::GEOMETRY AS geomFROM range(0, 1000) AS rx(x), range(0, 1000) AS ry(y);
-- Checkpoint to persist the data and storage layout to disk, and apply shreddingCHECKPOINT;
-- Now check the storage layout and memory usage of the geometry column in both attached databasesSELECT database_name, database_size FROM pragma_database_size();----┌───────────────┬───────────────┐│ database_name │ database_size ││ varchar │ varchar │├───────────────┼───────────────┤│ shredded_db │ 2.2 MiB │ -- Almost 3x smaller storage thanks to shredding!│ geometry_db │ 6.5 MiB ││ memory │ 0 bytes │└───────────────┴───────────────┘
-- We can inspect what type of segments are used to store the geometry column-- in each database using the `pragma_storage_info` function.
-- The geometry column in `geometry_db` is stored as regular GEOMETRY segmentsSELECT DISTINCT(segment_type) FROM pragma_storage_info('geometry_db.points');----┌──────────────┐│ segment_type ││ varchar │├──────────────┤│ GEOMETRY ││ VALIDITY │└──────────────┘
-- While the geometry column in `shredded_db` is decomposed into primitive DOUBLE segments,-- which can be compressed much more efficiently!SELECT DISTINCT(segment_type) FROM pragma_storage_info('shredded_db.points');----┌──────────────┐│ segment_type ││ varchar │├──────────────┤│ VALIDITY ││ DOUBLE │└──────────────┘Geometrie-Statistiken
GEOMETRY-Spalten enthalten geometriespezifische Statistiken, die die Bounding Box der Geometrien in jeder Row Group sowie die Menge der Geometrie-Typen und Vertex-Dimensionen verfolgen, die in der Row Group vorhanden sind.
Sie können die Statistiken einer Spalte mit der Funktion stats() prüfen:
CREATE TABLE geometries as select 'POINT Z (30 10 5)'::GEOMETRY as geom;
SELECT stats(geom) AS geom_stats FROM geometries;----┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐│ geom_stats ││ varchar │├─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤│ [Extent: [X: [30.000000, 30.000000], Y: [10.000000, 10.000000], Z: [5.000000, 5.000000], M: [inf, -inf]], Types: [point_z], Flags: [Has Empty Geom: false, Has No Empty Geom: true, Has Empty Part: ││ false, Has No Empty Part: true]][Has Null: false, Has No Null: true][Approx Unique: 1] │└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘Diese Statistiken können vom Query-Optimizer verwendet werden, um Row Groups zu überspringen, die nicht dem von einer Abfrage benötigten Geometrie-Typ oder den Vertex-Dimensionen entsprechen, oder um räumliche Prädikate zu beschleunigen, indem zuerst geprüft wird, ob die Bounding Box der Geometrien in der Row Group mit der Bounding Box der Abfrage-Geometrie überlappt.
Derzeit kann nur der Operator &&, der prüft, ob die Bounding Box einer Geometrie die Bounding Box einer anderen Geometrie schneidet, Geometrie-Statistiken nutzen, wenn er in einer WHERE-Klausel verwendet wird. Es wird daran gearbeitet, weitere statistikbasierte Optimierungen für die Funktionen der Erweiterung spatial hinzuzufügen, etwa ST_Intersects, ST_Distance usw.
Das Persistieren von Geometrie-Statistiken ist nur in Speicherversionen v1.5 und höher möglich; bei älteren Speicherversionen werden die Geometrie-Statistiken beim Checkpointing daher zu „unbekannten“ Statistiken. Mit anderen Worten: Die Bounding Box wird auf eine unendlich große Bounding Box gesetzt, und alle Geometrie-Typen und Vertex-Dimensionen werden als möglicherweise vorhanden markiert, sodass die Ausführungsmaschine keine Optimierungen auf Basis der Geometrie-Statistiken vornehmen kann.
Koordinatenreferenzsysteme
Für die Ausführungsmaschine gelten Geometrien als in einem kartesischen Koordinatensystem existierend. In der Praxis sind die meisten Geodaten jedoch mit einem bestimmten Koordinatenreferenzsystem (CRS) verknüpft, das festlegt, wie die Koordinaten sich auf reale Orte auf der Erdoberfläche beziehen.
Eine hilfreiche Analogie ist, CRSs als das Pendant zu „Zeitzonen“, aber für Geodaten, zu betrachten. So wie Zeitzonen festlegen, wie die Ortszeit sich auf eine Standard-Referenzzeit bezieht (z. B. UTC), legen CRSs fest, wie die Koordinaten einer Geometrie sich auf ein Standard-Referenzsystem beziehen (z. B. WGS 84). CRSs sind üblicherweise entweder geografisch (z. B. WGS 84, das Breite und Länge verwendet) oder projiziert (z. B. UTM, das lineare Einheiten wie Meter verwendet).
Bei der Arbeit mit Geodaten ist es wichtig, das mit verschiedenen Datensätzen verknüpfte CRS zu kennen. Das Ausführen räumlicher Operationen auf Geometrien in unterschiedlichen CRSs ohne ordnungsgemäße Transformation führt höchstwahrscheinlich zu falschen Ergebnissen.
Wie werden Koordinatenreferenzsysteme in DuckDB gespeichert?
Um solche Fehler zu vermeiden, ermöglicht DuckDB, ein CRS explizit mit einer GEOMETRY-Spalte zu verknüpfen.
Das geschieht, indem ein CRS-„Identifikator“ als Parameter des Typs GEOMETRY übergeben wird. Eine Spalte vom Typ GEOMETRY('OGC:CRS84') speichert beispielsweise Geometrien, die mit dem Koordinatenreferenzsystem „OGC CRS84“ verknüpft sind.
CRS-Identifikatoren in DuckDB sind immer Zeichenketten. OGC:CRS84 ist der Identifikator für ein gängiges geografisches Koordinatensystem, das den gesamten Globus umfasst, wobei die X-Koordinate den Längengrad und die Y-Koordinate den Breitengrad darstellt. DuckDB weiß das nur, weil der Identifikator ‘OGC:CRS84’ als bekanntes CRS im Systemkatalog registriert ist.
Standardmäßig sind nur eine Handvoll gängiger CRSs als bekannt registriert, aber Erweiterungen können zusätzliche bekannte CRSs registrieren. Insbesondere registriert die Erweiterung spatial über 7000 CRSs aus dem EPSG Geodetic Parameter Dataset, das wohl die am weitesten verbreitete Datenbank von Koordinatenreferenzsystemen ist.
Sie können alle DuckDB bekannten verfügbaren CRSs mit der Funktion duckdb_coordinate_systems() auflisten:
SELECT * FROM duckdb_coordinate_systems();----┌───────────────┬──────────────┬─────────────┬────────────┬─────────┬───────────┬───────────┬───────────┬───────────────────────────────────────┬───────────────────────────────────────┐│ database_name │ database_oid │ schema_name │ schema_oid │ crs_oid │ crs_name │ auth_name │ auth_code │ projjson │ wkt2_2019 ││ varchar │ int64 │ varchar │ int64 │ int64 │ varchar │ varchar │ varchar │ varchar │ varchar │├───────────────┼──────────────┼─────────────┼────────────┼─────────┼───────────┼───────────┼───────────┼───────────────────────────────────────┼───────────────────────────────────────┤│ system │ 0 │ main │ 0 │ 1354 │ OGC:CRS83 │ OGC │ CRS83 │ {"$schema":"https://proj.org/schemas… │ GEOGCRS["NAD83 (CRS83)",DATUM["North… ││ system │ 0 │ main │ 0 │ 1353 │ OGC:CRS84 │ OGC │ CRS84 │ {"$schema":"https://proj.org/schemas… │ GEOGCRS["WGS 84 (CRS84)",ENSEMBLE["W… │└───────────────┴──────────────┴─────────────┴────────────┴─────────┴───────────┴───────────┴───────────┴───────────────────────────────────────┴───────────────────────────────────────┘Unbekannte Koordinatenreferenzsysteme behandeln
Wie oben erwähnt, können nur Koordinatensysteme, die im Systemkatalog registriert sind (und DuckDB daher „bekannt“ sind), beim Anlegen von GEOMETRY-Spalten verwendet werden.
Wenn Sie versuchen, eine GEOMETRY-Spalte mit einem unbekannten CRS-Identifikator anzulegen, entweder manuell oder durch Import eines externen Geodatensatzes, schlägt die Anweisung mit einem Fehler fehl.
SELECT 'POINT(1 2)'::GEOMETRY('DUCK:1337') AS my_point;----Binder Error:Encountered unrecognized coordinate system 'DUCK:1337' when trying to create GEOMETRY typeThe coordinate system definition may be incomplete or invalid ...Diese Einschränkung besteht, weil DuckDB die vollständige CRS-Definition braucht, nicht nur einen Identifikator, um Koordinatentransformationen durchzuführen und in Formate zu exportieren, die CRS-Metadaten einbetten, etwa GeoParquet. Ohne einen Eintrag im Systemkatalog gibt es keine Möglichkeit, einen Identifikator in seine vollständige Definition aufzulösen.
Sie können die Konfigurationsoption ignore_unknown_crs auf true setzen, um unbekannte CRSs einfach zu überspringen und stattdessen GEOMETRY-Spalten ohne CRS anzulegen.
-- Ignore any unknown CRS identifiersSET ignore_unknown_crs = true;
select 'POINT(1 2)'::GEOMETRY('DUCK:1337') AS my_point;----┌─────────────┐│ my_point ││ geometry │ -- The geometry is created, but the CRS is dropped from the type!├─────────────┤│ POINT (1 2) │└─────────────┘Alternativ können Sie, wenn Sie selbst eine GEOMETRY-Spalte definieren, statt eines Kurz-Identifikators eine vollständige CRS-Definition im Format WKT oder PROJJSON als CRS-Parameter angeben. Vollständige CRS-Definitionen sind jedoch üblicherweise sehr groß, sodass das schnell unhandlich wird und für interaktive Nutzung nicht empfohlen wird.
Es ist derzeit nicht möglich, ein benutzerdefiniertes CRS aus SQL heraus zu definieren oder benutzerdefinierte CRS-Definitionen in einer Datenbank zu persistieren, sodass DuckDB sie zur Auflösung von CRS-Identifikatoren für Geometrie-Spalten verwenden kann; das erwägen wir jedoch für die Zukunft.
Mit Geometrien in unterschiedlichen Koordinatenreferenzsystemen arbeiten
Ein Vorteil der Verfolgung von CRSs als Teil des Typsystems ist, dass es viele häufige Fehler verhindert, die bei der Arbeit mit Geometrien aus unterschiedlichen Koordinatensystemen auftreten können. Die meisten räumlichen Funktionen, die auf mehreren GEOMETRY-Werten arbeiten, prüfen, dass alle Eingabeausdrücke dasselbe CRS haben, bevor die Operation ausgeführt wird. Ebenso können GEOMETRY-Spalten nur implizit in andere GEOMETRY-Spalten und aus ihnen gecastet werden, wenn Quelle oder Ziel kein CRS angegeben haben.
Um eine Geometrie von einem CRS in ein anderes umzuwandeln, können Sie die Funktion ST_Transform(geom, crs) aus der Erweiterung spatial verwenden.
LOAD spatial;
SELECT ST_Transform('POINT(4.897070 52.377956)'::GEOMETRY('OGC:CRS84'), 'EPSG:3857') AS transformed;----┌────────────────────────────────────────────┐│ transformed ││ geometry('epsg:3857') │├────────────────────────────────────────────┤│ POINT (545139.3387790163 6868755.38408516) │└────────────────────────────────────────────┘Sie können auch die Funktion ST_SetCRS(geom, crs) verwenden, um einer Geometrie ohne CRS ein CRS zuzuweisen oder ein CRS neu zuzuweisen, ohne Koordinaten zu transformieren (z. B. wenn die Daten bereits im richtigen Koordinatensystem vorliegen, aber das korrekte CRS fehlt).
SELECT ST_SetCRS('POINT(4.897070 52.377956)'::GEOMETRY, 'OGC:CRS84') AS with_crs;----┌───────────────────────────┐│ with_crs ││ geometry('ogc:crs84') │├───────────────────────────┤│ POINT (4.89707 52.377956) │└───────────────────────────┘Oder wenn Sie das CRS von einer Geometrie entfernen möchten, können Sie entweder einfach nach GEOMETRY casten oder das CRS auf '' setzen:
SELECT 'POINT(4.897070 52.377956)'::GEOMETRY('OGC:CRS84')::GEOMETRY AS no_crs;----┌───────────────────────────┐│ no_crs ││ geometry │├───────────────────────────┤│ POINT (4.89707 52.377956) │└───────────────────────────┘
SELECT ST_SetCRS('POINT(4.897070 52.377956)'::GEOMETRY('OGC:CRS84'), '') AS no_crs;----┌───────────────────────────┐│ no_crs ││ geometry │├───────────────────────────┤│ POINT (4.89707 52.377956) │└───────────────────────────┘Natürlich können Sie auch ST_CRS(geom) verwenden, um das CRS einer Geometrie abzurufen:
SELECT ST_CRS('POINT(4.897070 52.377956)'::GEOMETRY('OGC:CRS84')) AS crs;----┌───────────┐│ crs ││ varchar │├───────────┤│ OGC:CRS84 │└───────────┘Funktionen
- Eine Liste der eingebauten Geometrie-Funktionen finden Sie unter Geometrie-Funktionen.
- Die Dokumentation der Erweiterung
spatialbeschreibt die große Menge zusätzlicher Geometrie-Funktionen der Erweiterung, einschließlich Funktionen zum Berechnen von Flächen, Distanzen, Schnittmengen, Vereinigungen und vieles mehr.