VYSOKÁ ŠKOLA BÁ ŇSKÁ – TECHNICKÁ UNIVERZITA OSTRAVA

Hornicko-geologická fakulta

Institut geoinformatiky

DIPLOMOVÁ PRÁCE

Ostrava 2007 Roman Ožana

VYSOKÁ ŠKOLA BÁ ŇSKÁ – TECHNICKÁ UNIVERZITA OSTRAVA

Hornicko-geologická fakulta

Institut geoinformatiky

POSOUZENÍ VLASTNOSTÍ GEONETWORK OPENSOURCE A JEHO UPLATNITELNOSTI PRO

ÚČELY NÁRODNÍHO METAPORTÁLU

Diplomová práce

Autor: Roman Ožana Vedoucí diplomové práce: Doc. Dr. Ing. Bronislava Horáková

Ostrava 2007

Prohlašuji, že

− celou diplomovou (resp. bakalářskou) práci včetně příloh, jsem vypracoval samostatně a uvedl jsem všechny použité podklady a literaturu.

− jsem byl seznámen s tím, že na moji diplomovou (resp. bakalářskou) práci se plně vztahuje zákon č.121/2000 Sb. – autorský zákon, zejména § 35 – využití díla v rámci občanských a náboženských obřadů, v rámci školních představení a využití díla školního a § 60 – školní dílo.

− beru na vědomí, že Vysoká škola báňská – Technická univerzita Ostrava (dále jen VŠB-TUO) má právo nevýdělečně, ke své vnitřní potřebě, diplomovou (resp. bakalářskou) práci užít (§ 35 odst. 3).

− souhlasím s tím, že jeden výtisk diplomové (resp. bakalářské) práce bude uložen v Ústřední knihovně VŠB-TUO k prezenčnímu nahlédnutí a jeden výtisk bude uložen u vedoucího diplomové práce. Souhlasím s tím, že údaje o diplomové práci, obsažené v Záznamu o závěrečné práci, umístěném v příloze mé diplomové (resp. bakalářské) práce, budou zveřejněny v informačním systému VŠB-TUO.

− rovněž souhlasím s tím, že kompletní text diplomové (resp. bakalářské) práce bude publikován v materiálech zajišťujících propagaci VŠB-TUO, vč. příloh časopisů, sborníků z konferencí, seminářů apod. Publikování textu práce bude provedeno v omezeném rozlišení, které bude vhodné pouze pro čtení a neumožní tedy případnou transformaci textu a dalších součástí práce do podoby potřebné pro jejich další elektronické zpracování.

− bylo sjednáno, že s VŠB-TUO, v případě zájmu z její strany, uzavřu licenční smlouvu s oprávněním užít dílo v rozsahu § 12 odst. 4 autorského zákona.

− bylo sjednáno, že užít své dílo – diplomovou (resp. bakalářskou) práci nebo poskytnout licenci k jejímu využití mohu jen se souhlasem VŠB-TUO, která je oprávněna v takovém případě ode mne požadovat přiměřený příspěvek na úhradu nákladů, které byly VŠB-TUO na vytvoření díla vynaloženy (až do jejich skutečné výše). V Ostravě dne 20.4.2007 Roman Ožana plné jméno autora podpis autora Adresa trvalého pobytu diplomanta Lukavec 115 742 46 okr. Nový Jičín

Anotace

Jméno a příjmení autora: Roman Ožana

Název instituce: Institut geoinformatiky, VŠB-TU Ostrava

Název práce: Posouzení vlastností GeoNetwork opensource

a jeho uplatnitelnosti pro účely národního metaPortálu

Vedoucí práce: Doc. Dr. Ing. Bronislava Horáková

Konzultant: Ing. Jan Růžička, Ph.D.

Počet stran: 70

Počet příloh: 11

Tato diplomová práce se zabývá posouzením uplatnitelnosti GeoNetwork opensource pro

účely národního metaportálu. Hlavním cílem je pospat funkčnost GeoNetwork opensource

s důrazem na použité technologie a standardy. Pozornost je věnována také možnostem

uživatelského přizpůsobení GeoNetwork a komunikačnímu rozhraní. Dále se práce věnuje

popisu současného stavu technologii podporující komunikaci mezi katalogy. Závěr práce

popisuje komunikační rozhraní systémů GeoNetwork a MIcKA.

Klíčová slova:

Metadata, GeoNetwork, CSW, Catalogue, Catalog Services, Web Services, ISO 19115, ISO

19139, Dublin Core, Open source, SDI, Spatial Data Infrastructure, Jeeves, Java, UNSDI,

FAO

Annotation

Author name: Roman Ožana

Name of institution: Geoinformatics Institute, VŠB–TU Ostrava

Thesis name: Evaluation of GeoNetwork Opensource Features and

Suitability for National Metaportal Design

Thesis leader: Doc. Dr. Ing. Bronislava Horáková

Consultant: Ing. Jan Růžička, Ph.D.

Pages: 70

Annexes: 11

This diploma thesis investigates suitability of GeoNetwork opensource for National

Metaportal Design. The main objective is to describe GeoNetwork opensource functionality

stressing the technologies and standards usage. The attention is also dedicate to user

customization possibilities and to GeoNetwork communication interface. Furthermore the

thesis describes current technologies, which support communication among catalogues. The

thesis conclusion emphasize the communication interface between GeoNetwork and MIcKA

briefly.

Keywords:

Metadata, GeoNetwork, CSW, Catalogue, Catalog Services, Web Services, ISO 19115, ISO

19139, Dublin Core, Open source, SDI, Spatial Data Infrastructure, Jeeves, Java, UNSDI,

FAO

Obsah

SEZNAM ZKRATEK................................................................................................................. I

ÚVOD .......................................................................................................................................... 1

1 ZÁKLADNÍ PRVKY METAINFORMA ČNÍ INFRASTRUKTURY.............................. 2

1.1 METADATA ......................................................................................................................... 2 1.1.1 Klasifikace metadat.................................................................................................... 3 1.1.2 Metadata informačních zdrojů (Dublin Core) ........................................................... 4 1.1.3 Metadata geodat (ISO 19115).................................................................................... 5

1.2 KATALOG ............................................................................................................................ 5 1.3 METAINFORMAČNÍ SYSTÉM................................................................................................. 6

1.3.1 Klasifikace metainformačních systémů ...................................................................... 7 1.4 METAINFORMAČNÍ PORTÁL (METAPORTÁL) ........................................................................ 8

1.4.1 Klasifikace metaportálu ............................................................................................. 8 1.4.2 Národní metaportál.................................................................................................... 9 1.4.3 Nadnárodní metaportál.............................................................................................. 9

1.5 GEOPORTÁL...................................................................................................................... 10

2 TECHNOLOGIE PRO BUDOVÁNÍ METAINFORMA ČNÍ INFRASTRUKTURY .. 11

2.1 ARCHITEKTURA ORIENTOVANÁ NA SLUŽBY ...................................................................... 11 2.2 WEBOVÉ SLUŽBY.............................................................................................................. 11 2.3 OGC WEB SERVICES........................................................................................................ 12

2.3.1 Volání operací a předávání parametrů.................................................................... 13 2.4 DISTRIBUOVANÁ ARCHITEKTURA GEOPORTÁLU................................................................ 14

2.4.1 Portálové služby (Portal Services)........................................................................... 15 2.4.2 Zobrazovací služby (Portrayal Services) ................................................................. 15 2.4.3 Katalogové služby (Catalogue Services).................................................................. 16 2.4.4 Datové služby (Data Services) ................................................................................. 16

2.5 ZNAČKOVACÍ JAZYKY ....................................................................................................... 16 2.5.1 HTML....................................................................................................................... 16 2.5.2 XML.......................................................................................................................... 16 2.5.3 Vybrané značkovací jazyky založené na XML.......................................................... 17

3 PROJEKT BUDOVÁNÍ UNSDI ........................................................................................ 18

3.1 UNGIWG......................................................................................................................... 18 3.2 UNSDI ............................................................................................................................. 19

3.2.1 Zapojení České republiky do budování UNSDI ....................................................... 19

4 CHARAKTERISTIKA GEONETWORK ......................... ............................................... 20

4.1 PŘEHLED ZÁKLADNÍCH SCHOPNOSTÍ SYSTÉMU GEONETWORK......................................... 21 4.2 ARCHITEKTURA GEONETWORK........................................................................................ 22 4.3 VERZOVÁNÍ GEONETWORK .............................................................................................. 22 4.4 DISTRIBUCE GEONETWORK.............................................................................................. 23

4.4.1 Stažení aktuálních zdrojových kódů ......................................................................... 23 4.4.2 Instalační balíček GeoNetwork................................................................................ 23

4.5 POŽADAVKY GEONETWORK NA SYSTÉM.......................................................................... 24

5 ANALÝZA TECHNOLOGIÍ VYUŽÍVANÝCH V GEONETWORK....... .................... 25

5.1 PLATFORMA JAVA ............................................................................................................. 25 5.1.1 Java Development Kit (JDK) ................................................................................... 25 5.1.2 Java Runtime Environment (JRE)............................................................................ 25 5.1.3 Java database conectivity (JDBC)........................................................................... 26 5.1.4 Zhodnocení platformy Java...................................................................................... 26

5.2 JAVA ENTERPRISE EDITION (JAVA EE) ............................................................................. 27 5.2.1 Technologie Java servlet.......................................................................................... 27 5.2.2 Zhodnocení technologie Java Servlet ...................................................................... 28

5.3 KOMPILOVÁNÍ JAVA SERVLETŮ - APACHE ANT............................................................... 28 5.3.1 Zhodnocení Apache ANT.......................................................................................... 29

5.4 SPOUŠTĚNÍ JAVA SERVLETŮ ............................................................................................. 29 5.4.1 Apache Tomcat server.............................................................................................. 29 5.4.2 Jetty server ............................................................................................................... 30 5.4.3 Zhodnocení testovaných aplikačních serverů .......................................................... 30

5.5 SYSTÉM JEEVES................................................................................................................ 30 5.5.1 Architektura systému Jeeves .................................................................................... 31 5.5.2 Jeeves a podpora vícejazyčných aplikací................................................................. 32 5.5.3 Zhodnocení systému Jeeves...................................................................................... 32

5.6 GEONETWORK A DBMS................................................................................................... 33 5.6.1 McKoi SQL............................................................................................................... 33 5.6.2 Způsob uložení metadat ........................................................................................... 33 5.6.3 Zhodnocení vztahu GeoNetwork a DBMS................................................................ 34

5.7 INDEXAČNÍ NÁSTROJ APACHE LUCENE............................................................................. 34 5.7.1 Vyhledávací schopnosti Apache Lucene .................................................................. 35 5.7.2 Zhodnocení Apache Lucene ..................................................................................... 35

5.8 DALŠÍ KNIHOVNY VYUŽÍVANÉ APLIKACÍ GEONETWORK...................................................36 5.9 ZÁVĚREČNÍ SHRNUTÍ......................................................................................................... 36

6 POPIS FUNKČNOST SYTÉMU GEONETWORK ........................................................ 37

6.1 VYHLEDÁVÁNÍ METADAT .................................................................................................. 37 6.1.1 Lokální vyhledávání ................................................................................................. 37 6.1.2 Vzdálené vyhledávání............................................................................................... 38 6.1.3 Zhodnocení funkce vyhledávání metadat ................................................................. 39

6.2 PROHLÍŽENÍ A STAHOVÁNÍ METADAT ................................................................................ 39 6.2.1 Prohlížení metadat ................................................................................................... 39 6.2.2 Stahování metadat.................................................................................................... 40 6.2.3 Zhodnocení funkce prohlížení metadat .................................................................... 40

6.3 VYTVÁŘENÍ METADAT ......................................................................................................41 6.3.1 Nová metadata ......................................................................................................... 41 6.3.2 Zhodnocení vytváření nových metadat..................................................................... 41 6.3.3 Vytváření metadat na základě XML ......................................................................... 44 6.3.4 Zhodnocení vytváření metadat na základě XML...................................................... 44

6.4 HROMADNÉ VYTVÁŘENÍ METADAT ................................................................................... 44 6.4.1 Harvesting metadat .................................................................................................. 45 6.4.2 Dávkový import metadat .......................................................................................... 46 6.4.3 Zhodnocení hromadného vkládání metadat ............................................................. 46

6.5 ADMINISTRACE SYSTÉMU GEONETWORK......................................................................... 46

6.5.1 Správa kategorii ....................................................................................................... 46 6.5.2 Správa pracovních skupin........................................................................................ 47 6.5.3 Správa uživatelských účtů ........................................................................................ 47 6.5.4 Zhodnocení administrace systému GeoNetwork ......................................................48

6.6 ZÁVĚREČNÉ SHRNUTÍ........................................................................................................ 48

7 ÚPRAVA UŽIVATELSKÉHO ROZHRANÍ GEONETWORK ........... ......................... 49

7.1 ÚPRAVA VZHLEDU GEONETWORK.................................................................................... 49 7.2 LOKALIZACE GEONETWORK DO NÁRODNÍHO PROSTŘEDÍ ................................................. 49 7.3 PŘIDÁNÍ STATICKÉ INTERNETOVÉ STRÁNKY...................................................................... 50 7.4 ROZŠÍŘENÍ FUNKCIONALITY GEONETWORK...................................................................... 51 7.5 ZÁVĚREČNÉ SHRNUTÍ........................................................................................................ 52

8 SOUČASNÉ MOŽNOSTI KOMUNIKACE KATALOG Ů ............................................ 53

8.1 STANDARD ANSI/NISO Z39.50 – ISO 23950 .................................................................. 53 8.2 KATALOGOVÉ SLUŽBY ......................................................................................................53

8.2.1 Architektura katalogových služeb ............................................................................ 54 8.2.2 Abstraktní model rozhraní katalogových služeb...................................................... 54

8.3 KATALOGOVÉ SLUŽBY A PODPORA INTEROPERABILITY..................................................... 55 8.3.1 Core queryable properties ....................................................................................... 55 8.3.2 CQL.......................................................................................................................... 55 8.3.3 Core returnable properties ...................................................................................... 56

8.4 KATALOGOVÉ SLUŽBY PRO WEB (CSW) ........................................................................... 56 8.4.1 Operace GetCapabilities.......................................................................................... 57 8.4.2 Operace DescribeRecord ......................................................................................... 57 8.4.3 Operace GetDomain ................................................................................................ 57 8.4.4 Operace GetRecords ................................................................................................ 57 8.4.5 Operace GetrecordById ........................................................................................... 58 8.4.6 Operace Transaction................................................................................................ 58 8.4.7 Operace Harvest ...................................................................................................... 59 8.4.8 Zhodnocení CSW...................................................................................................... 59

8.5 ZÁVĚREČNÉ SHRNUTÍ........................................................................................................ 59

9 KOMUNIKA ČNÍ ROZHRANÍ GEONETWORK........................................................... 60

9.1 IMPLEMENTACE CSW V GEONETWORK ........................................................................... 60 9.1.1 Způsob testování implementace CSW ...................................................................... 61 9.1.2 Zhodnocení implementace CSW............................................................................... 62

9.2 KATALOGOVÉ SLUŽBY 1.0 ................................................................................................ 62 9.2.1 Zhodnocení implementace katalogových služeb 1.0 ................................................ 63

9.3 HARVESTING GEONETWORK ............................................................................................ 63 9.3.1 Zhodnocení harvestingu GeoNetwork...................................................................... 63

9.4 RSS A GEORSS ................................................................................................................ 64 9.5 ZÁVĚREČNÉ SHRNUTÍ........................................................................................................ 64

10 ZHODNOCENÍ GEONETWORK .................................................................................... 65

10.1 POŽADAVKY NA UŽIVATELE GEONETWORK ................................................................... 65 10.2 UŽIVATELSKÁ PODPORA GEONETWORK A DOKUMENTACE............................................. 65 10.3 INSTALACE GEONETWORK ............................................................................................. 66

10.4 PROVOZ GEONETWORK.................................................................................................. 66 10.5 DODRŽOVÁNÍ STANDARDŮ A NOREM .............................................................................. 66 10.6 POUŽITÉ TECHNOLOGIE................................................................................................... 66 10.7 FUNKCIONALITA SYSTÉMU .............................................................................................. 67

10.7.1 Nastavení systému .................................................................................................. 67 10.8 ÚPRAVA UŽIVATELSKÉHO ROZHRANÍ A ROZŠIŘITELNOST................................................ 67 10.9 KOMUNIKAČNÍ ROZHRANÍ............................................................................................... 68 10.10 CENA GEONETWORK.................................................................................................... 68

11 SPOLUPRÁCE SYSTÉMŮ GEONETWORK A MICKA.............................................. 69

11.1 CHARAKTERISTIKA SYSTÉMU MICKA ............................................................................ 69 11.2 PROPOJENÍ SYSTÉMŮ GEONETWORK A MICKA.............................................................. 69

ZÁVĚR ...................................................................................................................................... 70

SEZNAM INFORMA ČNÍCH ZDROJŮ................................................................................. II

SEZNAM OBRÁZK Ů..............................................................................................................III

SEZNAM TABULEK .............................................................................................................. IV

SEZNAM PŘÍLOH ....................................................................................................................V

Seznam zkratek

České zkratky

ČNI Český Normalizační Institut OS Operační systém TNK Technická normalizační komise

Cizojazyčné zkratky

ANSI American National Standards Institute API Application Program Interface CEN Committee for European Normalization CORBA Common Object Request Broker Architecture CQL Common Query Language CS Catalogue services CSS Cascading Style Sheets CSW Catalogue services for Web CVS Concurrent Versions System DBMS Database Management System. DTD Document Type Definition EN European norm FAO Food and Agriculture Organization of the United Nations FGDC US Federal Geographic Data Committee FTP File Transfer Protocol GPL General Public Licence. HTML HyperText Markup Language HTTP Hyper Text Transfer Protocol IIOP Internet Inter-ORB Protocol INSPIRE The INfrastructure for SPatial InfoRmation in Europe ISO International Standards Organization JAXP Java API for XML JDBC Java Database Connectivity JDK Java Development Kit JEEVES Java Easy Engine for Very Effective Systems JRE Java Runtime Environment JVM Java Virtual Machine KVP keyword-value pair NISO National Information Standards Organization OGC Open Geospatial Consortium OWS OGC Web Servcies RSS Rich Site Summary SDI Spatial Data Infrastructure SGML Standard Generalized Markup Language

SMTP Simple Mail Transfer Protocol SOA Service Oriented Architecture SOAP Simple Object Access Protocol SQL Structured Query Language TC Technical Committee UDDI Universal Description Discovery and Integration UML Unified Modelling Language UNGIWG United Nations Geospatial Information Working Group UNSDI United Nations Spatial Data Infrastructure UUID Universally Unique Identifie W3C World Wide Web Consortium WCS Web Coverage Service WFS Web Feature Service WMS Web Mapping Service WSDL Web Services Description Language XML Extensible Markup Language XSD XML schema XSL Extensible Stylesheet Language

1

Úvod

Informace se staly jedním z nejdůležitějších artiklů současnosti. Hrají klíčovou roli

v rozhodovacím procesu. Jejich nedostatek zvyšuje riziko špatného rozhodnutí. Dalo by se

předpokládat, že pro snížení tohoto rizika postačí pouze získat větší množství informací.

Jenže ani větší množství informací nám nedává záruku toho, že rozhodneme správně.

Nezřídka se stává, že velké množství informací vede k informačnímu zahlcení. Ukazuje se,

že kvalita informací je mnohem důležitější, než jejich množství.

Správná rozhodnutí je možné přijímat pouze na základě optimálního množství kvalitních

informací, ty je možné získat zpracováním kvalitních informačních zdrojů. Jedním z těchto

kvalitních informačních zdrojů, by se do budoucna měl stát národní metainformační portál

(metaportálu).

Národní metaportál by měl tvořit jeden ze stěžejních pilířů národní geoinformační

infrastruktury České republiky. Měl by zjednodušit, urychlit a tím také zlevnit vyhledávání

geoinformačních zdrojů dostupných v rámci státu. Národní metaportál by měl být začleněn do

rozsáhlé metainformační sítě, budované v rámci geoinformační infrastruktury Spojených

národů. Národní metaportál by také měl reagovat na požadavky definované v rámci směrnice

Evropského společenství INSPIRE.

Hlavním cílem této práce je posoudit uplatnitelnost GeoNetwork opensource (dále jen

GeoNetwork) pro účely budování národního metaportálu. Proč právě GeoNetwork? Tento

systém by se měl do budoucna stát stěžejním pro správu, sdílení, uchovávání a prezentování

metadat v rámci geoinformační infrastruktury Spojených národů.

Tato diplomová práce analyzuje a popisuje GeoNetwork z hlediska použitých

a podporovaných technologii, standardů a funkčnosti systému. V neposlední řadě tato práce

zkoumá a popisuje možnosti úprav a přizpůsobení uživatelského rozhraní GeoNetwork.

Závěrem se diplomová práce zabývá analýzou současného stavu technologii,

podporujících komunikaci mezi metainformačními systémy potažmo katalogy a implementací

těchto technologii v GeoNetwork. Zvýšený důraz je kladen zejména na implementaci

katalogových služeb OGC. Schopnosti katalogových služeb OGC jsou následně ověřeny

prakticky ve spolupráci se systémem MIcKA.

Veškeré informace uvedené v této diplomové práci se týkají systému

GeoNetwork 2.1 alfa 1, případně GeoNetwork 2.1 alfa 2, není-li uvedeno jinak.

2

1 Základní prvky metainforma ční infrastruktury

Tato kapitola popisuje základní prvky metainformační infrastruktury. Vysvětluje pojem

metadata, katalog, metainformační systém, metainformační portál a geoportál.

1.1 Metadata

Pojem metadata je možné definovat různými způsoby. Zjednodušující, avšak běžně

používaná definice definuje metadata, jako (strukturovaná) data o datech.

