Datentypen für Geodaten

Snowflake bietet native Unterstützung von räumlichen Merkmalen wie Punkten, Linien und Polygonen auf der Erdoberfläche.

Tipp

Sie können den Suchoptimierungsdienst verwenden, um die Leistung von Abfragen zu verbessern. Weitere Details dazu finden Sie unter Suchoptimierungsdienst.

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. Snowflake speichert GEOGRAPHY-Koordinaten mit 14 Dezimalstellen. Wenn die Daten Dezimalstellen enthalten, die dieses Limit überschreiten, werden die Koordinaten gerundet, um die Einhaltung der angegebenen Längenbeschränkung sicherzustellen.

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

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 speichert GEOMETRY-Koordinaten mit 14 Dezimalstellen. Wenn die Daten Dezimalstellen enthalten, die dieses Limit überschreiten, werden die Koordinaten gerundet, um die Einhaltung der angegebenen Längenbeschränkung sicherzustellen.

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:

Möglicherweise sind auch folgende Referenzen hilfreich:

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' oder GEOMETRY_OUTPUT_FORMAT='GeoJSON':

    • ResultSetMetaData.getColumnType(i) gibt java.sql.Types.VARCHAR zurück.

    • ResultSetMetaData.getColumnClassName(i) gibt "java.lang.String" zurück.

  • Wenn GEOGRAPHY_OUTPUT_FORMAT='WKT' oder 'EWKT', oder wenn GEOMETRY_OUTPUT_FORMAT='WKT' oder 'EWKT':

    • ResultSetMetaData.getColumnType(i) gibt java.sql.Types.VARCHAR zurück.

    • ResultSetMetaData.getColumnClassName(i) gibt "java.lang.String" zurück.

  • Wenn GEOGRAPHY_OUTPUT_FORMAT='WKB' oder 'EWKB', oder wenn GEOMETRY_OUTPUT_FORMAT='WKB' oder 'EWKB':

    • ResultSetMetaData.getColumnType(i) gibt java.sql.Types.BINARY zurü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:

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)');
Copy
alter session set GEOGRAPHY_OUTPUT_FORMAT='GeoJSON';
Copy
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" |
| }                      |
+------------------------+
Copy
alter session set GEOGRAPHY_OUTPUT_FORMAT='WKT';
Copy
select g
    from geospatial_table
    order by id;
+-------------------------------------+
| G                                   |
|-------------------------------------|
| POINT(-122.35 37.55)                |
| LINESTRING(-124.2 42,-120.01 41.99) |
+-------------------------------------+
Copy
alter session set GEOGRAPHY_OUTPUT_FORMAT='WKB';
Copy
select g
    from geospatial_table
    order by id;
+------------------------------------------------------------------------------------+
| G                                                                                  |
|------------------------------------------------------------------------------------|
| 01010000006666666666965EC06666666666C64240                                         |
| 010200000002000000CDCCCCCCCC0C5FC00000000000004540713D0AD7A3005EC01F85EB51B8FE4440 |
+------------------------------------------------------------------------------------+
Copy
alter session set GEOGRAPHY_OUTPUT_FORMAT='EWKT';
Copy
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) |
+-----------------------------------------------+
Copy
alter session set GEOGRAPHY_OUTPUT_FORMAT='EWKB';
Copy
select g
    from geospatial_table
    order by id;
+--------------------------------------------------------------------------------------------+
| G                                                                                          |
|--------------------------------------------------------------------------------------------|
| 0101000020E61000006666666666965EC06666666666C64240                                         |
| 0102000020E610000002000000CDCCCCCCCC0C5FC00000000000004540713D0AD7A3005EC01F85EB51B8FE4440 |
+--------------------------------------------------------------------------------------------+
Copy

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

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).

Ändern des räumlichen Bezugssystems (SRS) und der SRID eines GEOMETRY-Objekts

Um das SRS und die SRID eines bestehenden GEOMETRY-Objekts zu ändern, rufen Sie die Funktion ST_TRANSFORM auf und übergeben die neue SRID. Die Funktion liefert ein neues GEOMETRY-Objekt mit der neuen SRID und den Koordinaten, die für die Verwendung mit dem SRS umgewandelt wurden. Um beispielsweise ein GEOMETRY-Objekt für geometry_expression zurückzugeben, das das SRS für SRID 32633 verwendet, führen Sie die folgende Anweisung aus:

SELECT ST_TRANSFORM(geometry_expression, 32633);
Copy

Wenn die Original-SRID im bestehenden GEOMETRY-Objekt nicht korrekt eingestellt ist, geben Sie die Original-SRID als zusätzliches Argument an. Wenn geometry_expression beispielsweise ein GEOMETRY-Objekt ist, das SRID 4326 verwendet, und Sie dieses in SRID 28992 umwandeln möchten, führen Sie die folgende Anweisung aus:

SELECT ST_TRANSFORM(geometry_expression, 4326, 28992);
Copy

Beachten Sie, dass Sie bei einem GEOMETRY-Objekt, das die richtigen Koordinaten für ein SRS verwendet, aber die falsche SRID hat, die SRID korrigieren können, indem Sie die Funktion ST_SETSRID aufrufen. Die folgende Anweisung setzt zum Beispiel die SRID für geometry_expression auf 4326, während die Koordinaten unverändert bleiben:

SELECT ST_SETSRID(geometry_expression, 4326);
Copy

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

  • TO_GEOMETRY(BINARY)).

  • 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.

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 Datentypen zwischen SQL und Java und Übergeben eines GEOGRAPHY-Werts an eine Inline-Java-UDF.

Verwenden von Geodaten in JavaScript-UDFs

In JavaScript-UDFs können die Datentypen GEOGRAPHY und GEOMETRY als Argument und als Rückgabewert verwendet werden.

Wenn eine JavaScript-UDF ein Argument vom Typ GEOGRAPHY oder GEOMETRY hat, wird dieses Argument im UDF-Body als JSON-Objekt im GeoJSON-Format angezeigt.

Wenn eine JavaScript-UDF den Datentyp GEOGRAPHY oder GEOMETRY 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
$$;
Copy

Verwenden von Geodaten in Python-UDFs

In Python-UDFs können die Datentypen GEOGRAPHY und GEOMETRY als Argument und als Rückgabewert verwendet werden.

Wenn eine Python-UDF ein Argument vom Typ GEOGRAPHY oder GEOMETRY hat, wird dieses Argument als GeoJSON-Objekt repräsentiert, das innerhalb des UDF-Body in ein Python-dict-Objekt umgewandelt wird.

Wenn eine Python-UDF den Datentyp GEOGRAPHY oder GEOMETRY zurückgibt, wird vom UDF-Body erwartet, dass er ein Python-dict-Objekt zurückgibt, das der Struktur von GeoJSON entspricht.

Im folgenden Beispiel gibt die Python-UDF die Anzahl unterschiedlicher Geometrien zurück, die einen zusammengesetzten GEOGRAPHY-Typ bilden:

CREATE OR REPLACE FUNCTION py_numgeographys(geo GEOGRAPHY)
RETURNS INTEGER
LANGUAGE PYTHON
RUNTIME_VERSION = 3.8
PACKAGES = ('shapely')
HANDLER = 'udf'
AS $$
from shapely.geometry import shape, mapping
def udf(geo):
    if geo['type'] not in ('MultiPoint', 'MultiLineString', 'MultiPolygon', 'GeometryCollection'):
        raise ValueError('Must be a composite geometry type')
    else:
        g1 = shape(geo)
        return len(g1.geoms)
$$;
Copy

In Snowflake Labs finden Sie weitere Beispiele für Python-UDFs. Einige dieser UDFs ermöglichen komplexe räumliche Manipulationen oder vereinfachen die Datenerfassung. Beispielsweise ermöglicht diese UDF das Lesen von Formaten, die nicht nativ unterstützt werden, wie Shapefiles (.SHP), TAB, KML, GPKG und andere.

Bemerkung

Die Codebeispiele in Snowflake Labs sind ausschließlich für Referenz- und Schulungszwecke gedacht. Diese Codebeispiele sind nicht durch Service Level Agreements abgedeckt.

Verwendung von GEOGRAPHY-Objekten mit H3

H3 ist ein hierarchischer geographischer Index, der die Welt in hexagonale Zellen eines diskreten globalen Gittersystems unterteilt.

