Mendelova univerzita v Brně Provozně ekonomická fakulta
Využití metadat digitálních fotografií v oblasti GIS Diplomová práce
Vedoucí práce: Ing. Mgr. Jana Dannhoferová, Ph.D.
Bc. Jakub Hemala
Brno 2011
2
3
Děkuji touto cestou vedoucí mé práce Ing. Mgr. Janě Dannhoferové, Ph.D. za in-‐‑ spiraci při upřesnění zadání práce, ochotu, trpělivost a cenné připomínky, které mi během zpracování práce poskytla. Dále děkuji panu Ing. Davidu Procházkovi, Ph.D. za přínosné konzultace v oblasti problematiky mapových aplikací a GIS.
4
Prohlašuji, že jsem tuto práci vyřešil samostatně s použitím literatury, kterou uvá-‐‑ dím v seznamu.
Abstrakt Hemala, J. Využití metadat digitálních fotografií v oblasti GIS. Diplomová práce. Brno 2011 Tématem diplomové práce je analýza současných možností využití metadat foto-‐‑ grafií v oblasti geografických informačních systémů a navržení systému na bázi webového mapového serveru podporujícího inovativní způsob přiřazování foto-‐‑ grafií, respektive fotografických alb, mapovým vrstvám mapového serveru, na zá-‐‑ kladě GPS údajů obsažených v metadatech fotografií. Dále jsou aplikovány po-‐‑ znatky z teorie grafů pro implementaci funkcionality vyhledávání tras na mapě v závislosti na zvolených fotografiích nalézajících se v mapě. Klíčová slova fotografie, metadata, geodata, vyhledávání, webová mapová služba, mapový ser-‐‑ ver, trasování
Abstract Hemala, J. Application metadata of digital photos in GIS domain. Thesis. Brno 2011 The topic of thesis is the analysis of the current possibilities for using photos metadata in geographic information systems domain and devising a system based on a web map server, that support innovative way of association photos or photo albums into map layers of the mapserver, based on GPS data contained by the metadata of photos. Furthermore, applied knowledge of graph theory to imple-‐‑ ment the functionality of search routes on the map, depending on the selected photographs situated on the map. Keywords photos, metadata, geodata, searching, web map services, map server, trace plan-‐‑ ning
6
7
Obsah 1 ÚVOD A CÍL PRÁCE ............................................................................................................. 10 1.1 ÚVOD .................................................................................................................................. 10 1.2 CÍL PRÁCE ........................................................................................................................... 11 3 METODIKA ............................................................................................................................. 12 4 TEORETICKÁ VÝCHODISKA ............................................................................................ 15 4.1 GEOGRAFICKÉ INFORMAČNÍ SYSTÉMY A GEODATA ......................................................... 15 4.2 MAPOVÉ VRSTVY ................................................................................................................ 15 4.2.1 Vektorové mapové vrstvy ............................................................................................. 15 4.2.2 Rastrové mapové vrstvy ............................................................................................... 16 4.3 TECHNOLOGIE GIS ............................................................................................................. 17 4.3.1 Funkcionalita GIS ........................................................................................................ 17 4.3.2 Technologie webových serverů ..................................................................................... 18 4.3.3 Webové služby .............................................................................................................. 19 4.4 WEBOVÉ SLUŽBY A GEODATA ............................................................................................ 20 4.4.1 Web Map Service ......................................................................................................... 21 4.4.2 Web Feature Service ..................................................................................................... 22 4.4.3 Web Coverage Service .................................................................................................. 22 4.4.4 Keyhole Markup Language .......................................................................................... 23 4.5 MAPOVÝ SERVER ................................................................................................................ 23 4.5.1 Common Gateway Interface ......................................................................................... 24 4.5.2 Princip fungování mapového serveru .......................................................................... 24 4.6 SOUŘADNÉ SYSTÉMY .......................................................................................................... 25 4.6.1 Referenční plocha ......................................................................................................... 25 4.6.2 Kartografické zobrazení ................................................................................................ 26 4.6.3 Křovákovo zobrazení .................................................................................................... 26 4.7 NEKOMPATIBILITA KARTOGRAFICKÝCH PROJEKCÍ .......................................................... 26 4.8 METADATA FOTOGRAFIÍ .................................................................................................... 27 4.8.1 Exif ............................................................................................................................... 27 4.8.2 IPTC (IIM) ................................................................................................................... 28 4.8.3 XMP ............................................................................................................................. 28 4.8.4 Formát DNG ................................................................................................................ 28 4.8.5 Specifikace formátu DNG ............................................................................................ 29 4.9 GPS TAGY STANDARDU EXIF ............................................................................................. 30 5 ANALÝZA DOSTUPNÝCH METOD ................................................................................. 32 5.1 DESKTOPOVÉ APLIKACE ..................................................................................................... 32 5.1.1 Google Earth ................................................................................................................. 32 5.1.2 Zoner Photo Studio ...................................................................................................... 32 5.1.3 Adobe Photoshop Elements .......................................................................................... 33 5.1.4 iPhoto ........................................................................................................................... 34 5.2 WEBOVÉ APLIKACE ............................................................................................................ 34 5.2.1 Google Maps ................................................................................................................. 35 5.2.2 Mapy ............................................................................................................................ 35 5.3 VYHODNOCENÍ ANALÝZY DOSTUPNÝCH METOD ............................................................ 36
8
6 METODY VÝVOJE A POSTUP REALIZACE ................................................................... 38 6.1 PROTOTYPOVÝ PŘÍSTUP ...................................................................................................... 39 6.2 SPIRÁLOVÝ PŘÍSTUP ............................................................................................................ 39 6.3 MODIFIKACE ZÁKLADNÍCH FÁZÍ CYKLU SPIRÁLY ............................................................ 40 6.3.1 Specifikace a Analýza požadavků ................................................................................. 40 6.3.2 Vyhodnocení požadavků ............................................................................................... 41 6.3.3 Navrhnutí prototypu a vhodných metod ..................................................................... 42 6.3.4 Implementace prototypu ............................................................................................... 42 6.3.5 Testování prototypu vývojářem a uživateli ................................................................. 42 6.3.6 Vyhodnocení relevantních připomínek uživatelů ........................................................ 42 6.3.7 Plán pro příští iteraci ................................................................................................... 42 6.4 NÁSTROJE PRO IMPLEMENTACI APLIKACE ....................................................................... 42 6.4.1 Jazykové nástroje a metody .......................................................................................... 42 6.4.2 Programové nástroje .................................................................................................... 44 6.5 POSTUP REALIZACE SYSTÉMU ............................................................................................ 45 7 VLASTNÍ ŘEŠENÍ .................................................................................................................. 47 7.1 IMPLEMENTACE VLASTNÍHO MAPOVÉHO SERVERU ......................................................... 47 7.1.1 Vytvoření vhodné adresářové struktury ...................................................................... 47 7.1.2 Instalace webového serveru .......................................................................................... 47 7.1.3 Instalace vlastního mapového serveru .......................................................................... 49 7.1.4 Získání vhodných mapových podkladů ........................................................................ 49 7.1.5 Konfigurace mapového serveru .................................................................................... 50 7.1.6 Návrh webového rozhraní pro práci s mapserverem .................................................... 53 7.1.7 Naprogramování ovládacích prvků mapy .................................................................... 54 7.2 DATABÁZE PRO UCHOVÁNÍ INFORMACÍ O FOTOGRAFIÍCH ............................................. 57 7.3 APLIKACE PRO PRÁCI S RELEVANTNÍMI METADATY FOTOGRAFIÍ ................................... 58 7.4 NAHRÁVÁNÍ FOTOGRAFIÍ .................................................................................................. 59 7.5 REPREZENTACE FOTOGRAFIÍ NA MAPĚ ............................................................................. 63 7.5.1 Využití Google Maps API ............................................................................................ 63 7.5.2 Vlastní zobrazování fotografií ...................................................................................... 64 7.6 VYTVÁŘENÍ FOTOGRAFICKÝCH ALB .................................................................................. 67 7.6.1 Princip slučování fotografií do alb ............................................................................... 67 7.6.2 Výběr vhodného algoritmu pro výpočet vzdálenosti .................................................... 69 7.7 REALIZACE MODULU PRO VYHLEDÁVÁNÍ TRAS ............................................................... 71 7.7.1 Vstupní data a volba algoritmu .................................................................................... 71 7.7.2 Implementace vyhledávání tras .................................................................................... 72 7.8 INTEGRACE SOUČÁSTÍ SYSTÉMU ........................................................................................ 74 7.9 SHRNUTÍ VÝSLEDKŮ ........................................................................................................... 74 7.10 PLÁN ROZVOJE PROJEKTU .................................................................................................. 75 7.10.1 Komerční a nekomerční distribuce ............................................................................. 75 7.10.2 Distribuční cesty ........................................................................................................ 75 7.10.3 Technologický rozvoj aplikace .................................................................................... 76 8 DISKUSE A ZÁVĚR ............................................................................................................... 78 8.1 DISKUSE .............................................................................................................................. 78
9
8.2 PŘÍNOS PRÁCE ..................................................................................................................... 79 8.3 ZÁVĚR ................................................................................................................................. 80 9 POUŽITÁ LITERATURA ...................................................................................................... 81 10 PŘÍLOHY ................................................................................................................................ 83 10.1 TECHNOLOGICKÉ MOŽNOSTI PŘIŘAZENÍ GPS INFORMACÍ ............................................. 83 10.1.1 Zápis fotoaparátem ..................................................................................................... 83 10.1.2 Zápis pomocí dodatečného zařízení ............................................................................ 83 10.2 OBRAZOVÝ DOPLNĚK K ANALÝZE DOSTUPNÝCH METOD ............................................... 84
10
1 Úvod a cíl práce 1.1 Úvod V současnosti se World Wide Web rychle stává standardní platformu pro geogra-‐‑ fické informační systémy (GIS) a množství rozličných geografických služeb stále stoupá. Do segmentu mapových služeb vstupují další poskytovatelé a přichází s novými možnostmi a využitími GIS. Se zvyšující se dostupností a různorodostí geografických informací distribuovaných pomocí internetu, rostou také nároky na funkcionalitu geografických informačních systémů a požadavky na jednoduché a intuitivní GUI (Graphic User Interface). Díky těmto tlakům a konkurenčnímu boji o koncového uživatele nabízených služeb je vývoj v oblasti rychlý. Nadále je nedostatečné poskytnout uživateli pouze digitalizované mapové pod-‐‑ klady, ale je kladen důraz na dodatečné služby související s využitím mapových služeb. Běžné jsou různorodé aktuální mapové podklady (běžná mapa, satelitní foto-‐‑mapa, terénní mapa, historická mapa nebo jiné specifické mapy), funkce vy-‐‑ hledávání objektů na mapě, měření vzdáleností, plánovače tras, určování GPS souřadnic a další možnosti například v podobě aktuální předpovědi počasí a do-‐‑ pravního zpravodajství přímo v mapě, nebo vkládání objektů do mapy. Zmíněné možnosti tak činí online mapový server do značné míry interaktivní aplikací, která mnohdy umožňuje uživateli vkládat nejen vlastní poznámky a záložky, ale také fotografie. Rychlý nástup digitální fotografie a rozvoj technologií pro tento druh záznamu, podpořen rostoucí popularitou nejen ve vědeckých kruzích, ale zejména v široké veřejnosti, napomohl tomu, že fotografie se velkou měrou podílejí na celkovém obsahu webových stránek, dokumentů a aplikací. Digitální a digitalizované foto-‐‑ grafie také mohou nést, díky mnohým grafickým formátům, množství neobrazo-‐‑ vých informací v podobě metadat. Fotografie pořizované digitálním fotoaparátem obvykle obsahují metadata ve formátu Exif1. V těchto metadatech jsou uloženy in-‐‑ formace o vzniku fotografie – datum a čas pořízení, použitá ohnisková vzdálenost, použití blesku, typ a výrobce fotoaparátu a podobně (Exchangeable image file format, 2010). Snaha o koordinaci dat v mnoha různých místech, vede k potřebě způsoby označit a identifikovat zdroje dat. Metadata jsou data o datech. Metadata hrají klíčovou roli při nahrávání, indexaci a koordinaci informačních zdrojů (Xiong, 2008). V souvislosti s rozvojem polohovacích zařízeních na bázi GPS, které se staly vyso-‐‑ ce přenosnými a nejsou již implementovány pouze ve specializovaných produk-‐‑ tech, ale také například v mobilních telefonech a fotoaparátech, jsou možnou sou-‐‑ částí metadat digitálních fotografií (standardně ve formátu Exif), právě údaje o poloze pořízené fotografie, tj. nadmořská výška, zeměpisná šířka a délka a urče-‐‑ ní polokoule. 1
Exchangeable image file format
11
Zaznamenání údajů o přesné poloze, kde byla fotografie pořízena, přináší nové možnosti v souvislosti s využitím fotografií v oblasti geografických informačních systémů, respektive mapových služeb. Zpřístupňují se tak nejen nové způsoby po-‐‑ řizování fotografických mapových podkladů, ale také nové způsoby tolik požado-‐‑ vaných dodatečných uživatelských funkcí a jejich automatizace, která může být jednou z rozhodujících konkurenčních výhod daného mapového systému.
1.2 Cíl práce Cílem práce je návrh a pilotní realizace systému na bázi webového mapového ser-‐‑ veru, který přináší inovativní možnosti využití metadat digitálních fotografií, sou-‐‑ visející s jejich polohováním na mapě, automatizovanou tvorbou alb v závislosti na místě pořízení fotografií, a logistickou podporu při plánování tras mezi jednot-‐‑ livými lokalitami, specifikovanými polohou fotografií. K dosažení cíle je mimojiné třeba provést podrobnou analýzu současných webo-‐‑ vých systémů a služeb, které pracují s digitálními fotografiemi a jejich polohovými údaji, identifikovat jejich silné stránky i nedostatky, a na základě těchto poznatků nalézt mezery v nabídce služeb, které budou sloužit jako východisko pro zásadní funkcionality navrhovaného systému. Nezbytné je také využití vhodných metod a nástrojů pro implementaci požadovaných funkcí systému v rámci webové apli-‐‑ kace.
12
3 Metodika Metodický postup zahrnuje zejména studium a také osvojení principů, zavede-‐‑ ných standardů a postupů v následujících oblastech a znalostních okruzích: • • • • • • •
mapové vrstvy, jejich typy a reprezentace, souřadné systémy a kartografické projekce, dostupné technologie geografických informačních systémů, technologie webových služeb pro využití geodat, způsoby aplikace mapového serveru s využitím webového rozhraní, struktura a obsah metadat digitálních fotografií s důrazem na GPS údaje, podpora metadat v různých formátech dat.
Po důkladném poznání teoretických východisek problematiky, zmapování sou-‐‑ časných možností v oblasti metadat digitálních fotografií, standardů metadat a způsobů jejich využití, je nutné provést analýzu dostupných metod, tedy již im-‐‑ plementovaných informačních systémů a aplikací. Analýza zahrne současné we-‐‑ bové i desktopové aplikace, které nabízí služby, umožňující využití metadat digi-‐‑ tálních fotografií k určování polohy jejich pořízení a podobné funkcionality. Vý-‐‑ stup analýzy, v podobě zhodnocení nabízených služeb a přístupů, silných i sla-‐‑ bých stránek dostupných řešení, vytvoří základ pro hledání inovativního využití metadat fotografií v oblasti geografických informačních systémů a pro návrh ta-‐‑ kových funkcionalit nového systému, které přinesou uživateli další možnosti při práci s fotografiemi. Cílem analýzy je tedy nalézt mezeru na trhu služeb ve zvole-‐‑ né oblasti a co nejlepší zúročení již ověřených přístupů, při maximální eliminaci případně identifikovaných nedostatků ve zkoumaných systémech. Po studiu teorie a analýze dostupných řešení následuje využití znalostí metod a postupů softwarového i systémového inženýrství, kladoucí důraz na moderní metody vývoje software a systémů. Cílem je najít ideální postup při návrhu a rea-‐‑ lizaci nového systému s využitím některé z moderních metod návrhu systémů a vývoje programového vybavení, případně kombinovat vhodné metody tak, aby bylo dosaženo efektivní cesty pro realizaci stanoveného systému a požadovaných vlastností. Výběr metod vývoje bude následován specifikací a analýzou požadavků, zahrnu-‐‑ jící následující požadavky a jejich vyhodnocení: • • • • •
Při implementaci webové aplikace se předpokládá využití různých jazykových nástrojů a metod, které budou podrobněji rozebrány v dalších kapitolách. Pro rea-‐‑ lizaci uživatelského rozhraní webové aplikace bude použit hypertextový značko-‐‑ vací jazyk XHTML 5. Komunikaci s databázovým subsystémem na straně serveru, manipulaci se soubory a práci s metadaty fotografií zajistí skriptovací interpreto-‐‑
13
vaný jazyk PHP. Vlastí databáze systému bude obsluhována dotazovacím jazy-‐‑ kem MySQL. Servis načtené stránky a dynamickou interakci s uživatelem zpro-‐‑ středkuje objektově orientovaný jazyk JavaScript a využití technologií DOM a AJAX. Při vlastním kódování je třeba dbát na efektivní využití objektového pří-‐‑ stupu, zejména pro bezproblémové předávání dat mezi jednotlivými moduly sys-‐‑ tému. Mapový server bude realizován na vlastním serveru Apache HTTP Server, s nain-‐‑ stalovaným modulem PHP a databází MySQL. Mapový server bude implemento-‐‑ vaný jako CGI-‐‑program. Předpokládá se využití balíku MS4W, zahrnující mimo jiné knihovnu GDAL/ORG, sloužící pro načítání vektorových i rastrových dat, a knihovnu Proj, obstarávající převody mezi souřadnými systémy. Zejména z dů-‐‑ vodů získání a udržování kvalitních mapových podkladů je třeba zvážit také out-‐‑ sourcing již existujících mapových služeb. Například společnost Google umožňuje přístup k mapovým podkladům za pomoci Google Maps API. Za pomoci popsaných nástrojů a získaných poznatků, vznikne systém na bázi we-‐‑ bového mapového serveru, podporující inovativní způsob přiřazování fotografií, respektive fotografických alb, mapovým vrstvám geografického informačního sys-‐‑ tému. Přiřazování bude probíhat na základě GPS údajů obsažených v metadatech fotografií. Budou vytvářena alba pro místa na mapě, která je daná souřadnicemi získanými ze zmíněných metadat. V další fázi budou aplikovány poznatky z teorie grafů pro implementaci plánova-‐‑ né služby vyhledávání tras na mapě. Dle zadaných parametrů a vybraných existu-‐‑ jících fotografií (fotografických alb) bude navržena nejvhodnější cesta, která umožní uživateli navštívit místa zvolená na základě polohových dat z fotografií. Systém tak umožní neobvyklý způsob využití současných trendů ve fotografii, umožňující zaznamenávat místo vzniku fotografie přímo fotografickým přístro-‐‑ jem, nebo dodatečně prací s metadaty, a poskytne užitečnou funkcionalitu organi-‐‑ zace fotografií v závislosti na místě pořízení. Přinese možnost plánování cest foto-‐‑ grafa pracujícího například na časosběrném projektu, návraty uživatele na místa, kde fotografoval, nebo plánování cest na základě fotografií jiných uživatelů a ces-‐‑ tovatelů. Harmonogram postupu realizace základních funkcionalit systému v jednotlivých krocích: • • • • • • • •
implementace vlastního mapového serveru, vytvoření databáze pro uchování informací o fotografiích, návrh aplikace pro práci s relevantními metadaty fotografií, ošetření nahrávání fotografií, zajištění prezentace fotografií přímo na mapě, vytváření fotografických alb, realizace modulu pro vyhledávání tras, integrace všech součástí do funkčního systému.
14
Důležitou součástí práce také bude testování aplikace a zhodnocení použitelnosti, reálných přínosů v dané oblasti a definování vize a hrubého plánu pro budoucí vývoj celého systému s ohledem na současné trendy v oblasti geografických in-‐‑ formačních systémů. V závěru práce je vhodné se zamyslet nad obchodním zhod-‐‑ nocením vyvíjeného systému a nad cestami distribuce k cílovému uživateli.
15
4 Teoretická východiska 4.1 Geografické informační systémy a geodata GIS, neboli geografický informační systém, je na počítačích založený informační systém pro získávání, ukládání, analýzu a vizualizaci dat, která mají prostorový vztah k povrchu Země. Geodata, se kterými GIS pracuje, jsou definována svou ge-‐‑ ometrií, topologií, atributy a dynamikou. Plnohodnotný geografický informační systém se, stejně jako obecný informační systém, skládá ze 4 součástí (GIS, 2010): •
• • •
hardware – nejčastěji osobní počítač s barevným monitorem, skener pro možnost vstupu obrazových dat, tiskárna či plotter pro možnost mapového výstupu, software – specializovaná sada programů pro analýzu a vizualizaci geodat, data – nejdůležitější a často finančně nejnáročnější součást GIS, pracovníci (uživatelé) – lidé se znalostmi geografie schopní obsluhovat in-‐‑ formační technologie.
Geodata se někdy označují také jako geografická data, geoprostorová data, a po-‐‑ dobně. Jsou to data (přírodní a antropogenní jevy) s implicitním nebo explicitním vztahem k místu na Zemi a skládají se z jednotlivých geoobjektů. Geoobjekt je část modelované reality, kterou je možno na dané úrovni generalizace v GIS modelo-‐‑ vat jako jeden objekt. Geoobjekt obsahuje dva druhy informací (GIS, 2010): • •
prostorové informace (tvar, poloha, topologie), neprostorové informace (atributy, specifické pro každý typ objektu).
Mapový server pak reprezentuje jednoduchý specificky zaměřený GIS, nebo jeho část, pracující převážně s dvourozměrnými mapovými podklady. Mapové vrstvy reprezentují geodata.
4.2 Mapové vrstvy Mapové vrstvy sdružují a uchovávají geoobjekty stejného tématu, proto jsou v některých případech také nazývány tématické. Tématem může být vodstvo, sil-‐‑ nice, cyklostezky, tahy ptáků, nadmořská výška a podobně. Dělení geodat do ma-‐‑ pových vrstev usnadňuje následnou analýzu těchto dat. Mapová vrstva zapsaná v samostatně přenositelném datovém souboru může být dle modelovaných dat rastrová nebo vektorová (GIS, 2010).
4.2.1 Vektorové mapové vrstvy Ve vektorové mapové vrstvě jsou geoobjekty reprezentovány body, které jsou z geometrického hlediska bezrozměrné. Pomocí řetězení úseček nebo křivek spo-‐‑ jujících dva body je možné reprezentovat geoobjekty jako je například silnice nebo řeka. Uvnitř geografických informačních systémů jsou vektorová data organizo-‐‑ vána do takzvaných vektorových modelů.
Ve špagetovém modelu jsou všechny objekty různých typů a formátu uloženy v jednom heterogenním seznamu, který má dvě položky (typ objektu, parametry objektu). Hierarchický model ukládá data do hierarchické struktury s ohledem na počet takzvaných dimenzí2, využívá polygonů složených z několika linií. Jednotli-‐‑ vé elementy, tedy body, úsečky, linie a polygony jsou v systému ukládány samo-‐‑ statně obvykle v geodatabázi.
Obr. 1: Ukázka uložení vektorových dat v hierarchickém vektorovém modelu (GIS, 2010)
Kompromisem obou předchozích případů je model topologický. Jsou ukládány pouze body a úsečky, ke kterým lze připojit informaci o jejich orientovanosti. Z těchto informací je možné určit sousedný levý a pravý polygon.
4.2.2 Rastrové mapové vrstvy Existují různé typy rastrů (čtvercový, šestiúhelníkový, trojúhelníkový). Rastrů se využívá k modelování veličin spojitě definovaných na modelovaném prostoru (vrstva nadmořské výšky, teplot, druhu půd, apod.).
2
Základní dělení geoobjektů podle počtu dimenzí. 0D, 1D, 2D a 3D objekty. Reálné objekty mají tři
dimenze.
17
Obr. 2: Rozdíl mezi vektorovou (vlevo) a rastrovou vrstvou (GIS, 2010)
Přes různé varianty rastrů, se v geografických informačních systémech používá ve většině případů prostorové dělení čtvercovou mřížkou. Jednotlivým buňkám rast-‐‑ ru pak přísluší hodnota reprezentované veličiny pro dané místo. Tyto hodnoty mohou být dvojího typu (GIS, 2010): •
•
Rastrové vrstvy výčtového typu, kdy každá buňka rastru obsahuje kód, ty-‐‑ picky celočíselný, z rozsahu 1...N. Tento kód reprezentuje kategorii sledo-‐‑ vaného jevu. Nutnou součástí rastrové vrstvy tohoto typu je proto překla-‐‑ dová tabulka, která kódy interpretuje. Rastry výčtového typu se používají tam, kde má zkoumaný jev konečný počet hodnot (např. typ vegetace), ne-‐‑ bo tam, kde lze spojitou veličinu rozdělit do konečného počtu kategorií (např. nízká, střední a vysoká hustota zalidnění). Rastrové vrstvy hodnotového typu, kdy každá buňka rastru nese informaci o diskretizované hodnotě spojité veličiny, která může teoreticky nabývat nekonečného počtu hodnot. V praxi je samozřejmě omezena rozsahem a přesností použitého datového typu (integer, float). Takto reprezentované veličině se v prostředí GIS někdy říká prostorový proces. Příkladem prosto-‐‑ rového procesu může být nadmořská výška, atmosférický tlak, teplota, apod.
Rastrových mapových vrstev se často využívá k různým druhům geografických analýz. Typickým příkladem je například analýza viditelnosti nebo analýza zápla-‐‑ vových oblastí.
4.3 Technologie GIS 4.3.1 Funkcionalita GIS Z hlediska funkcionality geografických informačních systémů můžeme definovat následující oblasti: •
vstup a verifikace dat – vstupem bývají digitální geodata v rozličných for-‐‑ mátech, digitalizované tištěné mapy nebo například senzory snímacího za-‐‑ řízení,
18
•
• •
databáze pro uchování a správu geografických dat – z důvodu nevhodnosti klasických relačních databází se obvykle používají specializované rozšíření databázových systémů (PostGIS apod.), analýza dat a transformace dat – soubor algoritmů pro práci s geodaty je esenciální součástí geografických informačních systémů, vizualizace a výstup dat – výstupem je mapa v grafické podobě nebo sou-‐‑ bory s geodaty, tabulkami, diagramy, sestavami atd.
Běžné systémy ve formě webové aplikace pracují na principu klient-‐‑server. Na zá-‐‑ kladě dotazu a zadaných parametrů, které jsou zaslány například na mapový ser-‐‑ ver, uživatel obdrží vygenerovanou mapu v podobě obrázku, výstupu java-‐‑ appletu, souboru a dodatečných informací. Výsledek dotazu může zahrnovat prvky v rámci jedné vrstvy. Příkladem takových dotazů mohou být: • • • • •
Kde je Praha? Jak velká je Praha? Jak dlouhá je cesta z Prahy do Brna? Kde je oblast Moravy? Kde jsou silnice prvních tříd?
Pro obsloužení druhého typu dotazu je nutné použít data dvou nebo více vrstev: • • • •
Jaké objekty se nacházení na Jižní Moravě? Kde roste jehličnatý porost na jílovité půdě? Jakou oblast národního parku pokrývají borové porosty? Jakými obcemi vede silnice z Brna do Velké Bíteše?
Nová mapová vrstva se tedy může skládat například z polygonů, které jsou slože-‐‑ ny z průniků dvou jiných vrstev (Oblasti všech členů družstva, které již byly ose-‐‑ ty.). Důležitou funkcionalitou GIS jsou datové analýzy a modely. Nástroje pro analýzu dat zahrnují množství technik pro porovnání a analýzu datových vrstev. Příkla-‐‑ dem může být kriging3 a jiné metody interpolace (Hiong, 2008).
4.3.2 Technologie webových serverů V rozvoji geografických služeb jsou jednou z hybných sil stávající a nově vznikající standardy podporující integraci mapových služeb v prostředí World Wide Web. Bezkonkurenční dostupnost prostřednictvím celosvětové počítačové sítě a interne-‐‑ tového prohlížeče směřuje vývoj méně sofistikovaných geografických informač-‐‑ ních systémů do podoby moderních mapových serverů a podobných webových aplikací, které jsou na rozdíl od fundovaných a rozsáhlých desktopových GIS do-‐‑ stupné bez instalace na lokální stanici. Typickým a častým představitelem jedno-‐‑ duchého geografického informačního systému využívajícího webových služeb je mapový server, který na rozdíl od rozsáhlých systémů poskytuje zpravidla úzce 3
Krigování (kriging) označuje interpolační metody, které využívají geostacionární metody odhadu.
19
zaměřenou funkcionalitu se specifickými funkcemi přizpůsobenými potřebě (ma-‐‑ pový server pro orientační běh, katastr nemovitostí).
4.3.3 Webové služby Dle definice W3C4 jsou webové služby softwarové systémy, se schopností posky-‐‑ tovat prostředky pro vzájemnou komunikaci a spolupráci aplikací přes počítačo-‐‑ vou síť. Jde o řešení, jak spolu aplikace mohou komunikovat a vyměňovat si in-‐‑ formace po síti bez ohledu na rozdílné systémy a platformy. Webové služby vy-‐‑ tváří rozhraní pro komunikaci různorodých aplikací pomocí HTTP5 protokolu, vzájemnou výměnou XML6 zpráv ve formátu standardu SOAP7. Komunikace pro-‐‑ bíhá formou zasílaných zpráv, dotazů na server a odpovědí zaslaných zpět klien-‐‑ tovi. Zpráva od klienta, který se ptá na informace o produktu z evidence skladu pomocí webové služby a dožaduje se informací o produktu označeném ID 827635 může vypadat následovně (Simple Object Access Protocol, 2010): <soap:Envelope xmlns:soap="ʺhttp:\\schemas.xmlsoap.org\soap\envelope\"ʺ> <soap:Body> <productID>827635<\productID> <\getProductDetails> <\soap:Body> <\soap:Envelope> Zjednodušená odpověď webové služby: <soap:Envelope xmlns:soap="ʺhttp:\\schemas.xmlsoap.org\soap\envelope\"ʺ> <soap:Body> <productName>Čokoláda sada 3 chutí<\productName> <productID>827635<\productID> <popis>Čokoláda hořka, bílá a smetanová<\popis> 98,50<\cena> <\getProductDetailsResult> <\getProductDetailsResponse> <\soap:Body> <\soap:Envelope>
4
Wordl Wide Web Consortium – mezinárodní konsorcium pro vývoj webových standardů WWW.
5
Hypertext Transfer Protokol – internetový protokol, původně pro výměnu hypertextových do-‐‑
kumentů ve formátu HTML. 6
Zkratka pro eXtensible Markup Language – obecný značkovací jazyk.
7
Simple Object Access Protocol – je protokolem pro výměnu zpráv založených na XML přes síť.
20
Vlastnosti jednotlivých rozhraní jsou popsána strojově čitelnou definicí v jazyce WSDL8, registraci a vyhledávání webových služeb umožňuje standardní mecha-‐‑ nismus UDDI9 (Kosek, 2006).
Obr. 3: Vztah tří základních technologií (SOAP, WSDL a UDDI) webových služeb (Kosek, 2006)
Webové služby bývají používány mnoha způsoby, nejčastější jsou: •
•
•
RPC (Remote procedure calls) – vzdálené volání procedur. Prostřednictvím webové služby je volána funkce s parametry definovanými v požadavku klienta, výsledek volání je oznámen v odpovědi na požadavek (Skoupil, 2008). SOA (Service-‐‑oriented architecture) – servisně orientovaná architektura. Základním prvkem komunikace je zpráva. Komunikace pomocí zasílání zpráv umožňuje volnější vazbu mezi systémy a je možné skrýt nepodstatné implementační detaily. REST (Representational State Transfer) – funkcionalita je rozdělena do jed-‐‑ notlivých prostředků (resources) s unikátními URL. Všechny prostředky sdílí uniformní rozhraní s omezenou množinu přesně definovaných operací (create, read, update, delete). Prostředky mohou být reprezentovány ome-‐‑ zenou množinou různých formátů (XML, HTML, JSON, SVG atd.).
4.4 Webové služby a geodata S neustále rostoucími nároky na prezentaci dat nejen v textové formě a požadavky na specifickou funkcionalitu webových geografických informačních serverů jsou 8
Web Services Description Language
9
Universal Description, Discovery and Integration
21
vytvářeny a formalizovány rozšiřující webové služby umožňující fundovanou práci s geodaty a podporu v prostředí Wordl Wide Web.
4.4.1 Web Map Service WMS je webová služba, splňující standard vydaný OGC10 – konsorciem skládají-‐‑ cím se z více než 300 komerčních, vládních, neziskových a výzkumných organiza-‐‑ cí, které vyvíjí a prosazuje společné standardy v oblasti GIS a zpracování a výmě-‐‑ ny geodat. Služba pracuje na principu klient-‐‑server umožňuje sdílení geografické informace ve formě rastrových map v prostředí Internetu. Výsledkem požadavku např. GIS softwaru na WMS server jsou primárně obrazová data v nejrůznějších formátech (JPEG, TIFF, PNG, aj.), které zobrazují tematické geografické informace (tematickou mapu respektive mapovou vrstvu), nebo mohou být výsledkem pře-‐‑ krytu více vrstev (mapová kompozice). WMS pracuje na principu vzájemných interakcí stroj-‐‑stroj a stroj-‐‑člověk. Na vrcho-‐‑ lu komunikace je mapový server. Servery podporující tuto službu se označují jako WMS servery. V jejich úložištích jsou georeferencovaná a databázová data, v na-‐‑ stavení popis možností WMS serveru a v databázi jsou uloženy atributové infor-‐‑ mace o geografických objektech. Software pro komunikaci se serverem za účelem získání informací se nazývá klient a pro komunikaci se využívá HTTP11 protokol a metody dotazů GET a POST. Klient si poté zpracuje informace, které mu server zpřístupnil. Jedná se o rastrová data. Tyto informace pomocí definovaného uživa-‐‑ telského rozhraní zpřístupní uživateli. Jedná se o interakci člověk-‐‑stroj, respektive uživatel-‐‑klient (Web Map Service, 2010). Základní typy dotazů dle OGC: •
•
•
GetMap – primární dotaz zpřístupňující klientovi mapu ve formě obrazo-‐‑ vých dat v určitém formátu. Query URL musí nezbytně obsahovat parame-‐‑ tr REQUEST=GetMap. GetCapabilities – zjištění možností práce s daty. Query musí obsahovat pa-‐‑ rametr REQUEST=GetCapabilities. Specifikace vyžaduje ještě jeden povin-‐‑ ný parametr SERVICE=WMS. GetFeatureInfo – Tento typ dotazu vrací klientovi XML soubor s atributy daného prvku na mapě o určitých souřadnicích. Query URL musí obsaho-‐‑ vat parametr REQUEST= GetFeatureInfo.
U dotazu GetMap a GetFeatureInfo vyžaduje specifikace (záleží dle použité verze WMS) ještě další povinné parametry, které mapovému serveru řeknou podrobněj-‐‑ ší informace o daném dotazu.
Open Geospatial Consortium
10
Hypertext Transfer Protokol
11
22
4.4.2 Web Feature Service Obdoba WMS, která poskytuje v základní verzi přístup k vektorovým datům s atributy ve formátu GML12. GML využívá XML pro kódování geografických dat. Definice pomocí XML schématu je modulárně rozdělena do tříd definujících aspekty geo-‐‑dat. Je možné uživatelsky definovat další třídy a v aplikacích defino-‐‑ vat GML profily pracující s určitou podmnožinou nadefinovaných tříd. WFS tedy oproti WMS neposkytuje vizualizace dat ve formě obrázků, ale umož-‐‑ ňuje pracovat vzdáleně v distribuovaném prostředí přes HTTP přímo s geografic-‐‑ kými daty vybraných geografickým prvků v mapě. Web Feature Service podporuje tyto operace (Skoupil, 2008): •
• •
•
•
•
GetCapabilities – Stejně jako u WMS, odpovědí na tento dotaz klienta je popis schopností daného WFS serveru, typy nabízených geografických prvků a seznam podporovaných operací na jednotlivých typech dat. DescribeFeatureType – odpovědí je popis daného typu geografických prv-‐‑ ků nabízeného službou. GetFeature – na požadavek klienta, obsahující definici vlastností geografic-‐‑ kých prvků, o které má zájem, a prostorové či neprostorové omezení dota-‐‑ zu, jsou službou poskytnuty odpovídající instance geografických prvků. GetGmlObject – služba vrací jednotlivé GML elementy odkazované odpo-‐‑ vídajícími XML ID v požadavku pomocí XML Linking Language. Klient může v požadavku definovat, zda se mají vracet i objekty odkazované vno-‐‑ řenými XLinks ve výsledných elementech. Transaction – operace transakce umožňuje požadavek složený z akcí, které modifikují geografický prvek (vytváření, změna a mazání geografických prvků). LockFeature – tato operace umožňuje uzamknout přístup k jednomu či více prvkům po dobu probíhající transakce.
Na základě operace podporované službou, jsou definovány tři třídy WFS: • • •
Basic WFS – služba musí podporovat operace GetCapabilities, DescribeFea-‐‑ tureType a GetFeature. Zajišťuje tedy přístup pouze pro čtení. XLink WFS – navíc podporuje operaci GetGmlObject s možností provádět tuto operaci v rámci operace GetFeature. Transaction WFS – služba splňuje požadavky na Basic WFS a navíc povin-‐‑ ně podporuje operaci Transaction, nepovinně pak operace GetGmlObject a LockFeature.
4.4.3 Web Coverage Service Standard rozhraní WCS umožňuje přístup k geodatům v nativní podobě. Data získaná pomocí WCS je možné dále zpracovávat, analyzovat, třídit a upravovat. Geography Markup Language
12
23
Používá se převážně pro poskytování dat o jevech na určitém území a proměnli-‐‑ vých v čase. Podporované operace jsou: • • •
GetCapabilities – stejný význam jako u předchozích služeb, tedy popis možností nabízených službou. DescribeCoverage – poskytuje detailní popis jednotlivých dostupných roz-‐‑ sahů (coverages) specifikovaných v dotazu. GetCoverage – poskytne klientovi rozsah geodat (coverage) obsahující vy-‐‑ branou množinu vlastností vybrané množiny lokací specifikovaných v do-‐‑ tazu.
4.4.4 Keyhole Markup Language KML je derivací jazyka XML navržená společností Keyhole, Inc.. KML byl přijat mezi standardy OGC, a jde v podstatě o zjednodušení jazyka GML s cílem snad-‐‑ nější integrovatelnosti do různorodých systému. Také díky tomu je využíván množstvím geografických produktů, jako jsou NASA WorldWind a ESRI ArcGIS. Data ve formátu KML jsou mnohdy přenášena v podobě komprimované verze KML souborů – KMZ. KML pracuje pouze s jediným geografickým souřadným systémem – WGS8413 a podporuje zobrazení vektorových, rastrových geodat a 3D modelů. Triviální KML dokument obsahující jeden bod na zemském povrchu má následu-‐‑ jící strukturu (Procházka, 2008): Bod<\Name> Bod ležící na zemském povrchu<\Description> -‐‑100,45,0<\Coordinates> <\Point> <\Placemark> <\kml> KML je využíván například aplikací Google Earth, která umožňuje virtuální pro-‐‑ hlížení zemského glóbu.
4.5 Mapový server Vzhledem k tomu, že primárním úkolem webového serveru je poskytovat webové stránky, GIS založené na bázi webové aplikace využívají pro provádění operací sekundární programy, obvykle CGI (Common Gateway Interface). World Geodetic System of 1984
13
24
4.5.1 Common Gateway Interface CGI je protokol pro propojení externích aplikací s webovým serverem, což serveru umožňuje delegovat požadavek od klienta na externí aplikaci, která dle požadav-‐‑ ku vrátí výstup. Taková aplikace typicky zpracuje nějaký skript ve webové stránce a webovému serveru navrátí statickou stránku, která je následně poslána klientovi jako výstup jeho požadavku. Rozhraní Common Gateway Interface bylo v prostředí internetu přítomno již od počátku 90. let a ve své době představovalo jediný způsob dynamického zpraco-‐‑ vání obsahu. Poté ale zaznamenaly bouřlivý vývoj skriptovací jazyky – některé určené výhradně pro webové aplikace, jiné jako rozšíření – je CGI postupně vytla-‐‑ čováno do ústranní (Common Gateway Interface, 2010). V Common Gateway Interface (CGI) je definován vztah mezi webovým serverem a procesy, které běží na hostitelském stroji. CGI program zapisuje výstupní data na standardní výstup, odkud jsou přebírána webovým serverem. Je schopný generovat dokumenty mnoha typů (text, obrázek, HTML, zvuk aj.), proto musí kromě vlastního dokumentu také předávat informaci o typu dokumentu. Důvodem je správné zobrazení v internetovém prohlížeči. Vý-‐‑ stup CGI programu má dvě části: • •
CGI hlavička dokumentu (specifikace typu dokumentu zakončená prázd-‐‑ ným řádkem), vlastní dokument.
Tvar CGI hlavičky: Content-‐‑type: \<podtyp> Dvojice \<podtyp> určuje typ dokumentu dle standardu MIME14.
4.5.2 Princip fungování mapového serveru Mapový server je program pracující na architektuře klient-‐‑server, který zpracová-‐‑ vá geodata. Lze jej definovat jako jednoduchý geografický informační systém, ovládaný neinteraktivně pomocí textových parametrů. Spolupracuje s webovým serverem, který mu předává potřebné parametry z webového formuláře. Parame-‐‑ try jsou zpracovávány a vraceny zpět jako výsledek dotazu, nebo soubor s mapou. Existuje množství mapových serverů, mezi komerční patří například produkty fi-‐‑ rem ESRI, systémy TopoL nebo T-‐‑mapy. Mezi produkty uvolněné pod některou z licencí umožňující svobodné užívání patří oblíbený mapový server MapServer univerzity v Minnesotě, jenž původně vznikal jako školní projekt. Mapový server lze užít následovně: •
CGI program vracející na základě vstupních parametrů obrázek mapy,
Multipurpose Internet Mail Extension
14
25
• •
CGI program vracející na základě vstupních parametrů a šablony hotovou internetovou stránku s mapou, využití rozhraní některého z programovacích jazyků (Python, PHP, Perl).
Ve druhém případě je jako šablona používán HTML (XHTML) dokument, jehož součástí je obrázek s mapou, nebo je mapový výstup zprostředkován například pomocí Java apletu15.
4.6 Souřadné systémy 4.6.1 Referenční plocha Referenční plocha je označení pro plochu, která se svým tvarem a velikostí přibli-‐‑ žuje skutečnému tvaru Země a při konstrukci map nahrazuje zemské těleso nebo jeho část. Používá se více druhů referenčních ploch, které se navzájem liší přesnos-‐‑ tí nahrazení zemského tělesa i svými parametry (geoid, elipsoid a referenční elip-‐‑ soid, referenční koule).
Aplikace menšího rozsahu umístěná do WWW strany, která běží v okně prohlížeče.
15
26
4.6.2 Kartografické zobrazení Kartografické zobrazení je způsob, který každému bodu na referenční ploše přiřa-‐‑ dí právě jeden bod na zobrazovací ploše. V kartografie je jich velké množství a to jak početních, tak konstrukčních. Je to dáno snahou, aby pro právě dané zájmové území bylo kartografické zobrazení co nejpřesnější (nejreálnější). Kartografická projekce (mapová projekce), je případ kartografického zobrazení, který využívá promítnutí bodu RP do zobrazovací plochy.
4.6.3 Křovákovo zobrazení Křovákovo zobrazení je obecné konformní kuželové zobrazení, tj. zemský povrch je zobrazen na kuželu, který je v obecné poloze. Bylo vytvořeno ing. J. Křovákem, přednostou triangulační kanceláře po 1.sv.válce, která měla za úkol vytvořit tako-‐‑ vé zobrazení, které bude nejvíce vyhovovat tehdejší republice. Křovákovo zobra-‐‑ zení se v České republice používá jako závazné pro všechna státní mapová díla pod názvem souřadný systém S-‐‑JTSK (jednotné trigonometrické sítě katastrální). Toto zobrazení je, z důvodu přesnosti pro území České Republiky, hojně používá-‐‑ no. Pro území ČR se používají i další zobrazení jako je například WGS-‐‑84, světový geodetický referenční systém z roku 1984, který se nejen u nás používá jako stan-‐‑ dartní při Satelitní navigaci GPS. Od 1.1.1998 je WGS-‐‑84 zaveden ve vojenském a civilním letectvu a v AČR je běžně používán v rámci kooperace a armádami NATO a standardizace v geodézii a kartografii (GeoWiki, 2008).
Obr. 5: Pravoúhlá soustava souřadnic v Křovákově zobrazení
4.7 Nekompatibilita kartografických projekcí Nekompatibilita daná různými způsoby kartografických projekcí může způsobit problém v okamžiku, kdy jsou žádány dvě vrstvy z různých serverů. První server je schopen vracet odpovědi např. pouze v souřadném systému S-‐‑JTSK, druhý pouze v souřadném systému WGS-‐‑84.
27
Situaci je možné částečně řešit přepočtem projekcí „za letu” (on the fly řešení). Přepočty mezi kartografickými projekcemi podporuje knihovna GDAL61, která je využívána i mnoha profesionálními produkty (vGeo, MapServer, a j.). Pomocí této knihovny je možné transformovat projekci a následně provést prolnutí. Nepříjem-‐‑ né je, že při transformaci může vzniknout poměrně významná chyba v přesnosti. Při transformaci mezi WGS-‐‑84 a S-‐‑JTSK může být chyba na území ČR řádově v desítkách metrů. Navíc některé kartografické projekce jsou ze své geometrické podstaty nekompa-‐‑ tibilní. Tento problém se v praxi týká pouze specifických aplikací, resp. států (Pro-‐‑ cházka, 2008). Podstatná část aplikací využívá systém WGS-‐‑84, který je podporo-‐‑ ván všemi mapovými servery, avšak v našich zeměpisných podmínkách je v ně-‐‑ kterých případech nezbytné použití S-‐‑JTSK.
4.8 Metadata fotografií Metadata, neboli strukturovaná data o datech, nachází uplatnění v mnoha odvět-‐‑ vích a často slouží k snadnému vyhledávání nebo popisu obsahu. V oblasti digi-‐‑ tální fotografie se zaběhlo pro metadata fotografií označení Exif, podle často pou-‐‑ žívané specifikace formátu metadat, vyvinutého japonskou průmyslovou asociací JEIDA16.
4.8.1 Exif Exif je specifikace pro formát metadat, vkládaných do souborů digitálními fotoa-‐‑ paráty. Informace se vkládají do existujících souborových formátů, jako je JPEG, TIFF a RIFF WAVE. Struktura Exif dat je převzatá ze souborového formátu TIFF a datové standardy typu TIFF, Exif, TIFF/EP a DCF si jsou velmi podobné. Exif navrhla japonská průmyslové asociace JEIDA, verze 2.1 vznikla 21. června 1998, verze 2.2 v dubnu 2002. V současnosti standard nikdo oficiálně nespravuje, takže není dále vyvíjen (Exif, 2010). Metadata v Exif mohou mimo jiné obsahovat značku a model fotoaparátu, datum a čas pořízení snímku, nastavení fotoaparátu zahrnující nastavenou citlivost, clo-‐‑ nu, expoziční čas, ohniskovou vzdálenost, informace o použití blesku, vzdálenost zaostření nebo orientace fotoaparátu, informace o autorovi (běžně přidávané až při dodatečném zpracování na počítači) a náhled snímku. Současné digitální foto-‐‑ aparáty pořizují snímky velikosti jednotek až desítek megabajtů, proto hlavička Exif přidává malý asi desetikilobajtový náhled, který umožňuje rychlé prohlížení obsahu ve formě zmenšenin. V souvislosti s geografickými informačními systémy je stěžejní možnost ukládat do metadat digitálních fotografií informace o místu pořízení. Tyto informace mo-‐‑ hou být do Exif zapsána pomocí GPS přijímače připojeného k fotoaparátu, samot-‐‑ ným fotoaparátem vybaveným GPS (viz příloha 10.1), nebo dodatečně pomocí vhodného softwaru. Japan Electronic Industries Development Association
16
28
4.8.2 IPTC (IIM) Starším zavedeným formátem pro metadata v oblasti publikování je Information Interchanges Model, častěji nepřesně označován IPTC. Formát byl vyvinut díky spolupráci organizace IPTC17 a sdružení NAA18 jako prostředek pro výměnu zpra-‐‑ vodajských podkladů. Jedná se v podstatě o univerzální formát s jehož pomocí lze popsat textové či grafické dokumenty, video či zvuk. Prosadil se hlavně při popisu elektronické grafiky a digitální fotografie. Metadata, která lze vyjádřit s pomocí IIM, dovolují zachytit status zdroje v rámci publikačního workflow (především vydávání periodik). Celkem 33 metadatových typů je zde určeno pro položky, jako jsou autor, datum a čas vytvoření, klíčová slova, kategorie, urgence, kontakt, copyright, redaktor apod. Masovějšímu využí-‐‑ vání formátu napomohla zejména společnost Adobe, když v polovině 90. let minu-‐‑ lého století zabudovala podporu IIM do svého produktu Photoshop a dovolila tak vkládání dat v uvedeném formátu do obrázkových souborů. Populární je IIM také například při popisu obrázků v různých online databankách (Krejčí, 2004).
4.8.3 XMP Jedním z řešení univerzálnosti metadat je dnes XMP19 společnosti Adobe. Univer-‐‑ zálnost a snadnou implementaci by mělo zajistit především založení uvedeného formátu na standardu XML, přesněji řečeno jazyce RDF20, vyvíjeného konsorciem W3C jako univerzální metadatová platforma. XMP umožňuje popsat v podstatě libovolná metadata s pomocí takzvaných sché-‐‑ mat. V rámci stávající specifikace se přitom nabízí řada přednastavených schémat, umožňujících kódovat například Exif informace, specifika PDF a Photoshop sou-‐‑ borů, údaje spojené s ochranou autorských práv a podobně. XMP informace lze vložit do souborů prakticky libovolném formátu.
4.8.4 Formát DNG Nasazení IIM sebou přináší mnohé problémy, jako je například dnes nedostačující podpora národních znakových sad mimo angličtinu. IPTC headers jsou v různých aplikacích implementovány nejednotně a využití je možné pouze v rámci někte-‐‑ rých formátů (Photoshop, JPEG, TIFF). Stěžejní problém je samotná struktura me-‐‑ tadatových typů, nedovolujících dostatečně popisovat publikační zdroje. Specifi-‐‑ kace formátu nedovoluje kódování s pomocí XML. Vývoj formátu je od roku 1997 pozastaven. V případě standardu Exif existuje také množství nevýhod. Barva je vyjádřena v 24 bitech, přičemž dnešní fotoaparáty mohou zachytit i vyšší barevnou hloubku. V některých obrazových formátech se Exif data mohou vyskytovat kdekoliv International Press and Telecommunications Council
17
Newspaper Association of America
18
eXtensible Metadata Platform
19
Resource Description Framework
20
29
v souboru, neboť není stanoveno pevné pravidlo pro jejich umístění. Tato skuteč-‐‑ nost přináší nepříjemné ztížení dekódování a opětné kódovaní těchto souborů. Z těchto důvodů většina obrázkových editorů poškodí nebo odstraní Exif metada-‐‑ ta (zvláště autorovy poznámky) při ukládání. Standard Exif povoluje pouze TIFF a JPEG soubory a neexistují žádná ustanovení pro „surová“21 data získávaná pří-‐‑ mo z optického senzoru. Výše zmíněné problémy, zejména neschopnost Exif formátů zachytit větší hloub-‐‑ ku než 24 bitů vedla k tomu, že výrobci používají svoje vlastní datové formáty, které jsou navzájem nekompatibilní. Možnou alternativu pro řešení problémů s nekompatibilitou přispěla společnost Adobe, která vyvinula formát DNG vychá-‐‑ zející z TIFF formátu. DNG, neboli Digital Negative, je veřejně dostupný archivní formát pro surové soubory vytvořené digitálními fotoaparáty. Dle společnosti Adobe je klíčovým přínosem tohoto formátu nezávislost na značce a typu digitální kamery, efektivní podpora metadata a jistota v budoucí kompatibilitě a podpoře ze strany softwaro-‐‑ vých produktů.
4.8.5 Specifikace formátu DNG Do formátu DNG je možné konvertovat data kódovaná v rozličných formátech RAW. DNG je založen na formátu TIFF, respektive TIFF/EP, jenž je rozšířený o možnost zápisu metadat odpovídajících specifikaci EXIF. Formát DNG obsahuje surová data vytvořená snímačem fotoaparátu a metadata obsahující podrobné charakteristiky přístroje, nezbytná k dalšímu zpracování snímku. Formát umožňu-‐‑ je výrobcům snímací techniky uchovávat i metadata vlastní. Specifikace formátu DNG je zdarma k dispozici i pro komerční využití, nejsou te-‐‑ dy například výrobcům fotoaparátů, tiskáren nebo softwarovým vývojářům kla-‐‑ deny překážky ve formě licenčních poplatků. Adobe poskytuje také širokou paletu profesionálních nástrojů, ve kterých je podpora formátu DNG samozřejmá a vyu-‐‑ žívání formátu přináší uživatelům mnohé výhody, zejména bezproblémovou pře-‐‑ nosnost mezi jednotlivými programy. Je možné jmenovat například Adobe Pho-‐‑ toshop a jeho zásuvný modul Camera RAW, nebo Adobe Photoshop Lightroom, profesionální fotografickou vývojnici, organizátor fotografií s širokými možnostmi publikace a tisku. Formát DNG definuje množinu nových značek, které nejsou součástí výchozí spe-‐‑ cifikace TIFF/EP (Digital Negative Specification, 2009), avšak zachovává, pro tuto práci stěžejní, GPS značky specifikace EXIF. Vybrané tagy jsou popsané v tabulce Tab. 1.
V oblasti digitální fotografie je zažité označení RAW, z anglického výrazu surový, nezpracovaný.
21
Je možné si jej představit jako digitální obdobu negativu z klasické fotografie. Nejde o obrázek, ale o surová data ze snímacího čipu, umožňující dodatečné zpracování fotografie.
30
Tab. 1: Vybrané značky specifikované formátem DNG (Phil Harvey, 2009) tag name
type
description
DNGVersion
BYTE
verze DNG, např. 1.2.0.0
UniqueCameraModel
ASCII
jméno modelu fotoaparát, např. "ʺCanon EOS 5D"ʺ
BlackLevel
RATIONAL
specifikuje úplnou černou
WhiteLevel
RATIONAL
specifikuje nejzazší bílou
DefaultScale
RATIONAL
ořez okrajů obrazu
DefaultCropOrigin
RATIONAL
souřadnice obrazu před aplikací DefaultScale
CalibrationIlluminant1
SHORT
první ze značek pro kalibraci barev
ColorMatrix1
SRATIONAL
konverze do nativního barevného prostoru
AnalogBalance
SRATIONAL
data bez aplikace digitálního vyvážení bílé
BaselineExposure
SRATIONAL
korekce expozice různých továrních ZERO hodnot
BaselineNoise
RATIONAL
relativní úroveň šumu při citlivosti ISO 100
BaselineSharpness
RATIONAL
relativní úroveň ostření dle modelu fotoaparátu
CameraSerialNumber
ASCII
sériové číslo těla kamery, která pořídila snímek
LensInfo
RATIONAL
vlastnosti použitého objektivu (clona, ohnisko)
ChromaBlurRadius
RATIONAL
množství chroma rozostření pro DNG čtečky
AntiAliasStrength
RATIONAL
síla anti-‐‑alias filtru (vyhlazení artefaktů)
DNGPrivateData
BYTE
cesta k úložišti privátních dat výrobce přístroje
OriginalRawFileName
ASCII/BYTE
jméno raw souboru, ze kterého bylo konvertováno
OriginalRawFileData
UNDEFINED posloupnost datových bloků originálního souboru
NoiseReductionApplied
RATIONAL
úroveň aplikované redukce šumu
ProfileToneCurve
FLOAT
tonální křivka aplikovaná při zpracování obrazu
PreviewDateTime
ASCII
datum a čas vytvoření náhledu
NoiseProfile
DOUBLE
popisuje množství šumu v původním raw obrazu
4.9 GPS tagy standardu Exif GPS značky jsou v rámci standardu Exif uloženy v samostatném IFD22. Dostupné je například řešení ExifTool, na platformě nezávislá knihovna pro jazyk Perl s příkazovou aplikací. Podrobný popis je uveden v tabulce Tab. 2. Tab. 2: GPS značky dle řešení ExifTool (Harvey, 2009) Tag ID
Tag Name
Writable
Values \ Notes
0x0000
GPSVersionID
int8u[4]:
0x0001
GPSLatitudeRef
string[2]
N'ʹ = North | 'ʹS'ʹ = South
0x0002
GPSLatitude
rational64u[3]
0x0003
GPSLongitudeRef
string[2]
E'ʹ = East | 'ʹW'ʹ = West
0x0004
GPSLongitude
rational64u[3]
0x0005
GPSAltitudeRef
int8u
0|1 = Above|Below Sea Level
0x0006
GPSAltitude
rational64u
Exif IFD je soubor značek pro záznam atributů specifických informací do Exif. Má stejnou struk-‐‑
22
turu jako IFD formátu TIFF, ačkoliv neobsahuje obrazová data.
31
0x0007
GPSTimeStamp
rational64u[3]
0x0008
GPSSatellites
string
0x0009
GPSStatus
string[2]
A'ʹ|'ʹV'ʹ = Meas. Active|Void
0x000a
GPSMeasureMode
string[2]
2|3 = 2-‐‑D|3-‐‑D Measurement
0x000b
GPSDOP
rational64u
0x000c
GPSSpeedRef
string[2]
K'ʹ|'ʹM'ʹ|'ʹN'ʹ = km\h|mph|knots
0x000d
GPSSpeed
rational64u
0x000e
GPSTrackRef
string[2]
T'ʹ|'ʹM'ʹ = True|Magnetic North
0x000f
GPSTrack
rational64u
0x0010
GPSImgDirectionRef
string[2]
T'ʹ|'ʹM'ʹ = True|Magnetic North
0x0011
GPSImgDirection
rational64u
0x0012
GPSMapDatum
string
0x0013
GPSDestLatitudeRef
string[2]
N'ʹ|'ʹS'ʹ = North|South
0x0014
GPSDestLatitude
rational64u[3]
0x0015
GPSDestLongitudeRef
string[2]
E'ʹ|'ʹW'ʹ = East|West
0x0016
GPSDestLongitude
rational64u[3]
0x0017
GPSDestBearingRef
string[2]
T'ʹ|'ʹM'ʹ = True|Magnetic North
0x0018
GPSDestBearing
rational64u
0x0019
GPSDestDistanceRef
string[2]
K'ʹ|'ʹM'ʹ = Kilometers|Miles
0x001a
GPSDestDistance
rational64u
0x001b
GPSProcessingMethod
undef
0x001c
GPSAreaInformation
undef
0x001d
GPSDateStamp
string[11]
(YYYY:MM:DD)
0x001e
GPSDifferential
int16u
0|1 = No Correction|Corrected
32
5 Analýza dostupných metod 5.1 Desktopové aplikace Většina desktopových aplikací umožňující pracovat s GPS údaji fotografií používá outsourcing mapových služeb, převážně mapového serveru Google Maps nebo Yahoo!, což znamená že pro používání je nutné připojení k internetové síti.
5.1.1 Google Earth Rozsáhlý projekt umožňující nahlížení na zemský glób, glób Marsu a oblohu. V případě země je možné přiblížení až na 27 stop nad zemí, přepínat mezi běžný-‐‑ mi mapovými podklady, vyhledávat trasy, firmy a další objekty. Podstatou pro-‐‑ jektu je možnost nahrávat fotografie z daných oblastí (po přiřazení GPS souřadnic kliknutím na dané místo mapy) a dokonce trojrozměrné modely staveb a budov.
Obr. 6: Náhled obrázku v aplikaci Google Earth
V dobře zmapovaných a vymodelovaných oblastech je možné se dokonce „projít“ vymodelovanou ulicí, nebo použít 360-‐‑ti stupňové panoráma složené z fotografií (viz příloha 10.2, obrázky C a D ) . K dispozici je také možnost prohlédnout dané území prostřednictvím webových kamer.
5.1.2 Zoner Photo Studio Aplikace umožňuje přiřazovat GPS data ručně nebo vyhledáním místa na mapě, zobrazovat je na mapě (viz příloha 10.2, obrázek E), editovat nebo odebírat. Do-‐‑ stupné je také přiřazení GPS dat do Google Earth a následné zobrazování fotogra-‐‑ fií na zemském glóbu. Používá služeb mapového serveru Google Maps a externí aplikace Google Earth.
33
Obr. 7: Menu aplikace Zoner Photo Studio 11
5.1.3 Adobe Photoshop Elements Adobe Photoshop Elements 7.0 využívá mapových služeb Yahoo!, dovoluje zapi-‐‑ sovat místo pořízení fotografií do EXIF metadat a napojit tyto GPS údaje na online mapu. Zeměpisné údaje lze zadat rovnou pomocí jednoduchého vyhledávače města a státu, které se pak zobrazí na souhrnné mapě. Fotografie je pak možné v albu vyhledávat dle místa pořízení. Při prohlížení mapy se fotografie zobrazují jako připínáčky, které lze rozkliknout a zobrazit tak náhled, respektive náhledy snímků z daného místa.
Obr. 8: Náhled fotografie přímo na mapě v aplikaci Adobe Photoshop Elements 7.0
34
5.1.4 iPhoto Pro uživatele operačních systémů MAC OS a OS X je dostupná aplikace iPhoto již jako jejich součást. Aplikace iPhoto také využívá služeb Google Maps, které zaru-‐‑ čují kvalitní a aktuální mapové podklady. Umožňuje rychlé vyhledání místa poří-‐‑ zení i přiřazení informací o poloze a zobrazení na mapě (viz příloha 10.1, obrázek F a G). Fotografie již obsahující informace GPS jsou automaticky přidány do tak-‐‑ zvaných „Places“, míst pořízení fotografií.
Obr. 9: Zobrazení polohy fotografie v aplikaci iPhoto
5.2 Webové aplikace Mapových služeb volně dostupných na internetu je značné množství, od nejjed-‐‑ nodušších aplikací informující o poloze firmy či instituce pomocí mapy, přes ma-‐‑ pové servery až po komplexní služby poskytující nejen přístup k aplikaci pracující s mapou a standardními funkcemi, ale také například umožňující přístup k aktualizovaným mapovým podkladům a podobně. K dispozici jsou služby ve-‐‑ řejné správy, jako územně identifikační registr adres, mapy škodlivých organismů, vodohospodářský informační portál VODA, mapové služby krajských orgánů, mapový server územního plánování, územní plány měst, katastr nemovitostí atd. Dále mapové služby a vyhledávače jako Mapy, Atlas, Quick, Google Maps a jiné, historické a další specifické mapy, nebo letecké a družicové přelety, 3D modely a modely počasí (Medard). Mnohé pracují s fotografiemi nejen jako s podkladem v podobě družicových snímků.
35
5.2.1 Google Maps Nejen v zahraničí je produkt společnosti Google velmi oblíbený. Kromě obvyklých funkcionalit jako vyhledávání na mapě, zobrazení různých mapových podkladů nebo vyhledávání tras, umožňuje přidávat vlastní mapy a také fotografie. Společ-‐‑ nost Google také umožňuje využití kompletních služeb Google Maps prostřednic-‐‑ tvím Google Maps API23.
Obr. 10: Fotografie na mapě ve webové aplikaci Google Maps (maps.google.com)
5.2.2 Mapy
Obr. 11: Fotografie na mapě ve webové aplikaci Mapy (www.mapy.cz)
Google Maps Application Programming Interface – rozhraní umožňující využití mapových slu-‐‑
23
žeb společnosti Google
36
Nejvyužívanější online mapovou službou na domácím trhu jsou Mapy, dostupné mimojiné přes portály Seznam a Centrum. Kromě obvyklých funkcí mapových serverů nabízí také možnost zobrazení stínování terénu, dopravního zpravodaj-‐‑ ství, počasí pro jednotlivé oblasti a fotografie.
5.3 Vyhodnocení analýzy dostupných metod Na základě provedené analýzy současných metod a programových prostředků pro využití metadat digitálních fotografií při práci s polohou, je možné označit dva stěžejní přístupy. Prvním jsou aplikace primárně zaměřené na práci s digitál-‐‑ ními fotografiemi, nabízející různé způsoby pro organizaci fotografií, případně je-‐‑ jich úpravu a prezentaci. V tomto případě jde zejména o desktopové aplikace, jako jsou Zoner Photo Studio, iPhoto, nebo Adobe Photoshop Elements. U těchto sys-‐‑ témů je jako jedna z mnoha funkcí, dostupná také práce s metadaty ve formátu EXIF. Běžná je možnost využití fotoaparátem zapsané polohové informace v me-‐‑ tadatech, přiřazování GPS polohových údajů do EXIF ručním zápisem, nebo zvo-‐‑ lením požadovaného místa na mapě. GPS data je dále možné upravovat nebo od-‐‑ stranit a zobrazit požadované fotografie na mapě. Všechny analyzované aplikace využívají externích dodavatelů mapových služeb a je nutné připojení k internetu. V těchto případech jde tedy převážně o pouhou možnost zobrazit nebo zapsat po-‐‑ lohové informace GPS, případně možnost zobrazit fotografii na mapě. Nejdále pokročila směrem, který je zajímavý vzhledem k předmětu této práce, společnost Apple. V aplikaci iPhoto umožňuje zobrazit fotografie na mapě za pomoci služby Places, kterou je možné interpretovat jako virtuální album fotografií obsahujících GPS údaje. Je možné fotografiím na mapě přidávat popisky, případně z nich vy-‐‑ tvořit nové album za pomoci jednoho a více pravidel. Pro tvorbu nového alba lze použít pravidlo stanovující, že se fotografie musí nacházet na mapě, neboli obsa-‐‑ huje souřadnice GPS, zapsané v metadatech fotografie. Bohužel není možné blíže specifikovat geografickou oblast, která by podmínila přiřazení fotografií například do alba s názvy Česká Republika, Jižní Morava, Brno atd. Druhým výrazným přístupem je forma online mapového serveru, případně we-‐‑ bových aplikací, využívajících jeho služeb. V těchto případech je přístup v podsta-‐‑ tě opačný. Fotografie a jejich případná organizace jsou doplňkovou službou zá-‐‑ kladní funkcionality v podobě mapových a geografických služeb, služeb pro vy-‐‑ hledávání lokalit a případného plánování tras mezi nimi. Co se týče dostupných služeb pro plánování tras, je vždy určující pouze adresa, nebo místo dané souřad-‐‑ nicemi na mapě. Fotografie tedy netvoří prvek, který by bylo možné použití jako body, ze kterých se vychází při plánování nové trasy. V obou přístupech je tedy zobrazení fotografií na mapě doplňkovou službou a ve většině případů nejsou nabízeny širší možnosti práce s fotografiemi, přesahu-‐‑ jící pouhé určení polohy pořízení snímku. Analýza dostupných metod ukázala, že v souladu se stanoveným cílem této práce, je dostatečný prostor pro inovativní možnosti využití polohových údajů zapsaných v metadatech fotografií.
37
V rámci této práce jde pak zejména o následující funkcionality, které na trhu pří-‐‑ buzných služeb a řešení chybí, nebo jsou podporovány pouze v omezeném rozsa-‐‑ hu: • •
automatizovaná tvorba alb v závislosti na místě pořízení fotografií, logistická podpora při plánování tras mezi jednotlivými lokalitami, specifi-‐‑ kovanými polohou fotografií.
Navrhovaný systém se tedy na základě stanoveného cíle práce a provedené analý-‐‑ zy bude soustředit na rozšíření možností při automatické tvorbě alb v závislosti na geografické poloze pořízených snímků a pokusí se přinést nový přístup v případě plánování tras, kdy bude možné použít fotografii na mapě jako jeden ze staveb-‐‑ ních prvků, definujících novou trasu. V novém systému tak fotografie nebude hrát pouze roli doplňkové informace k vyhledanému místu na mapě, se kterou nelze dále pracovat.
38
6 Metody vývoje a postup realizace Řešená problematika je komplexní problém zahrnující do sebe více disciplín, od problematiky tvorby webu, přes vývoj a správcovství webových a mapových ser-‐‑ verů, až po práci s databázemi a digitálními fotografiemi. Integrací všech součástí projektu vznikne informační systém, poskytující zejména geografická, obrazová data a výstup plánů cesty v textové podobě. Vzhledem k povaze projektu je vhodné využití předem definované metodiky vý-‐‑ voje softwarového produktu a její dodržování po celou dobu životního cyklu sys-‐‑ tému. Základní životní cyklus systému má následující fáze (Merunka, 2003): • • • • •
zadání, analýza, návrh, implementace, testování a provoz.
Metodika vývoje systému vychází ze modifikovaného spirálovitého modelu s důrazem na prototypový přístup a interakci s uživatelem, kdy je každý prototyp testován nejen programátorem, ale pro následnou úpravu a transformaci do nové-‐‑ ho prototypu jsou použity také nové poznatky a požadavky uživatelů, podílejících se na testování současného prototypu. Metodika tedy nese i prvky přístupu Rapid Application Development24. Životní cyklus informačního systému je dále modifikován v závislosti na použité metodice tak, aby obsáhl problematiku vývoje prototypů, zpětné vazby uživatelů a rozdělení na jednotlivé části systému – moduly (Řepa, 1999). Tyto části systému můžeme označit jako podsystémy. Podsystémy jsou vyvíjeny v podobě samostat-‐‑ ných prototypů, jejichž funkcionalita je nezávislá na běhu ostatních modulů. Pří-‐‑ stup umožňuje nejen snadnou integraci, další vývoj a úpravy jednotlivých modu-‐‑ lů, ale také usnadňuje použití finálních produktů, vyvinutých z jednotlivých pro-‐‑ totypů, v jiných informačních systémech. Práce tedy vychází ze dvou základních životních cyklů: • •
životní cyklus celého projektu – informačního systému, životní cyklus prototypu.
Životní cyklus prototypu reprezentuje významnou část jednoho cyklu spirály, jejíž jednotlivé iterace se po modifikaci podílejí na životním cyklu celého projektu.
Rapid Application Development (RAD) je takový přístup k vývoji software, který zahrnuje itera-‐‑
24
tivní vývoj prototypů. RAD byl původně použit k označení procesu vývoje software, který zavedl James Martin v roce 1991. (Office of Information Services, 2008)
39
6.1 Prototypový přístup Vývoj pomocí vytváření prototypů je takový přístup k vývoji software, kde do-‐‑ chází k vývoji neúplných verzí software, tzv. prototypů. Základní principy proto-‐‑ typového přístupu (SELECTING A DEVELOPMENT APPROACH, 2008): •
• • • • •
Není samostatným a kompletním přístupem metodiky vývoje, ale spíše pří-‐‑ stup k jednotlivým částem větších tradičních metodik vývoje software (tj. přírůstková metoda, spirála, nebo RAD -‐‑ Rapid Application Develop-‐‑ ment). Snaha snížit nebezpečí projektových rizik rozdělením projektu na menší části a zjednodušit tak možnost změn v průběhu procesu vývoje. Uživatel je zapojen v celém procesu vývoje, což zvyšuje pravděpodobnost přijetí konečné implementace uživatelem. Malé ukázky systému jsou vyvíjeny iterativním procesem, dokud se proto-‐‑ typ nevyvine tak, že splňuje požadavky uživatele. Většina prototypů je sice vyvíjena s tím, že budou vyřazeny, ale v někte-‐‑ rých případech je možné pokročit od prototypu k funkčnímu systému. Aby se předešlo vývoji, který řeší jiný problém, než bylo zadáno, je třeba pochopit základní business problematiku.
Prototypový přístup je v práci uplatňován při vývoji jednotlivých modulů systé-‐‑ mu, a je tedy součástí životního cyklu subsystémů celého projektu.
6.2 Spirálový přístup Spirálový přístup je proces vývoje software kombinující prvky designového pří-‐‑ stupu a prototypového přístupu tak, aby zkombinoval výhody obou konceptů shora-‐‑dolů (prototypování) a zdola-‐‑nahoru (designování). Základní principy spi-‐‑ rálového přístupu (SELECTING A DEVELOPMENT APPROACH, 2008): •
•
•
Zaměřuje se na analýzu rizik a minimalizaci projektových rizik rozdělením projektu na menší segmenty a umožněním změn během procesu vývoje. V průběhu vývoje je také možné vyhodnocovat rizika a zvažovat další po-‐‑ kračování projektu v průběhu životního cyklu. Každý cyklus spirály spouští stejný sled kroků pro každou část produktu a pro každou úroveň elaborace (od konceptuálních dokumentů až po pro-‐‑ gramování jednotlivých programů). Během každého cyklu spirály jsou tak spouštěny čtyři základní fáze (kvad-‐‑ ranty): • • • •
•
analýza – stanovení cílů, alternativ a rozsahu iterace, vyhodnocení – vyhodnocení alternativ, identifikace a řešení rizik, vývoj – vývoj produktu a kontrola očekávaných výsledků, plánování – plán pro příští iteraci.
V počátku každého cyklu se identifikují zainteresované subjekty a jejich podmínky kladené na úspěch iterace, na konci každého cyklu se provádí revize a předání.
40
6.3 Modifikace základních fází cyklu spirály V závislosti na stanovených požadavcích vývoje, jsou základní fáze cyklu uprave-‐‑ ny tak, aby plně zahrnovaly přístup prototypováním a zpětnou vazbu uživatele: • • • • • • •
specifikace a Analýza požadavků, vyhodnocení požadavků, navrhnutí prototypu a vhodných metod, implementace prototypu, testování prototypu vývojářem a uživateli, vyhodnocení relevantních připomínek uživatelů, plán pro příští iteraci.
Obr. 12: Originální a modifikovaný cyklus spirály
6.3.1 Specifikace a Analýza požadavků Systematická analýza požadavků je také obecně známa jako requirements engine-‐‑ ering (Wiegers, 2003). Analýza požadavků je kritická ve vztahu k úspěšnému do-‐‑ končení projektu vývoje (Abran, 2004). Požadavky musí být proveditelné, měřitel-‐‑ né, testovatelné a taky musí být definované dostatečné detailně pro účely návrhu funkčního systému. Východiska práce jsou uvedeny v kapitole 1.2 Cíl práce. Na základě těchto výcho-‐‑ disek a analýzy již existujících informačních systémů a aplikací, které se zabývají podobnou tématikou, je vytvořena počáteční specifikace požadavků na systém, která přináší inovativní přístup v odvětví. Tato specifikace je v závislosti na vý-‐‑ sledcích v jednotlivých cyklech a na základě požadavků testovací skupiny uživate-‐‑ lů upravována pro vstup do navazujícího cyklu, dokud není výsledkem vývoje funkční prototyp splňující veškeré relevantní požadavky zadání a nároky uživate-‐‑
41
lů. Dle typologie požadavků (Requirements analysis, 2010), jsou specifikovány ná-‐‑ sledující esenciální požadavky: •
Funkční požadavky – objasňující co se musí udělat a identifikuje nutné úkony, aktivity a akce, které musí být vykonány: • • • • • • •
•
Výkonnostní požadavky – kritérium stanovující do kdy nebo jak musí být funkce nebo činnost vykonaná: • • •
•
implementace systému v podobě webové aplikace, dostupnost aplikace online, implementace v podobě mapového serveru.
Odvozené požadavky – požadavky, které jsou transformovány z požadav-‐‑ ků vyšší úrovně: • •
•
okamžitá odezva systému, preference větší rychlosti plánování tras a nezatěžování zbytečně přesnou lokalizací, úprava naplánované cesty v reálném čase.
Designové požadavky – požadavky na procesy vyjádřená v technických da-‐‑ tových balíčcích a technických příručkách: • • •
•
nahrávání a uchování fotografií v systému, možnost přiřazení polohových informací fotografiím, zobrazení fotografií na mapě na základě informací o jejich poloze, seskupování fotografií do alb v závislosti na jejich poloze, odstranění fotografií nebo alb ze systému, plánování cest a interaktivní úprava naplánované cesty, možnost zahrnutí do naplánované cesty jednotlivé fotografie nebo alba.
vytvoření vhodného rozhraní pro práci s mapovým serverem, vytvoření vhodného rozhraní pro plánování cest, atd.
Alokované požadavky – požadavky, které vznikly rozdělením nebo aloko-‐‑ váním tzv. high-‐‑level požadavku. • •
instalace webového serveru Apache, instalace vlastního mapového serveru (mapserver), atd.
6.3.2 Vyhodnocení požadavků Vyhodnocování požadavků probíhá v každém cyklu spirály. Je kladen zejména důraz na selekci relevantních požadavků, zkoumání možností řešení jednotlivých požadavků, hledání nejvýhodnějších alternativ řešení a zkoumání možných rizik a problémů při dodatečné implementaci nově vzniklých požadavků.
42
6.3.3 Navrhnutí prototypu a vhodných metod Návrh prototypu zahrnuje definování vstupů a výstupů jednotlivých subsystémů, způsoby přenosu a zpracování dat, způsoby uchování dat a přístupu k nim. Dále obsahuje sestavení algoritmů řešících jednotlivé funkcionality a výběr jazykových prostředků, technologií a postupů pro implementaci procesů.
6.3.4 Implementace prototypu Vlastní programování navrhnutého prototypu s využitím stanovených jazykových prostředků a technologií, zahrnující i první fázi testování realizovaných částí pro-‐‑ totypu kodérem a následnou modifikaci kódu. Tvorba grafického uživatelského rozhraní.
6.3.5 Testování prototypu vývojářem a uživateli Testování prototypu z pohledu vývojáře klade důraz zejména na ověření míry na-‐‑ plnění požadavků funkční specifikace, hledání případných chyb zpracování, jako jsou chyby v algoritmech, chybné fakty, opomenutí, nekonzistence, nejednoznač-‐‑ nosti nebo chybné požadavky. Je snahou pokrýt maximální počet z možných pří-‐‑ padů zadání a minimalizovat případy nenadálých výjimek. Po ukončení je proto-‐‑ typ postoupen na testování uživatelům. Chyby jsou opravovány průběžně v rámci testování, v případě systémových chyb je řešení postoupeno do návrhu nového prototypu. Pro testování prototypu z pohledu uživatele je vytvořena skupina testerů. Je tes-‐‑ tována zejména správná funkcionalita systému, uživatelské rozhraní, jeho přívěti-‐‑ vost a uspořádání.
6.3.6 Vyhodnocení relevantních připomínek uživatelů Upozornění na chyby jsou postoupeny do návrhu nového prototypu. U připomí-‐‑ nek je vyhodnocována míra relevantnosti v závislosti na funkční specifikaci sub-‐‑ systému a případný přínos v návrzích na vylepšení funkcionality, nebo funkciona-‐‑ litu novou.
6.3.7 Plán pro příští iteraci Na základě výsledků testování jsou vytvořeny podklady pro úpravu stávající spe-‐‑ cifikace a analýzy požadavků, ze kterých bude vycházet další prototyp. Pokud je dosaženo bezchybného funkčního prototypu, přechází se k analýze požadavků pro další subsystém.
6.4 Nástroje pro implementaci aplikace 6.4.1 Jazykové nástroje a metody Pro realizaci uživatelského rozhraní webové aplikace je použit jazyk XHTML25 vyvinutý konsorciem W3C – rozšiřitelný hypertextový značkovací jazyk, který vy-‐‑ eXtensible HyperText Markup Language
25
43
chází z XML26, obecného značkovacího jazyka, který umožňuje vytváření konkrét-‐‑ nějších značkovacích jazyků pro různé typy dat a různé účely, výměnu dat mezi aplikacemi, publikování a prezentaci dokumentů, serializaci dat nebo transforma-‐‑ ci na jiné typy dokumentů. XHTML během svého vývoje přineslo například mo-‐‑ dularizaci, jejíž cílem je dožení vyšší flexibility a nezávislosti ve vztahu k uživatelským agentům, jako jsou WWW prohlížeče, čtečky, tiskárny nebo mo-‐‑ bilní zařízení. Verze XHTML 5 pak přináší mnoho rozšíření v podobě značek pro video, audio, tvorbu offline webových aplikací atd. Pro komunikaci s databázovým subsystémem, práci s metadaty ve formátu Exif a manipulaci se soubory, je použit jazyk PHP27 – hypertextový procesor. PHP je skriptovací interpretovaný programovací jazyk pro realizaci dynamických stránek na internetu. Skripty PHP běží na straně serveru a jsou prováděny před načtením stránky v prohlížeči, kterému jsou postoupeny výsledky činnosti PHP skriptu v podobě HTML stránky. PHP přináší podporu mnoha různorodých knihoven pro zpracování grafiky, textu, přístup k databázovým serverům (MySQL, Oracle, PostgreSQL…) i práci se soubory. PHP je jazyk dynamicky typový (datový typ proměnné je určen okamžikem přiřazení hodnoty). PHP 5 obsahuje nové rysy jako je vylepšená podpora pro objektově orientované programování, PHP Data Objects extension, definující lehké a konzistentní rozhraní pro napojení k databázím (Trachtengberg, 2008). Pro obsluhu již načtené stránky, dynamickou interakci s uživatelem a využití slu-‐‑ žeb mapového serveru je použit jazyk JavaScript. JavaScript je multiplatformní, objektově orientovaný skriptovací jazyk, jehož autorem je Brendan Eich z tehdejší společnosti Netscape. Nyní se zpravidla používá jako interpretovaný programo-‐‑ vací jazyk pro WWW stránky, často vkládaný přímo do HTML kódu stránky. Jsou jím obvykle ovládány různé interaktivní prvky GUI (tlačítka, textová políčka) ne-‐‑ bo tvořeny animace a efekty obrázků. JavaScript běží na straně klienta, podporuje dynamické přiřazení typů, objekty jako asociativní pole, funkce jako metody a konstruktory objektů i takzvanou prototypovou dědičnost. V souvislosti s jazykem JavaScript, je nutné zmínit také využitou technologii vývo-‐‑ je interaktivních webových aplikací AJAX28, umožňující změnu obsahu webové stránky, aniž by bylo nutné její znovunačtení a překreslení, předávání dat mezi skripty běžícím na straně uživatele a skripty na straně serveru. Technologie AJAX je využita zejména v modulu pro nahrávání fotografií a při práci s mapovým ser-‐‑ verem, s využitím JavaScript a technologií DOM29. DOM – objektový model do-‐‑ kumentu, je technologie platformě a jazykově nezávislá, objektově orientovaná reprezentace XML nebo HTML dokumentu, umožňující přístup k dokumentu a jeho datové struktuře. K dokumentu je přistupováno jako ke stromu (datová struktura s propojenými uzly). eXtensible Markup Language
26
Hypertext Preprocessor
27
Asynchronous JavaScript and XML
28
Document Object Model
29
44
Pro realizaci vlastního mapového serveru jsou využívány knihovny PROJ.4 a GDAL 30 . PROJ.4 je knihovna kartografických projekcí, která zajišťuje práci s různými souřadnými systémy. Díky této knihovně je možné používat podklado-‐‑ vá data a zdrojové mapy v různých projekcích současně i v reálném čase. GDAL je určená pro zápis a čtení rastrových GIS formátů, vyvíjená pod hlavičkou Open Source Geospatial Fundation. Obě knihovny jsou open source projekty, využívané v komerční i nekomerční sféře (Google Earth, GRASS GISS, ArcGIS).
6.4.2 Programové nástroje Safari – internetový prohlížeč společnosti Apple, používaný zejména pro tvorbu, revizi, ladění a testování systému. Díky podpoře HTML5 historie AJAX, umožňuje vývojáři vytvářet interaktivní dynamické aplikace, založené na technologii AJAX. Zásadním nástrojem pro vývoj webových aplikací je Web Inspector, který posky-‐‑ tuje rychlý přístup k bohaté sadě vývojářských nástrojů pro správu HTML kódu, skriptů, kaskádových stylů a databázových úložišť. Web Inspector obsahuje ná-‐‑ stroje Elements, Resources, Scripts, Timeline, Profiles, Storage a Console. Nástroj Elements slouží k správě, prohledávání a revizi HTML kódu a vlastností CSS31. Parametry CSS je možné editovat v záložce Styles, přičemž se úpravy ihned projeví na zobrazené stránce. Záložka Properties informuje o jednotlivých elemen-‐‑ tech z hlediska DOM. Nástroj Resources poskytuje údaje o průběhu nahrávání stránky, provádí analýzu časové náročnosti provádění skriptů a načítání dokumentů. Výstupem analýzy je graf doby načítání jednotlivých souborů a jejich velikostí. Klíčovými parametry jsou Start Time (čas začátku nahrávání souboru), End Time (čas dokončení staho-‐‑ vání souboru), Response Time (rychlost poskytnutí souborů serverem), Duration (doba stahování souboru) a Latency (doba mezi požadavkem na server a jeho od-‐‑ povědí). Další možností monitoringu, týkající se měření časové náročnosti je ná-‐‑ stroj Timeline. Nástroj Scripts poskytuje podporu při ladění skriptů v jazyce JavaScript. Po výbě-‐‑ ru laděného skriptu, je možné kliknutím na zvýrazněné místo zastavení zpracová-‐‑ ní skriptu (breakpoint), zobrazit relevantní informace o hodnotách proměnných, stavu zásobníku volání atd. K měření výkonu JavaScriptových funkcí slouží nástroj Profiles, který umožňuje zaznamenání veškerého dění na stránce a analýzy příslušných JavaScriptových funkcí vložením příkazů pro profilování přímo do kódu. Správa souborů na serveru je realizována pomocí jednoduchého FTP32 klientu Cy-‐‑ berduck. Tento FTP klient je navržen pro operační systém Mac OS X pod licencí GPL33 a podporuje šifrovanou komunikaci. Geospatial Data Abstraction Library
30
Cascading Style Sheets
31
File Transfer Protokol
32
45
Pro zápis a editaci skriptů je použit editor TextWrangler, vyvinutý společností Ba-‐‑ re Bones Software. Editor podporuje zvýrazňování syntaxe více než třiceti jazyků (syntax highlighting), multisouborové vyhledávání a nahrazování, editaci uživa-‐‑ telského slovníku, obsahuje zabudovaný FTP klient a disponuje širokou nabídkou kódování. Vytvoření databáze se systémem řízení báze dat MySQL, modifikace databáze a její správa, jsou řešeny prostřednictvím webového rozhraní phpMyAdmin, ná-‐‑ stroje zapsaného v jazyce PHP. Rozhraní umožňuje rychlou editaci databáze, se-‐‑ stavování SQL dotazů a vizualizovaný přímo editovatelný výstup. Pro implementaci vlastního mapového serveru je využit webový server Apache HTTP Server s otevřeným kódem, který je zodpovědný za vyřizování HTTP po-‐‑ žadavků zaslaných klienty (webovými prohlížeči) a odeslání webové stránky. V rámci projektu je instalován a využíván mapový server MapServer univerzity v Minnesotě, který nabízí otevřenou platformu pro publikování prostorových dat a interaktivní mapové aplikace na webu.
6.5 Postup realizace systému Po důkladném prostudování problematiky geografických informačních systémů, analýze možností uchování GPS údajů v metadatech digitálních fotografií a defi-‐‑ nování metodiky i technologií, bylo pro návrh aplikace umožňující zobrazení fo-‐‑ tografií na mapě dle polohových údajů zapsaných v Exif, zvoleno následující po-‐‑ řadí implementace jednotlivých modulů: •
vytvoření databáze pro uchování informací o fotografiích, návrh aplikace pro práci s relevantními metadaty fotografií, •
•
přiřazení GPS souřadnic do metadat fotografie,
ošetření nahrávání fotografií, • •
• •
vytvoření vhodné adresářové struktury, instalace webového serveru, instalace vlastního mapového serveru, získání vhodných mapových podkladů, konfigurace mapového serveru, návrh webového rozhraní pro práci s mapserverem, naprogramování ovládacích prvků mapy,
fyzické nahrání dat na server, zápis informací do databáze,
zajištění prezentace fotografií přímo na mapě, vytváření fotografických alb,
General Public License
33
46
• • • •
navrhnutí principu automatického seskupování fotografií, implementace funkcionality v aplikaci,
realizace modulu pro vyhledávání tras, integrace všech součástí do funkčního systému.
47
7 Vlastní řešení 7.1 Implementace vlastního mapového serveru První prototypy mapového serveru jsou implementovány a vyvíjeny na původně lokálním počítači, běžícím pod operačním systémem Windows XP. Pro realizaci funkčního serveru, poskytujícího mapové služby prostřednictvím webové aplika-‐‑ ce, je instalován webový server Apache HTTP Server, modul PHP pro Apache a databáze MySQL.
7.1.1 Vytvoření vhodné adresářové struktury Na severu je vytvořena adresářová struktura s ohledem na bezpečný přístup k datům. Mapový server data nedistribuuje, ale zprostředkovává na ně náhled, což je důvodem skladování dat v adresáři odděleném od vlastní webové aplikace. Vytvořená adresářová struktura proto jednoznačně stanovuje, ke kterým datům má přístup uživatel z webové aplikace, a které obhospodařuje výhradně mapový server. Tab. 3: Adresářová struktura mapového serveru
adresář s daty podadresář s vlastními daty podadresář se šablonami adresář s CSS a applety dočasné výsledné obrázky pro klienta vlastní CGI mapserver Instalace Apache 2.0.x serveru Instalace MySQL serveru Instalace PHP
7.1.2 Instalace webového serveru Je instalována binární verze HTTP Apache Server 2.0.x, která je k dispozici na ad-‐‑ rese http.apache.org. Instalací je ve Windows XP vytvořena služba Apache2, která startuje po spuštění serveru. Pro rychlé spouštění, zastavení a restartování serveru slouží monitorovací aplikace Monitor Apache Servers, monitorující běh HTTP ser-‐‑ veru. V konfiguračním souboru HTTP Apache serveru httpd.conf je nastaven koře-‐‑ nový adresář webové aplikace následovně: DocumentRoot “c:/web/www“ Kromě standardnímu naslouchání serveru na portu 127.0.0.1:80 (localhost), je na-‐‑ stavena pomocí položky Listen také pevná IP adresa lokálního stroje 192.168.1.10, protože adresa localhostu není dostupná z LAN sítě. Listen 127.0.0.1:80 Listen 192.168.1.10:80
48
V souboru .htaccess jsou definovány možnosti práce na kořenovém adresáři webu a služby: Options Indexes Includes FollowSymLinks MultiViews AllowOverride All Order allow,deny Allow from all Pro vývoj jednotlivých prototypů byly nakonfigurovány samostatné domény, kte-‐‑ rým byly přiřazeny vlastní adresáře. Příklad konfigurace dvou domén v souboru httpd.conf, sloužící pro přístup k prototypům modulu nahrávání fotografií na ser-‐‑ ver: DocumentRoot "ʺC:/web/www/upload/prototyp1"ʺ ServerName www.upload1.cz ServerAlias upload1.cz DocumentRoot "ʺC:/web/www/upload/prototyp2"ʺ ServerName www.upload2.cz ServerAlias upload2.cz Na server je nainstalována podpora PHP ve formě modulu Apache serveru a na-‐‑ stavena systémová PATH na c:\web\prg\php. Instalovány jsou také rozšiřující knihovny Aspell a české slovníky a je doplněn konfigurační soubore HTTP Apa-‐‑ che serveru httpd.conf pro podporu PHP modulu: DirectoryIndex index.html index.htm index.php cr.php uplod.php latlng.php LoadModule php5_module "ʺc:\web\prog\php\php5apache2_2.dll"ʺ AddType application/x-‐‑httpd-‐‑php .php AddType application/x-‐‑httpd-‐‑php-‐‑source .phps Nainstalovány jsou rozšiřující knihovny php_mbstring.dll a php_exif.dll a potřebná konfigurace PHP modulu pro podporu některých rozšíření pro práci s MySQL a zejména s formátem Exif u digitálních fotografií, je v souboru php.ini zapsána ná-‐‑ sledovně: extension=php_mbstring.dll extension=php_exif.dll extension=php_curl.dll extension=php_gd2.dll extension=php_mbstring.dll extension=php_pdo.dll extension=php_xmlrpc.dll extension=php_mysql.dll
49
extension=php_mysqli.dll extension=php_pspell.dll extension=php_sqlite.dll extension=php_pdo_mysql.dll extension=php_pdo_sqlite.dll extension=php_mcrypt.dll Po instalaci třetí stěžejní komponenty – MySQL databázového serveru, je připra-‐‑ ven webový server pro většinu běžných úkonů. Pro řešení dotazů nad prostoro-‐‑ vými daty, je dále instalován vlastní mapový server.
7.1.3 Instalace vlastního mapového serveru První série vyvíjených prototypů je implementována na mapovém serveru Minne-‐‑ sotské Univerzity MapServer, uvolněný pod licencí GNU GPL – všeobecnou ve-‐‑ řejnou licencí GNU, poskytující dostatečnou svobodu využívání produktu. Mapo-‐‑ vý server je implementován jako CGI-‐‑program, vracející hotovou internetovou stránku s mapou na základě vstupních parametrů a šablony (MapServer, 2010). MapServer je možné instalovat z předpřipravených programových balíků, jako je například MS4W, zahrnující základní i rozšiřující knihovny pro práci s geodaty, MapServer, Apache HTTP Server i modul PHP. Protože je PHP i server Apache již instalován samostatně, se specifickou konfigurací, jsou doinstalovány pouze po-‐‑ třebné knihovny, zejména: • •
knihovna GDAL/ORG, sloužící k načítání různých formátů vektorových i rastrových dat, knihovna Proj, starající se o převody mezi souřadnými systémy.
7.1.4 Získání vhodných mapových podkladů Aktuální a přesné mapové podklady jsou stěžejním východiskem pro úspěch ce-‐‑ lého projektu. Existuje několik institucí státního i veřejného sektoru, které posky-‐‑ tují volně dostupné mapové podklady, popisující zejména území České republiky. Je možné získat vektorové i rastrové mapy ČR, přičemž je třeba při výběru dbát na aktuálnost mapového podkladu. Takovými institucemi jsou například: • • •
Ministerstvo dopravy, Ředitelství silnic a dálnic, Cenia34.
Ze zdrojů Ministerstva dopravy a Ředitelství silnic a dálnic jsou využity vektorové mapy, týkající se dopravní infrastruktury na území ČR (železniční síť, silniční a dálniční síť). Portál Cenia nabízí nejen využití vlastního mapového serveru, ale také množství různých mapových podkladů, týkajících se zejména životního pro-‐‑ středí. Pro účely projektu jsou použity mapové vrstvy rastrové i vektorové, týkají-‐‑ cí se zástavby, vodních doků a názvů ulic. Česká informační agentura životního prostředí
34
50
V zásadě jsou dvě základní možnosti, jak zásobovat mapový server potřebnými mapovými podklady, nad kterými může vykonávat operace: • •
mapový server využívá vlastní rastrové a vektorové mapy, mapový server využívá mapových podkladů třetí strany.
V prototypech systému, využívajících MapServer, jsou kombinovány obě možnos-‐‑ ti, pro vytvoření výsledné mapové kompozice. Vektorová data sloužící pro vyhle-‐‑ dávání tras, získaná z výše uvedených zdrojů, jsou uložena přímo na serveru v adresáři c:\web\mapservdata\data\. Jako základní vrstva je použita rastrová vrst-‐‑ va reliéfu ČR, přes kterou jsou zobrazovány ostatní vrstvy, na základě uživatel-‐‑ ského nastavení. Část rastrových mapových vrstev je získávána přímo s využitím mapových služeb serveru geoportal.cenia.cz a kombinována s lokálními prostorovými daty, pro-‐‑ střednictvím služby klient-‐‑server mapové služby WMS. Základní formát adresy pro WMS dotazování nad geoportálem Cenia je: http://geoportal.cenia.cz/wmsconnector/com.esri.wms.Esrimap/ Místo položky nazev_sluzby je dosazován dle potřeby identifikátor mapového podkladu. Pro použití bez specializovaných programů je nutné v adrese na mapo-‐‑ vý zdroj definovat dle potřeby následující WMS dotazy: • • •
GetMap, v URL definován parametrem REQUEST=GetMap, GetCapabilities, v URL definován parametry REQUEST=GetCapabilities a SERVICE=WM, GetFeatureInfo, definovaný parametrem REQUEST=GetFeatureInfo.
Použitá rastrová data jsou ve formátu TIFF a PNG, vektorové mapové vrstvy jsou reprezentovány několika soubory. U souborů ve formátu ESRI Shape File jsou to zejména soubory s příponou .shp, .shx a .dbf, které jsou povinné pro uložení zá-‐‑ kladních údajů. Digitální vektorový formát popisuje prostorovou geometrii kři-‐‑ vek, bodů a polygonů, a může obsahovat i další volitelné soubory. Používány jsou následující soubory, tvořící formát Shape File: • • • •
.shp – obsahuje informace o vektorech a základní geografické referenční údaje, .shx – tvarový index formátu, umožňující rychlé prohledávání, .dbf – tabulka s atributy ve formátu dBase, .prj – popisuje souřadný systém a projekci.
Polohová data o jednotlivých bodech a vektorech jsou použita jako soubor vstup-‐‑ ních informací pro algoritmus vyhledávání cest.
7.1.5 Konfigurace mapového serveru Nastavení mapového serveru MapServer je provedeno v konfiguračním souboru Mapfile s příponou .map. Pomocí souboru Mapfile je definována zobrazovaná ob-‐‑ last a způsob vykreslovaní jednotlivých vrstev. Je možné zobrazit či skrýt vrstvy, nastavit jim průhlednost, přiřadit vektorovým vrstvám parametry, jako je barva
51
a tloušťka čáry, nebo symbol. Mapfile také definuje použité kartografické zobra-‐‑ zení. Konfigurační mapfile soubor musí být dostupný ze strany klienta, proto je uložen v adresáři s daty: c:\web\mapservdata\ Konfigurační soubor obvykle obsahuje tři základní objekty s různými vlastnostmi. Územím, referenční mapou, kartografickou projekcí a podobnými parametry, je definován objekt MAP. Objekt MAP umožňuje nastavit globální vlastnosti výsled-‐‑ né mapové kompozice. Jednotlivé vrstvy, které je možné dělit na třídy – CLASS, jsou definovány položkou LAYER. Třídy disponují vlastním stylem zobrazení STYLE a každý objekt je ukončen slovem END. Základní struktura konfiguračního souboru je následující: MAP
… END
LAYER CLASS STYLE LABEL CLASS … LAYER
Mapfile je poměrně obsáhlý soubor, definující veškeré zobrazené prvky na mapě, které poskytuje mapový server, jejich vzhled a způsob zobrazení. Pro názornost jsou níže uvedeny pouze některé podstatné položky, jejichž význam je pro funkci-‐‑ onalitu systému esenciální: • • • • •
• •
STATUS – nastavení výchozího příznaku zobrazení vrstvy parametry ON, OFF a DEFAULT, TYPE – definuje datový typ na plochy, linie, body nebo rastr, DATA – určuje soubor s daty, SHAPEPATH – uvádí cestu k adresáři s uloženými daty z pohledu mapserveru, WEB – definuje šablonu pro generování webového rozhraní (TEMPLATE), adresář pro ukládání obrázků (IMAGEPATH) a URL tohoto adresáře (IMAGEURL), EXTENT – definuje hraniční souřadnice projektu, PROJECTION – objekt definující pro celý projekt i pro jednotlivé vrstvy projekci, ve které pracují; projekci je možné definovat jménem, referenčním elipsoidem a jeho parametry, ručně nebo použitím standardizovaného předdefinovaného číselného kódu EPSG35 (pro defaultně zobrazovanou ob-‐‑ last ČR je použit kód 2065).
European Petroleum Survey Group
35
52
Části Mapfile definující projekt a některé použité mapové vrstvy: MAP
NAME 'ʹCr'ʹ SIZE 800 530 EXTENT -‐‑905634.3618 -‐‑1228293.7588 -‐‑430134.3618 -‐‑935193.7588 UNITS meters SHAPEPATH "ʺ/web/mapservdata/data/"ʺ IMAGECOLOR 206 218 182 IMAGETYPE PNG FONTSET 'ʹtmpls/font.list'ʹ WEB TEMPLATE "ʺ/web/www/mapserver/cr.html"ʺ IMAGEPATH "ʺ/web/www/mapserver/temp/"ʺ IMAGEURL "ʺ/mapserver/temp/"ʺ END … LAYER NAME 'ʹvod_pl'ʹ DATA vod_pl STATUS OFF TYPE POLYGON TRANSPARENCY 55 PROJECTION "ʺinit=epsg:2065"ʺ END CLASS NAME 'ʹVodní plochy'ʹ STYLE COLOR 100 140 255 END END END LAYER NAME 'ʹcr_relief'ʹ DATA cr_relief.tif TYPE RASTER STATUS DEFAULT END LAYER NAME 'ʹsilnice'ʹ CLASSITEM 'ʹTRIDA_SIL'ʹ TYPE LINE …
53
CLASS NAME 'ʹdálnice'ʹ EXPRESSION 'ʹD'ʹ STYLE WIDTH 3 COLOR 0 0 0 END END …
7.1.6 Návrh webového rozhraní pro práci s mapserverem Základním principem vytváření webového rozhraní, které ovládá mapový server, je využití schopnosti implementovaného serveru MapServer generovat mapy spo-‐‑ lečně s webovými stránkami. Internetové stránky, neboli webové rozhraní mapo-‐‑ vého serveru, jsou vytvářeny na základě HTML šablon, uložených v příslušném adresáři. Mapový server je CGI program a na základě uživatelem zadaných parametrů, na-‐‑ příklad do formulářových polí HTML rozhraní, vrací náležitou mapovou kompo-‐‑ zici. Statickou mapu je možné generovat v těle webové stránky pomocí obrázku, se zdrojem generovaným mapovým serverem: Po nasměrování webového prohlížeče na příslušný soubor mapového serveru, je vrácena stránka definovaná šablonou, která obsahuje příslušnou mapu: http://192.168.1.10/cgi-‐‑bin/mapserv?map=/web/mapservdata/cr.map Tímto postupem je však získán pouze statický obrázek, vykreslený mapovým ser-‐‑ verem. Mapu je možné ovládat příslušným vstupy z formulářů, které po odeslání předají serveru nové údaje například o výseku mapy, který je třeba vidět, nebo o míře přiblížení. Pro zlepšení uživatelského komfortu a práci s mapou bez nut-‐‑ nosti znovunačtení celé stránky je v druhé řadě prototypů rozhraní mapového serveru použit pro vykreslovaní mapy java applet jBox, jehož nahrazení použitím dynamického HTML by bylo velmi obtížné. Applet jBox disponuje sadou funkcí, které umožňují mimojiné propracovaný zo-‐‑ om a posun. Applet jBox je instalován pouhým umístěním souborů jBox.class a jBox.jar do adresáře c:\web\www\mapserver\jbox\. Použití pro generování mapy v HTML šabloně je následující:
7.1.7 Naprogramování ovládacích prvků mapy Ošetření základního ovládání mapy v podobě přibližování, oddalování a posunu pomocí myši, je ošetřeno implementací java appletu jBox. Ovládání zobrazení jed-‐‑ notlivých vrstev je řešeno zaškrtávacími políčky formuláře. Dále jsou přidány další ovládací a informační prvky: • • • •
legenda – informační prvek popisující objekty na mapě a symboly, které je reprezentují, měřítko – informace o měřítku mapy, vypovídající o zmenšení zobrazova-‐‑ ného prostorů vůči skutečnosti, referenční mapa – zmenšenina celé mapy, na které je vyznačena oblast, kte-‐‑ rá je aktuálně zobrazena na mapě hlavní, měření ploch a vzdáleností.
Ovládání mapy pomocí funkcí jBox je v HTML šabloně implementováno násle-‐‑ dovně: function setbox_handler(name, minx, miny, maxx, maxy) { document.mapserv.imgbox.value = minx + "ʺ "ʺ + miny + "ʺ "ʺ + maxx + "ʺ "ʺ + maxy; document.mapserv.imgxy.value = minx + "ʺ "ʺ + miny; document.mapserv.submit(); } function seterror_handler(message) { alert(message); } …
Ovládací a informační prvky závislé na službách poskytovaných mapovým serve-‐‑ rem jsou definovány v HTML šabloně a v konfiguračním souboru cr.map. Mapový server opět generuje požadované informace v internetové stránce na výstupu. Implementace legendy v souboru Mapfile, kde je příslušná šablona pro prvek de-‐‑ finována značkou TEMPLATE: LEGEND KEYSIZE 12 12 STATUS ON LABEL TYPE BITMAP SIZE MEDIUM COLOR 206 218 182 END TEMPLATE "ʺtmpls/legenda.html"ʺ END Legenda v HTML šabloně:
Legenda:
[legend]
Implementace měřítka v souboru Mapfile, kde status EMBED znamená integraci měřítka přímo v mapě: SCALEBAR ALIGN center INTERVALS 5 … UNITS kilometers INTERVALS 2 TRANSPARENT TRUE STATUS EMBED END
56
Měřítko v HTML šabloně:
Měřítko: 1:<script language="ʺJavaScript"ʺ> document.write(Math.round([scale]/100)*100);; Oblast: Česká Republika; Souř. sys.: S-‐‑JTSK;
Implementace referenční mapy v souboru Mapfile, pro kterou jsou nastaveny hra-‐‑ niční souřadnice tagem EXTENT a nezbytná cesta k obrázku referenční mapy tagem IMAGE: REFERENCE IMAGE 'ʹtmpls/mapka2.png'ʹ EXTENT -‐‑905634.3618 -‐‑1228293.7588 -‐‑430134.3618 -‐‑935193.7588 STATUS ON … MARKERSIZE 24 MARKER 'ʹcross'ʹ SIZE 185 122 END Referenční mapa v HTML šabloně:
Další funkci, kterou přináší applet jBox, je měření vzdálenosti přímo na mapě po-‐‑ mocí myši. Je přidáno ovládací tlačítko, informační HTML element a výpočty za-‐‑ jišťuje funkce v jazyce JavaScript: function measure_handler(name, s, t, n, a) { var c= 1/72/39.3700787/1000; var f = [scale] * c; var plocha=a*f*f; var text; if ((s>0) || (t>0)) { text = "ʺPoslední úsek: "ʺ + Math.round(s*f) + "ʺ km Celková délka: "ʺ + Math.round(t*f) + "ʺ km PoËet uzl˘: "ʺ + n + "ʺ Celková plocha: "ʺ + Math.round(plocha)+"ʺ km<sup>2"ʺ; document.getElementById('ʹvzdalenost'ʹ).innerHTML= text; } } … Měření …
57
Implementací popisovaných funkcí je vytvořen vlastní mapový server, nabízející dostatečné služby spojené s poskytováním prostorových informací uživateli, který lze využít pro realizaci všech zamýšlených služeb spojených s metadaty digitál-‐‑ ních fotografií. Server je hardwarově nezávislý a využívá převážně vlastní mapo-‐‑ vé podklady, což však přináší do budoucna nevýhodu v podobě nutné aktualizace podkladů vlastními silami. Část podkladů je dodávána třetí stranou, pomocí služ-‐‑ by WMS.
7.2 Databáze pro uchování informací o fotografiích Kromě informací uložených přímo v souborech mapových vrstev, je třeba ucho-‐‑ vávat data týkající se vlastních digitálních fotografií a fotografických alb. Fotogra-‐‑ fie nahrané do systému mapového serveru jsou uchovávány v podobě původních obrazových souborů v příslušném datovém adresáři, který je přístupný webové aplikaci z internetu. Databáze je vytvořena na serveru a spravována multiplatformním databázovým systémem MySQL, který je volně šiřitelný. Dotazování nad databází probíhá po-‐‑ mocí modifikovaného a rozšířeného jazyka SQL, a pro správu databáze je použito webové rozhraní phpMyAdmin. Nainstalovaný databázový systém MySQL tvoří společně s PHP a Apache základní programové vybavení webového serveru. Každé nahrané fotografii je přiřazený jednoznačný identifikátor id, sloužící jako primární klíč v databázi a pro identifikaci fotografie při práci ve webovém rozhra-‐‑ ní celého systému. Kromě informací o jménu fotografie a cestě k vlastnímu soubo-‐‑ ru jsou podstatná polohová data. Zeměpisná šířka (Latitude) a délka (Longitude) jsou uloženy ve tvaru desetinného čísla (sloupce x a y) a je použit datový typ, jenž umožňuje zachování vysoké přesnosti lokalizace, díky svému rozsahu. Určení po-‐‑ lokoule pro zeměpisnou šířku a délku jsou uloženy ve sloupcích xRef a yRef, kdy je použit datový typ jednoho znaku, neboť sloupec xRef může nabývat hodnot „N“ a „S“ (North a South) a sloupec yRef hodnot „E“ a „W“ (East a West). Pokud obsa-‐‑ huje fotografie také informace o nadmořské výšce, je uložena do sloupce z. Důleži-‐‑ tou položkou záznamu každé fotografie je sloupec album, který v případě, že je nenulový, odkazuje na příslušnost k určitému albu, které vytvořil uživatel. Esenciální tabulka databáze – fotky, uchovává podstatné informace o uložených fotografiích a má strukturu popsanou tabulkou 4. Další podstatnou strukturou je tabulka alba, kterou popisuje tabulka 5. Tab. 4: Datová struktura tabulky fotky
Sloupec id jmeno cesta x y xRef
Typ int(10) varchar(200) varchar(200) double double char(1)
Vlastnosti UNSIGNED
Nulový Ne Ne Ne Ano Ano Ano
Klíč Primary Key
58
yRef z pozn album
char(1) smallint(6) text int(10)
Ano Ano Ano Ano
Foreign key
Nulový Ne Ne Ano Ano
Klíč Primary Key
Tab. 5: Datová struktura tabulky alba
Sloupec id jmeno počet pozn
Typ int(10) varchar(200) smallint(6) text
Vlastnosti UNSIGNED
7.3 Aplikace pro práci s relevantními metadaty fotografií S digitálními fotografiemi je mnohdy uložena v jejich metadatech celá řada infor-‐‑ mací. Pro potřeby projektu jsou však relevantními metadaty myšleny informace o poloze fotografie, uložené ve formátu Exif. Pro práci s metadaty fotografií ve formátu Exif je použit jazyk PHP, který pro tyto potřeby poskytuje speciální rozšíření v podobě knihovny php_exif.dll. Rozšíření podporuje práci se soubory JPEG i TIFF a je nutné nejdříve nainstalovat a nakonfi-‐‑ gurovat příslušné knihovny na PHP serveru. PHP je třeba kompilovat s řádkem „-‐‑-‐‑enable-‐‑exif“ v konfiguračním souboru php.ini. V případě, že server běží pod systémem Windows, je nutná také instalace a konfi-‐‑ gurace rozšíření mbstring, přičemž php_mbstring.dll je nutné zkompilovat před php_exif.dll (PHP, 2010). Načtení informací z Exif probíhá následujícím zápisem ve skriptu: $exif = exif_data_read($cesta_k_fotce); Funkcí je načten kompletní balík informací do asociativního pole. V případě, že ve fotografii Exif není, vrací hodnotu false. Z asociativního pole jsou relevantní in-‐‑ formace o poloze fotografií, jejichž identifikátory jsou následující: • • • • •
GPSLatitude – zeměpisná šířka, GPSLongitude – zeměpisná délka, GPSLatitudeRef – určení polokoule pro zeměpisnou šířku („N“ nebo „S“), GPSLongitudeRef – určení polokoule pro zeměpisnou délku („E“ nebo „W“), GPSAltitude – nadmořská výška.
K výpočtům je vhodný desetinný formát GPS souřadnic. Základním prvkem apli-‐‑ kace je tedy funkce toNumber, která se stará o převod zlomkového zápisu stupňů, minut a sekund na desetinné číslo: function toNumber($val, $prec = 2) { $val2 = 0; $prec = $prec * 10;
Další práce s formátem Exif je popsána v následující kapitole.
7.4 Nahrávání fotografií Subsystém nahrávání fotografií je tvořen několika podstatnými částmi, které spo-‐‑ lečně zajišťují úspěšné vložení fotografie: • • •
rozhraní pro nahrávání fotografií a fyzický zápis souborů na server, zpracování polohových informací uložených v metadatech fotografií, zápis informací do databáze.
Rozhraní pro nahrávání fotografií umožňuje výběr a dávkové nahrávání více foto-‐‑ grafií najednou, přičemž je kontrolováno, zda nedochází k duplicitám. Pro vysoký uživatelský komfort je použita technika AJAX, umožňující práci s formulářem bez nutnosti obnovování příslušné stránky a je průběžně zobrazován stav nahrávání, přenosová rychlost a další informace. Položkou „Procházet"ʺ je aktivováno prohledávání počítače, na kterém je spuštěna webová aplikace systému. Po vybrání všech fotografií je možné dále jejich seznam editovat, smazat, nebo fyzicky nahrát na server za pomocí položky „Nahrát"ʺ. Na-‐‑ hrané fotografie ještě nejsou zapsány do databáze, lze tedy ještě před zápisem je-‐‑ jich seznam editovat. Jakmile je uživatel spokojen se seznamem fotografií, které chce zanést do databáze a zobrazit na mapě, spustí položkou „Vlož do DBS"ʺ sadu skriptů, které ošetřují práci s metadaty, zpracování a uložení příslušných záznamů o fotografiích. Interaktivní rozhraní je implementováno za použití modulární, objektově oriento-‐‑ vané sady nástrojů MooTools, což je framework zapsaný v jazyce JavaScript, a knihovny funkcí FancyUpload.
60
Obr. 13: Webové rozhraní pro nahrávání fotografií
Zpracování polohových informací uložených v metadatech fotografií, nahrání fy-‐‑ zického souboru a zápis náležitých informací do databáze, je provedeno po použi-‐‑ tí volby „Vlož do DBS”, které aktivuje provedení skriptu exif_dbs.php. Skript využí-‐‑ vá funkcí a objektů definovaných v externích souborech objekty.php a dbs.php. Soubor objekty.php definuje objekty, jejich vlastnosti a chování, které jsou při běhu systému využívány. Základním kamenem většiny operací je objekt „fotka”, který svou konstrukcí kopíruje datovou strukturu, která je zřízena pro ukládání infor-‐‑ mací o fotografiích do databáze. Definovány jsou také metody objektu – operace, které je možné provádět nad objektem. Deklarace objektu „fotka” je následující: class fotka { var $id; var $jmeno; var $cesta; var $xLatitude; var $yLongitude; var $xRef; var $yRef; var $zAltitude; var $pozn; var $album; function Nacti($i,$a,$b,$c,$d,$e,$f,$g,$h,$al) { $this-‐‑>id = $i; $this-‐‑>jmeno = $a; …
Skript dbs.php obsahuje funkce nezbytné pro práci s databází a využívá objekt fot-‐‑ ka, který je často předáván jako parametr funkce. Pro ilustraci jsou níže uvedeny pouze některé důležité funkce, jako je například připojení do databáze a zápis fo-‐‑ tografie do databáze. Funkce připojení do databáze: function PripojDBS ($server="ʺh90-‐‑mysql1"ʺ,$login="ʺmysql19108"ʺ,$heslo="ʺh_heslo"ʺ, $databaze="ʺmysql27007"ʺ) { MySQL_Connect($server, $login, $heslo) or die("ʺNepodařilo se připojit k databázi"ʺ); // připojení k databázi MySQL_Select_DB($databaze) or die("ʺNepodařilo se otevřít databázi"ʺ); } Funkce vložení do databáze: function ZapisFotoDBS ($id,$jmenosouboru,$rootway,$x,$y,$xref,$yref,$z,$pozn,$album) { $vysledek=mysql_query("ʺINSERT INTO fotky (id, jmeno, cesta, x, y, xref, yref, z, pozn, album) VALUES ('ʹ"ʺ.$id."ʺ'ʹ,'ʹ"ʺ.$jmenosouboru."ʺ'ʹ,'ʹ"ʺ.$rootway."ʺ'ʹ,'ʹ"ʺ.$x."ʺ'ʹ,'ʹ"ʺ.$y."ʺ'ʹ,'ʹ"ʺ.$xref."ʺ'ʹ, 'ʹ"ʺ.$yref."ʺ'ʹ,'ʹ"ʺ.$z."ʺ'ʹ,'ʹ"ʺ.$pozn."ʺ'ʹ,'ʹ"ʺ.$album."ʺ'ʹ)"ʺ); if (!$vysledek) {echo "ʺ Nepodařilo se zapsat do databáze! "ʺ;} $chyba = MySQL_Error(); echo $chyba."ʺ "ʺ; } Funkce výpisu jedné fotky z databáze do objektu fotka, pokud vrací SQL dotaz více než jeden řádek vypíše pouze první: function VytvorFotkuDBS ($sql,&$foto) {
62
}
$foto = new fotka; $vysledek=mysql_query($sql); $radky=mysql_num_rows($vysledek); if ($radky==0) echo "ʺV databázi není informace o žádné fotografii!"ʺ; else { $zaznam=MySQL_Fetch_Row($vysledek); $foto-‐‑>jmeno = $zaznam[0]; $foto-‐‑>cesta = $zaznam[1]; $foto-‐‑>xLatitude = $zaznam[2]; $foto-‐‑>yLongitude = $zaznam[3]; $foto-‐‑>xRef = $zaznam[4]; $foto-‐‑>yRef = $zaznam[5]; $foto-‐‑>zAltitude = $zaznam[6]; $foto-‐‑>pozn = $zaznam[7]; $foto-‐‑>album = $zaznam[8]; }
Skript exif_dbs.php, s využitím výše zmíněných knihoven funkcí a objektů, načte postupně informace o nahraných fotografiích a polohové informace uložené v me-‐‑ tadatech souborů ve formátu Exif, pokud jsou k dispozici. Informace jsou s použi-‐‑ tím objektu fotka zpracovány a zapsány do databáze a uživatel je přesměrován na HTML šablonu s mapou a fotografiemi. Načtení Exif dat z fotografie: $photo = $cesta.$jmenosouboru; $exif = exif_read_data($photo); Pro zpracování GPS souřadnic je naprogramována funkce toNumber, pomocí které jsou převáděny souřadnice uvedené ve stupních, minutách a sekundách na dese-‐‑ tinné číslo. Zjištěním, zda jsou ve fotografiích zapsány informace o poloze a při-‐‑ způsobením souřadnic správné polokouli se zabývá následující úryvek kódu: if (is_array($exif)) { $gpsComplete = true; if (!isSet($exif['ʹGPSLatitudeRef'ʹ])) { $gpsComplete = false; } if (!isSet($exif['ʹGPSLongitudeRef'ʹ])) { $gpsComplete = false; } if (!is_array($exif['ʹGPSLatitude'ʹ]) && count($exif['ʹGPSLatitude'ʹ]) > 2) { $gpsComplete = false; } if (!is_array($exif['ʹGPSLongitude'ʹ]) && count($exif['ʹGPSLongitude'ʹ]) > 2) { $gpsComplete = false; } } $gpsLonNum = toNumber($exif['ʹGPSLongitude'ʹ][0], 5) + (toNumber($exif['ʹGPSLongitude'ʹ][1], 5) / 60) + (toNumber($exif['ʹGPSLongitude'ʹ][2], 5) / (60 * 60));
63
$gpsLatNum = toNumber($exif['ʹGPSLatitude'ʹ][0], 5) + (toNumber($exif['ʹGPSLatitude'ʹ][1], 5) / 60) + (toNumber($exif['ʹGPSLatitude'ʹ][2], 5) / (60 * 60)); if (strToUpper($exif['ʹGPSLongitudeRef'ʹ]) != 'ʹE'ʹ) { $gpsLonNum = -‐‑$gpsLonNum; } if (strToUpper($exif['ʹGPSLatitudeRef'ʹ]) != 'ʹN'ʹ) { $gpsLatNum = -‐‑$gpsLatNum; } Vytvoření objektu fotka, jeho naplnění, využití pro informační výpis uživateli a zápis do databáze, ukončení práce se soubory a přesměrování: $foto = new fotka; $foto-‐‑>Nacti($id,$jmenosouboru,$rootway,$gpsLatNum,$gpsLonNum,$xref,$yref,$z, NULL,NULL); echo $foto-‐‑>Vypis($foto); … ZapisFotoDBS($id, $foto-‐‑>jmeno, $foto-‐‑>cesta, $foto-‐‑>xLatitude, $foto-‐‑>yLongitude, $foto-‐‑>xRef, $foto-‐‑>yRef, $foto-‐‑>zAltitude, $foto-‐‑>pozn, $foto-‐‑>album); copy($cesta.$jmenosouboru, "ʺphotos_in_dbs/"ʺ.$jmenosouboru); unlink($cesta.$jmenosouboru); closedir($adresar); header ("ʺlocation: http://dip.fotohemala.cz/cr.php"ʺ, TRUE, 303);
7.5 Reprezentace fotografií na mapě 7.5.1 Využití Google Maps API Vzhledem k ekonomické i časové nákladnosti získávání kvalitních a aktuálních mapových podkladů, velkých nároků na správu vlastních geodat a jejich aktuali-‐‑ zaci, je na základě podnětů testovací skupiny uživatelů, pro další prototypy ma-‐‑ pového serveru, využíváno Google Maps JavaScript API. Jedná se o programové rozhraní v jazyce JavaScript, které umožňuje využívat mapových podkladů spo-‐‑ lečnosti Google v desktopových i webových aplikacích. Rozhraní je implemento-‐‑ váno v podobě knihovny, pomocí jejichž funkcí je možné přistupovat k mapám a pracovat s nimi. Výhody spojené s využitím Google Maps API: • • • •
Mapové podklady nejsou omezené hranicemi ČR, jako tomu je u dosud získaných a použitých, volně dostupných geodat. Eliminace finančních i časových nákladů na údržbu a zejména aktualizaci geodat. Google Maps API poskytuje bohatou knihovnu funkcí pro práci s mapou a její využití. Odpadá nutnost nadále provozovat a udržovat vlastní serverový stroj s ge-‐‑ odaty.
64
Nevýhody: • •
Nutná adaptace existujících prototypů webového rozhraní pro práci s ma-‐‑ povým serverem. Z licence pro užívání Google Maps API a mapových podkladů společnosti Google vyplívá, že je není možné užívat v produktech určených ke ko-‐‑ merční distribuci. V případě transformace projektu na komerční produkt, by bylo tedy nutné počítat s nákupem náležitých licencí.
Implementace Google Maps API V3 v HTML šabloně mapového serveru je prove-‐‑ dena zavedením příslušného skriptu, a na rozdíl od předchozí verze, není nutné generovat speciální klíč pro danou webovou stránku (Google Code – Google Maps JavaScript API V3, 2010): <script type="ʺtext/javascript"ʺ src="ʺhttp://maps.google.com/maps/api/js?sensor=true &language=cs®ion=CZ"ʺ> Po zavedení API se vlastní mapová kompozice generuje v šabloně pomocí vsuvky v jazyce JavaScript a je možné využití veškerých objektů a metod definovaných knihovnami Google Maps API. Vlastní funkce a objekty jsou zapsány v souboru gskript.js. K zobrazení mapy slouží funkce „initialize”, která vytváří objekt „myLatlng” defi-‐‑ nující souřadnice středu zobrazené mapy. Zobrazená plocha je dále určena para-‐‑ metrem „zoom”, který je použit při vzniku dalšího objektu – „map"ʺ, jehož deklarací a použitím metody „directionsDisplay.setMap(map)” je zajištěno i vykreslení mapy. Zobrazení mapy je, pomocí DOM, zacíleno do náležitého elementu HTML šablo-‐‑ ny. Funkce „initialize” má následující tvar: function initialize() { var myLatlng = new google.maps.LatLng(49.7644, 15.7738); var myOptions = { zoom: 8, center: myLatlng, scaleControl: true, mapTypeId: google.maps.MapTypeId.TERRAIN }; map = new google.maps.Map(document.getElementById("ʺmap_canvas"ʺ), myOptions); directionsDisplay.setMap(map); directionsDisplay.setPanel(document.getElementById("ʺdirectionsPanel"ʺ)); }
7.5.2 Vlastní zobrazování fotografií Po spuštění webového rozhraní je, na straně serveru a před vykreslením stránky v prohlížeči, provedeno dotazování nad databází. Pomocí PHP, funkcí a objektů zapsaných v dbs.php, je vytvořena proměnná „$pole”. Jednotlivé prvky tohoto pole
65
jsou tvořeny objekty „fotka”, které jsou naplněny údaji o jednotlivých fotografiích z databáze:
include 'ʹdbs.php'ʹ; PripojDBS(); VytvorPoleFotekDBS('ʹSELECT * FROM `fotky`'ʹ); $fotekvpoli = count ($pole);
Ve skriptu gskript.js je zapsán objekt „fotka” se stejnou datovou strukturou, jako stejnojmenný objekt používaný na straně serveru, z něhož je opět vytvořeno pole objektů. Načtení PHP proměnné „$pole” a její přiřazení proměnné v jazyce JavaScript je realizováno pomocí datového formátu JSON36 – na platformě nezávis-‐‑ lého objektového zápisu pro přenos dat (JSON, 2010). Vstupem formátu JSON je libovolná datová hodnota a výstupem řetězec, který je pomocí funkce „eval” kon-‐‑ vertován na objekt. Zápis v HTML šabloně vypadá následovně: var polefotek = eval(); Tímto je získáno pole objektů, které reprezentují jednotlivé fotografie v systému. Tato proměnná je využívána pro operace a výpočty na straně klienta. Vlastní zob-‐‑ razení fotografií je realizováno průchodem všech prvků pole v cyklu a provádě-‐‑ ním funkce „MapujFoto” nad jednotlivými objekty: for (i in polefotek) { foto = new fotka(polefotek[i].id,polefotek[i].jmeno, polefotek[i].cesta, polefo tek[i].xLatitude , polefotek[i].yLongitude, polefotek[i].xRef, polefotek[i].yRef, polefotek[i].zAltitude, polefotek[i].pozn, polefotek[i].album); MapujFoto(foto); } Funkce „MapujFoto” zajišťuje generování fotografií na mapě. Každá fotografie je reprezentována pomocí prvku „InfoWindow”, který umožňuje zobrazit libovolný obsah daný zápisem HTML kódu. Parametrem InfoWindow je „Marker”, což je značka na mapě, která má svojí jednoznačnou polohu danou GPS souřadnicemi. Obsah InfoWindow je určen hodnotou položky „content”. Položce je přiřazena tex-‐‑ tová proměnná, která vzniká dynamicky – řetězením proměnných, HTML tagů a textu. Statický obsah HTML kódu je nutné uzavřít do apostrofů: function MapujFoto(foto) { var myLatlng = new google.maps.LatLng(foto.xLatitude, foto.yLongitude); var contentString = 'ʹ
'ʹ; var infowindow = new google.maps.InfoWindow({ content: contentString }); var marker = new google.maps.Marker({ position: myLatlng, map: map, }); google.maps.event.addListener(marker, 'ʹclick'ʹ, function() { infowindow.open(map,marker); }); } Jednotlivá InfoWindow obsahují kromě náhledu fotografie, který je generován ob-‐‑ jektem pro tvorbu náhledů v reálném čase, také ovládací prvky pro výmaz foto-‐‑ grafie, vytvoření alba nebo zahrnutí fotografie do plánované trasy. Kliknutím na náhled je fotografie zobrazena v novém okně, ve velikosti závisející na jejím rozli-‐‑ šení omezené oknem internetového prohlížeče.
Obr. 14: Zobrazení fotografií na mapě
67
7.6 Vytváření fotografických alb Povaha vyvíjeného projektu, kdy je fundamentálním leitmotivem prostorová loka-‐‑ lizace fotografií a práce s ní, ovlivnila podstatným způsobem i směr vývoje funk-‐‑ cionality seskupování fotografií do alb.
7.6.1 Princip slučování fotografií do alb Alba jsou vytvářena seskupováním fotografií automaticky, na základě jejich polo-‐‑ hy. Uživatel tedy nevytváří alba dle svévolného uvážení, obsahu fotografií nebo jiných preferencí, může však jejich obsah ovlivnit zadáním prostoru, ve kterém jsou fotografie seskupeny. Prostor je určen kružnicí, definovanou jejím středem a poloměrem. Střed kružnice lze stanovit výběrem některé z fotografií, které jsou již zobrazeny v systému. Po stisku příslušného ovladače je uživatel vyzván pro zadání názvu alba a vzdálenosti v metrech, definující poloměr kružnice, v rámci které budou fotografie zahrnuty do alba. V případě obrázku číslo 15, budou do alba zařazeny fotografie 85 a 82. Fotografie 115 se nenachází v zadané kružnici, proto zařazena nebude.
Obr. 15: Princip přiřazení fotografií do alba
68
Po zadání poloměru kružnice, je aplikován algoritmus, který najde fotografie na-‐‑ cházející se uvnitř, nebo na hranici zadané kružnice. Toto hledání probíhá nad ostatními fotografiemi v několika krocích: •
• •
výpočet vzdálenosti mezi dvěma body, kdy prvním bodem je vždy poloha fotografie, ze které je aktivováno vytvoření alba, a druhým souřadnice prá-‐‑ vě procházené fotografie, zjištění, zda je výsledná vzdálenost menší nebo rovna poloměru kružnice zapsání identifikátoru fotografie do pole reprezentující index alba.
Fotografiím, které se nachází v zadaném okruhu, je v databázi přiřazen cizí klíč ve sloupci album, který vytváří relaci s položkou v tabulce alba. Při spuštění webové-‐‑ ho rozhraní je fotografiím patřícím do některého z vytvořených alb, generován v InfoWindow nový ovládací prvek ve formě symbolu, který značí příslušnost k albu a odkazuje na ně.
Obr. 16: Zobrazení generovaných alb
69
V případě, že si uživatel rozklikne fotografii, která není v žádném albu, zobrazí se náhled této fotografie v samostatném okně. Pokud je fotografie zahrnuta v některém z albu, zobrazí se uživateli informace o albu, následovaná náhledy fo-‐‑ tografií. Automaticky je generováno album dalších fotografií v blízkém okolí – do 1000 metrů, a album fotografií v okolí – do 10 kilometrů. Je možné také zobrazit všechna alba chronologicky volbou Zobrazit alba v hlavním ovládacím panelu.
7.6.2 Výběr vhodného algoritmu pro výpočet vzdálenosti Výpočet vzdálenosti probíhá na modelu povrchu země. Země je rotační těleso s nepravidelným a členitým povrchem. Tvar země vystihuje matematický model v podobě rotačního geoidu, jehož povrch je však pro potřeby mapování stále příliš složitý, proto jej nahrazujeme referenčními plochami. Těmito plochami jsou refe-‐‑ renční elipsoid, referenční koule a referenční rovina (Čada, 2010). Odchylka při použití těchto referenčních ploch, se může od skutečnosti lišit v řá-‐‑ dech milimetrů až desítek metrů, v závislosti na poloze bodů na zemském po-‐‑ vrchu a vzdálenosti bodů. Proto je nutné zvolit algoritmus vhodný pro účel pro-‐‑ jektu. Ihned v úvodu je vyřazena možnost použití referenční roviny, kdy by se vzdálenost počítala Pythagorovou větou. V tomto případě by při větších vzdále-‐‑ nostech vznikala neúnosná odchylka. V případě algoritmů využívající referenční koule, jde o výpočet ortodromy, neboli nejkratší spojnice dvou bodů na kulové ploše.
Obr. 17: Ortodroma (Wikipedie, 2010)
Algoritmy počítající ortodromu, jsou zatíženy odchylkou v rozsahu jednotek me-‐‑ trů na jeden kilometr. Při použití referenčního elipsoidu, je možné dosáhnout přesnosti až 0,5 milimetrů v rámci celého elipsoidu, avšak algoritmus je časově ná-‐‑ ročnější, což může působit problém s odezvou systému v případě, že se počet fo-‐‑ tografií v databázi rozroste. Pro výběr algoritmu jsou tedy brány v úvahu jak přesnost výpočtu, tak jeho časová náročnost.
70
Pro testování jsou použity dva algoritmy využívající model referenční koule a al-‐‑ goritmus využívající referenčního rotačního elipsoidu: •
•
•
Great Circle – algoritmus využívaný mnohými navigačními přístroji i ma-‐‑ povým software. Vysoká rychlost algoritmu, který používá referenční kou-‐‑ li, je vykoupena větší odchylkou. Haversine – algoritmus také používá referenční kouli, je však sofistikova-‐‑ nější a dosahuje oproti Great Circle přesnějších výsledků, bez značného na-‐‑ výšení časové náročnosti. Vincenty – algoritmus využívá referenčního elipsoidu a dosahuje nejlepších výsledků, co se týče přesnosti výpočtu vzhledem ke skutečnosti. Odchylka se zásadně nezvyšuje s rostoucí vzdáleností.
Při testování byly porovnávány výsledky všech tří algoritmů a zvolena byla místa s řádově odlišnou vzdáleností, z důvodu ilustrace vlivu vzdálenosti na rostoucí odchylku algoritmů, které používají referenční kouli. Část reprezentativních vý-‐‑ sledků je uvedena v tabulce 6. Z tabulky vyplívá, že rozdíl mezi algoritmem Great Circle a Haversine je zanedba-‐‑ telný pro všechny testované vzdálenosti. Při porovnávání Vincenty a Haversine algoritmů, je první z nich méně přesný zejména na velké vzdálenosti, avšak rozdíl u vzdáleností desítek až stovek metrů je v řádech desítek centimetrů. Na základě zkušeností testovacích uživatelů, je většina alb tvořena v rámci desítek metrů až několika kilometrů a odchylka při vytváření alb o rozloze států nebo kontinentů je irelevantní, neboť alba jsou realizována na základě plochy, kterou tvoří kružnice. Proto je pro výpočet vzdálenosti dvou bodů používán algoritmus Haversine. Použitím algoritmu je také výrazně eliminována zátěž při výpočtech nad rozsáhlými databázemi, které mohou obsahovat tisíce fotografií. Tab. 6: Výsledky testování algoritmů pro výpočet vzdálenosti dvou bodů
Algoritmus pracuje s formulí Haversine a pro zpracování je nejdříve nutné převést souřadnice zadané ve stupních na radiány (Lewis, 2007):
!d$ havers # & = havers (lat1 − lat2 ) + cos (lat1 ) cos (lat2 ) havers ( Δlon ) "R% ! Θ $ (1− cos (Θ)) havers (Θ) = sin 2 # & = "2% 2
71
R je poloměr referenční koule, havers je funkce haversine, d je vzdálenost mezi dvěma body, lat1 je latitude prvního bodu, lat2 je latitude druhého bodu a ∆lon je rozdíl mezi longitude obou bodů. Implementace algoritmu Haversine v jazyce JavaScript je následující: function VzdalenostSphereHaversine(lat1, lon1, lat2, lon2) { var R = 6371; // km var dLat = (lat2-‐‑lat1).toRad(); var dLon = (lon2-‐‑lon1).toRad(); var a = Math.sin(dLat/2) * Math.sin(dLat/2) + Math.cos(lat1.toRad()) * Math.cos(lat2.toRad()) * Math.sin(dLon/2) * Math.sin(dLon/2); var c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1-‐‑a)); var d = (R * c) * 1000; //převod na metry return d ; }
7.7 Realizace modulu pro vyhledávání tras 7.7.1 Vstupní data a volba algoritmu Silniční, dálniční, železniční síť, cyklostezky nebo pěší stezky ve formě rastrových mapových vrstev je možné interpretovat jako nezáporný, ohodnocený a oriento-‐‑ vaný graf G, definovaný množinou hran E a množinou vrcholů V (West, 2007). V případě vektorových geodat je každá hrana (například úsek silnice nebo dálni-‐‑ ce) ohodnocená hodnotou, která reprezentuje její délku. Po převodu do požado-‐‑ vaného souřadného systému je poloha jednotlivých vrcholů jednoznačně repre-‐‑ zentována a je tak umožněno zobrazit vypočítanou cestu na mapě. Pokud máme definovaná data v podobě grafu, je možné pro nalezení nejkratší ces-‐‑ ty aplikovat například úplný Dijkstrův algoritmus, jehož aplikace je vzhledem k absenci nezáporných hran možná. Problém však nastává v případě rozsáhlých grafů, jaké reprezentují například evropskou silniční síť. V takových případech může výpočet pomocí Dijkstrova algoritmu trvat řádově desítky minut. Z tohoto důvodu používají mapové servery různé optimalizační metody, jako je například tvoření hierarchie dálnic nebo heuristická vylepšení Dijkstrova algoritmu. Vzhledem k tomu, že je při plánování tras nutné najít nejen cestu z jednoho bodu do druhého, ale nejkratší cestu, v rámci které navštívíme více míst vzniku fotogra-‐‑ fií, při požadavku úplné optimalizace, je nutné řešit problém obchodního cestují-‐‑ cího. Jedná se o problém, který je NP-‐‑těžký, tudíž je pravděpodobné, že se nepo-‐‑ daří najít deterministický algoritmus, jenž by umožňoval nalézt optimální řešení v polynomiálně omezeném čase (Hynek, 2008). Z tohoto důvodu existují různé přibližné algoritmy, algoritmy využívající heuristiku a genetické algoritmy. Modul plánování tras a využívá algoritmus implementovaný v Google Maps API, který zajištuje i optimalizační metodu, řešící problém obchodního cestujícího.
72
7.7.2 Implementace vyhledávání tras Funkce vyhledávání tras mezi dvěma body je implementována pomocí formuláře pro zadání výchozího a cílového bodu a způsobu dopravy (auto, kolo, pěšky). Po odeslání formuláře příslušným tlačítkem je, prostřednictvím definované vlast-‐‑ nosti onClick, spuštěna funkce „PlanujCestu”, která zajišťuje výpočty, vykreslení cesty na mapě a zobrazení informací o naplánované cestě. Do vyhledávání je možné zahrnout libovolnou fotografii, která je nahrána do sys-‐‑ tému a zobrazena na mapě, prostřednictvím zaškrtnutí CheckBox v InfoWindow fotografie. Zaškrtnutí provede funkci „ZapisFotoNaCeste”, jejíž prarametry jsou ID příslušné fotografie a polohové GPS souřadnice. Funkce zapíše fotografii do pole „fotky_na_ceste”, které slouží jako seznam fotografií, kterými prochází trasa: function ZapisFotoNaCeste(ind,x,y){ var souradnice = x + "ʺ, "ʺ + y; if (document.getElementById(ind).checked) { fotky_na_ceste[ind] = souradnice; document.getElementById("ʺtest"ʺ).innerText = document.getElementById("ʺtest"ʺ).innerText + fotky_na_ceste[ind]+"ʺ "ʺ; alert(fotky_na_ceste[ind]+"ʺ -‐‑ souřadnice fotografie č. "ʺ+ind+"ʺ jsou zahrnutydo příštího plánování trasy."ʺ); } else { fotky_na_ceste.splice(ind,ind++); document.getElementById("ʺtest"ʺ).innerText = document.getElementById("ʺtest"ʺ).innerText + fotky_na_ceste[ind]+"ʺ "ʺ; alert("ʺSouřadnice fotografie č. "ʺ+ind+"ʺ jsou vyřazeny z plánování trasy."ʺ); } } Funkce „PlanujCestu” načítá z formuláře začátek a konec cesty v textové podobě nebo v podobě GPS souřadnic, a také seznam bodů, které je třeba projít ve formě pole souřadnic. Optimalizace cesty zapojením řešení problému obchodního cestu-‐‑ jícího je zajištěna nastavením vlastnosti „optimizeWaypoints” na hodnotu „true”: function PlanujCestu() { var tstart = document.getElementById("ʺstart"ʺ).value; var tcil = document.getElementById("ʺcil"ʺ).value; var zastavky = []; var x; for (x in fotky_na_ceste) { zastavky.push({ location:fotky_na_ceste[x], stopover:true }); } if(tstart == "ʺ"ʺ || tcil == "ʺ"ʺ || document.getElementById("ʺmode"ʺ).value ==
73
}
"ʺNEVYBRANO"ʺ) { alert("ʺJe třeba zatat start a cíl cesty i způsob cestování!"ʺ); } else { var selectedMode = document.getElementById("ʺmode"ʺ).value; var request = { origin: tstart, destination: tcil, waypoints: zastavky, optimizeWaypoints: true, travelMode: google.maps.DirectionsTravelMode[selectedMode] }; directionsService.route(request, function(response, status) { if (status == google.maps.DirectionsStatus.OK) { directionsDisplay.setDirections(response); } }); }
Pro zobrazení trasy na mapě a zajištění možnosti úpravy tras ve formě přetahová-‐‑ ní myší jsou deklarovány ve skriptu gskript.js následující objekty: var rendererOptions = { draggable: true }; var directionsDisplay = new google.maps.DirectionsRenderer(rendererOptions); var directionsService = new google.maps.DirectionsService();
Obr. 18: Naplánovaná trasa
74
7.8 Integrace součástí systému Jsou implementovány následující části projektu: • • • • • • •
vlastní mapový server, databáze pro uchování informací o fotografiích a albech, aplikace pro práci s relevantními metadaty fotografií, nahrávání fotografií, prezentace fotografií přímo na mapě, vytváření fotografických alb, subsystém pro vyhledávání tras.
Všechny aktuální a funkční prototypy jednotlivých subsystémů, jsou integrovány prostřednictvím jednotného webového rozhraní, které zpřístupňuje a obsluhuje jejich funkcionality. Vlastní mapový server MapServer je, z několika výše uvede-‐‑ ných důvodů, nahrazen využitím rozhraní Google Maps API. Webové rozhraní je realizováno formuláři a výstupem metod objektů, vytváře-‐‑ ných prostřednictvím Google Maps API. Pro minimalizování nutnosti obnovování stránky a zvýšení komfortu uživatele, je používána technika AJAX a objektový model HTML dokumentu DOM.
7.9 Shrnutí výsledků V posledním funkčním prototypu webové aplikace systému jsou využívány ná-‐‑ sledující služby Google Maps API formou outsourcingu: • • •
dodání mapových podkladů, standardní ovládací prvky mapy, algoritmus vyhledávání tras.
Vlastními silami je v prototypu realizovány moduly, algoritmy a služby: • • • • • • •
systémová databáze, modul pro zpracování metadat fotografií, rozhraní pro nahrávání fotografií, algoritmy zajišťující reprezentaci fotografií na mapě a práci s nimi, algoritmy pro generování fotografických alb na základě polohy fotografií, modifikace algoritmu vyhledávání tras pro možnost začlenění fotografií do plánované trasy, webové rozhraní integrující jednotlivé části systému.
Aktuální pracovní verze webové aplikace je dostupná na adrese: http://dip.fotohemala.cz/cr.php
75
7.10 Plán rozvoje projektu 7.10.1 Komerční a nekomerční distribuce Zásadní vliv na směřování projektu, bude mít rozhodnutí o způsobu distribuce. V případě nekomerční distribuce poskytují licenční podmínky Google Maps API dostatek prostoru, neboť denní limit pro zobrazení stránek využívajících toto roz-‐‑ hraní není stanoven, respektive se nepředpokládá více než 500 000 zobrazení za den. Pro případ vyššího zatížení stránek, je možné zažádat o navýšení kapacity. Google Maps API neobsahuje reklamu a o případných změnách je uživatel infor-‐‑ mován s dostatečným předstihem na příslušném blogu. Podmínky pro používání Google Maps API s nekomerční licencí, jsou zejména volná dostupnost koncovým uživatelům, zákaz překrývání loga a atributů mapy, používání v souladu s příslušnou legislativou a udržování stránek s ohledem na kompatibilitu s aktuálními verzemi Google Maps API (Google Code – Google Maps/Google Earth APIs Terms of Service, 2011). Společnost Google Inc. si samozřejmě vyhrazuje právo na změnu ve všech zmiňo-‐‑ vaných oblastech, ovšem její přístup je dostatečně kontinuální, takže riziko nega-‐‑ tivních změn v parametrech poskytovaných služeb je přijatelné. V případě komerční distribuce aplikace je třeba uzavřít se společností Google Inc. smlouvu o poskytování služeb. Je také možné vzít v úvahu využití vlastního ma-‐‑ pového rozhraní a mapové podklady získávat přímo od společnosti Tele Atlas B.V. Společnost zajišťuje dodání a údržbu mapových podkladů pro Google Maps. Vzhledem k vysokým nákladům na služby poskytující mapové podklady a jejich aktualizaci, by bylo v případě komerčního směřování aplikace nezbytné najít in-‐‑ vestora.
7.10.2 Distribuční cesty Během několika posledních let je možné, v souvislosti s distribučními cestami, identifikovat tři významné trendy: • • •
rychlý nástup a obliba sociální sítě Facebook, rozvoj chytrých telefonů a tabletů, přesun prodeje krabicového software do digitálních distribucí.
Obr. 19: Počet návštěvníků sociálních sítí v ČR (Google Trends, 2011)
76
V prvním případě je podstatný nejen počet uživatelů Facebooku, který jich uvádí více než půl miliardy37, ale také možnost pro ně vytvářet aplikace. Facebook tak poskytuje nejen rozhraní pro tvorbu aplikací a vlastní trh, ale i distribuční cestu k němu. Také v České Republice Facebook nadále roste, dokonce i na úkor zave-‐‑ dených domácích sociálních sítí. Z hlediska počtu uživatelů mobilních zařízení, jsou zajímavé zejména přístroje s operačním systémem Android a iOS. Obě platformy umožňují stahování aplikací přímo do přístroje uživatele, prostřednictvím specializovaných virtuálních obcho-‐‑ dů s aplikacemi – Android Market a App Store. Společnost Apple Inc. nabízí mož-‐‑ nost digitální distribuce aplikací i pro počítače s operačním systémem Mac OS X. Zmíněné distribuční cesty jsou vhodné pro komerční i nekomerční distribuci apli-‐‑ kace a umožňují zacílení na vhodný segment trhu. Na rozdíl od klasických distri-‐‑ bučních cest také minimalizují náklady. Nevýhodou je nutnost vývoje více verzí aplikace v závislosti na příslušné platformě.
7.10.3 Technologický rozvoj aplikace Současný prototyp webové aplikace je nutné obohatit o vhodné funkce tak, aby poskytoval ucelené spektrum služeb. Nejbližší kroky vývoje jsou: • • • •
přepracování ovládacího rozhraní, realizace uživatelských účtů, rozšíření možnosti práce s alby, podpora sdílení naplánovaných tras, alb a fotografií.
V závislosti na zvolených distribučních cestách je vhodné začít s vývojem následu-‐‑ jících verzí: • • • •
aplikace pro Facebook, aplikace pro mobilní zařízení s operačním systémem Android, aplikace pro iPhone a iPad, desktopová aplikace pro Mac OS X a Windows.
Pro vývoj aplikací vytvořil Facebook knihovnu PHP Facebook API Client Library, umožňují snadnější využití prostředí sociální sítě. V aplikaci pro Facebook bude stěžejní implementace vyvinutých funkcí na existující alba uživatelů a vzájemné sdílení jejich výsledků. Při vývoji aplikace pro operační systém Android je možné využít vývojářských prostředí Eclipse, nebo neoficiální prostředí NetBeans. Jazykem vývoje aplikace pro platformu iOS je objektový Objective-‐‑C a vývojářské prostředí poskytuje XCode s bezplatným rozšířením SDK, podporující vývoj aplikací pro iPhone i je-‐‑ jich testování. V případě mobilních telefonů a tabletů je zajímavá možnost využití polohových služeb těchto přístrojů, podporované zabudovanými moduly GPS a určováním polohy vzhledem k pozemním vysílačům mobilního signálu. Celosvětový počet uživatelů k 3. září 2011 byl 574 125 820, v ČR pak 3 348 500.
37
77
Vývoj desktopových aplikací pro Mac OS X, s možností digitální distribuce pro-‐‑ střednictvím App Store, případně pro operační systémy Windows, bude vhodné směřovat k podobě zásuvných modulů do zavedených aplikací, nebo rozšíření pracovního prostředí operačních systémů – widgetů.
78
8 Diskuse a závěr 8.1 Diskuse Podstatné moduly a subsystémy projektu, respektive jejich funkční prototypy, již tvoří celek, který poskytuje na počátku definované funkcionality. Výsledky práce navozují některé otázky, které se následující text pokusí zodpovědět. Byla zvolená metodika spirálovitého přístupu k vývoji software, s modifikovaným průbě-‐‑ hem cyklu spirály a důrazem na prototypování, vhodná? Ano, metodika a zvolený postup odráží mnohé trendy v softwarovém inženýrství, přičemž vychází z ověřených přístupů k vývoji software. Možnost zpětné vazby, poskytované testovací skupinou uživatelů, urychlila hledání systémových chyb, zvýšila uživatelský komfort a dokonce zásadně ovlivnila směr vývoje celého pro-‐‑ jektu, neboť byl realizován přechod od vlastního mapového serveru k využití slu-‐‑ žeb třetí strany. Přechod k využívání Google Maps API významně zvětšil rozsah poskytovaných mapových podkladů. V průběhu vývoje se ukázalo, že původní rozdělení na jednotlivé subsystémy a moduly je příliš striktní, neboť některé funkce systému jsou poskytovány jejich kolaborací a tester tedy nemá možnost posuzovat kvalitu a funkčnost pouze jed-‐‑ noho modulu. Přináší přechod na Google Maps API skutečně výhody? Vzhledem k tomu, že pro vlastní mapový server jsou k dispozici volně dostupné mapové podklady, které pokrývají pouze území České Republiky, je využití ma-‐‑ pových služeb společnosti Google velmi výhodné. Zaručuje kvalitní a aktuální mapové podklady, pokrývající většinu povrchu země, bez jakéhokoliv zvýšení ča-‐‑ sových a ekonomických nákladů na pravidelnou údržbu dat. API také přináší možnost implementace složitých vyhledávacích, plánovacích a optimalizačních algoritmů, které by při realizaci vlastními silami zdaleka překročily rámec této práce. Podstatnou nevýhodou je však licence, podmiňující volné užití mapových služeb Google Maps API pouze pro nekomerční projekty. Proto je nutné, v případě bu-‐‑ doucích plánů na komerční distribuci produktu počítat s náklady na nákup pří-‐‑ slušné licence. Je systém něčím inovativní? I přesto, že je dnes nepřeberné množství mapových služeb, které podporují něja-‐‑ kou formu práci s fotografiemi a jejich polohovou lokalizací na základě GPS sou-‐‑ řadnic, přináší systém nové přístupy. Zejména v možnosti zapojení fotografií do plánování trasy nebo způsobu tvorby fotografických alb je systém netradiční a inovativní. Jak je možné systém vylepšit?
79
Projekt je nadále ve vývoji a prostor pro zlepšování je rozsáhlý, od přepracování uživatelského rozhraní do více interaktivní a graficky atraktivnější podoby, přes větší možnosti při práci s alby, až po realizaci systému pro ukládání, editaci a sdí-‐‑ lení vypočítaných tras, fotografických alb a fotografií nebo realizaci systému uži-‐‑ vatelských účtů. Komu může aplikace něco přinést? Aplikace je navržena například pro fotografy, kteří pracují na časosběrném projek-‐‑ tu, a vracejí se několikrát na místa fotografování, nebo pro každého, kdo si na zá-‐‑ kladě prohlédnutých fotografií naplánuje svůj výlet (v souvislosti s touto skupi-‐‑ nou uživatelů je aktuální zejména vylepšení ve smyslu sdílení fotografií, alb a je-‐‑ jich polohy ostatním). Jaká je vize budoucnosti projektu? Vzhledem k rychle se vyvíjejícím produktům silné konkurence v podobě zavede-‐‑ ných softwarových gigantů, je budoucnost projektu jako samostatné autonomní služby nepravděpodobná. Při sledování současných trendů například v oblasti so-‐‑ ciálních sítí, by mohl najít uplatnění jako jedna z jejich aplikací. V každém případě, nemá-‐‑li být vývoj zastaven, je třeba přicházet s dalšími inovacemi, například v podobě průniku do oblasti mobilních aplikací, které odliší produkt od konku-‐‑ rence, neboť diferenciace produktu, je jedním z klíčů k jeho úspěchu. Rostoucí trh chytrých telefonů, tabletů a souvisejících, nejen polohových služeb, směřuje bu-‐‑ doucnost projektu také k vývoji mobilních aplikací.
8.2 Přínos práce Od počátku je záměrem diplomové práce inovativní způsob využití metadat digi-‐‑ tálních fotografií. Na základě analýzy dostupných metod je ověřena absence plá-‐‑ novaných funkcionalit na trhu, zejména v oblastech využití polohy fotografií pro plánování tras a automatizovaného generování alb. Podařilo se realizovat ukázkový prototyp systému, umožňující automatické umís-‐‑ tění digitálních fotografií na mapě v závislosti na souřadnicích GPS. Polohové in-‐‑ formace uložené v metadatech fotografií, je možné využít pro plánování trasy jed-‐‑ noduchým zahrnutím fotografie do seznamu míst k navštívení. Fotografická alba je možné generovat automaticky, na základě volby polohy výchozí fotografie a ok-‐‑ ruhu, v jehož rámci mají být fotografie zahrnuty do alba. Zcela automaticky jsou generována defaultní alba fotografií v blízkém okolí a v okolí. Hlavním přínosem práce je tedy rozšíření funkcionality, automatizace procesů a inovativní postupy v oblasti mapových služeb, které zahrnují práci s digitálními fotografiemi a jejich polohou.
80
8.3 Závěr Diplomová práce se zabývá možnostmi inovativního využití metadat digitálních fotografií, respektive informací o geografické poloze fotografií, v oblasti geogra-‐‑ fických informačních systémů. Nejdříve byly prostudovány možnosti, které mo-‐‑ hou metadata fotografií v této oblasti nabídnout a metody práce s nimi. Práce se úzce zabývá také využitím technologií mapových serverů. Na základě získaných poznatků je provedena analýza existujících webových a desktopových aplikací a jejich služeb. Po provedení této analýzy, jsou v souladu s cílem práce, stanoveny základní parametry funkcionality aplikace tak, aby bylo dosaženo požadovaného inovativního využití, zejména zajištěním: • •
možnosti zahrnutí místa pořízení fotografií do plánování cesty, slučování fotografií do alb v závislosti na jejich geografické poloze.
Pro zajištění úspěšného vývoje systému, je v rámci práce navržena metodika vývo-‐‑ je software, v souladu s trendy softwarového inženýrství a ověřenými postupy. Postupy jsou modifikovány pro maximalizaci přínosů zpětné vazby testovací sku-‐‑ piny uživatelů a vývoje prototypů. Základem první série prototypů celého systému, je instalace a provozování vlast-‐‑ ního webového a mapového serveru, který využívá volně dostupných mapových podkladů pro území České Republiky. Přestože je verze s vlastním mapovým ser-‐‑ verem v průběhu vývoje nahrazena využitím mapových služeb třetí strany, byla její realizace cennou zkušeností nejen pro práci s mapovými podklady. Využití mapových služeb Google Maps API v dalších prototypech přineslo nesporné vý-‐‑ hody, zejména v minimalizaci ekonomických i časových nákladů na údržbu kva-‐‑ litních mapových podkladů. V jednotlivých krocích vývoje jsou navrženy a realizovány funkční prototypy da-‐‑ tabáze pro uchování informací o fotografiích, aplikace pro práci s metadaty foto-‐‑ grafií, ošetření nahrávání fotografií, prezentace fotografií přímo na mapě, vytvá-‐‑ ření fotografických alb a realizace vyhledávání tras, se zahrnutím požadovaných fotografií a optimalizací trasy. Jednotlivé části jsou v dalším kroku integrovány v jednotném webovém rozhraní. Závěrem vlastní práce je nastíněn plán rozvoje projektu i možné formy jeho distribuce. V diskusi je hodnocena míra aktuálnosti řešení a funkcí, které systém nabízí. I přes velkou konkurenci v oblasti vývoje mapového software, který využívá fotografie, jsou shledány jako přínosné a inovativní zejména princip zapojení fotografií do plánování tras a možnost seskupování fotografií do alb na základě jejich polohy. Tento přístup je v souladu s filozofií projektu a snahou přinést nové prvky do ob-‐‑ lasti využití polohových informací, zapsaných v metadatech digitálních fotografií. V závěru diskuse jsou navržena možná vylepšení a nastíněna vize budoucnosti projektu a jeho uplatnění.
81
9 Použitá literatura ABRAN, ALAIN; MOORE, JAMES. Guide to the software engineering body of knowledge. Los Alamitos, CA : IEEE Computer Society Press , 2004. 200 s. ISBN 0-‐‑7695-‐‑2330-‐‑7. Requirements analysis. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 26. 12. 2008, last modified on 15. 12. 2010 [cit. 2011-‐‑11-‐‑05]. Dostupné z WWW: . Common Gateway Interface. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2. 12. 2006, last modified on 28. 6. 2010 [cit. 2010-‐‑09-‐‑012]. Dostupné z WWW: . ČADA, VÁCLAV. Geomatika [online]. 2010 [cit. 2011-‐‑12-‐‑20]. Tvar zemského tělesa a referenční plochy. Dostupné z WWW: . Digital Negative Specification. San Jose : ADOBE SYSTEMS INCORPORATED, 2009. 89 s. Dostupné z WWW: . Exchangeable image file format. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 25. 7. 2005, last modified on 11. 6. 2010 [cit. 2010-‐‑01-‐‑04]. Dostupné z WWW: . GeoWiki [online]. 2008 [cit. 2010-‐‑09-‐‑25]. Dostupné z WWW: . GIS. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 8. 9. 2006, last modified on 17. 10. 2006 [cit. 2010-‐‑05-‐‑09]. Dostupné z WWW: . Google Code [online]. 2011 [cit. 2011-‐‑12-‐‑11]. Google Maps/Google Earth APIs Terms of Service. Dostupné z WWW: . Google Code [online]. 2010. Google Maps JavaScript API V3. Dostupné z WWW: . Google Trends [online]. 2008 [cit. 2011-‐‑12-‐‑12]. Dostupné z WWW: . HARVEY, PHIL. ExifTool by Phil Harvey [online]. 2009 [cit. 2011-‐‑09-‐‑30]. Dostupné z WWW: . HYNEK, JOSEF. Genetické algoritmy a genetické programování. Praha : Garda Publishing a.s., 2008. 182 s. JSON [online]. 2010 [cit. 2011-‐‑12-‐‑15]. Dostupné z WWW: . KOSEK, JIŘÍ. Kosek [online]. 2006 [cit. 2010-‐‑02-‐‑09]. Využití webových služeb a protokolu SOAP při komunikaci. Dostupné z WWW: .
82
KREJČÍ, RICHARD Encyklopedie publikačních formátů: IPTC, Exif a XMP. In Polygrafie [online]. Praha : Grafika Publishing, 2004 [cit. 2011-‐‑09-‐‑25]. Dostupné z WWW: . LEWIS, ANDRÉ; PURVIS, MICHAEL; SAMBELLS, JEFFREY. Beginning Google maps applications with Rails and Ajax : from novice to professional. New York : Apress, 2007. 365 s. ISBN 9781590597873. MapServer [online]. 2010. MapServer 6.0.1 Documentation. Dostupné z WWW: . MERUNKA, VOJTĚCH; POLÁK, JIŘÍ; CARDA, ANTONÍN. Umění systémového návrhu. Praha : Ekopress, 2003. 196 s. ISBN 80-‐‑247-‐‑0. PHP [online]. 2010 [cit. 2010-‐‑12-‐‑01]. PHP Manual. Dostupné z WWW: . PROCHÁZKA, DAVID. Modelování a vizualizace vymezeného geografického prostoru s možností interaktivního zásahu do modelovaného procesu. Brno, 2008. 143 s. Dizertační práce. Mendelova zemědělská a lesnická univerzita v Brně, Provozně ekonomická fakulta. ŘEPA, VÁCLAV. Analýza a návrh informačních systémů. Praha : Ekopress, 1999. 403 s. ISBN 80-‐‑86119-‐‑13-‐‑0. Selecting a development approach. In Office of Information Services [online]. Baton Rouge : Centers for Medicare & Medicaid Services, 2008 [cit. 2011-‐‑11-‐‑04]. Dostupné z WWW: . Simple Object Access Protocol. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 10. 11. 2006, last modified on 9. 11. 2010 [cit. 2010-‐‑02-‐‑09]. Dostupné z WWW: . SKOUPIL, MARTIN. Vizualizace stavu životního prostředí s využitím webových mapových služeb. Brno, 2008. 52 s. Diplomová práce. Masarykova univerzita. TRACHTENBERG, ADAM. Why PHP 5 Rocks. In Upgrading to PHP 5 [online]. Online : O'ʹReilly Media, Inc., 2004 [cit. 2010-‐‑12-‐‑01]. Dostupné z WWW: . Web Map Service. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 31. 8. 2007, last modified on 17. 8. 2010 [cit. 2010-‐‑03-‐‑15]. Dostupné z WWW: . WEST, DOUGLAS. Introduction to graph theory. New Delhi : PHI Learning, 2009. 247 s. ISBN 0-‐‑201-‐‑41033-‐‑8. WIEGERS, KARL. Software Requirements. Redmond : Microsoft Press, 2003. 256 s. ISBN 0-‐‑7356-‐‑1879-‐‑8. Xiong, Hui. Encyclopedia of GIS. New York : Springer, 2008. 1377 s. ISBN 9780387359731.
83
10 Přílohy 10.1 Technologické možnosti přiřazení GPS informací 10.1.1 Zápis fotoaparátem Na trhu se již objevily fotoaparáty se zabudovaným GPS modulem. Funkce se ob-‐‑ jevuje dokonce u kompaktních přístrojů určených pro amatérské použití. Jedním z prvních průkopníků byl fotoaparát Ricoh 500E (rok 2007).
Obr. A: Fotoaparát vybavený modulem GPS
10.1.2 Zápis pomocí dodatečného zařízení Pro fotoaparáty vybavené paticí pro blesk je dostupné řešení přídavného zařízení, které do exifu fotografií přidá GPS tagy longitude, latitude, jméno ulice, zemi po-‐‑ řízení, a zip kód.
Obr. B: GPS Tagging Device Jobo
84
10.2 Obrazový doplněk k analýze dostupných metod
Obr. C: Náběh do náhledu panorámatu v aplikaci Google Earth
Obr. D: Pohled v režim 360-‐‑ti stupňového panorámatu v aplikaci Google Earth
Obr. E: Náhled fotografie na mapě v aplikaci Zoner Photo Studio 11
85
Obr. F: Přiřazení lokality dané fotografii pomocí jednoduchého vyhledání na mapě
Obr. G: Přidání nové lokality do fotografického alba iPhoto
