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 OpenStreetMap . . . . . . 1.1.1 Formát dat . . . . 1.2 Android . . . . . . . . . . 1.2.1 Historie . . . . . . 1.2.2 Architektura . . . 1.2.3 Vývoj pro Android

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

1 1 1 2 2 2 3

2 Popis problému, specifikace cíle 2.1 Popis problému . . . . . . . . . . . . . . . 2.2 Specifikace cíle . . . . . . . . . . . . . . . 2.3 Kontext použití a cílová skupina uživatelů 2.4 Popis existujících aplikací . . . . . . . . . 2.4.1 Google Maps . . . . . . . . . . . . 2.4.2 Mapy.cz . . . . . . . . . . . . . . . 2.4.3 RMaps . . . . . . . . . . . . . . . . 2.4.4 MapDroyd . . . . . . . . . . . . . 2.5 Použité technologie . . . . . . . . . . . . . 2.5.1 OpenGL . . . . . . . . . . . . . . . 2.5.2 PostgreSQL a PostGIS . . . . . . . 2.5.3 SQLite . . . . . . . . . . . . . . . . 2.5.4 Mapnik . . . . . . . . . . . . . . . 2.5.5 Carto . . . . . . . . . . . . . . . . 2.5.6 osm2pgsql . . . . . . . . . . . . . . 2.5.7 Node.js . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

6 6 6 7 7 7 8 8 9 10 10 11 11 12 12 12 12

. . . . . . . .

14 14 15 15 15 17 17 19 20

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3 Analýza a návrh řešení 3.1 Formát mapových podkladů . . . . . . . . . 3.2 Výběr úrovně Android API . . . . . . . . . 3.3 Výběr prostředí pro běh serveru . . . . . . . 3.4 Návrh řešení . . . . . . . . . . . . . . . . . 3.4.1 Klientská aplikace . . . . . . . . . . 3.4.2 Serverová aplikace . . . . . . . . . . 3.5 Analýza funkčních a nefunkčních požadavků 3.6 Použité vývojové prostředí . . . . . . . . . .

vii

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

OBSAH

viii

4 Realizace 4.1 Schéma mapové databáze . . . . . . . . . 4.2 Implementace klientské aplikace . . . . . . 4.2.1 Rozdělení aplikace do Aktivit . . . 4.2.2 Aplikační databáze . . . . . . . . . 4.2.3 Vykreslování pomocí OpenGL . . . 4.2.4 Využívání mapových zdrojů . . . . 4.2.5 Proces vykreslování mapy . . . . . 4.2.6 Hledání bodů zájmu . . . . . . . . 4.2.7 Žádosti o vytvoření mapy . . . . . 4.2.8 Konfigurace online služeb . . . . . 4.2.9 Popis Java balíčků . . . . . . . . . 4.3 Implementace serverové aplikace . . . . . 4.3.1 Databáze . . . . . . . . . . . . . . 4.3.2 Žádosti o vytvoření mapy . . . . . 4.3.3 Styly vzhledu renderovaných map . 4.3.4 Aktuální nedostatky . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

21 21 22 22 23 24 26 27 27 27 29 29 30 30 31 31 32

5 Testování 5.1 Testovací prostředí . . . . . . 5.2 Testování funkcionality . . . . 5.3 Uživatelské testování . . . . . 5.3.1 Průběh testů . . . . . 5.3.2 Výsledky testů . . . . 5.4 Výsledky externího testování

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

33 33 33 33 34 34 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 1.2

Android architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Životní cyklus Android Aktivity . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 2.2

Rubberband mód . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Vykreslovací řetězec OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 3.2 3.3 3.4

Rozdělení Android verzí . . . . . . . . . Verze Android platformy . . . . . . . . . Diagram komponentů klientské aplikace Diagram komponentů serverové aplikace

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

16 16 18 18

4.1 4.2 4.3 4.4 4.5 4.6 4.7

Schéma mapové databáze v SQLite formátu . . . . . . Závislosti jednotlivých Aktivit klientské aplikace . . . Schéma databáze, kterou používá klientská aplikace . Mřížka pro vykreslování mapových dlaždic . . . . . . . Diagram znázorňující proces vykreslování mapy . . . . Schéma pomocné databáze serverové aplikace . . . . . Snímek obrazovky pro editaci stylů programu TileMill

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

22 23 24 25 28 30 32

ix

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3 5

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ě =.

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 AndroidManifest.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 WYSIWYG4 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

Obrázek 1.2: Stavový diagram životního cyklu Android Aktivity. [10]

5

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

2.3

7

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 usability1 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


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átu2 . 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:


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.


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


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.


2.5.4

12

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 OpenStreetMap 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.


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 2zoom −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Í

3.2

15

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í.


16

Obrázek 3.1: Rozdělení Android verzí v dubnu 2012. [9]

Verze platformy Android 1.5 Android 1.6 Android 2.1 Android 2.2 Android 2.3 - 2.3.2 Android 2.3.3 - 2.3.7 Android 3.0 Android 3.1 Android 3.2 Android 4.0 - 4.0.2 Android 4.0.3

Kódové jméno Cupcake Donut Eclair Froyo Gingerbread Gingerbread Honeycomb Honeycomb Honeycomb Ice Cream Sandwich Ice Cream Sandwich

API úroveň 3 4 7 8 9 10 11 12 13 14 15

Podíl 0,3% 0,7% 6,0% 23,1% 0,5% 63,2% 0,1% 1,0% 2,2% 0,5% 2,4%

Obrázek 3.2: Používané verze Android platformy v dubnu 2012. [9]