Snowflake bietet SQL-Funktionen, mit denen Sie H3 mit GEOGRAPHY-Objekten verwenden können. Sie können diese Funktionen für Folgendes verwenden:

  • Abrufen der ID der H3-Zelle (Index) für ein GEOGRAPHY-Objekt, das einen Punkt repräsentiert (und umgekehrt).

  • Abrufen der IDs der minimalen Menge von H3-Zellen, die ein GEOGRAPHY-Objekt abdecken.

  • Abrufen der IDs der H3-Zellen, die Zentroide innerhalb eines GEOGRAPHY-Objekts haben, das ein Polygon repräsentiert.

  • Abrufen des GEOGRAPHY-Objekts, das die Begrenzung einer H3-Zelle repräsentiert.

  • Abrufen der übergeordneten und untergeordneten Zellen einer bestimmten H3-Zelle.

  • Abrufen von Längen- und Breitengrad des Zentroids einer H3-Zelle (und umgekehrt).

  • Abrufen der Auflösung einer H3-Zelle.

  • Abrufen der hexadezimalen Darstellung der ID einer H3-Zelle (und umgekehrt).

Die SQL-Funktionen für H3 sind unten aufgeführt:

Funktion

Beschreibung

H3_CELL_TO_BOUNDARY

Gibt das GEOGRAPHY-Objekt zurück, das die Begrenzung einer H3 -Zelle repräsentiert.

H3_CELL_TO_CHILDREN

Gibt ein ARRAY der INTEGER-IDs der untergeordneten Zellen einer H3-Zelle für eine gegebene Auflösung zurück.

H3_CELL_TO_CHILDREN_STRING

Gibt ein ARRAY mit VARCHAR-Werten zurück, die die hexadezimalen IDs der untergeordneten Zellen einer H3-Zelle für eine gegebene Auflösung enthalten.

H3_CELL_TO_PARENT

Gibt die ID der übergeordneten Zelle einer H3-Zelle für eine gegebene Auflösung zurück.

H3_CELL_TO_POINT

Gibt das GEOGRAPHY-Objekt zurück, das den Punkt repräsentiert, der der Zentroid einer H3-Zelle ist.

H3_COVERAGE

Gibt ein ARRAY von IDs (als INTEGER-Werte) zurück, die die minimale Menge von H3-Zellen identifiziert, die eine Form (angegeben durch ein GEOGRAPHY-Objekt) vollständig abdecken.

H3_COVERAGE_STRINGS

Gibt ein ARRAY von hexadezimalen IDs (als VARCHAR-Werte) zurück, die die minimale Menge von H3-Zellen identifiziert, die ein Polygon (spezifiziert durch ein GEOGRAPHY-Objekt) vollständig abdecken.

H3_GET_RESOLUTION

Gibt die Auflösung einer H3-Zelle zurück.

H3_GRID_DISTANCE

Gibt den Gitterabstand zwischen zwei H3-Zellen zurück.

H3_GRID_DISK

Gibt ein ARRAY der IDs von H3-Zellen zurück, die sich innerhalb eines bestimmten Gitterabstands von einer bestimmten H3-Zelle befinden.

H3_GRID_PATH

Gibt ein ARRAY der IDs von H3-Zellen zurück, die die Linie zwischen zwei H3-Zellen bilden.

H3_INT_TO_STRING

Konvertiert den INTEGER-Wert der ID einer H3-Zelle in das hexadezimale Format.

H3_LATLNG_TO_CELL

Gibt den INTEGER-Wert der ID einer H3-Zelle für einen bestimmten Längen- und Breitengrad und eine bestimmte Auflösung zurück.

H3_LATLNG_TO_CELL_STRING

Gibt die ID einer H3-Zelle im hexadezimalen Format (als VARCHAR) für einen bestimmten Längen- und Breitengrad und eine bestimmte Auflösung zurück.

H3_POINT_TO_CELL

Gibt den INTEGER-Wert der ID einer H3-Zelle für einen Punkt (durch ein GEOGRAPHY-Objekt angegeben) für eine bestimmte Auflösung zurück.

H3_POINT_TO_CELL_STRING

Gibt den hexadezimalen Wert der ID einer H3-Zelle für einen Punkt (durch ein GEOGRAPHY-Objekt angegeben) für eine bestimmte Auflösung zurück.

H3_POLYGON_TO_CELLS

Gibt ein ARRAY von INTEGER-Werten der IDs von H3-Zellen zurück, deren Zentroide in einem Polygon (angegeben durch ein GEOGRAPHY-Objekt) enthalten sind.

