Univerzita Palackého v Olomouci Přírodovědecká fakulta Katedra geoinformatiky

Synchronizace dat mezi mobilními aplikacemi na platformě Android ­ na příkladu databáze

horolezeckých cest severní Moravy

Magisterská práce

Bc. Dalibor JANÁK

Vedoucí práce: doc. RNDr. Vilém PECHANEC, Ph.D.

Olomouc 2015

ANOTACE Práce se zabývá možnostmi vývoje mobilních GIS aplikací a synchronizací geografických dat

mezi centrálním úložištěm a mobilní aplikací na platformě Android. V rámci této práce byla vytvořena mobilní aplikace sloužící jako horolezecký průvodce.

Klíčová slova Synchornizace dat, Android, mobilní zařízení, GIS, horolezecký průvodce, databáze.

Počet stran práce: 52 Počet příloh: 1 (volná)

Anotation This thesis deals with the possibilities of development of mobile GIS applications and

synchronization of the geospatial databases on the Android platform. A climbing guide mobile application has been developed within this thesis.

Keywords Synchronization, Android, mobile device, GIS, climbing guide, database. Number of pages: 52 Number of appendixes: 1

Prohlašuji, že ­diplomovou práci včetně příloh, jsem vypracoval samostatně a uvedl jsem všechny použité podklady a literaturu. ­ jsem si vědom, že na moji diplomovou práci se plně vztahuje zákon č.121/2000 Sb. ­ autorský zákon, zejména § 35 – využití díla v rámci občanských a náboženských obřadů, v rámci školních představení a využití díla školního a § 60 – školní dílo, ­ beru na vědomí, že Univerzita Palackého v Olomouci (dále UP Olomouc) má právo nevýdělečně, ke své vnitřní potřebě, diplomovou práci užívat (§ 35 odst. 3), ­ souhlasím, aby jeden výtisk diplomové práce byl uložen v Knihovně UP k prezenčnímu nahlédnutí, ­ souhlasím, že údaje o mé diplomové práci budou zveřejněny ve Studijním informačním systému UP, ­ v případě zájmu UP Olomouc uzavřu licenční smlouvu s oprávněním užít výsledky a výstupy mé diplomové práce v rozsahu § 12 odst. 4 autorského zákona, ­ použít výsledky a výstupy mé diplomové práce nebo poskytnout licenci k jejímu využití mohu jen se souhlasem UP Olomouc, která je oprávněna v takovém případě ode mne požadovat přiměřený příspěvek na úhradu nákladů, které byly UP Olomouc na vytvoření díla vynaloženy (až do jejich skutečné výše). V Olomouci dne Dalibor Janák

Děkuji vedoucímu práce doc. RNDr. Vilému Pechancovi, Ph.D. za podněty a připomínky při vypracování práce.

Obsah Úvod …………………………………………………………………………………... 1 Cíle práce …………………………………………………………………………… 2 Použité metody a postup zpracování ………………………………………………...

2.1 Použité programy a technologie ……………………………………………... 2.2 Postup zpracování …………………………………………………………….

3 Současný stav řešené problematiky ………………………………………………… 3.1 Mobilní platforma Android ………………………………………………….. 3.2 Horolezecké aplikace………………………………………………………….

4 Možnosti vývoje GIS aplikací pro Android ……………………………………….... 4.1 Nativní aplikace ……………………………………………………………… 4.2 Android NDK ………………………………………………………………... 4.3 Sada nástrojů Android SDK …………………………………………………. 4.4 Vytváření GIS pomocí webových technologií ……………………………….. 4.5 Další vývojová prostředí ……………………………………………………... 4.6 Frameworky pro vývoj GIS aplikací ………………………………………….

5 Přenos a synchronizace dat mezi mobilními zařízeními …………………………….. 5.1 Konflikty při synchronizaci …………………………………………………... 5.2 Datové struktury pro přenos geodat ………………………………………….. 5.4 Algoritmy využitelné při synchronizaci dat ………………………………….. 5.5 Hotová řešení pro mobilní platformu ………………………………………....

6 Průvodce horolezeckých oblastí severní Moravy ………………………………….... 6.1 Přenos dat …………………………………………………………………….. 6.2 Serverová část ………………………………………………………………... 6.3 Android aplikace ……………………………………………………………... 6.4 Testování ……………………………………………………………………...

7 Výsledky …………………………………………………………………………….. 7.1 Výsledky teoretické části …………………………………………………….. 7.2 Výsledky praktické části ……………………………………………………...

8 Diskuze …………………………………………………………………………….... 9 Závěr ……………………………………………………………………………….... Literatura …………………………………………………………………………….... Summary …………………………………………………………………………….... Přílohy

7 8 9 9 9 10 10 11 13 14 15 15 17 17 18 23 23 25 30 32 36 36 37 39 44 45 45 45 47 48 49 52

Úvod Mobilní zařízení jakými jsou chytré telefony nebo tablety tvoří zcela běžnou součást

každodenního života. V dnešní době není problém nalézt mobilní aplikaci téměř na cokoliv. S pomocí chytrého telefonu lze dohledat nejbližší kavárnu či hotel, objednat pizzu a rezervovat jízdenku na nejbližší vlakový spoj. Dokonce ani sport a volnočasové aktivity nezůstávají tomuto fenoménu stranou. Obchody s mobilními aplikacemi jsou doslova plné nejrůznějších sport­trackerů, run­keeprů a podobných více či méně užitečných aplikací. Nyní se aplikace rozšiřují i do méně známých sportovních odvětví a horolezectví je jedním z nich. Průvodci pro horolezce se dosud vydávali pouze knižně a jejich datová základna se tak stávala neaktuální v momentě vydání knihy. Při využití mobilní aplikace lze datový obsah pravidelně aktualizovat a tomuto hlavnímu problému předejít. Navíc průvodce jako mobilní aplikace bude vždy po ruce a nemusí tížit lezcův batoh. V geoinformatice se nabízí mnoho možností jak využívat mobilní zařízení. Pomocí aplikací

pro prohlížení lze doručit kartografické produkty uživatelům pomocí populárních a snadno dostupných metod. Na profesionální úrovni pak můžou tato řešení představovat levně dostupné metody pro sběr a revizi datové základny přímo v terénu. Vzhledem k technologickému pokroku se určování polohy dostává na velice přijatelnou přesnost a také se díky využití datové sítě značně zkracuje počáteční fix. Toto řešení otevírá geoinformatice nové možnosti uplatnění v mnoha podoborech, kde se tyto vlastnosti zúročí přímo v praxi. Geoinformatika, která se nyní zabývá tímto tématem jen velice okrajově, by měla na dynamický trh s mobilními zařízeními reagovat a přizpůsobit se mu.

7

1 Cíle práce Cílem práce je provést rešerši a na jejím základě otestovat dostupné metody pro synchronizaci

dat v offline i online režimu mezi centrálním úložištěm a různými mobilními zařízeními na platformě Android. Dalším cílem práce je prozkoumat z geoinformatického hlediska možnosti vývoje mobilních aplikací na této platformě. V teoretické části bude podán přehled možností vývoje mobilních GIS aplikací na platformě

Android a aspektů s tím spojených. Budou řešeny typy vývoje, dostupné programové prostředí, geolokalizace, uložení dat, apod. Dále se teoretická část bude zabývat předáváním dat do mobilních zařízení a jejich vzájemnou synchronizací. Tato část by se hlavně měla zaměřit na přenosové formáty, používané algoritmy, problémy při synchronizaci a existující programová řešení, která se používají v souvislosti s vývojem mobilních aplikací. Dle těchto zkušeností pak bude vybráno nejlepší řešení pro případovou studii databáze

horolezeckých cest severní Moravy a tímto řešením bude naprogramována aplikace pro mobilní platformu Android. Aplikace bude zobrazovat prostorovou databázi online průvodce nad mapou a hlavní důraz bude kladen na možnost použití v offline režimu. Hlavním problémem bude efektivně vyřešit synchronizaci dat z centrální serverové databáze do mobilních zařízení. Aplikace by měla také umět určit geografickou polohu zařízení, zobrazit GPS status, nadmořskou výšku a navigovat k oblasti tak, aby ji mohl lezec v terénu smysluplně využít. Vlastní mobilní aplikace bude postavena na Javě & Android SDK. Zaznamenané/aktualizované údaje bude možno synchronizovat s centrální databází. Výměna bude probíhat v offline režimu pomocí XML souborů.

8

2 Použité metody a postup zpracování

2.1 Použité programy a technologie Aplikace navazuje na již běžící projekt, který je veřejný. Z těchto důvodů byla serverová část

limitována na možnosti standardního hostingu. Severová část byla napsána v jazyce PHP 5.6 a pro snadnější vývoj, s důrazem na bezpečnost, byl využit Nette Framework využívající MVP 1

model vývoje ve verzi 2.3. Nette je stabilní programové prostředí, které je vyvíjeno českými vývojáři a je jeden z nejpoužívanějších PHP frameworků v Česku. Nette má třídy pro zpracování a zasílání dat ve formátu JSON, dále užitečné nástroje pro přístup k databázi a kvalitní zabezpečení proti útokům. Pro práci byla jako základ modelu využita komponenta Nette Database. Serverová část má také přístup k relační databázi Průvodce, která je uložena v MySQL s InnoDB. Mobilní aplikace byla napsána pomocí webových technologií v prostředí Apache Cordova

verze 5.0.0 a byla kompilována na Linuxové distribuci Mint. Průvodce byl naprogramován v jazycích JavaScrip, HTML5 a CSS3. Jako uložiště na straně klienta byla použita databáze Sqlite3, zpřístupněna pomocí pluginu Cordova­sqlite­storage. Popis jednotlivých technologií je v dalších kapitolách.

2.2 Postup zpracování Prvním krokem byl průzkum trhu dostupných mobilních průvodců pro mobilní zařízení. Dále

byly zpracovány dostupná řešení a možnosti vývoje geoinformatických aplikací pro Android. Následně byla zkoumána a popsána řešení pro synchronizaci dat ze zařízení a problematika s tím spojená, tedy algoritmy, formáty pro přenos dat a hotová řešení, která by mohla být využita pro praktickou část. Dále byla vybrána technologie pro tvorbu aplikace a byl vytvořen první návrh celého řešení. V praktické části byla nejprve napsána první implementace serverového řešení, která

umožňuje přístup k databázi. Ta byla dále lazena a modifikována souběžně s vývojem mobilní aplikace. Mobilní aplikace byla naprogramována dle návrhů a vybraných metod na základě teoretické části. Aplikace byla dále testována v terénu a na základě zpětné vazby uživatelů následně modifikována. Nakonec byly vytvořeny webové stránky o diplomové práci.

1 MVC ­ Model­Vewer­Presenter ­ návrhový vzor pro vyvíjení webových aplikací

9

3 Současný stav řešené problematiky

3.1 Mobilní platforma Android Mobilní operační systém Android představuje platformu, která se dnes používá na nejvíce

mobilních zařízeních na světě . Android byl vyvíjen firmou Android Inc., která byla založena v 2

roce 2003 v Kalifornii. V roce 2005 firmu odkoupil Google a udělal z ní svou dceřinou společnost. Nyní systém vyvíjí uskupení zvané Open Handset Alliance, jenž bylo založeno společností Google v roce 2007 a Android přešel pod jeho správu. Open Handset Alliance nyní tvoří společensví 84 firem, které společně vyvíjí otevřené standardy pro mobilní zařízení a samotnou platformu Android [1]. Android je postaven na linuxovém jádře a je vyvíjen jako open­source software pod licencí

Apache Software License, Version 2.0 [2]. Podrobnější architektura systému je popsána v kapitole 4.1. Android nepředstavuje pouze operační systém, ale je dodáván i s celou škálou nástrojů. K dispozici je pro vývojáře několik vývojových prostředí, ve kterých se dají vytvářet aplikace (Android SDK, Android NDK popsáno v kapitole 4), dále sada ladících nástrojů zvaná Android Studio (dříve pouze plugin pro Eclipse) a také služby, které poskytuje Google online jako např. geolokace, routování atd. Pro koncové uživatele, je kromě základních aplikací pro chod zařízení dostupná také služba Google Play, která snadno spojuje svět vývojářů a koncových zákazníků. Play představuje online obchod s několika částmi. Google Play Store (dříve Android Market) obsahuje katalog dostupných aplikací. Vývojáři zde mohou aplikace snadno nahrávat a dávat k dispozici zdarma či za poplatek. Dále existuje Google Play Books jako obchod s knihami, Google Play Movies & TV pro nákup filmů a Google Play Music pro nákup hudby.

Obr. 1: Android robot ­ symbol operačního systému [3]