3.4.1

17

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).


18

Android

Graphical User Interface

Controller

OpenGL renderer

«use»

«use»

HTTP client

HTTP request

«datastore» SQLite

Database client

Map data source

«use»

Obrázek 3.3: Diagram komponentů klientské aplikace

Node.js

HTTP request

HTTP server

«use»

«datastore» SQLite

«use»

Mapnik node-mapnik

«use»

«datastore» PostGIS node-sqlite3

node-postgres

Obrázek 3.4: Diagram komponentů serverové aplikace


3.5

19

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.


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 LATEX. Související odkazy: Eclipse IDE Android SDK ADT Plugin for Eclipse Mercurial Enterprise Architect LATEX

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ů


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.


services «column» *PK _id * name * protocol * host * port * pattern «PK» + PK_services()

24

usermaps «column» *PK _id * name dbpath +online_sevice * * dbmodtime 0..1 * * online online_sevice * minzoom * maxzoom * location desc

locations

+location *

1

mapdownloads

«column» *PK _id * x * y * zoom * dx * dy

«column» *PK _id * name * key * style * url desc

«PK» + PK_locations()

«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.

Sheet1


25

y -x

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 218 dlaždic a pokud budou rozměry dlaždice 256 × 256 pixelů je výsledná výška a šířka mapové mřížky je 256 · 218 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


26

Práce s vektory a texturami Při vykreslování každého snímku je potřeba pomocí OpenGL API specifikovat pozice všech bodů ve scéně, všechny tyto informace se tak musí přenést do paměti grafického akcelerátoru. K procesu přenosu informací lze použít nativních bufferů z Java NIO, jejich hlavní výhodou jsou řádově rychlejší I/O operace za cenu náročnější alokace a dealokace v paměti. Tato nevýhoda je v implementaci klientské aplikace vyřešena takzvaným poolingem zdrojů. Pooling je technika spočívající v znovu použití různých zdrojů, které jsou náročné na vytvoření. Princip je ten, že se tento zdroj nejdříve z poolu vypůjčí a poté co už není využíván, tak se do něj vrátí zpět. Tímto způsobem se zamezí časté alokaci a dealokaci používaných nativních bufferů a vykreslování by tak mělo být mnohem efektivnější. Nezbytnou součástí vykreslování mapových podkladů je práce s rastrovými obrázky, tj. texturami vyplňujícími mapovou mřížku. OpenGL API poskytuje nástroj pro konverzi bitmap do OpenGL reprezentace textur, při procesu vykreslování se pak používá unikátní textureId asociované s danou texturou. Všechny takto konvertované textury jsou však drženy v paměti, dokud nejsou manuálně uvolněny, což může vést k vyčerpání dostupné paměti. V implementaci klientské aplikace je tak použita fronta, do které jsou asynchronně vloženy již nepoužívané textury, a ve vykreslovacím procesu jsou pak textury obsažené v této frontě pravidelně uvolňovány. V paměti jsou tak drženy jen aktuálně nezbytné textury. Nevýhodou použití takovéto fronty je nenulová pravděpodobnost, že bude uvolněna právě používaná textura, což může způsobit nedefinované chování. To může nastat v situaci, kdy se změní OpenGL EGL kontext (například při vytření nového GLSurfaceView), což způsobí automatické uvolnění všech OpenGL zdrojů a je tak nutné vytvořit všechny zdroje znovu. V této situaci je zmíněná fronta také vyprázdněna, ale protože jsou do ní textury vkládány asynchronně existuje možnost, že při dalším vykreslovacím cyklu bude ve frontě nějaké textureId asociované s již neexistující texturou. Pokud se toto staré textureId bude shodovat s nějakým nově vytvořeným textureId, dojde ke smazání nesprávné textury. I když je pravděpodobnost výskytu takové události velmi malá, tak v současné implementaci není zcela vyloučená.

4.2.4

Využívání mapových zdrojů

Další podstatnou částí klientské aplikace je poskytování mapových dat a to hlavně rastrových dlaždic. Zdrojem těchto dat může být SQLite databáze nebo některé webové služby, ale z pohledu vykreslování není mezi těmito zdroji žádný rozdíl. Pro poskytování mapových dlaždic slouží abstraktní implementace rozhraní TileProvider, která se stará o základní manipulaci s dlaždicemi. Tato implementace obsahuje vnitřní LRU cache1 se Soft referencemi2 sloužící k ukládání poskytovaných dlaždic a tím urychluje přístup k nedávno použitým dlaždicím. Díky použití Soft referencí není tato cache v případě nedostatku paměti nadbytečnou zátěží. Další třídy, které dědí od této abstraktní třídy, musí poskytnout pouze implementaci metody pro získání rastrové dlaždice z konkrétního zdroje. V současné době klientská aplikace obsahuje implementaci pro poskytování rastrových dlaždic z SQLite databáze nebo z online služeb. Při používání online služeb je navíc vytvořena nová SQLite databáze na SD kartě, kam jsou ukládány již stažené dlaždice. Před 1 2

LRU (Least Recently Used) cache vyřazuje nejméně používané prvky jako první. Java SoftReference je druh slabých referencí, které jsou smazány v případě nedostatku paměti.


27

