Vyhledávání mapových služeb v prostředí Internetu

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Vyhledávání mapových služeb v prostředí Internetu Bakalářská práce Vedoucí práce: Ing. David Procházka, Ph.D. Pavel Čermák Brno 2010

2 Chtěl bych poděkovat vedoucímu mé práce, panu Ing. Davidu Procházkovi, Ph.D., za velmi cenné konstruktivní rady a výraznou podporu po celou dobu psaní bakalářské práce. Dále bych chtěl poděkovat T. Koenigovi, vývojáři knihovny Qt, za jeho teoretické rady a technickou podporu. V neposlední řadě bych chtěl poděkovat mé rodině za podporu a zázemí, které mi poskytovala v průběhu celého studia.

3 Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně a v seznamu literatury uvedl veškeré informační zdroje, které jsem použil pro její tvorbu. V Brně, dne 13. května

4 4 Abstract ČERMÁK, P. Searching of the map services through the Internet. Bachelor thesis. Brno, 2010 The thesis deals with design and experimental implementation of a tool which searches for the map services through the Internet. The available geodata searching methods, their comparison and technical resources appropriate for the final tool implementation are introduced to the reader. The thesis also deals with the way how to transform the geodata into a suitable file format that is supported by available GIS freeware tools. Keywords web map service, search service, geodata, indexation, transformation, kml Abstrakt ČERMÁK, P. Vyhledávání mapových služeb v prostředí Internetu. Bakalářská práce. Brno, 2010 Práce se zabývá návrhem a experimentální implementací nástroje pro vyhledávání mapových služeb v prostředí Internetu. Čtenář je seznámen s dostupnými způsoby vyhledávání geodat, jejich vzájemným srovnáním a technickými prostředky, které jsou vhodné pro jejich implementaci do výsledného nástroje. Tato práce se taktéž zabývá způsobem transformace nalezených geodat do vhodného souborového formátu, který by byl podporován volně dostupnými GIS nástroji. Klíčová slova webová mapová služba, vyhledávací služba, geodata, indexace, transformace, kml

5 OBSAH 5 Obsah 1 Úvod a cíl práce Úvod Cíl práce Principy vyhledávání mapových služeb Webové mapové služby OpenGIS c Web Map Service (WMS) Geography Markup Language Keyhole Markup Language Katalogové mapové služby OpenGIS c Catalogue Service INSPIRE Geoportal Rozhraní vyhledávacích služeb (API) Google Yahoo! Bing Shrnutí Technické prostředky Qt framework Nástroje Moduly XML Definice struktury XML dokumentů Zpracování XML Moduly Qt pro zpracování XML Moebius Mapserver Virtualizační část Indexovací část Metodika 27 5 Vlastní řešení Výběr vhodných komponent Výběr vyhledávací služby Výběr souborového formátu pro transformaci Výběr uživatelského rozhraní Implementace Vyhledávání geodat Transformace geodat Webové uživatelské rozhraní

6 OBSAH 6 6 Závěr 39 7 Literatura 40 Přílohy 43 A Příklad GetCapabilities souboru 44 B UML diagram 47 C Zobrazení transformovaných geodat 48 D Vzhled webové aplikace 49

7 1 ÚVOD A CÍL PRÁCE 7 1 Úvod a cíl práce 1.1 Úvod V poslední době zažívají geografické informační systémy velmi rychlý rozvoj, který je zapříčiněn nejen pokrokem v oblasti informačních technologií, ale také rostoucí popularitou geografického zpracování dat. Tyto systémy byly zpočátku využívány zejména státními orgány a velkými organizacemi pro podporu rozhodování (např. podpora při řízení povolování staveb, odhad šíření živelných katastrof apod.). Jejich využití se však v současnosti masově rozšiřuje z uzavřených prostor velkých organizací mezi širokou veřejnost, která objevuje funkce usnadňující každodenní činnosti. Mezi služby, které jsou v řadách veřejnosti nejvíce využívány, lze bezesporu zařadit webové mapové aplikace a GPS. Širší využití geografických informačních systémů klade velký důraz na schopnost bezproblémové výměny dat mezi aplikacemi různých dodavatelů. Touto problematikou se zabývá světová organizace Open Geospatial Consortium, Inc., jenž vytváří a udržuje standardy pro výměnu geodat, které jsou podporovány převážnou většinou běžně používaných produktů v této oblasti (Procházka, 2008). Přestože existuje řada projektů zabývajících se poskytováním geodat v prostředí Internetu, neexistuje nástroj schopný takto roztroušená geodata sjednotit do souhrnné databáze, nad kterou by bylo možné provádět výsledné vyhledávání. Vytvořením takové služby, pod názvem Moebius Mapserver 2 1, se zabývali v rámci svých bakalářským prací Bc. Radek Brian Polovinčák a Bc. Karel Šimoník. Ta umožňuje indexovat a virtualizovat webové mapové služby tak, aby bylo možné nad takto sjednocenými geodaty provádět vyhledávání. Koncepce vychází z dřívější implementace v rámci disertační práce Ing. Davida Procházky, Ph.D. Výsledná služba má však jeden funkční nedostatek sběr geodat musí být prováděn ručně. 1.2 Cíl práce Cílem této práce je vytvoření nástroje, který by byl schopen pracovat s indexovací částí služby Moebius Mapserver 2 (MM2). Tento nástroj bude zajišťovat automatizované vyhledávání webových mapových služeb v prostředí Internetu, ověřování konzistence dat na nich uložených a jejich předávání již vytvořené indexovací části MM2. Souvisejícím úkolem je i vytvoření služby, která by byla schopna transformovat geodata z mapových serverů do vhodného souborového formátu, jenž by umožnil laické veřejnosti prezentaci geodat bez nutnosti vlastnění profesionálních nástrojů. Jednou z takových veřejně dostupných aplikací je například Google Earth 2. K tomu, aby bylo těchto cílů dosaženo, bude zapotřebí prostudovat tematiku webových mapových služeb, možnosti dostupných internetových vyhledávacích slu

8 1.2 Cíl práce 8 žeb, existující souborové formáty pro sdílení geodat a v neposlední řadě také nástroje programovacího jazyka. Na základě zjištěných poznatků bude navržena metodika řešení daného problému, jenž bude ověřena experimentální implementací.

9 2 PRINCIPY VYHLEDÁVÁNÍ MAPOVÝCH SLUŽEB 9 2 Principy vyhledávání mapových služeb K tomu, aby bylo možné implementovat automatické indexování mapových zdrojů je nezbytné se zamyslet nad způsobem, jakým je možné tyto zdroje nalézt. Tato kapitola nám poskytne základní přehled o standardech a principech webových mapových služeb a způsobech jejich nalezení. Existují prakticky tři způsoby, kterými je možné takové vyhledávání provést, a to využitím webových vyhledávacích rozhraní (API 3 ), katalogových služeb nebo vytvořením vlastního vyhledávacího agenta. Tato práce se bude věnovat pouze prvním dvěma jmenovaným způsobům. Lze totiž předpokládat, že agent, kterého by bylo možné v rámci práce vytvořit, by zdaleka nedosahoval kvalit již existujících agentů jak z hlediska funkcionality, tak výpočetní síly pro jeho nasazení. 2.1 Webové mapové služby Webové mapové služby umožňují sdílení geodat v distribuovaném prostředí Internetu. Pro kladení prostorových dotazů vůči těmto službám jsou používány metody GET a POST, které poskytuje protokol HTTP. Přesné popisy lze nalézt v příslušných standardech (Procházka, 2008). Mezi základní webové mapové služby se řadí Web Map Service (WMS), Web Feature Service (WFS), Web Processing Service (WPS) a Web Coverage Service (WCS). V následujícím textu se zaměříme pouze na detailní popis služby WMS, jenž je klíčová pro dosažení cíle práce. Ve spojení s prezentací geografických dat je nutné zmínit alespoň dva významné souborové formáty Geography Markup Language (GML) a Keyhole Markup Language (KML). GML, využívaný zejména službou WFS, je formátem využívaným pro vektorová data. KML je zjednodušenou verzí GML, který je velmi často těžko implementovatelný z důvodu jeho přílišné komplexnosti. I když je KML z pohledu funkčnosti omezenější než GML, díky jeho jednoduché implementovatelnosti představuje silný nástroj pro prezentaci geodat široké veřejnosti, která nedisponuje profesionálními GIS nástroji (Procházka, 2008) OpenGIS c Web Map Service (WMS) OpenGIS c Web Map Service (WMS) poskytuje jednoduché HTTP rozhraní pro vyžádání geografických mapových snímků z jedné nebo více distribuovaných geoprostorových databází. WMS požadavek definuje geografické vrstvy a oblasti zájmu, které mají být zpracovány. Odpověď na tuto žádost je jeden nebo více geografických mapových snímků (ve formátech JPEG, PNG, atd.), které mohou být následně zobrazeny v prohlížeči. Rozhraní také podporuje možnost nastavení transparentnosti navracených snímků, což ve výsledku umožní kombinovatelnost vrstev z více ser- 3 Application Programming Interface rozhraní pro programování aplikací

10 2.1 Webové mapové služby 10 verů (Open Geospatial Consortium, Inc., b). Specifikace WMS definuje tři typy operací: GetMap na základě parametrů dotazu (např. určení vrstev, prostorového referenčního systému, zeměpisné oblasti apod.) navrací mapový snímek obsahující geodata. GetCapabilities vrací informace o obsahu mapového serveru (seznam vrstev, informace o formátu map, podporovaných kartografických projekcích, způsob ošetření výjimek) a platných parametrech jednotlivých dotazů. GetFeatureInfo vrací informace o prvcích nacházejících se na mapové vrstvě. Její implementace je nepovinná a je podporována pouze u těch vrstev, které mají tuto operaci povolenu (k tomu slouží atribut queryable, který musí mít nastavenu hodnotu na 1 ). Popis dotazu GetCapabilities Odpovědí na GetCapabilities (GC) dotaz bývá XML 4 dokument obsahující metadata služby WMS. Tento dokument by měl splňovat strukturu danou DTD 5 schématem, který určuje povinný a volitelný obsah. GC dotaz, který musí být povinně implementovaný na všech WMS serverech, poskytuje následující informace (ESRI, 2010): všechna rozhraní, která jsou podporována WMS službou, poskytované formáty obrázků (např. JPEG, PNG, GIF), seznam dostupných prostorový referenčních systémů pro poskytovaná mapová data, seznam všech formátů výjimek, které mohou být navráceny, seznam dostupných mapových vrstev na serveru, seznam vrstev podporujících nepovinnou GetFeatureInfo operaci. Formát GC dotazu je dán specifikací OGC 6, která však není zcela striktní. To má za následek jisté odlišnosti při implementaci specifikace v závislosti na konkrétním produktu (Procházka, 2008). Specifikace OGC definuje 5 základních parametrů z nichž pouze některé jsou povinné a ostatní jsou volitelné. Tyto parametry shrnuje Tab. 1. Následující odkaz představuje položení GC dotazu na WMS server a vyžádání si tak informací o službě běžící na dané URL 7. GetCapabilities 4 Extensible Markup Language 5 Document Type Definition jazyk popisující strukturu dokumentu 6 Open Geospatial Consortium, Inc. R 7 Uniform Resource Locator řetězec znaků sloužící k přesné specifikaci umístění zdrojů informací

