Tvorba uživatelsky přívětivého mapového portálu

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Tvorba uživatelsky přívětivého mapového portálu Diplomová práce Vedoucí práce: Ing. David Procházka, Ph.D. Bc. Ondřej Svoboda V Brně 2013

2 STRANA PRO UMÍSTĚNÍ ZADÁNÍ DIPLOMOVÉ PRÁCE 2

3 Zde bych rád poděkoval vedoucímu mé diplomové práce Ing. Davidu Procházkovi, Ph.D. za cenné rady, kritiky i připomínky, které mi udílel při tvorbě této práce. Dále bych chtěl poděkovat své rodině za podporu během celého studia.

4 Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně a v seznamu literatury uvedl veškeré informační zdroje, které jsem použil pro její tvorbu. V Brně

5 5 Abstract Development of user-friendly map portal This thesis deals with map portal development. The reader is introduced into basic concepts of online GIS systems, next part contains review of available frameworks for geodata processing and review of available frameworsk for graphical user interface development in Java EE language. The folowing part describes detail phase of application designing and reader is introduced into particular design patterns. The last part of thesis describes design and implementation of new web-based map portal. Keywords: GIS, GUI Patterns, GUI Design, Map portal, Java EE Abstrakt Tvorba uživatelsky přívětivého mapového portálu Tato diplomová práce se zabývá problematikou tvorby vlastního mapového portálu. V úvodní části práce je čtenář seznámen se základními pojmy z prostředí webových GIS, je provedena rešerše dostupných rámců pro práci s geodaty a pro tvorbu GUI webových aplikací v Java EE. V následující části je podrobně rozebrána fáze návrhu aplikace, čtenář je seznámen s jednotlivými návrhovými vzory. Ve vlastní práci byl proveden návrh a implementace vlastního mapového portálu. Klíčová slova: GIS, GUI, Návrhové vzory, Mapový portál, Java EE

6 OBSAH 6 Obsah 1 Úvod a cíl práce Úvod Cíl Technologie a standardy Standardy a organizace Web Maping Service (WMS): Web Map Tile Service (WMTS): Web Feature Service (WFS): API pro tvorbu GUI Webových aplikací Google Web Toolkit Apache Struts Java Server Faces a Prime Faces Spring Framework API pro práci s prostorovými geodaty Google Maps JavaScript API v OpenLayers API LeafLet API Srovnání vlastností Mapito projekt Návrh aplikace Analýza uživatele Vzory chování uživatelů Návrh aplikace Přístupy k designu rozhraní Návrhové vzory pro strukturu aplikace Přechody mezi stavy aplikace Pozice v aplikaci Operace Metodika práce 30 5 Vlastní práce Analýza uživatele Přímé pozorování uživatelů Návrh aplikace Specifikace Implementace Výsledná aplikace Problémy během začátku vývoje Zprovoznění aplikace

7 OBSAH Navigace v mapě Správa uživatelů Správa plánků Správa vrstev Editor objektů vrstev Překlad názvů do geografických souřadnic pomocí Google Geocoding API Odezva prováděných akcí Aplikované návrhové vzory Uživatelské testování Diskuze Možnosti využití obdobných aplikací ve firemním prostředí Možnosti budoucího rozvoje projektu Závěr 51 8 Reference 52

8 1 ÚVOD A CÍL PRÁCE 8 1 Úvod a cíl práce 1.1 Úvod Díky rozmachu moderních technologií v posledních letech postupně dochází k zásadním změnám v chápání prostorových dat jak na uživatelské, tak na autorské úrovni. Pojem mapa dnes u uživatelů nevyvolá představu papírového plánku, ale spíše si většina představí interaktivní technický nástroj. Online mapy se stávají nepřehlédnutelnou součástí našeho života. Drtivá většina restaurací, památek, měst, zkrátka všech míst na zeměkouli, která jsou identifikovatelná zeměpisným umístěním, má na svých webových stránkách mapku dané lokality. Mapy lze také považovat za součást života sociálního. Miliony uživatelů denně využívají Facebook, Twitter či Google Plus a každá uveřejněná aktivita na těchto sítích v sobě nese záznam v podobě lokace. Výkonné počítače a různá mobilní zařízení jsou dnes samozřejmostí a díky tomu mají uživatelé přístup k mapovým službám téměř kdykoliv. Naprostá většina uživatelů dnes při vyhledávání tras nebo určitých bodů zájmů sáhne po některé z dostupných webových služeb. Pokud by si však uživatel chtěl vytvořit nebo alespoň částečně přizpůsobit vlastní plánek, tak má smůlu. Nástrojů pro prohlížení mapových vrstev existuje obrovské množství, kdežto nástroje, které by nám umožňovali editaci prostorových geodat, téměř neexistují. Výjimkou jsou složité robustní systémy, které jsou pro běžného uživatele nepřehledné a nepochopitelné. Proto by bylo vhodné přijít s něčím novým a jednodušším, s něčím co by uživatelům přineslo možnost vyzkoušet si a případně dlouhodobě využívat nástroje pro tvorbu vlastních plánků, aniž by museli investovat spoustu času a peněz na jejich zprovoznění. Bylo by ideální nabídnout takovýto nástroj ve formě webové aplikace, která bude jednoduše dostupná online a jediným krokem pro zprovoznění ze strany uživatele by bylo zadání URL adresy tohoto nástroje. 1.2 Cíl Cílem vlastní práce bude tvorba uživatelsky přívětivého mapového portálu. V práci se budu zabývat problematikou konstrukce vlastního geoportálu, rozborem dostupných knihoven pro tvorbu GUI webových aplikací a rozborem knihoven sloužících k zobrazení mapových vrstev. Bude provedena identifikace funkcí, které při své práci využívají uživatelé GIS začátečníci. Na základě této identifikace bude proveden návrh grafického uživatelského rozhraní. Dále budou vybrány nejvhodnější API a bude proveden návrh a implementace vlastního geoportálu.

9 2 TECHNOLOGIE A STANDARDY 9 2 Technologie a standardy 2.1 Standardy a organizace Klasický portál je webová stránka, která se chová jako přístupová brána k vícero zdrojům z jednoho místa. Jedná se o webové rozhraní, které umožňuje organizacím nebo komunitám uživatelů shromažďování a sdílení určitého obsahu. Mapový portál je uživatelské rozhraní pro přístup k online kolekcím geoprostorových informačních zdrojů, zahrnující datové sady a služby. Po celém světe jsou rozvíjeny různé infrastruktury prostorových dat, tyto infrastruktury dohromady tvoří Globální infrastrukturu prostorových dat (Global Spatial Data Infrastructure). Jelikož po celém světě jsou značné rozdíly v hospodářských, sociálních a právních rámcích, bylo nutné přinést infrastrukturám jasný řád. Díky koordinačním snahám řídícího výboru Global Spatial Data Infrastructure (asociace GSDI) došlo ke stanovení jasné podoby a obsahu jednotlivých elementů těchto infrastruktur. GSDI asociace v sobě zahrnuje společnosti, agentury i jednotlivce z celého světa. Velice významným subjektem v oblasti mapových služeb je Open Geospatial Consortium. OGC je mezinárodní asociace více jak 480 firem, vládních agentur a vysokých škol z celého světa, které se účastní rozvoje veřejně dostupných standardů rozhraní. Tyto standardy dávají vývojářům možnost vyvíjet komplexní služby, které díky tomu mohou být dostupné pro vývoj rozličných druhů aplikací. (OGC, 2013) Standardů OGC je celá řada, detailnějšímu popisu se budu věnovat jen u těch, které bych rád využil ve vlastní práci, konkrétně se jedná standardy WMS, WMTS a WFS Web Maping Service (WMS): Standard Web Map Service poskytuje jednoduché HTTP rozhraní pro získávání georeferencovaných rastrových mapových dat z jedné či více distribuovaných geodatabází. WMS požadavek definuje požadované vrstvy a oblasti zájmů, které mají být zpracovány. Odpovědí na požadavek jsou rastrová data (data jsou vracena jako JPEG, PNG, GIF apod. ), která mohou být zobrazena v klientské aplikaci. Rozhraní dále podporuje možnost určit, zda vrácené snímky mají být průhledné, nebo aby bylo možné kombinovat vrstvy z více serverů. Tento standard definuje dvě třídy, jednu pro základní WMS, druhou pro Queryable WMS. Každá z těchto tříd obsahuje dvě podtřídy - jednu pro klientskou stranu, druhou pro servery. Basic WMS musí podporovat: Požadavek GetCapabilities, který na základě požadavku specifikovaného v URL(viz. tabulka) navrací XML dokument. Tento dokument hraje zásadní roli. Jsou v něm obsažena metadata, které nám pomáhají identifikovat všechny potřebné informace o dané WMS. Odpověď obsahuje řadu informací, které pro náš účel nyní nebudou podstatná. Důležité jsou pro

10 2 TECHNOLOGIE A STANDARDY 10 nás primárně tagy LAYER, CRS, NAME a BoundingBox. LAYERS nám říká, kolik služba nabízí vrstev. CRS (zkratka pro Coordinate Reference Systems) určuje, v jakém souřadném systému služba poskytuje podklady, NAME popisuje unikátní název vrstvy, pod kterým se může vrstva připojit z vlastní aplikace. Jméno vrstvy nám samo o sobě nemusí nic říkat o jejím obsahu, proto se v getcapabilites nachází u vrstev tag TITLE, který nám zastupuje srozumitelný název vrstvy. Položky BoundingBox jsou pro nás užitečné v případě, že nemáme ponětí jakou oblast vrstva pokrývá. BoundingBox nám určuje souřadnice linií hraničních oblasti vrstev. Na listingu číslo 1 je zobrazena ukázka odpovědi getcapabilites dotazu. (MITCHELL, 2005) 1 <WMS_Capabilities> 2 <Service>...</Service> 3 <Capability> <Layer> <Layer> 8 <Name>GR_ZM50</Name> 9 <Title>Základní mapa 1:50 000</Title> <CRS>EPSG:4326</CRS> <BoundingBox CRS= EPSG:4326 miny= 11 minx= 47 maxy= 19 maxx= 51 /> </Layer> 16 </Layer> 17 </Capability> 18 </WMS_Capabilities> Listing 1: Ukázka struktury getcapabilities XML Parametr požadavku Povinné Popis VERSION=version Ne Verze požadavku SERVICE=WMS Ano Typ služby REQUEST=GetCapabilites Ano Název požadavku FORMAT=MIME_type Ne Formát navrácených metadat UPDATESEQUENCE=string Ne Ovládání mezipaměti Tabulka 1: Parametry URL požadavku GetCapabilities Požadavek GetMap: odpovědí na tento požadavek jsou výsledná rastrová data. Queryable WMS musí podporovat operace Basic WMS a dále pak požadavek GetFeatureInfo. Tento požadavek je podporován pouze vrstvami, které mají nastavený atribut queryable = 1. GetFeatureInfo operace je vytvořena pro poskytnutí detailnějších informací týkající se určitých vrstev. Základní příkladem užití může být případ, kdy na klientské straně byl již zpracován požadavek GetMap, klient výběrem bodu (souřadnice I,J) na zobrazené mapě dokáže pomocí tohoto požadavku získat detailnější informace o prvcích nacházejících se pod tímto bodem. Povinnými parametry dotazu jsou: VERSION,

