Vždy je uspokojivé sdílet nové silné způsoby řešení problémů, zvláště když bylo řešení "skryto na očích" už nějakou dobu. Tentokrát ukazuji, jak kombinace ArcGIS Enterprise branch versioning a cloud native data sharing přináší nejen rychlý přístup k datům lidem bez přístupu k portálu, ale i možnost požádat přístupná data, aby cestovala zpět v čase, kdy byla mladší. Jako tyto parcely, uvidíte dříve nerozdělenou parcelu a nyní její tři pododdělení.<\/P>
Parcel subdivision<\/span><\/span>Parcel subdivision<\/SPAN><\/SPAN><\/SPAN><\/P>Představte si dataset s miliony prvků a pod těžkou denní údržbou, jak je branch versioning navržen zvládnout, vaši zákazníci mohou přistupovat ke všem nebo jakékoli části výchozí verze pro jakýkoli okamžik v čase. Navždy. Bez další zátěže na váš Enterprise portál.<\/P>Jak jsem se k tomu dostal? Jednoduše jsem si všiml, že insert-only transakční model branch versioning je vhodný pro inkrementální vytváření GeoParquet souborů v cloudovém úložišti, které společně uchovávají stav dat v čase a lze je dotazovat prostorově i časově, aby bylo možné na vyžádání vytvořit lokální data pro vaši oblast a čas zájmu.<\/P>Je to však velmi složitý dotaz! Dobrá zpráva ale je, že ho nemusíte sami rozluštit, blogový download obsahuje notebook s příklady pro mé téma parcel, stačí vložit vaše vlastní.<\/P>Nemusel jsem vymýšlet přístup k dotazu, Esri zveřejňuje materiály z workshopů na toto téma. Například pokud přejdete kolem 18. minuty této prezentace, uvidíte, jak takový dotaz vypadá.<\/P>Spoiler<\/a>přidáte archive class do mapy, jsou dostupná:<\/P>
Archive class added to the map<\/span><\/span>Archive class added to the map<\/SPAN><\/SPAN><\/SPAN><\/P>Několik věcí k poznámce ve fields mapě: ObjectID je degradován na obyčejné dlouhé celé číslo (hodnoty už nejsou unikátní) a jsou přidána různá pole pojmenovaná GDB_*. Ta umožňují zobrazit data v určitém okamžiku času, což je princip branch versioning - nejnovější stav prvku vítězí, což může být i stav smazaný, ale historie dat nezmizí (pokud ji nesmažete), což umožňuje cestování časem.<\/P>Archive class je také dobrá pro zjištění, jaké editační momenty jsou ve vašich datech.<\/P>S archive class poskytující viditelnost všech polí byl možný workflow sdílení a údržby. Probíhá takto:<\/P>Vytvořit počáteční parquet soubor se všemi řádky archive class, kde GDB_BRANCH_ID = 0<\/LI>Podle libovolného smysluplného plánu vytvářet delta parquet soubory pro nové stavy řádků výchozí větveTy mají GDB_FROM_DATE pozdější než maximum ve všech existujících parquet souborech<\/LI>Také mají GDB_BRANCH_ID = 0<\/LI><\/UL><\/LI>Udržovat všechny parquet soubory ve vašem oblíbeném S3-kompatibilním objektovém úložišti na globální cestě<\/LI>Dát svým zákazníkům dat notebook nebo skriptový nástroj, který mohou použít k extrakci datDodaný notebook vyžaduje DuckDB verzi 1.0.0 v Python prostředí<\/LI><\/UL><\/LI><\/UL>Nyní to inzeruji jako cloud native distribuci dat, ale při psaní ještě nastavují svůj AWS účet, takže přiložený notebook používá lokální cestu k souborovému systému, aktualizuji to až budu mít veřejnou S3 URL cestu. Mezitím si můžete stáhnout vzorová data pro testování zde, zde, zde a zde. Jsou to počáteční hromadná verze kopie a několik inkrementálních delta souborů s několika dny editací každý. Změňte proměnnou pqPath v notebooku podle svého prostředí dokud nenastavím S3 cestu.<\/P>Spoiler<\/A>Data která používám nejsou skutečně udržována v branch verzované geodatabázi, vytvořil jsem vzorová data, laskavě viz oprávnění k datům v detailech položek výše uvedených odkazů.<\/DIV>
Data která používám nejsou skutečně udržována v branch verzované geodatabázi, vytvořil jsem vzorová data, laskavě viz oprávnění k datům v detailech položek výše uvedených odkazů.<\/DIV><\/DIV>
V notebooku poskytuji šablonu pro extent a time travel dotazy. Zjistil jsem, že mohu extrahovat všech 2.7 milionu parcel ve svých datech za něco málo přes 3 minuty z lokálního disku. Přístup ze S3 očekávám být trochu pomalejší, uvidíme až to budu mít nastavené. Vyzkoušejte si notebook sami.<\/P>
Můžete mít pár otázek ohledně notebooku, pokusím se předvídat několik:<\/P>
- Používá se DuckDB 1.0.0 protože je v Esri Conda kanálu a novější verze pracují s geometrií jinak<\/LI>
- Sloupec bbox v parquet souborech je typu JSON ale dotazuje se jako varchar protože DuckDB nepoznal data jako JSON<\/LI>
- Zkoušel jsem použít vestavěný pseudosloupec rowid v DuckDB ale dostal jsem chyby, tak jsem ho přepsal<\/LI>
- Zkoušel jsem zapisovat výstupní feature class přes prostorově povolený dataframe ale dostal jsem chyby<\/LI>
- V blogovém downloadu má projekt atbx skriptový nástroj který jsem použil k nalezení požadovaných šířek textových polí výstupu<\/LI><\/UL>
Nyní budu trochu sobecký. Pro vytvoření svých vzorových dat a parquet souborů jsem postavil pár ETL nástrojů (Pro 3.4), které bych mohl napsat jako skripty. Tyto nástroje nejsou v blogovém downloadu. Pokud máte o ně zájem napište mi prosím a mohu je sdílet. Pomůže nám to zdejšímu týmu pokud uslyšíme kolik lidí má zájem o tento paradigm sdílení dat, tak nám prosím pomozte pomoci vám.<\/