11 2.1 Webové mapové služby 11 Tab. 1: Parametry GetCapabilities dotazu (Open Geospatial Consortium, Inc., b) Požadovaný parametr Povinné/ Volitelné Popis VERSION=verze volitelné požadovaná verze SERVICE=WMS povinné typ služby REQUEST=Getcapabilities povinné jméno požadavku FORMAT=typ MIME volitelné výstupní formát metadat UPDATESEQUENCE=řetězec volitelné číslo sekvence nebo řetězce pro řízení cache Výsledkem dotazu je XML soubor, jehož struktura se dá rozdělit na tři části. První obsahuje obecné informace o mapové službě jako jsou například název, abstrakt, klíčová slova a kontaktní údaje. Druhá část popisuje poskytované operace, tj. GetCapabilities a GetMap. Definuje například podporované výstupní formáty, způsob ošetření výjimek aj. Poslední část tvoří seznam poskytovaných vrstev včetně jejich detailního popisu název, titulek, klíčová slova aj. (Polovinčák, 2009). Ukázka výstupního GC souboru je uvedena v příloze A Geography Markup Language OpenGIS c Geography Markup Language (GML), založen na XML gramatice, slouží jako modelovací jazyk pro geografické systémy stejně tak jako otevřený formát pro výměnu geografických dat na Internetu. Jako u většiny jazyků založených na XML gramatice existuje schéma, které popisuje dokument a instance dokumentu, který obsahuje skutečné údaje. Dokument GML, definován pomocí GML schématu, umožňuje uživatelům a vývojářům obecně popsat geografická data (geografické funkce, topologii, geometrii, měrné jednotky, hodnoty objektů aj.), která obsahují body, linie a polygony (Open Geospatial Consortium, Inc., c). GML je příliš komplexní a obecně platí, že aplikace nepotřebují využívat celý rozsah jazyka, ale vystačí si pouze s podmnožinou konstrukcí, které korespondují s jejími specifickými požadavky. Z toho důvodu byly navrženy profily, které tyto podmnožiny jazyka definují (Procházka, 2008): Point Profile pro aplikace, ve kterých se zaznamenávají pouze body. GML Simple Features profile jazyk je omezen pouze na popis základních vlastností geodat, je využíván např. u Web Feature Service. A GML profile for GMJP2. A GML profile for RSS Keyhole Markup Language KML, vycházející z jazyka XML, je souborovým formátem pro modelování a ukládání geografických funkcí, jako jsou body, čáry, obrázky, mnohoúhelníky a modely,

12 2.2 Katalogové mapové služby 12 které mohou být zobrazeny v aplikaci Google Earth, ve službě Google Maps, Google Mobile a v mnoha dalších aplikacích. KML jsou zpracovávány podobným způsobem, jakým webové prohlížeče zpracovávají soubory HTML 8 a XML (Google, 2010b). Tento jazyk byl původně vyvíjen společností Keyhole, Inc. jako rozhraní pro aplikaci Earth Viewer (nynější Google Earth) a později byl zakoupen společností Google. Aktuální verze 2.2 se stala začátkem roku 2008 standardem OGC. Struktura KML je, stejně jako XML, založena na značkách s názvy a atributy, které definují konkrétní zobrazení. Všechny značky jsou citlivé na velikost znaků a musí být uvedeny přesně tak, jak jsou uvedeny v KML dokumentaci. Ukázka jednoduchého KML souboru popisující bod umístěný na konkrétních souřadnicích: <?xml version="1.0" encoding="utf-8"?> <kml xmlns=" <Placemark> <Name>Jednoduchý bod</name> <Description>Bod umístěný na konkrétních souřadnicích</description> <Point> <Coordinates>-120,35,0</Coordinates> </Point> </Placemark> </kml> Výše uvedený příklad se dá rozdělit na tři části XML hlavička, jmenný prostor KML a Placemark objekt. Poslední zmiňovaný pak obsahuje definici jména (Name), popisu (Description), typu prvku (Point) a jeho souřadnic (Coordinates). Tento KML soubor pak umožní v Google Earth zobrazení bodu a jeho popisu na daných souřadnicích (Google, 2010c). Distribuce KML je často prováděna pomocí KMZ souborů, které jsou komprimovanou podobou KML. KMZ se skládá z hlavního souboru KML a několika podpůrných souborů. Během dekomprese KMZ jsou hlavní KML soubor společně s podpůrnými soubory zpět uloženy v původních názvech, formátech a adresářové struktuře. V závislosti na obsahu KML souboru bývá obvyklý poměr komprimace 10:1 (Google, 2010d). KML se stal v poslední době velmi rozšířeným formátem pro přenos geodat využívaným laickou veřejností. Příčinou tohoto masivního rozšíření je pravděpodobně jednoduchost práce s KML, velmi kvalitní a mezi veřejností rozšířený prohlížeč Google Earth, využití ve službě Google Maps či volně dostupný 3D modelovací nástroj Google SketchUp (Procházka, 2008). 2.2 Katalogové mapové služby Značný rozvoj v oblasti geografického zpracování dat vede k tomu, že denně vzniká množství zdrojů geografických informací. Tyto zdroje jsou často velmi špatně zdoku- 8 HyperText Markup Language hypertextový značkovací jazyk

13 2.2 Katalogové mapové služby 13 mentovány a informace o jejich existenci není mezi uživateli příliš rozšířená. Vzniká tudíž potřeba k vytvoření síťového řešení s cílem usnadnit vyhledávání, hodnocení a přístup ke geografickým datům. Spatial Data Infrastructures (SDI) poskytuje framework pro optimalizaci vytváření, údržby a distribuci geografických informací na různých organizačních úrovních (např. regionální, národní nebo světové). Hlavním cílem je usnadnit a umožnit efektivní využívání geografických informací více subjekty zúčastněnými na trhu geografických informací. Jednou z klíčových komponent SDI je geografický katalog umožňující uživatelům nebo aplikačnímu software najít již existující informace za použití distribuovaného výpočetního prostředí. Geografické katalogy jsou řešením pro publikování a vyhledávání popisů (metadat) o geoprostorových datech, službách a relevantních zdrojích. Pro využití indexovaných a vyhledávatelných metadat je stanoven slovník, vůči kterému jsou pokládány dotazy. K tomu, aby tyto katalogy poskytovaly sdílení geografických informací maximálnímu počtu uživatelů je nezbytné vytvořit distribuované sítě katalogů využívajících standardizovaného mechanismu pro dotazování. Jedním ze standardů je i OpenGIS Catalogue Service Implementation Specification, který je udržován organizací OGC (Nogueras-Iso, J., et al., 2005) OpenGIS c Catalogue Service OpenGIS Catalogue Services Specification (OCS) definuje obecný model katalogového rozhraní poskytující řadu služeb, které podporují vyhledávání, přístup, údržbu a organizaci katalogů geoprostorových informací a souvisejících zdrojů. Současná verze OCS podporuje tři protokoly CORBA, Z39.50 a HTTP (Open Geospatial Consortium, Inc., a). V závislosti na těchto protokolech může dojít k různým omezením při implementaci obecného modelu, který je zobrazen na Obr. 1. Obr. 1: Referenční architektura pro vývoj katalogového rozhraní (Open Geospatial Consortium, Inc., a) Klientské dotazy jsou zasílány pomocí metod POST a GET na rozhraní katalogové služby, která k jejich zodpovězení využívá tří zdrojů místní skladiště metadat (Metadata Repository), služby zdrojů nebo jiných katalogů služeb. Podle Procházky

14 2.2 Katalogové mapové služby 14 (2008) je nejvíce využíváno protokolu HTTP Catalogue Service for Web (CSW), který podporuje následující dotazy: GetCapabilities vrací popis služby. DescribeRecord vrací popis metadatového záznamu. GetRecords vrací metadatový záznam na základě dotazu. GetRecordById vrací metadatový záznam na základě identifikátoru záznamu. GetDomain (nepovinné) popisuje doménu metadat. Transaction (nepovinné) ukládání, resp. aktualizace metadatových záznamů na serveru. Harvest (nepovinné) automatické stahování metadat z jiného serveru. Z českých katalogových služeb lze jmenovat například geoportál ČÚZK 9 a ze zahraničních například projekt GeoNetwork OpenSource 10. Seznam registrovaných produktů podporujících OCS je přístupný na: INSPIRE Geoportal INSPIRE INfrastructure for SPatial InfoRmation in Europe je iniciativou Evropské komise. Stejnojmenná směrnice Evropské komise a Rady si klade za cíl vytvořit evropský legislativní rámec potřebný k vybudování evropské infrastruktury prostorových informací. Stanovuje obecná pravidla pro založení evropské infrastruktury prostorových dat zejména k podpoře environmentálních politik a politik, které životní prostředí ovlivňují. Hlavním cílem INSPIRE je poskytnout větší množství kvalitních a standardizovaných prostorových informací pro vytváření a uplatňování politik Společenství na všech úrovních členských států. Základní principy INSPIRE (CENIA, 2010): Data sbírána a vytvářena pouze jednou a spravována na takové úrovni, kde se tomu tak děje nejefektivněji. Možnost kombinovat prostorová data z různých zdrojů a sdílet je mezi mnoha uživateli a aplikacemi. Prostorová data vytvářena na jedné úrovni státní správy a sdílena jejími dalšími úrovněmi. Prostorová data dostupná za podmínek, které nebudou omezovat jejich rozsáhlé využití. Snadnější vyhledávání dostupných prostorových dat, vyhodnocení vhodnosti jejich využití pro daný účel a zpřístupnění informace, za jakých podmínek je možné tato data využít

15 2.2 Katalogové mapové služby 15 Geoportál INSPIRE 11, který je stále ve vývojové fází, má za úkol nabídnout prostředky pro vyhledávání prostorových dat a jejich služeb v rámci členských států EU. INSPIRE usiluje o zpřístupnění relevantních, sjednocených a kvalitních geografických informací na podporu vytváření, uplatňování, sledování a vyhodnocování zásad a činností, které mají přímý nebo nepřímý vliv na životní prostředí (např. územní plánování, přírodní katastrofy apod.). Geoportál umožní propojení s mnoha institucionálními servery a portály a poskytne on-line přístup k souborům prostorových dat a služeb poskytovaných veřejnými a soukromými organizacemi. Na Obr. 2 je znázorněna plánovaná architektura geoportálu INSPIRE. Většina poskytovaných služeb (WMS, WFS, WCS, WCatS) již byla vysvětlena v předchozím textu. Gazetter Service nabídne funkce umožňující geokódování geografického jména, prostorového kódu aj. na adekvátní prostorovou a geometrickou reprezentaci. Thesaurus Service stanoví slovníky pro dotazování a analýzu nad geografickými informacemi (Bernard, L., et al., 2005). Obr. 2: Plánovaná architektura geoportálu INSPIRE (Bernard, L., et al., 2005) Uživatel geoportálu bude mít možnost nalézt požadovanou vrstvu dat pomocí vyhledávacích služeb, které mu zobrazí metadata k datům odpovídající jeho zadaným požadavkům. Na základě výsledků si zvolí konkrétní vrstvu, kterou si může zobrazit pomocí prohlížecí služby nebo stáhnout na lokální disk (se souhlasem s licenční smlouvou). Vyhledávací a zobrazovací služby budou poskytovány uživateli zdarma s výjimkou průběžně aktualizovaných dat velkého objemu (např. meteorologická data). Zpoplatnění ostatních služeb a samotných dat bude záležet na konkrétním poskytovateli (CENIA, 2010). V současné době je spuštěn prototyp INSPIRE geoportálu, který přistupuje pouze k omezenému počtu vyhledávacích a zobrazovacích služeb, což má za následek menší počet dostupných metadat. Prototyp podporuje následující funkce: 11

