Aplikace pro práci s OpenStreetMap pro Android. Tomáš Mudruňka

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Aplikace pro práci s OpenStreetMap pro Android Tomáš Mudruňka Vedoucí práce: Ing. Tomáš Novotný Studijní program: Otevřená informatika, Bakalářský Obor: Softwarové systémy 21. května 2012

iv Poděkování Tímto bych rád poděkoval panu Ing. Tomáši Novotnému za cenné rady, připomínky a odborné vedení této bakalářské práce. Dále bych chtěl poděkovat celé své rodině za jejich podporu při studiu.

Abstract This bachelor thesis deals with designing and implementation of an application used for browsing a map data for the mobile operating system Android. It uses the accelerated graphic environment OpenGL ES for map rendering. The main purpose of this application is to display maps offline although it can use a map data from available web services. While online the application also supports a point of interest searching. Another feature of this application is creating of map files in the SQLite format from a geographical data of the OpenStreetMap project. This feature is handled by the server part of this application and provides an ability to generate a map data in a various visual styles. Abstrakt Tato bakalářské práce se zabývá návrhem a implementací aplikace pro mobilní operační systém Android určené k prohlížení mapových podkladů, která pro vykreslování používá akcelerované grafické prostředí OpenGL ES. Aplikace je určená hlavně k zobrazování map offline, ale umožňuje použití i mapových podkladů z webových služeb. V online režimu aplikace také podporuje hledání bodů zájmu. Další funkcionalitou je vytváření mapových souborů v SQLite formátu z geografických dat projektu OpenStreetMap. Tato funkcionalita je pak zprostředkována serverovou částí aplikace a umožňuje generovat mapové podklady v několika různých vizuálních stylech. vi

Obsah 1 Úvod 1 1.1 OpenStreetMap................................... 1 1.1.1 Formát dat................................. 1 1.2 Android....................................... 2 1.2.1 Historie................................... 2 1.2.2 Architektura................................ 2 1.2.3 Vývoj pro Android............................. 3 2 Popis problému, specifikace cíle 6 2.1 Popis problému................................... 6 2.2 Specifikace cíle................................... 6 2.3 Kontext použití a cílová skupina uživatelů.................... 7 2.4 Popis existujících aplikací............................. 7 2.4.1 Google Maps................................ 7 2.4.2 Mapy.cz................................... 8 2.4.3 RMaps.................................... 8 2.4.4 MapDroyd................................. 9 2.5 Použité technologie................................. 10 2.5.1 OpenGL................................... 10 2.5.2 PostgreSQL a PostGIS........................... 11 2.5.3 SQLite.................................... 11 2.5.4 Mapnik................................... 12 2.5.5 Carto.................................... 12 2.5.6 osm2pgsql.................................. 12 2.5.7 Node.js................................... 12 3 Analýza a návrh řešení 14 3.1 Formát mapových podkladů............................ 14 3.2 Výběr úrovně Android API............................ 15 3.3 Výběr prostředí pro běh serveru.......................... 15 3.4 Návrh řešení.................................... 15 3.4.1 Klientská aplikace............................. 17 3.4.2 Serverová aplikace............................. 17 3.5 Analýza funkčních a nefunkčních požadavků................... 19 3.6 Použité vývojové prostředí............................. 20 vii

OBSAH viii 4 Realizace 21 4.1 Schéma mapové databáze............................. 21 4.2 Implementace klientské aplikace.......................... 22 4.2.1 Rozdělení aplikace do Aktivit....................... 22 4.2.2 Aplikační databáze............................. 23 4.2.3 Vykreslování pomocí OpenGL....................... 24 4.2.4 Využívání mapových zdrojů........................ 26 4.2.5 Proces vykreslování mapy......................... 27 4.2.6 Hledání bodů zájmu............................ 27 4.2.7 Žádosti o vytvoření mapy......................... 27 4.2.8 Konfigurace online služeb......................... 29 4.2.9 Popis Java balíčků............................. 29 4.3 Implementace serverové aplikace......................... 30 4.3.1 Databáze.................................. 30 4.3.2 Žádosti o vytvoření mapy......................... 31 4.3.3 Styly vzhledu renderovaných map..................... 31 4.3.4 Aktuální nedostatky............................ 32 5 Testování 33 5.1 Testovací prostředí................................. 33 5.2 Testování funkcionality............................... 33 5.3 Uživatelské testování................................ 33 5.3.1 Průběh testů................................ 34 5.3.2 Výsledky testů............................... 34 5.4 Výsledky externího testování........................... 35 6 Závěr 37 6.1 Další možný vývoj................................. 37 Literatura 39 A Seznam použitých zkratek 41 B Instalační příručka 43 B.1 Instalace klientské aplikace............................ 43 B.2 Instalace serverové aplikace............................ 43 C Obsah přiloženého CD 45

Seznam obrázků 1.1 Android architektura................................ 3 1.2 Životní cyklus Android Aktivity.......................... 5 2.1 Rubberband mód.................................. 9 2.2 Vykreslovací řetězec OpenGL........................... 11 3.1 Rozdělení Android verzí.............................. 16 3.2 Verze Android platformy.............................. 16 3.3 Diagram komponentů klientské aplikace..................... 18 3.4 Diagram komponentů serverové aplikace..................... 18 4.1 Schéma mapové databáze v SQLite formátu................... 22 4.2 Závislosti jednotlivých Aktivit klientské aplikace................ 23 4.3 Schéma databáze, kterou používá klientská aplikace.............. 24 4.4 Mřížka pro vykreslování mapových dlaždic.................... 25 4.5 Diagram znázorňující proces vykreslování mapy................. 28 4.6 Schéma pomocné databáze serverové aplikace.................. 30 4.7 Snímek obrazovky pro editaci stylů programu TileMill............. 32 ix

Kapitola 1 Úvod Tato bakalářská práce se zabývá návrhem a implementací aplikace pro mobilní operační systém Android určené k zobrazování rastrových map a to především za využití dat z projektu OpenStreetMap. Součástí implementované aplikace je i její serverová část, která slouží k vlastnímu renderování rastrových map a poskytování dalších informací z projektu OpenStreetMap. V této kapitole je dále představen zmíněný projekt OpenStreetMap a také platforma pro mobilní zařízení Android. 1.1 OpenStreetMap OpenStreetMap (OSM) je komunitní projekt s cílem vytvořit editovatelnou mapu celého světa dostupnou zdarma. Mapy jsou tvořeny z dat získaných pomocí přenosných satelitních navigačních zařízení, leteckých snímků, jiných zdarma dostupných zdrojů nebo z místních znalostí. Renderované obrázky i samotná vektorová data jsou pak dostupná pod Creative Commons Attribution-ShareAlike 2.0 1 licencí. Přístup OSM projektu k sbírání geografických dat byl inspirován projekty jako je Wikipedia, umožňuje jednoduchou editaci dat, uchovává kompletní historii provedených změn a výsledky práce jsou dostupné veřejnosti zdarma. Projekt OSM založil Steve Coast v červenci roku 2004. Následně v dubnu roku 2006 byla založena nadace OpenStreetMap Foundation (OSMF) za účelem podpořit růst, vývoj a rozšiřování geografických dat zdarma pro kohokoli k používání a sdílení. Zpočátku byla geografická data sbírána dobrovolníky při systematických průzkumech pomocí ručních GPS zařízení, poznámkových bloků a digitálních fotoaparátů. Nasbíraná data pak byla vložena přímo do OSM databáze. Později se data získávala z leteckých snímků, komerčních i vládních zdrojů, což umožnilo rychlejší a detailnější pokrytí. [19] 1.1.1 Formát dat Pro ukládání dat OSM používá následující topologickou datovou strukturu. 1 Creative Commons Attribution-ShareAlike 2.0 licence umožňuje bezplatné soukromé i komerční použití a úpravy díla za podmínky použití stejné nebo podobné licence na výsledný produkt. 1