11 2 TECHNOLOGIE A STANDARDY 11 Parametr požadavku Povinné Popis VERSION=1.3.0 Ano Verze požadavku REQUEST=GetMap Ano Název požadavku LAYERS=seznam_vrstev Ano Seznam vrstev, oddělen čárkami STYLES=seznam_stylu Ano Seznam renderovacích stylů CRS=namespace:idetifier Ano Koord. systém BBOX=minx,miny,maxx,maxy Ano Hranice v CRS jednotkách WIDTH=sirka Ano Šířka mapy v px HEIGHT=vyska Ano Výška mapy v px FORMAT=format Ano Formát navrácených metadat TRANSPARENT=value Ne Průhlednost(TRUE F ALSE) BGCOLOR=value Ne Barva pozadí EXCEPTIONS=format Ne Formát reportovaných vyjímek TIME=time Ne Požadované časové určení vrstvy ELEVATION=elevation Ne Požadovaná nadmořská výška vrstvy Další dimenze Ne Hodnota dalších dimenzí dle potřeb Tabulka 2: Parametry URL požadavku GetMap REQUEST, QUERY_LAYERS, INFO_FORMAT, I, J. Nepovinné parametry: FEATURE_COUNT,EXCEPTIONS. (OGC, 2006) Web Map Tile Service (WMTS): Tento implementační standard umoňuje poskytovat mapová data užitím předdefinovaných obrazových dlaždic. Principiálně se jedná doplněk předešlého WMS. Díky členění na dlaždice umožňuje služba pracující s tímto standardem větší výkonnost a změnu zobrazovaného obsahu podle měřítka. Důležitou součástí této služby je, aby server dokázal zpracovat asynchronní přístup k dlaždicím, jelikož od většiny klientů bude přicházet požadavek na více dlaždic současně. WMTS rozhraní umožňuje klientovi získat tři druhy zdrojů buď v reakci na požadavek na zdroje ve zdrojově orientované architektuře nebo v reakci na operaci v procedurálně orientované architektuře. Těmito zdroji a operacemi jsou: Zdroje metadat služeb jako odpověď GetCapabilities operace pro procedurálně orientovanou architekturu. Dlaždicové zdroje jako odpověď na GetTile operaci dojde k navrácení dlaždicového fragmentu vrstvy. Feature info zdroje jako odpověď na GetFeatureInfo. Totožné s WMS GetFeatureInfo. (OGC, 2010)

12 2 TECHNOLOGIE A STANDARDY Web Feature Service (WFS): Jak již bylo psáno dříve, WMS služby navrací data ve formě rastrových obrazových dat a tato data není možné koncovým uživatelem přímo editovat nebo provádět nad nimi analýzy. Řešením je standard WFS. Tento mezinárodní standard určuje chování služeb, které poskytují transakční přístup ke geografickým datům způsobem, který je nezávislý na druhu uložení vlastních dat. WFS služby umožňují klientovi přijímat a upravovat geodata ve formátu GML (Geography Markup Language). GML je dalším z OCG standardů (je také standardem ISO 19136:2007). GML jazyk je nástroj pro uchovávání a přenos geografických informací v jazyce XML. Pro podporu transakcí a zpracování dotazů byla definována skupina následujících operací: GetCapabilities: WFS služba musí být schopna popsat vlastní možnosti. Konkrétně musí být schopna definovat, které typy prvků je možné poskytnout a jaké operace jsou podporované na každém typu prvku. DescribeFeatureType: WFS musí být schopna na základě požadavku popsat strukturu jakéhokoliv prvku, který obsluhuje. GetFeature: musí být schopem obsloužit požadavek o získání instancí prvků. Kromě toho by měl klient mít možnost specifikovat, které vlastnosti prvků chce zahrnout, a měl by být schopen vymezit dotaz jak z prostorového, tak z ne-prostorového hlediska. GetGmlObject: schopnost obsluhovat žádosti o načtení prvků instance projížděním jednotlivých XLinků, které odkazují na jejich XML ID. Kromě toho by měl být klient schopen určit, zda by XLinky (vnořené v navrácených datech) měly být také navráceny. Transaction: WFS musí být schopna zpracovat transakční požadavky. Tyto požadavky se skládají z operací, které modifikují jednotlivé geografické prvky (operace vytvořit, aktuailzovat a odstranit). LockFeature: WFS by měla být schopna zpracovat blokovací požadavek na jednu nebo i více instancí typů prvků po dobu trvání transakce. Tímto je zajištěna podpora serializovaných transakcí. Jak u WMS, tak i WFS je možné rozdělit do skupin podle vlastností a obsažených operací. WFS mají definovány následující tři třídy: Basic WFS by měla implementovat GetCapabilities, DescribeFeatureType and GetFeature. Takováto služba tedy nabízí jen funkce pro načítení prvků, nikoliv pro editaci.

13 2 TECHNOLOGIE A STANDARDY 13 XLink WFS by měla podporovat všechny operace základního WFS, dále potom GetGMlObject pro lokální nebo i vzdálené XLinky. Transaction WFS by měla opět podporovat všechny operace základní WMS, dále pak bezpodmínečně transakční operace. Nepovinně potom operace GetGmlObject a (nebo) LockFeature. (OGC, 2010)

14 2 TECHNOLOGIE A STANDARDY API pro tvorbu GUI Webových aplikací Na základě konzultace byl pro implementaci zvolen programovací jazyk Java, a proto se zaměřím na rešerši dostupných API pro tento programovací jazyk. Tato práce se zaměřuje na uživatelskou přívětivost. Použitý Framework by tedy měl umožňovat snadnější implementaci návrhových vzorů, popsaných v další části Google Web Toolkit I když se jedná o framework vyvíjený společností Google, je poskytován pod Open Source licencí. Tento rámec slouží k vývoji RIA aplikací (Rich Internet Applications), plně využívajících výhod AJAXu. Pro vývojáře je dostupný plugin pro IDE Eclipse. Plugin se skládá z vlastní knihovny, integrovaného kompilátoru a App Engine. Výhodou tohoto nástroje je, že vlastní vývoj klientské i serverové části kódu může probíhat přímo v čistém jazyce Java, avšak klientská část je před nasazením zkompilována do html a JavaScrtipu. Jako další doplněk je dostupný GWT Designer. Tento nástroj umožňuje sestavit rozhraní webové aplikace pomocí grafického rozhraní designeru. Google web toolkit umožňuje provázání se službou Google App Engine. Tato služba poskytuje vývojáři možnost nasadit aplikaci přímo z IDE. Odpadá nutnost hledání vhodného hostingu pro vlastní aplikaci. App Engine hosting na appspot.com je v základní verzi zdarma, avšak bezplatná verze s sebou přináší určitá omezení poskytovaných zdrojů. Je však možné připlatit si za dodatečné kapacity. Nevýhodou App Enginu je neúplná podpora standardních Java EE API. Vývojář je odkázán na JRE Class White List, který obsahuje seznam tříd dostupných pro App Engine. App Engine dále umožňuje v IDE spouštět a debugovat aplikace ve vývojářském módu, kdy není nutné po každé změně klientského kódu provádět kompilaci. Pro tento rámec dále existuje rozšiřující knihovna SmartGWT. Tato knihovna obsahuje rozsáhlé množství komponent pro grafické uživatelské rozhraní, každá komponenta umoňuje množství metod pro řízení událostí Apache Struts Mezi nejvýznamnější server-side frameworky, které se objevily v posledních letech, patří Jakarta Struts Web aplication development framework. Struts vděčí své popularitě zejména i díky implementaci návrhového vzoru MVC (Model-View-Controller), krerý definoval Trygve Reenskaug již v roce 1979 pro jazyk Smalltalk. Jedním z problému užití JSP (Java Server Pages) a servletů bez dodatečných rámců je, že vývojáři mají sklon míchat UI a server-side kódu na jednom místě (JSP stránka), což vedlo k předvídatelným problémům. Struts vyřešil tento problém striktním následováním MVC vzoru, kde pohled (View) definuje kód uživatelského prostředí a model je kód na straně serveru pro zpracování aplikačních dat. Kontroler ve Struts je zjednodušeně řečeno servelet, který zpracovává všechny příchozí webové požadavky a odesílá je odpovídajícím stránkám nebo kompentám

15 2 TECHNOLOGIE A STANDARDY 15 pohledu. Pro přístup k modelu nebo k aplikačním datům struts využívá takzvané Akce. Akce jsou adaptére mezi obsahem přicházejícího HTTP požadavku a odpovídající aplikační logikou, která by měla tento požadavek zpracovat. Struts dále poskytují pro pohled skromnou sadu knihoven s JSP tagy. Tyto knihovny umožňují renderovat běžné HTML elementy, zobrazovat zprávy a práci s logickými operacemi. (BURNS, 2010) Java Server Faces a Prime Faces JSF je součástí standardu Java EE 1. Zprovoznění je tedy velmi jednoduché, v podstatě stačí nastavit konfiguraci v deployment descriptoru (soubor web.xml). JSF kombinuje návrhový vzor MVC s mohutným, komponentově orientovaným rámcem pro tvorbu uživatelského rozhraní. Jednotlivé stránky jsou tvořeny XHTML Facelet soubory na straně pohledu(view) a JavaBean komponentami, které se stará o zpracovávání výstupu z uživatelského rozhraní klienta. Pro JSF existuje řada rozšiřujících knihoven, které přináší další prvky GUI. Jedním z těchto rámců je Prime Faces. Instalace je opět velice jednoduchá, jedná se o jednu knihovnu, kterou je jen potřeba umístit do classpath projektu. Výhodou tohoto rozšíření je již v základu integrovaná rozsáhlá řada komponent pro implementaci Google Maps API V Spring Framework Krátce po tom, co se stal Struts de facto standardním webovým rámcem, vyvinul Rod Johnson Spring jako alternativní programovací model pro J2EE. Nejpodstatnější inovací, kterou tento rámec přinesl, byl návrhový vzor Inversion of Control. Mnoho rámců se nám snaží zjednodušit některé části vývoje, filozofií Springu je zjednodušit komplexně vývoj v J2EE. Toho se snaží dosáhnout lehkým a neinvazivním vývojem využívajícím POJO(plain old Java objects) a volným spojením objektů za pomocí vkládání závislostí. POJO jsou Java objekty, které neimplemenentují žádné rozhraní ani nerozšiřují žádnou konkrétní třídu. Spring nabízí vlastní plugin pro IDE Eclipse Spring Tool Suite, dále vlastní MVC rámec. (BURNS, 2010) 1 Od roku 2006 je součástí Java EE 5. Verze JSF v tomto roce byla 1.2. V současné době ve vývoji verze 2.2 pro Java EE 7.