16 2.3 Rozhraní vyhledávacích služeb (API) 16 Discovery vrací záznamy metadat, které odpovídají kritériím uživatelských vyhledávání. Viewer umožňuje uživatelům procházet mapová data, včetně jejich kombinování z více zdrojů. Metadata Editor a Metadata Validator umožňují vytváření a validaci metadat v podobě XML souborů. Jak již bylo zmíněno výše, geoportál prozatím běží v testovacím provozu, který má velmi omezené možnosti. Největší slabinou je v tuto chvíli velmi malé množství geografických dat, ke kterým lze přistupovat. Jakmile bude tato služba spuštěna do ostrého provozu, což vyžaduje integraci dat všech členských států, stane se velmi cenným centralizovaným zdrojem geoinformací. Na jednom místě tak budou sjednoceny relevantní geodata zvyšující efektivitu jejich vyhledávání. Nevýhodou však bude jeho datová omezenost v důsledku zapojení pouze členských států EU. Další nevýhodou je prozatimní absence rozhraní, které by umožňovalo aplikacím třetích stran pokládání a následné zobrazení výsledků dotazů pomocí protokolu HTTP. V tuto chvíli jsou vytvořeny pouze návrhy rozhraní splňujícího OCS, avšak jeho implementace ještě nebyla dokončena. V této fázi existuje pouze webový klient umožňující komunikaci s geoportálem. Ve srovnání s vyhledávacími službami různých poskytovatelů, jako je například Google nebo Yahoo!, nám v budoucnu nabídne geoportál INSPIRE velmi vysokou efektivitu vyhledávání a to z toho důvodu, že odpadne problém irelevantních výsledků (v podobě negeografických dat PDF, HTML apod.) a jejich následná validace. V rámci EU bude takto vytvořená služba téměř ideálním prostředkem pro vyhledávání geodat. Problémem při spravování tak obsáhlého projektu by však mohla být aktualizace geodat, jenž budou poskytována uživatelům. Po celé EU vznikají denně geodata, která bude nutno na portál zaindexovat, což bude vyžadovat úsilí buď ze strany provozovatele portálu INSPIRE nebo poskytovatele geodat. V opačném případě by portál ztratil jeden ze svých hlavních smyslů poskytovat úplná a aktuální geodata. 2.3 Rozhraní vyhledávacích služeb (API) Vyhledávací služby jsou prostředkem pro lokalizaci informací na Internetu. Vyhledávací službu můžeme definovat jako systém, který na základě klíčového slova naformulovaného uživatelem hledá v databázi nebo v indexu a výsledek hledání poté oznámí uživateli. Důležitou roli při vyhledávání hraje klíčové slovo keyword, kterým se uživatel snaží vyjádřit svou informační potřebu. Jako klíčové slovo lze použít jednotlivé slovo, část slova nebo frázi. Z jednoho nebo více vyhledávacích výrazů je pak složen dotaz query, který reprezentuje úplný vyhledávací požadavek. V dotazech se často uplatňují relační operátory, které umožňují jejich detailnější specifikaci (Masarykova univerzita, 2007). Vyhledávací služby bývají většinou tvořeny třemi částmi:

17 2.3 Rozhraní vyhledávacích služeb (API) 17 Robot podle určitého algoritmu prochází webové servery včetně dokumentů na nich se vyskytujících a analyzuje jejich obsah. Výsledky své práce předává indexovací části. Indexovací část indexuje výsledky práce robota do vlastní databáze. Tato databáze uchovává seznam klíčových slov, kde ke každému z nich je přiřazen seznam webových serverů, které toto klíčové slovo obsahují. Vyhledávací mechanismus je uživatelské rozhraní umožňující zadávání dotazů, jejich následné vyhodnocení oproti databázi a vracení odpovědí. Na poli českých vyhledávačů dominují Seznam, Atlas, Centrum a Jyxo. Ve světě pak dominují zejména Google, Yahoo!, Ask, AOL a nově vzniklý Bing od společnosti Microsoft. Jelikož úspěšní tuzemští poskytovatelé vyhledávání využívají služeb světových vyhledávačů, zaměříme se v následujícím textu pouze na tyto největší světové poskytovatele. Vývoj podílu vyhledávačů na trhu USA je znázorněn na Obr. 3. Obr. 3: Vývoj podílu vyhledávačů na trhu USA (Bednář, 2009) Google Zakladatelé společnosti Google, studenti Stanfordské univerzity Larry Page a Sergey Brin, vyvinuli nový algoritmus k vyhledávání informací na Internetu. Od té doby se mohutně rozšířil mezi uživateli a stal se tak nejpoužívanějším vyhledávačem na světě. Jen v USA činí jeho podíl na trhu téměř 70 %. Takového úspěchu dosáhl zejména díky jednoduchému vzhledu, rychlosti vyhledávání, možnostem nastavení a vysoce relevantním výsledkům. Přesné algoritmy vyhledávání, podle kterých jsou řazeny výsledky dotazů jsou obchodním tajemstvím společnosti. Je však známo, že je řazení ovlivněno spoustou faktorů, ke kterým se přihlíží například PageRank (počet, kvalita a relevance odkazů, které na danou stránku vedou), pozice klíčového slova v dokumentu, stáří dokumentu nebo webu a mnoho dalších. Výsledná pozice stránky ve výsledcích je pak

18 2.3 Rozhraní vyhledávacích služeb (API) 18 dána kombinací těchto faktorů, které by měly zajistit přirozené objektivní výsledky (Fishkin, 2007). Google poskytuje svým uživatelům dvě rozhraní vyhledávače klasické webové a Google AJAX Search API 12. Obě rozhraní podporují vyhledávání mezi mnoha typy dat weby, obrázky, videa, blogy, novinky, knihy nebo patenty. Google AJAX Search API je založeno na knihovně Javascript, která umožňuje přímo na vašich webových stránkách nebo v jiných webových aplikacích využívat rozhraní vyhledávače. Pro prostředí nepodporující Javascript je nabízeno REST 13 rozhraní, které komunikuje pomocí metody GET. Jednotlivé dotazy se pokládají na URL, jejíž tvar se odvíjí od typu vyhledávaných dat. Každý dotaz se skládá z povinných a nepovinných parametrů, které se dále liší podle typu vyhledávaných dat (Google, 2010a). Obecný formát dotazu lze popsat následujícím způsobem: v=1.0&q={dotaz}[&parametr=hodnota&] Položka typ_dat nese informaci o požadovaném typu dat, mezi kterými má být vyhledání prováděno (tj. weby, obrázky aj.). Parametr v obsahuje verzi protokolu služby, v současnosti s jedinou přípustnou hodnotou 1.0. Klíčový parametr q nese hledaný řetězec znaků. Za těmito povinnými parametry již následují pouze parametry nepovinné. Výsledky jsou vraceny v lehce zpracovatelném formátu JSON 14 : {"zakaznik": {"jmeno": "Jan Novak", "vek": 53}, "prihlasen": true, "opravneni": [3,5,7]} Následující příklad demonstruje položení reálného dotazu vyhledávajícího mezi weby: Takto položený dotaz obsahuje již zmíněné dva nezbytně nutné parametry verzi a hledaný řetězec. Výsledkem dotazu je seznam všech webů obsahujících řetězec wms Yahoo! V roce 1994 založili studenti Stanfordské univerzity David Filo a Jerry Yang společnost Yahoo! Inc., která sídlí v Sunnyvale v Kalifornii a má pobočky ve více než 25 zemích. Yahoo! Inc. se postupem času vyvinulo v přední světovou značku, která změnila způsob, jakým spolu lidé navzájem komunikují. Nabídku uživatelských služeb lze v současné době rozdělit do pěti kategorií: integrované spotřebitelské zkušenosti, komunikační aplikace, vyhledávání, produkty medií a řešení a mobilní služby (Yahoo! Inc., 2010a) Representational State Transfer architektura umožňující přistup k datům pomocí standardních metod HTTP 14 JavaScript Object Notation formát pro přenos dat, která mohou být organizována v polích nebo agregována v objektech

19 2.3 Rozhraní vyhledávacích služeb (API) 19 I Yahoo! poskytuje svým uživatelů dva typy vyhledávacích rozhraní klasické webové a rozhraní BOSS (Build your Own Search Service) 15. BOSS je otevřené API umožňující vývojářům třetích stran využívat Yahoo! vyhledávač ve svých vlastních aplikacích. Vývojáři tak získají přístup k Yahoo! algoritmům pro procházení, indexování, hodnocení a relevanci dat. BOSS v současné době podporuje vyhledávání mezi weby, novinkami a obrázky. Zasílání dotazů je prováděno pomocí GET metody, jejichž tvar se odvíjí od typu vyhledávaných dat (Yahoo! Inc., 2010b). Obecný formát dotazu má následující tvar: appid=xyz[&parametr=hodnota&] Stejně jako u Google AJAX Search API, i zde se vyskytují položky typ_dat a dotaz, které mají stejný význam. Navíc se zde objevuje povinný parametr appid, který obsahuje unikátní klíč Boss App ID. Tento klíč je možné získat bezplatnou registrací a slouží k identifikaci aplikace. Za tímto klíčem se už uvádějí pouze nepovinné parametry, jejichž výčet je uveden v dokumentaci. Mezi nimi se nachází například možnost omezení vyhledávání pouze na určitá URL, nastavení počtu navracených výsledků nebo jazyk vyhledávání. Standardně jsou všechny výsledky vraceny ve formátu JSON, avšak pomocí volitelného parametru format je možné nastavit výstupním formátem soubor XML Bing V roce 1998 vstoupila na trh vyhledávačů společnost Microsoft se svým MSN Search, který zpočátku využíval vyhledávacích služeb jiných poskytovatelů. V roce 2006 následovala podstatná aktualizace služby, která byla uvedena pod jménem Windows Live Search. Zcela nový vyhledávací algoritmus byl komponentou aktivit souhrnně ukrytých pod značkou Windows Live. Roku 2007 došlo k marketingovému a organizačnímu odtržení vyhledávače od služeb Live do další podoby - Live Search. Aktuálně uvedený vyhledávač Bing je bezprostředním potomkem této vyhledávací platformy. Microsoft při své současné technologické úrovni v daném oboru může nabídnout služby plně srovnatelné s konkurencí tedy v globálním měřítku s Yahoo! a Google. Vzhled a funkce nového vyhledávače se drží zažitých konvencí tak, aby byly pro uživatele jednoduché (Bednář, 2009). Česká verze je prozatím v beta verzi a spíše než o plnohodnotný Bing vyhledávač se jedná o převlečený Live Search, který neobsahuje všechny nové funkce. K tomu, aby mohl český uživatel využívat plný potenciál nového vyhledávače, jej musí přepnout do zobrazení pro USA. Ten oproti české verzi navíc obsahuje: vyhledávání ve videích, mapách a obchodech přímo v liště, historii vyhledávání, náhled textu v prohledávané stránce. 15

