Datentypen für Geodaten¶
Snowflake bietet native Unterstützung von räumlichen Merkmalen wie Punkten, Linien und Polygonen auf der Erdoberfläche.
Unter diesem Thema:
Datentypen¶
Snowflake bietet die folgenden Datentypen für Geodaten:
Datentyp GEOGRAPHY, der die Erde so modelliert, als wäre sie eine perfekte Kugel.
Datentyp GEOMETRY, der Merkmale eines planaren (euklidischen, kartesischen) Koordinatensystems repräsentiert.
GEOGRAPHY-Datentyp¶
Der Datentyp GEOGRAPHY verwendet WGS-84 als globales Georeferenzsystem (EPSG-ID 4326; Einzelheiten siehe https://spatialreference.org/ref/epsg/wgs-84/).
Punkte auf der Erde werden als Längengrade (von -180 Grad bis +180 Grad) und Breitengrade (-90 bis +90) dargestellt.
Höhenangaben werden derzeit nicht unterstützt.
Liniensegmente werden als geodätische Bögen auf der Erdoberfläche interpretiert.
Snowflake bietet auch Geodatenfunktionen, die den Datentyp GEOGRAPHY verarbeiten.
Wenn Sie Geodaten (z. B. Längen- und Breitengrad, WKT, WKB, GeoJSON usw.) haben, sollten Sie diese Daten konvertieren und in GEOGRAPHY-Spalten speichern, anstatt die Daten in ihren ursprünglichen Formaten in VARCHAR-, VARIANT- oder NUMBER-Spalten zu behalten. Das Speichern Ihrer Daten in GEOGRAPHY-Spalten kann die Leistung von Abfragen, die Geofunktionen verwenden, erheblich verbessern.
GEOMETRY-Datentyp¶
Vorschau-Feature – Offen
Verfügbar bei allen Konten.
Der Datentyp GEOMETRY repräsentiert Merkmale eines planaren (euklidischen, kartesischen) Koordinatensystems.
Die Koordinaten werden als Paare von reellen Zahlen (x, y) dargestellt. Derzeit werden nur 2D-Koordinaten unterstützt.
Die Maßeinheiten von X und Y werden durch das räumliche Bezugssystem (Spatial Reference System, SRS) bestimmt, das dem GEOMETRY-Objekt zugeordnet ist. Das räumliche Bezugssystem wird durch die Kennung des räumlichen Bezugssystems (Spatial Reference System Identifier, SRID) identifiziert. Wenn die SRID weder beim Erstellen des GEOMETRY-Objekts noch durch Aufruf von ST_SETSRID bereitgestellt wird, hat die SRID den Wert 0.
Snowflake bietet eine Reihe von Geodatenfunktionen, die den Datentyp GEOMETRY verarbeiten. Für diese Funktionen gilt Folgendes:
Alle Funktionen setzen planare Koordinaten voraus, auch wenn die Geometrie ein nicht-planares SRS verwendet.
Die Messfunktionen (z. B. ST_LENGTH) verwenden die gleichen Einheiten wie das Koordinatensystem.
Bei Funktionen, die mehrere GEOMETRY-Ausdrücke als Argumente akzeptieren (z. B. ST_DISTANCE), müssen die Eingabeausdrücke im selben SRS definiert sein.
Eingabe und Ausgabe von Geodaten¶
In den folgenden Abschnitten werden die Standardformate und Objekttypen beschrieben, die beim Lesen und Schreiben von Geodaten verwendet werden können.
Unterstützte Standardformate für die Ein- und Ausgabe¶
Die Datentypen GEOGRAPHY und GEOMETRY unterstützen die folgenden branchenspezifischen Standardformate für die Ein- und Ausgabe:
Well-Known Text (WKT)
Well-Known Binary (WKB)
Erweitertes WKT und WKB (EWKT und EWKB) (siehe den Hinweis zur Behandlung von EWKT und EWKB)
IETF GeoJSON (siehe den Hinweis zur Verwendung von GeoJSON)
Möglicherweise sind auch folgende Referenzen hilfreich:
Simple Feature Access des Open Geospatial mit „Common Architecture“ und SQL-Option:
Jede Abweichung von diesen Standards wird ausdrücklich in der Snowflake-Dokumentation vermerkt.
Hinweis zur Verwendung von GeoJSON mit GEOGRAPHY-Werten¶
Die Standards WKT und WKB geben nur ein Format an. Die Semantik von WKT/WKB-Objekten hängt vom Referenzsystem ab, zum Beispiel Ebene oder Kugel.
Der GeoJSON-Standard gibt andererseits sowohl ein Format als auch seine Semantik an: GeoJSON-Punkte sind explizit WGS-84-Koordinaten, und GeoJSON-Liniensegmente werden als ebene Kanten (gerade Linien) betrachtet.
Im Gegensatz dazu interpretiert der Datentyp GEOGRAPHY von Snowflake alle Liniensegmente als geodätische Bögen, einschließlich derjenigen, die im GeoJSON-Format eingegeben oder ausgegeben werden. Im Wesentlichen behandelt Snowflake GeoJSON-Daten als JSON-formatierten WKT mit sphärischer Semantik.
Hinweis zur Verwendung von EWKT und EWKB mit GEOGRAPHY-Werten¶
EWKT und EWKB sind spezifische Formate, die von PostGIS eingeführt wurden. Sie erweitern die Formate WKT und WKB um einen Spatial Reference System Identifier (SRID), der das mit den Daten zu verwendende Koordinatenreferenzsystem angibt. Snowflake unterstützt derzeit nur WGS84, was SRID=4326 zugeordnet ist.
Standardmäßig gibt Snowflake einen Fehler aus, wenn ein EWKB- oder EWKT-Eingabewert eine andere SRID als 4326 enthält. Umgekehrt weisen alle EWKB- und EWKT-Ausgabewerte die SRID=4326 auf.
Unterstützten Typen von Geodatenobjekten¶
Die Datentypen GEOGRAPHY und GEOMETRY können die folgenden Typen von Geodatenobjekten speichern:
WKT/WKB/EWKT/EWKB/GeoJSON-Geodatenobjekte:
Punkt
MultiPoint
LineString
MultiLineString
Polygon
MultiPolygon
GeometryCollection
GeoJSON-spezifische Geodatenobjekte:
Funktion
FeatureCollection
Angeben des Ausgabeformats für Resultsets¶
Die Sitzungsparameter GEOGRAPHY_OUTPUT_FORMAT und GEOMETRY_OUTPUT_FORMAT steuern das Rendern von Spalten vom Typ GEOGRAPHY bzw. GEOMETRY in entsprechenden Resultsets.
Die Parameter GEOGRAPHY_OUTPUT_FORMAT und GEOMETRY können einen der folgenden Werte haben:
Parameterwert
Beschreibung
GeoJSON (Standard)
Das GEOGRAPHY/GEOMETRY-Ergebnis wird als ein OBJECT-Wert im GeoJSON-Format gerendert.
WKT
Das GEOGRAPHY/GEOMETRY-Ergebnis wird als ein VARCHAR-Wert im WKT-Format gerendert.
WKB
Das GEOGRAPHY/GEOMETRY-Ergebnis wird als ein BINARY-Wert im WKB-Format gerendert.
EWKT
Das GEOGRAPHY/GEOMETRY-Ergebnis wird als ein VARCHAR-Wert im EWKT-Format gerendert.
EWKB
Das GEOGRAPHY/GEOMETRY-Ergebnis wird als ein BINARY-Wert im EWKB-Format gerendert.
Für EWKT und EWKB ist die SRID in der Ausgabe immer „4326“. Siehe den Hinweis zur Verwendung von EWKT und EWKB.
Dieser Parameter betrifft alle Clients, einschließlich Snowflake-UI und SnowSQL-Befehlszeilenclient sowie Treiber und Konnektoren für JDBC, ODBC, node.js, Python usw.
Beispiel: Der JDBC-Treiber gibt die folgenden Metadaten für eine GEOGRAPHY-typisierte Ergebnisspalte zurück (Spalte i in diesem Beispiel):
Wenn
GEOGRAPHY_OUTPUT_FORMAT='GeoJSON'oderGEOMETRY_OUTPUT_FORMAT='GeoJSON':ResultSetMetaData.getColumnType(i)gibtjava.sql.Types.VARCHARzurück.ResultSetMetaData.getColumnClassName(i)gibt"java.lang.String"zurück.
Wenn
GEOGRAPHY_OUTPUT_FORMAT='WKT'oder'EWKT', oder wennGEOMETRY_OUTPUT_FORMAT='WKT'oder'EWKT':ResultSetMetaData.getColumnType(i)gibtjava.sql.Types.VARCHARzurück.ResultSetMetaData.getColumnClassName(i)gibt"java.lang.String"zurück.
Wenn
GEOGRAPHY_OUTPUT_FORMAT='WKB'oder'EWKB', oder wennGEOMETRY_OUTPUT_FORMAT='WKB'oder'EWKB':ResultSetMetaData.getColumnType(i)gibtjava.sql.Types.BINARYzurück.ResultSetMetaData.getColumnClassName(i)gibt"[B"(Bytearray).
Bemerkung
APIs zum Abrufen von datenbankspezifischen Typnamen (getColumnTypeName in JDBC und der SQL_DESC_TYPE_NAME-Deskriptor in ODBC) geben immer GEOGRAPHY und GEOMETRY als Typnamen zurück, unabhängig vom Wert des Parameters GEOGRAPHY_OUTPUT_FORMAT bzw. GEOMETRY_OUTPUT_FORMAT. Weitere Details dazu finden Sie unter:
Snowflake-spezifisches Verhalten in der Dokumentation zum JDBC-Treiber.
Abrufen von Ergebnissen und Informationen über Ergebnisse in der Dokumentation zum ODBC-Treiber.
Beispiele für das Einfügen und Abfragen von GEOGRAPHY-Daten¶
Der folgende Code zeigt die Ein- und Ausgabe von Beispieldaten mit dem Datentyp GEOGRAPHY. Beachten Sie Folgendes:
Bei Koordinaten in WKT, EWKT und GeoJSON wird erst die Länge, dann die Breite angezeigt (z. B.
POINT(lon lat)).Bei WKB- und EWKB-Ausgaben wird angenommen, dass der Parameter BINARY_OUTPUT_FORMAT auf
HEX(Standardwert des Parameters) gesetzt ist.
Das Beispiel erstellt eine Tabelle mit einer Spalte GEOGRAPHY, fügt Daten im Format WKT ein und gibt die Daten in verschiedenen Ausgabeformaten zurück.
create table geospatial_table (id INTEGER, g GEOGRAPHY); insert into geospatial_table values (1, 'POINT(-122.35 37.55)'), (2, 'LINESTRING(-124.20 42.00, -120.01 41.99)');alter session set GEOGRAPHY_OUTPUT_FORMAT='GeoJSON';select g from geospatial_table order by id; +------------------------+ | G | |------------------------| | { | | "coordinates": [ | | -122.35, | | 37.55 | | ], | | "type": "Point" | | } | | { | | "coordinates": [ | | [ | | -124.2, | | 42 | | ], | | [ | | -120.01, | | 41.99 | | ] | | ], | | "type": "LineString" | | } | +------------------------+alter session set GEOGRAPHY_OUTPUT_FORMAT='WKT';select g from geospatial_table order by id; +-------------------------------------+ | G | |-------------------------------------| | POINT(-122.35 37.55) | | LINESTRING(-124.2 42,-120.01 41.99) | +-------------------------------------+alter session set GEOGRAPHY_OUTPUT_FORMAT='WKB';select g from geospatial_table order by id; +------------------------------------------------------------------------------------+ | G | |------------------------------------------------------------------------------------| | 01010000006666666666965EC06666666666C64240 | | 010200000002000000CDCCCCCCCC0C5FC00000000000004540713D0AD7A3005EC01F85EB51B8FE4440 | +------------------------------------------------------------------------------------+alter session set GEOGRAPHY_OUTPUT_FORMAT='EWKT';select g from geospatial_table order by id; +-----------------------------------------------+ | G | |-----------------------------------------------| | SRID=4326;POINT(-122.35 37.55) | | SRID=4326;LINESTRING(-124.2 42,-120.01 41.99) | +-----------------------------------------------+alter session set GEOGRAPHY_OUTPUT_FORMAT='EWKB';select g from geospatial_table order by id; +--------------------------------------------------------------------------------------------+ | G | |--------------------------------------------------------------------------------------------| | 0101000020E61000006666666666965EC06666666666C64240 | | 0102000020E610000002000000CDCCCCCCCC0C5FC00000000000004540713D0AD7A3005EC01F85EB51B8FE4440 | +--------------------------------------------------------------------------------------------+
Verwenden von Geodaten in Snowflake¶
In den folgenden Abschnitten werden die Standardformate und Objekttypen beschrieben, die beim Lesen und Schreiben von Geodaten verwendet werden können.
Erläuterungen zu den Auswirkungen verschiedener SRIDs mit GEOMETRY
Ausführen von DML.Operationen auf GEOGRAPHY/GEOMETRY-Spalten
Erläuterungen zu den Auswirkungen verschiedener SRIDs mit GEOMETRY¶
In einer GEOMETRY-Spalte können Sie Objekte einfügen, die unterschiedliche SRIDs haben. Wenn die Spalte mehr als eine SRID enthält, kommen einige wichtige Leistungsoptimierungen nicht zur Anwendung. Dies kann zur Verlangsamung von Abfragen führen, insbesondere bei der Verwendung von geografischen/räumlichen Prädikaten in Verknüpfungen (Join).
Ausführen von DML.Operationen auf GEOGRAPHY/GEOMETRY-Spalten¶
Wenn eine GEOGRAPHY/GEOMETRY-Spalte das Ziel einer DML-Operation (INSERT, COPY, UPDATE, MERGE oder CREATE TABLE AS …) ist, kann der Quellenausdruck der Spalte folgende Datentypen aufweisen:
GEOGRAPHY/GEOMETRY: Ein Ausdruck vom Typ GEOGRAPHY oder GEOMETRY ist normalerweise das Ergebnis einer Analysefunktion (Parsing), einer Konstruktorfunktion oder einer vorhandenen GEOGRAPHY/GEOMETRY-Spalte. Eine vollständige Liste der unterstützten Funktionen und Funktionskategorien finden Sie unter Geodatenfunktionen.
VARCHAR: Wird als WKT, WKB, EWKT, EWKB (im Hex-Format) oder als GeoJSON-formatierte Zeichenfolge interpretiert (siehe TO_GEOGRAPHY(VARCHAR)).
BINARY: Wird als WKB Binary interpretiert (siehe TO_GEOGRAPHY(BINARY)) und
VARIANT: Wird als GeoJSON-Objekt interpretiert (siehe TO_GEOGRAPHY(VARIANT)) und TO_GEOMETRY(VARIANT).
Laden von Geodaten aus Stagingbereichen¶
Daten aus CSV- oder JSON/AVRO-Dateien in einem Stagingbereich können direkt (d. h. ohne COPY-Transformationen) in eine GEOGRAPHY-Spalte geladen werden.
CSV: Zeichenfolgenwerte aus der entsprechenden CSV-Spalte werden als GeoJSON, WKT, EWKT, WKB oder EWKB analysiert (siehe TO_GEOGRAPHY(VARCHAR)).
JSON/AVRO: Die JSON-Werte in der Datei werden als GeoJSON interpretiert (siehe TO_GEOGRAPHY(VARIANT)).
Siehe auch Hinweis zur Verwendung von GeoJSON mit GEOGRAPHY-Werten.
Das Laden von Daten aus anderen Dateiformaten (Parquet, ORC usw.) ist über eine COPY-Transformation möglich.
Verwenden von Geodaten in Java-UDFs¶
In Java-UDFs kann der Datentyp GEOGRAPHY als Argument und als Rückgabewert verwendet werden. Weitere Informationen dazu finden Sie unter Zuordnung von SQL-Java-Datentypen für Parameter und Rückgabetypen und Übergeben eines GEOGRAPHY-Werts an eine Inline-Java-UDF.
Verwenden von Geodaten in JavaScript-UDFs¶
In JavaScript-UDFs kann der Datentyp GEOGRAPHY als Argument und als Rückgabewert verwendet werden.
Wenn eine JavaScript-UDF ein Argument vom Typ GEOGRAPHY hat, wird dieses Argument im UDF-Body als JSON-Objekt im GeoJSON-Format angezeigt.
Wenn eine JavaScript-UDF den Datentyp GEOGRAPHY zurückgibt, wird erwartet, dass der UDF-Body ein JSON-Objekt im GeoJSON-Format zurückgibt.
Beispielsweise entsprechen die beiden folgenden JavaScript-UDFs in etwa den integrierten Funktionen ST_X und ST_MAKEPOINT:
create or replace function my_st_x(G geography) returns real
language javascript
as
$$
if (G["type"] != "Point")
{
throw "Not a point"
}
return G["coordinates"][0]
$$;
create or replace function my_st_makepoint(LNG real, LAT real) returns geography
language javascript
as
$$
g = {}
g["type"] = "Point"
g["coordinates"] = [ LNG, LAT ]
return g
$$;
Auswählen des passenden Geodatentyps (GEOGRAPHY oder GEOMETRY)¶
In den nächsten Abschnitten werden die Unterschiede zwischen den Datentypen GEOGRAPHY und GEOMETRY erläutert:
Erläuterungen zu den Unterschieden zwischen GEOGRAPHY und GEOMETRY
Beispiele zum Vergleich der Datentypen GEOGRAPHY und GEOMETRY
Erläuterungen zu den Unterschieden bei der Validierung der Eingabedaten
Erläuterungen zu den Unterschieden zwischen GEOGRAPHY und GEOMETRY¶
Beide Datentypen GEOGRAPHY und GEOMETRY definieren geografische Merkmale, verwenden dabei aber unterschiedliche Modelle. In der folgenden Tabelle sind die Unterschiede zusammengefasst.
GEOGRAPHY-Datentyp |
GEOMETRY-Datentyp |
|---|---|
|
|
Beispiele zum Vergleich der Datentypen GEOGRAPHY und GEOMETRY¶
In den folgenden Beispielen wird die Ausgabe der Geodatenfunktionen bei Verwendung der Datentypen GEOGRAPHY und GEOMETRY als Eingabetypen verglichen.
Beispiel 1: Abfragen der Entfernung zwischen Berlin und San Francisco¶
Die folgende Tabelle vergleicht die Ausgabe von ST_DISTANCE für GEOGRAPHY-Typen und GEOMETRY-Typen:
ST_DISTANCE mit . GEOGRAPHY-Eingabe |
ST_DISTANCE mit . GEOMETRY-Eingabe |
|---|---|
SELECT ST_DISTANCE(
ST_POINT(13.4814, 52.5015),
ST_POINT(-121.8212, 36.8252))
AS distance_in_meters;
+--------------------+
| DISTANCE_IN_METERS |
|--------------------|
| 9182410.99227821 |
+--------------------+
|
SELECT ST_DISTANCE(
ST_GEOM_POINT(13.4814, 52.5015),
ST_GEOM_POINT(-121.8212, 36.8252))
AS distance_in_degrees;
+---------------------+
| DISTANCE_IN_DEGREES |
|---------------------|
| 136.207708844 |
+---------------------+
|
Wie im obigen Beispiel gezeigt:
Bei GEOGRAPHY-Eingabewerten sind die Eingabekoordinaten in Grad und der Ausgabewert ist in Meter angegeben. (Das Ergebnis ist 9.182 km.)
Bei GEOMETRY-Eingabewerten sind die Eingabekoordinaten und der Ausgabewert ist in Grad angegeben. (Das Ergebnis ist 136,208 Grad.)
Beispiel 2: Abfragen der Fläche von Deutschland¶
Die folgende Tabelle vergleicht die Ausgabe von ST_AREA für GEOGRAPHY-Typen und GEOMETRY-Typen:
ST_AREA mit . GEOGRAPHY-Eingabe |
ST_AREA mit . GEOMETRY-Eingabe |
|---|---|
SELECT ST_AREA(border) AS area_in_sq_meters
FROM world_countries
WHERE name = 'Germany';
+-------------------+
| AREA_IN_SQ_METERS |
|-------------------|
| 356379183635.591 |
+-------------------+
|
SELECT ST_AREA(border) as area_in_sq_degrees
FROM world_countries_geom
WHERE name = 'Germany';
+--------------------+
| AREA_IN_SQ_DEGREES |
|--------------------|
| 45.930026848 |
+--------------------+
|
Wie im obigen Beispiel gezeigt:
Bei GEOGRAPHY-Eingabewerten sind die Eingabekoordinaten in Grad und der Ausgabewert ist in Quadratmeter angegeben. (Das Ergebnis ist 356.379 km^2.)
Bei GEOMETRY-Eingabewerten sind die Eingabekoordinaten in Grad und der Ausgabewert ist in Quadratgrad angegeben. (Das Ergebnis ist 45,930 Quadratgrad.)
Beispiel 3: Abfrage der Namen von Ländern, die auf der Linie Berlin - San Francisco liegen¶
Die folgende Tabelle vergleicht die Ausgabe von ST_INTERSECTS für GEOGRAPHY-Typen und GEOMETRY-Typen:
ST_INTERSECTS mit . GEOGRAPHY-Eingabe |
ST_INTERSECTS mit . GEOMETRY-Eingabe |
|---|---|
SELECT name FROM world_countries WHERE
ST_INTERSECTS(border,
TO_GEOGRAPHY(
'LINESTRING(13.4814 52.5015, -121.8212 36.8252)'
));
+--------------------------+
| NAME |
|--------------------------|
| Germany |
| Denmark |
| Iceland |
| Greenland |
| Canada |
| United States of America |
+--------------------------+
|
SELECT name FROM world_countries_geom WHERE
ST_INTERSECTS(border,
TO_GEOMETRY(
'LINESTRING(13.4814 52.5015, -121.8212 36.8252)'
));
+--------------------------+
| NAME |
|--------------------------|
| Germany |
| Belgium |
| Netherlands |
| United Kingdom |
| United States of America |
+--------------------------+
|
|
|
Erläuterungen zu den Unterschieden bei der Validierung der Eingabedaten¶
Um für eine Eingabeform ein entsprechendes GEOMETRY- oder GEOGRAPHY-Objekt zu erstellen, müssen Sie eine Form verwenden, die gemäß den OGC-Regeln für einfache Merkmale wohlgeformt und gültig ist. In den nächsten Abschnitten wird erläutert, wie sich die Gültigkeit der Eingabedaten zwischen GEOMETRY und GEOGRAPHY unterscheidet.
Eine Form kann für GEOGRAPHY gültig, aber für GEOMETRY ungültig sein¶
Eine gegebene Form kann ein gültiges GEOGRAPHY-Objekt sein, aber ein ungültiges GEOMETRY-Objekt (und umgekehrt).
So sind beispielsweise sich selbst schneidende Polygone nach den OGC-Regeln nicht zulässig. Eine gegebene Menge von Punkten kann Kanten definieren, die sich im kartesischen Koordinatensystem schneiden, aber nicht auf einer Kugel. Betrachten Sie das folgende Beispiel:
POLYGON((0 50, 25 50, 50 50, 0 50))
Im kartesischen System wird dieses Polygon zu einer Linie reduziert und ist daher ungültig.
Auf einer Kugel hingegen schneidet sich das gleiche Polygon nicht selbst und ist gültig:
Konvertierungs- und Konstruktorfunktionen verwenden Validierung unterschiedlich¶
Wenn die Eingabedaten ungültig sind, erfolgt die Validierung der GEOMETRY/GEOGRAPHY-Funktionen auf unterschiedliche Weise:
Die Funktionen zur Konstruktion und Konvertierung in GEOGRAPHY-Objekte (z. B. TO_GEOGRAPHY) könnten versuchen, die Form zu reparieren, um Probleme wie nicht geschlossene Schleifen, Spitzen, Schnitte und sich selbst schneidende Schleifen in Polygonen zu beseitigen.
Gelingt es der Funktion, die Form zu reparieren, gibt sie ein GEOGRAPHY-Objekt zurück.
Die Funktionen zum Konstruieren und Konvertieren in GEOMETRY-Objekte (z. B. TO_GEOMETRY) bieten keine Unterstützung für die Reparatur von Formen.
Konvertierung zwischen GEOGRAPHY und GEOMETRY¶
Snowflake bietet keine Unterstützung für die Umwandlung von GEOGRAPHY in GEOMETRY (und umgekehrt). Snowflake unterstützt auch keine Transformation von Objekten, die unterschiedliche räumliche Bezugssysteme (SRS) verwenden.
Wenn Sie ein GEOGRAPHY-Objekt in ein GEOMETRY-Objekt (oder von GEOMETRY in GEOGRAPHY) umwandeln müssen, können Sie GeoJSON als Zwischenformat verwenden.
Im folgenden Beispiel wird das GEOGRAPHY-Objekt geography_expression in ein GEOMETRY-Objekt mit SRID 0 umgewandelt:
SELECT TO_GEOMETRY(ST_ASGEOJSON(geography_expression));
Wenn Sie die SRID des GEOMETRY-Objekts festlegen müssen, rufen Sie die Funktion ST_SETSRID auf. Beispiel für die Umwandlung des GEOGRAPHY-Objekts geography_expression in ein GEOMETRY-Objekt mit SRID 4326:
SELECT ST_SETSRID(TO_GEOMETRY(ST_ASGEOJSON(geography_expression)), 4326);