Working with Ingested Data

After ingestion, your datasets are available as regular Snowflake tables for querying, analysis, and integration with other data. This chapter covers how to locate and work with ingested data.

Locating Ingested Tables

All ingested datasets are stored in the Ingestion Target Database configured in the application settings. The fully qualified table name of each ingested dataset is displayed in the Ingestion Target Table column on the Ingestion Tasks view, accessible via the main menu option Tasks.

You can browse these tables directly in Snowsight or any connected SQL client with access to the Ingestion Target Database.

Permissions: Users with the APP_ADMIN role have full control over the Ingestion Target Database and all its contents. Users with the APP_USER role can browse all schemas and query any table or view in the Ingestion Target Database.

Querying Ingested Data

Ingested datasets are available as regular Snowflake tables and can be queried using standard SQL. For example:

SELECT *
FROM my_ingestion_db.example_org.wfs_my_ingested_dataset;

You can filter, join, and aggregate the data just like any other Snowflake table.

Performing Geospatial Operations

When working with geospatial datasets ingested through the Geo Data Connector, the geometry data is stored in the geom_geojson column in GeoJSON format. To use Snowflake's native GEOMETRY type for spatial analysis, the geometry data must be converted using the TO_GEOMETRY function.

Because geometry data quality varies across sources, follow these practices for reliable conversions.

1. Allow Invalid Geometry Inputs

Use the following form of the conversion function to set the allow_invalid flag to TRUE:

TO_GEOMETRY(geom_geojson, TRUE)

Setting allow_invalid to TRUE instructs Snowflake to return a GEOMETRY value even if the input is invalid and cannot be automatically repaired. This helps prevent query failures due to non-conforming geometry shapes, which may be present in some datasets.

2. Filter Out Empty Geometry Values

Some datasets may include rows where the geometry is missing or empty. To avoid processing these, include a filter condition that checks for non-empty coordinate arrays:

WHERE ARRAY_SIZE(PARSE_JSON(geom_geojson):coordinates) > 0

This ensures that only valid, non-empty geometries are passed to the TO_GEOMETRY function, improving both performance and accuracy.

Complete Example Query

Here is a complete example combining both practices:

SELECT ST_CENTROID(TO_GEOMETRY(geom_geojson, TRUE)) AS centroid
FROM my_ingestion_db.example_org.wfs_my_ingested_dataset
WHERE ARRAY_SIZE(PARSE_JSON(geom_geojson):coordinates) > 0;

Choosing Between GEOMETRY and GEOGRAPHY

Snowflake has two spatial data types: GEOMETRY and GEOGRAPHY. Choosing the wrong one can give you incorrect results — distance calculations return degrees instead of meters, and area calculations return values that are difficult to interpret. Understanding the difference prevents confusing bugs in downstream analysis.

Type	Conversion Function	Coordinates	Distance/Area Units	Best For
GEOMETRY	TO_GEOMETRY(geom_geojson, TRUE)	Planar (flat)	CRS units (degrees for WGS 84)	Shape operations, spatial joins, intersections
GEOGRAPHY	TO_GEOGRAPHY(geom_geojson, TRUE)	Spherical (Earth)	Meters / square meters	Distance calculations, area measurements

Use GEOGRAPHY when you need results in real-world units (meters, square kilometers). Use GEOMETRY when performing topological operations (containment, intersection, overlap).

When the Choice Matters

The difference is most visible in distance and area calculations. The following two queries measure the distance from a monitoring station to Helsinki — the first using GEOMETRY, the second using GEOGRAPHY:

-- GEOMETRY: returns distance in degrees (not useful for real-world measurement)
SELECT
    name,
    ROUND(ST_DISTANCE(
        TO_GEOMETRY(geom_geojson, TRUE),
        TO_GEOMETRY('POINT(24.94 60.17)')  -- Helsinki as WKT
    ), 4) AS distance_degrees
FROM my_ingestion_db.fi_syke.wfs_monitoring_stations
WHERE ARRAY_SIZE(PARSE_JSON(geom_geojson):coordinates) > 0
LIMIT 5;

