Back

How to Use Snowflake Cortex AI for Geospatial Use Cases

Amine Kriaa 

Solutions Architect

June 18, 2025

How to Use Snowflake Cortex AI for Geospatial Use Cases

Large Language Models (LLMs) are redefining how we interact with data, especially in domains traditionally siloed behind specialized knowledge and technical complexity, like geospatial analysis. By translating natural language into structured spatial queries, LLMs dramatically reduce the technical barrier to extracting location-based insights. 

With platforms like Snowflake Cortex, this capability is now embedded directly into the data warehouse, enabling faster, more accessible geospatial experimentation than ever before. These kinds of capabilities are at the heart of what’s now called GeoAI: combining geospatial intelligence with artificial intelligence.

We can now ask specific questions and the model generates a spatial SQL query to retrieve answers, like:

  • “What is the distance between each row in this table and a specific location?”
  • “Which customers are within 5 km of a service outage zone?”
  • “Can you clean up this list of POIs and tell me if the coordinates match the actual place and city?”
  • “Can you standardize these addresses in Portugal and include the district, city, and country?”
 

But while LLMs make it easier to explore and prototype with spatial data, they aren’t a replacement for geospatial logic, governance, or production-grade performance. Without careful integration of geospatial functions—distance calculations, spatial indexing, projection handling—LLMs can produce flawed or oversimplified results.

In this article, we walk you through three practical use cases that showcase the power of LLMs for geospatial analytics inside Snowflake:

  1. Insurance Risk Assessment based on proximity to emergency services

  2. Address Standardization to improve insurance data quality and geocoding precision

  3. POI Normalization to clean and contextualize amenities in real estate listings

Use case #1 : GeoAI for Insurance Risk — Emergency service proximity

This use case shows how GeoAI and LLMs help insurers quickly assess property risk by calculating distances to fire stations, directly in Snowflake, without GIS tools or complex queries.

Business Context

In property insurance, proximity to emergency services like fire stations is a critical factor in underwriting and pricing. The closer a property is to first responders, the lower the perceived risk—and potentially, the premium. Traditionally, calculating these spatial relationships requires GIS tools and spatial SQL expertise, creating friction between business users and actionable insights.

What the LLM Does

With Snowflake Cortex and a small, embedded list of fire station coordinates, we asked an LLM to compute the nearest fire station for each property. Here’s an example:

Prompt“Calculate the distance between each insured property and the nearest fire station in Québec City. Only return the distance in kilometers, no other text.”

Here’s the SQL query used along with the results returned by the model:

Benefits

This approach allows insurers to quickly assess risk based on emergency service proximity—without needing a full GIS stack, and without extracting data outside the warehouse. All analysis happens where the data already lives—ensuring better performance, governance, and scalability.

Use Case #2: Address Standardization in Insurance

Business Context

In the insurance industry, accurate and consistent address data is essential for underwriting, risk assessment, and claims management. Customer-submitted addresses often come in varied formats—with missing postal codes, inconsistent abbreviations, or formatting errors—that can compromise geocoding precision and downstream risk calculations.

By using Snowflake Cortex, we provided a raw list of customer addresses and prompted the LLM to clean and standardize the records:

Prompt:
“Clean and standardize the following list of customer-provided addresses. Ensure proper casing, consistent formatting, and include missing province or postal code information where possible. Use Canadian address formatting conventions. Only return cleaned and standardized address.”

 Here’s the SQL query used along with the results returned by the model:

Benefits

The LLM interpreted the intent, corrected typos, filled in missing location hierarchy levels, and returned a clean, structured output—all within the Snowflake environment. This ensured all addresses conformed to a consistent format, enabling precise geocoding and risk zone mapping.

Use Case #3: POI Normalization in Real Estate

In real estate analytics, points of interest (POIs)—like parks, grocery stores, cafés, and schools—are key to scoring neighborhoods and evaluating property value. But user-submitted or scraped listing data often contains misspelled, vague, or colloquial POI names that can’t be reliably geocoded or aggregated. Those free-text POI mentions are inconsistent and hard to geocode reliably.

By applying LLM-powered POI normalization, platforms can:

  • Standardize POI names across listings (e.g., “Starbux” → “Starbucks”).
  • Resolve vague or colloquial references (e.g. Whole Foods Market, the park near downtown, etc) using city and coordinate context.
  • Improve map-based search, amenity scoring, and neighborhood analytics.

Using Snowflake Cortex and an input list of incorrectly spelled addresses, we applied a prompt-driven LLM function to automatically clean, standardize, and enrich the data with consistent formatting and missing geographic details.