Metadata lze považovat za celkový souhrn údajů, které je možné přiřadit abstraktnímu,

nebo reálnému objektu. Obecně je možné pomocí metadat popsat libovolný objekt, proces

nebo jev, nemusí se tedy nutně jednat jen o data.

Je zřejmé, že metadata nacházejí uplatnění v celé řadě oborů a lidských činností

(knihovnictví, zábavný průmysl, Internet). Výjimkou není ani oblast geoinformatiky. (viz.

kap. 1.1.3) [27].

Na metadata jsou kladeny různé požadavky. Ve zkratce zde uvádím některé z těchto

požadavků. Metadata by měla dle [44] a [27]:

� vyjadřovat co nejaktuálnější stav popisovaného objektu,

� napomoci k pochopení funkce a obsahu popisovaného objektu,

� být přesná a konzistentní,

� tvořit nedílný logický celek s popisovaným objektem,

� napomáhat při vyhledávání objektů dle různých parametrů,

� usnadnit porovnávání popisovaných objektů,

� být zapsána formalizovaným způsobem vhodným pro komunikaci, interpretaci

a zpracování,

� usnadnit efektivní sdílení a výměnu informací o popisovaném objektu.

Ve výsledku by měla být kvalitní metadata jedním z hlavních podkladů, při rozhodování

o využití popisovaného zdroje [44], [27].

V současné době jsou metadata pořizovány především v souvislosti s elektronickými

zdroji. Sledovaným objektem je pak tzv. informační zdroj. Metadata vztažená k tomuto

informačnímu zdroji popisují [27]:

� Charakter a obsah – popisují informační zdroj co do obsahu a charakteru,

� Kontext – udává aspekty spojené s vytvořením informačního zdroje,

� Strukturu – charakterizuje vnitřní a vnější vztahy mezi informačními zdroji.

3

Metadata nepopisují jen vnější znaky informačního objektu, ale také jeho chování

a vazby k jiným objektům. Dále popisují, jakým způsobem může být informační zdroj

využíván a spravován [27].

Aby mohla být metadata efektivně využívána, je potřeba stanovit jednotnou formu

metadat a způsob jejich pořizování, to vytváří prostor pro standardy, normy, vyhlášky

a legislativu [44].

1.1.1 Klasifikace metadat

Metadata je možné klasifikovat na základě celé řady charakteristik, například z hlediska

vazby na informační zdroj je možné rozlišit vložená metadata a samostatná metadata.

Vložená metadata jsou pevnou součástí popisovaného zdroje a metadata samostatná jsou

uchovávána nezávisle na popisovaném zdroji [27].

Hledisko vazby na informační zdroj je jen jedno z mnoha hledisek, na základě kterého

je možné metadata klasifikovat. Další hlediska jsou dle [27] například:

� Zdroje metadat – rozlišujeme interní nebo externí zdroje metadat, interní jsou

generovány zpravidla současně se vnikem informačního zdroje, zatímco externí

jsou vytvářeny dodatečně;

� Metody tvorby metadat – rozlišujeme metadata generována automatizovaně nebo

manuálně (manuálně rozumějme člověkem);

� Povahy metadat – metadata mohou být vytvářená laikem nebo expertem v oblast

metadat, případně expertem na popisovanou problematiku;

� Charakteru metadat – rozlišujeme metadata statického nebo dynamického

charakteru, metadata dynamického charakteru se mohou měnit v průběhu života

informačního objektu;

� Životnosti metadat – dle životnosti dělíme metadata na dlouhodobá nebo

krátkodobá, dlouhodobá metadata jsou důležitá pro zajištění přístupnosti

informačního zdroje (přístupová práva, technický formát apod.);

� Struktury metadat – rozlišujeme strukturována a nestrukturována metadata,

nestrukturované neodpovídají standardizovaným strukturám, jsou to například

poznámky, nebo anotace;

� Sémantiky metadat – dle sémantiky dělíme metadata na kontrolovaná

a nekontrolovaná, kontrolována odpovídají standardizovaným slovníkům, nebo

autorizovaným formátům;

4

� Úrovně metadat – zde dělíme metadata na metadata vztažená ke kolekci, nebo

k individuálním informačnímu objektu.

Metadata je možné klasifikovat, dle jejich obsahu na:

� Administrativní metadata – jsou používané pro řízení a správu informačních

zdrojů, identifikují zdroj (např. název) a také informují o jeho umístění;

� Archivační metadata – se vztahují k procesu dlouhodobé archivace digitálního

informačního zdroje, měla by zajistit trvalou integritu a kontext dokumentu,

pro jeho zpřístupnění v budoucnosti;

� Metadata pro právní nároky – dokumentují právní nároky k popisovanému

informačnímu objektu, popisují podmínky přístupu ke zdroji a podobně;

� Metadata pro užití – charakterizují informační zdroj tak, aby bylo možné

porozumět jeho obsahu, podporují vyhledávání popisovaného zdroje;

� Technická metadata – jsou vytvářena pro počítačový systém, nebo jsou vytvářena

počítačovým systémem, popisují jak se systém chová a co požaduje pro svůj

provoz;

� Strukturální metadata – definuji vnitřní organizaci objektu, jsou nezbytná pro

zobrazení a navigaci tohoto objektu.

Nejobecněji je možné jakákoliv metadata rozčlenit do čtyř základních skupin na:

� Syntaktická metadata – zde řadíme metadata poskytující podrobné informace

o informačních objektech (např. název, datum vytvoření a podobně);

� Strukturální metadata – jsou zaměřena na strukturu informačního objektu

(dokumentu), zjednodušují vyhledávání informací;

� Sémantická metadata – popisují kontextově relevantní informace, soustředí se na

doménově specifické elementy, jsou srozumitelné uživatelům, pohybujícím se

v dané doméně;

� Ontologie – představují nejvyšší formu metadat, umožňují homogenizovat

metadata nižších úrovní, definují jednotné chápání pojmů.

V běžné praxi jsou dnes využívána zejména syntaktická metadata. Tato metadata jsou

často předmětem katalogizace. Ukládají se v tzv. katalogu (viz. kap. 1.2) [27].

1.1.2 Metadata informačních zdrojů (Dublin Core)

Pro popis informačních zdrojů, existuje celá řada standardů. Jejich přehled je uveden

například v [27]. Klíčovou roli mezi těmito standardy hraje standard Dublin Core.

5

Dublin Core je standard, který vytváří základní rámec pro popis libovolného informačního

zdroje. Je to obecné doporučení toho, co by měl obsahovat každý metadatový záznam. Slouží

pro zajištění interoperability metadat mezi doménovými oblastmi. Standard Dublin Core

může být pro specifické účely rozšiřován. V roce 2003 se stal standard Dublin Core

mezinárodní normou ISO 15836 [18], [27], [56].

1.1.3 Metadata geodat (ISO 19115)

Jak již bylo řečeno, metadata je možné pořídit k libovolnému informačnímu zdroji. Tímto

informačním zdrojem mohou být samozřejmě také geoinformační zdroje.

Standardizací na poli metadat v geoinformatice se zabývají technické komise národních

a nadnárodních standardizačních organizací. Jsou to tyto:

� ISO/TC 211 Geographic information/Geomatics [32] na nadnárodní úrovni,

� CEN/TC 287 Geographic information [14] na úrovni Evropské unie a

� TNK 122 Geografická informace/Geomatika [16] na České národní úrovni.

Na základě činnosti ISO/TC 211 byla v roce 2003 přijata norma ISO 19115:2003

Geographic Information-Metadata. V roce 2005 byla tato norma transponována do

normalizační soustavy Evropské unie, jako EN ISO 19115:2005, a následně byla přijata

členskými státy Evropské unie [27].

Úkolem této normy je poskytnout strukturu metadat především pro digitální geografická

data, avšak v zásadě je možné normu použít také pro popis analogových nebo neprostorových

dat.

Na normu EN ISO 19115:2005 by měla v roce 2007 navázat norma Geographic

information – Metadata -- XML schema implementation ISO 19139 [32].

1.2 Katalog

Katalog je dle [11] kolekce popisných informací (metadat) o informačních zdrojích. Je

řízen metainformačním systémem (viz. kap. 1.3) a typicky umožňuje tyto funkcionality [11]:

� Registrace (přidávání) popisných informací do kolekce;

� Procházení popisných informací, uchovávaných v kolekci;

� Správa popisných informací uložených v kolekci.

Katalog by měl být schopen uchovat velké množství popisných informací, které nemusí

nutně odpovídat pouze jediné normě, nebo standardu.

6

1.3 Metainformační systém

Metainformační systém je systém, který umožňuje uložit, organizovat, publikovat

a spravovat metadata. Metainformační systém by měl dle [56] umožňovat:

� Vyhledávání metadata – např. dle specifikovaných podmínek: název, klíčová

slova, popis, plošné pokrytí atd.;

� Zobrazení metadat – ve smyslu prohlížení metadatových záznamů;

� Editaci metadat – editace metadatového záznamu včetně prvotního pořízení;

� Import/export metadat;

� Uložení metadat – zahrnuje např. zálohování, uložení, archivaci;

� Administraci systému a metadat – zahrnuje také administraci přístupových práv

k metadatům;

� Podporu uživatelů – zahrnuje nápovědu, dokumentaci a podobně;

Obr. 1 Struktura metainformačního systému [56]

Klíčovou funkcí metainformačního systému je vyhledávání metadat. Popisují-li metadata

prostorová data je důležité umožnit uživateli vyhledávání nejen podle tzv. klíčových slov,

ale také podle prostorového umístění popisovaných dat.

Metainformační systém by měl být dostatečně otevřený a přístupný. Na druhou stranu

by měl umožňovat dostatečné zabezpečení metadat, proti neautorizovanému přístupu,

zobrazení, editaci či jiným formám zneužití. Otevřenost metainformačního systému by měla

spočívat také v možnosti importovat, exportovat a spravovat metadata, odpovídající různým

metadatovým standardům. Základem metainformačních systémů je dnes nejčastěji DBMS,

který se stará o uchovávání a správu veškerých spravovaných metadat [56].

Editace (vstup, odstranění) metadat

Import/export metadat

Administrace Zabezpečení

Uložení metadat

Vyhledávání metadat

Zobrazení metadat

Podpora uživatelů (nápověda, dokumentace)

Met

ain

form

ačn

í sys

tém

7

1.3.1 Klasifikace metainformačních systémů

Metainformační systémy je možné, obdobně jako metadata, klasifikovat dle různých

kritérií. Jedním z těchto kritérií, může být například zodpovědnost za obsah

metainformačního systému. Rozlišujeme metainformační systémy:

� za jejichž obsah zodpovídají autoři metadat,

� za jejichž obsah zodpovídá provozovatel,

� případně kombinované (hybridní), zodpovědnost za obsah se dělí mezi autory

metadat a provozovatele.

Dle charakteru je možné metainformační systémy rozčlenit na:

� veřejné – poskytují svoji funkcionalitu široké veřejnosti, například

prostřednictvím Internetu;

� neveřejné – jsou určené pouze vybranému okruhu uživatel.

Cílem veřejných metainformačních systémů je poskytnout co nejširšímu počtu uživatelů

požadované informace, týkající se existujících datových sad geodat a případně

i zprostředkovat jejich nákup, či přístup k souvisejícím aplikacím, nebo službám.

Podle charakteru obsahu je možno metainformační systémy dle [56] rozdělit na:

� Podnikové

� Oborové (tématické)

� Národní

� Nadnárodní

Podnikové metainformační systémy, nebo též podnikové encyklopedie mají zpravidla

neveřejný charakter. Tyto systémy se zabývají se správou vnitropodnikových dat a metadat.

Oborové metainformační systémy jsou specifickou skupinou, zabývají se metadata

určenými pro určitý vymezený obor. Bývají obvykle také veřejnými metainformačními

systémy.

Národní metainformační systémy shromaždují a prezentují metadata o datových sadách

různého charakteru. Obvykle tyto systémy shromaždují pouze základní metadata a snaží se

spíše o podchycení vybraných významných informačních zdrojů. U těchto systému hraje

zásadní roli podstata veřejného charakteru.

Nadnárodní metainformační systémy mají podobný charakter jako národní

metainformační systémy, avšak spravují rozsáhlejší území přesahující hranice státu [56].

8

1.4 Metainformační portál (metaportál)

Určit hranici mezi metaportálem a metainformačním systémem je v některých případech

velmi obtížné. Celá řada metainformačních systémů vykonává také funkci metaportálu.

Obr. 2 Vztah metainformačních systémů a metaportálu (zpracováno dle [56])

Metaportál představuje nástroj pro uživatele, který jednotným způsobem zpřístupňuje

metadata z více metainformačních systémů. Jedná se tedy o uživatelské rozhraní, které

zastřešuje více metainformačních systémů a umožňuje uživateli vyhledávat v těchto

systémech s využitím jednoho rozhraní. Často je metaportál konstruován tak, že nezkušený

uživatel ani nepozná, že vyhledává v různých metainformačních systémech.

Metadata prezentovaná uživatelům jsou spravována v několika různých metainformačních

systémech. Databáze metaportálu pak obsahuje jen potřebné minimum údajů o datových

sadách a připojených metainformačních systémech, tak aby mohl efektivním způsobem

provést vyhledání datových sad dle požadavku uživatele. Vyhledání může probíhat různými

způsoby a struktura dat v databázi metainformačního portálu může být také různá.

Cílem metaportálu je především zjednodušit přístup k metadatům a zpříjemnit, a také

zlevnit pro uživatele vyhledávání datových zdrojů [56].

1.4.1 Klasifikace metaportálu

Budování metaportálu zpravidla úzce souvisí s budování geoinformačních infrastruktur.

U geoinformačních infrastruktur je možné rozlišit, dle jejich rozsahu, tyto základní úrovně:

� Globální

� Regionální

Metainformační portál

Základní metadata

Základní metadata

Základní metadata

Metainformační systém

Metainformační systém

Metainformační systém

Uživatel

9

� Evropská

� Národní

� Lokální

Avšak metaportály postačí klasifikovat dle spravovaného území na:

� Národní metaportály a

� Nadnárodní metaportály

1.4.2 Národní metaportál

Národní metaportál zpravidla vytváří komplexní přehled o podstatných informačních

zdrojích, dostupných v daném státě. Eviduje, zpřístupňuje a spravuje metadata týkající se jak

území celého státu, tak i jeho částí. Obvykle o informačních zdrojích uchovává pouze

základní metadata. Pro evidované informační zdroje je charakteristická značná různorodost.

Provozovatelem národního metaportálu je obvykle nezávislá skupina (či organizace), která

je financovaná z veřejných prostředků, nebo grantů. Tento stav se do budoucna změní

v souvislosti se směrnicí INSPIRE [56], [30].

Národní metaportál by měl:

� respektovat obecně uznávané mezinárodní standardy na poli metadat,

� mít lokalizované komunikační rozhraní (v národním jazyce),

� umožňovat vzdálený přístup k metadatům uloženým v katalogu,

� mít garantovaný obsah katalogu,

� umožnit import a export metadat odpovídajícím jak národním tak mezinárodním

standardům,

� být schopen interoperability s nadnárodními metaportály.

1.4.3 Nadnárodní metaportál

Nadnárodní metaportál eviduje informační zdroje, které svým rozsahem přesahují hranice

států. Pro evidované informační zdroje je rovněž charakteristická značná různorodost.

Nadnárodní metaportál je určen ke správě mnohem většího území, než národní metaportál

[56].

Mezi uživateli nadnárodního metaportálu navíc existují kulturní, jazykové a technologické

rozdíly. Tyto rozdíly kladou na nadnárodní metaportál specifické nároky.

10

S ohledem na dobrou přístupnost nadnárodního metaportálu, je nutné zajistit podporu

národních jazyků všech zúčastněných států. Podpora národních jazyků se týká také

evidovaných informací (metadat).

Je tedy žádoucí vytvořit, případně zvolit takový systém, který je schopen všechny tyto

požadavky uspokojit. Z toho plyne, že je nutné použít pro uchovávání informací o zdrojích

standardizovaný, všeobecně uznávaný, výměnný formát metadat. Tento výměnný formát musí

být uzpůsoben pro uchovávání nejen jazykově různorodých dat.

Další nezbytnou vlastností nadnárodní metaportálu, by měla být dobrá propojitelnost

(interoperabilita) s jinými systémy. Nutnost interoperability klade požadavky jak na

nadnárodní metaportál tak na veškeré ostatní zúčastněné systémy.

1.5 Geoportál

Určit hranici mezi metaportálem a geoportálem je velmi obtížné, ne-li nemožné. Geoportál

je jednotnou vstupní branou, která umožňuje publikování a sdílení geografických dat,

metadata a služeb. Geoportál tyto data přímo neukládá, ale eviduje o nich pouze základní

informace tak, aby byl schopen zprostředkovat vazbu mezi uživatelem a původním zdrojem

[47], [19].

Geoportál nabízí svoji funkcionalitu nejčastěji prostřednictvím sítě Internet. Příkladem

takovéhoto geoportálu je [19], který z pohledu běžného uživatele umožňuje:

� Publikovat vlastní informační zdroj,

� Vyhledávání dat, metadat, služeb případně dalších geoportálů,

� Zobrazování a vytváření map.

Distribuovaná architektura geoportálu je popsána v kapitole č. 2.4.

11

2 Technologie pro budování metainforma ční infrastruktury

Tato kapitola popisuje vybrané technologie, využívané při budování metainformační

infrastruktury.

2.1 Architektura orientovaná na služby

SOA je návrhový styl software, který umožňuje poskytovat funkcionalitu aplikace,

v podobě nezávislých služeb, prostřednictvím sítě (pozn. definici SOA uvádí [49]). SOA

umožňuje vzájemně propojit dva nezávislé systémy, poskytovatele služby (service provider)

a uživatel služby (service consumer) [80], [73].

Obr. 3 Schéma SOA, vztah poskytovatele a uživatele služby (zpracováno dle [73] a [80])

Služba je schopná reagovat na zasílané požadavky (service request) generováním

odpovědi (service response). Uživatel služby (service consumer) vnímá službu jako „černou

skříňku“, s pevně definovaným vstupním a výstupním rozhraním a popsanou funkcionalitou.

Díky SOA je možné dosáhnout mnohem větší otevřenosti a přístupnosti systému, při

zachování stávající bezpečnosti vnitřního systému. Poskytovatel má plnou kontrolu nad

zveřejněnými službami. Jednou z implementací SOA jsou například webové služby (viz. kap.

2.2) [80], [49], [73].

2.2 Webové služby

Webové služby (web services), je možno definovat jako množinu vzájemně provázaných

technologii, které umožňují komunikaci systémů prostřednictvím sítě (nejčastěji je touto sítí

Internet). Webové služby jsou specifikovány organizací W3C [75].

Přenosové médium (síť)

Uži

vate

l slu

žby

serv

ice c

on

sum

er

Poskytovatel služby se

rvice p

rovid

er

Služba

Služba

Funkcionalita systém

u

Požadavek (service request)

Odpověď (service response)

12

Specifikace [73] popisuje webové služby prostřednictvím abstraktního modelu, bez vazby

na konkrétní technologie, komunikační protokol, případně mechanizmus předávání zpráv a

podobně. Následující text, pro zjednodušení, uvádí konkrétní skupinu technologii, běžně

používaných k implementaci webových služeb.

Systémy, vstupující do vzájemné interakce, se nazývají v případě webových služeb agenti

(agent). Tito agenti spolu komunikují prostřednictvím zasílání zpráv (messages). K přenášení

zpráv jsou využívány standardní komunikační protokoly (např. HTTP, FTP, SMTP atd.).

Zprávy jsou předávány v XML, prostřednictvím standardizovaného mechanizmu (např.

SOAP [72], XML-RPC [81], atd.). Informace o dostupných webových službách jsou

shromažďovány v registru služeb (ten bývá postaven na UDDI [65]). Komunikační rozhraní

služeb je popsáno standardní formou tak, aby bylo srozumitelné agentům (nejčastěji

prostřednictvím WSDL [74]).

Obrázek č. 4 zobrazuje architekturu a technologie, typicky využívané při implementaci

webových služeb [73].

Obr. 4 Ukázka architektury webových služeb (zpracováno dle [73])

2.3 OGC Web Services

OGC Web Services (dále jen OWS), obdobně jako webové služby (viz. kap. 2.2),

umožňují zpřístupnit funkcionalitu systému prostřednictvím sítě. Na rozdíl od webových

služeb, mají všechny OWS přesně definovanou a pospanou množinu operací, které je možné

spouštět a volat.

Services registr

Provider Agent

Requester agent

WS

DL

Request

Response

HTTP

SOAP

WS

DL

Base technologies (XML, DTD, Schema)

UDDI

13

Do rodiny specifikací, označovaných jako OWS, patří například WMS, WFS, WCS

a podobně (pozn. specifikace jednotlivých OWS jsou dostupné na stránkách OGC [51]).

Společné vlastnosti všech OWS jsou definovány v OGC Web Services Common Specification

[50].

Architektura OWS je v mnohém podobná architektuře webovým služeb (viz. kap. 2.2).

Komunikace mezi poskytovatelem služby a uživatelem služby funguje také na bázi předávání

XML dokumentu. K předávání dokumentu je využíván některý ze standardních

komunikačních protokolů (nejčastěji je to HTTP).

Obr. 5 Schéma komunikace uživatele a poskytovatele OWS (zpracováno dle [50])

Každá OWS musí dle [50] povinně podporovat jedinou operaci, a to operaci

GetCapabilities. Tato operace vyžaduje dva povinné parametry, service a request. Po zavolání

operace může uživatel získat:

� metadata o schopnostech služby,

� metadata o zveřejněných operacích,

� základní informace o poskytovateli služby.

2.3.1 Volání operací a předávání parametrů

Specifikace [50] definuje dva možné způsoby, prostřednictvím kterých je možné volat

operace a předávat jim potřebné parametry:

� parametry jsou zakódované jako keyword-value pair (KVP)

