Vyhledávání zájmových bodů v geografických datech

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Vyhledávání zájmových bodů v geografických datech

BAKALÁŘSKÁ PRÁCE

Ondřej Sobočík

Brno, jaro 2015

Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Ondřej Sobočík

Vedoucí práce: RNDr. Jaroslav Ráček, Ph.D.

Poděkování Chtěl bych poděkovat doktoru Ráčkovi za ochotu, motivující přístup, věcné připomínky a odborný nadhled. Dále bych chtěl poděkovat své rodině za trpělivost a podporu.

Shrnutí V této práci analyzujeme alternativy řešení a požadavky systému pro vyhledávání blízkých bodů zájmů v geografických informacích. Dále navrheme a vytvoříme datový model a model tříd, jež následně implementujeme a popíšeme použité postupy.

Klíčová slova GIS,GPS, Java, mapa, výpočet vzdáleností, body zájmu, mobilní aplikace.

Obsah 1

Úvod ........................................................................................................................................... 2

2

Analýza ....................................................................................................................................... 3 2.1

Alternativy .......................................................................................................................... 4

2.1.1

Mapové portály .......................................................................................................... 4

2.1.2

Aplikace pro správu a manipulaci s GPS daty ............................................................. 5

2.2

Oblasti užití......................................................................................................................... 5

2.2.1

Šifrovací hry ................................................................................................................ 5

2.2.2

Turistické známky ....................................................................................................... 6

2.2.3

Pojišťovny ................................................................................................................... 6

2.2.4

Vyhledávání restaurací ............................................................................................... 7

2.3

Analýza požadavků ............................................................................................................. 8

2.3.1 3

4

Technologie .............................................................................................................................. 12 3.1

Programovací jazyk .......................................................................................................... 12

3.2

Databáze........................................................................................................................... 13

Vývoj ......................................................................................................................................... 14 4.1

Datový model ................................................................................................................... 14

4.2

Diagram tříd ..................................................................................................................... 18

4.2.1

Správa a vyhledávání POI ......................................................................................... 20

4.2.2

Automatizovaný sběr dat ......................................................................................... 20

4.2.3

Správa událostí ......................................................................................................... 23

4.2.4

Správa uživatelů ....................................................................................................... 24

4.2.5

Zabezpečení uživatelských hesel .............................................................................. 25

4.2.6

Ukládání uživatelských logů ..................................................................................... 25

4.2.7

Vyhledání POI v GPS datech ..................................................................................... 25

4.2.8

Formát vyměňovaných dat....................................................................................... 26

4.3

5

Návrh mobilní aplikace ............................................................................................... 9

API .................................................................................................................................... 27

4.3.1

LocationsServlet ....................................................................................................... 27

4.3.2

UserConfigServlet ..................................................................................................... 29

Závěr ......................................................................................................................................... 31

1

1 Úvod Cílem práce je navrhnout a implementovat konfigurovatelný systém pro vyhledávání blízkých bodů zájmu v geografických informacích (dále jen systém). V současnosti existuje velké množství specializovaných portálů a databází, ve kterých lze vyhledávat body zájmu (dále POI - point of interest) specifického typu (např. restaurace, firmy). Systém bude univerzální a jednoduše přizpůsobitelný, použitelný pro široké spektrum oblastí. Bude možné ho využít jako knihovnu pro stávající aplikace nebo přímo nasadit samostatně na aplikační server. Záměrem je, aby systém pracoval jako služba poskytující požadované funkce uživatelům online. Při návrhu a implementaci se na systém budeme dívat ze dvou pohledů. Prvním bude pohled administrátora, jenž bude od systému požadovat snadné přidávání POI s možností automatizace, vytváření a správu událostí a dostupnost zmíněných funkcí přes webové rozhraní. Druhým pohledem je pohled běžného uživatele. Jenž bude chtít pomocí mobilní aplikace najít POI ve svém okolí, s možností výsledky hledání filtrovat, získat bližší informace o těchto lokacích a událostech s nimi spojenými a uložit si je mezi oblíbené nebo navštívené. Implementace mobilní aplikace nebude součástí této práce, protože podoba a šíře funkcí bude záviset na zamýšleném použití systému, nicméně vytvoříme ukázkový model aplikace, která by mohla služby systému využívat. V první části práce se zaměříme na to, co je GIS (Geographic information system - geografický informační systém), co jsou geografické informace a co konkrétně pro nás bude znamenat POI. Poté se podíváme na existující prostředky pro vyhledávání takovýchto informací a navrhneme několik různých možných oblastí užití. Na základě dostupných prostředků a těchto oblastí určíme funkční požadavky, vybereme technologie, ve kterých budeme systém implementovat, vytvoříme datový model, na kterém podrobněji popíšeme důležité entity, a model tříd. Jednotlivé třídy popíšeme v další části práce, také u nich předvedeme implementační detaily hlavních funkcionalit systému a možnosti přizpůsobení systému pro specifické účely případů užití. V poslední části se zaměříme na API (Application Programming Interface - rozhraní pro programování aplikací) pomocí kterého se systémem mohou komunikovat další aplikace.

2

2 Analýza Začneme určením základních pojmů. Co jsou to geografické informace, jak se ukládají, jaké jsou problémy při vyhledávání bodů v těchto informacích? Pro práci s geografickými informacemi se používají GIS. Úřad pro veřejné informační systémy je definuje jako „Organizovaný soubor počítačového hardware, software, geografických údajů a personálu určený k efektivnímu sběru, uchovávání, obnovování, manipulaci, analýze a zobrazování všech geograficky vztažených informací.“ [1] Data, se kterými GIS pracuje, se nazývají geografická data a skládají se z jednotlivých geoobjektů. Geoobjekty obsahují dva druhy informací, a to prostorové (tvar, poloha, topologie) a neprostorové (atributy specifické pro typ objektu). Geoobjekty můžeme dělit podle počtu rozměrů: •

0D geoobjekt - bod, definovaný pouze svou polohou

•

1D geoobjekt - úseky čar s konečnou délkou a nulovou plochou

•

2D geoobjekt - dvourozměrné objekty s konečným obvodem a plochou

•

3D geoobjekty - geometrické těleso, v GIS se používá výjimečně

V rámci práce budeme mluvit o POI jako o 0D geoobjektech s dodatečnými neprostorovými informacemi. Dvě nejčastěji řešené úlohy při výpočtech v geografických informacích jsou takzvané přímý a inverzní geodetický problém. Přímým geodetickým problémem je výpočet výsledné pozice, pokud známe výchozí bod, směr a vzdálenost. Za inverzním geodetickým problémem se skrývá výpočet vzdálenosti dvou bodů na Zemi. V této práci se budeme zabývat pouze případem inverzního geodetického problému. Pokud jsou dva body dostatečně blízko u sebe, můžeme jejich vzdálenost počítat v rovině pomocí Pythagorovi věty. Pro větší vzdálenosti je nutné použít sférickou trigonometrii. Nejkratší spojnice dvou bodů na kulové ploše (tzv. ortodroma) je kratší oblouk hlavní kružnice procházející těmito dvěma body. Hlavní kružnice je průsečík povrchu koule a roviny procházející středem koule. Pro výpočet musíme znát souřadnice dvou bodů [U1;V1] a [U2;V2], středový úhel σ a poloměr koule (v našem případě Země) R = 6371,1. Středový úhel v radiánech pak vypočítáme pomocí následující rovnice:

σ = arccos (sin U 1 sin U 2 + cos U 1 cos U 2 cos (V 2 − V 1)) Délku ortodromy d v kilometrech dostaneme rovnicí:

d =σ ⋅R⋅

π 180

3

2.1 Alternativy V této části práce se nejdříve podíváme na alternativy k našemu systému. Tedy na možnosti, jak můžeme z hlediska běžného uživatele vyhledávat POI v geografických informacích. Zajímat nás také budou možnosti ukládání a správy vlastních bodů. Zejména se zaměříme na mapové portály, a to z následujících důvodů: •