každým stažením se pak kontroluje tato záložní databáze, jestli neobsahuje požadované dlaždice, a tím se minimalizuje datový přenos. Implementace stahování dlaždic z online služeb navíc dodržuje OSM Tile usage policy, ta mimo jiné limituje maximální počet stahovacích vláken na dvě [14]. Pro mapové podklady dostupné z online služeb se v současné implementaci předpokládá dodržení standardu, který je používaný službami z projektu OSM. Poskytované dlaždice jsou přímo ve formě konkrétních objektů používaných pro samotné vykreslování mapy. K tomu je použit návrhový vzor Abstract factory. Před začátkem vykreslování je tak nutné specifikovat konkrétní implementaci, která bude sloužit k vytváření potřebných objektů z rastrových dlaždic. Tímto způsobem jsou od sebe navzájem odděleny části pro vykreslování mapy a části sloužící k poskytování dlaždic, což umožňuje velkou modularitu celé klientské aplikace.

4.2.5

Proces vykreslování mapy

Na obrázku 4.5 na straně 28 jsou znázorněny hlavní části procesu vykreslování mapy včetně části zabývající se poskytováním mapových dlaždic z různých zdrojů. Celý tento proces je řízen asynchronními událostmi (v diagramu zelené segmenty), kde za počáteční impuls lze považovat žádost o aktualizaci mapy (Reload request). Tato událost nastane vždy, když se změní poloha či úroveň přiblížení zobrazované mapy. Pro zjednodušení není v diagramu znázorněno ošetření různých chybových stavů a další drobnosti.

4.2.6

Hledání bodů zájmu

Mezi další funkcionalitu klientské aplikace patří hledání bodů zájmu (POI) a to buď podle jména či adresy a nebo podle konkrétních souřadnic daných zeměpisnou šířkou a zeměpisnou délkou. Způsob vytváření adresy ze souřadnic nebo OSM bodů se nazývá reverse geocoding. Současná implementace podporuje hledání bodů zájmu z dostupných online služeb nebo pomocí serverové čísti aplikace. Hledání bodů zájmu je navíc možné omezit jen na viditelnou část mapy. Jako externí službu pro hledání bodů zájmu klientská aplikace používá Nominatim Search Service z projektu MapQuest, která poskytuje neomezované API dostupné zdarma3 . Ke komunikaci s touto službou se používají HTTP dotazy a XML souborový formát pro přenos informací.

4.2.7

Žádosti o vytvoření mapy

Klientská aplikace také umožňuje odeslat žádost o vytvoření mapy serverové části aplikace a následně umožňuje i její stažení. Proces odeslání žádosti je rozdělen do dvou kroků, za prvé specifikace obdélníkové oblasti na mapě, za druhé výběr maximální úrovně přiblížení a odeslání této žádosti. Aby měl uživatel nějakou představu o velikosti výsledné mapy, tak je před odesláním žádosti vypočten přibližný počet rastrových dlaždic obsažených v mapové databázi spolu s velikostí celého výsledného souboru. Vlastní stahování mapových souborů není v klientské aplikaci implementováno přímo, ale je za tímto účelem využit externí webový prohlížeč daného Android zařízení. 3

Více informací o Nominatim Search Service API na:


28

Map renderer

Tile provider

External event

Reload request

Tile request

New tile loaded

[yes]

Clear tile rendering list

[no]

In cache?

Add tile to rendering list

Load tile Compute visible tiles

Render request Return tile

Return NULL

«loop» For each tile

Tile request

[yes] Available?

Render request

[no] Load tile Use "loading" tile

Set projection, offset and scale

Load bitmap image form resource Take all tiles form rendering list

Add tile to rendering list «loop» For each tile

Create tile form bitmap

Tile rendering Render request

New tile loaded

Obrázek 4.5: Diagram znázorňující proces vykreslování mapy


4.2.8

29

Konfigurace online služeb

Všechny online služby, které klientská aplikace může používat, musí být specifikovány v konfiguračním XML souboru umístěném v res/raw/map_services.xml. Tento soubor obsahuje informace nutné pro spojení s webovými službami poskytujícími rastrové dlaždice a se službami pro hledání bodů zájmu. Ke stejnému účelu slouží i konfigurační soubor pro serverovou část aplikace, umístěný v res/raw/download_server.xml. Za běhu klientské aplikace jsou pak tyto soubory parsovány.

4.2.9

Popis Java balíčků

Kořenovým Java balíčkem klientské aplikace je balíček net.extbrain.android.app.maps, ten obsahuje Android Aktivity, ze kterých se skládá výsledná aplikace. Další Java třídy jsou rozděleny do několika pod-balíčků, následuje jejich stručný popis. Pod-balíčky v net.extbrain.android.app.maps: • database - obsahuje nástroje pro přístup do aplikační databáze a do databází s mapovými podklady v SQLite formátu • model - balíček se třídami reprezentujícími uživatelské mapy, žádostí o vytvoření a další pomocné objekty • view - balíček obsahující rozhraní pro vykreslování mapových podkladů a kontroler sloužící k veškeré manipulaci s mapou • view.opengl - obsahuje pomocné třídy a vlastní implementaci potřebnou k vykreslování mapových podkladů za použití knihovny OpenGL • tiles - obsahuje nástroje a další pomocné třídy sloužící k poskytování mapových dlaždic z různých zdrojů • net - balíček s nástrojem pro stahování mapových dat a třídami reprezentujícími online mapové služby • location - obsahuje třídy pro reprezentaci polohy na mapě, body zájmu a nástroj na konverzi mezi různými souřadnicovými systémy • conf - obsahuje Aktivitu s uživatelským nastavením aplikace a nástroj pro parsování informací z XML souborů • utils - tento balíček obsahuje pomocné Java třídy a nástroje používané v celé aplikaci, například nástroje pro práci se streamy a se soubory, logovací nástroj, LRU cache se Soft referencemi, obecný objektový pool a další


4.3

30