-- GEOGRAPHY: returns distance in meters
SELECT
    name,
    ROUND(ST_DISTANCE(
        TO_GEOGRAPHY(geom_geojson, TRUE),
        ST_MAKEPOINT(24.94, 60.17)  -- Helsinki (longitude, latitude)
    )) AS distance_meters
FROM my_ingestion_db.fi_syke.wfs_monitoring_stations
WHERE ARRAY_SIZE(PARSE_JSON(geom_geojson):coordinates) > 0
LIMIT 5;

A station 274 km from Helsinki would show as approximately 2.47 with GEOMETRY (degrees) and 274000 with GEOGRAPHY (meters). If your distance results look unexpectedly small, check whether you are using GEOMETRY when you need GEOGRAPHY.

For spatial joins and containment tests (ST_WITHIN, ST_INTERSECTS, ST_CONTAINS), use GEOMETRY — these operations work on shape relationships and do not depend on real-world units.

Error-Safe Conversions with TRY_TO Functions

When exploring an unfamiliar dataset, use TRY_TO_GEOMETRY or TRY_TO_GEOGRAPHY instead of the standard conversion functions. These return NULL for rows with invalid or unparseable geometry instead of failing the entire query:

SELECT
    name,
    TRY_TO_GEOMETRY(geom_geojson) AS geom,
    TRY_TO_GEOGRAPHY(geom_geojson) AS geog
FROM my_ingestion_db.fi_syke.wfs_monitoring_stations
LIMIT 10;

This is useful for checking data quality before building views or running analysis. Rows where conversion fails will have NULL in the spatial columns, making them easy to identify and investigate.

Creating a View with Both Types

If you need both types — GEOMETRY for spatial joins and GEOGRAPHY for measurements — create a view that exposes both:

CREATE OR REPLACE VIEW my_ingestion_db.fi_syke.v_monitoring_stations AS
SELECT
    *,
    TO_GEOMETRY(geom_geojson, TRUE) AS geom,
    TO_GEOGRAPHY(geom_geojson, TRUE) AS geog
FROM my_ingestion_db.fi_syke.wfs_monitoring_stations
WHERE ARRAY_SIZE(PARSE_JSON(geom_geojson):coordinates) > 0;

Downstream queries can then use whichever type is appropriate — geom for joins, geog for distance and area — without repeating the conversion. See Create a Geospatial View with Pre-Converted Types for a more complete example including centroid computation.

Tip: Snowflake expects coordinates in longitude, latitude order (x, y) — not latitude, longitude. If your distance or area results look wrong, check the coordinate order first. Many data formats and APIs use latitude, longitude order, which will produce incorrect results when passed directly to Snowflake spatial functions.

Available Geospatial Functions

Once converted to Snowflake's native spatial types, you can use any of Snowflake's geospatial functions. Commonly used functions include:

Function	Description
ST_WITHIN	Tests if one geometry is within another
ST_INTERSECTS	Tests if two geometries intersect
ST_CONTAINS	Tests if one geometry contains another
ST_DISTANCE	Calculates the distance between two geometries
ST_CENTROID	Returns the centroid of a geometry
ST_AREA	Returns the area of a geometry
ST_LENGTH	Returns the length of a linestring
ST_BUFFER	Returns a geometry expanded by a distance
ST_ENVELOPE	Returns the bounding box of a geometry
ST_UNION	Returns the union of two geometries
ST_INTERSECTION	Returns the intersection of two geometries
ST_COLLECT	Aggregates geometries into a collection
ST_MAKEPOINT	Creates a point from longitude and latitude
H3_LATLNG_TO_CELL	Converts coordinates to an H3 hexagonal grid cell
H3_CELL_TO_BOUNDARY	Returns the boundary polygon of an H3 cell

For a complete list of geospatial functions, refer to the Snowflake Geospatial Documentation.

Pre-Computed H3 Spatial Indices