� parametry jsou zakódovány v XML dokumentu

Na obrázku č. 6 je zobrazen příklad volání operace GetCapabilities, včetně předání

povinných parametrů. Předávané parametry jsou zakódovány jako KVP. Přičemž například

Poskytovatel služby HTTP POST

Uživatel služby

XML

HTTP GET KVP

HTTP POST XML

Zpravování požadavků

Generování požadavků

Internet

OWS

14

"SERVICE" je tzv. klíčové slovo (keyword) a řetězec "CSW" je potom předávaná hodnota.

Specifikace [50] doporučuje využít pro přenos těchto parametrů a jejich hodnot metodu GET

komunikačního protokolu HTTP [50], [28].

?SERVICE=CSW&REQUEST=GetCapabilities

Obr. 6 Ukázka volání operace GetCapabilities, předávané parametry jsou zakódovány jako KVP

Ve druhém příkladě je opět volána operace GetCapabilities, avšak povinné parametry jsou

zakódovány v podobě XML dokumentu. Specifikace [50] doporučuje využít k předání tohoto

dokumentu metodu POST, komunikačního protokolu HTTP [50], [28], [76].

<?xml version="1.0" encoding="UTF-8"?>

<GetCapabilities

xmlns="http://www.opengis.net/ows"

xmlns:ows="http://www.opengis.net/ows"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instanc e"

xsi:schemaLocation="http://www.opengis.net/ows

fragmentGetCapabilitiesRequest.xsd"

service="CSW"

></GetCapabilities>

Obr. 7 Ukázka volání operace GetCapabilities, předávané parametry jsou zakódované prostřednictvím XML

2.4 Distribuovaná architektura geoportálu

S rostoucí složitostí systému zpravidla roste složitost jakýchkoliv úprav tohoto systému.

Distribuovaná architektura rozděluje celý systém na menší logické celky, samostatné

podsystémy, schopné zabezpečovat určitou parciální funkcionalitu. Tyto podsystémy jsou

mnohem lépe přizpůsobitelné a upravitelné. Pro budoucnost geoportálu (viz. kap. 1.5) je

důležité držet se právě této myšlenky.

Orientace na služby (viz. kap. 2.1) poskytuje možnost jednoduše rozšířit funkcionalitu

geoportálu. Samostatné služby jsou také mnohem lépe škálovatelné, zpravidla bez rozsáhlé

přestavby celého systému. Díky distribuované architektuře je dosaženo otevřenosti

a přístupnosti celého systému. [47], [27].

Dle [47] by měla být postavena architektura geoportálu na čtyřech pilířích:

� Portálové služby (Portal Services);

� Zobrazovací služby (Portrayal Services);

� Katalogové služby (Catalogue Services);

� Datové služby (Data Services).

15

Obr. 8 Geospatial Portal Reference Architecture [47]

2.4.1 Portálové služby (Portal Services)

Portálové služby přispívají k zpřístupnění geoinformačních zdrojů. Umožňují správu

a administraci celého portálu. Uživatele mohou prostřednictvím portálových služeb působit na

další prvky distribuované architektury. Portálové služby nabízejí nástroje pro správu

uživatelských účtů.

Umožňují nastavit přístupová práva, jednotlivých uživatelů, k funkcionalitám portálu.

Oprávněným uživatelům umožňují publikaci nového obsahu. Dále poskytují nástroje pro

prohlížení a vyhledávání geoinformačních zdrojů [47].

2.4.2 Zobrazovací služby (Portrayal Services)

Zobrazovací služby zabezpečují vizuální prezentaci prostorových dat v podobě

kartografických map případně datových náhledů. Generované prezentace mohou být

dynamické, nebo statické. V případě dynamických prezentací mohou zobrazovací služby také

zajišťovat nastavení stylů zobrazení. Příkladem zobrazovací služby je například Web Map

Services (WMS) [47].

Data Services Symbology management Gazetteer Coverages Features

Portal Services View Client Discovery Client Management Client Access Control Exposed Services

Internet

Catalog Services Data Discovery Services Discovery Catalog Update Query Languages

Portrayal Services Maps Styling Coverages Map Content

Geospatial Portal

16

2.4.3 Katalogové služby (Catalogue Services)

Katalogové služby zabezpečují vyhledávání a poskytování informací o zdrojích,

uložených v katalogu (viz. kap. 1.2). Poskytují podporu pro publikování a správu popisných

informací. Katalogové služby umožňují, v neposlední řadě, sběr informací uložených v jiných

katalozích. Zpřístupňují metadata jak pro ruční, tak pro programové zpracování [47].

2.4.4 Datové služby (Data Services)

Datové služby zabezpečují přístup k údajům uloženým v databázových systémech.

Usnadňují a urychlují vyhledávání uložených informací.

2.5 Značkovací jazyky

Současné moderní informační systémy využívají celou řadu značkovacích jazyků.

Výjimkou nejsou samozřejmě ani metainformační portály, dokonce je možno říct, že

značkovací jazyky zde hrají velmi významnou roli, zejména pak jazyk XML (viz.

kap. 2.5.2). Je jasné, že postihnout široký vztah metainformačních portálů k značkovacím

jazykům není snadné a v této chvíli ani účelné. Pozornost bude věnována pouze těm

nejvýznamnějším, které souvisí s GeoNetwork (viz. kap. 4).

2.5.1 HTML

HTML je značkovací jazyk, určený pro publikaci libovolných dat prostřednictvím sítě

Internet. Je odvozen od značkovacího jazyka SGML (ISO 8879). Význam jednotlivých

značek je předem dán specifikací, tento jazyk není možné na rozdíl od jazyka XML

standardizovanou cestou rozšířit o nové značky. Tento značkovací jazyk je dostupný

v několika verzích. Poslední je HTML 4.01, touto verzí byl vývoj jazyka HTML ukončen

[71].

2.5.2 XML

XML je jednoduchý a velmi snadno rozšířitelný značkovací jazyk, specifikovaný

konsorciem W3C. Právě díky jednoduchosti a snadné rozšiřitelnosti tohoto jazyka vzniká celá

řada implementaci, nejen v oblasti geoinformatiky [76].

Tento jazyk je určen zejména pro výměnu dat mezi aplikacemi. Dokumenty vytvořené

v tomto značkovacím jazyku jsou výhradně orientovány na strukturu přenášených dat, přímo

17

se nezabývá vizuální prezentací dat. Základem pro tento značkovací jazyk byl jazyk SGML

(ISO 8879) [76], [56].

K hlavním výhodám tohoto značkovacího jazyka patří dle [56], [44], [76]:

� Pevná pravidla pro zápis elementů, atributů, obsahu, komentářů a podobně

� Snadná rozšiřitelnost o nové značky (elements)

� Možnost konverze do dokumentů s jinou strukturou

� Možnost konverze do jiného formátu, například do prostého textu, HTML

a podobně

� Automatizovaně kontrolovatelná struktura na základě definičního schématu

� Podpora 32bitového kódování znaků (UNICOD, ISO 10646)

Jazyk XML je možné využít k prezentaci a výměně různých informací, těmito

informacemi mohou být například metadata. Tento jazyk také tvoří faktický základ OWS (viz.

kap. 2.3).

2.5.3 Vybrané značkovací jazyky založené na XML

XSL je skupina značkovacích jazyků, určených k transformaci, vizualizaci a procházení

XML dokumentů. Do této skupiny patří [70]:

� XSLT – jazyk určený pro transformaci jednoho XML dokumentu do jiného

(nemusí se nutně jednat opět o XML dokument)

� XSL-FO – značkovací jazyk, určený pro definici formátování element XML

dokumentu

� XPath – jazyk určený pro adresování elementů a atributů obsažených v XML

dokumentu [77]

XSD je značkovací jazyk určení k popisu struktury XML dokumentu. Dovoluje popsat

strukturu dokumentu, datové typy jednotlivých elementů a atributů, omezit počet výskytů

elementů a podobně. Tento popis je následně možné použít pro validaci dokumentu [78].

18

3 Projekt budování UNSDI

Tato kapitola velmi stručně popisuje projekt budování geoinformační infrastruktury

Spojených národů. Do tohoto projektu je zapojena také České republika.

Geoinformační infrastrukturu – je možné definovat jako soubor podstatných technologií,

politik, institucionálních dohod, standardů a metadat, které mají usnadnit přístup

k prostorovým datům [68].

3.1 UNGIWG

UNGIWG byla založena v roce 2000, má za úkol hledat společné řešení na poli

geoinformatiky pro členy Organizace Spojených národů, mimo jiné by se měla zasadit

o vybudování Geoinformační infrastruktury Spojených národů – UNSDI (viz. kap. 3.2).

V rámci UNGIWG pracuje šest tématických skupin, přičemž každá z nich se zabývá

vymezenou oblastí. [67].

Obr. 9 Struktura pracovní skupiny UNGIWG [67]

UNGIWG spolupracuje s nevládními organizacemi, výzkumnými institucemi

a průmyslem. Společně pracují na vývoji a údržbě geoinformačních technologií a společných

geografických databází. K dnešnímu dni má UNGIWG 30 členů z celého světa [67].

Hlavní cíle UNGIWG jsou dle [67]:

� vylepšit využití geografických informací pro podporu rozhodování,

� podpořit tvorbu standardů a norem v oblasti geoinformatiky,

� vytvořit základní sady map a zabránit duplicitnímu pořizovaní dat,

� vytvořit mechanizmy pro sdílení, správu a garanci kvality geografických

informací,

19

� vytvořit prostor pro diskuzi o budoucích řešeních a technologických změnách

v oblasti GI.

V souladu s cílem UNGIWG, vytvořit mechanizmy pro sdílení, správu a garanci kvality

geografických informací, byl zahájen vývoj systém GeoNetwork, který představuje základní

technický prvek UNSDI (viz. kap. 4) [68].

3.2 UNSDI

Základ UNSDI byly položeny v roce 2005 na šestém celosvětovém meetingu UNGIWG

v Adis Abebě [69].

Hlavním účelem UNSDI je propojit mezi sebou existující geoinformační infrastruktury

jednotlivých členských států a organizací v decentralizované síti tak, aby došlo

k maximalizaci užitku z dostupných geografických informací. Vybudováním jednotné

geoinformační infrastruktury by se také mělo dle [69] a [66] docílit:

� lepšího sdílení a využití geografických informací v rámci Spojených národů,

� zpřístupnění a sdílení jednotlivých informačních zdrojů prostřednictvím

decentralizované sítě,

� zlepšení interoperability jednotlivých národních geoinformačních infrastruktur,

� několikanásobného využití geografických informací,

� zjednodušení vyhledávání a získávání geografických informací,

� výměny geografických informací prostřednictvím otevřených výměnných

formátů,

� interoperability a standardizace vytvořených nástrojů.

Proces implementace UNSDI je dle [69] rozdělen do čtyř fází. Koncem roku 2006 došlo

k nastartování první fáze procesu implementace, Budování základů UNSDI. Prioritní oblastí

pro tuto fázi, je oblast metadat.

3.2.1 Zapojení České republiky do budování UNSDI

Česká republika je aktivně zapojena do budování UNSDI od 18. června 2006, kdy proběhl

v Brandýse nad Labem tzv. startovní meeting. Česká republika se stala, jednou se šestí

pilotních zemí světa zastupující, společně s Nizozemím a Maďarskem, Evropu.

V rámci projektu se bude Česká republika zabývat zejména otázkou: Jak zpřístupnit

prostorová data UNSDI? Za tímto účelem by mělo v České republice dojít k testování

katalogových služeb. [68]

20

4 Charakteristika GeoNetwork

Tato kapitola představuje systému GeoNetwork, podává přehled o dostupných verzích

GeoNetwork a nastiňuje filozofii a základní architekturu systému GeoNetwork.

GeoNetwork je dynamicky generovaná webová aplikace, která umožňuje komplexní

správu a sdílení metadat prostřednictvím sítě internet. GeoNetwork respektuje normy

ISO/TC 211, principy Free and Open Source Software a standardy OGC [7], [32], [51].

Obr. 10 Ukázka uživatelského rozhraní GeoNetwork

GeoNetwork vzniká pod záštitou čtvrté pracovní skupiny UNGIWG - Interoperable

services (viz. kap. 3.1). Na vývoji GeoNetwork pracuje od roku 2000 organizace FAO. Vývoj

systému GeoNetwork je financován z prostředků této organizace. Dále na vývoji spolupracují

dle [68] následující organizace:

� FAO – Food and Agriculture Organization of the United Nations

� WFP – World Food Programme

� WHO – World Health Organization

� UNEP – United Nations Environment Programme

� UN-OCHA – United Nations Office for the Coordination of Humanitarian Affairs

GeoNetwork si klade za cíl dle [68] a [7]:

� vylepšit podporu rozhodování,

21

� zlepšit výměnu a sdílení pořízených metadat na všech úrovních,

� vylepšit přístupnost geografických dat pro odbornou a širokou veřejnost,

� zvýšit povědomí o možnostech využití geografických datech,

� zamezit duplikaci pořízených dat a tím ušetřit prostředky uživatelů,

� přičinit se o nárůst spolupráce, mezi organizacemi, při sběru a pořizování

prostorových dat.

GeoNetwork standardně dovoluje spravovat metadata o informačních zdrojích

odpovídající následujícím normám a standardům:

� ISO19115 a ISO19139 (viz. kap. 1.1.3),

� Dublin Core (viz. kap. 1.1.2),

� FGDC [62].

4.1 Přehled základních schopností systému GeoNetwork

GeoNetwork 2.1 alpha 1 umožňuje:

� Uchovávání metadat,

� Vkládání nových a editaci stávajících metadat,

� Validaci metadat při vkládání,

� Hromadné (dávkové) vkládání metadat,

� Vyhledávání metadat v lokálním katalogu,

� Sdílení a vyhledávání metadat v široké decentralizované síti katalogů,

� Dynamické prohlížení jednotlivých metadatových záznamů,

� Řadit metadata do skupin, procházení skupinami metadatových záznamů,

� Sběr metadat umístěných v jiných katalozích,

� Import a export spravovaných metadat, jak jednotlivě, tak po skupinách,

� Řídit práva jednotlivých registrovaných uživatelů,

� Publikovat novinky prostřednictvím RSS a GeoRSS kanálů,

� Volitelně umožňuje přístup k distribuovaným mapovým zdrojům.

Podrobnější popis funkčnosti GeoNetwork je možné nalézt v kapitole č. 6.

22

4.2 Architektura GeoNetwork

GeoNetwork dle [7] z velké části splňuje požadavky definované v [47] (viz. kap. 2.4).

GeoNetwork implementuje podle [61] tři, ze čtyř základních pilířů:

� Portálové služby (Portal Services),

� Katalogové služby (Catalogue Services),

� Datové služby (Data Services).

GeoNetwork přímo nepodporuje čtvrtý pilí ř, zobrazovací služby (Portrayl Services).

Zobrazovací služby slouží pro vizualizaci prostorových dat v prostředí internetu. Nicméně

[61] uvádí, že existuje několik opensource projektů, které mohou tyto služby zabezpečit místo

GeoNetwork. Chybějící implementaci mapového prohlížeče, je možné nahradit například

pomoci aplikace InterMap. Na vývoji aplikace InterMap se také podílí organizace FAO

[61], [31].

Dále jsou v [61] tyto aplikace, zabezpečující zobrazovací služby:

� Degree [17]

� MapServer [39]

� GeoServer [24]

4.3 Verzování GeoNetwork

Poslední oficiálně dostupnou stabilní verzí, je verze GeoNetwork 2.0.3. V současné době

je předmětem vývoje GeoNetwork verze 2.1. Stabilní verze GeoNetwork 2.1 by měla být

dostupná v průběhu roku 2007. Přehled uvolněných verzí zobrazuje tabulka číslo 1.

Tab. 1 Přehled verzí systému GeoNetwork opensource od roku 2004

Označení verze Datum vydání Poznámka GeoNetwork 1.2.1 28. 10. 2004 Neznámo GeoNetwork 2.0 20. 12. 2005 Oficiální verze GeoNetwork 2.0.2 18. 04. 2006 Oficiální verze GeoNetwork 2.0.3 20. 10. 2006 Oficiální verze – opravuje chyby v 2.0.2 GeoNetwork 2.1 alpha 1 21. 10. 2006 Testovací verze GeoNetwork 2.1 alpha 2 03. 01. 2007 Testovací verze GeoNetwork 2.1 beta 12. 02. 2007 Neoficiální testovací verze GeoNetwork 2.1 beta2 20. 03. 2007 Neoficiální testovací verze, poslední před

vydání GeoNetwork 2.1 GeoNetwork 2.1 Neznámo Předpokládané uvolnění finální veze

GeoNetwork 2.1, Červenec 2007

23

4.4 Distribuce GeoNetwork

GeoNetwork je dostupný pod licencí GNU GPL, která podporuje volné šíření tohoto

systému a to včetně zdrojových kódů [25]. GeoNetwork je distribuován v podobě zdrojových

kódů, případně jako automatický instalátor (instalační balíček). Návod na instalaci

GeoNetwork je uveden v příloze číslo 7.

4.4.1 Stažení aktuálních zdrojových kódů

Při testována vývojové verze GeoNetwork 2.1, bylo potřeba často sáhnout po aktuálních

zdrojových kódech. Zdrojové kódy GeoNetwork jsou spravovány prostřednictvím Concurrent

Versions System (CVS). Tento systém umožňuje vývojářům GeoNetwork udržet přehled

o změnách provedených ve zdrojových kódech, a také dovoluje určit pravidla pro zápis a čtení

zdrojových kódů.

Zdrojové kódy GeoNetwork jsou pro běžného uživatele dostupné pouze ke čtení. Postup

kompilace aktuálních zdrojových kódů je popsán v příloze číslo 6. Pro přístup k aktuálním

zdrojovým kódům byl využit CVS klient TortoiseCVS. Tento klient je dostupný zdarma pod

licencí GPL [63].

4.4.2 Instalační balíček GeoNetwork

GeoNetwork je distribuován také v podobě automatického instalačního balíčku. Instalační

program je vytvořen pro prostředí Java SE. Návod na sestavení tohoto instalačního balíčku je

popsán v příloze číslo 6. Instalační balíček v sobě integruje následující komponenty:

� Aplikaci GeoNetwork

� Ukázkové metadata

� Testovacího klienta CSW (funkční pouze v OS Linux)

� Webový server Jetty (viz. kap. 5.4.2)

� DBMS McKoi (viz. kap. 5.6) včetně JDBC konektor

� Aplikaci pro migraci mezi verzemi GeoNetwork

� Zdrojové kódy systému GeoNetwork

� Dokumentaci zdrojových kódů GeoNetwork

Instalaci GeoNetwork s využitím instalačního balíčku je popsána v příloze číslo 7.

24

4.5 Požadavky GeoNetwork na systém

Systém GeoNetwork má dle [22] tyto minimální požadavky na systém:

� OS: Windows, Linux a Mac OS X

� Operační paměť 250 MB

� Procesor 1GHz

� Prostor na pevném disku 30 Mb

� DBMS (standardně dodáván s McKoi)

� Nainstalováno JRE 1.5.0 (viz. kap. 5.1.2)

� Internetový prohlížeč (podporující XSL transformaci na straně klienta)

25

5 Analýza technologií využívaných v GeoNetwork

Tato kapitola poskytuje přehled nejdůležitějších technologií, svázaných s provozem

případně vnitřní stavbou GeoNetwork.

5.1 Platforma Java

Jazyk Java je jedním z nejrozšířenějších objektově orientovaných programovacích jazyků

na světě. Platformou Java se pak rozumí skupina programů, umožňujících spouštění appletů

(programů) napsaných v programovacím jazyce Java. Vývojem této platformy se zabývá

firma SUN Microsystems. V současnosti existují tři základní edice této platformy:

� Java SE (Java Standard Edition) – je platforma určená pro desktop zařízení;

� Java ME (Java Micro Edition) – je platforma určená pro mobilní zařízení;

� Java EE (Java Enterprise Edition) - je platforma určena pro vývoj podnikových

serverových aplikací (viz. kap. 5.2).

Java EE a Java ME jsou odvozeny od Java SE. Z pohledu tvorby interaktivních webových

aplikací, jakou je například GeoNetwork, je nejdůležitější Java EE (viz. kap. 5.2) [59].

5.1.1 Java Development Kit (JDK)

JDK je skupina nástrojů usnadňující vývoj aplikací v programovacím jazyce Java. JDK

obsahuje nástroje pro ladění a kompilaci zdrojových kódů a také JRE (viz. kap. 5.1.2).

Vývojem JDK se opět zabývá firma SUN Microsystems, poslední dostupnou verzí JDK je

verze 1.6. [59].

5.1.2 Java Runtime Environment (JRE)

JRE je softwarový balík, který umožňuje běh Java aplikací. Java aplikace jsou spouštěny

nad standardním rozhraním virtuálního stroje JVM. Následující schéma nastiňuje postup

kompilování a následného spouštění aplikace s využitím JRE [59].

26

Obr. 11 Schéma překladu zdrojového kódu jazyka Java (zpracováno dle [59])

Zdrojové kódy jsou nejprve přeloženy kompilátorem do speciálního kódu. Tento kód se

nazývá bytecode. Bytecode je vlastně jakýsi mezistupeň mezi zdrojovým kódem a strojovým

kódem.

Bytecode je interpretován virtuálním strojem JVM, který je součástí JRE. Pro zvýšení

rychlosti aplikace je možné bytecode přeložit přímo do strojového kódu, pomocí kompilátoru

Just-in-time (JIT). Součástí distribuce JRE je také balík základních knihoven, nutných pro

bezproblémový chod aplikací [59].

5.1.3 Java database conectivity (JDBC)

JDBC je standardizované API rozhraní, umožňující univerzální přístup k různým DBMS.

Toto rozhraní je součástí platformy Java SE. Připojení k databázi je realizováno