KAPITOLA 1. ÚVOD 2 Nodes jsou body reprezentující geografickou polohou uložené jako souřadnice nadmořské výšky a šířky. Ways jsou posloupnosti uzlů reprezentující polylinii či polygon. Relations jsou skupiny uzlů, cest nebo dalších relací, kterým je přiřazena určitá vlastnost. Tags jsou atributy, které mohou být přiřazeny uzlům, cestám nebo relacím ve formě <klíč>=<hodnota>. 1.2 Android Android je platforma pro mobilní zařízení zahrnující operační systém, middleware a další klíčové aplikace. Již od svého počátku Android získal velkou popularitu a v roce 2011 měl téměř 50% na trhu s chytrými telefony [7]. Dle studie z roku 2011 Android používalo 67% vývojářů mobilních aplikací [6]. Koncem roku 2011 dosáhl tehdejší Android Market 2 10 miliard stažených aplikací [4]. 1.2.1 Historie Za vznikem této platformy stojí společnost Android Inc., která byla založena v roce 2003 ve Spojených státech s cílem vyvíjet chytrá mobilní zařízení. V roce 2005 tuto společnost koupila společnost Google Inc., tento krok vyvolal spekulace o tom, že Google chce proniknout na trh s mobilními telefony. V roce 2007 pak za iniciativy Google vzniklo konsorcium Open Handset Alliance (OHA) složené z řady společností zabývajících se výrobou mobilních zařízení, mezi ně patří HTC, Intel, Motorola, Nvidia, Qualcomm a další. Cílem tohoto uskupení byl vývoj otevřených standardů pro mobilní zařízení. Dnem vzniku OHA také vydala svůj první produkt - Android, platformu pro mobilní zařízení postavenou na Linuxovém jádře verze 2.6. Krátce poté bylo představeno první vývojové prostředí Android SDK. První mobilní telefon využívající Android 1.0 byl HTC Dream (známý také jako T-Mobile G1 ), který byl vydán 22. října 2008. [16] 1.2.2 Architektura Operační systém Android se skládá z jádra postaveného na Linux jádře s middleware, knihovnami a API napsanými v jazyce C. Dále obsahuje aplikační vrstvu běžící na aplikačním rámci, který je složen z Java knihoven z projektu Apache Harmony 3. Android používá vlastní virtuální stroj Dalvik VM s just-in-time kompilací, který je obdobou virtuálního stroje jazyka Java. Detailnější schéma Android architektury je znázorněno na obrázku 1.1 na straně 3. Virtuální stroj Dalvik má architekturu odlišnou od běžné Java VM, využívá vlastní bytekód a má odlišné spustitelné soubory (Dalvik executable s příponou.dex). Ačkoliv 2 Android Market byla běžně dostupná aplikace ve všech systémech Android sloužící k hledání, stahování a nakupování aplikací. V roce 2012 byla nahrazen službou Google Play. 3 Apache Harmony je open source implementace Javy vyvíjená Apache Software Foundation.

KAPITOLA 1. ÚVOD 3 je Dalvik postaven na Javě, nedodržuje standardy Java Standard Edition ani Java Micro Edition, není tak s Javou 100% kompatibilní. Pomocí nástroje zvaného dx je možné převést některé Java.class soubory do formátu podporovaného virtuálním strojem Dalvik. Dalvik je optimalizován pro chod na mobilních zařízeních a to především co se týče paměťové náročnosti. Dle Google byl Dalvik navržen tak, aby umožňoval efektivní běh více virtuálních strojů na jednom zařízení najednou. [15] Obrázek 1.1: Hlavní komponenty operačního systému Android. [10] 1.2.3 Vývoj pro Android Ačkoliv je možné psát aplikace pro Android přímo v nativním kódu, což umožňuje Android Native Development Kit (NDK), nejčastěji se využívá programovacího jazyku Java a Android Software Development Kit (SDK). Důvodem je hlavně rozsáhlá podpora vývojářských nástrojů jako jsou debugger, knihovny, emulátory mobilních zařízení, dokumentace, ukázkové kódy a návody. Android SDK je dostupné pro systémy Linux, Windows i Mac OS a podporuje také rozšíření do vývojových prostředí, například Android Development Tools (ADT) pro vývojové prostředí Eclipse. Každá aplikace v systému android má přiřazen vlastní proces, vlastní virtuální stroj a existuje ve svém prostoru v paměti. Systém Android se chová jako multiuživatelský operační systém Linux, kde každá aplikace představuje jednoho uživatele. Tímto jsou aplikace od sebe bezpečně odděleny. Tomuto způsobu se někdy říká tzv. Sand-box (česky pískoviště). Android aplikace jsou distribuovány jako archiv (Application Package s příponou.apk) obsahující spustitelné soubory pro virtuální stroj Dalvik, různé zdroje v XML formátu, obrázky a další zdrojové soubory. Specifika vývoje aplikací pro Android:

KAPITOLA 1. ÚVOD 4 Aplikace nemají jeden vstupní bod jako je main() metoda, ale jsou rozděleny do Aktivit (Activity), které jsou na sobě nezávislé a mohou existovat samostatně. Aktivity obvykle reprezentují jednu obrazovku dané aplikace s konkrétní funkcionalitou. Stav těchto Aktivit se řídí životním cyklem, kde dochází k přepínání mezi během na popředí, na pozadí či inicializace a ukončování Aktivity. Stavový diagram životního cyklu Aktivity je na obrázku 1.2 na straně 5. Tento princip je klíčová vlastnost Android aplikací a poskytuje řadu výhod. Například umožňuje členit aplikace do nezávislých částí a pohodlně využívat již existující řešení jako je Internetový prohlížeč, mapy, e-mailový klient a podobně. Android aplikace mohou také obsahovat Služby (Service), které jsou podobné zmíněným Aktivitám jen s tím rozdílem, že slouží k provádění dlouho trvajících operací na pozadí systému. Dalšími prvky aplikace mohou být Content providers a Broadcast receivers, které slouží k poskytování různých dat nebo přijímání zpráv od systému či jiných aplikací. Dalším specifikem Android aplikací je Android Manifest, což je XML soubor obsahující klíčové informace o aplikaci. Každá Android aplikace musí mít soubor Android- Manifest.xml ve svém kořenovém adresáři. Manifest soubor mimo jiné obsahuje jméno aplikace, její Java balíček, definuje všechny používané komponenty, minimální podporovanou verzi Android API a další. Mezi nejdůležitější obsažené informace patří seznam Oprávnění (Permissions), které definují co bude aplikaci umožněno provádět. Příkladem Oprávnění je přístup k Internetu, zápis na SD kartu, posílání SMS, zahájení hovoru, použití GPS a podobně. Při instalaci aplikace musí uživatel všechny tyto Oprávnění povolit. Zajímavým prvkem vývoje pro Android je návrh a implementace grafického uživatelského rozhraní (GUI). To lze vytvářet programově, ovšem mnohem častější a pohodlnější cestou je definice GUI pomocí XML Layout souborů. Tyto soubory pak obsahují veškeré informace o podobě uživatelského rozhraní. Pro usnadnění vývoje Android SDK poskytuje i WYSIWYG 4 editor. Výhodou tohoto přístupu je možnost mít různé rozložení uživatelského rozhraní pro různé velikosti a orientace displeje. 4 z anglického what you see is what you get