20 2.3 Rozhraní vyhledávacích služeb (API) 20 Kromě klasického webového vyhledávače nabízí i Bing API rozhraní pod názvem Bing API Version , které neslouží čistě k vyhledávání, ale nabízí i další funkce. Mezi tyto funkce můžeme zařadit například vkládání reklam do aplikací nebo překladač textů. Naše práce se však bude zabývat čistě vyhledávacími funkcemi. API podporuje vyhledávání mezi weby, obrázky, videi, novinkami, mobilními weby a umožňuje taky vyhledávání v encyklopedii Encarta 17. Jednotlivé dotazy jsou zasílány pomocí metody GET a jejich tvar se odvíjí dle typu požadovaného formátu výsledků JSON a XML. API navíc podporuje protokol SOAP 18, jenž umožňuje v projektech Microsoft Visual Studia integraci vyhledávacího rozhraní přímo do vyvíjené aplikace (Microsoft Corporation, 2010). Obecný formát dotazů pro výstupy ve formátu JSON a XML jsou: sources=typ_dat[&parametr=hodnota&] sources=typ_dat[&parametr=hodnota&] Tak jako BOSS i Bing API Version 2.0 vyžaduje vložení aplikačního klíče, který umožní identifikaci aplikace přistupující k vyhledávači. Tento klíč, volně dostupný po zaregistrování na webu, se zadává do povinného parametru Appid. Dalšími povinnými parametry jsou query a sources obsahující hledaný řetězec znaků a typ dat, mezi kterými má být provedeno vyhledávání. Dále pak už následují pouze nepovinné parametry, jejichž výčet je oproti konkurenci menší Shrnutí Na základě výše uvedených informací lze konstatovat, že možnosti nastavení vyhledávácích rozhraní jednotlivých poskytovatelů jsou si velmi podobné. Všichni zmiňovaní podporují kladení dotazů pomocí metody GET, jejíž tvar je definován v dokumentaci příslušného poskytovatele. Jednotlivé dotazy obsahují části povinné (zejména klíčové slovo a typ vyhledávaných dat) a části nepovinné, které umožňují bližší specifikaci dotazu. U Bing a Yahoo! je navíc potřeba provést bezplatnou registraci díky níž uživatel obdrží unikátní klíč, jenž je povinným parametrem zasílaného dotazu. Všechny vyhledávače podporují vyhledávání mezi základními typy dat weby a obrázky. Jednotlivé služby pak dále rozšiřují nabídku datových typů, které jsou velmi různorodé (např. vyhledávání v encyklopedii, návrhy hláskování apod.). V oblasti podporovaných formátů výsledků je na tom nejlépe Bing podporující XML, JSON a navíc protokol SOAP. Po stránce zpracování dokumentace je na tom nejlépe Yahoo!, který si dal záležet na velmi přehledném poskytnutí srozumitelných a užitečných informací o službě a možnostech práce s ní Simple Object Access Protocol protokol pro výměnu dat v decentralizovaných, distribuovaných prostředích

21 3 TECHNICKÉ PROSTŘEDKY 21 3 Technické prostředky Tato kapitola představí klíčové technické prostředky, kterých bude třeba využít k implementaci výsledné služby zajišťující automatickou indexaci mapových zdrojů a jejich transformaci do vhodného souborového formátu. 3.1 Qt framework Qt, vyvíjená společností Qt Development Frameworks 19 (dříve Trolltech), je multiplatformní aplikační a UI framework běžící na platformách jako jsou Embedded Linux, Mac OS X, Windows, Linux/X11, Windows CE/Mobile, Symbian a Maemo. Použitím Qt můžete napsat webové aplikace pouze jednou a poté je nasadit na různorodých desktopových, mobilních a embedded operačních systémech bez nutnosti přepisu zdrojového kódu (Nokia Corporation, 2009). Mezi nejznámější aplikace využívající tento framework patří desktopové prostředí KDE 20, Google Earth, Opera, Skype nebo virtualizační nástroj VirtualBox. První verze Qt byla vydána již v roce 1991 a od té doby se framework stále rozšiřuje a zlepšuje. V současné době je Qt ve verzi 4.6, která je dostupná jak pod komerční, tak i pod LGPL 21 licencí, která navzdory určitým omezením zaručuje, že software pod ní vyvíjený, je možno prodávat bez nutnosti zakoupení licence Nástroje Qt nabízí nástroje pro podporu tvorby aplikací v oblasti 3D grafiky a multimédií, které umožňují vytvářet interaktivní grafické aplikace využívající výhod pokročilých kreslících funkcí. Dále obsahuje nástroje pro tvorbu platformově nezávislých databázových aplikací podporujících většinu databázových systémů, práci s ActiveX R ve Windows a Motif TM v systémech Unix, modul umožňující čtení a manipulaci s daty uloženými ve formátech založených na XML struktuře, tzv. widgets poskytující vyvíjeným aplikacím standardní GUI 22 funkcionalitu a mnoho dalších užitečných nástrojů. Qt představuje inovativní alternativu pro komunikaci mezi objekty nazývanou signály a sloty, která nahrazuje starou a ne příliš bezpečnou techniku zpětného volání používanou v mnoha frameworcích (Nokia Corporation, 2009) Moduly Qt se skládá z mnoha modulů, jež jsou odděleně uloženy v knihovnách. Tyto moduly můžeme rozdělit do 3 hlavních skupin: obecné moduly pro vývoj software, moduly K Desktop Environment desktopové prostředí pro Linux 21 GNU Lesser General Public License 22 Graphical User Interface - grafické uživatelské rozhraní umožňující ovládat počítač pomocí interaktivních grafických ovládacích prvků

22 3.2 XML 22 pro práci s Qt nástroji a moduly pro Windows a Unix vývojáře. Jejich detailní popis je k nalezení v oficiální dokumentaci Qt knihovny. Moduly musí být v programu připojeny vhodným zápisem do projektového souboru a následným připojením v hlavičkovém souboru třídy, která bude danou funkcionalitu modulů využívat (Polovinčák, 2009). /* zápis v projektovém souboru */ QT += core network xmlpatterns /* zápis v hlavičkovém souboru */ #include <QtCore> #include <QtNetwork> #include <QtXmlPatterns> 3.2 XML Extensible Markup Language (XML) je jednoduchý, velmi flexibilní textový formát odvozený od metajazyka SGML 23. Tento značkovací jazyk (World Wide Web Consortium, 2008) byl vyvinut XML Working Group (původně známý jako SGML Editorial Review Board) pod záštitou W3C 24 v roce Formát XML sehrává stále důležitější roli při elektronické výměně nejrůznějších dat (EDI 25 ) mezi aplikacemi a pro publikování dokumentů, u kterých popisuje jejich datovou strukturu. Cílem návrhu XML bylo zejména: použitelnost v internetovém prostředí, podpora širokého spektra aplikací, kompatibilita s SGML, snadná tvorba aplikací, které dokáží zpracovat XML, dostatečně jasné a čitelné dokumenty, počet volitelných funkcí v XML musí být omezen na absolutní minimum, v ideálním případě na nulu, lehce vytvořitelné dokumenty. Každý XML dokument má logickou a fyzickou strukturu. Fyzická struktura zahrnuje skladbu dokumentu z jednotek nazývaných entity, jenž mají jasně danou hierarchickou strukturu a vztahy mezi sebou. Každý dokument začíná kořenovou entitou, na kterou navazují entity další. Logická struktura je tvořena elementy, které jsou ohraničené buď počáteční a koncovou značkou start-tag a end-tag nebo pouze jednou značkou u tzv. prázdných elementů. Každý element nese typ, identifikátor jména a nepovinně taky jeden nebo více atributů (World Wide Web Consortium, 2008). Následující příklad názorně předvádí stavbu jednotlivých značek: 23 Standard Generalized Markup Language univerzální značkovací metajazyk jehož podmnožinami jsou ostatní značkovací jazyky 24 World Wide Web Consortium Electronic Data Interchange

23 3.2 XML 23 /* Příklad počáteční a koncové značky */ <nazev_znacky atribut="hodnota">data</nazev_znacky> /* Příklad značky u tzv. prázdných elementů */ <nazev_znacky atribut="hodnota"/> Definice struktury XML dokumentů Document Type Definition (DTD) udává, které elementy a atributy mohou tvořit strukturu dokumentu, včetně vztahů mezi jednotlivými elementy. DTD schéma je vhodným nástrojem pro kontrolu validity struktury jednotlivých dokumentů a za podmínky jejího splnění nám umožní využívat i různých specifických nástrojů navržených pro práci s nimi. DTD se k dokumentu přidává pomocí deklarace typu dokumentu DOCTYPE, která je umístěna na začátku dokumentu ihned za XML deklarací. Deklarace má následující tvar (Kosek, 1999): <!DOCTYPE Kořenový_element SYSTEM "Url"> Kořenový_element je jméno kořenového elementu, který obsahuje všechny další elementy dokumentu. Url udává adresu nebo jméno souboru, ve kterém je uloženo DTD. DTD však není jediným schématem definujícím strukturu XML dokumentů. Novějším je XML Schema, označované jako XSD 26, které narozdíl od DTD umožňuje definici přípustných datových typů Zpracování XML Ke zpracování, tzv. parsování se v současné době nejvíce používají dvě API DOM 27 a SAX 28, které se liší v přístupu ke zpracování XML dokumentu. Obecně se však nedá určit, které z nich je lepší každé má své klady a zápory. DOM, pravděpodobně známější rozhraní pro zpracování XML, je vyvíjen a standardizován W3C. Obsah XML dokumentu je převeden do paměti na objektový model v podobě stromové struktury, která přesně odráží složení dokumentu. DOM je využíván téměř všemi moderními webovými prohlížeči, protože umožňuje například kdykoliv přistoupit ke všem prvkům ve struktuře. Další výhodou DOM je, že vytvořenou stromovou strukturu lze měnit, popřípadě ji lze převést zpět do XML dokumentu. K těmto operacím se využívají již nadefinované funkce daného vývojového prostředí. Nevýhodou však je vysoká paměťová náročnost, která se nehodí pro zpracování příliš objemných dokumentů (Molketin, 2007). SAX je vyvíjen jako opensource SourceForge 29 projekt napsaný v programovacím jazyce Java (SAX Project, 2005). SAX je rozhraní řízené událostmi, které 26 XML Schema Definition 27 Document Object Model 28 Simple API for XML