H3_POLYGON_TO_CELLS_STRINGS

Gibt ein ARRAY von VARCHAR-Werten der IDs von H3-Zellen zurück, deren Zentroide in einem Polygon (angegeben durch ein GEOGRAPHY-Objekt) enthalten sind.

H3_STRING_TO_INT

Konvertiert die ID einer H3-Zelle im hexadezimalen Format in einen INTEGER-Wert.

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

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

  • Definiert Merkmale auf einer Kugel.

  • Nur das WGS84-Koordinatensystem. SRID ist immer 4326.

  • Die Koordinaten werden in Grad für Breitengrad (-90 bis 90) und Längengrad (-180 bis 180) angegeben.

  • Die Ergebnisse von Messoperationen (ST_LENGTH, ST_AREA usw.) werden in Meter angegeben.

  • Segmente werden als geodätische Bögen auf der Erdoberfläche interpretiert.

  • Definiert Merkmale auf einer Ebene.

  • Unterstützt beliebige Koordinatensysteme.

  • Die Maßeinheit der Koordinatenwerte wird durch das räumliche Bezugssystem definiert.

  • Die Ergebnisse von Messoperationen (ST_LENGTH, ST_AREA usw.) haben die gleiche Maßeinheit wie die Koordinaten. Wenn beispielsweise die Eingabekoordinaten in Grad angegeben sind, werden die Ergebnisse in Grad ausgegeben.

  • Segmente werden als Geraden in der Ebene interpretiert.

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;
Copy
+--------------------+
| DISTANCE_IN_METERS |
|--------------------|
|   9182410.99227821 |
+--------------------+
Copy
SELECT ST_DISTANCE(
         ST_GEOM_POINT(13.4814, 52.5015),
         ST_GEOM_POINT(-121.8212, 36.8252))
       AS distance_in_degrees;
Copy
+---------------------+
| DISTANCE_IN_DEGREES |
|---------------------|
|       136.207708844 |
+---------------------+
Copy

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';
Copy
+-------------------+
| AREA_IN_SQ_METERS |
|-------------------|
|  356379183635.591 |
+-------------------+
Copy
SELECT ST_AREA(border) as area_in_sq_degrees
  FROM world_countries_geom
  WHERE name = 'Germany';
Copy
+--------------------+
| AREA_IN_SQ_DEGREES |
|--------------------|
|       45.930026848 |
+--------------------+
Copy

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)'
    ));
Copy
+--------------------------+
| NAME                     |
|--------------------------|
| Germany                  |
| Denmark                  |
| Iceland                  |
| Greenland                |
| Canada                   |
| United States of America |
+--------------------------+
Copy
SELECT name FROM world_countries_geom WHERE
  ST_INTERSECTS(border,
    TO_GEOMETRY(
      'LINESTRING(13.4814 52.5015, -121.8212 36.8252)'
    ));
Copy
+--------------------------+
| NAME                     |
|--------------------------|
| Germany                  |
| Belgium                  |
| Netherlands              |
| United Kingdom           |
| United States of America |
+--------------------------+
Copy
Länder, die sich bei Verwendung von GEOGRAPHY schneiden Länder, die sich bei Verwendung von GEOMETRY schneiden

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))
Copy

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:

POLYGON((0 50, 25 50, 50 50, 0 50)) ungültige GEOMETRY, aber gültige GEOGRAPHY

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 unterstützt das Konvertieren von einem GEOGRAPHY-Objekt in ein GEOMETRY-Objekt (und umgekehrt). Snowflake unterstützt auch die Transformation von Objekten, die unterschiedliche räumliche Bezugssysteme (SRS) verwenden.

Im folgenden Beispiel wird ein GEOGRAPHY-Objekt, das einen Punkt repräsentiert, in ein GEOMETRY-Objekt mit der SRID 0 umgewandelt:

SELECT TO_GEOMETRY(TO_GEOGRAPHY('POINT(-122.306100 37.554162)'));
Copy

Um die SRID des neuen GEOMETRY-Objekts festzulegen, übergeben Sie die SRID als Argument an die Konstruktorfunktion. Beispiel:

SELECT TO_GEOMETRY(TO_GEOGRAPHY('POINT(-122.306100 37.554162)', 4326));
Copy