Implementace serverové aplikace

Serverová aplikace je navržena pro běh na platformě Node.js a vlastní implementace aplikace je tak realizována v programovacím jazyku JavaScript. Tato implementace částečně vychází z ukázkového kódu, který je součástí projektu node-mapnik. Veškerá funkcionalita serverové aplikace je přístupná přes HTTP GET dotazy, odpověď serveru pak záleží na konkrétní funkcionalitě. Díky tomu, že platforma Node.js používá událostmi řízenou architekturu, jednotlivé dotazy na server mohou běžet paralelně a jsou tak zpracovávány i při vytížení serveru. Pro svůj běh serverová aplikace hojně využívá již existujících komponentů, což je i součástí zadání této práce. Pro její zprovoznění je tak nezbytně nutné zprovoznit právě všechny tyto komponenty, ty hlavní jsou navíc v současné době v aktivním stádiu svého vývoje. Proto je při nasazování serverové aplikace na konkrétní stroj nejvhodnější zkompilovat tyto komponenty přímo ze stabilních verzí zdrojových kódů (to je možné díky použitým open source licencím). Důvodem může být například přidávání nové funkcionality, snížení počtu chyb a zvýšení stability výsledného systému. Z tohoto důvodu se jeví vhodné použít pro běh serverové aplikace operační systém GNU/Linux, celá serverová aplikace tak byla vyvíjena a testována na distribuci Linux Mint 12.

4.3.1

Databáze

Hlavní databází, která je nutná pro běh serverové aplikace, je PostgreSQL s rozšířením PostGIS. Ta je nejvíce používána nástrojem Mapnik k renderování rastrových dlaždic, další využití nachází i při hledání bodů zájmu. Tato databáze je klíčová pro většinu funkcí serverové aplikace a je tak vhodné provést výkonnostní optimalizace, popsané například na . Pro import geografických dat z projektu OSM do PostGIS databáze je použit nástroj osm2pgsql, který podporuje OSM XML formát a nově i PBF. K udržení aktuálních dat se pak do databáze importují diff soubory, které obsahují pouze změny. Mimo geografické databáze používá serverová aplikace i pomocnou databázi pro ukládání informací o generovaných mapových souborech. Tato databáze je ve formátu SQLite souboru uložena v pracovním adresáři serveru a její schéma je znázorněno na obrázku 4.6 na straně 30. map_files «column» *PK key file modtime status «PK» + PK_map_files()

Obrázek 4.6: Schéma pomocné databáze serverové aplikace


4.3.2

31

Žádosti o vytvoření mapy

Při obdržení nové žádosti o vytvoření mapy je vyhodnocena požadovaná oblast a pokud splňuje daná omezení, je zahájen proces generování nové mapové databáze. Při tomto procesu je nejprve v souborovém systému serveru vytvořen nový soubor s SQLite databází, poté je vypočteno jaké mapové dlaždice pokrývají požadovanou oblast a ty jsou následně vrenderovány a uloženy do této mapové databáze. Styl použitý pro vzhled mapy může být specifikován v žádosti o vytvoření mapy dodatečným parametrem. Odpověď na každou žádost je poslána ihned po obdržení a pokud byla žádost přijata, obsahuje unikátní klíč sloužící ke stažení výsledného souboru. Pro stažení výsledného souboru s mapovou databází je nutné použít další HTTP GET dotaz, který musí obsahovat unikátní klíč asociovaný s příslušnou žádostí. Tento soubor je možné stáhnout až poté, co byl celý proces generování mapy dokončen, potřebná doba závisí na velikosti požadované oblasti a na aktuálním vytížení serveru. Všechny vygenerované soubory jsou uloženy na serveru a po uplynutí definované doby neaktivity jsou smazány. Soubory je tedy možné stáhnou vícekrát.

4.3.3

Styly vzhledu renderovaných map

Serverová aplikace podporuje více různých stylů vzhledu renderovaných map, ty lze měnit pomocí dodatečného parametru style. Samotné styly jsou realizovány pomocí různých XML stylesheet souborů, které používá renderer Mapnik. V těchto souborech jsou definována pravidla určující co a jakým způsobem bude vyrenderováno a jaké zdroje geografických dat budou použity. Většina těchto stylů používá mimo geografických dat z databáze i takzvané Coastlines Shapefiles, které obsahují pouze údaje o hranicích států a pobřeží. Jelikož XML stylesheet soubory bývají většinou velmi rozsáhlé a nepřehledné, často se nevytváří manuálně, ale používá se různých nástrojů pro jejich generování. Jednou z možností je použití pre-procesoru Carto, ten umožňuje vytváření XML stylesheet soubory pomocí přehledných stylů podobných CSS. K pohodlnému vytváření těchto stylů je možné použít volně dostupný WYSIWYG editor TileMill. Tento program pak dokáže vygenerovat XML stylesheet použitelný pro nástroj Mapnik. Tímto způsobem lze efektivně vytvářet nové styly vzhledu nebo modifikovat již stávající. Podrobná uživatelská příručka k programu TileMill se nachází na , snímek obrazovky pro editaci stylů je na obrázku 4.7 na straně 32. V současné implementaci serverové aplikace jsou použity dva styly vzhledu mapy. Prvním je styl z projektu mapnik-stylesheets 4 , který používá projekt OSM pro základní vzhled svých map. Druhým je styl z projektu open-streets-style 5 , vycházející z Open Streets Project. Další styly je ovšem možné snadno vytvořit zmíněným programem TileMill. Aby bylo možné tyto styly použít při renderování, musí být definovány v konfiguračním souboru settings.js. Tento soubor rovněž obsahuje i další nastavení serverové aplikace. Všechny potřebné údaje a nastavení jsou z něj pak získány za běhu. 4 5