Every ingested vector dataset includes pre-computed H3 hexagonal grid indices as additional columns. These indices enable efficient spatial binning, aggregation, and joining without computing H3 cells at query time.

Column	Type	Description
h3_indices	array	H3 cell identifiers at fine resolution covering the feature's geometry
h3_resolution	integer	The H3 resolution level used for fine-resolution indexing
h3_indices_coarse	array	H3 cell identifiers at coarse resolution covering the feature's geometry
h3_resolution_coarse	integer	The H3 resolution level used for coarse-resolution indexing

The resolution levels are automatically selected based on the geographic extent of each dataset. Coarse-resolution cells are larger and useful for continental or national-scale aggregation, while fine-resolution cells provide more granular spatial binning.

Example — Aggregate features by pre-computed H3 cell:

SELECT
    h3.value::BIGINT AS h3_cell,
    COUNT(*) AS feature_count
FROM my_ingestion_db.fi_nls.wfs_administrative_regions,
    LATERAL FLATTEN(h3_indices_coarse) AS h3
GROUP BY h3_cell
ORDER BY feature_count DESC;

Example — Spatial join two datasets using H3 indices (faster than geometry-based joins for large datasets):

SELECT DISTINCT
    stations.station_name,
    regions.region_name
FROM my_ingestion_db.fi_syke.wfs_monitoring_stations AS stations,
    LATERAL FLATTEN(stations.h3_indices) AS s_h3
JOIN (
    SELECT region_name, h3.value::BIGINT AS h3_cell
    FROM my_ingestion_db.fi_nls.wfs_administrative_regions,
        LATERAL FLATTEN(h3_indices) AS h3
) AS regions
    ON s_h3.value::BIGINT = regions.h3_cell;

Tip: H3-based spatial joins are significantly faster than geometry-based joins (ST_WITHIN, ST_INTERSECTS) for large datasets because they use simple integer matching instead of computational geometry. The trade-off is that H3 joins are approximate — features near cell boundaries may match neighbouring cells.

Usage Examples for Geospatial Analysts

The following examples demonstrate common geospatial analysis patterns using data ingested through Geo Data Connector. Replace the table names with your actual ingested table names from the Tasks view.

Calculate Feature Areas

Compute the area of polygon features in square kilometers using the GEOGRAPHY type:

SELECT
    name,
    ROUND(ST_AREA(TO_GEOGRAPHY(geom_geojson, TRUE)) / 1e6, 2) AS area_sq_km
FROM my_ingestion_db.fi_nls.wfs_administrative_regions
WHERE ARRAY_SIZE(PARSE_JSON(geom_geojson):coordinates) > 0
ORDER BY area_sq_km DESC;

Proximity Search

Find all features within a specified distance of a location. Using GEOGRAPHY, distances are in meters:

SELECT
    name,
    ROUND(ST_DISTANCE(
        TO_GEOGRAPHY(geom_geojson, TRUE),
        ST_MAKEPOINT(24.94, 60.17)  -- Helsinki (longitude, latitude)
    )) AS distance_meters
FROM my_ingestion_db.fi_syke.wfs_monitoring_stations
WHERE ARRAY_SIZE(PARSE_JSON(geom_geojson):coordinates) > 0
  AND ST_DISTANCE(
        TO_GEOGRAPHY(geom_geojson, TRUE),
        ST_MAKEPOINT(24.94, 60.17)
    ) < 50000  -- within 50 km
ORDER BY distance_meters;

Spatial Join Between Two Datasets

Join two ingested datasets based on spatial containment — for example, finding which administrative region each monitoring station belongs to:

SELECT
    stations.station_name,
    regions.region_name,
    regions.population
FROM my_ingestion_db.fi_syke.wfs_monitoring_stations AS stations
JOIN my_ingestion_db.fi_nls.wfs_administrative_regions AS regions
    ON ST_WITHIN(
        TO_GEOMETRY(stations.geom_geojson, TRUE),
        TO_GEOMETRY(regions.geom_geojson, TRUE)
    )