KAPITOLA 1. ÚVOD 5 Obrázek 1.2: Stavový diagram životního cyklu Android Aktivity. [10]

Kapitola 2 Popis problému, specifikace cíle Tato kapitola se zabývá obecným popisem řešeného problému, specifikací cílů této práce, požadavky na výslednou aplikaci v kontextu jejího užití, obsahuje rešeršní porovnání již existujících aplikaci pro zobrazování mapových podkladů a také popisuje technologie použité při implementaci této práce. 2.1 Popis problému V dnešní době jsou chytré telefony velmi rozšířené a jejich výkon je již dostačující ke komfortnímu prohlížení i velkých a detailních mapových dat. S rozšiřováním počtu chytrých telefonů stoupá i poptávka po aplikacích schopných zobrazovat mapové podklady, takže i nabídka takovýchto aplikací se rozšiřuje a uživatelé mají velkou možnost výběru [12]. Ovšem kvalitních aplikací dostupných zdarma, schopných prohlížet mapová data offline, je jen malé množství. Další nevýhodou některých aplikací je nemožnost změny vzhledu zobrazovaných map či použití vlastních mapových podkladů. Také vyhledávání bodů zájmu na mapě je funkcionalita, která některým aplikacím bohužel schází. 2.2 Specifikace cíle Cílem této bakalářské práce je implementovat funkční aplikaci pro zobrazování mapových podkladů určenou hlavně pro offline použití. Aplikace bude určena pro mobilní operační systém Android a jako mapové podklady bude využívat SQLite databáze uložené v zařízení (nejčastěji na SD kartě). Aplikace dále bude umožňovat prohlížení map i online z dostupných webových služeb a také bude podporovat hledání bodů zájmu. Dalším cílem práce je implementace serverové strany aplikace, která bude sloužit hlavně ke generování mapových podkladů. Serverová aplikace bude schopná vyrenderovat vybranou oblast mapy do formátu podporovaného klientskou stranou aplikace. Server bude dále umožňovat i renderování jednotlivých rastrových obrázků a vyhledávání bodů zájmu. Všechna funkcionalita serveru bude přístupná z klientské části aplikace. Motivací je umožnit uživatelům pohodlně prohlížet mapové podklady bez nutnosti stálého připojení k Internetu. Navíc by měla aplikace umožnit uživatelům výběr z více stylů vzhledu výsledné mapy či použití vlastních mapových dat. 6

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 7 2.3 Kontext použití a cílová skupina uživatelů Jak již bylo zmíněno, výsledná aplikace bude určená zejména pro offline používání a to jak v prostorech s dostupným připojením tak i bez něj. Mobilní Internet je sice čím dál více rozšířen a i přenosové rychlosti jsou již na použitelné úrovni, ovšem cena může být stále pro některé uživatele překážkou. Cena je pak obzvlášť limitující faktor při pobytu v zahraničí. Příkladem využití aplikace může být právě zahraniční turistika nebo sport, kdy si uživatel může dopředu stáhnout mapu vybraného místa pro pozdější offline prohlížení. Dalším příkladem může být využití již stažené mapy města k online vyhledávání bodů zájmu přes mobilní Internet a tím se lze vyhnout velkým datovým přenosů. Cílovou skupinou uživatelů aplikace jsou uživatelé znalí operačního systému Android, se základní zkušeností práce s mapami a obeznámenými s pojmem bod zájmu (POI). Jelikož je aplikace určena zejména pro offline použití, je určena hlavě uživatelům, kteří při používání aplikace z nějakého důvodu nemohou nebo nechtějí být online. 2.4 Popis existujících aplikací Tato sekce bude věnována některým vybraným aplikacím pro platformu Android, které slouží k zobrazování map a případně dalších dodatečných informací, jako jsou například body zájmu. Zmíněny jsou pouze aplikace, které jsou ke stažení zdarma, placených aplikací je na trhu jen minimum a v konkurenci aplikací zdarma najdou využití jen v ojedinělých případech. 2.4.1 Google Maps Aplikace Google Maps od společnosti Google Inc. patří bezesporu k těm nejpoužívanějším a nejpropracovanějším aplikacím určených k zobrazování map vůbec. Důvodem je hlavně to, že je vyvíjena společností Google, která zároveň stojí i za celou platformou Android. Výhodou oproti ostatním aplikacím je také fakt, že na většině zařízení je již obsažena v tovární verzi systému a není jí tak třeba manuálně instalovat. Google Maps nabízí mnoho funkcí jako různé druhy mapových podkladů včetně satelitních snímků, službu Street View, fulltext vyhledávání, hlasové vyhledávání, GPS a kompas, plánování tras, navigaci, hledání nejbližších bodů zájmu v okolí, zobrazování detailních informací o bodech zájmu a další. Vyhledávání na mapách je napojeno na službu Google search a výsledky jsou tak v odpovídající kvalitě. Z technického hlediska jsou Google Maps na velmi dobré úrovni. Díky akcelerovanému vykreslování pomocí OpenGL je odezva a celková rychlost aplikace nadprůměrná. Grafické uživatelské rozhraní je minimalistické a intuitivní bez závažných usability 1 problémů. Za zmínku stojí i vlastní manipulace s mapou, kde dochází k postupnému načítání mapových dat a působí tak mnohem plynuleji. Tímto způsobem je před uživatelem naprosto ukryta úroveň přiblížení, která zde vůbec nemá pevně dané hladiny. To je z uživatelského hlediska velkou výhodou. 1 použitelnost - snadné používání a naučení se

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 8 Mezi nevýhody Google Maps patří hlavně nutnost stálého připojení k datovým službám pro využití veškeré funkcionality. Aplikace sice v omezené míře ukládá mapová data do vnitřní paměti a redukuje tak datové přenosy, ovšem offline lze zobrazit jen tyto data a ostatní funkce aplikace jsou nedostupné. Za další nevýhodu lze považovat to, že aplikace umožňuje zobrazovat pouze mapová data od Google, takže kvalita a přesnost může být v některých lokalitách (například v ČR) nižší než mapových podkladů z OSM nebo Seznamu. Mapové podklady od Google navíc nemusí vyhovovat preferencím uživatele. Do nejnovějších verzích byla přidána funkcionalita stažení mapy vybrané oblasti pro pozdější offline prohlížení [8]. Množství stažených dat je však limitováno. 2.4.2 Mapy.cz Mapy.cz je aplikace pod záštitou tuzemského serveru Seznam.cz využívající jeho mapové podklady a vyhledávání. Tato aplikace cílí hlavně na český trh, kde patří mezi největší konkurenty Google Maps. Mapové podklady Seznamu jsou na území ČR velmi kvalitní a detailní, mimo ČR je ale k dispozici pouze Evropa to jen v omezené míře. Mimo náš trh není tedy příliš použitelná. Mezi příjemnou funkcionalitu aplikace patří vyhledávání bodů zájmu v okolí a zobrazování přidružených informací. Dále aplikace podporuje fulltextové vyhledávání na mapě, GPS s kompasem a plánování cest. I aplikace Mapy.cz má velmi dobré technické zpracování a také využívá akcelerované vykreslování map pomocí OpenGL stejně jako Google Maps. Nicméně v rychlosti a plynulosti načítání před Google Maps trochu zaostává. Také zde nejsou hladiny přiblížení pevně dány a mapu tak lze přiblížit libovolně. Velkou výhodou aplikace je vyhledávání a zobrazování informací o nejbližších bodech zájmu, které je díky specializaci na český trh velmi kvalitní. Nevýhodou aplikace Mapy.cz je opět jako u Google Maps nutnost stálého připojení k datovým službám. Zde ale aplikaci používat offline nelze vůbec. Grafické uživatelské rozhraní je minimalistické a celkem intuitivní. Ale Mapy.cz ve verzi 1.1.2 obsahuje nepříjemný usability problém, kde části uživatelského rozhraní mizí, když uživatel s mapou přestane manipulovat. Další nevýhodou je opět omezení na mapové podklady, tentokrát pouze od Seznamu. 2.4.3 RMaps RMaps je open source aplikace pro zobrazování map dostupná na Android Marketu. Aplikace podporuje mnoho mapových podkladů včetně OSM, Google, Microsoft a další. Zobrazovat tyto podklady lze online, ale také offline z vnitřní paměti aplikace. Aplikace automaticky ukládá mapová data při online prohlížení. Další zdroj mapových podkladů, který aplikace RMaps podporuje, jsou mapy na SD kartě v SQLite formátu 2. Mezi další funkce RMaps patří vyhledávání adres na mapě, vkládání bodů zájmu, GPS s kompasem a zaznamenávání trasy či pohybu uživatele. Největší výhodou aplikace RMaps oproti ostatním aplikacím je podpora velkého množství mapových podkladů (včetně vlastních podkladů uživatele) a možnost offline prohlížení. Záznam tras patří také mezi zajímavou funkcionalitu. V ostatních oblastech aplikace nijak nevyniká. 2 Na stránkách vývojáře aplikace RMaps je umístěn návod jakým způsobem stáhnout mapové podklady a převést je do SQLite formátu. Odkaz: <http://robertdeveloper.blogspot.com/2009/08/rmaps.html>

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 9 Za nedostatky lze považovat málo kontrastní průhledná tlačítka k ovládání mapy a ne tak dobrou manipulaci se samotnou mapou. Úrovně přiblížení mapy jsou zde evidentní a lze jen přepínat mezi pevně danými hladinami. Také způsob práce s body zájmu není příliš uživatelky přívětivý, tato funkcionalita aplikace není ještě zcela dotažena. 2.4.4 MapDroyd Aplikace MapDroyd, dostupná zdarma na Google Play, umožňuje zobrazovat mapové podklady z projektu OSM. Aplikace se zaměřuje hlavně na offline prohlížení map, kde je možné si dopředu stáhnout mapové podklady vybrané oblasti. Netradičním prvkem této aplikace je vykreslování samotné mapy, to totiž probíhá vektorově místo toho, aby se používali předrenderované obrázky. Další funkce aplikace jsou otáčení mapy, kompas a zobrazení polohy uživatele. Hlavní výhodou aplikace je možnost zmíněného offline prohlížení, navíc díky vektorovému vykreslování je omezen i datový přenos a množství stažených dat. Výhodou je i to, že díky vektorovým datům tu prakticky neexistují úrovně přiblížení, jen se liší množství zobrazených informací. Toto vykreslování není ale tak přesné a nezobrazuje všechna dostupná data, která OSM poskytuje. Nevýhodou aplikace je to, že nepodporuje žádné funkce hledání na mapě a také málo kontrastní průhledná tlačítka k ovládání mapy. Mezi zajímavou funkcionalitu aplikace patří i takzvaný Rubberband mód ovládání, který je možné použít místo klasického ovládání. Obrázek 2.1: Ukázka Rubberband módu aplikace MapDroyd. Gesto pro přiblížení vlevo a gesto pro oddálení vpravo.

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 10 Rubberband mód Tento mód aplikace spočívá v alternativní manipulaci s mapou. Místo klasického posunu mapy způsobem drag-and-drop a multi-touch gesta pro přiblížení a oddálení jsou zde použita jen tři speciální gesta. První gesto realizované pohybem prstu směrem doprava dolů slouží k přiblížení mapy do výseku znázorňovaného červeným obdélníkem. Druhé gesto realizované pohybem prstu směrem doleva nahoru slouží k oddálení mapy tak, že současné viditelná oblast bude zmenšena do výseku znázorňovaného modrým obdélníkem. Třetí gesto realizované samotným kliknutím na mapu slouží k posunu středu obrazovky na vybrané místo. Snímky obrazovky aplikace MapDroyd v Rubberband módu jsou na obrázku 2.1 na straně 9. Oproti klasickému módu lze Rubberband mód pohodlně používat jen jednou rukou, není ovšem tak intuitivní a uživatel si na tento způsob manipulace s mapou musí zvyknout. Přibližování a oddalování mapy je v tomto módu velmi efektivní a rychlé, ale posun a jemnější změny přiblížení jsou zase pomalé. 2.5 Použité technologie Tato sekce popisuje technologie a projekty třetích stran, které jsou použity v rámci implementace výsledné aplikace. 2.5.1 OpenGL OpenGL (Open Graphics Library) je multi-platformní a multi-jazyčný standard definující specifikace aplikačního rozhraní pro psaní aplikací vytvářejících 2D a 3D počítačovou grafiku. Toto rozhraní obsahuje více jak 250 různých funkcí, díky kterým lze vytvářet komplexní tří-dimenzionální objekty z jednoduchých datových primitiv. OpenGL bylo vyvinuto společností Silicon Graphics Inc. v roce 1992 a v současné době je spravováno neziskovým technologickým konsorciem Khronos Group. OpenGL je velmi rozšířené grafické rozhraní a nachází bezpočet uplatnění. [18] OpenGL slouží hlavně ke dvěma účelům. Za prvé zakrýt složitosti různých grafických akcelerátorů za jednotné rozhraní. Za druhé skrýt rozdílné schopnosti hardwarových platforem tím, že všechny jeho implementace musí pokrýt veškeré OpenGL funkce (v případě nutnosti i za využití softwarové emulace). Aplikační rozhraní OpenGL je nízkoúrovňové a procedurální, takže vyžaduje aby programátor přesně definoval kroky nezbytné k vykreslení scény. Z tohoto důvodu je k použití OpenGL API nutná dobrá znalost grafického vykreslovacího řetězce, který je znázorněn na obrázku 2.2 na straně 11. OpenGL ES OpenGL ES (OpenGL for Embedded Systems) je podmnožina běžného OpenGL určená hlavně pro vestavěné systémy, jako jsou mobilní telefony a herní konzole. OpenGL ES je kvůli provozu na mobilních zařízeních optimalizované hlavně na nízkou spotřebu a malou paměťovou náročnost. Android OpenGL Platforma Android již od verze 1.0 podporuje akcelerované vykreslování grafiky pomocí OpenGL, konkrétně ve specifikaci OpenGL ES 1.0 a 1.1. Ve verzi Android 2.2 byla navíc přidána podpora i pro specifikaci OpenGL ES 2.0. Nutno ovšem

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 11 poznamenat, že API poskytované platformou Android je podobné specifikaci OpenGL ES, ale nikoliv zcela identické. Obrázek 2.2: Grafický vykreslovací řetězec OpenGL. [21] 2.5.2 PostgreSQL a PostGIS PostgreSQL je open source objektově-relační databázový systém, který je postaven na projektu POSTGRES z Berkeley Computer Science Department na University of California a v současnosti je vyvíjen skupinou PostgreSQL Global Development Group. PostgreSQL je velmi spolehlivý a výkonný databázový systém a v open source komunitě je velmi oblíben. PostgreSQL poskytuje mnoho sofistikovaných funkcí jako jsou indexy, triggery, dědičnost, replikace, Multi-Version Concurrency Control (MVCC) a mnoho dalších, také plně splňuje standardy ACID (atomicity, consistency, isolation, durability). PostgreSQL je navíc multiplatformní a má API pro řadu programovacích jazyků. [20] PostGIS je open source software, který přidává do databázového systému PostgreSQL podporu pro geografické objekty. Upravená databáze pak dodržuje standard Simple Features specifikující geografické objekty jako bod, čára, polygon, multi-plygon a podobně spolu s dalšími funkcemi nad těmito objekty. Takovou databázi pak lze například použít pro Geografická Informační Systém (GIS). 2.5.3 SQLite SQLite je volně dostupná softwarová knihovna implementující relační databázový systém. SQLite databáze není založena na principu klient-server, ale místo toho je celá uložena v jediném souboru. Tento soubor tak obsahuje veškerá data potřebná pro běh databáze včetně všech tabulek, indexů, triggerů a podobně. SQLite je multiplatformní a existuje mnoho API pro různé programovací jazyky, platformně nezávislé jsou i vlastní databázové soubory. Samotná SQLite knihovna je velmi malá (přibližně 300 KB) a má i minimální paměťové nároky na svůj provoz, často se tak používá v mobilních zařízeních.

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 12 2.5.4 Mapnik Mapnik je open source sada nástrojů sloužících k vyváření mapových aplikací. Mapnik umožňuje renderování rastrových obrázků z geografických dat, která jsou zpravidla ve vektorové podobě. Celá tato sada je napsaná v jazyce C++ a pro běžné softwarové problémy jako je správa paměti, přístup k souborovému systému, regulární výrazy, parsování a podobně využívá standardizované C++ knihovny z projektu boost.org. Navíc obsahuje i aplikační rozhraní pro jazyk Python. Mapnik je navržen jako multi-platformní se zaměřením primárně na vývoj webových aplikací, ale umožňuje i desktopové použití. Ke čtení různých datových zdrojů používá Mapnik architekturu založenou na rozšířeních, v současné době existují rozšíření pro čtení dat ve formátu ESRI shapefiles, PostGIS, TIFF raster, OSM XML, Kismet a OGR/GDAL. Hlavním cílem projektu Mapnik je vytváření hezky vypadajících map. [11] 2.5.5 Carto Carto je open source pre-procesor pro XML stylesheet soubory používané nástrojem Mapnik vyvíjený společností MapBox, jehož vývoj byl inspirován obdobným pre-procesorem Cascadenik. Vytvářené XML stylesheet soubory obsahují pravidla a další definice použité při renderovacím procesu, tyto soubory jsou často velmi velké a nejsou tak vhodné pro manuální editaci. Carto proto slouží k vytváření těchto souborů z jednodušších a přehlednějších šablon, které jsou podobné CSS používaných při tvorbě HTML stránek. 2.5.6 osm2pgsql osm2pgsql je open source nástroj sloužící ke konverzi geografických dat z projektu Open- StreetMap do formátu, který může být nahrán do PostgreSQL databáze s PostGIS rozšířením. Konverze geografických dat pomocí tohoto nástroje je ztrátová, neboť osm2pgsql konvertuje pouze data s určitými atributy, které jsou definovány v konfiguračním souboru. Nástroj osm2pgsql bývá často použit při vizualizaci OSM dat za využití nástroje Mapnik. 2.5.7 Node.js Node.js je softwarová platforma postavená na JavaScript Engine V8 navržená pro psaní škálovatelných aplikací a to zejména webových serverů. Programy pro Node.js jsou psány v JavaScriptu, kde lze využít standardní JavaScriptové funkce spolu s API, které poskytuje samotný Node.js. Node.js používá událostmi řízený model a neblokující I/O operace pro minimalizaci režie a maximalizaci výkonu. Je tak ideální pro datově náročné real-time aplikace běžící na distribuovaných zařízeních. Cílem této platformy je umožnit snadné vytvoření škálovatelných webových aplikací. [5][17] V8 JavaScript Engine V8 je open source interpreter JavaScriptu vyvíjený společností Google. V8 je napsán v jazyce C++ a může běžet buď samostatně nebo jako součást jiných C++ aplikací. Pro zvýšení výkonu V8 kompiluje před spuštěním JavaScript přímo do nativního strojového kódu, místo interpretování bytekódu. V současné době je V8 součástí webového prohlížeče Google Chrome.

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 13 Použité moduly do Node.js node-mapnik - modul sloužící k zpřístupnění aplikačního rozhraní mapového rendereru Mapnik v Node.js aplikacích node-sqlite3 - implementace asynchronního klienta pro SQLite3 databáze node-postgres - implementace asynchronního klienta pro PostgreSQL databáze využívající nativní knihovnu libpq node-pool - univerzální modul pro pooling zdrojů, lze jej použít k opakovanému použití nebo limitování počtu různých zdrojů, které jsou náročné na vytváření, jako jsou například databázová spojení xmlbuilder-js - nástroj pro dynamické vytváření textových souborů v XML formátu