Dostupný z: Dostupný z:


32

Obrázek 4.7: Snímek obrazovky pro editaci stylů programu TileMill

4.3.4

Aktuální nedostatky

Současná implementace serverové aplikace slouží hlavně jako prototyp a její funkcionalita má tak některé nedostatky. Při vývoji byl kladen důraz na rychlou implementaci s ohledem na to, že tato aplikace bude v budoucnu dále rozvíjena a vylepšována. Úkolem tedy bylo spíše ukázat princip fungování a hlavní myšlenku této práce, než vytvořit robustní aplikační server. Jedním z nedostatků jsou omezení kladená na požadavky o vyrenderování mapy, která jsou málo restriktivní, což může vést k přetížení serveru. V současné implementaci prakticky není nijak limitována velikost výsledné mapy ani počet souběžných renderovacích procesů. Současná verze API také neposkytuje žádnou možnost stornovat nebo jinak zastavit již probíhající proces renderování. Dalším nedostatkem je to, že renderování probíhá po jednotlivých mapových dlaždicích i při generování rozsáhlé mapy. V tom případě by bylo mnohem efektivnější vyrenderovat najednou větší plochu a tu následně rozřezat do jednotlivých dlaždic. Za další nedostatek lze považovat ne příliš efektivní implementaci hledání bodů zájmu podle jména nebo souřadnic.

Kapitola 5

Testování Tato kapitola obsahuje popis a výsledky testování celé aplikace, které proběhlo v rámci realizace této práce. Nejdříve je popsáno zvolené testovací prostředí, poté testování funkčnosti bez uživatele a testování s uživateli, následně jsou uvedeny výsledky z provedeného externího testování. Vzhledem k rozsahu a časové náročnosti této páce bylo, po konzultaci s vedoucím práce, provedeno pouze základní testování. Důkladnější testování celé aplikace je pak zajištěno vedoucím práce.

5.1

Testovací prostředí

Při testování klientské aplikace i při samotném vývoji bylo použito mobilní zařízení HTC Desire s operačním systémem Android ve verzi 2.2. Pro testování i vývoj serverové aplikace byl použit operační systém Linux Mint 12 ve 64-bit variantě, na hardwarové konfiguraci Intel Core 2 Duo @ 2.00 GHz, 4 GB RAM. Geografická databáze, používaná serverovou aplikací, obsahovala data importovaná z extraktu Planet.osm souboru, který obsahoval pouze Prahu a její blízké okolí.

5.2

Testování funkcionality

Již od počátků svého vývoje byla funkcionalita celé aplikace důkladně testována. Tímto způsobem tak byla odhalena a následně odstraněna celá řada chyb a dalších nedostatků. Na testovacím hardware a software výsledná aplikace fungovala správně, v souladu se svými funkčními i nefunkčními požadavky. Finální verze klientské aplikace je tak funkční a plnohodnotná aplikace pro platformu Android.

5.3

Uživatelské testování

Na klientské aplikaci proběhlo během jejího vývoje i testování s uživateli. Cílem těchto testů bylo odhalit možné problémy v použitelnosti i další případné chyby. První uživatelský test proběhl v rané fázi vývoje celé aplikace a jeho cílem bylo otestovat klíčovou funkcionalitu

33

KAPITOLA 5. TESTOVÁNÍ

34

aplikace, tj. zobrazování a správu mapových podkladů. Tento test odhalil několik nedostatků a usability1 problémů, které klientská aplikace obsahovala. Problematické prvky GUI klientské aplikace pak byly přepracovány a vylepšeny. Poznatky z testu byly použity při návrhu dalších funkcí a velmi tak pomohly v dalším vývoji. Následuje popis a výsledky druhého uživatelského testu, který proběhl již na finální verzi klientské a serverové aplikace.

5.3.1

Průběh testů

Na finální verzi celé aplikace proběhl základní uživatelský test se třemi participanty. Úkolem tohoto testu bylo prakticky ověřit chování celé aplikace a také otestovat provedené změny a novou funkcionalitu. Testovány byly následující dva průchody klientskou aplikací v uvedeném pořadí. 1) import uživatelské mapy do aplikace (offline i online), zobrazení této mapy a následné hledání bodů zájmu 2) výběr oblasti na mapě, odeslání žádosti o její vytvoření serverové aplikaci a následně její stažení Před zahájením testu byla klientská aplikace uvedena do počátečního stavu jaký má hned po své instalaci a na SD kartě zařízení byl umístěn soubor s mapovými podklady. Při testu bylo k dispozici internetové připojení a fungující spojení se serverovou stranou aplikace. Každý participant byl před vlastním testováním krátce seznámen s testovanou aplikací a s úkoly, které bude v rámci testu plnit. Po skončení celého testu bylo provedeno s participantem krátké interview zhodnocující průběh testování i celou aplikaci.

5.3.2

Výsledky testů