16 2 TECHNOLOGIE A STANDARDY API pro práci s prostorovými geodaty V následující části práce budou rozebrány dostupné API pro práci s prostorovými daty. Primárně se zaměřím pouze na ty rámce, které nabízí zdarma licence pro nekomerční užití Google Maps JavaScript API v3 V minulosti byly využívaným nástrojem Mapplety. Jednalo se o rámec pro tvorbu menších webových aplikací, které pracují s Google Mapami. Strukturálně byly maplety tvořeny XML souborem, který obsahuje HTML a JavaScriptové zdrojové kódy. Výsledkem byl Gadget, který si uživatelé mohli umístit na své webové stránky (YOUNG, 2008). I když se jednalo o vcelku rozšířený nástroj, Google ukončil podporu 19. května Mapplety vytvořené do tohoto data by stále mely být funkční, není však možné vytvářet nové. Vzhledem k nefunkčnostem Mappletů se tedy zaměřím na aktuální JavaScriptové Google Maps API 3. Google mapy byly poprvé představeny v únoru roku Způsobilo to revoluci v principech práce s mapou ve webových aplikacích. Uživatelé poprvé mohli měnit zobrazovanou oblast mapy pouhým přetažením. Mapová řešení využívaná do této doby byla velmi nákladná, vyžadovala speciální mapové servery a i přesto nenabízela srovnatelnou úroveň interakce. Ještě předtím, než bylo dostupné veřejné API, se podařilo některým vývojářům obejít ochranu a využívat funkčnosti Google map na svých webových stránkách. Obdobné kroky nakonec Google přesvědčily o tom, že je značná poptávka po veřejném API. Díky tomu bylo již v červnu roku 2005 uvolněno Google Maps API i pro širokou veřejnost (SVENNERBERG, 2010). V současné době je toto API stále pod vlastnictvím společnosti Google a to v sobě přináší daň ve formě určitých omezení. Jedním z těchto omezení je limit požadavků pro načtení mapy za jeden den. Dodatečné kvóty jsou dostupné za poplatek. Google nabízí i množství dodatečných služeb, které usnadní vývoj vlastních aplikací. Jsou to například Geocoding API, Street View, Direction services a další. Obrázek 1: Ukázka Google Maps V3

17 2 TECHNOLOGIE A STANDARDY OpenLayers API OpenLayers API je projektem Open Source Geospatial Foundation a je často používán ve spojení s mapami a daty služby OpenStreetMaps. Jedná se o JavaScriptovou knihovnu umožňující zobrazovaní mapových dat ve většině moderních webových prohlížečů a to bez závislosti na serverové straně aplikace. Díky implementaci standardních JavaScriptových API umožňují OpenLayers tvorbu bohatých webových geografických aplikací. Principiálně se jedná o obdobu Google Maps API, avšak s tím rozdílem, že tento projekt je svobodným softwarem dostupným pod 2-clause BSD licencí (také známou jako FreeBSD licence). Jedná se o projekt vyvíjený komunitou pro komunitu. (OPEN LAYERS, 2012) Aktuálně dostupná stabilní verze(2.12) nepodporuje WebGl. Ve vývoji je verze 3.0, která by však měla přinést plnou podporu i pro WebGl. OpenLayers API nabízí v základu oproti LeafLetu rozsáhlejší množství funkcí, ale díky svému dřívějšímu vzniku nenabízí tolik možností využití v mobilních zařízeních. Obrázek 2: Ukázka Open Layers LeafLet API LafLet je další čistě JavaScriptovou knihovnou pro zobrazování prostorových dat. API je opět dostupné pod BSD licencí. Na rozdíl od OpenLayers neklade důraz na množství funkcí, ale na jejich celkovou odladěnost. Samotná knihovna je tvořena jen 28KB zdrojového kódu, LeafLet však nabízí podporu pro množství rozšiřujících pluginů třetích stran. Pro většinu uživatelů je však plně dostačující i základní API. (LEAFLET, 2013) Jedním z nejvýznamnějších uživatelů LeafLet API je například oblíbená geolokační služba Foursquare Srovnání vlastností V tabulce číslo 3 je znázorněno srovnání základních parametrů jednotlivých API.

18 2 TECHNOLOGIE A STANDARDY 18 Obrázek 3: Ukázka LeafLet GoogleMaps OpenLayers LeafLet Verze Vydáno WMS Ano Ano Ano WFS Ano Ano Ano License Nekomerční užití / Bussines BSD BSD Omezení načtení / den Ne Ne Navigace klávesnicí Ano Ano Ano Dotykové ovládání Ano Ano Ano 2.4 Mapito projekt Tabulka 3: Funkce jednotlivých API Dalším z nástrojů, který bych chtěl ve své práci využít, je Open Source projekt Mapito. Předchozí nástroje pro práci s geodaty nemohou pracovat samostatně, jedná se o API pro vývoj vlastní mapové aplikace. Oproti tomu Mapito je již kompletní nástroj v PHP, pomocí kterého je možné vytvořit vlastní mapový portál s WMS vrstvami. Uživatelská data jsou ukládána v MySQL databázi, pro správu vektorových dat je využíváno Geoserveru 2. Stažení Mapita je možné přímo z adresy Po nasazení aplikace je potřeba provést konfiguraci MySQL, PostGIS a Geoserveru a poté je již možné vytvářet vlastní plány. Tento nástroj je dostupný pod MIT licencí. Projekt nabízí vlastní backendové API, pomocí kterého je možné spravovat data i vzdáleně skrze http požadavky. Konkrétně bych chtěl využít funkčnosti tohoto backendového API a uživatelské rozhraní vytvořil vlastní. Součástí mapita je i editor vektorových vrstev. 2 Geoserver je Open Source nástroj napsaný v jazyce Java, který umožňuje uživatelům sdílet a editovat například WFS.

19 3 NÁVRH APLIKACE 19 3 Návrh aplikace 3.1 Analýza uživatele Před tím, než bude možné provést jakýkoliv návrh, je nutné podrobně poznat cílového uživatele. Každý uživatel je unikátní. Co je pro jednoho snadným úkolem, pro druhého může být obtížnou překážkou. Je tedy potřeba zjistit, co je uživatelovým cílem při užití software, a je nutné definovat konkrétní úkoly, které podnikají ve snaze o dosažení těchto cílů. Dále musíme zjistit, jaké jsou dovednosti při používání obdobných aplikací, jaký je postoj uživatele k obdobným aplikacím a jak rozdílný design může ovlivnit tyto postoje. Poslední věcí, co je nutné pro začátek pochopit, je způsob vyjadřování (jazyk a slova), jakým uživatel popisuje výše uvedené činnosti. I když takovéto poznávání uživatele bývá časově i finančně náročné, eliminují se tím neurčitosti a návrh je poté snadnější. Erik Klimczak ve své knize popisuje následující techniky pozorování uživatelů: Pozorování: Přímé pozorování uživatelů je pravděpodobně nejjednodušší, nejrychlejší a nejlevnější způsob, jak získat skutečnou zpětnou vazbu s informacemi o požadované skupině uživatelů. Těm designerům, kteří nemají dostatek času nebo finančních prostředků, může pomoci v návrhu metoda sestávající z následujících kroků: 1. Zjistit, kdo je našim cílovým uživatelem. 2. Navštívit uživatele na místě jejich pracoviště a požádat je o svolení pozorovat je při práci. 3. Připravit si zařízení pro záznam obrazu. Obrazový záznam má mnohem větší vypovídací hodnotu než pouhé poznámky na papíře. 4. Přivést si spolupracovníka. 5. Sledovat uživatele při běžné činnosti. 6. Pozorovat zaváhání a selhání. Tato pozorování mohou být velmi cenným nástrojem pro odstranění chyb v uživatelské přívětivosti vlastního produktu, případně mohou dopomoci v diferenciaci plánovaného vlastního produktu. 7. Všímat si, jak uživatelé komunikují s okolím (vědomě i nevědomě). 8. Analyzovat nahrávky a pokusit se z chování vyčíst určité vzory. Vzory chování uživatelů jsou popsány na dalších stranách. 9. Seskupit návrhové vzory a převést je na poznatky. Dotazování uživatelů: Kdykoliv vyvíjíte novou mobilní aplikaci nebo webovou stránku, musíte zjistit co uživatelé chtějí. Nejlepším způsobem jak to zjistit

20 3 NÁVRH APLIKACE 20 je přímo se jich dotázat. Nicméně porozumět tomu, co lidé chtějí, může být velmi obtížné. Kognitivní psychologie nám říká, že podstatou lidí je neschopnost: Vyjádřit, co nás činí šťastnými. Odhadnout, co se nám bude nebo nebude líbit. Poskytnout zpětnou vazbu o věcech, na kterých nám nezáleží. V některých případech je vhodnější a jednodušší outsourcovat fázi výzkumu a dotazování profesionálům. Ovšem opět ne vždy to umožňuje finanční nebo časový rozpočet. Proto je velmi důležité správně stanovit otázky, na které se budeme při dotazování ptát. Správnému stanovení dotazů pomohou následující pravidla: Vyvarovat se uzavřených otázek: Uzavřené otázky nás obvykle při výzkumu přivádí do slepé uličky. Obecně platí, že bychom se měli vyhnout takovým otázkám, na které je možné odpovědět jednoduchým ano nebo ne. Tyto otázky mohou posloužit k jednoduchému testu znalostí jednotlivce avšak nejsou moc dobré ke generování promyšlených odpovědí. Vyvarovat se zavádějících otázek: Takovéto otázky jsou vlastně další formou uzavřených otázek, směřují k určité odpovědi a uzavírají možnost alternativní odpovědi. Typicky se jedná o otázky končící tázacími dovětky: Nemyslíte? Správně? Je to tak? Využívat otevřené otázky: Otevřené otázky podporují promyšlené odpovědi a obvykle motivují účastníky ke sdílení jedinečných aspektů jejich aktivit. Persony: Tato metoda neslouží přímo k získávání dat, ale přichází na řadu až ve chvíli, kdy jsou již tato data sesbíraná. Po identifikaci vzorů chování se provede roztřídění uživatelů do skupin, charakteristických určitými shodnými rysy, a pro každou skupinu se provede tvorba klíčových person. Personu můžeme chápat jako imaginární osobu, která bude mít reprezentativní vlastnosti stanovené skupiny. Nad personou se pak dále provádí průzkum a zjišťuje se, jak by se osoba v daných situacích zachovala. Často dochází k neshodám mezi tím co chtějí uživatelé a co stakeholdeři(zúčastněné strany). V takovémto případě je vhodné vytvořit i personu reprezentující tyto stakeholdery. Scénáře a příběhy užití: Jedná se o další metodu pro zpracování dat. Na základě získaných dat se sestaví jednotlivé scénáře, popisující chování uživatele při dosahování svého cíle. Principiálně tyto scénáře mohou připomínat Use Case. Podobají se v to, že obě tyto techniky popisují, jak bude uživatel komunikovat s konkrétní dílčí částí produktu. Největším rozdíl tkví v tom, že tato metoda oproti Use Case nezachází tak do hloubky. Uživatelské scénáře je nejlepší využít k popisu hlavních styčných bodů mezi uživatelem a produktem. Pro usnadnění tvorby scénářů je možné využít metody P.I.E.C.E.

