Während der Esri User Conference 2026 hörten wir von mehreren Personen, dass sie gerne Zero-Copy-Integration externer Daten hätten. Das bedeutet Live-Daten, die auf Abruf in ArcGIS geliefert werden, ohne dass sie in eine ETL-Kopie geschrieben werden, und idealerweise auch ohne einen Zwischenserver. Dies ist ein Schritt über die Datenvirtualisierung hinaus, bei der möglicherweise ein Cache gehalten wird (aus einem sehr guten Grund, nämlich der Anzeigeleistung). Gib mir einfach die Daten in meiner Karte sagten sie.
OK, hier sind sie.
Was Sie sehen, ist Overture Maps Foundation Places Themen-Daten, die von AWS S3 gelesen und innerhalb des aktuellen Kartenbereichs in Sekunden in eine ArcGIS Pro-Speicherebene geliefert werden.
Keine Zwischenkopie, kein Datenbankserver in der Lieferkette.
Um etwas zurückzutreten: Ich bin mit dem Blogtitel etwas ehrgeizig, dies ist keine unterstützte Query Layer Version, aber es könnte für viele Anwendungsfälle eine „gut genug“ Annäherung sein und nicht nur für eine Sitzung – Sie können die Daten bei Bedarf aktualisieren.
Wie funktioniert das? Im Blog-Anhang befindet sich eine ArcGIS Pro 3.7 Toolbox mit einem Skriptwerkzeug Make Serverless Query Layer mit zwei Eingabeparametern: einer WHERE-Klausel zur Filterung der heruntergeladenen Daten und einem Boolean, der bestimmt, ob das Ausgabeschema Textfelder mit einer Standardbreite oder einer aus den Daten abgeleiteten Breite hat, was ich „Tuning“ nenne.
Die Quelldaten, Kartenausschnittserkennung und Sichtdefinition sind im Werkzeug fest codiert.
So sieht die Sichtdefinitionsabfrage aus:
# Abfrage S3
query = f"""select
id,
names.primary as primary_name,
basic_category,
taxonomy.primary as primary_category,
brand.names.primary as primary_brand,
concat_ws(',',brand.names.common) as other_brands,
concat_ws(' ',addresses[1].freeform,addresses[1].locality,addresses[1].postcode,addresses[1].region,addresses[1].country) as address,
array_to_string(taxonomy.hierarchy,' > ') as taxonomy_hierarchy,
array_to_string(websites,' ') as websites,
array_to_string(emails,' ') as emails,
array_to_string(socials,' ') as socials,
array_to_string(phones,' ') as phones,
operating_status,
confidence,
ST_AsWKB(geometry) as shape,
from read_parquet('s3:\/\/overturemaps-us-west-2\/release\/{release}\/theme=places\/type=place\/*.parquet',filename=false,hive_partitioning=1)
where ST_Intersects(geometry,ST_MakeEnvelope({xmin},{ymin},{xmax},{ymax}))
and bbox.xmin >= {xmin} and bbox.ymin >= {ymin} and bbox.xmax <= {xmax} and bbox.ymax <= {ymax}
and {where};"""
Wir fragen GeoParquet in S3 mit DuckDB ab, daher ist die oben gezeigte SQL-Syntax für DuckDB. Nicht gezeigt: Das Lesen des Overture-Release-Namens aus einem STAC-Katalog, den Overture pflegt, damit wir den Wert in den Abfrage-f-String einfügen können.
Punkte im Code hervorzuheben:
- DuckDB SQL-Funktionen werden verwendet
- Komplexe Spalten werden zur Vereinfachung in einen einzelnen Wert umgewandelt
- Sowohl der räumliche Operator ST_Intersects als auch eine bbox-Struktur Eigenschaften werden abgefragt
Ich lasse Ihnen Zeit, den Code des Skriptwerkzeugs in Ruhe zu prüfen; ein weiterer bemerkenswerter Aspekt ist das Einlesen der Daten in eine Apache Arrow Tabelle auf dem Weg zu einer Speicher-Feature-Class. Arrow-Tabellen können anstelle von nativen ArcGIS-Feature-Classes als Geoverarbeitungsparameter verwendet werden. Allerdings habe ich einen Fehler gefunden, der eine doppelte Handhabung der Daten erfordert (die Daten werden über eine separate Speicher-Feature-Class geleitet statt direkt an mein Ziel ausgegeben), sodass Sie schnellere Leistung erwarten können, wenn dies behoben ist.
Um das Werkzeug auszuführen, fügen Sie zuerst die angehängte Toolbox des Blogs Ihrem Projekt hinzu, machen dann eine Karte oder Szene aktiv in einem Bereich, der Sie interessiert – wobei alle Places-Daten im Bereich mit der Standard-WHERE-Klausel "1 = 1" gelesen werden – wählen dann aus, ob Sie die Textfelder tunen möchten (oder nicht) und klicken auf Ausführen. Probieren Sie die Beispiel-WHERE-Klauseln im Skriptwerkzeug aus:
Hier sind ungefähr 5.400 Lebensmittelgeschäfte im Großraum London, GB, als meine Karte zur Laufzeit im Maßstab 1:500K war:
Zum Tuning der Textfelder in den Daten: Dateibasierte Formate (z.B. GeoParquet, CSV, JSON) enthalten normalerweise keine Schemadefinition (außer EsriJSON). In ArcGIS treffen verschiedene Werkzeuge unterschiedliche Entscheidungen bezüglich der Textfeldbreiten, was zu einem sogenannten „pathologischen Schema“ führen kann; zum Beispiel würden ungetunte Daten in diesem Beispiel Textfelder mit 5000 Bytes Breite erzeugen. Das ist normalerweise kein Problem, kann aber je nach Weiterverwendung der Daten zu langsamerer Leistung in Geodatabases oder Feature Services bei großen Datenmengen führen. Da wir es bei diesem Beispiel wahrscheinlich nicht mit Big Data zu tun haben, können Sie wahrscheinlich darauf verzichten, Ausgaben zu tunen; aber auf jeden Fall haben Sie eine Umgehungsmöglichkeit.
Wenn Ihre Daten wirklich dokumentgroße Spalten enthalten, können Sie das Werkzeug ohne Tuning ausführen und anschließend Export Features verwenden, um Ihre eigenen Spaltenbreiten mit der Feldzuordnungskontrolle dieses Werkzeugs festzulegen.
Wenn Sie wirklich eine echte „serverlose Abfrageebene“ möchten, fragen Sie Ihren Esri-Ansprechpartner nach dieser Funktion! Ich kenne einen Kollegen, der einige Ansätze mit dem Pro SDK testet; Ihr Feedback ist jedoch sehr wertvoll.