WHERE ARRAY_SIZE(PARSE_JSON(stations.geom_geojson):coordinates) > 0
  AND ARRAY_SIZE(PARSE_JSON(regions.geom_geojson):coordinates) > 0;

Aggregate Statistics by Region

Count features and calculate total area per region by combining spatial joins with aggregation:

SELECT
    regions.region_name,
    COUNT(*) AS protected_area_count,
    ROUND(SUM(ST_AREA(TO_GEOGRAPHY(areas.geom_geojson, TRUE))) / 1e6, 1) AS total_area_sq_km
FROM my_ingestion_db.fi_syke.wfs_protected_areas AS areas
JOIN my_ingestion_db.fi_nls.wfs_administrative_regions AS regions
    ON ST_INTERSECTS(
        TO_GEOMETRY(areas.geom_geojson, TRUE),
        TO_GEOMETRY(regions.geom_geojson, TRUE)
    )
WHERE ARRAY_SIZE(PARSE_JSON(areas.geom_geojson):coordinates) > 0
  AND ARRAY_SIZE(PARSE_JSON(regions.geom_geojson):coordinates) > 0
GROUP BY regions.region_name
ORDER BY total_area_sq_km DESC;

Buffer Analysis

Create buffer zones around point features and find what falls within them — for example, identifying land parcels within 1 km of environmental monitoring stations:

SELECT
    stations.station_name,
    parcels.parcel_id,
    parcels.land_use_type
FROM my_ingestion_db.fi_syke.wfs_monitoring_stations AS stations
JOIN my_ingestion_db.fi_nls.wfs_land_parcels AS parcels
    ON ST_INTERSECTS(
        TO_GEOMETRY(parcels.geom_geojson, TRUE),
        ST_BUFFER(TO_GEOMETRY(stations.geom_geojson, TRUE), 0.009)  -- ~1 km in degrees
    )
WHERE ARRAY_SIZE(PARSE_JSON(stations.geom_geojson):coordinates) > 0
  AND ARRAY_SIZE(PARSE_JSON(parcels.geom_geojson):coordinates) > 0;

H3 Hexagonal Grid Analysis

Use Snowflake's H3 functions to aggregate geospatial data into hexagonal grid cells for uniform spatial binning:

SELECT
    H3_LATLNG_TO_CELL(
        ST_Y(ST_CENTROID(TO_GEOMETRY(geom_geojson, TRUE))),
        ST_X(ST_CENTROID(TO_GEOMETRY(geom_geojson, TRUE))),
        7  -- H3 resolution (0-15, higher = smaller cells)
    ) AS h3_cell,
    COUNT(*) AS feature_count,
    ROUND(AVG(population), 0) AS avg_population
FROM my_ingestion_db.fi_stat.wfs_population_grid
WHERE ARRAY_SIZE(PARSE_JSON(geom_geojson):coordinates) > 0
GROUP BY h3_cell
ORDER BY feature_count DESC
LIMIT 100;

Combine Raster and Vector Data

Join raster pixel values with vector boundaries to analyze, for example, average band values within each administrative region:

SELECT
    regions.region_name,
    COUNT(*) AS pixel_count,
    ROUND(AVG(pixels.band_1), 2) AS avg_band_1,
    ROUND(AVG(pixels.band_2), 2) AS avg_band_2
FROM my_ingestion_db.fi_stat.wms__landcover_6f91760c AS pixels
JOIN my_ingestion_db.fi_nls.wfs_administrative_regions AS regions
    ON ST_WITHIN(
        ST_MAKEPOINT(pixels.x, pixels.y),
        TO_GEOMETRY(regions.geom_geojson, TRUE)
    )
WHERE ARRAY_SIZE(PARSE_JSON(regions.geom_geojson):coordinates) > 0
GROUP BY regions.region_name
ORDER BY pixel_count DESC;

Usage Examples for Data Engineers

Create a Geospatial View with Pre-Converted Types

Avoid repeated type conversions by creating a view that exposes native spatial types:

CREATE OR REPLACE VIEW my_ingestion_db.fi_nls.v_admin_regions AS
SELECT
    *,
    TO_GEOMETRY(geom_geojson, TRUE) AS geom,
    TO_GEOGRAPHY(geom_geojson, TRUE) AS geog,
    ST_CENTROID(TO_GEOMETRY(geom_geojson, TRUE)) AS centroid
FROM my_ingestion_db.fi_nls.wfs_administrative_regions
WHERE ARRAY_SIZE(PARSE_JSON(geom_geojson):coordinates) > 0;

Downstream queries become simpler and more efficient:

SELECT region_name, ST_AREA(geog) / 1e6 AS area_sq_km
FROM my_ingestion_db.fi_nls.v_admin_regions;

Join Ingested Geospatial Data with Business Data

Enrich business data with spatial context by joining your existing Snowflake tables with ingested geospatial datasets:

SELECT
    c.customer_id,
    c.customer_name,
    regions.region_name,
    regions.population
FROM my_business_db.public.customers AS c
JOIN my_ingestion_db.fi_nls.wfs_administrative_regions AS regions
    ON ST_WITHIN(
        ST_MAKEPOINT(c.longitude, c.latitude),
        TO_GEOMETRY(regions.geom_geojson, TRUE)
    )
WHERE ARRAY_SIZE(PARSE_JSON(regions.geom_geojson):coordinates) > 0;

Schedule Derived Table Refreshes

Use Snowflake tasks to keep derived geospatial tables up to date after each ingestion cycle:

CREATE OR REPLACE TASK my_db.public.refresh_customer_regions
    WAREHOUSE = my_warehouse
    SCHEDULE = 'USING CRON 0 6 * * * UTC'  -- daily at 06:00 UTC
AS
    CREATE OR REPLACE TABLE my_db.public.customer_regions AS
    SELECT
        c.customer_id,
        r.region_name,
        ST_DISTANCE(
            TO_GEOGRAPHY(r.geom_geojson, TRUE),
            ST_MAKEPOINT(c.longitude, c.latitude)
        ) AS distance_to_region_center_m
    FROM my_db.public.customers AS c
    JOIN my_ingestion_db.fi_nls.wfs_admin_regions AS r
        ON ST_WITHIN(
            ST_MAKEPOINT(c.longitude, c.latitude),
            TO_GEOMETRY(r.geom_geojson, TRUE)
        )
    WHERE ARRAY_SIZE(PARSE_JSON(r.geom_geojson):coordinates) > 0;

Share Geospatial Data Across Teams

Use Snowflake Secure Data Sharing to make ingested geospatial datasets accessible to other accounts or teams without copying data:

-- Create a share containing ingested geospatial data
CREATE OR REPLACE SHARE geospatial_data_share;

GRANT USAGE ON DATABASE my_ingestion_db TO SHARE geospatial_data_share;
GRANT USAGE ON SCHEMA my_ingestion_db.fi_nls TO SHARE geospatial_data_share;
GRANT SELECT ON TABLE my_ingestion_db.fi_nls.wfs_administrative_regions
    TO SHARE geospatial_data_share;

Working with Raster/Image Data

When ingesting from raster data sources (WMS, WMTS, WCS, OGC API Maps, OGC API Tiles, OGC API Coverages), the output differs from vector data. Instead of GeoJSON in a single table, raster ingestion always produces two artifacts:

1. Pixel data table: The primary target table containing per-pixel raster data
2. Metadata table: A companion table (suffixed with __metadata) containing image properties

WMS, WMTS, and their OGC API equivalents (OGC API Maps, OGC API Tiles) also produce a third artifact:

3. Image stage: A Snowflake stage containing the georeferenced image file(s)

WCS and OGC API Coverages deliver raw raster data and do not produce an image stage.

Locating Raster Data

The Ingestion Target Table shown in the Tasks view is the pixel data table. The metadata table and image stage share the same base name:

Artifact	Name Pattern	Example
Pixel data table	<table_name>	WMS__AVI1000K_6F91760C
Metadata table	<table_name>__metadata	WMS__AVI1000K_6F91760C__metadata
Image stage	Created automatically	Same schema as the data table

Pixel Data Table

The pixel data table contains one row per pixel, with spatial coordinates and band values:

Column	Type	Description
_row_number	integer	Snowflake row identifier
pixel_id	integer	Unique pixel identifier (computed as row × width + col)
x	decimal	Pixel center X coordinate in the native coordinate reference system
y	decimal	Pixel center Y coordinate in the native coordinate reference system
row	integer	Pixel row index (0-based from top of image)
col	integer	Pixel column index (0-based from left of image)
geom_geojson	string	GeoJSON Point geometry for the pixel center in native CRS coordinates
band_1, band_2, ...	decimal	Raster band values (one column per band in the source image)

The number of band columns depends on the source data. For example, a 3-band RGB image produces band_1, band_2, and band_3.

Example — Query pixel values within a geographic area:

SELECT pixel_id, x, y, band_1, band_2, band_3
FROM my_ingestion_db.fi_stat.wms__avi1000k_6f91760c
WHERE x BETWEEN 25.0 AND 26.0
  AND y BETWEEN 60.0 AND 61.0
LIMIT 100;

Metadata Table

The metadata table (suffixed __metadata) contains a single row with comprehensive image properties:

Column	Type	Description
source_type	string	OGC service type (e.g., wms, wmts, wcs, ogc_api_maps, ogc_api_tiles, ogc_api_coverages)
crs	string	EPSG code for the coordinate reference system
width	integer	Image width in pixels
height	integer	Image height in pixels
bands	integer	Number of raster bands
band_names	string	Comma-separated band names
band_units	string	Comma-separated band measurement units
band_value_range	string	Comma-separated min-max value ranges per band
band_nodata	string	Comma-separated nodata sentinel values per band
pixel_size_x	decimal	Pixel size in X direction (native CRS units)
pixel_size_y	decimal	Pixel size in Y direction (native CRS units)
pixel_value_type	string	Data type of pixel values (e.g., float32, uint8)
pixel_count	integer	Total number of pixels across all raster files
file_size	integer	Total size of raster files in bytes
file_location	string	Location of the raster data files
bbox_native_min_lon	decimal	Minimum longitude/easting in native CRS
bbox_native_min_lat	decimal	Minimum latitude/northing in native CRS
bbox_native_max_lon	decimal	Maximum longitude/easting in native CRS
bbox_native_max_lat	decimal	Maximum latitude/northing in native CRS
bbox_wgs84_min_lon	decimal	Minimum longitude in WGS84
bbox_wgs84_min_lat	decimal	Minimum latitude in WGS84
bbox_wgs84_max_lon	decimal	Maximum longitude in WGS84
bbox_wgs84_max_lat	decimal	Maximum latitude in WGS84

Example — Query image properties:

SELECT source_type, crs, width, height, bands, pixel_value_type
FROM my_ingestion_db.fi_stat.wms__avi1000k_6f91760c__metadata;

Accessing Image Files

For WMS, WMTS, OGC API Maps, and OGC API Tiles datasets, the ingested image is also available as a georeferenced image file in a Snowflake stage. Use Snowflake's stage commands to access it:

-- List files in the stage
LIST @my_ingestion_db.fi_stat.wms__avi1000k_6f91760c_stage;

-- Get a pre-signed URL for downloading an image file
SELECT GET_PRESIGNED_URL(
    @my_ingestion_db.fi_stat.wms__avi1000k_6f91760c_stage,
    'image.tif'
);

Use Cases for Raster Data

Raster data ingested through Geo Data Connector is suitable for:

• Spatial analysis: Query pixel values by coordinate ranges or join with other spatial datasets
• Visualization: Display map images in dashboards or applications using the image files from the Snowflake stage
• Basemaps: Use as background layers in mapping applications
• Machine Learning: Feed imagery into ML pipelines for classification or detection
• Band analysis: Compare band values across geographic areas for remote sensing workflows