21 3 NÁVRH APLIKACE 21 Persona: Na koho se zaměříme? Intrique: Co naláká uživatele k produktu? Enage: Jak pomoci uživateli k dosažení jejich cílů? Close: Jak uživatel může ukončit scénář? Extend: Jak může uživatel rozšířit zkušenosti mimo obrazovku? (KLIMCZAK, 2013) Vzory chování uživatelů J. Tidwell ve své knize popisuje skupinu návrhových vzorů, které popisují chování uživatelů. Jedná se o vědci a výzkumníky dlouhodobě ověřené postupy. Uživatelská rozhraní, zohledňující tyto vzory, umožní uživatelům dosažení jejich cílů mnohem rychleji a efektivněji než rozhraní, která tyto vzory nezohledňují. Na rozdíl od jiných skupin návrhových vzorů se však nejedná o vzory popisující konkrétní elementy uživatelského rozhraní, ale jak bylo psáno výše popisuje způsoby chování uživatelů, z čehož můžeme při následné implementaci vycházet. Safe Exploration: Uživatel chce zkoušet funkce aplikací, aniž by se dostal do situace, kdy není návratu zpět. Dobrý software by měl lidem umožnit zkoušet neznámé a umožnit návrat do některého z předchozích stavů. Instant Gratification: Lidé rádi vidí výsledky práce ihned. Pokud někdo začne používat aplikaci a uvidí určitý výstup v řádu několika vteřin, cítí určité uspokojení a motivuje jej to k další práci s aplikací i když pozdější pokroky už nemusí být tak jednoduché. Je tedy vhodné odhadnout, co bude uživatel chtít udělat jako první krok a s tímto krokem se mu snažit vypomoci. Satisficing: Když si lidé prohlíží nové rozhraní, nezkoumají každou jedinečnou jeho část, nehledají ten nejlepší způsob, jak určitou operaci provést. Obvykle vyberou první funkci, která by podle jejich uvážení mohla vést k výsledku. Nepotřebují nalézt nejlepší funkci, stačí alespoň uspokojivá. Changes in Midstream: Pokud to není nutné, není vhodné uzavírat uživatele v určitých částech aplikace. Uživatel by měl mít možnost přestat s určitou činností a později se k ní zase vrátit. Deferred Choices: Tento vzor chování vychází z Instant Gratification. Nezahlcovat uživatele zbytečnými dotazy, jasně vyznačit povinné položky a k těm nepovinným umožnit návrat později. Zvolit dobré výchozí hodnoty. Incremental Construction: Pokud lidé vytváří nějaký výstup, většinou věci nedělají v přesném pořadí. Měla by zde být možnost provádět pozdější úpravy.

22 3 NÁVRH APLIKACE 22 Habituation: Pokud si uživatel zvykne na určité postupy, které platí v jiných aplikacích, tak následně předpokládá, že i v dalších aplikacích tyto zvyky bude moci aplikovat. Například různé klávesové zkratky a gesta. Microbreaks: Klíčovou vlastností tohoto vzoru je zpřístupnění aktivity rychle a jednoduše. Tento vzor je aplikován převážně pro mobilní zařízení. Příkladem může být prohlížení u na mobilním telefonu. Nevyžaduje složitou instalaci, spuštění aplikace je rychlé a uživatel není pokaždé obtěžován dotazem pro zadání přihlašovacích údajů. Spatial Memory: Když lidé pracují s objekty či dokumenty, často je poté hledají na základě toho, že si pamatují kde se přesně nachází, nikoliv podle jejich pojmenování. Je tedy vhodné umísťovat ovládací prvky na očekávaná místa. Prospective Memory: Prospektivní paměť je v psychologii dobře známým jevem. V designu rozhraní si však tento jev nenašel takový záběr. Lidé mají potřebu si vytvářet návěstí pro podporu dlouhodobé paměti. V podstatě prospektivní paměť využíváme vždy, když plánujeme nějakou budoucí činnost a nějakým způsobem si připravíme věci, které nám tuto činnost připomenou. Například pokud si chceme další den vzít knihu do práce, položíme ji na stolek vedle vchodových dveří. V aplikacích může výt podpora tohoto vzoru ve formě poznámek a připomenutí. Streamlined Repetition: U mnoha druhů aplikací jsou uživatelé nucení k provádění určitých operací opakovaně. Je tedy vhodné snažit se zredukovat nutnost odezvy uživatele na na co nejmenší počet kroků. Příkladem tohoto návrhového vzoru může být funkce najít a nahradit v textových editorech, kdy uživatel má možnost najít a nahradit shody v celém dokumentu, aniž by musel potvrzovat každý krok. Uživatele velmi irituje opakovat určité úkony časem začne ignorovat jejich podstatu. Keyboard Only: Někteří lidé neradi používají při práci myš, jiní zase neradi při ovládání přepínají z klávesnice na myš raději by měli ruce na klávesnici po celou dobu. Někteří uživatelé stále pracují s aplikacemi, které mají pouze textové rozhraní. Pro tyto skupiny uživatelů je tedy vhodné navrhovat aplikace tak, aby bylo možné celé rozhraní ovládat nejen pomocí myší, ale i pomocí klávesnice. Je tedy vhodné definovat klávesám různé funkce a nastavit klávesové zkratky. Formuláře, ovládací panely a standardní webové stránky je poměrně snadno možné řídit pomocí klávesnice. Oproti tomu grafické editory a jiné aplikace, kde je nutná přesnost, je ovládat pomocí klávesnice mnohem těžší, přesto ne nemožné. Other People s Advice: Lidé jsou společenští, a proto se zajímají i o názory ostatních lidí. Z toho je možné vytěžit například přidáním systému komentářů nebo diskuzí.

23 3 NÁVRH APLIKACE 23 Personal Recommendations: Tento vzor pracuje na stejných principech jako předchozí. Lidé se nechávají silně ovlivňovat názory svých známých. (Tidwell, 2010) 3.2 Návrh aplikace Přístupy k designu rozhraní User centered design: Návrh designu aplikace se přizpůsobuje uživateli, designér se tedy stává překladatelem uživatelových potřeb. Díky tomu se při návrhu můžeme dostat do slepé uličky, pohled uživatele není vždy jasně definovatelný. Activity centered design: Při návrhu je kladen důraz na definování aktivit, které musí být provedeny. Jednotlivé aktivity se skládají z úkolů. Genius design: Uživatel je z návrhu tohoto designu prakticky vypuštěn. Klíčový je zkušený návrhář. Tento přístup se využívá například pokud není možné testování kvůli obchodnímu tajemství. System centered design: Důraz je kladen na komponenty systému, pomáhá navrhnout zejména funkcionalitu, nikoliv vzhled.(procházka, 2011) Návrhové vzory pro strukturu aplikace Některé z následujících návrhových vzorů definují strukturu pro rozsáhlé části aplikací, kdežto některé, jako je Canvas Plus Palette a Feature, Search and Browse, jsou součástí jiných návrhových vzorů, které se vzájemně doplňují. Tidwell ve své knize opět popisuje řadu návrhových vzorů, zde však provedu popis jen těch nejvýznamnějších. Feature, Search and Browse: Tyto tři elementy se nachází na mnoha úspěšných stránkách. Hledání a prohlížení jsou dva způsoby, kterými mlžeme nalézt požadované položky. Někteří uživatelé budou vědět co hledají a soustředí se na vyhledávací pole, zatímco jiní budou procházet jednotlivými kategoriemi a seznamy, které jim budou předloženy. Doporučené (Featured) položky jsou nástrojem, jak upoutat uživatele. Jsou podstatně zajímavější, hlavně pokud použijete poutavé obrázky. Uživatel má možnost vstřebávat obsah, aniž by musel cokoliv udělat. Canvas Plus Palette: Tento návrhový vzor je charakterizovatelný dvojicí prvků prázdným plátnem (canvasem) a nástrojovým panelem vedle něj. Nástrojový panel je paleta pro tvorbu objektů, které se potom umísťují na canvas. Tato kombinace je tak běžná, že téměř každý uživatel desktopového software se s ní již setkal. Je to přirozené mapování fyzických objektů do virtuálního světa.

24 3 NÁVRH APLIKACE 24 Wizard: Pokud je navrhováno rozhraní pro provádění úkolů, které jsou komplikované nebo zdlouhavé, je vhodné využít průvodce a uživatele postupně těmito kroky provést. Příkladem může být průvodce instalací software. Settings Editor: Pokud je potřeba v aplikaci spravovat rozsáhlé množství nastavení nebo vlastností, je vhodné vytvořit zvláštní, jednoduše nalezitelnou stránku, na které budou tato nastavení srozumitelně strukturovaná do jednotlivých záložek nebo podstránek. Two Panel Selector: Tento návrhový vzor je definován dvěma panely vedle sebe. V prvním panelu je zobrazen seznam věcí, které může uživatel vybrat, ve druhém panelu jsou zobrazovány podrobnosti vybrané položky z prvního seznamu. One Window Drilldown: Zobrazuje seznam položek na jedné stránce, po vybrání jedné z položek je seznam nahrazen detailnějšími informacemi, týkajícími se vybrané položky. Tento návrhový vzor nachází uplatnění zejména tam, kde není dostatek místa pro použití Two Panel Selectoru, například v mobilních zařízeních. Alternative Views: Umožněte uživatelům vybrat si z několika alternativních způsobů zobrazení obsahu aplikace. Příkladem tohoto vzoru je třeba možnost změny způsobu zobrazení výpisu obsahu adresářů v grafickém rozhraní operačních systémů (miniatury, ikony, seznam s podrobnostmi apod.) Many Worskpaces: Lidé často dělají více věcí na jednou. Využívejte záložek, karet a oken tak, aby uživatelé mohli zobrazit více než jednu stránku, projekt, soubor či jakýkoliv obsah aplikace současně. Pokud je to možné, dovolte uživateli uspořádat si pracovní prostředí jedno vedle druhého. Příkladem tohoto vzoru jsou třeba karty u naprosté většiny webových prohlížečů. Multi-level help: Nejen pokud navrhujete komplexní aplikaci, někteří uživatelé budou vyžadovat plnohodnotný systém nápovědy, většina uživatelů však nebude mít čas ani chuť tento systém využívat. Nápověda by měla být logicky strukturovaná, měla by umožňovat vyhledávání. Dále je vhodné implementovat nápovědu i na další úrovně. Je vhodné nastavit dynamické textové nápovědy nad tlačítky, ikonkami a dalšími elementy GUI(tooltips). Další pomocí pro uživatele je implementace návrhových vzorů Input Hints a Input Promt, které budou popsány dále. (Tidwell, 2010) Přechody mezi stavy aplikace Existuje několik modelů, které popisují navigační struktury aplikací. Jinak řečeno, popisují jak jsou jednotlivé obrazovky(stránky) navázané jedna na druhou a jak se uživatel mezi nimi může pohybovat. Hub and spoke: Tento způsob navigace je nejčastěji k nalezení u mobilních zařízení. Tato architektura zobrazuje nejdůležitější součásti stránky nebo apli-

