<\/HEAD>
Momentálně jsme ve fázi vývoje a testování implementace Parcel Fabric pro náš okres a narazili jsme na EXTRÉMNÍ problémy s výkonem, na které nikdo zdá se nemá odpověď.<\/P>
<\/P>
Jako krátké pozadí: Už před několika měsíci jsme dokončili rozsáhlý proces čištění našich parcel – zjednodušili jsme čáry odstraněním nadbytečných vrcholů a většinu z nich planarizovali na 2-bodové čáry (kromě menšiny hranic parcel sledujících přírodní prvky jako hydro, atd., které zůstaly jako linestringy). Toto čištění odstranilo přes 10 milionů nadbytečných vrcholů. Naše očištěná data parcel a rozdělení byla dále zpracována a nahrána do staging schématu poskytovaného ESRI (FGDB), kde byly opraveny všechny topologické chyby/problémy, a nakonec nahrána do nového Fabricu (FGDB). Tento zdrojový Fabric FGDB byl následně nahrán do našeho Development SDE (ArcSDE 10.3.1 | Oracle 11.2.0.3) databáze pomocí nástroje Copy Parcel Fabric.<\/P>
<\/P>
První problém s výkonem jsme zaznamenali při pokusu o registraci Fabricu jako verzovaného. Protože proces verzování spouští sérii „analyz“ na všech objektech/tabulkách Fabricu před samotnou registrací, proces se zdá být zaseknutý – ve skutečnosti však trvá velmi dlouho, než se dokončí. V našem případě „velmi dlouho“ znamená, že jak feature class „Parcels“, tak „Lines“ trvaly každá 4-5 hodin na dokončení. Povrchní pohled na tabulky (a jejich různé vytvořené indexy) odhalil, že samotná feature class „Lines“ má 2,9 milionu řádků/záznamů. Ačkoliv mě to trochu znepokojuje, nikdo v ESRI nenaznačil, že by to bylo nějak extrémní.<\/P>
<\/P>
Po konečné registraci jsem začal s jednoduchým testováním úprav, hlavně zaměřeným na jednoduché Parcel Fabric workflow jako je rozdělení parcely. Okamžitě v bodě workflow, kdy je aktivován Construction nástroj, kurzor/křížek vykazuje otupující latenci, mění se na ukazatel s přesýpacími hodinami při pohybu přes mapové okno (jako by probíhala intenzivní operace). Pokud kurzor necháte nehybný (přestanete pohybovat myší), křížek se vrátí po 10-15 sekundách… ale okamžitě se změní zpět na přesýpací hodiny, jakmile se pokusíte kurzor znovu pohnout. Pokud posunete nereagující ukazatel do dosahu přichycení ke konstrukční linii a počkáte, bude se chovat jako přichycený, jakmile se křížek vrátí. Odtud pokud POMALU posunete kurzor podél již přichycené linie, zůstane aktivním křížkem. Pokud se však pohnete příliš rychle nebo překročíte toleranci přichycení (10 pixelů), křížek se opět změní na přesýpací hodiny. Pokud jste dost trpěliví a začnete během této doby konstruovat liniový prvek, stejné chování bude pokračovat po celou dobu přidávání vrcholů a přichycování k odpovídajícím liniovým prvkům. Po dokončení můžete vytvořené prvky sestavit jako obvykle.<\/P>
<\/P>
Po dalším testování jsem zjistil, že pokud zapnu prostředí ‚Classic Snapping‘, které umožňuje ovládat, které vrstvy a typy prvků v TOC jsou dostupné pro přichycení (na rozdíl od novějšího výchozího prostředí přichycení, kde jsou všechny vrstvy stále povoleny pro přichycení), a vypnu přichycení u všech vrstev, problém s výkonem zmizí. V tomto bodě Fabric stále vynucuje přichycení k sobě samému (což je nutné), i když jsou všechny vrstvy nastaveny tak, aby nebyly přichyceny. Okamžikem zapnutí Lines FC však výkon prudce klesne.<\/P>
<\/P>
Zajímavé je, že toto chování nenastává ve FGDB. To mě vede k závěru, že existuje nějaká unikátní interakce mezi ArcMapem, SDE a Oracle databází pokud jde o datově náročný Lines FC. Přestože ESRI poskytlo několik dalších způsobů přímé (pomocí SQL) reanalýzy tabulek Fabricu a regenerace prostorových indexů atd., žádné zlepšení nebylo dosaženo ani nikdo neidentifikoval (pomocí SDE Intercept a Oracle trace souborů) žádnou zjevnou úzkou hrdlo… Není to problém I/O ani SQL zpracování.<\/P>
<\/P>
Vrátím se ke svému obavám ohledně obrovského počtu záznamů v Lines feature class, ale nemám způsob jak potvrdit proč/zdali je to oprávněná obava. ArcMap evidentně zápasí s možností interakce s daty Lines v reálném čase, ale nemohu nabídnout funkční vysvětlení kromě svých pozorování. Jasně FGDB vytváří vlastní druh prostorových indexů a podobně u této velké feature class, ale běží hladce stejně tak. Naproti tomu Oracle by měl být ještě robustnější a měl by si poradit s datovou tabulkou o pouhých 3 milionech záznamů – přesto je výkon v tomto případě katastrofální. Takže stále docházím k závěru, že problém je něco co aplikace dělá a ne jen samotná databáze.<\/P>
<\/P>
Pokud má někdo podobné zkušenosti nebo vhled do tohoto problému, velmi bychom to ocenili!<\/P>
<\/P>
Gavin<\/P><\/BODY><\/HTML>