24 3.3 Moebius Mapserver 2 24 jsou generovány v průběhu zpracování XML dokumentu. Jednotlivé typy událostí jsou vyvolávány na základě prvků vstupního dokumentu, jako jsou značky, komentáře, instrukce pro zpracování atd. Programátor pak musí ručně naimplementovat metody, které se mají volat pro jednotlivé typy událostí. Hlavní nevýhodou tohoto přístupu je, že SAX nepodporuje manipulaci s dokumentem celý se sekvenčně čte jako proud znaků a neumožňuje vracení se zpět. Z toho důvodu záleží hlavně na programátorovi, které metody se rozhodne naimplementovat k zabezpečení zpracování určitých událostí. Tyto vlastnosti dělají SAX rozhraní vysoce efektivní, poměrně rychlé a relativně nenáročné na paměť, což umožňuje zpracování objemných dokumentů. Na druhou stranu jsou kladeny vyšší požadavky na schopnosti programátora než u DOM (World Wide Web Consortium, 2003) Moduly Qt pro zpracování XML Qt framework poskytuje dva moduly pro práci s XML. Prvním je QtXml, který obsahuje metody pro čtení a zápis XML souborů a taky C++ implementaci SAX a DOM parseru. Druhým modulem je QtXmlPatterns, který obsahuje užitečné metody například pro validaci dat oproti XSD schématům. Pro zpřístupnění funkcionality obou modulů je nutné upravit projektový soubor a hlavičkové soubory tříd přidáním následujících řádků: /* zápis v projektovém souboru */ QT += xml xmlpatterns /* zápis v hlavičkovém souboru */ #include <QtXml> #include <QtXmlPatterns> 3.3 Moebius Mapserver 2 Jak již bylo zmíněno v úvodu, myšlenkou vytvoření funkčního virtuálního mapového serveru dostupného veřejnosti se již zabývali studenti Mendelovy univerzity v Brně. Výsledkem jejich práce je Moebius Mapserver 2 (MM2), což je aplikace napsaná v jazyce C++ využívající knihovnu Qt. Tato aplikace má za úkol indexovat a virtualizovat různé webové mapové služby tak, aby bylo možné provádět vyhledávání nad takto sjednocenými geodaty. Virtualizační část MM2 zatím podporuje pouze dvě operace GetCapabilities a GetMap, což je část specifikace označovaná jako Basic WMS Virtualizační část Základní princip funkce virtualizační části spočívá v udržování souboru symbolických odkazů na skutečné vrstvy mapových serverů. Pokud uživatel požaduje virtuální mapovou vrstvu, MM2 akceptuje tento požadavek, vytvoří novou žádost na reálnou vrstvu a zašle ji na zdrojový mapový server. Odpověď, v podobě souboru

25 3.3 Moebius Mapserver 2 25 s rastrovým obrázkem, je předána klientovi (Polovinčák, 2009). Hlavní přínos tohoto přístupu je poskytnutí rozhraní umožňujícího manipulaci s geodaty bez nutnosti znalosti jejich reálného úložiště. To znamená, že uživatel je oproštěn od potřeby prohledávat celý Internet za účelem nalezení konkrétních geodat tuto práci za něj vykoná MM2, který vystupuje jako klasický mapový server jak vůči klientovi, tak vůči reálným mapovým serverům (Procházka, 2008). Popis virtualizační části vychází z práce Polovinčáka (2009). Hlavní třídou aplikace virtualizační části je Moebius, která zajišťuje načtení nastavení z konfiguračního souboru umístěného na lokálním disku, připojení k databázovému serveru Postgre- SQL 30 a spuštění TCP 31 serveru. Samotný TCP server, jenž je klíčovou částí projektu, naslouchá na konkrétním portu a vyřizuje klientské požadavky. Celý server je navržen pro zpracování jednotlivých požadavků v samostatných vláknech, což má pozitivní vliv na rychlost odezvy. Protokol WMS definuje dle platné specifikace dvě použitelné metody komunikace GET a POST. Pouze první zmíněná metoda byla implementována. Příklad demonstrující položení GetCapabilities (GC) dotazu pomocí GET metody: Takto položený dotaz aplikace přijme a na základě definované operace a parametrů buď položí dotazy na reálné mapové servery, jejichž zpracované odpovědi předá klientovi a nebo vrátí klientovi seznam zaindexovaných mapových vrstev v databázi. Novinkou oproti práci doktora Procházky bylo rozšíření protokolu o možnost vyhledávání. Klient má možnost pomocí několika navržených parametrů specifikovat v GC dotazu o jaké mapové vrstvy má zájem (např. vyhledávání podle zeměpisné polohy, výskytu klíčového slova v metadatech vrstev apod.). Na základě těchto parametrů je odpovědí GC soubor obsahující geodata, která splňují definované podmínky pro vyhodnocování a řazení výsledků byl navržen speciální algoritmus Indexovací část Popis indexovací části je založen na práci Šimoníka (2009). Hlavní třídou indexovací části je Indexer, která zajišťuje stejné funkce jako hlavní třída u virtuálního mapového serveru, tj. načtení konfigurace, připojení k databázovému serveru PostgreSQL a spuštění TCP serveru, který naslouchá na určitém portu. Komunikace mezi klientem a serverem je realizovaná POST metodou. Úkolem indexeru je zpracování POST dotazu, který obsahuje URL na reálný mapový server ve formátu: addr=url_na_getcapabilities Na základě hodnoty atributu addr si aplikace vyžádá GC soubor reálného serveru, zpracuje jej pomocí DOM parseru a jeho obsah zaindexuje vhodným způsobem 30 Relační opensource databázový systém 31 Transmission Control Protocol transportní protokol sloužící k vytváření síťových spojení mezi počítači

26 3.3 Moebius Mapserver 2 26 do databáze. Nad takto zaindexovanými daty jsou následně prováděny operace Get- Capabilities a GetMap virtualizační části aplikace MM2. Indexovací část implementuje aktualizační službu, která má za úkol zabezpečit aktuálnost dat v databázi. Principem aktualizace je pravidelné procházení URL již zaindexovaných reálných mapových serverů a jejich opětovné naindexování. Při aktualizaci záznamů se neporovnávají počty vrstev mezi databází a nově obdrženým GC souborem, ale je provedeno smazání všech vrstev a naindexování nových ze souboru. V průběhu aktualizace se může stát, že dotazovaný server bude nedostupný, ať už z důvodu momentální přetíženosti či jeho neexistence. V takovém případě se nastaví příznak nedostupnosti, který při dosažení definované hranice způsobí vyřazení daného serveru z databáze. Proces aktualizace probíhá v pravidelných periodách, které jsou definovány v konfiguračním souboru: <updating> <time>3:00</time> <period>14</period> </updating> Nevýhodou současného indexeru je absence validace obdržených GC souborů oproti DTD, což by mělo jistě za následek zvýšení odezvy indexovací části. V tuto chvíli se indexer snaží zaindexovat jakékoliv předložené XML, což je v případě jeho nekorektní struktury ztrátou času. Validátor by zajistil, že takto nekorektní data by nebyla vůbec zpracována.

27 4 METODIKA 27 4 Metodika Pro realizaci nástrojů pro automatizované indexování webových mapových služeb a transformaci geodat je nezbytné vybrat vhodný způsob jejich vyhledávání, zvolit vhodný souborový formát pro transformaci a vytvořit uživatelsky přívětivé rozhraní umožňující ovládání již zmíněných nástrojů. Výběr vyhledávací služby Vyhledávací služba má za úkol poskytnout klíčová geodata funkční části aplikace. Z toho důvodu je nezbytné vybrat vhodný způsob jejich vyhledávání. Na výběr máme ze dvou již zmiňovaných možností webové vyhledávací rozhraní a katalogové mapové služby. V tuto chvíli neexistuje jednotná katalogová služba, která by poskytovala centralizovanou databázi všech WMS. Namísto toho existuje mnoho roztroušených katalogových služeb, které jsou pro tento projekt nevhodné. A to z toho důvodu, že pro zefektivnění vyhledávání WMS je vhodné využít pouze jedinou službu, která by byla schopna nalézt co nejvíce relevantních dat. Na základě toho se zaměříme na webové vyhledávací rozhraní, které by mělo tento požadavek splnit. Pro výběr API byla definována čtyři kritéria: množství zaindexovaných dat ve vyhledávačích, podporovaný formát odpovědí, dokumentace, stabilita služby. Výběr vhodného řešení bude proveden na základě prostudovaných vyhledávacích API popsaných v předchozím textu, dostupných informací na Internetu a jednoduchého ověření funkcionality. Největší důraz bude kladen na množství zaindexovaných dat ve vyhledávačích, jelikož je požadováno získání co největšího počtu WMS. Výběr souborového formátu pro transformaci Důležitým krokem před tvorbou samotného nástroje pro transformaci geodat je volba souborového formátu. Výběr bude proveden na základě informací v předchozím textu tak, aby byla jeho implementace co nejjednodušší a jeho podpora ze strany neprofesionálních GIS produktů byla co nejvyšší. Velký důraz bude kladen na rozšířenost tohoto software mezi širokou laickou veřejností. Výběr uživatelského rozhraní Uživatelské rozhraní slouží jako prostředek pro komunikaci mezi uživatelem a výslednými nástroji. Toto rozhraní by mělo jednoduchým a přehledným způsobem uživateli umožnit přístup do databáze již zaindexovaných WMS služeb, jejich transformaci do vhodného souborového formátu a spuštění automatické nebo ruční indexace WMS. Výsledné rozhraní by mělo sloužit pouze jako prezentační vrstva (GUI), která bude oddělena od funkční části aplikace. Z důvodu požadavku na širokou dostupnost rozhraní bez nutnosti instalace dodatečné aplikace se jeví nejlepším řešením forma webové aplikace.

28 5 VLASTNÍ ŘEŠENÍ 28 5 Vlastní řešení Vlastní řešení práce spočívá ve výběru vhodných komponent pro experimentální implementaci nástrojů pro automatizované indexování webových mapových služeb a transformaci geodat a jejich následnou implementaci. Před samotnou implementací bude provedena vizualizace návrhu výsledných nástrojů pomocí jazyka UML v diagramu tříd, který je uveden v příloze B. 5.1 Výběr vhodných komponent Komponenty potřebné pro implementaci (vyhledávací služba, souborový formát a uživatelské rozhraní) jsou vybírány na základě předpokladů, které byly stanoveny v předchozí kapitole Výběr vyhledávací služby Jak již bylo zmíněno v předchozím textu, volba vyhledávací služby bude provedena na základě čtyř důležitých kritérií množství zaindexovaných dat, podporovaný formát odpovědí, dokumentace služby a stabilita služby. Při prověřování množství zaindexovaných dat ve vyhledávačích bylo provedeno zkušební vyhledávání, které mělo za úkol vrátit co nejvíce relevantních výsledků pro klíčové slovo getcapabilities. Toto vyhledávání prokázalo, že nejvíce relevantních výsledků vrací služba od Google, následována službami od Yahoo! a Bing, které jich vracely podstatně méně. Tyto výsledky potvrzují mnohé články odborných periodik a serverů, které řadí vyhledávač Google mezi světovou špičku neustále zdokonalující své vyhledávací algoritmy, díky čemuž se stává nejúspěšnějším. V počtu formátů odpovědí dominuje Bing, který kromě XML a JSON nabízí podporu i protokolu SOAP. Na pomyslné druhé příčce skončilo Yahoo! následováno Google. Nejvhodnějším formátem pro zpracování pomocí Qt knihovny se jeví formát XML, pro jehož zpracování je možno využít jak DOM, tak i SAX parser. V oblasti zpracování dokumentace dominuje Yahoo!, které si ze všech tří poskytovatelů dalo nejvíce záležet na přehledném poskytnutí všech důležitých informací. Při testování funkčnosti jednotlivých vyhledávacích rozhraní byl nalezen problém se stabilitou rozhraní Google, které ne vždy vracelo korektní počet výsledků ve formátu JSON. To se projevovalo v tom, že ne vždy bylo možno projít všechny navrácené výsledky a nebo byl počet navrácených výsledků velmi nízký oproti stejnému vyhledávání provedenému o pár sekund později. Přehled umístění vyhledávačů v jednotlivých kategoriích je znázorněn v Tab. 2.