Kapitola 3 Analýza a návrh řešení Tato kapitola obsahuje analýzu problému řešeného touto prací, návrh vhodného řešení, specifikaci funkčních a nefunkčních požadavků kladených na výslednou aplikaci a také popisuje zvolené implementační prostředí. 3.1 Formát mapových podkladů Samotná geografická data z projektu OpenStreetMap jsou ve vektorové podobě ve formě uzlů, cest a relací. Tento způsob je velmi efektivní pro ukládání a editaci dat, ale pro jejich vizualizaci již není tak vhodný. Často se tak pro přímou vizualizaci používají předrenderované rastrové dlaždice - tedy jednotlivé obrázky, ze kterých se mapa skládá. Obvyklá velikost jedné dlaždice je 256 256 pixelů. K vytváření takových dlaždic z vektorových dat slouží například renderovací nástroj Mapnik. Planeta Země má tvar rotačního hyperboloidu a pro specifikaci konkrétní polohy se používá polární souřadnicový systém daný zeměpisnou šířkou a zeměpisnou délkou (anglicky latitude a longitude). Tento systém využívá i OSM projekt k ukládání svých dat. Ovšem pokud chceme ze zakřiveného povrchu Země vytvořit jednu mapu v obdélníkové nebo čtvercové podobě, musí se použít vhodná projekce. V současnosti se nejčastěji používá Mercatorovo zobrazení, které promítá povrch Země na válec a výsledná mapa má pak čtvercový tvar. Nevýhodou této projekce je systematicky se zvyšující nepřesnost směrem od rovníku k pólům. Díky častému používání jsou ale uživatelé na tvar mapy v Mercatorově zobrazení zvyklí. Pro vykreslování mapy se v aplikaci používá právě Mercatorovo zobrazení. Jelikož je výsledná mapa Země čtvercová, používá se souřadnicový systém x, y a zoom (úroveň přiblížení), kde rozsah hodnot x a y je vždy od 0 do 2 zoom 1. Pro zoom = 0 mapa obsahuje pouze jednu dlaždici zobrazující celou Zemi, pro zoom = 1 má mapa 2 2 dlaždic, pro zoom = 2 má mapa 4 4 dlaždic a tak dále. Počet dlaždic, ze kterých se skládá celá mapa, tak roste exponenciální řadou. Souřadnice x = 0 a y = 0 vždy odpovídají levému hornímu rohu mapy. Tuto konvenci pro pojmenování dlaždic používá řada webových služeb poskytujících mapy včetně webového serveru projektu OSM. 14

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 15 3.2 Výběr úrovně Android API Úroveň Android API je přirozené číslo, které unikátně identifikuje programové rozhraní poskytované danou verzí platformy Android. Tato úroveň pak specifikuje balíčky, třídy, XML elementy, XML atributy a další zdroje, které může aplikace používat. Minimální, maximální a cílová úroveň API pro danou aplikaci se specifikuje v jejím Manifest souboru. Úrovně Android API mají tu výhodu, že jsou dopředně kompatibilní, veškeré změny jsou totiž aditivní nebo vylepšují stávající funkcionalitu. To znamená, že například aplikaci určenou pro úroveň API 8 (Android 2.2) je možné spustit na zařízení s Android 4.0 (úroveň API 14). Zpětná kompatibilita ovšem zaručena není. Rozložení používaných API úrovní v dubnu 2012 je znázorněno v grafu na obrázku 3.1 a v tabulce na obrázku 3.2 na straně 16. Z těchto dat je zřejmé, že úroveň API 8 (Android 2.2) pokrývá více jak 90% současně používaných zařízení a lze předpokládat další zvyšování tohoto podílu. Další výhodou použití úrovně 8 je větší stabilita a méně chyb ve vestavěném HTTP klientovi, jehož starší verze obsahují známé chyby [3]. Z těchto důvodů byla pro implementaci výsledné aplikace zvolena úroveň API 8. 3.3 Výběr prostředí pro běh serveru Jedním z cílů této práce je navrhnout a implementovat serverovou část aplikace a to za maximálního využití již existujících nástrojů. Důraz je také kladen na rychlou implementaci zvoleného řešení. V celém kontextu serverová aplikace slouží spíše jako prototyp či takzvaný proof-of-concept, který má hlavně za cíl nastínit cestu dalšího vývoje. Klíčovou funkcí serverové aplikace je renderování rastrových map, za tímto účelem se jeví nejlepší použít open source nástroje Mapnik. Výhodou Mapniku je to, že byl navržen na rychlé renderování a je vhodný pro nasazení na webových serverech. Alternativou k tomuto nástroji může být Osmarender, který dokáže renderovat mapy do SVG obrázků z dat ve formátu OSM XML. Ten ovšem není tak rozšířen jako Mapnik a jeho vývoj byl navíc ukončen v dubnu 2012 [13]. Vlastní běhové prostředí by mělo být škálovatelné s nízkými nároky na režii a mělo by umožnit rychlé nasazení na server. Tyto předpoklady zcela splňuje prostředí Node.js, jehož velkou výhodou je existence celé řady volně dostupných modulů a rozšíření. Mezi ně patří například modul node-mapnik zpřístupňující Mapnikovské API. Při vlastní implementaci serveru tak bude možné maximálně využít již existujících řešení. 3.4 Návrh řešení Celá aplikace se skládá ze dvou základních částí, které ale mohou existovat i samostatně. První a hlavní částí je klientská strana aplikace sloužící primárně k zobrazování mapových podkladů, tato část zároveň obsahuje uživatelské rozhraní zpřístupňující veškerou funkcionalitu celé aplikace. Druhou částí je podpůrná serverová aplikace, sloužící k renderování různých mapových podkladů a k hledání bodů zájmu. Komunikace mezi klientskou a serverovou stranou aplikace probíhá přes síťový protokol HTTP. Serverová aplikace neposkytuje žádné grafické uživatelské rozhraní.

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 16 Obrázek 3.1: Rozdělení Android verzí v dubnu 2012. [9] Verze platformy Kódové jméno API úroveň Podíl Android 1.5 Cupcake 3 0,3% Android 1.6 Donut 4 0,7% Android 2.1 Eclair 7 6,0% Android 2.2 Froyo 8 23,1% Android 2.3-2.3.2 Gingerbread 9 0,5% Android 2.3.3-2.3.7 Gingerbread 10 63,2% Android 3.0 Honeycomb 11 0,1% Android 3.1 Honeycomb 12 1,0% Android 3.2 Honeycomb 13 2,2% Android 4.0-4.0.2 Ice Cream Sandwich 14 0,5% Android 4.0.3 Ice Cream Sandwich 15 2,4% Obrázek 3.2: Používané verze Android platformy v dubnu 2012. [9]

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 17 3.4.1 Klientská aplikace Klientská aplikace je určená pro mobilní operační systém Android a skládá se z několika částí, které spolu vytváří jednu aplikaci. Nejdůležitější částí je vlastní vykreslování mapových podkladů, které využívá akcelerované grafické prostředí OpenGL. Díky použití této grafické knihovny by vykreslování map mělo být rychlé, efektivní a v dobré kvalitě. Další důležitou součástí aplikace je komponenta poskytující mapové podklady v rastrové podobě a to buď z SQLite databáze uložené na zařízení nebo z dostupných webových serverů. Modularita těchto komponent umožňuje jejich jednoduchou zaměnitelnost. Další část aplikace je komponenta sloužící k síťové komunikaci se serverovou aplikací a jinými webovými službami například pro stahování mapových dat a informacích o bodech zájmu. Všechny tyto komponenty zastřešuje grafické uživatelské rozhraní aplikace, které je rozděleno do několika Aktivit. Diagram hlavních komponentů klientské aplikace je na obrázku 3.3 na straně 18. Pro vykreslování mapy by se dal použít i alternativní způsob zobrazování grafiky, který platforma Android také podporuje, a tím je takzvaný Canvas. Ten má jednodušší a abstraktnější API než OpenGL, ale není zase tak efektivní a flexibilní. Velkou nevýhodou je také to, že podporuje pouze 2D grafiku, zatímco OpenGL má plnou podporu pro 3D grafiku. Při implementaci aplikace tak byla zvolena knihovna OpenGL a to hlavně z výkonnostních důvodů. 3.4.2 Serverová aplikace Serverová část aplikace běží na platformě Node.js jako HTTP sever. Pro renderování rastrových obrázků z geografických dat pak používá nástroj Mapnik za využití modulu node-mapnik. Při samotnému procesu renderování je použit stylesheet v XML formátu, definující vzhled výsledné mapy. Server umožňuje výběr z více možných stylů vzhledu mapy právě díky použití různých stylesheet souborů. Geografická data, která server při renderování používá, jsou uložena v PostGIS databázi a jejich zdrojem je projekt OpenStreetMap. K importu geografických dat od databáze se využívá nástroje osm2pgsql a vlastních dat ve formě Planet.osm souboru. Pro generování mapových souborů v SQLite formátu server využívá modul node-sqlite3 a pro vytváření XML souborů využívá modul xmlbuilder-js. Diagram komponentů serverové aplikace je na obrázku 3.4 na straně 18. Planet.osm Geografická data z projektu OpenStreetMap jsou k dispozici mnoha způsoby, jedním z nich je právě takzvaný Planet.osm soubor. Ten obsahuje veškerá dostupná data pro celou zemi, tedy všechny uzly, cesty a relace tvořící mapu. Z pochopitelných důvodů je to velmi velký soubor, přibližně 16 GB v komprimované podobě a přes 250 GB bez komprese. Nová verze tohoto souboru je vydávána pravidelně každý týden a existuje řada serverů, ze kterých se dá stáhnout. Navíc existují i takzvané diff soubory, obsahující pouze změny, které jsou obvykle vydávané v jednodenních intervalech. Tyto soubory jsou již menší (řádově desítky MB) a slouží například k aktualizacím databází a podobně. Existují také takzvané extrakty obsahující data pouze pro jednotlivé kontinenty, státy, metropole a podobně. Pro soubory Planet.osm se používají dva hlavní formáty, starší verzí je komprimovaný OSM XML formát a novější více efektivnější formát PBF (Protocolbuffer Binary Format).

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 18 Android Graphical User Interface Controller OpenGL renderer «use» HTTP request HTTP client «use» Map data source «datastore» SQLite Database client «use» Obrázek 3.3: Diagram komponentů klientské aplikace Node.js HTTP request HTTP server «use» node-mapnik Mapnik «use» «use» «datastore» SQLite node-sqlite3 node-postgres «datastore» PostGIS Obrázek 3.4: Diagram komponentů serverové aplikace

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 19 3.5 Analýza funkčních a nefunkčních požadavků Z požadavků kladených na výslednou aplikaci specifikovaných v předchozí kapitole a návrhu vhodného řešení vyplývají následující funkční a nefunkční požadavky. Ty jsou dále rozděleny na části týkající se klientské a serverové strany aplikace. Funkční požadavky klientské aplikace Zobrazování mapových podkladů offline ze souborů na SD kartě. Zobrazování mapových podkladů online za využití webových služeb. Přepínaní mezi více mapovými podklady. Správa mapových podkladů tj. přidávat, mazat, editovat a vyhledávat v nich. Hledání bodů zájmu online s využitím webových služeb. Zobrazování bodů zájmu na mapě. Výběr oblasti na mapě dané krajními souřadnicemi a úrovněmi přiblížení. Odeslání žádosti o vyrenderování zvolené oblasti serverové části aplikace. Stažení dříve vyrenderovné oblasti ze serverové části aplikace. Správa stahování mapových podkladů tj. vytvářet, mazat, editovat a vyhledávat v nich. Nefunkční požadavky klientské aplikace Aplikace bude implementována pro mobilní operační systém Android ve verzi 2.2, úroveň API 8. Aplikace by měla využívat vnitřní paměť (cache) pro rastrové obrázky k urychlení načítání. K vykreslování mapy bude použito graficky akcelerovaného prostředí OpenGL ES 1.0. Při prohlížení online bude použita záložní databáze rastrových obrázků na SD kartě k minimalizaci datových přenosů. Funkční požadavky serveru Renderování jednotlivých rastrových obrázků pro zvolené souřadnice, úroveň přiblížení a styl mapy. Příjem žádosti o vyrenderování zvolené oblasti dané krajními souřadnicemi, úrovněmi přiblížení a stylem mapy. Možnost stažení dříve vyrenderovné oblasti. Hledání bodů zájmu ve zvolené oblasti podle jména nebo podle zvolených souřadnic. Poskytnutí informací o API serveru a dostupných stylech.

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ 20 Nefunkční požadavky serveru Serverová aplikace bude implementována pro běh na Node.js a bude využívat nástroje Mapnik pro renderování map. Serverová aplikace by měla maximálně využít existující nástroje. API serveru bude využívat HTTP dotazy a XML formát pro posílání zpráv. Server by měl umožňovat volbu mezi různými styly renderování mapy. 3.6 Použité vývojové prostředí Pro vývoj a implementaci aplikace bylo použito vývojové prostředí Eclipse IDE ve verzi 3.7.2 spolu s rozšířením ADT Plugin for Eclipse. Při implementaci Android aplikace byla použita sada nástrojů z Android SDK. K verzování zdrojového kódu byl použit distribuovaný verzovací systém Mercurial. Pro tvorby diagramů byl použit program Enterprise Architect s akademickou licencí a tento text byl vysázen pomocí programu L A TEX. Související odkazy: Eclipse IDE <http://www.eclipse.org/> Android SDK <http://developer.android.com/sdk/index.html> ADT Plugin for Eclipse <http://developer.android.com/sdk/eclipse-adt.html> Mercurial <http://mercurial.selenic.com/> Enterprise Architect <http://www.sparxsystems.com.au/> L A TEX <http://www.latex-project.org/>