2 Podle statcounter.com z března 2015 má Android podíl 55,3% světových mobilních zařízení, následuje iOS s 30,8%, dále Series 40 4,2% následováno BlackBery, Samsung a Windows Phone.

10

Tab. 1: Vydané verze operačního systému Android

Verze Označení Vydána první verze

1.5 Cupcake 30.4.2009

1.6 Donut 15.9.2009

2.0 / 2.1 Eclair 26.10.2009

2.2 Froyo 20.5.2010

2.3 / 2.4 Gingerbread 6.12.2010

3.0 / 3.1 / 3.2 Honeycomb 22.2.2011

4.0 Ice Cream Sandwich 19.6.2012

4.1 / 4.2 / 4.3 Jelly Bean 9.7.2012

4.4 KitKat 3.9.2013

5.0 Lollipop 25.6.20014

5.1 Lollipop 9.2.2015

3.2 Horolezecké aplikace V obchodě Google Play je možné nainstalovat několik horolezeckých aplikací či průvodců.

Většina však není moc použitelná v praxi kvůli neúplnosti datové základny pro průvodce a špatné vizualizaci dat. Průvodci většinou nejsou postaveni nad mapou, proto slouží pouye jako prohlížečky databáze v online režimu. Pokud mapa v průvodci je, tak je postavena pouze nad základní Google Maps se zobrazením nejvýše bodové vrstvy skalních oblastí. 8a.nu Topos Jedná se o světový projekt vizualizující databázi jednoho z nejznámějších lezeckých webů

8a.nu. Aplikace nabízí procházení jednotlivých oblastí ve světě a možnost uložení lezeckých cest do telefonu. Databáze je však neúplná, chybí plánky skal a funkčnosti navigace. Aplikaci není možné kvůli koncepci a absenci mapy použít k orientaci v terénu. Klettern | enziano Enziano je čerstvě vydaná betaverze velice podařené aplikace s průvodci pro Rakousko a jih

Německa. Obsahuje několik regionů s možností nákupu podrobných průvodců přímo v mobilním zařízení. Aplikace má nad mapou zobrazené oblasti formou bodové vrstvy, umožňuje zobrazit polohu a procházet jednotlivé průvodce. Kromě grafického zpracování se jedná o velice použitelnou aplikaci.

11

Craggie Climbing Guide Topo Aplikace obsahuje seznam průvodců pro některé oblasti světa, z nichž se většina nedá

zobrazit. Obsahuje fotky stěn, u některých oblastí má průvodce a polohu na mapě. V aplikaci jsou pouze u některých stěn zoomovatelné plánky.

Obr. 2: Rozhraní průvodců Klettern enziano (vlevo), Craggie, Climbing on Kullaberg (vpravo)

Climbing on Kullaberg Climbing on Kullaberg je díky své dobré datové základně velice použitelným průvodcem.

Nabízí stažení dat do telefonu a nad mapou zobrazuje skalní oblasti s popisem. Každá oblast obsahuje zoomovatelné nákresy stěn a horolezecké cesty s popisy. Průvodce je vytvořen pouze pro oblasti na jihu Švédska. Climbing Away Francouzská aplikace zobrazující skalní oblasti především ve Francii. Obsahuje i pár oblastí v

České republice, bohužel ale nezvládá kódování českého jazyka. Jednou z nevýhod může být i přítomnost reklamy. Mapová část je uživatelsky nepřívětivá kvůli clusterování bodů nad google mapou a pomalému načítání dat.

12

4 Možnosti vývoje GIS aplikací pro Android V praxi existuje několik přístupů jak aplikace pro Android vyvíjet. Pro geoinformatiky s ne

příliš dobrým vztahem k programování je řešením využití exporterů z různých softwarů, které zvládnou pomocí jednoduchého průvodce vytvořit interaktivní prohlížečku dat. Zde je nutné jmenovat jednoho z největších komerčních hráčů v geoinformatice ­ firmu ESRI, která poskytuje několik programů. Tyto programy umí poloautomaticky vytvářet mobilní aplikace jak pro online, tak i offline režim. Jedná se o aplikace uzpůsobené hlavně ke sběru a prohlížení geografických dat v terénu. V současnosti portfólio firmy nabízí Collector for ArcGIS, Explorer for ArcGIS a Web AppBuilder for ArcGIS [4]. Snadný vývoj aplikací také nabízí řada WYSIWYG editorů volně dostupných na internetu,

které mají nástroje na jednoduchou kompozici GUI (Graphic user interface) a definování dalších funkcionalit pro pestřejší běh programu. Takovou možnost nabízí např. Mozilla Appmaker. Jedná se o online nástroj, pomocí kterého lze jednoduše vytvořit aplikace pro mobilní telefony bez znalosti programování. Služba je zdarma dostupná na webové stránce webmaker.org. Appmaker nabízí komponenty grafického rozhraní s různou funkčností, a tak lze vytvořit jednoduchou mobilní aplikaci velice snadno. Dalším, možná mnohem zajímavějším řešením je Polymer projekt. Polymer přichází s řadou

responzivních komponent pro mobilní aplikace. Rozšiřuje standardní html o vlastní značky, pomocí kterých lze aplikace snadno vytvořit. Tento mladý projekt pod taktovkou vývojářů z Googlu byl představen na konferenci Google I/O v roce 2014. Polymer je neustále vyvíjen. Nové verze vychází pravidelně každý měsíc a nabízí také online WYSIWYG editor. Například pro práci s google mapami používá polymer značku google­map. Samotné přidání google mapy do webu či aplikace je pak velice snadné [5]:

<link rel="import" href="google­map.html">

<google­map latitude="50.226365" longitude="17.205404"></google­map>

Tyto přístupy programování aplikací se však lépe hodí pro online režim zařízení. Pro

programování pokročilejších a svižnějších aplikací, přímo uzpůsobených pro offline režim, se používají přístupy a nástroje, popsané v následujících kapitolách.

13

4.1 Nativní aplikace Pro lepší pochopení systému Android je potřeba poznat architekturu systému, která se skládá

z pěti vrstev. Vrstvy jsou vyobrazeny v následujícím diagramu. Každá vrstva má svůj účel a řeší část logiky celého systému.

Obr. 3: Pět vrstev systému Android [6]

Abstraktní vrstva hardwaru (HAL) tvoří jádro operačního systému. Jedná se o nejnižší

vrstvu systému, a tvoří tak abstraktní vrstvu mezi používaným hardwarem a zbytkem softwaru. Jádro systému Android je postaveno na jádře systému Linux. V prvních verzích Androidu šlo o verzi Linuxu 2.6.x, která pak byla nahrazena novějšími verzemi. V Androidu je využito mnoho Linuxových vlastností, jako je správa sítí, podpora správy paměti, zabudované ovladače nebo správa procesů. Dalším příkladem je souběžný běh aplikací, které běží jako samostatné procesy s oprávněním stanoveným systémem [6].

14

Běhové prostředí C/C++ tvoří nativní knihovny psané v jazycích C a C++, které běží přímo na kernelu HAL a umožňují tak službám přímý přístup do aplikací v Androidu. Zde tvůrci vývojářům nabízí Android NDK popsaný v kapitole 4.2. Hlavní částí Android runtime je běhové prostředí pro jazyk Java. Android do verze 4.4 má v

sobě přímo zabudovaný virtuální stroj Dalvik Virtual Machine (DVM). Ten pak vytváří běhové prostředí, ve kterém jsou spouštěny aplikace nižších vrstev napsané v Javě. Od verze Android 5.0 Lollipop je Dalvik nahrazen procesorem Android Runtime zkráceně ART, který má lepší vlastnosti a zajišťuje tak mimo jiné i rychlejší překlad aplikací [7]. Tato vrstva přímo komunikuje s jádrem systému [6]. Aplikační framework je nejdůležitější vrstva pro vývojáře. Poskytuje sadu nástrojů k

funkcím zařízení a různým knihovnám zvanou Android SDK (Software Development Kit). SDK se verzuje nezávisle na verzích Androidu a vždy je zpětně kompatibilní. Nejvyšší vrstvu pak tvoří aplikace samotné (Aplikační vrstva), ke kterým přímo přistupuje

koncový uživatel zařízení. Android nabízí několik předinstalovaných aplikací jako např. aplikace pro správu mobilního telefonu. Další aplikace se dají doinstalovat pomocí Google Play (dříve Android Market), což je virtuální obchod s aplikacemi. Aplikace jsou vytvářeny v jazyku Java a zpracovává je Android Runtime. Android je přímo uzpůsoben na vytváření aplikací v Javě a většina aplikací je psána touto formou. Aplikace využívají vývojové prostředí Android SDK (popsáno v kapitole 4.3), které jim umožňuje snadno přistupovat k funkcím zařízení jako je kompas, GPS, obsluha volání atp.

4.2 Android NDK Android NDK (Native­code Developer Kit) umožňuje implementovat části aplikací přímo v

nativním kódu Androidu, tedy v jazycích C nebo C++. Tato možnost může být výhodou pro některé aplikace. Psaní v nižším jazyku než je Java umožňuje napsat aplikaci rychlejší a úspornější, protože tento přístup nepotřebuje další překladač, jako je např. ART pro Javu. Výhoda kódu jazyka C je jeho menší náročnost na paměť a rychlost interpretace, proto se většinou používá pro ty části aplikace, které hodně vytěžují CPU zařízení. Tento vývoj však spolu nese určitá rizika, proto je potřeba najít správný balanc v kombinaci s kódem v Javě. Tímto způsobem se většinou řeší různé knihovny pro SDK atp. [8]

4.3 Sada nástrojů Android SDK Android SDK zahrnuje nástroje, které usnadňují vývojářům vývoj aplikací pro Android.

Obsahují jak programové API pro přístup k hardwaru zařízení, tak i kompilační nástroje, které zabalí aplikaci do formátu .apk, který je pak přímo připraven k distribuci pro koncové uživatele. Připraveny jsou také virtuální stroje Androidových distribucí AVM (Android Virtual manager) a novinkou je i Android Studio. Jedná se o nedávno vydaný editor, vyvíjený Googlem, který je

15

přímo uzpůsoben k programování pro Android [9]. Popisovat rozsáhlé prostředí není cílem této práce, proto je zde uvedeno pouze několik nástrojů v souvislosti s tvorbou GIS aplikací.

4.3.1 Geolokace Určení polohy zařízení je jedna ze základních funkcí využitelných v GIS aplikaci. Android,

jako operační systém, má ve svém SDK třídy, které umožňují programátorovi snadněji získávat pozici přístroje, data ze senzorů a status těchto senzorů v zařízení. Balík má namespace android.location a je možné na něj navázat listenery (posluchače), které se vyvolávají při změně či získání polohy ze senzorů. Dále obsahuje třídy pro jednoduché geokódování, zobrazení GPS statusu, informace o družicích, třídu jako instanci polohy, také správce a poskytovatele polohy. Podrobnější popis metod všech tříd je popsán v dokumentaci [10]. V dokumentaci se však doporučuje využít API vyvinuté Googlem zvané Google Location

Services for Android, které nabízí mnohem více nástrojů pro určení a zpracování polohy přístroje. Tyto nástroje vyžadují v aplikaci zpřístupnění služeb Google Play a použít se dají pod com.google.android.gms.location. Soubor tříd nabízí přesnější určování polohy využitím serverů Googlu a bohatější práci s GPS statusem [11]. Příklad jednoduchého získání polohy (Java) Nejprve je potřeba z metody onCreate zavolat metodu, která nastartuje služby google play: protected synchronized void buildGoogleApiClient() mGoogleApiClient = new GoogleApiClient.Builder(this) .addConnectionCallbacks(this) .addOnConnectionFailedListener(this) .addApi(LocationServices.API) .build();

Poté můžeme získat samotné zjištění polohy pomocí: public class MainActivity extends ActionBarActivity implements

ConnectionCallbacks, OnConnectionFailedListener

...

@Override

public void onConnected(Bundle connectionHint)

mLastLocation = LocationServices.FusedLocationApi.getLastLocation(

mGoogleApiClient);

if (mLastLocation != null)

mLatitudeText.setText(String.valueOf(mLastLocation.getLatitude()));

mLongitudeText.setText(String.valueOf(mLastLocation.getLongitude()));

16

4.4 Vytváření GIS pomocí webových technologií Charakteristickým projektem pro tento přístup k vývoji je PhoneGap. Byl vyvinut firmou

Nitoby, kterou v roce 2011 koupila Adobe Systems. Projekt dnes z velké částí vyvíjí Apache Foundation pod názvem Apache Cordova pod open­source licencí. Cordova zpřístupňuje vývoj mobilních aplikací pomocí webových technologií, konkrétně JavaScriptu, CSS a HTML5. Dělá to tak, že webovou aplikaci rendruje pomocí WebView dostupné v SDK Androidu a přidává k němu JavaScriptové API, které umožňuje přístup k hardwaru zařízení. Cordova neobsahuje komponenty GUI, jedná se pouze o kompiler a programové prostředí [12]. Toto řešení se často nazývá jako hybridní vývoj mobilních aplikací. Jeho velkou výhodou je