29 5.1 Výběr vhodných komponent 29 Tab. 2: Přehled umístění vyhledávačů v jednotlivých kategoriích Bing Yahoo! Google Množství zaindexovaných dat Formát odpovědí Dokumentace Stabilita Při pohledu na tabulku se jeví na první pohled nejvhodnějším vyhledávačem Yahoo!. Avšak na základě kritéria množství zaindexovaných dat byl zvolen vyhledávač Google, který poskytuje nejvíce relevantních výsledků, což je klíčovým předpokladem pro optimální chod nástroje automatizované indexace. Jak již bylo zmíněno výše, při využívání rozhraní nastávaly problémy s navracenými výsledky, což znemožňovalo bezproblémové využití služby. Po důkladném zvážení všech kladů a záporů bylo od počátečního návrhu využití rozhraní API upuštěno. I za cenu ručního zpracování výsledků je totiž výhodné využít vyhledávací službu navracející maximální počet relevantních výsledků. Z toho důvodu budou jednotlivé dotazy kladeny pomocí protokolu HTTP na standardní URL, jenž je využívána pro běžné webové rozhraní vyhledávače Google. Princip pokládání dotazů je obdobný tomu, jenž je popsán výše. Výsledky však budou vraceny ve formátu HTML, který je nutno ručně zpracovat pomocí metod vytvořených přímo pro tento účel Výběr souborového formátu pro transformaci Dalším důležitým krokem je volba souborového formátu pro nástroj zajišťující transformaci geodat do formátu, který je podporován volně dostupnými geografickými aplikacemi. Z důvodu jednoduchosti implementace, dostačující nabídce funkcí, velmi kvalitní dokumentaci a široké podpoře ze strany softwarových produktů, byl zvolen souborový formát KML. Tento formát je mimo jiné podporován i aplikací Google Earth, která je masově rozšířena mezi veřejností a splňuje tak hlavní kritérium stanovené v předchozí kapitole. KML podporuje Super-Overlays, což je technologie umožňující sdílení libovolně velkých rastrů pomocí Internetu tak, aby nebyla omezena interaktivita klientské aplikace z důvodu vysoké datové náročnosti přenosu. Jejím detailnějším popisem se budeme zabývat v implementační části práce Výběr uživatelského rozhraní Posledním dílčím krokem je vytvoření jednoduchého rozhraní pro ovládání výsledných aplikací, jehož návrh vzhledu je zobrazen na Obr. 4. Jako nejlepší řešení se jeví vytvoření webové aplikace využívající PHP, HTML, CSS a SQL. Tato aplikace by měla uživateli umožnit přístup do databáze již naindexovaných WMS služeb, jejich transformaci a spuštění indexace WMS. Přístup do databáze by byl prováděn pomocí PHP skriptu, což je nejjednodušší způsob získání dat v ní obsažených. Spouštění aplikací pro transformaci dat a indexaci by bylo prováděno opět pomocí

30 5.2 Implementace 30 PHP kódu, který by tyto služby spouštěl přímo na serveru a vracel jejich výstupy webové aplikaci. Obr. 4: Návrh vzhledu webové aplikace 5.2 Implementace V předchozí části této kapitoly byly vybrány potřebné komponenty pro výsledné nástroje a v následujícím textu bude popsána jejich experimentální implementace. Ta bude rozdělena do tří podsekcí zabývajících se popisem výsledných nástrojů pro vyhledávání geodat, jejich transformaci do KML a uživatelským rozhraním sloužícím k jejich ovládání. Nástroje pro vyhledávání geodat a jejich transformaci byly vytvořeny v jazyce C++ za využití Qt framework ve verzi Pro jejich vývoj bylo použito vývojové prostředí Eclipse IDE for C/C++ Developers 32 umožňující snadnou správu projektu. Pro podporu Qt knihoven bylo zapotřebí doinstalovat balík Qt Eclipse Integration Vyhledávání geodat Nástroj pro vyhledávání geodat a jejich indexaci je založen na vyhledávání WMS služeb, které tato geodata agregují. Cílem vyhledávání jsou všechny URL, nesoucí GetCapabilities (GC) dotaz na mapový server, které poskytují seznam všech vrstev (geodat) na nich uložených. Nástroj je rozdělen do čtyř funkčních částí inicializace aplikace, nalezení dat na základě stanovených klíčových slov, validace nalezených dat a indexace do databáze. Nástroj byl navržen pro běh ve dvou režimech. Prvním z nich je vyhledávání geodat včetně jejich validace a automatizované indexace. Druhý režim, manuální indexace, slouží pro ruční vkládání URL nesoucí GC dotaz, jeho validaci a následnou indexaci. Tento režim byl navržen pro webovou aplikaci 32

31 5.2 Implementace 31 umožňující jak automatizovanou, tak i manuální indexaci. V následujícím textu si popíšeme výsledný nástroj a jeho jednotlivé funkční části. Aplikace se zavádí spuštěním souboru main.cpp, který zajistí vytvoření instance hlavní třídy Crawler a předání dvou atributů. První atribut, který je povinný, musí obsahovat název konfiguračního souboru. Druhý atribut, jehož zadání je nepovinné, nese GC dotaz na WMS server. Na základě počtu vložených atributů se zvolí jeden ze dvou výše popsaných režimů. Inicializace aplikace K úspěšné inicializaci aplikace je nejprve nutné načíst konfigurační soubor, jenž se nachází na lokálním disku tuto operaci zajišťuje metoda loadconfiguration() přebírající parametr s názvem souboru. Tato metoda ověří existenci a čitelnost XML souboru a zajistí jeho následné parsování metodou DOM (QDomDocument). Konfigurační soubor se načte pomocí metody setcontent() do dokumentu, který má formu stromové struktury. Ta umožňuje snazší přístup k jednotlivým prvkům. QFile fconfig(cfg); // inicializace konfiguračního souboru QDomDocument config; // vytvoření nového dokumentu // ověření existence a čitelnosti souboru if ( fconfig.exists() && fconfig.open(qiodevice::readonly) ) { // načtení obsahu souboru do dokumentu config.setcontent(&fconfig); } fconfig.close(); K procházení stromové struktury dokumentu config jsou k dispozici čtyři metody documentelement() vracející kořenový element, firstchild() vracející prvního potomka konkrétního elementu, toelement() vracející požadovaný element a nexsibling(), jenž vyhledává další elementy dané úrovně a navrací případného sousedního potomka. Nastavení, získané při procházení načtené stromové struktury, je uloženo do vícerozměrné mapy QMap. Po úspěšném načtení a zpracování konfiguračního souboru je nutné načíst a zvalidovat XML schéma (XSD), jenž bude využíváno k validaci získaných dat. K tomuto účelu je navržena metoda loadschema() přebírající jako parametr název souboru se schématem uloženým na lokálním disku. QXmlSchema schema; // vytvoření nového schématu QFile fschema(schema_path); // inicializace souboru // ověření existence a čitelnosti souboru if ( fschema.exists() && fschema.open(qiodevice::readonly) ) {

32 5.2 Implementace 32 // načtení schématu ze souboru schema.load( &fschema, QUrl::fromLocalFile(fSchema.fileName()) ); } // validace načteného schématu if (!schema.isvalid() ) { // ošetření neplatného schématu } fschema.close(); Pro práci se schématem jsou implementovány dvě metody instance třídy QXmlSchema load(), která načítá ze zdroje dat (např. QIODevice) potřebné schéma a metoda isvalid(), jenž jej validuje oproti W3C specifikaci. Takto načtené a zvalidované schéma je možné využít k validaci oproti jakémkoliv XML dokumentu. Vyhledávání dat na základě klíčových slov Část pro vyhledávání dat je tvořena dvěmi klíčovými metodami getresults() a parseresults(). Metoda getresults(), přebírající parametr s hledaným klíčovým slovem (řetězcem), má za úkol zaslání požadovaného dotazu na webové rozhraní Google a zpracování navrácených výsledků. Jednotlivá klíčová slova jsou během inicializace načtena z konfiguračního souboru a uložena v dynamickém poli keywords. Pro každé z klíčových slov je metoda volána samostatně, tak jak demonstruje následující příklad. // procházení pole klíčových slov a volání metody getresults() for (int i = 0; i < keywords.size(); ++i) { // získání výsledků pro dané klíčové slovo getresults( keywords.value(i) ); } Metoda getresults() iterativně prochází navrácená HTML data a pomocí speciálně navržené metody parseresults() vyhledává URL, které jsou službou Google označeny jako relevantní vzhledem k hledanému klíčovému slovu (řetězci). Všechny takto navrácené URL jsou ukládány do dynamického pole results. Kromě toho metoda parseresults() zkoumá i data na nich uložená. Z důvodů zvýšení efektivnosti vyhledávání jsou všechny URL, které se v těchto datech vyskytují, taktéž uloženy do pole results. Dá se totiž předpokládat, že navracené výsledky jsou tematicky spojeny s WMS službami a i když dané URL nebude obsahovat přímo GC soubor, mohou se zde vyskytovat aspoň odkazy na tyto soubory. Validace výsledků Jakmile je dokončeno dotazování na službu Google a všechny navrácené URL jsou uloženy, přichází na řadu jejich validace oproti načtenému XSD. Pro naše účely bylo zvoleno XSD definující strukturu GC souboru ve verzi 1.1.1,