prostřednictvím JDBC konektoru. Tento konektor tvoří prostředníka mezi DBMS a rozhraním

JDBC [59].

5.1.4 Zhodnocení platformy Java

Platforma Java nabízí standardizované prostředí JRE pro běh Java aplikací. Díky tomuto

standardizovanému prostředí nemusí docházet k žádným úpravám programového kódu

v závislosti na použitém hardware a software. JRE je dostupné například pro OS Windows,

OS Linux nebo OS Solaris. Přístup k DBMS prostřednictvím standardizovaného JDBC je

výhodný zejména v tom, že nemusí docházet k rozsáhlému zásahu do kódu aplikace, pokud

JDK

Hardware

JRE

JVM

Zdrojový kód v jazyce Java

Bytecode

Kom

pilátor

Debugger

Knihovny

27

dojde ke změně DBMS. Zpravidla pouze stačí změnit příslušný JDBC konektor. JDBC

konektor je většinou poskytován na stránkách výrobce DBMS.

Celá platforma Java je vyvíjena renomovanou firmou, dá se předpokládat, že její vývoj

bude do budoucna podporován stejnou silou jako doposud. Všechny výše uvedené skutečnosti

se promítají do schopnosti a vlastností GeoNetwork zejména v tom, že jej činí více

nezávislým a univerzálním.

5.2 Java Enterprise Edition (Java EE)

Java EE je platforma určená pro provoz centralizovaných informačních systémů,

podnikových aplikací a interaktivních webových aplikací. Jedná se o sadu vzájemně

propojených technologii, jejichž základem je platforma Java SE. Z hlediska tvorby

interaktivních webových aplikací je nejdůležitější technologie Java Servlet, kterou využívá

systém GeoNetwork [59].

5.2.1 Technologie Java servlet

Java Servlet API je přesně definované rozhraní, jehož prostřednictvím je možné spouštět

Java aplikace na straně serveru tzv. servlety. Technologie Java Servlet je nedílnou součástí

platformy Java EE. Poslední verze tohoto API je Java Servlet 2.5..

Servlet je nevizuální komponenta, spouštěna na straně serveru, na základě požadavku

klienta. Po zpracování požadavku může dojít k vygenerování odpovědi, nejčastěji v podobě

HTML nebo XML kód. Odpověď je generována dynamicky a vychází z požadavků klienta,

nejčastěji je klientem webový prohlížeč. Pro přenos komunikace mezi klientem a serverem je

nejčastěji využíván komunikační protokol HTTP. Schéma interakce klient-server je zobrazeno

na obrázku číslo 12. [58], [35].

28

Obr. 12 Schéma komunikace mezi klientem a serverem podporujícím technologii JAVA servlet [35]

Komunikace server-klient probíhá následovně:

1. Klient vygeneruje požadavek, který je předán aplikačnímu serveru, například

prostřednictvím komunikačního protokolu HTTP [28];

2. Požadavek je serverem zpracován a předán konkrétnímu servletu, tento servlet

běží v prostředí JVM (viz. kap. 5.1.2);

3. Servlet zpracuje požadavek a výsledek předá zpět aplikačnímu serveru;

4. Aplikační server odešle požadavek klientovy.

Je důležité si uvědomit, že klient nekomunikuje s požadovaným servletem přímo, činí tak

pouze prostřednictvím aplikačního serveru. Každý servlet je spuštěn pouze jednou a to při

startu aplikačního serveru. Procesy obsluhující požadavky klientů jsou spouštěny nezávisle

v samostatných vláknech. Životní cyklus servletu končí společně s ukončením aplikačního

serveru [35], [58].

5.2.2 Zhodnocení technologie Java Servlet

Technologie Java Servlet nabízí vývojářům celou řadu silných nástrojů (JDBC, web

services, JAXP), avšak nejdůležitější je, že dokáže využít veškerou funkcionalitu Java SE.

Další výhody této technologie jsou uvedeny například v [60].

Technologii určených k tvorbě interaktivních webových aplikací existuje celá řada, avšak

málokteré z nich nabízejí takovou nezávislost řešení a podporu jako Java Servlet.

5.3 Kompilování Java Servletů - Apache ANT

Apache ANT je nástroj, určený pro bezproblémové kompilování zdrojových kódů

napsaných zejména v jazyce Java. Tento nástroj usnadňuje tvorbu binární kompilaci

zdrojového kódů. Je vyvíjen od roku 2000 a je kompletně postaven na platformě Java SE.

Aplika ční Server

Ser

vlet

AP

I

Klient 1

Klient 2

Klient n

JVM Servlet 1

Servlet 2

Servlet 3

Požadavky

Odpovědi

DB JDBC

29

Apache ANT a je dostupný jako opensource pod licencí Apache Software License. Poslední

verze tohoto nástroje byla uvolněna v prosinci 2006, jedná se o verzi Apache ANT 1.7.0 [1],

[38].

Kompilace zdrojových kódů je řízena prostřednictvím skriptu napsaného v jazyce XML.

Tento skript obsahuje seznam po sobě jdoucích operací, které je nutné provést

pro bezchybnou kompilaci zpracovávaných zdrojových kódů. Operací je pak myšleno

například smazání adresáře, vytvoření dočasných souborů, a podobně [1], [76].

5.3.1 Zhodnocení Apache ANT

Během testování GeoNetwork bylo potřeba mnohokrát zkompilovat aktuální zdrojové

kódy, stažené prostřednictvím CVS (viz. kap. 4.4.1). Proces kompilace se vždy obešel bez

problémů a to zejména díky kompilačnímu nástroji Apache ANT. Zdrojové kódy

GeoNetwork obsahují předpřipravený kompilační skript, proces kompilace aplikace je popsán

v příloze číslo 6.

5.4 Spouštění Java Servletů

Java servletové aplikace je možné spouštět prostřednictvím tzv. aplikačního serveru.

Aplikační server je aplikace typu klient-server, která dokáže zpracovat požadavky klientů

a reagovat na ně. Nejběžnějšími klienty jsou webové prohlížeče, avšak v zásadě se může

jednat o libovolné jiné aplikace. Tyto aplikace musí být schopné interakce se serverem, tato

interakce spočívá například v podpoře stejných komunikačních protokolů a podobně. Aby

bylo možné spouštět servletové aplikace musí aplikační server implementovat rozhraní Java

Servlet (viz. kap 5.2.1). Aplikačních serverů implementujících rozhraní Java Servlet existuje

celá řada, následující podkapitoly popisují dva testované aplikační servery a sice aplikace

Apache Tomcat server a Jetty server.

5.4.1 Apache Tomcat server

Apache Tomcat je aplikační server, implementující technologii Java Servlet a Java Server

pages. Je jej možné využít samostatně nebo případně v kombinaci s webovým serverem jako

je například Apache HTTP server [2].

Apache Tomcat je dostupný pod licencí Apache Software License [38] zdarma jako

opensource, pro komerční i nekomerční využití. Poslední dostupnou verzí je Apache Tomcat

30

6.x, tato verze implementuje Java Servlet 2.5 a dokáže obsloužit servlety vyžadující pro svůj

běh Java SE 1.5 a vyšší [3].

5.4.2 Jetty server

Jetty je opensource aplikační server postaven kompletně na platformě Java SE. Je

dostupný pod licencí Apache Software License [38], zdarma jako opensource pro komerční i

nekomerční účely. První verze této aplikace byla vytvořena v roce 1995. V současnosti je

poslední dostupnou verzí Jetty 6.1, tato verze implementuje Java Servlet 2.5.

Jetty je vytvořen tak, aby byl co možná nejvíce efektivní, jednoduchý a bylo jej možné

jednoduše rozšířit. Jádro Jetty je udržováno co nejjednodušší a nejmenší. Veškera rozšiřující

funkcionalita je obsažena v externích volitelných knihovnách. Jetty je dle [37] možné použít

jako:

� samostatně stojící tradiční webový server, pro generování statického a

dynamického obsahu,

� server pro generování dynamického obsahu, stojící za tradičním webovým

serverem,

� jako vloženou aplikaci, případně komponentu jiné aplikace platformy Java SE.

5.4.3 Zhodnocení testovaných aplikačních serverů

Funkčnost systému GeoNetwork byla otestována na obou výše uvedených aplikačních

serverech. Aplikační server Jetty je přímo součástí instalačního balíčku (viz. kap. 4.4.2),

server Apache Tomcat je dostupný na stránkách Apache Software Foundation [1].

Oba aplikační servery se během testování chovaly stabilně a spolehlivě a nezpůsobily

žádné problémy. Z hlediska výkonu je dle [22] žádoucí pro více vytěžované instance

GeoNetwork využít Apache Tomcat, aplikační server Jetty je vhodný pro testovací provoz

případně pro provoz na desktop systémech.

5.5 Systém Jeeves

Jeeves (Java Easy Engine for Very Effective Systems) je balík kódů, napsaný v jazyce

Java. Umožňuje snadné vytváření webových aplikací s minimální znalostí technologie Java

Servlet. Jeeves je vytvářen jako dílčí projekt, spojený s projektem GeoNetwork a dle [40] je

navržen tak, aby:

31

� maximálně usnadnil vývoj webových aplikací,

� vyžadoval znalost co nejmenšího počtu technologii (stačí znát pouze XML a XSLT

jazyky),

� udržel oddělenou datovou a prezentační složku,

� oddělil lokalizační soubory od samotné aplikace (lokalizace je centralizována),

� poskytl základní (klíčové) služby a zároveň byl dobře přizpůsobitelný.

Systém Jeeves má ve svém jádře zakomponováno několik základních služeb, které

je možné využít při obsluze požadavku klienta. Jsou to:

� database access – přístup k databázím (včetně vkládání, editace a mazání

záznamů),

� logging management – správa přihlášení – včetně řízení práv přístupů

k jednotlivým servisům,

� multilingual support – kompletní podpora jazykových mutací aplikace,

� service chaining – řetězení jednotlivých servisů,

� session management – správa sezení,

� commit/rollback management – správa chodu servisů,

5.5.1 Architektura systému Jeeves

Architektura systému Jeeves je velmi jednoduchá, jak je možné vidět na následujícím

obrázku.

Obr. 13 Schéma architektury systému Jeeves [40]

Běžně vypadá komunikace se systémem následovně:

1. prohlížeč zašle požadavek systému Jeeves, prostřednictvím protokolu HTTP;

2. v případě, že je nutné získat data z databáze je tak učiněno (database access);

Webový prohlížeč

XSL

DBMS

HTTP odpověď

HTTP požadavek JDBC Jeeves

XML

HTML

32

3. na základě obdrženého požadavku a případných dat je poté vygenerována odpověď

v podobě XML dokumentu (v požadované jazykové mutaci multilingual support);

4. vygenerovaný XML dokument je přeložen pomoci XSL transformačního skriptu

do HTML podoby;

5. výsledný transformovaný dokument je předán zpět prohlížeči.

Každý požadavek klienta je mapován na metodu systému Jeeves, případně na metodu

přidruženého systému (přidruženým systémem může být například GeoNetwork). Jeeves

kontroluje privilegia přístupu (logging management) k dané službě. Dále Jeeves zachytává

a zpřístupňuje specifické informace o jednotlivých sezeních, jako je například IP adresa,

cookies a podobně (session management).

Jeeves se rovněž stará o bezproblémový chod jednotlivých služeb, v případě že dojde

k chybě je uživatel automaticky přesměrován zpět (commit/rollback management) [40].

5.5.2 Jeeves a podpora vícejazyčných aplikací

Jeeves interně nabízí podporu vícejazyčných aplikací. Veškeré aplikace je možné díky

tomuto systému plně přeložit a to včetně grafických elementů. Jednotlivé lokalizace jsou od

sebe odděleny, každá je uložena v samostatném adresáři. Po zvolení příslušného jazyka

dochází automaticky k úpravě požadované URL adresy. V případě, že je daná lokalizace

neúplná, nebo daný výraz není potřeba lokalizovat, k úpravě URL nedochází [40].

5.5.3 Zhodnocení systému Jeeves

Architektura systému Jeeves je do značné míry určující pro celkovou architekturu

GeoNetwork, jelikož Jeeves fakticky tvoří jádro GeoNetwork.

Největší sílu systému Jeeves je možné spatřovat v totálním oddělení samotných dat

a jejich vizuální prezentace a samozřejmě v jeho jednoduchosti. Schopnosti Jeeves se přímo

promítají do škálovatelnosti GeoNetwork, této problematice je věnována kapitola číslo 7 – ve

zkratce Jeeves umožňuje:

� upravit vizuální prezentaci, prostřednictvím úpravy výsledného HMTL kódu (viz.

kap. 7.1)

� lokalizovat celou aplikaci do národního jazyka (viz. kap. 7.2)

� přidat statickou webovou stránku (viz. kap. 7.3)

� rozšířit funkcionalitu GeoNetwork o nové služby (viz. kap. 7.4)

33

Je dobré, že Jeeves se snaží používat minimální množinu technologii, je tak zamezeno

nechtěným závislostem. Další pozitivní aspekt systému Jeeves je v tom, že nemá ambice

poskytnout veškeré možné funkcionality, ale poskytuje jich pouze pečlivě vybranou

omezenou skupinu (viz. kap. 5.5).

5.6 GeoNetwork a DBMS

GeoNetwork ukládá veškerá data, metadata a nastavení prostřednictvím relačního

DBMS. Data rozděluje celkem do 16 tabulek, seznam těchto tabulek, včetně jejích atributů, je

uveden v příloze č.2. Pro přístup k databázovým systémům je využito rozhraní JDBC (viz.

kap. 5.1.3). Součástí distribuce GeoNetwork je JDBC konektor pro databázový systém

McKoi. JDBC konektory pro ostatní databázové systémy je nutné dohrát, při instalaci,

z jiných zdrojů. GeoNetwork 2.1 alpha standardně podporuje tyto tří databázové systémy:

� McKoi

� Oracle [52]

� MySQL [45]

GeoNetwork 2.1 alpha 2 k těmto třem přidává podporu DMBS PostgreSQL [54]. Je

možné očekávat, že skupina podporovaných DBMS se bude rozrůstat podle požadavků

uživatelů GeoNetwork.

5.6.1 McKoi SQL

McKoi SQL je relační DBMS vytvořený pod platformu Java SE. Jedná se o aplikaci typu

klient-server. McKoi SQL je dostupný pod licencí GNU GPL [25] a jeho vývoj byl zahájen

v roce 1998. McKoi SQL dokáže zpracovat dotazy v jazyce SQL, co do rozsahu,

je podporována většina příkazů specifikovaných ve specifikaci SQL-92 (ISO/IEC 9075:1992).

McKoi SQL pro svůj běh vyžaduje Java SE 1.4 nebo vyšší. Konektor McKoi SQL

implementuje rozhraní JDBC verze 2. Poslední dostupná verze je McKoi 1.0.3 byla uvolněná

v roce 2004 [41].

5.6.2 Způsob uložení metadat

Každý metadatový záznam je opatřen jedinečným identifikátorem Universally Unique

Identifier (UUID), výhodou tohoto identifikátoru je absolutní jedinečnost v rámci celého

světa. Seznam atributů evidovaných u metadatových záznamů uvádí obrázek číslo 14.

34

Obr. 14 Schéma tabulky metadata, včetně seznamu evidovaných atributů

Metadatové záznamy jsou uchovány jako prostý text v rámci atributu data tabulky

metadata. Metadatovým záznamem rozumějme zdrojový XML dokument, odpovídající

příslušnému normalizovanému (případně standardizovanému) schématu (dále jen schéma),

pro ukládání metadat.

5.6.3 Zhodnocení vztahu GeoNetwork a DBMS

GeoNetwork standardně podporuje uchovávání metadat ve třech schématech (viz. kap. 4).

Principielně však umožňuje uchovat metadat, odpovídající libovolnému schématu. Což

přináší velké výhody, avšak také nemalé úskalí, například při vyhledávání metadat (viz. kap.

6.1).

Nevýhodou zvoleného způsobu uchovávání metadatových záznamů je to, že v případě

sebemenší úpravy, třeba jen části metadatového záznamu, musí vždy dojít k načtení

a následném zpracování celého XML dokumentu. Zde by se nabízel prostor pro nativní XML

databáze, které nabízejí ve srovnání s relačními DBMS, pokročilejší metody pro zpracování

XML dokumentů [44].

5.7 Indexační nástroj Apache Lucene

Apache Lucene je kvalitní indexační a vyhledávací nástroj, napsaný v programovacím

jazyce Java, který je dostupný pod licencí Apache Software License [38] zdarma jako

opensource, pro komerční i nekomerční využití. Poslední dostupnou verzí je Apache Lucene

2.1, tato verze byla uvolněna v roce 2007. Výhody systému Apache Lucine jsou dle [5]

následující:

� Rychlost indexace přes 20 MB/minutu,

� Malé požadavky na RAM paměť (kolem 1 MB),

35

� Přírůstková indexace a rychlá dávková indexace,

� Velikost indexu zhruba 20–30% proti indexovaným datům,

� Opensource projekt napsán v jazyce Java.

Apache Lucene vyžaduje pro svůj chod JRE minimálně ve verzi 1.4 [5].

5.7.1 Vyhledávací schopnosti Apache Lucene

Apache Lucene řadí nalezené výsledky sestupně od záznamu s nejvyšší relevancí,

případně dle libovolného atributu. Umožňuje vyhledávat na základě času a data. Dokáže

vyhledávat ve více indexech a výsledky poté sloučit do jediné odpovědi. Dle [5] Apache

Lucene dokáže zpracovat následující typy dotazů:

� RangeQuery – vyhledá záznamy k jejichž modifikaci došlo mezi určitým datem

například výraz mod_date:[20020101 TO 20070101] najde dokumenty, k jejichž

změně došlo mezi 1.1.2002 a 1.1.2007;

� ProximityQuery – vyhledá záznamy, u nichž jsou slova vzdálené do určité

vzdálenosti např. "GeoNetwork opensource"~10 najde veškeré záznamy u nichž

jsou slova GeoNetwork a opensource vzdálené maximálně 10 slov;

� WildcardQuery – vyhledávání záznamů prostřednictvím zástupných znaků

například po zadání výrazu Kni* nalezne Lucene všechny záznamy začínající

na znaky Kni;

� FuzzyQuery – vyhledá záznamy, které obsahují nejpodobnější výrazy hledanému

řetězci. Je také možné určit hladinu, pod níž budou ještě záznamy zahrnuty do

výsledku.

Vyhledávané výrazy je možné mezi sebou slučovat pomoci logických operátoru AND, OR

a NOT [5].

5.7.2 Zhodnocení Apache Lucene

GeoNetwork indexuje a následně prohledává uchovávané metadatové záznamy

prostřednictvím systému Apache Lucene. Vyhledávací schopnosti tohoto systému se přímo

promítají do vyhledávacích schopností GeoNetwork. GeoNetwork dokáže zpracovat výrazy

odpovídající dotazům RangeQuery, ProximityQuery, WildcardQuery i FuzzyQuery.

GeoNetwork indexuje u jednotlivých metadatových záznamů zvlášť Titulek, Abstrakt

a klíčová slova. Dále jsou metadatové záznamy prohledávány jako prostý text, při tomto

36

prohledávání není brána zřetel na strukturu metadat, ale pouze na obsah jednotlivých

elementů.

5.8 Další knihovny využívané aplikací GeoNetwork

GeoNetwork využívá celou řadu knihoven, tyto knihovny jsou napsány výhradně v jazyce

Java. Nejdůležitější z nich jsou uvedeny v následujícím seznamu:

� Apache Xalan – knihovna je použita pro transformací XML dokumentů s využitím

XSL, tato knihovna implementuje Java API for XML Processing JAXP [6], [57];

� Java-CQL – knihovna určená pro zpracování CQL dotazů [15];

� Tyrex – knihovna určena pro ověření bezpečnosti lokálních a distribuovaných

zdrojů [64];

� Jakarta Commons – je skupina vzájemně nezávislých knihoven, které usnadňují

vývoj aplikací v prostředí Java, GeoNetwork využívá knihovny HttpClient, Lang,

Logging, Email a Codec [4].

5.9 Závěreční shrnutí

Mezi veškerými technologiemi, které GeoNetwork využívá, je možné nalézt jedno pojítko,

tímto pojítkem je platforma Java. Jak již bylo uvedeno, největší výhodou této platformy je

to, že neomezuje uživatele systému co do použitého hardware a operačního systému. Díky

tomu je GeoNetwork skutečně jedinečným a univerzálně použitelný systémem pro správu

metadat.

Veškeré výše popsané technologie mají za sebou několikaletý vývoj, je tudíž možné

prohlásit, že jsou dostatečně otestovány. Dalším pozitivním faktem je to, že jejich vývoj je

většinou podporován renomovanými společnostmi. Obě tyto skutečnosti snižují riziko

předčasného ukončení vývoje některé z komplementárních částí GeoNetwork.

Během testování GeoNetwork se nepodařilo identifikovat z technického hlediska žádné

závažné chyby. Výše popsané technologie se chovali stabilně a dle očekávání

37

6 Popis funk čnost sytému GeoNetwork

Tato kapitola popisuje funkčnosti systému GeoNetwork z pohledu uživatele. GeoNetwork

rozlišuje tyto třídy uživatelů:

� Neregistrovaný uživatel,

� Registrovaný uživatel (Registred user),

� Editor (Editor),

� Administrátor uživatelů (User administrator),

� Administrátor systému (Administrator).

Rozdělení privilegii přístupu k jednotlivým funkcionalitám systému GeoNetwork je

uvedeno v příloze číslo 8. Největší pravomoc má přirozeně administrátor systému, tomu je

zpřístupněna veškerá funkcionalita GeoNetwork.

6.1 Vyhledávání metadat

Funkcionality vyhledávání metadat jsou přístupné všem třídám uživatelů. Formulář,

určený pro zadání parametrů vyhledávání metadatových záznamů je možné přeponou do dvou

módů:

� Jednoduchého módu (Simple search),

� Rozšířeného módu (Advanced search).

Tyto dva módy jsou dostupné jak pro lokální vyhledávání (Local Search), tak pro

vzdálené vyhledávání (Remote Search). Jádrem vyhledávání je systém Apache Lucene (viz.

kap. 5.7).

6.1.1 Lokální vyhledávání

Lokální vyhledávání (Local Search) umožňuje prohledat metadatové záznamy uložené

v lokálním katalogu. V rozšířeném módu vyhledávání (Advanced Search) je možné

vyhledávat metadatové záznamy na základě:

� Titulku (Title),

� Abstraktu (Abstract),

� Libovolného textu (Any Text),

� Klíčových slov (Keywords),

� Polohy (Location)

� Zařazení do skupiny (Group),

38

� Zařazení do kategorie (Category),

� Strany (Site),

� Typu mapy (Map type).

Obr. 15 Ukázka formuláře pro lokální vyhledávání metadat – rozšířený mód

Parametr přesnost (Precison) určuje citlivost GeoNetwork, potažmo Lucene, na výskyt

hledaného výrazu.

6.1.2 Vzdálené vyhledávání

Vzdálené vyhledávání (Remote Search) umožňuje prohledávat obsah katalogů vzdálených

instancí systému GeoNetwork. GeoNetwork verze 2.1 alpha obsahuje odkazy asi na čtyřicet

dalších uzlů metadatové sítě Spojených národů. Seznam těchto uzlů je možné rozšířit. Princip

vzdáleného vyhledávání je popsán v kapitole číslo 9.2.

Obr. 16 Ukázka formuláře pro vzdálené vyhledávání metadat – rozšířený mód

39

6.1.3 Zhodnocení funkce vyhledávání metadat

Metadata pro geodata umožňují popsat geografickou polohu geodat prostřednictvím tzv.

ohraničující obálky (Boundary Box). Geodata je tedy možné vyhledávat také na základě jejich

polohy, avšak tuto možnost GeoNetwork uživateli nenabízí. Zejména proto, že by bylo

nemyslitelné, aby při každém vyhledávání, docházelo k parsování všech metadatových

záznamů, za účelem zjištění polohy popisovaných geodat.

Tento nedostatek by bylo možné velmi efektivně vyřešit například prostřednictvím DBMS

PostgreSQL [54] s nadstavbou PostGIS [53].

Až na výše uvedenou výhradu, je možné vyhledávací schopnosti GeoNetwork hodnotit

jako dostačující.

6.2 Prohlížení a stahování metadat

V zásadě je prohlížení a stahování metadatových záznamů zpřístupněno všem uživatelům

bez rozdílu. Dostupnost těchto funkcionalit však může být ovlivněna nastavením

přístupových práv k jednotlivým záznamům.

6.2.1 Prohlížení metadat

GeoNetwork umožňuje prohlížet metadata ve třech módech:

� Základním módu (Default view),

� Rozšířeném módu (Advanced view),

� XML módu (XML view).

Základní mód (Default View) zobrazuje celý metadatový záznam najednou na jediné

stránce. Rozšířený mód (Advanced View) pak dělí metadatový záznam do samostatných

sekcí, tyto sekce jsou odvozeny od příslušného schématu. XML mód (XML View) umožňuje

zobrazit surová data metadatového záznamu v podobě XML dokumentu.

Obr. 17 Ukázka části metadatového záznamu zobrazeného v základním módu

40

Administrátor systému, nebo editor má prostřednictvím prohlížeče zpřístupněny tyto

funkcionality:

� Smazání metadatového záznam (Delete);

� Přidání nového metadatového záznamu (Add) – umožňuje vytvořit nový

metadatový záznam na základě zkopírování údajů v aktuálně prohlíženém

metadatovém záznamu;

� Úprava zobrazeného metadatového záznamu (Edit);

� Změna zařazení metadatového záznamu do kategorie (Category);

� Změna přístupových práv (Privileges).

Změna přístupových práv (Privileges) – umožňuje zvolit privilegia přístupu k jednotlivým

metadatovým záznamům pro jednotlivé pracovní skupiny. Administrátor systému nebo

případně Editor může určit kdo má právo metadatový záznam prohlížet (view), editovat (edit),

stahovat (download) a podobně.

Obr. 18 Ukázka formuláře pro změnu přístupových privilegii k vytvořenému metadatovému záznamu

Do pracovní skupiny all jsou implicitně zařazeni všichni registrovaní a neregistrovaní

uživatele GeoNetwork. Do pracovní skupiny internall jsou zařazeni všichni registrovaní

uživatelé.

6.2.2 Stahování metadat

Stahování metadat (Download) – umožňuje uživateli získat metadatový záznam v podobě

XML dokumentu, v té podobě v jaké byl vložen do katalogu. Dostupnost této funkcionality je

ovlivněna nastavením přístupových práv k metadatovému záznamu.

6.2.3 Zhodnocení funkce prohlížení metadat

Prohlížeč metadatových záznamů zobrazuje veškeré údaje dostatečně přehledně

a strukturovaně. Avšak některé informace, například titulek (Title), by bylo dobré vizuálně

zvýraznit velikostí písma případně barvou.

41

V případě nadpisů sekcí není zvolená dostatečně kontrastní barevná kombinace písma

a pozadí (pozn. kontrastnost testována dle doporučení [79]). Celkově je však možné prohlížeč

metadatových záznamů Geonetwork považovat za dostačující.

6.3 Vytváření metadat

GeoNetwork umožňuje vytvořit nový metadatový záznam dvojí cestou:

� Pomocí editoru metadatových záznamů,

� Vložením XML dokumentu.

Nový metadatový záznam může vytvořit administrátor systému, administrátor uživatelů,

nebo editor. Navíc musí být tento uživatel začleněn alespoň do jedné pracovní skupiny

(Group) (viz. kap. 6.5.2).

6.3.1 Nová metadata

Nová matedata (New Metadata) – umožňuje vytvořit nový metadatový záznam, na základě

předlohy (template), prostřednictvím editoru metadatových záznamů. Součástí standardní

instalace GeoNetwork jsou čtyři předpřipravené předlohy pro různá schémata (ISO 19115,

ISO 19139, FGDC, Dublin Core). Základní množinu předloh je možné rozšířit, předlohy jsou

vytvářeny obdobně, jako nové metadatové záznamy. Stejně jako prohlížeč metadatových

záznamů, umožňuje také editor metadatových záznamů zadávání metadat ve třech módech:

� Základním módu (Default View),

� Rozšířeném módu (Advanced View),

� XML módu (XML View).

Základní mód umožňuje vytvořit metadatový záznam prostřednictvím jediného

formuláře. Rozšířený mód rozděluje formulář do několika sekcí, dle příslušného schématu.

XML mód umožňuje vytvořit metadatový záznam na základě XML dokumentu.

6.3.2 Zhodnocení vytváření nových metadat

Tato kapitola poskytuje výčet pozitivních a negativních vlastností editoru metadatových

záznamů. Tento výčet byl sestaven na základě subjektivních zkušeností získaných při

testování.

Negativní vlastnosti editoru metadatových záznamů:

Editor metadatových záznamů vizuálně nerozlišuje povinné a nepovinné elementy daného

schématu. Informace o povinnosti elementu je dostupná teprve prostřednictvím nápovědy.

42

Obr. 19 Ukázka nápovědy GeoNetwork k elementu Metadata author

Standardně dodávaná nápověda neuvádí příklad validní hodnoty daného elementu, pouze

slovně vysvětluje daný element, což je v mnoha případech nedostačující. Obsah nápovědy je

možné přizpůsobit uživatelským potřebám prostřednictvím lokalizace (viz. kap. 7.2).

Nový metadatový záznam není možné vytvářet v několika etapách. Veškeré metadatové

záznamy jsou před uložením validovány, pokud metadatový záznam neprojdou touto validací,

není uživateli umožněno dokončit ukládání. Uživatel je tak nucen vytvořit celý záznam

najednou (pozn. opraveno ve verzi GeoNetwork 2.1 beta).

Validace metadatového záznamu je nevyhovující, výstupem validátoru je pouze oznámení

zda je vytvářený metadatový záznam validní, nebo ne. Uživatelsky mnohem přívětivější by

bylo, kdyby validátor vypsal také proč je zadávaný záznam nevalidní.

Editor metadatových záznamů neumožňuje u nově vytvářeného metadatového záznamu

zvolit kategorii a nastavit privilegia přístupu, tyto volby je možné provést teprve dodatečně

(pozn. opraveno ve verzi GeoNetwork 2.1 beta).

Uživatel má možnost měnit ve formuláři skupinu zadávaných položek. Může přidat,

případně odstranit jednotlivé sekce, nebo položky v závislosti na použitém schématu. Obrázek

číslo 20 zobrazuje umístění ovládacích prvků pro úpravu seznamu zadávaných položek.

Obr. 20 Ukázka umístění ovládacích prvků pro úpravu seznamu zadávaných položek

Je-li některé ze sekcí odstraněna, není již možné tuto sekci opětovně přidat zpět. Tato

skutečnost nutí uživatele v případě chybné úpravy začít vytvářet celý metadatový záznam

znovu (pozn. všechna doposud zadaná data jsou ztracena). Úprava vzhledu formuláře není

řešená dynamicky, při libovolné změně je vždy překreslená celá stránka zadávacího

formuláře.

43

Pozitivní vlastnosti editoru metadatových záznamů:

Struktura formuláře, pro zadávání nového metadatového záznamu, se odvíjí od struktury

použitého schématu. Se složitosti schématu roste přirozeně také složitost formuláře.

Jednotlivé sekce formuláře jsou vizuálně dostatečně odděleny, tudíž nedochází ke „ztracení

se“ při zadávání jednotlivých položek.

Velmi pěkně je vyřešeno zadávání položky typu datum, kde je uživateli umožněno pro

zadání využít dynamicky generovaný kalendář.

Obr. 21 Ukázka kalendáře pro zadávání atributu typu datum

Editor metadatových záznamů dokáže automaticky doplnit geografické souřadnice do

elementu Geographic Box, na základě uživatelem vybraného státu.

Obr. 22 Ukázka vyplněného elementu Geographic box

Nově vytvářený metadatový záznam je možné opatřit tzv. náhledem geodat (thumbnail).

Náhled je vytvářen na základě nahraného obrázku, velikost obrázku je automaticky upravena.

Obr. 23 Ukázka části formuláře sloužícího pro nahrání náhledu popisovaných geodat

44

Závěrečné shrnutí vlastností editoru metadatových záznamů:

Ve světle výše uvedených připomínek je možné označit funkcionalitu editoru

metadatových záznamu za nedostačující. Je však nutné přihlédnout k tomu, že byla testována

vývojová verze GeoNetwork 2.1 alpha. Dle dosavadního vývoje, je možno očekávat, že

mnohé negativní vlastnosti editoru metadatových záznamů budou ve finální verzi odstraněny.

6.3.3 Vytváření metadat na základě XML

Vytváření metadata na základě XML (XML Metadata Insert) – umožňuje vytvořit nový

metadatový záznam na základě surových dat, v podobě XML dokumentu.

Obr. 24 Ukázka vyplněného formuláře pro vytvoření met. záznamu na základě XML dokumentu

6.3.4 Zhodnocení vytváření metadat na základě XML

Surová data je nutné vložit prostřednictvím schránky (clipboard) do příslušného

formuláře. GeoNetwork nenabízí možnost přímého načtení XML souboru. Zvolený způsob

není uživatelsky příliš přívětivý. Na druhou stranu tento způsob umožňuje přímou úpravu

vkládaného XML kódu. Formulář nedovoluje zvolit zařazení metadatového záznamu do

kategorie (pozn. opraveno v GeoNetwork 2.1 beta).

6.4 Hromadné vytváření metadat

GeoNetwork nabízí dvě možnosti jak vložit do katalogu větší počet metadatových

záznamů:

� Harvesting metadat (Harvesting);

45

� Dávkový import metadat (Batch Import).

Tyto funkcionality sytému GeoNetwork může využít pouze administrátor systému.

6.4.1 Harvesting metadat

Harvesting metadat (Harvesting) je proces, při kterém jsou procházeny katalogy

vzdálených instancí GeoNetwork, za účelem aktualizace obsahu lokálního katalogu.

GeoNetwork dokáže rozpoznat změněné případně nové metadatové záznamy na základě

jedinečného identifikátoru UUID a data změny. Technická základ harvestingu metadat je

popsán v kapitole číslo 9.3.

Administrátor systému může:

� Přidat nový uzel (Add harvesting),

� Odebrat vybraný uzel (Remove harvesting),

� Spustit okamžitě sběr metadat (Run harvesting),

� Zastavit harvesting metadat (Stop harvesting).

Obrázek číslo 26 zobrazuje ukázku vyplněného formuláře pro přidání nového uzlu pro

harvesting metadat. U nově přidaného uzlu je nutné nastavit parametry připojení a také

naplánovat v jakých časových intervalech má docházet ke sběru metadatových záznamů.

Obr. 25 Ukázka nastavení sběru metadat pro testovací uzel GeoNetwork VŠB

46

6.4.2 Dávkový import metadat

Dávkový import metadat (Batch Import) – umožňuje jednorázově vložit skupinu

metadatových záznamů. Vkládané metadatové záznamy musí být uloženy v jednom adresáři

v podobě XML dokumentu. Adresář musí být přirozeně dostupný systému GeoNetwork.

Obr. 26 Ukázka vyplněného formuláře pro dávkový import metadatových záznamů

6.4.3 Zhodnocení hromadného vkládání metadat

Harvesting metadat vykazoval při testování celou řadu chyb. Například nebylo možné

některé uzly po přidání editovat, případně smazat. V některých případech nereagovalo ani

okamžité spuštění harvestingu.

Komunikační rozhraní GeoNetwork není zpětně kompatibilní. Harvesting je funkční

pouze mezi totožnými verzemi GeoNetwork. Dávkový import, se při testování, choval dle

očekávání uživatele.

6.5 Administrace systému GeoNetwork

Administrátor systému může při správě GeoNetwork využít tyto funkcionality:

� Správa kategorii (Catagory management);

� Správu pracovních skupin (Group managemem);

� Správa uživatelských účtů (User management).

6.5.1 Správa kategorii

Skupiny podobných metadatových záznamů je možné zařadit do kategorií, tyto kategorie

následně usnadňují nalézání metadatových záznamů. Správa kategorií (Category

management) umožňuje administrátorovi systému:

� Vytvořit novou kategorii (Add a new category);

� Smazat kategorii (Delete);

� Upravit existující kategorii (Edit).

47

6.5.2 Správa pracovních skupin

Každý uživatel systému GeoNetwork může být zařazen do tzv. pracovní skupiny. Bez

zařazení do pracovní skupiny nemůže uživatel publikovat metadata. Pracovní skupiny zároveň

slouží pro rozdělení privilegii přístupu k jednotlivým metadatovým záznamům.

Správa pracovních skupin (Group management) umožňuje administrátorovi systému:

� Vytvořit novou skupinu (Add a new Group) – u skupin je možné evidovat jméno

skupiny, popis a email;

� Smazat kategorii (Delete);

� Upravit existující kategorii (Edit).

6.5.3 Správa uživatelských účtů

Správa uživatelských účtů umožňuje administrátorovi systému:

� Vytvořit nového uživatele (Add a new user to the Database)

� Smazat uživatele (Delete)

� Upravit existujícího uživatele (Edit)

Obrázek číslo 24 ukazuje příklad vyplněného formuláře pro registraci nového uživatele.

Nově registrovaný uživatel bude moci publikovat metadata pod dvěma pracovními skupinami

(moje_skupina a moje_skupina2) a bude mít status administrátora systému.

Obr. 27 Ukázka vyplněného formuláře pro vytvoření nového uživatelského účtu

48

Po registraci, si může každý uživatel nastavit vlastní parametry (jméno, příjmení, email,

přístupové heslo, adresu pod.).

6.5.4 Zhodnocení administrace systému GeoNetwork

Během testování administrace systému GeoNetwork nebyly identifikovány žádné závažné

problémy. Systém se choval dle očekávání.

Jediné co je možné vytknout, z technického hlediska, je způsob uložení hesel uživatelů

systému. Ty jsou uloženy v tabulce user (viz. příloha č. 2) bez kryptování - jako prostý text,

což je možné vnímat jako možné bezpečnostní riziko. Hesla uživatelů jsou přístupné

minimálně správci DBMS.

6.6 Závěrečné shrnutí

Při testování funkčnosti systému GeoNetwork, byla odhalena celá řada nedostatků.

Testovaná verze je stále předmětem vývoje, dá se předpokládat, že před vypuštěním stabilní

verze budou některé z identifikovaných nedostatků odstraněny.

Největší problémy byly identifikovány v editoru metadatových záznamů a harvestingu

GeoNetwork.

49

7 Úprava uživatelského rozhraní GeoNetwork

Následující kapitola se věnuje popisu možnostem škálovatelnosti systému GeoNetwork.

V úvodu jsou nastíněny možnosti úprav vzhledu uživatelského rozhraní, závěr kapitoly se pak

věnuje rozšíření funkcionality GeoNetwork. Veškeré níže popsané úpravy systému

GeoNetwork jsou umožněny díky schopnostem systému Jeeves (viz. kap. 5.5).

7.1 Úprava vzhledu GeoNetwork

Vizuální prezentaci GeoNetwork je možné upravit prostřednictvím editace:

� XSL dokumentů určených k vizualizaci,

� CSS kaskádových stylů [10].

Editací XSL dokumentů, které jsou uložené v adresáři web/xsl, je možné dosáhnout změny

generovaného HTML kód a tudíž i změny rozložení generovaných stránek. Příklad

pozměněného souboru web/xsl/banner.xsl je uveden v příloze číslo 3.

Editací kaskádových stylů CSS [10] je možné dosáhnout úpravy vizuální prezentace

generovaných HTML kódů. Kaskádové styly jsou uloženy v souboru web/geonetwork.css.

7.2 Lokalizace GeoNetwork do národního prostředí

V současnosti je GeoNetwork kompletně přeložen do čtyř světových jazyků:

� Angličtina,

� Francouzština,

� Španělština,

� Čínština.

Díky použitému kódování znaků (UNICODE) a zvolené technologii (viz. kap. 5.5.2),

je možné GeoNetwork lokalizovat prakticky do libovolného národního prostředí. Tato

kapitola popisuje postup, použitý při lokalizaci GeoNework do Českého jazyka.

Celý proces lokalizace je možné shrnout do tří základních kroků. V prvním kroku bylo

nutné upravit stávající menu GeoNetwork, sloužící pro změnu jazyka. Toto menu je

nadefinováno v souboru web/xsl/banner.xsl. Do tohoto souboru byl na patřičné místo přidán

následující kód:

50

<xsl:choose>

<xsl:when test="/root/gui/language=' cs'">

<font class="banner-active"><xsl:value-of select="/root/gui/strings/ cs"/></font>

</xsl:when>

<xsl:otherwise>

<a class="banner" href="{/root/gui/service}/ cs/main.home"><xsl:value-of select="/root/gui/strings/ cs"/></a>

</xsl:otherwise>

</xsl:choose>

Obr. 28 XML kódu upravující menu pro volbu lokalizace GeoNetwork

Ve druhém kroku byl upraven obsah souboru web/loc/en/xml/string.xml, obsahující

jednotlivé používané řetězce. Zde byl přidán následující jednoduchý kód:

<cs> Čeština</cs>

Obr. 29 XML kód pro rozšíření seznamu řetězců o řetězec Čeština

Ve třetím kroku byl okopírován obsahu složky web/loc/en, do složky web/loc/cs.

Samotná lokalizace pak spočívá v přeložení hodnot elementů všech XML dokumentů,

uložených ve web/loc/cs/xml a úpravě obrázků, uložených v adresáři web/loc/cs/images.

7.3 Přidání statické internetové stránky

GeoNetwork je možné rozšířit o libovolnou statickou webovou stránku, postup rozšíření je

možné shrnout do třech následujících kroků.

V prvním kroku je nutné vytvořit nový XML dokument např. examplepage.xml, a ten

umístit do složky web/loc/en/xml (pozn. umístění souboru se může lišit). Obrázek číslo 30

zobrazuje příklad kódu XML dokumentu.

<?xml version="1.0" encoding="UTF-8"?> <examplepage> <title>Titulek stranky</title> <content> <h1>Hlavní nadpis</h1> <p>zde bude text</p> </content> </examplepage>

Obr. 30 Ukázka XML kódu nové statické webové stránky (examplepage.xml)

Ve druhém kroku je nutné určit, na základě jakého XSL bude nově vytvořená stránka

transformována do HTML. Pro transformaci je možné využít například soubor page.xsl, který

51

je standardní součástí GeoNetwork. Tuto skutečnost je nutné nadefinovat v souboru,

web/WEB-INF/config.xml prostřednictvím následujícího kódu:

<service name="examplepage"> <output sheet="page.xsl"> <xml name="page" file="xml/examplepage.xml" /> </output> </service>

Obr. 31 Ukázka XML kódu pro přidání nové stránky (config.xml)

V posledním kroku je potřeba nadefinovat nová přístupová práva, k vytvořené stránce, pro

jednotlivé profily. Stránku je možné zpřístupnit přidáním následujícího kódu do souboru

web/xml/user-profiles.xml.

<allow service="examplepage"/>

Obr. 32 Ukázka XML kódu pro změnu privilegií přístupů (user-profiles.xml)

Veškeré provedené změny se projeví po restartování aplikačního serveru. Nově vytvořena

stránka je dostupná typicky na adrese: http://localhost:8080/geonetwork/srv/en/examplepage.

7.4 Rozšíření funkcionality GeoNetwork

Rozšíření funkcionality GeoNetwork je složitější a vyžaduje zásah do zdrojových kódů

GeoNetwork. Také v tomto případě je využito schopností systému Jeeves, který vnímá