Usability problémy nalezené během uživatelského testování v pořadí podle závažnosti. • Nejzávažnějším problémem bylo stahování vyrenderované mapy ze serverové aplikace. To není implementováno v klientské aplikaci přímo, ale místo toho je použit externí internetový prohlížeč. Proto musí uživatel použít právě internetový prohlížeč ke stažení mapového souboru, dále je většinou nutné použít vhodného správce souborů k přesunutí stažené mapy do pracovního adresáře klientské aplikace. Tento postup nemusí být pro uživatele napoprvé zcela zřejmý. Navíc se ukázalo i neočekávané chování některých internetových prohlížečů v případě stahování neznámého typu souboru. V tom případě je aktivita prohlížeče ihned ukončena, což vede k dalšímu zmatení uživatele. Návrh řešení: Nejlepším řešením tohoto problému se zdá být implementace stahování mapy přímo uvnitř klientské aplikace. • Středně závažným problémem byly rychlé změny úrovně přiblížení při prohlížení mapových podkladů online, což způsobovalo nepřiměřeně dlouhé načítání mapy. Tento problém je zapříčiněn tím, že jsou načítány i mapové dlaždice z úrovní, které byly 1

použitelnost - snadné používání a naučení se


35

rychle přeskočeny. Dlouhé načítání dlaždic je pak nejvýraznější právě při použití online služeb, kde je na stažení jedné dlaždice potřeba více času. Návrh řešení: Zde je pravděpodobně nejlepším řešením zrušit stávající žádosti o stažení dlaždice v případě, kdy se změní úroveň přiblížení. • Dalším středně závažným problémem bylo přibližování a oddalování mapy pomocí multi-touch gest. Tento způsob manipulace s mapou není v klientské aplikaci ještě zcela odladěn a při testování někdy způsoboval nechtěné chování. V současné implementaci působí zobrazování tzv. načítacích dlaždic rušivým dojmem a to hlavně při online prohlížení. Návrh řešení: Funkcionalita přiblížení a oddálení mapy by měla být rozšířena o postupné načítání dlaždic, kde by byly zobrazovány stávající dlaždice, dokud nebudou dostupné ty z nové úrovně přiblížení. Používání multi-touch gest by mělo být nadále testováno. • Méně závažným problémem bylo rozdělení vytváření nové mapy do dvou fází - odeslání žádosti o její vytvoření a stažení hotové mapy. Někteří uživatelé by mohli očekávat, že bude vše provedeno v jednom kroku. Návrh řešení: V klientské aplikaci by tato záležitost měla být více osvětlena. Mimo výše uvedených nedostatků celá aplikace fungovala dle očekávání a uživatelé jí hodnotili pozitivně.

5.4

Výsledky externího testování

Vedoucím práce bylo v konečné fázi vývoje zajištěno externí testování celé výsledné aplikace. Toto testování odhalilo několik usability problémů, chyby způsobující pád klientské aplikace a další nedostatky. • Během importu velké mapy byla změněna orientace displaye, což následně způsobilo pád aplikace. Při změnách orientace displaye se navíc ztrácí dříve vybraná cesta k mapovému souboru. Také by bylo vhodné přednastavit jméno importované mapy podle jména mapového souboru. • Hledání POI není stabilní, pro stejný hledaný řetězec aplikace zobrazuje různé výsledky. Dále po výběru jednoho z nalezených POI pak není možné vrátit se zpět na předchozí výsledky hledání. • Během testování nefungovalo hledání POI podle souřadnic, nikdy nebyly nalezeny žádné výsledky. Pro větší pohodlí uživatele by také bylo vhodné sloučit hledání POI do jedné aktivity s primárním přepnutím na hledání podle jména. • V situaci, kdy není dostupné spojení se serverovou částí aplikace, je Aktivita správy žádostí o stažení při připojování k serverové aplikaci zablokována, uživatel pak na delší dobu nemá možnost s klientskou aplikací nijak interagovat.


36

• Vybrání akce uložit při editaci uživatelské mapy, by mělo způsobit přechod na předchozí Aktivitu. • Když je během prohlížení online mapy OpenStreetMap v maximálním přiblížení změněna mapa na OpenCycleMap, dojde k pádu aplikace. • Pro uživatele klientské aplikace může být matoucí, že i online mapy je nutné importovat přes správu uživatelských map. • Po delší době prohlížení online mapy při špatném internetovém připojení, došlo k pádu aplikace. • Na některých zařízeních (například Galaxy Nexus s Androidem 4.0.4 a Motorola MB526 s Androidem 2.3.5) nefunguje vykreslování mapy správně. Místo mapových dlaždic se občas vykreslují pouze jednobarevné plochy. Řada těchto nedostatků byla ve finální verzi aplikace odstraněna.

Kapitola 6

Závěr Cíle této bakalářské práce byly naplněny v souladu se zadáním. Byla navržena a implementována funkční aplikace pro mobilní operační systém Android, schopná zobrazovat mapové podklady v rastrové podobě a hledat body zájmu na mapě. Dále byla navržena a implementována serverová aplikace určená k vytváření rastrových obrázků z geografických dat za použití projektu OpenStreetMap a schopná poskytovat informace o bodech zájmu. Celá výsledná aplikace byla navržena s ohledem na její další vývoj, snadnou rozšiřitelnost a modularitu. Zdrojový kód je proto podrobně dokumentován formou Javadoc. Klientská aplikace používá pro vykreslování mapových podkladů akcelerované grafické prostředí OpenGL ES 1.0, čímž umožňuje využít potenciál dnešních chytrých telefonů ke kvalitnímu a rychlému prohlížení map. Jako zdroj mapových podkladů jsou používány databázové soubory v SQLite formátu nebo online mapové služby, aplikace také umožňuje tyto zdroje jednoduše spravovat. Klientská aplikace je určená hlavně pro offline použití a uživatelé tak nemusí spoléhat na dobrou internetovou konektivitu. Při online používání navíc klientská aplikace umožňuje hledání bodů zájmu pomocí webových služeb. Serverová aplikace je určena pro běh na platformě Node.js, která umožňuje dobrou škálovatelnost a paralelní zpracování jednotlivých žádostí. K samotnému renderování rastrových obrázků z geografických dat je použit nástroj Mapnik. Serverová aplikace pak umožňuje generovat celé mapy ve formátu SQLite databáze nebo jen jednotlivé mapové dlaždice. Dále umožňuje i hledání bodů zájmu podle zadaného jména či souřadnic. Klíčovou funkcionalitou serverové aplikace je také možnost výběru stylu vzhledu renderované mapy. Veškerá funkcionalita serverové aplikace je pro uživatele dostupná přes mobilní klientskou aplikaci. Celá výsledná aplikace je stále v počáteční fázi svého vývoje a není proto zcela bez chyb, například se objevuje špatné vykreslování mapy na některých mobilních zařízeních. Předpokládá se tak její další vylepšování a rozšiřování stávající funkcionality. Nicméně všechny specifikované funkční a nefunkční požadavky výsledná implementace splňuje.