však to, že je multiplatformní. Kompilovaná aplikace pomocí Cordovy je schopna běžet jak na iOS, Androidu, Windows Phone, tak i dalších platformách s plnou podporou hardwaru. Nevýhodou tohoto řešení je, že aplikace mohou být na některých zařízeních pomalejší. Pro další, méně používaná hybridní řešení, je možno využít Appcelerator Titanium nebo Telerik AppBuilder [13]. Hybridní řešení vývoje zažívá velký boom a v dnešní době existuje mnoho frontendových

frameworků, které velice zpříjemňují vývoj. Jedním z nich je i nově vydaný Ionic framework. Dlouho očekávaný pomocník nabízí i snadné buildovací nástroje pro platformu Node.js. Ionic ke svému líbivému designu kompiluje CSS z jazyku Sass (Syntactically Awesome Style Sheets). Sass je jazyk popisující styl, který se kompiluje do CSS. Syntaxe je podobná CSS, a tu rozšiřuje o cykly, proměnné, zanořování objektů, funkce atd., díky kterým se dá CSS psát dynamicky a lépe se udržovat. Klientskou interakci v Ionic využívá JavaScript a je přímo připraven na použití s JavaScriptovým frameworkem Angular.js [14]. Vytváření aplikací pomocí webových technologií staví na platformě Node.js (není však nutno

využít). Node.js, jeden z trendů současného vývoje, umožňuje spouštět JavaScript na serverové straně. Díky tomu je možné využít stejný jazyk v klientovi i na serveru. Interpert Node.js je navržen pro snadnou škálovatelnost a jednoduchost použití. Nabízí několik komponent a balíčkovací systém NPM (Node package manager), který obsahuje okolo 150 tis. balíčků pro použití v serverových aplikacích [15]. Apache Cordova je také vyvíjen jako balíček pro NPM.

4.5 Další vývojová prostředí V průběhu popularizace Androidu začaly vznikat i další projekty, které se snažily umožnit

psaní aplikací v jiném jazyce než je Java. Vznikali tak interpreti v jazyce C, běžící pod NDK a vytvářeli běhové prostředí pro jiný jazyk. Dobrým příkladem je multiplatformní framework Kiwi, který umožňuje na Androidu spouštět aplikace psané v Pythonu. Kiwi také nabízí základní SDK komponenty a přístup k funkcím zařízení [16]. Existují i implementace v jiných jazycích, jako například komerční Xamarin, který poskytuje možnost vývoje aplikací v jazyku C# nebo prostředí pro vývoj v Ruby atp.

17

V únoru 2015 bylo oznámeno vydání projektu React Native, který umožňuje psát nativní aplikace v JavaScriptu a frameworku React. Projekt vyvíjí firma Facebook. Nabízí sadu komponent jak pro uživatelské prostředí, tak i nástroje pro běh aplikace [17]. Je to velice mladá platforma, která je nyní plně použitelná pouze pro iOS. Facebook nicméně přislíbil podporu Androidu, která by měla být dostupná během následujícího půl roku [18].

4.6 Frameworky pro vývoj GIS aplikací Pro vývoj nativních aplikací v Javě existuje několik frameworků, které mají programové

nástroje pro editaci, úpravu a vizualizaci geografických dat. Lze na nich pak Geografický informační systém snadno postavit.

4.6.1 Google Maps Android API v2 Google již od začátku vývoje Androidu nabízí nástroje pro integraci Google Maps API. Jedná

se o zdarma dostupné API, které je však omezené užitím dat a počtem dotazů. Lze však zakoupit Work licenci pro náročnější aplikace, která zvedá limity a mění užití [19]. Google Maps nabízí v základu práci s vektorovými prvky a popupy pro body (Markers), linie (Polylines) a areály (Polygons). Také umožňují práci s georeferencovanou překryvnou bitmapou, kterou přidává jako GroundOverlay a standardní přidání dlaždicové vrstvy s uspořádáním dlaždic WMTS (TileOverlays) [20]. API v2 dává k dispozici i rozhraní pro přístup ke Street View (Data ve formě sférických 360°

snímků) pomocí třídy StreetViewPanorama. V online režimu se dá tato funkce využít v jakékoliv aplikaci v souladu s právní politikou Googlu. Podobně lze přepnout na 3D view Google Map a např. s pomocí GoogleMap.setBuildingsEnabled(true) lze jednoduše prostorově zobrazit budovy pro města, která již tyto datové podklady mají (v současné době se jedná o velká města v USA a Evropě). Silným nástrojem nad daty od Googlu je Geolokační API. Umožňuje kódovat a dekódovat geografická data, lze tak do aplikace vložit silný vyhledávací Nominatim pro vyhledávání adres či geonym, možno využít i routování na silniční síti od Googlu [20].

18

Příklad kódu jednoduché mapové aplikace s bodovou vrstvou (Java) import com.google.android.gms.maps.*;

import com.google.android.gms.maps.model.*;

import android.app.Activity;

import android.os.Bundle;

public class MapPane extends Activity implements OnMapReadyCallback

@Override

protected void onCreate(Bundle savedInstanceState)

super.onCreate(savedInstanceState);

setContentView(R.layout.map_activity);

MapFragment mapFragment = (MapFragment) getFragmentManager()

.findFragmentById(R.id.map);

mapFragment.getMapAsync(this);

@Override

public void onMapReady(GoogleMap map)

LatLng olomouc = new LatLng(50.226365, 17.205404);

map.setMyLocationEnabled(true);

map.moveCamera(CameraUpdateFactory.newLatLngZoom(olomouc, 12));

map.addMarker(new MarkerOptions()

.title("Olomouc")

.position(olomouc));

4.6.2 Osmdroid Osmdroid je sada nástrojů, která umožňuje vyvíjet GIS aplikace postavené nad

OpenStreetMap na Androidu. Prakticky Osmdroid nahrazuje třídu MapView z Google Maps. Také přidává modulární vrstvu pracující s dlaždicemi, která podporuje spoustu online a offline dlaždicových vrstev a má nástroje pro práci s vektorovými daty a práci s geolokací [21]. Příklady projektů postavených na Osmdroid: MySpeed, Open Avation Maps,

osmtracker­android, BikeRoute, Mapzen POI Collector, Open GPS Tracker, SmartTracker, Turbo GPS 2, AndRoad, CallerID, CellSearcher, EPFL Pocket Campus,iTravelFree,BikeNode, HikeNode, CycleStreets aj. [22].

19

Obr. 4: Screenshoty starteru Osmdroid (vlevo) a MapBox SDK (vpravo)

4.6.3 MapBox Android SDK Společnost MapBox, jako velký hráč na poli prostorových webových technologií, vyvíjí svoji

vlastní sadu nástrojů pro android s názvem Mapbox Android SDK. Sada vznikla jako fork Osmdroid, takže jádro je distribuováno pod open­source licencí (Apache 2.0), ale bylo přepsáno tak, že není závisle na Google Maps SDK nebo dalších jiných komponentách androidu, které vyžadovaly použití služeb Google Play [23]. MapBox SDK má výhodu v tom, že je přímo uzpůsobeno na zobrazování podkladových dat z

MapBox účtu. Nevýhodou je však závislost na komerční službě. OpenStreetMapu lze jednoduše libovolně nastylovat na webu a zvýraznit tak pouze prvky, které chcete a barevně je pak sladit s designem aplikace, ta je pak použita jako podkladová mapa v aplikaci. Toto SDK také umí rotovat s celou mapou, přidávat dlaždicové vrstvy, práci s vektorovou grafikou a má nástroje pro práci v offline režimu [24].

20

4.6.4 ArcGIS Runtime SDK for Android Další komerční subjekt ESRI si také nenechává ujít mobilní trh a nabízí i pro Android pod

komerční licencí své ArcGIS Runtime SDK. Z hlediska možností se jedná o SDK s nejvíce pokročilými prostorovými operacemi, avšak proti užití stojí vysoká cena. Toto SDK by mohlo vyhovět komerčním subjektům, které mají své řešení postaveno na platformě ESRI či mají svá data uložena v cloudových službách od ESRI. ESRI nabízí k SDK bohatou podporu a na stránkách lze najít spoustu tutoriálů. Po založení

projektu se musí aplikace zaregistrovat na stránkách ESRI, kde si zákazník zakoupí licenci. Licenční klíč se pak přímo vkládá do aplikace při vytváření inicializačního objektu SDK [25].

Tab. 2: Licencování přístupu k Android Runtime SDK

Licence Možnosti

Developer (pro testování) všechna funkčnost (obsahuje vodoznaky)

Basic geokódování, routování, editace, práce s lokální geodatabází, synchronizační operace

Standard všechny funkcionality

V SDK je zahrnuto [25]: ­ API pro práci s portálem ArcGIS Online ­ přidávání vrstev z ArcGIS Serveru ­ offline práce s podkladovými a datovými vrstvami, offline routování, offline

geokodování ­ pokročilou editaci dat offline s následnou online synchronizací a ukládání změn ­ local cache ­ základní geoprocesing

V poslední verzi SDK ESRI uvolnila i betaverzi nového modulu pro prostorové analýzy, které

se vypočítávají přímo na CPU mobilního zařízení. Před tím SDK podporovalo pouze analýzy firmou RESTu na ArcGIS Server [26].

21

4.6.5 Nutiteq SDK Nutiteq je estonská firma s komerční licencí stejnojmenného programového prostředí pro

mobilní zařízení. SDK je v základní verzi nabízeno zdarma, další dvě licence s pokročilejšími funkcemi jsou za poplatek. K dispozici je několik starterů, ve kterých jsou již vyřešeny některé kódové funkčnosti. Knihovna umožňuje práci s offline mapami, různé podkladové vrstvy, zobrazování jak rastrových (GeoTIFF, BSB, ECW, MrSID), tak vektorových dat (KML, Shapefile, MapInfo a další), editaci vektorů a velice svižné 3D zobrazení všech map [27].

Mapová aplikace postavená v prostředí Nutiteq

4.6.6 Mapsforge Zdarma dostupný open­source projekt (distribuován pod LGPL3 licencí), který umožňuje

ad­hoc renderování OpenStreetMap přímo v Android zařízení [28]. Tato poměrně malá knihovna (~ 400 Kb) poskytuje velice silný základ pro vystavění aplikace. Je na ni postaveno hodně sofwarových řešení třetích stran, jako například Nutiteq SDK, nebo aplikace Locus, ARDrone Flight, APRSdroid, Android­Speedometer, c:geo aj.

22

5 Přenos a synchronizace dat mezi mobilními zařízeními Synchronizace představuje proces konzistence a jednotnosti instancí dat ve více systémech.

Zajišťuje tedy stejné kopie nebo verze dat v různých zařízeních [29]. Tento proces se využívá k udržení stejné datové základny v jednotkách distribučního počítačového systému. Replikace je pak proces, který neustále hlídá databázové systémy, jestli v nich nedošlo ke změně a pokud ano, tak spouští přenos dat [30]. Každá databázová jednotka v distribučním počítačovém sytému (clusteru) se nazývá uzel

(ang. node) a ten má vždy jednu ze dvou rolí, nejčastěji nazývaných jako master a slave. Master je systém, do kterého se dají data zapisovat a dají se z něj i číst. Slave naopak slouží pouze ke čtení dat [30]. Migrace dat mezi těmito systémy může probíhat několika způsoby. Přenos dat z master na

slave je nejjednodušší způsob. Data se přenáší jednosměrně a to tak, že nové změny v databázi vznikají pouze v masteru a ty pak putují do slave datatabáze. V počítačovém clusteru, kde je jeden master a i více slave serverů nedochází ke kolizím dat. Druhým způsobem přenosu dat je master­master replikace jako případ clusteru, ve kterém jsou dvě master databáze. V obou těchto databázích lze zapisovat a data je tedy nutno přenášet obousměrně. Pokud je v distribuovaném systému více master zařízení než dvě, tak se jedná o tzv.multi­master replikci. Při multi­master replikaci se data mění ve všech databázích a změny se přenáší do ostatních zařízení. V tomto modelu počítačového clusteru pak dochází ke kolizím. Speciálním případem je snapshot replikace, kde se v jeden okamžik přenáší celý stav rodičovské databáze. Využívá se zejména při první inicializaci replikace. Pokud chceme data přenášet mezi mobilními zařízeními, je téměř nemožné kvůli