jednotlivé funkcionality sytému, jako samostatně stojící služby (services). Z těchto služeb je

poskládána celková funkcionalita GeoNetwork.

Nově vytvářená služba, v podobě třídy Java, musí implementovat rozhraní service

systému Jeeves. Toto rozhraní definuje dvě veřejné metody [36]:

� void init(java.lang.String appPath, ServiceConfig params),

� Element exec(Element params, ServiceContext context).

Metoda init je volána při inicializaci služby. Metoda exec je spouštěna při volání služby,

výstupem této metody je objekt typu org.jdom.Element [34]. Minimální podoba této třídy je

uvedena v příloze číslo 4. Služby jsou nejběžněji umístěny v adresáři services (viz. zdrojové

kódy GeoNetwork).

Aby bylo novou službu možné spustit, je potřeba upravit patřičné konfigurační soubor

(web/WEB-INF/config.xml) a nastavit přístupová privilegia (web/xml/user-profiles.xml).

Obdobně jako v případě vytváření statické webové stránky. Poté je možné přistoupit ke

kompilaci všech zdrojových kódů (viz. příloha číslo 6) a násadné instalaci GeoNetwork (viz.

příloha číslo 7).

52

7.5 Závěrečné shrnutí

GeoNetwork je možné velmi dobře rozšířit a přizpůsobit uživatelským požadavkům

a potřebám. Rovněž je možné GeoNetwork jednoduše přeložit do národního jazyka. Autorem

českého překladu GeoNetwork 2.0.3 je Ing. Jan Růžička, Ph.D. (VŠB-TUO, Institut

geoinformatiky). V současné době je dle jeho vyjádření přeloženo zhruba 80% celého

komunikačního rozhraní.

53

8 Současné možnosti komunikace katalog ů

Tato kapitola popisuje současné možnosti technologii, podporující komunikaci mezi

katalogy. Začátek kapitoly ve stručnosti popisuje komunikační protokol Z39.50. Zbytek

kapitoly je věnován OGC Catalogue Services (dále jen katalogové služby).

8.1 Standard ANSI/NISO Z39.50 – ISO 23950

Komunikační protokol Z39.50 je první ze dvou technologii, které v současné době

umožňují vzájemné propojení katalogů. Z počátku byl tento protokol určen výhradně pro

vyhledávání bibliografických informací. Avšak postupem času byl upraven, prostřednictvím

profilů, také pro potřeby jiných odvětví. Protokol Z39.50 zde pak představuje pouze

komunikační rámec, který je možné využít pro přenos libovolných informací, tudíž

i metadat o informačních zdrojích [29].

Pro oblast geoinformatiky existují dva základní profily [13]:

� Z39.50 Application Profile for Geospatial Metadata – Geo Profile; Version 2.2;

19.04.1999 [82]

� Catalogue Interoperability Protocol - (CIP) Profile 06.1998 [13]

Z39.50 byl doposud vydán ve třech verzích, v roce 1998 byl přijat jako mezinárodní

norma ISO 23950 Information retrieval Z39.50 – Application service definition and protocol

specification [13], [29]. Praktické zkušenosti s implementací katalogových služeb 1.0 nad

tímto protokolem popisuje kapitola číslo 9.2.

8.2 Katalogové služby

Katalogové služby, jsou z pohledu OGC, klíčovou technologii uzpůsobenou pro sdílení,

vyhledávání, publikování a spravování popisných informací (metadat), prostřednictvím

distribuované sítě. Z tohoto důvodu je katalogovým službám věnován výrazně větší prostor

[51], [13].

OGC se zabývá specifikací katalogových služeb od roku 1999, kdy byla zveřejněna verze

1.0, ta je dnes považována za překonanou. Pozornost tedy bude nadále věnována pouze

poslední dostupné verzi katalogových služeb, a sice verzi 2.0.1, která byla zveřejněna v roce

2005 [13].

54

8.2.1 Architektura katalogových služeb

Obr. 33 Schéma základní architektury katalogových služeb (vytvořeno dle [13])

Katalogové služby zprostředkovávají vztah mezi klienty (Application clients) a lokálním

úložištěm metadat – katalogem (Metadata Repository). Nepřímo zprostředkovávají také vztah

mezi informačními zdroji (Resources) a klienty. Díky distribuovanému vyhledávání

(Distributed Search) dokáží zprostředkovat také vztah mezi klienty a vzdálenými úložišti

metadat (viz. [13] Annex B) [13].

Klienti zasílají své požadavky skrze rozhraní OGC Catalog interface. Toto rozhraní je

popsáno prostřednictvím abstraktního modelu (viz. kap. 8.2.2) [13].

8.2.2 Abstraktní model rozhraní katalogových služeb

Základní abstraktní model rozhraní OGC Catalog interface je uveden v příloze číslo 9.

Rozhraní OGC Catalog interface je definováno prostřednictvím objektu CatalogServices,

který je složen z těchto několika tříd [13]:

� OGC_Service – třída umožňuje prostřednictvím operace GetCapabilities získat

informace o poskytované službě;

� Discovery – třída poskytuje metody určené pro prohledávání zdrojů uchovávaných

v katalogu;

� Manager – třída poskytuje metody pro správu záznamů uložených v katalogu;

� BrokeredAccess – třída umožňuje zprostředkovat přístup ke zdrojům evidovaným

v katalogu.

Specifikace katalogových služeb [13] popisuje tři instance objektu CatalogServices.

Každá z těchto instancí je postavena na jiném komunikačním protokolu:

Catalogue services

Application clients

Metadata repository Resources describes

Distributed Search

OGC Services interface

OGC Catalogue interface

CS CS

CS

55

� Z39.50 – (popsána v [13] kap. č. 8),

� CORBA/IIOP (popsána v [13] kap. č. 9),

� HTTP.

Instance CatalogServices postavena na komunikačním protokolu HTTP [28], je také

nazývána Catalogue Services for Web (dále jen CSW), této instanci se věnuje kapitola číslo

8.4 [13].

8.3 Katalogové služby a podpora interoperability

Jedním z nejdůležitějších cílů katalogových služeb je zvýšit interoperabilitu . Z tohoto

důvodu musí každá instance katalogových služeb podporovat následující [13]:

� Core queryable properties,

� Common Catalogue Query Language (dále jen CQL),

� Core returnable properties.

8.3.1 Core queryable properties

Core queryable properties – jsou definovány jako minimální množina společných

stěžejních atributů, na něž je možné se dotázat libovolné instance katalogových služeb [13].

Tab. 2 Přehled společných atributů pro dotazování - Core queryable properties [13]

Jméno atributu Popis Subject Hlavní téma obsahu zdroje Title Pojmenování zdroje Abstract Shrnutí obsahu zdroje AnyText Libovolný text obsažený v metadatovém záznamu (full-

text prohledávání) Format Formát popisovaného zdroje Identifier Jednoznační identifikátor zdroje Modified Datum poslední modifikace zdroje Type Podstata nebo typ zdroje BoundingBox Obalový obdélník – oblast zájmu CRS Souřadný systém Association Zdroj

8.3.2 CQL

CQL je jednotný společný dotazovací jazyk, který je definován přímo v rámci specifikace

katalogových služeb [13]. Svojí syntaxí se tento jazyk podobá jazyku SQL. XML podoba

56

jazyka CQL je popsána samostatně ve specifikaci Filter Encoding Implementation

Specification [20], [13].

8.3.3 Core returnable properties

Core returnable properties (nebo také OGC Core Elements) – je množina stěžejních

elementů, které je možné v odpovědi požadovat po libovolné instanci katalogových služeb.

Tyto elementy jsou odvozeny od Dublin Core elementů (viz. kap. 1.1.2) [18], díky tomu je

zaručena návaznost katalogových služeb také mimo oblast geoinformatiky [13]. Seznam OGC

Core elements je uveden v příloze číslo 5.

8.4 Katalogové služby pro web (CSW)

CSW jsou instancí abstraktního modelu katalogových služeb (viz. kap. 8.2.2), která

využívá pro realizaci interakce mezi klientem a serverem komunikační protokol HTTP [28].

CSW vychází ze specifikace OWS (viz. kap. 2.3). Obrázek číslo 34 zobrazuje konceptuální

schéma CSW [13].

Obr. 34 Konceptuální schéma CSW – rozdělení operací [13]

Klienty katalogových služeb je možné rozdělit do dvou skupin na:

� Konzumenty metadat (Metadata Consumer),

� Producenty metadat (Metadata Producer).

CSW nabízí těmto klientům celkem sedm operací, tyto operace jsou volány stejným

způsobem jako v případě OWS (viz. kap. 2.3). Přehled dostupných operací CSW, včetně

vyznačení povinností, je uveden v příloze číslo 10. Všem operacím (kromě GetCapabilities)

je nutné předávat tyto povinné parametry [13]:

CSW

Metadata Consumer Metadata Producer

Harvest

Transaction

GetCapabilities

GetRecords

DescribeRecord

GetRecordById

GetDomain

57

� request – uchovává jméno operace (GetDomain, GetRecords a podobně),

� service – uchovává jednoznačný identifikátor požadované služby,

� version – uchovává verzi požadované služby.

8.4.1 Operace GetCapabilities

Tato povinná operace umožňuje klientovy získat popisné informace (metadata)

o poskytované službě. Vychází z operace GetCapabilities specifikované v [50] (viz. kap. 2.3).

Pro vyvolání operace GetCapabilities je potřeba zaslat požadavek na server, obsahující

minimálně dva povinné parametry service a request. Dále je možno zaslat několik

nepovinných parametrů, které jsou popsány v [50] případně v [13]. V závislosti na tomto

požadavku je možné obdržet tyto informace [13]:

� ServiceIdentification – obsahuje základní informace o poskytované službě,

� ServiceProvider – obsahuje informace o poskytovateli služby,

� OperationsMetadata – obsahuje přehled dostupných operací,

� Filter_Capabilities – obsahuje popis elementů, které jsou podporovány.

8.4.2 Operace DescribeRecord

DescribeRecord je povinná operace, umožňující prozkoumat části informačního modelu,

podporované danou instancí katalogových služeb. Nejdůležitějším povinným parametrem této

operace je parametr namespace, který slouží pro určení požadovaného jmenného prostoru.

Odpověď na volání této operace nejčastěji obsahuje část definičního schématu XSD [13].

8.4.3 Operace GetDomain

Nepovinná operace GetDomain slouží k získání informací o skutečném rozsahu hodnot

elementů metadatového schématu. Informace o skutečném uchovávaném rozsahu elementů

může být využitá například při návrhu „chytrého“ klienta – který neumožní zadání parametru

překračujícího rozsah [13].

8.4.4 Operace GetRecords

Operace GetRecords je bezesporu nejdůležitější povinnou operací, která umožňuje

vyhledávání metadatových záznamů uložených v katalogu. Prostřednictvím této operace je

možné požádat o množinu záznamů, které splňují požadované kriterium. Toto kriterium je

58

předávání prostřednictvím parametru constrain (omezení), v podobě CQL [13] dotazů či

XML kódu FILTER [20].

Prostřednictvím vstupních parametrů operace GeoRecords je možné [13]:

� zvolit schéma navracených metadatových záznamů (outputSchema);

� omezit maximální počet navrácených metadatových záznamů (maxRecords)

a startovní pozici ve skupině záznamů (startPosition);

� zvolit rozsah obdržených metadatových záznamů (resultType);

� zvolit způsob řazení záznamů (SortBy);

� formát výstupu (outputFormat).

Operace GetRecords umožňuje také asynchronní zpracování požadavku.

Prostřednictvím parametru ResponseHandler je možné zvolit místo, kam má být

přesměrována odpověď, po dokončení zpracování. Asynchronní zpracování požadavku je

výhodné zejména v případě distribuovaného vyhledávání, které může být časově náročnější.

Distribuované vyhledávání je možné aktivovat prostřednictvím parametru

DistributedSearch [13].

8.4.5 Operace GetrecordById

GetRecordById je povinná operace, které na rozdíl od GetRecords, umožňuje získat

pouze jediný záznam. Tento metadatový záznam je identifikován na základě jednoznačného

identifikátoru, který je předán parametrem id. Metadatový záznam není před návratem nijak

upraven, je navrácen v té podobě, v jaké uložen do katalogu [13].

8.4.6 Operace Transaction

Nepovinná operace Transaction umožňuje provádět následující transakce:

� Insert – slouží pro vložení jednoho nebo skupiny metadatových záznamů do

katalogu (pozn. katalog musí dokázat uchovat předávané schéma);

� Update – slouží k úpravě metadatových záznamů uchovávaných v katalogu,

záznamy jsou vybrány prostřednictvím parametru constrain (omezení);

� Delete – slouží k mazání metadatových záznamů uchovávaných v katalogu,

záznamy jsou vybrány prostřednictvím parametru constrain (omezení).

Operace Transaction vrací v odpovědi souhrn informací o provedené transakci, jako

například počet vložených, smazaných případně upravených záznamů a podobně [13].

59

8.4.7 Operace Harvest

Nepovinná operace Harvest dokáže „sklidit“ obsah metadatového katalogu ve smyslu

stažení obsahu katalogu.

Pokud je nastaven parametr HarvestInterval dochází k opakovanému zpracování

zaslaného požadavku, ve zvoleném časovém intervalu. Což v kombinaci s asynchronním

zpracováním požadavku (parametr ResponseHandler), vede k neustálému periodickému

zasílání aktuálního obsahu katalogu na zvolené místo. Požadavek je jednoznačně

identifikován na základě obsahu parametru Source.

8.4.8 Zhodnocení CSW

Během zkoumání specifikace katalogových služeb bylo zjištěno, že existuje dvojí výklad

obsahu povinného parametru service. Dle [13] by měl parametr obsahovat řetězec „CSW“

avšak dostupné XML schéma [46] uvádí jako výchozí hodnotu

„http://www.opengis.net/cat/csw“. Oba tyto výklady jsou normativní, avšak na základě [50] je

žádoucí se přiklánět k první variantě (tedy CSW). Dále byl zjištěn nesoulad v pojmenování

parametrů u některých operací, tento nesoulad částečně řeší Annex E.

Katalogové služby OGC v současnosti prochází revizí, která by měla vyústit k přijetí verze

OGC Catalog Services 2.0.2 (pozn. tato verze byla zveřejněna 23. 2. 2007).

8.5 Závěrečné shrnutí

Schopnosti současných technologií podporující komunikaci mezi katalogy jsou

dostačující. Prostřednictvím výše zmíněných technologii je možné vytvořit komunikační

rozraní mezi národním metaportálem a metainformačními systému, které již v České

republice existují. Avšak v případě katalogových služeb OGC bude potřeba vyjasnit některé

nejasnosti, nejlépe vytvořením a přijetím národního profilu katalogových služeb OGC.

60

9 Komunika ční rozhraní GeoNetwork

Tato kapitola popisuje komunikační rozhraní GeoNetwork, věnuje se zejména praktickým

poznatkům, získaným při testování.

Obr. 35 Schéma komunikačního rozhraní GeoNetwork

GeoNetwork nabízí několik cest (formátů, technologii), prostřednictvím kterých je možné

prohledávat, nebo získat obsah katalogu:

� HTML

� CSW (viz. kap. 9.1)

� CS 1.0 - Katalogové služby 1.0 (viz. kap. 9.2)

� Harvesting GeoNetwork (viz. kap. 9.3)

� RSS a GeoRSS (viz. kap. 9.4)

K přenosu požadavků mezi klientem a serverem (GeoNetwork) je možné využít dva

komunikační protokoly a sice HTTP a Z39.50, jak je naznačeno na obrázku číslo 35.

9.1 Implementace CSW v GeoNetwork

Systém GeoNetwork implementuje CSW 2.0.1 (viz. kap. 8.4). Komunikační rozhraní

CSW je typicky dostupné na adrese http://localhost:8080/geonetwork/srv/en/csw. Tabulka

číslo 3 poskytuje přehled operací CSW s popisem podpory v GeoNetwork.

Clie

nt

CSW

Harvesting

RSS

GeoRSS HTTP

Z39.50

HTML

CS 1.0

Cat

alog

Geo

Net

wor

k

61

Tab. 3 Přehled rozsahu implementace operací CSW v GeoNetwork

Operace Implementována Podporované parametry GetCapabilities Plně Všechny DescribeRecord Plně Všechny GetDomain Nepodporuje GetRecords Částečně Povinné a část nepovinných GetRecordById Plně Všechny Harvest Nepodporuje Transaction Nepodporuje

Při srovnání tabulky číslo 3, a tabulky uvedené v příloze číslo 10, je vidět, že GeoNetwork

implementuje pouze povinné operace.

Nejdůležitější implementovanou operací je operace GetRecords, přehled podporovaných

parametrů je uveden v příloze číslo 11. Co do podpory interoperability (viz. kap. 8.3) je

implementována podpora Core queryable properties a Core returnable properties.

Pokud se jedná o implementaci dotazovacích jazyků, podporuje GeoNetwork jak CQL tak

FILTER [20]. Rozsah implementace jazyka FILTER je uveden v tabulce číslo 4.

Tab. 4 Přehled rozsahu implementace dotazovacího jazyka FILTER

FILTER Podpora

Geometrické operandy (GeometryOperands)

gml:Envelope

Prostorové operátory (SpatialOperators)

BBOX

Logické operátory (LogicalOperators)

EqualTo, Like, LessThan, GreaterThan, LessThanEqualTo, GreaterThanEqualTo,

NotEqualTo, Between Aritmetické operátory (ArithmeticOperators)

nepodporováno

9.1.1 Způsob testování implementace CSW

Pro testování implementace CSW byl použit speciální klient, vytvořený za tímto účelem.

K vývoji vlastního klienta bylo přistoupeno zejména proto, že jedině tímto způsobem bylo

možné získat plnou kontrolu nad podobou zasílaných dotazů. Klient byl napsán v jazyce C#

.NET prostřednictvím nástroje Borland Turbo C# Professional [8], které je dostupný zdarma.

62

Obr. 36 Ukázka grafického rozhraní vytvořeného testovacího klienta CSW

Testovací klient umožňuje zasílat požadavky metodou POST i GET protokolu HTTP.

Tento klient dokáže vygenerovat požadavky na následující operace:

� GetCapabilities,

� GetRecords,

� GetRecordById.

9.1.2 Zhodnocení implementace CSW

GeoNetwork implementuje CSW do té míry, že umožňuje jednorázově získat záznamy

uložené v katalogu prostřednictvím operace GetRecords případně GetRecordById.

GeoNetwork neimplementuje transakční operace (Transaction) a rovněž není implementován

harvesting (Harvest).

V případě operace GetRecords z množiny podporovaných parametrů plyne, že

GeoNetwork neumožňuje distribuované vyhledávání ani asynchronní zpracování požadavků.

9.2 Katalogové služby 1.0

Systém GeoNetwork implementuje OGC Catalog Services 1.0 [48]. Rozraní katalogových

služeb 1.0 je dostupné prostřednictvím protokolu Z39.50, nejčastěji na portu 2100.

Implementace katalogových služeb 1.0 byla otestována dvěma způsoby. Prostřednictvím

Z39.50 klienta gvSIG 1.0 [26] a prostřednictvím samotného GeoNetwork.

63

Geonetwork využívá rozhraní katalogových služeb 1.0 pro funkci Vzdáleného

vyhledávání (Remote Search), které je popsáno v kapitole číslo 6.1.2. V rámci testování této

funkcionality, byl stávající seznam uzlů vzdáleného vyhledávání rozšířen o MIDAS

GeoNetwork VŠB [43]. Seznam uzlů se nachází v souboru web/xml/repositories.xml,

upravený soubor repositories.xml, je uveden v příloze číslo 1.

9.2.1 Zhodnocení implementace katalogových služeb 1.0

Během testování katalogových služeb 1.0 nebyly identifikovány žádné problémy. Systém

je schopen spolupracovat jak s Z39.50 klientem, tak s další instancí GeoNetwork. Je nutné

připomenout, že rozhraní katalogových služeb 1.0 je v současnosti považováno za překonané

a je plně nahraditelné novou verzí katalogových služeb [13] (viz. kap. 8.2).

9.3 Harvesting GeoNetwork

Harvesting GeoNetwork (viz. kap. 6.4.1) je postaven na komunikačním protokolu HTTP.

Pro zasílání požadavků je využívána metoda POST, veškeré požadavky jsou zakódovány

v XML. Komunikace typicky probíhá následovně:

� Přihlášení ke vzdálenému uzlu GeoNetwork

� Spuštění vyhledávání metadat

� Stažení metadat (metadata jsou identifikovány na základě UUID a data změny)

� Odhlášení od vzdáleného uzlu

Harvesting GeoNetwork je přírůstkový, což znamená, že jsou staženy jen ty záznamy,

které byly od posledního harvestingu změněny. Změněná, případně nová metadata, jsou

automaticky vložena do lokálního katalogu [9].

9.3.1 Zhodnocení harvestingu GeoNetwork

Komunikační rozhraní Harvestingu GeoNetwork není zdokumentované, tudíž jej není

možné bez rozsáhlého studia zdrojových kódů využít. Bylo primárně vytvářenou pouze za

účelem propojení instancí systémů GeoNetwork a sdílení informací mezi nimi. Toto rozhraní

bylo implementováno před uvolněním specifikace katalogových služeb OGC [13], tudíž není

s tímto rozhraním kompatibilní. Je možné očekávat, že do budoucna bude toto rozhraní

nahrazeno harvestingem v té podobě, jak jej specifikují katalogové služby OGC [13] (viz.

kap. 8.2).

64

9.4 RSS a GeoRSS

GeoNetwork publikuje poslední přidané metadatové záznamy prostřednictvím RSS kanálu

[55] a GeoRSS kanálu [23] (pozn. GeoRSS v je rozšířením specifikace RSS). Oba tyto

formáty jsou postaveny na jazyku XML, tudíž je možné je velmi jednoduše zpracovat