jsou snadno dostupné online,

•

často jsou přístupné i jako mobilní aplikace

•

poskytují spoustu různých funkcí nad rámec obyčejného vyhledávání POI a navigaci.

Podíváme se také na tradiční aplikace pro správu GPS dat. Naopak se nebudeme zabývat GPS navigacemi (ať hardwarovými nebo mobilními aplikacemi), kterých existuje velké množství, ale kromě navigace a vyhledávání podle známých informací neposkytují funkce, které budeme požadovat po našem systému. 2.1.1

Mapové portály

V první řadě se podíváme na mapové portály. Konkrétně na dva u nás nejoblíbenější a nejpoužívanější, a to Mapy.cz (http://mapy.cz) a Google Maps (https://www.google.cz/maps). Oba portály mají společné základní funkce. Kromě základního zobrazení nabízejí i letecké snímky, pohled z úrovně ulice nebo turistickou/topografickou mapu. Mapy.cz nabízejí více typů map (např. historické mapy měst, cykloturistickou mapu a další) a na území České republiky jsou podrobnější. Oba portály umožňují vyhledávat místa podle adresy, GPS souřadnic nebo jména. Ve vyhledávání podle jména jsou první větší rozdíly. Při testování Google Maps úspěšně našly větší množství restaurací a podobných podniků, zato Mapy.cz našly více lokací, jako jsou muzea, knihovny, lékařská zařízení atd. Oba portály umí najít trasu mezi libovolnými body, a to jak pro automobil, tak pro chodce nebo prostřednictvím městské hromadné dopravy (případně kombinací). Mapy.cz mají pro přihlášené uživatele možnost označovat místa jako navštívená a ukládat si naplánované trasy, také umí navrhnout zajímavá místa nebo akce pro výlet. Google Maps umožňují vytvářet a ukládat vlastní mapy s vyznačenými body, naplánovanými trasami a poznámkami a upravené mapy sdílet s ostatními uživateli. Mapy.cz poskytují jednoduché API, které umožňuje vkládat mapu na jiné webové stránky. Na mapě je možné zobrazovat vlastní body zájmu, vrstvy s ovládacími prvky, vektorové prvky atd. Dále poskytují aplikaci pro mobilní operační systém Android, umožňující funkce portálu využívat také offline. Google Maps poskytují několik API pro různé aplikace/portály společnosti Google související s mapami, která umožňují na jiných webových stránkách zobrazit mapy s širokými možnostmi úprav a přizpůsobení, Street View, interaktivní prohlídky pamětihodností, vyhledávání v databázi 4

míst a podniků a mnoho dalšího. Google nabízí ke stažení SDK (Software Development Kit - soubor nástrojů pro vývoj softwaru) pro iOS a Android umožňující využívat funkcionalitu Google Maps v aplikacích psaných pro tyto operační systémy. 2.1.2

Aplikace pro správu a manipulaci s GPS daty

Na trhu je velké množství aplikací pro GPS navigaci a sledování polohy, ale aplikací umožňujících správu POI a manipulaci s nimi je velmi málo. Podíváme se blíže na dvě z nich, a to na Viking GPS data

editor

and

analyzer

(http://sourceforge.net/projects/viking/)

a

GPS

Utility

(http://www.gpsu.co.uk/index.html). Obě aplikace mají společné základní funkce a charakteristiky. Jsou určené pro osobní počítače, postrádají tedy možnost jednoduchého sdílení dat s dalšími uživateli (obě aplikací umožňují data exportovat do celé řady GPS formátů), jsou dostupné ve freeware verzi, umí zobrazovat POI na různých mapách, které jsou buď součástí aplikace nebo se dají importovat, a umí vyhledávat trasy mezi body na mapě. Aplikace GPS Utility k tomu klade důraz na spolupráci s hardwarovými GPS navigacemi. Především ukládání a pohodlné vytváření tras s postupnými body a následné nahrávání do GPS zařízení. Za zajímavou považuji integraci GPS Utility s Google Maps, umožňující využít Google Maps k vyhledání a naplánovaní trasy a pomocí několika kliknutí trasu nahrát.

2.2 Oblasti užití V této podkapitole určíme a popíšeme některé možné oblasti použití našeho systému. Oblasti se budou lišit scénáři použití i množstvím a typem vyžadovaných funkcí, protože možnost přizpůsobení systému pro nás bude v této práci důležitá. U každé oblasti použití určíme několik zásadních bodů. Vynecháme základní principy systému společné pro všechny oblasti, jako schopnost propojení s mobilní aplikací, vyhledávání POI v blízkém okolí uživatele a další. 2.2.1

Šifrovací hry

Organizátoři šifrovací hry chtějí systém využít k zadávání úkolů a sběru výsledků účastníků. Před zahájením vytvoří v systému lokace stanovišť, na nichž se budou nacházet jednotlivé šifry a úkoly, a události obsahující zadání úkolů nebo klíče k šifrám. Události budou zveřejněny v okamžik zahájení hry. Účastníci budou vybaveni telefonem s mobilní aplikací, která vyhledá a zobrazí na mapě všechna stanoviště. Výběr startovního místa a trasy je pouze na účastnících. Po zahájení hry se účastníkům zobrazí události s instrukcemi k daným stanovištím. Pokud danou šifru vyřeší, označí stanoviště jako navštívené a přidají komentář s řešením a aplikace připojí časový údaj. Zadané informace jsou aplikací odeslány na server, kde jsou uloženy do databáze. Po skončení hry organizátoři data využijí ke kontrole a vyhodnocení výsledků. 5

Pro tento případ užití je důležité: •

vytváření lokací a publikovatelných událostí

•

označení lokací/událostí jako navštívených s připojeným komentářem.

2.2.2

Turistické známky

Systém bude použit jako turistická aplikace usnadňující sběr turistických známek. Lokace budou do systému přidávány automaticky z existujících internetových stránek www.turisticke-znamky.cz. Systém bude umožňovat vyhlašování výzev. Např. navštívit během května co nejvíce zámků v Moravskoslezském kraji. Uživatelé budou moci pomocí mobilní aplikace vyhledávat lokace v okolí, označovat je jako navštívené a výsledky hledání bude možné filtrovat podle tohoto označení a typu lokace. Aplikace bude obsahovat navigaci k vybraným lokacím. V případě plnění výzvy uživatel pořídí na daném místě log sestávající z GPS souřadnic, časové známky a komentáře. Log bude následně odeslán na server, kde je lokace s výzvou označena jako navštívená a zaslané informace budou uloženy do databáze. Pro tento případ užití je důležité: •

automatizovaný sběr dat o lokacích

•

vyhlašování výzev

•

zpracovávání logů z lokalit.

2.2.3

Pojišťovny

Pojišťovna chce systém využít v rámci mobilní aplikace pro klienty, pomocí které budou vytvářet pojistné události. Například dopravní nehody. V případě takovéto události se uživatel přihlásí do mobilní aplikace, vytvoří novou událost s krátkým popisem a pořídí fotografii havarovaného vozidla. Aplikace automaticky přidá GPS souřadnice a datum a odešle soubor dat na server pojišťovny. Uživatel nemá možnost upravovat data připojená aplikací z důvodu předcházení pojistných podvodů. Po přijetí dat serverovou aplikací je fotografie uložena na souborový server a událost je založena do databáze s odkazem na fotografii. Data jsou následně zpracovávána dalšími systémy pojišťovny. Systém je tedy používán jednosměrně pouze ze strany klientů/uživatelů. Pro tento případ užití je důležité: •

autonomní pořízení GPS dat a data

•

uložení přijatých obrazových souborů

•

založení události v databázi.

6

2.2.4

Vyhledávání restaurací

Systém bude sloužit pro vyhledávání restaurací, barů a podobných podniků v blízkém okolí uživatelů. Podniky je možné přidávat manuálně administrátory nebo manažery podniků. Manažerem je v tomto případě myšlen uživatel, který má oprávnění přidávat nové lokace do systému. Tyto lokace však musí být schváleny administrátorem, než jsou v systému viditelné ostatním uživatelům. Obdobným způsobem bude možné v lokacích vytvářet události. Podniky i události můžou být různého typu. Přidávání velkého množství podniků manuálně by však bylo nepraktické. Je tedy vyžadována možnost automatizovaného sběru dat o podnicích. Standardní uživatelé systému budou pomocí mobilní aplikace vyhledávat podniky v blízkém okolí. Výsledky bude možné filtrovat. Například podle typu podniku, jestli v něm probíhá nějaká událost, zda je na ní vstupné, podle otevírací doby apod. Mobilní aplikace bude umět k vybranému podniku navigovat, v ideálním případě bude brát volitelně do úvahy i městskou hromadnou dopravu. Uživatelé budou mít možnost podniky hodnotit, označovat je jako navštívené a přidávat si je k oblíbeným podnikům. Pro tento případ užití je důležité: •

rozlišení různých uživatelů s rozdílnými oprávněními v systému

•

automatický sběr dat o lokacích

•

vyhledávání blízkých podniků s možností filtrování výsledků

•

označování lokací jako oblíbených a navštívených

•

hodnocení lokací.

7

2.3 Analýza požadavků Systém musí fungovat jako služba běžící na aplikačním serveru a musí být snadno nasaditelný do mnoha rozdílných prostředí. Tuto vlastnost zajistíme volbou vhodných implementačních technologií v další kapitole. Bude rozlišovat dva typy uživatelů, administrátory a běžné uživatele, ale část práv uživatelů bude konfigurovatelná, a tak se mohou uživatelská typy z části prolínat. Primárními daty v systému budou POI, které budou určeny zeměpisnými souřadnicemi a názvem. Dále budou mít volitelné atributy (viz kapitola Databázový model),, zejména typ POI. Typy budou taktéž

konfigurovatelné

administrátory.

Administrátoři

mohou

POI

přidávat

ručně

nebo automatizovaně parsováním HTML (hypertext markup language - hypertextový značkovací jazyk) dokumentů, včetně volně dostupných webových stránek,, a dále informace o nich upravovat. Systém bude umožňovat vytváření událostí provázaných s POI a tyto události, události stejně jako POI, zveřejňovat ve vybraný čas. Následující UC (use case - případ užití) diagram ilustruje práci s POI z hlediska administrátora. administrátora

Obrázek 2.1: UC diagram z pohledu administrátora.

Pro uživatele bude nejdůležitější funkce vyhledávání blízkých POI. Blízkými, budeme rozumět POI na ploše malého města nebo městské části. Počet výsledků vyhledávání bude nastavitelný, takže například v centru velkého města, kde se dá očekávat větší hustota POI, budou zobrazeny výsledky z menší plochy,, než třeba na periferiích. Výsledky vyhledávání budou také filtrované dle uživatelem nastavených filtrů. Uživatelé ivatelé se budou moci registrovat. Funkce vyhledávání POI bude dostupná i neregistrovaným uživatelům, registrovaní uživatelé budou moci POI přidávat mezi oblíbené, označovat je jako navštívené, navštívené hodnotit a nahrávat logy. Logy budou obsahovat zeměpisné souřadnice, dnice, čas a datum pořízení a komentář, které budee uložen do databáze 8

a provázán s uživatelem a POI, POI případně událostí. Následující UC diagram ilustruje práci s POI z hlediska uživatele.

Obrázek 2.2: UC diagram z pohledu uživatele.

Systém ém bude obsahovat rozhraní pro komunikace postavené na protokolu http (hypertext transfer protokol - protokol pro přenos hypertextových dokumentů). Tím umožníme využívání služeb systému nezávisle na platformě uživatele. 2.3.1

Návrh mobilní aplikace

Realizace mobilní ilní aplikace, která by využívala služeb systému, není součástí této práce, protože jednotlivé aplikace se budou podle zamýšleného použití odlišovat množstvím a typem funkcí. Nicméně navrhneme ukázkovou aplikaci, sloužící k vyhledávání barů v okolí a jejich jejic hodnocení. Aplikace bude bary zobrazovat na mapě a případně uživatele navigovat k vybranému podniku. Aplikace bude určena pro chytré telefony s operačním systémem Android a GPS modulem. Hlavním důvodem pro tuto volbu je, že standardní součástí Androidu jsou sou Google Maps. To nám umožní snadnou integraci mapy do aplikace. Pomocí API Google Maps

budeme na mapě

zobrazovat naše POI a případně trasu ke zvolenému cíli. cíli Trasa se aktualizuje aktual na požádání. Na obrázku 2.3 můžeme vidět návrh uživatelského rozhraní.

9

Obrázek 2.3: Návrh uživatelského rozhraní ukázkové aplikace.

Po spuštění aplikace zjistí současné GPS (Global ( Positioning System - Globální polohovací systém) souřadnice, vyhledá bary v okolí podle defaultního nebo naposledy použitého nastavení nas a zobrazí pozici uživatele a vyhledané POI na mapě. Nepřihlášený uživatel může pouze vyhledávat, filtrovat a zobrazovat informace o barech. barech Tlačítko Přihlásit se zobrazí přihlašovací dialog, tlačítko Hledej znovu vyhledá POI v okolí s aplikací zvolených zvole filtrů a tlačítko Filtry otevře podmenu pod s jednotlivými filtry. Filtrovat lze podle počtu zobrazených barů, typu a přihlášení uživatelé navíc mohou zapnout nebo vypnout zobrazování oblíbených a již hodnocených podniků.

Obrázek 2.4: Podmenu Filtry.

Po kliknutí na ikonku baru na mapě se zobrazí vyskakovací okno s informacemi. Okno obsahuje název podniku, ikonku kalendáře, která otevře další vyskakovací okno s otevírací dobou, pět hvězdiček reprezentujících průměrné hodnocení, informace informace o podniku a dvě tlačítka pro ohodnocení a přidání mezi oblíbené. Tlačítka mají ikonku znázorňující, jestli byla operace již provedena. Pro nepřihlášeného uživatele budou tlačítka neaktivní. Přihlášený uživatel bude moci označit počet hvězdiček, které chce chc podniku dát. V tom okamžiku se aktivuje tlačítko, tlačítko kterým hodnocení zašle na server. Na obrázku 2.5 jsou dvě vyskakovací okna. První znázorňuje, co uvidí nepřihlášený uživatel. Druhé ukazuje, co uvidí přihlášený uživatel, s otevřenou ikonkou otevírací doby, pokud je podnik přidaný mezi oblíbené podniky uživatele a uživatel uživatel vybral hodnocení, ale ještě jej neodeslal.

10

Obrázek 2.5: Různé formy vyskakovacích oken.

11

3 Technologie 3.1 Programovací jazyk Při výběru programovacího jazyka musíme zvážit několik důležitých kritérií. Předně všechny použité technologie musí být bezplatné. Za druhé, systém musí být snadno nasaditelný do prostředí uživatele. Důležitá je tedy multiplatformovost. Na základě osobních zkušeností a preferencí zvažuji hlavně jazyky Java a C# s platformou .NET. Podíváme se ale i na jiné alternativy, a to Python a Ruby. Ruby on Rails (dále jen Rails) je open sourcový webový framework založený na jazyce Ruby. Rails využívá architekturu MVC (model-view-controller) pro strukturování webových aplikací a mezi jeho základní filozofické principy patří „Konvence před konfigurací“ (Convention over Configuration - CoC) a „Neopakuj se“ (Don’t Repeat Yourself - DRY). CoC znamená, že programátor musí specifikovat pouze aspekty odchylující se od standardního chování. Např. pokud máme v modelu třídu Sale, odpovídající tabulka v databázi se bude jmenovat sales. Pouze pokud budeme chtít, aby se jmenovala jinak, bude nutné to specifikovat. Rails je možné nasadit na velké množství webových serverů (Mongrel, Apachee a další) a spolupracuje s databázovými servery jako MySQL a PostgreSQL. Nevýhodou je, že Rails dobře neškáluje pro velké množství dotazů na aplikaci. To by mohlo vést k problémům, jelikož náš systém bude komunikovat s mobilními aplikacemi backendem. Python je open sourcový víceparadigmatický skriptovací jazyk s instalačními balíky pro většinu běžných platforem. Pro vývoj webových aplikací nabízí několik různých frameworků. Python je jednoduchý na naučení, zdrojový kódy jsou krátké a snadno čitelné a rychlost výsledných programů bývá velmi dobrá. Mezi nevýhody patří, že programy je třeba speciálně upravovat pro platformovou nezávislost, pokud mají fungovat na systémech Windows i Linuxových platformách. C# .NET je společně s Javou nejmodernější a nejpoužívanější platforma pro vývoj takzvaných business aplikací. Nicméně byl vyvinutý společností Microsoft a tak je velmi úzce provázán se systémy Windows. Nesplňuje tedy požadavek na multiplatformovost. Java [2] je jeden z nejoblíbenějších programovacích jazyků a její enterprise edice (J2EE) je široce využívána ve světě komerčních webových aplikací. Od roku 2007 je dostupná pod open sourcovou licencí GNU General Public License. Cílem při vytváření Javy bylo vytvořit jazyk, který bude jednoduchý, objektově orientovaný, robustní, bezpečný, multiplatformní, výkonný, dynamický, interpretovaný a podporující operace s vlákny. Pro nás je velmi důležitá především multiplatformovost. Javové programy jsou kompilovány do univerzálního bytekódu, který je následně spouštěn na JVM (Java Virtual Machine - běhové prostředí javy) pro konkrétní hardware. V praxi je tak možné jeden program spouštět na téměř libovolné kombinaci hardwaru 12

a operačního systému. Javové programy je možné nasadit na obrovské množství aplikačních serverů (Tomcat, Jetty, GlassFish a další) a tím pádem je pro uživatele velmi jednoduché tyto aplikace používat. Z výše uvedených důvodů použijeme právě Javu i pro náš systém.

3.2 Databáze Data budeme uchovávat v open sourcové databázi založené na SQL (Structured Query Language strukturovaný dotazovací jazyk pro relační databáze). Blíže se podíváme na SQLite, MySQL a PostgreSQL. SQLite je velmi rychlá a nenáročná databáze, napsaná jako knihovna použitelná aplikacemi ve všech možných jazycích (Java je jedním z nich). Všechna data jsou uložena v jednom souboru, takže je snadno přenositelná. Nicméně nepodporuje přístup více uživatelů a je zaměřena spíše na použití desktopovými aplikacemi. MySQL patří mezi nejoblíbenější bezplatné databáze, i když má i placenou verzi, je multiplatformní a lze ji nainstalovat jako samostatný databázový server. Je jednoduché ji začít používat a mezi její hlavní přednosti patří rychlost, především operací čtení. Několikanásobné současné operace čtení a zápisu jsou však již pomalejší. Také plně neimplementuje ANSI/ISO standart pro SQL databáze, takže převod databáze na jiný SQL server může být problematický. PostgreSQL je nejpokročilejší open source databáze s největším množstvím různých funkcí a podporovaných datových typů. Původně byla vyvíjena pro Linuxové systémy, ale v současnosti je dostupná pro všechny běžné operační systémy a splňuje standard ANSI-SQL:2008. PostgreSQL nabízí široké možnosti přizpůsobení, může tedy být obtížnější na použití a nasazení. Výběr mezi MySQL a PostgreSQL závisí na konkrétním zamýšleném použití a pro tuto práci jsou obě dvě naprosto adekvátní. Na základě osobních preferencí tedy vybereme PostgreSQL.

13

4 Vývoj V této kapitole se podíváme na implementační detaily systému. V první podkapitole nejdříve vytvoříme ERD (Entity Relationship Diagram - objektově relační diagram) datový model. V průběhu postupně popisujeme jednotlivé části, celý diagram se nachází na konci podkapitoly. V datovém modelu používáme obecné datové typy, nikoliv typy specifické pro PostgreSQL. Ve druhé podkapitole vytvoříme diagram tříd a jednotlivé třídy podrobně popíšeme v podkapitolách. V nich se také budeme věnovat použitým algoritmům a možnostem konfigurace systému. Všechny algoritmy budou psané pseudokódem, nebude-li uvedeno jinak.

4.1 Datový model Nejdůležitější entitou systému je pro nás bod zájmu. Začneme tedy modelovat od něj. V rámci modelu budeme entitu POI nazývat Loc ati o n . Entita je určena automaticky generovaným atributem l oc ati o ni d a má čtyři povinné atributy nezbytné pro vyhledávání a zobrazení uživateli. Těmi jsou GPS souřadnice typu float (číslo s plovoucí desetinou čárkou) reprezentované dvojicí latit ude a l o n git ude , jméno POI lo ca ti o n na m e a atribut p u bl is h ed typu boolean (logická hodnota), který určuje, jestli je POI možné vyhledávat a zobrazovat uživateli. Entita Lo ca ti o n má také volitelné atributy addre s s , ci ty a de sc r ip ti o n uchovávající informace

o adrese a popis POI, atribut typ e definovaný administrátorem systému (možnostem přizpůsobení systému se budeme věnovat v jedné z dalších kapitol) a atribut ad mi ss i o n typu boolean určující jestli je na POI vyžadováno vstupné. Hodnocení POI umožňuje dvojice celočíselných atributů sc o re , celkový součet všech hodnocení, a rated , počet hodnocení. Průměrné hodnocení je vždy vypočítáno ve chvíli, kdy je na něho vznesen dotaz. Hodnotící škála je také definována administrátorem, musí však být založena na číselném hodnocení. Posledním nepovinným atributem je h ou r si d . Cizí klíč odkazující na entitu H ou r s , sloužící k uchování otvírací doby. Nepovinné atributy nemusí mít žádnou hodnotu, jedná se o tzv. nulable typy. Vztah mezi entitami Lo c ati o n a H ou r s je asociace jedna ku jedné, průchozí směrem od Lo ca ti o n k H o u rs . Tedy jeden POI může mít pouze jednu tabulku otevírací doby a v entitě H o u rs nedržíme odkaz na POI, ke které patří. Hou r s má primární klíč h ou r si d a dvojici

atributů typu datetime (typ pro ukládání času a data) pro každý den (např. m o nda ybe g a mo n day e nd ) určující začátek a konec otevírací doby.

14

Obrázek 4.1: Entity Location a Hours.

Další entita mající vztah k primární entitě Loc ati o n je entita Ev ent , tedy entita reprezentující událost. Má primární klíč ev e nti d a cizí klíč lo cat io n id odkazující na POI ke kterému patří. Událost musí být vždy přiřazena k nějakému POI. Povinnými atributy jsou nam e , jméno události, a p ubl is h ed , ten má stejný význam jako u entity Loca ti o n . Volitelné atributy jsou des c rip ti o n , popis události, admi ss i o n , opět stejný význam jako u Loc L ati o n , a dvojice sta r td ate a e ndd at e udávající datum a čas začátku a konce události. Událost může mít pouze

čas začátku, ale ne pouze čas konce a ten musí čas začátku následovat.. Souslednost časů je hlídána v kódu obslužné třídy. y. Jeden POI může mít přiřazeno více událostí. Máme tedy vazbu asociace jedna ku N. Vazba je udržována v entitě Ev en t . Chceme-li Chceme najít všechny události patřící k POI, musíme prohledat tabulku Ev ent na atribut l oc at i on id .

Obrázek 4.2: Entita Event.

15

V systému se nachází dva typy uživatelů, administrátor a běžný uživatel. Jsou reprezentováni entitou Use r s atributem use rt yp e rozlišujícím typ uživatele a primárním klíčem use ri d . Dalšími povinnými atributy jsou use rn a me , jméno, pod kterým uživatel vystupuje v systému, h as h , zahashovaná podoba uživatelova hesla, a sal t , náhodný řetězec znaků připojovaný k heslu

pro větší bezpečnost. Mezi nepovinné atributy patří em ai l , emailová adresa umožňující ověření a komunikaci s uživateli, na me , jméno uživatele, su r na me , příjmení uživatele, age , věk uživatele, a add re ss , adresa uživatele. S výjimkou atributu a ge jsou všechny nepovinné atributy textového typu. Korektnost vstupních dat musí být hlídána mimo systém. To platí obzvláště pro email. Uživatelé mohou mít několik různých vazeb na lokace. Dvě z těchto vazeb jsou uchovávány v entitě Use rL o cat i o nR ele at i on . Primární klíč entity je id , kromě něho má entita dva cizí klíče pro uživatele a POI, a to use r id a l o ca ti o ni d . Typ vazby je uchováván v atributu typ e , a smí

nabývat

hodnot

favorite

pro

oblíbené

POI

a

visited

pro

navštívené.

U se rL o ca ti o nR el eat i o n je vazební entita. Každý uživatel smí mít jednu vazbu favorite

a jednu vazbu visited pro konkrétní POI, ale každou z vazeb smí mít pro libovolný počet POI. Jedná se o vazbu M ku N rozdělenou na dvě vazby 1 ku N. Třetí typ vazby je reprezentován entitou Rated . Tato entita uchovává informace o tom, které POI uživatel hodnotil, a také vlastní hodnocení. To umožňuje později toto hodnocení změnit. Entita obsahuje tři atributy. Dva z nich jsou cizí klíče us er id a l o ca ti o ni d , tvořící dohromady kompozitní primární klíč entity. Třetí atribut je celočíselný rati n g pro uložení hodnocení. Uživatelé mohou hodnotit libovolný počet POI, každý však pouze jednou. Uživatelé mohou jako navštívené označovat také události. Tato vazba je zachycena vazební entitou Visit edEv e nt . Entita obsahuje pouze dva cizí klíče use rid a ev e nti d tvořící kompozitní klíč entity.

16

Obrázek 4.3: Entita User se všemi vazebními entitami.

Uživatelé mohou nahrávat z POI logy s připojenými daty, která jsou uložena do databáze. Pro spojení dat logu s uživatelem slouží entita Us e rL o g . Entita má opět primární klíč id a dva cizí klíče use rid a l oc ati o n id pro provázání s uživatelem a POI.. Pro ověření místa pořízení logu slouží atributy latit ud e a l on g it ude s GPS souřadnicemi. V atributu times ta mp je čas pořízení logu a v atributu not e případná poznámka přidaná uživatelem. uživatelem Logů může být z libovolného POI nahráno libovolné množství.

Obrázek 4.4: Entita UserLog.

17

Obrázek 4.5: ERD se všemi entitami a vazbami.

4.2 Diagram tříd V diagramu tříd se nachází čtyři entitní třídy, které které jsou téměř totožné s entitami datového modelu, takže se jim nebudeme blíže věnovat, a čtyři třídy starající se o správu POI, událostí, uživatelů

a

logů.

Se

třídou

Lo ca ti o n Ma n a ge r

úzce

spolupracují

třídy

Lo ca ti o n Dat aC o le ct o r , starající se o automatizovaný automatizovan sběr dat, Sea rch St ri n gB ui ld e r ,

vytváří vyhledávací SQL dotazy, a třída GPS Ca lc ul a to r provádějící výpočty s GPS souřadnicemi a její soukromá třída Dis ta nc eC o mp a r at o r . Třída P as s wo r d Ma na g e r hashuje a ověřuje hesla, JS ON M o du le převádí javové objekty do podoby podoby vhodné pro přenos po internetu. Komunikace

se

systémem

je

zprostředkovaná

dvěma

servlety

Loc ati o n sSe rv le t

a Us e rC o nf i gS e rv l et . Třídy podrobně popíšeme v následujících podkapitolách.

18

Obrázek 4.6:: Diagram tříd.

19

4.2.1

Správa a vyhledávání POI

Třída Lo cat i o nM a na g er slouží pro správu POI. Vytvořit POI lze pomocí metody cr ea te Lo ca ti o n , která vyžaduje jako parametr objekt Loc ati o n . Ten získáme z konstruktoru

stejnojmenné třídy. Create L oc ati o n podle typu uživatele ověřuje, zda má tento uživatel oprávnění POI vytvářet. Administrátoři mají oprávnění vždy, u běžných uživatelů ho lze nastavit v konfiguračním XML souboru co n fi g u ra ti o n .x m l v elementu <us e rL o cat i o n> nastavením na hodnotu true. Pro získání POI z databáze slouží čtyři metody. GetL oc ati o n vyhledává podle primárního klíče POI, getL oc at i on By N am e podle jména POI a a getL oc ati o ns vrátí seznam všech POI v databázi. Čtvrtou metodou je sea rc h , které dáme za parametr databázový dotaz v podobě textového řetězce vytvořeného třídou Sea rc h St r in g Bu il de r , a která z databáze vybere POI podle uživatelských filtrů. Třída Sea rch St ri n g Bu i lde r obsahuje metodu cr ea te Qu e ry , která bere jako parametr mapu s parametry pro filtrování předané uživatelem. O komunikaci mezi uživateli a systémem budeme psát dále. Metoda cr ea te Qu e ry vytvoří základní dotaz a poté projde předanou mapu a pro každý nalezený filtr mezi klíči přidá k dotazu odpovídající řetězec obsahující hodnotu klíče. Po projití všech dvojic z mapy vrátí hotový databázový dotaz. Algoritmus pro vytvoření dotazu metodou cre ate Q u er y . F ORE AC H K ey I N M a p IF K ey = ‘ ad mi ss i o n’

Připoj k dotazu řetězec obsahující hodnotu Value . IF K ey = ‘t yp e ’

Připoj k dotazu řetězec obsahující hodnotu Value . IF K ey = ‘ cit y’

Připoj k dotazu řetězec obsahující hodnotu Value . EN DF ORE ACH

Filtrovat POI můžeme podle typu, města a podle toho, jestli je na daném místě vyžadováno vstupné. Typy POI jsou definovány v souboru con fi g ur at i on . x ml následující strukturou: j mé n o t yp u

4.2.2

Automatizovaný sběr dat

Přidávání velkého množství dat ručně je časově náročné a nepohodlné. Vytvořil jsem tedy třídu Lo ca ti o n Dat aC o ll ec to r , která tento úkon automatizuje. V této třídě využívám open

sourcovou knihovnu jsoup [X]. Jsoup slouží pro parsování, extrakci a manipulaci s daty z webových 20

stránek. Umí pracovat s online stránkami i HTML dokumenty uloženými lokálně. Budeme využívat toho, že jsoup umí vyhledávat elementy na stránce podle CSS (Cascading Style Sheets - kaskádové styly) selektoru. Můžeme tak získat všechny elementy stejného typu. Před zahájením sběru dat je potřeba nakonfigurovat jejich zdroje v souboru lo cda ta. x m l . Ukázkový konfigurační XML soubor pro nastavení zdrojů dat. < re s ou r ce> < re s o ur ce Ty p e >< ! -- web n eb o l oc al -- > < u rl s> < u r l> ww w . n ej ak a- ad r es a. c o m< /u r l> < /u r ls > .t r id a e le me nt < in f o r ma ti o n s> < n a me> . naz ev -l ok ac e< / na me > < l ati tu de> . l at< /l at itu de > < l o n gi tud e> .l o n < ci ty> . me st o< /c ity > < ad d re ss >. a dr es a< add r es s> < de sc r ip t i o n>p o p i s < typ e>t yp < t yp e> < /i n f o rm at i on s >

Každý je skupina URL (Uniform Resource Locator - jednotná adresa zdroje) se stejnou strukturou a nastaveními pro sběr dat. Může se jednat o různé webové stránky, i když v tomto případě je nepravděpodobné, že by měly stejné CSS lokátory, části jedné webové stránky (např. seznamy POI začínajících na stejné písmeno) nebo stejně strukturované HTML dokumenty uložené

lokálně.

Třída

Lo cat i o nD at aC ol ec to r

má

jedinou

veřejnou

metodu

co le ct L oc ati o n Da ta . Ta řídí sběr dat, vkládá nalezené POI do databáze a volá pomocné

metody. Svůj běh opakuje pro všechny elementy . Pro každý element z l ocd at a. x m l nejdříve zavolá metodu op enR es o ur ce . Ta podle < re s ou r ce Typ e> vybere vhodnou metodu z knihovny jsoup, pomocí které otevře zdroj na zadané URL, a vrátí volající

21

metodě objekt typu XML dokument (org.w3c.dom.Document). Element má povolené dvě hodnoty. W eb pro online internetové stránky a loc a l pro HTML soubory uložené lokálně. Poté se metoda cole ct Lo ca ti o n Dat a podle elementu <deta il s Typ e> rozhodne, jakým způsobem bude pokračovat ve sběru dat. Element <deta il s Typ e> může nabývat hodnot p age a ele me nt a určuje strukturu, jakou jsou ve zdrojovém HTML dokumentu uloženy informace o POI. Pa ge znamená, že každý POI má vlastní stránku s informacemi, to bývá většinou případ živých webových stránek. Typ elem e nt znamená, že na jedné stránce jsou informace o více POI. To bude většinou případ HTML dokumentu předpřipraveného pro automatizované zadání POI do databáze. Pokud má každý POI vlastní stránku s detaily, metoda najde všechny odkazy na tyto stránky podle elementu <deta i lL o cat o r > , každý z těchto odkazů otevře jako nový dokument a zavolá metodu p ar se D eta il s s tímto dokumentem jako vstupním parametrem. Obdobně, pokud je hodnota <detai ls Ty p e> e le me nt , metoda co le ct L oc ati o n Da ta vytvoří seznam všech elementů odpovídajících <det ai l L oc at o r> a na každý tento element zavolá p a rs eD eta il s . Metoda p a rs eD eta il s se podívá do elementu , který má

dceřiné elementy odpovídající atributům entity Loc at i on s . Tyto elementy jsou nepovinné. Pokud metoda element odpovídající danému atributu najde, získá z HTML dokumentu hodnotu tohoto atributu pomocí lokátoru, uloženého v tomto elementu. Metoda cole c tL oc ati o n Da ta z takto naparsovaných informací vytvoří objekt typu Loca ti o n

a předá ho třídě

Lo ca ti o n Ma n a ge r , která ho vloží do databáze POI.

Algoritmus automatizovaného sběru dat. F ORE AC H < re s ou r ce > I N < r es o u rc es > F ORE AC H < u rl > I N < ur l s> IF < re s ou r ce Ty p e> = = w eb TH E N Ot ev ř i < re s ou r ce> j ak o o n li n e s t rá n k u. ELS E O tev ř i < re s o ur ce> j ak o s o ub o r . EN DIF IF == p a ge TH E N

Na jd i

v š e ch ny

odk az y

na

st rá nc e

p o dl e

<de tai l L oc at o r >

a otev ř i n ov ý d ok u m en t j ak o ‘ det ai l Pa g e‘ . ELS E N a jdi v š ech n y ele m en ty na st rá nc e p od le <de ta i l L oc at o r >

jak o

‘de ta il P a ge ’ EN DIF F ORE AC H ‘ det ai l Pa g e’ IF H AS CH I LD < na me > 22

Zí sk e j z d ok u me nt u a tr ib ut na me . EN DIF IF H AS CH I LD Zí sk e j z d ok u me nt u a tr ib ut lat it ude . EN DIF IF H AS CH I LD Zí sk e j z d ok u me nt u a tr ib ut l on g it ude . EN DIF IF H AS CH I LD Zí sk e j z d ok u me nt u a tr ib ut c ity . EN DIF IF H AS CH I LD Zí sk e j z d ok u me nt u a tr ib ut a dd re s s. EN DIF IF H AS CH I LD Zí sk e j z d ok u me nt u a tr ib ut d es c rip ti o n . EN DIF IF H AS CH I LD Zí sk e j z d ok u me nt u a tr ib ut t yp e . EN DIF EN DF ORE ACH EN DF ORE ACH EN DF ORE ACH

POI přidané automatizovaným sběrem dat nejsou publikované, aby se do systému nedostaly nežádoucí nebo chybné informace. Administrátor je tedy musí zkontrolovat a publikovat manuálně. 4.2.3

Správa událostí

Pro správu událostí slouží třída Ev en tM a na g e r . Událost do systému přidáme, obdobně jako u třídy Loc at i on M a na ge r , metodou cre at eEv e nt , která vyžaduje vstupní parametr typu Ev e nt . Detailní informace o události můžeme získat metodou getEv e nt s primárním klíčem

události jako vstupním parametrem. Všechny události z databáze získáme metodou ge tEv e nt s . Událost musí být vždy spojená s POI, která může mít takto přiřazených událostí větší množství. Můžeme se tedy databáze dotázat na všechny události spojené s konkrétním POI metodou ge tEv e nt s In L oc at i on . Za vstupní parametr je vyžadován primární klíč POI.

23

4.2.4

Správa uživatelů

Třída Use r M an a ge r je nejsložitější ze skupiny manažerských tříd. Neobsahuje pouze metody pro správu uživatelů, ale také pro správu všech vazeb, které mohou uživatelé mít. Stejně jako předešlé třídy obsahuje metody pro vytvoření události z objektu odpovídající entitní třídy, vyhledání události podle primárního klíče a vyhledání všech událostí. Navíc umí vyhledávat uživatele

podle

uživatelského

jména

(jediný

povinný

atribut

kromě

id)

metodou

ge t Use r By U se r na m e .

Dále třída obsahuje tři podobné skupiny metod pro tři typy vazeb, které může mít uživatel s POI. Jedná se o vazby Oblíbené, Navštívené a Hodnocené. Všechny tři skupiny mají metodu pro získání všech POI s konkrétní vazbou k danému uživateli (getF av o r ite s, get V is it ed, get Ra ted ). Skupiny pro oblíbené a navštívené POI mají metodu, která zjistí, zda má uživatel vazbu s POI (isF av o r ite , i sV is it e d ) a umožňují přidání vazby (addF av o r ite , a dd Vi sit ed ). Tyto metody vyžadují jako parametry id uživatele a POI. Kromě toho uživatel může POI odebrat z oblíbených metodou rem ov eF av o rit e . Pro zjištění, zda uživatel nějaké POI již hodnotil, slouží metoda getR ati n g , opět s id uživatele a POI jako parametry. Pokud metoda vrátí prázdnou hodnotu null, uživatel POI nehodnotil. Přidat POI mezi hodnocené nelze přímo. Tato vazba vznikne jako důsledek ohodnocení POI uživatelem. To se provádí metodou rate L oc ati o n . Tato metoda má tři číselné vstupní parametry. Id uživatele, id POI a samotné hodnocení. Škála hodnocení je definována v souboru co n fi g u ra ti o n .x m l elementy <min Rat i n g> a <m a xRa ti n g> pro spodní a horní hranici

hodnocení. Pokud uživatel ještě konkrétní POI nehodnotil, přičte se hodnocení k atributu sc o re instance POI v databázi a atribut r ate d se zvedne o jedna. Pokud uživatel již danou POI někdy hodnotil, odečte se nejdříve staré hodnocení (získané metodou getR at in g ) od atributu s c o re a poté se přičte nové hodnocení. Atribut rat ed se v tomto případě nezvyšuje. Po ohodnocení se vytvoří vazba hodnocení mezi uživatelem a POI. Algoritmus ohodnocení POI. IF ( o ld Rat i n g = g etR ati n g (u se r Id , lo ca ti o nI d) ) != n ul l Odeč ti

ol dR ati n g

od

sc o re

P OI

s id

lo ca ti o nI d

a

n a s t av

p ř íz na k

al re ad yRa ted = t r ue . EN DIF Př ič ti n ov ý ra ti n g k s co r e PO I . IF a l re ady Rat ed != t r ue Zv ed ni at r ib ut P OI r a ted o jed n a. EN DIF Vytv oř v az b u h o dn o c en í p r o us e rId a l oc a ti on Id . 24

4.2.5

Zabezpečení uživatelských hesel

Všechny uživatelské účty musejí být zabezpečené heslem. To je uložené jako atribut v entitě U se r v zahashované podobě. Hashování hesel a jejich následné ověřování je prováděno třídou Pa s sw o r dM a na g e r . Při vytváření hashe hesla, je nejprve vygenerován náhodný řetězec

nazývaný salt. Ten slouží pro zvýšení bezpečnosti hesla. Při jeho použití budou mít stejná hesla pokaždé jiný hash, slouží tedy jako ochrana proti slovníkovým útokům. K jeho vygenerování slouží metoda creat eS al t , která využívá kryptograficky bezpečný pseudonáhodný číselný generátor (CSPRNG - Cryptographically Secure Pseudo-Random Number Generator). CSPRNG oproti běžným pseudonáhodným generátorům poskytuje vysoký stupeň náhody a je naprosto nepředvídatelný. Vygenerovaný salt je uložen v entitě Use r daného uživatele. Vytváření vlastního hashe má na starost metoda h ash Pa ss w o rd . Jako vstupní parametry bere heslo zadané uživatelem a vygenerovaný salt a výsledný řetězec zahashuje PBKDF2WithHmacSHA1 algoritmem. PBKDF2 (Password Based Key Derivation Function) je kryptografická funkce, která z hesla a soli generuje hash opakovaným voláním pseudonáhodné funkce (v tomto algoritmu HmacSHA1). Výsledný hash je uložen v entitě Use r . K ověření hesla slouží funkce auth e nti ca te Us e r . Podle zadaného us er id nejdříve zjistí salt a hash hesla daného uživatele. Potom z tohoto saltu a nově zadaného

hesla vytvoří nový hash metodou h ash Pa ss w o r d . Tyto dva hashe porovná a vrátí logickou hodnotu true nebo false podle toho, jestli se hashe shodují nebo ne. 4.2.6

Ukládání uživatelských logů

Uživatelé mohou z POI pomocí mobilních aplikací nahrávat logy. Jejich ukládání do systému obstarává třída Use r L o g Ma n a ge r metodou create L o g . Vytvoření vlastního logu provádí servlet sloužící pro komunikaci (o servletech budeme mluvit v další části). Při vyhledávání logů máme několik možností. Pokud známe id žádaného logu, použijeme metodu getL o g . Metodou ge t Use r s L og s , které dáme id uživatele, získáme seznam všech logů nahraných daným

uživatelem. Na logy pro specifického uživatele a POI se můžeme zeptat metodou ge tSp eci f ic L o gs , za vstupní parametry použijeme id uživatele a POI. Pomocí této metody

můžeme ověřit, zda uživatel nějaký log pro POI již nahrál. Pokud ne, metoda vrátí hodnotu null. 4.2.7

Vyhledání POI v GPS datech

Hlavní funkcionalitou systému je vyhledávání POI v okolí uživatele podle zadaných GPS souřadnic. To obstarává třída GPSC al cu la t o r , pomocí metody get Nea r es tL o cat i o n , a s ní související třída Di sta n ceC o mp a r at o r . Ge t Ne a res tL o ca ti on přijme tři parametry, zeměpisnou šířku a délku a seznam POI. Tento seznam uspořádá podle vzdálenosti od zadaných souřadnic a vrátí ho volající metodě. Porovnání vzdálenosti má na starost třída Dista n ceC o mp a rat o r implementující rozhraní Co mp a ra to r . Tato třída má dvě metody comp ar e . První je 25

předepsaná rozhraním a jako vstupní parametry vyžaduje obecné objekty. Druhá metoda má jako vstupní parametry dva objekty typu Loc at i on , tyto přetypuje a zavolá první metodu. Výpočet vzdálenosti mezi GPS souřadnicemi je proveden metodou getDi st a nce Bet w ee nP o i nt s třidy G PS Ca lc u lat o r . Tato metoda bere na vstup dvě dvojice zeměpisné šířky a délky a vrátí

vzdálenost v metrech. Systém je určen k vyhledávání POI v blízkém okolí uživatele, vzdálenosti tedy počítáme v rovině se zanedbáním výšky a můžeme použít algoritmus založený na Pythagorově větě [3]. Pro zobrazení zemského povrchu v rovině se používá ekvidistantní válcová projekce (také Marinovo zobrazení). Je to jednoduchá kartografická projekce, jejímž výsledkem je mapa, na které jsou poledníky stejně daleko jako rovnoběžky. Vzdálenost dvou GPS bodů je zkreslená, nicméně u relativně blízkých bodů je toto zkreslení zanedbatelné a pro nás je důležité porovnání vzdáleností bodů, které jsou zkresleny všechny stejně, nikoliv zjištění přesné vzdálenosti. Metoda pro výpočet vzdálenosti mezi dvěma GPS body v jazyce Java. p r iv at e

d o ub le

ge tD ist a nc eBe tw ee n P oi nt s( d ou bl e

f r o m la t, d o ub le

f r om l o n ,

do ub le to l at , d o ub le to l o n) { d o ub le lat = t o Rad ia n (t o lat - f r om l a t); do ub le

lon

=

t o Rad ia n (t o l on

-

fr o ml o n )

*

Ma th . c o s( 0 . 5

*

to Rad ia n ( f r om l at + t o lat ) ); ret u r n e a rth R a diu s * M ath .sq r t( l at* l at +l o n* l o n); }

GPS souřadnice jsou zadané ve stupních, ale použité vzorce je vyžadují v radiánech. Pro převod mezi stupni a radiány slouží metoda toRa di a n třídy G PS Ca lc u lat o r . 4.2.8

Formát vyměňovaných dat

Pro přenos dat mezi systémem a dalšími aplikacemi jsem se rozhodl pro formát JSON (JavaScriptObjectNotation - JavaScriptový objektový zápis). „JSON je odlehčený formát pro výměnu dat. Je jednoduše čitelný i zapisovatelný člověkem a snadno analyzovatelný i generovatelný strojově. Je založen na podmnožině Programovacího jazyka JavaScript, Standard ECMA-262 3rd Edition - December 1999. JSON je textový, na jazyce zcela nezávislý formát, využívající však konvence dobře známé programátorům jazyků rodiny C (C, C++, C#, Java, JavaScript, Perl, Python a dalších). Díky tomu je JSON pro výměnu dat opravdu ideálním jazykem.“ [4] Třída JS O N M od ul e převádí javové objekty do formátu JSON a zpět. Informace o POI můžeme získat v základní a plné verzi prostřednictvím metod bas ic L oc ati o n In f o a f ul lL o cat i o nI n f o . Obě vyžadují jako vstupní parametr objekt třídy Loc ati o n . B ac is L oc ati o n I n f o zobrazí pouze 26

povinné atributy entity Loc at i on , fu ll L oc at i on I n f o zobrazí všechny, i pokud mají hodnotu null. Pro převedení seznamu POI do pole JSON objektů slouží metoda loc at i o ns I n f o . Obdobné metody pro převod informací o událostech jsou ev ent I n f o (zobrazí všechny informace) a ev en ts I nf o pro seznam událostí. Pro převod v opačném směru, tedy z JSON objektů, respektive pole, na javové objekty, slouží metody jso n T oL o cat i o n a js o n T o Lo ca ti o n s pro POI a jso nT o Ev e nt a j s o n T oEv e nt s pro události.

4.3 API Komunikace se systémem je implementována jako RESTful (Representational State Transfer architektura rozhraní, navržená pro distribuované prostředí) webová služba a probíhá prostřednictvím protokolu HTTP. Rozhraní REST se používá pro jednotný přístup ke zdrojům, kterými mohou být data stejně jako stavy aplikace. V systému jsou přístupné dva zdroje. Servlety Lo ca ti o n sSe rv le t , sloužící pro práci s POI, a U se rC o n fi g Se rv let odpovídající za práci

s uživateli. Oba servlety umí zpracovávat požadavky typu GET a POST. Jednotlivé funkce jsou volány podle části URI za jménem servletu a před dotazovacím řetězcem (tzv. extra path information). Dále v textu je budeme označovat jako fragmenty. URI zdroje tedy vypadá jako se rv e r / jm e no Se rv le t u/ f ra g me n t? p a r a met r y V následujících podkapitolách si popíšeme

funkce dostupné skrze servlety pro jednotlivé fragmenty. 4.3.1

LocationsServlet

locationInfo Fragment sloužící k získání základních informací o POI podle id. POI vyhledá pomocí třídy Lo ca ti o n Ma n a ge r a data pro odpověď připraví metoda basic L oc ati o n In f o třídy JS O N M od ul e .

Http metoda: GET Parametry: locationId moreInfo Téměř stejný jako fragment l oc at i on I n fo . Využívá metodu fu l L oc ati o n In f o pro tvorbu dat odpovědi. Http metoda: GET Parametry: locationId nearLocations Základní fragment pro vyhledávání blízkých POI. Jako parametry předané prostřednictvím URI vyžaduje zeměpisnou šířku, délku a žádaný počet POI. Najde zadaný počet nejbližších POI, ale neaplikuje žádné filtry. Primárně je určen pro nepřihlášené uživatele. 27

Http metoda: GET Parametry: latitude, longitude, take search Funkce pro pokročilé vyhledávání POI s filtrováním. Nejdříve uplatní filtry specifické pro POI, tedy typ POI, město a zda je na POI vyžadováno vstupné, pomocí metody se a rch třídy Lo ca ti o n Ma n a ge r . Na nalezené POI následně uplatní filtry týkající se uživatele. Tedy jestli se

mají zobrazovat oblíbené, navštívené a hodnocené POI. Výsledný seznam je uspořádán metodou ge t Nea r es tL o cat i o n ze třídy GPS Ca lc ul at o r a v http odpovědi je zaslán specifikovaný

počet nejbližších POI. Pro vyhledávání jsou povinné pouze parametry zeměpisných souřadnic a parametr tak e . Ostatní jsou volitelné. Http metoda: GET Parametry:latitude, longitude, take, type, city, admission, favorite, visited, rated createLocation Fragment zprostředkovávající vytvoření nového

POI pomocí metody http POST. Požadavek

obsahuje jeden nebo více POI ve formátu JSON a parametr amo u nt , udávající jestli se jedná o jeden nebo více objektů. POI jsou převedeny na javové objekty třídou JS O N M od ul e a následně přidány do systému třídou Loca ti o n Ma na g e r . Http metoda: POST Parametry: amount events Fragment zpřístupňující všechny události provázané s daným POI. Parametrem je id zmíněného POI. Pokud není zadáno, jsou vyhledány všechny události v databázi. Http metoda: GET Parametry: locationId eventInfo Fragment pro přístup k informacím o události. Parametrem je id události. Http metoda: GET Parametry: eventId createEvent Fragment se stejnou funkcí jako cre ate L oc ati o n pouze pro vytváření událostí. Http metoda: POST Parametry: amount 28

4.3.2

UserConfigServlet

createUser Fragment pro vytvoření nového uživatele v systému podobný fragmentu cre ate Lo ca ti o n . Opět pomocí třídy JSO N M od u le je z J SO N objektu vytvořen javový objekt entity U se r , který je následně do systému přidán třídou Use r Ma n a ge r . Fragment je bez parametrů. Http metoda: POST Parametry: addFavorite Fragment přidá POI mezi oblíbené položky uživatele. Vyžaduje id uživatele a POI jako parametry. Http metoda: POST Parametry: userId, locationId removeFavorite Fragment pro odebrání POI z oblíbených položek. Vyžaduje id uživatele a POI jako parametry. K mazání využíváme http metodu POST nikoliv DELETE. Http metoda: POST Parametry userId,locationId getFavorites Fragment získá všechny oblíbené položky podle id uživatele. Http metoda: GET Parametry: userId addVisited Obdobný fragment jako addF av o ri te , pouze pro navštívené POI. Http metoda: POST Parametry: userId, locationId getVisited Obdobný fragment jako getF av o rit es , pouze pro navštívené POI. Http metoda: GET Parametry: userId rateLocation Fragment umožňující ohodnocení POI. Za parametry vyžaduje id uživatele, POI a hodnocení. K hodnocení využívá stejnojmennou metodu rate L o cat i o n třídy Use r M an a ge r . Http metoda: POST 29

Parametry: userId, locationId, rating getRated Fragment získá seznam všech hodnocených POI podle id uživatele. Http metoda: GET Parametry: userId getRating Fragment zjistí hodnocení konkrétního POI daným uživatelem podle jejich id. Http metoda: GET Parametry: userId, locationId login Fragment slouží k autorizaci uživatele. Uživatelské jméno a heslo jsou předávány skrz parametry dotazu. Tento fragment by měl být využíván pouze přes zabezpečené http spojení. Autorizace je provedena třídou Pas s wo rd M a na ge r . Http metoda: GET Parametry: user, password createLog Fragment pro vytváření logů. Z přijatých parametrů vytvoří objekt entity Use r Lo g , ten předá třídě Use r L o g Ma n ag e r , která log uloží do databáze. Za parametry vyžaduje GPS souřadnice, čas pořízení a případný komentář uživatele. Http metoda: POST Parametry: latitude, longitude, timestamp, comment

30

5 Závěr Práci jsme začali vysvětlením základních pojmů a určením, co pro nás znamená POI. Podívali jsme se na existující alternativy a navrhli několik různých oblastní užití systému, s vytyčením bodů pro tyto oblasti důležitými. Určili jsme požadavky na systém a navrhli mobilní aplikaci, která by systém využívala. Následně jsme zvážili a vybrali technologie pro implementaci. Vytvořili jsme datový model a model tříd, na něm jsme podrobně popsali použité algoritmy a možnosti konfigurace systému. V poslední části práce jsme rozebrali rozhraní pro komunikaci. Systém je možné využít pro široké spektrum oblastí a je možné ho provozovat na téměř všech běžných systémech.

31

Literatura [1] Úřad pro veřejné informační systémy, Terminologický výkladový slovník pojmů, ISSN 1213225X, 2001. [cit. 2015-05-05]. Dostupné z: http://www.gisportal.cz/wpcontent/uploads/2013/08/Terminologický-výkladový-slovník-pojmů.pdf [2] Java EE 5 development with NetBeans 6develop professional enterprise Java EE 5 applications quickly and easily with this popular IDE. Edited by David R. Heffelfinger. Birmingham, U.K.: Packt Publishing Ltd., 2008. iv, 384 p. ISBN 9781847195463. [3] VENESS, Chris. Calculate distance, bearing and more between Latitude/Longitude points: Equirectangular approximation [online]. [cit. 2015-05-05]. Dostupné z: http://www.movabletype.co.uk/scripts/latlong.html [4]Úvod do JSON [online]. [cit. 2015-05-05]. Dostupné z: http://www.json.org/json-cz.html

32