Exportovat a synchronizovat vektorová data

ChristineBrunner

<\/HEAD>

Produktová rodina ArcGIS Runtime SDKs<\/A> je od verze 10.2 schopná práce offline. Přitom lze exportovat podkladové mapy a vektorová data ze služeb a v případě vektorových dat je také synchronizovat. Aby tyto funkce byly názorné, vyvinula společnost Esri Deutschland demoaplikaci, která simuluje offline funkčnost Collector for ArcGIS<\/A> s ArcGIS Runtime SDK pro .NET<\/A> a Java<\/A>. Tato demo nese název Collector Light a je zveřejněna na GitHub<\/A>. Navíc již vyšel i blog<\/A> k tomuto tématu.<\/SPAN><\/P>

V tomto článku se nyní na příkladu Java demo podrobněji podíváme na proces exportu a synchronizace vektorových dat.<\/SPAN><\/P>

<\/H2>Je třeba provést několik příprav<\/SPAN><\/H2>Demo používá jako zdroj dat <\/SPAN>WebMap<\/A><\/SPAN>. Ta ale není nezbytně nutná. Pro možnost exportu vektorových dat je potřeba pouze FeatureService. Ten může být hostován jak na ArcGIS Online<\/A>, v Portal for ArcGIS<\/A> nebo na vlastním ArcGIS for Server<\/A>. Je třeba dbát na to, že ve službě je aktivován proces „Synchronisieren“. Na ArcGIS for Server lze toto nastavit v ArcGIS Server Manageru u dané služby pod Funkce -> Feature Access.<\/SPAN><\/SPAN><\/P>

<\/P>

V ArcGIS Online a Portal for ArcGIS pak v Properties služby.<\/SPAN><\/P><\/SPAN><\/P>Po aktivaci této funkce služba nabízí další REST rozhraní. Pomocí operace „Create Replica“ lze data stáhnout offline. „Synchronize Replica“ slouží k synchronizaci dat a pomocí „Unregister Replica“ lze data smazat. O tom ale později více.<\/SPAN><\/P><\/P>

<\/H2>Nyní konečně začíná programování<\/SPAN><\/H2>Tyto REST rozhraní ale nemusíme implementovat přímo. Jsou již zabaleny v ArcGIS Runtime SDK pro Java tak, že máme k dispozici Java třídy a metody pro jejich použití. Použití pro export vektorových dat najdeme v demu ve třídě action.CreateOfflineProject. Konkrétněji v metodě createGeodatabaseFromService. <\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/>.
Po malé úpravě dat kvůli použití WebMap začíná zajímavá část v řádku 330 vytvořením GenerateGeodatabaseParameters</ A >..< / span >.< / span >.< / p >.< p >.< / p >.< pre class= "lia-code-sample line-numbers language-none ">//nastavení parametrů
                                      
  GenerateGeodatabaseParameters params = new GenerateGeodatabaseParameters(
       ArrayUtils.toPrimitive(layerIds.toArray(new Integer[layerIds.size()])),
       extent,
       map.getSpatialReference(),
       false,& nbsp;
 & nbsp;
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 





































gdbTask.generateGeodatabase(params,pathToGdb,false,statusCallback,gdbResponseCallback); Inicializovat databázi pomocí třídy Geodatabse. Pro každou jednotlivou vrstvu se vytvoří GeodatabseFeatureTable.<\/SPAN><\/P><\/P>Geodatabase localGeodatabase = new Geodatabase("PathToGeodatabase");
  for (GeodatabaseFeatureTable table : localGeodatabase.getGeodatabaseTables()) {
  FeatureLayer featureLayer = new FeatureLayer(table);
  featureLayer.initializeAsync();
}<\/PRE><\/P>Chci zase volat domů<\/SPAN><\/H2>Tak, teď jsou data offline. Můžeme se nyní volně pohybovat daleko od digitální civilizace a sbírat, měnit nebo mazat data. Ale jednou přijde okamžik, kdy budeme chtít své změny sdílet s kolegy. Navíc mě možná zajímá, co dělali během mé nepřítomnosti. Musíme tedy navázat kontakt s mateřskou lodí (FeatureService). V demo aplikaci se to děje ve třídě action.SyncProject. Metoda syncGeodatabase ve známé třídě GeodatabaseSyncTask nám s tím pomáhá.<\/SPAN><\/P><\/P>gdbTask.syncGeodatabase(syncParams, gdb, statusCallback, syncResponseCallback);<\/PRE><\/P>Opět vidíme dva callbacky pro stavové zprávy a pro výsledek. Jako další parametry potřebujeme Geodatabase (gdb) a speciální SyncGeodatabaseParameters. Geodatabase jsme již vytvořili v předchozím kroku pro vizualizaci dat. A o SyncParametry se nemusíme starat, protože je generuje Geodatabase.<\/SPAN><\/P><\/P>final SyncGeodatabaseParameters syncParams = gdb.getSyncParameters();<\/PRE><\/P>Výhodou je, že nemusíme znát složitou strukturu databáze, abychom extrahovali naše změny. Přenáší se vždy jen delta, ne celá databáze. Při synchronizaci se také všechny změny na službě přenesou do mé lokální databáze, takže mohu pokračovat s aktuálními daty. I zde se přenáší pouze delta. To je patrné i na následujícím obrázku, který schematicky znázorňuje celý workflow.<\/SPAN><\/P><\/P><\/P>Pokud více kolegů provedlo změny na jednom záznamu, vždy vyhrává poslední změna. Přičemž rozhodující je časová značka synchronizace a ne časová značka změny. V budoucnu budou k dispozici i jiné možnosti řešení konfliktů, které bude možné nastavit pro každou službu zvlášť. Aktuálně to však ještě není možné.<\/SPAN><\/P><\/H2>Ukončeme život poustevníka<\/SPAN><\/H2>Jednou se snad vrátíte zpět do kanceláře a už nebudete potřebovat lokální kopii dat. Pak je důležité ji nesmazat jen tak, ale nejdříve provést odregistrování u služby. K tomu máme opět k dispozici třídu GeodatabaseSyncTask, tentokrát s metodou unregisterGeodatabase.<\/SPAN><\/P><\/P>gdbTask.unregisterGeodatabase(gdb, unregisterCallback);<\/SPAN><\/PRE><\/P>V demo aplikaci najdete tento volání ve třídě action.DeleteProject. Proč je toto volání tak důležité? FeatureService vytváří pro každou kopii tzv. Replica. Ta obsahuje informace o kopii jako například čas poslední synchronizace. Tyto údaje jsou potřeba k fungování synchronizačního mechanismu. Při odregistrování se tato Replica smaže, protože služba pak ví, že lokální kopie už není potřeba. Repliky služby si můžete také prohlédnout v jejím Service Directory.<\/SPAN><\/P><\/P><\/P><\/BODY><\/HTML>