Prompt:
“Given a POI name, a city and coordinates, return de corrected POI name and the corrected city (if needed). Also, indicate if the coordinates likely match the POI. Only return a JSON with “corrected_poi”, “corrected_city”, location_match”. ”

 Here’s the SQL query used along with the results returned by the model:

Benefits

The LLM generated enriched, consistent names, corrected typos, and disambiguated local references based on spatial hints. This approach accelerates address standardization by eliminating manual processing or the need for external tools. By interpreting the user’s intent and transforming messy input into consistent, geocodable formats, the LLM dramatically improves the quality of address data used in downstream analytics.

Limitations of LLMs for Geospatial Uses

While Large Language Models (LLMs) bring powerful capabilities for prototyping spatial queries and speeding up early-stage analysis, they are not yet reliable for production-grade geospatial workflows without proper GIS integration. Several key limitations need to be considered : 

    • Inaccurate or Oversimplified Results

      LLMs can misinterpret unit conversions, mislabel outputs, or ignore coordinate reference systems. For example, a distance conversion request might return the same numeric value with only the unit changed, without applying the correct conversion factor. Even small errors can lead to significant business risks in fields like insurance or logistics.

      Limited spatial context

      Unlike GIS systems, LLMs lack embedded geographic ontologies. They don’t inherently understand administrative boundaries, projections (e.g., WGS84 vs. UTM), or topological relationships like adjacency or containment. This can lead to syntactically correct but semantically flawed queries

    • Performance and scalability issues

      The SQL code generated by LLMs is often not optimized for scale. It may neglect key spatial performance practices such as spatial indexing (ST_CLUSTERKMEANS, ST_CLUSTERDBSCAN, or GEOGRAPHY_INDEX in Snowflake), filtering early in joins, or minimizing computation over large bounding boxes. This can result in slow-running queries that don’t scale across millions of rows, hindering production use in high-throughput environments.

    • No built-in validation

      LLMs can’t verify if their outputs are correct. They can’t assess whether a spatial join succeeded or a buffer was applied properly. Human review remains essential,  highlighting the continued need for geospatial experts.

    • Cost and query optimization

      LLMs can generate functional spatial queries, but they often overlook cost efficiency. For example, calculating distances between properties and fire stations might produce overly complex SQL when a simple function like ST_DISTANCE would be faster and cheaper in Snowflake. Even with good prompts, query validation and optimization are crucial to control credit usage.

Key Takeaways

LLMs can accelerate experimentation, reduce time-to-first-insight, and expand geospatial access to non-experts, but they are not a replacement of robust GIS systems, domain knowledge, or validated spatial logic. When integrated carefully within a governed environment like Snowflake, they become a powerful co-pilot (but not an autopilot) for location-based analytics.

For production-grade solutions, especially those involving large datasets or requiring high spatial accuracy, the role of geospatial engines remains essential.

The most effective path forward is a hybrid one: integrating LLMs where they can add the most value (like natural language interfaces, prototyping, and automation) while continuing to rely on GIS platforms and geospatial experts to ensure precision, scalability, and reliability.

As a Snowflake Select Tier Partner, Korem can help organizations unlock the power of this platform by combining our geospatial expertise with Snowflake AI capabilities. Whether you’re looking for advanced geo-analytics, complex modeling based on large-scale data, or seamless integration of location intelligence into your data workflows, we can help you move faster—with confidence.

Contact us today to discuss your project.

FAQ: GeoAI, LLMs, and Geospatial analytics

No, current LLMs are not designed for real-time geospatial processing. While they can help generate queries or prototypes, tasks that require real-time updates, like live asset tracking or dynamic routing, still depend on specialized GIS engines or streaming platforms.

LLMs are most effective for generating straightforward spatial SQL queries (e.g., distance calculations, simple joins, or standardization tasks) and for assisting with prototyping or exploration. Complex spatial operations involving advanced topological relationships or multi-layer spatial joins are better handled by GIS tools.

No. LLMs don’t have an inherent understanding of coordinate systems or projections (e.g., WGS84 vs. UTM). They rely entirely on the information provided in prompts, which means they can’t detect or correct projection mismatches without explicit guidance.

LLM-generated queries can work, but they often result in unnecessarily complex or inefficient SQL, leading to higher compute costs. Traditional spatial queries crafted by GIS specialists or optimized manually are typically more cost-efficient, especially at scale.

GeoAI can be leveraged for address standardization to enhance data quality and geocoding precision in the insurance and banking sectors. While it’s useful for rapid exploration and prototyping, production workflows that require compliance, audits, or high accuracy still rely on traditional GIS systems, solid data governance, and expert validation.

Stay connected!

Subscribe to our newsletter:

CHATWITH US