33 5.2 Implementace 33 která je v tuto chvíli implementována na většině mapových serverů. Validace je prováděna ve smyčce, ve které se prochází pole results. Ke každé URL jsou stažena data na ní uložená (downloadurl()) a je provedena jejich validace oproti XSD. V případě, že jsou data validní, tzn. obsahují GC informace ve verzi 1.1.1, je daná URL uložena do dynamického pole validated. Následující příklad zjednodušeně demonstruje proces validace. QXmlSchemaValidator validator(schema); // nastavení XSD pro validaci QByteArray data; // pole bytů určené pro stažená data downloadurl(address,data); // stažení dat z konkrétní URL if ( validator.validate(data) ) // validace stažených dat { // zpracování validní URL } Indexace validních výsledků Zasílání validních URL je prováděno pomocí metody sendtoindexer(), která komunikuje pomocí metody POST s indexovací částí služby MM2. Tato metoda přebírá tři parametry první z nich definuje URL s GC dotazem a zbylé dva adresu a port, na kterém běží indexer. Následující zjednodušený příklad zobrazuje komunikaci s indexační částí, které se předává zvalidované URL určené k indexaci (param). QHttp http; QUrl url(indexurl); // nastavení událostní smyčky QEventLoop loop; QObject::connect(&http, SIGNAL(done(bool)), &loop, SLOT(quit())); // nastavení adresy a portu a zaslání dat pomocí POST http.sethost(url.host(), url.port(indexerport)); http.post(url.toencoded(qurl::removescheme QUrl::RemoveAuthority), param); loop.exec(); // čeká na dokončení komunikace Komunikaci zajišťuje třída QHttp sloužící pro základní ovládání protokolu HTTP a QEventLoop spouštící smyčku do doby, než jsou všechna data přenesena. Adresa a port indexeru jsou dány instancí třídy QUrl. Samotná komunikace je prováděna pomocí metody post() instance třídy QHttp, které předchází definice adresy a portu indexeru (sethost()). Zasílaná data, nesoucí URL s validním GC dotazem, jsou předávána v proměnné param. Pro zajištění přenosu všech dat je nutno spustit událostní smyčku, která zajistí, že proces nebude ukončen dříve než bude

34 5.2 Implementace 34 dokončena komunikace. K ošetření událostní smyčky je třeba napojit signál done() objektu http na slot quit() objektu loop, čímž se zajistí přerušení smyčky v případě dokončení komunikace Transformace geodat Transformace geodat do formátu KML (služba pod názvem WMS2KML 33 ) je prováděna pomocí dvou CGI skriptů captokml a getkml běžících na experimentálním serveru echo 34. Řešení CGI skripty je implementačně snadnější, jelikož není potřeba uvažovat správu síťového spojení. Veškerá komunikaci s uživatelem je spravována řešením externím (v našem případě Apache 35 ) a CGI se zaměřuje pouze na poskytnutí potřebné služby. Nástroj WMS2KML, běžící jako mezivrstva mezi mapovým serverem a klientem, je schopen převést obsah mapového serveru do KML souboru s podporou technologie Super-Overlays. Takto transformovaná data je možné zpřístupnit v mnoha GIS aplikacích v našem případě se jedná o Google Earth, který podporuje načítání rastrů pomocí standardu WMS (viz příloha C). Obr. 5: Princip rozdělení rastru na díly pro Super-Overlays (Procházka, 2008)

35 5.2 Implementace 35 Princip Super-Overlays Následující teoretický popis technologie vychází z disertační práce Procházky (2008). Formát KML teoreticky umožňuje sdílení libovolně velkých rastrů, jejichž distribuce je v praxi problematická. V určitých případech je totiž nutné přenášet velký objem dat, která jsou vykreslena až ve chvíli kompletního stažení ke klientovi. Řešením je využití technologie Super-Overlays, která umožňuje sdílení libovolně velkých rastrů pomocí Internetu tak, aby nebyla omezena interaktivita klientské aplikace z důvodu vysoké datové náročnosti přenosu. Celý princip vytváření KML souborů je založen na tvorbě pyramid, tj. několika podvzorkovaných verzí rastru. Vytvoření pyramidy pro zobrazení rozsáhlého rastru se skládá ze dvou kroků (viz Obr. 5): Rozdělení na díly rastrová vrstva v původním rozlišení např px je rozdělena na 4 díly o hraně 1024 px, ty jsou rekurzivně rozděleny na 4 díly o hraně 512 px atp., až do určité zvolené velikosti (např. 256 px). Podvzorkování každý díl je podvzorkován na zvolenou minimální velikost (v tomto případě 256 px). Ke sdílení takto vytvořeného obrazu pomocí technologie Super-Overlays je třeba vytvořit jeden hlavní (nejvyšší úrovně) a několik vedlejších (nižších úrovní) KML souborů. Struktura KML souboru nejvyšší úrovně je znázorněna na následujícím příkladu, který byl z důvodu rozsáhlosti zkrácen.... <NetworkLink> <name>global_mosaic</name> <description>wms Global Mosaic, pan sharpened</description> <visibility>0</visibility> <Style> <ListStyle> <listitemtype>checkhidechildren</listitemtype> </ListStyle> </Style> <Region> <LatLonAltBox> <north>84</north> <south>-60</south> <east>180</east> <west>-180</west> </LatLonAltBox> <Lod> <minlodpixels>128</minlodpixels> <maxlodpixels>-1</maxlodpixels> </Lod> </Region> <Link> <href> wms.jpl.nasa.gov/wms.cgi?service=wms&request=getmap&

36 5.2 Implementace 36 version=1.1.1&layers=global_mosaic&srs=epsg:4326& bbox=-180,-60,180,84&styles=&format=image/png& transparent=true&width=256&height=256& draworder=1&</href> <viewrefreshmode>onregion</viewrefreshmode> </Link> </NetworkLink>... Tato struktura vychází z KML, který byl vygenerován skriptem captokml. Důležitým elementem je NetworkLink představující odkaz na další KML soubor. Element visibility definuje, zda-li mají být vrstvy po načtení v 3D prohlížeči automaticky viditelné. Element Region specifikuje, ve které oblasti a při jakém přiblížení má dojít k přechodu na jiný KML soubor. Oblast je definována elementem LatLonAltBox pomocí geografických souřadnic a přiblížení Level of Detail elementem Lod, který udává potřebný počet pixelů zobrazených v dané oblasti tak, aby došlo k přechodu. Element Link definuje soubor, na který se přechází při splnění nutných podmínek. Z konkrétního příkladu je vidět, že daná vrstva odkazuje na druhý skript getkml, který generuje pomocí Super-Overlays KML nižší úrovně, které oproti úrovni nejvyšší nese i rastrová data v podobě GetMap dotazu na mapový server. KML nižší úrovně se skládá ze tří hlavních elementů Region, GroundOverlay a NetworkLink. První dva jmenované slouží k zobrazovaní rastrového dílu (v nejnižším rozlišení) v konkrétní oblasti. Element NetworkLink pak slouží k definici čtyř nových podoblastí nad daným dílem. Při dostatečném přiblížení (Level of Detail) do některé z nově specifikovaných podoblastí dochází k přechodu na nový KML soubor obsahující rastr s vyšším rozlišením a rekurzivně definované podoblasti pro daný rastr. Následující příklad zobrazuje strukturu KML nižší úrovně (z důvodu rozsáhlosti byl opět zkrácen).... <Region> <LatLonAltBox> <north>84</north> <south>-60</south> <east>180</east> <west>-180</west> </LatLonAltBox> <Lod> <minlodpixels>128</minlodpixels> <maxlodpixels>-1</maxlodpixels> </Lod> </Region> <GroundOverlay> <name>global_mosaic_base</name> <draworder>1</draworder> <LatLonBox>

37 5.2 Implementace 37 <north>84</north> <south>-60</south> <east>180</east> <west>-180</west> </LatLonBox> <Icon> <href> request=getmap&version=1.1.1&layers=global_mosaic_base &srs=epsg:4326&bbox=-180,-60,180,84&styles=& format=image/png&transparent=true&width=256& height=256&</href> </Icon> </GroundOverlay> <NetworkLink>... </NetworkLink>... Takto vytvořená pyramidová struktura má výhodu v tom, že při pohledu z větší vzdálenosti není nutné načítat rastrovou vrstvu v maximálním rozlišení a současně se při přibližování načítají ve vyšším rozlišení pouze ty oblasti, které uživatel skutečně vyžaduje. To má za následek značné snížení skutečně přenesených dat mezi serverem a klientem. I když se v současné době rychlost internetových připojení neustále zvyšuje, často dochází k přetížení mapových serverů a technologie Super-Overlays je jednou z možností jak mu předcházet. captokml Tomuto skriptu se předává jediný parametr url odkazující na GC soubor poskytovaný WMS servery. Nejprve se vytvoří instance třídy GetCapabilitiesKML, které se předá již zmiňovaný parametr url. Pomocí DOM parseru jsou tato data zpracována a potřebné informace načteny verze podporovaného WMS standardu, souřadný systém, seznam podporovaných rastrových formátů, seznam všech poskytovaných vrstev a URL pro kladení GetMap dotazů. Na jejich základě je vygenerován hlavní KML soubor, který je tvořen hlavičkou a seznamem všech vrstev z GC souboru. Každá vrstva je v KML reprezentována elementem NetworkLink definující její oblast a odkaz na KML soubor obsahující pyramidu dané vrstvy. Tento odkaz směřuje na druhý skript getkml přebírající potřebné parametry pro vytvoření pyramidy. getkml Potřebné parametry z předchozí úrovně KML jsou předány instanci třídy outkml. Ta vytvoří KML soubor obsahující odkaz na rastrový díl specifikovaný pomocí elementu GroundOverlay. Odkaz na rastrový díl je tvořen GetMap dotazem na WMS server. Dále jsou vytvořeny rovnoměrným rozdělením aktuální oblasti čtyři nové podoblasti, každá definovaná samostatným elementem NetworkLink. Odkaz na další podoblast v každém NetworkLink elementu je tvořen rekurzivním voláním getkml skriptu.

38 5.2 Implementace Webové uživatelské rozhraní Vzhled webové aplikace (viz příloha D), tvořen pomocí XHTML a kaskádových stylů (CSS), vychází z návrhu v předchozí části této kapitoly. Webová aplikace se z funkčního hlediska dělí do tří částí výpis všech zaindexovaných vrstev včetně jejich transformace do KML, spuštění automatizované indexace a spuštění ruční indexace. Jednotlivé funkční části jsou přístupné za pomocí ovládacích prvků umístěných v horní liště. Existují dvě možnosti pro výpis všech zaindexovaných vrstev přímým přístupem do databáze za pomocí SQL nebo HTTP dotazem na službu MM2 vracející GC soubor, který obsahuje seznam všech vrstev. V našem případě byla zvolena možnost první, jenž nevyužívá MM2 jako mezivrstvu pro přístup do databáze a z toho důvodu je přímý přístup rychlejší. Přístup do databáze je řešen pomocí PHP kódu s využitím SQL dotazu načítající seznam všech zaindexovaných vrstev tak, jak nám znázorňuje následující příklad. /* funkce zajišťující komunikaci s databází */ function sendtodb($connection, $dotaz) { if (!$res = pg_query($connection, $dotaz) ) { echo Nastala chyba při komunikaci s databází.pg_last_error($connection); die; } return $res; } /* proměnná pro přístup do databáze */ $connection = pg_connect( host=localhost user=username password=password dbname=index_3 ); /* dotaz pro výpis všech vrstev */ $dotaz = "SELECT gcurl FROM Servers;"; $res = sendtodb($connection, $dotaz); Proměnná connection slouží pro připojení k databázi dbname běžící na stroji host, pod přihlašovacími údaji user a password. Vytvořená funkce sendtodb přebírá dva parametry definující připojení a dotaz SQL, na jejichž základě vrací výsledek res, který je následně zpracován a zobrazen. Jednotlivé výsledky je pak možno pomocí vytvořeného hypertextového odkazu na skript getkml převádět do KML. Další dvě funkční části, pro automatizovanou a ruční indexaci, jsou prováděny pomocí PHP kódu, který provede jejich spuštění na experimentálním serveru echo a zajistí přesměrování jejich výstupů do webové aplikace.

