Během konference Esri User Conference 2026 jsme slyšeli od několika lidí, že by chtěli zero-copy externí integraci dat. To znamená živá data dodávaná na vyžádání do ArcGIS bez zápisu do ETL kopie a ideálně také bez jakéhokoli mezilehlého serveru. Toto je krok za virtualizací dat, kde může být uchovávána cache (z velmi dobrého důvodu, totiž pro výkon zobrazení). Jen mi dejte data v mé mapě řekli.
Dobře, tady to máte.
Na co se díváte, je Overture Maps Foundation Places tematická data čtená z AWS S3 a dodaná do paměťové vrstvy ArcGIS Pro, v rámci aktuálního rozsahu mapy, během sekund.
Žádná mezilehlá kopie, žádný databázový server v dodavatelském řetězci.
Abych se trochu vrátil zpět, jsem trochu ambiciózní s názvem blogu, toto není podporovaná Query Layer edice, ale může to být „dostatečně dobrá“ aproximace pro mnoho případů použití, a nejen pro jednu relaci – data můžete obnovit na vyžádání.
Jak to funguje? V příloze blogu je nástroj ArcGIS Pro 3.7 obsahující skriptový nástroj Make Serverless Query Layer se dvěma vstupními parametry, where klauzulí filtrující stažená data a booleanem určujícím, zda má výstupní schéma textová pole s výchozí šířkou nebo s šířkou odvozenou z dat, což nazývám „ladění“.
Zdrojová data, detekce rozsahu mapy a definice pohledu jsou v nástroji pevně zakódovány.
Takto vypadá dotaz definice pohledu:
# Dotaz na 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};"""
My dotazujeme GeoParquet v S3 pomocí DuckDB, takže SQL syntaxe výše je pro DuckDB. Není zde ukázáno čtení názvu vydání Overture ze STAC katalogu, který Overture udržuje, abychom mohli vložit hodnotu do f-string dotazu.
Věci k upozornění v kódu:
- Používají se DuckDB SQL funkce
- Složité sloupce jsou zjednodušeny do jedné hodnoty pro jednoduchost
- Jsou dotazovány jak prostorový operátor ST_Intersects, tak i bbox struktura vlastnosti
Nechte si kód skriptového nástroje prohlédnout podle libosti, ale další pozoruhodný aspekt je čtení dat do Apache Arrow tabulky na cestě k tomu stát se paměťovou třídou prvků. Arrow tabulky mohou být použity místo nativních tříd prvků ArcGIS jako parametry geoprocessingu, nicméně jsem našel chybu vyžadující dvojí zpracování dat (přesun dat přes samostatnou paměťovou třídu prvků místo přímého připojení k cílovému výstupu), takže můžete očekávat rychlejší výkon až bude tato chyba opravena.
Pro spuštění nástroje nejprve přidejte přiložený toolbox blogu do svého projektu, poté aktivujte mapu nebo scénu v rozsahu, o který máte zájem – mějte na paměti, že všechna data Places v rozsahu budou načtena pomocí výchozí where klauzule "1 = 1" – pak zvolte zda ladit (nebo ne) textová pole a klikněte na Spustit. Vyzkoušejte vzorové where klauzule ve skriptovém nástroji:
Zde je přibližně 5 400 obchodů s potravinami ve větším Londýně, GB když byla moje mapa ve škále 1:500K při spuštění:
Co se týče ladění textových polí v datech: Formáty založené na souborech (např. GeoParquet, CSV, JSON) obvykle nepřicházejí s definicí schématu (kromě EsriJSON). V ArcGIS různé nástroje volí různé šířky textových polí, což může vést k tomu, co je v oboru známo jako „patologické schéma“, například neladěná data v tomto vzorku by vytvořila textová pole široká 5000 bajtů. Obvykle to není problém, ale může být v závislosti na tom, kam data putují dál – například pomalejší výkon v geodatabázi nebo feature service u velkých dat. Protože pravděpodobně nepracujeme s velkými daty pomocí tohoto vzorku, pravděpodobně můžete zvolit neladit výstupy, ale každopádně máte alternativní přístup.
Pokud opravdu máte ve svých datech sloupce velikosti dokumentu, můžete nástroj spustit bez ladění a následně spustit Export Features, abyste nastavili vlastní šířky sloupců pomocí ovládání mapy polí v tomto nástroji.
Pokud byste chtěli skutečnou „serverless query layer“, požádejte svého zástupce Esri o tuto funkci! Znám kolegu testujícího některé přístupy pomocí Pro SDK, ale váš vstup je neocenitelný.
