Types de données géospatiales

Snowflake offre un support natif pour les fonctionnalités géospatiales telles que les points, les lignes et les polygones sur la surface de la Terre.

Astuce

Vous pouvez utiliser le service d’optimisation de recherche pour améliorer les performances des requêtes. Pour plus de détails, voir Service d’optimisation de la recherche.

Dans ce chapitre :

Types de données

Snowflake fournit les types de données suivants pour les données géospatiales :

  • Le type de données GEOGRAPHY, qui modélise la Terre comme si elle était une sphère parfaite.

  • Le type de données GEOMETRY, qui représente les caractéristiques dans un système de coordonnées planes (euclidien, cartésien).

Type de données GEOGRAPHY

Le type de données GEOGRAPHY suit la norme WGS 84 (ID de référence spatiale 4326 ; pour plus de détails, voir https://spatialreference.org/ref/epsg/wgs-84/).

Les points sur la Terre sont représentés par des degrés de longitude (de -180 degrés à +180 degrés) et de latitude (-90 à +90 degrés). Snowflake utilise 14 décimales pour stocker les coordonnées GEOGRAPHY. Lorsque les données comportent des décimales dépassant cette limite, les coordonnées sont arrondies afin de respecter la contrainte de longueur spécifiée.

L’altitude n’est actuellement pas prise en charge.

Les segments de ligne sont interprétés comme des arcs géodésiques sur la surface de la Terre.

Snowflake fournit également des fonctions géospatiales qui fonctionnent sur le type de données GEOGRAPHY.

Si vous disposez de données géospatiales (par exemple, des données de longitude et de latitude, WKT, WKB, GeoJSON, etc.), vous devez convertir et stocker ces données dans des colonnes GEOGRAPHY, plutôt que de conserver les données dans leur format d’origine dans des colonnes VARCHAR, VARIANT ou NUMBER. Le stockage de vos données dans des colonnes GEOGRAPHY peut améliorer considérablement les performances des requêtes qui utilisent la fonctionnalité géospatiale.

Type de données GEOMETRY

Le type de données GEOMETRY représente les caractéristiques dans un système de coordonnées planes (euclidien, cartésien).

Les coordonnées sont représentées par des paires de nombres réels (x, y). Actuellement, seules les coordonnées 2D sont prises en charge.

Les unités de X et Y sont déterminées par le `système de référence spatiale (SRS)`__ associé à l’objet GEOMETRY. Le système de référence spatiale est identifié par `l'identificateur de système de référence spatiale (SRID)`__. À moins que le SRID ne soit fourni lors de la création de l’objet GEOMETRY ou en appelant ST_SETSRID, le SRID est 0.

Snowflake utilise 14 décimales pour stocker les coordonnées GEOMETRY. Lorsque les données comportent des décimales dépassant cette limite, les coordonnées sont arrondies afin de respecter la contrainte de longueur spécifiée.

Snowflake fournit un ensemble de fonctions géospatiales qui opèrent sur le type de données GEOMETRY. Pour ces fonctions :

  • Toutes les fonctions supposent des coordonnées planes, même si la géométrie utilise un SRS non plan.

  • Les fonctions de mesure (par exemple, ST_LENGTH) utilisent les mêmes unités que le système de coordonnées.

  • Pour les fonctions qui acceptent plusieurs expressions GEOMETRY comme arguments (par exemple, ST_DISTANCE), les expressions d’entrée doivent être définies dans le même SRS.

Entrée et sortie géospatiales

Les sections suivantes traitent des formats standard et des types d’objets pris en charge lors de la lecture et de l’écriture de données géospatiales.

Formats d’entrée et de sortie standard pris en charge

Les types de données GEOGRAPHY et GEOMETRY prennent en charge les formats industriels standard suivants pour l’entrée et la sortie :

Vous pouvez également trouver les références suivantes utiles :

Tout écart par rapport à ces normes est indiqué explicitement dans la documentation de Snowflake.

Note sur le traitement GeoJSON des valeurs GEOGRAPHY

Les normes WKT et WKB spécifient uniquement un format ; la sémantique des objets WKT/WKB dépend du système de référence - par exemple, un plan ou une sphère.

La norme GeoJSON, en revanche, spécifie à la fois un format et sa sémantique : les points GeoJSON sont explicitement des coordonnées WGS 84 et les segments de ligne GeoJSON sont censés être des arêtes planes (lignes droites).

Contrairement à cela, le type de données GEOGRAPHY de Snowflake interprète tous les segments de ligne - y compris ceux entrés ou sortis au format GeoJSON - comme des arcs géodésiques. En substance, Snowflake traite GeoJSON comme du WKT au format JSON avec une sémantique sphérique.

Note sur le traitement EWKT et EWKB des valeurs GEOGRAPHY

EWKT et EWKB sont des formats non standard introduits par PostGIS. Ils améliorent les formats WKT et WKB en incluant un identificateur de système de référence spatiale (SRID), qui spécifie le système de référence de coordonnées à utiliser avec les données. Snowflake ne prend actuellement en charge que WGS84, qui correspond à SRID=4326.

Par défaut, Snowflake génère une erreur si une valeur d’entrée EWKB ou EWKT contient un SRID autre que 4326. Inversement, toutes les valeurs de sortie EWKB et EWKT ont un SRID = 4326.

Types d’objets géospatiaux pris en charge

Les types de données GEOGRAPHY et GEOMETRY peuvent stocker les types d’objets géospatiaux suivants :

  • Objets géospatiaux WKT / WKB / EWKT / EWKB / GeoJSON :

    • Point

    • MultiPoint

    • LineString

    • MultiLineString

    • Polygone

    • MultiPolygon

    • GeometryCollection

  • Ces objets géospatiaux spécifiques à GeoJSON :

    • Fonctionnalité

    • FeatureCollection

Spécification du format de sortie des jeux de résultats

Les paramètres de session GEOGRAPHY_OUTPUT_FORMAT et GEOMETRY_OUTPUT_FORMAT contrôlent le rendu des colonnes de type GEOGRAPHY et GEOMETRY dans les jeux de résultats (respectivement).

Les paramètres GEOGRAPHY_OUTPUT_FORMAT et GEOMETRY peuvent avoir l’une des valeurs suivantes :

Valeur du paramètre

Description

GeoJSON (par défaut)

Le résultat GEOGRAPHY / GEOMETRY est rendu sous la forme d’un OBJECT au format GeoJSON.

WKT

Le résultat GEOGRAPHY / GEOMETRY est rendu sous la forme d’un VARCHAR au format WKT.

WKB

Le résultat GEOGRAPHY / GEOMETRY est rendu sous la forme d’un BINARY au format WKB.

EWKT

Le résultat GEOGRAPHY / GEOMETRY est rendu sous la forme d’un VARCHAR au format EWKT.

EWKB

Le résultat GEOGRAPHY / GEOMETRY est rendu sous la forme d’un BINARY au format EWKB.

Pour EWKT et EWKB, le SRID est toujours 4326 dans la sortie. Consultez la note sur le traitement d” EWKT et d” EWKB.

Ce paramètre concerne tous les clients, y compris l” UI de Snowflake et le client de ligne de commande SnowSQL, ainsi que les pilotes et connecteurs JDBC, ODBC, node.js, python, etc.

Par exemple : le pilote JDBC renvoie les métadonnées suivantes pour une colonne de résultat de type GEOGRAPHY (colonne i dans cet exemple) :

  • If GEOGRAPHY_OUTPUT_FORMAT='GeoJSON' or GEOMETRY_OUTPUT_FORMAT='GeoJSON':

    • ResultSetMetaData.getColumnType(i) renvoie java.sql.Types.VARCHAR.

    • ResultSetMetaData.getColumnClassName(i) renvoie "java.lang.String".

  • Si GEOGRAPHY_OUTPUT_FORMAT='WKT' ou 'EWKT', ou si : GEOMETRY_OUTPUT_FORMAT='WKT' ou 'EWKT' :

    • ResultSetMetaData.getColumnType(i) renvoie java.sql.Types.VARCHAR.

    • ResultSetMetaData.getColumnClassName(i) renvoie "java.lang.String".

  • Si GEOGRAPHY_OUTPUT_FORMAT='WKB' ou 'EWKB', ou si GEOMETRY_OUTPUT_FORMAT='WKB' ou 'EWKB' :

    • ResultSetMetaData.getColumnType(i) renvoie java.sql.Types.BINARY.

    • ResultSetMetaData.getColumnClassName(i) renvoie "[B" (tableau d’octets).

Note

Les APIs pour récupérer les noms de type spécifiques à la base de données (getColumnTypeName dans JDBC et le descripteur SQL_DESC_TYPE_NAME dans ODBC) renvoient toujours GEOGRAPHY et GEOMETRY pour le nom de type, quelle que soit la valeur des paramètres GEOGRAPHY_OUTPUT_FORMAT et GEOMETRY_OUTPUT_FORMAT. Pour plus de détails, voir :

Exemples d’insertion et d’interrogation de données GEOGRAPHY

Le code ci-dessous montre des exemples d’entrée et de sortie pour le type de données GEOGRAPHY. Remarques :

  • Pour les coordonnées en WKT, EWKT et GeoJSON, la longitude apparaît avant la latitude (par exemple POINT(lon lat)).

  • Pour la sortie WKB et EWKB, il est supposé que le paramètre BINARY_OUTPUT_FORMAT est défini sur HEX (la valeur par défaut du paramètre).

L’exemple crée une table avec une colonne GEOGRAPHY, insère des données au format WKT et renvoie les données dans différents formats de sortie.

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

Utilisation de données géospatiales dans Snowflake

Les sections suivantes traitent des formats standard et des types d’objets pris en charge lors de la lecture et de l’écriture de données géospatiales.

Comprendre les effets de l’utilisation de différents SRIDs avec GEOMETRY

Dans une colonne GEOMETRY, vous pouvez insérer des objets qui ont des SRIDs différents. Si la colonne contient plus d’un SRID, certaines des optimisations importantes des performances ne sont pas appliquées. Cela peut entraîner des requêtes plus lentes, en particulier lors de la jonction sur un prédicat géospatial.

Changement du système de référence spatiale (SRS) et SRID d’un objet GEOMETRY

Pour modifier les SRS et SRID d’un objet GEOMETRY existant, appelez la fonction ST_TRANSFORM en lui transmettant le nouveau SRID. La fonction renvoie un nouvel objet GEOMETRY avec le nouveau SRID et les coordonnées converties pour utiliser le SRS. Par exemple, pour renvoyer un objet GEOMETRY pour geometry_expression qui utilise le SRS pour SRID 32633, exécutez l’instruction suivante :

SELECT ST_TRANSFORM(geometry_expression, 32633);
Copy

Si le SRID d’origine n’est pas défini correctement dans l’objet GEOMETRY existant, spécifiez le SRID d’origine en tant qu’argument supplémentaire. Par exemple, si geometry_expression est un objet GEOMETRY qui utilise le SRID 4326, et que vous voulez le transformer pour utiliser le SRID 28992, exécutez l’instruction suivante :

SELECT ST_TRANSFORM(geometry_expression, 4326, 28992);
Copy

Notez que si un objet GEOMETRY utilise les coordonnées correctes pour un SRS, mais a un SRID erroné, vous pouvez corriger le SRID en appelant la fonction ST_SETSRID. Par exemple, l’instruction suivante définit le SRID pour geometry_expression à 4326 tout en laissant les coordonnées inchangées :

SELECT ST_SETSRID(geometry_expression, 4326);
Copy

Exécution des opérations DML sur des colonnes GEOGRAPHY et GEOMETRY

Lorsqu’une colonne GEOGRAPHY ou GEOMETRY est la cible d’une opération DML (INSERT, COPY, UPDATE, MERGE ou CREATE TABLE AS…), l’expression source de la colonne peut être n’importe lequel des types suivants :

  • GEOGRAPHY ou GEOMETRY : une expression de type GEOGRAPHY ou GEOMETRY est généralement le résultat d’une fonction d’analyse, d’une fonction constructeur ou d’une colonne GEOGRAPHY ou GEOMETRY existante. Pour une liste complète des fonctions et catégories de fonctions prises en charge, voir Fonctions géospatiales.

  • VARCHAR : interprété comme une chaîne au format WKT, WKB (format hexadécimal), EWKT, EWKB (format hexadécimal), ou GeoJSON (voir TO_GEOGRAPHY(VARCHAR)).

  • BINARY : interprété comme un WKB binaire (voir TO_GEOGRAPHY(BINARY) et

  • TO_GEOMETRY(BINARY)).

  • VARIANT : interprété comme un objet GeoJSON (voir TO_GEOGRAPHY(VARIANT) et TO_GEOMETRY(VARIANT)).

Chargement des données géospatiales à partir de zones de préparation

Les données des fichiers CSV ou JSON / AVRO dans une zone de préparation peuvent être chargées directement (c’est-à-dire sans transformations de copie) dans une colonne GEOGRAPHY.

Le chargement de données à partir d’autres formats de fichiers (Parquet, ORC, etc.) est possible via une transformation COPY.

Utilisation de données géospatiales avec des UDFs Java

Les UDFs Java autorisent le type GEOGRAPHY comme argument et comme valeur de retour. Voir Mappages de type de données SQL-Java et Transmission d’une valeur GEOGRAPHY à une UDF Java en ligne pour plus de détails.

Utilisation des données géospatiales avec des UDFs JavaScript

Les UDFs JavaScript autorisent le type GEOGRAPHY ou GEOMETRY comme argument et comme valeur de retour.

Si une UDF JavaScript a un argument de type GEOGRAPHY ou GEOMETRY, cet argument sera visible en tant qu’objet JSON au format GeoJSON à l’intérieur du corps de l’UDF.

Si une UDF JavaScript renvoie GEOGRAPHY ou GEOMETRY, le corps de l’UDF devrait renvoyer un objet JSON au format GeoJSON.

Par exemple, ces deux UDFs JavaScript sont à peu près équivalents aux fonctions intégrées ST_X et 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

Utilisation des données géospatiales avec des UDFs Python

Les UDFs Python autorisent le type GEOGRAPHY et GEOMETRY comme argument et comme valeur de retour.

Si une UDF Python a un argument de type GEOGRAPHY ou GEOMETRY, cet argument sera représenté comme un objet GeoJSON, qui est converti en un objet Python dict à l’intérieur du corps de l’UDF.

Si une UDF Python renvoie GEOGRAPHY ou GEOMETRY, le corps de l’UDF est censé renvoyer un objet Python dict conforme à la structure de GeoJSON.

Par exemple, cette UDF Python renvoie le nombre de géométries distinctes qui constituent un type composite GEOGRAPHY :

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

Consultez Snowflake Labs pour plus d’exemples d’UDFs Python. Certains d’entre eux permettent des manipulations spatiales complexes ou simplifient l’ingestion de données. Par exemple, cette UDF permet de lire des formats qui ne sont pas pris en charge de manière native, tels que Shapefiles (.SHP), TAB, KML, GPKG, et d’autres.

Note

Les exemples de code de Snowflake Labs sont uniquement destinés à des fins de référence et pédagogiques. Ces échantillons de code ne sont couverts par aucun accord de niveau de service.

Utilisation d’objets GEOGRAPHY avec H3

H3 est un index géospatial hiérarchique qui divise le monde en cellules hexagonales dans un système de grille global discret.

Snowflake fournit des fonctions SQL qui vous permettent d’utiliser H3 avec des objets GEOGRAPHY. Vous pouvez utiliser ces fonctions pour :

  • Obtenir l’ID de la cellule H3 (index) pour un objet GEOGRAPHY qui représente un point (et vice versa).

  • Obtenir les IDs de l’ensemble minimal de cellules H3 qui couvrent un objet GEOGRAPHY.

  • Obtenir les IDs des cellules H3 qui ont des centroïdes dans un objet GEOGRAPHY qui représente un polygone.

  • Obtenir l’objet GEOGRAPHY qui représente la limite d’une cellule H3.

  • Obtenir les parents et les enfants d’une cellule H3 donnée.

  • Obtenir la longitude et la latitude du centre de gravité d’une cellule H3 (et vice versa).

  • Obtenir la résolution d’une cellule H3.

  • Obtenir la représentation hexadécimale d’un ID de cellule H3 (et vice versa).

Les fonctions SQL pour H3 sont répertoriées ci-dessous :

Fonction

Description

H3_CELL_TO_BOUNDARY

Renvoie l’objet GEOGRAPHY représentant la limite d’une cellule H3.

H3_CELL_TO_CHILDREN

Renvoie un ARRAY des IDs INTEGER des enfants d’une cellule H3 pour une résolution donnée.

H3_CELL_TO_CHILDREN_STRING

Renvoie un ARRAY des VARCHARs qui contient les IDs hexadécimaux des enfants d’une cellule H3 pour une résolution donnée.

H3_CELL_TO_PARENT

Renvoie l’ID du parent d’une cellule H3 pour une résolution donnée.

H3_CELL_TO_POINT

Renvoie l’objet GEOGRAPHY représentant le point qui est le centre de gravité d’une cellule H3.

H3_COVERAGE

Renvoie un ARRAY d’IDs (sous forme de valeurs INTEGER) qui identifie l’ensemble minimal de cellules H3 qui couvrent complètement une forme. (spécifié par un objet GEOGRAPHY).

H3_COVERAGE_STRINGS

Renvoie un ARRAY d’IDs hexadécimaux (sous forme de valeurs VARCHAR) qui identifie l’ensemble minimal de cellules H3 qui couvrent complètement un polygone (spécifié par un objet GEOGRAPHY).

H3_GET_RESOLUTION

Renvoie la résolution d’une cellule H3.

H3_GRID_DISTANCE

Renvoie la distance de grille entre deux cellules H3.

H3_GRID_DISK

Renvoie un ARRAY d’IDs de cellules H3 dans une distance de grille spécifiée d’une cellule H3 spécifiée.

H3_GRID_PATH

Renvoie un ARRAY d’IDs de cellules H3 qui constituent la ligne entre deux cellules H3.

H3_INT_TO_STRING

Convertit la valeur INTEGER d’un ID de cellule H3 au format hexadécimal.

H3_LATLNG_TO_CELL

Renvoie la valeur INTEGER d’un ID de la cellule H3 pour une latitude, une longitude et une résolution données.

H3_LATLNG_TO_CELL_STRING

Renvoie l’ID de la cellule H3 au format hexadécimal (sous forme de VARCHAR) pour une latitude, une longitude et une résolution données.

H3_POINT_TO_CELL

Renvoie la valeur INTEGER d’un ID de cellule H3 pour un point (spécifié par un objet GEOGRAPHY) à une résolution donnée.

H3_POINT_TO_CELL_STRING

Renvoie la valeur hexadécimale d’un ID de cellule H3 pour un point (spécifié par un objet GEOGRAPHY) à une résolution donnée.

H3_POLYGON_TO_CELLS

Renvoie un ARRAY d’IDs INTEGER identifiant les cellules H3 dont les centroïdes sont contenus par un polygone (spécifié par un objet GEOGRAPHY).

H3_POLYGON_TO_CELLS_STRINGS

Renvoie un ARRAY d’IDs VARCHAR identifiant les cellules H3 dont les centroïdes sont contenus par un polygone (spécifié par un objet GEOGRAPHY).

H3_STRING_TO_INT

Convertit un ID de cellule H3 au format hexadécimal en une valeur INTEGER.

Choix du type de données géospatiales à utiliser (GEOGRAPHY ou GEOMETRY)

Les sections suivantes expliquent les différences entre les types de données GEOGRAPHY et GEOMETRY :

Comprendre les différences entre GEOGRAPHY et GEOMETRY

Bien que les types de données GEOGRAPHY et GEOMETRY définissent tous deux des caractéristiques géospatiales, ils utilisent des modèles différents. Le tableau suivant résume les différences.

Type de données GEOGRAPHY

Type de données GEOMETRY

  • Définit les caractéristiques sur une sphère.

  • Uniquement le système de coordonnées WGS84. SRID est toujours 4326.

  • Les coordonnées sont la latitude (-90 à 90) et la longitude (-180 à 180) en degrés.

  • Les résultats des opérations de mesure (ST_LENGTH, ST_AREA, etc.) sont en mètres.

  • Les segments sont interprétés comme des arcs géodésiques sur la surface de la Terre.

  • Définit les caractéristiques sur un plan.

  • Tout système de coordonnées est pris en charge.

  • L’unité des valeurs de coordonnées est définie par le système de référence spatiale.

  • Les résultats des opérations de mesure (ST_LENGTH, ST_AREA, etc.) sont dans la même unité que les coordonnées. Par exemple, si les coordonnées d’entrée sont en degrés, les résultats sont en degrés.

  • Les segments sont interprétés comme des lignes droites sur le plan.

Exemples comparant les types de données GEOGRAPHY et GEOMETRY

Les exemples suivants comparent les résultats des fonctions géospatiales en utilisant les types de données GEOGRAPHY et GEOMETRY en entrée.

Exemple 1 : interrogation de la distance entre Berlin et San Francisco

Le tableau suivant compare la sortie de ST_DISTANCE pour les types GEOGRAPHY et GEOMETRY :

ST_DISTANCE Utilisation de l’entrée . GEOGRAPHY

ST_DISTANCE Utilisation de l’entrée . GEOMETRY

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

Comme indiqué dans l’exemple ci-dessus :

  • Avec les valeurs d’entrée GEOGRAPHY, les coordonnées d’entrée sont en degrés, et la valeur de sortie est en mètres. (Le résultat est 9 182 km.)

  • Avec des valeurs GEOMETRY d’entrée, les coordonnées d’entrée et la valeur de sortie sont des degrés. (Le résultat est 136,208 degrés.)

Exemple 2 : interrogation de la région de l’Allemagne

Le tableau suivant compare la sortie de ST_AREA pour les types GEOGRAPHY et GEOMETRY :

ST_AREA Utilisation de l’entrée . GEOGRAPHY

ST_AREA Utilisation de l’entrée . GEOMETRY

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

Comme indiqué dans l’exemple ci-dessus :

  • Avec les valeurs d’entrée GEOGRAPHY, les coordonnées d’entrée sont en degrés, la valeur de sortie est en mètres carrés. (Le résultat est 356,379 km^2.)

  • Avec les valeurs d’entrée GEOMETRY, les coordonnées d’entrée sont en degrés, et la valeur de sortie est en degrés carrés. (Le résultat est 45,930 degrés carrés.)

Exemple 3 : interrogation des noms de pays chevauchant la ligne Berlin-San Francisco

Le tableau suivant compare la sortie de ST_INTERSECTS pour les types GEOGRAPHY et GEOMETRY :

ST_INTERSECTS Utilisation de l’entrée . GEOGRAPHY

ST_INTERSECTS Utilisation de l’entrée . GEOMETRY

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
Pays se recoupant lors de l'utilisation de GEOGRAPHY Pays se recoupant lors de l'utilisation de GEOMETRY

Comprendre les différences de la validation des données d’entrée

Pour créer un objet GEOMETRY ou GEOGRAPHY pour une forme d’entrée, vous devez utiliser une forme qui est dans un format valide, conformément aux règles OGC des caractéristiques simples. Les sections suivantes expliquent comment la validité des données d’entrée diffère entre GEOMETRY et GEOGRAPHY.

Une forme peut être valide en GEOGRAPHY mais non valide en GEOMETRY

Une forme donnée peut être un objet GEOGRAPHY valide mais un objet GEOMETRY non valide (et vice versa).

Par exemple, les polygones qui s’auto-intersectent ne sont pas autorisés par les règles OGC. Un ensemble donné de points peut définir des arêtes qui se croisent dans le domaine cartésien mais pas sur une sphère. Prenons le polygone suivant :

POLYGON((0 50, 25 50, 50 50, 0 50))
Copy

Dans le domaine cartésien, ce polygone se dégrade en une ligne et, par conséquent, n’est pas valide.

Cependant, sur une sphère, ce même polygone ne se coupe pas et est valide :

POLYGON((0 50, 25 50, 50 50, 0 50)) GEOMETRY non valide, mais GEOGRAPHY valide

Les fonctions de conversion et de construction traitent la validation différemment

Lorsque les données d’entrée ne sont pas valides, les fonctions GEOMETRY et GEOGRAPHY gèrent la validation de différentes manières :

  • Les fonctions de construction et de conversion en objets GEOGRAPHY (par exemple, TO_GEOGRAPHY) peuvent tenter de réparer la forme pour gérer des problèmes tels que les boucles non fermées, les pointes, les coupures et les boucles qui s’entrecoupent dans les polygones.

    Si la fonction réussit à réparer la forme, elle renvoie un objet GEOGRAPHY.

  • Les fonctions de construction et de conversion en objets GEOMETRY (par exemple, TO_GEOMETRY) ne prennent pas en charge la possibilité de réparer la forme.

Conversion entre GEOGRAPHY et GEOMETRY

Snowflake prend en charge la conversion d’un objet GEOGRAPHY en un objet GEOMETRY (et vice versa). Snowflake prend aussi en charge les transformations d’objets qui utilisent des systèmes de référence spatiale différents (SRS).

L’exemple suivant convertit un objet GEOGRAPHY représentant un point en un objet GEOMETRY avec l’élément SRID 0 :

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

Pour définir le SRID du nouvel objet GEOMETRY, transmettez le SRID comme argument à la fonction du constructeur. Par exemple :

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

Si vous devez définir le SRID d’un objet GEOMETRY existant, consultez Changement du système de référence spatiale (SRS) et SRID d’un objet GEOMETRY.

Spécification du mode de traitement des formes géospatiales non valides

Par défaut, lorsque vous utilisez une fonction de conversion géospatiale pour convertir des données dans un format d’entrée pris en charge en un objet GEOGRAPHY ou GEOMETRY, la fonction effectue les opérations suivantes :

  1. La fonction tente de valider la forme dans les données d’entrée.

  2. La fonction détermine si la forme est valide conformément à la norme Open Geospatial Consortium’s Simple Feature Access/Common Architecture.

  3. Si la forme n’est pas valide, la fonction tente de réparer les données (par exemple, réparer les polygones en fermant les anneaux).

  4. Si la forme n’est toujours pas valide après les réparations, la fonction signale une erreur et ne crée pas l’objet GEOGRAPHY ou GEOMETRY. (Pour les fonctions TRY_*, les fonctions renvoient NULL, plutôt que de signaler une erreur.)

Avec cette fonction, vous avez plus de contrôle sur le processus de validation et de réparation. Vous pouvez :

  • Autorisez ces fonctions de conversion à créer des objets GEOGRAPHY et GEOMETRY pour les formes non valides.

  • Déterminez si la forme d’un objet GEOGRAPHY ou GEOMETRY n’est pas valide.

Compréhension des effets des formes non valides sur les fonctions géospatiales

Différentes fonctions géospatiales ont des effets différents lorsque vous transmettez un objet GEOGRAPHY ou GEOMETRY pour une forme non valide.

Effets sur les objets GEOMETRY

Pour les objets GEOMETRY :

Effets sur les objets GEOGRAPHY

Pour les objets GEOGRAPHY :

Utilisation de formes non valides

Les sections suivantes expliquent comment autoriser les fonctions à créer des formes non valides et comment déterminer si un objet GEOGRAPHY ou GEOMETRY représente une forme non valide ou réparée.

Autorisation des fonctions de conversion à créer des formes non valides

Pour permettre aux fonctions de conversion suivantes de créer des objets géospatiaux non valides, transmettez TRUE pour le deuxième 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

Par défaut, l’argument allowInvalid est FALSE.

Lorsque vous transmettez TRUE pour l’argument allowInvalid , la fonction de conversion renvoie un objet GEOGRAPHY ou GEOMETRY, même lorsque la forme d’entrée n’est pas valide et ne peut pas être réparée avec succès.

Par exemple, la forme d’entrée suivante est une LineString composée des deux mêmes points. Transmettre TRUE pour l’argument allowInvalid renvoie un objet GEOMETRY qui représente une forme non valide :

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

Déterminer si une forme est non valide

Pour déterminer si un objet GEOGRAPHY ou GEOMETRY est non valide, appelez la fonction ST_ISVALID.

L’exemple suivant vérifie si un objet est valide :

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