25 3 NÁVRH APLIKACE 25 kace na domovské obrazovce. Jednotlivé podobrazovky jsou zaměřeny na určitý okruh činností, většinou zde není místo pro zobrazení jiných obrazovek. Příkladem tohoto modelu je domovská obrazovka systému ios. Obrázek 4: Hub and spoke Fully connected: Mnoho webových stránek implementuje tento model. Nachází se na nich jedna hlavní domovská obrazovka, avšak všechny další obrazovky jsou provázány odkazy například globální navigace pomocí menu v horní části obrazovky. Obrázek 5: Fully connected Multi-level: Tento model je opět běžný v prostředí webových stránek. Hlavní stránky jsou plně propojeny mezi sebou (šedá a černá barva na obr. 6), podstránky jsou propojeny v rámci svých podskupin. Obrázek 6: Multi-level

26 3 NÁVRH APLIKACE 26 Stepwise: Prezentace, procesní toky a průvodci vedou uživatele krok za krokem po jednotlivých obrazovkách v předepsaných sekvencích. Odkazy na předchozí nebo další obrazovky jsou na jednotlivých stránkách nezbytností. Obrázek 7: Stepwise Pyramid: Varianta modelu stepwise. Centrem pyramidy je hlavní stránka s výpisem s odkazy na všechny dostupné podstránky. Obrázek 8: Pyramid Pand and zoom: Některé prvky aplikací je vhodnější zobrazit samostatně, přes velkou část obrazovky. Do této kategorie spadají například mapy, velké obrázky, textové dokumenty a videa. Posouvání a zoomování jsou druhem navigace, proto je vhodné nabídnout ovládací prvky pro přesun (pohyb vertikálně nebo horizontálně), přibližování a oddalování a pro resetování do výchozí polohy. Flat navigation: Existují určité druhy aplikací, které potřebují minimální, nebo dokonce žádnou navigaci. Například u aplikace Adobe Photoshop (Canvas Plus Pallete) je většina funkcí a nástrojů dostupná přes menu, nástrojové panely a palety. Další nástroje mohou být dostupné přes modální panely nebo přes průvodce. Modal Panel: Modální panely jsou zobrazovány jako nejvyšší vrstva, přes všechen obsah obrazovky nebo stránky. Obvykle slouží k vyřízení malých úkolů, které si však vyžadují plnou pozornost ze strany uživatele (obrázek 9). Obrázek 9: Modal panel

27 3 NÁVRH APLIKACE 27 Clear entry points: Aplikace by měla obsahovat jen pár jasně popsaných a úkolově odlišených vstupních bodů (obrázek 10). Obrázek 10: Clear entry points Bookmarks: Záložky jsou způsobem, jak uživatele pohodlně navigovat na určitý bod zájmu, aniž by musel procházet celou strukturou aplikace (obrázek 11). Obrázek 11: Bookmarks Escape hatch: Pokud se uživatel v aplikaci beznadějně zamotá, dostane se do chybového stavu nebo se prokliká hluboko do stránky, kde již nerozumí kontextu, potřebuje únikový východ z této situace. Potřebuje se dostat do známé části aplikace. Je tedy vhodné umístit na stránky nějaké záchranné tlačítko, které uživatele přesměruje zpět na výchozí nebo domovskou obrazovku (obrázek 12 ). (Tidwell, 2010) Obrázek 12: Escape hatch Pozice v aplikaci Pro identifikaci pozice v aplikaci existuje opět několik návrhových vzorů.

28 3 NÁVRH APLIKACE 28 Sequence Map: Při návrhu aplikací, kde je potřeba uživatele provést stránku po stránce, je vhodné na každé straně umístit mapu popisující všechny strany v sekvenci, včetně informace o aktuální pozici v sekvenci. Breadcrumbs: Pokud aplikace obsahuje víceúrovňovou navigační hierarchii, hodí se umístit v horní části obrazovky seznam všech rodičovských stran této hierarchie. Tento seznam je obvykle ve formě odkazů nebo tlačítek. Annotated Scrollbar: Tento návrhový vzor je aplikovatelný například při návrhu aplikací pracujících s texty. Při scrollování stránky uživatel jen těžko stíhá prohlížet celý obsah stránky. Je tedy vhodné u scrollbaru zobrazovat dynamický text charakterizující obsah stránky, při vyhledávání barevně zvýraznit na kterých pozicích se nachází shody apod. Animated transition: V určitých situacích mohou náhlé změny stavů aplikace uživatele dezorientovat. Kdyby změny navigace mapy nebo přesun textu neprovázel animovaný přesun, uživatel neměl z prostředí dobrý dojem. Při změně umístění prvků je vhodné doplnit tyto procesy animací. Většinou když je nutné v aplikaci změnit umístění určitých prvků, je vhodné toto doprovázet nerušivou animací. Výzkumy prokázaly, že ideální délka animace je kolem 300 milisekund. Délka by pak neměla překročit 1 vteřinu. (Tidwell, 2010) Operace Nabízení operací návrhové vzory jak uživateli předložit nástroje. Button Groups: Tlačítka ovládající určitou skupinu funkcí seskupovat do oddílů. Action Panel: Kromě používání klasického menu je někdy vhodnější využít zvláštního nástrojového panelu, který je správně uspořádaný a vždy viditelný. Smart Menu Items: Přizpůsobit popisky v menu podle toho, co přesně funkce provede. Done Button: Umístit tlačítko ukončující operaci na konec visuálního toku. Musí být jasné, že se jedná o poslední krok. Provádění procesů Preview: Zobrazit uživateli, co se stane, až bude určitý proces dokončen. Vhodné zejména, pokud se uživatel chystá provést rozsáhlejší úlohy (např. tisk velkého dokumentu, odeslání objednávky v eshopu). Eliminuje se tím množství chyb. Z náhledu by mělo být umožněno vrátit se zpět k předchozím krokům.

29 3 NÁVRH APLIKACE 29 Progress Indicator + Cacelability: U úloh běžících déle než dvě vteřiny zobrazovat určitou formu notifikace s informacemi o tom se děje, jaká část úlohy je hotová, kolik zabere zbytek úlohy a jak probíhající úlohu zrušit. Časově náročné úlohy by mělo jít jednoduše zrušit. Cmd. Hist. + Multilevel Undo + Macros: Vytvářet evidenci operací, které uživatel provedl, umožnit navrácení do předchozích stavů (Safe Exploration a Incremental Construction). Implementace Macros možnost nahrání určité sekvence příkazů a tyto příkazy opakovat. Vkládání hodnot Forgiving format: Umožnit uživateli zadávat text v mnoha formátech, převod do potřebného formátu vlastnoručně vyřešit na straně aplikace. Structured format: V některých případech je nutný přesně daný, strukturovaný vstup. Je vhodné použít nápovědy, vstupním polím nastavit masku případně hodnoty vybírat ze selectorů. Filll-in-the-Blanks: Dotaz je formulován jako věta, do které uživatel doplňuje slova. Input Hints: V okolí vstupního pole umisťovat text vysvětlující obsah požadovaného vstupu. Input Prompt: Zobrazovaná nápověda ve vstupním poli. Zpravidla stručnější než Input Hints. Autocompletion: Během psaní vstupního řetězce se pokusit odhadnout, co bude uživatel psát a nabízet možné dokončení. Dropdown Chooser+Illustrated Choices: V případě že potřeba vybrat m z n elementů. Volby lze často nahradit obrázkem ilustrujícím volbu. List Builder: Zobrazení dvou sloupcového seznamu, kdy jsou položky z levého seznamu vybírány a přesouvány do pravého seznamu. Good Defaults: Kdykoliv je to možné, snažit se uživateli nabízet vhodné výchozí hodnoty. Same-Page Error Message: Chybová hlášení vypisovat přímo na stránce s formulářem. Popisek by měl být zobrazen přímo u chybné položky, jasně a lidsky by mělo popsáno, co je špatně. (PROCHÁZKA, 2010)

30 4 METODIKA PRÁCE 30 4 Metodika práce V prvotní fázi tvorby vlastní práce budou identifikovány nejpoužívanější funkce laických uživatelů GIS, v mém případě studentů předmětu PEF MENDELU Geografické informační systémy. Za pomocí trackovacího software bude proveden záznam jejich práce se softwarem během cvičení. Na základě tohoto záznamu budou určeny nejen nejpoužívanější funkce, ale i způsob jak k těmto funkcím bylo přistupováno. Z této analýzy bude v dané části práce vycházeno při návrhu grafického rozhraní vlastní webové aplikace. Na základě rešerší jsem pro tvorbu uživatelského rozhraní vybral rámec Google Web Toolkit s nástavbou SmartGWT. Z počátku jsem váhal nad užitím JSF a PrimeFaces, proto jsem si vytvořil pomocí obou rámců jednoduché aplikace, které měly na starost pouze zobrazit mapu s jedním bodem. Z hlediska pohodlnosti a rychlosti vývoje se mi použití Google Web Toolkit zdálo vhodnější. Dále pak díky kvalitní dokumentaci, znovupoužitelnosti, přehlednosti a rozsáhlé funkčnosti jednotlivých komponent GUI. Dalším z důvodů, proč užít tento rámec, byl projekt GWT-Open Layers. Jedná se Open Source projekt vytvářející doplňkovou knihovnu pro Google Web Toolkit, která umožňuje přímou integraci Open Layers funkčnosti do GWT. Celý vývoj klientského kódu tedy nyní může probíhat čistě v jazyce Java a celá klientská část aplikace je před nasazením zkompilována do html a JavaScriptu. Open Layers již v základu nabízí znatelně rozsáhlejší funkcionalitu, než je tomu u LeafLet. Posledním z důvodů, proč jsem dal přednost Open Layers před Google Maps API, jsou licenční a kapacitní omezení ze strany společnosti Google. V poslední části práce budu vycházet z předešlých poznatků, bude vytvořena specifikace, návrh a následně implementace vlastní webové aplikace. V implementaci bude využito vybraných knihoven a budou představeny klíčové funkce vlastní aplikace. U vybraných funkcí budou popsány principy, jak je možné tyto funkce implementovat.

