Aktualizace: ArcGIS Pro 3.4/ArcGIS Enterprise 11.4 zavedly Spouštěcí pole což ovlivňuje diskusi o zmírnění dopadů úprav pomocí eventů.
Správa podsítí často zahrnuje stovky nebo tisíce úprav prvků při vytváření nebo přeconfigurování podsítě. Z tohoto důvodu systém nabízí několik různých režimů úprav, které lze použít k provedení těchto aktualizací. Více informací o tomto tématu najdete v téma Podsítě v online nápovědě.
Přečtením tohoto článku pochopíte dopad tohoto nastavení na výkon nástroje update subnetwork a proč byste pro určité pracovní postupy mohli chtít povolit eventing, i když to ovlivní výkon.
Co je režim úprav?
Co je to režim úprav? V ArcGIS Utility Network označuje režim úprav způsob, jakým software spravuje systémová pole u prvků při správě podsítí. V současnosti jsou k dispozici dvě možnosti režimů úprav, s eventingem nebo bez eventingu.
Co znamená „eventing“, když říkáme, že data spravujeme s eventingem nebo bez eventingu? Když mluvíme o eventingu, máme na mysli konkrétně geodatabázové události, které se spouštějí v reakci na úpravy. Geodatabázové události jsou jedním ze způsobů, jak ArcGIS spouští speciální chování při úpravách objektů v geodatabázi. Běžné příklady zahrnují vyplňování polí sledování editoru, spouštění atributových pravidel, zasílání zpráv o změnách souvisejících objektů a aktualizaci anotací propojených s prvky.
Jak to souvisí s podsítěmi? Jedním z nástrojů, které uživatelé běžně používají jako součást svého pracovního postupu úprav, je nástroj update subnetwork. Tento nástroj spravuje systémová pole u prvků utility network, která popisují podsíť, do které patří. Při každé úpravě těchto prvků se spustí různé editační události. Datové modely obsahující vztahy nebo atributová pravidla vyvolají během update subnetwork více událostí než modely s méně vztahy a atributovými pravidly. Všechny tyto události, pravidla a vztahy přidávají další čas k procesu update subnetwork.
Aby tuto situaci zvládli, mohou správci nakonfigurovat vrstvy ve své síti tak, aby používaly režim úprav buď s běžnými geodatabázovými událostmi (s eventingem) nebo obcházející běžný model geodatabázových událostí (bez eventingu) při správě podsítí v dané vrstvě. Na konci tohoto článku je krátká diskuse o tom, jak vyhodnotit obchodní požadavky a nejlepší postupy pro toto rozhodnutí. Kromě toho můžete také použít spouštěcí pole k přesné kontrole, na které úpravy atributová pravidla reagují, abyste zmírnili dopady editačních událostí během update subnetwork.
Nyní si však ukážeme několik příkladů různých konfigurací. V každém příkladu budeme sledovat, jak sada prvků reaguje za určitých podmínek. Každý prvek je označen 4 poli a když je hodnota upravena, pole/hodnota se zobrazí tučně:
- Asset ID – Jedinečný identifikátor každého prvku. Je vyplněn při vytvoření prvku.
- Date Modified – Pole sledování editoru spravované geodatabází.
- Subnetwork Name – Pole názvu podsítě spravované utility network.
- Network Region – Toto pole spravuje atributové pravidlo, které používá název podsítě prvku k získání hodnoty 'region' z vyhledávací tabulky.
Poznámka: Pokud žádné atributové pravidlo nevyžaduje informace z podsítě, lze všechna atributová pravidla nakonfigurovat tak, aby se nespouštěla při aktualizacích provedených během update subnetwork a tím zmírnila dopad na výkon způsobený atributovými pravidly během update subnetwork.
Aktualizace bez eventingu ve výchozím nastavení
První příklad ukazuje něco, co každý projekt dělá alespoň jednou. Spuštění update subnetwork na výchozí verzi v zcela nové databázi. V tomto případě mají všechna pole názvu podsítě v databázi hodnotu ‚Unknown‘ a ostatní pole mají své počáteční hodnoty z načtení dat. Příklad vidíte na obrázku níže.
Obrázek 1 Počáteční stav databáze
Po spuštění update subnetwork na Síti A vidíme, že pole názvu podsítě bylo aktualizováno u všech prvků v podsíti, ale sledování editoru a atributová pravidla nebyla během těchto aktualizací spuštěna. Pokud by některé třídy měly anotace propojené s prvky, anotace by také nebyla během této události upravena.
Obrázek 2 Update subnetwork ve výchozím nastavení bez eventingu
Nyní porovnejme toto s chováním systému při stejném kroku s režimem úprav nastaveným na s eventingem.
Aktualizace s eventingem ve výchozím nastavení
Když je utility network nakonfigurována tak, aby aktualizovala podsíť s eventingem, znamená to, že všechny chování geodatabáze budou spuštěny při aktualizaci atributů prvku nástrojem update subnetwork. Kdyby byl předchozí příklad spuštěn s eventingem, výsledky by vypadaly jako na diagramu níže.
Obrázek 3 Update subnetwork ve výchozím nastavení s eventingem
Vidíte, že kromě vyplnění pole názvu podsítě bylo také aktualizováno pole Last Modified sledováním editoru a pole Operating Area bylo aktualizováno naším atributovým pravidlem. Kromě toho by byly aktualizovány i anotace propojené s prvky odkazující na jedno nebo více těchto polí.
Všechny tyto další spouštěče a aktualizace však přinášejí výkonový náklad. Pokud máte mnoho atributových pravidel a/nebo tříd anotací propojených s prvky, měli byste pečlivě zvážit dopad na váš systém.
Aktualizace bez eventingu v pojmenované verzi
Nejzajímavější situace je sledovat chování update subnetwork při spuštění v pojmenované verzi bez eventingu. To je výchozí chování systému kvůli nejvyššímu výkonu.Při spuštění update subnetwork v pojmenované verzi bez eventingu má nevýhodu v tom, že nemůže aktualizovat informace o podsíti u prvků, které ještě nebyly upraveny v této verzi. Pokud se vám nelíbí chování z těchto příkladů, pamatujte, že jsme zavedli novou možnost k překonání těchto omezení diskutovanou v následující části (Aktualizace s eventingem v pojmenované verzi).
Abychom tuto problematiku plně probrali, zvážíme dva samostatné příklady situací, kdy může spuštění update subnetwork v pojmenované verzi přinést neočekávané výsledky. Stojí za zmínku, že i když nástroj nemusí za všech okolností produkovat očekávané výsledky ve verzi, po publikování verze do výchozí verze a spuštění update subnetwork ve výchozím nastavení bude výsledek správný.
Nově vytvořené prvky
Náš první příklad navazuje na předchozí. Předpokládejme databázi bez informací o podsítích a před spuštěním update subnetwork ve výchozím nastavení vytvoříme novou pojmenovanou verzi a přidáme novou službu do této verze. Zde je obrázek nově vytvořených prvků ve verzi před spuštěním update subnetwork:
Obrázek 4 Nové prvky vytvořené v pojmenované verzi
Po spuštění update subnetwork bez eventingu v pojmenované verzi si všimnete něčeho zajímavého.Pouze prvky vytvořené v této verzi mají vyplněný název podsítě.
Obrázek 5 Aktualizace nových prvků v pojmenované verzi bez eventingu
Při spuštění update subnetwork bez eventingu v pojmenované verzi lze aktualizovat pouze prvky vytvořené nebo upravené v této verzi. Je to proto, že pokud prvek ještě nebyl upraven ve verzi, vyžadovalo by to spuštění geodatabázové události pro vložení úpravy do verze.
Existující prvky
V dalším příkladu se podíváme na praktický případ neočekávaných výsledků při spuštění update subnetwork bez eventingu v pojmenované verzi. Budeme sledovat reakci update subnetwork na úpravu vedoucí ke změně přináležitosti prvků z jedné podsítě do druhé.
Začínáme se dvěma podsítěmi (Síť A a Síť 
), které jsou odděleny spojovacím zařízením (otevřený vypínač, zavřený ventil atd.). Všechny podsítě byly aktualizovány ve výchozí verzi a všechny atributy jsou správně vyplněny. Protože spojovací zařízení patří do více podsítí, pole názvu podsítě je odděleno středníky.
Obrázek 6 Dvě podsítě ve výchozím nastavení
V tomto příkladu změníme spojovací zařízení mezi podsítěmi ze zařízení 3 na zařízení 1. To se často děje v reálném světě při přeconfiguraci okruhů nebo tlakových zón kvůli dlouhodobým či sezónním změnám poptávky zákazníků. Změníme stav těchto dvou zařízení tak, aby zařízení 1 bylo nyní spojovacím zařízením a zařízení 3 již nefungovalo jako bariéra.
Obrázek 7 Aktualizované spojovací zařízení
Tyto změny vidíme na diagramu výše: indikátor spojovacího zařízení se přesunul ze Zařízení 3 na Zařízení 1, datum poslední úpravy bylo aktualizováno a barvy prvků byly změněny tak, aby vizuálně ukazovaly příslušnost k jednotlivým podsítím při trasování každé z nich. Názvy podsítí stále zobrazují staré hodnoty protože jsme ještě nespustili update subnetwork. Níže je diagram znázorňující všechny změny atributů po spuštění update subnetwork za těchto podmínek.
Obrázek 8 Aktualizovaná podsíť v pojmenované verzi
Jak očekáváme, pole názvu podsítě bylo aktualizováno u obou zařízení upravených v této verzi.Nicméně prvky dříve připojené k Síti A a nyní připojené k Síti B stále mají staré hodnoty názvu podsítě a provozní oblasti. Protože tyto prvky nebyly upraveny v této verzi, update subnetwork je nemůže upravit bez spuštění editačních událostí.
Oba tyto příklady zdůrazňují omezení aktualizace podsítí v pojmenovaných verzích bez eventingu. Pro mnoho zákazníků jsou tato omezení přijatelná kvůli výhodám výkonu tohoto režimu úprav a protože data se zobrazí správně, jakmile jsou data odeslána do default a spustí se aktualizace podsítě, kde všichni mohou vidět výsledky. Nicméně jiní zákazníci byli ochotni akceptovat delší dobu běhu aktualizace podsítě, aby splnili určité obchodní požadavky. Proto jsme zavedli možnost aktualizace podsítě s editací s eventingem jak si vysvětlíme v následující části.
Aktualizace s eventingem v pojmenované verzi
Pojďme znovu prozkoumat dva výše uvedené scénáře a podívat se, jak se chovají při aktualizaci podsítě v pojmenované verzi, když je vrstva nakonfigurována tak, aby měla režim úprav s eventingem.
Nově vytvořené prvky
Níže vidíme první příklad, kde je směs existujících a nových prvků, které je třeba aktualizovat.
Obrázek 9 Nové prvky ve verzi
A následuje výsledek po spuštění aktualizace podsítě s eventingem.
Obrázek 10 Aktualizace podsítě s eventingem v pojmenované verzi
Jak vidíte, všechny prvky mají správný název podsítě a provozní oblast. Síť bude trvat déle na zpracování, protože upravuje více prvků a protože každý prvek spustí další úpravy pro zpracování sledování editorů, pravidel atributů atd.
Existující prvky
Dále se podíváme na druhý příklad, kde jsme přeorganizovali několik podsítí. Níže jsou data před spuštěním aktualizace podsítě.
Obrázek 11 Prvky ve verzi před aktualizací podsítě
A níže je stav prvků po spuštění aktualizace podsítě v pojmenované verzi s eventingem.
Obrázek 12 Nové prvky ve verzi
Opět můžete vidět, že všechny atributy na prvcích mají správné hodnoty. Stojí za zmínku, že to bude trvat déle než provedení stejné operace bez eventingu. Přesto doba trvání bude přímo souviset s počtem/komplexitou pravidel atributů, která máte nakonfigurována na svých prvcích, spolu s počtem vztahů s povoleným zasíláním zpráv (včetně feature-linked annotation). Je vhodné měřit a zvážit tyto náklady na výkon vzhledem k důležitosti vizuální kontroly/review atributů síťových informací během vašeho procesu kontroly kvality.
Konfigurace
Nyní, když jste viděli, jak tyto chování fungují, podívejme se, jak jsou nakonfigurovány v utility network. Tyto možnosti jsou konfigurovány pomocí nástroje Set Subnetwork Definition. Protože tento nástroj umožňuje upravit konfiguraci pro konkrétní vrstvu ve vaší síti, znamená to, že můžete definovat různé chování pro každou vrstvu (např. System a Pressure). I když je příjemné mít možnost mít různé chování pro každou vrstvu, většina zákazníků preferuje mít všechny své vrstvy nastavené stejně, aby zajistili konzistentní pracovní postupy úprav pro editory.
Při nastavování režimu úprav pro definici podsítě jsou dvě různá pole, každé se dvěma různými možnostmi. To znamená, že existují čtyři kombinace hodnot, které můžete nakonfigurovat pro své režimy úprav:
- Bez eventingu v defaultu, bez eventingu v pojmenovaných verzích (výchozí)
- Bez eventingu v defaultu, s eventingem v pojmenovaných verzích
- S eventingem v defaultu, s eventingem v pojmenovaných verzích
- S eventingem v defaultu, bez eventingu v pojmenovaných verzích
Než strávíte příliš mnoho času přemýšlením o tom, kterou ze čtyř možností vybrat, měli byste vědět, že základní datové modely utility network poskytované Esri již mají své režimy úprav nakonfigurovány. Každý z těchto datových modelů má doporučenou sadu konfigurací vyvinutou odborníky z oboru spolu s jejich komunitou tak, aby konfigurace vyhovovala co nejširšímu spektru pracovních postupů pro daný obor.
I když tyto konfigurace vyhovují potřebám většiny zákazníků, je vždy dobré tyto konfigurace přezkoumat v kontextu vašich obchodních požadavků a jakýchkoli změn konfigurace/datového modelu, které jste provedli, abyste zajistili, že typická konfigurace je stále nejvhodnější.
Nejlepší postupy
Nejčastější otázka, kterou dostávám, je jaký je nejlepší postup pro konfiguraci režimu úprav ve utility network? Neexistuje jedna odpověď platná pro všechny zákazníky. Existuje však několik kritérií k zvážení, která vám pomohou rozhodnout se, která možnost je pro vás nejvhodnější. Tato kritéria obvykle spadají do tří kategorií: pracovní postupy, anotace a pravidla atributů.
Prvním faktorem je váš verzionovaný pracovní postup úprav. Pokud váš pracovní postup úprav vyžaduje provádění kontroly kvality v pojmenovaných verzích a tento proces zahrnuje používání nástrojů nebo vrstev závislých na atributech uložených na prvcích (název podsítě, propagované hodnoty atd.), pak budete chtít nastavit režim úprav pro pojmenované verze na „S Eventingem“. To zajistí správné naplnění polí podsítě pro všechny prvky ve vaší verzi tak, aby mohly být použity při kontrole kvality. Pokud lze váš QA proces provést zcela v defaultu nebo může používat trasování místo spoléhání se na atributy prvků, můžete nastavit režim úprav pro pojmenované verze na „Bez Eventingu“.
Druhým faktorem je zda máte feature-linked annotation. Pokud nemáte feature-linked annotation nebo anotace neobsahují informace z podsítě (název podsítě, propagované hodnoty atd.), pak je vhodná kterákoliv možnost režimu úprav. Vztahové třídy s povoleným zasíláním zpráv jako feature-linked annotation třídy mají výkonový dopad při úpravách, který musíte pečlivě sledovat. Důležitější však je pokud vaše feature-linked annotation obsahuje informace o podsíti – musíte učinit rozhodnutí. Ukládání informací o podsíti do anotací není považováno za nejlepší praxi kvůli statické povaze anotací a dynamické povaze podsítí a výkonovým nákladům udržování synchronizace obou. Měli byste zvážit nahrazení těchto feature-linked annotation funkcemi štítků (labels). Pokud je to však tvrdý požadavek, musíte nastavit režim úprav na „S Eventingem“ jak pro pojmenované verze tak i default k zajištění aktualizace textu anotací při spuštění aktualizace podsítě; buďte však připraveni na dopad na výkon této operace.
Třetím faktorem jsou pravidla atributů definovaná na vašich prvcích utility network. Jakékoli pravidlo atributu nastavené k aktivaci při aktualizaci bude vyhodnoceno kdykoli je daný prvek aktualizován bez ohledu na pole jeho přiřazení. To znamená že pokud používáte režim úprav s eventingem, všechna pravidla okamžitého výpočtu budou spuštěna během aktualizace podsítě u všech upravovaných prvků. Pokud je to tvrdý požadavek a jste ochotni akceptovat výkonové náklady, měli byste přezkoumat svá pravidla atributů tak aby obsahovala logiku časného ukončení během aktualizace podsítě ke snížení těchto nákladů. Pokud máte pravidla atributů reagující na změny polí podsítě vězte že to není považováno za nejlepší praxi. Pokud je to však tvrdý požadavek musíte nastavit režim úprav na „S Eventingem“ k zajištění spuštění pravidla atributu během aktualizace podsítě.
S těmito faktory na paměti si projdeme čtyři možnosti a uvidíme kde jsou nejvhodnější.
Bez eventingu v defaultu i bez eventingu v pojmenovaných verzích. Tato možnost představuje výchozí chování systému. Poskytuje nejlepší výkon ale má omezení při aktualizaci prvků ve verzích a feature-linked annotation.
Bez eventingu v defaultu a s eventingem v pojmenovaných verzích. Tato možnost představuje kompromis mezi výkonem a funkčností. Poskytuje nejlepší výkon při aktualizaci podsítě v defaultu a nejlepší zážitek z kontroly kvality v pojmenované verzi.
S eventingem v defaultu i s eventingem v pojmenovaných verzích. Tato možnost nabízí nejvíce funkcionalit ale také nejvyšší náklady na výkon. Pokud tuto konfiguraci implementujete měli byste přezkoumat všechna pravidla atributů nastavená ke spuštění při modifikaci prvků aby byla nakonfigurována s logikou časného ukončení během aktualizace podsítě.
S eventingem v defaultu bez eventingu v pojmenovaných verzích. Toto je nejméně běžná konfigurace určená pro zákazníky kteří potřebují spouštět anotaci nebo pravidla atributů pouze v defaultu ale ne ve verzích.
Závěr
Nyní když jste si přečetli tento článek byste měli rozumět výhodám/nevýhodám různých režimů úprav používaných pro správu podsítí a měli byste být schopni určit které režimy jsou vhodné pro váš datový model, pracovní postupy úprav a obchodní požadavky.
Pokud chcete zjistit jak zmírnit dopady výkonu editačních událostí na pravidla atributů přečtěte si článek Spouštění pravidel atributů podle polí.
Pokud chcete vědět více o správě podsítí nebo si vyzkoušet praktické návody najdete příklady specifické pro odvětví v sérii vzdělávacích materiálů Začínáme s ArcGIS Utility Network.
Pokud chcete podrobnosti a hlubší pohledy na možnosti správy podsítí utility network doporučuji podívat se na další technické články na stránce komunity ArcGIS Utility Network. Stránka komunity Esri