strojově. Tyto formáty rovněž možné zařadit do komunikačního rozhraní GeoNetwork.

GeoNetwork generuje RSS kanály odpovídající specifikaci RSS2.0 [55].

RSS kanál obsahuje pouze informace o titulku (title) a abstraktu (abstract) nových

metadat, GeoRSS obsahuje navíc informace o geografické poloze popisovaných geodat.

Typicky je toto rozhraní dostupné například na adrese

http://localhost:8080/geonetwork/srv/en/rss.latest.

9.5 Závěrečné shrnutí

GeoNetwork nabízí několik možností, prostřednictvím kterých je možné získat obsah

katalogu. Z pohledu budování národního metaportálu se jeví jako nejperspektivnější

komunikační rozhraní CSW. Nicméně testovaná verze GeoNetwork toto komunikační

prozatím zatím nepodporuje v plné šíři. Implementované vzdálené vyhledávání a harvestingu

GeoNetwork jsou postaveny na jiných technologických základech než CSW.

65

10 Zhodnocení GeoNetwork

Původně tato kapitola měla porovnávat schopnosti systému GeoNetwork s požadavky na

národní metaportál, které měly být dodány státní správou. Nicméně tyto požadavky nebyly

v průběhu zpracování této práce dodány. Z těchto důvodů byl systém GeoNetwork posuzován

z hlediska vlastních zkušeností autora. Tato kapitola shrnuje a hodnotí poznatky získané

během testování GeoNetwork.

10.1 Požadavky na uživatele GeoNetwork

Požadavky na uživatele ze strany systému GeoNetwork je možné vnímat dvojím

způsobem a sice z pohledu:

� Běžného uživatele,

� Administrátora systému.

Na běžného uživatele jsou kladeny ze strany GeoNetwork minimální nároky . Uživatel

vystačí pouze se znalostí práce s webovým prohlížečem. Instalace desktop varianty systému

GeoNetwork také nevyžaduje žádné rozsáhlé dovednosti, uživatel musí být schopen

nainstalovat aplikaci s využitím instalačního průvodce. Pokud jde o jazykové znalosti, vystačí

se základní znalostí anglického jazyka (pozn. instalační program je v anglickém jazyce).

Na administrátora systému jsou kladeny mnohanásobně vyšší nároky. Administrátor

systému by měl:

� dokázat vytvořit novou databázi v DBMS a nastavit k této databází práva přístupu,

� rozumět problematice komunikace mezi klientem a serverem,

� být obeznámen s webovými technologiemi (jako například HTML, CSS, XSL,

XSD, XML a podobně),

� rozumět principům platformy Java,

� být schopen pracovat s příkazovou řádkou OS,

� a podobně.

10.2 Uživatelská podpora GeoNetwork a dokumentace

Veškerá uživatelská podpora je dostupná prostřednictvím oficiálních stránek projektu

GeoNetwork. Na stránkách [21] je možné získat dokumentaci, návody, referenční manuály

a podobně. Dále je možné získat uživatelskou podporu v podobě emailové konference, a to

66

buď jako běžný uživatel nebo jako vývojář systému. Veškerá uživatelská podpora je dostupná

výhradně v anglickém jazyce.

Celkově je možné hodnotit Uživatelskou podporu systému GeoNetwork jako dostačující.

10.3 Instalace GeoNetwork

Během testování bylo provedeno několik instalací a odinstalací různých verzí systému

GeoNetwork. Instalační balíček se vždy choval dle očekávání a proces instalace se obešel bez

jakýchkoliv závažných obtíží. Souhrnně je možné označit proces instalace za jednoduchý

a bezproblémový. Návod na instalaci GeoNetwork je uveden v příloze číslo 7.

10.4 Provoz GeoNetwork

Jako velmi pozitivní je možné hodnotit to, že GeoNetwork dokumentuje své spouštění

a provoz prostřednictvím celé řady log souborů. Systém GeoNetwork byl při testování

provozován jak na OS Windows tak na OS Linux, pod aplikačním serverem Jetty 5.1

a Apache Tomcat 5.5. Jako DBMS byly otestovány systémy McKoi SQL 1.0.3 a MySQL 5.0.

Po celou dobu testovacího provozu se GeoNetwork choval stabilně. Nicméně během

testování nebyl systém podroben dostatečné zátěži, tudíž není možné spolehlivě posoudit, jak

se bude chovat do budoucna.

10.5 Dodržování standardů a norem

Během testování bylo zjištěno, že GeoNetwork nedodržuje v plné šíři standard HTML

[71], většina generovaných výstupů (stránek) obsahuje celou řadu chyb. Tyto chyby je však

možné odstranit prostřednictvím úprav vizuální prezentace GeoNetwork, která je popsána

v kapitole číslo 7.1. Dále bylo zjištěno, že GeoNetwork nerespektuje zásady definované

v [79] o zvyšování přístupnosti webových stránek.

I přes tyto problémy je však možné prohlásit, že se vývojáři GeoNetwork snaží dodržovat

veškeré používané normy a standardy.

10.6 Použité technologie

Jak již bylo zmíněno, GeoNetwork využívá pro dosažení své funkcionality technologie,

které jsou vyvíjeny řadu let. Dá se předpokládat, že vývoj těchto technologii bude pokračovat

i do budoucna.

67

Veškeré technologie, které GeoNetwork využívá, jsou postaveny na platformě Java. Což

poskytuje systému GeoNetwork jednu velkou konkurenční výhodu, a sice nezávislost na

hardware a operačním systému.

GeoNetwork je možné provozovat nad celou řadou DBMS, jelikož využívá

standardizované rozhraní JDBC.

GeoNetwork využívá pro indexaci veškerých údajů uložených v katalogu výkonný nástroj

Apache Lucene. Tento nástroj je schopný zpracovat velké množství dat, ve velmi krátkém

čase (pozn. test výkonnosti systému je dostupný v [5]).

10.7 Funkcionalita systému

Funkcionalitu systému GeoNetwork je možné označit jako dostačující nikoliv však

vyhovující. Nicméně je nutné opět připomenout, že byla testována verze, který je předmětem

vývoje.

Největší nedostatky vykazoval editor metadatových záznamů. Editor metadatových

záznamů je možné označit za jednu z hlavních vstupních bránu každého metainformačního

systému. Tudíž by jeho vývoji měla být věnována patřičná pozornost. Vytvořený editor by

měl být intuitivní, přehledný, přívětivý a jednoduchý.

Obdobné problémy, jež byly identifikovány u editoru metadatových záznamů

GeoNetwork, je možné nalézt také v celé řadě jiných systému. Tyto problémy pramení mimo

jiné z toho, že doposud nebylo definováno schéma normy ISO 19115. Tato skutečnost dává

vývojářům jakéhokoliv metainformačního systému velmi špatné startovní podmínky.

Celá řada nedostatků byla identifikována také při testování harvestingu GeoNetwork.

Pozitivně je možné zhodnotit vyhledávací schopnosti systému GeoNetwork, ten umožňuje

prohledávání jak lokálních tak vzdálených katalogů.

10.7.1 Nastavení systému

Veškerá nastavení systému GeoNetwork je možné realizovat pouze prostřednictvím

editace konfiguračních souborů. Administrátor systému nemá možnost do nastavení

GeoNetwork zasáhnout prostřednictvím webového rozhraní.

10.8 Úprava uživatelského rozhraní a rozšiřitelnost

GeoNetwork je možné velmi dobře rozšířit a přizpůsobit, dle potřeb uživatele a to včetně

překladu celého systému do národního jazyka.

68

10.9 Komunikační rozhraní

Kvalitní komunikační rozhraní je jednou z podmínek bezproblémového chodu národního

metaportálu. Národní metaportál musí být schopen interoperability s jinými systémy, vyplývá

to z jeho podstaty.

Zkoumaná testovací verze GeoNetwork nenabízí dostatečné možnosti, prostřednictvím

kterých by jej bylo možné snadno a efektivně propojit z jinými metainformačními systémy.

Komunikační rozhraní je nevyhovující z těchto důvodů:

� Katalogové služby jsou implementovány pouze částečně (viz. kap. 9.1)

� Vzdálené vyhledávání je postaveno na technologii (pozn. katalogové služby 1.0),

která je v současnosti považována za překonanou

� Harvesting, v té podobě jak je implementovaný umožňuje propojit pouze systémy

stejného typu

10.10 Cena GeoNetwork

Nespornou výhodou systému GeoNetwork je to, že je dostupný zdarma pod licencí GNU

[25].

69

11 Spolupráce systém ů GeoNetwork a MIcKA

Tato kapitola popisuje tvorbu komunikačního rozhraní mezi systémy GeoNetwork

a MIcKA. Toto komunikační rozhraní bylo vytvořeno na základě spolupráce se správcem

systému MIcKA RNDr. Štěpánem Kafkou.

11.1 Charakteristika systému MIcKA

MIcKA je metainformační systém, umožňující komplexní správu a pořizování metadat

prostřednictvím internetu. Tento metainformační systém je vyvíjen firmou Help Servis

Remote Servis. Metainformační systém MIcKA umožňuje správu dat odpovídající normě ISO

19115. Do budoucna se s tímto systémem počítá jako s jedním ze vstupních uzlů pro národní

metaportál [42].

Metainformační systém MIcKA implementuje CSW verze 2.0.1 (viz. kap. 8.4). MIcKA

podporuje operace GetRecords, GetRecordByID a GetCapabilities. Podporovány nejsou

operace DescribeRecord, GetDomain, Harvest a Transaction.

Co do podpory interoperability (viz. kap. 8.3) je implementována podpora Core queryable

properties a Core returnable properties. Jediným podporovaným dotazovacím jazykem je

jazyk FILTER [20].

11.2 Propojení systémů GeoNetwork a MIcKA

Komunikační rozhraní mezi systémy GeoNetwork a MIcKA bylo vybudováno nad

katalogovými službami. Oba tyto systémy implementují rozhraní CSW, avšak ani jeden

z těchto systémů jej neimplementuje plně. Díky těmto nepříznivým výchozím podmínkám

bylo možné vybudovat pouze propojení ze systému MIcKA do systému GeoNetwork. Ve

výsledku byl katalogový klient systému MIcKA schopen prohledávat obsah katalogu

testovacího serveru MIDAS GeoNetwork VŠB [43].

Oba výše uvedené systémy jsou v současné době předmětem vývoje. Budou-li do

budoucna plně implementovat rozhraní katalogových služeb, nebude nic bránit jejich

obousměrnému propojení.

70

Závěr

Cílem této práce bylo posoudit vlastnosti systému GeoNetwork s ohledem na jeho

uplatnitelnost pro účely vybudování národního metaportálu České Republiky.

Národní metaportál by měl tvořit jednu ze stěžejních částí národní metainformační

infrastruktury. V úvodu se tato práce zabývá popisem základních stavebních prvků

metainformační infrastruktury, vysvětluje některé důležité pojmy a uvádí čtenáře do celé

problematiky. Na první kapitolu plynule navazuje kapitola 2, která popisuje vybrané

technologie běžně využívané pro budování metainformační infrastruktury.

Vývoj systému GeoNetwork je zastřešen projektem budování geoinformační

infrastruktury Spojených národů. Kapitola číslo 3 stručně popisuje tento projekt a také

zapojení České republiky do tohoto projektu. Po prostudování těchto teoretických základů

bylo konečně přistoupeno k popisu vlastností GeoNetwork.

V rámci podrobné analýzy systému GeoNetwork byly nejprve prozkoumány technické

základy, na nichž je systém GeoNetwork postaven. Přehled nejdůležitějších technologií,

s nimiž je GeoNetwork svázán, je uveden v kapitole číslo 5. Dále byla popsána funkčnost

sytému z uživatelského pohledu, výsledky shrnuje kapitola číslo 6.

Systém GeoNetwork byl prozkoumán z hlediska možnosti úprav uživatelského rozhraní.

Tuto skutečnost dokumentuje kapitola číslo 7.

Aby bylo možné popsat komunikační rozhraní systému GeoNetwork, bylo nutné se

nejprve seznámit se současným stavem technologií, podporujících komunikaci mezi

metainformačními systémy, potažmo katalogy. Pozornost byla věnována zejména

katalogovým službám OGC. Výsledky shrnuje kapitola číslo. V návaznosti na analýzu

současného stavu technologii podporujících komunikaci mezi katalogy, bylo prozkoumáno

komunikační rozhraní GeoNetwork.

Na základě veškerých zjištění byla vypracována kapitola číslo 10, která shrnuje

nejdůležitější zjištění a rovněž hodnotí systém GeoNetwork.

Jedním z dílčích cílů této práce bylo vytvořit a otestovat komunikační rozhraní mezi

systémy MIcKA a GeoNetwork. Toto komunikační rozhraní bylo vytvořeno právě nad

katalogovými službami, jak je popsáno v kapitole číslo 11.

Seznam informa čních zdroj ů

[1] Apache. Ant. [online]. [2006] [cit. 2007-01-01]. Dostupný z WWW: <http://ant.apache.org/>.

[2] Apache HTTP server [online]. 2005 [cit. 2007-01-01]. Dostupný z WWW: <http://httpd.apache.org/>.