31 5 VLASTNÍ PRÁCE 31 5 Vlastní práce 5.1 Analýza uživatele Jako první krok, ještě před začátkem návrhu vlastní aplikace, je nezbytností poznat detailněji uživatele. Na základě předcházejících kapitol je tedy vhodné stanovit následující : 1. Cíl užití software: Vlastní aplikace bude mapový portál, proto cílem užití SW bude tvorba, editace a sdílení mapových plánků. 2. Jaké úkony uživatel provede pro dosažení tohoto cíle: Bude se jednat o webovou aplikaci, proto uživatel nebude muset pro zprovoznění provádět žádné kroky ze své strany. 3. Zkušenosti uživatele, používaný jazyk a postoj k designu: Aplikace bude určena pro pokročilejší uživatele informačních technologií avšak pro uživatele GIS systémů začátečníky. Dá se předpokládat, že cílovou skupinou budou z velké části uživatelé OS Windows, a proto by měly principy aplikace částečně korespondovat s jejich zažitými zvyklostmi z tohoto systému. Tyto kroky je sice možné částečně odhadnout, avšak pro zpřesnění výstupu je vhodné vycházet z pozorování uživatelů. Pro tento účel jsme zvolili techniky přímého pozorování uživatelů Přímé pozorování uživatelů V rámci vlastní práce byl proveden záznam studentů na cvičeních předmětu PEF MENDELU Geografické informační systémy. Účelem záznamu bylo provést analýzu nejpoužívanějších funkcí, dále pak identifikace počtu kroků k nalezení dané funkce. K záznamu bylo využito nástroje společnosti ASM Software, konkrétně aplikace BlackBox Express. Tento software byl nainstalován na 19 klientských stanicích. Záznam probíhal na pozadí, při každé zaznamenané aktivitě studenta byl uložen snímek obrazovky. Celkově bylo takto pořízeno přes 200 tisíc snímků. Pro vlastní analýzu jsem využil data ze cvičení, kdy probíhalo vypracovávání zápočtových prací, a bylo tedy zřejmé, že se uživatelé nemohli řídit přesně podle pokynů vyučujících. Z celkové množiny 112 studentů jsem náhodně vybral 10 studentů a následně provedl rozbor jejich postupu při práci na daném cvičení. Postupně jsem identifikoval používané funkce a určil relativní četnosti počtu kroků, které musel uživatel pro nalezení dané funkce provést. Je zřejmé, že i tak byli studenti částečně ovlivněni předchozí výukou a v zaznamenaných postupech byly jisté shody. Data poslouží zejména pro stanovení klíčové množiny funkcí. V tabulce číslo 4 jsou zobrazeny nejpoužívanější funkce, relativní četnosti přístupů k těmto funkcím a čísla v hlavičce tabulky vyjadřují počet kroků, které museli uživatelé pro nalezení dané funkce absolvovat.

32 5 VLASTNÍ PRÁCE Vrstvy Přejmenovat Zobrazit/ skrýt Importovat Odstranit Export vybraných dat do nové Změna symbolu Zobrazení dle přiblížení Nový Shapefile Nastavení coord. sys Atributová tabulka Přidat pole(atribut) Upravit údaje Databázové dotazy Automatizované dopočítaní dat Režim editace Start Stop Výběr kreslícího nástroje Tabulka 4: Tabulka s relativní četností přístupu k funkcím 5.2 Návrh aplikace Nyní se nacházíme ve fázi, kdy máme definovaný účel aplikace, ale stále je zapotřebí stanovit klíčovou funkcionalitu a tedy jednotlivé komponenty aplikace. Na základě přímého pozorování uživatelů můžeme stanovit hlavní okruhy funkcí, které by měl vlastní mapový portál obsahovat. Těmito okruhy jsou: 1. Správa plánků: Vytvářet plánky. Modifikovat plánky. Sdílet plánky. 2. Správa vrstev, které budou obsaženy v plánku: Přidávat. Odstraňovat. Upravovat. Stylizovat. 3. Editace jednotlivých objektů vrstev:

33 5 VLASTNÍ PRÁCE 33 Přidávat. Odstraňovat. Upravovat. Spravovat atributy. Po stanovení klíčové sady funkcí, ještě před samotným návrhem designu aplikace, byl proveden návrh mapy průchodu aplikací. Tento návrh je vykreslen na obrázku číslo 13. Obrázek 13: Návrh mapy průchodu aplikací Při návrhu designu aplikace bylo vycházeno z rozdělení funkcí do skupin výše. Jednotlivé funkce tedy budou sjednocovány do skupin podle návrhového vzoru Button Groups. Každá skupina tlačítek má v hlavičce titulek, který stručně popisuje jejich funkčnost. První skupina tlačítek bude obsahovat funkce týkající se správy uživatelových plánků, druhá skupina zahrnuje funkce pro přidání nových překryvných vrstev. V pravé části aplikace se bude nacházet částečně průhledný správce vrstev, které se již v projektu nachází. Kompletní správu obsažených vrstev bude možné provádět přímo z tohoto panelu, ať už se jedná o změnu jména vrstvy, odstranění, stylizaci, nastavení priority nebo viditelnosti. Oproti tomu nástroje pro úpravu

34 5 VLASTNÍ PRÁCE 34 jednotlivých objektů vrstvy budou sjednoceny na odpovídajícím ovládacím panelu ve třetí skupině tlačítek. Přímé pozorování uživatelů nám ukázalo, že funkce pro přidávání a editaci vrstev budou nejvíce využívané, proto budou pomocí rozhraní dostupné hned na ovládacím panelu na prvním kroku. Jelikož se jedná o mapový portál, největší část obrazovky bude zabírat prostor pro zobrazení map a jednotlivých vrstev. Jednou z dalších podmínek při tvorbě návrhu bylo, aby uživatelské rozhraní bylo možné ovládat i z mobilních zařízení. Zaměřil jsem se tedy zároveň na optimalizaci velikosti prvků pro pohodlné ovládání na tabletech, majících úhlopříčku displeje 7 palců a více, jako jsou například Apple ipad mini nebo Google Nexus 7. Pro návrh designu bylo použito aplikace Balsamiq Mockups. Návrh na obrázku 14. Obrázek 14: Mockup designu Specifikace Před samotnou implementací už zbývá vyřešit poslední věc a to specifikaci nefunkčních požadavků. Funkční požadavky se podařilo stanovit již v předchozích krocích. Nefunkční požadavky tedy budou: 1. Aplikace bude psána v jazyce Java. 2. Pro GUI bude použit Google web toolkit.

35 5 VLASTNÍ PRÁCE Pro zobrazování mapových vrstev bude použito OpenLayers API s využitím projektu GWT-Open Layers. 4. Pro správu uživatelských dat a WMS bude využito API projektu Mapito. 5. Pro běh aplikakce bude použit aplikační server Apache Tomcat 7.0.x. 5.3 Implementace Výsledná aplikace Výsledná aplikace pro svůj běh vyžaduje PHP, PostGIS databázi, MySQL databázi a Apache Tomcat. PHP a MySQL jsou nezbytností pro práci Mapita. PostGIS a Tomcat je nutný pro běh vlastní aplikace. Mapito API dále využívá pro správu WFS vrstev geoserver. Bohužel v současné době tato funkcionalita nebyla dostupná, proto jsem vytvořil vlastní systém správy geodat na serveru a Mapito zde slouží pouze pro správu uživatelských dat, informací o WMS a jednotlivých pláncích (spolu s evidencí pravomocí). Tato data jsou uložena v MySQL databázi. K celkovému řízení těchto dat mělo být primárně využito API Mapita. Bohužel v současné době neumožňuje toto API vkládat data do databáze, a proto vkládání dat probíhá přímo z vlastní aplikace. Získání dat pomocí Mapita probíhá odesláním http požadavku s příslušnými parametry na url API. Odpověď ve většině případů dorazí ve formě JSON dat. Vlastní aplikace je tvořena více jak 70 třídami, které dohromady obsahují přibližně řádků zdrojového kódu. Přibližně 80 procent zdrojových kódů tvoří klientskou část aplikace, zbytek tvoří serverovou část aplikace Problémy během začátku vývoje Ihned na počátku vývoje bylo nutné vyřešit, aby aplikace při každé změně rozlišení klientského prohlížeče zareagovala překreslením velikostí komponent GUI podle nového rozlišení. Samotný Google Web Toolkit dokáže rozhraní překreslovat podle potřeb automaticky, ale bohužel při integraci Open Layers se widget s mapou při užití standardního postupu nepřekresloval. Tento problém byl vyřešen přidáním naslouchače události změny rozlišení okna klientského prohlížeče, kde je následně manuálně nastavováno rozlišení všech widgetů. Díky tomu je rozhraní aplikace vykresleno v nejvyšší možné míře a na tabletech dojde ihned i při změně rotace k překreslení GUI, aniž by bylo nutné znovu načítat aplikaci. Dalším z prvotních problémů byl nesoulad v kódování. I když zdrojové kódy i databáze měly nastaveno kódování UTF-8, při volání API Mapita byly navráceny řetězce v nesprávném kódování a některé české znaky se nezobrazovaly korektně. Tento problém vyřešilo manuální nastavení kódování InputStreamReaderu, který je ve vlastní aplikaci využíván spolu s BufferedReaderem při zpracování odpovědí po volání API Mapita.

36 5 VLASTNÍ PRÁCE 36 Obrázek 15: Automatické překreslení GUI při změně rotace (Apple ipad mini) Zprovoznění aplikace Aby bylo možné aplikaci spustit na vlastním serveru, je nejprve nutné nainstalovat a nakonfigurovat MySQL v projektu Mapito. Pro správný chod Mapita je nutností podpora pro php curl a povolené htaccess. Dále je potřeba provést konfiguraci vlastní aplikace nastavením parametrů v konfiguračním souboru config.properties. V tomto souboru je potřeba nastavit url k API Mapita. Toto API se nachází standardně ve složce mapito/api. Dále se v tomto souboru nastavují parametry MySQL a PostGIS databází. Po prvotním spuštění aplikace je většina funkcí pro nepřihlášeného uživatele skrytá. V podstatě je možné pouze využívat následující funkce: Zobrazit aktuální polohu. Používat nástroj pro měření vzdáleností. Vyhledávat lokace (viz. sekce Google Geocoding API). Registrovat nového uživatele. Přihlásit registrovaného uživatele. Měnit zobrazenou podkladovou vrstvu. Uživatel má na výběr ze sedmi podkladových vrstev, kdy jsou integrovány Google Maps V3 mapy i Open Street Maps vrstvy. Google Maps nabízí klasickou mapu, satelitní mapu, hybridní mapu a mapu terénu. Z Open Street Maps je obsažena opět klasická mapa, cyklo mapa (obsahující vrstevnice a informace o cyklostezkách) a prázdná vrstva.