nepravidelnému datovému přenosu přenášet data z jednoho zařízení do druhého. Vzhledem k počtu aktivních mobilních zařízení, užívaných pro sběr dat, by to ani nebylo technicky možné. Proto se používá centrální databázový server, ke kterému se všechny zařízení připojují pomocí datové sítě a tím se multi­master replikace zjednoduší pouze na mnoho master­master či master­slave replikací. Při tomto modelu pak konflikty vznikají mnohem méně a systém se dá lépe kontrolovat. Ve většině případů nepřenášíme na mobilní platformu všechna data, která jsou uložena v databázi na serveru. Vhodné je použití pohledů nebo sestav nad databází a posílat jenom části databáze či jen několik tabulek. Tomuto přenosu pak říkáme částečná nebo filtrovaná replikace dat. Tato metoda je velice úsporná vzhledem k objemu přenášených dat [31].

5.1 Konflikty při synchronizaci Při replikaci dvou databází, které mají role master mohou vznikat konflikty. Pokud byla data

editována současně v obou databázích, tak se při synchronizaci dat jedna změna snaží přepsat druhou a vzniká tak kolize, kterou je nutno řešit. Vše se ještě komplikuje při zpřístupnění editace databáze programem na mobilních zařízeních v offline režimu. V tomto případě se editace na

23

centrální server přenáší méně častěji pouze tehdy, pokud je přístroj online a tím pádem vzniká kolizí více a v delším časovém horizontu. Konflikty můžeme v relačních databázových systémech řešit na řádcích, anebo na

jednotlivých buňkách. Při řešení na jednotlivých buňkách však složitost systému enormně roste, a proto se tomu snaží většina programů vyhnout. Rozlišujeme několik typů konfliktů [32]: Konflikt aktualizací ­ nastane pokud se dva záznamy zeditují současně ve dvou databázích a

poté nastane synchronizace. V případně mobilních zařízení může, vzhledem k delší době offline režimu, nastat tato kolize i ve třech a více uzlech. Konflikt odstranění ­ nastane pokud je stejný záznam v jedné databázi smazán a ve druhé je

editován nebo také smazán. Konflikt unikátních hodnot ­ vzniká pokud se vytvoří záznamy ve dvou databázích se

stejným primárním nebo unikátním klíčem ve stejný čas.

5.1.1 Vyhýbání se kolizím I když existuje mnoho nástrojů pro řešení kolizí v databázi, je vždy jednodušší navrhnout

aplikaci tak, aby se tvorbě konfliktů co nejvíce vyhnula. Zamykání záznamů ­ záznam je v databázi zamknut a editovat ho smí pouze uživatel jedné

databáze, které záznam patří. Při tomto modelu je však nutné určit vlastníka a držet informace o zamčení. Při využití editace v mobilních zařízeních je tato metoda použitelná pouze pro některé typy dat, převážně ty, u kterých nedochází k časté editaci. Vlastnictví dat ­ každá část databáze má svého vlastníka a pouze ten může data editovat,

ostatní data pouze čtou. Musí být vyřešeno, jak se dá zjistit vlastník. Povolení k modifikaci dat ­ rozšiřuje předchozí metodu o možnost předávání práv k editaci

dat. Musí se vyřešit způsob předávání dat. Vyhýbání se konfliktům unikátních hodnot ­ při přidávání záznamů se musí v každé

databázi vytvářet unikátní klíče tak, aby při synchronizaci nekolidovaly s klíči ostatních aplikací. Toto lze zajistit tak, že že každé zařízení generuje vlastní vzájemně disjunktní množinu unikátních hodnot. Často lze využít identifikátor uživatele, nebo zařízení. Vyhýbání se konfliktům při odstranění ­ data nemaže každá databáze, ale pouze je označí

ke smazání (“soft delete”). Data jsou pak přenesena na centrální server, kde se smažou. Transakce ­ každá editace se potvrdí pouze tehdy, jakmile je synchronizována na databázový

server. Pozdější synchronizace neaktuálních dat jsou odmítnuty.

5.1.2 Řešení kolizí Existuje několik možných způsobů přístupu, jak lze řešit samotné kolize, vždy však záleží na

možnostech nasazovaného systému a struktuře uložení datové základny. Obecně se však používá několik základních metod: “Vyhrává novější” je způsob, při němž se záznam přepíše nejnovější

24

přidanou změnou. Tato metoda je využitelná v některých modelech online replikaci dat, avšak je nutno uvažovat, že dochází k odstranění starších aktualizací. Dá se však využít i při synchronizaci v mobilních zařízeních, například při editaci vlastních komentářů uživatelů. V tomto případě má vždy práva k editaci pouze malý počet osob. Další způsoby slučování záznamů pro celé řádky se dají řešit pouze manuálně. Prvním ze

způsobů je nechat řešit kolize administrátora či uživatele, který má přístup do centrálního úložiště. Pokud se tedy objeví kolize, je administrátor upozorněn a musí ji v systému vyřešit spojením obou záznamů. Jiným přístupem je vrátit změnu uživateli zpět do zařízení (nejlépe pomocí transakční logiky). Uživatel je upozorněn, že od doby, co naposledy synchronizoval data vznikla editace v záznamu, který editoval. Tuto kolizi pak musí vyřešit sám.

5.2 Datové struktury pro přenos geodat Existuje mnoho datových struktur pro přenos dat v internetu. Při synchronizaci geografických

dat se dají informace rozdělit na tři typy: média, textová informace a prostorová informace. Média jsou binární soubory, tvořící nejčastěji obrazovou a video dokumentaci. Textová informace představuje především atributovou složku. Prostorovou složku tvoří nejčastěji geografické souřadnice v určitém souřadnicovém systému. Vždy však záleží na datovém modelu a způsobu uložení dat v databázi. Při přenosech všech formátů hraje velkou roli časová informace, na které jsou závislé některé algoritmy, řešící synchronizaci dat. V následujících podkapitolách jsou popsány nejpoužívanější otevřené formáty, které se využívají pro přenos textové a prostorové informace. Přenos médií není předmětem této práce.

5.2.1 JSON Formát nazývaný JSON je zkratka slov JavaScript Object Notation. Jedná se o textový zápis,

užívající člověkem čitelný text, kterým se zapisují strukturovaná data. Data se ve formátu JSON ukládají do objektů nebo polí a výstupem je vždy formátovaný řetězec. JSON byl původně odvozen z jazyku JavaScript, avšak je jazykově i platformě nezávislý [33]. Za otce JSON formátu je považován Douglas Crockford, který ho jako první specifikoval.

Později byl popsán a standardizován dvěma standardy jimiž jsou RFC 7159 a ECMA­404 (definováno standardizační organizací ECMA) [33]. Výhoda JSONu tkví v minimalizaci jeho zápisu. Hodně strukturovaná data jim lze zapsat

pomocí několika znaků, na rozdíl od XML, které nabývá kvůli definici tagů na velikosti. JSON je jednoduchý a také snadno čitelný jak strojem, tak i člověkem, proto se hojeně používá pro přenos dat na internetu, např. v aplikacích využívajících technologii AJAX. Mezi hlavní nevýhody patří nemožnost definování znakové sady, problém se zalomením

řádků, bílými znaky a nemožnost psaní komentářů. Jako MIME typ se oficiálně užívá aplication/json [34], neoficiálně se užívá aplication/javascript nebo text/json.

25

Příklad JSON formátu: "objekt" :

"číslo" : 10,

"text" : "hodnota1",

"pole" : ["hodnota1" , "hodnota2"]

5.2.2 GeoJSON Formát JSON přímo vybízí k využití pro přenos geografické informace. Tato implementace

byla specifikována v roce 2008 skupinou webových vývojářů. Formát definuje strukturu JSON objektů pro uchovávání prostorové informace a její atributovou složku [35]. Typy prvků:

Point ­ bod zadaný dvěma souřadnicemi MultiPoint ­ kolekce bodů zadaná v poli LineString ­ liniový prvek zadaný polem s minimálně dvěma body MultiLineString ­ více linií v poli Polygon ­ polygon představuje uzavřenou linii tvořící plochu a je zadáván minimálně třemi souřadnicemi v poli MultiPolygon ­ více polygonů zanořených v poli GeometryCollection ­ objekt, který umožňuje držet v sobě zároveň body linie i polygony Příklad:

"type": "FeatureCollection",

"features": [

"type": "Feature",

"properties":

"atribut": "hodnota"

,

"geometry":

"type": "Point",

"coordinates": [

17.2077012,

50.2241194

]

]

26

GeoJSON také umožňuje definovat souřadnicový systém pomocí objektu crs. Samotný systém je pak definován pomocí EPSG kódu nebo OGC CRS URN identifikátoru. "crs":

"type": "name",

"properties":

"name": "urn:ogc:def:crs:OGC:1.3:CRS84"

5.2.3 YAML YAML Ain't Markup Language (zkráceně YAML) je formát čitelný nejen strojem, ale i