39 6 ZÁVĚR 39 6 Závěr V souladu se zadáním byly analyzovány dostupné zdroje informací o mapových službách v prostředí Internetu. Z důvodu následné implementace nástrojů, které by umožnily automatizovanou indexaci a transformaci nalezených geodat do vhodného souborového formátu, byly prozkoumány možnosti programovacího jazyka C++ a multiplatformní knihovny Qt, souborové formáty pro transformaci geodat a způsob indexace mapových služeb používaný v projektu MM2. Ze získaných teoretických znalostí byla vytvořena experimentální implementace těchto nástrojů. Na základě stanovených požadavků je výsledná aplikace pro automatizované indexování založena na vyhledávací službě Google. Z důvodu problémů se stabilitou API rozhraní bylo nutné přistoupit ke komunikaci skrze standardní webové rozhraní služby, což vyžadovalo vytvoření metod zajišťujících zpracování navracených výsledků. Aplikace pro transformaci geodat je založena na otevřeném formátu KML, jenž představuje silný nástroj pro prezentaci geodat bez nutnosti vlastnictví profesionálních GIS aplikací. Pro výsledné nástroje bylo vytvořeno grafické uživatelské rozhraní ve formě webové aplikace, jenž umožňuje jejich snazší ovládání. Při implementaci metod zajišťujících validaci výsledků bylo v knihovně Qt verze nalezeno několik zásadních chyb, které způsobují pád celé aplikace. Tyto chyby byly nahlášeny vývojářům knihovny a v následující verzi 4.7, která má vyjít v nejbližších týdnech, by měly být již opraveny. Dočasným řešením je vypnutí validace nalezených dat, což má za následek vyšší zatížení indexační části služby MM2, které se předává obrovské množství dat. Jiným řešením by mohlo být využití již existujících knihoven třetích stran, které taktéž implementují validační metody. Toto řešení se však nejeví být ideálním, jelikož by se do nástroje zaváděla další knihovna, jenž by jej činila zbytečně komplikovaným. Toto řešení by připadalo v úvahu až ve chvíli, kdy by se ukázalo, že v knihovně Qt se nachází příliš mnoho nových chyb na to, aby mohla být využívána pro naše účely. Navzdory zmíněnému problému bylo experimentální implementací ověřeno, že zvolený způsob vyhledávání se jeví býti vhodným řešením pro automatizovanou indexaci geodat poskytovaných službou MM2. Takto vytvořený nástroj je schopen nalézt velké množství geodat, která jsou roztroušena po Internetu, čímž řeší problematickou část služby MM2 nedostatek geodat dostupných uživateli. Společně s nástrojem pro transformaci geodat v kombinaci s vhodnými GIS nástroji otevírá uživatelům nové možnosti při práci s geografickými informacemi. Do budoucna by bylo vhodné nástroj pro automatizovanou indexaci rozšířit o podporu vyhledávání ve více vyhledávacích službách. Vyhledávání každého klíčového slova (řetězce) by se provádělo ve více vyhledávacích službách najednou, čímž by se zvýšil počet obdržených výsledků, jenž by pravděpodobně vedl k získání více validních geodat. Dalším vylepšením by mohla být implementace paralelního zpracování dat zvyšující výkon nástroje. V neposlední řadě by se také dalo zaměřit na optimalizaci dotazu, jehož možnosti nastavení jsou ze strany poskytovatele neustále rozšiřovány např. filtrování výsledků.

40 7 LITERATURA 40 7 Literatura Bednář, V. Lupa - Server o českém Internetu. [online] [cit ]. Hledáme s Bing.com čtvrtý pokus Microsoftu. Dostupné z WWW: < Bernard, L., et al., The European geoportal one step towards the establishment of a European Spatial Data Infrastructure. Computers, Environment and Urban Systems [online] 2005, 29, [cit ]. Dostupné z WWW: < Cenia Inspire. [online] c2010. [cit ]. Dostupné z WWW: < Esri ESRI Support Centre. [online] c2010. [cit ]. Dostupné z WWW: < connect/wms_connector/get_capabilities.htm>. Fishkin, R. Interval.cz. [online] [cit ]. Google Search Engine Ranking Factors V2. Dostupné z WWW: < Google Google Code. [online] c2010a. [cit ]. Google AJAX Search API. Dostupné z WWW: < reference.html>. Google Uživatelská příručka aplikace Google Earth. [online] c2010b. [cit ]. O jazyce KML. Dostupné z WWW: < Google Google Code. [online] c2010c. [cit ]. KML Tutorial. Dostupné z WWW: < tut.html>. Google Google Code. [online] c2010d. [cit ]. KMZ Files. Dostupné z WWW: < kmzarchives.html>. Kosek, J. Téměř vše o www. [online] [cit ] DTD Definice typu dokumentu pod lupou. Dostupné z WWW: < Masarykova univerzita Kurz práce s informacemi. [online] [cit ]. Vyhledávací nástroje na Internetu I. Dostupné z WWW: < pages/internet_opora.pdf>.

41 7 LITERATURA 41 Microsoft Corporation Microsoft Developer Network. [online] c2010. [cit ]. Bing API, Version 2. Dostupné z WWW: < Molketin, D. The Book of Qt 4 : The Art of Building Qt Applications. No Starch Press, Inc., s. ISBN Nogueras-Iso, J., et al., OGC Catalog Services: a key element for the development of Spatial Data Infrastructures. Computers & Geosciences [online] 2005, 31 [cit ]. Dostupné z WWW: < Nokia Corporation and/or its subsidiary(-ies) Qt 4.6 Whitepaper. [online] c2009. [cit ]. Dostupné z WWW: < Open Geospatial Consortium, Inc. Catalogue Service. [online] c a. [cit ]. OpenGIS Catalogue Service Implementation Specification. Dostupné z WWW: < Open Geospatial Consortium, Inc. Web Map Service. [online] c b. [cit ]. OpenGIS Web Map Service (WMS) Implementation Specification. Dostupné z WWW: < Open Geospatial Consortium, Inc. Geography Markup Language. [online] c c. [cit ]. OpenGIS Geography Markup Language (GML) Encoding Standard. Dostupné z WWW: < Polovinčák, B. R. Virtualizace webových mapových služeb. Brno, s. Bakalářská práce. Mendlova univerzita v Brně. Procházka, D. Modelování a vizualizace vymezeného geografického prostoru s možností interaktivního zásahu do modelovaného procesu. Brno, s. Dizertační práce. Mendlova univerzita v Brně. Sax Project. [online] [2005]. [cit ] Dostupné z WWW: < Šimoník, K. Indexování webových mapových služeb. Brno, s. Bakalářská práce. Mendlova univerzita v Brně. World Wide Web Consortium (W3C) World Wide Web Consortium (W3C). [online] [cit ]. Document Object Model FAQ. Dostupné z WWW: < World Wide Web Consortium (W3C)Extensible Markup Language (XML). [online] [cit ] Version 1.0, Fifth Edition, 26 November Dostupné z WWW: <

42 7 LITERATURA 42 Yahoo! Inc. Yahoo!. [online] c2010a. [cit ]. Company Overview. Dostupné z WWW: < Yahoo! Inc. Yahoo! Developer Network. [online] c2010b. [cit ]. BOSS API Guide. Dostupné z WWW: <

43 Přílohy

44 A PŘÍKLAD GETCAPABILITIES SOUBORU 44 A Příklad GetCapabilities souboru <?xml version="1.0" encoding="windows-1250" standalone="no"?> <WMT_MS_Capabilities version="1.1.1" updatesequence="0"> <Service> <Name>JMK:WMS-Digitalni UP</Name> <Title>JMK - Digitalni UP</Title> <Abstract></Abstract> <OnlineResource xlink:type="simple" xlink:href=" xmlns:xlink=" <ContactInformation> <ContactPersonPrimary> <ContactPerson>Ing. arch. Milan Pachta</ContactPerson> <ContactOrganization>Odbor uzemniho planovani a stavebniho radu Krajskeho uradu Jihomoravskeho kraje </ContactOrganization> </ContactPersonPrimary> <ContactPosition>architect</ContactPosition> <ContactAddress> <AddressType>postal</AddressType> <Address>Zerotinovo nam. 3/5</Address> <City>Brno</City> <StateOrProvince>Czech republic</stateorprovince> <PostCode>601 82</PostCode> <Country>Czech republic</country> </ContactAddress> <ContactVoiceTelephone> </ContactVoiceTelephone> <ContactElectronicMailAddress>PACHTA.MILAN@kr-jihomoravsky.cz </ContactElectronicMailAddress> </ContactInformation> <Fees>none</Fees> <AccessConstraints>none</AccessConstraints> </Service> <Capability> <Request> <GetCapabilities> <Format>application/vnd.ogc.wms_xml</Format> <DCPType> <HTTP> <Get> <OnlineResource xlink:type="simple" xlink:href= " &" xmlns:xlink="

45 A PŘÍKLAD GETCAPABILITIES SOUBORU 45 </Get> <Post> <OnlineResource xlink:type="simple" xlink:href= " &" xmlns:xlink=" </Post> </HTTP> </DCPType> </GetCapabilities> <GetMap> <Format>image/jpeg</Format> <Format>image/png</Format> <DCPType> <HTTP> <Get> <OnlineResource xlink:type="simple" xlink:href= " &" xmlns:xlink=" </Get> <Post> <OnlineResource xlink:type="simple" xlink:href= " &" xmlns:xlink=" </Post> </HTTP> </DCPType> </GetMap> </Request> <Exception> <Format>application/vnd.ogc.se_xml</Format> </Exception> <Layer> <Name>WMS JMK</Name> <Title>WMS JMK</Title> <LatLonBoundingBox minx="12" miny="48" maxx="19" maxy="51.5"/> <SRS>EPSG:102067</SRS> <SRS>EPSG:2065</SRS> <BoundingBox SRS="EPSG:102067" minx=" " miny=" " maxx=" " maxy=" "/> <Layer active="1"> <Title>Správní členění ČR</Title> <Layer queryable="1" active="1"> <Name>GP_KRAJ_JM</Name>

46 A PŘÍKLAD GETCAPABILITIES SOUBORU <Title>Jihomoravský kraj</title> <ScaleHint min="200000" max=" "/> <Style> <Name>default</Name> <Title>default</Title> <LegendURL width="16" height="14"> <Format>image/png</Format> <OnlineResource xlink:type="simple" xlink:href= " JM.png" xmlns:xlink=" </LegendURL> </Style> </Layer>

47 B UML DIAGRAM 47 B UML diagram Obr. 6: UML diagram tříd

48 C ZOBRAZENÍ TRANSFORMOVANÝCH GEODAT 48 C Zobrazení transformovaných geodat Obr. 7: KML soubor otevřený pomocí aplikace Google Earth

49 D VZHLED WEBOVÉ APLIKACE 49 D Vzhled webové aplikace Obr. 8: Úvodní stránka webové aplikace Obr. 9: Výpis seznamu zaindexovaných vrstev