37 5 37 VLASTNÍ PRÁCE Google Maps měly ve výchozím stavu povolenou nízkou maximální hodnotu zoomu a nebylo tedy možné dostatečně přiblížit mapu a následně vytvářet menší prvky vektorových vrstev (v řádech jednotek metrů). Po vytvoření instance Google Maps je však možné manuálně nastavit parametr maximální úrovně přiblížení a v aplikaci nyní lze nastavit zoom i na maximální možnou hodnotu. Nicméně manuální vynucení maximálního přiblížení u terénní mapy Google nebylo možné z důvodu nedostupných podkladů pro větší přiblížení. Proto terénní mapu není možné přiblížit na stejnou úroveň jako mapy ostatní. Teprve po přihlášení uživatele dojde ke zpřístupnění všech dodatečných funkcí vlastní aplikace. Na obrázku číslo 16 je zobrazen stav, kdy je uživatel přihlášen do systému a otevřel jeden ze svých plánků. (Gwtmaps, MainMapWidget, EditRibbonSection, HelpUserRibbonSection, MainRibbon, MenuItemBigger, ProjectRibbonSection, RibbonIconButton, RibbonIconMenuButton, ToolsRibbonSection, UserRibbonSection)3 Obrázek 16: Po otevření plánku Navigace v mapě Každý uživatel je má zažité jiné postupy v ovládání aplikací, proto jsem se snažil umožnit ovládání prostředí co nejvíce způsoby. Navigace v mapě je možná třemi způsoby: 1. Přímo pomocí myši nebo dotykového zařízení. Tažením prstu nebo kliknutím myši a tažením se provede přesun mapy. Zoom +/- pomocí rolovacího kolečka 3 Třídy v projektu týkající se prvků GUI.

38 5 VLASTNÍ PRÁCE 38 myši nebo použitím gesta pinch. Klávesa shift + tlačítko myši aktivuje režim, ve kterém je možné zaznačit obdélníkovou oblast, na níž se následně provede přiblížení pohledu. 2. Pomocí navigačního nástroje, který se nachází v levé části obrazovky. 3. Klávesnicí pomocí kurzorových kláves a kláves +, -, Page Up a Page Down. Pomocí tabulátoru lze přeskakovat po jednotlivých prvcích grafického rozhraní, mezerníkem dojde k aktivaci označeného prvku. Při vývoji vlastní aplikace je ve výchozím stavu funkční jen první z těchto způsobů navigace. Ostatní kontroléry je potřeba aktivovat manuálně. Jedná se však o jednoduché operace. Postup aktivace navigace dalšími způsoby je zobrazen v listingu číslo 2. Ve vlastním projektu je toto vyřešeno ve tříde MainMapWidget. 1 Projection DEFAULT_PROJECTION = new Projection( EPSG:4326 ); 2 MapOptions defaultmapoptions = new MapOptions(); 3 4 defaultmapoptions. setprojection(default_projection); //Nastaveni projekce mapy 5 6 MapWidget mapwidget = new MapWidget( 640px, 400px,mapOptions) 7 8 Map map = mapwidget.getmap(); 9 10 map.addcontrol(new PanZoomBar()); //Navigacni nastroj 11 map.addcontrol(new KeyboardDefaults()); //Ovladani klavesnici Listing 2: Java kód aktivace navigačních funkcí Správa uživatelů Pro správu uživatelů je využíváno funkcí Mapito API. Přihlášení uživatele probíhá tak, že po vyplnění uživatelského jména a hesla je z vlastní aplikace odeslán na Mapito API http požadavek o přihlášení, Mapito se pokusí najít uživatele s odpovídajícími údaji. V případě úspěchu je vygenerován, zaznamenán do databáze a navrácen hash, který slouží jako identifikátor uživatele při dalších operacích. Při každém přihlášení je generován hash nový a starý hash je zneplatněn. Díky tomu je zabráněno, aby uživatel byl přihlášen současně z více míst. Mapito o každém přihlášení vytváří log v databázi a je tedy možné zpětně dohledat a identifikovat aktivity jednotlivých uživatelů. (LoginWindow,RegisterWindow,UserRibbonSection) Správa plánků Ve vlastní aplikaci je možné vytvářet dva druhy plánků veřejný a soukromý. Soukromý plánek je dostupný jen a pouze pro jeho autora, kdežto veřejné plánky je možné prohlížet (nikoliv však editovat) všemi přihlášenými uživateli. Plánky je samozřejmě možné zveřejnit nebo skrýt i kdykoliv dodatečně. Každý plánek má evidován výchozí zoom a lokaci, která je zobrazena po jeho otevření. Dále plánek obsahuje textový popisek a vlastní název. (PlanCenterPicker, ProjectListGrid, Project- 4 Třídy v projektu, které se týkají správy uživatelů.

39 5 VLASTNÍ PRÁCE 39 ListGridData, ProjectListGridRecord, ProjectManagerDialog, ProjectRibbonSection, NewProjectWizzard) Správa vrstev Open Layers API obsahuje vlastního správce vrstev, avšak tento správce neumožňoval dodatečné úpravy v potřebné míře. Velikosti a rozložení prvků nebylo vyhovující pro práci na dotykových zařízeních. Proto byl jako součást aplikace vytvořen správce vlastní. Díky novému správci vrstev lze přímo pomocí tlačítek nebo kontextové nabídky upravovat: Styl: U každé vrstvy lze nastavit barvy a průhlednosti bodů, linií a polygonů. Obrázek 17: Manažer stylů Název vrstvy. Pořadí vrstev: Pomocí kontextové nabídky je možné měnit pořadí (překrytí) vrstev. WMS vrstvy jsou defaultně vkládány pod vektorové, avšak pořadí je možné dodatečně upravovat. Zazoomovat k objektům vrstvy: Uživatel se často může dostat mimo editovanou oblast, tato funkce vypočítá mezní rohy obsažených prvků vrstvy a provede se úprava pohledu tak, aby všechny prvky byly zobrazeny v aktuálním pohledu. Viditelnost vrstev: Skrývat nebo zobrazovat vrstvy. Odstraňovat vrstvy.(layermanager, LayerPropertiesManager, LayerListGrid, LayerListGriData, LayerListGridRecord, LayerBaseListGrid, LayerBaseList- GriData, LayerBaseListGridRecord) 6 5 Třídy v projektu, které se týkají správy plánků. 6 Třídy v projektu pro správu vlastností vrstev.

40 5 VLASTNÍ PRÁCE 40 Obrázek 18: Ukázka vlastního správce vrstev WMS vrstvy: uživatelé mohou do svých plánků přidávat libovolné WMS služby a to několika různými způsoby. Pro usnadnění jejich práce je generován katalog WMS, který obsahuje přehled serverů a vrstev použitých v projektech jiných uživatelů nebo v dalších vlastních projektech. WMS je možné vybrat a vložit do svého plánku přímo z katalogu. Před vložením je možné zobrazit náhled WMS vrstvy. Přidat WMS je možné také přímo manuálně a to v případě, že jsou známy všechny potřebné parametry formát, název vkládané vrstvy, podporované projekce služby a url služby. V předchozích kapitolách byly rozebírány vlastnosti a parametry WMS služeb, na základě tohoto rozboru zde bylo využito funkčnosti požadavku getcapabilites. Stačí tedy, aby uživatel zadal url WMS služby a aplikace se automaticky postará o načtení parametrů. Aplikace odešle na adresu zadané url getcapabilites požadavek (povinné parametry dotazu request=getcapabilites a service=wms) a následně je provedeno zpracování obdržených XML dat pomocí JAXP (Java API for XML Processing). Po zpracování celé odpověďi je na klientském prohlížeči zobrazen seznam všech službou poskytovaných vrstev, formátů a projekcí. Na obrázku číslo 19 ukázka nástroje pro manuální i automatické přidání nové WMS služby. (WMSLayerListGrid, WMSLayerListGridData, WMSLayerListGridRecord, WMSLayerConfigurator) 7 Vektorové vrstvy: Kromě klasické tvorby bodových, liniových a polygonových vrstev lze do svého plánku nahrát i kml soubor s vektorovými daty. Z kml souboru jsou načítány atributy i styly. 7 Třídy v projektu, které se týkají WMS.

41 5 VLASTNÍ PRÁCE 41 Obrázek 19: Nástroj pro přidání nové WMS Obrázek 20: Nástroj pro přidání vektorové vrstvy Editor objektů vrstev Pro úpravu vektorových vrstev byl vytvořen vlastní editor. Tvorba tohoto editoru byla na celé aplikaci tím nejsložitějším úkolem. Příčinou toho bylo hned několik. Open Layers nabízí pro každou operaci s objekty vrstev speciální kontroléry (např DragFeature pro přesun, DrawFeature pro kreslení, ModifyFeature pro úpravu a SelectFeature pro výběr objektů) a k nim příslušné naslouchače událostí. I když implementovat samotné kreslení na straně klienta nebylo tak složité, bylo nutné vhodně sladit i příslušné odezvy na straně serveru, aby aplikace maximálně využívala výhod AJAXu. Muselo se sladit, který kontrolér bude danou chvíli aktivován, který objekt je kontrolérem dotčen a sledovat, jestli po aktivaci controleru došlo nad daným objektem k nějakým změnám. Pokud by ke změnám nedošlo, aby se například zbytečně nevolaly metody serveru. Pokud by nebyla tato část bezchybně sladěna, mohly by se v databázích vyskytovat duplicitní záznamy, nebo by mohlo docházet

42 5 VLASTNÍ PRÁCE 42 k nežádoucímu odstranění některých záznamů. Pro snazší orientaci uživatele v aplikaci je i rozhraní nastaveno tak, aby se snažilo uživatele vést pomocí aktivace/deaktivace tlačítek a nastavování příslušných tooltipů. Na obrázku číslo 21 jsou zobrazeny 3 stavy, ve kterých se může panel s editačními tlačítky nacházet. První stav je v případě, kdy není vybrána žádná vrstva a není tedy důvod spouštět režim editace, do druhého stavu panel přejde, pokud uživatel vybere jednu z vlastních vrstev. Třetí stav nastane, pokud uživatel spustí režim editace. (AddFeatureRibbonSection, EditRibbonSection) 8 Obrázek 21: Režimy editačního panelu Pro editaci prvků vybrané vrstvy je nutné spustit režim editace. V tomto režimu je následně možné: Přidávání nových objektů vrstvy: Součástí nástroje pro přidávání nových prvků vektorových vrstev je dodatečný nástrojový panel (obrázek 22), který přináší funkce zpět, opakovat, zrušit a přichycovací režim. Funkce zpět a opakovat lze využívat pro zoopakování nebo pro zrušení předcházejících kroků provedených během kreslení. Operace se týkají jen aktuálně kresleného tvaru, na dříve přidané prvky nemají tato tlačítka vliv, proto při modifikaci nebo přesouvání prvků je tato nabídka skryta. Přichycovací režim kreslení spustí mód, kdy se kreslené prky snaží navazovat na dříve nakreslené, nejblíže nacházející se prvky totožné vrstvy. Poslední funkční tlačítko zrušit ukončí a zruší kreslení posledního přidávaného objektu vrstvy. 1 Vector vectorlayer= new Vector( ); 2 vectorlayer. setjsobject(map.getlayer( ID_VYBRANE_VRSTVY ).getjsobject ()); 3 4 DrawFeature drawlinefeaturecontrol = new DrawFeature(vectorLayer, new PolygonHandler()); //polygon 5 // drawlinefeaturecontrol = new DrawFeature(vectorLayer, new PointHandler()); //bod 6 // drawlinefeaturecontrol = new DrawFeature(vectorLayer, new PathHandler()); //linie 7 map.addcontrol(drawlinefeaturecontrol); 8 drawlinefeaturecontrol. activate (); Listing 3: Java kód zjednodušená ukázka přidání objektu vrstvy Obrázek 22: Dodatečná editační nabídka 8 Třídy v projektu, které se týkají editace.

