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

Transkript

1 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

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

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

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

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

6 Obsah 1 Úvod Analýza Alternativy Mapové portály Aplikace pro správu a manipulaci s GPS daty Oblasti užití Šifrovací hry Turistické známky Pojišťovny Vyhledávání restaurací Analýza požadavků Návrh mobilní aplikace Technologie Programovací jazyk Databáze Vývoj Datový model Diagram tříd Správa a vyhledávání POI Automatizovaný sběr dat Správa událostí Správa uživatelů Zabezpečení uživatelských hesel Ukládání uživatelských logů Vyhledání POI v GPS datech Formát vyměňovaných dat API LocationsServlet UserConfigServlet Závěr

7 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

8 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 Délku ortodromy d v kilometrech dostaneme rovnicí: ( sinu1sinu 2 + cosu1cosu 2 cos ( V 2 V1) ) d = σ R π 180 3

9 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 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 ( a Google 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

10 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 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 ( a GPS Utility ( 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ší Š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

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

12 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

13 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, 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. 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é 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é, hodnotit a nahrávat logy. Logy budou obsahovat zeměpisné souřadnice, čas a datum pořízení a komentář, které bude uložen do databáze 8

14 a provázán s uživatelem a 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 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 Návrh mobilní aplikace Realizace mobilní 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 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 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. Trasa se aktualizuje na požádání. Na obrázku 2.3 můžeme vidět návrh uživatelského rozhraní. 9

15 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í 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. Tlačítko Přihlásit se zobrazí přihlašovací dialog, tlačítko Hledej znovu vyhledá POI v okolí s aplikací zvolených filtrů a tlačítko Filtry otevře podmenu 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 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 podniku dát. V tom okamžiku se aktivuje 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 vybral hodnocení, ale ještě jej neodeslal. 10

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

17 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

18 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

19 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 Location. Entita je určena automaticky generovaným atributem locationid 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í latitude a longitude, jméno POI locationname a atribut published typu boolean (logická hodnota), který určuje, jestli je POI možné vyhledávat a zobrazovat uživateli. Entita Location má také volitelné atributy address, city a description uchovávající informace o adrese a popis POI, atribut type definovaný administrátorem systému (možnostem přizpůsobení systému se budeme věnovat v jedné z dalších kapitol) a atribut admission typu boolean určující jestli je na POI vyžadováno vstupné. Hodnocení POI umožňuje dvojice celočíselných atributů score, 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 hoursid. Cizí klíč odkazující na entitu Hours, sloužící k uchování otvírací doby. Nepovinné atributy nemusí mít žádnou hodnotu, jedná se o tzv. nulable typy. Vztah mezi entitami Location a Hours je asociace jedna ku jedné, průchozí směrem od Location k Hours. Tedy jeden POI může mít pouze jednu tabulku otevírací doby a v entitě Hours nedržíme odkaz na POI, ke které patří. Hours má primární klíč hoursid a dvojici atributů typu datetime (typ pro ukládání času a data) pro každý den (např. mondaybeg a mondayend) určující začátek a konec otevírací doby. 14

20 Obrázek 4.1: Entity Location a Hours. Další entita mající vztah k primární entitě Location je entita Event,, tedy entita reprezentující událost. Má primární klíč eventid a cizí klíč locationid 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 name, jméno události, a published,, ten má stejný význam jako u entity Location.. Volitelné atributy jsou description,, popis události, admission, opět stejný význam jako u Location, a dvojice startdate a enddate 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. 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ě Event.. Chceme-li najít všechny události patřící k POI, musíme prohledat tabulku Event na atribut locationid. Obrázek 4.2: Entita Event. 15

21 V systému se nachází dva typy uživatelů, administrátor a běžný uživatel. Jsou reprezentováni entitou User s atributem usertype rozlišujícím typ uživatele a primárním klíčem userid. Dalšími povinnými atributy jsou username, jméno, pod kterým uživatel vystupuje v systému, hash, zahashovaná podoba uživatelova hesla, a salt, náhodný řetězec znaků připojovaný k heslu pro větší bezpečnost. Mezi nepovinné atributy patří , ová adresa umožňující ověření a komunikaci s uživateli, name, jméno uživatele, surname, příjmení uživatele, age, věk uživatele, a address, adresa uživatele. S výjimkou atributu age 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 . Uživatelé mohou mít několik různých vazeb na lokace. Dvě z těchto vazeb jsou uchovávány v entitě UserLocationReleation. Primární klíč entity je id, kromě něho má entita dva cizí klíče pro uživatele a POI, a to userid a locationid. Typ vazby je uchováván v atributu type, a smí nabývat hodnot favorite pro oblíbené POI a visited pro navštívené. UserLocationReleation 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 userid a locationid, tvořící dohromady kompozitní primární klíč entity. Třetí atribut je celočíselný rating 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 VisitedEvent. Entita obsahuje pouze dva cizí klíče userid a eventid tvořící kompozitní klíč entity. 16

22 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 UserLog.. Entita má opět primární klíč id a dva cizí klíče userid a locationid pro provázání s uživatelem a POI. Pro ověření místa pořízení logu slouží atributy latitude a longitude s GPS souřadnicemi. V atributu timestamp je čas pořízení logu a v atributu not e případná poznámka přidaná uživatelem. Logů může být z libovolného POI nahráno libovolné množství. Obrázek 4.4: Entita UserLog. 17