Tijdens de Esri User Conference 2026 hoorden we van verschillende mensen dat ze graag zero-copy externe data-integratie zouden willen. Dat betekent live data die op aanvraag wordt geleverd in ArcGIS zonder dat er een ETL-kopie wordt gemaakt, en bij voorkeur ook zonder een tussenliggende server. Dit is een stap verder dan data-virtualisatie, waarbij mogelijk een cache wordt bijgehouden (om een heel goede reden, namelijk weergaveprestaties). Geef me gewoon de data in mijn kaart zeiden ze.
Oké, hier is het.
Wat je ziet is Overture Maps Foundation Places thema-data gelezen van AWS S3 en geleverd in een ArcGIS Pro geheugenlaag, binnen de huidige kaartuitbreiding, binnen enkele seconden.
Geen tussenliggende kopie, geen databaseserver in de leveringsketen.
Om even terug te gaan, ik ben wat ambitieus met de blogtitel, dit is geen ondersteunde Query Layer editie, maar het kan een "goed genoeg" benadering zijn voor veel gebruikssituaties, en niet alleen voor één sessie - je kunt de data op aanvraag verversen.
Hoe werkt dit? In de bijlage van de blog staat een ArcGIS Pro 3.7 toolbox met een scripttool Maak Serverloze Querylaag met twee invoerparameters: een where-clausule die de gedownloade data filtert, en een boolean die bepaalt of het uitvoerschema tekstvelden heeft met een standaardbreedte of één afgeleid uit de data, wat ik "afstemming" noem.
De brondata, kaartuitbreidingsdetectie en weergavedefinitie zijn hard gecodeerd in de tool.
Dit is hoe de weergavedefinitie-query eruitziet:
# Query 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};"""
We zijn GeoParquet in S3 aan het queryen met DuckDB, dus de SQL-syntaxis die je hierboven ziet is voor DuckDB. Niet getoond: het lezen van de Overture release naam uit een STAC-catalogus die Overture onderhoudt zodat we de waarde kunnen injecteren in de query f-string waarde.
Punten om op te merken in de code:
- DuckDB SQL-functies worden gebruikt
- Complexe kolommen worden afgevlakt tot één enkele waarde, voor eenvoudigheid
- Zowel de ruimtelijke operator ST_Intersects als een bbox structuur eigenschappen worden bevraagd
Ik laat je het scripttool-code op je gemak inspecteren, maar een ander opmerkelijk aspect is dat data wordt gelezen in een Apache Arrow tabel op weg naar het worden van een geheugen feature class. Arrow-tabellen kunnen worden gebruikt in plaats van ArcGIS native feature classes als geoprocessing parameters, maar ik vond een bug die dubbele verwerking van de data noodzakelijk maakt (de data via een aparte geheugen feature class laten lopen in plaats van direct toe te voegen aan mijn doeluitvoer), dus je kunt snellere prestaties verwachten wanneer dit is opgelost.
Om de tool te gebruiken, voeg eerst de bijgevoegde toolbox van de blog toe aan je project, maak dan een kaart of scène actief op een gebied waarin je geïnteresseerd bent - onthoud dat alle Places-data binnen dat gebied wordt gelezen met de standaard "1 = 1" where-clausule - kies vervolgens of je de tekstvelden wilt afstemmen (of niet) en klik op Uitvoeren. Probeer de voorbeeld where-clausules in het scripttool:
Hier zijn ongeveer 5.400 supermarkten in Groot-Londen, GB toen mijn kaart op schaal 1:500K stond tijdens runtime:
Over het afstemmen van tekstvelden in de data: Bestandsgebaseerde formaten (bijv. GeoParquet, CSV, JSON) reizen meestal niet met een schema-definitie (EsriJSON uitgezonderd). In ArcGIS maken verschillende tools verschillende keuzes over tekstveldbreedtes, wat kan leiden tot wat in de industrie bekend staat als een "pathologisch schema", bijvoorbeeld niet-afgestemde data in dit voorbeeld zou tekstvelden creëren van 5000 bytes breed. Dit is meestal geen probleem, maar kan dat wel zijn afhankelijk van waar de data naartoe gaat downstream, zoals tragere prestaties in geodatabase of feature service bij big data. Omdat we waarschijnlijk niet met big data werken met dit voorbeeld, kun je waarschijnlijk kiezen om outputs niet af te stemmen, maar in elk geval heb je een workaround-methode.
Als je echt document-schaal kolommen hebt in je data, kun je de tool zonder afstemming draaien en daarna Export Features gebruiken om je eigen kolombreedtes in te stellen met de veldmapcontrole in die tool.
Als je echt een echte "serverloze querylaag" wilt, vraag dan je Esri-vertegenwoordiger om deze functie! Ik ken een collega die enkele benaderingen test met behulp van het Pro SDK, maar jouw input is onschatbaar.
