Univerzita Palackého v Olomouci Přírodovědecká fakulta Katedra geoinformatiky
Martin DZÍBELA
MOŽNOSTI POKROČILÉ SPOLUPRÁCE GIS A .NET FRAMEWORKU Bakalářská práce
Vedoucí práce: Doc. Mgr. Jiří Dvorský, Ph.D.
Olomouc 2013
Čestné prohlášení Prohlašuji, že jsem bakalářskou práci bakalářského studia oboru Geoinformatika a geografie vypracoval samostatně pod vedením doc. Jiřího Dvorského. Všechny použité materiály a zdroje jsou citovány s ohledem na vědeckou etiku, autorská práva a zákony na ochranu duševního vlastnictví. Všechna poskytnutá i vytvořená digitální data nebudu bez souhlasu školy poskytovat.
V Olomouci 20. dubna 2013
……..……………………………...
OBSAH Úvod............................................................................................................................................................. 6 1
Cíle práce ......................................................................................................................................... 7
2
Použité produkty a technologie .......................................................................................... 8 2.1
2.1.1
Struktura .NET Framework ...................................................................................... 9
2.1.2
Sestavení (assembly)................................................................................................ 10
2.1.3
Programovací jazyk C# ............................................................................................ 11
2.1.4
Microsoft Visual Studio............................................................................................ 12
2.2
3
.NET Framework .................................................................................................................... 8
ArcObjects ............................................................................................................................. 12
2.2.1
Produkty ArcGIS ......................................................................................................... 13
2.2.2
Funkčnost ArcObjects .............................................................................................. 15
2.2.3
Možnosti vyžití ArcObjects..................................................................................... 15
2.2.4
Podpora vývoje na platformě .NET Framework ............................................ 17
Základy práce s ArcObjects ................................................................................................ 19 3.1
Object model diagrams (OMD) ...................................................................................... 19
3.1.1
Typy tříd ........................................................................................................................ 20
3.1.2
Vztahy mezi objekty.................................................................................................. 21
3.1.3
Rozhraní ........................................................................................................................ 21
3.2
Datový model ArcGIS a práce s daty ........................................................................... 23
3.2.1
Geodatabáze ................................................................................................................. 23
3.2.2
Workspace .................................................................................................................... 24
3.2.3
Datové sady (datasety) ............................................................................................ 25
3.3
Tabulky a třídy prvků (feature-based datasety) .................................................... 26
3.3.1
Schéma datasetu třídy prvků ................................................................................ 26
3.3.2
Procházení a filtrování dat ..................................................................................... 28
3.4
Geometrie prostorových dat .......................................................................................... 29
3.4.1
Prostorová reference ................................................................................................ 29
3.4.2
Základní objekty geometrie ................................................................................... 30 4
4
Vývoj ArcGIS for Desktop add-in ..................................................................................... 32 4.1
Charakteristika ArcGIS for Desktop add-in .............................................................. 32
4.1.1
Instalace a správa add-in doplňků ...................................................................... 32
4.1.2
Typy add-in objektů .................................................................................................. 33
4.1.3
Struktura add-in souborů ....................................................................................... 34
4.1.4
Desktop add-in šablony ........................................................................................... 35
4.2
Vlastní řešení add-inů pro aplikaci ArcMap ............................................................. 35
4.2.1
Export to Excel add-in .............................................................................................. 36
4.2.2
Bookmark from selection add-in ......................................................................... 37
4.2.3
Google reverse geocoding add-in ........................................................................ 37
5
Diskuse .......................................................................................................................................... 41
6
Závěr ............................................................................................................................................... 43
Použitá literatura a informační zdroje .................................................................................. 44 Summary ................................................................................................................................................ 46
5
ÚVOD Geoinformační technologie (GIS) představují relativně mladý obor, jehož vznik je úzce spojen s boomem informačních technologií v druhé polovině minulého století. V současnosti lze GIS chápat jako průnik hned několika vědních disciplín za účelem pořizování, správy, analýzy a prezentace geografických dat. Platforma .NET Framework je součástí moderního a robustního ekosystému pro vývoj a nasazování širokého spektra typů aplikací. Mezi vývojáři jde o velice rozšířenou platformu, jejíž obliba neustále roste. Navíc vzhledem k faktu, že za jejím vývojem stojí společnost Microsoft, která jí distribuuje jako součást svých operačních systémů Windows, to nevypadá, že by se na tomto trendu mělo (alespoň prozatím) něco měnit. Možností využití platformy .NET v GIS je nepochybně mnoho. Od vývoje vlastních desktopových geoinformačních systémů přes realizaci serverových řešení až po vývoj mobilních aplikací. Mimoto lze s pomocí .NET Framework rozšiřovat stávající GIS aplikace o novou specifickou funkčnost. Pochopitelně je nutné, aby aplikační rozhraní (API) dané aplikace platformu .NET podporovalo a aby toto API bylo alespoň částečně zdokumentováno. Společnost ESRI patří
mezi
jedny z nejsilnějších hráčů na poli
vývoje
geoinformačních systémů. „Vlajkovou lodí“ ESRI je ArcGIS – komplexní GIS řešení a dalo by se říci i platforma. Součástí ArcGIS je veřejné a relativně bohatě zdokumentované API, což u komerčních produktů (GIS sektor nevyjímaje) nebývá vždy samozřejmostí. Přístupné a zdokumentované API společně s popularitou a rozšířeností systémů ArcGIS (ArcGIS for Desktop patří mezi hlavní analytické nástroje Katedry geoinformatiky na Univerzitě Palackého v Olomouci) jsou hlavními důvody, proč byl ArcGIS, konkrétně pak ArcGIS for Desktop, vybrán jako ideální produkt pro demonstraci možností spolupráce vývojové platformy .NET Framework a GIS.
6
1 CÍLE PRÁCE Cílem této bakalářské práce je popis komponent ArcObjects a možností jejich využití ve spolupráci s platformou .NET Framework. Teoretickou část práce bude tvořit základní charakteristika komponent ArcObjects a principu jejich spolupráce s technologií .NET. Tato spolupráce bude demonstrována v rámci možností vývoje nad jedním z produktů společnosti ESRI – ArcGIS Desktop, který je z velké části na komponentách ArcObjects postaven. Mimo popisu samotných ArcObjects, možností práce s nimi a principu jejich spolupráce s platformou .NET Framework, bude součástí této práce i popis některých aspektů vývoje nad komponenty ArcObjects v prostředí platformy .NET. Zvláštní důraz bude kladen na nejnovější model pro začleňování vlastní funkčnosti do aplikací ArcGIS for Desktop pomocí add-in rozšíření a doplňků. Teoretická část bude podpořena o vývoj vlastních add-in rozšíření pro aplikaci ArcMap (stěžejní aplikaci produktu ArcGIS for Deskop). V rámci této bakalářské práce budou vytvořeny celkem tři add-iny, jejichž zdrojové kódy budou součástí její digitální přílohy. Právě prostřednictvím těchto add-inů budou demonstrovány různé možnosti, které tento způsob práce s komponenty ArcObjects přináší, a to od pouhé automatizace pracovních postupů až po pokročilejší možnosti spolupráce v podobě využití funkčností knihoven třetích stran nebo služeb vzdálených API.
7
2 POUŽITÉ PRODUKTY A TECHNOLOGIE V této kapitole budou představeny technologie a produkty, které byly využity při zpracovávání této práce, případně které jsou důležité pro ucelenější pohled na danou problematiku.
2.1 .NET Framework Podle [1] představuje .NET Framework (.NET vyslovováno „dotnet“) softwarovou platformu, navrženou společností Microsoft tak, aby v rámci operačních systémů Windows realizovala prostředí nezbytné pro běh a vývoj .NET aplikací. Charakteristické vlastnosti .NET Framework lze shrnou do následujícího výčtu [2]: •
Interoperabilita s již existujícím kódem – schopnost vzájemné spolupráce s jinými již existujícími technologiemi. Podporované jsou tři formy této spolupráce: .NET–COM (COM interop), COM–.NET (.NET interop) a .NET– C/Win32 API (P/Invoke).
•
Jazyková nezávislost – jednou z velkých výhod celé platformy .NET je nezávislost na konkrétním programovacím jazyce. Jedna aplikace tak může být postavena na knihovnách napsaných pokaždé v jiném jazyce – pro .NET to nepředstavuje žádný problém.
•
Jednotné běhové prostředí – .NET Framework, podobně jako třeba Java, využívá technologií založených na virtuálním strojovém prostředí.
•
Společná knihovna tříd – součástí frameworku je rozsálá knihovna tříd, dostupná všem na .NET cílených jazykům a poskytující jim tak jednotné veřejné API.
•
Jednoduchý model instalace/údržby aplikací – předchozí technologie vývoje softwaru (myšleno především COM) se potýkaly s poměrně složitou režií spojenou s instalací aplikací. Problémem byla i jejich údržba, zejména verzování DLL knihoven (neduh označovaný jako DLL Hell). .NET Framework většinu těchto problémů zdárně řeší.
•
Bezpečnost – součástí .NET Framework jsou sofistikované bezpečnostní mechanismy pro zajištění bezpečnosti chodu aplikace. V potaz je brána jak identita aktuálně do systému přihlášeného uživatele, tak třeba i původ dané aplikace.
Ačkoliv současné verze operačních systémů Windows již .NET Framework obsahují ve svém základu, lze jej bezplatně získat a doinstalovat jako samostatný produkt.
8
Framework je volně ke stažení viz [3], a to jak aktuální verze .NET Framework 4.5, tak i verze předchozí.
2.1.1 Struktura .NET Framework .NET Framework se skládá ze dvou hlavních komponent: virtuálního strojového prostředí CLR (Common Language Runtime) a rozsáhle knihovny tříd, známé jako .NET Framework Class Library [1]. Common Language Runtime (CLR) CLR, jak uvádí [2], představuje jádro celého frameworku. Jeho primární úlohou je provádění (tj. načítání a obsluha) spravovaného kódu právě běžících .NET aplikací; mimoto poskytuje řadu dalších služeb a nástrojů, včetně propracovaného systému automatické správy paměti (a s tím spojeného životního cyklu objektů), bezpečnostní vrstvy pro přístup ke zdrojovému kódu, samopopisného systému typů a dalších. O kódu běžícím pod kontrolou CLR a využívajícím výhod s tím spojených se běžně hovoří jako o řízeném kódu, zatímco kód vně CLR se označuje jako neřízený. V tomto kontextu je třeba zmínit, že CLR nepracuje s nativním strojovým kódem. Zdrojový kód .NET aplikací není kompilován přímo do strojového kódu, ale je nejprve přeložen do intermediálního jazyka (IL, konkrétně CIL – Common Intermediate Language), jakési formy jazyka symbolických adres. Teprve ten je virtuálním strojem CLR kompilován do nativního kódu dané platformy, a to až těsně před jeho provedením, tzv. Just In Time (JIT) [4]. V zásadě se jedná o podobný přístup, jaký aplikuje Java. Důležitý prvek CLR představuje společný typový systém (CTS – Common Type System), popisující všechny datové typy sdílené napříč frameworkem. Na CTS pak navazuje standard Common Language Specification (CLS), definující množinu na .NET Framework cílených programovacích jazyků. Jazyků vyhovujícím specifikacím standardu CLS existuje hned několik, např. C#, VB.NET, Visual C++, JScript nebo F#, a jejich počet není do budoucna nijak limitován [1]. .NET Framework Class Library Podle [1] je .NET Framework Class Library soubor softwarových knihoven pevně zasazených do výše popsané infrastruktury CLR. Úlohou těchto knihoven je odstínění vývojářů od systémové API a poskytnutí jim solidního, objektově orientovaného modelu, který zastřešuje všechny podstatné detaily programování od práce se zdroji až po návrh a konektivitu s uživatelským rozhraním. Jednotlivé .NET knihovny jsou rozděleny do hierarchicky uspořádaných jmenných prostorů. 9
Většinu základní funkčnosti spojené s objektově orientovaným programováním, ale i programováním obecně, lze nalézt v kolekci knihoven tříd Base Class Library (BCL). Patří mezi ně třídy a struktury pro práci s řetězci, kolekcemi, pro manipulaci s databázemi, soubory a podobně. Nad ní se nachází další důležitá knihovna ADO.NET, která poskytuje API pro přístup k datovým zdrojům a pro práci s XML. Tyto knihovny tvoří funkční základ, nad kterým mohou být postaveny další nástavby frameworku, jako například: •
Windows Forms – zprostředkovává práci s formuláři v operačních systémech Windows,
•
ASP.NET pro vývoj webových aplikací,
•
Windows Presentation Foudation (WPF) pro vývoj moderního grafického uživatelského rozhraní,
•
Windows Communication Foundation (WCP) – unifikovaný komunikační model mezi programovacími rozhraními,
•
Workflow Foundation (WF) pro důsledné oddělení aplikační a prezentační vrstvy při vývoji a návrhu aplikací.
2.1.2 Sestavení (assembly) Opětovně použitelné jednotky spravovaného kódu se v prostředí platformy .NET nazývají assembly (česky také sestavení). Ty, jak uvádí [4], tvoří jeden nebo i více modulů (soubory typu EXE, DLL nebo module) spravovaného (CIL) kódu, doplněných manifestem. Manifest sestavení Manifest sdružuje metadata popisující dané sestavení a jeho obsah. Jeho součástí jsou následující typy informací: •
identita, tj. jméno, verze a kultura,
•
seznam souborů tvořících dané sestavení,
•
odkazy na další použitá sestavení,
•
popis exportovaných veřejných typů a zdrojů,
•
bezpečností požadavky na dané sestavení.
Sestavení řeší většinu známých problémů spojených s nasazováním a údržbou aplikací, se kterými se potýkala (potýká) většina předchozích technologií vývoje softwaru [1].
10
Soukromé a sdílené sestavení Instalace .NET aplikací spočívá v instalaci jejich sestavení. Ta může probíhat dvěma způsoby: sestavení může být nainstalováno jako soukromé, anebo jako sdílené. Soukromé sestavení jsou ty programové jednotky spravovaného kódu, které jsou používány pouze lokálně v rámci jen jedné aplikace; nepočítá se tedy s jejich širším uplatněním [4]. Celý proces instalace je v tomto případě zjednodušen na pouhé nakopírování daného sestavení do příslušného aplikačního adresáře. Sdílené sestavení jsou přístupné v rámci celého systému a mohou je tak používat i aplikace třetích stran. Oproti soukromým sestavením jsou na ně kladeny přísnější požadavky v pojmenování – jméno každého sestavení musí být pro celý systém unikátní (u soukromých sestavení stačí, aby bylo unikátní jen pro daný adresář) [4]. Sdílené sestavení jsou povětšinou instalovány do Global Assebly Cache (GAC). V GAC se, mimo jiné, nachází také sestavení tvořící knihovny tříd .NET Framework Class Library.
2.1.3 Programovací jazyk C# Podle [4] je C# (vyslovováno jako „c sharp“) objektově orientovaný striktně typový programovací jazyk vyšší úrovně, který byl vyvinut společností Microsoft, jako referenční jazyk platformy .NET Framework. Zdrojový kód C#, respektive jeho syntaxe, se velmi podobá syntaxi dalších programovacích jazyků z rodiny C (zejména pak C++) a jazyku platformy Java, kde se tvůrci C# inspirovali zřejmě nejvíce. Kompilátor C# Kompilátor (překladač) jazyka C# je součástí .NET Framework. V počítači jej lze nalézt pod souborem csc.exe. Kompilace programu do sestavení (assembly) spravovaného kódu pak může v příkazovém řádku vypadat třeba následovně: csc.exe /r:mscorlib.dll /target:exe program.cs
Příkaz spustí kompilátor a předá mu tři parametry: •
Prvním je /r specifikující závislosti překládaného sestavení. (V tomto případě jde o sestavení částí knihovny Base Class Library, na které kompilátor odkazuje automaticky a nemusí se tedy uvádět.)
•
Druhý parametr, /target, instruuje kompilátor jaký typ sestavení má vytvářet (exe je výchozím typem a rovněž nemusí být uveden). 11
•
Posledním parametrem je soubor obsahující samotný zdrojový kód, jenž má být přeložen.
Výsledkem provedení toho příkazu pak bude do spravovaného (CIL) kódu přeložený program „program.exe“. Výše uvedenému postupu se lze vyhnout užitím vhodného vývojového prostředí, které se o všechny úkony spojené s kompilací postará samo; např. Visual Studio, popsané v následující podkapitole.
2.1.4 Microsoft Visual Studio Microsoft Visual Studio je vývojové prostředí (IDE – Integrated Development Environment) navržené společnosti Microsoft pro zajištění podpory vývoje aplikací nad vlastní platformou .NET Framework. Jedná se o poměrně pokročilý nástroj, který pokrývá kompletně celý proces návrhu a tvorby softwaru [5]. Klíčovou komponentou každého IDE je editor zdrojového kódu. Visual Studio zde nabízí vyspělý systém nápovědy, tzv. IntelliSence a nástroje pro refaktoring kódu. Vývoj uživatelských rozhraní (GUI) usnadňuje grafický designér. Pro možnosti ladění kódů Visual Studio integruje debugger schopný pracovat i na úrovni virtuálního stroje. Vývojové verze Visual Studia V současnosti je nejaktuálnější verzí Visual Studio 2012. To je dostupné ve třech licenčních úrovních: Ultimate, Premium a Professional. Dále je možné získat bezplatnou verzi Visual Studio Express, která je omezená vždy na jednu danou platformu – web, windows 8, desktop windows nebo třeba windows phone; pozn. dříve platila omezení na vybraný programovací jazyk (C#, .NET nebo C++) a nikoliv na platformu. Zároveň jsou Express edice Visual Studia ochuzeny o některé nástroje a pokročilejší možnosti vývoje [5]. Pro zpracování této bakalářské práce byla zvolena verze Visual Studio 2010 Professional s bezplatnou studentskou licencí. Hlavním důvodem, proč nebyla zvolena nejnovější verze (tedy Visual Studio 2012), bylo zajištění kompatibility s vývojovými nástroji ArcObjects SDK (viz následující kapitola o ArcObjects).
2.2 ArcObjects ArcObjects jsou knihovny softwarových komponent, které poskytují služby pro podporu funkčnosti geoinformačních systémů (GIS). Tvoří také důležitou součást aplikační infrastruktury, nad níž jsou postaveny některé z klíčových produktů 12
systému ArcGIS firmy ESRI [6]. Knihovny ArcObjects jsou napsané v jazyce C++, přičemž využívají technologických standardů Component Object Model (COM). Díky tomu jsou nezávislé jak na vývojářské, tak i na produkční platformě. K jednotlivým komponentám ArcObjects a jejich funkcím je možné přistupovat přes čtyři aplikační programovací rozhraní (API – Application Programming Interface): COM, .NET (C#, VB.NET, VC++), Java nebo C++ API [6]. Tato práce se bude věnovat pouze jedné z uvedených technologií a její API, a to právě technologické platformě .NET.
2.2.1
Produkty ArcGIS
Knihovny ArcObjects nejsou samy o sobě žádným samostatně distribuovaným produktem, ale jsou instalovány společně s některým ze softwarových řešení (produktů) ArcGIS – ArcGIS for Desktop, ArcGIS Engine nebo ArcGIS for Server. ArcGIS for Desktop ArcGIS for Desktop (dříve ArcGIS Desktop) je softwarový balíček uživatelských aplikací, které dohromady poskytují komplexní nástroje pro GIS. ArcGIS for Desktop tvoří několik vzájemně provázaných aplikací: •
ArcMap – jedná se klíčovou aplikaci celého balíčku. Umožňuje provádět veškeré úkony spojené s tvorbou map – dotazy a analýzy nad prostorovými daty, vytváření mapových kompozic, případně jejich následný tisk.
•
ArcCatalog, který obsahuje sadu nástrojů k tvorbě, editaci a organizaci prostorových i tabulkových dat.
•
ArcToolbox – uživatelské rozhraní pro přístup k celé řadě GIS nástrojů pro správu a analýzu geografických dat.
•
Grafické modelovací prostředí ModelBuilder, které umožňuje řetězit jednotlivé kroky zpracovávání dat v jeden ucelený pracovní model.
Kromě výše zmíněných aplikací jsou dostupná i dílčí rozšíření (extenze) [7]; např. ArcGIS 3D Analyst nebo ArcGIS Network Analyst pro podporu trojdimensionálních, respektive síťových analýz prostorových dat. Podle [8] je ArcGIS for Desktop nabízen ve třech licenčních úrovních: Basic, Standard a Advanced (dříve ArcView, ArcEditor a ArcInfo). Ty se vzájemně liší především v rozsahu jimi poskytované funkcionality. Zatímco ArcGIS for Desktop Basic je určen především pro zobrazování a analýzu prostorových dat, případně pro následnou tvorbu jednoduchých mapových výstupů, licence Standard již plně 13
využívá potenciálu datového modelu ArcGIS (zejména geodatabází); poskytuje plné možnosti úpravy a správy vektorových formátů geodat, včetně validace jejich topologie. Maximální podporu profesionálního GIS pak přináší licence ArcGIS for Desktop Advanced. Produkt ArcGIS Desktop (ArcInfo) ve verzi ArcGIS 10 (současná nejaktuálnější verze je 10.1) byl využit při vypracovávání této bakalářské práce. ArcGIS Engine Oproti koncovému GIS řešení, jakým je ArcGIS for Desktop, představuje ArcGIS Engine jen jakousi aplikační infrastrukturu. Tvoří jej kolekce multiplatformních GIS knihoven (přesněji knihoven ArcObjects), které společně s dodávaným API poskytují profesionální framework pro vývoj vlastních stand-alone aplikací, případně geoinformačních extenzí pro aplikace stávající [6]. Podle [6] přichází ArcGIS Engine ve formě dvou principiálně odlišných produktů. Jednak jako sada vývojářských nástrojů ArcGIS Engine Developer Kit, tedy produkt určený primárně jen vývojářům, anebo jako běhové prostředí ArcObjects komponent, ArcGIS Engine (dříve ArcGIS Engine Runtime), které je nezbytné jak pro testování, tak i pro finální nasazení vyvíjených aplikací. Součástí instalace ArcGIS Engine je i kolekce předpřipravených ovládacích prvků, které vývojáři ocení zejména při návrhu a tvorbě grafických uživatelských rozhraní (GUI – Graphical User Interface); jako příklad lze uvést objekt MapControl, který zapouzdřuje přístup k mapovému dokumentu a zobrazuje (vykresluje) jeho obsah uživateli. ArcGIS for Server Jak uvádí [6], ArcGIS for Server (dříve ArcGIS Server) poskytuje serverové řešení pro GIS. Dovoluje centralizovat geoinformační systémy a zpřístupnit jejich služby více uživatelům současně. Jeho základ tvoří GIS server, na kterém běží komponenty ArcObjects. Nad ním je postavena vývojářská nástavba Application Developer Framework (ADF), která umožňuje vzdálený přístup klientských (například webových) aplikací ke službám GIS serveru. ArcGIS for Server je, na základě poskytované funkcionality, distribuován ve třech licenčních úrovních: Basic, Standard a Advanced (podobně jako ArcGIS for Desktop), a ve dvou úrovních kapacity serveru: Workgroup a Enterprise [7].
14
2.2.2
Funkčnost ArcObjects
ArcObjects představují komplexní řešení pro vývoj GIS softwaru. Podle [9] jsou jednotlivé komponenty ArcObjects seskupeny do několika desítek (zhruba sedmdesáti) knihoven, které poskytují vždy specifický typ funkcí a služeb. Na disku jsou pak uloženy ve formě dynamických DLL (Dynamic Link Library) knihoven. Základní funkčnost knihoven ArcObjects lze shrnou do následujícího výčtu: •
Konfigurace map a jejich obsahu, tj. správa zobrazovaných dat, editace mapových vrstev, včetně designování layoutu. Většina této a podobné funkčnosti je obsažená knihovnou Carto. V případě produktu ArcGIS for Desktop knihovnou ArcMap, která zapouzdřuje rozhraní pro manipulaci s aplikací ArcMap.
•
Produkce mapových děl – export hotových map, případně jejich tisk má na starost knihovna Output.
•
Interakce s mapou a zobrazovanou grafikou – většinu funkcí pro vykreslování nejen obsahu map, ale i grafiky všeobecně, stejně jako funkce umožňující interakci s touto grafikou lze nalézt v knihovně Display, případně Animation, pokud jde o grafiku dynamickou.
•
Správa a editace dat je klíčovou záležitostí všech (geo)informačních systémů, ArcGIS nevyjímaje. Jedná se především o správu datových úložišť (knihovna
Geodatabase),
editaci
a
vytváření
nových
dat,
včetně
správy/tvorby geometrie prostorových dat (knihovna Geometry). •
Datové analýzy představují jeden z primárních úkolů GIS. Většina analytických funkcí ArcGIS je obsažena knihovnou Geoprocessing. Dalo by se říct, že Geoprecessing představuje analytické jádro ArcGIS. Kompletní seznam všech knihoven a jejich popis v dokumentaci API viz[9].
Ne každá knihovna ArcObjects je dostupná napříč všemi produkty ArcGIS (viz předchozí kapitola). Některé, zejména knihovny tvořící GUI desktopových aplikací, jsou dostupné jen v rámci produktové řady ArcGIS for Desktop [9].
2.2.3
Možnosti vyžití ArcObjects
S knihovnami ArcObjects lze, v závislosti na produktu ArcGIS (spolu s kterým jsou knihovny dodávány, a také na specifikacích řešeného problému), pracovat několika níže popsanými způsoby.
15
Přizpůsobení aplikací ArcGIS for Desktop Aplikace ArcGIS for Desktop je možné přizpůsobovat, upravovat nebo rozšiřovat o novou funkčnost dle aktuálních potřeb a požadavků uživatele. Mimo základní možnosti konfigurace těchto aplikací, tj. prostřednictvím jejich uživatelských rozhraní, a mimo možnosti automatizace pracovních postupů pomocí skriptovacího jazyka Python spolu s nativní ArcGIS knihovnou pro Python – ArcPy (nesouvisejících s problematikou využití knihoven ArcObjects), existují další dva možné způsoby, jak toho docílit: •
rozšíření knihoven ArcObjects o své vlastní komponenty;
•
využití nového modelu pro vývoj a integraci Add-in doplňků [6].
Každý z těchto přístupů je vhodný k řešení jiného problému. Každý má své výhody a nevýhody, případně svá omezení. Jejich detailnější popis (zejména Add-in doplňků) a příklady použití jsou jedním z cílů této práce. Vývoj aplikací nad ArcGIS Engine a ArcGIS for Desktop Podle [6] mohou knihovny ArcObjects sloužit jako stavební bloky, respektive jakýsi GIS framework, pro vývoj vlastních stand-alone aplikací a tím jim poskytnout bohatou mapovací, vizualizační nebo jinou, pro GIS typickou, funkčnost. Příkladem takovéhoto využití ArcObjects jsou stand-alone aplikace. Ty představují ideální řešení pro tvorbu vlastních geoinformačních systémů, navržených přesně na míru a podle konkrétních požadavků koncového uživatele. V dalším případě, kdy je třeba do některé již existující aplikace zaimplementovat podporu GIS, je možné využít funkčnosti ArcGIS Engine nebo ArcGIS for Desktop pro vývoj odpovídající GIS extenze. V neposlední řadě lze nad komponenty ArcObjects vytvářet samostatně spustitelné nástroje zprostředkovávající specifické funkce některé z dostupných ArcGIS for Desktop aplikací, a to nezávisle na GUI této aplikace. Při každém spuštění „Engine“ (tzn. komponenty ArcObjects využívající) aplikace musí nejprve dojít k inicializaci příslušného ArcGIS produktu, tj. ArcGIS for Desktop nebo ArcGIS Engine. Před tímto krokem jsou komponenty knihoven ArcObjects pro aplikaci nepřístupné [6]. Více k tomuto tématu viz [6]: Building stand-alone applications.
Vývoj (webových) aplikací nad ArcGIS for Server Pro vývoj webových nebo mobilních aplikací nad ArcGIS for Server je vývojářům k dispozici rozhraní ADF (Application Developer Framework). Toto rozhraní umožňuje vzdálenou komunikaci s komponenty ArcObjects na mapovém serveru. 16
Vývoj nad rozhraním ADF není součástí ArcObjects SDK. Více informaci o ArcGIS Server ADF viz [10].
Je-li to nutné, je možné pracovat s komponenty ArcObjects přímo na úrovni serveru, např. při tvorbě extenzí. Práce s ArcObjects prostřednictvím ArcGIS for Server je v mnoha ohledech podobná jako v případě desktopových verzí, nicméně je nutné zvážit a promyslet některé detaily práce nad vzdálenými, na serveru umístěnými, objekty. Více informací viz [6]: Developing with ArcGIS Server.
2.2.4
Podpora vývoje na platformě .NET Framework
ArcObjects jsou napsány v C++, jako COM komponenty. Přesto, že jsou COM a .NET Framework docela odlišné technologie (.NET využívá služeb virtuálního stroje – jeho kód je řízený, COM nikoliv), dovedou spolu vzájemně spolupracovat. Princip spolupráce .NET a COM Jak uvádí [1], je Runtime Callable Wrapper (RCW) základním kamenem mechanismu, kterým běhové prostředí .NET (CLR) zpřístupňuje COM komponenty (tedy nespravovaný kód) klientům spravovaného kódu. RCW v něm vystupuje jako proxy objekt, který je vytvořen nad každým COM objektem, který si provádění spravovaného kódu vyžádá. Tato spolupráce funguje pochopitelně i obráceně, kdy COM klient volá .NET komponentu. Tento opačný postup se pak nazývá COM Callable Wrapper (CCW). Aby byla vzájemná spolupráce umožněna, musí mít klientská aplikace (respektive CLR) k dispozici sestavení popisující typovou knihovnu takto zpřístupňované COM komponenty. Takové sestavení lze vygenerovat pomocí automatizovaných nástrojů .NET Framework. Avšak, je-li poskytováno, je všeobecně doporučované využívat oficiální sestavení, tzv. primární interop sestavení (PIA – Primary Interop Assembly), dodávané a podepsané samotnými autory COM knihoven [1]. Podle [6] dodává ESRI kolekce primárních interop sestavení pro všechny COM komponenty ArcObjects jako součást sady vývojářských nástrojů (SDK – Software Development Kit) pro platformu .NET. Takto poskytnutá primární sestavení jsou pak v systému globálně přístupná prostřednictvím Global Assembly Cache (GAC), tedy podobně jako sestavení standardních knihoven .NET Framework.
17
ArcObjects SDK ArcObjects SDK for the Microsoft .NET Framework (dále jen ArcObjects SDK) představuje balíček programátorských nástrojů pro podporu vývoje nad komponenty ArcObjects v prostředí platformy .NET Framework. ArcObjects SDK je součástí distribuce produktů ArcGIS for Desktop, ArcGIS Engine nebo ArcGIS for Server (verze SDK je shodná s verzí ArcGIS, v tomto případě tedy ArcObjects SDK 10). Přítomnost instalace (a autorizované licence) alespoň jednoho z těchto produktů je nezbytným požadavkem na používání ArcObjects SDK. Stejně tak jako přítomnost .NET Framework alespoň ve verzi 3.5 [11]. Při vývoji nad ArcObjects (SDK 10) je nutné odkazovat se na .NET Framework ve verzi 3.5, a to i tehdy, je-li k dispozici aktuálnější verze frameworku. Součástí ArcObjects SDK je následující výčet materiálů a podpůrných nástrojů: •
ArcObjects Help for .NET developers – systém nápovědy, jehož součástí je i zdokumentované API, doporučené postupy a jiné návody, včetně ukázkových zdrojových kódů.
•
Object model diagrams (OMDs) – PDF soubory s kolekcemi UML diagramů pro znázornění vztahů a vazeb mezi jednotlivými komponentami ArcObjects.
•
Add-in nástroje a snippety – součástí ArcObjects SDK je i řada užitečných nástrojů a rozšíření, které umožňují integraci do konkrétního vývojového prostředí – IDE (Integrated Development Environment); v tomto případě do vývojového prostředí Visual Studio. Patří mezi ně i snippety – relativně malé bloky již předpřipraveného kódu, které poskytují řešení některých rutin při psaní kódu a vývoji aplikací.
•
Kolekce primárních interop sestavení (PIA), viz výše. Další informace o možnostech integrace ArcObjects SDK do IDE (Visual Studio) viz [6]: Visual Studio integration.
Podpora vývojového prostředí Visual Studio ArcObjects SDK 10 nabízí podporu pro Microsoft Visual Studio 2008 SP1 ve verzích: Professional, Premium, Ultimate Edition a Visual Basic / C# Express. Visual Studio 2010 je ze strany ArcObjects SDK 10 podporováno ve verzích Professional, Premium i Ultimate (Express edice nejsou podporovány) [11]. Od verze ArcGIS 10.1 (ArcObjects SDK 10.1) je podporováno již jen Visual Studio 2010, v tomto případě i včetně Express edicí [12].
18
3 ZÁKLADY PRÁCE S ARCOBJECTS Tato kapitola popisuje základy práce nad knihovnami ArcObjects. Vzhledem k rozsáhlosti dané problematiky nebylo možné obsáhnout všechny aspekty práce s ArcObjects a bylo nutné omezit se jen na některá vybraná témata. Kompletní dokumentaci a návody pro práci s ArcObjects lze dohledat v systému nápovědy, případně i online na webu viz [6].
3.1 Object model diagrams (OMD) Modelové diagramy (OMD – Object Model Diagrams) představují důležitý doplněk pro orientaci se v ArcObjects API. Přinášejí vizuální výpověď o vztazích mezi jednotlivými
strukturami
a
knihovnami
ArcObjects,
o
rozhraních,
které
implementují, případně o jejich metodách a vlastnostech [6]. Porozumění a schopnost čtení OMD jsou jedním z předpokladů úspěšného vývoje nad produkty ArcGIS for Desktop, ArcGIS Engine nebo ArcGIS for Server. Diagramy OMD jsou dostupné prostřednictvím systému nápovědy pro vývojáře ArcObjects Help for (.NET) Developers, jenž je součástí instalace balíčku vývojářských nástrojů ArcObjects SDK, a to formou PDF souborů. Vzhledem k počtu knihoven a jimi obsažených tříd a struktur, je nemožné zobrazit kompletní model ArcObjects pohromadě (jako jeden PDF soubor). Namísto toho jsou OMD rozděleny do více samostatných modelů (více PDF souborů), jenž většinou reprezentují jednu konkrétní knihovnu ArcObjects. Samotné PDF soubory s OMD diagramy jsou také přístupné z adresáře instalace ArcObjects SDK; např. C:\Program Files\ArcGIS\DeveloperKit10.0\Diagrams. Čtení OMD diagramů Podle [6] jsou OMD postaveny na standardu grafického modelovacího jazyka UML (Unified Modeling Language), navrženého speciálně za účely vizualizace návrhu a popisu aplikačního modelu softwaru. Základy čtení UML modelů knihoven ArcObjects, stejně tak jako některé specifické vlastnosti ArcObjects OMD diagramů, budou představeny v následujících několika kapitolách.
19
3.1.1
Typy tříd
Obr. 1 Základní symbologie OMD [9] Komponenty ArcObjects jsou postaveny na třech odlišných typech tříd. Podle [6] jimi jsou: •
Abstraktní třídy (abstract classes) – tyto třídy jsou v OMD reprezentovány jednoduchým (2D) obdélníkem a jménem třídy psaném kurzívou; viz obr. 2.1. Jde o neinstancovatelné třídy, které slouží pouze jako základní kostra pro rozhraní dědících tříd (podobně jako v některých objektových jazycích). Jelikož se každá takto odvozená (poděděná) třída zavazuje k implementaci abstraktní třídou definovaných rozhraní, jsou abstraktní třídy důležitým vodítkem, na základě kterého mohou vývojáři navrhovat vlastní typy tříd a rozšiřovat tak funkčnost ArcObjects. Příkladem může být třeba třída Layer, která definuje základní rozhraní pro všechny ostatní typy mapových vrstev, např. BasemapLayer, FeatureLayer a další.
•
Coclasses – pohledem programátora jde o klasické třídy známé z objektového
programování.
V diagramech
ArcObjects OMD
jsou
znázorňovány šedým obdélníkem s 3D efektem (stínováním); viz obr. 1. Instance objektů těchto tříd lze vytvářet klasickým způsobem, který nabízí konkrétní vývojářská platforma a její jazyk (např. klíčovým slovem new v případě jazyka C# na platformě .NET Framework). •
Třídy (classes) – grafikou OMD je tento typ tříd symbolizován podobně jako výše zmiňovaný typ tříd coclasses, nicméně s rozdílem ve výplni obdélníku, která je v tomto případě bílá; viz obr. 1. Základní charakteristikou těchto tříd je fakt, že jediný způsob jak získat jejich instanci je prostřednictvím 20
návratové hodnoty metody jiné třídy. Například objekt reprezentující záznam (řádek) v geodatabázi, tj. objekt třídy Row, není možné instancovat klíčovým slovem new, nýbrž je třeba zavolat metodu ICursor.NextRow() na objektu kurzoru.
3.1.2
Vztahy mezi objekty
Mezi jednotlivými třídami knihoven ArcObjects může existovat hned několik typů vazeb a závislostí. OMD zobrazuje následující typy: •
Asociace (associations) – vyjadřuje vazbu/vztah mezi dvěma typy objektů.
•
Násobnost (multiplicity) – vlastnost asociace, která vyjadřuje kardinalitu vztahu dvou objektů, tj. 1:1, 1:M nebo N:M.
•
Kompozice (composition) – vztah, kdy jeden typ objektu je složen z dalších typů objektů. Podobně jako u asociací i zde může být kardinalita tohoto vztahu vyjádřena násobností.
•
Tvoří (instantiation) – daný typ objektu vytváří instanci jiného typu. Jedná se o jedinou možnost jak získat instance tříd typu classes (viz předchozí kapitola).
•
Dědičnost (type inheritance) – vztah označovaný také jako „je typem“ (anglicky „type of“). Definuje vztah potomek-rodič [6].
3.1.3
Rozhraní
ArcObjects jsou postaveny na technologickém standardu COM (Component Object Model). COM je technologie, poskytující jednotlivým binárním komponentám softwarový standard, který umožňuje jejich vzájemnou komunikaci. Jednotlivé komponenty tak nemusí být napsané ve stejném programovacím jazyce a dokonce ani nemusí běžet na stejném počítači a pod stejným operačním systémem. Těchto výhod je, mimo jiné, docíleno díky striktnímu zapouzdření COM objektu – tzn. skrytí vnitřní implementace metod a parametrů před okolním světem. Komunikace s nimi je tak možná jedině přes rozhraní. Rozhraní představuje jakousi smlouvu o poskytování služeb; všechny COM objekty (nebo spíš jejich třídy) se implementací daného rozhraní zavazují, že budou poskytovat tímto rozhraním definované metody a funkce. Všichni klienti těchto objektů pak s nimi komunikují právě prostřednictvím jejich rozhraní. Je běžné, že jedna třída implementuje více než jen jedno rozhraní. Všechna danou třídou implementovaná rozhraní jsou v diagramech OMD znázorněna symbolem „lízátka“ viz obrázek 1. Pokud je rozhraní definováno v jiné knihovně, než ve které 21
se konkrétní třída nachází, OMD na toto upozorňuje tečkovou notací (podobně jako je tomu u .NET jmenných prostorů). Stejně tak dává vývojáři vědět, zda se jedná o volitelné (optional) rozhraní, případně o rozhraní, jehož implementace je závislá na konkrétní instanci. Dědičnost rozhraní Jelikož jsou rozhraní ArcObjects rozhraní COM, všechna dědí z IUnknown („I“ na začátku názvu rozhraní je všeobecně uznávaná konvence, značící, že jde právě o rozhraní). Pokud některé rozhraní dědí z druhého, automaticky získává přístup ke všem členům jeho rodiče. Díky tomu je například možné volat metody a vlastnosti rozhraní IGeometry na objektu s referencí na IPoint, které právě z IGeometry dědí [6]. Jednou vydaná COM rozhraní nelze měnit – důvodem je stabilita již dříve napsaného softwaru. Právě proto se dědičnost využívá i při potřebě rozšířit nebo nahradit stávající rozhraní; příkladem může být rozraní IGeometry, respektive IGeometry5 (číslo na konci názvu rozhraní značí o kolikátou verzi/rozšíření se v ArcObjects API jedná). Metody a vlastnosti rozhraní OMD znázorňuje i členy vybraných rozhraní, které daná třída implementuje. Mezi tyto členy patří vlastnosti, které vypovídají o aktuálním stavu objektu a metody, které specifikují jeho chování a možné akce [6]. Vlastnosti objektů mohou být pouze pro čtení (get), pouze pro zápis (put) nebo pro čtení i zápis (get/put). OMD současně informuje i o tom, zda je vlastnost definovaná hodnotou nebo referencí. Vlastnosti (properties) jsou diagramy OMD zobrazovány symbolem viz obr. 2; jeho součástí je i jméno dané vlastnosti (dle obecně uznávané konvence jde o podstatné jméno) a datový typ požadované/návratové hodnoty, který je uvedený na konci za jejím jménem. Metody se typicky pojmenovávají slovesem a v grafice OMD jsou značeny symbolem šipky (viz obr. 2). Má-li metoda nějaké vstupní parametry, jsou uvedeny v závorce za jménem metody. Má-li návratovou hodnotu, je uvedena podobně, jako je tomu u vlastností.
22
Obr. 2 Značení členů (vlastností a metod) rozhraní [9] Ne všechna rozhraní, která třída implementuje, jsou v OMD zobrazeny i s jejich členy. Většinou je tak jen u těch podstatnějších rozhraní, která přímo souvisí s funkčností dané třídy. Např. u třídy Layer jsou to rozhraní ILayer a IPublishLayer, kde OMD zobrazuje i jejich vlastnosti a metody, zatímco u ostatních rozhraní je uveden jen jejich název. Více informací o OMD viz [6]: Reading OMDs.
3.2 Datový model ArcGIS a práce s daty Komponenty pro práci s geodatabází jsou součástí knihovny Geodatabase (namespace ESRI.ArcGIS.Geodatabase). Knihovna poskytuje API umožňující jednotný přístup ke všem podporovaným datovým zdrojům ArcGIS, včetně lokálních i ArcSDE databází nebo souborových datových úložišť.
3.2.1 Geodatabáze Primárním úložištěm prostorových dat platformy ArcGIS jsou geodatabáze – relační databáze navržené a přizpůsobené pro správu a manipulaci s prostorovými daty (tzv. geodaty). Jsou schopny pracovat jak nad vektorovými, tak nad rastrovými formáty geodat. Podle [7] ArcGIS v současnosti rozeznává tři typy geodatabází: •
Osobní geodatabáze (personal geodatabase) – původní ArcGIS model pro uchovávání geodat. Osobní geodatabáze jsou postaveny na funkčnosti Microsoft Access. Jako takové jsou podporovány jen na operačních systémech Windows a jejich maximální kapacita, tzn. maximální velikost MS Access souboru (přípona mdb), je omezena limitem 2 GB.
•
Souborová geodatabáze (file geodatabase) – databáze je na disku ukládána do adresářové struktury, kde každá datová sada představuje oddělený soubor. Její kapacita může dosáhnout velikosti až 1 TB (v extrémních případech až 256 TB). V porovnání s osobní geodatabází je souborová
geodatabáze
preferovanějším
prostorových dat. 23
typem
pro
uchovávání
•
ArcSDE geodatabáze – enterprise řešení založené na vybraném DBMS (Database Management System) produktu; možnosti jsou následující: Oracle, Microsoft SQL, IBM DB2, IBM Informix nebo PosgreSQL. ArcSDE je vhodné řešení pro rozsáhlé projekty, na kterých pracuje více uživatelů současně.
Další typy úložišť Kromě výše uvedených typů geodatabází je možné využít i jiných ne-databázových forem uchovávání a správy prostorových dat, jako shapefile (SHP), CAD, netCDF, coverages nebo TIN. Informace o všech podporovaných typech dat viz [7]: About geographic data formats.
3.2.2 Workspace Jak uvádí [9], je workspace referencí na konkrétní datové úložiště, tj. geodatabázi nebo adresář. Aplikaci poskytuje přístup k jím obsaženým datasetům (datovým sadám), případně umožňuje zakládat datasety nové. ArcObjects dělí workspace, podle datového úložiště, do tří základních typů: •
FileSystemWorkspace – ne-databázová datová úložiště (např. soubory SHP nebo CAD).
•
LocalDatabaseWorkspace – lokální prostorová databáze, tzn. File/Personal geodatabase.
•
RemoteDatabaseWorkspace – geodatabáze umožňující vzdálený přístup (např. ArcSDE).
Workspace factory Aby se zamezilo duplicitním připojením vedoucím na jeden a týž workspace, nelze objekty workspace instancovat přímo. Je nutné využít služeb workspace factory – pro
dané
datové
IWorkspaceFactory.
úložiště Při
specifické
každém
pokusu
třídy, o
implementující přístup
k již
rozhraní
otevřenému
(instancovanému) workspace objekt workspace factory vrátí referenci odkazující právě na tento workspace; v opačném případě vytvoří a vrátí instanci nového objektu workpace [6]. Třídy workspace factory využívají návrhového vzoru singleton, čímž je zajištěna existence jen jedné instance pro danou implementaci třídy workspace factory. Následující kód demonstruje jak získat workspace pro souborovou geodatabázi, definovanou plnou cestou k jejímu souboru, viz parametr (string) path.
24
Type factoryType = Type.GetTypeFromProgID( "esriDataSourcesGDB.FileGDBWorkspaceFactory"); IWorkspaceFactory factory = (IWorkspaceFactory) Activator.CreateInstance(factoryType); // singleton IWorkspace workspace = factory.OpenFromFile(path, 0);
Za otevření workspace je zodpovědná metoda rozhraní IWorkspaceFactory OpenFromFile(), která přímá dva povinné parametry:
•
První v podobě řetězce, reprezentujícího plnou cestu k souboru daného workspace, případně k souboru s konfigurací připojení ke vzdálené (ArcSDE) geodatabázi.
•
Druhým parametrem je pak handle k oknu aplikace (Windows HWND) umožňující například zobrazení případné chybové hlášky.
Mimo to jsou třídy workspace faktory zodpovědné za vytváření nových lokálních geodatabází, souborových (nedatabázových) úložišť, anebo souborů s konfigurací databázové připojení k ArcSDE geodatabázím; vše provádí jediná metoda Create(), a to v závislosti na konkrétním typu dané workspace faktory [6].
3.2.3 Datové sady (datasety) Podle [9] je datová sada, neboli dataset, kolekcí dat stejného typu a představuje elementární organizační prvek jak geodatabáze, tak i celého datového modelu aplikací ArcGIS. K datasetům lze přistupovat nebo je vytvářet, pomocí objektu třídy workspace. Existují tři výchozí typy datasetů: •
Třídy prvků (feature classes) – homogenní kolekce geodat o stejném typu prostorové reprezentace (tzn. body, linie, polygony), stejném schématu atributových vlastností a jednotném souřadnicovém systému. Každý objekt třídy prvků má povinně definovanou geometrii, která je uživateli zobrazovaná formou vektorů.
•
Rastry (raster dataset) zobrazují geodata do bitmapové grafiky – rovnoběžného gridu, kdy každá buňka tohoto gridu (o velikosti jednoho pixelu) nese hodnotu popisující charakteristickou vlastnost konkrétního území, jako např. informaci o teplotě, sklonu nebo nadmořské výšce.
25
•
Tabulky (tables) představují základní mechanismus pro ukládání dat v geodatabázích. Data v tabulkách jsou uložena do řádků a sloupců, kdy řádky představují jednotlivé záznamy a sloupce vlastnosti tohoto záznamu.
Jak již bylo řečeno, třídy prvků, rastry i tabulky jsou výchozími typy datasetů. Právě na nich je postavena celá řada dalších, vyspělejších datových modelů, schopných popisovat nejen konkrétní geografické entity, ale například i jejich vzájemné vztahy a závislosti. Více informací o datasetech a jejich typech viz [7]: A quick tour of data management.
Třídy všech typů datasetů implementují rozhraní IDataset, které poskytuje přístup k jejich vlastnostem (např. jméno, typ nebo nadřazený workspace). K jejich obsahu (tedy k datům samotným) se pak přistupuje přes specifická rozhraní daných datasetů, např. ITable a IFeatureClass. Podobně je tomu i při jejich editaci nebo vytváření datasetů nových.
3.3 Tabulky a třídy prvků (feature-based datasety) Tabulku nebo dataset třídy prvků (neboli kterýkoliv feature-based dataset) lze načíst prostřednictvím objektu feature workspace a jím implementovaných metod rozhraní IFeatureWorkspace [6]. Viz následující řádky kódu: IFeatureWorkspace fws = (IFeatureWorkspace)workspace; IFeatureClass fc = fws.OpenFeatureClass(datasetName);
Vstupním parametrem volané metody OpenFeatureClass() je řetězec s názvem požadovaného datasetu. Pro získání tabulky slouží podobná metoda OpenTable(). Obě pak navrací instanci typu IFeatureClass, respektive ITable.
3.3.1 Schéma datasetu třídy prvků Rozhraní IFeatureWorkspace poskytuje rovněž i metody pro zakládání nových datasetů. Nicméně aby to bylo možné, je nutná alespoň elementární znalost jejich schématu. Tabulky a třídy prvků (feature classes) Tabulky slouží pro uchovávání neprostorových (atributových) dat. Přístup jak k jejich schématu, tak i k jednotlivým záznamům (řádkům), poskytuje rozhraní ITable. Tabulky geodatabází jsou dokumentací ArcGIS označované jako třídy
objektů (object classes). Oproti „obyčejným tabulkám“ implementují navíc 26
rozhraní IObjectClass a nabízejí některé pokročilejší možnosti v podobě validací dat, definic podtypů tříd nebo použití specifických domén. Každý objekt třídy objektů musí mít definovaný jedinečný identifikátor ObjectID (typu Object ID), jehož roli lze přirovnat k úloze primárních klíčů relačních databází. Jelikož jsou třídy prvků potomky tabulek, je možné k nim stále přistupovat i přes rozhraní ITable. Obsah tabulek a datasetů tříd objektů je tvořena kolekcí řádků (rozhraní IRow), respektive kolekcí objektů (rozhraní IObject) [6]. Třídy prvků (FeatureClass) jsou potomky tříd objektů (ObjectClass). Jsou rozšířené o prostorovou informaci. Ta je reprezentována povinným atributem Shape, který představuje referenci na geometrii daného záznamu. Třídy prvků implementují rozhraní IFeatureClass, které umožňuje přístup k jejich typickým vlastnostem a metodám, stejně tak jak k jejich obsahu – kolekci objektů feature (objektů implementujících rozhraní IFeature) [6]. Více informací na tomto témata viz [6]: Working with feature data.
Atributová pole (fields) Jak uvádí [6], výše popsané typy datasetů se skládají z atributových polí, které lze přirovnat k sloupcům tabulky. Ty jsou v datasetu drženy v podobě kolekce typu IFields (nebo IFieldsEdit), která je zpřístupněna vlastností IClass.Fields,
respektive ITable.Fields nebo IFeatureClass.Fields. Konkrétní atributové pole, objekt typu IField, může být získán metodou IFields.get_Field(), jejímž jediným parametrem je index požadovaného pole. Následující kód ukazuje užití této metody v praxi: int fieldIndex = featureClass.FindField(fieldName); if (fieldIndex == -1) { // TODO: atributové pole neexistuje } IFields fields = featureClass.Fields; IField field = fields.get_Field(fieldIndex);
Metoda FindField(), vrací index atributového pole, který koresponduje s jeho jménem – vstupním parametrem metody; v kódu jde o proměnnou (string) fieldName. Pokud v kolekci polí žádné takové není, návratovou hodnotou metody je -1. Kolekce atributových polí je jedním ze vstupních parametrů metod vytvářejících nové datasety; např. CreateTable() nebo CreateFeatureClass()z rozhraní 27
IFeatureClass. Při vytváření těchto kolekcí je vhodnou praxí využívat validačních
služeb poskytovaných skrz IFieldChecker a přenechávat tvorbu povinných atributových polí metodě RequiredFields() patřící jednomu z rozhraní IFeatureClassDescription, IObjectClassDescription. [6] Příklady zdrojových kódů a více informací k tomuto tématu jsou dohledatelné na ArcObject Help for .NET developers: Creating and modifying schema.
3.3.2 Procházení a filtrování dat Pro obdržení konkrétního záznamu obsaženého v datasetu slouží v datovém modelu ArcGIS kurzor, objekt třídy Cursor. Ten představuje jednoduchý ukazatel, umožňující jednosměrný průchod kolekcí dat daného datasetu. Objekt kurzoru lze získat přes atributový nebo (v případě geodat) prostorový dotaz, vyvolaný prostřednictvím metody Search(), přístupné přes rozhraní ITable, případně IFeatureClass. V prvním případě tato metoda vrací kurzor typu ICursor, v tom
druhém IFeatureCursor. [6] Kód pro průchod jednotlivými řádky tabulky pak může vypadat následovně: ICursor cursor = table.Search(null, false); IRow row = cursor.NextRow(); while (row != null) { DoSomething(row); // zpracování získaného záznamu row = cursor.NextRow(); }
První parametr, přijímaný metodou Search(), je filtr (viz dále), který se před navrácením samotného kurzoru aplikuje na kolekci přistupovaných dat. Ve výše uvedeném případě má filtr hodnotu null, tudíž dojde k navrácení kurzoru odkazujícím na celou tuto kolekci (v tomto případě na všechny řádky tabulky). Druhý, booleanovský, parametr pak určuje, zda se má při průchodu jednotlivými objekty kolekce uplatňovat recyklace kurzoru. Více o recyklaci kurzoru viz [6]: Geodatabase API best practices.
Řádek (Row) nebo objekt třídy prvků (Feature) lze následně získat aplikací metody ICursor.NextRow(),
respektive
IFeatureCursor.NextFeature().
Žádné
metody typu zpět či reset kurzory nemají. Pro opětovný průchod datasetem je nutné získat kurzor nový [9].
28
Typy kurzorů Podle [6] se v aplikaci mohou kurzory vyskytovat ve třech formách, a to jako search, update, anebo insert cursor. Například dříve zmíněná metoda Search() vrací ukazatele typu search cursor. Naopak metoda Insert() navrací insert cursor a konečně metodou Update() lze získat upadate cursor. Před použitím některého z těchto ukazatelů je důležité uvědomit si jakého je typu, protože volání některých metod, jako třeba ICursor.InsertRow()
nebo
IFeatureCursor.InsertFeature(), na jiném typu ukazatele než insert má za
následek vyvolání výjimky. Stejně tak jako editační metody, volané na jiných než update ukazatelích. Filtry Programové rozhraní knihovny Geodatabase umožňuje vybírat data z datasetů pomocí specifických požadavků jak na neprostorové atributy, tak i geometrii těchto dat (možno pouze v případě tříd prvků). Takový požadavek je v datovém modelu ArcGIS reprezentován objektem třídy filtru, který implementuje některé z rozhraní IQueryFilter, respektive ISpatialFilter. Příklady zdrojových kódů a více informací k tomuto tématu jsou dohledatelné viz [6]: Querying data.
3.4 Geometrie prostorových dat Každá entita třídy prvků je definovaná svým tvarem a prostorovou referencí – informací o vztahu entity k použitému referenčnímu systému Země. Knihovna Geometry (namespace ESRI.ArcGIS.Geometry) poskytuje komplexní sadu tříd pro vektorovou reprezentaci bodů, linií, polygonů a dalších geometrických elementů, jako multipoints nebo multipathces, včetně podpory zmíněné prostorové reference [9].
3.4.1
Prostorová reference
Pomocí prostorové reference mohou být vektorové objekty geodat lokalizovány v reálném světě. Nedílnou součástí prostorové reference je použitý souřadnicový systém. Ten, podle [7], může být: •
Geographic coordinate system (GCS) – souřadnice jsou často v úhlových jednotkách (stupně, radiány) a vyjadřují zeměpisnou šířku (φ) a délku (λ) na zvoleném referenčním tělese (elipsoidu).
29
•
Projected coordinate system (PCS) – v úvahu je bráno i kartografické zobrazení (projekce). Jde tedy o rovinné souřadnice (x, y), které jsou do roviny projektovány (projekci lze chápat jako nějaký matematický vzorec) z GCS.
Součástí souřadnicových systému je i informace o použitých jednotkách míry (např. stopy, metry, stupně), o zvoleném referenčním modelu Země a v případě PCS i o použitém kartografickém zobrazení (tedy projekci). Dále se prostorová reference skládá z několika souřadnicových sítí (gridů). Úkolem těchto sítí je definovat jak přesnost jednotlivých souřadnic (jejich rozlišení), tak i rozsah obsaženého území. Podrobnější popis problematiky prostorové reference geodat a dalších geometrických objektů viz [7]: Georeferencing and coordinate systems a [6]: Working with spatial references .
3.4.2
Základní objekty geometrie
Každý geometrický objekt implementuje rozhraní IGeometry. Nejníže postaveným objektem při práci s geometrií je bod (třída Point implementující rozhraní IPoint). Ten slouží nejen pro reprezentaci bezrozměrných entit, ale je zároveň
i základním stavebním kamenem pro složitější geometrii, jakou představují například linie, polygony nebo multipatch. Bod je lokalizován v dvojdimensionálním prostoru souřadnicemi X, Y. Hloubka (třetí dimenze) bodu může být přidána atributem Z, nicméně jedná se skutečně jen o atributovou hodnotu a nijak nepostihuje prostorovost (tj. geometrii) bodu – bod je stále lokalizován jen dvěma rozměry [9]. Dalšími atributy mohou být M (measure) a ID (cizí klíč). To, zda se mají při operacích nad objekty geometrie brát v úvahu i tyto atributy lze ovlivnit rozhraním IZAware, IMAware respektive IPointIDAware. Zdrojový kód pro vytvoření bodu, by pak mohl vypadat následovně: IPoint point = new PointClass(); point.PutCoords(x, y); point.Z = z; ((IZAware)point).ZAware = true;
Body jsou využívány k tvorbě segmentů. V tomto případě se o bodech hovoří jako o vrcholech (vertexech). Segment (objekt typu ISegment) je funkce spojující vertexy. Knihovna Geometry rozeznává čtyři objekty segmentů: CircularArc, Line, ElipticArc a BezierCurve. Segmenty mohou být dále slučovány do kolekcí
tvořící buďto cesty (paths), anebo hranice (rings). Ty pak mohou tvořit 30
pokročilejší objekty geometrie, jako jsou linie (třída Polyline) v případě paths, anebo polygony (třída Polygon) v případě rings [9]. Obrázek 3 znázorňuje hierarchii při vytváření vyšších objektů geometrie, jakými jsou polygony a linie.
Obr. 3 Hierarchie objektů tvořících geometrii [9] Další objekty pro práci s geometrií GeometryEnviroment je singleton poskytující globální vlastnosti ovlivňujících práci s geometrií. Rovněž poskytuje řadu metod exponovaných z jiných objektů geometrie a umožňuje jejich použití v prostředí platformy .NET (a Java) [6]; více k tomuto v dokumentaci ArcObjects API, konkrétně pak v popisu rozhraní IGeometryBridge
a
IGeometryBridge2,
které
GeometryEnvirometnt
implementuje. Envelope představuje jakousi rovnoběžnou obálku nad objektem/objekty geometrie v kartézském souřadnicovém systému [9]. Každý objekt implementující rozhraní IGeometry je schopen poskytnou objekt envelope (IEnvelope). Prostorová reference envelope je pak shodná s prostorovou referencí tohoto objektu. GeometryBag je kolekcí odkazující na kterékoli objekty implementující IGeometry. Ty mohou být do kolekce GeometryBag přidány prostřednictvím metod rozhraní IGeometryCollection. Některé, například topologické, operace nad kolekcí
GeometryBag vyžadují přítomnost pouze jednoho typu geometrie (tj. bod, linie, polygon, segment, atd.) [9]. GeometryBag má rovněž svou vlastní prostorovou referenci, kterou po přidání sdílejí i jím obsažené objekty. Další informace geometrickém modelu ArcGIS a o práci s geometrií viz [6]: Working with geometry.
31
4 VÝVOJ ARCGIS FOR DESKTOP ADD-IN ArcGIS for Desktop add-in (dále jen add-in) je, podle [6], nový model vývoje a začleňování uživatelských doplňků do produktů ArcGIS for Desktop, který byl uvolněný společně s ArcGIS 10. Obsahem této kapitoly je stručná charakteristika tohoto modelu a popis jeho možností.
4.1 Charakteristika ArcGIS for Desktop add-in Každý add-in vystupuje jako jediný komprimovaný soubor s příponou esriAddin. Vše potřebné pro správnou funkčnost daného add-inu (softwarové knihovny, .NET sestavní, obrázky a všechny ostatní datové zdroje) musí být součástí tohoto souboru. Výhodou takového přístupu je snadná distribuce a sdílení add-inů mezi jednotlivými uživateli [6]. Omezení add-in modelu Každý add-in je limitován na předem daný výčet objektů (viz dále v kapitole „Typy add-in objektů“), které lze k rozšíření dané ArcGIS for Desktop aplikace použít [6]. Pokud je třeba rozšířit aplikaci v jiném bodě, než tento výčet dovoluje – např. implementace vlastních datových modelů nebo vykreslovacích vrstev (layers) a jejich rendererů – je již třeba využít klasický model rozšiřování samotných COM komponent ArcObjects. Více informací k rozšiřovaní ArcObjects o své vlastní komponenty viz [6]:
Extending
ArcObjects.
Dalším omezením, se kterým musí vývojáři add-inů počítat je, že daný model nedovoluje využívat externí knihovny a služby, které vyžadují registraci nebo administrátorská oprávnění [6]. To je daň za snadnou distribuci a integraci add-in doplňků, která nevyžaduje žádné instalátory, případně zvláštní uživatelská oprávnění.
4.1.1 Instalace a správa add-in doplňků Režie spojená s instalací nebo odstraněním daného doplňku je omezena na minimum – prosté nakopírování, respektive smazání, jediného souboru z patřičného adresáře. Odpadá tak nutnost jakýkoliv zásahů do systému, např. registrace dynamických (DLL) knihoven [6]. Součástí instalace ArcGIS for Desktop je i služba Add-in Instalation Utility (EsriRegAddIn.exe), která je asociovaná na esriAddin-soubory a celý proces instalace add-in doplňků automatizuje. Předtím uživateli poskytne všeobecné 32
informace spojené s daným doplňkem – jeho popis, verzi, autora, případně informaci o digitálním podpisu vydavatele. Správa add-in je umožněna prostřednictvím uživatelského prostředí některé z aplikací ArcGIS for Desktop, konkrétně pak přes dialogové okno Add-in Manager, dostupné z nabídky Customize. Uživatel zde také může vytvářet/odebírat adresáře, v nichž jsou jednotlivé add-iny hledány.
4.1.2 Typy add-in objektů Vývoj add-in doplňků je omezen na předem daný výčet typů komponent (objektů), o které je možné aplikace ArcGIS for Desktop rozšiřovat. Podle [6] jimi jsou: •
Button, tool – jednoduché ovládací prvky, které lze slučovat do panelů (objekty toolbar) nebo nabídek (objekty menu) v případě typu button. Zatímco button představuje prostý spouštěč akcí, provedených v reakci na událost „kliknutí“, ovládací prvek tool očekává následnou interakci s GUI aplikace.
•
Combo box – rozbalovací seznam s možností výběru jedné z uvedených, textem reprezentovaných, hodnot. Volitelně je jeho součástí i textové pole umožňující zadání vlastní hodnoty.
•
Menu, context menu – rozbalovací nabídka tvořená dalšími ovládacími prvky typu button, menu (pro tvorbu podnabídek) a multi-item.
•
Multi-item – nabídka, ne nepodobná výše uvedenému menu, která je vytvářena dynamicky až za běhu programu.
•
Toolbar – panel nástrojů poskytující prostor pro objekty typu button, tool, menu, tool palette a combo box. Tyto pak jsou (v rámci doplňkem cílené aplikace) uživatelsky mnohem lépe přístupné.
•
Tool palette – ovládací prvek umožňující vytvářet logická kompaktní seskupení příbuzných komponent typu tool.
•
Dockable window – volně plovoucí nebo ukotvená okna, hostovaná některou z ArcGIS for Desktop aplikací.
•
Application extension – extenze je nevizuální komponenta, schopná reagovat na změny stavu aplikace. Lze ji využít dvěma způsoby: 1) jako koordinátor mezi všemi dalšími typy objektů, které tvořící jeden add-id; 2) jako jakýsi správce callbacků, reagujících na události generované hostující aplikací. 33
•
Editor extension – jde o podobný add-in typ, jako application extension, nicméně namísto samotné aplikace obsluhuje jen editační relaci. Jinými slovy je editor extension načtena až po zahájení editační relace (Editor -> Start Editing) a reaguje na události s ní spojené.
Žádné jiné, nežli výše uvedené typy, není možné k tvorbě add-in využít. Pokud je nutné rozšířit funkčnost aplikací ArcGIS for Desktop v jiném bodě, je nezbytné využít přístupu v podobě rozšiřování COM komponent samotných ArcObjects.
4.1.3 Struktura add-in souborů Jak již bylo řečeno add-in je distribuován v podobě jediného souboru. Jedná se o komprimovaný („zazipovaný“) soubor se specifickou příponou esriAddin, obsahující celou řadu dalších dílčích souborů [6]. Lze se o tom snadno přesvědčit – stačí přejmenovat koncovku esriAddin-souboru na standardní ZIP a rozbalit jej.
Obr. 4 Struktura add-in (.esriAddin) souboru Součástí každého add-in je konfigurační XML soubor, Config.xml, který musí být přítomný na jeho kořenové úrovni. Tento soubor kompletně popisuje deklarativní část daného add-in doplňku (včetně popisných metadat). Většina add-in také obsahuje adresář Install s jeho imperativní částí (tj. především .NET sestavení). Zatím co Config.xml popisuje statické vlastnosti add-inu (layout kontrolních prvků, popisky, textová nápověda apod.), obsah adresáře Install ty dynamické (rekce na akce uživatele). Ne každý add-in musí obsahovat tento adresář. Některé add-in doplňky jako například toolbar, tool palette nebo menu jsou kompletně deklarativní a imperativní část kódu nepotřebují [6].
34
Po registraci add-inu aplikací je obsah složky Install automaticky rozbalen do dočasné složky (např. ..\AppData\Local\ESRI\Desktop10.0\AssemblyCache). Poté, co je daný add-in odinstalován, je odstraněna i tato cache. Součástí kořenového adresáře esriAddin je i podadresář Images, který obsahuje veškeré obrázky (např. ikony tlačítek a nástrojů, kurzory, apod.), na které je odkazováno prostřednictvím konfiguračního souboru. Další informace, nejen o souborové struktuře add-inů, jsou dohledatelné na [6]: Building addins for ArcGIS Desktop a Advanced add-in concepts.
Soubor esriAddin a jeho struktura, tak jak byla popsána výše, je výsledkem kompilace projektu ArcGIS for Desktop add-in, postaveném na některé z add-in šablon. Tyto šablony se stanou součástí daného vývojového prostředí (IDE) hned po instalaci balíčku nástrojů ArcObjects SDK (viz kapitola 2.2.4).
4.1.4
Desktop add-in šablony
V prostředí Microsoft Visual Studio je vývoj nových add-in doplňků do značné míry usnadněn přítomností již předpřipravených Desktop add-in šablon. Ty jsou součástí doplňků a integračních nástrojů instalovaných společně s balíčkem ArcObjects SDK. Šablony jsou ve Visual Studiu přístupné z dialogového okna pro založení nového projektu. Pro vývoj add-inů je dostupná čtveřice šablon – pro každou ArcGIS for Desktop aplikaci (ArcMap, ArcCatalog, ArcScene a ArcGlobe) jedna. Součástí každé šablony je i jednoduchý průvodce s uživatelským prostředím, který umožňuje během několika kroků nakonfigurovat, jak by měla šablonou generovaná kostra projektu vypadat (např. jaké typy add-in objektů budou využívány apod.). Současně lze pomocí průvodce nastavit statické vlastnosti add-inu, včetně některých jeho výchozích hodnot. Po ukončení průvodce je vygenerována základní kostra projektu, kterou tvoří konfigurační soubor (Config.xml) a základní implementace tříd objektů (viz kapitola 4.1.2) tvořících daný add-in. Velkou výhodou je, že takto vytvořený projekt je při kompilaci sestavován již rovnou do podoby souboru esriAddin. Více informací viz [6]: ArcGIS Visual Studio IDE Integration Framework for add-ins
4.2 Vlastní řešení add-inů pro aplikaci ArcMap V rámci této bakalářské práce byly vytvořeny tři add-in rozšíření pro aplikaci ArcMap: •
Export to Excel add-in, 35
•
Bookmark from selection add-in,
•
Google reverse geocoding add-in. Vytvořené add-iny (soubory .esriAddin), včetně jejich projektů z IDE Visual Studio Professional 2010, jsou součástí přiloženého paměťového media.
4.2.1
Export to Excel add-in
Export to Excel add-in je jednoduchou ukázkou, jak snadno lze rozšířit desktopovou aplikaci ArcGIS for Desktop o novou funkčnost s využitím knihoven třetích stran. Add-in umožňuje intuitivní export atributových (neprostorových) dat z jedné nebo více mapových vrstev do souboru pracovního sešitu Excel (tj. soubor .xlsx). Celý add-in tvoří jeden button (zasazený do vlastního panelu nástrojů), který je aktivní/neaktivní v závislosti na aktuálním výběru tříd prvků. Exportují se totiž právě jen vybrané objekty (záznamy) ze všech mapových vrstev tříd prvků. Jinými slovy pokud je výběr prázdný není co exportovat a button je tak neaktivní. Atributové hodnoty jsou exportovány do podoby, ve které je zobrazují atributové tabulky jednotlivých vrstev (s výjimkou hodnot typu geometry a blob, které jsou ignorovány); jsou tak exportovány i záznamy napojených (joint) tabulek apod. Vyexportovaný „excelovský“ sešit pak obsahuje tolik listů, z kolika mapových vrstev byla data exportována – pro každou vrstvu jeden. Pro generování tohoto sešitu byla využita opensource knihovna EPPlus. Další informace o této knihovně lze dohledat přímo na stránkách projektu; viz [13]. Třída ExportToExcelButton Veškerou
funkční
logiku
popisovaného
add-inu
obsahuje
jediná
třída
ExportToExcelButton, která dědí z ESRI.ArcGIS.Desktop.AddIns.Button.
Třída je poměrně jednoduchá a obsahuje jen několik málo vlastních metod. Klíčovou metodou je pak OnClick(), jenž představuje callback vyvolaný událostí „stisknutí buttonu“. V rámci této metody je vytvořen objekt představující „excelovský“ sešit a následně je pro každou mapovou vrstvu aktivní mapy, která obsahuje nějaký výběr, volána privátní metoda LayerToWorksheet(), která vytvoří a naplní nový list „excelovského“ sešitu. Na konci metody OnClick() se zavolá metoda Save(), která je zodpovědná za zobrazení dialogu „Uložit jako“ a následné uložení právě vytvořeného sešitu. Veškeré zdrojové kódy, které byly pro vytvoření add-inu napsány, jsou k dispozici na přiloženém záznamovém mediu.
36
Jak je vidět vytvořit podobný doplněk k ArcGIS for Desktop aplikaci není nikterak těžké. V podobném duchu byl vytvořen i add-in popsán v následující kapitole.
4.2.2
Bookmark from selection add-in
Bookmark from selection je další ukázkou jednoduchého ArcMap add-inu, který přidává možnost vytvoření nové záložky (položka nabídky Bookmark) odkazující na aktuální výběr prvků aktivní mapy. Podobně jako Export to Excel add-in (popsán v předchozí kapitole), je i tento add-in tvořen jedním buttonem. Veškeré zdrojové kódy, které byly pro vytvoření add-inu napsány, jsou k dispozici na přiloženém záznamovém mediu.
Po instalaci add-inu jej lze nalézt mezi ostatními ovládacími prvky ArcMap v kategorii „Add-In Controls“ (pod záložkou Commands dialogu Customize).
4.2.3
Google reverse geocoding add-in
Poslední add-in vytvořený v rámci této bakalářské práce je Google reverse geocoding. Oproti dvěma předchozím add-inům je tento o něco komplexnější. Je tvořen několika typy komponent (viz kapitola 4.1.2), které jsou vzájemně propojeny a vzájemně se ovlivňují. Add-in propojuje dvě veřejné (online) API, Google geocoding a Google static maps, a zpřístupňuje jejich služby uživatelům aplikace ArcMap. Dokumentace k oběma API je k dispozici na stránkách Google Developers; viz [14] a [15]. Google geocoding je geokódovací služba, která na základě parametrizovaných dotazů (např. poštovní adresa) na server vrací strukturovanou odpověď (např. zeměpisnou polohu) ve výměnném formátu JSON, anebo XML [15]. Popisovaný addin realizuje tzv. reverzní geokódování – ze zadané zeměpisné polohy (zeměpisná šířka a délka) získá seznam k této poloze příslušných adres. V rámci této bakalářské práce byla nad touto službou napsána jednoduchá abstraktní vrstva. Následující kód demonstruje její použití v praxi: Coords coords = new Coords((double)lat, (double)lng); GeocodingRequest request = new GeocodingRequest() { LatLng = coords }; GeocodingResponse response = null; try { GeocodingResponse response = request.GetResponse(); }
37
catch (WebException e) { // TODO: chyba internetového připojení } if (response != null) { foreach (GeocodeResult result in response.Results) { string fa = result.FormattedAddress; Coords sw = result.Geometry.Viewport.SouthWest; DoSomething(fa, sw); // zpracování výsledků } }
Google static maps je služba, která na základě url požadavku na její server vrací mapový výřez ve formě obrázku (JPEG, GIG nebo PNG) [14]. Google reverse geocoding add-in pomocí této služby zobrazuje mapové výřezy pro konkrétní výsledky reverzního geokódování. Podobně jako nad předchozí službou Google geocoding, byla i nad touto vytvořena jakási abstraktní vrstva pro usnadnění práce s ní; viz níže uvedený zdrojový kód: map = new StaticMap(ApiKey); // (string) Google API key map.Sensor = false; map.Format = MapFormat.png; map.Type = MapType.satelite; // vytvoření markeru marker = new MapMarker(“Olomouc, 17.listopadu 50”); marker.Color = MarkerColor.yellow; map. Markers.Add(marker); map.Centre = “Olomouc, 17.listopadu 50”; map.Zoom = 14; // url dotaz na Google static maps Uri url = map.GetUri();
Třída StaticMapsGeocodingExtension Klíčovou třídu tohoto add-inu představuje StaticMapsGeocodingExtension, potomek ESRI.ArcGIS.Desktop.AddIns.Extension. Třída obstarává dotazování na obě Google API a zpracování jejich odpovědí. Zároveň realizuje vzájemnou komunikaci mezi ostatními komponentami daného add-inu.
38
Následující výčet popisuje všechny vlastnosti a metody implementované touto třídou: •
GetExtension() – tato veřejná statická metoda zpřístupňuje instanci
StaticMapsGeocodingExtension ostatním objektům/komponentám add-inu. •
StaticMapsGeocodingExtension() – veřejný konstruktor třídy.
•
ResultsWindows – privátní vlastnost vracející objekt (komponentu add-inu)
ResultWindows. V případě, že jeho instance neexistuje, tak ji také vytvoří. •
MarkerTool – privátní vlastnost podobná té předchozí s rozdílem, že
návratovou hodnotou je objekt typu MarkerTool. •
OnStartup() - metoda je volaná ihned po startu aplikace (ArcMap). Provede
napojení handlerů na vybrané události aplikace; těmi jsou: NewDocument, OpenDocument a ActiveViewChanged. Následně poprvé inicializuje add-in. •
Initialize() – inicializuje stav (výchozí hodnoty) add-inu.
•
HasAppropriateGCS()
–
privátní
metoda,
jenž
kontroluje
(vrací
true/false), zda má aktivní mapové okno odpovídající referenční systém;
viz dále. •
WireActiveViewEvents() – provede napojení handlerů na události právě
aktivního mapového okna. •
OnDocumentSetUp() – handler událostí OpenDocument a NewDocument,
který je zodpovědný za inicializaci add-inu, viz metoda Initialize(). Zároveň volá metodu WireActiveViewEvents(). •
OnActiveViewChange()
–
handler
k
události
ActiveViewChanged.
V podstatě provádí to samé, co předchozí (výše popsaný) handler. •
OnSpatialReferenceChanged() – handler k události mapového okna
SpatialReferenceChanged. Rovněž je zodpovědný za inicializaci add-inu. •
Enabled – veřejná vlastnost informující ostatní komponenty add-inu, zda je
daný add-in povolen; konkrétně zda je nastaven odpovídající referenční systém. •
AddinLocation – veřejná vlastnost vracející aktuální lokaci (cestu k
adresáři) právě spuštěného sestavení add-inu; v praxi jde o cestu do add-in assembly cache. •
ApiKey – veřejná vlastnost, jenž vrací (případně i načítá) zadaný (případně
na disku uložený) Google API klíče. •
SetApiKey() – metoda pro zadání (trvale nebo jen v rámci relace spuštěné
aplikace) Google API klíč. 39
•
ShowHideResultsWindow() – veřejná metoda pro skrytí, anebo zobrazení
plovoucího okna se statickou mapou a seznamem výsledků reverzního geokódování. Metoda rovněž skrývá/zobrazuje označený bod mapového pole; viz dále (třída MarkerTool). •
ReverseGeocoding() – odesílá parametrizovaný dotaz na službu Google
geocoding a navrácené výsledky předává třídě ResultWindow. •
GetStaticMapImage() – odesílá parametrizovaný dotaz na službu Google
static maps a vrací obrázek mapového výřezu Google maps. •
InitializeStaticMap()
– vytváří parametrizovaný dotaz na službu
Google static maps. Některé další vybrané třídy, které Google reverse geocoding obsahuje: •
MarkerTool (Tool) – nástroj pro získání (označení) souřadnic v mapovém poli ArcMap, na které bude uplatněno reversivní geokódování (tj. získání adres/geokódů).
•
ResultWindow (UserControl) – plovoucí okno pro prezentaci výsledků obou použitých služeb – Google geocoding a Google Static Maps
•
ToogleButton (Button) – jednoduchý přepínač, který zobrazuje/skrývá výsledky.
•
ApiKeyButton (Button) – tlačítko pro dialog k zadání Google API klíče.
Většinou tyto třídy představují pouze jakýsi uživatelský vstup bez nějaké výraznější funkčnosti; ta je přenechána výše popsané třídě StaticMapGeocodingExtension, jejíž instance je dostupná všem objektům popisovaného add-inu. Omezení na souřadnicový systém Projekci, kterou využívá Google u svých mapových služeb je Web Mercator. Ten je projektován ze souřadnicového systému WGS84. Aby byla zaručena přesnost prováděného geokódování, bylo nutné omezit funkčnost add-inu jen na referenční systémy „postavené“ nad modelem WGS84. Třída StaticMapsGeocodingExtenzion kontroluje splnění tohoto požadavku metodou HasAppropriateGCS(). Veškeré zdrojové kódy, které byly pro vytvoření add-inu napsány, jsou k dispozici na přiloženém záznamovém mediu.
40
5 DISKUSE Původním záměrem a cílem této práce bylo vytvořit stručného průvodce základy práce nad komponenty ArcObjects. Nicméně po provedení rešerše a zjištění o jak rozsáhlý aplikační model se ve skutečnosti jedná, bylo nutné od tohoto prvotního záměru upustit a zaměřit se jen na určité aspekty práce s ArcObjects, jejichž popis by více odpovídal rozsahu bakalářské práce. Bakalářská práce se tedy zaměřuje především na vývoj add-in doplňků a rozšíření k aplikacím ArcGIS for Desktop. Obecný popis práce s komponenty ArcObjects je pak omezen jen na takovou míru, aby pokrýval právě jen ty oblasti, které se přímo týkají v rámci práce vytvořených add-inů. Je také třeba upozornit, že i přes snahu obsáhnou teoretickou část pokud možno co nejjednodušeji, je pro její plné pochopení nutná alespoň elementární znalost principů (objektově orientovaného) programování. Vytvořené ArcMap add-iny jsou vzájemně funkčně poměrně dost vzdálené. Cílem jejich vývoje bylo ukázat, že add-iny představují relativně snadný a rychlý model vývoje, který dovoluje přizpůsobit nebo o vlastní funkčnost rozšířit kteroukoliv z ArcGIS for Desktop aplikací. Ačkoliv jsou všechny vytvořené add-iny v praxi plně využitelné, nebylo jejich produkční nasazení prioritou při jejich vývoji. Jinými slovy, motivem k jejich vývoji nebyla řešení specifických problémů nebo potřeb na rozšíření funkčnosti aplikace ArcMap. Je zřejmé, že vytvořené add-iny neodhalují plný potenciál a možnosti využití komponent ArcObjects ve spojení s platformou .NET Framework, nicméně i přesto mohou sloužit jako zajímavé ukázky, co a jak lze s pomocí nového ArcGIS for Desktop add-in modelu vytvořit. Mimo již zmíněný model vývoje desktop add-inů, lze aplikace ArcGIS for Desktop upravovat, či rozšiřovat přímo na úrovni samotných komponent ArcObjects. Tímto způsobem je možné aplikace rozšířit nebo upravit téměř v jakémkoliv jejich bodě. Lze tak například vytvářet zcela nové typy symbolů, vykreslovacích vrstev a jejich rendererů a rozšiřovat tak možnosti kartografické prezentace vlastní aplikace. Ač je tento způsob využití komponent ArcObjects v práci několikrát zmíněn, není již dále více rozebírán. Hlavním důvodem je, mimo omezený rozsah bakalářských prácí, především relativní složitost architektury aplikací ArcGIS for Desktop, jejíž znalost je v tomto případě nutností. Podobně, jen v krátkosti, byly zmíněny i dva další okruhy využití a práce s komponenty ArcObjecs: 1) Vývoj nad produktem ArcGIS Engine, kdy je možné vytvořit vlastní softwarové řešení pro GIS, jenž bude postavené přesně na míru a ve 41
srovnání s krabicovými GIS produkty i za přijatelnější náklady. Pro tuto možnost vývoje nad produktem ArcGIS Engine je však nutná, kromě licence samotného běhového prostření komponent ArcObjects, také vývojářská licence. 2) Tvorba vzdálených aplikací a služeb na bázi klient-server nad produktem ArcGIS for Server. Na závěr je třeba poznamenat, že ať již je využita funkčnost kteréhokoliv z produktů ArcGIS for Desktop, ArcGIS Engine nebo ArcGIS for Server, pořad se jedná o jedny a ty samé komponenty ArcObjects, a tak i práce s nimi se prakticky nijak výrazně neliší.
42
6 ZÁVĚR V rámci bakalářské práce byly popsány některé možnosti praktického uplatnění platformy .NET Framework ve spolupráci s knihovnami ArcObjects, které tvoří aplikační infrastrukturu produktů ArcGIS for Desktop, ArcGIS Engine nebo ArcGIS for Server. Zvláštní pozornost pak byla věnována novému modelu rozšiřování funkčnosti aplikací ArcGIS for Desktop pomocí tzv. add-inů. Mimo textové části popisující samotný model add-in doplňků a vývoj nad tímto modelem, je součástí této práce i praktická ukázka v podobě tří vytvořených add-in rozšíření pro aplikaci ArcMap. Konkrétně byly vytvořeny následující add-iny: •
Export to Excel – jednoduchá ukázka spolupráce se softwarovými knihovnami třetích stran. Add-in umožňuje export atributových tabulek jednotlivých mapových vrstev do souboru pracovního sešitu Excel.
•
Bookmark from selection – jednodušší ukázka uplatnění add-inů pro automatizaci pracovního postupu. Add-in zřetězuje několik kroků nutných pro vytvoření záložky nad aktivním výběrem.
•
Google reverse geocoding – příklad komplexnějšího add-inu, který využívá vzdálené, online dostupné, služby pro realizaci reversivního geokódování, jehož výsledky jsou následně zobrazeny jako mapový výřez v plovoucím okně aplikace.
Tyto add-iny, stejně jako jejich projekty vývojového prostředí Visual Studio 2010, jsou součástí přiloženého paměťového média.
43
POUŽITÁ LITERATURA A INFORMAČNÍ ZDROJE [1] Microsoft, „Overview of the .NET Framework,“ Microsoft, [Online]. Dostupné z: http://msdn.microsoft.com/en-us/library/zw4w595w.aspx. [Přístup získán 2012-12-12]. [2] A. Troelsen, Pro C# 2008 and the .NET 3.5 Platform, Apress, 2007. [3] Microsoft, „.NET Downloads, Developer Resources and Case Studies,“ 2013. [Online]. Dostupné z: http://www.microsoft.com/net/. [Přístup získán 201302-03]. [4] T. Nash, C# 2010 Rychlý průvodce novinkami a nejlepšími postupy, Computer Press, a.s., 2010. [5] Microsoft, „Visual Studio,“ [Online]. Dostupné z: http://msdn.microsoft.com/csCZ/vstudio. [Přístup získán 2013-02-03]. [6] ESRI, „ArcObjects Help for .NET,“ [Online]. Dostupné z: http://resources.arcgis.com/en/help/arcobjects-net/conceptualhelp/. [Přístup získán 2013-02-02]. [7] ESRI, „ArcGIS Help 10.1,“ [Online]. Dostupné z: http://resources.arcgis.com/en/help/main/10.1/. [Přístup získán 2013-0202]. [8] ESRI, „Introducing ArcGIS for Desktop,“ [Online]. Dostupné z: http://resources.arcgis.com/en/help/gettingstarted/articles/026n00000005000000.htm. [Přístup získán 2013-02-02]. [9] ESRI, „ArcObjects API Reference for .NET,“ [Online]. Dostupné z: http://resources.arcgis.com/en/help/arcobjects-net/componenthelp/. [Přístup získán 2013-02-03]. [10] ESRI, „Web ADF for the Microsoft .NET Framework,“ [Online]. Dostupné z: http://resources.arcgis.com/content/web-adf-microsoft-net-framework. [Přístup získán 2013-02-03]. [11] ESRI, „ArcObjects SDK 10 System Requirements,“ [Online]. Dostupné z: http://resources.arcgis.com/content/arcgissdks/10.0/system-requirements.
44
[Přístup získán 2013-02-02]. [12] ESRI, „System Requirements,“ [Online]. Dostupné z: http://resources.arcgis.com/en/help/system-requirements/10.1/index.html#. [Přístup získán 2013-02-03]. [13] „EPPlus - Create advanced Excel 2007 spreadsheets on the server,“ [Online]. Dostupné z: http://epplus.codeplex.com/. [Přístup získán 2013-02-02]. [14] Google, „Static Maps API V2 Developer Guide,“ 2013. [Online]. Dostupné z: https://developers.google.com/maps/documentation/staticmaps/. [Přístup získán 2013-03-01]. [15] Google, „The Google Geocoding API,“ 2013. [Online]. Dostupné z: https://developers.google.com/maps/documentation/geocoding/. [Přístup získán 2013-03-01].
45
SUMMARY The main aim of the bachelor thesis is describe possibilities of cooperation between .NET Framework and ArcObjects – a collection of SW libraries which underlies ArcGIS for Desktop, ArcGIS Engine and ArcGIS for Server applications or services. The thesis also describes some basics of working with ArcObjects components on the .NET development platform. Special attention is paid to the new add-in model for customizing and extending ArcGIS for Desktop applications by custom functionality. A practical part of the thesis is based on three customs add-ins for ArcMap, which were created as a simple demonstration of possibilities of this new model. The first one is Export to Excel add-in. The add-in exports selected attribute data from one or more map layers to a new Excel workbook. Its functionality is based on an open-source library. The second add-in is a simple demonstration of workflow automation. The add-in simply creates a bookmark that refers to currently selected features. The last created addin connects two public APIs (Google Geocoding and Google Static Maps) to perform reverse geocoding. All these add-ins were created as practical examples of using the new add-in model and development framework for extending or customizing some of ArcGIS for Desktop applications and they are – including source codes – a part of digital attachment of the thesis.
46