Kapitola 4 Realizace Tato kapitola ze zabývá podrobnějším popisem implementace výsledné aplikace a vlastním procesem realizace celé této práce. První část se zabývá použitými mapovými podklady a další části obsahují popis implementace klientské a serverové strany aplikace. Poděkování Během procesu realizace této práce významně pomohly návody a ukázkové příklady pro práci s grafickou knihovnou OpenGL [2][21][1], vývojářská příručka pro platformu Android [10] a při řešení mnoha problémů se ukázal velmi užitečný komunitní server Stack Overflow [22]. 4.1 Schéma mapové databáze Hlavním zdrojem mapových podkladů, který klientská aplikace používá, je databáze v SQLite formátu. V této databázi jsou uloženy již vyrenderované mapové dlaždice spolu se svými souřadnicemi x, y a zoom. V současné implementaci klientské aplikace jsou podporovány SQLite mapové databáze v RMaps formátu (používaný aplikací RMaps), který je podobný standardu používaném webovými službami OSM, jenom se liší v reprezentaci úrovně přiblížení. V tomto formátu je úroveň přiblížení reprezentována obráceně, například zoom úroveň 0 odpovídá úrovni 18 v OSM formátu. Pro konverzi zoom úrovní se dá použít následující funkce. Tato konverze je symetrická, lze jí tak použít pro konverzi oběma směry. convertzoom(zoom) = 17 zoom Databázové schéma takovéto mapové databáze je znázorněno na obrázku 4.1 na straně 22. V tomto schématu stojí za zmínku tabulka info, která obsahuje minimální a maximální zoom úroveň dostupnou v příslušné databázi. Tento formát byl zvolen z důvodu možného využití mapových podkladů používaných aplikací RMaps, které lze například vytvořit open source nástrojem MOBAC. Databázové soubory poskytované serverovou aplikací také dodržují RMaps SQLite formát v rámci zachování kompatibility s klientskou stranou aplikace. 21