6.1

Další možný vývoj

Při dalším vývoji klientské aplikace by bylo vhodné opravit nalezené nedostatky, které jsou uvedené v předchozí kapitole. Například implementace stahování mapy, postupné na-

37

KAPITOLA 6. ZÁVĚR

38

čítání mapových dlaždic, vylepšení manipulace s mapou pomocí multi-touch gest a vhodná úprava hledání bodů zájmu. Také chybné vykreslování mapy na některých zařízeních by mělo být podrobě prozkoumáno. Předmětem dalšího vývoje by mohlo být i rozšíření nebo vylepšení stávající funkcionality. Například podpora lokalizačních služeb a GPS, použití kompasu k natáčení zobrazované mapy, možnost stahovat data o bodech zájmu pro offline použití a zobrazování více dostupných informací. Pro další zvýšení rychlosti vykreslování mapových podkladů by šla použít komprese textur, kterou většina grafických akcelerátorů podporuje, nebo využití výkonnější grafické knihovny OpenGL ES 2.0. Další vývoj serverové části aplikace by mohl směřovat k větší optimalizaci stávající funkcionality a přidávání nových funkcí. Možnou další funkcionalitou by mohlo být například posílání e-mail zpráv uživatelům o tom, že požadovaná mapa je připravená ke stažení, rozšíření API o možnost editace geografických dat na serveru, vyhledávání bodů zájmu dle zvolené kategorie a podobně.

Literatura [1] AHN, S. H. OpenGL [online]. 2012. [cit. 3. 5. 2012]. Dostupné z: . [2] BERGMAN, P.-E. OpenGL ES Tutorial for Android [online]. 2012. [cit. 3. 5. 2012]. Dostupné z: . [3] BRAY, T. Android’s HTTP Clients [online]. 2012. [cit. 24. 4. 2012]. Dostupné z: . [4] DOUGHERTY, D. 10 Billion Android Market Downloads [online]. 2012. [cit. 18. 4. 2012]. Dostupné z: . [5] Joyent, Inc. node.js [online]. 2012. [cit. 23. 4. 2012]. Dostupné z: . [6] KAPETANAKIS, M. Winners and losers in the platform race [online]. 2012. [cit. 18. 4. 2012]. Dostupné z: . [7] LESKE, N. Android conquers almost 50 percent of smartphone market [online]. 2012. [cit. 18. 4. 2012]. Dostupné z: . [8] OHAZAMA, C. “Download map area” added to Labs in Google Maps for Android [online]. 2012. [cit. 23. 2. 2012]. Dostupné z: . [9] Open Handset Alliance. Android platform versions [online]. 2012. [cit. 18. 4. 2012]. Dostupné z: . [10] Open Handset Alliance. Android developer’s guide [online]. 2012. [cit. 18. 4. 2012]. Dostupné z: . [11] PAVLENKO, A. mapnik [online]. 2012. [cit. 25. 4. 2012]. Dostupné z: .

39

LITERATURA

40

[12] Přispěvatelé OSM wiki. Android software supporting OpenStreetMap [online]. 2012. [cit. 26. 2. 2012]. Dostupné z: . [13] Přispěvatelé OSM wiki. Osmarender [online]. 2012. [cit. 27. 4. 2012]. Dostupné z: . [14] Přispěvatelé OSM wiki. Tile usage policy [online]. 2012. [cit. 5. 5. 2012]. Dostupné z: . [15] Přispěvatelé Wikipedie. Dalvik Virtual Machine [online]. 2012. [cit. 18. 4. 2012]. Dostupné z: . [16] Přispěvatelé Wikipedie. Android (operating system) [online]. 2012. [cit. 18. 4. 2012]. Dostupné z: . [17] Přispěvatelé Wikipedie. Node.js [online]. 2012. [cit. 23. 4. 2012]. Dostupné z: . [18] Přispěvatelé Wikipedie. OpenGL [online]. 2012. [cit. 26. 4. 2012]. Dostupné z: . [19] Přispěvatelé Wikipedie. OpenStreetMap [online]. 2012. [cit. 18. 4. 2012]. Dostupné z: . [20] PostgreSQL Global Development Group. PostgreSQL [online]. 2012. [cit. 28. 4. 2012]. Dostupné z: . [21] TIŠNOVSKÝ, P. Seriál Grafická knihovna OpenGL [online]. 2012. [cit. 26. 4. 2012]. Dostupné z: . [22] Uživatelé Stack Overflow. Stack Overflow [online]. 2012. [cit. 4. 5. 2012]. Dostupné z: .

Příloha A