Note: For advanced raster analytics within Snowflake, consider using Snowpark with Python libraries that support raster processing.

Visualizing Data in QGIS

QGIS is a widely used open-source GIS application. With the Snowflake Connector plugin for QGIS, you can connect directly to your Snowflake database and visualize datasets ingested by Geo Data Connector on a map.

The steps below were verified with QGIS 3.44 and the Snowflake Connector for QGIS plugin 1.0.11. Refer to the plugin documentation for the latest compatibility information.

Note: QGIS and its Snowflake Connector plugin are third-party tools maintained independently. Installing, configuring, and updating QGIS is your responsibility.

Prerequisites

• QGIS (3.44 or later) with the Snowflake Connector plugin installed (Plugins > Manage and Install Plugins > search "Snowflake Connector")
• A Snowflake user configured with key pair authentication or SSO
• Access to a warehouse and the Ingestion Target Database configured in Application Settings

Connecting to Snowflake

1. Open Layer > Data Source Manager > Snowflake
2. Click New to create a connection
3. Fill in the connection fields:

Field	Value
Name	A descriptive label (e.g., "My Ingestion DB")
Account	Your Snowflake account in org-account format (e.g., MYORG-ACCOUNT1)
Warehouse	Any available warehouse
Database	Your Ingestion Target Database (configured in Application Settings)

Key Pair Authentication

Suitable for individual users and automated workflows.

1. Select Key Pair from the Connection Type dropdown
2. In the Authentication section, use the Basic tab: enter your Snowflake username and leave the password field blank
3. Browse to your RSA private key file (.pem or .p8, PKCS#8 format)
4. Enter the key passphrase if the key is encrypted
5. Click Test Connection, then OK

Note: Use the Basic tab for your username, not the Configuration (encrypted credentials) tab. The plugin has a known issue where the Configuration tab does not work correctly with key pair connections.

Single Sign-On (SSO)

Suitable for organizations using federated identity providers.

1. Select Single sign-on (SSO) from the Connection Type dropdown
2. Click Test Connection — a browser window opens for authentication
3. Complete the sign-in process in the browser
4. Once authenticated, click OK to save

SSO requires that your Snowflake account is configured with an identity provider (e.g., Okta, Microsoft Entra ID). Contact your Snowflake administrator if SSO is not available.

Preparing Tables for QGIS

The QGIS Snowflake Connector plugin only displays tables that have native GEOMETRY or GEOGRAPHY typed columns. Geo Data Connector stores geometry as GeoJSON text, so ingested tables do not appear in QGIS by default.

To make ingested tables visible in QGIS, create a view that converts the geometry to a native type. See Create a Geospatial View with Pre-Converted Types earlier on this page for the full pattern. A minimal example:

CREATE OR REPLACE VIEW my_ingestion_db.fi_nls.v_admin_regions AS
SELECT
    *,
    TO_GEOMETRY(geom_geojson, TRUE) AS geom
FROM my_ingestion_db.fi_nls.wfs_administrative_regions
WHERE ARRAY_SIZE(PARSE_JSON(geom_geojson):coordinates) > 0;

Tip: Create a dedicated schema (e.g., QGIS) for your visualization views to keep them organized separately from the ingested tables.

Adding Layers

1. In the Data Source Manager, select your connection and click Connect
2. Browse to the schema containing your views
3. Double-click a view to add it as a layer
4. When prompted for a Primary Key, select _ROW_NUMBER

The layer is now visible on the QGIS map canvas and can be styled, queried, and used in spatial analysis like any other vector layer.

QGIS Plugin Notes

The following are characteristics of the QGIS Snowflake Connector plugin, not limitations of Geo Data Connector:

• The plugin stores key passphrases in QGIS settings as plaintext. Consider using an unencrypted private key if this is a concern on shared machines.
• SSO availability depends on your Snowflake account's identity provider configuration.
• Only tables with native GEOMETRY or GEOGRAPHY columns appear in the connection browser. The view workaround described above addresses this.