KAPITOLA 4. REALIZACE 22 tiles «column» *PK x *PK y *PK z image info «column» minzoom maxzoom «PK» + PK_tiles(,, ) Obrázek 4.1: Schéma mapové databáze v SQLite formátu 4.2 Implementace klientské aplikace Klientská aplikace je navržena pro běh na mobilním operačním systému Android a vlastní implementace aplikace je tak realizována z největší části v programovacím jazyku Java. Celá aplikace byla implementována v souladu se zvyklostmi a zásadami pro programování pro platformu Android. Pro práci s mapami je v aplikaci použit koncept uživatelských map (user map), které reprezentují jednotlivé mapové podklady a to jak ty dostupné offline (SQLite databázové soubory na SD kartě), tak i ty dostupné online. K prohlížení mapových podkladů tak musí uživatel do aplikace tyto uživatelské mapy importovat. Na podobném principu je založeno i stahování mapových podkladů ze serverové části aplikace, zde jsou použity žádosti o vytvoření mapy (map download request). 4.2.1 Rozdělení aplikace do Aktivit Nezbytnou součástí každé Android aplikace jsou Aktivity, které představují jednotlivé obrazovky aplikace. Klientská aplikace se tak skládá z několika Android Aktivit, ty lze rozdělit do čtyř hlavních skupin. V první skupině je Aktivita obsluhující hlavní menu aplikace a Aktivita Preferencí obsahující nastavení aplikace, druhou skupinou jsou Aktivity sloužící ke správě uživatelských map a žádostí o vytvoření mapy, třetí skupina slouží ke stahování mapových dat z online služeb, poslední a nejdůležitější skupinou jsou Aktivity sloužící k prohlížení mapových podkladů. Na obrázku 4.2 na straně 23 jsou znázorněné závislosti jednotlivých Aktivit a v následujícím seznamu je detailnější popis všech Aktivit, které jsou součástí klientské aplikace. MainActivity - obsluhuje hlavní menu aplikace a slouží také jako vstupní bod pro celou aplikaci MainPreferences - obsahuje různá uživatelská nastavení aplikace ManageMapsActivity - slouží ke správě uživatelských map uložených v aplikaci, tj. vytváření, prohlížení, editace a mazání UserMapImportActivity - se stará o import nových uživatelských map z online nebo offline zdrojů