Wenn Sie die SRID eines vorhandenen GEOMETRY-Objekts festlegen müssen, rufen Sie die Funktion Ändern des räumlichen Bezugssystems (SRS) und der SRID eines GEOMETRY-Objekts auf.

Festlegen der Verarbeitung von ungültigen Geodaten

Wenn Sie eine Konvertierungsfunktion für Geodaten verwenden, um Daten aus einem unterstützten Eingabeformat in ein GEOGRAPHY- oder GEOMETRY-Objekt zu konvertieren, versucht die Funktion standardmäßig folgendes zu tun:

  1. Die Funktion versucht, die Form in den Eingabedaten zu validieren.

  2. Die Funktion ermittelt, ob die Form nach dem Standard Simple Feature Access / Common Architecture des Open Geospatial Consortium gültig ist.

  3. Wenn die Form ungültig ist, versucht die Funktion, die Daten zu reparieren (z. B. Polygone durch Schließen der Ringe reparieren).

  4. Wenn die Form nach der Reparatur immer noch ungültig ist, meldet die Funktion einen Fehler und erstellt kein GEOGRAPHY- oder GEOMETRY-Objekt. (Bei TRY_*-Funktionen geben die Funktionen NULL zurück, anstatt einen Fehler zu melden.)

Mit diesem Feature erhalten Sie mehr Kontrolle über den Validierungs- und Reparaturprozess. Sie können Folgendes tun:

  • Zulassen, dass diese Konvertierungsfunktionen GEOGRAPHY- und GEOMETRY-Objekte für ungültige geografische Formen erstellen.

  • Feststellen, ob die Form für ein GEOGRAPHY- oder GEOMETRY-Objekt ungültig ist.

Erläuterungen zu den Auswirkungen ungültiger Formen auf Geodatenfunktionen

Verschiedene Geodatenfunktionen haben unterschiedliche Auswirkungen, wenn Sie ein GEOGRAPHY- oder GEOMETRY-Objekt für eine ungültige Form übergeben.

Auswirkungen auf GEOMETRY-Objekte

GEOMETRY-Objekte:

Auswirkungen auf GEOGRAPHY-Objekte

GEOGRAPHY-Objekte:

Verwenden von ungültigen Formen

In den nächsten Abschnitten wird erläutert, wie Sie zulassen, dass Funktionen ungültige Formen erstellen, und wie Sie feststellen, ob ein GEOGRAPHY- oder GEOMETRY-Objekt eine ungültige oder reparierte Form repräsentiert.

Zulassen, dass Konvertierungsfunktionen ungültige Formen erstellen

Um zuzulassen, dass die folgenden Konvertierungsfunktionen ungültige Geodatenobjekte erstellen, übergeben Sie TRUE als zweites Argument (allowInvalid):

TO_GEOGRAPHY( <input> [, <allowInvalid> ] )
Copy
ST_GEOGFROMWKB( <input> [, <allowInvalid> ] )
Copy
ST_GEOGFROMWKT( <input> [, <allowInvalid> ] )
Copy
TO_GEOMETRY( <input> [, <allowInvalid> ] )
Copy
ST_GEOMFROMWKB( <input> [, <allowInvalid> ] )
Copy
ST_GEOMFROMWKT( <input> [, <allowInvalid> ] )
Copy

Standardmäßig hat das allowInvalid-Argument den Wert FALSE.

Wenn Sie TRUE für das Argument allowInvalid übergeben, gibt die Konvertierungsfunktion ein GEOGRAPHY- oder GEOMETRY-Objekt zurück, selbst wenn die Eingabeform ungültig ist und nicht erfolgreich repariert werden kann.

Die folgende Eingabeform ist beispielsweise ein LineString, das aus denselben zwei Punkten besteht. Das Übergeben von TRUE für das Argument allowInvalid gibt ein GEOMETRY-Objekt zurück, das eine ungültige Form repräsentiert:

SELECT TO_GEOMETRY('LINESTRING(100 102,100 102)', TRUE);
Copy

Feststellen, ob eine Form ungültig ist

Um festzustellen, ob ein GEOGRAPHY- oder GEOMETRY-Objekt ungültig ist, rufen Sie die Funktion ST_ISVALID auf.

Das folgende Beispiel prüft, ob ein Objekt gültig ist:

SELECT TO_GEOMETRY('LINESTRING(100 102,100 102)', TRUE) AS g, ST_ISVALID(g);
Copy