člověkem. Byl specifikován v roce 2001 a nyní se používá verze 1.2 definovaná na podzim 2009 [36]. YAML umožňuje uložit text, číslo, pole i objekt. Hlavní struktura používá pouze pomlček, dvojteček a zalomení řádků, proto je, také jako JSON, velice minimalistický a oblíbený. Na rozdíl oproti JSONu umí YAML ukládat komentáře. Jednořádkový komentář lze zapsat pomocí mřížky (#). YAML zatím nemá specifikaci pro přenášení geografických dat. Formát se často využívá pro konfigurační soubory. Pro formát jsou dostupné otevřené parsery v mnoha programovacích jazycích. Příklad použití YAML: ­ klic: hodnota

­ klic2:

­ [hodnotapole1, hodnotapole2]

#komentar nad objektem

­ klic: kodnota, klic2: hodnota2

5.2.4 XML formáty Extensible Markup Language (zkráceně XML) je obecný značkovací jazyk, který byl vyvinut

a standardizován konzorciem W3C. Specifikace je dostupná všem. XML dokument je vždy v Unicode. Samotné XML nedefinuje obsah dokumentu, ale pouze strukturu, aby byl dokument správně formátovaný (“Well fromated”). XML je implementován v mnoha programovacích jazycích a je hlavní konkurent JSON a YAML. Na rozdíl od nich je však jeho zápis pomocí značek mnohem delší než u předchozích dvou formátů, a tak velikost datové struktury značně narůstá. Kvůli tomu není formát často využíván pro synchronizaci dat. Pro XML existuje, na rozdíl od předchozích formátů, řada specifikací, definující strukturu

uložení prostorových informací. Jedním z nejpoužívanějších je KML. Keyhole Markup Language (zkráceně KML) je nyní ve verzi 2.2 standardizován OGC (Open Geospatial Consortium). Byl vyvinut firmou Keyhole, kterou později odkoupil Google a tento formát použil

27

jako hlavní formát pro geografická data ve svých produktech. KML má na XML poměrně úspornou syntax a umožňuje uložit nejen prostorovou složku ve vektorech, ale i sylopis, překryvnou vrstvu nebo pohledy na geografická data. Komprimováním KML v definované struktuře pak vzniká binární formát KMZ [37]. Dalším používaným formátem je GPX (GPS Exchange Format). Je to formát vyvinutý pro

použití v navigacích. Jeho specifikace definuje uložení bodů a linií [38]. Většinou je používán pro ukládání surových dat v zařízeních, které jsou pak dále zpracovávána. GPX není příliš vhodný pro přenos dat, ale oproti KML má jednu výhodu, umožňuje držet časovou značku na vertexech linie. Často používaným formátem na geoinformatickém poli je i GML (Geography markup

Language), který prvně specifikovala OGC v roce 2000 [39]. GML se používá jako velice jednoduchá definice pro uložení prostorových dat v základu, tak i obálka která zaštiťuje specifikace mnoha geoinformatických odvětví. Používají se definice jako CityGML, GDL, IndoorGML, GML in JPEG2000 aj. Bod uložený pomocí GML: <gml:Point gml:id="p21" srsName="http://www.opengis.net/def/crs/EPSG/0/4326">

<gml:coordinates>50.226450, 17.205258</gml:coordinates>

</gml:Point>

GML z hlediska použitelnosti je asi nejlepší z XML formátů pro migraci geografických dat.

Dalšími XML formáty, využívanými pro přenos geografické informace, jsou například GeoRSS a OSM XML. 5.2.3 Textové formáty Textové formáty pro přenos dat představují skupinu formátů, které používají strukturovaný

text k zápisu geografické informace. Nejjednodušším zástupcem je Simple Feature Access (SFA), což je standard definovaný OGC a ISO pro jednoduché uložení 2D grafiky [40]. Simple Feature Access umožňuje uložit bod, linii, polygon, multilinii a multi­polygon. Tento formát je využíván především k uložení prostorových dat do databáze a využívá jej například Spatial extensions v MySQL [41], PostGIS, SpatiaLite nebo databáze Oracle. SFA je vhodné kombinovat například s datovou strukturou JSON či YAML, ve kterých by řešil strukturu uložení souřadnic jako string. Pokročilejším formátem, který se podobně využívá je WKT (Well­Known Text). Jedná se o

strukturovaný text, který velice jednoduše a s minimálním počtem znaků ukládá geografická data. Byl částečně standardizován OGC a plně ISO. Dokáže uložit 2D, 3D i 4D informace.Umí, spolu s nimi, uložit i souřadnicový systém[42]. (specifikováno OGC). WKT je naimplementován ve většině databázových systémů, které podporují práci s prostorovými daty.

28

5.2.4 Binární formáty Binární formáty jsou datové struktury uloženy v binární soustavě a je potřeba příslušného

interpreta, aby se daly otevřít. Za nejjednoduší binární formát pro uložení geografických dat, který se v geoinformatice používá, lze považovat KMZ. KMZ je pouze sada KML souborů zkomprimovaných pomocí komprimační metody ZIP, a tudíž se dají otevřít jakýmkoli programem pro čtení archivů. Well­known Binary (WKB) je datový formát implementovaný v relačních databázových

systémech pro uložení prostorové informace. Do databáze se pak ukládá jako text, např. BLOB v MySQL. WKB používá syntaxi WKT a tu kóduje do bitového řetězce. Např. WKB hodnota pro WKT POINT(1 1) se bude skládat ze sekvence 21 bytů (reprezentovaných dvěma hexadecimálními čísly) [43]: 0101000000000000000000F03F000000000000F03F Sekvence se dá pro lepší pochopení rozložit jako:

Pořadí bytů : 01 Typ WKB: 01000000 X souřadnice: 000000000000F03F Y souřadnice: 000000000000F03F Mladá specifikace OGC pro ukládání dat se nazývá GeoPackage. V podstatě se jedná o

SQLite databázi, ve které OGC specifikuje strukturu uložení vektorových dat, rastrových dat (především v dlaždicích) a metadat. Formát vznikl jako reakce na formát pro ukládání dlaždic do MBTiles. Nicméně implementaci zatím podporuje pouze několik GIS software např. GDAL, OpenJUMP, SpatilaLite 4.2.0, GeoServer a částečně i ArcGIS for Desktop a Server od 10.2.2 [44]. Firma MapBox, zabývající se distribucí rastrových dat na internetu, vyvíjí otevřený formát

pro ukládání rastrových map, nazvaný MBTiles. Tento formát definuje uložení rastrové mapy v dlaždicích 256x256 pixelů podle specifikace Google Mercator. V podstatě se jedná o SQLite databázi s přesně definovanou strukturou, kde jsou kromě metadat uloženy i samotné dlaždice. MBTiles umožňuje ukládat i interaktivní dlaždicovou vrstvu specifikovanou jako UTFGrid [45].

29

5.4 Algoritmy využitelné při synchronizaci dat V kapitole je popsáno několik vybraných programových algoritmů, které se využívají v

distribuovaných počítačových systémech pro zajištění přenosu dat.

Lamport timestamps Algoritmus Lamportovy hodiny (někdy nazývaný Skalární) se používá pro zajištění

globálního času v distribuovaných počítačových systémech. Byl vymyšlen a popsán Lesliem Lamportem v roce 1978. Každý uzel systému má vlastní logické hodiny a inkrementálně si čísluje operace. Při procesu synchronizace spolu systémy komunikují pomocí zasílání zpráv. Časová značka každé zprávy se porovnává se značkou v uzlu. Poté se porovná, zda se událost stala před nebo po konkrétním stavu. Systém předpokládá, že dvě události nenastanou ve stejný čas [46]. Vector clock Vektorové hodiny jsou odvozeny od Lamportových, které rozšiřují a zavádí vyšší přesnost.

Místo jednoho inkrementálního čítače obsahují tolik čísel, kolik je uzlů. Každý uzel si pak drží údaje o ostatních uzlech a ty pak tvoří vektor. Multiversion concurrency control Multiversion concurrency control (MVCC) je metoda řešení problému přístupu ke sdílené

databázi. Pokud je databáze dostupná pro více uživatelů ke čtení i zápisu, může nastat problém, kdy jeden uživatel čte data, do kterých jiný uživatel právě zapisuje. V tento moment by uživatel, co data čte, viděl neúplný zápis. Nejjednodušší algoritmus, který toto řeší, je zamykání záznamů. Ten však velice zpomaluje čtení v databázi. MVCC řeší tento problém tak, že při přidání nového záznamu nepřepisuje starý záznam, ale pouze ho označí jako zastaralý a přidá záznam nový. Uživatel pak vždy čte pouze nejnovější záznam a tím předejde kolizi [47]. Optimistic concurrency control Metoda Optimistic concurrency control (OCC), také někdy nazýván jako Optimistic Offline

Lock, zprostředkovává řízení souběžných systémů užívaných v transakčních systémech, jako jsou například relační databáze nebo transakční paměti programů. Metodu poprvé navrhl H.T. Kung. OCC předpokládá, že většina transakcí může být úspěšně dokončena bez toho, aniž by ovlivnila další transakce. Po zahájení transakce se nezamykají zdrojová data. Transakce probíhá a po změnách jsou data přenesena zase zpět. Pokud je po přenesení zpátky detekována chyba, pak se celá transakce ruší a uživateli je vrácena chyba. Tato metoda se využívá zejména na datech, kde dochází k méně časté editaci a konflikty pak není potřeba řešit [48].

30

Obr. 5: Příklad OCC [48]

Pessimistic Offline Locking Řeší transakční logiku podobně jako OCC, na rozdíl od toho, že po otevření záznamu jedním

klientem záznam zamkne a znemožní editaci ostatním klientům. Tento patern ovšem selhává v použitelnosti, pokud je editace prováděna příliš dlouho [49].

Obr. 6: Schéma pesimistického zamykání [49]

31

Timestamp ordering ­ algoritmus přiřazuje jednotlivým transakcím časové značky a podle nich pak řadí změny. Při nasazení v mobilních zařízení může nastat problém, pokud nejsou hodiny v zařízeních zcela přesné. Operational transformation ­ je systém, který umožňuje řešit mnoho kolizí v jeden moment. Užívá se např. v nástrojích pro hromadnou editaci dat, jako je Apache Wave nebo Google Docs. Princip spočívá v tom, že editace dokumentu probíhá v lokálním úložišti a transakčně se pak přenáší do centrální databáze. Přenosy se dějí velice často s editací každého znaku a tím se snaží co nejméně zabránit kolizím [50]. Na server se posílají data: Insert(0, 'B') ­ na pozici nula vlož písmeno velké b Delete(88) ­ smaž znak který je v pořadí 88 Byzantine fault tolerance ­ algoritmus se snaží řešit obecně známý problém dvou generálů, který nastává při doručování zprávy ve dvou systémech se špatným spojením a řeší chybovosti systému. Systém předpokládá, že pokud dojde zpráva, ve které není příliš mnoho vad, tak je správná.

5.5 Hotová řešení pro mobilní platformu V kapitole je popsáno několik dostupných řešení pro synchronizaci prostorových dat, které by

mohly být použity jako základ pro vývoj mobilních aplikací pro platformu Android. Pro nasazení pro praktickou část se uvažovalo právě mezi následujícími řešeními.

5.5.1 Android Sync Adapters Android SDK v sobě od API Level 7 a vyšší nabízí synchronizační vrstvu pro synchronizaci

se serverem nazvanou Sync Adapters. Jde o pětivrstvou archytekturu, která se spouští asynchronně, nezávisle na aplikaci a využívá REST archytekturu. Použití tohoto frameworku umožňuje velice efektivní synchronizaci v nativním prostředí a má několik výhod oproti jiným řešením mimo SDK [51]:

­ je koncipováno pro používání jako pluginu ­ automaticky se spouští v zařízení na pozadí ­ automaticky kontroluje připojení k síti ­ je uzpůsoben tak, aby co nejvíce šetřil baterii ­ obsahuje nástroje pro autentizaci a správu uživatelských účtů

32

Pro použití Sync Adapteru je nutno vytvořit serverovou část, která bude řešit odesílání a přijímání dat a autentizaci uživatelů. Některé proprietální serverové databázové systémy mají v sobě tyto nástroje již připravené.

5.5.2 SymmetricDS SymmetricDS je open­source software pro souborovou synchronizaci a synchronizaci

databází s podporou pro multi­master synchronizace, filtrované synchronizace a transformace napříč sítí v heterogenním prostředí. Podporuje více účastníků v jednom směru replikace nebo bi­directional, asynchronní replikace dat. Využívá webové a databázové technologie k replikaci dat jak v plánovaném čase, tak v téměř reálném čase. Pracuje s většinou operačních systémů, systémů souborů a databází, včetně Oracle, MySQL, MariaDB, PostgreSQL, MS SQL Server (včetně Azure), IBM DB2, H2, HSQLDB, Derby, Firebird, Interbase, Informix, Greenplum, SQLite (včetně Androidu), Sybase ASE a Sybase ASA (SQL Anywhere) databáze [52]. SymmetricDS také plně podporuje migraci dat z a na platformu Android. Má vyvinutého

klienta v Javě, který umožňuje synchronizaci databáze SQLite s libovolnou databází přes internet. Nejedná se o standardní verzi, ale spíše o knihovnu, která se přidá do Android projektu a řídí replikaci dat [52]. 5.5.3 CoutchDB Poslední trend a rozvoj webových aplikací na platfrome Node.js napomáhá k většímu rozvoji

a popularitě tzv. NoSQL databází. Jedním z často využívaných řešení je dynamický projekt 3

Apache CoutchDB. Jedná se o open­source databázový systém, který se zaměřuje na snadnost použití ve webových a mobilních aplikacích. Jedná se o objektově orientovaný databázový systém, který používá formát JSON pro ukládání dat v key­value objektech. Je napsaný v jazyce Erlang a používá JavaScript jako aplikační programové prostředí, které využívá technologii MapReduce a HTTP protokol. První release CoutchDB byl vydán v roce 2005. V roce 2008 pak 4

celý projekt přešel pod Apache Foundation, která řídí její vývoj [53]. CoutchDB implementuje Multi­Version Currency control (MVCC), kvůli zabránění zamykání

souborů při zápisu dat s následkem jejich ztráty. Je také skvěle navrhnuta pro použití v distribuovaných databázových systémech s důrazem na snadnou škálovatelnost. Umožňuje použití libovolného počtu nezávislých kopií stejné databáze. Mezi těmito kopiemi replikuje data a zachovává plnou databázovou interaktivitu (dotazování, mazání, editace, přidávání záznamu). Systém je plně schopný v nasazení pro občasný offline provoz, je tedy velice vhodný pro využití s nativními aplikacemi pro mobilní zařízení. CoutchDB má implementovanou detekci konfliktů a snadnou replikaci dat. Kopíruje pouze data, která byla změněna od poslední replikace. Pro řešení samotných konfliktů má mnoho nástrojů k řešení jak automaticky, tak i poloautomaticky.

3 NoSQL ­ databázový koncept, ve kterém datové úložiště i zpracování dat používají jiné prostředky než tabulkové schémata relační databáze

4 MapReduce ­ programovací model pro zpracování velkých množin dat pomocí paralelního zpracování

33

CoutchDB umožňuje master­slave replikaci, master­master replikaci, filtrovanou replikaci dat, inkrementační replikaci v obou směrech a silnou zprávu konfliktů v databázi [54]. Příklad logiky fungování CouchDB jednoduchého dotazování pomocí CURL. Otestování

běhu CoutchDB [55]: curl http://127.0.0.1:5984/

Tento příkaz posílá GET dotaz na s odpovědí že databáze běží: “couchdb”:”Welcome”, “version”:”0.10.1”

Vytvoření databáze: curl ­W PUT http://127.0.0.1:5984/baseball Odpověď: “ok”: true

Vypsání všech databází na serveru: curl ­X GET http://127.0.0.1:5984/_all_dbs

Odpověď: [“baseball”]

CoutchDB má vestavěné prostředí zvané “Futon” pro jedonodušší přístup k databázovému

serveru pomocí webového prohlížeče. Toto prostředí se nachází na dotazu _ulits (http://127.0.0.1:5954/_ulits), který v prohlížeči otevře nástroj pro práci [55].

Obr. 7: Prohlížeč Futon, pro prostředí CoutchDB [54]

34

5.5.4 PouchDB JavaScriptový port CoutchDB navrhnutý pro vývoj offline webových aplikací se jmenuje

PoutchDB. Je přímo navržen pro práci aplikací v offline a online režimu. Zaobaluje HTML5 lokální úložiště ve webovém prohlížeči a sjednocuje tak webové úložiště nekompatibilní ve všech prohlížečích. PoutchDB poskytuje objektové úložiště v JSON formátu a syntaxí kopíruje CoutchDB. Umí multi­master synchronizaci dat i filtrovanou replikaci [56]. Toto řešení je velice vhodné pro využití v aplikacích postavených na Apache Cordova. Jako

úložiště přímo v JavaScriptu nabízí možnost uložení dat do celkové velikosti 5Mb. Dá se použít přímo s pluginem pro práci s SQLite databází, pak je limit dle databáze SQLIte3. Příklad použití PoutchDB v Apache Cordova: var db = new PouchDB('pruvodce', adapter : 'websql'); db.put( _id: 'certovy­kameny', name: 'Čertovy kameny', lat: '50.245646', lng: '17.239054' );

Výběr dat: db.get('certovy­kameny', null, function(err, response) if(!err) console.log(response); );

5.5.5 Cloudová řešení Existuje i několik cloudových řešení, které mají silné nástroje pro synchronizování dat. Tyto

řešení často nabízí určitý objem přenesených dat zdarma a po té se platí dle obchodní politiky. Nevýhodou oproti předchozích řešeních je finanční náročnost pro velké projekty. Naopak výhodou je poskytnutí technické podpory, mají vyvinuté prostředky a návody pro rychlou implementaci a také umějí službu dobře zabezpečit. Jedním z dalších výhod je snadná škálovatelnost. V podstatě se tedy není potřeba starat o nahazování dalších serverů při velké zátěži. Vše řeší poskytovatel. Jedním z takových, je např. projekt Parse. Tento projekt nabízí cloudový backend, jako základ

pro vývoj mobilních či webových aplikací. Obsahuje souborové úložiště, databázové úložiště a zajišťuje i přenos dat. Parse také klientům vyvíjí programové prostředí pro využití na několika platformách. Na podobném principu funguje více služeb, jako např. Buddy, Kinvey nebo Google App Engine.

35

6 Průvodce horolezeckých oblastí severní Moravy Projekt Průvodce horolezeckých cest na Moravě už čtvrtým rokem slouží horolezcům jako

webová aplikace a je zdarma dostupný na internetu. Tento projekt vznikl jako rešerše několika lezeckých oblastí na severu Moravy. Jako prezentace a návod pro lidi, kteří neznají tento kraj. Během let se z něj vytvořila pokročilejší webová aplikace s uživatelskými přístupy a složitým backendem. Aplikace má dvě základní části: Mapovou aplikaci napsanou v Openlayers 3 a katalogové procházení oblastí. Průvodce tvoří skalní oblasti. Každá skalní oblast představuje jednu logickou část krajiny uzpůsobenou pro sportovní lezení. Skalní oblast je pak dopodrobna popsána, obsahuje vylezené cesty, informace o nich a mapky či plánky samotné oblasti. Cílem této praktické části bylo vytvoření mobilní aplikace, použitelné v offline režimu nad touto datovou základnou. Hlavní část tvoří mobilní aplikace, která se nainstaluje na Android. Pomocí této aplikace má

koncový uživatel možnost přistupovat k databázi offline v terénu. Při připojení k síti pak probíhá synchronizace dat, při které uživatel získává čerstvá data z databáze. Proces synchronizace vyžadoval připravenost na obou stranách jak serveru, tak aplikace. Z toho důvodu bylo nutné vytvořit aplikaci, která přijímá všechny data a odesílá ty data, které byly změněny od poslední aktualizace datové základny v aplikaci, také na serveru. Část aplikace v mobilním zařízení data zase přijme, zpracuje a uloží do lokální databáze. Aplikace pak k této databázi přistupuje a data zobrazuje uživateli. Jelikož jsou data na serveru uložena relačně v MySQL databázi, tak celá synchronizace

probíhá na úrovni tabulek a replikuje upravené a smazané řádky databáze. Jelikož je databáze specifická, bylo pro proces synchronizace vytvořeno vlastní řešení. Data do ní přibývají pouze párkrát do týdne a záznamy se téměř nemažou. Také bylo nutno zajistit kontrolu nad přístupem v telefonech kvůli hlášení chyb, zabezpečení a budoucí možnosti přístupu pouze přihlášeným uživatelům.

6.1 Přenos dat Jako výměnný formát pro přenos dat byl zvolen JSON. Je to kompaktní formát, který má

menší datový objem než značkovací jazyk XML a také kvůli JavaScriptu, ve kterém je synchronizační proces na straně klienta napsán. Aplikace byla navržena tak, aby se vyhnula master­master replikaci, ale zároveň byla připravena na budoucí možnost editovat databázi přímo z telefonu či tabletu. Proces master­slave synchronizace probíhá následovně: Mobilní zařízení (slave) vybere z databáze časovou známku poslední synchronizace a tu pošle AJAXovým dotazem v GET parametru na server (master). Server se podívá do databáze a vybere z tabulky všechny záznamy, které se editovaly od té doby a druhým dotazem všechny záznamy, které byly smazány. V databázi průvodce se data mažou pouze tzv. soft delete metodou, dá se jim tedy

36

pouze příznak, že byly smazány. Z vybraných dat se pak vyberou pouze ty sloupce, které jsou potřebné pro aplikaci (databáze obsahuje i sloupce s logikou webu). Z nich se následně vytvoří JSON a ten se vrátí jako odpověď. Mobilní aplikace data přijme, zvaliduje a aktualizuje záznamy v databázi, případně vytvoří nové. Pokud je databáze aktuální, tak se pošle prázdný objekt. JSON, který aplikace posílá, zaobaluje každou tabulku do pole a v tom pak každý jednotlivý

řádek představuje další pole:

stamp: "1425240000",

data:

table:

edited: [

id: 2, col1: "value1", col2: "value2"

],

deleted: []

,

table2:

edited: [],

deleted: [

id: "1"

]

6.2 Serverová část Tato část celého systému tvoří vrstvu, která řízeně zpřístupňuje data z databáze pro mobilní

zařízení. Dělá to tak, že přijímá požadavky klienta na určitých url adresách a na základě těchto požadavků vybírá data z databáze, které vrací jako odpověď ve strukturovaném formátu. K tomuto účelu je nutno spouštět dynamicky skripty. Z důvodů nasazení na standardním PHP hostingu byl vybrán jazyk PHP jako skriptovací jazyk. Pro dobré zabezpečení a usnadnění vývoje byl zvolen pro vývoj serverové části Nette Framework, který vyniká nejen dobrým zabezpečením a silnými nástroji pro přístup k databázi, ale i připravením na komunikaci pomocí formátu JSON. Nette ctí logiku aplikace MVP (Model Viewer Presenter). Model přistupuje k databázi a

vybírá z ní data, ty pak předává Presenteru, který je zpracuje a předá do View. V případě psaní serverového API není potřeba používat View, protože po zpracování dat v Presenteru se data utřídí do datové struktury, která se převede do JSONu a je pak odeslána jako odpověď. Není tedy potřeba řešit šablony a celou vykreslovací logiku. Modelová vrstva byla napsána pomocí Nette\Database. Jedná se o soubor tříd, které

zapouzdřují PDO a poskytují přístup k databázi. Základní funcionalitu pak zajišťuje 5

5 PHP Data Objects (PDO) ­ lehká základní databázová vrstva v jazyce PHP

37

Database\Table, která poskytuje pokročilou vrstvu pro práci s tabulkou a Database\Connection, které reprezentuje připojení k databázi. Práce s databází je pak velice rychlá ( není vůbec potřeba psát SQL dotazy). Nette také umí efektivně skládat dotazy a tím méně zatěžuje databázi. Příklad použití modelu ­ získání dat z tabulky skalních oblastí do proměnné $areas (PHP): $areas = $this­>models­>areas­>getVisible(); $areas­>where('UNIX_TIMESTAMP(edited) > ?', $stamp) ­>order('name ASC');

Tento kód vybere z modelu model areas a na něm zavolá metodu getVisible(), která vrací

Nette\Database\Table s oblastmi, které mají příznak, že jsou viditelné pro uživatele. NaTable se pak volá ještě metoda where(), která je součástí Database\Table a vybere pouze ty oblasti, které byly editovány od doby poslední synchornizace. Metoda order(), pak řadí data podle jména. Presenter pracuje následovně: Při vytvoření objektu nainjektuje model pro použití metodou 6

injectModelService(), dále Presenter sám zavolá metodu render, která se stará o řízení dalšího vykonávání programu. Do ní jsou předány parametry z URL. Po validaci parametrů nás zajímá hlavně jeden, tím je “stamp”, který obsahuje časovou známku poslední synchronizace. Mobilní aplikace ho posílá na server s tím, že očekává, že dostane změny v databázi od poslední synchronizace. Dále jsou vybírány data pomocí Modelu. Každá tabulka v datové struktuře obsahuje jeden objekt a v něm jsou id smazaných řádků (deleted) a řádky, které byly editovány (edited). Pro lepší čitelnost kódu je v presenteru každé logické třídění dat z tabulky v jedné metodě. Ty se pak složí do datové struktury pomocí (PHP): $response = array(

'stamp' => $stamp, 'data' => array( 'area' => array( 'edited' => $this­>getEditedAreas($stamp), 'deleted' => $this­>getDeletedAreas($stamp) ), ... ) );

Je to tak proto, že strukturaarea neobsahuje přímo kopii tabulky v databázi. Je to výběr z více tabulek, jakási obdoba “pohledu” do databáze, ale na aplikační vrstvě. Průvodce má totiž celkem 23 tabulek a část dat je zde uložena pouze kvůli funkčnosti editačního modulu, jenž je jeho součástí. Je zde také část dat, která slouží logice webu. Tyto data vůbec není potřeba přenášet do mobilních zařízení a díky tomu se uspoří objem přenášených dat.

6 Využívá patern Dependeny Injection, na kterém staví Nette

38

Proměnná $response pak obsahuje strukturu dat s klíčovými hodnotami, kterou je potřeba převést na objekt JSON a odeslat. K tomu je použita metoda sentResponse a objekt JsonResponse. JsonResponse je třída, která převede strukturu na JSON formát a odešle ho s patřičnými okolnostmi. V tomto objektu je ještě nastavena hlavička s MIME typem a kódování, se kterým je potřeba data odeslat (PHP): $this­>sendResponse(new JsonResponse($response)) ­>setContentType('application/json', 'UTF­8');

Obr. 8: Tok dat v aplikační logice

6.3 Android aplikace Pro vývoj aplikace bylo zvoleno hybridní řešení vývoje. Tedy skoro celá aplikace je napsaná

pomocí webových technologií a zabalená spolu s Apache Cordova. Skriptovacím jazykem je JavaScript a jako značkovací jazyk byl použit HTML a CSS3 pro vzhled a kompozici. I přesto, že toto řešení pro vývoj sebou nese pozitiva, jako multiplatformnost a počáteční jednoduchost, je nutno vytvořit si všechny komponenty uživatelského rozhraní. Jedním z hlavních kritérií pro

39

výběr tohoto řešení byla možnost použití Openlayers 3, která je zdarma dostupná pod otevřenou licencí, nabízí mnohem více možností pro vývoj mapové aplikace a je nezávislá na datových zdrojích (téměř všechny mapové frameworky pro Android se vytváří kolem datové základny, viz. kapitola 4.6). Jako úložiště je použita SQLite databáze, která je se základním schématem přibalená s aplikací (“build­in”). Pro přístup k SQLite je použit plugin Cordova­sqlite­storage, který maximálně emuluje rozhraní WebSQL. Velká výhoda využití SQL databáze je v tom, že se data dají snadno třídit a filtrovat (využito například při vyhledávání cest či řazení oblastí). Aplikace dále vyžaduje Cordova pluginy pro geolokaci (org.apache.cordova.geolocation) a práci se sítí (org.apache.cordova.network­information).

6.3.1 Synchronizace v aplikaci V rámci vytváření aplikace byla naprogramována databázová vrstva nad API

Cordova­sqlite­storage pluginu nazvaná dBase. Tato vrstva usnadňuje přístup k monotvárnému WebSQL API a má velice jednoduché použití. Konstruktor dBase vytvoří připojení k SQLite. Dále jsou k dispozici metody select, replace, update ainsert, které slouží pro přístup k databázi. Také je v třídě metoda escape, která vrací escapovanou hodnotu řetězce. Používá se hlavně při vkládání dotazů uvnitř třídy. Příklad výběru dat pomocí dBase (JavaScript): var dbase = new dBase('guide.db');

dbase.select('table', function(res)

window.console.log(res);

);

Kód v příkladu vytváří instanci třídy dBase a poté pomocí metodyselect vybere všechna data

z tabulky table. Do konzole se pak vypíší výsledky (res), což je pole, ve kterém každý prvek obsahuje objekt s key­value hodnotami, které reprezentují řádek v databázi. Všechny metody myslí a volají se asynchronně, je tedy nutno zadat funkci (callback), která se po úspěšném provedení dotazu do databáze zavolá. Pro synchronizování dat byla v rámci práce vytvořena vrstva naddBase nazvanáSynchronize,

která se stará o synchronizaci dat. Vrstva je přímo napsána na míru pro průvodce a synchronizuje čtyři tabulky. Má dvě privátní metodystart_a finish_ a veřejnou metodusend. Třída si sama řídí synchronizaci a vypisuje uživateli informace pomocí vyskakovacího okna se stavovou lištou. Po zavolání konstruktoru se vytvoří instance dBase a inicializuje se vyskakovací okno. Pak se zavolá metoda start_, která nejprve zjistí, kdy se naposled synchronizovalo a pak časovou známku odešle na server. Server vrátí záznamy, které se změnily od poslední synchronizace, metoda je příjme, vloží do patřičných tabulek a smaže záznamy, které se smazaly v databázi na severu. Proběhne tedy master­slave replikace dat. Pokud server nepošle žádná data, tak je

40

uživateli oznámeno, že není potřeba přenášet data. Celý proces je postupně znázorňován stavovou lištou. Po skončení synchronizace je zavolána metodafinish_, která zaznamená úspěšně proběhlou synchronizaci.

6.3.2 Uživatelské rozhraní a navigace Samotná data jsou pak uživateli prezentována v offline i online režimu přímo z SQLite

databáze v zařízení. Uživatel tedy nemusí zatěžovat datový přenos a může pohodlně a rychle procházet databází. Aplikace má na horní straně oranžovou lištu s ikonou pro otvírání menu. Pod lištou se pak zobrazuje obsah. Při některých pohledech se zobrazuje i spodní lišta, která nabízí nástroje pro filtrování obsahu. Po spuštění aplikace se zobrazí hlavní obrazovka nazvaná “zeď”. Na ní je sada čtyř velkých ikon pro snadný přechod do jiných částí. Hned při spuštění, pokud je zařízení připojeno pomocí Wi­Fi, se automaticky spustí synchronizace. Tato funkce se dá vypnout v Nastavení, stejně tak jako lze v nastavení synchronizaci spouštět ručně.

Obr. 9: Úvodní obrazovka aplikace (vlevo), průběh synchronizace a nastavení (vpravo)

Aplikace má dvě hlavní části: Mapu a textové procházení průvodce. Mapa je postavena na

Openlayers 3 a je kompilovaná pomocí Closure compileru zvaného Plovr. Jako podkladové mapy slouží dlaždicové vrstvy, nad nimiž jsou zobrazeny bodové vrstvy z průvodce. Základ tvoří bodová vrstva skalních oblastí znázorněna pomocí žlutého puntíku, při bližším přiblížení se pak objeví obrázky, rozlišené podle druhu oblasti (skalní oblast, boulderová oblast nebo umělá stěna). Při bližším přiblížení se zobrazí i bodová vrstva s jednotlivými věžemi. Symboly na kliknutí zobrazí vyskakovací okno, ve kterém je zobrazen název, popis a odkaz do textového

41

výpisu. Mapa plně podporuje multi­touch a rotování pomocí dvou prstů. Pro mapové zobrazení je použito WGS 84 / Pseudo­Mercator (EPSG:3857). Všechna data v databázi jsou ve WGS 84.

Obr. 10: Zobrazení mapy (vlevo), geolokace a výpis oblastí seřazený podle nejbližšího (vpravo)

Spodní lišta nabízí tlačítka pro vysouvání dvou nastavení. První nastavení umožňuje měnit

podkladové vrstvy či zapínat překryvné vrstvy. Druhé menu se věnuje geolokaci. Pokud uživatel chce, může si zapnout sledování polohy. Při datovém připojení se poloha získává pomocí Cell­ID, pokud je k dispozici Wi­Fi, tak pomocí Wi­Fi a při zapnuté GPS získáme polohu pomocí GPS senzoru. V téže kartě se zároveň vypisuje GPS status, poloha, přesnost, nadmořskou výšku aj.V mapě lze také přímo zobrazit přesnost, která se vykresluje modrým bufferem okolo červeného bodu pozice, kdy poloměr udává přesnost určení polohy. Textový výpis dat začíná kartou “Skalní oblasti”. Zde je vypsaný seznam všech skalních

oblastí uložených v zařízení. Data se dají filtrovat podle typu oblasti (skalní, boulderová, umělá stěna). a řadit abecedně nebo na základě vzdálenosti. Po stisku tlačítka, se nejprve pomocí geolokace, najde poloha zařízení (podobný algoritmus jako v mapové části), poté se vypočítá vzdálenost ke každé oblasti a nakonec se oblasti seřadí od nejbližší k nejvzdálenější. Výpočet probíhá na kouli WGS84 o poloměru 6378137m a užívá Harvestine algoritmus. Samotný výpočet je řešen pomocí Openlayers 3, které mají tento algoritmus implementovaný (JavaScript):

42

var pos = geolocation.getPosition();

//calculate distance

var wgs84Sphere = new ol.Sphere(6378137);

areas.forEach(function(area)

var dist = wgs84Sphere.haversineDistance(

[pos[1], pos[0]], [area.lat, area.lng]

);

//save distance in km

area.dist = Math.round(dist / 1000);

);

Z výpisu oblastí nebo z mapy se uživatel dostane přímo na zobrazení skalní oblasti, kde je v

prvním náhledu zobrazen popis a přístup k oblasti se základními informacemi. Ve druhé kartě pak samotný průvodce obsahuje skalní věže a jednotlivé cesty na ně. Výpis cest je doplněn o miniatury plánků a přehledových map oblasti. Po kliknutí na zobrazení miniatury přehledové mapy se otevře v zobrazení přes celou obrazovku v zoomovatelné prohlížečce. Prohlížečka je v lokálních souřadnicích vytvořených pomocí Openlayers 3. Načítání plánků funguje pouze pokud je aplikace online. Synchronizace medií pro offline použití nebyla předmětem této práce.

Obr. 11: Popis oblasti (vlevo), lezecké cesty v oblasti a zoomovatelná prohlížečka přehledových map (vpravo)

Poslední karta, ke které má uživatel přístup, je Vyhledávání cest. Zde se nachází pole pro

zadávání, které po napsání více jak tří znaků začne vyhledávat v databázi telefonu. Aplikace

43

vyhledává v databázi přímo, když uživatel změní text, proto je vyhledávání velice příjemné. Zároveň zobrazuje i počet výsledků, které byly nalezeny.

6.4 Testování Prvotní testování aplikace probíhalo průběžně během vývoje v emulátorech Androidu pomocí

AVD (Android Virtual Device Manager) a na fyzickém zařízení. V terénu pak bylo testováno přímo lezci na několika zařízeních Samsung řady S. Vždy byli vytipováni lezci v několika oblastech na severní Moravě a těm byl přímo pod skálou průvodce ukázán. Dále byla sledována funkčnost a přehlednost uživatelského rozhraní. Takto bylo osloveno 15 lezců. Zkušenosti s užíváním aplikace v terénu byly s lezci konzultovány a využity k dalšímu rozvoji aplikace.

44

7 Výsledky Výsledky diplomové práce lze rozdělit do dvou hlavních kategorií. Teoretická část popisuje

možnosti vývoje, dostupné algoritmy a východiska spojená s touto problematikou. Součástí praktické části bylo naprogramování aplikace a vytvoření webových stránek o práci.

7.1 Výsledky teoretické části V teoretické části je výsledkem práce zmapování dostupného trhu pro vývoj mobilních GIS

aplikací. Tato problematika je rozepsaná v kapitole 4. Byl zde proveden popis operačního systému Android a dále byly popsány všechny možnosti vývoje mobilních aplikací. Kapitola je koncipována tak, aby ji pochopil i neprogramátor a zabývá se geoinformatickými aspekty při vývoji. V kapitole je také popsáno šest frameworků, které slouží jako základ pro vytváření GIS aplikací, jejich výhody a nevýhody. Některé jsou také doplněny komentovanými částmi zdrojového kódu při použití. Dále se teoretická části zabývá problematikou synchronizace dat mezi mobilními zařízeními

(kapitola 5). V práci je popsán proces synchronizace dat mezi centrálním úložištěm a mobilními aplikacemi, který se řeší při synchronizaci. Jsou zde popsány problémy tohoto řešení, kolize v procesu a řešení jednotlivých kolizí. Dále byly popsány nejpoužívanější formáty pro výměnu dat přes internet (kapitola 5.2). Kapitola se také zabývá vybranými algoritmy, které se používají při programování synchronizační logiky. Dále bylo během práce prakticky otestováno několik hotových softwarových či programových prostředí, které řeší synchronizaci dat do mobilních zařízení. Ty jsou popsány v poslední podkapitole této části.

7.2 Výsledky praktické části Hlavním výstupem práce je mobilní aplikace pro platformu Android. Aplikace je mapovou

navigací pro horolezce a slouží pro snadnou orientaci v terénu. Aplikace je schopna periodicky aktualizovat data z centrální databáze na serveru a řeší efektivní práci v offline i online režimu. Aplikace dle nastavení uživatele synchronizuje online průvodce do mobilního zařízení. V rámci aplikace byla naprogramována databázová a synchronizační vrstva, která tento proces řeší. Mobilní průvodce nabízí uživateli mapovou část, kde je databáze průvodce vyobrazena v bodových vrstvách nad podkladovou dlaždicovou mapou. Mapová část umí pracovat s polohou zařízení a pomocí geolokace zobrazuje polohu zařízení na mapě pomocí GPS navigace, Wi­Fi připojení nebo Cell­ID. Také zobrazuje GPS status, přesnost, nadmořskou výšku, rychlost zařízení atp. Aplikace rovněž umožňuje procházet textovou části databáze, zobrazuje jednotlivé skalní oblasti, zobrazuje informace o oblastech a prochází horolezecké cesty a jednotlivé skály v oblastech. Nákresy jednotlivých skal je pak možno prohlížet online pomocí zoomovatelné prohlížečky. Výpis oblastí je pak možno různě filtrovat a řadit. Nejzajímavější je řazení na

45

základě geografické polohy, kde aplikace přepočítává sférickou vzdálenost mezi polohou zařízení a jednotlivými oblastmi. Aplikace také nabízí možnost vyhledávání horolezeckých cest. V rámci práce byla také vytvořena serverová aplikace s endpointy, na které se aplikace

přistupuje a pomocí nichž získává aktualizovaná data z databáze. Serverová část je napsaná v jazyce PHP a v Nette Frameworku (popsáno v kapitole 6.2). O diplomové práci byly také vytvořeny webové stránky, které jsou hostovány na katedrálním

serveru. Stránky jsou napsány pomocí validního HTML5 a stylopisu CSS3. Na stránkách jsou informace o práci, kontakt na autora a úplný text práce. Webové stránky, serverová část a Android aplikace jsou přiloženy na kompaktním disku.

46

8 Diskuze Severová část byla napsána v jazyce PHP 5.6 a pro snadnější vývoj, s důrazem na bezpečnost,

byl využit Nette Framework. Limit pro tyto technologie byl stanoven nasazením na běžném hostingu, s možnostmi spouštět skripty pouze v jazyku PHP. To byl i jeden z důvodů programování vlastního řešení pro synchronizaci dat. Druhým důvodem pro toto vlastní řešení byla specifičnost projektu. V databázi horolezeckých cest data ve většině případů pouze přibývají a občas se aktualizují, smazaných záznamů je minimum. Díky tomuto byly naprogramované aplikace obou stran vytvořeny tak, aby co nejlépe využily této vlastnosti a snížily tak objem přenášených dat. Toto řešení také myslí na budoucí rozvoj, autentizaci uživatelů a získávání statistických dat o uživatelích. Mobilní aplikace nebyla naprogramována pomocí technologií, které jsou zmiňované v zadání.

Během teoretické části (kapitola 4) a zkoumání dostupných možností trhu, bylo nalezeno řešení, které je vhodnější pro vytváření aplikace pro tento projekt. Umožnilo efektivnější vývoj a designovou sjednocenost s původním projektem webového průvodce. Také bylo možno díky tomuto směru vývoje využít přední GIS technologie jako je balík Openlayers 3. Rovněž je díky tomu aplikacenezávislá na datových zdrojích. Použitá platforma Apache Cordova neztrácí v žádném směru na použitelnost nativní aplikace napsané v jazyce Java. Aplikace je svižná s podporou dotykových událostí a laik rozdíl nepozná. Aplikace také nepřenáší editovaná data průvodce na server. V rámci projektu bylo

rozhodnuto, že sbírání uživatelských dat přináší do projektu velkou míru nejednotnosti a zanáší zbytečně nepřesná data do databáze, proto bylo zatím od myšlenky editace dat v zařízení opuštěno. Aplikace je nachystaná na doimplementování této funkcionality v budoucnu. Metodám zpětné synchronizace dat se nicméně plně věnuje kapitola 5 a tyto řešení jsou zde důkladně popsány alespoň na teoretické úrovni. Aplikace je naprogramována a testována pro Android 4.0 a vyšší. Ve starších verzích nebyla

funkčnost testována. Dle oficiálních statistik Googlu však nižší verzi Androidu používá pouze 6,8% uživatelů Androidu.

47

9 Závěr Tato práce se zabývá vývojem mobilních GIS aplikací na platformě Android. V rámci

teoretické části bylo cílem popsat možnosti vývoje a věnovat se synchronizaci dat do mobilních zařízení. Tyto cíle byly naplněny. Práce pojednává o dostupných možnostech vývoje GIS aplikací pro platformu Android a je zde i popsáno několik programových řešení, včetně ukázek komentovaných zdrojových kódů, jako základ pro vývoj mobilních geoinformačních technologií. Druhá část se pak zabývá možnostmi synchronizace dat mezi centrálním úložištěm a mobilními zařízeními. Jsou zde popsány principy, řešení a problémy, které mohou nastat při vytváření systému pro synchronizování dat. Dále jsou v práci popsány algoritmy, které se používají při synchronizaci. Tato část je zakončena vybranými hotovými řešeními, které jsou dostupné a použitelné pro předávání dat mezi mobilním zařízením a databázovým serverem. Tato teoretická část může sloužit jako přehled dosavadních možností a návodů pro vývoj datově orientovaných GIS aplikací a lze na základě těchto zkušeností vybrat řešení na míru danému projektu. Cílem praktické části bylo vytvořit funkční mobilní aplikaci zobrazující databázi

horolezeckých cest a serverovou aplikaci pro vzájemnou synchronizaci dat. Tento cíl se podařilo naplnit. Výstupem práce je mobilní GIS aplikace naprogramovaná pomocí Apache Cordova, která umí zobrazovat data z průvodce (údaje o oblastech, jednotlivých skálách a lezeckých cestách) tak, aby se podle nich mohl uživatel (lezec) v terénu orientovat. Aplikace zobrazuje data v offline režimu a je schopna stahovat si aktuální informace ze serveru, dále umí určit svoji polohu, zobrazovat GPS status, nadmořskou výšku atp. Serverová část napsaná pomocí Nette Frameworku je připravená na komunikaci se zařízeními a poskytuje aktuální data. Aplikace by měla sloužit lezcům a v budoucnu by měla být dostupná ke stažení na internetu.

48

Literatura Knižní [6] JORDAN, Lucas L a Pieter GREYLING. Practical Android projects. New York: Distributed by Springer Science+Business Media, c2011, xiv, 404 p. ISBN 1430232439. [9] ALLEN, Grant. Android 4: průvodce programováním mobilních aplikací. 1. vyd. Brno: Computer Press, 2013, 656 s. ISBN 978­80­251­3782­6. [13] ŠKOULA, Michal. Multiplatformní vývoj v HTML5. 2014 [29] TKÁČ, Josef a Ondřej ZAORAL. 2005. Průvodce světem kapesních počítačů: aneb PDA na dlani. 1. vyd. Praha: Grada, 205 s. ISBN 80­247­1227­X. [30] SOLANSKÁ, Markéta. Synchronizace a replikace geodat v prostředí Esri platformy. Olomouc, 2014. diplomová práce (Mgr.). UNIVERZITA PALACKÉHO V OLOMOUCI. Přírodovědecká fakulta [31] KOCMAN, Richard. Replikace dat. Č. Bud., 2008. bakalářská práce (Bc.). JIHOČESKÁ UNIVERZITA V ČESKÝCH BUDĚJOVICÍCH. Pedagogická fakulta [32] MLNÁŘÍK, David. Synchronizace databází pro platformu Android. 2013. Diplomová práce. Masarykova univerzita, Fakulta informatiky. [33] ZAKAS, Nicholas C. Javascript pro webové vývojáře: programujeme profesionálně. 1. vyd. Brno: Computer Press, 2009, 832 s. ISBN 9788025125090. [46] SKUPA, Jindřich. KIVFS ­ Synchronizace a trasování požadavků. Plzeň, 2012. diplomová práce (Ing.). ZÁPADOČESKÁ UNIVERZITA V PLZNI. Fakulta aplikovaných věd [47] ACM Transactions on Database Systems. New York: Association for Computing Machinery. ISBN 0362­5915. [55] ANDERSON, J, Jan LEHNARDT a Noah SLATER. 2010. CouchDB: the definitive guide. 1st ed. Sebastopol, CA: O'Reilly, xxi, 245 p. ISBN 05­961­5589­1. Elektronická [1] Open Handset Alliance [online]. 2011. [cit. 2015­05­09]. Dostupné z: http://www.openhandsetalliance.com/ [2] Licenses: Android developers [online]. 2013. [cit. 2015­05­09]. Dostupné z: https://source.android.com/source/licenses.html [3] Brand Guidelines: Android developers [online]. 2015. [cit. 2015­05­09]. Dostupné z: http://developer.android.com/distribute/tools/promote/brand.html [4] Apps: Experience Better Collaboration and More Efficient Operations [online]. 2015. [cit. 2015­05­09]. Dostupné z: http://www.esri.com/software/apps/ [5] Polymer: Welcome to the future [online]. 2015. [cit. 2015­05­09]. Dostupné z: www.polymer­project.org [7] Why is ART better than Dalvik? [online]. 2013. [cit. 2015­05­09]. Dostupné z: http://www.quora.com/Why­is­ART­better­than­Dalvik

49

[8] Android NDK: Android developers [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://developer.android.com/tools/sdk/ndk/index.html [10] Location and Maps: Android developers [online]. 2015. [cit. 2015­05­09]. Dostupné z: http://developer.android.com/guide/topics/location/index.html [11] Location APIs: Android developers [online]. 2015. [cit. 2015­05­09]. Dostupné z: http://developer.android.com/google/play­services/location.html [12] About Apache Cordova [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://cordova.apache.org/ [14] Ionic: Advanced HTML5 Hybrid Mobile App Framework [online]. 2015. [cit. 2015­05­09]. Dostupné z: http://ionicframework.com/ [15] NPM [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://www.npmjs.com/ [16] Kivy: Cross­platform Python Framework for NUI Development [online]. 2015. [cit. 2015­05­09]. Dostupné z: http://kivy.org/ [17] React Native: A FRAMEWORK FOR BUILDING NATIVE APPS USING REACT [online]. 2015. [cit. 2015­05­09]. Dostupné z: http://facebook.github.io/react­native/ [18] When is React Native Android coming? [online]. 2015. [cit. 2015­05­09]. Dostupné z: http://facebook.github.io/react/blog/#when­is­react­native­android­coming [19] Google Maps API licensing [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://developers.google.com/maps/licensing [20] Google Maps Android API v2 [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://developers.google.com/maps/documentation/android/ [21] Osmdroid [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://github.com/osmdroid/osmdroid [22] Osmdroid: ApplicationsUsingOsmdroid [online]. 2010. [cit. 2015­05­09]. Dostupné z: https://code.google.com/p/osmdroid/wiki/ApplicationsUsingOsmdroid [23] Mapbox/mapbox­android­sdk [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://github.com/mapbox/mapbox­android­sdk [24] Mapbox Android SDK [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://www.mapbox.com/mapbox­android­sdk/ [25] ArcGIS Runtime SDK for Android [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://developers.arcgis.com/android/guide/welcome­to­the­help­for­arcgis­runtime­sdk­for­android.htm [26] ArcGIS Runtime SDK for Android [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://developers.arcgis.com/android/ [27] Nutiteq [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://www.nutiteq.com/ [28] Mapsforge [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://github.com/mapsforge/mapsforge [34] Media Types. 2015. Internet Assigned Numbers Authority (IANA) [online]. [cit. 2015­05­09]. Dostupné z: http://www.iana.org/assignments/media­types/media­types.xhtml

50

[35] The GeoJSON Format Specification. 2008. GeoJSON [online]. [cit. 2015­05­09]. Dostupné z: http://geojson.org/geojson­spec.html [36] YAML Ain’t Markup Language (YAML) Version 1.2. 2009. YAML [online]. [cit. 2015­05­09]. Dostupné z: http://www.yaml.org/spec/1.2/spec.html [37] KML Reference. 2015. Google Developers [online]. [cit. 2015­05­09]. Dostupné z: https://developers.google.com/kml/documentation/kmlreference [38] GPX 1.1 Schema Documentation. 2015. Topografix [online]. [cit. 2015­05­09]. Dostupné z: http://www.topografix.com/gpx/1/1/ [39] Geography Markup Language. 2015. OGC [online]. [cit. 2015­05­09]. Dostupné z: http://www.opengeospatial.org/standards/gml [40] Simple Feature Access. 2015. OGC [online]. [cit. 2015­05­09]. Dostupné z: http://www.opengeospatial.org/standards/sfs [41] Extensions for Spatial Data. 2015. MySQL [online]. [cit. 2015­05­09]. Dostupné z: http://dev.mysql.com/doc/refman/5.1/en/spatial­extensions.html [42] Well­known text representation of coordinate reference systems. 2015. OGC [online]. [cit. 2015­05­09]. Dostupné z: http://www.opengeospatial.org/standards/wkt­crs [43] Well­Known Binary (WKB) Format. 2015. MySQL [online]. [cit. 2015­05­09]. Dostupné z: https://dev.mysql.com/doc/refman/4.1/en/gis­wkb­format.html [44] An Open Format for Geospatial Information. 2015. GeoPackage [online]. [cit. 2015­05­09]. Dostupné z: http://www.geopackage.org/ [45] An open platform: MBTiles. 2015. MapBox [online]. [cit. 2015­05­09]. Dostupné z: https://www.mapbox.com/guides/an­open­platform/ [48] Optimistic Offline Lock. 2015. Martin Flowler: P of EAA Catalog [online]. [cit. 2015­05­09]. Dostupné z: http://martinfowler.com/eaaCatalog/optimisticOfflineLock.html [49] Pessimistic Offline Lock. 2015. Martin Flowler: P of EAA Catalog [online]. [cit. 2015­05­09]. Dostupné z: http://martinfowler.com/eaaCatalog/pessimisticOfflineLock.html [50] Operational Transformation [online]. 2015. [cit. 2015­05­09]. Dostupné z: https://operational­transformation.github.io/ [51] Transferring Data Using Sync Adapters. 2015. Android Developers [online]. [cit. 2015­05­09]. Dostupné z: https://developer.android.com/training/sync­adapters/index.html [52] SymmetricDS [online]. 2015. [cit. 2015­05­09]. Dostupné z: http://www.symmetricds.org/ [53] Apache CouchDB [online]. 2015. [cit. 2015­05­09]. Dostupné z: http://couchdb.apache.org/ [54] About CouchDB. 2014. Apache Software Foundation [online]. [cit. 2015­05­09]. Dostupné z: https://cwiki.apache.org/confluence/display/COUCHDB/Introduction [56] Replication. 2015. Pouchdb [online]. [cit. 2015­05­09]. Dostupné z: http://pouchdb.com/guides/replication.html

51

Summary The main aim of this thesis is to develop the mobile GIS applications and synchronize the

geospatial databases on the Android platform. Theoretical part of the text presents the possibilities of development of mobile geographic information systems. Further, several software solutions are introduced as base for building mobile applications. The following part describes principles, problems and solutions for the database synchronization between central database and mobile devices. The current software solutions for such a case are included in the end of the chapter. In the practical part of the thesis a mobile application has been developed based on the

theoretical research. The application presents a mobile climbing guide of north Moravia. The mobile guide projects climbing areas as overlay over the map and displays position of device and GPS status. There is also a browser in this application including climbing areas which displays routes and rocks with an overview map. Hybrid solution on Apache Cordova toolkit was chosen as a base for the application. Further, during the work on this thesis a server­side application written in PHP has been developed which provides access to the databases on the server for mobile apps. The mobile climbing guide synchronizes periodically its databases with the server and in the future it should be available on the internet to all the climbers interested in climbing areas of north Moravia.

52

Přílohy

Seznam příloh Příloha č. 1: Kompaktní disk Obsahuje: ­ mobilní aplikaci ­ zdrojové kódy k mobilní aplikaci ­ serverovou část ­ webové stránky o práci ­ text diplomové práce v elektronické podobě