KAPITOLA 4. REALIZACE 23 UserMapEditActivity - umožňuje editaci dříve vytvořených uživatelských map ManageDownloadsActivity - slouží ke správě žádostí o vytvoření mapy uložených v aplikaci, tj. vytváření, prohlížení, editace a mazání MapDownloadInfoActivity - umožňuje prohlížení a editaci dříve vytvořených žádostí o vytvoření mapy DownloadRequestActivity - umožňuje vytvoření a odeslání nové žádostí o vytvoření mapy serverové aplikaci SearchActivity - slouží k hledání bodů zájmu podle jména nebo souřadnic pomocí dostupných online služeb MapViewActivity - je hlavní Aktivita aplikace sloužící k prohlížení mapových podkladů uložených v aplikaci ve formě uživatelských map, dále také umožňuje i hledání bodů zájmu na mapě MapViewBBoxActivity - slouží k zobrazování mapových podkladů s vybraným stylem poskytovaných serverovou částí aplikace, dále umožňuje výběr oblasti na mapě pro odeslání žádostí o její vytvoření MainPreferences MapViewActivity SearchActivity MainActivity ManageMapsActivity UserMapEditActivity ManageDownloadsActivity MapDownloadInfoActivity UserMapImportActivity MapViewBBoxActivity DownloadRequestActivity Obrázek 4.2: Závislosti jednotlivých Aktivit klientské aplikace 4.2.2 Aplikační databáze Platforma Android umožňuje každé aplikaci mít několik vlastních databází, které jsou pak uložené v zařízení jako SQLite databázové soubory. K dlouhodobému ukládání uživatelských map a žádostí o vytvoření mapy tak klientská aplikace používá vnitřní databázi. Schéma této databáze je znázorněno na obrázku 4.3 na straně 24.

