- 19 native H3-Funktionen in reinem SQL - kein Bibliotheksimport, keine Cluster-Konfiguration. H3-beschleunigte Spatial Joins auf 100 Mio.+ Datensatzen sinken von Minuten auf Sekunden, indem teure Geometrie-Operationen in Integer-Gleichheits-Joins umgewandelt werden
- GEOGRAPHY (WGS 84 Kugel) und GEOMETRY (planar, beliebige SRID) Typen mit 60-70 nativen Raumfunktionen. Deckt den 80%-Fall fur raumliche Analysen ab - aber kein Raster, kein 3D, keine Topologie
- Drei Ansatze zur raumlichen Indizierung: automatisches Micro-Partition-Pruning, H3-Clustering (empfohlen fur grosse Tabellen) und Search Optimisation Service (nur Enterprise, 10-facher Credit-Satz - Kosten vor der Aktivierung abschatzen)
- Snowpark-Python-UDFs unterstutzen GeoPandas, Shapely, Fiona und PyPROJ innerhalb der Snowflake-Sandbox. Verwenden Sie Snowpark-optimierte Warehouses (256 GB Speicher) fur schwere raumliche Operationen - Standard-Warehouses laufen bei komplexen Geometrien in OOM-Fehler
- Zero-Copy-Datenaustausch uber den Snowflake Marketplace ist das Alleinstellungsmerkmal, das keine andere Plattform bietet. CARTO, Precisely und Foursquare stellen Geodatensatze bereit, die Sie ohne Datenbewegung joinen konnen
- Typische moderate Geospatial-Workload kostet 150-300 USD/Monat an Snowflake-Credits. Ein wochentlicher Spatial Join auf 50 Mio. Features kostet etwa 16 USD/Monat auf einem Large Warehouse gegenuber 7.000 USD/Jahr fur eine ArcGIS-Advanced-Lizenz
Serie: Geospatial in Cloud
Dies ist Teil 4 unserer Serie “Geospatial in Cloud”. Jeder Beitrag ist in sich abgeschlossen. Teil 1 behandelt Databricks. Teil 2 behandelt AWS. Teil 3 behandelt GCP. Lesen Sie den Beitrag, der zu Ihrem Stack passt.
Snowflake ist die Plattform, die Teams wahlen, wenn sie raumliche Analysen ohne Infrastruktur-Overhead wollen. Keine Cluster zu konfigurieren, keine Bibliotheken zu installieren, kein Spark-Kontext zu debuggen. Sie schreiben SELECT ST_DISTANCE(a.geom, b.geom) und es funktioniert.
Diese Einfachheit ist real. Aber die Trade-offs auch. Snowflake hat keine Raster-Unterstutzung, keine 3D-Geometrie, und die Anzahl der Raumfunktionen betragt etwa ein Sechstel von PostGIS. Wenn Ihr Workflow Satellitenbilder, Gelandemodelle oder komplexe Topologie-Operationen umfasst, ist dies nicht Ihre Plattform.
Fur alles andere - Point-in-Polygon-Joins, H3-Aggregation, Expositionsanalyse, Flottenanalyse, Location Intelligence - liefert Snowflake mit weniger operativem Aufwand als jede andere Cloud-Datenplattform, mit der wir gearbeitet haben.
Warum Snowflake fur Geospatial
Das Versprechen ist einfach: Wenn Ihr Team in SQL denkt und Ihre Daten bereits in Snowflake liegen, ist das Hinzufugen von Geospatial nahezu ohne Aufwand. Keine neue Infrastruktur, keine neuen Fahigkeiten, keine neuen Budgets zu genehmigen.
Kein Cluster-Management
Skalieren von XS bis 6XL Warehouse mit einem Befehl. Auto-Suspend nach 60 Sekunden Leerlauf. Keine Spark-Konfiguration, kein Driver/Executor-Tuning.
Natives H3 in reinem SQL
19 integrierte H3-Funktionen. Einen Spatial Join auf 100 Mio. Datensatzen von Minuten auf Sekunden beschleunigen, indem Geometrie-Operationen in Integer-Gleichheits-Joins umgewandelt werden.
Zero-Copy-Datenaustausch
Joinen Sie Ihre Daten mit CARTO-, Precisely- oder Foursquare-Datensatzen aus dem Snowflake Marketplace, ohne ein einziges Byte zu bewegen. Keine andere Plattform bietet das.
SQL, das Ihr Team bereits kennt
Kein Python erforderlich fur raumliche Analysen. Ihre SQL-Analysten konnen am ersten Tag raumliche Abfragen schreiben. Die Lernkurve beschrankt sich auf einige ST_*-Funktionen.
GEOGRAPHY vs GEOMETRY
Snowflake bietet zwei raumliche Datentypen. Den falschen zu wahlen ist einer der haufigsten Fehler, die wir bei Teams in ihrer ersten Woche sehen.
GEOGRAPHY modelliert die Erde als Kugel mit WGS 84 (SRID 4326). Koordinaten sind Langengrad/Breitengrad in Grad. Entfernungsberechnungen liefern Meter auf der spharischen Oberflache. Dies ist der Typ, nach dem die meisten GIS-Ingenieure zuerst greifen - er entspricht direkt dem Lon/Lat-Modell aus QGIS und ArcGIS.
GEOMETRY verwendet ein planares kartesisches Koordinatensystem. Es unterstutzt beliebige SRIDs - EPSG:27700 fur British National Grid, EPSG:32632 fur UTM Zone 32N, was auch immer Ihre Daten verwenden. Berechnungen sind euklidisch. Verwenden Sie diesen Typ, wenn Ihre Daten in einem projizierten Koordinatensystem vorliegen und Sie meteergenaue Entfernungen ohne spharische Verzerrung benotigen.
Kritische Einschrankungen
- Nur 2D-Koordinaten unterstutzt - keine Z- (Hohe) oder M- (Mass) Werte
- Kein Cast zwischen GEOGRAPHY und GEOMETRY moglich - es sind getrennte Welten
- GEOGRAPHY unterstutzt nur WGS 84 - kein anderes CRS
- Spaltengrossen-Limit ist 64 MB pro Wert (erhoht von 8 MB in 2025)
- GEOGRAPHY verwendet ein perfektes Kugelmodell, kein Ellipsoid - leichte Genauigkeitsunterschiede gegenuber PostGIS bei geodatischer Arbeit
Faustregel: Wenn Ihre Daten in Lon/Lat vorliegen und Sie Analysen durchfuhren (Entfernung, Enthaltensein, Aggregation), verwenden Sie GEOGRAPHY. Wenn Ihre Daten in einer nationalen oder UTM-Projektion vorliegen und Sie prazise planare Geometrie-Operationen benotigen, verwenden Sie GEOMETRY. Wenn Sie zwischen Projektionen konvertieren mussen, verwenden Sie ST_TRANSFORM - aber nur auf GEOMETRY-Spalten.
Spatial-SQL-Funktionen
Snowflake bietet etwa 60-70 native Raumfunktionen. Zum Vergleich: PostGIS hat 400+. Die Lucke ist real, aber oft irrelevant: Die 60 Funktionen, die Snowflake hat, decken die Kern-Operationen ab, die 80% der Geospatial-SQL-Workflows benotigen.
Die wichtigsten sind alle vorhanden: ST_DISTANCE, ST_INTERSECTS, ST_CONTAINS, ST_BUFFER, ST_UNION, ST_INTERSECTION, ST_SIMPLIFY, ST_CENTROID, ST_AREA. Sie konnen Spatial Joins ausfuhren, Puffer erstellen, Polygone auflosen, Entfernungen berechnen und Enthaltensein-Prufungen durchfuhren.
Zwei Aggregatfunktionen decken den Grossteil der GIS-Dissolve-Operationen ab: ST_COLLECT kombiniert Zeilen zu einer GeometryCollection, und ST_UNION_AGG lost alle Geometrien in einer Gruppe auf - das SQL-Aquivalent von ArcGIS Dissolve.
Funktionen, die Sie vermissen werden (kommend von PostGIS)
- Kein
ST_Voronoi/ST_DelaunayTriangles - Kein
ST_ClusterDBSCAN/ST_ClusterKMeans(verwenden Sie Python-UDFs) - Kein
ST_MakeValidnativ (verfugbar uber Sedona Native App) - Keine lineare Referenzierung (
ST_LineLocatePoint,ST_LineInterpolatePoint) - Keine Topologie-Operationen, kein Routing, keine Netzwerkanalyse
- Uberhaupt keine Raster-Funktionen
Die Lucke fullt die Apache Sedona Native App (SedonaSnow), verfugbar im Snowflake Marketplace. Sie verdoppelt in etwa die verfugbare Funktionsanzahl und fugt ST_MakeValid, ST_SubDivide, breitere CRS-Unterstutzung uber ST_Transform und mehr hinzu. Lohnt sich zu evaluieren, wenn Sie an die Grenze der nativen Funktionen stossen.
H3: Das Killer-Feature
H3 ist Ubers hexagonales raumliches Indexierungssystem, und Snowflakes native Integration ist wirklich hervorragend. 19 Funktionen, alle vollwertige SQL-Burger. Kein Bibliotheksimport, kein UDF-Wrapper, kein Setup.
Die zentrale Erkenntnis: Traditionelle Spatial Joins ( ST_INTERSECTS auf zwei grossen Tabellen) sind rechenintensiv. Jede Zeile links muss potenziell gegen jede Zeile rechts gepruft werden. Mit H3 konvertieren Sie beide Datensatze in die gleiche hexagonale Auflosung und joinen dann uber Integer-Gleichheit. Eine O(n*m) Geometrie-Operation wird zum Hash Join. Bei 100 Mio.+ Datensatzen konnen Spatial Joins so von Minuten auf Sekunden sinken.
Die wichtigsten Funktionen: H3_LATLNG_TO_CELL(lat, lng, resolution) konvertiert einen Punkt in einen H3-Zellindex. H3_COVERAGE(geography, resolution) bedeckt ein Polygon mit der minimalen Menge an H3-Zellen. H3_CELL_TO_BOUNDARY(cell) konvertiert zuruck in ein hexagonales Polygon zur Visualisierung. H3_CELL_TO_PARENT und H3_CELL_TO_CHILDREN navigieren die Hierarchie fur Multi-Auflosungs-Analysen.
H3-AUFLOSUNGSLEITFADEN
Auflosung 3
~12.400 km2 - Landesebene
Auflosung 5
~253 km2 - Regionale Analyse
Auflosung 7
~5,16 km2 - Stadt / Einzugsgebiete
Auflosung 9
~0,105 km2 - Stadtteil / Postleitzahl
Auflosung 11
~0,002 km2 - Gebaudeebene
Auflosung 15
~0,9 m2 - Sub-Meter-Prazision
Das typische Muster: Fugen Sie eine H3-Spalte zu Ihrer Tabelle hinzu, clustern Sie danach und joinen Sie dann uber Integer-Gleichheit. Fur eine Tabelle mit Versicherungsanspruchen, die mit Hochwasserzonen gejoint wird, liefert Auflosung 9 Stadtteil-Prazision. Der Join wird zu einem GROUP BY auf einer Integer-Spalte - genau das, wofur Snowflakes Columnar-Engine optimiert ist.
Vergleich: Databricks hat H3 nativ seit DBR 17+ und uber Mosaic auf alteren Runtimes. BigQuery hat kein eingebautes H3 - es setzt auf S2 als nativen raumlichen Index. Fur Teams, die H3 in reinem SQL ohne Spark-Komplexitat wollen, ist Snowflake der einfachste Weg.
Zellenanzahl im Auge behalten
Das Ausfuhren von H3_COVERAGE bei Auflosung 12+ auf landersgrossen Polygonen erzeugt Milliarden von Zellen. Beginnen Sie bei Auflosung 7-9 und erhohen Sie nur, wenn Ihre Analyse es erfordert. Ein mittleres Warehouse kann Auflosung 9 fur die meisten Workloads bewaltigen. Auflosung 12+ auf grossen Polygonen benotigt XL oder grosser.
Geodaten laden
Snowflake versteht nativ GeoJSON, WKT, WKB, EWKT und EWKB. Sie konnen diese aus Staged Files (interne oder externe S3/GCS/Azure-Stages) uber COPY INTO mit einem TO_GEOGRAPHY()- oder TO_GEOMETRY()-Cast laden.
GeoParquet ist das empfohlene Format. Es speichert Geometrie als WKB in einer Binarspalte, komprimiert gut und wird zum Austauschstandard uber Snowflake, Databricks, DuckDB und BigQuery hinweg. Iceberg-Tabellen-Unterstutzung fur GEOGRAPHY- und GEOMETRY-Typen wurde auf dem Summit 2025 angekundigt - nach GA macht dies den GeoParquet-Austausch zwischen Plattformen unkompliziert.
Shapefiles werden nicht nativ unterstutzt. Das ist Reibung fur jedes Team, das von ArcGIS migriert. Der empfohlene Workflow: Lokal in GeoParquet konvertieren mit ogr2ogr oder GeoPandas, auf eine Snowflake-Stage hochladen, dann COPY INTO mit WKB-Parsing. Alternativ konnen Sie FMEs nativen Snowflake-Spatial-Writer verwenden, falls Ihre Organisation bereits eine Lizenz hat.
DATENLADE-UNTERSTUTZUNG
Eine Falle, auf die Sie achten mussen: GeoJSON-FeatureCollections mussen abgeflacht werden. Jedes Feature wird uber LATERAL FLATTEN zu einer Zeile. Der GEOGRAPHY-Typ lehnt jede SRID ausser 4326 ab - wenn Ihr GeoJSON ein anderes CRS hat, benotigen Sie stattdessen GEOMETRY.
Raumliche Indizierung
Es gibt kein CREATE SPATIAL INDEX in Snowflake. Wenn Sie von PostGIS kommen, fuhlt sich das falsch an. Aber Snowflake hat drei Mechanismen, die ahnliche Ergebnisse auf unterschiedlichen Wegen erzielen.
1. Automatisches Micro-Partition-Pruning
Snowflake speichert Bounding-Box-Metadaten fur jede Micro-Partition. Bei raumlichen Filterabfragen werden Partitionen ubersprungen, deren Bounding Boxes sich nicht uberlappen. Dies ist automatisch und kostenlos. Fur gut geclusterte Daten bietet es erhebliche Beschleunigung. Fur zufallig verteilte Daten hilft es weniger.
2. H3-Clustering (empfohlen)
Berechnen Sie eine H3-Index-Spalte vor und clustern Sie die Tabelle danach. Dies stellt sicher, dass raumlich benachbarte Daten in denselben Micro-Partitionen liegen, was das Bounding-Box-Pruning hocheffektiv macht. Dies ist die gunstigste und wirkungsvollste Optimierung fur grosse raumliche Tabellen. Verwenden Sie ALTER TABLE ... CLUSTER BY (h3_column).
3. Search Optimisation Service (nur Enterprise)
Erstellt persistente Suchzugriffspfade fur raumliche Pradikate. Pro Spalte aktivieren mit ALTER TABLE ... ADD SEARCH OPTIMIZATION ON GEO(column). Unterstutzt ST_INTERSECTS, ST_CONTAINS, ST_WITHIN, ST_DWITHIN.
Kostenwarnung: SOS nutzt Serverless-Compute, das zum 10-fachen des normalen Credit-Satzes berechnet wird. Fuhren Sie SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS vor der Aktivierung aus. Bei haufig aktualisierten Tabellen kann dies 150-600 USD/Monat zusatzlich kosten.
Fur die meisten Teams ist Option 2 (H3-Clustering) der richtige Ausgangspunkt. Es kostet nur die Standard-Auto-Reclustering-Credits und bietet die grosste Leistungsverbesserung pro Dollar. Fugen Sie SOS nur hinzu, wenn H3-Clustering nicht ausreicht und Sie die Kosten bestatigt haben.
Python + GeoPandas Integration
Snowpark Python ist die Brucke zwischen SQL und Python innerhalb von Snowflake. Python-UDFs laufen in einer sicheren Sandbox mit Zugriff auf Pakete aus Snowflakes Anaconda-Channel. Die wichtigen Geospatial-Pakete sind verfugbar: Shapely, GeoPandas, Fiona, PyPROJ und GDAL.
Der primare Anwendungsfall: Operationen, die Snowflakes natives SQL nicht bewaltigen kann. Raumliches Clustering mit DBSCAN, komplexe Geometrie-Validierung, Koordinatentransformationen uber CRS, die nativ nicht unterstutzt werden, oder das direkte Lesen von Shapefiles von einer Stage mit Fiona.
Performance-Fallen bei Python-UDFs
- Cold Start: ~400 ms bei kleinen Warehouses, ~900 ms bei mittleren. Der erste Aufruf in einer Session ist spurbar langsamer
- Speicherlimits: Standard-Warehouses bieten ~16 GB pro Knoten. Fur schwere GeoPandas-Operationen verwenden Sie Snowpark-optimierte Warehouses (256 GB pro Knoten)
- Rasterio: Im Anaconda-Channel nicht zuverlassig verfugbar. Rasterverarbeitung in Snowflake-UDFs ist praktisch nicht machbar
- Debugging: Python-UDF-Fehler erscheinen als generische SQL-Fehler. Fugen Sie explizite try/except mit aussagekraftigen Meldungen in Ihren UDFs hinzu
Snowflake Notebooks (Streamlit-basiert) ermoglichen es, GeoPandas interaktiv innerhalb von Snowflake mit Pydeck oder Folium zur Visualisierung auszufuhren. Fur explorative raumliche Analysen ist dies der schnellste Weg. Fur Produktions-Pipelines verpacken Sie Ihre Logik in Stored Procedures oder UDTFs.
Streamlit in Snowflake verdient Erwahnung: Sie konnen interaktive Geospatial-Web-Apps (Karten, Dashboards) erstellen, die vollstandig innerhalb Ihres Snowflake-Kontos laufen. Daten verlassen niemals die Plattform, Zugriffskontrollen erben von Snowflakes RBAC, und es gibt keine Infrastruktur zu verwalten. Fur interne Tools ist dies eine uberzeugende Alternative zum Aufsetzen einer separaten Kartenanwendung.
Snowflake vs Databricks fur Geospatial
Beides sind Fokus-Plattformen fur uns. Dies ist ein direkter Vergleich basierend auf der Migration von Produktions-Workloads zu beiden.
| FAKTOR | SNOWFLAKE | DATABRICKS |
|---|---|---|
| Primarsprache | SQL (Python uber UDFs) | Python/Spark (SQL uber Spark SQL) |
| H3-Unterstutzung | 19 native SQL-Funktionen | Nativ (DBR 17+) + Mosaic-Bibliothek |
| Raumfunktionen | 60-70 nativ | 90+ nativ + Sedona + Mosaic |
| Raster-Unterstutzung | Keine | Uber Mosaic / Sedona |
| 3D-Geometrie | Keine | Begrenzt |
| Cluster-Management | Keines (serverless) | Erforderlich (Spark-Konfiguration) |
| Datenaustausch | Zero-Copy (Marketplace) | Delta Sharing (offenes Protokoll) |
| Skalierungsobergrenze | Hervorragend bis ~500 Mio. Zeilen | Uberlegen jenseits 500 Mio. (verteiltes Spark) |
| ML auf Raumdaten | Cortex ML (grundlegend) + Python-UDFs | MLflow + Spark ML + Mosaic |
| Kostenmodell | Credits (einfacher) | DBUs + Cloud-Infra (schwerer vorhersagbar) |
Wahlen Sie Snowflake, wenn: Ihr Team SQL-first ist, Ihre Daten bereits in Snowflake liegen, Sie Zero-Copy-Sharing mit Marketplace-Datenanbietern benotigen und Ihr Workload Vektoranalysen ohne Raster-Anforderungen umfasst.
Wahlen Sie Databricks, wenn: Ihr Team Python/Spark-first ist, Sie Raster-Unterstutzung benotigen, Sie ML-Pipelines auf raumlichen Features aufbauen oder Sie bei extremem Massstab verarbeiten (Milliarden Zeilen mit komplexen Geometrie-Operationen).
Fur den Ruckversicherungs-Anwendungsfall konkret - 50 Mio. Flurstucke mit Hochwasserzonen joinen und Anspruche nach Hexagon aggregieren - bewaltigen beide Plattformen dies. Snowflake ist einfacher einzurichten und zu betreiben. Databricks ist leistungsfahiger fur den nachsten Schritt: raumliche Risikomodelle auf den Ergebnissen trainieren.
Kostenmodell
Snowflake berechnet Standard-Compute-Credits fur alle raumlichen Operationen - keine separate Geospatial-Preisgestaltung. Sie zahlen pro Sekunde Warehouse-Zeit (1-Minuten-Minimum bei Wiederaufnahme) plus Speicher.
| WORKLOAD | WAREHOUSE | DAUER | ~KOSTEN (ENTERPRISE) |
|---|---|---|---|
| Spatial Join, 10 Mio. x 10 Tsd. | Medium | ~30 Sek. | ~0,09 USD |
| H3 Polyfill, 1 Mio. Polygone bei Aufl. 9 | Large | ~2 Min. | ~0,81 USD |
| Wochentliche Hochwasserrisikoanalyse, 50 Mio. Flurstucke | Large | ~15 Min. | ~4 USD/Lauf |
| Tagliche Punktaggregation, 10 Mio. Events | Medium | ~5 Min. | ~0,67 USD/Lauf |
| Geo Search Optimisation (monatlich) | Serverless (10x) | Fortlaufend | 150-600 USD/Mon. |
Ein moderater Geospatial-Analytics-Workload - wochentliche Batch-Jobs, tagliche Aggregationen, Ad-hoc-Analysten-Abfragen - landet im Bereich von 150-300 USD/Monat. Vergleichen Sie das mit einer ArcGIS-Advanced-Lizenz bei ca. 7.000 USD/Jahr fur aquivalente Desktop-Verarbeitung. Der Break-even-Punkt bevorzugt Snowflake fur jeden Workload, der mehr als ein paar Mal pro Monat lauft.
Versteckte Kosten beachten
- Search Optimisation Service zum 10-fachen Credit-Satz bei grossen, haufig aktualisierten Tabellen
- Dauerlaufende Warehouses - setzen Sie Auto-Suspend auf 60 Sekunden fur Ad-hoc-Raumabfragen
- H3 Coverage bei Auflosung 12+ auf landersgrossen Polygonen erzeugt Milliarden von Zellen
- Snowpark-optimierte Warehouses kosten das 1,7-fache von Standard-Warehouses
- Enterprise Edition fur Geo Search Optimisation erforderlich - Standard Edition bietet dies nicht
Wann Snowflake fur Geospatial NICHT verwenden
Jede Plattform hat Grenzen. Hier sind die von Snowflake.
Raster- oder Bildverarbeitung
Kein GeoTIFF, keine DEMs, keine Satellitenbilder, keine Rasteralgebra. Wenn Ihr Workflow Rasterdaten beruhrt, verwenden Sie Databricks (Mosaic), Google Earth Engine oder eine dedizierte Raster-Pipeline.
3D-Geometrie oder LiDAR
Nur 2D-Koordinaten unterstutzt. Keine Z-Werte, keine M-Werte. Gelandeanalyse, 3D-Gebaudemodelle und Punktwolken erfordern ein anderes Werkzeug.
Raumliche Lookups unter 100 ms
Snowflake ist eine OLAP-Plattform. Wenn Sie eine Live-Karten-API mit Echtzeit-Raumabfragen benotigen, brauchen Sie weiterhin PostGIS oder einen spezialisierten Tile-Server.
Komplexe Topologie-Operationen
Keine Netzwerkanalyse, kein Routing, keine lineare Referenzierung, keine Voronoi-Diagramme nativ. PostGIS oder Shapely uber Python-UDFs konnen einige Lucken fullen, aber wenn Topologie zentral fur Ihren Workflow ist, ist Snowflake das falsche Werkzeug.
Aufwandige CRS-Transformationen
GEOGRAPHY ist auf WGS 84 festgelegt. GEOMETRY unterstutzt SRIDs, aber der integrierte CRS-Katalog ist im Vergleich zu PostGIS begrenzt. Wenn Ihr Workflow haufige Umprojektionen zwischen ungewohnlichen Koordinatensystemen erfordert, erwarten Sie Reibung.
Budgetbeschrankte Teams ohne Enterprise
Das wirkungsvollste Performance-Feature (Geo Search Optimisation) erfordert die Enterprise Edition. Mit der Standard Edition verlassen Sie sich auf H3-Clustering und Micro-Partition-Pruning - immer noch effektiv, aber die Obergrenze ist niedriger.
Erste Schritte
Wenn Sie bereits auf Snowflake sind, ist die Aktivierung von Geospatial sofort moglich. Keine Pakete zu installieren, keine Erweiterungen zu aktivieren. Die Raumfunktionen und H3-Funktionen sind in jedem Warehouse verfugbar.
Shapefiles in GeoParquet konvertieren
Verwenden Sie ogr2ogr oder GeoPandas lokal. Dies ist der einzige Schritt, den Sie nicht uberspringen konnen - Snowflake liest Shapefiles nicht nativ.
Stagen und laden
PUT-Dateien auf eine Stage, COPY INTO mit TO_GEOGRAPHY() oder TO_GEOMETRY(). Validieren mit ST_ISVALID.
H3-Indizes hinzufugen
Fugen Sie eine H3-Spalte bei Auflosung 7-9 hinzu und clustern Sie danach. Dieser einzelne Schritt bringt die grosste Leistungsverbesserung.
Mit SQL starten
ST_INTERSECTS, ST_DISTANCE, ST_AREA, GROUP BY H3-Zelle. Ihre SQL-Analysten konnen sofort raumliche Daten abfragen.
Python bei Bedarf hinzufugen
Greifen Sie nur dann zu Snowpark-Python-UDFs, wenn natives SQL die Aufgabe nicht erfullen kann - raumliches Clustering, komplexe Validierung, Formatkonvertierung.
Marketplace erkunden
Prufen Sie den Snowflake Marketplace auf die CARTO Analytics Toolbox (70+ zusatzliche Raumfunktionen) und Drittanbieter-Geodatensatze (Hochwasserzonen, Demografie, POI).
Snowflake versucht nicht, PostGIS zu sein. Es versucht, raumliche Analysen fur jeden SQL-Analysten zuganglich zu machen, der bereits ein Snowflake-Konto hat.
Fur Teams, die Point-in-Polygon-Joins, H3-Aggregation, Expositionsanalyse und Location Intelligence benotigen - alles in SQL, ohne Infrastruktur zu verwalten - liefert es. Die 19 nativen H3-Funktionen allein sind die Evaluierung wert. Der Zero-Copy-Datenaustausch ist etwas, das keine andere Plattform bietet.
Kennen Sie seine Grenzen. Kein Raster. Kein 3D. Keine Sub-Millisekunden-Lookups. Wenn Ihr Workflow innerhalb dieser Grenzen liegt, ist Snowflake einer der einfachsten Wege von Legacy-Desktop-GIS zu cloud-nativer raumlicher Analyse.
Workflow-Automatisierung Einblicke erhalten
Monatliche Tipps zur Automatisierung von GIS-Workflows, Open-Source-Tools und Erkenntnisse aus Enterprise-Deployments. Kein Spam.