43 5 VLASTNÍ PRÁCE 43 Změna tvaru objektu vrstvy: Na obrázku číslo 23 je zobrazen vzhled prvku během režimu úpravy tvaru. Během tohoto režimu jsou zobrazeny úchopné body, které je možné libovolně přesouvat a tak měnit výsledný vzhled prvku. V polovině vzdálenosti mezi jednotlivými body se vždy nachází průhledný bod. Tento bod není součástí prvku, avšak pokud uživatel tento bod přemístí, stane se z něj bod reálný a bude součástí tvaru. Takto lze postupně libovolně přidávat další body prvku. 1 2 Vector vectorlayer= new Vector( ); 3 vectorlayer. setjsobject(map.getlayer( ID_VYBRANE_VRSTVY ).getjsobject ()); 4 5 ModifyFeatureOptions modifyfeaturecontroloptions = new ModifyFeatureOptions(); 6 modifyfeaturecontroloptions.setmode(modifyfeature.reshape); 7 8 ModifyFeature modifyfeaturecontrol = new ModifyFeature(vectorLayer, modifyfeaturecontroloptions ); 9 map.addcontrol(modifyfeaturecontrol ); 10 modifyfeaturecontrol. activate (); Listing 4: Java kód změna tvaru Obrázek 23: Režim změny tvaru Přesouvání objetků: Listing 5 znázorňuje zjednodušenou ukázku přesunu objektu včetně jednoho ze způsobů, jak identifikovat zda-li došlo ke změně umístění objektu. Přesun objektů je dále možný (stejně jako u předchozího nástroje) pomocí ModifyFeature kontroléru, jen je třeba nastavit režim na ModifyFeature.Drag. Tímto postupem sice dosáhneme stejného výsledku, avšak uživateli je vykreslen pouze jeden úchopný bod, pomocí kterého lze objekt přesunout. U DragFeature kontroléru je možné přesouvat uchopením kdekoliv na objektu. 1 2 DragFeatureOptions dragfeatureoptions = new DragFeatureOptions(); 3 Pixel dragfeaturestartpixel ; 4 5 dragfeatureoptions. onstart(new DragFeatureListener() { public void ondragevent(vectorfeature vectorfeature, Pixel pixel ) { 10 dragfeaturestartpixel = pixel ; 11 } 12 }); dragfeatureoptions.oncomplete(new DragFeatureListener() {

44 5 VLASTNÍ PRÁCE public void ondragevent(vectorfeature vectorfeature, Pixel pixel ) { i f (dragfeaturestartpixel!=pixel){ 21 //Pokud plati, objekt se presunul 22 } } }); dragfeature = new DragFeature(vectorLayer, dragfeatureoptions ); 31 map.addcontrol(dragfeature ); 32 dragfeature. activate (); Listing 5: Java kód přesun objektu Odstraňování objektů: Listing 6 znázorňuje ukázku odstranění objektu vrstvy včetně dotazu o potvrzení odstranění ze strany uživatele. 1 2 SelectFeature deletefeaturecontrol = new SelectFeature(vectorLayer ); 3 map.addcontrol(deletefeaturecontrol ); 4 deletefeaturecontrol. activate (); 5 deletefeaturecontrol. addfeaturehighlightedlistener(new FeatureHighlightedListener() { 6 7 public void onfeaturehighlighted(final VectorFeature vectorfeature) { 8 9 SC. confirm( Opravdu chcete odstranit objekt?, new BooleanCallback() { public void execute(boolean value) { i f (value) { vectorfeature. destroy (); } } }); 24 } 25 } Listing 6: Java kód ukázka odstranění objektu vrstvy Úprava atributů objektu: Po vybrání některé z vrstev se automaticky spustí režim, kdy lze prohlížet atributy objektů. Do režimu úpravy atributů se uživatel dostane opět přes editační nabídku. 1 2 SelectFeature sf = new SelectFeature(vectorLayer ); 3 map.addcontrol( sf ); 4 sf. addfeaturehighlightedlistener(new FeatureHighlightedListener() { public void onfeaturehighlighted(vectorfeature vectorfeature) { Attributes atributy = new Attributes (); atributy = vectorfeature. getattributes (); //takto jsou ziskany vsechny atributy objektu 14 atributy. setattribute( Nazev, prirazena_hodnota ); //takto je pridan atribut k objektu 15 atributy. unsetattribute( Nazev ); //takto se odsrani atribut objektu } }); 20 sf. activate (); Listing 7: Java kód získání a přiřazení atributů objektu

45 5 VLASTNÍ PRÁCE Překlad názvů do geografických souřadnic pomocí Google Geocoding API Do vlastního portálu jsem dále implementoval vyhledávání lokalit pomocí Google Geocoding API. Tato funkce nyní umožňuje vyhledávat města, státy, přírodní útvary památky apod. a přímo zobrazit výsledky na mapě. Tento nástroj sám o sobě implementuje návrhový vzor Forgiving Format a uživatel tedy dostane výsledky vyhledávání i při zadání nepřesného názvu. Vlastní API se nachází na serverech společnosti Google a to opět přináší jistá omezení. Uživatel (zde uživatelem myšlena serverová část aplikace, nikoliv konkrétní uživatel) denně může v neplaceném režimu provést 2500 vyhledávacích požadavků. Bussines verze zvyšuje limit na požadavků denně. Celé to funguje tak, že klient odešle http požadavek, obsahující jako parametr název vyhledávané lokality, a API navrátí JSON nebo XML data obsahující výsledek vyhledávání. Ve vlastní aplikaci jsou odpovědi získávány a zpracovávány ve formátu JSON. V serverové části aplikace jsou z odpovědí vybrány informace o názvech nalezených lokalit, souřadnicích jiho-západního a severo-východního rohu (BoundingBox pro nastavení pohledu mapy a úrovně zoomu) a vlastní středová souřadnice nalezené lokality. Po zpracování všech položek JSON jsou odeslána data klientské části aplikace a uživateli je zobrazen finální seznam nalezených shod. Po vybrání některé z položek je provedena změna pohledu mapy podle obsažených parametrů vybrané lokality. Ukázka vyhledávací funkce na obrázku 24. Listning 8 zobrazuje ukázku volání Geocoding API a následné zpracování JSON odpovědi serverovou částí vlastní aplikace. Pro přehlednost kódu v ukázce není zobrazeno zachycení výjimek. (SearchCityWindow, ToolsRibbonSection, SearchCityListGrid, SearchCity- ListGridRecord, SearchCityListGridData ) public ArrayList<SearchCityTransferObject> searchcity(string string ) { 3 4 String nazevmestadourl = removediacritics( string ); //odstranit diakritiku 5 nazevmestadourl = nazevmestadourl. replaceall( \\s, %20 ); //nahradit mezery v pozadavku 6 ArrayList<SearchCityTransferObject> searchtransferob= new ArrayList<SearchCityTransferObject>(); 7 String serverresponse = null ; 8 Strings gocapi = googleapis.com/maps/api/geocode/json?address= ; //URL Geocoding API 9 URL url = new URL(gocAPI + nazevmestadourl + &sensor=true&language=cs ); //nastaveni cestiny v odpovedi 10 HttpURLConnection conn = (HttpURLConnection) url.openconnection(); //Vytvoreni spojeni 11 BufferedReader rd = new BufferedReader( new InputStreamReader(conn.getInputStream(), UTF 8 )); 12 StringBuilder sb = new StringBuilder (); 13 String line ; while (( line = rd. readline())!= null) { sb.append( line ); } serverresponse = sb. tostring (); 22 rd. close (); 23 conn. disconnect (); JSONObject json = new JSONObject(serverResponse ); //com. google.appengine. labs.repackaged. org. json.* 26 JSONArray citys = json.getjsonarray( results ); 27 for(int i = 0; i < citys. length (); i++){ SearchCityTransferObject scto = new SearchCityTransferObject (); //objekt zastupujici jedno nalezene misto 30 String adresa= ; 31 JSONObject c = citys.getjsonobject( i ); 32 JSONArray adresscomponents = c.getjsonarray( address_components ); for(int j = 0; j < adresscomponents. length (); j++){ 9 Třídy související s funkčností Geocoding API

46 5 46 VLASTNÍ PRÁCE } JSONObject adddinfo = adresscomponents.getjsonobject( j ) ; adresa+=adddinfo. getstring ( long_name )+, ; } String formatedadressstring = c. getstring ( formatted_address ) ; JSONObject geometry = c.getjsonobject( geometry ) ; JSONObject bounds = geometry.getjsonobject( viewport ) ; JSONObject northeast = bounds.getjsonobject( northeast ) ; scto. setnelat(northeast. getstring ( lat ) ) ; scto. setnelon(northeast. getstring ( lng ) ) ; JSONObject southwest = bounds.getjsonobject( southwest ) ; scto. setswlat(southwest. getstring ( lat ) ) ; scto.setswlon(southwest. getstring ( lng ) ) ; scto. settxt(adresa ) ; JSONObject location = geometry.getjsonobject( location ) ; scto. setcenterlan( location. getstring ( lat ) ) ; scto. setcenterlon( location. getstring ( lng ) ) ; searchtransferob.add( scto ) ; } return searchtransferob ; //pole vsech nalezenych objektu Listing 8: Java kód implementace využití Google Geocoding API Obrázek 24: Vyhledávač Odezva prováděných akcí Jak bylo psáno výše, vlastní aplikace komunikuje se serverovou částí asynchronně. Uživatel tedy není nucen čekat na dokončení jednotlivých akcí a může pokračovat v práci například i během aktualizace atributů objektů v databázi. Během prováděných operací je zobrazen animovaný statusbar, který navíc obsahuje textový popis aktuálně probíhající operace. Metody serveru jsou volány pomocí Remote Procedure Call. Schéma Google Web Toolkit RPC je znázorněno na obrázku číslo 25. Pro správnou funkčnost je nutné dodržet stanovenou strukturu rozhraní a tříd.