[3] Apache Tomcat [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://tomcat.apache.org/>.

[4] Apache. Jakarta Commons [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://jakarta.apache.org/commons>.

[5] Apache. Lucene [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://lucene.apache.org/java/docs/>.

[6] Apache. Xalan Project [online]. c2005 [cit. 2007-01-01]. Dostupný z WWW: <http://xalan.apache.org/>.

[7] Background : GeoNetwork Opensource [online]. [2006] [cit. 2007-01-01]. Dostupný z WWW: <http://geonetwork-opensource.org/background>.

[8] Borland. Turbo C# Explorer Professional [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://www.turboexplorer.com/csharp>.

[9] CARBONI, Andrea. GeoNetwork RemoteHarvesting Capabilities [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://csi.cgiar.org/geonetwork/documents/harvesting.pdf>.

[10] Cascading Style Sheets [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.w3.org/Style/CSS/>.

[11] Catalog 2.0.1 Accessibility for OWS3 – Best Practices [online]. 2005 [cit. 2007-01-01]. Dostupný z WWW: <http://portal.opengeospatial.org/files/?artifact_id=12597>. Http://www.opengeospatial.org/standards/cat.

[12] Catalogue Interoperability Protocol [online]. [2005] [cit. 2007-01-01]. Dostupný z WWW: <http://wgiss.ceos.org/ics/documentation.html>.

[13] Catalogue Service Implementation Specification [online]. 20.5.2005. 2005 [cit. 2007-01-01]. EN. 04-021r3 . Dostupný z WWW: <http://www.opengeospatial.org/standards/cat>.

[14] CEN. European Committee For Standardization [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.cen.eu>.

[15] CQL-Java: a free CQL compiler for Java [online]. 2003[cit. 2007-01-01]. Dostupný z WWW: <http://zing.z3950.org/cql/java/index.html>.

[16] ČNI. Český normalizační institut [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.cni.cz/>.

[17] Degree [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://deegree.sourceforge.net>.

[18] Dublin Core Metadata Initiative [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://dublincore.org>.

[19] European Geo-Portal [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://eu-geoportal.jrc.it/>.

[20] Filter Encoding Implementation Specification [online]. 3.5.2005. 2005 [cit. 2007-01-01]. EN. 04-095 . Dostupný z WWW: <http://www.opengeospatial.org/standards/filter>.

[21] GeoNetwork opensource Community website [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://geonetwork-opensource.org/>.

[22] GeoNetwrok opensource : Quick Start Guide [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://geonetwork-opensource.org/documentation/manual/quickstartguide1.0/ GeoNetwork%20opensource%20Quick%20Start%20Guide%20v1.0.pdf>.

[23] GeoRSS [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.georss.org/>.

[24] GeoServer [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.geoserver.org>.

[25] GNU General Public License [online]. [2001] [cit. 2007-01-01]. Dostupný z WWW: <http://www.gnu.org/licenses/gpl.html>.

[26] gvSIG [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.gvsig.gva.es/>.

[27] HORÁKOVÁ, Bronislava. Metainformační infrastruktura v evropském a národním měřítku. [s.l.], 2006. 169 s. VŠB - TU Ostrava. Habilitační práce.

[28] HTTP - Hypertext Transfer Protocol [online]. 1999 [cit. 2007-01-01]. Dostupný z WWW: <http://www.ietf.org/rfc/rfc2616>.

[29] Information Retrieval (Z39.50) : Application Service Definition and Protocol Specification [online]. c2003 [cit. 2007-01-01]. EN. Dostupný z WWW: <http://www.loc.gov/z3950/agency/Z39-50-2003.pdf>. ISBN 1-880124-55-6. ISSN 1041-5653.

[30] INSPIRE: The INfrastructure for SPatial InfoRmation in Europe [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://inspire.jrc.it/>.

[31] Intermap [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://sourceforge.net/projects/intermap>.

[32] ISO. TC211/ Geographic Information/ Geomatica [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.isotc211.org/>.

[33] IzPack. [online]. [2007] [cit. 2007-01-01]. Dostupný z WWW: <http://www.izforge.com/izpack/>.

[34] Java Document Object Model [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.jdom.org/>.

[35] Java Servlets - predstavenie technológie [online]. 2003 [cit. 2007-01-01]. Dostupný z WWW: <http://interval.cz/clanky/java-servlets-predstavenie-technologie/>.

[36] Jeves [online]. 2002 , 2002 [cit. 2007-01-01]. Dostupný z WWW: <http://sourceforge.net/projects/jeeves>.

[37] Jetty WebServer [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://jetty.mortbay.org/>.

[38] Licenses - The Apache Software Foundation [online]. c2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.apache.org/licenses/>.

[39] MapServer [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://mapserver.gis.umn.edu>.

[40] MARSELLA, Marco. Jeeves Developer\'s Manual [online]. 2005. 2005 [cit. 2007-01-01]. Dostupný z WWW: <http://geonetwork.fao.org/developer/Jeeves.doc>.

[41] McKoi SQL Database [online]. c2000 [cit. 2007-01-01]. Dostupný z WWW: <http://www.mckoi.com/database/>.

[42] Metainformační katalog MIcKA [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.bnhelp.cz/bnhelp/micka.htm>.

[43] MIDAS Geonetwork VŠB [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://gis.vsb.cz:8080/geonetwork2/srv/cs/main.home>.

[44] MIKLOŠ, Josef. Metainformační systém založený na XML. Ostrava, 2004. 107 s. Vysoká škola Báňská - technická univerzita Ostrava. Diplomová práce.

[45] MySQL [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.mysql.com>.

[46] Official schema repository of the Open Geospatial Consortium [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://schemas.opengis.net/>.

[47] OGC. Geospatial Portal Reference Architecture : A Community Guide to Implementing Standards-Based Geospatial Portals [online]. verze 0.2. 2004 [cit. 2007-01-01]. Dostupný z WWW: <https://portal.opengeospatial.org/files/?artifact_id=6669>.

[48] OGC. Catalog Interface Implementation Specification (Version 1.0) [online]. 1999 [cit. 2007-01-01]. Dostupný z WWW: <http://www.opengeospatial.org/standards/cat>.

[49] OGC. Service Oriented Architecture [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.opengroup.org/projects/soa/>.

[50] OGC. Web Service Common Implementation Specification [online]. 2005 [cit. 2007-01-01]. Dostupný z WWW: <http://www.opengeospatial.org/standards/common>.

[51] Open Geospatial Consortium [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.opengeospatial.org/>.

[52] Oracle [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.oracle.com>.

[53] PostGIS [online]. 2005 [cit. 2007-01-01]. Dostupný z WWW: <http://postgis.refractions.net/>.

[54] PostgreSQL [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.postgresql.org>.

[55] RSS Advisory Board [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.rssboard.org/>.

[56] RůŽIČKA, Jan. Metadata pro prostorová data. [s.l.], 2002. 160 s. VŠB - TU Ostrava. Disertační práce. Dostupný z WWW: <http://gis.vsb.cz/seminarMetadata/>.

[57] SUN. Java API for XML processing (JAXP) [online]. c2007 [cit. 2007-01-01]. Dostupný z WWW: <http://java.sun.com/webservices/jaxp/index.jsp>.

[58] SUN. Java Servlet Technology Overview [online]. [2006] [cit. 2007-01-01]. Dostupný z WWW: <http://java.sun.com/products/servlet/overview.html>.

[59] SUN. JAVA technology [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://java.sun.com/>.

[60] SUN. Story of a Servlet: An Instant Tutorial [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://java.sun.com/products/servlet/articles/tutorial/index.html>.

[61] Technical specifications : GeoNetwork opensource [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://geonetwork-opensource.org/technical_spec>.

[62] The Federal Geographic Data Committee [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.fgdc.gov>.

[63] TortoiseCVS:About. [online]. [2006] [cit. 2007-01-01]. Dostupný z WWW: <http://www.tortoisecvs.org>.

[64] Tyrex [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://sourceforge.net/projects/tyrex/>.

[65] UDDI Universal Description, Discovery and Integration [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.uddi.org/>.

[66] UNGIWG-UNSDI Objective [online]. c2006 [cit. 2007-01-01]. Dostupný z WWW: <http://www.unsdi.cz/index.php?act=objective?=en>.

[67] United Nations Geospatial Information Working Group [online]. [2006] [cit. 2007-01-01]. Dostupný z WWW: <http://www.ungiwg.org>.

[68] United Nations Spatial Data Infrastructure : Vision, Implementation Strategy and Reference Architecture [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://www.ungiwg.org/docs/unsdi/UNSDI%20Draft%20Discussion%20Paper%2025-10-\\\'06.pdf>.

[69] United Nations Spatial Data Infrastructure - UNSDI [online]. [2005] [cit. 2007-01-01]. Dostupný z WWW: <http://www.ungiwg.org/unsdi.htm>.

[70] W3C. Extensible Stylesheet Language [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://www.w3.org/TR/xsl/>.

[71] W3C. HTML 4.01 Specification [online]. 1999 [cit. 2007-01-01]. Dostupný z WWW: <http://www.w3.org/TR/html/>.

[72] W3C. SOAP Specifications [online]. 2003 [cit. 2007-01-01]. Dostupný z WWW: <http://www.w3.org/TR/soap/>.

[73] W3C. Web Service Architecture [online]. 2004 [cit. 2007-01-01]. Dostupný z WWW: <http://www.w3.org/TR/ws-arch/>.

[74] W3C. Web Services Definition Language [online]. 2001 [cit. 2007-01-01]. Dostupný z WWW: <http://www.w3.org/TR/wsdl>.

[75] W3C. World Wide Web Consortium [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.w3.org/>.

[76] W3C. XML [online]. c1996-2003 [cit. 2007-01-01]. Dostupný z WWW: <http://www.w3.org/XML/>.

[77] W3C. XML Path Language [online]. 1999 [cit. 2007-01-01]. Dostupný z WWW: <http://www.w3.org/TR/xpath>.

[78] W3C. XML Schema [online]. [2004] [cit. 2007-01-01]. Dostupný z WWW: <http://www.w3.org/XML/Schema>.

[79] Web Content Accessibility Guidelines 2.0 [online]. 2006 [cit. 2007-01-01]. Dostupný z WWW: <http://www.w3.org/TR/WCAG20/>.

[80] Web Services and Service-Oriented Architectures [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.service-architecture.com/>.

[81] XML-RPC [online]. 2007 [cit. 2007-01-01]. Dostupný z WWW: <http://www.xmlrpc.com/>.

[82] Z39.50 Application Profile for Geospatial Metadata : Version 2.2 [online]. 27.5.2000. 2000 [cit. 2007-01-01]. Dostupný z WWW: <http://www.blueangeltech.com/standards/GeoProfile/geo22.htm>.

Seznam obrázk ů

Obr. 1 Struktura metainformačního systému [56] ......................................................................6

Obr. 2 Vztah metainformačních systémů a metaportálu (zpracováno dle [56]).........................8

Obr. 3 Schéma SOA, vztah poskytovatele a uživatele služby (zpracováno dle [73] a [80])....11

Obr. 4 Ukázka architektury webových služeb (zpracováno dle [73]) ......................................12

Obr. 5 Schéma komunikace uživatele a poskytovatele OWS (zpracováno dle [50])...............13

Obr. 6 Ukázka volání operace GetCapabilities, předávané parametry jsou zakódovány jako

KVP...................................................................................................................................14

Obr. 7 Ukázka volání operace GetCapabilities, předávané parametry jsou zakódované

prostřednictvím XML........................................................................................................14

Obr. 8 Geospatial Portal Reference Architecture [47] .............................................................15

Obr. 9 Struktura pracovní skupiny UNGIWG [67] ..................................................................18

Obr. 10 Ukázka uživatelského rozhraní GeoNetwork..............................................................20

Obr. 11 Schéma překladu zdrojového kódu jazyka Java (zpracováno dle [59]) ......................26

Obr. 12 Schéma komunikace mezi klientem a serverem podporujícím technologii JAVA

servlet [35].........................................................................................................................28

Obr. 13 Schéma architektury systému Jeeves [40]..................................................................31

Obr. 14 Schéma tabulky metadata, včetně seznamu evidovaných atributů..............................34

Obr. 15 Ukázka formuláře pro lokální vyhledávání metadat – rozšířený mód ........................38

Obr. 16 Ukázka formuláře pro vzdálené vyhledávání metadat – rozšířený mód .....................38

Obr. 17 Ukázka části metadatového záznamu zobrazeného v základním módu......................39

Obr. 18 Ukázka formuláře pro změnu přístupových privilegii k vytvořenému metadatovému

záznamu.............................................................................................................................40

Obr. 19 Ukázka nápovědy GeoNetwork k elementu Metadata author.....................................42

Obr. 20 Ukázka umístění ovládacích prvků pro úpravu seznamu zadávaných položek ..........42

Obr. 21 Ukázka kalendáře pro zadávání atributu typu datum ..................................................43

Obr. 22 Ukázka vyplněného elementu Geographic box...........................................................43

Obr. 23 Ukázka části formuláře sloužícího pro nahrání náhledu popisovaných geodat ..........43

Obr. 24 Ukázka vyplněného formuláře pro vytvoření met. záznamu na základě XML

dokumentu .........................................................................................................................44

Obr. 25 Ukázka nastavení sběru metadat pro testovací uzel GeoNetwork VŠB.....................45

Obr. 26 Ukázka vyplněného formuláře pro dávkový import metadatových záznamů.............46

Obr. 27 Ukázka vyplněného formuláře pro vytvoření nového uživatelského účtu ..................47

Obr. 28 XML kódu upravující menu pro volbu lokalizace GeoNetwork.................................50

Obr. 29 XML kód pro rozšíření seznamu řetězců o řetězec Čeština........................................50

Obr. 30 Ukázka XML kódu nové statické webové stránky (examplepage.xml)......................50

Obr. 31 Ukázka XML kódu pro přidání nové stránky (config.xml).........................................51

Obr. 32 Ukázka XML kódu pro změnu privilegií přístupů (user-profiles.xml) .......................51

Obr. 33 Schéma základní architektury katalogových služeb (vytvořeno dle [13]) .................54

Obr. 34 Konceptuální schéma CSW – rozdělení operací [13] .................................................56

Obr. 35 Schéma komunikačního rozhraní GeoNetwork ..........................................................60

Obr. 36 Ukázka grafického rozhraní vytvořeného testovacího klienta CSW...........................62

Seznam tabulek

Tab. 1 Přehled verzí systému GeoNetwork opensource od roku 2004 ....................................22

Tab. 2 Přehled společných atributů pro dotazování - Core queryable properties [13].............55

Tab. 3 Přehled rozsahu implementace operací CSW v GeoNetwork.......................................61

Tab. 4 Přehled rozsahu implementace dotazovacího jazyka FILTER......................................61

Seznam p říloh

Příloha č. 1 Upravený seznam uzlů pro vzdálené vyhledávání - soubor repositories.xml.........1

Příloha č. 2 Seznam tabulek GeoNetwork včetně jejích atributů ...............................................2

Příloha č. 3 Ukázka upraveného souboru banner.xsl, obsahujícího definici hlavičky ...............3

Příloha č. 4 Ukázka kódu třídy realizující službu.......................................................................4

Příloha č. 5 Seznam Core returnable properties [13]..................................................................5

Příloha č. 6 Návod na kompilování GeoNetwork.......................................................................6

Příloha č. 7 Návod na instalaci GeoNetwork .............................................................................7

Příloha č. 8 Rozdělení privilegii přístupu k funkcionalitám GeoNetwork .................................9

Příloha č. 9 Základní všeobecný model katalogových služeb (převzato z [13] ) .....................10

Příloha č. 10 Přehled dostupných operací CSW (vytvořeno dle [13]) .....................................11

Příloha č. 11 Přehled implementovaných parametrů operace GetRecords v GeoNetwork......12

PŘÍLOHY

1

Příloha č. 1 Upravený seznam uzlů pro vzdálené vyhledávání - soubor repositories.xml

<?xml version="1.0" encoding="UTF-8"?> <RepositoryDirectory> <TypeMapping type="Z3950" class="com.k_int.z3950.IR Client.Z3950Origin"/> <TypeMapping type="HSS" class="com.k_int.srw.client .SRWSearchable"/> <!-- localhost --> <Collection collection_dn="localhost:2100/geonetwor k" collection_name="Local GeoNetwork"/> <!-- VSB - Geonetwork 2.1 alpha (test server) --> <Collection collection_dn="158.196.143.103:2100/geo network" collection_name="VSB - Geonetwork 2.1 alpha"/> <!-- localhost --> <Repository repository_dn="localhost:2100/geonetwor k" name="Local GeoNetwork" type="Z3950" can_multiplex_ sessions="no" > <RepositoryProperty name="ServiceHost" value="local host" /> <RepositoryProperty name="ServicePort" value="2100" /> <RepositoryProperty name="service_short_name" value ="geonetwork" /> <RepositoryProperty name="default_record_syntax" va lue="xml" /> <RepositoryProperty name="default_element_set_name" value="s" /> <RepositoryProperty name="full_element_set_name" va lue="f" /> <RepositoryProperty name="logo_src" value="http://www.k-int.com/collection_ico/sif.gif" /> </Repository> <!-- VSB - Geonetwork 2.1 alpha (test server) --> <Repository repository_dn="158.196.143.103:2100/geo network" name="VSB - Geonetwork 2.1 alpha" type="Z3950" can_ multiplex_sessions="no" > <RepositoryProperty name="ServiceHost" value="158.1 96.143.103" /> <RepositoryProperty name="ServicePort" value="2100" /> <RepositoryProperty name="service_short_name" value ="geonetwork" /> <RepositoryProperty name="default_record_syntax" va lue="xml" /> <RepositoryProperty name="default_element_set_name" value="s" /> <RepositoryProperty name="full_element_set_name" va lue="f" /> <RepositoryProperty name="logo_src" value="http://www.k-int.com/collection_ico/sif.gif" /> </Repository> <!-- localhost --> <Instance instance_dn="localhost:2100/geonetwork" collection_dn="localhost:2100/geonetwork" repository_dn="localhost:2100/geonetwork" local_name="geonetwork" /> <!-- VSB - Geonetwork 2.1 alpha (test server) --> <Instance instance_dn="158.196.143.103:2100/geonetw ork" collection_dn="158.196.143.103:2100/geonetwork" repository_dn="158.196.143.103:2100/geonetwork" local_name="geonetwork" /> </RepositoryDirectory>)

2

Příloha č. 2 Seznam tabulek GeoNetwork včetně jejích atributů

pozn. dokumentace GeoNetwork neuvádí relační vztahy mezi jednotlivými tabulkami

3

Příloha č. 3 Ukázka upraveného souboru banner.xsl, obsahujícího definici hlavičky

<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <!-- upraveny hlavni panel --> <xsl:template name="banner"> <style type="text/css"> div.banner{ background-color:#064377; height:80px; } div.menu { background-color:#064377; clear:both; height:25px; line-height:25px; } div.menu ul { display:inline; } div.menu li { background-color:navy; font-weight:bold; color:white; float:left; list-style:none; text-align:center; padding-left:10px; padding-right:10px; } div.menu li a { font-weight:normal; display:block; padding-left:10px; padding-right:10px; } </style> <div class="banner"> <img src="{/root/gui/url}/images/header-left.jpg" a lt="World picture" style="float:left;"/> <img src="{/root/gui/url}/images/header-right.gif" alt="GeoNetwork opensource logo" style="float:right;" /> </div> <div class="menu" style=""> <ul> <xsl:choose> <xsl:when test="/root/gui/reqService='main.home'"> <li><xsl:value-of select="/root/gui/strings/home"/> </li> </xsl:when> <xsl:otherwise> <li><a class="banner" href="{/root/gui/locService }/main.home"><xsl:value-of select="/root/gui/strings/home"/></a></li> </xsl:otherwise> </xsl:choose> <xsl:choose> <xsl:when test="/root/gui/reqService='feedback'"> <li><xsl:value-of select="/root/gui/strings/contact Us"/></li> </xsl:when> <xsl:otherwise> <li><a class="banner" href="{/root/gui/locService}/ feedback"><xsl:value-of select="/root/gui/strings/contactUs"/></a></li> </xsl:otherwise> </xsl:choose> <!-- zde mohou nasledovat dalsi operace --> </ul> </div> </xsl:template> </xsl:stylesheet>

4

Příloha č. 4 Ukázka kódu třídy realizující službu

package org.fao.geonet.services.sluzba; import org.jdom.*; import jeeves.interfaces.*; import jeeves.server.*; import jeeves.server.context.*; import jeeves.constants.*; public class proved implements Service { public void init(String appPath, ServiceConfig par ams) throws Exception {} public Element exec(Element params, ServiceContext context) throws Exception { Element res = new Element("ok"); return res; } }

5

Příloha č. 5 Seznam Core returnable properties [13]

Dublin Core metadata element name

Term used in OGC

queryables

Description (“Resource” means the thing being described in the

metadata)

dc:title Title A name given to the resource. Also known as “Name”. dc:creator An entity primarily responsible for making the content of the

resource. dc:subject Subject A topic of the content of the resource. This is a place where a

Topic Category or other taxonomy could be applied. dct:abstract Abstract An account of the content of the resource. This is also known as

the “Abstract” in other aspects of OGC, FGDC, and ISO metadata.

dc:publisher An entity responsible for making the resource available. This would equate to the Distributor in ISO and FGDC metadata.

dc:contributor An entity responsible for making contributions to the content of the resource.

dc:date Modified A date of a creation or update event of the metadata resource. dc:type Type The nature or genre of the content of the resource. dc:format Format The physical or digital manifestation of the resource. dc:identifier Identifier An unambiguous reference to the resource within a given

context. dc:source Source A reference to a resource from which the present resource is

derived. dc:language A language of the intellectual content of the resource. dc:relation Relation,

Source, Target

A reference to a related resource.

dct:spatial Envelope, CRS

The spatial extent or scope of the content of the resource.

dc:rights Information about rights held in and over the resource.

6

Příloha č. 6 Návod na kompilování GeoNetwork

GeoNetwork je možné zkompilovat na základě předpřipraveného XML kompilačního

skriptu. Tento skript je součástí zdrojových kódů GeoNetwork, které jsou publikovány

prostřednictvím CVS (viz. kap. 4.4.1). Skript je pojmenován build.xml a nachází se přímo

v kořenovém adresáři zdrojových kódů.

Pro kompilování je potřeba mít nainstalováno:

� JRE 1.5 (viz. kap. 5.1.2)

� Apache ANT [1]

Před spuštěním kompilace zdrojových kódů je nutné nastavit systémové proměnné

JAVA_HOME a ANT_HOME, které určují fyzické umístění JDK a Apache ANT. Toto

nastavení je v OS Windows realizováno pomoci příkazu SET.

SET JAVA_HOME=c:\Program Files\Java\jdk1.5.0_09 SET ANT_HOME=d:\temp\ant cd d:\temp

Následující příkaz pak spustí samotnou kompilaci, dle kompilačního skriptu build.xml,

výstup je přesměrován do souboru installog.txt.

ant -f d:\temp\geonetwork\build.xml -logfile d:\tem p\insatllog.txt

Obdobně je možné vytvořit také automatický instalační balíček GeoNetwork. V tomto

případě je využit kompilační skript installer/build.xml. Instalační balíček je vytvořen pomocí

nástroje IzPack [33]. Tento nástroj je plně integrován v Apache ANT.

7

Příloha č. 7 Návod na instalaci GeoNetwork

GeoNetwork je možné instalovat jako desktop nebo serverovou aplikaci, postup

instalace se pro obě tyto varianty výrazně neliší. V obou variantách instalace jsou po uživateli

požadovány tyto údaje:

� Název serveru (jméno organizace)

� Jedinečnou identifikaci instance geonetwork (např. URI adresa)

� IP adresa serveru (je detekována automaticky)

� Port a adresu, na němž poběží servletový server (typicky je to port 8080)

� Kontakt na administrátora (email)

� Parametry připojení k DBMS (přístupové jméno, heslo, připojovací řetězec)

Dle [22] je vhodné pro desktop variantu zvolit servletový server Jetty [37] v kombinaci

s DBMS McKoi [41]. Server Jetty i DBMS McKoi jsou součástí instalačního balíčku

GeoNetwork. Pro serverovou variantu je doporučeno využít server Apache Tomcat [3]

v kombinaci DBMS Oracle [52], MySQL [45] nebo PostgreSQL [54].

Před zahájením instalace je nutné splnit požadavky definované v kapitole č. 4.5. Instanční

program GeoNetwork, je postaven na platformě Java SE a je koncipován jako jednoduchý

průvodce.

Instalace desktop varianty nevyžaduje žádné hlubší dovednosti, ze strany uživatele. Po

dokončení instalace desktop varianty je možné spustit GeoNetwork předpřipraveným

dávkovým souborem. Tento soubor se nachází ve složce geonetwork/bin se jmenuje start-

geonetwork.bat respektive start-geonetwork.sh. Po spuštění je uživatelský interface dostupný

prostřednictvím internetového prohlížeče na adrese serveru. Typicky je to například

následující adresa: http://localhost:8080/geonetwork/.

Instalace server varianty je z pohledu uživatele o něco náročnější, před zahájením

instalace je nutné:

� Ve vybraném DBMS vytvořit prázdnou databázi a uživatelský účet, který má

právo zápisu do nově vytvořené databáze

� Opatřit pro zvolený DBMS JDBC konektor, ten je dostupný nejčastěji na stránkách

výrobce DBMS (pozn. dle doporučení [22] byl využit MySQL)

� Mít nainstalovaný a funkční servletový server (pozn. dle doporučení [22] byl

využit Apache Tomcat)

8

Během instalace je uživatel vyzván k tomu, aby nakopíroval konektor pro vybraný DBMS

do adresáře web/WEB-INF/lib. Po dokončení instalace, je možné GeoNetwork zprovoznit

dvěma způsoby.

� Nakopírovat obsah adresáře geonetwork/web do adresáře Tomcat

5.5/webapps/geonetwork;

� Nastavením cesty k instalaci GeoNetwork, pomocí elementu Context,

v konfiguračním souboru Tomcat 5.5/config/server.xml.

Při editaci souboru server.xml nesmí být server Tomcat spuštěn. Do konfiguračního

souboru byl vložen následující kód. Tento kód byl vložen do elementu Host.

<Context path="/geonetwork" docBase="C:\Program Files\geonetwork/web" crossContext="false" debug="0" reloadable="false" />

Uvedený kód se může lišit v závislosti na OS případně místu instalace GeoNetwork.

Změna nastavení se projeví po opětovném spuštění serveru Tomcat. Uživatelský interface

GeoNetwork je dostupný prostřednictvím internetového prohlížeče na adrese serveru, typicky

je to například adresa http://mujserver:8080/geonetwork/.

Při testování Geonetwork verze 2.1 alpha 2 došlo při pokusu o zobrazení uživatelského

interface ke generování celé řady chyb. Tyto chyby měli za následek nefunkčnost celého

systému. Chyby způsobovalo nastavení cest k některým balíčkům Java. K opravě postačilo

upravit konfiguračního souboru GeoNetwork web.xml, který se nachází v adresáři web/WEB-

INF. Do tohoto souboru byl za element web-app přidán následující kód.

<display-name>geonetwork</display-name>

9

Příloha č. 8 Rozdělení privilegii přístupu k funkcionalitám GeoNetwork

Veškeré funkcionality uvedené v této tabulce jsou popsány v kapitole číslo 6.

Funkcionalita GeoNetwork /

Uživatelská třída

Adm

inis

trát

or s

ysté

mu

(Ad

min

istr

ato

r)

Adm

in. U

živa

telů

(Use

r a

dm

inis

tra

tor)

Edi

tor

(Ed

itor)

Reg

istr

ovan

ý už

ivat

el (R

eg

istr

ed

use

r)

Ner

egis

trov

aný

uživ

atel

Vyhledávání metadata v lokálním katalogu (Local Search)1 ● ● ● ● ● Vyhledávat metadata ve vzdálených katalozích (Remote Search) 1 ● ● ● ● ● Prohlížení metadat (View metadata) 1 ● ● ● ● ● Stahování metadat (Download metadata) 1 ● ● ● ● ● Vkládání metadat (New metadata) ● ● ● ○ ○ Vkládání metadat jako XML (XML Metadata Insert) ● ● ● ○ ○ Dávkový import metadat (Batch Import) ● ○ ○ ○ ○ Správa uživatelských účtů (User management) ● ● ○ ○ ○ Správa pracovních skupin (Group management) ● ○ ○ ○ ○ Správa kategorii (Category management) ● ○ ○ ○ ○ Nastavení harvestingu (Harvesting management) ● ○ ○ ○ ○ Správa osobních údajů (Change User information) ● ● ● ● ○ Změna vlastního hesla (Change password) ● ● ● ● ○

1) dostupnost této funkcionality může být ovlivněna přístupovými právy k metadatovým záznamům

10

Příloha č. 9 Základní všeobecný model katalogových služeb (převzato z [13] )

Ostatní UML modely, definující rozhraní katalogových služeb, jsou dostupné v [13].

11

Příloha č. 10 Přehled dostupných operací CSW (vytvořeno dle [13])

Povinně Volitelně Operace

Povinná operace1 Metoda

HTTP Zakódování parametrů

Metoda HTTP

Zakódování parametrů

GetCapabilities ● GET KVP POST XML DescribeRecord ● POST XML GET KVP GetDomain ○ POST XML GET KVP GetRecords ● POST XML GET KVP GetRecordById ● GET KVP POST XML Harvest ○ POST XML POST KVP Transaction ○ POST XML

1) povinná operace - ve smyslu povinnosti implementovat tuto operaci v konkrétní instanci CSW

12

Příloha č. 11 Přehled implementovaných parametrů operace GetRecords v GeoNetwork

Název parametru Povinnost1 Podporován2 Poznámky k podpoře3 REQUEST ● ● GetRecors

service ● ● Pouze: http://www.opengis.net/cat/csw

version ● ● Pouze: 2.0.1 NAMESPACE ○ ○ resultType ○ ● hits, results, validate outputFormat ○ ● Pouze: application/xml outputSchema ○ ● csw:Record, csw:isoRecord startPosition ○ ● maxRecords ○ ● typeNames ● ● ElementSetName ○ ● brief, summary, full CONSTRAINLANGUAGE ○ ● CQL_TEXT, FILTER Constrain ○ ●

SortBy ○ ● Možno řadit dle Core queryable properties

DistributedSearch ○ ○ hopCount ○ ○ ResponseHandler ○ ○

1) Povinnost podporovat parametr dle specifikace [13]

2) Je parametr podporován GeoNetwork

3) Seznam možných hodnot, případně jiná poznámka