Seznam použitých zkratek ACID Atomicity, Consistency, Isolation, Durability ADT Android Development Tools API Application Programming Interface CSS Cascading Style Sheets GIS Geographic Information System GPS Global Positioning System GUI Graphical User Interface HTML HyperText Markup Language HTTP Hypertext Transfer Protocol IDE Integrated Development Environment I/O Input/Output LRU Least Recently Used NPM Node Package Manager OHA Open Handset Alliance OpenGL Open Graphics Library OpenGL ES OpenGL for Embedded Systems OSM OpenStreetMap OSMF OpenStreetMap Foundation PBF Protocolbuffer Binary Format PNG Portable Network Graphics

41

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

POI Point Of Interest RGBA Red, Green, Blue, Alpha SD Secure Digital SDK Software Development Kit SQL Structured Query Language SVG Scalable Vector Graphics UML Unified Modeling Language VM Virtual Machine WYSIWYG What You See Is What You Get XML Extensible Markup Language 2D Two-Dimensional 3D Three-Dimensional

42

Příloha B

Instalační příručka B.1

Instalace klientské aplikace

Klientská aplikace je distribuována jako samoinstalační balíček ExtBrainMaps.apk pro platformu Android. K instalaci této aplikace je nutné umístit tento soubor například na SD kartu zařízení a pomocí libovolného správce souborů tento soubor spustit, tím se zahájí standardní proces instalace Android aplikací. Vlastní instalace může vyžadovat povolení instalace aplikací z neověřených zdrojů. Po úspěšné instalaci lze aplikaci v zařízení najít pod jménem ExtBrain Maps. Při prvním spuštění aplikace je vhodné nastavit pracovní adresář, kde bude aplikace hledat mapové soubory. To je možné v nastavení aplikace, které je přístupné z hlavního menu, přednastavená hodnota je /sdcard/extbrain/maps/. V nastavení je také možné specifikovat konkrétní konfiguraci serverové aplikace pomocí zvoleného XML souboru, přednastavená cesta k tomuto souboru je /sdcard/extbrain/maps/download_server.xml.

B.2

Instalace serverové aplikace

Pro nasazení serverové aplikace na konkrétním zařízení je nutné nejdříve zprovoznit všechny komponenty, které serverová aplikace používá. Hlavními jsou Mapnik a Node.js s modulem node-mapnik. Doporučeným operačním systémem pro běh serveru je GNU/Linux, nicméně všechny použité komponenty by měly být platformě nezávislé. Nástroj osm2pgsql není nutný k samotnému běhu serverové aplikace, ale je použit pro import geografických dat do PostGIS databáze. Doporučené pořadí instalace jednotlivých komponent: 1) Python knihovny a běhové prostředí ve verzi 2.7 nebo novější 2) PostgreSQL verze 9.0 a výš s rozšířením PostGIS, více informací:

43

PŘÍLOHA B. INSTALAČNÍ PŘÍRUČKA

44

3) Node.js a NPM (Node Package Manager), více informací: 4) Mapnik ve verzi 2.0.0 nebo výše, více informací: 5) osm2pgsql v nejnovější verzi, více informací: 6) modul node-mapnik v nejnovější verzi, více informací: 7) instalace ostatních modulů pro Node.js pomocí NPM, konkrétně: - node-sqlite3 - node-postgres - node-pool - xmlbuilder-js V případě Node.js, Mapnik, osm2pgsql a node-mapnik je doporučena instalace ze zdrojových kódů ve stabilních verzích. Konkrétní verze všech použitých komponent, které byly použity při vývoji a testování serverové aplikace, jsou uvedeny v přiloženém CD. K instalaci modulů do Node.js lze použít nástroj NPM, který umožňuje jejich instalaci globálně přepínačem -g nebo v aktuálním pracovním adresáři bez něj. Například instalaci modulu node-postgres lze provést následujícím příkazem. > npm install -g pg Pokud je modul zkompilovaný ze zdrojových kódů, je většinou nutné přidat cestu k příslušným spustitelným souborům do proměnné prostření NODE_PATH. Po úspěšné instalaci a zprovoznění všech potřebných komponent je možné serverovou aplikaci nasadit. Prvním krokem je zkopírování zdrojových souborů do pracovního adresáře a poté je nutné nakonfigurovat serverovou aplikaci pro běh v daném prostředí. Veškerá potřebná nastavení jsou umístěna v konfiguračním souboru settings.js. Server pak lze spustit pomocí Node.js a souboru main.js, například následujícím příkazem. > node main.js

Import geografických dat do databáze Ke správnému fungování serveru je nutná také PostGIS databáze s geografickými daty, je tedy třeba tato data do databáze importovat. K tomu slouží nástroj osm2pgsql, který umožňuje import dat z projektu OSM ve formátu Planet.osm. Mnoho míst, kde se dají tyto soubory stáhnout, je uvedeno na . Vlastní import dat pak lze provést například následujícím příkazem. > osm2pgsql -s -d gis -U postgres -W -H localhost -P 5432 planet.osm.pbf

Příloha C

Obsah přiloženého CD C:\Users\Mudrc\Documents\CVUT FEL OI\BP\thesis\src\CD.txt

CD ├── │ │ │ │ │ │ │ ├── │ │ └──

app ├── │ │ │ └──

client ├── ExtBrainMaps.apk ├── ExtBrainMaps-javadoc.zip └── ExtBrainMaps-src.zip server ├── ExtBrainMapServer-src.zip └── README.txt test-data ├── praha.osm.pbf └── praha.sqlitedb text ├── mudrutom-thesis-2012.pdf └── mudrutom-thesis-2012-src.zip

45

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

Recommend Documents