KAPITOLA 4. REALIZACE 24 services usermaps locations mapdownloads «column» *PK _id * name * protocol * host * port * pattern «PK» + PK_services() +online_sevice 0..1 * «column» *PK _id * name * dbpath * dbmodtime * online online_sevice * minzoom * maxzoom * location desc +location * 1 «column» *PK _id * x * y * zoom * dx * dy «PK» + PK_locations() «column» *PK _id * name * key * style * url desc «PK» + PK_mapdownloads() «PK» + PK_usermaps() Obrázek 4.3: Schéma databáze, kterou používá klientská aplikace 4.2.3 Vykreslování pomocí OpenGL K zobrazování mapových podkladů ve formě rastrových dlaždic je v klientské aplikaci použita grafická knihovna OpenGL ES ve verzi 1.0. Tato knihovna poskytuje procedurální nízkoúrovňové API a pro vykreslování je nutné přesně specifikovat celou scénu. OpenGL při vykreslování používá pravotočivý kartézský souřadnicový systém se souřadnicemi x,y,z a pro reprezentaci barev je použit čtyř-prvkový model RGBA (Red, Green, Blue, Alpha). Pro vykreslování textur je použito UV mapování, což je proces mapování 2D textur na 3D objekty. Dále se používají takzvané transformační matice, kterými se násobí příslušné vektory ve scéně než jsou následně vykresleny, existují čtyři druhy GL_MODELVIEW, GL_PROJECTION, GL_TEXTURE, a GL_COLOR. Hlavními jsou matice GL_MODELVIEW, která slouží k různým lineárním transformacím objektů ve scéně (například posuny, rotace, změny měřítka a podobně), a matice GL_PROJECTION, která slouží k projekci celé vykreslované scény na 2D display zařízení. Při implementaci Android aplikací využívajících OpenGL se používají hlavně třídy GLSurfaceView a GLSurfaceView.Renderer, které poskytují základní vykreslovací API. Teoretické řešení Jak již bylo zmíněno, celá mapa se skládá ze čtvercových rastrových dlaždic, jejichž počet závisí na úrovni přiblížení. Pro vykreslování těchto dlaždic je použita dvou-dimenzionální mřížka, která je tvořena vrcholy jednotlivých dlaždic. Samotné rastrové obrázky jsou pak použity jako textury vyplňující tuto mřížku. V souřadnicovém systému OpenGL je mřížka umístěna ve čtvrtém kvadrantu s tím, že levý horní roh dlaždice [0, 0] je umístěn v počátku. Ilustrace této mřížky je na obrázku 4.4 na straně 25. Na obrázku je také znázorněná reprezentace aktuální polohy displeje jako vektor od počátku do středu obrazovky. Tímto způsobem je mapová mřížka reprezentována jednotlivými body v prostoru, které tak mají pevně danou pozici. Kvůli tomu je posun a změna měřítka mapy realizována výhradně jen úpravami projekční matice GL_PROJECTION. To si lze představit jako změnu pozice kamery ve scéně. Počátek souřadnicového systému je po této projekci vždy ve středu obrazovky. Při procesu vykreslování scény se pak vypočítá jaké konkrétní mapové dlaždice jsou aktuálně viditelné v závislosti na poloze displeje a jen ty jsou následně vykresleny.

KAPITOLA 4. REALIZACE Sheet1 25 -x y Obrázek 4.4: Ilustrace mřížky pro vykreslování mapových dlaždic se znázorněním reprezentace pozice displeje Praktická realizace Výše zmíněný přístup má však z hlediska praktické implementace podstatný nedostatek. Android OpenGL API totiž poskytuje pouze single-precision formát pohyblivé řádové čárky pro vektory a operace s transformačními maticemi, což může způsobit nepřesnosti při vykreslování. Důvodem je to, že například pro úroveň přiblížení 18 je výška a šířka mapy 2 18 dlaždic a pokud budou rozměry dlaždice 256 256 pixelů je výsledná výška a šířka mapové mřížky je 256 2 18 pixelů. To ovšem přesahuje přesnost single-precision formátu, takže není možné takové hodnoty reprezentovat bezeztrátově a se zvyšující se úrovní přiblížení nepřesnost ještě více narůstá. Tento problém je v implementaci klientské aplikace vyřešen, tím že byl do zmíněného konceptu přidán navíc vektorový offset. Ten zajišťuje, že souřadnice bodů tvořící mapovou mřížku právě vkreslovaných dlaždic budou mít hodnoty dostatečně malé pro zaručení bezeztrátové přesnosti. Offset se mění dynamicky dle potřeby tak, aby jeho vzdálenost od aktuální pozice středu obrazovky zůstala v dané toleranci. Tím je zaručena přesnost vykreslování prakticky pro libovolnou úroveň přiblížení a pozici displeje. Nevýhodou tohoto přístupu je o něco vyšší režie při vlastním procesu vykreslování a hlavně nedeterministická poloha bodů tvořících mapovou mřížku pro části aplikace, které nemají k aktuálnímu vektorovému offsetu přístup. Proto není možné použít dodatečné komponenty k vykreslování například bodů zájmu nad mapou, které by byly nezávislé na komponentě sloužící k vykreslování samotné mapy. Za tímto účelem tak komponenta pro vykreslování mapy umožňuje registraci dodatečných MapOverlay, které pak pravidelně dostávají informace o aktuální poloze vykreslované mapy. Tímto způsobem je možné pohodlně přidávat další vykreslovací komponenty bez nutnosti modifikace stávající implementace. Page 1