Značkovací jazyky na platformě GeoWeb - Institut geoinformatiky

Transkript

Vysoká škola báňská – Technická univerzita Ostrava
Hornickogeologická fakulta
Obor Geoinformatika
Značkovací jazyky na platformě GeoWeb
Učební materiál v 0.1
Ostrava, Srpen 2010
Jan Růžička
K doplnění učebního textu byly využity poznatky z individuálního kurzu pro zvýšení odborného růstu
akademických pracovníků „Praktický úvod do SOA“. Účast na kurzu byla hrazena z projektu
CZ.1.07/2.2.00/07.0327. Tento projekt je spolufinancován z ESF a státního rozpočtu ČR.
Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
2
Obsah
1 Seznam použitých zkratek.......................................................................................................5
2 Úvod.........................................................................................................................................9
2.1 GeoWeb.......................................................................................................................................9
2.2 Open source GIS.........................................................................................................................9
3 Standardizace pro GeoWeb..................................................................................................13
3.1 Standardizace............................................................................................................................13
3.2 Popis dat....................................................................................................................................15
3.2.1 Datová sada............................................................................................................................................16
3.3 Standardy pro popis, transformaci a vázání dat....................................................................16
3.3.1 SGML.....................................................................................................................................................16
3.3.2 HTML....................................................................................................................................................17
3.3.3 XML, XHTML.......................................................................................................................................17
3.3.4 RDF........................................................................................................................................................22
3.3.5 OWL.......................................................................................................................................................22
3.3.6 CSS.........................................................................................................................................................23
3.3.7 XSL........................................................................................................................................................24
3.4 Standardizace zápisu prostorových dat..................................................................................29
3.4.1 Geometrické prvky.................................................................................................................................29
3.4.2 Výměnné formáty..................................................................................................................................31
3.5 Metadata pro prostorová data a jejich standardizace...........................................................38
3.5.1 Dublin Core............................................................................................................................................39
3.5.2 Standardy pro metadata o prostorových datech.....................................................................................40
3.5.3 Společné prvky standardů pro prostorová data......................................................................................43
3.5.4 Srovnání hlavních standardů v této oblasti............................................................................................43
3.6 Standardizace v oblasti komunikačních protokolů................................................................46
3.6.1 HTTP......................................................................................................................................................46
3.6.2 HTTPS....................................................................................................................................................47
3.6.3 SOAP......................................................................................................................................................48
3.6.4 CORBA..................................................................................................................................................50
3.6.5 RMI........................................................................................................................................................50
3.6.6 GeoWeb Services...................................................................................................................................51
3.6.7 WMS......................................................................................................................................................51
3.6.8 WFS........................................................................................................................................................52
3.6.9 WCS.......................................................................................................................................................53
3.6.10 WPS......................................................................................................................................................54
3.6.11 Komunikační protokoly pro hledání v metadatech pro geodata..........................................................55
3.7 Webové služby...........................................................................................................................56
3.7.1 Klienti pro Webové služby.....................................................................................................................57
3.7.2 WSDL.....................................................................................................................................................58
3.7.3 ISO 19119 - Geographic information – Services...................................................................................59
3.8 Způsoby volání služeb...............................................................................................................59
3.8.1 Synchronní.............................................................................................................................................59
3.8.2 Asynchronní...........................................................................................................................................60
4 Architektura platformy otevřený GeoWeb...........................................................................61
3
4.1 Architektura..............................................................................................................................61
4.2 Datové služby............................................................................................................................65
4.3 Katalogy, metadatové služby...................................................................................................65
4.3.1 Samostatné veřejné metainformační systémy........................................................................................66
4.3.2 Veřejné metainformační portály............................................................................................................66
4.3.3 Správa metadat v katalogu.....................................................................................................................69
4.3.4 Metadata vznikající automatizovaně......................................................................................................69
4.3.5 Očekávaný rozsah metadat.....................................................................................................................70
4.3.6 UDDI......................................................................................................................................................74
4.3.7 WSIL......................................................................................................................................................74
4.3.8 CSW 2.0.................................................................................................................................................75
4.3.9 Skryté katalogy.......................................................................................................................................76
4.4 Analytické služby......................................................................................................................76
4.5 Choreografie, orchestrace a řetězení služeb ..........................................................................76
4.5.1 BPEL......................................................................................................................................................76
4.5.2 WS-CDL.................................................................................................................................................77
4.6 Zabezpečení, platby..................................................................................................................78
4.6.1 Zabezpečení............................................................................................................................................78
4.6.2 Platby......................................................................................................................................................79
4.7 Klienti........................................................................................................................................80
4.7.1 Univerzální klient...................................................................................................................................80
4.7.2 Samo generující se klienti......................................................................................................................80
4.7.3 Překladače..............................................................................................................................................81
4.8 Využití open source nástrojů pro platformu otevřený GeoWeb...........................................81
4.9 Využití platformy Semantic Web pro platformu otevřený GeoWeb....................................82
5 Závěr......................................................................................................................................84
6 Seznam použité literatury a dalších informačních zdrojů..................................................85
7 Seznam obrázků, tabulek a příkladů....................................................................................98
4
1 Seznam použitých zkratek
2D
3D
4D
5D
ArcIMS
ArcSDE
ASCII
CAD
CAGI CEN CGI
CIDS
CORBA
CSS
CSW
CT
ČR
ČSN
ČSNI
DC
DCMI
DCT
DDML
DIS
DTD
DTP
DXF
ECMA
ECW
EEA
EPSG
ESB
ESRI
ETSI
FAO
FDIS
FGDC FTP
GAČR
GAZ
Dvourozměrný
Trojrozměrný
Čtyřrozměrný
Pěti rozměrný
Arc Internet Mapping System
Arc Spatial Data Engine
American Standard Code for Information Interchange
Computer Aided Design
Česká asociace pro Geoinformace European Commitee for Standardization (Comité Européen de Normalisation
Common Gateway Interface
Component Information Dictionary Standard
Common Object Request Broaker Architecture
Cascade Style Sheets
Catalogue Services for the Web
Coordinate Transformation Service Implementation Specification
Česká republika
Česká technická norma
Český normalizační institut
Dublin Core
Dublin Core Metadata Initiative
Discrete Cosine Transformation
Document Definition Markup Language
Draft International Standard
Deklarace typu dokumentu
Desktop Publishing
Drawing eXchange Format
European Computer Manufacturers Association
ER Mapper Compressed Rasters
European Environment Agency
European Petroleum Survey Group
Enterprise Service Bus
Environmental System Research Institute
European Telecommunications Standards Institute
Food and Agriculture Organization of the United Nations
Final Draft International Standard
Federal Geographic Data Committee
File Transfer Protocol
Grantová agentura České republiky
Gazetteer services
5
GDDD GeoRSS
GIMP
GIS GML GPS
GPX
GRASS
HGS HGSS
HTML HTTP HTTPS
HZS
IAB
IANA
IDL
IEC
IEEE
IETF
IFLA
IMS
IP
IPR
ISO ISOC
ISVS ITU
JML
JPEG
JRC
JSP
JUMP
KML
KMS MEGI MIDAS
MMO
MrSID
NASA
NCGI NGDF
NGII
Geographical Data Description Directory
Geographically Encoded Objects for RSS feeds
GNU Image Manipulation Programme
Geografický informační systém
Geography Markup Language
Global Positioning Systems
GPS Exchange Format
Geographic Resources Analysis Support System
HTTPbased GeoTemporal Searching
HTTPbased GeoTemporal Simple Searching
HyperText Markup Language
HyperText Transfer Protocol
Secure HyperText Transfer Protocol
Hasičský záchranný sbor
Internet Architecture Board
Internet Assigned Numbers Authority
Interactive Data Language
International Electrotechnical Commission
Institute of Electrical and Electronic Engineers
Internet Engineering Task Force
International Federation of Library Associations and Institutions
Information Management system
Internet Protocol
Intellectual Property Rights
International Organization for Standardization
Internet Society
Informační systém veřejné správy
International Telecommunications Union
JUMP GML
Joint Picture Experts Group
Joint Research Centre
Java Server Pages
Java Unified Mapping Platform
Keyhole Markup Language
Kort&Matrikelstirelsen
Metadata för geografisk information
Metainformační databázový systém
Magistrát města Ostrava
Multiresolution Seamless Image Database
National Aeronautics & Space Administration
National Clearinghouse for Geoinformation
National Geospatial Data Framework
Národní geoinformační infrastruktura (National geoinformation infrastructure)
6
NMEA
NSDI Ntrip
OASIS
ODA
ODL
OGC
OMG
OpenLS
OWL
PCIS
PHP
PNG
PVL
RAVI
RDF
RMI
RPC
RSS
SJTSK
SAML
SCS
SDGM
SDIC
SDTS
SGML
SLD
SMS
SMTP
SNIG SOAP
SOX
SPIDI SPS
SŘBD
SSL
SVG SWF
TIFF
TIN
TLS
UDDI
UML
National Marine Electronics Association
National Spatial Data Infrastructure
Networked Transport of RTCM via Internet Protocol
Organization for the Advancement of Structured Information Standards
Open Document Architecture
Object Description Language
Open Geospatial Consortium
Object Management Group
OpenGIS Location Services
Web Ontology Language
Pinnacles Component Information Standard
PHP: Hypertext Preprocessor
Portable Network Graphics
Parameter Value Language
Dutch Council for Geographic Information
Resource Description Framework
Remote Method Invocation
Remote Procedure Call
Really Simple Syndication
Systém jednotné trigonometrické sítě katastrální
Security Assertion Markup Language
Sensor Collection Service
Standard for Digital Geospatial Metadata
Spatial Data Interest Communities
Spatial Data Transfer Standard
Standard Generalized Markup Language
Styled Layer Descriptor
Style Management Services for Emergency Mapping Symbology
Simple Mail Transfer Protocol
National system for Geographic Information
Simple Object Access Protocol
Schema for Objectoriented XML
Spatial Information Directory
Sensor Planning Service
Systém řízení báze dat
Secure Sockets Layer
Scalable Vector Graphics
Macromedia Flash/Shockwave format
Tag Image File Format
Triangular irregular network Transport Layer Security Protocol
Universal Description, Discovery and Integration
Unified Modelling Language
7
UNSDI
URL
URI
ÚVIS VRML
W3C
WCS
WFS
WKB
WKT
WMS
WNS
WPS
WS
WSCDL
WSCO
WSDL
WSIL
WTS
WWW XDR
XHTML
XMI
XML XSD
XSL XSLT
United Nations Spatial Data Infrastructure
Uniform Resource Locator
Uniform Resource Identifier
Úřad pro veřejné informační systémy
Virtual reality modelling language
World Wide Web Consortium
Web Coverage Service
Web Feature Service
Well Known Binary
Well Known Text
Web Map Service
Web Notification Service
Web Processing Service
Web Service(s)
Web Service Choreography Description Language
Web Services Catalogue for Orchestration
Web Services Description Language
Web Services Inspection Language
Web Terrain Server
World Wide Web
XMLData Reduced
eXtensible HyperText Markup Language
XML Metadata Interchange Format
eXtensible Markup Language XML Schema Definition
eXtensible Stylesheet Language
eXtensible Stylesheet Language Transformation
8
2 Úvod
2 Úvod
„Již po mnoho let je pro prezentaci elektronických dokumentů využíváno WWW (World Wide Web) služby sítě Internet. Důvody jsou jednoduché, jedná se o levný a snadno aktualizovatelný způsob prezentace informací, které se rychle dostanou k uživatelům. Tento způsob prezentace dokumentů se nevyhýbá ani oblasti elektronických map a atlasů a zabývá se jím vědní obor Geoinformatika. Spojení předpony Geo a slova Web dalo vznik slovu GeoWeb, kterým je tato oblast souhrnně nazývána. Jedná se o oblast relativně vyspělou a technologicky dobře zvládnutou, a to jako i v jiných oblastech výpočetní techniky způsobuje vstup laických uživatelů na scénu“ [Růžička 2005i].
Jedním ze zásadních nástrojů pro využívání nebo budování platformy GeoWeb jsou značkovací jazyky. Značkovací jazyky jsou pro většinu čtenářů snadno srozumitelné a proto je jejich stále častější využívání běžným jevem. Následující text by měl pomoci studentům oboru Geoinformatika (případně jiných oborů) pomoci se v dané problematice dobře orientovat a efektivně využívat výhod značkovacích jazyků. 2.1 GeoWeb
„Při tvorbě map se již řadu let uplatňuje výpočetní technika. Digitální kartografie dnes stojí u zrodu map všeho druhu. Pod pojmem mapa si většina lidí v současnosti představí stále ještě ‘tradiční‘ mapu, tedy nejčastěji arch papíru, který je možno složit či srolovat do tvaru, s nímž lze relativně snadno manipulovat, přenášet v terénu a opět jej podle potřeby rozložit. Před několika lety se vývoj vydal cestou elektronických map a elektronických atlasů, jejichž existence je s digitálními technologiemi bytostně spjata. Důležitým mediem pro šíření některých těchto kartografických děl se stal internet.“ [Růžička 2003].
V současné době i průměrně zdatný uživatel osobního počítače zvládne publikovat prostorová data v prostředí WWW. Nástroje nabízené v této oblasti nevyžadují znalost programování ani samotných používaných technologií a o kartografických znalostech ani nemluvě.
GeoWeb je však více než jen publikování prostorových dat na WWW. Jedná se zejména o platformu pro distribuovaný GIS (Geografický informační systém). Zahrnuje tedy nejen publikování, ale i modelování, analýzy, transformace a jiné operace s prostorovými daty. K tomu všemu využívá principy servisně orientované architektury (SOA) v podobě webových služeb a jejich řetězení.
2.2 Open source GIS
Platforma otevřený GeoWeb bude ve velké míře využívat nástrojů z oblasti open source GIS, proto se hned v úvodu podívejme na stručný přehled popisující tuto často Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
9
2 Úvod
opomíjenou oblast GIS. V závěru textu jsou nástroje, zde stručně popsané, zařazeny do kontextu platformy otevřený GeoWeb. Když se řekne open source GIS, může se stát, že si někteří tento termín mylně spojí s organizací Open GIS (dnes Open Geospatial) Consortium. Specifikace které spravuje Open Geospatial Consortium však propojují nástroje pro GIS jak z open source tak z close source oblasti. Tyto specifikace vytvářejí obecný (univerzální) rámec pro komunikaci různých programových vybavení tak aby byla možná interoperabilita mezi nezávislými produkty z různých vývojářských dílen.
Open source GIS však znamená GIS s otevřeným programovým kódem. Zdrojový kód programu je distribuován společně se zkompilovaným (instalačním) programem, případně je distribuován pouze zdrojový kód. V případě otevřeného kódu se může do vývoje zapojit velké množství programátorů z celého světa. Tito programátoři mohou v programu hledat chyby, chyby opravovat nebo přímo vyvíjet ucelené moduly (knihovny, pluginy) daných programů. Nemalý význam má otevřený kód pro účely výzkumu a vzdělávání. Výzkumní pracovníci a studenti se mohou podrobně seznámit s různými algoritmy a jejich implementací. Celkově přináší otevřený kód svobodu šíření a využívání informací v oblasti informačních technologií.
V oblasti open source vzniklo mnoho zajímavých projektů, které našly uplatnění v komerční sféře. Namátkou vyberme několik zajímavých, které mají obecné využití.
Apache HTTP Server – Dnes nejpoužívanější WWW server.
GNU/Linux, FreeBSD – Operační systémy, velmi často nasazovány v oblasti serverových řešení, postupně se však prosazují i v oblasti desktopu.
PostgreSQL, MySQL – systémy řízení báze dat, MySQL je dnes nejpoužívanějším nástrojem v oblasti dynamických WWW stránek.
PHP (PHP: Hypertext Preprocessor) – Jeden z nejvyhledávanějších nástrojů pro tvorbu dynamických WWW stránek.
Mozilla – WWW prohlížeč, v současné době jeden z mála použitelných WWW prohlížečů postačující aktuálním požadavkům služby WWW.
Open Office – Balík nástrojů srovnatelný s MS Office s mnoha zajímavými funkcemi navíc.
Eclipse – Vývojové prostředí (platforma) rozšířitelná pomocí pluginů, pluginy dnes pokrývají mnoho oblastí jako např. jazyky C++, PHP, Java, HTML (HyperText Markup Language), UML (Unified Modelling Language), SQL.
Scribus, Inkscape – DTP (Desktop Publishing) nástroje.
GIMP (GNU Image Manipulation Programme) – nástroj pro zpracování rastrového obrazu.
NVU – nástroj pro tvorbu WWW stránek srovnatelný s MS Front Page.
Přestože se v oblasti GIS open source nástroje vyvíjejí také velmi dlouho není jich zatím příliš mnoho takového dominantního významu jako např. Apache HTTP Server, přesto jich existuje několik, které se výrazně prosadily i v komerční sféře.
Na první místo by měl být zařazen nástroj UMN Map Server [RUMN 2002]. Jedná se o velmi kvalitní mapový server (publikuje prostorová (GIS) data v prostředí WWW). Jeho Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
10
2 Úvod
rozšíření je velmi významné a v České a Slovenské republice patří k nejrozšířenějším mapovým serverům. Zásluhu na tomto rozšíření mají bezesporu Štěpán Kafka a společnost Help Service Remote Sensing a společnost TMapy, které kombinují close source s open source, a tak vzniká velmi kvalitní řešení, navíc se zárukou podpory zákazníka.
K velmi zajímavým projektům patří projekt JUMP (Java Unified Mapping Platform) [JUMP 2005c] (dnes OpenJUMP) a kooperující projekt JUMP Pilot Project. Projekt JUMP má sice širší záběr, ale především nabízí uživatelsky velmi dobře koncipované prostředí pro práci s prostorovými daty. Nejedná se však o pouhou prohlížečku dat, ale i o nástroj, kde můžeme data analyzovat, editovat a to vše nad datovým modelem, který respektuje (podporuje) specifikace připravené organizací Open Geospatial Consortium. JUMP Workbench navíc nabízí mechanismy, které umožňují snadné rozšiřování funkcionality pomocí tzv. pluginů. V současné době je již k dispozici mnoho externích pluginů, které zastřešuje JUMP Pilot Project. Namátkou jmenujme pluginy pro: síťové analýzy, modelování pomocí celulárních automatů, připojení na PostGIS, ArcIMS (Arc Internet Mapping System), WMS (Web Map Service).
Praktické využití stále častěji zaznamenává nástroj PostGIS. Je to rozšiřující modul systému řízení báze dat PostgreSQL, který umožňuje práci (ukládáni, dotazování, aktualizaci) s prostorovými daty v prostředí relační databáze. PostGIS si lze představit jako open source alternativu ke komerčnímu řešení Geodatabase (+ konektor ArcSDE (Arc Spatial Data Engine)). PostGIS však nepodporuje práci s rastrovým datovým modelem. Nejznámějším produktem open source GIS scény je produkt GRASS (Geographic Resources Analysis Support System). Přes jeho nemalé přednosti je nutné konstatovat, že je určen pro úzkou skupinu uživatelů, a to především z výzkumné sféry. Můžeme jej také vnímat jako nástroj pro vývoj specializovaných aplikací pro práci s prostorovými daty, velmi často ve spojení s modelováním dynamických procesů (hydrologické, hydrogeologické, ekologické, meteorologické, socioekonomické modely). Jeho moduly umožňují analýzu a vizualizaci 3D, 4D, 5D dat, což dokáže jen málokterý GIS nástroj, ale na druhou stranu ne každý pokročilý uživatel (a téměř žádný začátečník) GIS nástrojů dokáže připravit data a metody pro takové analýzy a vizualizaci a také výsledky dobře (kvalifikovaně) interpretovat.
Zajímavých a užitečných open source nástrojů pro GIS jsou desítky, těch ostatních, které se teprve zajímavými a užitečnými stát mohou jsou stovky možná tisíce. Mnoho z nástrojů je stále ve vývojové fázi a jejich stabilita je problematická. Opravdu stabilních open source GIS nástrojů je jen několik málo. Zatím neexistují (nebo o nich nejsou dostupné informace) kvalitní nástroje pro digitální kartografii a pořizování prostorových dat. Nicméně oblast open source GIS se velmi dynamicky vyvíjí a je nutné s ní počítat. V budoucnosti je možné si přestavit následující obchodní model. Komerční firmy přispívají na open source projekty a výsledky práce úročí v podobě specializovaných aplikací postavených na jádru open source nástrojů. Základní nástroje jsou vyvíjeny otevřeně a jsou tak i k dispozici zdarma. Poplatky plynou pouze ze specializovaných nástrojů (a služeb) a ty mohou (záleží na mnoha okolnostech) být distribuovány jako close source. Významným propojovacím mechanismem open a close source nástrojů budou v budoucnosti webové služby, které umožní jejich vzájemnou interoperabilitu bez zásahu do licenčních pravidel. Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
11
2 Úvod
Open a close komunita by spolu neměly soupeřit, ale naopak se snažit spolupracovat, problém však tkví ve filosofickém pohledu na svět. Open source nástroje pro GIS by měly být základem pro celou architekturu. Je možné je snadno zkoumat, rozšiřovat a mnohé z nich distribuovat v síti a tak řešit problém optimalizace datových toků. Řešení pro koncového zákazníka a specializované služby by naopak mohly být předmětem uzavřených komerčních nástrojů.
12
3 Standardizace pro GeoWeb
Velmi důležitou součástí dobře fungující platformy GeoWeb je sada implementovaných standardů (specifikací)1. Z tohoto důvodu je v textu zařazena tato kapitola, která má čtenáři poskytnout přehled hlavních standardů, které se pro GeoWeb uplatňují. Z významné části se jedná o značkovací jazyky. Výčet standardů není jistě vyčerpávající, protože všechny používané standardy není možné obsáhnout a ani by to nebylo účelné. Přesto je množina dostatečně reprezentativní k popisu problematiky platformy otevřený GeoWeb. Pro dodatečné informace je možné využít následující zdroje2 3.1 Standardizace
Standardizace je tak stará jako lidstvo samo. Standardizace je především o komunikaci a již jazyk samotný je standardem. Další významný standard, který se v lidské společnosti objevil, je písmo. Písmo jako takové je pak nejčastějším nástrojem k vyjadřování dalších standardů. Komunikace je obecný pojem a zahrnuje nejen komunikaci mezi lidmi, ale např. i mezi stroji. Aby jeden stroj mohl komunikovat s druhým, musí si rozumět. Aby mohl inženýr navrhnout chování příslušných strojů, musí mít k dispozici příslušnou dokumentaci, která standardní komunikaci popisuje. Dokument je často z velké části tvořen psaným jazykem, ale velmi často obsahuje grafické prvky jiného charakteru, které jsou názornější a informativnější. Existují i případy, kdy v dokumentu písmo úplně chybí a je zcela zastoupeno jinou grafickou symbolikou.
1
2
Z analýz prováděných v rámci výzkumu však stále více vyplývá, že standardizace může být také velkým problémem. Autor se
domnívá, že oblast standardizace pro GeoWeb je již dnes natolik rozsáhlá, že není v silách jedince ani malého týmu vývojářů
komplexně postihnout celou problematiku. Autor vidí cestu pouze v zapojení malých vývojářských týmů do komunity open source
GIS, kde je možné poznatky rychle sdílet. Pokud se toto nestane s největší pravděpodobností malé firmy zaniknout neboť nebudou
schopny konkurovat velkým hráčům na trhu. Velké společnosti se stovkami vývojářů jsou schopny problematiku pojat komplexně,
malé a střední nikoli. Z přehledu uvedeného dále to nemůže posoudit čtenář sám, stačí se však do některých ze specifikací začíst a
nebo se zapojit do některého diskusního fóra, kde vývojáři diskutují problémy samotné implementace (např. fórum GeoNetwork Open
Source).
[Aalders 2001], [Aalders 1998], [Adobe 2006], [Apache 2001], [askGIraffe 2002], [Beneš 2005], [BKG 2001], [CAGI 2006], [Cartonet 2001], [CCSDS 2002], [CCSDS 2002b], [CEN 1998], [CEN 1998b], [CEN 2002], [CENELEC 2001], [Chassels 2000], [CIESIN
2001], [CNIG 2001], [Cover 2001], [Craglia 2000], [Craglia 2000b], [ČSNI 2002], [ČSNI 2001], [DCMI 1999], [DCMI 2002],
[Duchoslav 2002], [ECMA 2001], [EEA 1999], [EEA 2001], [EPSG 2006], [ESRI 2002], [ESRI 2005b], [ESRI 2005], [ESRI 2001],
[ESRI 2001b], [ETSI 2001], [ETC/CDS 1998], [FGDC 2001], [FGDC 1998], [Fraser 2001b], [GIS FSC 2001], [Gonçalves 2003],
[Gouveia 2001], [Grünreich 2001], [Guptill 1995], [Guřan 2005], [Hancock 2000], [Hart 1998], [Holt 2000], [Hood 2006], [Horák
2000], [IAB 2001], [IANA 2001], [IBM 2002], [IBM 2005], [IEC 2001], [IEEE 2001], [IETF 2001], [IFLA 2001], [IGN 2006], [ILRT
2002], [INSPIRE 2005], [INSPIRE 2004], [ISO 1999], [ISO 2004], [ISO 2001], [ISOC 2001], [ITU 2001], [JUMP 2005b], [Katz
2001], [KMS 2001], [Kosek 2002], [Kosek 2004], [Kralidis 2000], [Laurent 1999], [Lesch 2001], [Li 2000], [Liesenfelt 1999], [Lind
2000], [LISA 2002], [MEGRIN 2001], [Meitner 2001], [MOP 2001], [NMDGA 2002], [Nelson 1997], [Neumann 2001], [NGDF
1999b], [NGDF 1999c], [NLS 2001], [OASIS 2005], [OGC 2007], [OGC 2001c], [OGC 2001], [OGC 2005b], [OGC 2003], [OGC
2004], [OGC 1999], [OGC 1999b], [OGC 1999c], [OGC 2005c], [OGC 2002], [OGC 1999d], [OGC 1999e], [Oracle 2002], [Orlík
2006], [Papcun 2004], [Phillips 2001], [Phillips 2001b], [Pitner 2001], [Pokorný 2001], [Pokorný 1998], [RAVI 2001], [Raytheon
2000], [Růžička 2001], [Růžička 2000b], [Růžička 2002], [Růžička 2000], [Růžička 2001b], [Růžička 2005k], [Růžička 2004c],
[Růžička 2005i, [Satrapa 1997], [Schutzberg 2001], [Skřivan 2001], [Smith 2001], [S-Kartverk 2001], [SUN 2005], [Šeliga 2004],
[TeIDE 2005], [Unicode 2001], [ÚVIS 2001], [ÚVIS 2001b], [ÚVIS 2002], [Vermei 2001], [W3C 2005], [W3C 2005b], [W3C 2001],
[W3C 1999], [W3C 2006c], [W3C 2004], [W3C 2004b], [W3C 2004c], [W3C 2005c], [W3C 2000], [W3C 2005d], [W3C 2006b],
[W3C 2005e], [W3C 2005f], [W3C 2005g], [W3C 2006b], [Web3D 2003], [Web3D 2005], [Wikipedia 2006], [Wood 1997].
13
Každý standard, máli být akceptovatelný jako všeobecná dohoda v určitém oboru lidské činnosti (např. geoinformatika), musí být srozumitelný odborníkům v této oblasti působícím. V této souvislosti, především v moderních (relativně nových) oborech lidské činnosti, jakým je bezesporu i geoinformatika, nastává problém, který je potřeba vyřešit již před celým procesem standardizace. Tímto problémem je terminologie. Jednotná terminologie podmiňuje srozumitelnost standardů pro daný obor. Proto prvním a základním standardem, který by se měl v daném oboru objevit, je terminologický slovník. Terminologický slovník by měl projít stejným vývojem jako jakýkoliv standard.
Standardizace jakožto proces, který produkuje standardy, je obvykle dlouhodobou záležitostí. Tvorba standardů obvykle prochází několika fázemi. Např. standardy W3C (World Wide Web Consortium) [W3C 2006b] procházejí čtyřmi fázemi. Na začátku je tzv. „úvodní studie“, která zdůvodňuje potřebu takového standardu a stanovuje základní charakteristiku obsahu standardu. Následuje tzv. "navrhovaný standard" (Proposed Standard). Tento standard je potřeba ověřit praktickou implementací, která obvykle odhalí nedostatky, které je nutné před převedením do třetí fáze odstranit. V třetí fázi je vytvořen tzv. "předběžný standard" (Draft Standard), který je již v podstatě „finálním“ standardem a neočekávají se v něm další významnější změny. Tento standard je obvykle dán k dispozici veřejnosti, k ověření jeho implementovatelnosti v širším měřítku. V poslední fázi je vytvořen tzv. „Final Standard“, který je již platným standardem. Oproti tomu standardy organizace International Organization for Standardization (ISO) procházejí šesti fázemi. „Návrhový stav“ (Proposal stage) se týká toho, zda je daný standard potřebný. Ve fázi „Přípravný stav“ (Preparatory stage) se vytvoří první pracovní verze standardu. V třetí fázi (Committee stage) se první pracovní verze zaregistruje na sekretariátu ISO a je rozeslána k připomínkování vybraným osobám a organizacím. Po zapracování připomínek vzniká draft International Standard (DIS). Ve čtvrté fázi (Enquiry stage) je standard rozeslán k připomínkování všem členům ISO. Výsledkem je final draft International Standard (FDIS). Ve schvalovací fázi (Approval stage) probíhá schválení standardu členy ISO. V poslední fázi (Publication stage) se upraví text do publikovatelné podoby a sekretariát ISO zajistí jeho publikování.
Vzhledem k tomu, že standard je obvykle dohodou, měl by být vytvořen minimálně dvěma subjekty. Často jsou však standardy obecnějšího charakteru a proto je k jejich vytvoření nutná účast více subjektů v dané oblasti působících. Tvorbou standardu se tedy obvykle zabývá skupina odborníků, kteří jsou k tomu určeni. Možností, jak takovéto skupiny vznikají, je mnoho a závisí to především na charakteru daného standardu. Skupiny mohou vznikat z řad pracovníků organizací, které se snaží na nějakém standardu dohodnout, nebo mohou vzejít z organizací, které se primárně standardizací zabývají a mají důvěru organizací, které jimi vytvářené standardy využívají. Existují však i standardy (a není jich málo), které jsou vytvořeny jediným subjektem. Takové standardy pak slouží pro vnitřní potřeby daného subjektu. Nicméně i takové standardy se mohou stát obecně platnými v případě, že je začne využívat více subjektů.
Nejvýznamnějšími organizacemi, které zasahují do procesu standardizace v oblasti geoinformatiky jsou zejména ISO [ISO 2002], OGC [OGC 2005b], ISOC [ISOC 2001], OASIS [OASIS 2005], W3C [W3C 2006b], [CEN 2002].
14
3.2 Popis dat
Velice důležitou složkou dat (samozřejmě i prostorových) je jejich popis. Tento popis označovaný obvykle jako metadata je často podceňován a opomíjen. Uvažme následující data: (1, 100, 150, 0.0064), (2, 120, 145, 0.0044), atd. Tato data nám byla dodána doc. Havlíkem a jsou důležitá pro naši práci. Doc. Havlík předtím než odjel na dovolenou (kde není k zastižení) sdělil pouze, že tato data dostal od někoho z firmy Velmi Velká Firma, a.s. Dále nám sdělil že to jsou koncentrace fenolů v podzemní vodě z vrtů v námi sledované oblasti. Po prohlédnutí takovýchto dat však zjistíme, že jsou pro nás naprosto bezcenná. Můžeme se dohadovat, že čísla 0.0064, 0.0044, atd. jsou koncentrace fenolů v mg/l (neboť taková koncentrace je v naší lokalitě očekávána). Dále můžeme čísla 1, 2 atd. vyhodnotit jako identifikátory jednotlivých vrtů. Čísla 100, 150, 120, 145, atd. by mohly být souřadnice daných vrtů. Soubor obsahuje hodnoty z 1500 vrtů. My však evidujeme pouze 500 vrtů. Používáme souřadnicový systém SJTSK (Systém jednotné trigonometrické sítě katastrální). Pro identifikaci vrtů používáme následující alfanumerické kódy: I1, I2, II1, IV
4, atd. Data, která máme k dispozici, jsou pro naši potřebu velmi špatně identifikovatelná, neli neidentifikovatelná a tudíž pro naši práci bezcenná.
Některý z následujících popisů dat (metadata) nám umožní původně bezcenná data využít.
Metadata1: Položky jednotlivých záznamů: Identifikátor vrtu, souřadnice x v místním souřadnicovém systému, souřadnice y v místním souřadnicovém systému, koncentrace fenolů v mg/l. Místní souřadnicový systém má osy orientované stejně jako SJTSK a počátek ve vrtu č.8, který má souřadnice SJTSK: x=1100303.22, y=455938.44. Měření byla prováděna 11.4.2000 v 9:00 hod.
Metadata2: Veškeré dostupné informace o daných datech má k dispozici ing. Vojtek. Ing. Vojtek je k dispozici na telefonním čísle 597325472 nebo emailové adrese [email protected]. Metadata3: Položky jednotlivých záznamů: Identifikátor vrtu, souřadnice x v místním souřadnicovém systému, souřadnice y v místním souřadnicovém systému, koncentrace fenolů v mg/l. Místní souřadnicový systém má osy orientované stejně jako SJTSK a počátek ve vrtu č.8, který má souřadnice SJTSK: x=1100303.22, y=455938.44. Měření byla prováděna 11.4.2000 v 9:00 hod. Veškeré další dostupné informace o daných datech má k dispozici ing. Vojtek. Ing. Vojtek je k dispozici na telefonním čísle 597325472 nebo emailové adrese [email protected].
Zatímco metadata1 nám umožní přímé využití dat (po několika úpravách), metadata2 nám umožní kontaktovat osobu (kontaktní místo), která může, ale také nemusí poskytnout potřebné informace pro využití dat. Metadata2 však mohou umožnit získání jiných doprovodných informací o poskytnutých datech. Ještě lepší variantou je kombinace obou popisů do metadat3. Tento stručný a názorný příklad poukazuje na několik skutečností, které se týkají metadat. Z příkladu vyplývá především to, že bez vhodných metadat jsou data často bezcenná Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
15
nebo obtížně použitelná. Druhá část příkladu demonstruje to, že často tou nejdůležitější složkou metadat je aktuální kontakt na zodpovědnou osobu. 3.2.1 Datová sada
Data bývají obvykle sdružována do kolekcí, které jsou označovány jako datové sady (data sets) nebo datové soubory (data files). Pojem "datová sada" je obecnější oproti pojmu "datový soubor". V dalším textu bude termín "datový soubor" představovat konkrétní soubor v souborovém systému paměťového média. Pojem "datová sada" bude představovat data tvořící logický celek v rámci určitého informačního systému či datové báze. Může se tedy jednat o jeden datový soubor či kolekci těchto souborů. Pojem datová sada nebude omezován jen na digitální data, ale může jím být označena i analogová forma dat (např. papírová mapa, atlas map, tištěný seznam majitelů parcel v okrese Nový Jičín). 3.3 Standardy pro popis, transformaci a vázání dat
Popsány jsou pouze standardy, které mají přímou vazbu na oblast GeoWeb a jsou základními obecnými nástroji pro popis, transformaci a vázání dat. Bez standardů pro popis dat, jejich transformaci a vytváření vazeb není možné efektivním způsobem využívat distribuované datové zdroje.
3.3.1 SGML
Jazyk SGML (Standard Generalized Markup Language), prazáklad značkovacích jazyků, vznikal již koncem 60tých let ve firmě IBM, která hledala možnost ukládání velkého množství právních dokumentů v programově a technicky nezávislém formátu. Jazyk SGML se dočkal standardizace v roce 1986 (ISO 8879) v rámci projektu ODA (Open Document Architecture) jako univerzální nástroj pro definici zápisu různých elektronických dokumentů nezávisle na HW a SW platformě a maximálně flexibilní.
SGML používá vláda USA (zvláště ministerstvo obrany) a velké společnosti jako IBM či Boeing.
Jednou z nejúspěšnějších aplikací jazyka SGML je elektronická dokumentace elektronických součástek, na jejímž standardu (standardu pro výměnu informací) se dohodly firmy Hitachi, Intel, National Semiconductors, Philips Semiconductors a Texas Instruments, které založili skupinu ECIX. Standard zahrnuje 2 části PCIS (Pinnacles Component Information Standard) a CIDS (Component Information Dictionary Standard). PCIS poskytuje informace o součástkách ve formátu, který lze snadno číst nebo ho importovat do CAD (Computer Aided Design) systémů. Najde se zde popis funkcí součástek, zapojení, montáže, instrukčních sad i balení, stejně jako paměťové mapy. Popis se odkazuje na slovník CIDS, kde jsou definovány termíny a vlastní součástky. Inženýři tak Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
16
mohou podstatně jednodušším způsobem zařazovat součástky různých firem do svých návrhů, hledat optimální, rychle zjišťovat jejich parametry.
Z jiných projektů lze jmenovat sadu specifikací pro údržbu letadel a výměny informací (Sdružení amerických leteckých dopravců), standard pro výměnu informací pro vozový park (Master Car Builder’s Association) atd. Aplikace SGML se příliš nerozšířily, protože jazyk je značně komplikovaný a aplikace jsou drahé. Stěží se tak může prosadit v prostředí Internetu. Na jeho základě však vznikly jazyky HTML (HyperText Markup Language) a XML (eXtensible Markup Language).
3.3.2 HTML
Jazyk HTML (HyperText Markup Language) slouží k tvorbě WWW dokumentů. Prostřednictvím HTML jazyka se definuje formátování textu, umístění obrázků, tabulky, formuláře, odkazy na jiné dokumenty a jiné prvky dokumentu. Definice těchto prvků se provádí pomocí HTML příkazů, které se vkládají do ASCII (American Standard Code for Information Interchange) nebo jinak kódovaného (např. UNICODE) textu dokumentu určeného k publikování. Tyto příkazy (značky) se zapisují mezi znaky <>. Řada těchto značek je párových tzn. že první značka označuje začátek určitého úseku dokumentu a druhá jej ukončuje (např. <font size=+1>Ahoj</font>). Značky mohou být modifikovány parametry.
Jazyk HTML je možné využívat např. v oblasti vizualizace prostorových dat nebo v oblasti popisu dat. Dokumenty vytvořené v jazyce HTML mohou být opatřeny metadaty. Obvykle se k tomu využívá značka META. Tato značka doplněná atributy a specifickými hodnotami může být dobře využita. V současné době bývá v této oblasti využíván zejména standard Dublin Core (viz dále).
Př. 3 1: Dublin Core v HTML (Převzato z [Kosek 2004])
<head>
<title>A Dirge</title>
<link rel="schema.DC"
href="http://purl.org/DC/elements/1.0/">
<meta name="DC.Title" content="A Dirge">
<meta name="DC.Creator" content="Shelley,
Percy Bysshe">
<meta name="DC.Type" content="poem">
<meta name="DC.Date" content="1820">
<meta name="DC.Format" content="text/html">
<meta name="DC.Language" content="en">
</head>
3.3.3 XML, XHTML
Jazyk XML (eXtensible Markup Language) patří do skupiny značkovacích jazyků. Na začátku roku 1998 byl konsorciem W3C uveden do života, zpočátku ne příliš aktivního. Vznikl zejména z důvodu tvorby takových WWW dokumentů, které by vnitřně popisovaly Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
17
svůj obsah a nezaměřovaly se pouze na formátování zobrazovaného obsahu v prostředí WWW prohlížeče. Postupem času si stále více vývojářů WWW prezentací uvědomuje potenciální výhody využití tohoto jazyka a jazyk začíná skutečně žít plnohodnotným životem jako jazyk HTML. Jazyk HTML se již nevyvíjí a do budoucna bude rozvíjen pouze jazyk XHTML, který je založen na jazyce XML.
XML vychází z jazyka SGML. Přestože jazyk HTML vychází rovněž jako XML z jazyka SGML, je zaměřen především na formátování vzhledu dokumentů tak jak jsou prezentovány uživateli. Stejně jako v případě jazyka HTML se autoři jazyka XML pokusili vytvořit relativně jednoduchý nástroj, v případě jazyka XML však zaměřený na popis obsahu dokumentů. Jazyk XML se snaží oprostit od složitých mechanismů jazyka SGML a přesto se zaměřit na formátování (popis) obsahu dokumentů.
XML dokumenty
XML dokumenty se skládají z textu (obsahu) a značek. Každý XML dokument může mít pevnou strukturu, která je definovaná v XML schématu (případně v deklaraci typu dokumentu). V ní je uvedeno, jaké prvky (elements) bude následující dokument obsahovat, kolikrát se mohou vyskytovat, jaké jiné prvky obsahují, jaké atributy mohou nebo musí mít a co mají obsahovat. Definuje se rovněž kořenový prvek, kterým celá struktura začíná.
V následující části je vlastní obsah dokumentu. Jakýkoliv text musí být uzavřen mezi značkami. K základním používaným značkám patří prvky, entity, komentáře a zpracovatelské instrukce. Prvek určuje význam textu, který ohraničuje. Začíná počáteční značkou a uzavírá se koncovou značkou. Př. 3 2: Značka XML dokumentu
<nazevDS>DMÚ 200</nazevDS>
Typ prvku je název datové sady a jeho obsahem je datová sada DMÚ (Digitální model území) 200.
Výhody XML
•
•
•
•
•
•
Pevnější pravidla strukturování než HTML (např. vynucování počátečních i koncových značek), přísně hierarchická stavba dokumentů.
Popis obsahu dokumentu metadaty.
Možnost používat standardy struktury dokumentů (DTD (Deklarace typu dokumentu), XML schémata) i možnost tvorby vlastních značek (definic dokumentů, schémat).
Podpora 32bitového kódování znaků (UNICODE, ISO 10646), což odstraní problémy s psaním a přenosem diakritických znaků.
Definice formátování dokumentů je oddělena od definice struktury a obsahu dokumentu (využití CSS nebo jazyka XSL (eXtensible Stylesheet Language)).
Možnost využití rozšířených odkazů pomocí XLink a XPointer. Jsou dovoleny obousměrné odkazy, je možné se odkazovat na část dokumentu (a přenést pouze Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
18
tuto část a ne celý dokument), lze se odkazovat na více míst současně (ze seznamu se vybírá konkrétní cíl), může se definovat odkaz i mimo návěští (např. na 3. prvek za návěštím). Odkazy lze ukládat i mimo stránku, ke které se vztahují. Z toho plyne lepší možnost centralizované správy dokumentů.
DTD
Pokud je využívána DTD (Deklarace typu dokumentu), pak musí být uvedena v úvodu každého dokumentu. Interní deklarace je celá popsána v dokumentu. Externí deklarace je provedena mimo vlastní dokument, ze kterého postačí provést odkaz na tuto definici. Existuje již celá řada uznávaných standardních DTD pro jednotlivé typy dokumentů, je však možné vytvářet své vlastní definice. Deklarace definuje jednotlivé používané prvky, jejich atributy, atd.
Př. 3 3: Definice prvků v DTD
<!ELEMENT datová_sada (název, organizace+, dokumentace?>
Prvek název se musí vyskytnout v dokumentu pro každý prvek datová sada právě 1x, za ním se musí vyskytnout 1 nebo více prvků organizace a nakonec může, ale nemusí být uvedena dokumentace.
<!ELEMENT organizace (název, popis*, adresa?>
Prvek organizace název se musí vyskytnout 1x, popis několikrát nebo také vůbec ne a nakonec adresa může, ale nemusí být uvedena. <!ELEMENT popis (#PCDATA|okeč>
Prvek popis obsahuje buď text (#PCDATA) nebo prvek okeč (| znamená OR).
Př. 3 4: Definice atributů prvků v DTD
Každý prvek může obsahovat definici atributů. Tyto mohou být několika typů. Nejjednodušším typem je CDATA, který umožňuje zadání libovolného textového řetězce. Striktnější omezení má typ NMTOKEN který umožňuje zadání jednoho spojitého znakového řetězce (písmena, číslice a několik speciálních znaků). Typ NMTOKENS umožňuje zadání několika řetězců typu NMTOKEN oddělených mezerou. Zvláštním typem je typ ID, který představuje jednoznačný identifikátor prvku. Další možností je vymezit typ seznamem možných hodnot. <!ATTLIST organizace
ICO ID #REQUIRED
Stat CDATA #IMPLIED
www NMTOKEN #IMPLIED
>
Vlastnost #IMPLIED značí že daný atribut nemusí být vůbec zadán. Vlastnost #REQUIRED značí že atribut je vyžadován.
19
XML Schémata
V některých případech je použití DTD nedostačující. Největším nedostatkem je nemožnost (nedostatečnost) definování datových typů pro jednotlivé značky.
Nestandardní syntaxe DTD vyžaduje, aby se vývojáři učili další jazyk (i když poměrně jednoduchý) pro popis struktury dokumentu. Syntaxe DTD je velice úsporná, což přesně odpovídá požadavkům doby, kdy vznikala. Dnes se většina vývojářů domnívá, že mnohem vhodnější je jazyk, založený na XML (někteří, a počet roste, se však raději věnují jazykům na jiné bázi jako např. Relax NG [Relax NG 2007]). Pro editaci schémat a jejich zpracování je pak možné využít nástroje, které již dnes existují pro XML.
Všechny nově vzniklé jazyky pro zápis schémat výše zmíněné nedostatky řeší. Kromě toho nabízejí další zajímavé rysy, které mohou být využity v určitých aplikačních oblastech.
Jedním z prvních schémat byl jazyk XMLData od společnosti Microsoft. Postupně byl zjednodušen a nazván XMLData Reduced (XDR). Používá se ve všech MS produktech (XML parser, BizTalk Server, SQL Server 2000). Mezi hodně používaná schémata patří i SOX (Schema for Objectoriented XML). Oproti XDR umožňuje ve schématech používat dědičnost. Jednotlivé části schémat mohou být sdíleny a opakovaně využívány. Velice jednoduchým jazykem, který ve své základní verzi nepodporuje různé datové typy je DDML (Document Definition Markup Language). Jeho hlavním cílem bylo poskytnou možnost zápisu DTD pomocí XML syntaxe, samotné možnosti DDML pro definici přípustné struktury dokumentu nenabízejí oproti DTD nic nového.
Př. 3 5: Definice prvků v XML schématu
<xs:element name="zamestnanec" type="osoba"/>
<xs:element name="student" type="osoba"/>
<xs:complexType name="osoba">
<xs:sequence>
<xs:element name="jmeno" type="xs:string"/>
<xs:element name="prijmeni" type="xs:string"/>
</xs:sequence>
</xs:complexType>
Př. 3 6: Definice prvků v XML schématu
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://ogr.maptools.org/"
xmlns:ogr="http://ogr.maptools.org/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml" elementFormDefault="qualified"
version="1.0">
<xs:import namespace="http://www.opengis.net/gml"
schemaLocation="http://schemas.opengeospatial.net/gml/2.1.2/feature.xsd"/>
<xs:element name="FeatureCollection" type="ogr:FeatureCollectionType"
substitutionGroup="gml:_FeatureCollection"/>
<xs:complexType name="FeatureCollectionType">
20
<xs:complexContent>
<xs:extension base="gml:AbstractFeatureCollectionType">
<xs:attribute name="lockId" type="xs:string" use="optional"/>
<xs:attribute name="scope" type="xs:string" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="kraje_pseudo" type="ogr:kraje_pseudo_Type"
substitutionGroup="gml:_Feature"/>
<xs:complexType name="kraje_pseudo_Type">
<xs:complexContent>
<xs:extension base="gml:AbstractFeatureType">
<xs:sequence>
<xs:element name="geometryProperty" type="gml:geometryPropertyType"
nillable="true" minOccurs="1" maxOccurs="1"/>
<xs:element name="cat" nillable="true" minOccurs="0" maxOccurs="1">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:totalDigits value="11"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="kodnuts" nillable="true" minOccurs="0"
maxOccurs="1">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="80"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="nazkr" nillable="true" minOccurs="0" maxOccurs="1">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="80"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="vymera" nillable="true" minOccurs="0" maxOccurs="1">
<xs:simpleType>
<xs:restriction base="xs:decimal">
<xs:fractionDigits value="15"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="ob91" nillable="true" minOccurs="0" maxOccurs="1">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
21
<xs:element name="ob01" nillable="true" minOccurs="0" maxOccurs="1">
<xs:simpleType>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
3.3.4 RDF
Resource Description Framework (RDF) je obecný jazyk sloužící k popisu zdrojů. V současné době využívá k zápisu metadat jazyk XML. Jedná se o rámec pro popis, který umožňuje lepší automatizované zpracování takto zapsaných metadat. RDF může sloužit jako obálka nebo doplnění k zápisu metadat a uvnitř zápisu se mohou vyskytovat různě strukturovaná metadata např. dle Dublin Core.
Př. 3 7 Zápis s využitím RDF (Převzato z [W3C 2007])
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns="http://xmlns.com/foaf/0.1/">
<Person>
<name>Dan Brickley</name>
<homepage dc:title="Dan's home page"
rdf:resource="http://danbri.org/"/>
<based_near geo:lat="51.47026" geo:long="-2.59466"/>
<rdfs:seeAlso rdf:resource="http:/danbri.org/foaf.rdf"/>

</Person>
</rdf:RDF>
3.3.5 OWL
Web ontology language je jazyk umožňující popis ontologií s využitím jazyka XML. OWL v kombinaci s RDF jsou základními stavebními kameny nové generace WWW, která je nazývána Semantic Web1.
1
Semantic Web se zatím jeví jako velmi zajímavý způsob sdílení dat a tedy i geodat. V této oblasti je však zatím výzkum teprve v
počátcích. Autor doporučuje tuto oblast prozkoumat (vhodné téma na doktorskou disertační práci nebo habilitační práci). Je velmi
pravděpodobné, že koncepce platformy otevřený GeoWeb navržená v závěru této práce by mohla být velmi efektivně doplněna o
prvky platformy Semantic Web. Možné doplnění je popsáno v závěru práce.
22
Zajímavé uplatnění popisuje rovněž příspěvek Geonames.org [Wick 2007], který se týká otevřeného svobodného celosvětového geografického rejstříku. Zde je OWL využíván zejména pro definování vazeb mezi jednotlivými prvky rejstříku.
Bezesporu zajímavým výzkumem v této oblasti je práce výzkumného týmu z Brazílie [Leite 2006].
Př. 3 8 Zápis tříd geoprvků (Převzato z [Leite 2006])
<rdf:RDF xmlns="http://localhost/ontologias/sudema.owl#"
xml:base="http://localhost/ontologias/sudema.owl"
xmlns:globalSDI="http://localhost/ontologias/globalSDI.owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:daml="http://www.daml.org/2001/03/daml+oil#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#">
<owl:Ontology rdf:about="">
<owl:imports
rdf:resource="http://localhost/ontologias/aesa.owl"/>
</owl:Ontology>
<owl:Class rdf:ID="Body_of_Water">
<rdfs:subClassOf rdf:resource="&owl;Thing"/>
<rdfs:subClassOf>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="&globalSDI;Dam"/>
<owl:Class rdf:about="&globalSDI;Lake"/>
<owl:Class rdf:about="&globalSDI;Well"/>
<owl:Class rdf:about="&globalSDI;River"/>
</owl:unionOf>
</owl:Class>
</rdfs:subClassOf>
</owl:Class>
<owl:DatatypeProperty rdf:ID="hasType"/>
<owl:Class rdf:ID="Geometry"/>
</rdf:RDF>
3.3.6 CSS
Cascade Style Sheets (CSS) slouží pro formátování WWW dokumentů. Umožňují mnohem snazší a efektivnější formátování něž pouhé nástroje (značky) HTML. Styl je možno nastavit na jakoukoli značku dokumentu. U některých značek však některé parametry stylu nemají význam.
Př. 3 9 Zápis CSS
Název_značky.Třída_značky {
Parametr_stylu: hodnota;
}
P { font-family: Courier; font-size: 24px;} /*styl bez třídy */
23
Styly je možné pro formátovaní HTML stránek použít dvěma způsoby. V prvním případě se styl zapisuje přímo do HTML kódu. V druhém případě se zapisuje do samostatného souboru a do HTML se importuje.
Kaskádové styly se dědí z nadřízené značky do podřízené. Nemyslí se tím vztah např. mezi značkami <H1> a <H2>. Tímto vztahem je míněno vnoření jedné značky do druhé. Např. většina značek v HTML kódu je vnořena do značky <BODY>. Pokud se nastaví nějaká vlastnost, která se dědí, na značku BODY, nastaví se automaticky na vnořené značky.
3.3.7 XSL
XSL je eXtensible Stylesheet Language. Jedná se o transformační jazyk, který umožňuje převádět dokumenty z jedné podoby do jiné (např. XML do HTML nebo XHTML).
Př. 3 10 XML dokument s údaji o nabídce snídaní pro transformaci. (Převzato z [W3C 2005b])
<?xml version="1.0" encoding="ISO8859-1" ?>
<?xml:stylesheet type="text/xsl" href="simple.xsl" ?>
<breakfast-menu>
<food>
<name>Belgian Waffles</name>
<price>$5.95</price>
<description>two of our famous Belgian Waffles with plenty of real
maple syrup</description>
<calories>650</calories>
</food>
<food>
<name>Strawberry Belgian Waffles</name>
<description>light Belgian waffles covered with strawberrys and
whipped cream</description>
</food>
<food>
<name>Berry-Berry Belgian Waffles</name>
<description>light Belgian waffles covered with an assortment of fresh
berries and whipped cream</description>
</food>
<food>
<name>French Toast</name>
<description>thick slices made from our homemade sourdough
bread</description>
</food>
<food>
<name>Homestyle Breakfast</name>
<description>two eggs, bacon or sausage, toast, and our ever-popular
hash browns</description>
24
</food>
</breakfast-menu>
Př. 3 11 Následující kód transformuje XML dokument obsahující údaje o nabídce snídaní do HTML podoby. (Převzato z [W3C 2005b])
<?xml version="1.0"?>
<HTML xmlns:xsl="http://www.w3.org/TR/WD-xsl">
<BODY STYLE="font-family:Arial, helvetica, sans-serif; font-size:12pt;
background-color:#EEEEEE">
<xsl:for-each select="breakfast-menu/food">
<DIV STYLE="background-color:teal; color:white; padding:4px">
<SPAN STYLE="font-weight:bold; color:white"><xsl:value-of
select="name"/></SPAN>
- <xsl:value-of select="price"/>
</DIV>
<DIV STYLE="margin-left:20px; margin-bottom:1em; font-size:10pt">
<xsl:value-of select="description"/>
<SPAN STYLE="font-style:italic">
(<xsl:value-of select="calories"/> calories per serving)
</SPAN>
</DIV>
</xsl:for-each>
</BODY>
</HTML>
Příkladem využití jazyka XSL pro oblast platformy GeoWeb může být komponenta určená k vizualizaci standardu „ISVS (Informační systém veřejné správy) pro metadata“ [ÚVIS 2001] v prostředí nástroje ArcCatalog. ArcCatalog využívá pro evidenci metadat jazyk XML (eXtensible Markup Language). Metadata jsou tedy ukládána jako XML dokumenty (soubory). Pro tvorbu těchto souborů se v prostředí aplikace ArcCatalog využívá interní editor metadat, který umožňuje vytváření XML dokumentů v souladu se standardy FGDC (Federal Geographic Data Committee) a ISO (pro popis můžete nahlédnout např. do [FGDC 1998], [ISO 1999]). Pro každý ze standardů existuje samostatný editor. Pro vizualizaci takto vytvořených XML dokumentů využívá ArcCatalog XSL (eXtensible Stylesheet Language) šablony, kde existuje pro každý ze standardů několik různých šablon pro různý vzhled (uspořádání, formátování) vizualizovaného dokumentu.
Standard ISVS rovněž definuje používání XML dokumentů pro evidenci metadat. Je tedy možné standard ISVS využívat i v prostředí aplikace ArcCatalog? Naneštěstí tomu tak není. Skripty dostupné ve standardní verzi aplikace ArcCatalog nerozumí standardu ISVS a zobrazují téměř prázdnou stránku (obvykle chybové hlášení nebo poznámku), podobně je tomu u interních editorů metadat.
Pro používání standardu ISVS je tedy nezbytně nutné vytvořit XSL šablony a editor metadat integrovaný do prostředí aplikace ArcCatalog. Z tohoto důvodu vznikl na VŠB
TUO, institutu geoinformatiky projekt, který si kladl za cíl vytvořit nástroj plně integrovaný Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
25
do prostředí ArcCatalog, který by umožnil prohlížení, editaci a pořizování metadat, které jsou v souladu se standardem ISVS. První fáze projektu byla zaměřena na prohlížení metadat, především z důvodu častějšího využívání této operace a existence již poměrně velkého množství XML dokumentů v souladu se standardem ISVS. Druhá fáze, která byla zaměřena na editační část, nakonec nebyla dokončena z důvodu přechodu na standard ISO.
Celá koncepce řešení je zobrazena na obrázku 31. Pro prohlížení metadat v prostředí aplikace ArcCatalog byl Petrem Papcunem vytvořen skript [Růžička 2004c], který umožňuje metadata uložená v XML dokumentech v souladu se standardem ISVS transformovat do podoby čitelné běžnému uživateli. Záměrně byla zvolena podoba (styly, barvy, fonty) používané v centrálním metainformačním systému MIDAS [CAGI 2006].
Použití skriptu v prostředí aplikace ArcCatalog je velmi jednoduché. Skript který se jmenuje ISVS.xsl se umístí do adresáře x:\arcgis\arcexe8?\Metadata\Stylesheets. A potom je již skript použitelný přímo v rozbalovacím seznamu skriptů produktu ArcCatalog. Pokud chceme používat ISVS standard jako implicitní standard, pak je ještě potřeba nastavit určité parametry v dialogovém okně Options aplikace ArcCatalog. Celý postup zavedení skriptu ISVS.xsl do produktu ArcCatalog je popsán v dokumentaci ke skriptu [Papcun 2004].
26
Obr. 31: Využití XML a XSL v prostředí ArcCatalog a MIDASLite (Převzato z [Růžička 2004c])
27
Obr. 32: XML dokument před transformací
Obr. 33: XML dokument po transformaci
Jiným příkladem využití jazyka XSL pro oblast platformy GeoWeb může být komponenta určená k transformaci metadat dle „ISVS pro metadata“ [ÚVIS 2001] do tvaru dle standardu ISO 19115 [ISO 1999]v prostředí nástroje ArcCatalog. Jan Kucharczyk vytvořil dvě XSL šablony pro transformaci. První šablona umožňuje transformaci bez využití rozšíření standardu ISO 19115. Pro druhou šablonu bylo navrženo rozšíření standardu ISO 19115.
28
3.4 Standardizace zápisu prostorových dat
K tomu aby mohla být problematika GeoWeb pojata komplexně je nutné popsat systém standardizace v oblasti prostorových dat a práce s nimi. Tato oblast práce poskytuje základní přehled v oblasti standardizace prostorových dat a návaznost na standardizaci jiných příbuzných oblastí. 3.4.1 Geometrické prvky
Popis geometrických prvků se velmi intenzivně vyvíjel a z tohoto důvodu vzniklo množství navzájem nekompatibilních způsobů popisu. V zásadě téměř každý programový produkt (resp. společnost) zavádí svůj vlastní proprietární formát. Nekompatibilitu různých formátů ve způsobu zápisu geometrické složky popisu geoprvku se snaží odstranit OGC (Open Geospatial Consortium). Z iniciativy konsorcia vznikla abstraktní specifikace nazvaná Simple Features.
Tato abstraktní specifikace definuje způsob popisu jednoduchých geometrických prvků a také možné operace s nimi prováděné, jako je např. překryv prvků, obálka. Základní definované prvky jsou bod, linie a polygon. Specifikace také uvádí jak vytvářet kolekce těchto prvků.
29
Obr. 34: Příklady Simple Features (Převzato z [Růžička 2005l])
30
Obr. 35: Hierarchie tříd Simple Features (Převzato z [OGC 1999c])
Z této abstraktní specifikace vychází dále popsaný jazyk GML (Geography Markup Language), ale především implementační specifikace z nichž nejznámější je Simple Features for SQL.
Simple Features for SQL definují jakým způsobem je možné manipulovat s geometrickými prvky s využitím jazyka SQL. Zavádí tedy pravidla pro to jak definovat bod, linii, polygon s využitím jazyka SQL, jak provádět prostorové operace.
Simple Features for SQL zavádí dva velmi důležité pojmy Well Known Text (WKT) a WKB (Well Known Binary). WKT je způsob zápisu geometrie s využitím textového popisu (viz příklad) a WKB je obdoba WKT, ale zápis je binární a zabírá tak méně místa v paměti počítače.
Př. 3 12 WKT (Převzato z [OGC 1999c])
‘POINT (10 10)’
‘LINESTRING ( 10 10, 20 20, 30 40)’
‘POLYGON ((10 10, 10 20, 20 20, 20 15, 10 10))’
‘MULTIPOLYGON (((10 10, 10 20, 20 20, 20 15, 10 10)), ((60 60, 70 70, 80
60, 60 60 ) ))’
‘GEOMETRYCOLLECTION (POINT (10 10), POINT (30 30), LINESTRING (15 15, 20 20))’
3.4.2 Výměnné formáty
Pro výměnu prostorových dat existuje řada formátů. K těm hlavním vektorovým patří GML, SVG (Scalable Vector Graphics), VRML (Virtual reality modelling language) (X3D), Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
31
ESRI Shapefile, DXF. K rastrovým patří, zejména GeoTIFF, TIFF (Tag Image File Format) a PNG (Portable Network Graphics).
GML
Geography Markup Language (GML) definuje jak s pomocí jazyka XML zapsat základní geometrická primitiva (simple features). Ve verzi 3.0 přidává další možnosti jako je definování souřadnicových systémů, stylů, animací, pohybu objektů. GML je tedy založen na jazyce XML a umožňuje přenos vektorových geodat. Ukázka GML je na obr. č. 45, který znázorňuje GML v prostředí nástroje JUMP Workbench.
Obr. 36: GML v prostředí aplikace JUMP Workbench
GML není formátem jak se mnoho uživatelů domnívá, ale jazykem, proto zároveň s GML dokumenty by měl být k dispozici dokument popisující schéma použité pro tyto GML dokumenty.
Př. 3 13 GML 2.0
<?xml version="1.0" encoding="utf-8" ?>
<ogr:FeatureCollection
xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
xsi:schemaLocation=". kraje_pseudo.xsd"
xmlns:ogr="http://ogr.maptools.org/"
32
xmlns="http://ogr.maptools.org/"
xmlns:gml="http://www.opengis.net/gml">
<gml:boundedBy>
<gml:Box>
<gml:coord><gml:X>-904222.837576437</gml:X><gml:Y>1227241.528725796</gml:Y></gml:coord>
<gml:coord><gml:X>-431433.3321681719</gml:X><gml:Y>935237.8791404357</gml:Y></gml:coord>
</gml:Box>
</gml:boundedBy>
<gml:featureMember>
<kraje_pseudo fid="0">
<cat>6</cat>
<nk>US</nk>
<kn>6</kn>
<kodnuts>CZ042</kodnuts>
<nazkr>Ustecky</nazkr>
<nazkr_a>Ustecky</nazkr_a>
<vymera> 533492.060000000055879</vymera>
<ob91>824461</ob91>
<ob01>820219</ob01>
<obakt>820868</obakt>
<nazcs>YVXFCMc</nazcs>
<zmenazaz>01012000</zmenazaz>
<ogr:geometryProperty><gml:Polygon><gml:outerBoundaryIs><gml:LinearRing><gml
:coordinates>-732885.511,-998448.558 -732885.511,-998448.558 -733385.882,998448.558 -733385.882,-998448.558 -733886.253,-998948.858 -733886.253,1000950.056 -734386.624,-1001450.356 ...
SVG
Jednou z významných aplikací jazyka XML je specifikace otevřeného vektorového formátu nazvaného SVG (Scalable Vector Graphics). Pro tento grafický formát je charakteristické využití standardních externích DTD jazyka XML, které jsou spravovány organizací W3C (World Wide Web Consortium).
Formát SVG umožňuje definovat základní geometrické objekty jako je bod, linie, polygon, elipsa. Umožňuje definovat další parametry jako je maskování, filtrace a je možné definovat i interaktivitu objektů na základě činnosti uživatele (např. kliknutí myší).
Protože se jedná o otevřený formát může jej vytvářet kdokoli se znalostí jazyka XML. Některé aplikace (obvykle pro práci s vektorovou grafickou např. Inkscape, Open Office Draw, Corel Draw) umožňují export do formátu SVG.
K vizualizaci souboru ve formátu SVG se v některých prohlížečích musí využívat rozšíření prohlížeče buď ve formě Plugin nebo Java applet. Výjimkou jsou některé prohlížeče (např. Mozilla (Mozilla Firefox) nebo Opera), které již dokáží formát SVG vizualizovat přímo. Některé desktop aplikace pro práci s prostorovými daty také umožňují vizualizaci SVG formátu.
Př. 3 14 SVG
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000303 Stylable//EN"
"http://www.w3.org/TR/2000/03/WD-SVG-200003023/DTD/svg-20000303stylable.dtd">
33
<svg width="20cm" height="15cm" viewBox="0 -1916 2000 1916 ">
.
Zde se nachází obsah elementů vrstev sídla a silnice
.
<polyline id="463" style="fill:none; stroke:#FF00; stroke-width:1"
points = "1431,-178 1440,-171 1440,-169" onclick="showDetailData(463,
'silnice')" ></polyline>
</g>
<g id = "DS3">
<polygon id="1" style="fill:#0FFFF; stroke:#000; stroke-width:1"
points = "1325,-1044 1331,-1035 1334,-1025 1329,-1015 1319,-1016 1308,1015 1303,-1006 1305,-996 1314,-991 1319,-982 1325,-993 1335,-996 1345,994 1348,-984 1350,-974 1349,-964 1344,-954 1350,-944 1359,-939 1361,-929
1361,-918 1357,-908 1359,-897 1364,-887 1368,-876 1361,-867 1351,-862
1346,-850 1341,-840 1331,-838 1321,-845 1306,-847 1294,-846 1288,-837
1292,-826 1293,-816 1286,-806 1276,-803 1266,-805 1258,-797 1252,-788
1254,-777 1243,-772 1237,-781 1226,-789 1215,-793 1205,-797 1195,-793
1185,-795 1174,-799 1169,-808 1168,-818 1162,-828 1151,-828 1146,-837
1136,-839 1134,-849 1139,-859 1138,-869 1140,-879 1145,-888 1149,-899
1139,-901 1133,-910 1139,-920 1141,-930 1137,-940 1128,-946 1118,-947
1105,-943 1114,-949 1107,-958 1116,-965 1120,-976 1124,-986 1136,-990
1135,-1000 1144,-994 1154,-999 1162,-991 1167,-981 1179,-984 1189,-983
1199,-977 1208,-971 1214,-982 1219,-991 1226,-983 1237,-982 1246,-989
1256,-996 1264,-1003 1274,-1004 1284,-1007 1294,-1012 1302,-1019 1307,1029 1314,-1037 1324,-1040" onclick="showDetailData(1, 'DS3')" ></polygon>
</g>
<g id = "DS2">
<rect id="1" x="790" y="-1052" width="162" height="115"
style="fill:#EA3522A; stroke:#000; stroke-width:1"
onclick="showDetailData(1, 'DS2')" ></rect>
</g>
<g id = "DS1">
<polygon id="1" style="fill:#9D9D275; stroke:#000; stroke-width:1" points
= "375,-1387 404,-1408 433,-1387 497,-1304 518,-1254 553,-1177 596,-1129
620,-1081 532,-1091 518,-1142 484,-1201 415,-1262 377,-1318"
onclick="showDetailData(1, 'DS1')" ></polygon>
</g>
</svg>
VRML, X3D
Virtual reality modeling language (VRML) je jazyk umožňující definovat 3D scény. Tento jazyk je otevřený, dokumentovaný a poskytuje nástroj pro prezentaci 3D objektů a scén v prostředí WWW. V současné době není bohužel přímo podporován žádným z prohlížečů. K prohlížení je nutné instalovat Plugin (např. Cosmo Player, Cortona nebo FreeWRL). K dispozici pro tvorbu VRML scén je možné využít buď libovolný textový editor nebo některý z nástrojů, u kterých je však využívání často zpoplatněno (např. Cosmo Software, 3D studio, ArcGIS) nebo je exportovaný soubor neoptimalizován (např. Blender). VRML umožňuje definovat prvky modelu jako jsou: koule, válce, kužely, kvádry, libovolné 3D objekty definované lomovými body, gridy (úspora kódu). Kromě jednoduchých objektů umožňuje jednoduché objekty kombinovat do komplexních objektů. Rovněž je možné Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
34
definovat vzhled objektů (barva, textura) a k objektům připojovat externí URL (Uniform Resource Locator) odkazy.
K dalším možnostem patří vkládání zvuků, umisťování videa, popisků. V neposlední řadě je k dispozici možnost skriptování, vytváření animací.
Př. 3 15 VRML
#VRML V2.0 utf8
#
#
#
#
This file was authored with Blender (http://www.blender.org/)
Blender version 241
Blender file kostkafranta.blend
Exported using VRML97 exporter v1.55 (2006/01/17)
NavigationInfo {
headlight FALSE
visibilityLimit 100.0
type ["EXAMINE", "ANY"]
avatarSize [0.25, 1.75, 0.75]
}
Background {
groundColor 0.057 0.221 0.4
skyColor 0.057 0.221 0.4
}
DEF Cube Transform {
translation 0.118 0.0 0.63
children [
Shape {
appearance Appearance {
material DEF MA_Material Material
{
diffuseColor 0.8 0.8
0.8
ambientIntensity 0.167
specularColor 0.401
0.401 0.401
emissiveColor 0.0 0.0
0.0
shininess 0.098
transparency 0.0
}
}
geometry IndexedFaceSet {
solid TRUE
coord DEF coord_Cube Coordinate {
point [
1.0 -1.0
-1.0, 1.0 -1.0 1.0, -1.0 -1.0 1.0, -1.0 -1.0 -1.0, 1.0 1.0 -1.0, 1.0 1.0 1.0, -1.0
1.0 1.0, -1.0 1.0 -1.0,
]
}
coordIndex [
0 1 2 3 -1, 4 7 6 5
-1, 0 4 5 1 -1, 1 5 6 2 -1, 2 6 7 3 -1, 4 0 3 7 -1,
]
}
}
35
]
}
DEF Lamp PointLight {
ambientIntensity 0.0
color 1.0 1.0 1.0
intensity 0.571
location 4.076 5.904 -1.005
radius 29.9999828339
}
DEF Camera Viewpoint {
description "Camera"
position 7.48 5.34 6.51
orientation -1.05 1.91 0.47 0.93
fieldOfView 0.661
}
X3D je následovník VRML s tím rozdílem, že jeho syntaxe je založena na jazyce XML. Jazyk X3D je navíc připraven (resp. prohlížeče souborů v tomto jazyce připravených) pro práci s geografickými (nebo projektovanými) souřadnicemi.
Př. 3 16 X3D
<!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.0//EN"
"http://www.web3d.org/specifications/x3d-3.0.dtd">
<X3D version="3.0" profile="Immersive"
xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance"
xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d-3.0.xsd">
<head>
<meta name="filename" content="kostkafranta.blend" />
<meta name="generator" content="Blender 241" />
<meta name="translator" content="X3D exporter v1.55 (2006/01/17)" />
</head>
<Scene>
<NavigationInfo headlight="FALSE" visibilityLimit="100.0" type="EXAMINE, ANY"
avatarSize="0.25, 1.75, 0.75" />
<Background groundColor="0.057 0.221 0.4" skyColor="0.057 0.221 0.4" />
<Transform DEF="Cube" translation="0.118 0.0 0.63">
<Shape>
<Appearance>
<Material DEF="MA_Material" diffuseColor="0.8
0.8 0.8" specularColor="0.401 0.401 0.401" emissiveColor="0.0 0.0 0.0"
ambientIntensity="0.167"
shininess="0.098" transparency="0.0" />
</Appearance>
<IndexedFaceSet solid="true" coordIndex="0 1 2 3 -1, 4 7 6
5 -1, 0 4 5 1 -1, 1 5 6 2 -1, 2 6 7 3 -1, 4 0 3 7 -1, ">
<Coordinate DEF="coord_Cube"
point="1.0 -1.0 -1.0, 1.0 -1.0
1.0, -1.0 -1.0 1.0, -1.0 -1.0 -1.0, 1.0 1.0 -1.0, 1.0 1.0 1.0, -1.0 1.0 1.0, -1.0
1.0 -1.0, " />
</IndexedFaceSet>
</Shape>
</Transform>
<PointLight DEF="Lamp" ambientIntensity="0.0" color="1.0 1.0 1.0"
intensity="0.571" radius="29.9999828339" location="4.076 5.904 -1.005" />
36
<Viewpoint DEF="Camera" description="Camera" centerOfRotation="0 0 0"
position="7.48 5.34 6.51" orientation="-1.05 1.91 0.47 0.93"
fieldOfView="0.661" />
</Scene>
</X3D>
Rastrové formáty
V oblasti geoinformatiky je dnes používáno mnoho rastrových formátů. Zde se omezíme pouze na shrnutí.
Pro ukládání prostorových dat v rastrové podobě se dnes ustálilo několik formátů. Hlavní prim stále hraje formát TIFF (Tag Image File Format) resp. GeoTIFF a to především jeho dlaždicová nebo pyramidová varianta. Z hlediska úspory místa se prakticky ustálily dva komprimované formáty založené na waveletové kompresi MrSID (Multiresolution Seamless Image Database) a ECW (ER Mapper Compressed Rasters). Oba formáty nabízejí zhruba stejnou míru komprese, přičemž ECW je z hlediska licenčních podmínek přístupnější. Třetí formát JPEG (Joint Picture Experts Group) 2000, který rovněž implementoval kompresi s využitím technologie wavelet, se zatím moc nerozšířil.
Pro distribuci rastrových dat v prostředí WWW se dnes primárně využívá formát PNG (Portable Network Graphics). Méně často se setkáme s formátem JPEG (ten je pro většinu kartografických výstupů nevhodný kvůli svému typu komprese založením na DCT (Discrete Cosine Transformation). Po vypršení patentu na formát GIF zažívá tento formát renesanci. GIF je vhodný pro většinu mapových výstupů, kde se nevyskytují plynulé barevné přechody. Nevhodný jed tedy formát GIS např. pro barevné letecké nebo družicové snímky. Další významné formáty a jazyky
Dalších významných formátů existuje celá řada a není v možnostech této práce všechny vyjmenovat natož pak popsat. Pro doplnění je však vhodné uvést alespoň následující. KML (Keyhole Markup Language) je novým formátem, který se začíná rozšiřovat především s příchodem nástroje Google Earth. Jedná se o značkovací jazyk na bázi XML umožňující popis trojrozměrných geografických prvků, včetně možností nastavení vzhledu, popisků a pohledů na data. NMEA (National Marine Electronics Association) vyvinula formát pro přenos dat z GPS (Global Positioning Systems) přijímače. De facto se jedná o standard, který je hojně využíván a podporován.
GPX (GPS Exchange Format) je formát pro výměnu dat pro GPS přijímače založený na jazyce XML. Jedná se o nový formát, který se však již začíná hojně využívat.
ESRI Shapefile je významný výměnný formát vytvořený společností ESRI. Tím, že společnost ESRI tento formát dobře zdokumentovala umožnila jeho hojné využívání. V zásadě se dnes již jedná o nepsaný standard pro přenos zejména 2D geodat.
37
DXF má původ v programu AutoCAD. Umožňuje přenos 2D i 3D konstrukčních prvků. V určité (dnes už omezené) míře se využívá i v oblasti geoinformatiky. LandXML je formátem, který si klade za cíl popis dat zejména z oblasti geodézie a katastru nemovitostí. V současné době jej nabízejí i některé GPS přijímače jako výstupní formát. Tento formát je velkou neznámou, přestože se o experimentování s ním již pokouší i OGC.
Pravděpodobnost využívání
Formát SVG je nevhodný pro výměnu dat, ale najde uplatnění v kartografii.
Dlouhodobě je předpokládáno stálé využívání formátu ESRI Shapefile, a to především z důvodu jednoduchosti.
Jazyk GML si bude hledat cestu velmi obtížně. Důvodem je přílišná komplexnost jazyka. Pomoci může, ale je to nepravděpodobné, specifikace WFS (Web Feature Service), popsaná dále. Postupně budou vznikat formáty založené na jazyce GML např. JML (JUMP GML).
Velmi perspektivně se jeví formát KML, který je jednoduchý, umožňuje definici ve 3D prostoru. Je pravděpodobné, že tento formát si najde cestu k laickým uživatelům, kteří však v budoucnu budou tvořit základ geoinformatické komunity.
Jako velmi neperspektivní se pro výměnu dat pro 3D prostor jeví jazyky VRML a X3D. Přes všechnu snahu, výzkum ukazuje, že se jedná pro většinu z uživatelů příliš komplikované a jednostranné zaměřené formáty virtuální reality.
3.5 Metadata pro prostorová data a jejich standardizace
Metadata pro prostorová data by měla vycházet z obecného charakteru metadat a tudíž obsahovat základní náležitosti tak jak jsou prezentovány např. v podobě Dublin Core. Toto potvrzuje např. implementace standardu CSW 2.0 (Catalogue Services for the Web), kde je jako implicitní záznam využívána právě podmnožina prvků Dublin Core.
Metadata pro prostorová data pak tento obecný základ rozšiřují o prvky podstatné pro jejich prostorový charakter. Tato kapitola prezentuje v obecné rovině prvky metadat pro prostorová data s důrazem na prvky týkající se především prostorového charakteru dat. Výčet prvků v této kapitole není natolik úplný aby mohl být považován za předpis pro strukturu metadat pro prostorová data. Tento výčet se snaží především zavést diskusi o jednotlivých prvcích metadat a jejich vzájemné vazbě. Další výklad je zaměřen na popis metadat pro datovou sadu prostorových dat. Stále více je však nutné uvažovat také o metadatech popisujících služby platformy otevřený GeoWeb. Zde se pak uplatňují standardy ISO 19119, WSDL (Web Services Description Language), UDDI (Universal Description, Discovery and Integration) apod. Dané specifikace jsou popsány dále neboť hrají významnou roli při využívání platformy otevřený GeoWeb.
38
Standardizace v oblasti metadat probíhá již řadu let a tak jsou k dispozici různé standardy specifického charakteru. V oblasti prostorových dat lze sledovat vývoj standardizace především na příkladu amerického národního standardu organizace Federal Geographic Data Committee (FGDC). Počátky standardizace v této oblasti se datují do poloviny 90. let dvacátého století. Standardy pro metadata pro prostorová data mají své specifické vlastnosti a ani po několika letech působení odborníků v této oblasti nejsou všechny otázky vyřešeny.
Stále častější provázání různých oborů vytváří spletitou síť informačních zdrojů, které jsou použitelné pro různé oblasti lidské činnosti. Vzhledem k tomu, že každý obor používá pro metadata své specifické standardy, existuje značné množství navzájem nekompatibilních popisů dat. Aby bylo možné v těchto metadatových záznamech vyhledávat standardním způsobem, musí existovat předpis, který stanovuje prvky obecného metadatového záznamu. Takovýto předpis vznikl roku 1995 v Kanadě a je označován Dublin Core. Dnes je tento standard standardem ISO. 3.5.1 Dublin Core
Dublin Core je obecné doporučení, co by měl každý metadatový záznam obsahovat. Na prvním doporučení se shodli odborníci z různých oblastí na kongresu v Dublinu (Ohio, Kanada) roku 1995. Výsledkem tohoto kongresu byl vznik otevřeného fóra The Dublin Core Metadata Initiative. Toto fórum je zaměřené na vývoj v oblasti metadat. Fórum se zabývá tvorbou standardů, pořádáním konferencí a vzděláváním. V této kapitole je uveden přehled jednotlivých elementů, včetně jejich popisu. Dublin Core popisuje tzv. Informační zdroje (resources). Datovým zdrojem může být například datová sada, datový soubor nebo organizace zabývající se prodejem dat nebo zvuková nahrávka. Dublin Core je natolik obecným předpisem, že umožňuje popsat jakýkoliv datový zdroj. Tabulka 41 obsahuje popis struktury Dublin Core. Tabulka 31: Struktura Dublin Core (přeloženo z [DCMI 1999] a doplněno komentáři)
Položka
Title
Creator
Subject
Description
Publisher
Contributor
Popis
Označení přiřazené datovému zdroji
Subjekt, který je primárně zodpovědný za vytvoření obsahu datového zdroje. Popis by měl ukazovat na osobu nebo organizaci, včetně kontaktu.
Typ obsahu datového zdroje. Obvykle se k definování využívá klíčových slov nebo termínů z řízeného slovníku (tezauru).
Popis datového zdroje. Měl by zahrnovat (není to však podmínkou) abstrakt, obsah (rejstřík), ukazatel na grafickou reprezentaci obsahu a volný popisující text.
Subjekt, zodpovědný za zpřístupnění datového zdroje. Popis by měl ukazovat na osobu nebo organizaci, včetně kontaktu.
Subjekt, který se podílí na vytvoření obsahu datového zdroje. Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
39
Položka
Popis
Popis by měl ukazovat na osobu nebo organizaci, včetně kontaktu.
Date Datum (data) týkající se životního cyklu datového zdroje. Obvykle se uvádí datum vzniku a datum, do kterého je datový zdroj platný.
Type
Typ obsahu datového zdroje. Obvykle se k definování využívá klíčových slov nebo termínů z řízeného slovníku (tezauru). Oproti elementu Subject se zaměřuje detailněji na strukturu.
Format
Fyzický nebo digitální charakter datového zdroje. Je vhodné využít termín(y) z řízeného slovníku (např. MIME (Multipurpose Internet Mail Extensions) [Hood 2006]) .
Identifier
Identifikátor v rámci nějakého identifikačního systému. Jako příklad může sloužit ISBN (International Standard Book Number) nebo URI (Uniform Resource Identifier) [W3C 2006c].
Source
Ukazatel na zdroj(e) ze kterého je popisovaný datový zdroj získán. Language
Jazyk, ve kterém se nachází obsah datového zdroje.
Relation
Ukazatel na příbuzný (v jakékoliv vazbě) datový zdroj.
Coverage
Popis rozsahu datového zdroje. Popisuje se vztah k území (buď ve formě souřadnic, nebo jiné (nepřímé prostorové referenční systémy)) a vztah k časové ose.
Rights
Informace o právech k datovému zdroji. Jako příklad může být uvedeno autorské právo nebo duševní vlastnictví.
Všechny prvky Dublin Core uvedené v tabulce 41 jsou doporučením pro ostatní aktivity v oblasti metadat. Každý metadatový popis by měl být v souladu s uvedeným Dublin Core. Z uvedeného přehledu je patrné, že ne všechny elementy mohou být u všech datových zdrojů uvedeny. Např. informace o jazyce je nezjistitelná u většiny družicových, či leteckých snímků, a to z důvodu, že tyto zdroje příslušný druh dat neobsahují. 3.5.2 Standardy pro metadata o prostorových datech
V současné době existuje pro popis metadat pro geoinformace (geodata) několik více či méně závazných standardů. V Evropě byl využíván standard CEN (European Commitee for Standardization) prEN 12657 Geographic Information – Metadata. Jiným standardem v této oblasti je standard americké organizace FGDC (Federal Geographic Data Committee) nazvaný Standard for Digital Geospatial Metadata (SDGM). Dalším je standard organizace ISO (ISO CD 19115, Geographic information – Metadata). Jisté aktivity, ve formě doporučení, pochází z Open Geospatial Consorcia. K dispozici je také množství oborových či národních standardů, které však často vychází z výše zmíněných standardů či Dublin Core.
40
V České republice se využívá především standard ISO, doznívá využívání standardů CEN a FGDC, existují však i české standardy. Doznívajícím standardem je např. překlad standardu CEN a je označován jako norma ”ČSN (Česká technická norma) P ENV 12657 Geografická informace – Popis dat – Metadata” nebo standard ÚVIS (Úřad pro veřejné informační systémy) nazvaný „Standard ISVS (Informační systém veřejné správy) pro strukturu a výměnný formát metadat informačních zdrojů“.
V dalším textu budou jednotlivé standardy stručně popsány a v další kapitole následuje jejich srovnání.
ISO CD 19115, Geographic information – Metadata
Standard ISO je nejmladším standardem v této oblasti a pro jeho vznik posloužil především standard SDGM a doplňkově pak standard CEN. Standard je v současné době jediným standardem, který je doporučeno využívat. Standard je velmi obecný a nabízí opravdu mnoho způsobů jak metadata pro prostorová data zapisovat. Velmi zajímavá je možnost vzniku tzv. profilů, které mohou být připraveny na míru určitým specifickým podmínkám (např. profesní, národní). Standard nabízí pravidla jak takovéto profily vytvářet, tak aby byly kompatibilní se svým mateřským standardem,
O vývoj standardu pro oblast geoinformatiky se v ISO stará TC 211. Výsledkem je stejně jako v případě CEN množina standardů pro tuto oblast, které se vzájemně doplňují a odkazují na sebe.
ISO 19139 Geographic information Metadata XML schema implementation
Protože se standard ISO 19115 ukázal jako příliš složitý nebo obecný pro samotnou implementaci vznikl (resp. stále vzniká) standard ISO 19139, který nabízí pravidla implementace ISO 19115, ale především XML schémata, která jasně definují jak mají vypadat XML dokumenty, které jsou v souladu se standardem ISO 19115.
Tento standard je zásadním standardem a je jen smutné, že jeho vydání se stále odkládá. V současné době již mnoho systémů staví na draft verzích tohoto standardu a mnoho uživatelů se v budoucnosti může ocitnout v nepříjemné situaci, kdy se draft bude od finální verze významně lišit.
EN 12657 Geographic Information – Metadata
Tento standard je výsledkem práce TC 287 organizace CEN, má dnes v Evropě již svou tradici a je hojně využíván. Patří do skupiny standardů, které sloužily pro potřeby geoinformatiky. TC 287 vytvořila standardy pro oblasti geoinformatiky, jako jsou terminologie, prostorové schéma, prostorové referenční systémy, kvalita prostorových dat, metadata pro prostorová data, přenos prostorových dat.
41
Významným prvkem těchto standardů byla dostupnost jejich předběžných (draft) verzí prostřednictvím Internetu. Finální verze standardů jsou k dispozici pouze prostřednictvím sekretariátu CEN a jeho distribuční sítě. Vývoj těchto standardů byl ukončen. Standardy, a především jejich předběžné verze se staly základem mnoha geoinformačních aplikací, včetně metainformačních systémů.
Standardy CEN rovněž posloužily jako doplňkový zdroj informací pro vznik standardů ISO pro tuto oblast. Výhodou využití poznatků CEN bylo, že standardy CEN byly hojně testovány v praktickém životě v oblasti evropských podmínek a často byly připomínkovány. V současné době se situace obrátila a CEN obnovil svou činnost. Jeho cílem je příprava ISO standardů pro potřeby evropských specifik. Postupně jsou tedy zpracovávány jednotlivé ISO standardy do podoby doporučení CEN pro jejich implementaci.
Standard for Digital Geospatial Metadata (SDGM)
Tento standard je nejstarším z popisovaných standardů. Vývoj přímo souvisí se vznikem americké National Spatial Data Infrastructure, která byla deklarována 11.4. 1994. Provozování zajistil FGDC. Tato aktivita dala podnět ke vzniku National Geospatial Data Clearinghouse, ve kterém se využívají dva standardy FGDC. Prvním z nich je zmiňovaný SDGM a druhým je Spatial Data Transfer Standard (SDTS), který slouží k přenosu prostorových dat.
Oba standardy jsou volně k dispozici k využití, kýmkoliv k jakémukoliv účelu a je možné je získat prostřednictvím Internetu. V obou případech je kromě samotného textu, který popisuje prvky standardu, k dispozici i předpis pro využití standardu pro XML.
Standardy SDGM a STDS jsou ve vzájemném těsném kontaktu především ve vazbě na kvalitu dat. Nicméně styčných ploch je daleko více. Cílem autorů je především před samotným přenosem dat tato data s využitím metadat ohodnotit z pohledu využití uživatelem.
Standard SDGM byl použit jako základ pro tvorbu ISO standardu pro metadata.
Standard ISVS pro strukturu a výměnný formát metadat informačních zdrojů
Tento standard ISVS (Informační systém veřejné správy) vznikl jako jedna z aktivit CAGI (Česká asociace pro Geoinformace). V době kdy se vyvíjel metainformační systém CAGI vznikl tlak na standardizaci popisu informačních zdrojů. Metainformační systém CAGI (dnes MIDAS) využíval upravenou verzi standardu CEN. Další organizace, které měly zájem prezentovat metadata v systému CAGI, eventuálně využívat systém pro správu svých metadat, vytvořili společně s CAGI meziresortní komisi pro metadata. Tato komise vytvořila základ pro vznik standardu ISVS. Standard vyšel ze standardu CEN, přičemž byl rovněž inspirován standardem ISO a předpisem Dublin Core. Především však standard zohlednil zkušenosti získané s vytvářením systému MIDAS jako např. číselníky.
Standard definuje strukturu a výměnný formát metadat pro popis datových souborů (dále jen DS) s prostorovou lokalizací nebo bez ní, událostí, služeb, aplikačního Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
42
programového vybavení a dokumentů. Výměnný formát je definován s využitím jazyka XML.
Standard byl garantován úřadem ÚVIS a o vytvoření se zasloužila zejména organizace CAGI. Standard byl určen pro orgány veřejné správy a je součástí standardů ISVS.
V současné době již standard pouze dožívá, není již závazným pro veřejnou správu a systémy postavené na tomto standardu se transformují tak aby umožnily používání standardu ISO.
Core Metadata
Všechny standardy specifikují, zda jimi specifikovaný element metadat je povinný či nepovinný nebo zda je jeho povinnost nebo nepovinnost něčím podmíněna. V této souvislosti existuje pojem Core Metadata, který představuje určité „jádro“ (základ) metadat. Tento základ metadat je tvořen prvky, které jsou pro metadatový záznam nejdůležitější a bez jejichž uvedení nemá metadatový záznam žádnou vypovídající schopnost. Toto povinné minimum je označováno jako Core Metadata. Core Metadata jsou tedy tvořena povinnými a podmíněně povinnými prvky. 3.5.3 Společné prvky standardů pro prostorová data
Všechny zmiňované standardy pro prostorová data přistupují k popisu datové sady. Přestože se výše zmiňované standardy často liší v některých detailech, všechny se snaží zachytit následující údaje popisující datovou sadu: •
identifikace (název, verze, ...), •
stručný popis (abstrakt, prostorové schéma, jazyk, důvod vytvoření), •
prvky kvality (popis vzniku, polohová přesnost, ...), •
související dokumenty, •
související datové sady, •
prostorový referenční systém, •
rozsah (prostorový, časový), •
popis obsahu (definice dat, klasifikace), •
administrativní metadata (organizace, osoby, údaje o distribuci), •
metadata o metadatech (autor, datum vzniku, ...). 3.5.4 Srovnání hlavních standardů v této oblasti
V případě tohoto srovnání byl hodnocen předběžný standard ”ENV 12657:1998 Geographic information – Data description – Metadata” vytvořený Evropskou komisí pro normalizaci (CEN), konkrétně technickou skupinou CEN/TC 287. Dále bude tento standard pro zjednodušení uváděn jen pod názvem komise jež jej vytvořila, a to CEN. Dalším srovnávaným standardem byl standard, respektive jeho pracovní verze ISO/CD 19115 z konce roku 1999 vytvořená technickou komisí ISO/TC 211. Standard bude pro zjednodušení Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
43
uváděn pod označením ISO. Třetím srovnávaným standardem byl Standard for Digital Geospatial Metadata, verze z roku 1998, který vytvořil Federal Geographic Data Comitee v USA. Standard bude pro zjednodušení uváděn pod označením FGDC. Posledním srovnávaným standardem byl standard „Standard ISVS pro strukturu a výměnný formát metadat informačních zdrojů“ v 1.1, který je garantován úřadem ÚVIS. Dále bude uváděn pod označením ISVS.
Protože jsou zde hodnoceny dva neúplné standardy (pracovní) a pouze jeden dokončený je třeba říci, že standard CEN se již nevyvíjí a tudíž může být pokládán za dokončený. Pracovní verze standardu ISO, která byla hodnocena, byla jedna z posledních před finální verzí standardu a standard nedoznal od té doby výraznějších změn.
V této části práce je uveden pouze souhrn srovnání. Pro podrobné informace je nutné nahlédnout do [Růžička 2001].
Povinné složky metadat
Tabulka 32: Povinné prvky srovnávaných standardů
Prvek metadat
CEN
ISO
FGDC
ISVS
Jazyk metadat
+
+

Znaková sada metadat

+

Název standardu

+
+

Verze standardu

+
+

Název datové sady
+
+
+
+
Abstrakt
+
+
+
+
Jazyk datové sady
+
+

+
Zaková sada datové sady
+
+

+
Prostorové schéma
+

+
Datum vzniku metadat
+
+
+
+
Datum aktualizace metadat
+

+
Datum kontroly metadat
+

Prostorový rozsah
+

+
+
Časový rozsah
+

+

Parametr kvality
+

+
Organizace
+
+
+

Kontaktní místo

+
+

Kategorie

+
+
+
Důvod vytvoření

+

Frekvence aktualizace

+

44
Prvek metadat
CEN
ISO
FGDC
Omezení přístupu a využívání metadat

+
ISVS
Dublin Core a popsané standardy
Tabulka 3 prezentuje jakým, způsobem jsou srovnávané standardy konformní s Dublin Core (DC). Tabulka 33: Srovnání Dublin Core a popisovaných standardů
DC
CEN
ISO
FGDC
ISVS
Title
+
+
+
+
Creator
C1
+
+
+
Subject
+
+
+
+
Description
+
+
+
+
Publisher
C1
+
+
C1
Contributor
C1
+
+
+
Date
+
+
+
+
Type
C2
+
C2
+
Format
+
+
+
+
Identifier
+
+
+
+
Source
+
+
+
+
Language
+
+

+
Relation
+
+
+
+
Coverage
+
+
+
+
Rights
+
+
+
+
C1 Osoba, Organizace (chybí číselník druhů vztahů nebo daný druh vztahu v číselníku není uveden)
C2 Neřešeno – předpokládá se pouze DS
Závěrečné zhodnocení standardů
Ze srovnání standardů vyplývá, že standardy FGDC, ISO a ISVS svou strukturou daleko konkrétněji rozebírají problematiku metadat. Zatímco CEN předkládá ve většině případů jen náměty jak některé části metadat zapisovat, FGDC, ISO i ISVS dávají přesné předpisy k jejich zápisu. Na druhé straně však standardy ISO a ISVS nevynucují mnohé užitečné údaje. Většinou se však jedná o obtížně specifikovatelné údaje ze strany tvůrce metadat. Tato skutečnost může vést k rychlejšímu rozvoji využívání metadat pro prostorová data, ale může také vést k nedostatečné dokumentaci zdrojů dat. V případě ISO a ISVS byla Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
45
zvolena cesta raději méně informací, tak aby byly akceptovatelné jakoukoliv organizací, ale v případě zájmu je možno evidovat více informací, standardy ISO a ISVS nabízí řadu volitelných možnosti.
Z výsledku srovnání vyplývá, že standardy CEN a FGDC jsou daleko striktnější než standardy ISO a ISVS. ISO a ISVS oproti CEN poskytuje daleko více přesnějších návodů jak metadata evidovat. Oproti standardu FGDC mají ISVS a ISO bezesporu několik nedostatků. Přesto se v některých oblastech uvažuje o přechodu na standard ISO. Minimálně vnikají mapovací postupy, transformační šablony či jiné nástroje pro konverzi z FGDC do ISO.
Metainformační systémy založené na standardu CEN nebo ISVS musí přejít na ISO standard v co nejbližší době (resp. již je téměř pozdě). Prvním krokem pro přechod by měla být schopnost předání metadat v souladu s ISO standardem. V tomto případě bude nutné se zaměřit především na povinnou klasifikaci a kontaktní místo.
3.6 Standardizace v oblasti komunikačních protokolů
Proto aby se mohla data efektivně zpracovávat v distribuovaném prostředí internetu je nutné aby byly standardizovány komunikační protokoly. V této oblasti je však ještě mnoho nevyjasněno a tato část práce by měla přehledně shrnout vývoj, současný stav a trendy.
V rámci kapitoly jsou představeny protokoly jako např. HTTP (HyperText Transfer Protocol), SOAP (Simple Object Access Protocol), CORBA (Common Object Request Broaker Architecture), RMI (Remote Method Invocation), WMS (Web Map Service), WFS nebo WCS (Web Coverage Service). 3.6.1 HTTP
HTTP (HyperText Transfer Protocol) je standardní protokol, který definuje komunikaci mezi WWW serverem a WWW klientem. Ve verzi 0.9 byl co nejjednodušší, tak aby zaručoval robustnost systému. Verze 1.0 přidává podporu vyrovnávací paměti a inspiruje se protokolem elektronické pošty a MIME (Multipurpose Internet Mail Extensions). Verze 1.1 je zatím poslední verze a zaměřuje se především na zrychlení komunikace na bázi tohoto protokolu. Navíc přidává podporu virtuálních serverů. Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
46
Obr. 37: Protokol HTTP
Komunikace probíhá dle následujícího schématu. Klient naváže spojení se serverem prostřednictvím nějakého transportního protokolu (obvykle TCP) a položí mu dotaz. Server na něj odpoví. Pak obvykle uzavře spojení. Takováto komunikace je často označována jako bezstavový protokol (komunikace) neboť server o klientech ví pouze v "krátkém" okamžiku dotazu a odpovědi. Častým způsobem komunikace je komunikace s využitím nepřímého spojení mezi serverem a klientem prostřednictvím nějakého prostředníka. K dispozici pro komunikaci bývají obvykle tři typy prostředníků. Proxy server je prostředník, který od klienta obdrží URL dekóduje jej a dotáže se serveru. Odpověď serveru předá klientovi. Často se využívá při přístupu odstíněných počítačů např. firewallem. Gateway server je prostředník, který slouží pro překlad HTTP do jiného protokolu. Např. email komunikace s HTTP serverem přes mailto (SMTP (Simple Mail Transfer Protocol)) protokol. Klient zašle požadavek na server přes email, gateway provede transformaci do http, obdrží odpověď v http, tu transformuje do „mailto podoby“ a odešle klientovi, klient obdrží email. Proxy Cache je prostředník proxy s vyrovnávací pamětí. Ukládá často používané stránky a klient pak nepřistupuje k těmto stránkám přímo u serverů, ale získává je z "paměti" proxy serveru.
3.6.2 HTTPS
Protokol HTTPS je rozšířením protokolu HTTP. Protokol umožňuje komunikaci v zašifrovaném módu. Data přenášená po síti jsou s využitím tohoto protokolu zabezpečena před zneužitím. Využívá se především při přenosu citlivých dat (např. přenos hesla pro přihlášení do nějakého systému). Tento protokol využívá vrstvy, která je implementací protokolu SSL (Secure Sockets Layer). V současné době se využívá především protokol SSL ve verzi 3. Oficiálním protokolem Internetu se však stal protokol TLS (RFC2246: Transport Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
47
Layer Security Protocol) vycházející z protokolu SSL verze 3. Tyto dva protokoly si jsou velice blízké, avšak klient využívající TLS se nedomluví se serverem využívajícím SSL a naopak. Šifrování a dešifrování pro HTTP server zajišťuje specializovaný modul, v některých případech může být jeden modul určen pro šifrování a druhý pro dešifrování, ale nebývá to obvyklé.
Obr. 38: HTTPS protokol
3.6.3 SOAP
Simple Object Access Protocol (SOAP) vznikl jako reakce na netransparentnost, uzavřenost, složitost nebo závislost stávajících řešení. Využívá možností jazyka XML. Umožňuje vzdálené volání metod (resp. výměnu strukturované informace) a nabízí univerzální popis volání. Volání může být jednosměrné nebo obousměrné (Request
Response) – např. RPC (Remote Procedure Call). Volání může skončit chybou (výjimkou). Pro zpracování výjimek existují standardní způsoby zpracování a nástroje pro deklaraci výjimek.
Požadavek je strukturován tak jak je uvedeno na obrázku.
48
Obr. 39: Struktura požadavku při použití protokolu SOAP (převzato z [Beneš 2005])
Odpověď je strukturována podobně jako požadavek. Př. 3 17 SOAP Request
<?xml version="1.0" encoding="ISO-8859-1"?>
<SOAP-ENV:Envelope SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAPENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:si="http://soapinterop.org/xsd" xmlns:namesp1="http://158.196.143.103/view">
<SOAP-ENV:Body>
<namesp1:getView xmlns:namesp1="http://158.196.143.103/view">
<c-gensym3 xsi:type="xsd:int">1</c-gensym3>
<c-gensym15 xsi:type="xsd:int">-2000</c-gensym15>
</namesp1:getView>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Př. 3 18 SOAP Response
49
<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<namesp1:getViewResponse xmlns:namesp1="http://158.196.143.103/view">
<s-gensym3
xsi:type="xsd:string">http://158.196.143.103/tmp/grass/200501231928197026/map.png<
/s-gensym3>
</namesp1:getViewResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Datové typy, které může volání i odpověď obsahovat jsou trojího druhu:
• Primitivní datové typy definované v XSD (XML Schema Definition)
• Vlastní složené datové typy – Objekty
• Výčtové datové typy – Kolekce a pole
SOAP Message může obsahovat objekty z různých XML schémat, to přináší nebezpeční existence stejných názvů pro různé objekty. Řešením jsou v tomto případě standardní mechanismy XML v podobě jmenných prostorů.
Př. 3 19: Jmenné prostory
xmlns:jencekgml="http://jencek.vsb.cz/gml/
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/
Jako transportní protokoly může využívat HTTP, HTTPS, SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol) a jiné. Jedná se tedy o jakousi logickou vrstvu nad těmito protokoly.
3.6.4 CORBA
Common Object Request Broaker Architecture je jazykově neutrální transparentní použití distribuovaných objektů. Je definován v dokumentech OMG (Object Management Group). K popisu rozhraní je využíván jazyk IDL (Interactive Data Language). Na základě IDL je možné provádět automatizované generování kódu např. pro jazyky C++, C a Smalltalk. CORBA se jeví jako příliš složitá s nedostatečnou podporou. O tomto by však bylo možné diskutovat. Jisté je, že CORBA nemá tak širokou podporu jako SOAP.
3.6.5 RMI
Remote Method Invocation (RMI) je obdoba technologie CORBA. Nevýhodou je závislost na jazyku Java. Z hlediska použití se jeví jako jednoduchá. Jisté je, že RMI podobně jako CORBA nemá tak širokou podporu jako SOAP. Oproti protokolu SOAP však nabízí nejen vzdálené volání a zasílání dat. Společně s daty může v systému migrovat i samotná logika služeb.
50
3.6.6 GeoWeb Services
Mnoho ze specifikací OGC velmi úzce souvisí s komunikačními protokoly, resp. mnoho z nich je přímo těmito protokoly. •
Distribuce dat – jako zástupce lze uvést zejména WMS (Web Map Service) [ISO 2004], WFS (Web Feature Service) [OGC 2005c], WCS (Web Coverage Service) [OGC 2006b], GML (Geography Markup Language) [OGC 2001], Web Terrain Server (WTS) [OGC 2001d].
•
Vyhledávání dat – jako zástupce lze uvést zejména CSW 2.0 [OGC 2007], WFS.
•
Podpora kartografie jako zástupce lze uvést zejména WMS, SLD (Styled Layer Descriptor) nebo adoptovaný dokument (SMS) Style Management Services for Emergency Mapping Symbology [OGC 2005f].
•
Služby založené na poloze – jako zástupce lze uvést zejména OpenGIS Location Services (OpenLS) [OGC 2006] and Gazetteer (GAZ) services [OGC 2001c].
•
Služby pro prostorové analýzy – jako zástupce lze uvést zejména Web Processing Service (WPS) [OGC 2005d].
•
Služby pro prostorové modelování jako zástupce lze uvést zejména WPS, Sensor Collection Service (SCS) [OGC 2002b] or Sensor Planning Service (SPS) [OGC 2005e].
•
Služby pro sítě senzorů jako zástupce lze uvést zejména Web Notification Service (WNS) [OGC 2003b], •
Služby pro transformaci – jako zástupce lze uvést zejména CT (Coordinate Transformation Service Implementation Specification) [OGC 2001e].
3.6.7 WMS
Web Map Service (WMS) je jednou ze specifikací OGC. Jedná se o poměrně starou a vyzrálou specifikaci (počátky v letech 19981999), která však dnes nedostačuje novým požadavkům kladeným na webové služby. Mapový server dle specifikace WMS publikuje dle požadavku uživatele obsah mapového pole v podobě obrázku (obvykle rastrového), který může vizualizovat uživatelův klient. Rastrový obrázek může být plně vyplněn pixely s nějakou barvou, ale v obrazu se mohou vyskytovat rovněž pixely průhledné (případně částečně průhledné). Díky této možnosti může uživatelův klient takto vizualizovat výstupy z více serverů najednou, naskládáním vrstev na sebe (analogie k digitální kartografii). Tato možnost činí z WMS serverů rodinu zdrojů dat, které je možné libovolně kombinovat.
Mnoho z tvůrců webových služeb očekávalo, že se změnou statutu WMS specifikace na ISO standard přestane být opomíjen vývoj v oblasti webových služeb a i pro WMS bude provedena patřičná inovace. Pokud se v současné době hovoří o webových službách pak výhradně ve spojitosti s protokolem SOAP. Samotná nenormativní definice webové služby dle W3C (W3C 2004) sice nevylučuje existenci webové služby i mimo tento protokol, ale prakticky se i v případě W3C mluví jen o protokolu SOAP. Standard ISO/DIS 19128 (WMS) na toto zapomíná a definuje předávání pokynů pro mapovou službu bez využití Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
51
protokolu SOAP. Dá se říci, že toto je zásadní chyba vznikajícího standardu a je až s podivem, že se ve standardu o protokolu SOAP neuvažuje. Tvůrci webových služeb budou i nadále proto oblast GIS považovat za izolovanou od okolního světa, protože pro mapovou službu nebudou definovány metody a jejich parametry pro SOAP volání. Je faktem, že v této oblasti již vznikly jisté aktivity, a specifikace SOAP pro WMS existují (např. [Gonçalves 2004], [OGC 2003] nebo [OGC 2004]) .
WMS může být doplněno požadavky dle specifikace SLD (Styled layer descriptor), kdy je možné ovlivňovat symbologii pro vykreslení geoprvků ve výstupním obrázku. Obr. 310: Web Map Service požadavek GetMap
Př. 3 20: WMS požadavek GetMap
http://www.airesip.org/wms/process.cgi?
REQUEST=GetMap&FORMAT=image/gif&WIDTH=640&HEIGHT=480&LAYERS=temperature&SR
S=EPSG:4326&BBOX=-110.,40.,-80.,30.&VERSION=1.1.1
3.6.8 WFS
Velmi zjednodušeně se dá říci, že specifikace Web Feature Service (WFS) definuje komunikační rozhraní mezi mapovým serverem, který publikuje výstup z báze prostorových dat v podobě vektorových dat, a klientem.
Specifikace definuje jak se klient musí mapového serveru „zeptat“ aby obdržel zpět vektorová a popisná data představující geometrickou a popisnou složku geoprvků. Specifikace dále definuje v jaké podobě jsou data zasílána zpět. K formátování zasílaných dat se využívá další ze specifikací OGC a to specifikace GML. GML definuje základní geometrická primitiva jako je bod, linie, polygon.
To jak se klient ptá je řešeno formou XML dokumentu, který musí být mapovému serveru na bázi WFS zaslán. Stejně tak je koncipována odpověď mapového serveru.
52
Obr. 311: Web Feature Service požadavekGetFeature
Př. 3 21: Web Feature Service požadavek DescribeFeatureType
<DescribeFeatureType version="1.0.0" service="WFS"
xmlns="http://www.opengis.net/wfs"
xmlns:ns01="http://www.server01.com/ns01"
xmlns:ns02="http://www.server02.com/ns02"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wfs ../wfs/1.0.0/WFSbasic.xsd">
<TypeName>ns01:TREESA_1M</TypeName>
<TypeName>ns02:ROADL_1M</TypeName>
</DescribeFeatureType>
3.6.9 WCS
Web Coverage Service (WCS) slouží zejména k získávání originálních (neupravených) rastrových dat ze serverů. Princip je podobný jako u WFS, s tím rozdílem, že na výstupu služby je rastrový soubor v požadovaném formátu.
Nejedná se tedy o mapovou kompozici (nebo obsah mapového pole), ale o data určená k dalšímu zpracování (analýze, vizualizaci, apod.).
53
Obr. 312: Web Coverage Service požadavek GetCoverage
3.6.10 WPS
Web Processing Service (WPS) je specifikace zatím velmi nezralá. Tato specifikace definuje rozhraní pro vzdálené volání různých operací. Spouštějí se např. různé výpočetní modely, a to ať složité (např. klimatický model) nebo relativně jednoduché (např. neřízená klasifikace družicového snímku). Jako vstupy do operací mohou být primitivní údaje (např. čísla, řetězce) nebo údaje komplexní (např. GML). Dále pak mohou do operací vstupovat výstupy ze služeb dle OGC specifikací (např. WFS, WMS, WCS, WPS). Tato možnost pak představuje určitý primitivní způsob řetězení služeb.
Výstupy z operací mohou být podobně jako vstupy primitivní údaje (např. čísla, řetězce) nebo údaje komplexní (např. GML). Dále pak může WPS výsledek publikovat s využitím jiné služby dle OGC specifikací (např. WFS, WMS, WCS). Obr. 313: Web Processing Service požadavek Execute
U WPS je možné využívat asynchronní volání. To znamená, že po zaslání požadavku nečeká klient na odpověď (některé operace mohou trvat i několik dní). Klient může průběžně zjišťovat jaký je stav zpracování, případně požádat o informování o ukončení zpracování Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
54
nějakým standardním způsobem. WPS specifikuje tři operace GetCapabilities, DescribeProcess a Execute.
Z analýzy WPS vyplývá, že se jedná o velmi primitivní řešení, které nemůže postačovat nárokům na řetězení, orchestraci a choreografii služeb, tak jak je popsána dále v textu. Dále popsané specifikace a navržené postupy jsou mnohem vhodnější, pokud má být orchestrace efektivní.
Za výhodu této specifikace můžeme považovat její jednoduchost, která může být její zbraní zvláště v oblasti geoinformatiky, neboť umožní rychlejší implementaci. V oblasti geoinformatiky se obvykle prosazují především jednoduchá řešení. Důkazem je masivní rozšíření specifikace WMS a téměř minimální rozšíření specifikace WFS mezi běžnými tvůrci GIS.
Jinou výhodou je zařazení metadat dle ISO 19115 přímo do popisu, který vrací metoda GetCapabilities. Velmi zajímavá je pak jasná vazba na OGC specifikace.
3.6.11 Komunikační protokoly pro hledání v metadatech pro geodata
Následující přehled není úplným, nicméně představuje reprezentativní skupinu komunikačních protokolů, které umožňují práci s metadaty v distribuovaném prostředí.
Z uvedeného přehledu se v současné době dá uvažovat pouze o dvou protokolech, a to o protokolu Z39.50 (GEO Profile) a protokolu CSW 2.0. Z analýz vyplývá, že EU se vydává směrem protokolu CSW 2.0, který však vykazuje stále ještě mnoho nedostatků. Je dosti pravděpodobné, že budou vznikat specifické protokoly pro distribuované vyhledávání, které budou snazší k implementaci a CSW 2.0 bude obvykle implementován jen v základním povinném rozsahu.
Simple Search
Tento protokol byl vyvinut společností CEOnet, která je jedním z tvůrců NCGI (National Clearinghouse for Geoinformation) [RAVI 2001]. Protokol je založen na výměně dat s využitím CGI (Common Gateway Interface) rozhraní přes HTTP protokol. CGI program vrací výsledky v podobě ASCII textu, který je naformátovaný dle ISO/CCDSdeveloped Parameter Value Language (PVL). Parameter Value Language byl vyvinut organizací CCSDS [CCSDS 2002]. Po jeho praktickém ověření byl navržen jako kandidát na ISO standard. Jedná se o obecnou specifikaci, která umožňuje specifikovat parametry a jejich hodnoty. Více informací lze nalézt v [CCSDS 2002b].
HGS
Tento protokol byl vyvinut v Joint Research Center (JRC) v Itálii. HTTPbased Geo
Temporal Searching (HGS) protokol je protokol, který je obdobně jako protokol Simple Search založen na PVL a URL. Tento protokol však počítá s existencí vyhledávacího portálu, který si udržuje přehled o databázích dostupných k prohledávání. Tento portál je Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
55
prostředníkem mezi uživatelem a databázemi. Výsledky vyhledání jsou předávány ve formě PVL.
HGSS
HTTPbased GeoTemporal Simple Searching (HGSS) protokol vznikl spojením a rozšířením protokolu Simple Search a HGS. Komunikace opět probíhá přes URL, CGI a HTTP, přičemž formátování výsledku vyhledání je rozděleno do dvou fází. V první fázi je vytvořen výstup opět s využitím jazyka PVL. V druhé fázi pak probíhá transformace do formátu XML.
Z39.50 Search and Retrieval Protocol
Tento protokol vychází z komunity tvůrců digitálních knihoven a v dnešní době se jedná o ISO standard. Poskytuje předpis pro specifikování struktury dotazu i struktury výsledku vyhledání (dotazu). Výhodou protokolu je jeho značné rozšíření
Z39.50/GEO Profile
FGDC vyvinulo aplikační specifikaci jak využít Z39.50 pro hledání v metadatech specifikovaných pomocí standardu SDGM. Tato specifikace byla nazvána GEO. Standard specifikuje strukturu pro dotazování v metadatech (včetně prostorových dotazů) a také strukturu výstupu. Na bázi této specifikace funguje americká NCGI. Protokol má stavový charakter s persistentním spojením mezi serverem a klientem
Information Management system (IMS)
Tento protokol vychází z půdy organizace NASA (National Areonautics & Space Administration). Protokol využívá možnosti jazyka Object Description Language (ODL) a to je jedna z jeho předností. Jazyk ODL je využíván k specifikaci parametru dotazu. K dispozici jsou jak klientská tak serverová aplikace zdarma stažitelné ze serveru NASA.
CSW 2.0
Protokol (specifikace) vychází z dílny Open GIS Consorcia. Podrobněji je popsán v další kapitole.
3.7 Webové služby
Velmi jednoduše lze říci, že webové služby nabízejí způsob propojení dříve neslučitelných aplikací. Díky webovým službám je možné snadno rozšiřovat funkcionalitu stávajících aplikací.
56
Webové služby jsou komponenty, které poskytují sadu metod, které jsou přístupné přes jasně definovaný protokol prostřednictvím počítačové sítě. Klient webové služby volá vybranou metodu služby, předává jí parametry volání a zpět od služby dostává odpověď. Parametry volání i odpověď mohou být buď jednoduché datové typy (např. řetězec, číslo) nebo i komplexní objekty (např. GML vrstva, mapa, obdélník). Klientem webové služby může být buď uživatelem ovládaná aplikace nebo jiná webová služba.
Architekturu webových služeb je možné členit do několika logických vrstev, z nichž některé jsou již představovány konkrétní specifikací (standardem, protokolem). Celou architekturou se prolíná jazyk XML [W3C 2005], který je používán pro definování většiny implementačních protokolů a specifikací.
Communication layer slouží k přenosu zpráv z klienta na službu a zpět. V této oblasti se již ustálil protokol SOAP (Simple Object Access Protocol) [W3C 2005c], který je obvykle využíván ve spojení s HTTP protokolem. Odtud také pochází zavádějící název webové služby, protože HTTP je využíván pro WWW. Description layer slouží k popisu webové služby. Popis webové služby sestává ze seznamu metod, parametrů a návratových hodnot, přípojných nodů (fyzických adres v počítačové síti) pro volání služby. Zde se obvykle využívá jazyk WSDL (Web Services Description Language) [W3C 2005g]. Registry layer má za úkol provádět katalogizaci služeb, tak aby bylo možné v reálném čase vyhledávat vhodné webové služby pro plnění specifických úkolů. Zde je k dispozici mnoho specifikací, z nichž nejzajímavější jsou UDDI [OASIS 2005b], WSIL (Web Services Inspection Language) [IBM 2005], CSW 2.0 [OGC 2007].
Security layer zajišťuje oblast autentizace, autorizace a šifrování. V této oblasti jmenujme např. WSSecurity [OASIS 2006], jako zatím nepříliš masivně využívanou specifikaci nebo SAML (Security Assertion Markup Language) [OASIS 2006b].
Reliable Messaging layer má zajistit ověřování spolehlivosti přenosu zprávy a věrohodnosti zda daná správa přišla ze správného zdroje a nezměněná.
Context, Coordination and Transaction layer zajišťuje především koordinaci činnosti webových služeb v případě dlouhých transakcí.
Business Process Languages layer slouží k řízení kontroly komunikace webových služeb v rámci aplikace. Jako nejznámější jazyk je uváděn BPEL.
Choreography layer umožňuje obecnější popis chování služeb při komunikaci mezi sebou. Zde se uplatňuje zejména jazyk WSCDL (Web Service Choreography Description Language) [W3C 2006].
Webové služby se dle výzkumu jeví jako potenciálně vhodné pro architekturu, zásadním problémem může být relativně obtížná implementace.
3.7.1 Klienti pro Webové služby
Klientem webové služby může být jakákoliv aplikace. V tomto se liší od běžného využívání WWW prostředí a využívání WWW prohlížečů.
Klienty mohou být obecně:
57
●
●
●
●
WWW aplikace běžící v prostředí WWW prohlížeče (např. HTML+Java Script, Java applet, Flash aplikace),
Desktopové aplikace (např. JUMP, Google Earth, uDIG, ArcMap),
Serverové aplikace (např. skripty napsané v jazyce PHP, SŘBD (Systém řízení báze dat), SMTP server),
Další služby
3.7.2 WSDL
Web Service Description Language (WSDL) umožňuje popsat webovou službu. Je založen na XML. Struktura popisu je jednoduchá:
● Jmenné prostory
● Datové typy
● Vstupní parametry
● Výstupní hodnoty
● Volání, Vázání (Binding)
U deklarace metod se deklarují vstupní parametry, výstupní hodnoty a název metody. Datové typy parametrů a návratových hodnot mohou být stejného typu jako u protokolu SOAP (koneckonců to je jasné z principu WSDL).
Př. 3 3 WSDL
<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:namesp1="http://158.196.143.103/view"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://158.196.143.103/view" name="3DView"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<message name="getViewRequest">
<part name="c-gensym3" type="xsd:int" />
</message>
<message name="getViewResponse">
<part name="s-gensym3" type="xsd:string" />
</message>
<portType name="3DViewPort">
<operation name="getView">
<input message="namesp1:getViewRequest" />
<output message="namesp1:getViewResponse" />
58
</operation>
</portType>
<binding name="3DViewBinding" type="namesp1:3DViewPort">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc" />
<operation name="getView">
<soap:operation soapAction="http://158.196.143.103/view#getView" />
<input>
<soap:body use="encoded" namespace="http://158.196.143.103/view"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
</input>
<output>
<soap:body use="encoded" namespace="http://158.196.143.103/view"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
</output>
</operation>
</binding>
<service name="3DViewService">
<port name="3DViewPort" binding="namesp1:3DViewBinding">
<soap:address location="http://158.196.143.103/cgi-bin/3dview.cgi" />
</port>
</service>
</definitions>
3.7.3 ISO 19119 Geographic information – Services
ISO 19119 je důležitým standardem v oblasti geoinformatiky neboť specifikuje jakým způsobem se mají vytvářet webové služby pro oblast geoinformatiky. ΙSO 19119 bylo navrženo na základě zkušeností OGC.
Důvodem vytvoření specifikace bylo zejména:
● dát k dispozici obecný rámec pro koordinovaný vývoj služeb,
● podpořit vývoj katalogů služeb s využitím definic metadat pro služby
● umožnit interoperabilitu služeb
● umožnit využití služeb jednoho poskytovatele jiným poskytovatelem.
3.8 Způsoby volání služeb
3.8.1 Synchronní
Synchronní způsob volání služby je znám z dob technologie RPC (Remote Procedure Call). Jedná se běžný způsob volání, který známe také z protokolu HTTP. Klient zašle požadavek na službu a ta v reálném čase odpoví návratovou hodnotou. Jde o způsob komunikace RequestResponse. Daný způsob je možný využívat velmi často, v některých případech je však toto využití nemožné. Příkladem mohou být déle trvající procesy, jako jsou třeba výpočty v oblasti hydrologického modelování. Jiný případem, kdy je využití synchronního volání nevhodné, je situace, kdy zaslaný požadavek prochází řadou služeb, které jej musí různým způsobem zpracovat. jednoduchým příkladem může být požadavek, který než doputuje k vlastnímu zpracování musí být ověřen, zda má klient právo (je autorizován), k jeho předložení a na základě obsahu požadavku je z katalogu vybrána vhodná služba k jeho vyřízení. I takto koncipované zpracování může běžně trvat déle než je možné Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
59
považovat za zpracování v reálném čase. V těchto případech je vhodné (obvykle nutné) využívat asynchronní volání služeb.
3.8.2 Asynchronní
Asynchronní volání služeb je založeno na modelu, kdy na zaslaný požadavek klienta služba v reálném čase neodpovídá, resp. může odpovědět, ale v odpovědi je pouze informace jak bude s požadavkem dále nakládáno. Způsobů jak se klient dostane k výsledkům zpracování jeho požadavku je několik. Následující přehled popisuje dvě základní varianty.
•
Klient se průběžně dotazuje služby v jakém stavu zpracování je jeho požadavek. V případě že obdrží zprávu, že je již jeho požadavek zpracován, může službu požádat o zaslání výsledku zpracování.
•
Klient současně s požadavkem zašle identifikaci služby, kam má být výsledek zpracování zaslán. Klient tak vystupuje ve dvou rolích, jakožto klient když zasílá požadavek a jakožto služba, když později přijímá odpověď na své volání.
V případě asynchronního zpracování se s výhodou využívá služeb fronty zpráv (Message Queue). Jedná se o službu, která přijímá zprávy, na základě metadat ve zprávě nebo i jiných údajů (např. stav sítě) rozhoduje o tom které službě zprávu zaslat.
60
4 Architektura platformy otevřený GeoWeb
Popis architektury platformy otevřený GeoWeb shrnuje poznatky získané z předchozích částí a definuje základní stavební prvky celé architektury, jako jsou klienti, servery, služby, protokoly, apod. Navržené komponenty celé architektury vychází z důkladného několikaletého výzkumu specifikací a standardů a z poznatků ze školení SOA (GOPAS SK, Červen, Bratislava). Další informace jsou dostupné v externích zdrojích1 4.1 Architektura
Na obr. 41 jsou jednotlivé komponenty pro otevřený GeoWeb prezentovány tak jak jsou chápány v běžném pojetí klientserver technologií třívrstvé architektury. Na platformu GeoWeb je však nutno nahlížet tak, že každá z komponent se může chovat jako služba (snad až na některé klienty) a tyto mohou navíc být distribuovány libovolně v prostředí počítačové sítě.
Skupina komponent označená na obr. 41 jako klienti představuje zejména programy s grafickým uživatelským rozhraním, které pro své účely využívají uživatelé. Prostřednictvím těchto klientů volají služby a využívají jejich funkcionalitu.
Na následujícím obrázku je demonstrována spolupráce jednotlivých komponent architektury.
1
[Aditya 2003], [Apache 2006], [Apache 2005], [askGIraffe 2002], [Beneš 2005], [BKG 2001], [BEA 2006], [CAGI 2006], [CCSDS
2002], [CCSDS 2002b], [CGDI 2001], [CGDI 2001b], [Chassels 2000], [CNIG 2001], [Coene], [Colapicchioni 2005], [Duchoslav
2002], [Duchoslav 2004], [Eclipse 2005], [EPSG 2006], [ESRI 2005b], [FAO-UN 2005], [FAO-UN 2006], [FGDC 2001], [FGDC
2002], [FGDC 2002], [Ferderer 2001], [Fraser 2001], [Fraser 2001b], [Gonçalves 2003], [Grünreich 2001], [Havey 2006], [Horáková
2005], [IBM 2006], [IBM 2005], [IGN 2006], [ILRT 2002], [INSPIRE 2005], [INSPIRE 2004], [ISO 1999], [ISO 2004], [ISO 2002],
[JBoss 2006], [JUMP 2005b], [JUMP 2005c], [JUMP 2005d], [Kralidis 2000], [Král 2004], [Kvist 1997], [Li 2000], [LTSA 2006],
[MEGRIN 2001], [Microsoft 2006], [Mitchel 2003], [Mono 2005], [Moroney 2004], [Mort Bay 2006], [Mule 2005], [Mule 2005b],
[Mule 2005c], [NMDGA 2002], [Nemoforum 2005], [Neomatix 2005], [NGDF 1999], [NGDF 1999c], [NGDF 1999d], [OASIS
2006b], [OGC 2007], [OGC 2001c], [OGC 2001], [OGC 2004], [OGC 2001e], [OGC 2006], [OGC 1999], [OGC 2001b], [OGC
2005c], [OGC 2002], [OGC 1999e], [Orlík 2006], [Panatkool 2002], [Pastorello 2005], [Pi4tech 2006], [QGIS 2005], [Ram 2000],
[Refraction 2005], [Refraction 2006], [Refraction 2006b], [RUMN 2002], [Růžička 2005], [Růžička 2004], [Růžička 2005b],
[Růžička 2005e], [Růžička 2002], [Růžička 2005f], [Růžička 2005g], [Růžička 2005h], [Růžička 2004b], [Růžička 2006], [Růžička
2000b], [Růžička 2005l], [Růžička 2005k], [Růžička 2006b], [Smith 2001b], [Smith 2004], [Šeliga 2004], [Šeliga 2005], [Tait 2005],
[TeIDE 2005], [TeIDE 2005b], [W3C 2006], [W3C 1999], [W3C 2005c], [W3C 2005f], [W3C 2005g], [W3C 2006b], [WDI 2006],
[WFP-UN 2005], [WS-CDL Eclipse 2006], [WSCO 2006].
61
Obr. 41: Komponenty architektury otevřený GeoWeb
62
Obr. 42: Spolupráce komponent architektury
1. Klienti celé architektury využívají orchestrů nebo jednoduchých řetězců a zpracovávají výsledky jejich spuštění. 2. Typy služeb vyhledávají klienti v katalozích. 3. Aktuální instance služeb vyhledávají orchestry v katalozích. 4. V závislosti na potřebách sítě může docházet k optimalizaci s využitím migrace služeb nebo dat. 5. Použití orchestru může být zpoplatněno. 6. Komunikace na všech úrovních může být zabezpečena s využitím šifrování zpráv.
7. Pro účely řetězení služeb mohou být využívány překladače mezi různě kódovanými zprávami.
8. Jedna geoinformační infrastruktura (např. firemní nebo národní) může být provázána s jinou geoinformační infrastrukturou s využitím platformě a procesně nezávislé choreografie. V případě potřeby je možné zajišťovat i migraci služeb mezi servery kooperujících infrastruktur. Migrace orchestrů je možná, ale spíše výjimečná z důvodů vazby na procesy v rámci infrastruktury.
63
Obr. 43: Zapojení katalogů a abstraktní komponeta metaportál
Je nutné si uvědomit, že celá architektura je založena na mnoha různých katalozích, které nabízejí metadata o všech potřebných prvcích dostupných na platformě. Dále jsou součástí platformy samotné služby a jejich uživatelé. Mozkem celé architektury je na předchozím obrázku uveden Metaportál, který zde představuje určitou formu abstraktní služby, která se stará o logiku využívání služeb. Je jasné, že taková služba je tvořena zase kombinací mnoha služeb. Logika Metaportálu je založena na orchestraci a choreografii služeb, tak jak je popsáno dále.
64
4.2 Datové služby
Základem architektury otevřený GeoWeb je distribuovaná správa dat. Každý pořizovatel dat (resp. jejich správce) poskytuje prostřednictvím veřejné (případně virtuální privátní) sítě data. Každý správce má data na svém serveru (serverech) a uživatel přistupuje k těmto datům pomocí sítě. Z důvodu efektivních datových toků bývá datová báze poskytovatele distribuována (nebo replikována) v síti.
Pro distribuci dat k uživatelům existují dnes již standardizované protokoly WMS, WFS a WCS, které jsou popsány v předchozích kapitolách. Tyto protokoly však potřebují úpravu (resp. následné specifikace) pro podporu nových protokolů (jako je SOAP), případně nově vznikajících protokolů. S největší pravděpodobností však k úpravě protokolů nedojde, ale budou využívány překladače v takovém smyslu jak je uvedeno dále.
Jinými protokoly jsou nativní protokoly pro přístup k datům spravovaným v relačních databázích. Zde se zřejmě ustálí protokoly pro PostGIS, ArcSDE a Oracle Spatial.
Samozřejmostí správy dat dnes musí být schopnost datového skladu spravovat časoprostorová data. Toto potvrzuje např. [Orlík 2005].
Specifickými datovými „službami“ pak budou datové zdroje, které jsou dostupné jednoduchým způsobem (podobně jako WMS) pouze zadáním URL adresy. takto budou distribuovány např. různé události (specifikace GeoRSS (Geographically Encoded Objects for RSS feeds) [GeoRSS 2007]) nebo i jiná data (např. KML soubory, ESRI Shapefile soubory). 4.3 Katalogy, metadatové služby
Nezanedbatelnou součástí každého dobře navrženého informačního systému (i geografického informačního systému) je správa metadat o datech vedených v tomto systému. Častým způsobem vedení metadat o datech spravovaných v informačním systému bývá dokumentace v samostatných dokumentech, které často nebývají žádným způsobem organizovány. Pokud jsou metadata vedena nějakým uceleným způsobem, jsou obvykle spravována jako specifická část informačního systému. Obvykle je pro jejich správu vyčleněna samostatná jednotka (označovaná také jako modul) specializovaná na vedení metadat. Méně častým případem jsou tzv. metainformační systémy (nebo zjednodušeně katalogy), ale pro platformu GeoWeb rozhodující. Metainformační systémy mohou stát mimo celý systém správy dat a mohou na něm být téměř nezávislé. Takto se však chovají obvykle portály, popsané dále. Naopak běžné metainformační systémy by měly být integrovány do informačního systému organizace, která geodata vytváří.
Pro práci mnoha organizací je samozřejmě nutné mít přehled nejen o vlastních datech popsaných v interním metainformačním systému, ale i o datech jiných organizací. Většina metainformačních systémů nemá veřejný charakter a organizace nemají možnost jednoduchým způsobem vyhledávat v metainformačních systémech jiných organizací. V praxi může existovat metainformační systém, který slouží pro potřeby více informačních systémů např. i pro více organizací. Takový systém, mimo jiné, pak nabízí nástroje ke sdílení metadat mezi více subjekty.
65
Některé organizace mohou využívat jak svůj vnitřní metainformační systém (modul) pro evidenci podrobných metadat a zároveň i externí (veřejný) metainformační systém pro prezentaci svých dat (např. formou méně podrobných metadat) ostatním organizacím. Pro některé organizace může být evidování metadat ve vlastním metainformačním systému nevýhodné a mohou veřejný metainformační systém využívat k evidenci vlastních metadat.
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).
Veřejné metainformační systémy mohou spravovat metadata dvojího druhu. První skupinou metadat jsou veřejná metadata, která mohou být jako celek zpřístupněna veřejnosti. Druhou skupinou jsou metadata, která mají část údajů neveřejného charakteru. Tato část metadat je veřejnosti odstíněna a přístup k ní má pouze vlastník metadatového záznamu. Metadata prezentovaná veřejnosti však musí mít vždy veřejný charakter a veřejné metainformační systémy musí tuto prezentaci zajišťovat.
Veřejné metainformační systémy mohou být založeny na dvou různých principech správy metadat. Na prvním principu jsou založeny samostatné veřejné metainformační systémy a na druhém tzv. veřejné metainformační portály.
4.3.1 Samostatné veřejné metainformační systémy
Základem samostatného veřejného metainformačního systému je databáze, ve které jsou spravována všechna metadata. Metadata prezentovaná veřejnosti jsou načítána právě z této databáze.
Obr. 44: Možná architektura samostatného veřejného metainformačního systému
4.3.2 Veřejné metainformační portály
Oproti předchozímu případu není základem systému databáze, která obsahuje všechna metadata, která jsou prezentována uživateli. Metadata prezentovaná uživatelům jsou Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
66
spravována v několika různých metainformačních systémech. Databáze metainformačního portálu 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á. Základním rozdílem oproti předchozímu případu je to, že metadata jsou spravována mimo metainformační portál. Obr. 45: Možná architektura metainformačního portálu
Je zřejmé, že mohou existovat hybridní formy, které kombinují možnosti metainformačního portálu a klasického metainformačního systému.
Tato architektura by navíc měla být otevřená pro vstup různých nodů infrastruktury metainformačních portálů. Zásadním problémem by mohlo být zapojování nodů do celého systému vyhledávání. Toto však lze vyřešit podobně jako v případně protokolu Ntrip (Networked Transport of RTCM via Internet Protocol) [Hanslian 2005] nebo služby WWW (zjednodušeně mechanismu Hypertext). Původně jsme vždy vycházeli z představy, že metaportál musí mít přehled o tom, ve kterých nodech má vyhledávat. Tato představa však byla chybná. Pro metaportál je nutné znát jen několik blízkých katalogů pro vyhledávání. Tyto katalogy pak znají několik dalších blízkých katalogů, ale umožňují svým prostřednictvím v nich vyhledávat a dále také distribuovat samotný požadavek vyhledávání.
Metaportál na základě požadavku uživatele hledá v metadatech evidovaných v nejbližších katalozích a požádá o další hledání ve spřízněných katalozích své nejbližší katalogy.
Uživatel si bude moci volit úroveň rekurze vyhledávání, případně volit vyhledání jen ve spřízněných (nejbližších) katalozích. Dále si bude uživatel moci volit způsob vyhledání na základě toho v jaké minimální době vyžaduje odpověď. Klient metaportálu, může být nastaven tak, že po určité době (třeba Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
67
24 hodin) vrátí všechny dosud nalezené výsledky. Samotné vyhledání se automaticky ukončí tím, že daný požadavek bude mít časově omezenou platnost. Pokud takový požadavek dorazí ke katalogu po vypršení jeho platnosti pak katalog požadavek automaticky zahodí a dále jej nedistribuuje. Zřejmě bude nutné stanovit nějakou maximální časovou platnost, protože v opačném případě by po síti mohlo být transportováno mnoho požadavků, které by však již nenašly uplatnění u čtenáře (uživatele).
Jiný způsob ukončení vyhledání by byl v případě, že se již podařilo projít celou síť katalogů (což by ale nemuselo být někdy reálné). Samotný požadavek bude postupně narůstat o identifikátory již navštívených katalogů a do již navštívených katalogů se distribuovat nebude. Toto by mohlo vést k tak velkému nárůstu velikosti požadavku, že by to nebylo v souladu s pravidly definovanými W3C. Z tohoto důvodu by v případě nárůstu požadavku nad stanovenou mez (objemovou) seznam navštívených katalogů zaznamenal s využitím služby k tomu určené. Požadavek by pak v sobě již nesl jen informaci o umístění služby, která ví o tom, které katalogy navštívil a vždy při rozhodování kam dále odeslat požadavek by katalog zavolal službu se seznamem jemu známých katalogů a dostal by odpověď kam má požadavek dále rozeslat. Služba by si dále zaznamenala katalogy zaslané katalogem pro tento konkrétní požadavek.
Odpovědi katalogů nemusí být transportovány stejnou cestou jakou přišel požadavek, ale může být transportován přímo ke klientovi, kterým je metaportál. Metaportál pak předá výsledek uživateli. Vzhledem k tomu, že požadavek je jasně identifikovaný pomocí kódu, může se vracet přímo zpět k zadavateli.
Obr. 46: Řetěnení katalogů
68
4.3.3 Správa metadat v katalogu
Zajímavou otázkou je správa samotných metadat v katalogu. Ta může být řešena mnoha způsoby. Můžeme samozřejmě využít běžný SŘBD relačního typu a metadata rozkládat do tabulek. Výzkum v projektu MIDAS a zejména WebCastle ukázal, že tato cesta je nevhodná. Takovýto způsob ukládání způsobuje problémy v oblastech změny standardu, rozšíření standardu (např. národní profily), implementace více standardů. Oproti tomu řešení na bázi XML takové problémy nepřináší.
Jiná cesta, která byla zkoumána Josefem Miklošem [Mikloš 2003] je využití XML nativních databází. Toto však naráží na stálou nedůvěru u většiny manažerů vývojových týmů. Autor tuto cestu považuje za jednu z nejlepších a stále doporučuje její využití pro projekty, kde se je vedení ochotné riskovat zavedení neověřených technologií. Pro většinu řešení však autor doporučuje kombinace uložení XML dokumentů v běžné SŘBD relačního typu. Metadata se však nerozkládají do relací, ale zůstávají v původní XML podobě. Zpracování pak probíhá běžnými XML a XSLT procesory. K takto ukládaným datům se pak vznikají indexy pro rychlé vyhledávání.
4.3.4 Metadata vznikající automatizovaně
Je samozřejmé, že metadata nesmí vznikat pracnou ruční tvorbou uživateli, ale z větší části automatizovaným způsobem. V celém systému architektury platformy otevřený GeoWeb musí metadata automaticky putovat do katalogu přímo od zdroje dat a to při jakékoliv změně dat nebo při vzniku derivovaných dat. Následující přehled údajů by měl vznikat automatizovaně.
● Identifikace: místo publikování (URL, URI), jedinečný kód generovaný některou funkcí pro generování jednoznačného identifikátoru.
● Název datové sady: je odvoditelný z názvu souboru, názvu adresáře, názvu tabulky, nebo názvu databáze. Tady bude zřejmě často nutný zásah uživatele, ale nemusí tomu tak být vždy. ● Prostorové schéma: základní schéma je bez problémů neboť vyplývá ze způsobu vzniku dat. Některá specifika, jako např. topologická pravidla mohou být však již obtížněji zjistitelná. Především však není možné ověřit všechna topologická pravidla, která pořizovatel dodržel, pokud nebudou jasně definována v systému, ale o jejich dodržování se bude starat přímo fyzická osoba.
● Ukázka dat: zde bude možná statická i dynamická ukázka dat. Není žádným problémem automaticky přichystat náhled na data.
● Prostorové referenční systémy: dnes je již prakticky pravidlem, že nově vnikající geodata mají určena prostorový referenční systém.
● Rozsah dat: zde je jasné určení prostorového rozsahu dat. V případě časového rozsahu by bylo jistě možné jej snadno určovat a u některých typů dat jej půjde určit i automaticky. V současné době toto však mnoho systémů nenabízí.
● Kvalita dat: asi nejrozsáhlejší skupina metadatových prvků, kde bude nutné (bude to vyžadováno) aby byla plně automaticky generována. Zde se objevuje zásadní problém Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
69
ve využívání uzavřených technologií. Součástí údajů o kvalitě by měly být i informace o algoritmu, který byl využit pro úpravu dat (např. generalizace linií). V případě uzavřených technologií je takový algoritmus často předmětem utajení. Autor se domnívá, že tady bude sílit tlak na otevírání technologií a programového kódu. Jak se může nějaký manažer kvalifikovaně rozhodnout, když není jasné jak vznikla data, na kterých své rozhodnutí zakládá. Může samozřejmě důvěřovat garanci ze strany poskytovatele, ale je možné, že taková garance bude nedostatečná.
● Datová struktura: zde je jediným problémem určitá nejednoznačnost v sémantice popisu datových typů. Zřejmě bude problematické jasně definovat popis datových typů tak aby byl jednoznačný. Jako řešení se nabízí využití definice typů ze základního schématu XSD, kde je definice jednoznačná.
● Klasifikace dat: nově vznikající datové sady by již měly vznikat v určitém sémantickém kontextu. Zde však bude vždy nutný částečný zásah uživatele, který tento kontext jasně určí. O ostatní se postarají ontologie a řízené slovníky (tezaury).
● Administrativní metadata: zde je generování jasné. Například je možné využít existujících údajů z lokálního systému, nebo obvykleji z centrální databáze uživatelů (LDAP, ActiveDirectory). Otázka je jak moc bude realita blízká potřebám a požadavků.
● Metadata o metadatech: v tomto případě je automatické vytvoření přímo podmínkou.
● Příbuzné objekty: vazby na příbuzné objekty je možné generovat částečně. Určitě nebude problém generovat vztahy mezi datovými sadami. V případě jiných objektů to již může být složitější a vyžaduje další integraci systémů a důslednější budování sémantických kontextů (pravděpodobně založených na ontologiích). Pokud pak bude datová sada vznikat v určitém kontextu bude možné s využitím RDF nebo OWL najít vazby i na další objekty, jako jsou například vyhlášky, zákony nebo události. Je jasné, že není možné aby pro všechna geodata vznikala taková sada metadat automatizovaně, je však pravděpodobné, že pro více než 80 % geodat bude možné takovou sadu metadatových elementů generovat přímo v průběhu tvorby geodat.
4.3.5 Očekávaný rozsah metadat
V budoucnu se dá očekávat, že služby v České republice (ČR) budou obsahovat reference na metadata dle několika základní množin. Množina položek metadat dle INSPIRE, množina metadat dle core ISO 19115, množina metadat dle základu Dublin Core, množina položek tak jak byly vyplněny v systému MIDAS. Jiné alternativy jsou málo pravděpodobné. Rozsah metadata je pro platformu GeoWeb velmi důležitý neboť přímo ovlivňuje možnosti následné orchestrace služeb této platformy.
Metadata dle INSPIRE
Přehled položek dle INSPIRE vychází z pracovní verze implementačních pravidel [INSPIRE 2007]. Úroveň 1
70
První úroveň metadat je základní úrovní, která bude vyžadována vždy (pokud podmíněné pravidlo nestanoví jinak).
● Název (Resource title).
● Časový rozsah (Temporal reference) pouze v případě, že je informace smysluplná.
● Prostorový rozsah (Geographic extent of the resource).
● Jazyk (Resource language) pouze v případě, že geodata obsahují text.
● Kategorie (Resource topic category).
● Klíčová slova (Keyword).
● Typ služby (Service type) v případě služby.
● Kontaktní místo (Resource responsible party).
● Abstrakt (Abstract).
● Reference na další popis (Resource locator) pouze v případě, že taková reference existuje.
Úroveň 2
Druhá úroveň metadat je rozšířenou úrovní a nepředpokládá se implementace pro všechny datové sady a katalogy.
● Omezení užití (Constraints).
● Původ, historie vzniku (Lineage).
● Soulad s pravidly (Conformity).
● Verze služby (Service type version) – pouze pro služby.
● Název metody (Operation name) – pouze pro služby.
● Výpočetní platforma (Distributed computing platform) – např. Webové služby.
● Identifikátor zdroje (Resource Identifier) – např. URI.
● Prostorové rozlišení (Spatial resolution).
INSPIRE dále specifikuje další prvky metadat, které by mohly být dostupné, jejich naplnění je však sporné. Podobně je tomu u úrovně druhé, kde je naplnění na libovůli správce geodat (služeb). V zásadě tedy můžeme počítat s minimální množinou metadat v podobě názvu, prostorového rozsahu (zjistitelný rovněž z popisu vrstev služby), jazyku, kategorií, klíčových slov, abstraktu, kontaktního místa a v některých případech časového rozsahu. Taková množina je sice pro podrobnou orchestraci nedostačující (např. chybí údaje o kvalitě dat nebo o prostorovém rozlišení), přesto není až tak zanedbatelná aby pro základní výběr služeb nemohla postačit. Zásadní problém může být v oblasti klíčových slov, která mají jasněji definovat obsah dat, zde však nemusí být jasná sémantika daných slov, protože mohou pocházet z různých slovníků.
Metadata dle ISO 19115 core
Ve specifikaci ISO 19115 je definována základní sada položek, které jsou definovány jako povinné, podmíněně povinné i volitelné. Tato sada je výrazně rozsáhlejší než návrh INSPIRE, a pokud by byl použit v plném rozsahu, byla by geodata popsána lépe a jejich analýza pro případnou orchestraci snazší a přesnější. Přesto pro podrobnější orchestraci chybí údaje o kvalitě, omezeních užití (může být k dispozici v popisu služby).
71
Tabulka 41: Struktura ISO 19115 core (převzato z [ISO 1999] a doplněno překladem)
Položka
Popis
Dataset title (M)
Název Dataset reference date (M)
Datum vzniku
Dataset responsible party (O)
Kontaktní místo
Geographic location of the dataset Plošný rozsah (by four coordinates or by geographic identifier) (C)
Dataset language (M)
Jazyk
Dataset character set (C)
Znaková sada
Dataset topic category (M)
Kategorie
Abstract describing the dataset (M)
Popis
Distribution format (O)
Formát pro distribuci
Additional extent information for the Vertikální a časový rozsah
dataset (vertical and temporal) (O) Spatial resolution of the dataset (O) Prostorové rozlišení
Spatial representation type (O)
Prostorové schéma (bod, linie, TIN (Triangular irregular network ), GRID, ...)
Reference system (O)
Prostorový referenční systém
Lineage (O)
Původ
Online resource (O)
Online zdroj
Metadata file identifier (O)
Identifikátor metadat
Metadata standard name (O)
Název standardu metadat
Metadata standard version (O)
Verze standardu metadat
Metadata language (C)
Jazyk metadat
Metadata character set (C)
Znaková sada metadat
Metadata point of contact (M)
Kontaktní místo pro metadata
Metadata date stamp (M)
Datum vzniku (aktualizace) metadat
M – Povinná položka (mandatory), C – Podmíněně povinná položka (conditional), O – Volitelná položka (optional)
Metadata dle Dublin Core
Dublin Core je sice rozšiřitelným standardem, takže je možno s jeho pomocí definovat téměř jakékoli metadatové prvky, přesto se nedá očekávat, že by se využívalo více než základních prvků, tak jak jsou specifikovány v kapitole 3.
72
Metadata odpovídající stavu naplnění systému MIDAS
Z analýzy databáze systému MIDAS vyplývá následující pravděpodobné naplnění metadatových položek. Je možné, že nově vznikající data budou mít metadatové položky vyplněny lépe než geodata, která byla popsána někdy i dlouhou dobu po jejich vytvoření, ale spoléhat se na to není příliš vhodné.
Následující tabulka třídí elementy metadat dle vyplnění v systému MIDAS.
Tabulka 42: Vyplnění elementů metadat v systému MIDAS pro datové sady geodat
Procento vyplnění
Položky
80 – 100 %
Název, Popis, Referenční systém metadat, Aktualizace metadat, Prostorové schéma, Původ, Polohová přesnost horizontální, Četnost aktualizace, Obsah dat, Formát, Jazyk, Klasifikace, Přímý prostorový referenční systém, Kontaktní místo
60 – 80 %
Alternativní název, Platnost od, Plošný rozsah souřadnicemi, Podkladová data
40 – 60 %
Použití dat
20 – 40 %
Poznámka, Plošný rozsah slovně
5 – 20 %
Zkrácený název, Verze, Důvod vytvoření, Časový rozsah textově, Jazyk metadat, Pokrytí, Měřítko, Platnost do
< 5 %
Název anglicky, Popis anglicky, Datum aktualizace, Cena, Plánovaná aktualizace metadat, Polohová přesnost vertikální, Logická konzistence, Úplnost, Homogenita, Rozlišení, Jakost, Vertikální extent, Distribuční jednotky, Nosič, Nepřímý prostorový referenční systém, Výškový referenční systém, Objekty v datové sadě
Z tabulky vyplývá především to, že povinné a podmíněné povinné položky byly vyplňovány v téměř všech případech, což však bylo dáno kontrolou systému. Z nepovinných položek byly významně vyplňovány ty, které nabízel systém v podobě jednoduchého seznamu. Zajímavé je podstatné vyplnění alternativního názvu, začátku platnosti dat a podkladových dat. neméně významné ja také použití dat. Úplně mimo zájem pořizovatelů zůstaly údaje o kvalitě dat (vyjma původu).
Žádná metadata
V nejhorším případě se můžeme setkat s tím, že v době orchestrace nebudou k daným službám žádná metadata. Takové služby nelze využít, a bude nutné k nim metadata doplnit. V první řadě se pokusíme kontaktovat správce služby, pokud však nebude mít zájem doplnit metadata, budeme se muset pokusit, pokud služba bude velmi užitečná, alespoň základní metadata doplnit sami. Popis bude získáván kvalifikovaným odhadem (např. klíčová slova, kategorie, jazyk) nebo získán z různých dokumentů. Naštěstí zásadní metadata popisující prostorový rozsah dat musí být obsažena už v popisu služby. Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
73
Hodnocení
Vyhlídky pro orchestraci a tedy jeden ze základních mechanismů platformy GeoWeb jsou celkem neradostné, protože ani v jenom z potenciálně množných scénářů nebude množina metadat dostatečná pro efektivní orchestraci. Z těchto důvodů jsou v současné době hledány další alternativní cesty jak data dále lépe analyzovat a stále je apelováno na tvůrce služeb, aby metadata vytvářeli.
4.3.6 UDDI
Universal Description, Discovery and Integration (UDDI) můžeme označit jako registr nebo katalog webových služeb. UDDI je však především definice rozhraní webové služby, které umožňuje obsluhovat katalog služeb. K metodám které UDDI popisuje (definuje) patří: •
Publikuj službu, •
Najdi službu, •
Dej popis služby, •
Aktualizuj popis služby.
4.3.7 WSIL
WSIL (Web Services Inspection Language) je snahou společnosti IBM o zjednodušení přístupu k seznamům služeb oproti relativně komplikovanému UDDI. WSIL je jednoduchý jazyk založený na XML, který umožňuje vytvořit seznam služeb dostupných v rámci domény.
Takto vytvořený dokument je umístěn pod jasně daným názvem inspection.wsil do kořenového adresáře domény (např. http://gis.vsb.cz/inspection.wsil). Aplikace hledající služby si pouze přes standardní HTTP protokol vyžádá daný soubor a tak může jednoduše uživateli nabídnout dostupné služby.
Př. 4 1 Ukázka zápisu v jazyce WSIL
<?xml version="1.0"?>
<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/"
xmlns:wsilwsdl="http://schemas.xmlsoap.org/ws/2001/10/inspection/wsdl/">
<service>
<description referencedNamespace="http://schemas.xmlsoap.org/wsdl/"
location="http://example.com/stockquote.wsdl">
<wsilwsdl:reference>
<wsilwsdl:implementedBinding
xmlns:ns1="http://example.com/stockquote.wsdl">ns1:StockQuoteSoapBinding</
wsilwsdl:implementedBinding>
<wsilwsdl:implementedBinding
xmlns:ns1="http://example.com/stockquote.wsdl">ns1:StockSymbolLookupSoapBi
nding</wsilwsdl:implementedBinding>
</wsilwsdl:reference>
</description>
</service>
74
<service>
<description referencedNamespace="http://schemas.xmlsoap.org/wsdl/"
location="http://example.com/tools/calculator.wsdl"/>
</service>
</inspection>
4.3.8 CSW 2.0
CSW 2.0 (Catalogue Services for the Web) se jeví jako vhodná specifikace pro vyhledávání služeb. Za všech okolností je však nutné tuto specifikaci kombinovat s dalšími specifikacemi jako je UDDI nebo WSIL. Není totiž možné očekávat, že vývojáři mimo oblast geoinformatiky budou ochotni implementovat CSW 2.0 specifikaci. CSW 2.0 (nebo jeho minimalistická verze CSW Lite) je však naprosto nezbytným rozhraním pro oblast geoinformatiky, protože umožňuje vyhledávat služby a data na základě prostorové lokalizace. Ostatní starší protokoly není nutné dále podporovat.
Obr. 47: Rozhraní CSW 2.0 (Upraveno dle [Horáková 2007]) K zajištění interoperability mezi specifikacemi UDDI, WSIL a CSW 2.0 musí vznikat překladače, které budou schopny překládat (samozřejmě omezeně) z jednoho rozhraní do jiného.
Uživatelé katalogu s rozhraním CSW 2.0 mohou vystupovat ve dvou rolích. V případě uživatelů metadat mohou využívat běžné metody daného rozhraní, které umožňují vyhledávat metadata nebo poskytují informace potřebné pro samotné vyhledávání. V případě tvůrců metadat se dá očekávat zejména využívání transakcí pro aktualizaci a vkládání metadat. Sklizeň záznamů je pak využívána pro metainformační portály.
Další podrobné informace z testování rozhraní CSW 2.0 je možné nalézt v [Horáková 2007]. Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
75
4.3.9 Skryté katalogy
Nesmíme zapomínat na to, že každá dobře navržená služba typu WMS, WFS nebo WCS je sama o sobě katalogem metadat, neboť v GetCapabilities by měla obsahovat odkazy na popisy používaných (distribuovaných) dat. 4.4 Analytické služby
Pro otevřený GeoWeb je velmi důležitá především analýza dat, které jsou základem celého systému. Analýza dat musí být založena na metadatech, která je popisují. Naneštěstí nejen samotná data hrají roli při jejich analýze. Celý proces analýzy dat je komplikován zejména užitím dat.
Pro kvalitní analýzu dat potřebuje celý systém také jasnou specifikaci jak se budou daná data užívat. Na prvním místě hraje roli důvod resp. účel užití a na druhém místě také kontext uživatele, ve kterém se nachází. V této oblasti je poměrně mnoho ke zkoumání a zatím neexistují jasná pravidla jak takovéto informace specifikovat, tak aby s nimi mohl systém efektivně nakládat.
Kromě tohoto typu služeb bude nutná existence i služeb analyzujících geodata z pohledu prostorové analýzy dat. K takovýmto typům služeb budou patřit zejména zonální a fokální operace, analýzy okolí, statistické analýzy nebo transformace dat. Jako příklad analytických služeb je nutné uvést minimálně dva projekty. ArcWeb Services (společnost ESRI), PyWPS (Jáchym Čepický) a GRASS Web Services (Antonín Orlík).
4.5 Choreografie, orchestrace a řetězení služeb Poslední tři vrstvy v architektuře WS (Web Service), které byly zmíněny dříve jsou velmi důležité. Obecně se tato oblast nazývá orchestrace služeb. Cílem orchestrace webových služeb je vytvořit dynamickou strukturu webových služeb, které plní určitý úkol. Jednotlivé služby jsou do procesu zapojovány dle aktuální potřeby.
Aktuálními potřebami mohou být např. cena za použití služby, kvalita dat, kvalita algoritmů, garance služby, specifika vytvářené mapy pro různé účely resp. pro různé odběratele, rychlost zpracování požadavků. Kvalita orchestrace služeb je závislá na kvalitě popisu služeb, dat a algoritmů. 4.5.1 BPEL
“Business Process Execution Language (BPEL) je dominantním jazykem pro orchestraci procesů“ [Havey 2006]. BPEL pracuje především s funkčními aspekty obchodních procesů [Colapicchioni 2005]:
● řízení kontroly (větvení, cykly, paralelní zpracování),
76
asynchronní komunikace a vztahy,
● dlouhotrvající zpracování, vnoření, chyby a nahrazování procesů.
Proces v podání jazyka BPEL sestává z několika kroků, každý z nich je nazýván „aktivitou (activity)“. BPEL podporuje využívání jednoduchých i komplexních aktivit. Jednoduché aktivity reprezentují základní stavební prvky a jsou využívány pro běžné úkoly jako jsou [Růžička 2006b]:
● Vyvolání webové služby, použitím <invoke>.
● Čekání na vyvolání obchodního procesu klientem zasláním zprávy, použitím <receive> (receiving a request).
● Generování odpovědi pro synchronní operace, použitím <reply>.
● Zpracování proměnných, použitím <assign>.
● Indikování chyb a výjimek, použitím <throw>.
● Čekání po určitou dobu, použitím <wait>.
● Ukončení celého procesu, použitím <terminate>.
Aktivity mohou být kombinovány tak aby definovaly komplexní algoritmus, který přesně popisuje obchodní proces. Ke kombinování jednoduchých aktivit nabízí BPEL několik strukturních aktivit. Mezi hlav ní patří:
• Sekvence (<sequence>), která nabízí možnost definování posloupnosti vykonávání aktivit.
• Proud (<flow>) k definici sady aktivit, které mají být vykonány paralelně.
• Struktura caseswitch (<switch>) k implementaci větvení.
• While (<while>) k definování cyklů.
• Schopnost výběru jedné z několika alternativních cest, použitím <pick>
Každý proces definovaný s využitím BPEL umožňuje definování odkazy na spolupracující procesy a deklarování proměnné, použitím <variable>.
Jazyk BPEL se jeví jako velmi vhodný pro orchestraci služeb. V letošním roce jsou rovněž testovány jiné jazyky, které by mohly orchestraci vhodně doplnit.
●
4.5.2 WSCDL
Web Service Choreography Description Language (WSCDL) není příliš složitým standardem pokud se na něj díváme z technického pohledu, v případě pohledu ze strany návrhu reálné choreografie pro integraci se stává tento jazyk komplikovaným. Hlavní myšlenky WSCDL popsané v [W3C 2006b] jsou následující:
● WSCDL je zaměřen na kompozici interoperabilních spolupracujících společenstev webových služeb vytvářených mezi různými typy účastníků bez ohledu na jakých platformách, technologiích a architekturách staví svá interní obchodní řešení. Popis choreografie je způsob náhledu na propojení více obchodních modelů z globálního pohledu. WSCDL nabízí způsob zápisu takového propojení.
● WSCDL slouží zejména ke specifikaci globálního pohledu na spolupráci organizací při mezipodnikové integraci. Jednotliví účastníci integrace mohou svá řešení testovat v kontextu tohoto globálního pohledu a umožnit tak efektivní integraci. WSCDL nabízí pravidla pro popis omezení, kterými se mezipodniková výměna zpráv bude řídit.
77
Výhodou globálního pohledu je oddělení mezipodnikové integrace od vnitropodnikové integrace. Toto oddělení umožňuje pro jednotlivá podniková řešení využívat naprosto rozdílné postupy a technologie pro integraci. To ve svém důsledku znamená, že i při zásadní změně vnitropodnikových pravidel nedojde k ohrožení integrace s okolními partnery. Tato pravidla se mohou velmi dobře uplatnit (pokud se WSCDL uchytí mezi vývojáři) pro platformu otevřený GeoWeb, protože v případě této platformy vždy půjde o choreografii mezi mnoha podnikovými orchestry. WSCDL neřeší problematiku vlastní orchestrace služeb, k tomuto účelu slouží jiné jazyky jako např. BPEL, popsaný výše. WSCDL bude do oblasti platformy vstupovat až později nebo nikdy. V nejbližší době si platforma vystačí s jednoduchým WPS a prozatím dostatečně komplexním BPEL. ●
4.6 Zabezpečení, platby
4.6.1 Zabezpečení
GeoWeb samozřejmě pracuje i s daty, která vyžadují určitou míru zabezpečení. Zabezpečení v heterogenních distribuovaných sítích však není tak triviální jako v případě běžné koncepce klientserver. Především budou zprávy různého druhu putovat po mnoha programových komponentách a ne vždy celá zpráva bude muset být čitelná pro danou komponentu. Např. některé překladače (viz dále) potřebují pouze detekovat typ obsahu zprávy a kontext, samotný obsah je však zajímat nemusí, protože pro přeložení samotné se starají jiné služby.
Jiným příkladem kdy je nutné různě přistupovat k dílčím částem zprávy je přístup různých uživatelů k jednomu zdroji. Pokud k jednomu zdroji přistupuje více uživatelů s různými právy dolování dat, ale vyžadují data ze stejného registru a data mají být doručena do přibližně stejného místa, pak je efektivní požadavek zaslat pouze jednou pro všechny uživatele, vhodně jej zašifrovat a tak různé části odpovědi zpřístupnit jen oprávněným osobám. K tomuto účelu se využívá s výhodou jazyk XML, kde je možné různé části zašifrovat různými klíči. Respektive se může využívat přímo jazyk SAML [OASIS 2006b], který je k těmto účelů určen nebo jazyk WSSecurity [Rosenberg 2004]. Princip je schématicky zobrazen na Obr. 48.
78
Obr. 48: Per partes šifrování
Klienti zašlou požadavek, který směřuje do jednoho datového skladu. Požadavek může být vyřízen jedním dotazem a zaslán v jedné odpovědi. Z důvodu bezpečnosti však musí být jednotlivé části odpovědi zašifrovány tak aby se k nim doslati jen oprávnění uživatelé. Např. operátor 1 pro svou práci potřebuje znát pouze počet osob a nemá práva zjišťovat polohu osob.
4.6.2 Platby
Problematičtější situace je v oblasti plateb za použití služeb. Je pravděpodobné, že společnosti provozující služby budou chtít jejich provoz a vývoj financovat z plateb za jejich užívání. Identifikace zákazníka je velmi jednoduchá, k tomuto účelu stačí využít elektronický podpis. Např. v prostředí platformy .NET 3.0 je k dispozici Windows Card Space, která umožňuje snadnou idenfifikaci uživatele včetně jeho profilování. Problémy, které však vyřešeny nejsou se týkají formy jakou se bude použití účtovat. Někdy totiž záleží více na množství vygenerovaných dat, někdy na tom jaká data byla použita.
Jiným zásadním problémem je smluvní vztah mezi zákazníkem a poskytovatelem služeb. Není reálné aby zákazník měl uzavřen smluvní vztah se všemi poskytovateli služeb. Toto může vést k několika řešením, které jsou však vysoce spekulativní a nebylo možné je pro účely tohoto učebního textu důkladněji prověřit. Jednotlivé modely se mohou také kombinovat.
1. Vznik korporací, které budou nabízet sady služeb a smluvní vztah bude vždy jen mezi zákazníkem a korporací a mezi samotnými korporacemi.
2. Úplné osvobození používání služeb od poplatků a financování celé infrastruktury z veřejných rozpočtů.
79
3. Ad hoc smluvní vztahy, uzavřené samotným použitím služby. Tato možnost však ze všech tří nejvíce naráží na problematiku právní.
4.7 Klienti
Klienti pro služby poskytované v rámci otevřeného GeoWeb mohou být různého charakteru. Základním předpokladem je, že každý uživatel bude moci využívat svůj oblíbený nástroj pro připojování ke službám a orchestrům, které jsou k dispozici.
Klienti mohou být spouštěni v rámci WWW prohlížeče nebo být desktop aplikací. V zásadě se nabízí dva základní přístupy.
1. Univerzální klienti.
2. Samo generující se klienti.
4.7.1 Univerzální klient
Univerzální klient vychází z předpokladu, že pro práci s prostorovými daty nabízí z uživatelského hlediska jen několik základních operací a pracovat jen s několika základními datovými formáty.
Univerzální klienti se liší také dle možností práce s 2D nebo 3D (případně vícerozměrnými) daty.
Mezi základní funkce, které univerzální klient nabízí patří:
● Vizualizace rastrového formátu prostorových dat (obvykle PNG, který je již transformován dle aktuálního referenčního systému používaného uživatelem).
● Vizualizace vektorového formátu prostorových dat (SVG a GML).
● Vytváření geometrických prvků.
● Editace existujících geometrických prvků.
● Definování tříd, vlastností a metod nových geoprvků.
● Spouštění služeb a orchestrů.
4.7.2 Samo generující se klienti
Samo generující se klienti jsou rovněž součástí celé platformy. Někdy je totiž výhodné převést část logiky na stranu klienta. Vygenerovaný klient je součástí některého z univerzálních klientů jako tzv. zásuvný modul.
V zásadě existuje několik různých modelů generování, přičemž se tyto mohou kombinovat. Dále jsou popsány tři možné metody.
Na základě rozhraní
Tento přístup je velmi obecný, ale tím také velmi flexibilní. Je postaven na základě rozhraní (resp. typu dotazu a typu odpovědi služby nebo orchestru). V takovém případě dojde k vygenerování GUI odpovídající možnostem zadání parametrů volání a možnostem vizualizace odpovědi. Systém generující klienta se pokusí datové typy převést do podoby Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
80
GUI. K tomu využívá existující komponenty. Ty se pokusí vhodně zkombinovat. K každému datovému typu se pokusí najít odpovídající komponentu. V případě že komponenta nebude nalezena, pokusí se datový typ rozložit na základní typy a k těm pak vystavět GUI. Toto však může často končit neúspěchem, Na základě tModelu
Tmodel (definice z UDDI) udává jakého typu daná služba je. Rozhraní v tomto případě není načítáno dynamicky, ale je jasně dáno typem služby (např. WMS). Pro dané tModely existují odpovídající obecné komponenty začlenitelné do existujících univerzálních klientů. Tyto komponenty je nutné vždy do určité míry přizpůsobit.
Na základě kontextu
K oběma metodám, které jsou spíše technického charakteru se přidává další metoda, která řeší otázku kontextu aplikace a uživatele. Tato metoda bere v úvahu i to v jakém prostředí uživatel pracuje, např., jaké používá technické zařízení pro vizualizaci, jaké je jeho znalostní pozadí (inženýr, manažer), v jaké situaci se nachází.
4.7.3 Překladače
Překladače hrají nejvýznamnější roli v případě, že se uživatelé resp. vývojáři vydají cestou univerzálního jednoduchého klienta. Překladače slouží k překladu z jednoho formátu do druhého. Např. pokud uživatelova klientská aplikace neumožňuje vizualizovat formát SVG, který je jediným výstupem služby, požádá klient o překlad tohoto formátu jinou službu do formátu, kterému rozumí. Takové službě se pak říká překladač. 4.8 Využití open source nástrojů pro platformu otevřený GeoWeb
Následující tabulka uvádí stručný výčet možných nástrojů (jedná se o reprezentativní výběr) z oblasti open source, které lze využít pro budování nodů platformy otevřený GeoWeb.
Tabulka 43: Open source pro platformu otevřený GeoWeb
Oblast
Možné nástroje
Datové služby
UMN MapServer, GeoServer, Deegree, PostGIS
Metadatové služby
GeoNetwork Open Source, CatMDEdit, Deegree
Analytické služby
GRASS (pyWPS), PostGIS (Gazeteer), WSCS, HUMBOLDT
Orchestrace, Choreografie
Active BPEL, WSCDL Eclipse, LTSA, MULE, OpenESB, NetBeans IDE
Platby
???
81
Klienti
OpenJUMP, uDIG, QGIS, gvSIG, GRASS, CatMDEdit, Mozilla, FreeWRL
Překladače
GDAL, OGR, PROJ.4, XSLTProc, Mozilla, HUMBOLDT
Zabezpečení
OpenSSL, JBOSS, MULE
Tabulka samozřejmě obsahuje jen zlomek toho, co dnes open source sféra nabízí, přesto se zatím nepodařilo objevit perspektivní nástroj pro řešení politiky plateb. Důvodem bude zřejmě častá orientace open source sféry na bezplatné poskytování dat. Přesto v oblasti služeb platby obvyklé bývají, ale to v jiné než webové rovině.
4.9 Využití platformy Semantic Web pro platformu otevřený GeoWeb
Platforma Semantic Web přináší mnoho nových pohledů na Web a jeho možnosti pro integraci informačních systémů. Sami autoři uvádějí, že nejsou ani tak zajímavé možnosti co je možné na platformě dělat, o kterých dnes víme, ale daleko zajímavější jsou ty možnosti, o kterých zatím ani nevíme.
Je složité jasně říci co tato platforma pro platformu otevřený GeoWeb přinese. Je jasné, že už se využívají možnosti v oblasti OWL a RDF, ale zatím jsou to jen minoritní implementace.
Hlavní výhodu v platformě Semantic Web spatřuje autor v možnosti relativně snadným způsobem definovat vazby a z nich odvozovat další skutečnosti. Tento princip je podobný principům znalostní báze expertních systémů. Takto vznikající expertní systém je však ve svých rozměrech unikátní. Na základě propojenosti znalostních prvků z mnoha domén bude možné odvozovat skutečnosti, které by jinak zůstaly skryty.
Platforma otevřený GeoWeb je založena na principech SOA a na webových službách. Tento způsob distribuce dat do globální databáze však může být pro mnoho potenciálních uživatelů příliš komplikovaný. Dále tento způsob zpřístupnění dat vyžaduje popis rozhraní v podobě, která stále ještě vyžaduje pro implementaci zásah programátora. Principy OWL a RDF však nabízejí popis dat v takové podobě, která bude zřejmě uchopitelná více automatizovaným způsobem než běžné popisy jako např. WSDL.
Pro další rozvoj platformy otevřený GeoWeb se tedy nabízejí dva způsoby využití platformy Semantic Web. Oba tyto způsoby pak musí koexistovat, tak aby využití bylo efektivní.
V první řadě je to tedy doplnění popisů rozhraní služeb popisy s využitím jazyků RDF a OWL. Díky tomuto doplnění bude možné s rozhraními služeb zacházet daleko více v kontextu uživatele a jeho potřeb, a také dojde k zlepšení automatizovaného generování zásuvných modulů pro univerzálního klienta.
V druhé řadě je to zpřístupnění dat bez využití webových služeb a pouze s využitím popisu v podobě RDF a OWL. Takto zveřejněná data pak bude snadné integrovat do platformy otevřený GeoWeb. Buď budou postupně vznikat katalogy takto publikovaných dat, Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
82
což bude možné s využitím robotů, a tedy automatizovaně. Nebo bude přístup k datům zajišťován „pouhým“ prohledáním stromu tripletů.
Jako příklad pro pochopení těchto uvedených poznatků může posloužit následující. Data o množství vypěstované pšenice budou vystavena na WWW ČSÚ v podobě XML dokumentu, který však bude doplněn metadaty v podobě RDF nebo OWL. Takto vystavená data bude možné jasně identifikovat a tak využít v geoinformatice. Běžný uživatel pak bude moci zadat velmi jednoduchý požadavek, že by chtěl kartogram výnosů pšenice v ČR pro jednotlivé kraje. Služba, která mu bude schopna takový výstup zprostředkovat si pouze s využitím RDF nebo OWL identifikuje potřebná data a propojí se geodaty pro vizualizaci administrativních jednotek krajů. Na základě takto získaných dat vytvoří potřebný výstup.
83
5 Závěr
5 Závěr
Předložený text shrnuje problematiku otevřené platformy GeoWeb a využití značkovacích jazyků pro ni, která bude v budoucnosti základem pro vývoj většiny geoinformačních systémů. Text má posloužit především jako materiál, který shrnuje poznatky a upozorňuje na možností této vznikající platformy. Možnosti vznikající platformy jsou vázány na využití značkovacích jazyků. Text je tedy možné využít jako studijní materiál pro předmět Značkovací jazyky. Text v žádném případě nezachází do podrobností, ty jsou obvykle popsány v článcích publikovaných na odborných setkáních a v materiálech k seminářům, které autor připravil. Růžička, J. Značkovací jazyky na platformě GeoWeb. Učební materiál.
84
6 Seznam použité literatury a dalších informačních zdrojů
[Aalders 2001]: AALDERS, H., J., G., L. Data searching by metadata [CDROM]. In Sborník z konference GIS Ostrava 2001, Ostrava, 2001, ISSN 1213239X.
[Aalders 1998]: AALDERS, H., J., G., L. GIS standards in CEN and ISO [online]. In Sborník z konference GIS Ostrava 1998. 1998 [cit. 20020616]. Dostupný na WWW: <http://gis.vsb.cz/GIS_Ostrava/GIS_Ova_1998/Sbornik/aalders/aalders.html>.
[Aditya 2003]: ADITYA, T.; LEMMENS, R. Chaining Distributed GIS Services [online]. 2003 [cit. 2005
0616]. Dostupný na WWW: <http://www.itc.nl/library/Papers_2003/non_peer_conf/aditya.pdf>.
[Adobe 2006]: Macromedia Player Licensing [online]. 2006 [cit. 20060616]. Dostupný na WWW: <http://www.adobe.com/licensing/developer/>.
[AG GIS 2005]: Deegree [online]. 2005 [cit. 20050616]. Dostupné na WWW: <http://deegree.sourceforge.net/>.
[Apache 2001]: Batic SVG Tollkit [online]. 2001 [cit. 20030616]. Dostupný na WWW: <http://xml.apache.org/batik/index.html>.
[Apache 2006]: Apache Tomcat [online]. 2006 [cit. 20060616]. Dostupný na WWW: <http://tomcat.apache.org/>.
[Andersen 2000]: ANDERSEN, H. P. Metadata Transfer via XML. In Proceedings The Nordic GIS Conference [online], Reykjavík, 2000 [cit. 20020616]. Dostupný na WWW: <http://www.ginorden.org/konf/getpaper.php?ID=13>.
[Apache 2005]: Axis [online]. 2005 [cit. 20050616]. Dostupné na WWW: <http://ws.apache.org/axis/>.
[askGIraffe 2002]: AskGIraffe, Data Locator [online]. 2001 – 2002 [cit. 20020616]. Dostupný na WWW: <http://datalocator.askgiraffe.org.uk/>.
[Autodesk 2005]: Autodesk [online]. 2005 [cit. 20050216]. Dostupné na WWW: <http://www.autodesk.com/>.
[Beneš 2005]: BENEŠ, M. Komponentní technologie [online]. 2005 [cit. 20050616]. Dostupný na WWW: <http://www.cs.vsb.cz/behalek/vyuka/pte/texty/komponenty/index.html>.
[BKG 2001]: ATKIS, Metainformationssystem [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.atkis.de/meta/meta_start_eng.htm>.
[BEA 2006]: BEA WebLogic Server 2006 [online]. 2006 [cit. 20060616]. Dostupný na WWW: <http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/weblogic/server/>.
[CAGI 2006]: MIDAS [online]. 2001 – 2006 [cit. 20060616]. Dostupný na WWW: <http://gis.vsb.cz/midas>.
[Cartonet 2001]: SVG Scalable Vector Graphics, Enabler for WebCartography [online]. 2000 – 2001 [cit. 20020616]. Dostupný na WWW: <http://www.carto.net/papers/svg/first_e.html>.
[CCSDS 2002]: Consultative Committee for Space Data Systems [online]. 2001 – 2002 [cit. 200206
16]. Dostupný na WWW: <http://www.ccsds.org/>.
[CCSDS 2002b]: CCSDS. Parameter Value Language Specificaton [online]. 2002. Dostupný na WWW: <http://www.ccsds.org/documents/pdf/CCSDS641.0B2.pdf>.
[CEN 1998]: CEN /TC 287. ENV 12657:1998 Geographic information – Data description – Metadata, CEN, 1998, 80 s.
[CEN 1998b]: CEN /TC 287. ENV 12656:1998 Geographic information – Data description – Quality, CEN, 1998, 46 s.
[CEN 2002]: CEN [online]. 2006 [cit. 20060616]. Dostupný na WWW: <http://www.cenorm.be>.
[CENELEC 2001]: CENELEC [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.cenelec.org>.
85
[CGDI 2001]: CGDI. About Discovery Portal – Services [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://ceonet.gc.ca/about/en/2.2.html>.
[CGDI 2001b]: CGDI. About Discovery Portal – Technology [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://ceonet.gc.ca/about/en/2.3.html>.
[Chassels 2000]: CHASSELS, M.,R. New Jersey Makes Environmental Data and GIS More Accessible Through the Environmental Data Exchange (ENDEX) [online]. 2000 [cit. 20020616]. Dostupný na WWW: <http://www.esri.com/library/userconf/proc00/professional/papers/PAP611/p611.htm>.
[CIESIN 2001]: CIESIN. CIESIN's Guide to Metadata [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.ciesin.org/metadata/TOC/>.
[CNIG 2001]: SNIG [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://snig.cnig.pt/>.
[Coene]: COENE, Y.; NGUYEN, T., H. Building a Web Services Network with BPEL [online]. 2005 [cit. 20060616]. Dostupný na WWW: <http://www.oracle.com/technology/pub/articles/bpel_cookbook/coene.html>.
[Colapicchioni 2005]: COLAPICCHIONI, A. Knowledge Centred Earth Observation (KEO): A service oriented architecture for information discovery and exploitation [online]. 2005 [cit. 20060616]. Available at: <http://earth.esa.int/rtd/Events/ESAEUSC_2005/Pr51_Colapicchioni.ppt>.
[Cover 2001]: COVER, R. XML Metadata Interchange (XMI) [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.oasisopen.org/cover/xmi.html>.
[Craglia 2000]: CRAGLIA, M. Metadata: European Needs and User Perspectives [CDROM], In Proceedings from 6th ECGIS Workshop, The Spatial Information Society Shaping the Future, Lyon, 2000.
[Craglia 2000b]: CRAGLIA, M. Towards a European Approach to Metadata for Geographic Information [online]. 2000 [cit. 20020616]. Dostupný na WWW: <http://www.ecgis.org/etemii/reports/D421
metadata.pdf>.
[ČSNI 2002]: ČSNI [online]. 1998 – 2002 [cit. 20020616]. Dostupný na WWW: <http://www.csni.cz/>.
[ČSNI 2001]: ČSNI. Historický vývoj národní normalizace [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.csni.cz/WWWCSNI/history.htm>.
[DCMI 1999]: DCMI. Dublin Core Element Set v. 1.1. – Reference Description [online]. 1999 [cit. 2005
0616]. Dostupný na WWW: <http://dublincore.org/documents/dces/>.
[DCMI 2002]: Dublin Core Metadata Initiative (DCMI) [online]. 1999 – 2002 [cit. 20020616]. Dostupný na WWW: <http://dublincore.org/>.
[Duchoslav 2002]: DUCHOSLAV, T. Tvorba metainformačního systému pro prostorová data s využitím Internetových technologií. Diplomová práce, VŠBTUO, Ostrava, 2002, 72 s.
[Duchoslav 2004]: DUCHOSLAV T.; HORÁK J.; RŮŽIČKA J.; HORÁKOVÁ B. WebCastle [online]. In Sborník z konference GIS Ostrava 2004, Ostrava, 2004 [cit. 20050616]. Dostupné na WWW: <http://gis.vsb.cz/Publikace/Sborniky/GIS_Ova/gis_ova_2004/sbornik/duchoslav/duchoslav.htm>. ISSN 1213239X.
[Eclipse 2005]: Eclipse. 2005 [cit. 20060616]. Dostupné na WWW: <http://www.eclipse.org/>.
[ECMA 2001]: ECMA [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.ecma.ch>.
[EEA 1999]: European Environment Agency. GEMET – GEneral Multilingual Environmental Thesaurus [online]. 1999 [cit. 20020616]. Dostupný na WWW: <http://www.mu.niedersachsen.de/cds/etc
cds_neu/software.html#gemet>.
[EEA 2001]: European Environment Agency. Information Locator Service [online]. 2001 [cit. 200206
16]. Dostupný na WWW: <http://www.mu.niedersachsen.de/system/cds/>.
[EPSG 2006]: EPSG. EPSG Geodetic Parameter Dataset [online]. 2006 [cit. 20060615]. Dostupný na WWW: <http://www.epsg.org>.
[ESRI 2002]: ESRI. ArcCatalog [online]. 2002 [cit. 20050616]. Dostupný na WWW: <http://www.esri.com/software/arcgis/arcinfo/overview3.html>.
86
[ESRI 2005b]: ESRI. ArcIMS [online]. 2005 [cit. 20050616]. Dostupný na WWW: <http://www.esri.com/software/arcgis/arcims/index.html>.
[ESRI 2005]: ESRI. 2005 [cit. 20050616]. Dostupné na WWW: <http://www.esri.com/>.
[ESRI 2001]: ESRI. ESRI Profile of the Content Standard for Digital Geospatial Metadata [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.esri.com/metadata/esriprof80.html>.
[ESRI 2001b]: ESRI. ESRI Shapefile Technical Description [online]. 2001 [cit. 20020616]. Dostupný naWWW: <http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf>.
[ETSI 2001]: ETSI [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.etsi.org>.
[ETC/CDS 1998]: European Topic Centre on Catalogue of Data Sources (ETC/CDS). European Environment Agency. Comparing the ETC/CDS core data model to GILS, GELOS, Dublin Core and ISO/CD 1504615 [online]. 1998 [cit. 20020616]. Dostupný na WWW: <http://www.mu.niedersachsen.de/cds/etccds_neu/library/Comparing_models.pdf>.
[FAOUN 2005]: FAOUN. 2005 [cit. 20050616]. Dostupné na WWW: <http://www.fao.org/>.
[FAOUN 2006]: GeoNetwork OpenSource. 2006 [cit. 20050616]. Dostupné na WWW: <http://geonetwork.sourceforge.net/>.
[FAOUN 2006b]: Intermap. 2006 [cit. 20060616]. Dostupné na WWW: <http://sourceforge.net/projects/intermap/>.
[FGDC 2001]: National Spatial Data Infrastructure (NSDI) [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.fgdc.gov/clearinghouse/>.
[FGDC 2002]: FGDC. Set up a Clearinghouse Node [online]. 2002 [cit. 20020616]. Dostupný na WWW: <http://www.fgdc.gov/clearinghouse/tutorials/howto.html>.
[FGDC 1998]: FGDC. Standard for Digital Geospatial Metadata [online]. 1998 [cit. 20020616]. Dostupný na WWW: <http://www.fgdc.gov/metadata/contstan.html>.
[FGDC 2002]: FGDC. The Cearinghouse Registry [online]. 2002 [cit. 20020616]. Dostupný na WWW: <http://clearinghouse4.fgdc.gov/registry/browsefunctions.asp>.
[Ferderer 2001]: FERDERER, D. A Data Management LifeCycle [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.esri.com/industries/petroleum/pug2001/ferderer.ppt>.
[Fraser 2001]: FRASER, D.; SMITH, S. Earth Observation Networks: The Virtue of Simplicity [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://ceonet.gc.ca/about/papers/simplicity/simplicity.html>.
[Fraser 2001b]: FRASER, D. Lessons Learned Implementing Z39.50/GEO/Isite WWW Gateways [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://ceonet.gc.ca/about/papers/llgateways/llgateways.html>.
[GeoRSS 2007]: GeoRSS ORG. GeoRSS :: Geographically Encoded Objects for RSS feeds [online]. 2007 [cit. 20070515]. Dostupný na WWW: <http://georss.org/>.
[GIS FSC 2001]: Spatial Information Directory (SPIDI) [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://spidi.gisvlaanderen.be/SPIDI/V3_spidifZoek.htm>.
[Gonçalves 2003]: GONÇALVES, P. GISServer SOAP WebServices [online]. 2003 [cit. 20050616]. Dostupné na WWW: <http://www.inovagis.org/giserver/webservices/>.
[Gouveia 2001]: GOUVEIA, C.; HENRIQUES, P.; NICOLAU, R.; ROCHA, J.; SANTOS, M. Moving from CEN TC 257 to ISO/TC 211 The approach of the Portuguese National Geographic Information Infrastructure. In Proceedings from 4th AGILE Conference on Geographic Information Science, Brno, Czech Republic, 2001.
[Grünreich 2001]: GRÜNREICH, D. GeoMIS.Bund: Metadata Information System for Federal Geodata [CDROM]. In Proceedings from 7th ECGIS Workshop, Managing the Mosaic, Potsdam, 2001.
[Gundavaram 1998]: GUNDAVARAM, S. CGI programování webových stránek a aplikací. Computer Press, Brno, 1998, 453 s., ISBN 807226088X.
[Guptill 1995]: GUPTILL, C.; MORRISON, J., L. a kol. Elements of spatial data quality. Elsevier Science, Ltd., Oxford, 1995, 202 s., ISBN 0080424325.
87
[Guřan 2005]: GUŘAN, J. Vizualizace metadat. Diplomová práce. VŠBTUO, Ostrava, 2005. [Hancock 2000]: HANCOCK, T. Meta what !?! A practitioner's view [CDROM]. In Proceedings from 6th ECGIS Workshop, The Spatial Information Society Shaping the Future, Lyon, 2000.
[Hanslian 2005]: HANSLIAN, J. Stručné představení protokolu Ntrip. Internetový časopis G Portál [online]. ročník 2. Červen 2005 [cit. 20070515]. Ostrava. Dostupné na WWW: <http://gisak.vsb.cz/gportal/modules.php?name=News&file=article&sid=93>
[Hart 1998]: HART, D.; PHILLIPS, H. Metadata Primer A "How To" Guide on Metadata Implementation [online]. 1998 [cit. 20020616]. Dostupný na WWW: <http://www.lic.wisc.edu/metadata/metaprim.htm>.
[Havey 2006]: HAVEY, M. Modeling Web Services Choreography with New Eclipse Tool [online]. 2006 [cit. 20060616]. Available at: <http://webservices.syscon.com/read/175396.htm>.
[Holt 2000]: HOLT, R. and contributors. Exchange Formats for Information Extracted from Computer Programs [online]. 2000 [cit. 20020616]. Dostupný na WWW: <http://plg.uwaterloo.ca/~holt/sw.eng/exch.format/>.
[Hood 2006]: HOOD, E. MIME [online]. 2000 [cit. 20060615]. Dostupný na WWW: <http://www.mhonarc.org/~ehood/MIME/>.
[Horák 2000]: HORÁK, J.; RŮŽIČKA, J. Jazyk XML v geoinformatice. In Sborník z konference GIS Ostrava 2000, Ostrava, 2000, s. 171177, ISBN 12114855.
[Horáková 2007]: HORÁKOVÁ, B.; RŮŽIČKA, J.; OŽANA, R. Development of MetaPortal Prototype and Communication Interface for Czech national environment. In Sborník z konference GIS Ostrava 2007, Ostrava, 2007, s. 123, ISBN 12114855.
[Horáková 2005]: HORÁKOVÁ, B.; RŮŽIČKA, J.; STROMSKÝ, J. Prototyp Metaportálu přístupový bod ke katalogovým službám národní geoinformační infrastruktury. In Sborník z konfernce Geoinformatika ve veřejné správě. 2005 [cit. 20060616]. CAGI. 8 s. Dostupné na WWW: <http://gisak.vsb.cz/wsco/publikace/Horakova_aKol_2005_Brno.pdf>.
[IAB 2001]: IAB [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.iab.org>.
[IANA 2001]: IANA [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.iana.org>.
[IBM 2002]: Developers Works – XML [online]. 2000 – 2002 [cit. 20020616]. Dostupný na WWW: <http://www106.ibm.com/developerworks/xml/>.
[IBM 2006]: Web Sphere. 2006 [cit. 20060616]. Dostupné na WWW: <http://www
306.ibm.com/software/websphere/>.
[IBM 2005]: IBM. WSIL. 2005 [cit. 20060616]. Dostupné na WWW: <http://www
106.ibm.com/developerworks/webservices/library/wswsilspec.html>.
[IEC 2001]: IEC [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.iec.ch>.
[IEEE 2001]: IEEE [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.ieee.org>.
[IETF 2001]: IETF [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.ietf.org>.
[IFLA 2001]: IFLA [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.ifla.org>.
[IGN 2006]: XML encoding and ISO 19139 Schemas [online]. 2006 [cit. 20060616]. Dostupný na WWW: <http://eden.ign.fr/xsd/isotc211>.
[ILRT 2002]: Metadata Research – Overview [online]. 2000 – 2002 [cit. 20020616]. Dostupný na WWW: <http://www.ilrt.bris.ac.uk/discovery/z3950/resources/>.
[INSPIRE 2005]: INSPIRE. 2003 – 2005 [cit. 20050616]. Dostupné na WWW: <http://www.ec
gis.org/inspire/>.
[INSPIRE 2004]: INSPIRE. INSPIRE Architecture and Standards Position Paper. 2004 [cit. 200506
16]. Dostupné na WWW: <http://inspire.jrc.it/reports/position_papers/inspire_ast_pp_v4_3_en.pdf>
[INSPIRE 2007]: INSPIRE. DT Metadata – Draft Implementing Rules for Metadata. 2007 [cit. 200704
12]. Dostupné na WWW: <http://www.ec
gis.org/inspire/reports/ImplementingRules/draftINSPIREMetadataIRv2_20070202.pdf>.
[ISO 1999]: ISO/TC 211. ISO/CD 19115. ISO/TC 211 Secretariat, Oslo, Norway, 1999, 118 s.
88
[ISO 2004]: ISO/TC 211: ISO/DIS 19128. ISO/TC 211 Secretariat, Geneva, Switzerland, 2004 [cit. 20050616], 83 s. Dostupný na WWW: <http://portal.opengis.org/files/?
artifact_id=5316&version=1>.
[ISO 2002]: ISO [online]. 1998 – 2006 [cit. 20060616]. Dostupný na WWW: <http://www.iso.ch>.
[ISO 2001]: ISO. Stages of the developement of International standards [online]. 2001 [cit. 200206
16]. Dostupný na WWW: <http://www.iso.ch/iso/en/stdsdevelopment/whowhenhow/proc/proc.html> [ISOC 2001]: ISOC [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.isoc.org>.
[Isaacs 1998]: ISAACS, S. Dynamické HTML. Computer Press, Brno, 1998, 436 s., ISBN 807226
0839.
[ITU 2001]: ITU [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.itu.ch>.
[JBoss 2006]: JBoss [online]. 2006 [cit. 20060616]. Available at WWW: <http://www.jboss.org>.
[JPP 2005]: JUMP Pilot Project. 2005 [cit. 20050616]. Dostupné na WWW: <http://jump
pilot.sourceforge.net/index.php>.
[JUMP 2005b]: JTS Topology Suite. 2005 [cit. 20050616]. Dostupné na WWW: <http://www.jump
project.org/project.php?PID=JCS&SID=OVER#overview>.
[JUMP 2005c]: JUMP Unified Mapping Platform. 2005 [cit. 20050616]. Dostupné na WWW: <http://www.jumpproject.org/project.php?PID=JUMP&SID=OVER>.
[JUMP 2005d]: The JUMP Project. 2005 [cit. 20050616]. Dostupné na WWW: <http://www.jump
project.org/>.
[Katz 2001]: MetaData and WWW Mapping Home Page [online]. 2000 – 2001 [cit. 20020616]. Dostupný na WWW: <http://www.blm.gov/gis/nsdi.html>.
[KMS 2001]: Geodatainfo.dk [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.geodatainfo.dk/>.
[Kolář 2005]: KOLÁŘ, J. Mapové servery přehled a srovnání. Semestrální práce. VŠBTUO, 2005.
[Kosek 2002]: Domovská stránka Jirky Koska "VŠE O WWW" [online]. 1998 – 2002 [cit. 20020616]. Dostupný na WWW: <http://www.kosek.cz>.
[Kosek 2004]: KOSEK, J. Design stránek [online]. 2004 [cit. 20060615]. Dostupný na WWW: <http://badame.vse.cz/izi228/prednasky/design.pdf>.
[Kralidis 2000]: KRALIDIS, T. GIS Potential Through Metadata and Access Protocol [online]. 2000 [cit. 20020616]. Dostupný na WWW: <http://www.kralidis.ca/gis/project/GISmeta/>.
[Král 2004]: KRÁL, J. Orientace na služby – klíčové paradigma současného softwaru. Str. 119138. 2004. In Proceedings from DataKon 2004. Ed. Karel Ježek. Brno 2004. [Kvist 1997]: KVIST, E. Selection Criteria for the Catalogue of Data Sources, Swedish Environmental Protection Agency and European Topic Centre on Catalogue of Data Sources [online]. 1997 [cit. 20020616]. Dostupný na WWW: <http://reports.eea.eu.int/929167107X/en>.
[Laurent 1999]: LAURENT, S., S. Tvorba internetových aplikací v XML. Brno : Computerpress, 1999, 222 s. ISBN 8072261703.
[Laurie 1997]: LAURIE, B.; LAURIE, P. Apache správa webového serveru. Brno : Computerpress, 1997, 257 s. ISBN 807226043X.
[Leite 2006]: LEITE, F., L., Jr.; BAPTISTA, C., S.; SILVA, P., A.; SILVA, E., R. WSGIS: Towards a SOABased SDI Federation [online]. 2006 [cit. 20070515]. Dostupné na WWW: <http://geoinfo.dpi.inpe.br/col/dpi.inpe.br/geoinfo@80/2006/11.28.11.47/doc/219233.pdf>
[Lesch 2001]: LESCH, J. CrossMedia Database Normalization of Various Metadata Standards for Environmental Decision Support and Community Management [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.esri.com/library/userconf/proc01/professional/papers/pap595/p595.htm>.
[Li 2000]: LI, B.; ZHANG, L. Distributed Spatial Catalog Service on the CORBA Object Bus. GeoInformatika vol. 4 no. 3, October 2000, str. 253 – 269, ISSN 13846175.
89
[Liesenfelt 1999]: LIESENFELT, G. Geographic Information in France [online]. In Sborník z konference GIS Ostrava 1999. 1999 [cit. 20020616]. Dostupný na WWW: <http://gis.vsb.cz/Publikace/Sborniky/GIS_Ova/gis_ova_1999/sbornik/liesenfelt/Referat.htm>.
[Lind 2000]: LIND, M. GI Metadata Datamodel Danish implementation of CEN ENv12657 [HD]. 2000. In Miniseminar om GI Metadata 2000.
[LISA 2002]: Landlýsing – enska [online]. 2002 [cit. 20020616]. Dostupný na WWW: <http://www.lmi.is/landsurvey.nsf/pages/landlysingenglish.html>.
[LTSA 2006]: LTSA WSEngineer [online]. 2006 [cit. 20060616]. Available at WWW: <http://www.doc.ic.ac.uk/ltsa/bpel4ws/>.
[Marenčík 2000]: MARENČÍK, S. Vytvoření grafického rozhraní pro komunikaci s uživateli metainformačního systému CAGI. Diplomová práce, VŠB – TU Ostrava, Ostrava, 2000, 52 s.
[MEGRIN 2001]: GDDD (Geographical Data Description Directory) [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.megrin.org/gddd/>.
[Meitner 2001]: MEITNER, M., J.; CAVENS, D.; SHEPPARD S., R., J. Academic Metadata Standards: Getting Compliance Without Enforcement. In Sborník z konference ESRI User Conference 2001 [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.esri.com/library/userconf/proc01/professional/papers/pap934/p934.htm>.
[Microsoft 2006]: BizTalk Server [online]. 2006 [cit. 20060616]. Dostupný na WWW: <http://www.microsoft.com/biztalk/default.mspx>.
[Microsoft 2001]: Microsoft Corp. Vector Markup Language (VML) [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://msdn.microsoft.com/library/default.asp?
url=/workshop/author/vml/default.asp>.
[Mikloš 2003]: Mikloš, J. XML metainformační systémy. Diplomová práce. VŠBTUO 2003.
[MIS 2005]: Mapový server Magistrátu města Ostravy. 2002 – 2005 [cit. 20050616]. Dostupné na WWW: <http://gisova.mmo.cz/>.
[Mitchel 2003]: MITCHELL, R. Web Services Put GIS on the Map. 2003 [cit. 20050616]. Dostupné na WWW: <http://www.computerworld.com/developmenttopics/development/webservices/story/0,10801,88092
p2,00.html>. [MOP 2001]: Slovenian National Spatial Data Catalogue [online]. 2001 [cit. 20010616]. Dostupný na WWW: <http://www.sigov.si:81/GISborza/MPBeng/>.
[Mono 2005]: Mono [online]. 2005 [cit. 20020616]. Dostupné na WWW: <http://www.mono
project.com/Main_Page>.
[Moroney 2004]: MORONEY, L. Get on the Enterprise Service Bus with the Open Source Mule API [online]. 2004 [cit. 20050616]. Dostupné na WWW: <http://www.devx.com/enterprise/Article/2680?
trk=DXRSS_LATEST>.
[Mort Bay 2006]: Jetty [online]. 2006 [cit. 20060616]. Dostupné na WWW: <http://www.mortbay.org/jetty/index.html>.
[Mule 2005]: MULE [online]. 2005 [cit. 20050616]. Dostupné na WWW: <http://mule.codehaus.org/>.
[Mule 2005b]: Mule Project Team. MULE Architecture Guide [online]. 2005 [cit. 20050616]. Dostupné na WWW: <http://mule.codehaus.org/Architecture+Guide>.
[Mule 2005c]: Mule Project Team. MULE Introduction [online]. 2005 [cit. 20050616]. Dostupné na WWW: <http://mule.codehaus.org/Introduction>.
[MySQL 2005]: MySQL AB. Well Known Text (WKT) [online]. 2005 [cit. 20060316]. Dostupné na WWW: <http://dev.mysql.com/doc/mysql/en/giswktformat.html>.
[NMDGA 2002]: Australian Spatial Data Infrastructure [online]. 2001 – 2002 [cit. 20020616]. Dostupný na WWW: <http://www.auslig.gov.au/asdi/>.
90
[Nelson 1997]: NELSON, D., O.; KRUMM, R., J.; DENHART, S., L.; BEAVERSON, S., K. ArcInfo Solutions to Metadata problems Building a Solid NSDI Clearinghouse Node on a Shifting Metadata Landscape [online]. 1997 [cit. 20060616]. Dostupný na WWW: <http://www.esri.com/library/userconf/proc97/proc97/to500/pap472/p472.htm>.
[Nemoforum 2005]: NEMOFORUM. Národní geoinformační infrastruktura České republiky Program rozvoje v letech 2001 – 2005 [online]. 2005 [cit. 20060616]. Dostupný na WWW: <http://www.vugtk.cz/~nemoforum/adr03/dokum/ngii.rtf>.
[Neomatix 2005]: NEOMATIX CORPORATION. GIS Web Services [online]. 2005 [cit. 20060616]. Dostupný na WWW: <http://gisfactory.com/webservices.html>.
[Neumann 2001]: NEUMANN, A. Vienna Social patterns and structures [online]. 2000 – 2001 [cit. 20020616]. Dostupný na WWW: <http://www.karto.ethz.ch/neumann/cartography/vienna/>.
[NGDF 1999]: NGDF CENTRAL MANAGEMENT TEAM. National Geospatial Data Framework Literature Review of the development and construction of distributed metadata services accessed via the World Wide Web, National Geospatial Data Framework (NGDF) Management Board [online]. 1999 [cit. 20020616]. Dostupný na WWW: <http://www.ngdf.org.uk/Pubdocs/metadata/litrev.htm>.
[NGDF 1999b]: NGDF CENTRAL MANAGEMENT TEAM. National Geospatial Data Framework Neutral Transfer Format for Metadata, National Geospatial Data Framework (NGDF) Management Board [online]. 1999 [cit. 20020616]. Dostupný na WWW: <http://www.ngdf.org.uk/Pubdocs/metadata/neuttrans.htm>.
[NGDF 1999c]: NGDF CENTRAL MANAGEMENT TEAM. National Geospatial Data Framework Communication Protocols for a Distributed Geospatial Metadata Service, National Geospatial Data Framework (NGDF) Management Board [online]. 1999 [cit. 20020616]. Dostupný na WWW: <http://www.ngdf.org.uk/Pubdocs/metadata/commsprot.htm>.
[NGDF 1999d]: NGDF CENTRAL MANAGEMENT TEAM. NGDF Metadata Gateway Architecture v 1.1 [online]. 1999 [cit. 20020616]. Dostupný na WWW: <http://www.ngdf.org.uk/arch.html>.
[NGDF 2001]: The United Kingdom Standard Geographic Base (UKSGB) [online]. 2001 [cit. 200206
16]. Dostupný na WWW: <http://www.ngdf.org.uk/>.
[NLS 2001]: Metadata för geografisk information (MEGI) [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.lm.se/samgis/databaskatalog/>.
[OASIS 2005]: OASIS [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://www.oasis
open.org/>.
[OASIS 2006b]: OASIS Security Services (SAML) TC. SAML [online]. 2006 [cit. 20060627]. Dostupné na WWW: <http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=security>.
[OASIS 2005b]: UDDI [online]. 2005 [cit. 20060619]. Dostupné na WWW: <http://www.uddi.org/>.
[OASIS 2006]: OASIS WSS TC. WSSecurity [online]. 2006 [cit. 20060616]. Dostupné na WWW: <http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wss>.
[OGC 2007]: OGC. Catalogue Service Implementation Specification [online]. 2007. Dostupné na WWW: <http://portal.opengeospatial.org/files/?artifact_id=20555>.
[OGC 2001c]: OGC. Gazetteer (GAZ) [online]. 2001 [cit. 20060616]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?artifact_id=1041>.
[OGC 2001]: OGC. Geography Markup Language (GML) 2.0 [online]. 2001 [cit. 20060616]. Dostupný na WWW: <http://www.opengis.net/gml/01029/GML2.html>.
[OGC 2005b]: OGC [online]. 2005. Dostupné na WWW: <http://www.opengeospatial.org/>
[OGC 2003]: OGC: OWS 1.2 SOAP Experiment Report [online]. 2003 [cit. 20060616]. Dostupné na WWW: <http://www.opengis.org/docs/03014.pdf>.
[OGC 2004]: OGC. OWS Common Implementation Specification [online]. 2004 [cit. 20060616]. Dostupné na WWW: <httphttp://portal.opengis.org/files/?artifact_id=6324>.
91
[OGC 2001e]: OGC. OpenGIS Coordinate Transformation Service Implementation Specification (CT) [online]. 2001 [cit. 20060616]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?
artifact_id=999>.
[OGC 2006]: OGC. OpenGIS Location Services (OpenLS): Core Services [Parts 15] (OLS Core) [online]. 2006 [cit. 20020616]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?
artifact_id=3418>.
[OGC 1999]: OGC. OpenGIS Simple Features Implementation Specification for CORBA [online]. 1999 [cit. 20060616]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?artifact_id=834>.
[OGC 1999b]: OGC. OpenGIS Simple Features Implementation Specification for OLE/COM [online]. 1999 [cit. 20060616]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?
artifact_id=830>.
[OGC 1999c]: OGC. OpenGIS Simple Features Implementation Specification for SQL [online]. 1999 [cit. 20060616]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?artifact_id=829>.
[OGC 2001b]: OGC. OpenGIS Service Architecture [online]. 2001 [cit. 20060616]. Dostupné na WWW: <http://www.opengeospatial.org/docs/02112.pdf>.
[OGC 2002b]: OGC. Sensor Collection Service (SCS) [online]. 2002 [cit. 20060616]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?artifact_id=1141>.
[OGC 2005e]: OGC. Sensor Planning Service (SPS) [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?artifact_id=12971>.
[OGC 2005f]: OGC. Style Management Services for Emergency Mapping Symbology (SMS) [online]. 2005 [cit. 20060616]. Dostupné na WWW: <https://portal.opengeospatial.org/files/?
artifact_id=7470>.
[OGC 2005g]: OGC. Web 3D Service (Web3D) [online]. 2005 [cit. 20060616]. Dostupné na WWW: <https://portal.opengeospatial.org/files/?artifact_id=8869>.
[OGC 2006b]: OGC. OpenGIS Web Coverage Service (WCS) Implementation Specification [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?
artifact_id=12582>.
[OGC 2005c]: OGC. Web Feature Service Implemantation Specification [online]. 2005 [cit. 200606
16]. Dostupné na WWW: <https://portal.opengeospatial.org/files/?artifact_id=8339>.
[OGC 2002]: OGC. Web Feature Service (Transactional) (WFS(T)) [online]. 2002 [cit. 20060616]. Dostupné na WWW: <https://portal.opengeospatial.org/files/?artifact_id=7176>.
[OGC 2003b]: OGC. Web Notification Service (WNS) [online]. 2003 [cit. 20060616]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?artifact_id=1367>.
[OGC 2005d]: OGC. Web Processing Service (WPS) [online]. 2005 [cit. 20070130]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?artifact_id=10634>.
[OGC 2001d]: OGC. Web Terrain Server (WTS) [online]. 2001 [cit. 20060616]. Dostupné na WWW: <http://portal.opengeospatial.org/files/?artifact_id=1072>.
[OGC 1999d]: OGC. The OpenGIS™ Abstract Specification Topic 11 – Metadata [online]. 1999 [cit. 20020616]. Dostupný na WWW: <http://www.opengis.org/public/abstract/99100r1.pdf>.
[OGC 1999e]: OGC. The OpenGIS™ Abstract Specification Topic 13 Catalog Services [online]. 1999 [cit. 20020616]. Dostupný na WWW: <http://www.opengis.org/public/abstract/99113.pdf>.
[Oracle 2002]: XML Home [online]. 2002 [cit. 20020616]. Dostupný na WWW: <http://technet.oracle.com/tech/xml/>.
[Orlík 2006]: ORLÍK, A.; RŮŽIČKA, J.; STROMSKÝ, J.; DĚRGEL, P.; KAMLER, J. Správa časoprostorových dat v prostředí PostgreSQL/PostGIS. In Sborník z konference Open Weekend 2005, Praha 15. 16.10.2005. ISBN: 800103349X.
92
[Panatkool 2002]: PANATKOOL, A.; LAOVEERAKUL, S. Decentralized GISWeb Services on Grid [online]. In Proceedings of the Open source GIS GRASS users conference 2002. Trento, Italy, 1113 September 2002. 2002 [cit. 20060616]. Dostupný na WWW: <http://www.ing.unitn.it/~grass/conferences/GRASS2002/proceedings/proceedings/pdfs/Panatkool_
Apirak.pdf>.
[Papcun 2004]: PAPCUN, P. Dokumentace k ISVS.xsl [online]. Ostrava. 2004 [cit. 20020616]. Dostupné na WWW: <http://gis.vsb.cz/midas>.
[Pastorello 2005]: PASTORELLO, G., Z. Publicacao e Integracao de Workflows Cientificos na Web [online]. 2005 [cit. 20020916]. Ph.D. Thesis. Available at: <http://www.lis.ic.unicamp.br/~gilberto/publicacoes/dissertacao.pdf>.
[Pi4tech 2006]: Pi4SOA CDL Editor [online]. 2006 [cit. 20020616]. Available at: <http://www.pi4tech.com/>.
[Peňáz 2001]: PEŇÁZ, T. Vizualizace prostorových dat z činnosti složek integrovaného záchranného systému v prostředí geografického informačního systému (na příkladu jednotek požární ochrany). Disertační práce, MU Brno, Brno, 2001, 120 s.
[Percivall 2002]: PERCIVALL, G. ISO 19119 and OGC Service Architecture [online]. 2002 [cit. 20060616]. Dostupný na WWW: <http://www.fig.net/pub/fig_2002/JS4/JS4_percivall.pdf>.
[Peterka 2001]: PETERKA, J. Co může Internet nabídnout [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://archiv.czech.net/a710s200/a710s200.htm>
[Peterka 1998]: PETERKA, J. Páni Internetu [online]. 1998 [cit. 20020616]. Dostupný na WWW: <http://archiv.czech.net/a804s200/a804p200.htm>.
[Phillips 2001]: PHILLIPS, H. Metadata Tolls for Geospatial Data [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://badger.state.wi.us/agencies/wlib/sco/metatool/mtools.htm>.
[Phillips 2001b]: PHILLIPS, H. xtme Metadata Entry Tool [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://badger.state.wi.us/agencies/wlib/sco/metatool/xtme.htm>.
[Pilný 2006]: PILNÝ, L. Výroční zpráva Komise GIS HZS ČR 2006. 2007. 44 s. MV – GŘ HZS ČR – Institut ochrany obyvatelstva.
[Pitner 2001]: PITNER, T. Návrh metadatového schématu pro environmentální data [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.mendelu.cz/user/ucpatrik/mendelnet/mendelnetht.htm#pitner>.
[Plewe 1997]: PLEWE, B. GIS Online information, retrieval, mapping, and the internet. Santa Fe, USA : OnWord Press, 1997, 311 s. ISBN 1566901375.
[Pokorný 2001]: POKORNÝ J. Prostorové objekty a SQL [CDROM]. In Sborník z konference GIS Ostrava 2001, Ostrava, 2001, ISSN 1213239X.
[Pokorný 1998]: POKORNÝ, J.; HALANKA. Databázové systémy. Skripta, 1. vyd, ČVUT Praha. 1998, 146 s., ISBN 8001017249.
[QGIS 2005]: Quantum GIS [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://www.qgis.org>.
[Ram 2000]: RAM, S.; KUNZMANN, M., R.; KIM, J.; ABBRUZZI, J., A. Digital "Living" Library A Prototype for Harvesting Ecological Data over the Internet [online]. 2000 [cit. 20020616]. Dostupný na WWW: <http://www.esri.com/library/userconf/proc00/professional/papers/PAP558/p558.htm>.
[Rapant 1998]: RAPANT, P. Geografické informační systémy. Habilitační práce, VŠBTU Ostrava, Ostrava, 1998, 140 s. [RAVI 2001]: NCGI (National Clearinghouse for Geographic Information) [online]. 2001 [cit. 200206
16]. Dostupný na WWW: <http://www.ncgi.nl>.
[Raytheon 2000]: Raytheon STX Corp. Metadata Expression using XML [online]. 2000 [cit. 200206
16]. Dostupný na WWW: <http://tarantella.gsfc.nasa.gov/xml/sdph2000/index.htm>.
93
[Refraction 2005]: GeoServer [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://geoserver.sourceforge.net/html/index.php>.
[Refraction 2006]: PostGIS [online]. 2006 [cit. 20060916]. Dostupné na WWW: <http://www.postgis.org/>.
[Refraction 2006b]: uDIG [online]. 2006 [cit. 20060916]. Dostupné na WWW: <http://udig.refractions.net/confluence/display/UDIG/Home>.
[Relax NG 2007]: Relax NG [online]. 2007 [cit. 20070105]. Dostupné na WWW: <http://relaxng.org/>.
[Rosenberg 2004]: ROSENBERG, J; REMY, D. L. Securing Web Services with WSSecurity. USA : Sams Publishing, 2004, 378 s. ISBN 0672326515.
[RUMN 2002]: Mapserver Homepage [online]. 2006 [cit. 20060616]. Dostupné na WWW: <http://mapserver.gis.umn.edu/>.
[Růžička 2001]: RŮŽIČKA, J. Comparison of CEN, FGDC and ISO standards for metadata [CDROM]. 2001. In Proceedings from 7th ECGIS Workshop, Managing the Mosaic, Potsdam, 2001.
[Růžička 2005]: RŮŽIČKA, J. Distributed architecture Problems described on example from the cartography area [online]. In Proceedings from International Workshop WATERMARK. Vienna. 2005 [cit. 20020616]. Dostupné na WWW: <http://gisak.vsb.cz/wsco/publikace/Ruzicka_2005_Vienna.pdf>.
[Růžička 2004]: RŮŽIČKA, J. GRASS Web Services. Internetový časopis GPortál [online]. ročník 1. Říjen 2004 [cit. 20050616]. Ostrava. Dostupné na WWW: <http://gisak.vsb.cz/gportal/modules.php?name=News&file=article&sid=31>.
[Růžička 2005b]: GeoWeb Internet pro Geoinformatiku [online]. Ostrava. 2005 [cit. 20060616]. Dostupné na WWW: <http://gis.vsb.cz/ruzicka/seminare/geoweb/index.php>.
[Růžička 2000b]: RŮŽIČKA, J.; MARENČÍK S. Jak najít data. Časopis GeoInfo 4/2000. Brno : Computer Press, 2000, 40 41 s. ISSN 12111082.
[Růžička 2005c]: RŮŽIČKA, J.; DĚRGEL, P. Jemný úvod od světa Open Source. Časopis GEOinformace. 1/2005, Praha : Klaudian Praha, 2005, str. 3435. ISSN 12142204.
[Růžička 2005d]: JUMP Plugins from GISAK.VSB.CZ. 2005 [cit. 20060616]. Dostupné na WWW: <http://gis.vsb.cz/ruzicka/Projekty/jump/index.php>
[Růžička 2005e]: RŮŽIČKA, J. Katalog ArcIMS služeb. Časopis arcREVUE [online]. Ročník 14, číslo 4. Praha : ARCDATA Praha s.r.o. Praha. 2005 [cit. 20060616]. str. 39 – 40. ISSN 12112135. Dostupné na WWW: <http://gisak.vsb.cz/wsco/publikace/Ruzicka_2005_ArcData.pdf>.
[Růžička 2002]: RŮŽIČKA, J: Metadata pro prostorová data. Doktorská disertační práce. Ostrava. 2002.
[Růžička 2000]: RŮŽIČKA, J. Metainformation system of CAGI [CDROM]. 2000. In Proceedings from 6th ECGIS Workshop, The Spatial Information Society Shaping the Future. Lyon, 2000.
[Růžička 2005f]: RŮŽIČKA, J. Open GeoWeb and its Orchestration [online]. In. Proceedings from conference GIS Visions 2025. Ostrava. 2005 [cit. 20060616]. VŠBTUO. Dostupné na WWW: <http://gisak.vsb.cz/wsco/publikace/Ruzicka_2005_GISVisions.pdf>.
[Růžička 2005g]: Open Source GIS [online]. Ostrava. 2005 [cit. 20060616]. Dostupné na WWW: <http://gis.vsb.cz/ruzicka/Seminare/OpenSource/index.php>.
[Růžička 1999]: RŮŽIČKA, J. Porovnání aplikace GeoMedia Web Map a FRAMME Field View v podmínkách firmy Ostravské vodovody a kanalizace. Diplomová práce, VŠBTU Ostrava, Ostrava, 1999, 73 s.
[Růžička 2005h]: RŮŽIČKA, J. Pomohou webové služby odstranit noční můru kartografů? In. Sborník z konfernce 16. kartografická konference (Mapa v informační společnosti). Brno. 2005 [cit. 200606
16]. Univerzita Obrany. 10s. ISBN 8072310151. Dostupné na WWW: <http://gisak.vsb.cz/wsco/publikace/Ruzicka_2005_Brno.pdf>.
[Růžička 2004b]: RŮŽIČKA, J. PostGIS 0.8.2. Internetový časopis GPortál [online]. Ročník 1. Srpen 2004 [cit. 20060616]. Ostrava. Dostupné na WWW:<http://gisak.vsb.cz/gportal/modules.php?
name=News&file=article&sid=19>
94
[Růžička 2005j]: Růžička J. Proč používám Open Source. Časopis GEOinformace. 1/2005, Praha : Klaudian Praha, 2005, ISSN 12142204. Str. 35.
[Růžička 2002b]: Seminář "Základy publikování prostorových dat na WWW" [online]. 2002 [cit. 2002
0616]. Dostupný na WWW: <http://gis.vsb.cz/seminarWWW/uvod.htm>.
[Růžička 2006]: RŮŽIČKA, J., Servisně orientovaná architektura – Základ budování NGII. In. Zborník príspevkov GIS 2005. TU Zvolen a SAGI : Zvolen. 2006 [cit. 20060616]. Str. 124 – 131. Dostupné na WWW: <http://www.sagi.sk/LinkClick.aspx?link=zbornik_gis_2005.pdf&mid=706>. ISBN 80
22815810.
[Růžička 2001b]: RŮŽIČKA, J. Srovnání standardů CEN, FGDC a ISO pro metadata [online]. 2001 [cit. 20020616]. In Sborník z konference GIS Seč 2001. Dostupný na WWW: <http://sec.upce.cz/sborniky/2001/Ruzicka.doc>.
[Růžička 2000b]: RŮŽIČKA, J. XML a metadatové služby [online]. 2000 [cit. 20020616]. In Sborník z konference GIS Seč 2000. Dostupný na WWW: <http://sec.upce.cz/sborniky/2000/Ruzicka/Ruzicka.rtf>.
[Růžička 2001c]: RŮŽIČKA, J.. XML a metainformační systémy [CDROM]. 2001. In Sborník z konference GIS Ostrava 2001, Ostrava, 2001, ISSN 1213239X.
[Růžička 2005l]: RŮŽIČKA, J.; FUKS; P. JUMP project a možnosti jeho rozšiřování. In Zborník príspevkov GIS 2005. TU Zvolen a SAGI : Zvolen. 2006 [cit. 20060616]. Str. 132 – 151. Dostupné na WWW: <http://www.sagi.sk/LinkClick.aspx?link=zbornik_gis_2005.pdf&mid=706>. ISBN 80228
15810.
[Růžička 2005k]: Technologie a architektury IS pro podporu interoperability [online]. Ostrava. 2005 [cit. 20060616]. Dostupné na WWW: <http://gis.vsb.cz/ruzicka/seminare/interoperabilita/index.php>.
[Růžička 2004c]: RŮŽIČKA, J.; PAPCUN, P. Využití standardu „ISVS pro metadata“ v prostředí ArcCatalog. Časopis arcREVUE. Ročník 12, číslo 4, str. 9 – 10, Praha : ARCDATA Praha s.r.o., 2003, ISSN 12112135.
[Růžička 2003]: RŮŽIČKA, J.; PEŇÁZ, T.; HORÁK, J.; STANKOVIČ, J.: Publikování prostorových dat na internetu. Distanční text. Ostrava : VŠBTU Ostrava, 2003, ISBN 80 248 0416 – 6.
[Růžička 2005i]: RŮŽIČKA, J.; ŠELIGA, M. Problems with Web Map Service Open GIS specification. 2005. Časopis Acta Montanistica Slovaca. 2/2005, Technical University of Kosice, the Faculty of Mining, Ecology, Process Control and Geotechnologies (F BERG), Košice 2005, ISSN 13351788. Str. 192197.
[Růžička 2006b]: RŮŽIČKA, J.; MARŠÍK, V.; ŠELIGA, M.; PRAGER, M.; ORLÍK, A.; HORÁKOVÁ, B. WSCDL for Geoinformatics [online]. 2006 [cit. 20060616]. In Sborník z konference GIS Brno 2006. Dostupný na WWW: <http://gisak.vsb.cz/wsco/publikace/Ruzicka_a_kolBrno2006.pdf>.
[Růžička 2007a]: RŮŽIČKA, J. a kol. JUMP Plugins from GISAK.VSB.CZ [online]. 2007 [cit. 200705
15]. Dostupný na WWW: <http://gis.vsb.cz/ruzicka/projekty/jump/index.php>.
[Růžička 2007b]: RŮŽIČKA, J.; KLÍMEK, F. Aktuální zemětřesení pro Google Earth. In Sborník z konference GIS Ostrava 2007, Ostrava, 2007, s. 134, ISBN 12114855.
[Růžička 2007c]: RŮŽIČKA, J.; KASZPER, R. Opět o metadatech v geoinformatice. In. sborník z 1. národní kongres v Česku – Geoinformatika pro každého, Mikulov, 29.31.5. 2007. 8 s.
[Satrapa 1997]: Satrapa, P. Web Design. Nekortex, 1997, 414 s. ISBN 809022301X.
[Schutzberg 2001]: SCHUTZBERG, A. XML, GIS and You [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.giscafe.com/GISVision/Review/XML.html>.
[Skřivan 2001]: SKŘIVAN, J. Jazyk XML [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.fi.muni.cz/~xskrivan/prog/xml/index.html>.
[Smith 2001]: SMITH, S.; FRASER, D. Rising Above a Quagmire of Search Protocols [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://ceonet.gc.ca/about/papers/quagmire/quagmire.html>.
[Smith 2001b]: SMITH, S. Low Cost Distributed Geospatial Searching [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://ceonet.gc.ca/about/papers/ssp/ssp.html>.
95
[Smith 2004]: SMITH, S. New OGC Web Services Initiative Announcement [online]. 2004 [cit. 2006
0616]. Available at WWW: <http://www10.giscafe.com/nbc/articles/view_weekly.php?
articleid=208799>.
[SKartverk 2001]: Kartverk produktkatalog [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://katalog.statkart.no/katalog/>.
[SUN 2005]: JDBC [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://java.sun.com/products/jdbc/>.
[Šeliga 2004]: ŠELIGA, M. Přehled technologií pro podporu interoperability a integrace systémů. Internetový časopis GPortál [online]. Ročník 1. Prosinec 2004. 2004 [cit. 20060616]. Ostrava. Dostupné na WWW: <http://gisak.vsb.cz/gportal/modules.php?name=News&file=article&sid=14>.
[Šeliga 2005]: ŠELIGA M., RŮŽIČKA J. Geoinformation systems and web services. 2005. Časopis Acta Montanistica Slovaca. 2/2005, Technical University of Kosice, the Faculty of Mining, Ecology, Process Control and Geotechnologies (F BERG), Košice 2005, ISSN 13351788. Str. 206212.
[Tait 2005]: TAIT, M. ArcWeb Services – On Demand GIS for Business [online]. 2005 [cit. 2000616]. Available at: <http://gis.esri.com/library/userconf/geoinfo05/docs/tait.pdf>
[TeIDE 2005]: CatMDEdit [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://teide.unizar.es/catmdedit>.
[TeIDE 2005b]: TeIDE [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://teide.unizar.es/>.
[Unicode 2001]: Code Charts [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www.unicode.org/charts/>.
[ÚVIS 2001]: ÚVIS: Standard ISVS pro strukturu a výměnný formát metadat informačních zdrojů, verze 1.1, Věstník ÚVIS, 2001.
[ÚVIS 2001b]: ÚVIS: ÚVIS – Hlavni strana [online]. 2001 [cit. 20020616]. Dostupný na WWW: <http://www1.uvis.cz/uvis/web.nsf/pages/uvis>.
[ÚVIS 2002]: ÚVIS: ÚVIS [online]. 2001 2002 [cit. 20020616]. Dostupný na WWW: <http://www.uvis.cz>.
[Vermei 2001]: VERMEIJ, B. Implementing European Metadata Using ArcCatalog . ArcUser [online]. JulySeptember, 2001, str. 30 –33. 2001 [cit. 20020616]. Dostupný také na WWW: <http://www.esri.com/news/arcuser/0701/metadata.html>. ISSN 15345467.
[W3C 2006]: W3C. Web Services Choreography Description Language Version 1.0 [online]. 2006 [cit. 20060616]. Dostupný na WWW: <http://www.w3.org/2002/ws/chor/edcopies/cdl/cdl.html>.
[W3C 2005]: W3C. Extensible Markup Language (XML) [online]. 2005 [cit. 20060616]. Dostupný na WWW: <http://www.w3.org/TR/RECxml>.
[W3C 2005b]: W3C. Extensible Stylesheet Language (XSL) [online]. 2005 [cit. 20060616]. Dostupný na WWW: <http://www.w3.org/TR/xsl/>.
[W3C 2001]: W3C. HTML 4.01 Specification [online]. 2001 [cit. 20060616]. Dostupný na WWW: <http://www.w3.org/TR/REChtml40/>.
[W3C 1999]: W3C. HTTP [online]. 1999 [cit. 20020616]. Dostupné na WWW: <ftp://ftp.isi.edu/in
notes/rfc2616.txt>.
[W3C 2006c]: W3C. Naming and Addressing: URIs, URLs, ... [online]. 1999 [cit. 20060616]. Dostupné na WWW: <http://www.w3.org/Addressing/>.
[W3C 2004]: W3C. RDF/XML Syntax Specification (Revised) [online]. 2004 [cit. 20060616]. Dostupné na WWW: <http://www.w3.org/TR/rdfsyntaxgrammar/>.
[W3C 2004b]: W3C. RDF (Resource Description Framework) [online]. 2006 [cit. 20060616]. Dostupné na WWW: <http://www.w3.org/RDF/>.
[W3C 2004c]: W3C. RDF: Často kladené dotazy [online]. Překlad Petrák J., Zemánek J. 2001 [cit. 20060616]. Dostupné na WWW: <http://dsic.zapisky.info/archive/RDFFAQ20031130/>.
[W3C 2007]: W3C. W3C Semantic Web Interest Group [online]. 2007 [cit. 20070516]. Dostupné na WWW: <http://www.w3.org/2003/01/geo/>.
96
[W3C 2005c]: W3C. SOAP [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://www.w3.org/2000/xp/Group/>.
[W3C 2000]: W3C. SVG DTD's [online]. 2000 [cit. 20060616]. Dostupný na WWW: <http://www.w3.org/TR/2000/03/WDSVG20000303/svgdtd.html>.
[W3C 2005d]: W3C. SVG [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://www.w3.org/Graphics/SVG/>.
[W3C 2006b]: W3C [online]. 1998 – 2006 [cit. 20060616]. Dostupný na WWW: <http://www.w3.org>
[W3C 2005e]: W3C. W3C Internationalization (I18N) Activity [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://www.w3.org/International/>.
[W3C 2005f]: W3C. Web Services Activity [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://www.w3.org/2002/ws/>.
[W3C 2005g]: W3C. Web Services Description Working Group [online]. 2005. Dostupné na WWW: <http://www.w3.org/2002/ws/desc/>.
[W3C 2006b]: W3C XML Protocol Working Group: Home Page [online]. 2006 [cit. 20060616]. Dostupné na WWW: <http://www.w3.org/2000/xp/Group/>.
[WDI 2006]: WDI. Business Integration Engine Javabased integration system [online]. 2006 [cit. 20060616]. Dostupné na WWW: <http://directory.fsf.org/all/bie.html>.
[Web3D 2003]: WEB3D CONSORTIUM. ISO/IEC 14772:1997: Virtual Reality Modeling Language (VRML97) [online]. 2003 [cit. 20060616]. Dostupné na WWW: <http://www.web3d.org/x3d/specifications/vrml/ISOIEC14772VRML97/>.
[Web3D 2005]: WEB3D CONSORTIUM. ISO/IEC 19776:2005: X3D encodings: XML and Classic VRML [online]. 2005 [cit. 20060616]. Dostupné na WWW: <http://www.web3d.org/x3d/specifications/ISOIEC19776X3DEncodingsXMLClassicVRML/>.
[WFPUN 2005]: WFPUN [online]. 2005 [cit. 20050616]. Dostupné na WWW: <http://www.wfp.org/>
[Wick 2007]: WICK, M. Geonames.org [online]. 2007 [cit. 20070515]. Dostupné na WWW: <http://www.nesc.ac.uk/action/esi/download.cfm?index=3384>
[Wikipedia 2006]: WIKIPEDIA. Computer Graphics Metafile [online]. 2006 [cit. 20060616]. Dostupné na WWW: <http://en.wikipedia.org/wiki/Computer_Graphics_Metafile>
[Wood 1997]: WOOD, T.; CASSERATI, S.; CRAGLIA, M. GIMETA Final report. Cambridge, 1997, 164 s.
[WSCDL Eclipse 2006]: WSCDL Eclipse [online]. 2006 [cit. 20060616]. Available at WWW: <http://sourceforge.net/projects/wscdleclipse/>
[WSCO 2006]: WSCO Project [online]. 2006 [cit. 20060616]. Dostupné na WWW: <http://gisak.vsb.cz/wsco/>
97
7 Seznam obrázků, tabulek a příkladů
Seznam obrázků
Obr. 3-1: Využití XML a XSL v prostředí ArcCatalog a MIDASLite (Převzato z [Růžička 2004c])...................27
Obr. 3-2: XML dokument před transformací..........................................................................................................28
Obr. 3-3: XML dokument po transformaci.............................................................................................................28
Obr. 3-4: Příklady Simple Features (Převzato z [Růžička 2005l]).........................................................................30
Obr. 3-5: Hierarchie tříd Simple Features (Převzato z [OGC 1999c])...................................................................31
Obr. 3-6: GML v prostředí aplikace JUMP Workbench.........................................................................................32
Obr. 3-7: Protokol HTTP........................................................................................................................................47
Obr. 3-8: HTTPS protokol......................................................................................................................................48
Obr. 3-9: Struktura požadavku při použití protokolu SOAP (převzato z [Beneš 2005])........................................49
Obr. 3-10: Web Map Service požadavek GetMap..................................................................................................52
Obr. 3-11: Web Feature Service požadavekGetFeature..........................................................................................53
Obr. 3-12: Web Coverage Service požadavek GetCoverage..................................................................................54
Obr. 3-13: Web Processing Service požadavek Execute........................................................................................54
Obr. 4-1: Komponenty architektury otevřený GeoWeb.........................................................................................62
Obr. 4-2: Spolupráce komponent architektury........................................................................................................63
Obr. 4-3: Zapojení katalogů a abstraktní komponeta metaportál...........................................................................64
Obr. 4-4: Možná architektura samostatného veřejného metainformačního systému..............................................66
Obr. 4-5: Možná architektura metainformačního portálu.......................................................................................67
Obr. 4-6: Řetěnení katalogů....................................................................................................................................68
Obr. 4-7: Rozhraní CSW 2.0 (Upraveno dle [Horáková 2007]) ............................................................................75
Obr. 4-8: Per partes šifrování..................................................................................................................................79
98
Seznam tabulek
Tabulka 3-1: Struktura Dublin Core (přeloženo z [DCMI 1999] a doplněno komentáři)......................................39
Tabulka 3-2: Povinné prvky srovnávaných standardů............................................................................................44
Tabulka 3-3: Srovnání Dublin Core a popisovaných standardů.............................................................................45
Tabulka 4-1: Struktura ISO 19115 core (převzato z [ISO 1999] a doplněno překladem)......................................72
Tabulka 4-2: Vyplnění elementů metadat v systému MIDAS pro datové sady geodat..........................................73
Tabulka 4-3: Open source pro platformu otevřený GeoWeb..................................................................................81
Seznam příkladů
Př. 3 -1: Dublin Core v HTML (Převzato z [Kosek 2004])....................................................................................17
Př. 3 -2: Značka XML dokumentu..........................................................................................................................18
Př. 3 -3: Definice prvků v DTD..............................................................................................................................19
Př. 3 -4: Definice atributů prvků v DTD.................................................................................................................19
Př. 3 -5: Definice prvků v XML schématu..............................................................................................................20
Př. 3 -6: Definice prvků v XML schématu..............................................................................................................20
Př. 3 -7 Zápis s využitím RDF (Převzato z [W3C 2007]).......................................................................................22
Př. 3 -8 Zápis tříd geoprvků (Převzato z [Leite 2006])...........................................................................................23
Př. 3 -9 Zápis CSS...................................................................................................................................................23
Př. 3 -10 XML dokument s údaji o nabídce snídaní pro transformaci. (Převzato z [W3C 2005b]).......................24
Př. 3 -11 Následující kód transformuje XML dokument obsahující údaje o nabídce snídaní do HTML podoby.
(Převzato z [W3C 2005b])......................................................................................................................................25
Př. 3 -12 WKT (Převzato z [OGC 1999c]).............................................................................................................31
Př. 3 -13 GML 2.0...................................................................................................................................................32
Př. 3 -14 SVG..........................................................................................................................................................33
Př. 3 -15 VRML......................................................................................................................................................35
Př. 3 -16 X3D..........................................................................................................................................................36
Př. 3 -17 SOAP Request..........................................................................................................................................49
Př. 3 -18 SOAP Response.......................................................................................................................................49
Př. 3 -19: Jmenné prostory......................................................................................................................................50
Př. 3 -20: WMS požadavek GetMap.......................................................................................................................52
Př. 3 -21: Web Feature Service požadavek DescribeFeatureType..........................................................................53
Př. 3 -3 WSDL........................................................................................................................................................58
Př. 4 -1 Ukázka zápisu v jazyce WSIL...................................................................................................................74
99