Datové infrastruktury pro prostorově informační společnost

Transkript

Datové infrastruktury
pro prostorově informační
společnost
Milan Konečný, Petr Kubíček a kolektiv
Masarykova univerzita
Brno 2012
Publikace byla vytvořena v rámci projektu „Lidský potenciál pro informační společnost využívající
prostorová data – GEOTÝM“ (CZ.1.07/2.3.00/09.0199), který byl realizován v letech 2010-2012
a financován Operačním programem „Vzdělávání pro konkurenceschopnost“.
© 2012 Masarykova univerzita
ISBN 978-80-210-6014-2
SEZNAM AUTORŮ
PETR DUDA
LUKÁŠ HERMAN
MIROSLAV KOLÁŘ
MILAN KONEČNÝ
JIŘÍ KOZEL
PETR KUBÍČEK
EVA MULÍČKOVÁ
TOMÁŠ ŘEZNÍK
ZDENĚK STACHOŇ
RADIM ŠTAMPACH
ZBYNĚK ŠTĚRBA
OBSAH
SEZNAM ZKRATEK
9
PŘEDMLUVA
13
1.GLOBÁLNÍ GEOINFORMAČNÍ INFRASTRUKTURY
15
1.1 GIS a internet
15
1.2 Vznik geoinformačních infrastruktur
16
1.3 Národní geoinformační infrastruktura
17
2. INFRASTRUKTURA PRO PROSTOROVÉ INFORMACE V EVROPSKÉM
SPOLEČENSTVÍ (INSPIRE) 19
2.1 Obecný rámec INSPIRE
19
2.1.1 Historie
19
2.1.2 Základní principy INSPIRE
20
2.1.3 Stav realizace Směrnice v České Republice
21
2.2 Infrastruktura INSPIRE
23
2.2.1 Soubory prostorových dat
24
2.2.2 Metadata
26
2.2.3 Síťové služby
26
2.2.4 Sdílení dat
28
2.2.5 Monitoring a reporting
28
2.3 Vytváření a správa metadat podle požadavků směrnice INSPIRE
29
2.3.1 Úvod
29
2.3.2 Základní profil pro INSPIRE metadata
29
2.3.3 INSPIRE metadata pro interoperabilitu
32
2.3.4 Využití metadat ve vyhledávacích službách INSPIRE
32
2.4 Vytváření a správa dat podle požadavků směrnice INSPIRE
2.4.1 Struktura a obsah datových specifikací
2.4.1.1 Jednotlivé části datových specifikací a jejich obsah
2.4.2 Co je potřeba znát pro vytvoření dat podle specifikace
33
33
33
34
2.4.2.1 UML – zápis pravidel ve formě diagramu
35
2.4.2.2 GML Application Schema – jak vypadá přepis UML do XML
36
2.4.2.3 GML – formát pro sdílení dat formou síťových služeb
36
2.4.3 Ukázka převodu z XSD do GML
36
3. GLOBÁLNÍ PROJEKTY
39
3.1 GMES
39
3.1.1 Vesmírná divize (Space division)
40
3.1.2 Divize služeb (GMES Services)
41
3.1.3 Stav a vývoj GMES v roce 2012
41
3.1.3.1 Divize služeb - služby krizového managementu (Emergency)
41
3.1.3.2 Divize služeb - služby sledování zemského povrchu (Land monitoring)
42
3.2 GEOSS
43
3.2.1 GEO
43
3.2.2 GMES a GEOSS
43
3.2.3 Součásti GEOSS
43
3.2.4 GEO Portal
44
3.2.5 Plán prací a rozvoje pro roky 2012-2015
45
3.2.6 Příklad systému GEOSS
46
3.3 Rámcové programy Evropské unie
46
3.3.1 Historie rámcových programů
46
3.3.2 Šestý rámcový program
46
3.3.2.1 ORCHESTRA
46
3.3.2.2 SANY – Sensors anywhere
47
3.3.3 Sedmý rámcový program
48
3.3.3.1 Struktura a zaměření 48
3.3.3.2 ENVIROFI
48
3.3.3.3 SUDPLAN
49
3.3.3.4 TaToo
50
3.4 Shrnutí 50
4. 3D MODELOVÁNÍ V KONTEXTU GEOINFORMAČNÍCH STANDARDŮ
51
4.1 CityGML 1.0
51
4.1.1 Vznik a vývoj
51
4.1.2 Víceúrovňová reprezentace
51
4.1.3 Geometrie a topologie
52
4.1.4 Textury a vizualizace
53
4.1.5 Sémantický model
53
4.1.6 Rozšiřitelnost sémantického modelu
55
4.1.7 Využití
56
4.2 CityGML 2.0
57
4.3 Datové specifikace INSPIRE
57
4.3.1 Téma prostorových dat Budovy (Buildings)
4.4 Webové služby pro 3D data
4.5.2 Hlukové mapování v Severním Porýní - Vesfálsku
4.5 Projekty využívající 3D geoinformační standardy
57
58
60
60
4.5.1 3D model Berlína
60
4.5.3 Výpočty energetické bilance budov 61
4.6 Shrnutí
62
5. PUBLIKACE DAT ZE SENZOROVÝCH SÍTÍ
63
5.1 Úvod
63
5.1.1 Senzory a aktuátory
64
5.1.2 Typy senzorů
64
5.1.3 Systém senzorů
66
5.2 Senzorové sítě
67
5.2.1 Způsoby přenosu dat v senzorových sítích
67
5.2.2 Výhody a nevýhody drátových a bezdrátových senzorových sítí
68
5.2.3 Typy senzorových sítí
69
5.2.4 Další služby senzorových sítí
70
5.2.5 Senzorové sítě pro aplikace v reálném čase
70
5.3 Specifika senzorových dat
71
5.3.1 Senzorové aplikace
71
5.3.2 Vyhledávání v senzorových datech
72
5.3.3 Centralizované portály
73
5.4 Middleware
5.4.1 Internet věcí, web věcí
5.5 Senzorový web
73
74
75
5.5.1 Standardy OGC SWE
76
5.5.2 Observations & Measurements
78
5.5.3 Sensor Observation Service
80
5.5.4 Služby SWE a interakce formátů
81
5.6 Závěr
82
6. KARTOGRAFICKÁ VIZUALIZACE SENZOROVÝCH DAT
83
6.1 Úvod
83
6.2 Kartografická vizualizace
83
6.2.1 Kartografická vizualizace senzorových dat
6.3 Kartografická symbolika
6.3.1 Členění a vlastnosti mapových znaků
83
84
84
6.3.1.1 Bodové mapové znaky
85
6.3.1.2 Bodové mapové znaky zobrazující více charakteristik
85
6.4 Formalizace mapového jazyka
85
6.4.1 Historický vývoj
85
6.4.2 Otevřené specifikace kartografické symboliky
86
6.5 Specifikace Symbology Encoding verze 1.1.0
87
6.5.1 Struktura SE dokumentu
87
6.5.2 Základní prvky SE dokumentu z hlediska kartografie
88
6.5.3 Symbolizéry
88
6.6 Hodnocení mapových znaků 89
6.7 Závěr
89
REFERENCE
90
SEZNAM ZKRATEK
2D
2 dimenze nebo dvojrozměrný
3D
3 dimenze nebo trojrozměrný
3DCityDB 3D City Database
3DPIE
3D Portrayal Testing Experiment
3DS
3D Studio
4D
4 dimenze nebo čtyřrozměrný
ADE
Application Domain Extension
API
Application Programming Interface
BIM
Building Information Modeling
CAFM
Computer Aided Facility Management
CDM
Common Data Model
CENIA
Česká informační agentura životního prostředí
CityGML City Geography Markup Language
COLLADACOLLAborative Design Activity
CS-W Catalogue Service for Web
CSM
Common Service Model
CSW Catalogue Service for Web
ČR
Česká republika
DTM Digital Terrein Model
E-ESDI
Environmental European Spatial Data Infrastructure
EC
European Commision – Evropská komise
EEA European Environmental Agency – Evropská agentura pro životní prostředí
EFAS
European Flood Awareness System
EGA
European GNSS Agency
EGII
European Geographic Information Infrastructure – Evropská infrastruktura geografických
informací
EIONET European Environment Information and Observation Network
EK
Evropská komise
EOS Earth Observation Systém
ES
Evropské společenství
ESA
European Space Agency – Evropská kosmická agentura
EU
Evropská unie
FAO Food and Agriculture Organization of the UN – Organizace OSN pro výživu a zemědělství
FI-PPP
Future Internet Public-Private-Partnership
FP
Framework Programme – Rámcový program
GCI
GEOSS Common Infrastructure
GCM
Generic Conceptual Model
GDI NRW Geodata Infrastructure North Rhine-Westphalia
GEOSS
Global Earth Observation System of Systems
GeoTIFF Geographic Tagged Image File Format
GII
GIS
GISC GMES
GML
GNSS
GPS
HFT
HTTP
ICT
IEEE
INSPIRE
IP
JRC
ISO
J2SE
KML
LADM
LiDAR
LMO LOD
MUTEP
NASA
NDSI NGII
NRW
O&M
OGC
PP
REST
RFID
SAR
SAS
SDI
SDIC SE
SEIS
SensorML
SensorSA
SES
SIG 3D
SIR
Geographic Information Infrastructure – Infrastruktura geografických informací
Geographic Information System
GMES in situ coordination
Global Monitoring for Environment and Security
Geography Markup Language
Global Navigation Satellite System
Global Positioning System
Hochschule fűr Technik – Technická univerzita
Hypertext Transfer Protocol
Information and Communication Technology
Institute of Electrical and Electronics Engineers
Infrastructure for Spatial Information in Europe
Internet Protocol
Joint Research Centre
International Organization for Standardization
Java 2 Platform, Standard Edition
Keyhole Markup Language
Land Administration Domain Model
Ligth Detection And Ranging nebo Laser Induced Detection And Ranging
Legally Mandated Organisation
Level of Detail – úroveň detailu
Multivariantní testovací program
National Aeronautics and Space Administration – Národní úřad pro letectví a kosmonautiku
National Spatial Data Infrastructure – Národní prostorová informační infrastruktura
National Geoinformatical Infrastructure – Národní geoinformační infrastruktura
North Rhine-Westphalia – Severní Porýní – Vestfálsko
Observations & Measurements
Open Geospatial Consortium
Prováděcí pravidla
Representational State Transfer
Radio Frequency Identification
Synthetic Aperture Radar
Sensor Alert Service
Spatial Data Infrastucture – Prostorová informační infrastruktura
Spatial Data Interest Communities
Symbology Encoding
Shared Environmental Information System
Sensor Model Language
Sensor Service Architecture
Sensor EventService
Special Interest Group 3D
Sensor Instance Registry
SLD
Styled Layer Descriptor
SMS
Short Message Service
SOA
Service-Oriented Architecture
SOAP
Simple Object Access Protocol
SOR
Sensor Observation Registry
SOS
Sensor Observation Services
SPS
Sensor Planning Service
SUDPLAN Sustainable Urban Development Planner for Climate Change Adaptation
SVG
Scalable Vector Graphics
SWE
Sensor Web Enablement
RM-OA Reference Model for the ORCHESTRA Architecture
RSS
Rich Site Summary
TaToo
Tagging Tool based on Semantic Discovery Framework
TIC
Terrain Intersection Curve
TIN
Triangulated Irregular Network
TML Transducer Model Language
TransducerMLTransducer Model Language
TU
Technische Universiät – Technická univerzita
UML
Unified Modelling Language
URI
Uniform Resource Identifier
URL
Uniform Resource Locator
USD
United States Dollar – americký dolar
VRML
Virtual Reality Modeling Language
W3C
World Wide Web Consortium
W3DS
Web 3D Service
WCS Web Coverage Service
WFS
Web Feature Service
WMS
Web Map Service
WNS
Web Notification Service
WPAN
Wireless Personal Area Network
WPS Web Processing Service
WPVS
Web Perspective View Service
WTS
Web Terrain Service
WVS
Web View Service
WWW
World Wide Web
X3D
eXtensible 3D
XLink
XML Linking Language
XML
eXtensible Markup Language
XSD
XML Schema Definition
PŘEDMLUVA
Publikace je jedním z klíčových výstupů projektu OPVK s názvem„Lidský potenciál pro informační společnost využívající prostorová data – GEOTÝM“ (CZ.1.07/2.3.00/09.0199). Shrnuje hlavní vědecké a
edukační zkušenosti jeho řešitelů a účastníků. Ústřední zadání projektu vychází z požadavků evropských
a národních dokumentů, které analyzují hlavní směry rozvoje v oblasti senzorových sítí, souvisejících tematických aplikací, možných dopadů zavedení připravované národní geoinformační infrastruktury (GII)
a legislativního rámce při její implementaci. Projekt navazuje na materiály Evropské komise související s
tvorbou geoinformačních infrastruktur (INSPIRE) a programem pro zajištění efektivního sběru, předávání a využití informací a dat o stavu životního prostředí a bezpečnosti (GMES). Zajištění obou iniciativ
je ze strany EU pouze rámcové a legislativní a pro jednotlivé země, tedy i ČR, bylo rozpracováváno až v
průběhu jejich řešení.
Kvalitní aplikace a uplatnění snah i na regionální a lokální úrovni nezbytně vyžaduje i aplikačního vzdělávání těsně spjaté s dosaženými výsledky v oblasti výzkumu a vývoje. Projekt vycházel z existujícího konceptu geoinformační infrastruktury (Konečný, 1996, 2008) a jejího dalšího rozvoje směrem k prostorově-informační společnosti. Prostorové umístění a prostorová (geografická) informace tak získává komerční
využití, je dostupná jak občanům, tak i aplikační sféře. Pro potřeby cílových uživatelských skupin je potřeba propojit a sdílet prostorová ( geografická) data mezi různými organizacemi, vytvářet technologické
platformy pro sdílení a přístup k uvedeným datům a iniciovat tvorbu služeb s nimi spojenými. Jako překážka se ukázala doposud nedostatečná spolupráce se zahraničními experty a výměna nejlepších zkušeností
se zahraničím („best practices“) v zájmu dosažení oboustranného prospěchu (tzv.win-win řešení). Právě
proto byla stěžejní částí projektu otázka rychlého předání a implementace zahraničních zkušeností ve
výzkumu, jejich porovnávání s domácími poznatky a výměna jak přednášejících, tak i stážistů na zahraničních evropských pracovištích.
Tvorba a využití GII není jenom otázkou technologickou, ale i procesu zvyšování povědomí o významu
geografických informací ve společnosti a jejich úloze v ekonomickém, ekologickém, edukačním i sociálním životě zemí a ekonomických či politických společenství. V mezinárodní odborné veřejnosti je uznávána existence první a druhé generace GII. Vznik 1. generace GII proběhl ve vyspělých zemích (USA,
Austrálie) v polovině 80. let minulého století a vedl k podpoře ekonomického rozvoje, stimulaci lepší a
kvalitnější činnosti vlád (e-government) a posílení myšlenky trvale udržitelné rozvoje. Postupný vznik
2. generace GII kolem roku 2000 vedl ke změně a aktualizaci konceptuálních modelů GII na více uživatelsky orientované, s předpoklady pro maximalizaci přidané hodnoty vytvářené z vlastnictví národních
prostorově informačních zdrojů, jež jsou také cenově efektivní, neboť působí jako mechanismy pro šíření
dat (Masser, 2007).
Druhá generace GII se mnohem více zaměřuje na usnadnění správy a řízení informačních zdrojů, namísto
přístupu k databázím a využití procesově založeného přístupu (Rajabifard et al, 2006). Pro 1. generaci
GII byla data hlavním cílem, druhá generace je naopak silně ovlivněna požadavky uživatelů na využití
dat a jejich aplikace. Výsledkem je též posílení úlohy regionálních a lokálních vlád a privátního sektoru
(Wiliamson et al, 2007).
Rozvoj GII je také posuzován z hlediska vzniku nových koncepcí rozvoje společnosti. Díky úspěšnému vybudování GII vznikla v Austrálii koncepce tzv. Spatially Enabled Society (SES) „prostorově otevřené společnosti“, která existuje v případě, že prostorová data jsou považována za běžné spotřební zboží dostupné
pro privátní i komerční aktivity. Tento fakt potom podpoří další rozvoj společnosti (Wallace et al., 2006).
V tomto případě tvoří většina společnosti uživatele prostorových dat, ať vědomě nebo nevědomě. Realizace myšlenky předpokládá splnění čtyř strategických cílů (Rajabifard, 2007) a to: vytvoření mechanismů
pro správu GII, mechanismů umožňujících sdílení dat, vytvoření příhodných, podpůrných a přístupných („enabling“) platforem a vyčlenění dostatečných kapacit. Základním předpokladem pro fungování
13
konceptu SES je existence vlády prostorově otevřené společnosti (Spatially Enabled Government), SES
může být chápán jako způsob řízení maximálně využívající procesy a koncepty prostorových dat a technologií (Bennett a Rajabifard, 2009). Správné a efektivní fungování takových vlád předpokládá splnění
tří základních předpokladů (Rajabifard 2007, Konečný 2008): 1. efektivní a transparentní zpřístupnění
informací o rozhodnutích volených zástupců jejich voličům. Tento fakt umožní efektivní zhodnocení jejich práce. 2. vytvoření prostředí relativního ekonomického blahobytu prostřednictvím rozvoje produkce
a služeb založených na prostorových informacích sbíraných na různých úrovních státní administrativy a
3. zajištění trvalé udržitelnosti pomocí pravidelného a opakovaného monitoringu širokého spektra indikátorů .
Otázky řešené v předkládané publikaci a odpovědi na ně se snaží přispět k výše uvedenému vývoji a přípravě společnosti na něj, byť se zaměřuje zejména na otázky spojené s tvorbou a využitím GII.
Prof. RNDr. Milan KONEČNÝ, CSc.
RNDr. Petr KUBÍČEK, CSc.
14
1. GLOBÁLNÍ GEOINFORMAČNÍ INFRASTRUKTURY
Milan KONEČNÝ, Petr KUBÍČEK, Miroslav KOLÁŘ
1.1 GIS a internet
Geografická data, mapy a později mapové výstupy byly jednou z významných kategorií obsahu internetu
od počátku jeho nástupu a postupného růstu v 90. letech minulého století. Ruku v ruce s rozvojem správy
geografických databází a teorie GIS se publikování a šíření geografických dat stalo důležitým předpokladem pro širší rozvoj geoinformačních aktivit v rámci sítě internet.
Hlavním rozdílem oproti samostatnému stolnímu počítači je možnost využití vícevrstevné architektury
založené na komunikaci mezi klientem a jedním čí více mapovými servery. Základní technologické principy využití kartografických výstupů v rámci sítě internet publikoval souhrnně PLEWE (1997). Obecné
schéma využití a vizualizace distribuované geografické informace si lze představit tak, že uživatel (v našem
specifickém případě geograficky lokalizovaných zdravotních dat) prostřednictvím webového prohlížeče
pošle požadavek na jeden či více webových mapových serverů, které jej zpracují a pošlou zpět výsledek v
odpovídající formě (mapa, text, datový soubor). Výsledek je následně předán ve srozumitelné formě do
webového prohlížeče, kde je zobrazen (obr. 1.1).
Obr. 1.1 Základní schéma využití a vizualizace distribuované geografické informace (upraveno podle PLEWE, 1997)
Rozvoj internetu přinesl rozšíření možností geografických dat a GIS analýz především proto, že uživatelé
již nemusí nezbytně mít databáze a programové vybavení na stolním počítači, ale mohou přímo přistupovat k distribuovaným zdrojům zdravotních data ve formě map a databází.
Nejvýznamnějšího pokroku v širokém zapojení geoinformatiky do řešení řady problémů, informování
veřejnosti a atraktivní vizualizace, přinesl GOOGLE. Zejména jeho možnosti vedou k širokému tvůrčímu
15
využívání výsledků geoinformatiky a kartografie obecnou veřejností. Ve vědecké oblasti pak umožňují
řešení komplexních problémů, v poslední době obohacených i o sociální aspekty.
1.2 Vznik geoinformačních infrastruktur
Na počátku 90. let byla velká pozornost věnována GISu jako základu pro geoinformační systémy a později
geoinformační vědu, a to zejména z hlediska technologického. Brzy se však ukázalo, že čistě technologický
přístup je třeba nahradit komplexním přístupem, který bere do úvahy ale také ostatní součásti systému,
jakými jsou datové, organizační a politické aspekty na lokální, regionální, národní a mezinárodní úrovni. Právě na tomto základě vznikl koncept „prostorových datových infrastruktur“ (Spatial Data Infrastructures), respektive geoinformačních infrastruktur (GII). GII dovolují sdílení geodat a geoinformací z
různých často geograficky velmi vzdálených zdrojů a tím umožňují uživatelům šetřit finanční i materiální
náklady, čas a úsilí při získávání nových datových sad. Zabraňují také duplikaci či dokonce multiplikaci
nákladů spojených s tvorbou a údržbou dat a integrací s dalšími datovými zdroji. Kromě role technologické, tedy hrají velmi významnou roli ekonomickou a mohou přinést významné úspory jak v rámci lidských
zdrojů, tak vynaložených či získaných finančních zdrojů.
Hlavní výhody zavedení GII souvisejí s podporou ekonomického rozvoje, efektivním fungováním státní
správy a napomáháním trvale udržitelnému rozvoji přírodního prostředí. Zavedení GII se projeví také ve
snazším přístupu k datům, a to nejenom geografickým, ale také napomůže širšímu použití geoinformací
během rozhodovacích procesů. Pozitivní ohlasy jsou patrné také v modernizaci veřejné správy a propagaci
využití geoinformací v politických, ekonomických, sociálních i osobních aktivitách.
Koncepce GII zahrnuje řadu aspektů, a proto není jednoduché ji přesně definovat. Na národní úrovni jako
jeden z prvních státu definovaly NGII USA v roce 1994 prostřednictvím nařízení prezidenta Clintona:
„Národní geoinformační infrastruktura (NGII) zahrnuje technologii, pravidla, standardy a lidské
zdroje nezbytné pro sběr, zpracování, ukládání, šíření a zlepšení využití geoinformací“ (EXECUTIVE
ORDER, 1994).
Evropská komise následně definovala Evropskou geoinformační infrastrukturu (EGII) v rámci dokumentu GI2000 s předpokladem, že půjde o:
„Evropský politický rámec vytvářející nezbytné podmínky pro dosažení cílů. Zahrnuje všechny nařízení,
regulativy, pobídky a struktury vytvořené jak na úrovni EU institucí, tak na úrovni států“ (EVROPSKÁ
KOMISE, 1995).
Dokument GI2000 představoval především politický rámec pro EGII, který definoval politické kroky,
které je potřeba podniknout k překonání existujících překážek. Mimo jiné konstatoval, že hlavní problémy pro úspěšné šíření a užití geoinformací v Evropě nejsou technického, ale především organizačního a
politického charakteru. Požadoval dále vytvoření stabilní sady dohodnutých pravidel, standardů, postupů
a pobídek pro tvorbu, sběr, výměnu a užití geoinformací a ve své podstatě přebíral hlavní cíle americké
koncepce GII.
Další definice vytyčující základní stavební kameny GII podává například MASSER (1999). Podle něj jsou
hlavními cíli snazší přístup ke geoinformacím a podpora rozvoje trhu s nimi.
Zkušenosti z 90. let prokázaly, že kromě samotné existence zdrojů a podnětů státní správy je nezbytným
předpokladem existence politického záměru vytvořit danou infrastrukturu. V té době byly definovány
také hlavní priority GII, mezi které patří (FRANK et al, 2000):
• Legislativa, pravidla a postupy nezbytné pro tvorbu, údržbu, výměnu a přístup ke geoinformacím
• Vytvoření metadatových služeb a případně datových skladů pro výměnu dat
16
• Samotná data, zejména pak data základní (referenční), na jejichž základě lze budovat služby a vytvářet odvozená data s přidanou hodnotou
• Lidé
Jak je zřejmé při porovnání jednotlivých definic GII a priorit v nich stanovených, tak mají řadu bodů společných, a to zejména v oblasti technologické a samotné správy geodat. Většina debat kolem GII na konci
20. století probíhala kolem stanovení priorit určitých činností a vytvoření legislativního rámce, který by
odrážel vztah zájmů mezi tvůrci geodat na straně jedné a uživateli na straně druhé. Snahy o vytvoření
jednotné GII na úrovni Evropy se ovšem podařilo legislativně naplnit teprve dále zmíněnou směrnicí INSPIRE.
1.3 Národní geoinformační infrastruktura
Při přípravě konference a související diskuzi o globální úrovni GII zkoumal ONSRUD (1998) v tehdejší
době existující a případně vznikající iniciativy na národní úrovni, které nazýval národní prostorové informační infrastruktury – NDSI (ONSRUD, 1998). Ve stejné době MASSER (1999) publikoval příspěvek
„První generace strategie národních geografických informací“, ve kterém popsal hlavní přístupy a současný
stav rozvoje NGII v různých zemích. Uvedené studie dokazovaly, že od počátku devadesátých let začaly
vznikat iniciativy pro budování GII na národní úrovni. Téměř všechny státy, které reagovaly na Onsrudův průzkum, daly na srozuměnou, že připravují určité iniciativy k vytvoření NGII. Obecně platilo, že
iniciativy řídí centrální vládní organizace, ačkoliv panovala obecná shoda s nutností koordinovat další
organizace, firmy a orgány veřejné správy. NGII většinou zahrnovaly geografická data v digitální formě, a
to především data topografická a data katastru nemovitostí. Zdůrazněna byla nutnost budování metadat a
datových skladů a spolupráce s privátní sférou. Souhrn počátečních aktivit na národní úrovni uvádí tab. 1.
(MASSER, 1999). Detailní popis počátků NGII v jednotlivých státech lze nalézt ve FRANK et al (2000).
Problematiku geoinformačních infrastruktur v rámci ČR akcentoval na pozadí tzv. informační dálnice
již v roce 1995 Konečný. O rok později zdůraznil nutnost rozvoje národní prostorové informační infrastruktury, jako základního předpokladu rozvoje a plného využití geografických informačních systémů
(KONEČNÝ, 1996). Na sklonku 20. století uvedl stejný autor také do českého prostředí koncept Digitální planety Země (Digital Earth), který zahrnuje datové infrastruktury od lokální až po globální úroveň
(KONEČNÝ, 1999).
Tab. 1.1 Počáteční aktivity v souvislosti s NGII v různých státech (MASSER, 1999)
17
V České republice vznikl pod vedením Josefa Hojdara a Milana Martínka na počátku 21. století koncepční dokument s názvem „Národní geoinformační infrastruktura České republiky - Program rozvoje v
letech 2001 – 2005“, který navrhoval jednotlivé kroky rozvoje GII v horizontu 5 let a v souladu s tehdy
známou evropskou koncepcí. Národní geoinformační infrastruktura byla popsána jako:
„Soubor vzájemně provázaných podmínek, které v prostředí ČR umožňují zajistit a zpřístupnit co největšímu okruhu uživatelů širokou škálu geoinformací uživatelsky vhodnou formou při plném využití potenciálu moderních (geo)informačních a komunikačních technologií“ (NEMOFORUM, 2000).
Soubor podmínek byl následně členěn do hlavních okruhů NGII:
1. existence Programu rozvoje NGII a jeho všeobecné přijetí orgány veřejné správy a profesní
samosprávy,
2. vytváření NGII ve vazbě na související evropské a světové iniciativy,
3. koordinace a spolupráce subjektů působících v oblasti geomatiky a geoinformatiky,
4. technické podmínky pro zpracovávání a zpřístupňování geodat a geoinformací,
5. organizační, legislativní, finanční a další podmínky pro dostupnost geodat a geoinformací,
6. základní datové fondy (datové báze) geodat,
7. informovanost o dostupných datových fondech geodat, jejich zdrojových místech a podmínkách
dostupnosti,
8. standardní přenosové formáty geodat a jejich souborů, standardní popis datových fondů, terminologie v oblasti geomatiky a geoinformatiky,
9. kvalifikace odborných pracovníků z oblasti geomatiky a geoinformatiky,
10.znalostní úroveň uživatelů z široké veřejnosti umožňující využití nových možností a dostupnosti
geodat a geoinformací.
Pro jednotlivé hlavní okruhy jsou dále specifikovány cíle, kterých je potřebné dosáhnout, a projekty nebo
opatření, která vedou k jejich zabezpečení. Dokument se stal prvním oficiálním vymezením hlavních
okruhů NGII a v rámci geoinformační komunity představuje jeden z „de facto“ uznávaných materiálů.
V současné době připravuje sdružení NEMOFORUM (2010) jeho aktualizace pro roky 2010 – 2015 v
závislosti na současném stavu státní informační politiky a zavádění pravidel směrnice INSPIRE (viz dále).
18
2. INFRASTRUKTURA PRO PROSTOROVÉ INFORMACE V EVROPSKÉM SPOLEČENSTVÍ (INSPIRE)
Eva MULÍČKOVÁ, Tomáš ŘEZNÍK, Radim ŠTAMPACH
Kapitola podává obecný přehled problematiky INSPIRE (kap. 2.1 a 2.2), a dále se blíže věnuje dvěma
specifickým oblastem této Směrnice - metadatům (kap. 2.3) a popisu datových sad (kap. 2.4).
Dílčí kapitoly 2.1 a 2.2 byly vytvořeny s využitím informací a dokumentů, které jsou k dispozici na stránkách Evropské komise (http://inspire.jrc.ec.europa.eu) a na stránkách Ministerstva životního prostředí
ČR(http://inspire.gov.cz), které v současnosti provozuje Česká agentura životního prostředí (CENIA)
zodpovědná za koordinaci INSPIRE v České republice. Stav informací v těchto kapitolách odpovídá říjnu
2012.
2.1 Obecný rámec INSPIRE
2.1.1 Historie
Dlouholeté snahy o vytvoření co nejpříznivějších podmínek, které by umožnily využívání geodat a geoinformací na území Evropy - zejména snaha o vytvoření tzv. Evropské geoinformační infrastruktury (EGII)
koncem 90. let - vyústily v záměr realizovat funkční infrastrukturu zpřístupňující geodata a geoinformace
z území Evropy v síti Internet (KUBÍČEK, 2010). Takto pojatá infrastruktura byla od počátku 21. století
připravována pod názvem INSPIRE (INfrastructure for SPatial InfoRmation in Europe).
V září 2001 byla v Bruselu svolána první schůzka expertní skupiny INSPIRE – v té době ještě nesla název
E-ESDI (The Environmental European Spatial Data Infrastructure). Tato expertní skupina sestávala ze
zástupců Evropské komise, EEA (European Environment Agency) a zástupců členských zemí z oblasti
geoinformatiky a životního prostředí. Účastnili se též zástupci vládních a nevládních organizací.
V prosinci 2001 byl vydán „ESDI Organisation and E-ESDI Action Plan“ (E-ESDI, 2001), který definoval
šest základních principů Evropské prostorové datové infrastruktury, čímž byly vytyčeny základní principy
INSPIRE:
1. Data by měla být sbírána a vytvářena jednou a spravována tam, kde je to nejefektivnější.
2. Mělo by být možné bezešvě kombinovat prostorová data z různých zdrojů a sdílet je mezi mnoha
uživateli a aplikacemi.
3. Informace shromažďované na jedné úrovni by mělo být možné sdílet s informacemi na jiných
úrovních; podrobné informace pro podrobné studie, obecné informace pro strategické účely
4. Geografické informace potřebné pro dobré rozhodování na všech úrovních státní správy a samosprávy by měly být hojně využívány a poskytovány za podmínek, které nebudou omezovat jejich
extenzivní využití.
5. Mělo by být snadnější vyhledávat dostupná prostorová data, vyhodnotit vhodnost jejich využití
pro daný účel a zjistit, za jakých podmínek je možné tato data použít.
6. Geografická data by měla být snadno pochopitelná, interpretovatelná a vizualizovaná v rámci
vhodného kontextu vybraného uživatelsky přívětivým způsobem.
"Směrnice Evropského parlamentu a rady 2007/2/ES o zřízení Infrastruktury pro prostorové
informace v Evropském společenství“ (dále jen Směrnice INSPIRE) vstoupila v platnost dne 15.
května 2007.
Z historického hlediska byly pro fungování směrnice vytyčeny 3 základní období (fáze), které byly v souvislosti s měnícími se ekonomicko-politickými podmínkami průběžně aktualizovány:
19
Fáze přípravná (2005 – 2006) – aktivity pro toto období byly definovány v dokumentu „INSPIRE Work
Programme Preparatory Phase 2005 – 2006“ (WP, 2004). Toto období vyžadovalo v členských státech
určité specifické aktivity. Zatímco některá nařízení/návrhy bylo možno pouze transponovat – přenést do
národního prostředí, pro jiná bylo nezbytné vytvořit tzv. Prováděcí pravidla (viz dále). Ze strany členských
zemí to vyžadovalo zejména časové a pracovní vytížení odborníků.
Fáze transpoziční (2007 – 2009) – aktivity pro toto období byly definovány v dokumentu „INSPIRE
Work Programme Transposition Phase 2007-2009“ (WP, 2007). Jakmile byla směrnice INSPIRE schválena
na úrovni Direktivy, nastalo období její transpozice do úrovně národních legislativních předpisů, které
mělo podle plánu trvat dva roky. INSPIRE vyžadovala řadu formálních kroků, včetně přijetí uvedených
pravidel podle „Comitology Procedure“ a také vytvoření výboru INSPIRE (INSPIRE Commitee). Jmenovaný výbor zajišťuje transparentní hlasování o jednotlivých částech Prováděcích pravidel. Členy výboru
jsou jednotlivé členské země EU a pravidla jsou schválena pouze v případě, že se většina členských států
vysloví kladně. Jakmile jsou Pravidla přijata, získají jeden ze statutů, a to „European Commision Decision“
nebo „European Commision Regulation“ (viz kap. 2.1.4). Přijatá pravidla je poté možno aplikovat na národní úrovni.
Fáze implementační (2009 – 2019) – po přijetí příslušných legislativních opatření nastává fáze implementace a sledování všech pravidel. Koordinace projektu je zajištěna jak na úrovni EU, tak na úrovni
národní a vzájemně propojena. Státy informují Komisi o průběhu projektu na základě přijatého časového
plánu.
2.1.2 Základní principy INSPIRE
Směrnice INSPIRE stanovuje pravidla pro zřízení infrastruktury pro prostorové informace v rámci
Evropské unie (EU). Jejím cílem je nalezení prostorových dat a služeb o životním prostředí a umožnění jejich
následného sdílení a výměny.
INSPIRE si klade za cíl zajistit koordinaci mezi uživateli a poskytovateli informací tak, aby bylo možno
kombinovat a šířit informace pocházející z různých odvětví.
Iniciativa INSPIRE se zaměřuje na politiku životního prostředí. Zahrnuje především informace potřebné
ke sledování a zlepšování stavu životního prostředí včetně ovzduší, vody, půdy a krajiny. Dotýká se však i
dalších odvětví, jako jsou např. zemědělství, doprava, energetika či krizové řízení.
Směrnice vychází z existujících datových zdrojů veřejné správy, které jsou již v členských státech vybudovány, a umožňuje, aby mohly být vzájemně propojeny jako součást infrastruktury pro prostorové informace
v rámci Evropské unie. Směrnice navrhuje koordinační mechanismus potřebný k fungování infrastruktury
na evropské úrovni.
V oblasti harmonizace upravuje aspekty potřebné k dosažení přeshraniční a mezioborové návaznosti prostorových dat. Důraz je kladen na interoperabilitu. Tou se rozumí možnost kombinace prostorových dat
a vzájemné komunikace mezi službami založenými na prostorových datech bez opakovaných ručních zásahů. Směrnice nepožaduje, aby členské státy měnily formát svých prostorových dat, ale skrze rozhraní
mohou heterogenní data převádět na jednotný model.
Prostorové informace musí být doplněny kompletními metadaty. Ta se mimo jiné týkají podmínek
přístupu a používání prostorových informací a služeb založených na prostorových datech, jejich kvality a
platnosti, a informují o tom, kdo je za ně odpovědný.
K zajištění interoperability informací jsou vypracovávána prováděcí pravidla (angl. implementing rules).
Nové prostorové informace musí být v souladu s těmito pravidly do dvou let po jejich přijetí, zatímco stávající informace do sedmi let. Prováděcí pravidla zahrnují také definici a klasifikaci geografických objektů
vztahujících se k tematickým oblastech, kterými se Směrnice INSPIRE zabývá.
20
Pro uživatele prostorových dat jsou členskými státy zpřístupněny síťové služby, které umožňují vyhledávání,
prohlížení, stahování a transformaci těchto dat. Prostorová data a služby založené na prostorových datech
jsou zpřístupněny prostřednictvím geoportálu INSPIRE, který je na úrovni Evropského společenství
(ES) spravovaný Evropskou komisí (EK), nebo prostřednictvím národních geoportálů provozovaných
jednotlivými členskými státy. Některé služby mohou být zpoplatněné.
Členské státy musí sdílet svá data a umožnit orgánům veřejné správy přístup k těmto datům, jejich výměnu
a používání za účelem plnění veřejných úkolů, které mohou mít vliv na životní prostředí.
Koordinaci infrastruktury INSPIRE na úrovni EU vykonává EK a na úrovni členských států příslušné
struktury a mechanismy určené těmito státy.
Směrnice INSPIRE se týká souborů prostorových dat, které splňují tyto podmínky:
• vztahují se k oblasti, ve které stát má nebo vykonává svrchovaná práva;
• jsou v elektronické podobě;
• jsou drženy:
■■ orgánem veřejné správy, přičemž byly orgánem veřejné správy vytvořeny nebo přijaty, nebo
jsou tímto orgánem spravovány nebo aktualizovány a spadají do oblasti jeho veřejných úkolů,
■■ třetí stranou, jíž byla síť zpřístupněna v souladu s článkem 12, nebo jejich jménem (čl. 12 ...
síť je zpřístupněna třetím stranám, jejichž soubory prostorových dat a služby založené na prostorových datech jsou v souladu s prováděcími pravidly, kterými se stanoví povinnosti, zejména
pokud jde o metadata, síťové služby a interoperabilitu);
• týkají se jednoho nebo více témat uvedených v Přílohách I, II nebo III (viz dále).
Podle Směrnice INSPIRE mají jednotlivé složky INSPIRE na starost tzv. povinné subjekty. Ty vytváří,
spravují, aktualizují a distribuují prostorová data a služby založené na prostorových datech. V České
republice se legislativní povinnosti vyplývající ze Směrnice INSPIRE (na základě novely zákona č.
123/1998 Sb. - viz dále) vztahují na tyto organizace a osoby:
• Správní úřady a jiné organizační složky státu a orgány územních samosprávných celků.
• Právnické nebo fyzické osoby, které na základě zvláštních právních předpisů vykonávají v oblasti
veřejné správy působnost vztahující se přímo nebo nepřímo k životnímu prostředí.
• Právnické osoby založené, zřízené, řízené nebo pověřené subjekty uvedenými v bodech 1 a 2, jakož i
fyzické osoby pověřené těmito subjekty, které na základě právních předpisů nebo dohody s těmito subjekty poskytují služby, které ovlivňují stav životního prostředí a jeho jednotlivých složek.
2.1.3 Stav realizace Směrnice v České Republice
Směrnice je v České Republice transponována novelou Zákona č. 123/1998 Sb., o právu na informace
o životním prostředí, která vyšla jako „Zákon č. 380/2009“, a dále „Vyhláškou č. 103/2010 Sb.“ Tato
vyhláška vstoupila v platnost 30. 4. 2010, což je také oficiální datum dokončení transpozice.
Pro přípravu novelizace zákona byla na podzim roku 2007 založena mezirezortní pracovní skupina, která
sdružovala zástupce všech ministerstev, regionálních samospráv a profesních organizací. Základem byla
spolupráce Ministerstva životního prostředí ČR, Ministerstva vnitra ČR, Českého úřadu zeměměřického a
katastrálního a České asociace pro geoinformace.
Zákonem č. 380/2009 Ministerstvo životního prostředí zřídilo Národní geoportál INSPIRE, který má
široké veřejnosti zpřístupňovat prostorová data, která se týkají alespoň jednoho z témat přílohy.
Služby na geoportálu mají umožnit uživateli vyhledávat, prohlížet, stahovat a transformovat data. Na geoportálu je také zřízena služba elektronického obchodu pro placení úhrad za data, která jsou zpoplatněna
(viz Zákon č. 380 / 2009, § 11a).
21
Zákon č. 380 / 2009 stanovuje, že kdokoliv může přistupovat k datům prostřednictvím síťových služeb.
Vyhledávací a prohlížecí služby založené na prostorových datech včetně dat jsou zpřístupňovány bezplatně. Ostatní služby (stahování dat, transformační služby, služby umožňující spouštění jiných služeb založených na prostorových datech) mohou být poskytovány za úplatu a přístup je možný na základě licenčních
smluv.
Orgány veřejné správy, státní příspěvkové organizace a organizační složky státu zřízené nebo založené
ministerstvy mají k datům, která odpovídají tématům Směrnice, přístup zdarma, pokud je používají pro
plnění úkolů majících vliv na životní prostředí.
2.1.4 Dokumenty INSPIRE
Směrnice INSPIRE obsahuje základní informace nutné pro vytvoření infrastruktury, ale legislativně závazné jsou i některé další dokumenty, které vycházejí z této směrnice. Dokumenty je z právního hlediska
možné rozdělit do čtyř základních úrovní:
1. Směrnice samotná - základní dokument s nejvyšší prioritou, který musí mít ekvivalent v zákoně
daného státu, tj. je transponován (např. slovenský Zákon č. 3/2010 Z. z. o národnej infraštruktúre
pre priestorové informácie).
2. Rozhodnutí Komise (Commission Decision) - prováděcí pravidla, která vstupují na úrovni
Evropské komise téměř okamžitě v platnost. Aby však platila v členském státě, musí být zakotvena
v národní legislativě. Zatím bylo vydáno pouze jedno, které se týká sledování a podávání zpráv
- ROZHODNUTÍ KOMISE 2009/442/ES (EU, 2009c), a v ČR bylo transponováno pomocí
Vyhlášky č. 103/2010.
3. Nařízení Komise (Commission Regulation) - prováděcí pravidla, která souvisí s technickou úrovní
infrastruktury. Nařízení Komise platí ve všech státech 20 dní po zveřejnění v Ústředním věstníku
EU.
4. Technické specifikace - tyto dokumenty obsahují detailní technický popis včetně ukázek zdrojových kódů a tvoří tak doplněk k prováděcím pravidlům ve formě Nařízení Komise. Nejsou však
legislativně závazná.
Na obrázku 2.1 je ilustrován vztah mezi jednotlivými dokumenty - prováděcími pravidly a technickými
specifikacemi. Technické specifikace jsou doporučeními, jak členské státy mohou implementovat pravidla, která jsou dána závazně Nařízeními Komise. Pokud se členské státy rozhodnou postupovat v souladu
s těmito specifikacemi, dosáhnou maximální interoperability služeb INSPIRE.
K
Obr. 2.1 Vztah mezi INSPIRE dokumenty
22
Prováděcí pravidla (PP) ve formě Rozhodnutí či Nařízení jsou přijímána pro následující oblasti:
• Metadata. Požadavky INSPIRE na metadata pro data a služby jsou zpracovány tak, aby tyto mohly
být konzistentně implementovány napříč Evropou.
■■ Pro tuto oblast bylo přijato NAŘÍZENÍ KOMISE (ES) č. 1205/2008, které se týká metadat (EU, 2008).
• Specifikace dat. Jsou vytvářeny základy pro specifikaci dat, zpracována metodologie pro její harmonizaci a přijetí pravidel k opatřením pro výměnu prostorových dat.
■■ Pro tuto oblast byla přijata NAŘÍZENÍ KOMISE (EU) č. 102/2011 (EU, 2011c) a č.
1089/2010, která se týkají interoperability sad prostorových dat a služeb prostorových dat
(EU, 2010a).
• Síťové služby. Jsou definovány provozními a neprovozními požadavky na podporu následujících
funkcionalit služeb: nahrávání (upload), stahování (download), vyhledávání, transformace, prohlížení a vyvolání.
■■ Pro tuto oblast bylo přijato NAŘÍZENÍ KOMISE (ES) č. 976/2009, které se týká síťových
služeb (EU. 2009a) a NAŘÍZENÍ KOMISE (EU) č. 1088/2010, které se týká stahování dat
a transformačních služeb (EU, 2010c).
• Sdílení dat a služeb. Je vytvořen rámec předpisů umožňujících organizacím veřejné zprávy a
evropským institucím sdílení prostorových dat a služeb za účelem splnění potřeb uživatele ve sféře
environmentálně zaměřených politik.
■■ Bylo přijato NAŘÍZENÍ KOMISE (EU) č. 268/2010, které se týká poskytnutí přístupu
k sadám prostorových dat a službám prostorových dat členských států orgánům a subjektům Společenství za harmonizovaných podmínek (EU, 2010d).
• Monitorování a podávání zpráv – vytvoření metodiky monitorování a stanovení indikátorů pro
monitoring a reporting.
■■ Bylo vydáno zatím jediné ROZHODNUTÍ KOMISE 2009/442/ES (EU, 2009c).
Prováděcí pravidla jsou přijata Komisí. Pomáhá ji při tom regulační výbor, který sestává z reprezentantů
členských států a je řízený představitelem Komise. Na poměrně komplikovaném procesu přípravy PP se
podílejí tzv. návrhové týmy (“drafting teams”), které jsou složeny z odborníků z různých zemí. Ti jsou na
své pozice navrženi SDIC (Spatial Data Interest Communities, tedy organizací/sdružením zabývajícím
se prostorovými daty) a LMO (Legally Mandated Organisation, tedy právně pověřené organizace; většinou se jedná o budoucí povinné poskytovatele) z jednotlivých států a vybráni Evropskou komisí.
2.2 Infrastruktura INSPIRE
Množinou propojených prvků infrastruktury INSPIRE jsou v oblasti prostorových dat:
• soubory prostorových dat
• metadata
• síťové služby (vyhledávací, prohlížecí, stahovací, transformační)
• sdílení (licenční politika)
• monitoring a reporting
• a další
Přístup k prostorovým datům a jejich metadatům se děje prostřednictvím služeb založených na prostorových datech (angl. spatial data services - SDS) (viz obr. 2.2). Všechny služby jsou popsány metadaty, která
umožňují lidem a softwarovým aplikacím nalézt specifickou službu v rámci infrastruktury. Soubory služeb
založených na prostorových datech, které jsou předepsány Směrnicí, jsou plně specifikovány jako síťové
služby (network services).
23
Obr. 2.2 Složky INSPIRE
2.2.1 Soubory prostorových dat
Umožnění interoperabilního přístupu k prostorovým datům je jedním z hlavních cílů Směrnice. Vzhledem k tomu, že INSPIRE zahrnuje 34 témat prostorových dat (viz obr. 2.3), bylo nezbytné vytvořit společný rámec pro zajištění interoperability mezi tématy. Tento rámec pro modelování je tvořen následujícími dokumenty:
• Generic Conceptual Model (GCM, 2012)
• Guidelines for the encoding of spatial data (GfEoSD, 211)
• Methodology for the development of data specifications (MfDoDS, 2008)
• Definition of Annex Themes and Scope, version 3.0 (DoATsS, 2008)
• Generic Network Model (GNM, 2012)
• INSPIRE Coverage Types (CT, 2012)
• INSPIRE Data Specifications – Base Models – Activity Complex (DS BM, 2012).
Tyto dokumenty usnadňovaly proces vývoje specifikací dat (ang. data specifications), které zaručují
interoperabilitu stávajících prostorových dat. Specifikace dat jsou vytvářeny pro všechna témata v
přílohách Směrnice (viz obr. 2.3). Struktuře a obsahu datových specifikací se blíže věnuje kapitola 2.4.
Testování specifikací pro data z témat Přílohy I Směrnice skončilo na jaře 2009. Výsledky testování sloužily
jako podklad pro vytvoření prováděcích pravidel, která byla Evropským parlamentem schválena dne 23.
listopadu jako Nařízení 1089/2010 (EU, 2010a).
Práce na popisu a přípravě pro testování specifikací pro témata z Příloh II a III Směrnice probíhá od začátku roku 2009. V červnu 2011 byly zveřejněny pracovní verze datových specifikací pro témata Příloh II
a III Směrnice, které bylo možné testovat a připomínkovat až do října 2011. Prováděcí pokyny k datovým
specifikacím příloh II a III jsou nyní v poslední verzi. Výsledná prováděcí pravidla by měla být legislativně
schvalována začátkem roku 2013.
Specifikace dat z témat Přílohy I Směrnice jsou k dispozici na stránkách Komise http://inspire.jrc.ec.europa.eu/index.cfm/pageid/2. Je zde možné nahlédnout i na pracovní verze specifikací ostatních dat (Příloha
II a III).
24
Obr. 2.3 Témata INSPIRE
Následující tabulka (tab. 2.1) podává přehled základních dokumentů, které souvisejí se soubory prostorových dat a časový rámec povinností, které z nich plynou.
Tab. 2.1 Přehled dokumentů a povinností souvisejících se soubory prostorových dat
Číslo
dokumentu
Vstup v
platnost
Nařízení Komise pro
interoperabilitu souborů
prostorových dat a služeb pro
témata přílohy I (EU, 2010a)
1089/2010
15.12.2010
Dodatek nařízení (EU, 2011c)
102/2011
4.2.2011
Zkrácený název dokumentu
Nařízení Komise pro
interoperabilitu a harmonizaci
souborů prostorových dat a
služeb pro témata příloh II a III
???
Povinnost
Naplnění
povinnosti
Nově sebrané nebo rozsáhle
rekonstruované soubory prostorových
dat pro témata přílohy I
4.2.2013
(23.11.2012)
K dispozici další soubory prostorových
dat pro témata přílohy I
4.2.2018
(23.11.2017)
Nově sebrané nebo rozsáhle
rekonstruované soubory prostorových
dat pro témata přílohy II a III
do 2 let od
přijetí IP
(?2015)
K dispozici další soubory prostorových
dat pro témata příloh II a III
do 7 let od
přijetí IP
(?2020)
Podle
hlasování
Evropského
parlamentu a
Rady (?2013)
25
2.2.2 Metadata
INSPIRE se zabývá nejen metadaty pro prostorová data, ale také metadaty pro služby. Prováděcí pravidla
popisují obsah a strukturu metadat pro data z témat v Přílohách I, II a III Směrnice.
Prováděcí pravidla pro metadata vstoupila v platnost 24. 12. 2008. Pro data z témat Příloh I a II musela být
metadata v souladu s těmito pravidly do dvou let. Pokud jsou data z témat přílohy III, budou muset být
metadata v souladu s pravidly do pěti let od vstoupení v platnost (viz tab. 2.2).
Na stránkách Evropského INSPIRE geoportálu je dostupný editor metadat, který lze pro jejich tvorbu
použít. Od ledna 2011 je také přístupný editor metadat na Národním geoportálu.
Podrobně se problematice metadat věnuje kapitola 2.3.
Tab. 2.2 Přehled dokumentů a povinností souvisejících s metadaty
Nařízení Komise pro metadata
(EU, 2008)
Číslo
dokumentu
Vstup v
platnost
1205/2008
24.12.2008
Povinnost
Naplnění
povinnosti
Zpřístupnění metadat k již existujícím
datům přílohy I. a II. Směrnice
24.12.2010
Zpřístupnění metadat k již existujícím
datům přílohy III. Směrnice
24.12.2013
V souvislosti s metadaty byla vydána technická specifikace INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119.
2.2.3 Síťové služby
Směrnice INSPIRE stanovuje obecná pravidla pro zřízení Infrastruktury pro prostorové informace v Evropském společenství. Členské státy mají zřídit a provozovat síť služeb určenou pro soubory prostorových
dat a služby založené na prostorových datech, pro které byla v souladu s uvedenou směrnicí vytvořena
metadata.
Jedná se o následující služby:
• Vyhledávací služba (discovery) - Služba umožňující vyhledání souborů prostorových dat a služeb
založených na prostorových datech na základě obsahu odpovídajících metadat a umožňující
zobrazení obsahu metadat.
• Prohlížecí služba (view) - Služba umožňující alespoň zobrazit, procházet, přiblížit a oddálit,
posouvat nebo překrývat zobrazitelné soubory prostorových dat a zobrazit vysvětlivky a jakýkoli
další významný obsah metadat.
• Služba stahování dat (download) - Služba umožňující stažení úplných souborů prostorových dat
nebo jejich částí a tam, kde je to prakticky možné, přímý přístup k nim.
• Transformační služba (transformation) - Služba, která umožňuje, aby soubory prostorových dat
byly transformovány za účelem dosažení interoperability.
• Vyvolání služby založené na prostorových datech (invoke) - Služba, která umožňuje definovat
jak vstupní, tak výstupní data očekávaná službou založenou na prostorových datech, stejně jako
pracovní tok či řetězec služeb kombinující více služeb. Umožňuje také definovat externí rozhraní
webové služby pro pracovní tok či řetězec služeb.
Prováděcí pravidla pro síťové služby zahrnují pravidla pro vyhledávání, prohlížení, stahování a transformaci dat. Pro jednotlivé typy služeb jsou vytvářena a schvalována postupně (viz tab. 2.3).
Prováděcí pravidla pro vyhledávací a prohlížecí služby vstoupila v platnost v listopadu 2009 jako Nařízení
26
976/2009 (EU, 2009a). Prováděcí pravidla pro stahovací a transformační služby byla schválena Evropským parlamentem jako Nařízení 1088/2010, kterým se doplňuje Nařízení 976/2009 o stahovací a transformační službě (EU, 2010c).
Spuštění služeb do provozu je rozděleno do dvou fází. V první budou služby spuštěny pouze s počáteční
funkcionalitou, kdy ještě nemusí splňovat všechny parametry uvedené v Nařízení.
Vyhledávací a prohlížecí služby s počáteční funkcionalitou musely být spuštěny do osmnácti měsíců od
vstupu Nařízení v platnost, tedy do 9. května 2011 a do 28. června 2012 pak stahovací a transformační
služby.
Do dvou let od vstupu Nařízení v platnost, tedy do 9. listopadu 2011 pro vyhledávací a prohlížecí služby a
do 28. prosince 2012 pro stahovací a transformační služby, budou obě muset splňovat všechny požadavky
stanovené v Nařízení.
Tab. 2.3 Přehled dokumentů a povinností souvisejících se síťovými službami
Nařízení pro síťové služby (EU,
2009a) - Vyhledávací a prohlížecí
služby
Nařízení pro stahovací a
transformační služby (EU, 2010c)
Nařízení pro služby umožňující
spouštění služeb
Číslo
dokumentu
Vstup v
platnost
976/2009
9.11.2009
1088/2010
???
Povinnost
Naplnění
povinnosti
Počáteční funkčnost vyhledávacích a
prohlížecích služeb
9.5.2011
Plně funkční vyhledávací a prohlížecí
služby v souladu s Nařízením
9.11.2011
Počáteční funkčnost stahovacích a
transformačních služeb
28.6.2012
Plně funkční stahovací a
transformační služby
28.12.2012
Plně funkční služby umožňující
spouštění služeb
do 2 let od
přijetí IP
(? 2015)
28.12.2010
Podle
hlasování
Evropského
parlamentu a
Rady (? 2012)
V souvislosti se síťovými službami byly vydány následující technické specifikace, které doplňují výše zmíněná Nařízení:
• pro stahovací služby: Technical Guidance for the implementation of INSPIRE Download Services
(TG, 2012)
• pro vyhledávací služby: Technical Guidance for the implementation of INSPIRE Discovery Services
(TG, 2011a)
• pro prohlížecí služby: Technical Guidance for the implementation of INSPIRE View Services (TG,
2011b)
• pro transformaci schématu: Technical Guidance for the INSPIRE Schema Transformation Network
Service (TG, 2010a)
• pro transformaci souřadnic (pracovní verze): Draft Technical Guidance for INSPIRE Coordinate
Transformation Services (TG, 2010b)
27
2.2.4 Sdílení dat
Sdílení prostorových dat podle INSPIRE upravuje Nařízení Komise EU 268/2010, pokud jde o poskytnutí přístupu k sadám prostorových dat a službám prostorových dat členských států orgánům a subjektům
Společenství za harmonizovaných podmínek (zkráceně Nařízení o sdílení dat) (EU, 2010d) a prováděcí
pokyny, které vyšly jako dokument Guidance on the 'Regulation on access to spatial data sets and services of
the Member States by Community institutions and bodies under harmonised conditions' (GR, 2010).
Nařízení určuje jak přístup Evropských orgánů k prostorovým datům a službám úřadů jednotlivých členských států, tak i pravidla používání. Součástí Pokynů vydaných k nařízení jsou modely licencí (základní
licence, specifická licence a rámcová dohoda) a příklady dobré praxe sdílení dat, které umožní snazší implementaci Nařízení.
Tab. 2.4 Přehled dokumentů a povinností souvisejících se sdílením dat
Nařízení Komise o sdílení dat
(EU, 2010d)
Číslo
dokumentu
268/2010
Vstup v
platnost
Povinnost
Naplnění
povinnosti
19.4.2010
Pro nově vytvořené dohody
19.10.2011
Pro již existující dohody
19.4.2013
2.2.5 Monitoring a reporting
Monitoring a reporting pokrývá čtyři hlavní oblasti INSPIRE: metadata, soubory prostorových dat a
služeb založených na prostorových datech, síťové služby a sdílení dat. Monitoring sleduje kvantitativní
ukazatele a probíhá každý rok, zatímco reporting se zabývá kvalitativními aspekty a probíhá každé tři roky.
Základní principy monitoringu a reportingu jsou specifikovány v článku 21 Směrnice. Prováděcí pravidla
pro monitoring a reporting vstoupila v platnost dne 5. června 2009 jako Rozhodnutí Komise 2009/442/ES
(EU, 2009c). Protože Rozhodnutí komise je nutné transponovat do národní legislativy, stal se monitoring
a reporting součástí Vyhlášky 103/2010 Sb. První zprávu (report) musely členské země zaslat do 15. května
2010 (viz tab. 2.5).
V rámci monitoringu sledujícího kvantitativní ukazatele poskytují členské země seznam souborů prostorových dat a služeb založených na prostorových datech. Tento seznam zahrnuje jak data a služby, které
jsou již v souladu s prováděcími pravidly, tak i ty, které ještě v souladu nejsou. Sleduje se např. existence
metadat, jejich soulad s prováděcími pravidly pro metadata, geografické pokrytí soubory prostorových
dat, soulad s datovými specifikacemi apod.
Reporting sleduje kvalitativní stránku. Členské státy musí poskytnout informace o koordinaci a zajištění
kvality, fungování a koordinaci infrastruktury, sdílení dat a analyzovat náklady a přínosy.
Výsledky monitoringu a reportingu jsou veřejně přístupné na webových stránkách Komise.
Tab. 2.5 Přehled dokumentů a povinností souvisejících s monitoringem a reportingem
Rozhodnutí Komise pro
monitoring a reporting (EU,
2009c)
28
Číslo
dokumentu
2009/442/ES
Vstup v
platnost
Povinnost
Naplnění
povinnosti
Ukazatele o využívání infrastruktury
budou reportovány až v době, kdy budou
relevantní. Tedy v době, kdy budou
dostupné všechny dokumenty a budou
spuštěny služby.
15.5.2010
a každé tři
roky
5.6.2009
2.3 Vytváření a správa metadat podle požadavků směrnice INSPIRE
2.3.1 Úvod
Směrnice Evropského parlamentu a Rady 2007/2/ES ze dne 14. března 2007 o zřízení Infrastruktury pro
prostorové informace v Evropském společenství (dále jen směrnice INSPIRE) byla vytvořena především
pro vyhledávání prostorových dat a služeb. I v samotném textu této směrnice se proto objevuje důraz na
popis prostorových dat a webových služeb publikujících prostorová data. Tento popis se pak v odborné
geoinformační terminologii nazývá metadata. Metadata fungují jako „živá voda“ celé infrastruktury prostorových dat s tím, že těžiště jejich využití spočívá ve vyhledávacích službách.
Směrnice INSPIRE navazuje na předchozí evropskou legislativu, zejména na Směrnici Evropského parlamentu a Rady 2003/98/ES ze dne 17. listopadu 2003 o opakovaném použití informací veřejného sektoru
(dále jen směrnice PSI). Směrnice PSI uvádí, že pro vývoj informační a znalostní společnosti je nutné
vytvořit obecný rámec podmínek opakovaného použití dokumentů, které již jednou byly vytvořeny veřejným sektorem, jinými slovy byly zaplaceny z veřejných zdrojů (státního rozpočtu, dotačních titulů Evropské unie apod.). Aby bylo možné využívat již dříve vytvořený dokument veřejného sektoru, je nutné
o takovém dokumentu vědět. Nemožnost vyhledat si obdobné dokumenty, tj. v geoinformačním pojetí
nemožnost vyhledat si určitá data a služby, se stali hlavní bariérou pro využití směrnice PSI v reálné praxi.
Také z tohoto důvodu směrnice INSPIRE si klade za hlavní cíl vytvoření takových mechanismů, které
povedou k nalezení existujících prostorových dat a služeb. Na základě výsledků vyhledávání je pak možné
využívat již existující data a služby místo vytváření nových – duplicitních – dat a služeb. Pro realizaci
těchto mechanismů jsou nezbytná metadata k prostorovým datům (datovým sadám, resp. sériím datových
sad) a k webovým službám.
Pro naplnění výše uvedeného konkretizuje směrnice INSPIRE požadavky na metadata ve dvou úrovních
(viz také obr. 2.4):
• zhodnocení – na této úrovni jsou popsána prostorová data a služby pro účely vyhledávání, tj.
jejich užití ve vyhledávacích službách odpovídajících implementační specifikaci Open Geospatial
Consortium (OGC) nazvané Catalogue Service for Web (CSW; OGC, 2007a).
• využití – tato úroveň navazuje na úroveň zhodnocení, zpřístupňuje celý dostupný popis prostorových dat nebo služby, tento popis slouží jako detailní informace při užití prostorových dat či služby
na expertní úrovni.
2.3.2 Základní profil pro INSPIRE metadata
Samotná směrnice INSPIRE definuje strukturu metadat o prostorových datech a službách na obecné
úrovni. Explicitně jsou ve směrnici INSPIRE uvedeny následující komponenty metadat:
1. soulad souborů prostorových dat s prováděcími pravidly pro interoperabilitu1 ;
2. podmínky pro přístup k souborům prostorových dat a službám založeným na prostorových datech, jejich používání a popřípadě odpovídajíc poplatky;
3. kvalita a platnost souborů prostorových dat;
4. orgány veřejné správy, které jsou pověřeny vytvářením, řízením, aktualizací a distribucí souborů
prostorových dat a služeb založených na prostorových datech;
5. omezení přístupu veřejnosti a důvody takového omezení.
1
dále uvedenými jako Nařízení komise o interoperabilitě
29
Obr. 2.4. Kategorie a povinnost metadat podle směrnice INSPIRE (zpracováno podle DT METADATA, 2007)
Komponenty metadat uvedené ve směrnici INSPIRE rozvádí do konkrétních prvků metadat Nařízení
Komise (ES) č. 1205/2008 ze dne 3. prosince 2008, kterým se provádí směrnice Evropského parlamentu
a Rady 2007/2/ES týkající se metadat (dále jen Nařízení komise o metadatech). Prvky metadat jsou uvedeny v tab. 2.6 (na následující straně) s rozdělením požadavků na metadata prostorových dat a metadata
ke službám.
Z tab. 2.6 je patrné, že základní profil pro INSPIRE metadata zahrnuje 21 metadatových prvků na obecné
úrovni. Tyto metadatové prvky slouží pro zhodnocení prostorových dat nebo služby při jejich získání ve
vyhledávacích službách. Těchto 21 metadatových prvků na obecné úrovni je dále rozvedeno v technických návodech pro INSPIRE metadata , které rozvádějí problematiku metadat na implementační úrovni
včetně zápisu do jazyka XML (eXtensible Markup Language). Technické návody pro INSPIRE metadata1
vycházejí z norem ISO 19115:2003 Geografická informace – Metadata a ISO 19119:2005 Geografická
informace – Služby. Koncept INSPIRE metadat a koncept metadat podle ISO jsou si podobné s tím,
že INSPIRE metadata tvoří podmnožinu ISO metadat. Na implementační úrovni nedochází k žádným
změnám oproti ISO konceptu, protože se jednotně využívá ISO 19139:2007 Geografická informace –
Metadata – XML schéma implementace. Jinými slovy řečeno, INSPIRE i ISO koncepty užívají identické
elementy v jazyce XML. To zajišťuje přímou převoditelnost metadat v obou konceptech na implementační úrovni.
1 INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119 (Version
1.2) 30
Tab. 2.6 Metadata souborů prostorových dat, sérií prostorových dat a služeb založených na prostorových datech podle požadavků Nařízení komise o metadatech.
Reference
Prvek metadat
Násobnost
Podmínka
1.1
Název zdroje (Resource title)
1
1.2
Abstrakt zdroje (Resource
abstract)
1
1.3
Typ zdroje (Resource type)
1
1.4
Lokátor zdroje (Resource
locator)
1.5
Jednotný identifikátor zdroje
(Unique resource identifier)
1..*
neaplikovatelné pro služby
1.6
Vázaný zdroj (Coupled resource)
0..*
neaplikovatelné pro data
Povinný, jestliže jsou k dispozici soubory
dat, na nichž je služba provozována.
1.7
Jazyk zdroje (Resource
language)
0..*
Povinný, pokud zdroj zahrnuje textové
informace.
2.1
Tematická kategorie (Topic
category)
1..*
2.2
Typ služby založené na
prostorových datech (Spatial
data service type)
1
neaplikovatelné pro data
0..*
3
Klíčové slovo (Keyword)
4.1
Geografické ohraničení
(Geographic bounding box)
1..* (data)
0..* (služby)
5.
Časová reference (Temporal
reference)
1..*
6.1
Původ (Lineage)
1..*
Povinné u služeb s explicitně vyjádřeným
geografickým rozsahem.
1
Prostorové rozlišení (Spatial
resolution)
0..*
7
Soulad (Conformity)
1.*
8.1
Podmínky přístupu a použití
(Conditions applying to access
and use)
1..*
8.2
Omezení veřejného přístupu
(Limitations on public access)
1..*
9
Odpovědná organizace
(Responsible party)
1..*
10.1
Kontaktní místo metadat
(Metadata point of contact)
1..*
10.2
Datum metadat (Metadata date)
1
10.3
Jazyk metadat (Metadata
language)
1
6.2
Povinný, pokud je k dispozici adresa URL
pro získání dalších informací o zdroji a/
nebo pro přístup k souvisejícím službám.
Povinný, pokud je k dispozici odkaz na
službu.
Povinné u datových souborů a sérií
datových souborů, jestliže lze stanovit
odpovídající měřítko nebo hodnotu
rozlišení.
Povinné v případech, kdy existuje
omezení prostorového rozlišení dotyčné
služby.
31
2.3.3 INSPIRE metadata pro interoperabilitu
Jak bylo uvedeno výše, základní profil pro INSPIRE metadata slouží především pro vyhledání prostorových dat a služeb a k jejich základnímu zhodnocení. Na tento základní profil pak navazují INSPIRE
metadata pro interoperabilitu, která se nacházejí v Nařízení komise č. 1089/2010 ze dne 23. listopadu
2010, kterým se provádí směrnice Evropského parlamentu a Rady 2007/2/ES, pokud jde o interoperabilitu sad prostorových dat a služeb prostorových dat (dále jen Nařízení komise o interoperabilitě). Rozšíření
základního profilu pro INSPIRE metadata podle Nařízení komise o interoperabilitě umožňuje využití
dalších popisných informací k prostorovým datům. V této souvislosti je důležité podotknout, že rozšíření
základního profilu je aplikovatelné pouze na prostorová data, tj. nelze jej vztáhnout na metadata služeb.
Rozšíření základního profilu pro INSPIRE metadata čítalo v době psaní této kapitoly, tj. k 31. 10. 2012,
pět dalších metadatových prvků (viz tab. 2.7). Kromě těchto pěti metadatových prvků společných pro
všech 34 témat prostorových dat INSPIRE existují další metadatové prvky, které představují rozšíření
specifická vždy pro jedno konkrétní téma prostorových dat INSPIRE. Sumárně tak metadata vytvářená
a udržovaná poskytovatelem dat mohou obsahovat 21 metadatových prvků základního profilu, dalších 5
prvků metadat pro interoperabilitu, například 7 dalších metadatových prvků specifických pro konkrétní
INSPIRE téma (například dopravní sítě) a k tomu ještě poskytovatel dat může přidat takřka libovolný
počet dalších metadatových prvků odpovídajících jeho aplikacím.
Tab. 2.7 Rozšíření základního profilu pro INSPIRE metadata podle Nařízení komise o interoperabilitě; legislativně označováno též jako „Metadata nezbytná pro interoperabilitu“.
Prvek metadat
Souřadnicový referenční systém
(Coordinate reference system)
Násobnost
Podmínka
1
Tento prvek je povinný, pouze pokud sada
prostorových dat obsahuje časové informace,
které se nevztahují na výchozí časový referenční
systém.
Časový referenční systém (Temporal
reference system)
0..*
Kódování (Encoding)
1..*
Topologická správnost (Topological
consistency)
0..*
Tento prvek je povinný, pouze pokud datová
sada obsahuje typy z obecného síťového modelu
(Generic Network Model) a nezajišťuje topologii
osy (propojení os) pro síť.
Kódování znaků (Character encoding)
0..*
Tento prvek je povinný, pouze když se používá
kódování, které není založeno na UTF-8.
2.3.4 Využití metadat ve vyhledávacích službách INSPIRE
Vyhledávací služby INSPIRE jsou logickou nadstavbou konceptu INSPIRE metadat. Jak bylo uvedeno
výše, vyhledávací služby INSPIRE jsou založeny na katalogové službě OGC podle implementační specifikace Catalogue Service for Web (OGC, 2007a). INSPIRE kompatibilní (vyhledávací) služba je zároveň OGC kompatibilní (vyhledávací) službou. Obrácená provázanost neplatí – tj. OGC kompatibilní
služba není automaticky kompatibilní z pohledu INSPIRE. Nařízení Komise o síťových službách se v
části pro vyhledávací služby dělí do tří základních částí. První (úvodní) odkazuje na existující standardy,
popisuje objektivní důvody pro vytvoření infrastruktury vyhledávacích služeb, vysvětluje užité zkratky
apod. Druhá (pouze dvoustránková) část se věnuje citaci preambule a článků 11 a 12 Směrnice 2007/02/
ES – tj. částí vztahujících se ke konceptu vyhledávací služby. Poslední, nejrozsáhlejší, pasáž se věnuje vlastnímu popisu funkcionality a náležitostem vyhledávací služby, kromě toho je v úvodu zmíněna i analýza
stávajících řešení.
Stejně jako u dalších síťových služeb i vyhledávací služby INSPIRE mají jako základní operaci Získat metadata vyhledávací služby (v OGC pojetí GetCapabilities; pro základní informace, tj. metadata, o této
službě – jako např. kdo je jejím vlastníkem, jaká data je možné stáhnout, za jakých – nejen obchodních
32
– podmínek, kde je odkaz na ceník apod.). Navazující operací je Vyhledat metadata (podle OGC GetRecords). Tato operace umožňuje nad metadaty kombinovat logické, matematické a prostorové operátory
a zodpovědět tak otázku, resp. nalézt odpovídající data na dotaz např. „Hledám prostorová data s panevropskou železniční sítí v měřítku větším než 1 : 50 000 pokrývající území Jihomoravského kraje, která
byla aktualizována po roce 2005.“ Vyhledávání probíhá nad metadaty, která jsou obsažena ve vyhledávací
službě (tj. metadatovém katalogu). Výsledky vyhledávací služby jsou opět metadata obsahující mj. odkaz
na prohlížecí službu, službu stahování dat a e-shop (v případě zpoplatněných dat). Další operací je Zveřejnit metadata, která odpovídá OGC operacím harvest a transaction a slouží pro přenos metadat mezi
jednotlivými servery s vyhledávacími službami.
Pro vyhledávací služby platí následující kritéria zajišťující minimální nefunkční požadavky:
• Výkon (odezva pod 3 vteřiny na straně serveru pro 250 záznamů vyhledávací služby)
• Dostupnost (99% času)
• Kapacita (30 současných dotazů na vyhledávací službu)
2.4 Vytváření a správa dat podle požadavků směrnice INSPIRE
Datové specifikace jsou velmi důležitou součástí INSPIRE. Zahrnují pravidla, která říkají, jakým způsobem se mají data poskytovat, aby byla v souladu s požadavky směrnice. Datové specifikace pokrývají všech
34 témat ze tří příloh směrnice.
2.4.1 Struktura a obsah datových specifikací
Všechny datové specifikace mají jednotnou strukturu.
2.4.1.1 Jednotlivé části datových specifikací a jejich obsah
Některé části (např. 1, 3, 4) jsou velmi krátké, jiné (např. 5, 8) jsou velmi rozsáhlé a pro tvorbu dat zcela
zásadní. Rozsah jednotlivých částí se také velmi liší u datových specifikací různých témat.
General Executive Summary – všeobecný úvod o INSPIRE
Theme-specific Executive Summary – souhrn celé datové specifikace
1. Scope – zařazení datové specifikace do přílohy
2. Overview – souhrn teorie tématu dané specifikace, vysvětlení pojmů
3. Specification scopes – vztah k jiným specifikacím
4. Identification information – identifikační údaje
5. Data content and structure – nejdůležitější část celé specifikace. Je zde popis struktury dat vytvořených podle datové specifikace. Tato kapitola obsahuje UML schéma (viz dále) a popis a vysvětlení
jednotlivých elementů a jejich vzájemných vztahů, které mají být obsaženy v poskytovaných datech.
6. Reference Systems – popis souřadných systémů a kalendáře, které mají být použity
7. Data Quality – popis toho, jak by měla být měřena kvalita poskytovaných dat – kompletnost, topologická správnost apod.
8. Metadata – vysvětlení metadatového popisu poskytované datové sady
9. Delivery – zde je určeno v jakém formátu a jakým způsobem dodat vytvořená data uživateli
10.Data Capture – informace pořizování dat o jeho parametrech
11.Portrayal – popis, jak data zobrazovat v prohlížecích službách INSPIRE
33
Annexes – přílohy. Součástí specifikace jsou další přiložené texty, jejich rozsah se u jednotlivých specifikací liší. Z hlediska tvorby dat jsou nejdůležitějšími přílohami Annex A a Annex B. Annex A - Abstract
Test Suite - by měl v budoucnu obsahovat informace o testování vytvořených datových sad, zda splňují
požadavky směrnice INSPIRE. Annex B - Use cases - popisuje praktické ukázkové příklady.
2.4.1.2 Další potřebné podkladové dokumenty
Kromě samotné specifikace je nutno brát při přípravě dat v úvahu i další dokumenty. Např. Generic Conceptual Model (GCM, 2012) obsahuje specifické stereotypy INSPIRE (napříč jednotlivými tématy prostorových dat). Ke specifikaci také náleží GML Application Schema – dokument ve formátu XSD. Je to
šablona určující strukturu GML souboru, ve kterém se budou data dané specifikace poskytovat uživatelům. Není přímo součástí datové specifikace, je poskytován ke stažení odděleně, ale se specifikací úzce
souvisí.
2.4.2 Co je potřeba znát pro vytvoření dat podle specifikace
Tato kapitola popisuje, jak postupovat při tvorbě dat odpovídající datové specifikaci. Je potřeba znát několik technologií: UML (Unified Model Language) – jazyk pro datové modelování, XSD (XML Schema
Definition) – jazyk pro vytváření šablon souborů XML a GML (Geography Markup Language) – jazyk
z rodiny XML pro zápis a přenos dat s prostorovou složkou.
Obr. 2.5 UML diagram datové specifikace tématu Půdy (převzato z DS SOIL, 2011, s. 16). Vlevo nahoře vyznačen výsek na
obr. 2.6
34
2.4.2.1 UML – zápis pravidel ve formě diagramu
V jazyce UML je vytvořeno schéma, které je umístěno v kapitole 5.2 všech datových specifikací. Je zde
vyznačeno, co je obsahem poskytovaných dat, jaké atributy mohou nabývat jakých hodnot apod. Spolu s
popisem dat v kapitole 5 jde o komplexní popis dat. Schéma UML bývá v některých specifikacích velmi
složité a kompletní vysvětlení jazyka UML je nad rámec této kapitoly. Na obr. 2.5 na předchozí stránce je
coby příklad znázorněno schéma z datové specifikace Půdy (DS SOIL, 2011, s. 16).
Na obr. 2.6 je malý výsek UML, který poslouží jako příklad. UML je tvořeno dvěma hlavními součástmi –
třídami s jejich obsahem (obdélníky) a asociacemi (čarami). Výsek obsahuje dvě třídy. Významy obou najdeme definovány v kap. 5.2 datové specifikace tématu půd. SoilPlot symbolizuje „místo s půdou“ - např.
určitou půdní sondu a SoilSample je půdní vzorek.
Oba elementy obsahuje povinně jednoznačný identifikátor pod názvem inspireID. Jiné atributy se už ale
u obou tříd liší. Zatímco půdní sonda obsahuje údaj o poloze (soilPlotLocation), třída půdní vzorek požaduje např. atribut sampledProperty informující o zkoumané vlastnosti. Tento atribut má navíc pomocí
údaje [1..*] vyznačeno, že může nabývat i více než jedné hodnoty (ovšem min. alespoň jedné), pokud je z
daného půdního vzorku zkoumáno více vlastností.
Podobně lze číst údaje o vzájemných vztazích mezi třídami. Oboustranná šipka symbolizuje, že vazba je
oboustranná. U třídy SoilPlot je vedle šipky napsáno isTakenFrom a číslo 1, u třídy SoilSample pak isSampledBy a číslo 0..*. To lze číst tak, že každý půdní vzorek byl získán právě z jediné půdní sondy, zatímco
každá sonda může být zastoupena žádným ale i neomezeně velkým počtem vzorků.
Obr. 2.6 Výsek z UML diagramu Půdy (převzato z DS SOIL, 2011, s. 16)
35
2.4.2.2 GML Application Schema – jak vypadá přepis UML do XML
Už bylo řečeno, že GML Application Schema (GML aplikační schéma) není součástí datové specifikace,
ale pro tvorbu dat je naprosto nezbytné. Je zmíněno v kapitole 9.2 datové specifikace. Jde o jazyk z rodiny
XML, který slouží pro tvorbu šablon a schémat pro tvorbu a kontrolu jiných XML souborů – např. geografických dat uložených v jazyce GML.
Jde o soubor s koncovkou XSD obsahující přepis pravidel z UML diagramu do textového formátu. Slouží
jako šablona při tvorbě dat, ale také jako kontrolní šablona pro ověření správnosti dat vytvořených podle
specifikace. Specifikace půd má např. GML Application Schema s názvem soilCore.xsd. Jelikož soubor
obsahuje mnoho pravidel obsažených v často komplikovaných UML diagramech, jde o velmi dlouhé a
složité dokumenty.
2.4.2.3 GML – formát pro sdílení dat formou síťových služeb
Geography Markup Language je jazyk z rodiny XML. Slouží pro modelování, transport a ukládání geografických informací. V kap. 9. Delivery datové specifikace je právě tento formát určen jako ten, ve kterém
se budou dodávat data pomocí stahovací služby k uživatelům. Pro INSPIRE byla zvolena verze – 3.2.1.
Výhodou GML je, že ho za standard prohlásily jak organizace Open Geospatial Consortium (OGC),
tak International Organization for Standardization (ISO). Jde tudíž o standard známý a rozšířený. Nevýhodou jsou naopak velké soubory, které vznikají při kódování dat v GML, důvodem je komplikovanost
tohoto jazyka.
2.4.3 Ukázka převodu z XSD do GML
Tato kapitola se pokusí vysvětlit, jak na základě pravidel ze šablony v GML Application Schematu vytvořit
dokument s daty zakódovaný v GML. Za příklad bude použit krátký výsek GML Application Schematu
půd. V dokumentu XSD jsou kromě jiných definována následující pravidla: jednotlivé typy elementů,
jejich obsah (např. další elementy), vzájemné pořadí elementů, max. a min. počet jednotlivých elementů
atd. Význam elementů je definován v datové specifikaci – kap. 5.2.
Ukázka ukazuje převod elementu ChemicalParametersType definovaného v XSD do GML. XSD definuje, že element ChemicalParametersType má dva podelementy – baseSaturation a cationExchangeCapacity. V kap. 5.2 se lze dočíst, že první atribut je nasycení bazickými ionty, zatímco druhý je výměnná kapacita
měřená v cmol/100g. Oba podelementy mají atribut nillable=true, což znamená, že mohou nabývat hodnotu null – hodnota nemusí být vyplněna. V takovém případě je ale připraven atribut nillReason, kam by
se měl uvést důvod proč je hodnota nevyplněna – zda je např. neznámá.
<element name="ChemicalParametersType" type="so:ChemicalParametersTypeType">
<complexType name="ChemicalParametersTypeType">
<sequence>
<element name="baseSaturation" nillable="true">
<complexType>
<extension base="gml:MeasureType">
<attribute name="nilReason" type="gml:NilReasonType"/>
</extension>
</complexType>
</element>
<element name="cationExchangeCapacity" nillable="true">
<complexType>
<extension base="gml:MeasureType">
<attribute name="nilReason" type="gml:NilReasonType"/>
</extension>
</complexType>
</element>
</sequence>
</complexType>
36
Následuje ukázka vyplněných dat ve formátu GML, které odpovídají dané šabloně GML Application
Schema. Vyplněn je jen atribut cationExchangeCapacity, jehož hodnota je 24 cmol/100g. Hodnota druhého atributu je označena za neznámou. Je vidět, že z mnohařádkové šablony GML Application Schema
vzniklo jen pár řádků kódu GML. Závěrem lze proto prohlásit, že bez ohledu na to, jak dlouhé a složité se
zdají být šablony jednotlivých témat, výsledná data pro stahovací službu jsou poměrně přehledná.
<ChemicalParametersType>
<baseSaturation nilReason="unknown"></baseSaturation>
<cationExchangeCapacityuom="cmol(+)/100g">24</cationExchangeCapacity>
</ChemicalParametersType>
37
38
3. GLOBÁLNÍ PROJEKTY
Radim ŠTAMPACH, Zbyněk ŠTĚRBA
V současné době probíhá příprava nebo realizace řady významných mezinárodních projektů týkajících se
geoprostorových dat. Některé jsou řešeny na celosvětové, jiné na regionální a lokální úrovni. Ty významnější jsou zaštiťovány vládami a řízené zákony, jiné jsou iniciativami přicházejícími „zdola“ od samotných
uživatelů a správců geoprostorových dat nebo mezinárodních vědeckých organizací. V kapitole nejsou
popsány všechny existující projekty, ale její autoři upozorňují na ty nejvýznamnější, které se dotýkají i ČR
a podstatně ovlivní podmínky rozvoje geoinformatiky u nás i v zemích Evropské unie v blízké budoucnosti. Patří k nim zejména směrnice INSPIRE, o které pojednává předchozí kapitola. Další velkou evropskou
iniciativou je GMES. Díky němu hraje EU významnou roli také v mezinárodním projektu GEOSS. V
druhé polovině kapitoly jsou popsány projekty evropských rámcových programů, které jsou významné
svou velikostí nebo dosaženými výsledky, a které by měly v příštích letech určovat další směr vývoje v oblasti využívání geoprostorových dat.
3.1 GMES
GMES je zkratkou názvu Global Monitoring for Environment and Security. Jde o program pro vytvoření
evropských kapacit pro pozorování Země a to zejména za účelem poskytování informací pro správu životního prostředí a bezpečnosti. GMES bylo založeno nařízením EU č. 911/2010 (EU, 2010b). Je součástí
Evropské vesmírné politiky (EU, 2011a, s. 2). V současné době probíhá tzv. přípravná fáze (2011-2013),
po které by měla následovat fáze operační (EU, 2011a, s. 2).
Celé GMES je podle GMES CZ (2012) a GMES EU (2012) řízeno Evropskou komisí, konkrétně DG
Podnikání a průmysl (DG Enterprise and Industry). V dokumentech EU (2011a, s. 6) se předpokládá
účast na koordinaci i ze strany European GNSS Agency (EGA), která řídí projekt evropského navigačního
systému Galileo.
Celá iniciativa se skládá z několika složek (Obr. 3.1):
1. vesmírná divize (space division) je řízena Evropskou kosmickou agenturou (dále ESA). Důležitou
roli zde hraje i Evropská organizace pro využívání meteorologických satelitů (dále EUMETSAT).
Nejdůležitější složkou této divize jsou satelity pro sledování Země, zvané „Sentinels“. Družice budou majetkem ESA a EUMETSAT, ale data budou poskytována pro potřeby Evropské komise
zdarma.
2. „pozemní“ divize (in situ division) je řízena Evropskou agenturou pro životní prostředí (dále
EEA). Český název je v uvozovkách, neboť je poněkud závádějící. Divize totiž kromě různých pozemních senzorů zahrnuje také senzory umístěné na letadlech, balónech, mořských bójích apod.
Podle (EEA, 2012) jde o různé typy senzorů, které jsou spravovány různými organizacemi. Hlavním cílem EEA tedy není budovat nové sítě senzorů, ale koordinovat přenos dat od vlastníků
senzorů a jejich využití pro divizi služeb. Zajištění dostupnosti dat z této složky GMES je náplní
projektu „GMES in situ coordination“ (GISC).
3. divize služeb (services) má za úkol zpracovávat data získaná předchozími dvěma složkami a nabízet je uživatelům v podobě map, dat a jiných produktů. Tato složka je řízena Evropskou komisí a
jejími organizacemi. Jednotlivé skupiny služeb by měly být podle EU (2011a, s. 6) řízeny tou agenturou, do jejíž oblasti spadají – např. služby skupiny Emergency Management by měly být zaštítěny
Evropským centrem rychlé reakce (European Emergency Response Centre).
39
Obr. 3.1 Organizační schéma iniciativy GMES (převzato z GIGAS, 2010)
3.1.1 Vesmírná divize (Space division)
Vypuštěné družice jsou rozdělovány do pěti typů nazvaných Sentinel 1 až 5. Některé z těchto typů mají
plánované dvě družice. V současné době jsou práce naplánovány asi do roku 2020. Další pokračování
bude záviset na zájmu uživatelů a finančních možnostech. Časové údaje o vypuštění některých satelitů se
v dokumentech zainteresovaných organizací vzájemně poněkud liší, nejnovější a asi nejspolehlivější údaje
v tomto případě podává ESA, která má celou divizi na starosti.
Sentinel 1 obsahuje radar typu Synthetic Aperture Radar (SAR). Umožňuje snímání za jakýchkoliv povětrnostních podmínek. SAR interferometrie pak umožňuje měřit změny terénu. Plánovány jsou postupně
dvě družice, podle ESA (2012) a ESA S1 (2012) bude Sentinel 1A vypuštěn roku 2013. Druhý pak patrně
2015.
Sentinel 2 určený pro multispektrální snímkování zemského povrchu ve vysokém rozlišení by měl podle
ESA S2 (2012) odstartovat v roce 2013, podle ESA (2012) pak o rok později. I zde je plánována druhá
družice, která by měla snímat povrch zároveň s prvním satelitem, aby byla nová data k dispozici co pět dní.
Sentinel 2 lze označit za pokračovatele známých družic Landsat a SPOT.
Sentinel 3 bude využíván pro snímání zemského i mořského povrchu. Mezi jeho přístroji je radiometr měřící teplotu moře a také altimetr na snímání výšky mořské hladiny. Podle EU (2009b, 8) a ESA S3 (2012)
bude první ze dvou plánovaných satelitů vypuštěn v roce 2013, podle ESA (2012) v roce 2014. I zde je
plánováno, že po vypuštění druhého satelitu budou oba snímat povrch zároveň.
Sentinel 4 bude mít mezi jinými přístroji také spektrometr snímající v oblasti ultrafialového, viditelného a
blízkého infračerveného pásma. Bude zaměřen na sledování atmosféry a jejího složení. Sentinel 4 nebude
samostatným satelitem. Přístroje pro tuto misi ponesou geostacionární satelity Meteosat (Meteosat Third
Generation). Podle ESA (2012) je vypuštění satelitů plánováno na rok 2017 a 2019.
Sentinel 5 bude také sledovat atmosféru, ale na rozdíl od geostacionárního Sentinelu 4 ji bude snímat z
nízké polární oběžné dráhy synchronizované se Sluncem. Také tento Sentinel ponese spektrometr měřící v
UV, viditelném a blízkém IR pásmu a další přístroje a také bude pouze součásti jiné družice. Bude nesen na
družici post-EUMETSAT Polar system (EUMETSAT, 2012). Start je podle (EU, 2009b, s. 8) naplánován
na rok 2019 a podle (EUMETSAT, 2012) a ESA (2012) na rok 2020. Sentinel 5 by měl být následníkem
současné mise Envisat. Aby se předešlo výpadku dat mezi oběma misemi, je plánováno vypuštění „předběžné verze“ Sentinelu 5. Podle stránek ESA (2012) a EUMETSAT (2012) bude start v roce 2015.
40
3.1.2 Divize služeb (GMES Services)
Využití GMES má být zaměřeno na sledování a předpovědi stavu složek životního prostředí Země. Podle
(ESA, 2012; GMES EU, 2012; GMES CZ, 2012) je definováno šest hlavních zájmových okruhů (tzv.
Core Services), které mají jednotlivé služby pokrývat:
Sledování zemského povrchu (Land Monitoring) – mezi jinými mají být získávány informace o typu
využití povrchu a jeho změnách, stavu vegetace, kvality vody a také využívány pro územní plánování, lesní
a vodní hospodaření, ochranu půdy a další činnosti.
Sledování moří (Marine Environment Monitoring) – tyto služby mají poskytovat informace o kvalitě
vody a životním prostředí, ale také např. informace potřebné pro bezpečnost námořní dopravy, rybolov,
likvidaci havárií a ropných skvrn.
Sledování atmosféry (Atmosphere Monitoring) – kromě dat naměřených o současném stavu atmosféry,
kvalitě ovzduší, množství skleníkových plynů a UV záření mají tyto služby poskytovat i údaje pro krátkodobou předpověď.
Krizový management (Emergency Management) – pro řízení záchranných operací při přírodních katastrofách nebo humanitárních krizích jsou potřeba včasné a přesné informace, které mají být získávány z
těchto služeb.
Bezpečnost (Security) – tato skupina služeb má být využívána zejména pro zabezpečení hranic EU včetně
mořských a podporu pro mírových misí během krizí mimo EU.
Změna klimatu (Climate Change) – skupina služeb, které mají za cíl lépe monitorovat a pochopit změny
klimatu.
Další specificky orientované služby, které na základě uživatelské poptávky budou řešit speciální zadání a
budou hrazené zadavatelem (instituce, členský stát apod.) se označují jako Downstream Services.
3.1.3 Stav a vývoj GMES v roce 2012
Pro rok 2012 bylo na vznik GMES vyčleněno 40 mil. EUR. Důraz v tomto roce měl být kladen na rozvoj
následujících prvků (EU, 2011b, s. 3).
3.1.3.1 Divize služeb - služby krizového managementu (Emergency)
3.1.3.1.1 Služby krizového managementu – mapování
Podle EU (2011b, s. 6) má být tato služba k dispozici na konci roku 2014. Je odhadováno, že ji uživatelé
využijí asi 50x za rok. Služby nebudou závislé jen na datech z družicového snímkování. Počítá se i s využitím dat již existujících v jednotlivých státech a zpřístupněných v rámci směrnice INSPIRE. Pro službu
jsou stanoveny následující úkoly:
• zajistit rychle dostupné („rush mode“) mapové podklady během krizové situace:
■■ mapy následků, škod a průběhu katastrofy v hodinách a dnech po katastrofě. Mají být k
dispozici do 24 hodin od zadání požadavku.
■■ topografické mapy oblastí postižených katastrofou, zejména infrastruktury a přírodních
zdrojů. Dostupné mají být do 6 hodin.
• podporovat další fáze krizového managementu (prevenci, připravenost, odstraňování následků
apod.) poskytováním dalších mapových podkladů jako např. pohyb a lokalizace uprchlíků.
41
3.1.3.1.2 Služby krizového managementu – systémy včasného varování
Podle EU (2011b, s. 11) má být tato skupina služeb k dispozici na konci roku 2014. Hlavní účel je poskytování podpory evropskému systému včasného varování před povodněmi - EFAS (European Flood Awareness System). Do EFAS mají vstupovat data meteorologická, hydrologická i předpovědi. Vstupními daty
mají být i data ze satelitů GMES. Systém se bude vzájemně doplňovat s národními systémy, ze kterých má
čerpat historická a současná hydrologická data. Má umožnit vzájemné poskytování informací v případě
velkých krizí, které vyžadují koordinaci na evropské úrovni. EFAS bude dvakrát denně produkovat celoevropské povodňové předpovědi tři až deset dní dopředu. Výsledky se mají publikovat prostřednictvím
GMES služeb krizového managementu.
3.1.3.2 Divize služeb - služby sledování zemského povrchu (Land monitoring)
3.1.3.2.1 Služby sledování zemského povrchu - celoevropské sledování využití země
(Pan-European Land Cover component)
• Práce začaly roku 2011, kdy bylo nasnímáno zhruba třetina území. V roce 2012 měl být nasnímán
zbytek. Podle EU (2011b, s. 14) má být služba k dispozici na konci roku 2013 a má poskytovat
data získávaná z družic i dalších zdrojů dat. Samotná služba má sloužit pro:
• post-processing nasnímaných dat a ověřování jejich kvality
• produkci pěti vrstev s vysokým rozlišením (20 m) podle typu využití povrchu (umělé povrchy,
lesní plochy, zemědělské plochy, mokřady, vodní plochy). Tyto mají sloužit jako vstup pro Corine
Land Cover a Urban Atlas.
• zajištění pokračování dat ze série Corine Land Cover pro rok 2012
• aktualizaci GMES Urban Atlas – projekt poskytující údaje a vzájemné srovnání o využití země pro
hustě osídlené oblasti Evropy s více než 100 tis. obyvateli.
3.1.3.2.2 Služby sledování zemského povrchu - Global Land Component
Tato skupina služeb má podle EU (2011b, s. 18) poskytovat data o stavu a změnách zemského povrchu
v celosvětovém měřítku. Má být také hlavním evropským přínosem do projektu GEOSS (viz kap. 3.2).
Výsledky mají být využitelné pro odhad úrody, zkoumání změny klimatu, boj proti desertifikaci apod. K
dispozici má být ve třetím čtvrtletí 2014.
3.1.3.3 Propagace služeb GMES mezi uživateli
Velmi důležitým cílem pro rok 2012 je propagace služeb GMES mezi potenciálními uživateli, aby se předešlo situaci, že po svém spuštění nebudou služby dostatečně využity (EU, 2011b, s. 22). Tato činnost
potrvá až do konce přípravného období na konci roku 2013. Součástí tohoto cíle je tvorba propagačních
materiálů, organizace workshopů a tréninkových seminářů, tvorba ukázkových příkladů, jak může GMES
pomoci různým organizacím při jejich činnostech, příprava uživatelských rozhraní pro zpřístupnění služeb GMES různým skupinám uživatelů atd. Zároveň má být získána i zpětná vazba od uživatelů.
3.1.3.4 Vesmírná divize
V roce 2012 pokračuje příprava vesmírné divize. Vypuštění Sentinelu 1 je plánováno podle EU (2011b, s.
25) na konec roku 2013, přičemž se zároveň pokračuje i v přípravě misí Sentinel 2 a 3.
42
3.2 GEOSS
GEOSS je zkratka názvu Global Earth Observation System of Systems. Systém má umožnit výměnu dat
a poznatků z pozorování jak ze zemského povrchu (in-situ), tak i pomocí družic otevřeným způsobem a s
minimálními náklady (GMES CZ, 2012). Tento „systém systémů“ propojí existující a plánované systémy
na sledování Země a podpoří jejich vytvoření tam, kde doposud chybí. Projekt používá technické standardy, takže data z tisíců různých přístrojů bude možno vzájemně kombinovat (GEOSS, 2012b).
3.2.1 GEO
Základem projektu GEOSS byl projekt GEO – Skupina pro pozorování Země (Group for Earth Observation) založený roku 2005 v Bruselu. Jeho předchůdcem byl projekt EOS (Earth Observation System) založený v r. 2003 na jednání Světového summitu G7 ve Washingtonu. Podle GEOSS (2012b) bylo v březnu
2012 jejím členem 88 států, Evropská komise a 64 organizací. GEO schválila desetiletý implementační
plán do roku 2015, který zasahuje do řady tematických oblastí a definuje sérii konkrétních úkolů.
3.2.2 GMES a GEOSS
V textech mnoha významných institucí lze najít vzájemné spojení mezi oběma těmito projekty. Několik
příkladů za všechny: „V globálním kontextu je GMES integrální součástí systému GEOSS“ (cit. EEA,
2012), „GMES je srdcem příspěvku EU do systému GEOSS: princip sdílení dat definovaný na tomto
mnohostranném fóru je jedním ze základů pro správu dat ze Sentinelů“ (cit. EU, 2009b, s. 6), „GMES
ve své iniciační fázi je považován za evropský příspěvek k systému GEOSS v rámci skupiny GEO“ (cit.
GMES CZ, 2012).
Výše zmíněné citace mohou být ale poněkud zavádějící, GMES totiž nebylo původně definováno jako
„evropská část GEOSS“, ale jedná se o samostatný projekt. Lze však konstatovat, že se jí může po svém
dokončení určitě stát, protože oba projekty sdílejí některé podobné aspekty, jakými jsou např. důraz na
sdílení dat, využívání a propojení stávajících systémů, či využívání dat pro podobné účely. Mezi oběma
projekty jsou však také určité odlišnosti:
• GEOSS je založen na dobrovolném členství, zatímco GMES je projekt řízený Evropskou komisí.
• GEOSS má mnohem víc členů z různých kontinentů než evropský GMES (v březnu 2012 bylo
jejím členem 88 států, Evropská komise a 64 organizací).
• GEOSS nemá tak striktní plán jako GMES. Byl založen roku 2005 s výhledem do roku 2015
(GMES CZ, 2012). Současný plán prací je pro roky 2012-2015.
• GEOSS neplánuje vyslání žádných satelitů určených výhradně pro tento program, ale chce naopak
využít již existující satelity různých organizací, které už vypuštěny byly a budou, a to včetně satelitů
z misí Sentinel v rámci programu GMES.
3.2.3 Součásti GEOSS
Infrastruktura, která umožňuje uživateli vyhledat a použít data, se v GEOSS nazývá GEOSS Common
Infrastructure (GCI). Podle GEOSS (2012b) se skládá z (viz obr. 3.2):
• GEO Portal, který tvoří místo, kde uživatel vyhledává dostupná data a služby.
• GEOSS Clearinghouse vyhledává data a distribuuje je uživateli přes GEO Portal.
• Registr komponent a služeb (GEOSS Components and Services Registry) obsahuje jméno, obsah a další informace o jednotlivých zdrojích dat.
• Registr standardů (GEOSS Standards and Interoperability Registry) poskytuje poskytovatelům
dat informace o standardech doporučených pro použití v GEOSS, aby jejich data mohla být použita co nejširší skupinou uživatelů.
43
Obr. 3.2 Schéma infrastruktury projektu GEOSS - „GEOSS Common Infrastructure“ (převzato z GEOSS, 2012b)
3.2.4 GEO Portal
GEO Portál je klíčovou součástí projektu. Jedná se o webové rozhraní, ve kterém uživatel může vyhledat
data, která jsou mu v rámci projektu GEOSS k dispozici, přičemž portál nabízí tři různé způsoby, jak data
vyhledávat (obr. 3.3). Jednak je možné data vyhledat podle výběru požadované lokality na interaktivním
glóbu, vložením klíčového slova do vyhledávacího textového pole (to je na obrázku umístěno hned nad
glóbem) nebo podle nabízených tematických okruhů v levé části celého uživatelského rozhraní.
Obr. 3.3 GEO Portal – webové rozhraní pro vyhledávání dat v projektu GEOSS (převzato z GEO Portal, 2012)
44
3.2.5 Plán prací a rozvoje pro roky 2012-2015
Na konci roku 2011 byl stanoven plán rozvoje projektu GEOSS pro následující tři roky (GEO, 2011).
V porovnání s plánem projektu GMES pro rok 2012 EU (2011b) je rozsáhlejší, s větším počtem cílů, ale
zároveň i méně konkrétní. Hlavní důvod byl naznačen už dříve v této kapitole, totiž že GEOSS chce především využívat data z již fungujících nebo budovaných systémů nebo využít zkušenosti z jejich budování,
a z tohoto důvodu se často „čeká“ než budou tyto systémy dokončené. Protože jde o systém celosvětový,
je kladen důraz i na budování systémů a infrastruktury v rozvojových zemích, ve kterých podobné technologie prozatím chybí.
Plán budování GEOSS v letech 2012-2015 je možné shrnout do následujících bodů:
• Systémy pro sledování Země (Earth Observing Systems)
Cílem je zajistit a koordinovat kontinuální sběr dat z pozemních i vesmírných zařízení. Bude nutno doplnit tyto systémy v těch případech, ve kterých nejsou dostatečné, např. v rozvojových zemích. Součástí
této snahy je i lepší koordinace stávajících sítí (např. seismografických), lepší koordinace sběru dat pomocí
družic a letadel. Při koordinaci sběru dat ze zdrojů mnoha organizací by měly být využity zkušenosti EEA
koordinující pozemní divizi GMES. I proto je Evropská komise důležitým členem skupiny, která má naplnit tento bod.
• Data o Zemi (Earth Data Sets)
Kromě získání dat z různých systémů je nutné také zajistit jejich validaci, dostupnost pro uživatele a další
náležitosti.
• Společná infrastruktura GEOSS (GEOSS Common Infrastructure)
Tato část pojednává o vypracování strategie na vylepšení stávající infrastruktury.
• Komunikační sítě GEOSS (GEOSS Communication Networks)
V této části je zdůrazněna nutnost zajištění sítě pro přenos a sdílení dat, především pak v rozvojových
zemích.
• Rozvinutí principů sdílení dat (Advancing GEOSS Data Sharing Principles)
Cílem je, aby co největší část dat byla uživatelům k dispozici zcela volně bez jakýchkoliv poplatků či omezení. Jedním z bodů je i vytvoření kolekce volně dostupných dat pro každého, a to v rámci tzv. GEOSS
Data CORE.
• Vytvoření institucionálních a individuálních kapacit (Developing Institutional and Individual
Capacity)
Je potřeba zajistit tréninkové kurzy pro uživatele, rozšířit využívání dat z GEOSS mezi vědeckými týmy a
udělat propagaci mezi politickými představiteli.
• Data GEOSS mají být využita v nejrůznějších oblastech lidské činnosti:
■■ sledování oceánu (pomocí družic i in-situ senzorů)
■■ sledování změn využití zemského povrchu (v rozlišení pod 50 m)
■■ sledování urbanizovaných území
■■ sledování lesů a hospodaření s nimi
■■ monitorování ekosystémů a biodiverzity a jejich ovlivnění činností
■■ podpora managementu krizových situací poskytováním aktuálních informací
■■ poskytnutí nástrojů a informací pro zdravotnictví – sledování kvality vody a vzduchu, alergenů, škodlivin apod.
■■ vyhledávání energetických zdrojů – vyhledávání geologických ložisek, míst s příznivými
podmínkami pro stavbu větrných a slunečních elektráren apod.
■■ sledování skleníkových plynů, plochy zmrzlé půdy a ledovců a další služby pro zkoumání
klimatických změn
■■ předpověď počasí, zejména jeho extrémních projevů
■■ celosvětové sledování a odhad úrody pro zajištění potravinové bezpečnosti
45
Mnoho z těchto bodů má být naplněno i ve spolupráci s GMES – např. sledování využití zemského povrchu úzce souvisí se službou GMES Global Land Component.
3.2.6 Příklad systému GEOSS
Ukázkou toho, jak mohou být v programu GEOSS shromážděna a využita data z různých zdrojů, může
být projekt Supersites (GEOSS, 2012a). Tento projekt umožňuje přístup ke geofyzikálním datům zaměřených na zemětřesení, sopečnou činnost a další s tímto spojené jevy. Dostupná data jsou získána jak sledováním Země z vesmíru (např. syntetický radar SAR nebo sledování deformací povrchu pomocí GPS), tak
i z pozemních stanic (např. seizmografy).
3.3 Rámcové programy Evropské unie
3.3.1 Historie rámcových programů
Rámcové programy (Framework programme, dále FP) jsou v Evropském společenství jedním z nejdůležitějších způsobů financování rozvoje vědeckého a technologického pokroku v tzv. Evropském výzkumném
prostoru. Motivace a zaměření těchto výzkumných programů vychází už ze zakládajících smluv Evropské
unie, přičemž hlavním cílem je podpořit pomocí výsledků těchto programů ostatní politiky EU, a dosáhnout tak zvýšení její mezinárodní konkurenceschopnosti.
První z rámcových programů (FP) byl zahájen už v roce 1984 (ukončen byl v roce 1988; každý další
program trval zpravidla pět let. Počínaje 7. FP je doba trvání prodloužena na sedm let. Česká republika se
účastnila již 3. FP (zahájen v roce 1990). Jednotlivé programy se svým zaměřením, rozpočtem i podmínkami čerpání podpory lišily. V rámci této kapitoly budou představeny vybrané projekty z posledních dvou
rámcových programů, zejména pak ze 7. FP.
3.3.2 Šestý rámcový program
Hlavním cílem 6. FP bylo především přispět ke koordinaci evropských výzkumných aktivit, které byly to
této doby relativně roztříštěné. Z tohoto důvodu byly jednotlivé oblasti programu zaměřeny na organizování spolupráce zejména na mezinárodní úrovni, propojování národních politik v této oblasti či zvyšování
mobility jednotlivců.
6. FP byl strukturován na dva specifické programy: první byl zaměřen na Integraci a posilování Evropského
výzkumného prostoru (tento program obsahoval dva bloky aktivit s celkem sedmi prioritními tematickými oblastmi), druhý program Strukturování Evropského výzkumného prostoru měl poté za úkol uvádět do
praxe hlavně specifický výzkum. Více se lze o cílech 6. FP a zaměření jednotlivých bloků dočíst např. na
internetových stránkách 6. FP (http://ec.europa.eu/research/fp6).
Z hlediska tematiky této publikace budou zmíněny projekty spadající svým zaměřením do druhé prioritní
oblasti prvního specifického bloku Technologie informační společnosti. Projekty z této oblasti byly zaměřeny na výzkum v oblasti bezpečnosti, komplexních informačních systémů, komunikační infrastruktury,
softwarových technologií, nanosystémů a výzkumem v oblasti nových technologií a principů majících
vztah k IT. Do této oblasti spadají i projekty ORCHESTRA a SANY.
3.3.2.1 ORCHESTRA
Projekt Orchestra (probíhal v letech 2004 až 2008) je na tomto místě zmiňován zejména s ohledem na
to, že některé jeho výsledky byly využity i při přípravě evropských iniciativ INSPIRE a GMES (o těchto
projektech pojednávají předcházející kapitoly) a mnoha dalších projektů šestého a později i sedmého
rámcového programu. Projekt byl zařazen v prioritní ose Improving Risk Management (ten byl zaměřen
na projekty rozvíjející integrované systémy a komponenty pro krizové řízení a civilní bezpečnost; viz
ISTWEB, 2012)
46
Cílem systému ORCHESTRA bylo především navržení služby, jejíž architektura bude umožňovat zdokonalení interoperability mezi jednotlivými složkami souvisejícími s krizovým managementem. Tento cíl
byl splněn převážně prostřednictvím vytvoření referenčního modelu tzv. Reference Model for the ORCHESTRA Architecture (RM-OA), který blíže specifikuje nároky na informační a funkční interoperabilitu systémů pro použití v krizovém managementu. Tento model byl vystavěn na základě standardů a specifikací
ISO, OGC a W3C. Hlavní výsledky a výstupy projektu ORCHESTRA, včetně podrobných specifikací
RM-OA, lze nalézt na internetových stránkách projektu (ORCHESTRA, 2012).
3.3.2.2 SANY – Sensors anywhere
Projekt SANY (probíhal v letech 2006 až 2009) byl v rámci 6. FP financován v prioritní ose ICT for Environmental risk management, která byla zaměřena na řešení problematiky informačních a komunikačních
technologií u koncových uživatelů v rámci GMES (více viz ISTWEB, 2012)
Projekt SANY vytvořil předlohu pro environmentální informační systémy, kterou lze považovat za implementaci principů, které vycházejí z projektu ORCHESTRA. Původní architektura RM-OA, která byla
z projektu ORCHESTRA převzata, byla ověřena při reálných situacích, jakými byli například monitorování přírodních hazardů či znečištění ovzduší. Pro tyto účely navíc proběhlo i rozšíření a optimalizace
modelu RM-OA.
Obr. 3.4 Ilustrace SANY architektury na jednotlivé komponenty systému v rámci pilotního projektu Sledování rizik v zastavěných Obroblastech (podle KLOPFER et al, 2009).
47
Jedním z hlavních výsledků projektu SANY bylo tedy vytvoření architektonického rámce SensorSA (Sensor Service Architecture), který se stal základním prostředím pro vytváření environmentálních aplikací
využívajících informací z různých druhů sensorů. Koncepce SensorSA vychází z již zmíněného modelu
RM-OA, ale zároveň i z OGC specifikací SWE (viz kapitola 5). Na těchto základech umožňuje SensorSA
vytváření velmi rozmanitých služeb, které mohou flexibilně reagovat na požadavky koncových uživatelů,
což bylo v poslední fáze projektu ověřeno i při třech pilotních projektech (KLOPFER et al, 2009).
3.3.3 Sedmý rámcový program
Právě probíhající 7. rámcový program (dále 7. FP) je zatím nejrozsáhlejším rámcovým programem, a to co
se týká délky trvání i celkového rozpočtu pro podpořené projekty. 7. FP začal v roce 2007 a během následujících sedmi let (program trvá až do konce roku 2013) budou podpořeny projekty za celkových více než
50 miliard eur. Relativně zajímavým poznatkem je celkové zjednodušení tohoto programu ve srovnání s
těmi předcházejícími, a to zejména ve strukturování jednotlivých podporovaných oblastí.
3.3.3.1 Struktura a zaměření
Zaměření 7. FP je rozděleno do čtyř specifických programů, které přitom odpovídají čtyřem hlavním
cílům současné evropské výzkumné politiky. Jak se lze dočíst v Rozhodnutí Evropského parlamentu č.
1982/2006/ES, jsou těmito specifickými programy: Spolupráce, Myšlenky, Lidé a Kapacity. Stejně jako v
ostatních předcházejících rámcových programech je kladen důraz na mezinárodní spolupráci (zejména v
rámci programu Spolupráce, který je zaměřen především na problematiku informačních a komunikačních
technologií, nanotechnologií, ale i životního prostředí a zdraví obyvatel). V rámci 7. FP jsou významně
rozvíjeny teoretické i technologické výsledky zejména předcházejícího rámcového programu, což je i případ dále zmiňovaných projektů ENVIROFI, TATTOO či SUDPLAN.
3.3.3.2 ENVIROFI
Projekt ENVIROFI je projekt 7. FP podpořený specifickým programem Spolupráce, který začal v roce
2011, a který bude probíhat až do konce roku 2013. ENVIROFI je zároveň jedním z osmi pilířů (tematických projektů) v rámci partnerského projektu FI-PPP (Future Internet Public-Private-Partnership).
Hlavním cílem projektu je vytvoření tzv. Environmental Observation Web, který lze chápat jako efektivní
nástroj pro přístup ke všem datům o životním prostředí pro koncové uživatele, a to zejména pro subjekty
činné v rozhodovacích procesech o životním prostředí; jak podotýkají HAVLIK et al (2011) měl by výsledný stav „environmentalizovat“ prostředí budoucího internetu, a to právě ve smyslu snadného přístupu
nejrůznějších aplikací k datům o životním prostředí. HAVLIK et al (2011) a SCHADE et al (2011) pak
uvádějí konkrétní příklady aplikace výše uvedeného internetového prostředí. Pomocí vhodně vytvořených
senzorových sítí bude například možné (s pomocí např. tweetů či jiných informací ze sociálních sítí) lépe
sledovat a posuzovat různé přírodní katastrofy v reálném čase, včetně jejich příčin a průběhu. Tyto informace bude možné mnohem rychleji využívat pro podporu všeobecné bezpečnosti či pro efektivní naplánování jednotlivých zásahových akcí.
V rámci projektu ENVIROFI budou v první fázi ve vybraných oblastech (sledování biodiverzity, atmosférické a oceánské podmínky) vytvořeny tzv. environmental enablers, tedy specifické aplikace, které budou
zaměřeny na sběr, třídění a vizualizaci konkrétních dat ze senzorových pozorování v dané oblasti. Tyto
aplikace by měly mít takové vlastnosti, aby je bylo možné flexibilně implementovat i v prostředí ostatních
dat o životním prostředí (viz ENVIROFI, 2012).
48
Obr. 3.5 Role projektu ENVIROFI při „environmentalizaci“ internetu (převzato z ENVIROFI, 2012)
3.3.3.3 SUDPLAN
Stejně jako v předchozím případě, je i projekt SUDPLAN (Sustainable Urban Development Planner for
Climate Change Adaptation, 2010 až 2012) financován ze specifického programu 7. FP Spolupráce. Cílem
tohoto programu je obohatit metodiku urbánního plánování o prostředky prediktivního nástroje, který
by bral v úvahu různé environmentální aspekty mající vliv na městský subsystém. Jednotliví uživatelé (především urbanisté či architekti) tak budou mít možnost relativně jednoduchým způsobem posuzovat vliv
plánovaných staveb a s tím související dopravní situace na kvalitu života v zastavěných oblastech (včetně
kvality ovzduší, půdy apod.).
Obr. 3.6 Ukázka uživatelského rozhraní s vizualizací modelu možného vývoje znečištění ovzduší v nově zastavěné oblasti (převzato ze SUDPLAN, 2012)
Na tomto místě je nutné uvést, že výše uvedené informace je možné již v současnosti získat a projekt si
proto neklade za cíl vytvářet nové databáze či senzorové sítě. Hlavním výsledkem je v tomto případě efektivní propojení existujících informací ze simulačních modelů, senzorových sítí, datových infrastruktur
nebo klimatických modelů pro urbánní systémy, k čemuž budou zároveň využity existující architektury
49
(SOA) a specifikace OGC (SWE aj.). Stejně tak budou využity technologické postupy vytvořené v rámci
projektu ORCHESTRA a SANY (hlavně co se týká zkušeností z pilotních projektů). Takto vytvořený
nástroj bude poté schopný zhodnotit různé scénáře, vizualizovat je a porovnávat je s dalšími alternativami,
včetně komparace s reálnými situacemi (DENZER et al, 2011).
Jedním z hlavních výstupů bude softwarová komponenta umožňující vizualizace vytvořených modelů ve
4D prostoru. Tato aplikace je součástí celého vytvářeného nástroje, přičemž v současné době (podzim
2012) lze na internetových stránkách projektu nalézt ukázku první verze této komponenty (viz SUDPLAN, 2012).
3.3.3.4 TaToo
Posledním projektem 7. FP, který bude zmíněn v této kapitole je TaToo (akronym pro Tagging Tool based
on Semantic Discovery Framework, 2012 až 2012). Náplň tohoto projektu relativně úzce souvisí s předchozím projektem, jeho hlavním úkolem je totiž umožnění správné identifikace požadovaných a relevantních
informací v internetovém prostoru, které jsou současně v daném momentě dostupné.
Hlavní důraz je proto kladen na vývoj nástrojů pro efektivní třídění dat o životním prostředí a zároveň i
pro přidání odpovídajících sémantických informací k těmto datům (pro jejich rychlejší budoucí použití).
Východiskem je totiž v současné době velké množství dat o životním prostředí, které nemají zcela jasný
původ, a jejichž relevantnost není v mnoha případech uživateli známa. Hlavní cíle projektu lze proto možné spatřovat v těchto oblastech: vytvoření jakéhosi „prostředníka“ mezi zdroji dat a koncovými uživateli,
přičemž tato architektura musí být schopna podrobně popsat původ těchto dat (což vyžaduje integraci a
případné zpracování existujících metainformací). Za druhé je nutné zajistit, aby byl tento nástroj schopen
k těmto datům rychle přistupovat (TATOO, 2012).
Obr. 3.7 Schéma TaToo infrastruktury umožňující popis, třídění a vyhledávání a relevantních dat na internetu (převzato z TATOO, 2012)
3.4 Shrnutí
V této kapitole byly uvedeny příklady řady významných projektů, které se různými způsoby snaží o jistou míru standardizace ve využívání geoprostorových dat. Je zřejmé, že bez existence vhodných nástrojů
nebude možné efektivně používat dostupné informace o životním prostředí, kterých je již v dnešní době
velké množství a lze se domnívat, že s nastupujícím fenoménem internetu věcí bude jejich množství i
rychle narůstat. Je možné předpokládat, že výsledky výše zmíněných projektů budou schopné nabídnout
dostatečně účelné nástroje pro efektivní využívání těchto informací.
50
4. 3D MODELOVÁNÍ V KONTEXTU GEOINFORMAČNÍCH STANDARDŮ
Lukáš HERMAN
Tato kapitola je věnována především standardu CityGML, jeho vývoji, hlavním vlastnostem a využití.
Dále je analyzována související problematika tématu prostorových dat budovy z datových specifikací
směrnice INSPIRE a 3D síťových služeb. Na příkladech konkrétních projektů jsou popsány možné aplikace 3D modelů v oblasti hlukového mapování, výpočtů energetické bilance budov.
4.1 CityGML 1.0
4.1.1 Vznik a vývoj
Za zrodem formátu CityGML stojí organizace Special Interest Group 3D (SIG 3D), jenž má více jak 70
členů, převážně z Německa. Patří mezi ně nejen výzkumné ústavy a vysoké školy, ale i soukromé firmy,
zemská (Severní Porýní – Vestfálsko) a místní samospráva. V čele skupiny SIG 3D stojí profesor Thomas
Kolbe z TU Berlin a doktor Gerhard Grőger (TU Bonn). Vývoj CityGML byl zahájen v roce 2002, v roce
2006 se o formátu začalo diskutovat také v rámci Open Geospatial Consortia (OGC) a v říjnu 2008 bylo
CityGML ve verzi 1.0 uznáno jako oficiální standard. Tím se ale vývoj standardu nezastavil, v průběhu
roku 2011 vrcholily práce na nové verzi, původně označované jako 1.1, nakonec však byla tato nová verze
označena jako 2.0 a v dubnu 2012 byla OGC schválena.
4.1.2 Víceúrovňová reprezentace
Další důležitou vlastností je víceúrovňová reprezentace. Ta je realizována pěti úrovněmi detailu (Level of
Detail – LOD). Podrobnost se zvyšuje od 2,5D modelu v LOD0 až po model budov včetně interiérů a jejich vybavení v LOD4. Se zvyšující se úrovní detailu roste zpravidla počet a složitost geometrických prvků
a mění se i tematická náplň. V jednom modelu mohou být použity prvky z různých úrovní a naopak jeden
objekt může mít v každé úrovni detailu jinou reprezentaci.
Obr. 4.1 Úrovně detailu (LOD) v CityGML (převzato z OGC, 2008)
Nejméně podrobnou úrovní je LOD0, což je v především2,5D model terénu. LOD1 je označení pro blokový model (bez modelace střech). Střechy podrobněji jsou modelovány v LOD2. LOD3 obsahuje ještě
podrobnější architektonický model i s detaily jako jsou na stěnách. LOD4 doplňuje předchozí úroveň o
znázornění interiérů a jejich zařízení.
51
4.1.3 Geometrie a topologie
Geometrie CityGML vychází z jazyka GML3. 3D objekty jsou založeny na datovém modelu reprezentace
hranic (v angl. „boundary representation“), jenž musí být uzavřené, aby se dalo pracovat s objemem jednotlivých objektů. V případě, že fyzicky uzavřené nejsou, jako například tunely, jsou uzavírány pomocí virtuálního povrchu ClosureSurface. CityGML obsahuje i další nadstavbové koncepty, kterými se od GML3
odlišuje. Jedním z nich je tzv. TIC – Terrain Intersection Curve. Tato křivka přesně popisuje, kde objekt,
například budova, protíná terén, čímž je zajištěn správný topologický vztah. Při znázornění opakujících
se objektů, například stromů, se používá koncept Implicit Geometry. Prototyp objektu, který může být i
v odlišném formátu, například VRML (Virtual Reality Modeling Language) nebo 3DS, je opakovaně
vkládán do modelu. Má vlastní souřadnicový systém a obsahuje transformační matici nebo kotevní bod
pro umístění do souřadnicového systému, používaného v modelu (OGC, 2008).
Obr. 4.2 Geometricko-topologická datová struktura (převzato z HERMAN, 2011a)
CityGML se výrazně liší od GML přístupem k definování topologie. Pro popisování topologických
vztahů se používá XLink (XML Linking Language), který odkazuje na unikátní ID jednotlivých prvků. Konkrétní geometrie, například polygon tvořící společnou zeď dvou domů, je tedy definována
jednou a při jejím dalším použití je na ni pouze odkazováno. Budova (Building) se může skládat jak z
geometrických (lod1Solid až lod4Solid), tak z topologických elementů (lod1TopoSolid až lod4TopoSolid).
CityGML tak může být nejen čistě geometrickým modelem, ale i modelem topologicko-geometrickým. Tím se
CityGML liší od starších řešení, které geometrii a topologii oddělovaly (KOLBE, 2008).
Obr. 4.3 Znázorněný průběh TIC (vlevo černě a vpravo červeně) a vpravo virtuální povrch ClosureSurface zvýrazněný zelenou
barvou (převzato z OGC, 2008)
52
4.1.4 Textury a vizualizace
Své místo v CityGML mají rovněž textury a informace o vzhledu povrch, uložené v rámci třídy
Appearance. Jednotlivé objekty jsou pokrývány texturami transformovanými podle zadaný parametrů (ParametrizedTextures) a k pokrytí terénu se zpravidla používají georeferencované textury (GeoreferencedTextures). CityGML podporuje takzvaný multi-texturing, což lze využít v případech, kdy pro jeden model
existuje více variant vzhledu. Příkladem může být několik textur budov - z termálního snímkování či pořízené ve viditelné části spektra. Rovněž mohou být použity odlišné textury s různými úrovněmi detailů.
Rastrový obraz je připojen pomocí atributu imageURI, což může být buď odkaz na soubor, nebo požadavek na webovou službu. K dispozici je pět základních přístupů k přikládání textur none, wrap – textura
se opakuje, mirror – textura se opakuje a zrcadlí, clamp – textura je roztažena k okrajům a border – barva
pozadí textury je určena elementem borderColor (OGC, 2008).
Obr. 4.4 Georeferencovaná textura na modelu a terénu a parametrizované textury na budovách a vegetaci (převzato z HERMAN, 2011a)
Vzhled může být určen nejen rastrovými snímky, ale i definicí materiálu a světelného chování objektu.
Tato možnost je převzata z formátů COLLADA (COLLAborative Design Activity) a X3D (eXtensible
3D). Pomocí atributů emissiveColor, diffuseColor, ambientIntensity, shinines, transparency lze nastavit barvy a komplexní světelné chování objektů (OGC, 2008; KOLBE, 2008).
4.1.5 Sémantický model
Klíčovým principem, kterým se CityGML odlišuje od ostatních 3D formátů, je sémantické modelování.
Model je tedy složen ze sémantických tříd a každé z nich je přiřazena jedna nebo více geometrických tříd
(sémantická třída může existovat i bez přiřazené geometrie, pak se označuje jako třída abstraktní). Třídy a
jejich vzájemné vztahy a atributy jsou modelovány v jazyce UML (Unified Modelling Language). Sémantická struktura použitá v CityGML je založena na standardu ISO 19109 (OGC, 2008).
Obecné schéma CityGML se skládá z horizontálních a vertikálních složek. Vertikální složky popisují tematické entity (budovy, reliéf, vegetace a další). Tři horizontální složky (Core, Appearance, Generics) pak
definují strukturu závaznou pro tematické moduly (KOLBE, 2008). Základní sémantické (vertikální)
třídy v CityGML 1.0 jsou budovy, model terénu, hydrografie, land use, vegetace a dopravní objekty. Na
nejvyšší úrovni se ve strukturním modelu CityGML nachází abstraktní třída CityObject. Konkrétní prvky CityObject jsou součástí kolekce CityModel, stejně jako třída definující vzhled objektů – Appearance
(OGC, 2008).
53
Obr. 4.5 Vzájemné provázání sémantické a geometrické datové struktury (převzato z HERMAN, 2011a)
Základní částí většiny modelů je digitální model terénu. Ve struktuře CityGML je reprezentován třídou
ReliefFeature, která je obsažena ve všech LOD. Terén může být reprezentován jako GRID (třída RasterRelief), TIN (TINRelief), pomocí lomových linií (BreaklineRelief), nebo pomocí bodů (MasspointRelief). Jednotlivé reprezentace reliéfu mohou být vzájemně kombinovány. Atribut extentOf Validity přitom
vymezuje území, pro které je použit daný model terénu. Zpravidla jsou takto kombinovány různě přesné
modely terénu. Použití rastrového reliéfu je realizováno pomocí odkazu na soubor GeoTIFF (Geographic
Tagged Image File Format). Ostatní typy jsou uloženy přímo v rámci souboru CityGML (OGC, 2008).
Obr. 4.6 Vybrané sémantické prvky z třídy budovy (převzato z OGC, 2008)
Do největší hloubky je sémantický model rozpracován pro budovy a jejich části. Jednotlivé domy lze rozložit na části, místnosti nebo stěny. Nejvyšší třída, která popisuje budovy AbstractBuilding, je specifikována
pomocí atributů class, function1 , usage (specifikují druh a využití budovy), yearOfConstruction, yearOfDemolition (časové určení budovy), roofType (typ střechy), measuredHeight (výška budovy), storeyAboveGround, storeyBelowGround (počet pater nad a pod zemí), storeyHeightsAboveGround a storeyHeightsBelowGround (výška nadzemních a podzemních pater). Třídě AbstractBuilding, jsou pak bezprostředně
podřízeny třídy Building a BuildingPart. Tyto třídy mohou být mimo jiné provázány s bodovou třídou
Address. U budov je dobře patrné uplatnění víceúrovňové reprezentace. Zatímco Building se vyskytuje
od LOD1, další (podrobnější) třídy jako BuildingInstallation se objevují v LOD2 a Window nebo Door
v LOD3. Tyto prvky jsou ohraničeny prvky z třídy BoundarySurface, např. RoofSurface, WallSurface,
GroundSurface (OGC, 2008).
1 Rozdíl mezi třídou (class) a funkcí (function), spočívá v počtu hodnot, které mohou zároveň nabývat. Třída musí být v rámci
jednoho objektu jen jedna, funkcí může být více. Toto platí i u dalších tříd, které mají tyto atributy.
54
K popisu vodstva slouží třída WaterBody. Ta může být z hlediska geometrie jak křivka (MultiCurve), plocha (MultiSurface) v obou případech LOD0 a LOD1, i těleso (Solid) v LOD1 až LOD4. V druhém případě je pak element ohraničen pomocí třídy WaterBoundarySurface, složené z WaterSurface (hladina),
WaterGroundSurface (dno) a případně WaterClosureSurface (virtuální uzavření, např. v případě moře).
Typ a využití vodního objektu je definováno příslušnými atributy (OGC, 2008).
Hlavní třídou pro popis dopravních objektů je TransportationComplex, jenž se skládá z dílčích tříd TrafficArea (například samotná plocha silnice) a AuxiliaryTrafficArea (středové pásy nebo příkopy), obě třídy
jsou blíže charakterizovány atributy function, usage a surfaceMaterial. Třídě TransportationComplex jsou
podřízeny třídy Track, Road, Railway a Square. TransportationComplex je definován v LOD0 jako liniový
prvek v podrobnějších LOD jako povrch (OGC, 2008).
Obr. 4.7 Silnice a její znázornění v jednotlivých úrovních detailu (převzato z HERMAN, 2011a)
Vegetace je v CityGML definována dvěma způsoby. Jednotlivé rostliny (nejčastěji stromy) jsou znázorněny pomocí třídy SolitaryVegetationObject, kdežto rozsáhlejší plochy používají třídu PlantCover (s MultiSurface nebo MultiSolid geometrií). Třída CityFurniture slouží k popisu a znázornění objektů, jako jsou
pouliční světla, semafory, reklamní panely a podobně. Atributy jsou specifikovány funkce konkrétních
objektů. Třídou Land use je v rámci CityGML definováno využití půdy. Tato třída má vždy geometrii
MultiSurface. Konkrétní funkce a využití jednotlivých ploch definují atributy. Tuto třídu lze používat ve
všech úrovních detailu (LOD0 – LOD4). Třída CityObjectGroup slouží k seskupení jednotlivých elementů CityObject (OGC, 2008).
Řada zmiňovaných atributů (např. class, function, roofType) je definována prostřednictvím číselníků obsažených v OGC specifikaci. Jakýkoliv z prvků v modelu může v CityGML sloužit i jako odkaz (prostřednictvím atributu externalReference) na zdroj dat nebo na doplňující informace. Budova tak může
kupříkladu odkazovat do katastru nemovitostí na informace o majiteli (OGC, 2008, KOLBE, 2008).
4.1.6 Rozšiřitelnost sémantického modelu
Pro případné rozšíření základního tematického modelu CityGML slouží dvě základní koncepty. Prvním
konceptem jsou generické prvky a atributy. Druhým je pak ADE (Application Domain Extension). Generické prvky (GenericCityObject) je možné použít jen pro objekty neobsažené v základním CityGML modelu, tyto třídy nejsou formálně specifikovány a snižují sémantickou interoperabilitu a při jejich používání
mohou vznikat konflikty. GenericCityObject může mít libovolný typ geometrie a podporuje také koncepty
TIC a ImlicitGeometry. Generické atributy (GenericAttribute) mohou odpovídat jakémukoliv z datových
typů povolených v CityGML, tj. String, Integer, Double, Date a URI (OGC, 2008).
55
ADE vzniká definováním nových tříd nebo rozšířením stávajících o nové atributy nebo relace. Jejich cílem
je rozšíření možností využití formátu CityGML. Každé ADE je specifikováno prostřednictvím vlastního
XSD schématu (XML Schema Definition). Definice elementů v ADE musí být vždy vztažena k základnímu tematickému schématu CityGML, tzn. nová ADE třída je vždy podřízena třídě obecné (OGC, 2008).
4.1.7 Využití
ADE určené k mapování hlukové zátěže je přímou součástí specifikace CityGML 1.0.0. Toto ADE zavádí
jak nové třídy, tak rozšiřuje některé stávající o další atributy. Obecné třídě Road je nově přiřazena podtřída
NoiseRoadSegment. Podobně je třída Railway rozšířena o podtřídu NoiseRailwaySegment a jí podřízený
element Train. O atributy je rozšířena i třída AbstractBuilding. Hlukové bariéry jsou popsány pomocí třídy NoiseCityFurnitureSegment, která je odvozena z obecné třídy CityFurniture. Všechny nové třídy obsahují atributy používané pro výpočty hlukové zátěže. Třída NoiseRoadSegment nese například informace
o průměrné hustotě dopravy (počtu aut) za hodinu ve čtyřech časových úsecích dne, podíl nákladních
automobilů, údaje o rychlostních limitech nebo průměrná denní hustota dopravy. Další atributy pak popisují parametry samotné silnice. Upřesňují její materiál, korekci odrazu zvuku, šířku vozovky nebo sklon
daného úseku Třída AbstractBuilding je rozšířena údaji o korekci odrazu hluku od budovy. Třída NoiseCityFurnitureSegment je blíže určena konkrétním typem protihlukové bariéry, odrazovými vlastnostmi,
výškou a vzdáleností od dopravní komunikace (OGC, 2008). Širší aspekty použití tohoto ADE jsou
popsány v příslušné podkapitole.
CityGML bylo využito například při studiu povodní. Na HFT (Hochschule fűr Technik) Stuttgart je vyvíjeno rozšíření pro integraci dat o změnách výšky vodní hladiny do CityGML. V tomto případě je rozšířena
třída, popisující hydrografii. Třída je modifikována WateryBody zavedením podtřídy DynamicWater. Tato
třída má dále dvě podtřídy DynamicWaterMetadata (popisující k výpočtu užitý software, hydraulický model a další parametry) a DynamicCoverage. V rámci této třídy jsou pak uloženy údaje o výšce vodní hladiny
a jejích změnách v čase, když specifikace atributů pro vyjádření času je převzatá z GML3 (SCHULTE et
al, 2009).
Obr. 4.8 Schéma rozšíření Hydro ADE a napojení na strukturu CityGML (upraveno podle SCHULTE et al, 2009)
UtilityNetwork ADE slouží k implementaci popisu rozvodných sítí do 3D modelů měst. ADE tvoří obecný rámec pro definování sítí konkrétních rozvodů (elektřina, plyn, pitná a odpadní voda). Základem je
implementace síťového grafu, který je tvořen uzly (třída Node) a hrany (Edge). Ty jsou ve struktuře ADE
podřízeny třídám Network, NetworkGraph, FeatureGraph a NetworkFeature. Zmíněné rozšíření umožňuje
provádět síťové analýzy a simulace v rozvodných sítích. V neposlední řadě umožňuje také vyjádřit síťové
komponenty jako 3D objekty (BECKER et al, 2010).
Skutečnosti, že CityGML umožňuje modelovat i vnitřní členění budov a interiérů, využívají rozšíření
pro BIM (Building Information Modeling) a CAFM (Computer Aided Facility Management), obě jsou
určeny pro správu informací o budovách (bližší informace viz: HERMAN, 2011a). Obdobné informace o
56
druzích povrchů v interiérech obsahuje i rozšíření vyvíjené společností Hitachi, které má sloužit jako podklad pro optimalizaci automatického pohybu robotů v interiérech (OGC, 2012b). Formátu CityGML
lze rovněž využít ve spojení rozšířenou realitou (augmented reality). Příkladem může být oblast námořní
navigace, když jsou promítány 3D informace, důležité k navigaci u pobřeží nebo v přístavu, do okulárů
speciálního dalekohledu kormidelníka lodi (HAASE et al, 2010). Své místo má CityGML i při simulaci
silniční dopravy a krizovém managementu. Těmto oblastem se věnují společnosti Rheinmetall Defence
Electronics a CPA Geoinformation.
4.2 CityGML 2.0
Nová verze CityGML byla původně schvalována jako verze 1.1, posléze se přešlo na označení 2.0. Mezi
hlavní novinky patří zavedení nových sémantické třídy pro mostní konstrukce (AbstractBridge) a tunely
(AbstractTunnel). Sémantika obou tříd (atributy a podřízené třídy) vychází do značné míry ze sémantické
struktury třídy AbstractBuilding, například třída TunnelPart je ekvivalentem BuildingPart (OGC, 2012b).
Sémantika třídy budov byla rovněž mírně modifikována přidáním dvou nových prvků z třídy BoundarySurface, a to OuterCeilingSurface (např. strop balkonu) a OuterFloorSurface (podlaha terasy). Další
úpravou třídy Building je její doplnění i do LOD0 ve formě 2D polygonu, což může být buď půdorys,
nebo průmět obvodu střechy. Byly přidány i nové atributy, například relativeToTerrain a relativeToWater
pro vyjádření pozice objektu vůči povrchu terénu nebo vodní hladině. Upravena byla i podoba číselníků.
Úspěšná migrace z CityGML 1.0 instancí do verze 2.0 vyžaduje změnu jmenných prostorů a umístění
schémat na aktuální (2.0) hodnoty (OGC, 2012b).
4.3 Datové specifikace INSPIRE
CityGML bylo použito i při návrhu datových specifikací v rámci směrnice INSPIRE, konkrétně tématu
prostorových dat Budovy. Ze CityGML byla k tomuto účelu použita část popisující budovy (na nejvyšší
úrovni je třída AbstractBuilding). CityGML se ale s datovými specifikacemi INSPIRE obsahově překrývá
i v jiných tématech. Tento překryv je naznačen v tabulce 4.1. Nutno dodat že se však jedná o překryv z
hlediska tematického. 3D geometrie, která je neoddělitelnou součástí standardu CityGML, je v rámci
datových specifikací směrnice INSPIRE začleněna především do témat prostorových dat Elevation (nadmořská výška) a Buildings (budovy).
4.3.1 Téma prostorových dat Budovy (Buildings)
Kromě standardu CityGML bylo při tvorbě datové specifikace tématu prostorových dat budovy využito také datový model LADM (Land Administration Domain Model), který popisuje budovy z hlediska
katastru nemovitostí, označovaný také jako standard ISO 19152 (draft verze). Pro číselníky je částečně
použita klasifikace Eurostatu.
Nejvyšší úroveň sémantiky základního 2D profilu představuje třída AbstractConstruction. Této třídě jsou
podřízeny třídy OtherConstruction, která reprezentuje objekty, jako jsou např. mosty, tunely, protihlukové bariéry nebo vysílače, a AbstractBuilding, jenž blíže popisuje budovy (tyto třídy musí mít přiřazenu
geometrii). Třída AbstractBuilding dále sdružuje třídy Building a BuildingPart, což je koncept vycházející
z vyjádření budov v CityGML. Povinnou částí je geometrie. Mezi atributy, které popisují třídu AbstractConstruction patří kupříkladu výška objektu, datum výstavby nebo demolice. Rozšířený 2D profil obsahuje oproti základní variantě navíc atributy popisující architekturu budovy (typ střechy, materiál omítky,
počet pater) a katastrální informace, např. oficiální výměra. Navíc jsou zařazeny i další třídy, konkrétně
Installation (zařízení) a BuildingUnit, zařazená pod třídy Building a BuildingPart, která představuje část
budovy homogenní z hlediska managementu (DS BUILDINGS, 2012).
57
Tab. 4.1 Vztah témat prostorových dat podle směrnice INSPIRE a sémantických tříd standardu CityGML 1.0
Příloha
Téma prostorových dat INSPIRE
I
Dopravní sítě (Transport networks)
Třída v CityGML 1.0
TransportationObject
II
Vodstvo (Hydrography)
WaterObject
II
Nadmořská výška (Elevation)
ReliefFeature
II
Krajinné pokrytí (LandCover)
VegetationObject, LandUse
III
Budovy (Buildings)
AbstractBuilding, CityFurniture,
III
Využití území (LandUse)
III
Veřejné služby a služby veřejné správy (Utility and governmental
services)
LandUse
Abstract Building, CityFurniture
III
Výrobní a průmyslová zařízení (Production and industrial
facilities)
Abstract Building, CityFurniture
Tab. 4.2 Profily a aplikační schémata v tématu prostorových dat Budovy (převzato z DS BUILDINGS, 2012)
Jednodušší sémantické informace
Bohaté sémantické informace
2D (a 2.5D)
geometrie
Core 2D profil (základní a core 2D aplikační schéma)
Rozšířený 2D profil (základní a rozšířené 2D
aplikační schéma)
Plnohodnotná 3D
geometrie
Core 3D profil (základní a core 3D aplikační schéma)
Rozšířený 3D profil (základní a rozšířené 3D
aplikační schéma)
Geometrie základního 3D profilu je založena na datovém modelu reprezentace hranic. Jeho podrobnost
je definována, v případě 3D geometrii, od LOD1 až po LOD4. Tyto LOD jsou převzaty z CityGML.
Povolená je však i 2D geometrie. Sémantický model základního 3D profilu se shoduje se základním 2D
profilem. Rozšířený 3D profil rovněž vychází z modelu budov v CityGML, geometrie může být jak, 2D
tak 3D (opět CityGML LOD1 až LOD4). Sémantické třídy vycházejí z rozšířeného 2D profilu, ale navíc
obsahuje rozšířený 3D profil i charakteristiky stěn, střech, oken nebo dveří. Dále může obsahovat také
odkazy na textury (DS BUILDINGS, 2012). Oba 3D profily podporují také prvek terreinIntersection,
což je obdoba TIC z CityGML.
Základní (base) aplikační schéma obsahuje definice prvků společných pro ostatní schémata a tedy i všechny čtyři profily. Předně jsou to definice datových typů a číselníky. Základní klasifikace budov, je prováděna
jak na základě využití budovy (číselník CurrentUseValue) tak podle konkrétního druhu objektu (číselník
BuildingNatureValue). Pomocí číselníku (HorizontalGeometryReferenceValue) je popsáno jakému rozměru budovy vlastně odpovídá daná geometrie, která tak nabývá kupříkladu hodnot footprint (půdorys),
roofEdge (průmět obvodu střechy) nebo envelope (ohraničující pravoúhelník). Obdobně ElevationReferenceValue upřesňuje, který výškový údaj má objekt přiřazen (DS BUILDINGS, 2012). Pro všechny profily je rovněž společný koncept externalReference, tedy odkaz na další informace o daném objektu, což je
další společný prvek s CityGML.
4.4 Webové služby pro 3D data
Kromě standardizace 3D formátů existují i snahy o standardizaci 3D webových služeb. Konkrétně jde o
služby WPVS (Web Perspective View Service) a W3DS (Web 3D Service), ani jedna nebyla dosud oficiálně
schválena. K WPVS jsou dostupné materiály Discussion Paper a W3DS existuje jako návrh (Draft), ačkoliv jsou zpracovávány od roku 2005, respektive 2001. WPVS byla zpočátku vyvíjena pod názvem WTS
(Web Terrain Service) a označuje také jako WVS (Web View Service). Tato služba vrací na serveru renderované pohledy na scénu (tedy 2D rastrové obrazy). Služba vrací odpovědi na dotazy GetCapabilities,
GetView (povinné), volitelně GetDescription a GetLegendGraphic (OGC, 2010b).
58
Služba W3DS naproti tomu vrací 3D geometrii a informace o vzhledu objektů (vektorová 3D data, která
mohou být doplněna o rastrové textury) ve formě grafu scény. Výstup je buď ve formátu X3D. Klientská
aplikace pak provádí vykreslování pohledů, čímž se tato služba odlišuje jak od WPVS, tak od WFS, kde
aplikace musí nejdříve graf scény vytvořit v klientovi. Služba vrací odpovědi na dotazy GetCapabilities,
GetScene (povinné), volitelně GetFeatureInfo, GetLayerInfo a GetTile (OGC, 2010a)
Mezi serverové řešení, které poskytují W3DS patří CityServer3D. Je to modulární klientsko-serverový
systém, vyvíjený v IGD Fraunhofer. Dále může poskytovat i WMS nebo vlastní proprietární webovou
službu. Využívat může data uložená v databázích MySQL, Oracle nebo PostGIS. Jako referenční implementace WPVS specifikace byla vyvinuta HPI Web View Service (SCHILLING et al, 2012).
Obr. 4.9 Srovnání služeb WFS (Web Feature Service), W3DS a WPVS (upraveno podle OGC, 2010a)
Příkladem klientské aplikace primárně určené pro W3DS je XNavigator. Dále podporuje WMS (Web
Map Service), SOS (Sensor Observation Services), WPS (Web Processing Service) a Catalogue Service for
Web (CS-W). Díky tomu, že je vytvořen pomocí Java3D a J2SE (Java 2 Platform, Standard Edition). Je
platformě nezávislý. Tento nástroj je využíván kupříkladu v projektu OpenStreetMap-3D. Další klientskou
aplikací je engine BSContact Geo od společnosti Bitmanagement Software GmbH určený pro vizualizaci
3D prostorových dat v aplikacích třetích stran. Podporuje CityGML a komponenty (tagy) pro manipulaci s geografickými souřadnicemi z formátů X3D a VRML (OGC, 2012a).
Obr. 4.10 Provázání dat poskytnutých W3DS (v levé části) a WPVS (vpravo) v prohlížeči XNavigator při 3DPIE (převzato z
OGC, 2012a)
Všechny výše zmíněné aplikace a jejich vzájemná interoperabilita byly poměrně úspěšně testována v rámci
OGC, jako tzv. 3D Portrayal Testing Experiment (3DPIE).
59
4.5 Projekty využívající 3D geoinformační standardy
4.5.1 3D model Berlína
V praxi je pořizování 3D dat komplexní úkol, a tak dochází ke kombinaci trojrozměrných dat získaných z
různých zdrojů. Příkladem může být právě 3D model Berlína, pro která byly použity data z katastru nemovitostí, digitální model terénu (DTM), letecké snímky a 3D model budov pořízených LiDARem (Ligth
Detection And Ranging nebo Laser Induced Detection And Ranging). Pro ukládání dat slouží 3D City
Database (3DCityDB), což je open source 3D geodatabáze založená na Oracle 10G R2 / 11G. Databázový model zohledňuje hierarchickou i sémantickou strukturu a víceúrovňovou reprezentaci. K importu a
exportu 3D modelů do této databáze slouží 3D City Database Import/Export Tool. Export může probíhat do formátů CityGML, KML (Keyhole Markup Language) nebo COLLADA. Pro zpracování 3D dat
je určena open source Java knihovna a API citygml4j. Pro editaci 3D modelu byl využíván také program
LandXplorer Studio Profesional od společnosti Autodesk (DŐLLNER et al, 2006).
Obr. 4.11 3D model Berlína, vlevo Braniborská brána fotorealistická vizualizace pro virtuální turistiku, vpravo zobrazení potenciálu pro umístění solárních panelů na střechách (převzato z HERMAN, 2011b)
Model Berlína může být zobrazován ve fotorealistické podobě, kterou si lze prohlédnout po transformaci
do formátu KML v programu GoogleEarth. Model je však zároveň využíván i při nefotorealistické vizualizaci. Projekt SIMKAS 3D do 3D modelu integruje informace o inženýrských sítích. Další projekt SolarAtlas Berlin se zabývá optimalizací rozmístění solárních panelů na základě modelu města (DŐLLNER
et al, 2006; HERMAN, 2011b)
4.5.2 Hlukové mapování v Severním Porýní - Vesfálsku
Jak již bylo zmíněno, součástí specifikace CityGML 1.0 je ADE pro hlukové mapování Bylo vyvinuto
v rámci projektu EU-Umgebungslärmkartierung in NRW a vychází i z Geodata Infrastructure North
Rhine-Westphalia (GDI NRW).
Toto GDI vzniklo jako společná iniciativa ministerstev zemské vlády spolkové země Severní Porýní –
Vestfálsko a zdejší zemské mapovací agentury (CZERWINSKI et al, 2008). GDI NRW používá CityGML a rastrový GeoTIFF jako jediné výměnné formáty mezi webovými službami a softwarem počítajícím
hlukovou zátěž. Použitá data i celková struktura ADE je dána směrnicí evropského parlamentu a rady
2002/49/ES ze dne 25. června 2002 o hodnocení a řízení hluku ve venkovním prostředí, která ukládá
členským státům povinnost zjišťovat každých 5 let hlukovou zátěž na budovách ve výšce 4 m od povrchu
země. Zároveň stanovuje základní metodiku výpočtů. Úroveň hluku je tak vypočítávána zvlášť pro denní
(6:00 – 18:00), večerní (18:00 – 22:00) a noční (22:00 – 6:00) dobu (OGC, 2008).
60
Obr 4.12 Vizualizace hlukové zátěže vypočtené pomocí 3D modelu (převzato z GRŐGER et al, 2008).
Model používaný pro výpočty je tvořen rastrovým DTM, 3D budovami doplněnými o atributy 3D daty o
dopravních komunikacích s atributy a daty o hlukových bariérách (blíže viz kapitola o ADE). Jednotlivé
třídy mají úroveň podrobnosti LOD0 nebo LOD1 (podtřídy, které jsou omezeny na podrobnější LOD
jsou vynechány). Použit je rastrový reliéf, budovy (LOD1), landuse a dopravní komunikace (LOD0). Naopak vypuštěny jsou celé třídy VegetationObject, CityObjectGroup a WaterObject. Jednotlivé datové třídy
nejsou uloženy v jednom úložišt, ale vektorová data jsou poskytována pomocí WFS a rastrový model
terénu pomocí WCS (Web Coverage Service). Výsledkem výpočtů je pak rastrová mapa hlukové zátěže,
která je publikována pomocí služby WMS (CZERWINSKI et al, 2008).
4.5.3 Výpočty energetické bilance budov
K další významné oblasti použití CityGML patří problematika stanovení energetických nároků budov.
3D modely zde využívány pro výpočty objemů budov, ploch jednotlivých stěn (zdi, střechy) nebo stanovení ploch společných (sousedních) stěn. S těmito údaji je pak možné porovnat data o spotřebě energií, určit
na kterých ukazatelích je spotřeba nejvíce závislá a v neposlední řadě zda, a jakým způsobem, je možné
energii uspořit. Data o energetických nárocích budov, je možné také dále kombinovat s údaji o potenciálu
pro umísťování solárních panelů, čímž je možné stanovit celkovou bilanci jednotlivých budov. Pro optimalizaci rozmístění solárních panelů na budovách jsou důležité především výpočty zastínění. I relativně
malý stín (tvořené například anténou nebo komínem) způsobuje významné ztráty při produkci energie
takto ovlivněným solárním panelem. Pro tyto účely navrhli pracovníci HFT Stuttgart. Jako zdrojová data
se používá CityGML model zástavby v LOD2 (EICKER et al, 2010; STRZALKA et al, 2011).
Modelové území pro výpočty energetické bilance představuje město Ludwigsburg. Zatím se k výpočtům
používají jen modely budov, do budoucna se plánuje rozšíření i o další prvky (např. vegetaci). Princip výpočtů však zůstane stejný. Ke zpracování výpočtů vyvíjí vlastní Java aplikaci a zároveň využívá i serverovou
aplikaci CAT3D, ve které jsou integrována podkladová data. Velký význam má však při analýze CityGML dat validace geometrie v rámci předzpracování. Validní geometrie je totiž základním předpoklad pro
úspěšné provedení dalších analytických operací, jako jsou výpočty povrchů nebo objemů. K validaci a
kontrole dat je na HFT aplikace vyvíjena aplikace CityDoctor (EICKER et al, 2010; STRZALKA et al,
2011).
61
4.6 Shrnutí
Protože je 3D modelování poměrně progresivním oborem, je většina aktuálních studijních materiálů k
dispozici na internetu. Weby www.citygml.org a www.citygmlwiki.org obsahují informace o CityGML,
přehledy volně dostupných datových sad, komerčních i nekomerčních programů, dostupných rozšířeních
nebo publikovaných článků. Další materiály nejen k problematice CityGML, ale i o W3DS a WPVS jsou
dostupné na webu OGC. Web Joint Research Centre ( JRC) obsahuje informace o datových specifikacích
INSPIRE a to i v případě tématu prostorových dat budovy.
Podpora 3D geometrie, sémantické modelování a přizpůsobivost datových struktur jsou společné znaky a
zároveň přednosti formátu CityGML a tématu prostorových dat. Tyto datové modely jsou v kombinaci s
aplikačními daty multifunkční a tudíž vhodné pro široké spektrum uživatelů.
62
5. PUBLIKACE DAT ZE SENZOROVÝCH SÍTÍ
Petr DUDA
5.1 Úvod
Úspěšnost integrace spolehlivých, aktuálních a okamžitě využitelných informací do geoinformačních
infrastruktur je podmíněna fungujícím provázáním geoinformační infrastruktury se senzorovými sítěmi, které jsou dnes za určitých podmínek již schopny tyto informace poskytovat. Díky technologickému
vývoji v oblasti miniaturizace elektroniky a elektrotechniky je možné sestavovat malá a poměrně levná
elektronická zařízení, která jsou schopna sledovat jednu nebo více vlastností svého okolí, tyto informace
zaznamenávat, podle požadavků uživatele předzpracovat, a odesílat v digitální podobě. Celé takovéto výpočetní systémy lze dnes umístit do jednoho čipu. Jsou malé (i ve velikosti větší mince), poměrně levné
(v cenové relaci nižší než 1000 USD za kus) a v současné době velmi často schopné komunikovat se svým
okolím pomocí bezdrátové technologie (prostřednictvím integrované radiostanice, infračerveného vysílače apod.).
Takováto zařízení jsou pro pokrytí určitého území často sdružována do komunikační sítě. Poté si vzájemně
mohou vypomáhat při předávání informací o stavu prostředí, v němž se nachází, k dalšímu zpracování do
vzdáleného místa. V takovém případě hovoříme o senzorové síti. Jednotlivá zařízení, která síť tvoří, se
poté označují jako uzly (nody) senzorové sítě. Pomocí velkého počtu těchto malých senzorových uzlů je tak
možné pokrýt i velké území a sledovat různé jevy, v závislosti na účelu takové senzorové sítě.
Automatické senzory, organizované v senzorových sítích, umožňují získávat informace o sledovaném jevu
rychle, podrobně, na poměrně velkém území a za tak nízkých nákladů, o kterých se nám dříve ani nesnilo.
Tyto kladné vlastnosti jsou ovšem vyváženy celou řadou ale. Existuje velké množství druhů senzorů, z
nichž každý má svá specifika (např. přesnost, spotřebu energie aj.), komunikace mezi jednotlivými senzory
a místem sbírajícím informace je značně komplikovaná, části přenášené informace se často ztrácejí a získaná data je vždy nutno prověřovat, neboť vzhledem k odlehlé poloze senzorů nevíme jistě, zdali jsou získané
hodnoty ovlivněny nějakou nepředvídanou událostí, změnou nastavení či dokonce poruchou senzoru.
Senzory také vždy nemusí zcela pokrývat celý fenomén. Geoinformační infrastruktury, které integrují
senzorová data, by měly být na tato specifika připraveny tak, aby na ně uživatel mohl reagovat, a aby taková
data byla případně nahrazena jiným, dostatečně adekvátním způsobem.
Největší překážku v pochopení různých omezení a slabých míst v datech z především automatizovaných
senzorových sítí je stále způsob, jakým jsou tyto sítě a jejich jednotlivé komponenty projektovány a jakým
způsobem je omezena či naopak rozšířena jejich funkčnost. Geografické systémy využívající živá senzorová data musí v řadě svých aplikací brát specifika architektury a pracovního procesu senzorových sítí
v potaz. V případě, že chceme, aby naše aplikace byla schopna zajišťovat výstupy ze senzorových dat v
reálném čase či pro bezpečnostní infrastrukturu či aplikace, na kterých je závislé lidské zdraví, je nutné se
ještě hlouběji zaměřit na výpočetní mechanismy a softwarovou vybavenost jednotlivých senzorů tak, aby
senzorová síť i výsledná aplikace byly dostatečně spolehlivé pro řešení daných úkolů.
V následujících odstavcích si přiblížíme některé zásadní vlastnosti senzorových sítí, jejich obvyklou architekturu a vlastnosti jejich komponent. V druhé části této kapitoly se zaměříme na specifické vlastnosti dat,
pocházejících ze senzorových sítí, a představíme si některé přístupy, jež umožňují plné využití senzorových
sítí v geoinformačních systémech.
Systémy, v nichž se tyto přístupy aplikují, nacházejí uplatnění v mnoha odvětvích lidských aktivit, od
sledování životního prostředí, přes bezpečnostní aplikace v armádě či policii, dopravu (např. s jakým
zpožděním budete muset počítat, ať už jedete autem či letíte letadem), až po vytváření tzv. chytrého
domova (např. regulace topení, osvětlení, zabezpečení, přesměrování audiovizuálních datových toků
63
apod.). Kontrolu stavu jednotlivých sledovaných objektů pak lze provádět i vzdáleně, například přes
internet, a to nejen pomocí klasických webových služeb, ale i pomocí chytrých telefonů či obdobných
zařízení. Spojením technologie Web 2.0 s mikrokontroléry senzorů tak lze vytvořit efektivní zdroj
informací a služeb, dostupný různým uživatelským vrstvám.
Dále jsou uvedeny základní skladební kameny senzorové sítě a popsány způsoby jejich propojení s geoinformačními infrastrukturami.
5.1.1 Senzory a aktuátory
Senzor (čidlo, snímač) je základní stavební jednotkou senzorové sítě. Obecně jej lze definovat jako zdroj
určité informace o prostředí, v němž se nachází. Obvykle se jedná o zařízení, které reaguje na určitý stimul
určitým deterministickým způsobem, a to např. produkcí signálu. Signál lze přenášet na dálku tak, aby
byl čitelný pro pozorovatele či jiné zařízení, např. řídicí systém (tj. i mozek). Každý senzor tedy sleduje
určitou vlastnost vnějšího prostředí. Tato vlastnost (angl. property; např. fyzikální veličina) v určitém časovém bodě (úseku) určuje či identifikuje určitý jev (fenomén; angl. phenomenon), jenž je takto sledován
(pozorován). Pozorovaná vlastnost je obvykle senzorem transformována do odlišné reprezentace (obvykle
elektrické či mechanické). Tato vnitřní reprezentace je označována jako signál1 a je odesílána vně senzoru
k dalšímu zpracování. Za senzor lze považovat i člověka, pokud nasbíraná data (mohou být jak kvantitativní, tak kvalitativní povahy) předává dále ke zpracování (KLOPFER et al, 2009; CHATZIGIANNAKIS
et al, 2007).
Aktuátor (akční člen, servopohon; angl. actuator) je druh motoru, který přeměňuje vstupní signál na pohyb. Příkladem aktuátoru může být elektrický motor, hydraulický píst, relé, elektroaktivní polymer aj. V
senzorových sítích je často využíván pro ovládání senzorů, jejich pohyb a nastavení (YICK et al, 2008).
V určitém ohledu je aktuátorem i lidský sval; případně celý člověk, je-li instruován systémem k nějaké
fyzické akci.
Aktuátory tak lze považovat za opak senzorů, neboť zatímco od senzorů systém informace přijímá, aktuátory naopak řídí. Ovšem za určitých okolností lze obvykle aktuátory také využít jako senzory.
Převodník (převaděč, měnič, převáděcí člen; angl. transducer) je souhrnné označení skupiny zařízení, které
převádí energii z jedné formy do jiné. Mezi převodníky patří mj. např. i mikrofony, reproduktory, teploměry, fotovoltaické články, žárovky či antény. Převodník je tedy nadřazeným pojmem pro pojmy senzoru
a aktuátoru.
5.1.2 Typy senzorů
Existuje velké množství zařízení, které lze podle předchozí definice označit za senzory. Mezi senzory tak
lze zařadit jak zařízení produkující jednoduchou informaci v určitém místě a čase, a to jak s analogovým
signálem, např. rtuťový teploměr (produkuje jednoduchou analogovou informaci o teplotě), srážkoměr,
seismograf, tak i jednoduché senzory digitální, jako například snímač polohy (např. GPS přijímač), scintilační detektor, radar, aj.
Mimo tato zařízení existují i senzory, které produkují komplexní informaci, tedy informaci skládající se z
více dílčích informací, např. videokamery či detektory více druhů chemických látek. Jako senzor tak lze
chápat nejen jednoduché čidlo, ale taktéž soubor čidel, které měří různé charakteristiky v jednom místě a
čase (tzv. komplexní senzor).
1 Např.: frekvence otáček hydrologické vrtule je reakce vrtule, ponořené do řeky, na proudění vody (vlastost) v řece (fenomén).
Pomocí indukční cívky (či čítače otáček) připevněné na ose vrtule se v závislosti na frekvenci indukuje určité napětí (nebo se načte
počet otáček za určitou časovou jednotku), a to je vodičem odváděno jako signál k dalším zpracování (signál tak může být jak
analogový, tak digitální). Pomocí hodnoty napětí (či frekvence otáček) a příslušných technických parametrů vrtule tak lze spočítat
rychlost proudění vody v daném místě. To však může být učiněno již v řídící jednotce této hydrologické vrtule a jako signál se poté
mimo senzor dostává již výsledná hodnota rychlosti.
64
Komplexní senzor (KLOPFER et al, 2009) se obvykle používá v situaci, kdy požadovaná vlastnost či fenomén nemůže být pozorován pomocí jediné senzorové technologie. Informaci o jednotlivých pozorovaných jevech – součástech komplexního jevu – však je možné zpracovat a výslednou informaci o komplexním jevu tak získat syntézou jednotlivých naměřených veličin. Takové senzory již zpravidla využívají ke
komunikaci výhradně digitální signál. Abstraktní model komplexního senzoru je uveden na obr. 5.1 vlevo.
Senzor, který podává jedinou informaci o jednom jediném jevu, ačkoli jej pozoruje na digitální bázi jedním či více způsoby a na výstup vysílá analogový signál, se někdy označuje jako simulovaný analogový
senzor1.
Obr. 5.1 Blokové schéma komplexního senzoru (vlevo) a blokové schéma senzorového systému (upraveno podle KLOPFER et
al, 2009)
Uvnitř senzoru je také možné další zpracování signálu (např. linearizace, upravení kalibračními koeficienty, transformace do jiného druhu reprezentace a další úpravy dat pro výstup ze senzoru). Pokud senzor
poskytuje doplňující funkce, které nejsou nutné ke generování korektní reprezentace pozorované veličiny,
je označován jako chytrý senzor (smart sensor).
Podoba a funkčnost chytrého senzoru je upravena rodinou standardů IEEE 1451 (IEEE, 2000). Tyto
standardy popisují univerzální a na konkrétní síti nezávislá komunikační rozhraní pro připojování senzorů k mikroprocesorům či přístrojovým systémům, jejichž propojením a spoluprací chytré senzory vznikají.
Chytré senzory obvykle bývají malé, lehké a s minimální spotřebou, a skládají se z jednoho nebo více čidel,
A-D převodníku2 , řídící jednotky, vnější paměti, vysílače s přijímačem a zdroje energie. Takováto jednotka je často schopna přijímat data i z dalších senzorů v síti, sama je předzpracovat (např. agregovat) a poté
odeslat buď dalšímu uzlu, nebo výstupnímu zařízení sítě. V případě, že jsou tato zařízení schopna určitých
samostatných úkolů při práci s příchozími a odchozími daty, jsou často označována jako mote. Tato zařízení dnes tvoří základní komunikační uzly bezdrátových senzorových sítí. Obecný model chytrého senzoru
podle IEEE 1451 je zobrazen na obr. 5.2.
Jako virtuální senzor je poté označováno zařízení, které obsahuje fyzický převaděč (senzor), zařízení pro
úpravu signálu a digitální zpracování signálu. Virtuální senzor je vždy součástí chytrého senzoru (LEWIS,
2005)
V některých publikacích jsou však jako virtuální senzory označovány i tzv. sběrné body v matematických
modelech. Výstupní data z mnohých matematických modelů mají často formu podobnou datům ze senzorů, proto lze některé přístupy pro řízení a správu senzorových dat použít i pro data vypočítávaná.
1 Simulovaným analogovým senzorem může být např. hydrologická vrtule popsaná v poznámce 1. Tento typ senzoru je nutno
odlišovat od simulovaných senzorů či simulovaných senzorových sítí obecně. Simulace činnosti senzorů či celých senzorových sítí se
obvykle provádí matematickým modelováním pomocí počítačů a obvykle slouží k testování funkčnosti navrhovaných instrukcí pro
práci senzorové sítě před jejich nasazením do fyzické sítě. 2 Převodník analogového signálu, nesoucího informaci z čidla, do digitálního signálu, jež může být dále výpočetně zpracován.
65
Obr. 5.2 Blokové schéma obecného modelu chytrého senzoru (upraveno podle LEWIS, 2005)
Je třeba zmínit, že umístění senzoru se může lišit od umístění sledovaného objektu. Taková situace nastává vlastně u všech zařízení, provádějících dálkový průzkum (radary, videokamery aj.). Zatímco zařízení
in-situ jsou obvykle umístěna v těsné blízkosti sledovaného objektu, takže jejich polohu a polohu sledovaného jevu lze (pro danou aplikaci) považovat za identickou. (KLOPFER et al, 2009)
I samotný signál ze senzoru však může být přenášen na dlouhé vzdálenosti. To lze zajistit jak různými druhy signálních vodičů (elektrické či optické kabely, hydraulická vedení, lana aj.) nebo bezdrátově (obvykle
radiovým či infračerveným signálem), tak i člověkem (např. přenášejícím vzorek vody do laboratoře). Rozlišujeme tedy vedením připojené (drátové, wired) a bezdrátové (wireless) senzory.
Velmi důležitým poznatkem, který ovlivňuje aplikaci senzorových dat v geoinformačních systémech je
skutečnost, že období mezi pozorováním a výstupem zpracovaného signálu ze senzoru (i sítě) je vždy
nějak dlouhé, přičemž zpracování daného signálu může probíhat postupně na více místech. Časový a prostorový kontext1 pozorování však musí být pro jednoznačnou identifikaci výsledných dat vždy zachován
(KLOPFER et al, 2009).
Z hlediska časové proměnlivosti pozice lze senzory rozdělit na mobilní (které snímají informace plynule
během pohybu), semimobilní (které lze přemisťovat a sbírat s nimi informace na různých místech) a statické, které jsou určeny k instalaci na jedno místo, a z nichž zjišťované hodnoty mají vždy jasný prostorový
kontext.
5.1.3 Systém senzorů
Více senzorů i aktuátorů (ať již analogových, nebo komplexních) různých druhů může být kombinováno
do senzorového systému. Senzorový systém obvykle tvoří fyzický celek, ale není to vždy nutností. Příkladem senzorového systému je satelit (fyzická konstrukce satelitu je ovšem označena termínem platforma,
nikoli termínem senzor), na němž jsou připevněny různé dálkové senzory a senzory indikující vnitřní stavy satelitu. Dalšími příklady mohou být meteorologická stanice, či zdravotní stanice kombinující senzory
pro měření krevního tlaku a pulsu.
Senzorový systém dovoluje správu nejen jednotlivých senzorů, ale též i systému senzorů jako celku. K
tomu slouží rozhraní správy senzorového systému. Klíčovou vlastností senzorového systému je jeho jednotné rozhraní výstupu a řízení, které reflektuje jeho organizační strukturu (senzory lze řídit jednotlivě i v
celém systému podle určitých kritérií).
1 Tj. v jakém místě (absolutně i relativně k jiným objektům a prostředí v okolí) a čase bylo pozorování uskutečněno. Například v
případě, že jsou odebírány vzorky půdy pro jejich analýzu v laboratoři, musí být jasně patrné, na kterých místech, kým, kdy, za jakých
okolností a jakou technikou byly tyto vzorky odebrány, jakým způsobem byly dopraveny do jaké laboratoře, a kdy, jakým způsobem
a kým byly zpracovány.
66
Na rozdíl od komplexního senzoru (který se uživateli jeví jako nerozborný celek) umožňuje senzorový
systém přímé adresování jeho jednotlivých částí (podsystémů, senzorů), jakož i celého systému. Tento
rozdíl se projevuje především v rozhraní správy senzoru, ovšem nemá vliv na podobu odezvy senzoru.
Jak komplexní senzor, tak i senzorový systém může poskytovat data vysledovatelná k jejich jednotlivým
částem. Abstraktní model senzorového systému je uveden na obr. 5.1 vpravo.
5.2 Senzorové sítě
Senzorová síť je definována jako skupina specializovaných převodníků (senzorů a aktuátorů), jež jsou propojeny komunikační infrastrukturou, a jsou určeny pro sledování a ukládání informací o podmínkách v
odlišných místech prostředí (KLOPFER et al, 2009). Moderní senzorová síť obvykle sestává z množství
sběrných či komunikačních uzlů, označovaných jako (senzorové) uzly (nody).
Senzorová síť však nemusí být pouze elektronická, za svého druhu senzorovou síť lze považovat například
i soustavu analogových sond, z nichž je jednou za čas fyzicky ("ručně") odebírána či odečítána informace,
ruční sčítání provozu na pozemních komunikacích, kdy jsou sčítací komisaři systematicky rozmístěni na
silniční síti a do notýsku si zapisují druhy a počty projíždějících vozidel, podobně jako hlídky policie, které
v případě přetížení komunikace uzavírají z obou stran dopravu. Charakter senzoru či aktuátoru tak není
v abstraktním konceptu rozhodující, důležité je pouze to, zda jsou nějaké informace o prostředí sbírány a
nějakým způsobem odesílány k uložení či dalšímu zpracování.
5.2.1 Způsoby přenosu dat v senzorových sítích
Jednou ze základních vlastností senzorových sítí, která do značné míry předurčuje výpočetní a komunikační schopnosti senzorových uzlů i sítě jako celku, je použitý druh nosiče pro přenos dat v senzorové síti.
Pokud je jako přenosové médium použit pevný vodič, hovoříme o drátových senzorových sítích (wired sensor networks), pokud se využívá bezdrátového spojení (především radiového, ale může být použito i např.
infračervené záření nebo zvukové vlny), jedná se o bezdrátové senzorové sítě (wireless sensor networks).
Právě bezdrátové sítě zažívají v poslední době značný rozvoj, a to především z toho důvodu, že dochází ke
značné miniaturizaci elektronických součástek i senzorů, snižování energetické náročnosti jejich provozu
a zlevňování jejich výroby, a to při zachování jejich funkcí. Takové senzory je pak možné rozmístit velmi
hustě, na rozsáhlá území nebo umístit do různých dálkově ovládaných zařízení a zařízení s omezeným
prostorem či nosností (např. bezpilotních letadel, inspekčních robotů, vrtných souprav, miniponorek aj.).
Oba typy sítí lze podle potřeby kombinovat.
Posledním způsobem propojení senzorů do komunikační sítě je použití agentů. Agent je autonomní entita
(např. robot či člověk), který fyzicky zajišťuje sběr a přenos dat ze senzorů do datového skladu, případně
provádí kalibrace a nastavení senzorů (sběrných míst).
Obecně lze říct, že v senzorové síti existují dva dominantní směry informačních toků. Jedním směrem
jsou sbírána a odesílána senzorová data k uživateli (aplikaci), druhým směrem jsou od základového uzlu k
jednotlivým senzorům posílány řídící a kontrolní příkazy. Na nižších vrstvách síťového modelu je ovšem
situace jiná, neboť pomineme-li fakt, že před každou výměnou dat musí dojít k nalezení cesty, navázání
spojení a v průběhu provozu sítě musí být toto spojení udržováno, jednotlivé uzly jsou schopny i určité
samostatné práce při některých úlohách, jako je například rozpoznávání sousedů pro komunikaci, oprava
chybně přijatých zpráv, určování vlastní polohy v síti, agregaci a předzpracování senzorových dat aj.
Obecný model komunikace v senzorové síti je znázorněn na obr. 5.3. V moderních senzorových sítích,
zvláště těch bezdrátových, neproudí každá senzorová informace přímo od daného senzoru do základové
stanice a dále k uživateli. Jednotlivé senzorové uzly si v přenosu informace vypomáhají. Určitá informace
(ať už senzorová, nebo řídící) tak dorazí k cíli až po několikátém přeskoku mezi jednotlivými senzorovými
uzly. Tento způsob spojení značně snižuje energetickou náročnost vysílání a zvyšuje spolehlivost přenosu
67
dat. Vzhledem ke snížení počtu přenosů jsou data během přenosu v jednotlivých uzlech sítě agregována a
různým způsobem předzpracovávána.
Obr. 5.3 Obecný model komunikace v senzorových sítích (upraveno podle AKYILDIZ et al, 2002)
Cesta, jakou data v dané síti od konkrétního zdroje ke konkrétnímu cíli proudí, je určována pomocí směrovacích mechanismů. Těchto mechanismů existuje celá řada. Obecně je lze rozdělit mezi statické (kdy
jsou jednotlivé cesty mezi uzly určeny již před spuštěním sítě a nelze je měnit) a dynamické (které nejen
že v době běhu sítě měnit lze, ale také je možné tyto cesty přizpůsobovat aktuálnímu stavu sítě, např. poruchou či přidáním nového uzlu). Dynamické směrování je jednou z podmínek, které umožňují vytvářet
tzv. samoorganizující se senzorové sítě.
5.2.2 Výhody a nevýhody drátových a bezdrátových senzorových sítí
Mezi hlavní nevýhody drátových senzorových sítí patří především nutnost vést fyzické vedení mezi všemi
uzly sítě. Bezdrátové senzory mohou být, na rozdíl od bezdrátových, umisťovány i na plně mobilní zařízení. Drátové senzory jsou také často, pro úsporu vedení, zapojené v sériích či větších shlucích, což může
při poruše jednoho spoje odstavit celou síť. Hledání poruchy poté může být velmi náročné. V některých
případech také bývá velmi nepraktické, až nemožné, vůbec fyzické vedení položit, ať už proto, že jednotlivé uzly od sebe dělí značné geografické vzdálenosti, fyzické překážky, nebo jejich spojení vodičem neumožňuje způsob depozice (shoz z letadla, snímání na balónu, automobilu aj.). Také blesky zvyšují riziko
zničení části či dokonce celé sítě.
Na druhou stranu bývají uzly drátové senzorové sítě trvale zásobovány proudem, takže mohou vysílat
déle, ve vyšších přenosových rychlostech, a je možné provádět náročnější úpravy dat před jejich odesláním. Bezdrátové senzory bývají kriticky závislé na stavu baterie, kterou mnohdy (ať již z důvodu obtížné
dostupnosti, nebo jiného) již není možné vyměnit či dobít, proto pro úsporu energie obvykle vysílají data
v určených intervalech a komprimovaném formátu. Pokud je to možné, je nutné jednou za čas jednotlivé
bezdrátové uzly zkontrolovat, a baterie dobít či vyměnit. Jinak je nutné deponovat zcela nové uzly. Ovšem
depozice nových uzlů nemusí být nijak náročná, neboť obzvláště bezdrátové sítě dnes disponují vlastností
samoorganizace, tedy dokáží ze shluku na různých místech deponovaných samostatných senzorových uzlů
automaticky sestavit funkční senzorovou síť, zapojit nově instalované zařízení prakticky kdykoliv, a i v
případě fatální poruchy znovu síť nastavit.
Mezi hlavní nevýhody bezdrátových senzorových sítí patří kromě bateriového provozu také mnohem nižší
přenosová rychlost a možné rušení jednotlivých senzorů mezi sebou či s jinými zařízeními. Také jsou stále,
i přes jejich značné zlevnění, mnohem dražší, než senzory drátové.
68
5.2.3 Typy senzorových sítí
Jak je z předchozího textu patrné, senzorové sítě se používají pro nejrůznější druhy úkolů. Právě zaměření
dané sítě rozhodující měrou ovlivňuje její funkčnost, architekturu, geografické rozmístění, komunikační
prostředky apod. Většina senzorových sítí je dnes koncipována jako jednoúčelové. Jednotlivé uzly senzorové sítě obvykle ani nejsou, vzhledem ke své omezené výpočetní, energetické a komunikační síle, schopny
vykonávat více rozdílných úloh najednou. V případě aplikací při sledování životního prostředí či lidských
aktivit, které využívají geografickou informaci, vykazují senzorové sítě určitou podobnost, a to nezávisle
na oboru výzkumu, podle prostředí, ve kterém jsou deponovány. Pro geoinformatiku se tak stává zajímavými především těchto pět typů senzorových sítí: pozemní, podzemní, podvodní, multimediální a mobilní
(YICK, 2008).
Pozemní senzorové sítě bývají složeny ze stovek až tisíců levných bezdrátových uzlů, které jsou rozmístěny
v určité lokalitě, a to buď podle momentální potřeby (ad hoc, např. shozem z letadla), nebo v předem
plánované konfiguraci (např. pravidelná síť, optimalizovaná síť aj.).
Podzemní senzorové sítě se obvykle skládají z několika senzorů, uložených pod zemí či v jeskyních nebo
šachtách. Další doplňkové uzly jsou uloženy nad zemí a zajišťují přenos informací ze senzorů k základové
stanici. Podzemní prostory značně zvyšují požadavky na přenosovou infrastrukturu, a to z důvodu vyššího
rizika ztrát a značného zeslabení signálu, neboť ten často musí procházet půdami, skálou a vodou s různým
minerálním složením. Z tohoto důvodu musí být rozmístění uzlů takové sítě pečlivě navrženo, přičemž se
musí, podobně jako v případě pozemních sítí, dbát na energetické nároky takové sítě, neboť baterie bývá
velmi obtížné dobít či vyměnit.
Podvodní senzorové sítě sestávají z množství senzorových uzlů a vozítek či robotů, které jsou rozmístěny
pod vodou. Počty uzlů bývají menší, než v předchozích případech, a to především z důvodu jejich vyšší
ceny. Autonomní podvodní roboty (vozítka, ponorky) se používají pro průzkum či sběr dat z jednotlivých
uzlů sítě. Typická komunikace podvodních sítí probíhá pomocí akustických vln, což má za následek užší
přenosové pásmo, delší čas přenosu informací a snižování intenzity signálu. Dalším problémem je poměrně vysoké riziko selhání senzorových uzlů z důvodu nepříznivých přírodních podmínek. Takové senzory
musí být schopny se samy překonfigurovat. Z těchto důvodů vznikají zvláštní komunikační a síťové protokoly pro podvodní sítě.
Multimediální senzorové sítě jsou navrhovány pro sledování událostí multimediálními prostředky (obrazově či zvukově). Skládají se z nízkonákladových uzlů, vybavených kamerami a mikrofony. Tyto senzorové
uzly jsou navzájem bezdrátově propojeny, a poskytují si navzájem prostředky nejen pro čistý přenos dat,
ale i jejich zpracování, sesouvztažnění a kompresi. Tyto sítě tak bývají velmi náročné na potřebnou šířku
přenosového pásma a mívají velmi vysokou energetickou spotřebu. Zpracováním síťových dat, spojováním
obsahu, filtrováním redundantních dat a kompresí lze značně navýšit výkonnost takové sítě. Geografické
rozmístění uzlů je nutno pečlivě plánovat, aby byl pozorovaný jev dostatečně pokryt.
Mobilní senzorové sítě se skládají ze skupiny senzorových uzlů, které jsou schopny pohybu a interakce se
svým fyzickým okolím. Klíčovým rozdílem mezi statickými a mobilními sítěmi je kromě změny jejich
polohy také schopnost automaticky se organizovat do sítě. Jednotlivé uzly mohou být na začátku deponovány na jednom místě a samy se rozprostřít do okolí a sbírat informace. Senzorová i další data mohou
proudit z jednoho mobilního uzlu do druhého, dokud jsou vzájemně v dosahu. Na rozdíl od statických
senzorových sítí, kde jsou data distribuována statickým směrováním či roztékáním, se zde využívá směrování dynamického.
69
5.2.4 Další služby senzorových sítí
Mimo služby komunikační, které zahrnují i služby směrovací, jsou pro zajištění dostatečně spolehlivých
a reprezentativních senzorových dat nutné, zvláště u bezdrátových sítí, i některé další služby. Vzhledem
k tomu, že jakákoli získaná senzorová informace musí být vztažena k určitému časovému okamžiku
a prostorovému umístění, nabývá přesnost určení času a místa, kde se senzor nachází, poměrně
značného významu. Pro určení polohy bylo vyvinuto množství zvláštních technik synchronizace času
mezi jednotlivými senzorovými uzly. Obvykle jsou tyto techniky založeny na měření zpoždění oproti
majákovému signálu, který pomocí své radiostanice vysílá některý z uzlů. Tyto techniky jsou obvykle
implementovány pomocí zvláštních protokolů
Pro určení neznámé pozice senzoru je taktéž možné využít některou z technik, založených na měření
doby zpoždění radiového signálu. Nejjednodušším přístupem je instalace přijímače GPS na každý uzel,
což je ovšem velmi drahé, energeticky náročné a nelze jej využít ve všech prostředích. Proto i zde existují
techniky, pomocí nichž mohou jednotlivé uzly určovat svoji vzdálenost oproti ostatním uzlům, a to při
rozmístění v ploše o několika kilometrech obvykle v řádu metrů (např. metodou trilaterace, kterou využívá
i systém GPS). U některých jiných metod, např. Spotlight (STOLERU et al, 2005) lze dosáhnout poziční
přesnosti i v mm.
V případě, že sledovaný jev (objekt) nabývá výrazně prostorového charakteru, nebo je v prostoru pohyblivý, je pro zachování dostatečného pokrytí zájmového území či zvýšení životnosti sítě při značném překryvu sledovaného území jednotlivých senzorů, je vhodné využit některou ze služeb, jež hlídá dostatečnost a
adekvátnost pokrytí daného jevu. Zapínání a vypínání, případně řízení přesunu jednotlivých senzorů, je v
současné době stále více autonomní záležitostí jednotlivých senzorových uzlů a vyžaduje pouze minimum
zásahů z vnějšího řídicího systému.
5.2.5 Senzorové sítě pro aplikace v reálném čase
Ačkoli by se mohlo zdát, že využití nízkonapěťových senzorových sítí1 s chytrými senzory pro aplikace,
které vyžadují senzorová data v reálném čase (např. bezpečnostní či lékařské), je dnes již bezproblémové, není tomu tak. Vzhledem k nízkému výpočetnímu výkonu a velmi malým paměťovým možnostem
řídících jednotek nízkonapěťových senzorových uzlů2 je velmi obtížné zamezit tomu, aby jedna úloha
nezablokovala celý procesor pro sebe. Vzhledem k tomu, že je pro tyto bezpečnostní aplikace nezbytné
zabezpečit příjem pouze autentizovaných příkazů a dat, a celou komunikaci šifrovat, může být zatížení
těchto procesorů značné. Multitasking v takovémto systému je téměř vyloučen. Plánování činností operačního systému všech uzlů však musí být schopno alespoň umožnit programům běžet ve více vláknech a
také spouštět operace v závislosti na čase jejich předpokládaného dokončení. Riziko, že daná operace bude
dokončena včas a nezpůsobí nadměrné zablokování uzlu, je za těchto podmínek obvykle přijatelné tehdy,
když obvyklá činnost uzlu nezabírá více jak přibližně 60 % výpočetních zdrojů (FAROOQ et al, 2011).
Podmínkou k tomu, aby senzorová síť mohla být bezpečným zdrojem dat v reálném čase, je její připojení
k dostatečně výkonné sítí. Ačkoli potřebná rychlost přenosu dat v síti se odvíjí především od charakteru
přenášených dat, snižuje přenosová rychlost sítě i riziko, že potřebná informace se k uživateli dostane
se zpožděním. Základem komunikace senzorových sítí v reálném čase je především takový komunikační
protokol, který umožňuje všem uzlům sítě rovný přístup k přenosovému médiu tak, aby dlouhé přenosy
dat z některých uzlů neblokovaly možnost přenosu i pro ostatní uzly sítě.
1 Tj. sítě, jejichž uzly využívají pro napájení pouze slabý elektrický zdroj, obvykle se jedná o malé bezdrátové senzory.
2 Typicky se paměť těchto uzlů počítá v jednotkách kilobajtů pro RAM, stovkách kilobajtů pro ROM a taktovací frekvence
procesorů v jednotkách MHz.
70
5.3 Specifika senzorových dat
Z jakého důvodu vyčleňujeme data ze senzorů jako specifickou kategorii, která vyžaduje zvláštní pozornost? Jistě je možné při přístupu, zpracování a vizualizaci senzorových dat využívat standardních technik,
ovšem tímto způsobem nejen že nevyužijeme všech možností, které nám přístup k živým senzorovým datům přináší, ale na druhou stranu si taktéž do jisté míry zkomplikujeme práci a výstupy z našeho systému
se mohou stát nevěrohodnými.
Hlavním důvodem rozdílu mezi normalizovanými daty v databázi a daty senzorovými tkví ve skutečnosti, že senzory jsou dynamickým zdrojem informací. Během své pracovní činnosti mohou senzory, ať už
vlivem vnějších okolností, nebo zásahy obsluhy či přednastaveným chováním, měnit některé ze svých
vlastností (od poruchových stavů přes nastavení senzoru až např. po polohu). Tyto změny poté mohou
ovlivňovat charakter získávaných dat, a to i zásadním způsobem.
Jedním ze způsobů, jakým se změny charakteristik senzoru odrazí v geoinformační infrastruktuře, je změna metadat pro data daných senzorů či senzorových systémů. Metadata se tak mohou měnit velmi rychle,
např. z důvodu změny pozice rychle se pohybujícího senzoru, nebo změny statusu senzoru (zaneprázdněn,
dostupný, aktivní, neaktivní). Senzorová data také mohu být dostupná pouze v určitý čas, a to například
tehdy, když jsou senzory instalovány na určitém místě pouze po určitou dobu. Velmi častým případem je
také neustálá instalace senzorů do sítě a jejich rekonfigurace nebo rušení. Tyto změny by tedy měly reflektovat nejen metadata senzorových dat či senzoru samotného, ale i další služby, které na vstupu senzorová
data využívají.
5.3.1 Senzorové aplikace
Senzorová data jsou využívána v různých aplikacích. Jejich podoba je do jisté míry podmíněna tím, jak se
daří řešit jednotlivé úkoly spojené s jejich funkčností. Funkčnost senzorových aplikací lze rozdělit podle
doby jejich vzniku do tří skupin (KLOPFER et al, 2009):
• První aplikace, které se objevily (sledování cílů, místností, životního prostředí atd.), obvykle využívaly několika senzorových uzlů, které náležely do jediné sítě. Zřetel byl kladen především na
algoritmy a protokoly pro efektivní správu napájení, směrování nebo lokalizaci.
• Současná druhá vlna aplikací zajišťuje určité přidané možnosti a služby, a v určitém rozsahu může
využívat více senzorových bran (základových stanic), čímž dochází k formulaci a nastavování nových standardů v rozsahu a variabilitě sítí. V současné době je možné spravovat více senzorových
sítí s takovou obtížností, jako dříve jednu.
• Třetí vlna, která v současné době teprve začíná, je spojena s aplikacemi v měřítku celého Internetu.
Na významu nabývá především rozhraní mezi různými aplikacemi a sítěmi. Tento druh aplikací je
spojen s tzv. Internetem věcí (the Internet of things, viz dále).
S tím, jak obor působnosti a rozsah senzorových aplikací stále roste, je nutné jít za dílčí a odloučené implementace. Senzorové aplikace budou hrát větší roli v tzv. global computing. Global computing znamená
výpočetní infrastrukturu dostupnou globálně, schopnou poskytovat jednotné služby s různým stupněm
záruky za komunikaci, spolupráci, mobilitu, použití zdrojů, bezpečnostních zásad a mechanismů, atd.,
zejména s ohledem k využití jejich univerzálního rozsahu a programovatelnosti jejich služeb. Integraci
internetu a senzorových sítí lze lépe popsat např. konceptem „Sensor-oogle“, či „Google Earth Sense“.
Může tak být poskytována zcela nová vrstva informací. Lze si tak představit verzi vyhledávače Google,
který je schopen vyhledat senzorové služby, či Google Earth s online senzorovými daty, pokrývajícími
každý čtvereční kilometr Země.
71
5.3.2 Vyhledávání v senzorových datech
Vybudování infrastruktury, která by umožnila globální vyhledávání v senzorových datech a globální
správu senzorových sítí různých výrobců, které pracují pod různými standardy, se dnes stává jednou z
důležitých součástí integrace senzorových dat do informační infrastruktury, dostupné pomocí standardizovaných metod a sítě internet. Pochopení odlišností při vyhledávání v senzorových datech je základním
předpokladem pro naplnění tohoto cíle. Vyhledávání v živých senzorových datech se v mnoha případech
odlišuje od vyhledávání v normalizovaných databázích. V některých případech postačí funkcionalitu současných vyhledávacích metod rozšířit, v jiných je však nutné přijmout zcela nové přístupy.
Přestože jsou data ze senzorových pozorování obvykle také nějakým způsobem normalizována, způsobů
reprezentace daného fenoménu může být velké množství. Rozdílné druhy senzorů mohou produkovat
rozdílné reprezentace téže pozorované vlastnosti. Reprezentace se tak mohou lišit druhem pozorované
veličiny, kvalitou či přesností reprezentace, pozorovací metodou či vnitřním zpracováním signálu. Pozorovaná vlastnost může být reprezentována např. jednou hodnotou, nebo rozpětím hodnot, výběrem mezi
nejhorší a nejlepší hodnotou, řadou hodnot či vícerozměrovým polem hodnot (např. obrázek složený z
hodnot pixelů). Může obsahovat jak hodnoty z každého bodu v prostorovém či časovém kontextu, tak
může být statistickou reprezentací těchto hodnot v prostoru či čase. Senzor či databáze systému může dále
uchovávat reprezentace staršího časového kontextu (historie) či prostorového kontextu. Taktéž může poskytovat i rozhraní pro svoji správu (např. pro označení názvem, konfiguraci vnitřního zpracování signálu
či sledování chování zařízení).
Popis reprezentace pozorování, podobně jako dalších informací s ním spjatých (vč. popisu senzoru samotného), tak musí být pro korektní využití dané aplikace poskytnuta jako metainformace. Také informace o
statusu senzoru mohou být využity i pro zlepšení kvality vyhledání senzorů (např. je vhodné vzít v potaz
poslední pozici senzoru). Kvalita vyhledávání může být také zvýšena zapracováním údajů o sémantických
vazbách mezi vyhledávanými jednotkami (např. sémantiky jevů, jež jsou měřeny senzory). Je umožněno
např. vyhledávat senzory, které sledují podobné či ekvivalentní jevy. Velmi vhodné je tedy navázání vyhledávacích služeb v senzorových aplikacích na tezaury, které mohou pomoci s automatizovaným vyhledáním podobných reprezentací v zájmovém území v případě, že není k dispozici požadovaná veličina. Sémantické vyhledávání v senzorových zdrojích se tak stává jedním z největších výzev pro automatizovanou
práci geoinformačních infrastruktur, které integrují senzorová data.
Senzorové datové zdroje taktéž kladou mnohem větší požadavky na řízení dat a přístupu k nim. Pro jejich
vyhledání je totiž třeba mnohem většího objemu metainformací a zvláštní funkce, kterými běžné systémy
přístupu k databázím nedisponují. Stejně tak je pro správné vyhledání dat či adekvátnímu úkolování senzorů nutná znalost o každém jednotlivém senzoru a jeho charakteristikách.
Z těchto skutečností vyplývá, že pro to, aby bylo možno efektivně využívat všech možností senzorových
systémů v geoinformační infrastruktuře, je třeba pro komunikaci mezi senzorovými sítěmi a s řídícími
systémy a publikačními platformami zavést specifický způsob komunikace a dokumenty se zvláštním kódováním, zpracovávajícím nové jevy. Protože jednotlivé senzorové systémy dnes pro vnitřní komunikaci
obvykle využívají různá proprietární řešení, která nejsou vzájemně interoperabilní, je nutno na vrstvě, v
níž se data z jednotlivých senzorových sítí stýkají, vytvořit novou vrstvu, která bude sloužit jako rozhraní mezi senzorovými sítěmi a uživatelskými aplikacemi, a umožní tak různým uživatelským aplikacím
přistupovat k senzorovým sítím jednotným způsobem. Řešení publikace dat pomocí služeb, jako je např.
WWW, vyhledávání a zpracování senzorových dat a případně úkolování senzorů vzdáleným uživatelem je
na komerční úrovni obvykle stále řešeno proprietárně, což značně ztěžuje propojování těchto zdrojů dat.
72
5.3.3 Centralizované portály
Jedním ze způsobů, jak řešit heterogenitu1 zdrojů senzorových dat, je vytvoření centralizovaného přístup
přes (např. webový) portál. Metadata registrovaných senzorů i nahraná senzorová data jsou hostována
centrálním portálem namísto jednotlivých služeb. Výhodou takovéhoto řešení je jednotné řešení připojování zdrojů dat, uživatelských aplikací apod. Využití takového řešení je ovšem nevhodné v případě, že
potřebujeme robustní architekturu, která se nespoléhá na jedno komunikační hrdlo. Toto řešení například
zvyšuje pravděpodobnost výpadků služeb, omezuje plnou kontrolu nad zaváděním a správou senzorů a
nevyhovuje potřebám přísného utajení.
Dnes existující centralizované webové portály pro senzory mohou být chápány jako nový typ systémů na
aplikační úrovni, které slouží ke zpřístupnění senzorových dat. Některé webové portály umožňují uživatelům nahrát a sdílet senzorová data. Podpora datových formátů je různá, od numerických dat (např.
teploty vzduchu) až po audio a video data (např. z webových kamer). Nahraná data mohou být dotazována
a zobrazována koncovým uživatelem např. jako graf časové řady či seznam videopřenosů.
Příkladem mohou být systémy jako SensorMap s infrastrukturou SenseWeb, SensorBase, Pachube či Sensorpedia. Některé z portálů mohou být i specializované, jako Weather Underground, která umožňuje lidem
registrovat jejich domácí meteorologické stanice a poskytovat svá měření k výpočtům předpovědí počasí,
či EarthCam, která odkazuje na přenosy z několika tisíců webových kamer.
5.4 Middleware
Softwarové prostředky a technologie, které formují vrstvu, jež pomáhá dostat různé senzorové zdroje do
běžných počítačových sítí a internetu, a učinit je tak dostupné aplikacím, se někdy souhrnně označují jako
middleware. Tyto technologie pomáhají spravovat rozličné senzorové zdroje a umožňují jejich použití v
aplikační vrstvě (BRÖRING et al, 2011). Není tak potřeba se omezovat na služby zavedených portálů,
ale pro potřeby vlastní organizace, širší skupiny dočasných nebo stálých zákazníků či veřejnosti jsou k
dispozici technologie, které umožňují zprostředkovat komunikaci mezi rozličnými senzorovými sítěmi a
aplikacemi pomocí standardních rozhraní.
Samotný termín middleware může být občas používán spíše jako módní pojem (buzzword), který znamená různé věci v závislosti na oblasti informatiky či IT, v níž je užíván. Na poli distribuovaných systémů je
obvykle chápán jako software, který leží mezi operačním systémem a aplikacemi, běžícími na každém uzlu
tohoto systému. Obecně lze říci, že úkolem middleware je skrýt vnitřní procesy a heterogenitu systému
poskytnutím standardních rozhraní, abstrakcí a množiny služeb, které značně závisí na dané aplikaci.
Middleware v senzorových sítích lze rozdělit do následujících kategorií (CHATZIGIANNAKIS et al,
2007):
Nástroje správy sítě – poskytují uživateli možnost vizualizovat výsledky ze senzorové sítě a kombinovat
je s daty uloženými na vstupní bráně. Tento případ nenabízí příliš programátorské flexibility, neboť je
zde k dispozici pouze omezené množství dostupných funkcí. Uzly v síti se dotazují svých senzorů v předem definované vzorkovací frekvenci a odpovědi zasílají vstupní bráně. Záznamy z této sítě jsou obvykle
uloženy v relační databázi pro další zpracování. Mezi tyto systémy patří Mote-View, Scatterweb, či novější
MundoCore, Mires nebo MiLAN.
Tyto systémy obstarávají správu senzorů, ale obvykle se nezaměřují na poskytování snadného přístupu k
senzorům. Mohou být chápány jako bližší k nižší senzorové vrstvě a ne zcela zasahují do aplikační vrstvy,
i když některá řešení mohou sloužit jako základ pro další přístupy, jako jsou infrastruktury senzorového
webu.
1
Tj. různá struktura nebo vlastnost složení, různorodost (opak homogenity).
73
Senzorové databáze – základní myšlenkou je poskytnout rozhraní podobné SQL, které zajišťuje, aby senzorová síť vypadala jako systém řízení báze dat. Příkladem může být TinyDB či COUGAR.
Virtuální stroje – poskytuje programovací primitiva senzorů v jazyku připomínajícím stavebnici. Uživatelé vytvářejí skripty, které jsou nahrány do nodů sítě a jsou spouštěny ve virtuálním stroji běžícím v každém
z těchto nodů. Příkladem takového systému je Maté.
Přístupy založené na agentech – software poskytuje programátorovi abstrakce pro výpočetní úlohy (podobně jako u virtuálních strojů), jako např. spouštění událostí, komplexní úlohy, atd., které jsou použity k
naprogramování mobilních agentů, což jsou zapouzdřené mikroaplikace, jež mohou přecházet z nodu do
nodu a v každém z nich vykonávat dané úkoly. Tímto způsobem mohou být realizovány komplexní úlohy
v situaci, kdy každý nod může používat rozdílný software. Příkladem může být Agrilla, IrisNet či Sensor
Web Agent Platform.
Publish/subscribe – interakce mezi poskytovatelem dat a uživatelem je zajišťována množinou prostředníků. Poskytovatelé publikují události (či publikace) do sítě prostředníků, a uživatelé se přihlašují k odběru
událostí, které je zajímají, prostřednictvím odesílání přihlášek do sítě prostředníků. Odpovědnost dodat
událost uživateli leží na straně prostředníků. Pokud je tento model založen na obsahu, mohou uživatelé
specifikovat omezení obsahu události, za kterých jim budou tyto události dodány. Takovým systémem je
Sensor Web Enablement, PULSENet či SOCRADES
Tuple-based – Systém založený na n-ticích sestává z omezené množiny koordinačních primitiv, které přistupují k abstraktnímu n-ticovému prostoru. Základní jednotkou tohoto publikačního systému jsou n-tice . Koordinační aktivity mezi agenty aplikace (včetně synchronizace) jsou prováděny nepřímo pomocí
výměny n-tic prostřednictvím sdíleného n-ticového prostoru. Koordinační primitiva poskytují agentům
přístup k tomuto prostoru (CABRI et al, 2009). Příkladem může být TinyLIME.
Všechna tato prostředí mohou být v jednotlivých aplikacích kombinována či obsahovat nástroje ke vzdálenému programování senzorových uzlů, jež usnadňují jejich správu a nasazení. Mezi systémy, které kombinují některé z výše uvedených prostředí, lze zařadit GeoSWIFT, který kombinuje SWE s prostorovým
dotazovacím rámcem založeným na peer-to-peer, Sensor Web 2.0 z dílny NASA kombinuje SWE s Webem
2.0 a umožňuje jednoduché vytváření mash-up aplikací, integrujících data z mnoha druhů senzorů pomocí REST technologie. Global Sensor Network používá virtuální senzorové abstrakce, založené na XML deskriptorech, s přístupem k datům pomocí jednoduchých SQL dotazů. Podobně funguje i Hourglass, který
se zaměřuje na kvalitu služeb datových toků. Sensor Network Services Platform definuje množinu rozhraní,
které lze použít jako API pro bezdrátové senzorové sítě (BRÖRING et al, 2011).
Middleware lze dále členit i podle rozsahu a způsobu programování:
• Programové abstrakce – poskytují programátorům abstrakce pro prohlížení senzorových nodů,
dat či celé sítě.
• Programová podpora – poskytuje mechanismy a služby, které usnadňují programování senzorových sítí, např. vysokoúrovňové skládání aplikací, vzdálená změna programového vybavení, vzdálené ladění apod.
Obě tyto skupiny lze dále dělit do podskupin v závislosti na zvláštnostech přístupu. Programové abstrakce
mohou být děleny kupříkladu na abstrakce globálního či lokálního chování (CHATZIGIANNAKIS et
al, 2007). Některé velké systémy naopak alespoň částečně tyto funkce sdružují.
5.4.1 Internet věcí, web věcí
Myšlenka propojení senzorů s aplikacemi je dosti podobná i myšlenkám internetu věcí a webu věcí.
Myšlenka internetu věcí a webu věcí tkví v integraci obecných „věcí“ reálného světa s internetem či webem.
Jako příklad mohou sloužit domácí spotřebiče, vestavěná a mobilní zařízení, ale také „chytrá“ senzorová
74
zařízení. Často např. uživatel interaguje pomocí mobilního telefonu, který funguje jako prostředník mezi
člověkem, věcí, a internetem či webem (BRÖRING et al, 2011). Z technického pohledu je možné v mnoha
přístupech k problematice těchto dvou oblastí využívat podobné přístupy, jako v případě senzorových sítí.
Internet věcí (Internet of Things, IoT) je koncept sítě (obvykle bezdrátové), která je vytvořena mezi nejrůznějšími objekty jak fyzického, tak virtuálního světa, a to prostřednictvím využívání možností sběru dat
a komunikace. Tato síť bude jako základ pro vývoj nezávislých spolupracujících služeb nabízet určitou
specifickou identifikaci objektů, senzorů a schopnost komunikace a bude ji charakterizovat vysoká míra
autonomního získávání dat, přenosu událostí, propojení sítí a interoperability (ZANDL, 2009).
K těmto objektům tak lze přistupovat podobně, jako k mobilním senzorům samotným. Z technického
hlediska mohou být stavebními kameny komunikační protokoly na bázi IP optimalizované pro chytrá
zařízení (IPv6, 6LoWPAN), služby pro věci, či unikátní identifikace objektů (RFID).
Objekty, jež se propojují a komunikují mezi sebou, mohou být senzory (např. teploměr), ale i „chytré“
věci (např. lednička) a samozřejmě i větší počítače. Což nelze chápat tak, že z terminálu chytré ledničky
se lze dostat na internet, ale že samotná lednička bude komunikovat přes internet s dalšími zařízeními
(ZANDL, 2009).
Web věcí (Web of Things, WoT) může být chápán jako další vývojové stádium Internetu věcí, kde všechny
věci a objekty denního života, které obsahují vestavěné zařízení či počítač, jsou propojeny a plně integrovány do webu. Základním stavebním kamenem je využití webových standardů pro propojení těchto zařízení, a také aplikační programové rozhraní (API), které umožňuje věci integrovat do služeb přístupných
přes web.
WoT využívá existující webové protokoly jako obecný jazyk pro vzájemnou interakci mezi reálnými objekty. HTTP se používá spíše jako aplikační než jako přenosový protokol. Věci jsou adresovány pomocí URL
a jejich funkcionalita je přístupná pomocí standardních operací protokolu HTTP (GET, POST, PUT,
atd.). WoT aplikace nabízejí REST API pro přístup k věcem a jejich vlastnostem jako zdrojům. Tato API
přitom mohou být použita nejen pro interakci s věcí pomocí webu, ale taktéž mohou být poskytovány
webové reprezentace věcí, které mohou zobrazovat dynamicky generované vizualizace dat sebraných věcí.
Poté mohou být pro relativně snadný vývoj aplikací použity nástroje z oblasti Web 2.0 a mash-up přístup
(např. aplikace může použít Twitter pro sdělení statusu pračky či může dovolit ledničce poslat seznam
potravin, které je třeba koupit).
5.5 Senzorový web
Senzorový web lze chápat jako technologii, založenou na myšlence webu věcí, přičemž se prozatím omezuje na senzory. Původně (DELIN et al, 1999) byl senzorový web chápán spíše jako bezdrátová senzorová
síť, jejíž nody nejen data nejen sbíraly, ale též i sdílely, a upravovaly své chování na základě těchto dat.
Termín web zde byl spojen spíše s procesem inteligentní koordinace sítě, než s termínem World Wide Web
(WWW).
Později se význam spojení senzorový web poněkud změnil. Dnes je však stále více chápán jako infrastruktura, která umožňuje interoperabilní využití senzorových zdrojů pomocí jejich vyhledávání, webového
přístupu k nim, jejich úkolování, vytváření a zpracování událostí a výstrah v senzorové síti, a to pomocí standardizovaných prostředků. Tedy, sensor web je pro senzorové zdroje totéž, co WWW pro zdroje
obecné – infrastruktura umožňující uživatelům jednoduše sdílet své senzorové zdroje jasně a standardně
definovaným způsobem (BRÖRING et al, 2011).
Senzorový web lze chápat jako prostředníka mezi senzory a (webovými) aplikacemi. Vzhledem k tomu se
skládá ze tří hlavních architektonických vrstev:
75
• První vrstvou je vrstva senzorů, kde se nachází hardwarová zařízení. Nejrůznější typy senzorů zde
mezi sebou komunikují pomocí nejrůznějších druhů proprietárních či standardizovaných komunikačních protokolů (např. WPAN protokoly, IEEE 1451).
• Druhou vrstvou je zprostředkující vrstva senzorového webu, která poskytuje funkcionalitu mezi
senzorovými zdroji a aplikacemi.
• Třetí vrstvou je vrstva aplikační, která zajišťuje přímou interakci s uživatelem. Samotné aplikace
mohou opět běžet na různých typech zařízení, od mobilních telefonů po servery.
Obr. 5.4 Vrstvy architektury senzorových systémů (upraveno podle KLOPFER et al, 2009)
Obr. 5.4 ukazuje popsané vrstvy a ilustruje pozice jednotlivých typů middleware, které jsou v daných vrstvách použity. Hranice jednotlivých typů middleware nejsou ostré, neboť jejich funkce se mohou překrývat
a mnohé přístupy nabízí funkcionalitu náležející více typům.
Ukrytí základních procesních vrstev a síťových komunikačních podrobností a rozličností senzorového
hardware před aplikacemi nad nimi postavenými je tedy základním účelem senzorového webu. Z tohoto
důvodu tento standard definuje rozhraní webových služeb, která jsou využívána pro přístup k senzorovým
datům, úkolování senzorů a výstrahám založeným na sebraných senzorových pozorováních. Dále vymezuje i standardizované modely senzorů, senzorových dat a jejich kódování (BRÖRING et al, 2011).
Tuto myšlenku v roce 2003 adaptovalo Open Geospatial Consortium (OGC), které začalo s vývojem Sensor
Web Enablement (SWE), v jehož rámci bylo vytvořeno množství standardů, které lze použít jako stavební
kameny senzorového webu.
5.5.1 Standardy OGC SWE
Standardy OGC SWE vymezují sadu rozhraní a protokolů, pomocí nichž je možno sestavit funkční
senzorový web. Pomocí těchto protokolů a rozhraní mohou aplikace přistupovat přes web k senzorům
různých typů. Tato sada sestává ze specifikací služeb, registrů, slovníků a společného základu. Jednotlivé
služby spolu komunikují prostřednictvím specifických dokumentů ve formátů XML, posílaných pomocí
standardních HTTP metod POST/GET. Je taktéž možné využít komunikaci pomocí SOAP. V současné době je aktuální až na výjimky verze 2.0. Pro lepší orientaci je všech 12 dokumentů rozděleno do tří
skupin. Skupina slovníků a registrů sestává z pěti standardů, které popisují kódování dokumentů, pomocí
nichž jsou přenášena senzorová data či data o senzorech a aktuátorech, a služby registrů, které ulehčují vyhledávání a spravování senzorových zdrojů. Skupina služby obsahuje 5 specifikací služeb pro zpřístupnění
senzorových dat. Společný základ poté obsahuje dvě specifikace, které jsou pro všechny standardy rodiny
SWE společné, a jsou proto umístěny v centrálních dokumentech. Jednotlivé standardy jsou do těchto
skupin přiděleny následovně:
76
a) Slovníky a registry
1. Observations & Measurements (O&M) - Standardní model a XML schema pro kódování pozorování a měření ze senzorů v reálném čase. Tento standard byl schválen organizací ISO jako
doporučená norma s označením ISO 19156.
2. Sensor Model Language (SensorML) - Standardní model a XML schéma pro popis senzorových
systémů a procesů spojených se senzorovými pozorováními. Poskytuje informace nutné pro nalezení senzorů, míst senzorových pozorování, zpracování nízkoúrovňových senzorových pozorování, získávání seznamů úkolů a podporu zpracování senzorových pozorování na požádání.
3. Transducer Model Language (TransducerML nebo TML) - Konceptuální model a XML schema
pro popis čidel a podporu přenosu dat z a do senzorového systému v reálném čase. Tento standard
není již ve verzi 2.0 podporován.
4. Sensor Instance Registry (SIR) - Služba a webové rozhraní pro řízení senzorových metadat. Tato
služba zahrnuje sběr metadat, správu senzorových statusů a funkce vkládání senzorových metadat
do standardních webových katalogů OGC.
5. Sensor Observale Registry (SOR) - Rozhraní webové služby, určené pro přístup k definicím jevů
a pro zkoumání sémantických vazeb mezi rozličnými jevy. SIR a SOR pracují jako rozšíření standardní webové katalogové služby OGC (CS-W).
b) Služby
6. Sensor Observations Service (SOS) - Standardní webová služba pro dotazování, filtrování a získávání pozorování a informací o senzorových systémech. Působí jako prostředník mezi klientem a
datovým skladem pozorování či přenosovým kanálem blízkým reálnému času.
7. Sensor Planning Service (SPS) - Standardní rozhraní webové služby pro dotazování a získávání
pozorování, řízených uživatelsky. Působí jako prostředek komunikace mezi klientem a prostředím
pro řízení senzorů.
8. Sensor Alert Service (SAS) - Standardní rozhraní webové služby pro publikování a přihlašování
k výstrahám ze senzorů. Vývoj této služby byl zastaven v důsledku zavedení Sensor Event Service.
9. Sensor Event Service (SES) - Jedná se o rozšíření SAS, které umožňuje přihlašovat se k odběru
senzorových dat a měření. Tato služba poskytuje i metody pro dynamické přidávání nových senzorů, nebo umožňuje přihlašovat se k odběru výstrah ze senzorů. Tato specifikace prozatím existuje
pouze v návrhu.
10.Web Notification Service (WNS) - Standardní rozhraní webové služby pro asynchronní doručování zpráv či výstrah ze SES, SPS, či dalších komponent senzorového systému.
c) Společný základ (Commons)
11.Common Data Model (CDM) - Datový model pro společné a základní datové typy, které jsou
užity v celé rodině standardů SWE.
12.Common Service Model (CSM) - Datový model definující podobu požadavků a odpovědí různých služeb SWE.
Pro nejjednodušší senzorový IS s podporou prostorových dotazů založený na standardech OGC (bez uvažování jakýchkoli nadstavbových služeb typu GIS) je nezbytné dodržet alespoň O&M, SOS a SensorML,
s přihlédnutím ke společnému základu. Dále je třeba znát alespoň základy notace UncertML1 . Základní
vlastnosti zápisu senzorových pozorování Observations & Measurements a služby Sensor Observation
Service si nyní přiblížíme.
1 Uncertainity Markup Language je konceptuální model a XML schéma pro kvantifikaci a výměnu komplexních informací o
nejistotách v datech. Interoperabilní model může být použit pro popis nejistot různým způsobem, např. vzorkováním, středními
hodnotami (průměr, rozptyl, směrodatná odchylka, kvantily) či pravděpodobnostním rozložením.
77
5.5.2 Observations & Measurements
Jak již bylo výše řečeno, standard Observations & Measurements je základním dokumentem rodiny SWE.
Obsahuje popis standardního modelu a XML schematu pro kódování pozorování a měření ze senzorů v
reálném čase, a je přijat jako norma ISO 19156. Jedná se vlastně o popis toho, jak by měl vypadat dokument, kterým jsou přenášena senzorová data.
Ideovým základem tohoto dokumentu je koncept pozorování. Jak již bylo zmíněno v kapitole o senzorech,
každý senzor provádí pozorování prostředí. Každé jedno senzorové pozorování musí být vztaženo k určitému místu a času (případně plošnému fenoménu a / nebo časovému rozmezí). Pozorování (observation)
je zde chápáno jako akt, proběhnuvší v určitém diskrétním čase či časovém rozpětí, během něhož je hodnota, termín či jiný symbol přiřazen k určitému jevu (jakékoli pozorovatelné události)1.
Obr. 5.5 Vztahy mezi jednotlivými prvky v modelu O&M a jejich vlastnostmi navzájem (upraveno dle KLOPFER et al, 2009)
Obr. 5.6 Obecná struktura dokumentu Observations & Measurements. (převzato z OGC, 2011)
1 Např. hodnota 24° C je přiřazena veličině (jevu) teplota vzduchu právě v 10.00 hodin v Brně-Tuřanech. Takové pozorování lze
též označit jako měření.
78
Základní idea pozorování, která tvoří obecnou strukturu dokumentu O&M, je zobrazena na obrázku 5.5.
Na obrázku 5.6 je pak tato struktura zobrazena podrobněji.
Každé pozorování je vázáno na proceduru, která reprezentuje proces, pomocí něhož bylo pozorování provedeno (např. fyzikálním senzorem nebo simulací). Pozorovaná vlastnost ukazuje na popis vlastnosti jevu,
jenž je pozorován (např. teplota vody či salinita). Výsledek pozorování (tj. výsledná naměřená hodnota)
není omezen na nějaký základní model pozorování a může být jakéhokoli typu, od jediného měření po
n-rozměrnou matici hodnot. Jednotlivé podtypy základního pozorování poté omezují druh výsledku pozorování.
Objektem zájmu je strojově zpracovatelná reprezentace objektu reálného světa (např. Mexický záliv či
vodní sloupec X na řece Mississippi). Tato reprezentace je tedy nositelem vlastnosti, jež je pozorována či
měřena. Výsledkem každého pozorování je hodnota, která je přiřazena této vlastnosti v určitém čase, označovaném jako čas jevu (phenomenon time). V určitých případech je však třeba ještě informovat o některých
dalších časových vlastnostech daného pozorování, k čemuž byly zavedeny dvě další časové hodnoty. Čas
výsledku (result time) je volitelná vlastnost, která reprezentuje čas, kdy byl výsledek pozorování vytvořen
(tedy čas ukončení zpracování dat). Čas platnosti (valid time) je další volitelná vlastnost, která vymezuje
časové období, pro které je výsledek pozorování použitelný. Tento údaj může být velmi cenný například v
předpovědních scénářích, kde předpověď počasí, vytvořená v 9:00 může být zneplatněna novou předpovědí, vytvořenou z novějších dat v 10:00. Čas platnosti pro první předpověď proto začíná v 9:00 a končí
v 10:00.
Představme si jednoduchou situaci, kdy váhy váží jablko. Konkrétní kódování pozorování podle standardu O&M potom může vypadat následovně:
<?xml version="1.0" encoding="UTF-8"?>
Deklarace XML
<om:Observation gml:id="obsTest1"
Hlavička; deklarace že jde o pozorováxmlns:om="http://www.opengis.net/om/2.0"
ní, jeho identifikace, odkazy na pouxmlns:swe="http://www.opengis.net/swe/2.0.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema- žité jmenné prostory a datové schéma.
-instance"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:gml="http://www.opengis.net/gml"
xsi:schemaLocation="http://www.opengis.net/
om/2.0 ../om.xsd">
<gml:description>Observation
test
instance: Název a krátký slovní popis obsahu tofruit mass</gml:description>
hoto dokumentu
<gml:name>Observation test 1</gml:name>
<om:phenomenonTime>
Časová známka, kdy bylo pozorování
<gml:TimeInstant gml:id="ot1t">
provedeno (formátování času dle stan<gml:timePosition>2005-01-11T16:22:25.00</
dardu GML).
gml:timePosition>
</gml:TimeInstant>
</om:phenomenonTime>
<om:procedure
xlink:href="http://www.flakey.org/register/process/scales34.xml"/>

<om:observedProperty
xlink:href="urn:ogc:def:phenomenon:OGC:mass"/>

<om:featureOfInterest
xlink:href="http://wfs.flakey.org?request=getFeature&featureid=fruit37f"/>

Tato část říká, že pozorovaná hodnota
je výsledkem procedury „scales“ (vážení), která pozorovala a zpracovala
vlastnost „mass“ (hmotnost) objektu
zájmu „fruit“ (ovoce). Pro popis procedury, vlastnosti i zájmového prvku
jsou použity odkazy (URL, OGC
URN [OGC 06-023r1] a WFS volání) na externí dokumenty.
79
<om:parameter>
<swe:Quantity
definition="http://sweet.jpl.
nasa.gov/ontology/property.owl#Temperature">
<swe:uom
xlink:href="urn:ogc:def:uom:UCUM:Cel"/>
<swe:value>22.3</swe:value>
</swe:Quantity>

</om:parameter>
Tato část popisuje parametr pozorování – teplotu objektu (v okamžik měření hmotnosti). Pro měření je nezbytný
parametr uom, určující fyzikální jednotky, ve kterých je měřeno (°C).
</om:Observation>
Uzavírací značka dokumentu
<om:result
Samotný výsledek pozorování. Vzhlexsi:type="gml:MeasureType" uom="urn:ogc:def:u- dem k tomu, že jde opět o měření, paom:OGC:kg">0.28</om:result>

Podobným způsobem jsou kódovány všechny přenosy dat ve službách Sensor Web Enablement. V současné době je možné využívat i redukovaný záznam, kdy se v případě opakovaných pozorování většina informací o senzoru, objektu zájmu a dalších parametrech posílá pouze jednou, zatímco v dalších přenosech
jsou již přenášeny pouze výsledky a parametry, které se změnily.
5.5.3 Sensor Observation Service
Služba pozorování senzory je základní službou rodiny SWE. Tato služba je postavena na konceptu jednotlivých pozorování. Pozorování jsou pak tematicky sdružována do nabídek pozorování (observation
offerings), v nichž je poté možné vyhledávat. Nabídky pozorování jsou typicky prostorově či tematicky se
nepřekrývající skupiny příbuzných senzorových pozorování (např. meteorologické jevy - teplota, vlhkost
či tlak vzduchu; nebo např. provoz v ulicích). Koncept je podobný konceptu vrstev ve webové mapové
službě (WMS).
Každou nabídku pozorování lze vymezit určitými parametry, mezi něž patří i následující:
• Časová období, pro která mohou být pozorování požadována (podporuje i historická data)
• Jevy, které jsou sledovány
• Geografická oblast, která obsahuje senzory
• Geografická oblast, která obsahuje prvky, které jsou předmětem senzorových sledování (a která se
může lišit od oblasti, kde jsou senzory umístěny)
Nyní si představme uživatele, který potřebuje nalézt a sledovat senzorová data, a přitom přesně neví, kde
má taková data hledat. Nejprve tedy potřebuje vyhledat příslušnou službu a poté se přesvědčit, zdali pozorování, jež tato služba nabízí, skutečně vyhovuje uživatelovým požadavkům.
V případě, že daná služba nabízí více druhů pozorování a uživatel tak potřebuje znát o příslušných senzorech více informací (např. kalibrační konstanty, čas sběru dat aj.), může požádat o senzorová metadata.
Nakonec může stáhnout samotná senzorová data.
80
Obr. 5.7 Typický průběh interakce uživatele se službou SOS (vlevo) a průběh interakce dvou poskytovatelů a jednoho uživatele
se službou SOS (převzato z OGC, 2007d)
Vlevo na obr. 5.7 je zobrazen typický postup práce SOS z pohledu uživatele. Nejprve uživatel pošle standardní požadavek GetRecords() do standardní katalogové služby OGC. V případě, že jsou v odpovědi
katalogové služby uvedeny instance SOS, může uživatel poslat přímo uvedené službě SOS zaslat požadavek GetCapabilities(). Odpověď poté obsahuje detailní informace o seznamu nabízených pozorování
(observation offerings), které daná služba poskytuje.
Dalším krokem může být vyhledání senzorových metadat pomocí operace DescribeSensor(), která mohou
být získána o každém senzoru, který je uveden v seznamu pozorování. Odpovědí na požadavek DescribeSensor() je dokument ve formátu SensorML. Tento krok lze použít i k filtrování těch pozorování, které
např. nemají dostatečně robustní detekci a korekci chyb, nebo nejsou dostatečně vhodná pro uživatelovy
záměry. Tento krok však může být v mnoha případech přeskočen.
V posledním kroku uživatel spustí operaci GetObservation(), která vrací data ve formátu Observation &
Measurement.
Nyní se podívejme na typický průběh práce se službou SOS z hlediska poskytovatele dat. Takovým poskytovatelem nemusí být jen obchodní společnosti, ale taktéž i soukromé osoby, které např. chtějí publikovat
data ze své osobní meteorologické stanice. Takový uživatel si nemusí být jist, která z nabízených služeb
je nejlepší pro publikaci jeho dat. Nejprve tedy tuto službu vyhledá (a to pomocí standardní katalogové
služby operací GetRecords()), poté teprve vloží nový senzor do této služby (operací RegisterSensor()) a až
od tohoto okamžiku může publikovat senzorová data (operací InsertObservation()).
Uživatel, který se snaží k senzorovým datům dostat, v prvním pokusu dle obr. 5.7b zjistí, že daný senzor
neexistuje, v pokusu druhém nedostane žádná senzorová pozorování a až teprve po vložení prvních pozorování alespoň od jednoho poskytovatele (operací InsertObservation()) může tato pozorování získat.
5.5.4 Služby SWE a interakce formátů
Aby byly senzory v síti dohledatelné, je pro jejich popis použit jazyk SensorML, pomocí něhož jsou registrovány službou SOS do katalogu. V případě, že uživatel potřebuje data z pozorování, posílá vyhledávací
dotaz katalogu. Katalog odpovídá seznamem instancí služby SOS, které vyhovují dotazu. Poté si uživatel
vybere příslušnou službu, odešle jí požadavek a získá data formátovaná v O&M.
81
Obr. 5.8 příklad použitých služeb, operací a datových formátů v systému SWE (upraveno podle OGC, 2011)
V případě, že katalog nenalezne odpovídající službu, která by vyhovovala uživatelovým požadavkům,
může uživatel prohledávat plánovací služby (SPS), které mohou úkolovat senzory pro vytvoření odpovídající akce (zahájení pozorování aj.) podle potřeb uživatele. Katalog poskytne odkaz do instance SPS a
uživatel zadá požadovanou akci. SPS přepošle příkaz senzoru.
Komunikace mezi SPS a senzorem je pro uživatele neprůhledná. Jakmile jsou senzory nastaveny tak, aby
mohly snímat zadané jevy, senzor směřuje svá data do databáze, která je navázána na SOS. SPS informuje
uživatele o dostupnosti dat pomocí webové notifikační služby (WNS). Výhodou je, že SPS může odpovědět na požadavek úkolu přímo a má mechanismus k dosažení uživatele v další etapě, např. pokud jsou
již data dostupná, nebo je úkol zpožděn či zrušen. Upozornění obsahuje všechny nezbytné informace o
přístupu k datům z SOS.
Častým případem je rovněž stav, kdy uživatele nezajímají všechny výsledky senzoru, ale chce být zpraven
okamžitě, pokud nastane určitá situace. K tomu slouží služba Sensor Event Service (SES).
Klient získá informace o příslušné SES z katalogu a přihlásí se k odběru služby SES. Senzory do SES publikují výsledky pozorování kontinuálně, ta je zpracovává, filtruje a upozorní klienta v případě, že podmínky
odběru jsou splněny. Klient se kromě toho může registrovat pro výstrahy. V takovém případě SES spouští
webovou notifikační službu (WNS), která posílá klientovi výstrahu přes zadaný komunikační protokol
(např. lze informovat uživatele pomocí SMS či e-mailu tehdy, když vodní hladina na sledovaném profilu
přesáhne hodnotu 5 m).
5.6 Závěr
V tomto textu jsme se velmi krátce seznámili s vlastnostmi senzorových sítí a vybraných způsobů publikace jejich dat nejen v geoinformační infrastruktuře, ale obecně v prostředí sdílených zdrojů internetu. Myšlenka webu věcí se s rozšiřujícími možnostmi mikroelektroniky stává stále aktuálnější, a integrace tohoto
konceptu do geoinformačních infrastruktur se zdá být dříve či později nevyhnutelná. Spřažení živých senzorových dat s prostředky GIS může nejen zrychlit a zlepšit práci různých monitorovacích a expertních
systémů, ale především otevřít nové možnosti v poskytování služeb a sdílení dat. Globální automatizované
vyhledávání senzorových dat umožní vytvářet nové druhy produktů pro nejrůznější cílové skupiny. Služby
pro senzorové sítě, založené na webových standardech, poskytují konkurenceschopnou alternativu proprietárních systémů, přičemž přinášejí znatelně větší interoperabilitu za nižších investičních nákladů. Služby
založené na webových standardech mohou být jednoduše přidány do existujících sítí, a to bez nutnosti
zásadních změn v původní infrastruktuře.
82
6. KARTOGRAFICKÁ VIZUALIZACE SENZOROVÝCH DAT
Jiří KOZEL, Zdeněk STACHOŇ
6.1 Úvod
Problematika senzorů a senzorových sítí je intenzívně rozvíjena jak po stránce technologické (dostupnost
čidel pro zaznamenávání různých veličin), tak po stránce procesní (např. definice standardů pro přenos
senzorových dat - SWE apod.) umožňující jejich využití. Senzory jsou tak stále více využívány pro sběr
informací různorodého charakteru. V užším slova smyslu jsou za senzory považována zařízení zaznamenávající nějakou fyzikální veličinu. V širším slova smyslu můžeme za senzory považovat nejen zařízení, ale
také informace získané z tzv. lidských senzorů apod. Získávaná data potom mohou být jak kvalitativního
tak kvantitativního charakteru. Příkladem kvantitativních senzorových měření může být kontinuální záznam teploty, vlhkosti apod. Příklad kvalitativního senzorového měření je kamerový záznam, subjektivní
hodnocení okolního prostředí uživateli atp.
Hlavními výhodami senzorových dat na rozdíl od jiných metod je zejména jejich získání v těsné blízkosti
sledovaného jevu, možnost opakování měření a vyšší efektivita sběru dat. Většina senzorů je konstruována
tak, že jsou schopny poskytovat více či méně dlouhé časové řady měření.
V úvodu kapitoly jsou představeny pojmy jako kartografická vizualizace, kartografická symbolika nebo
mapový znak. Důraz je přitom kladem na vizualizaci senzorových dat. Následně se kapitola zabývá formalizací mapového jazyka, která je nezbytným předpokladem automatizované kartografické vizualizace, a s
ní související specifikací Symbology Encoding. V závěru se potom kapitola zabývá hodnocením mapových
znaků pro senzorová data.
6.2 Kartografická vizualizace
Pojem kartografická vizualizace je v poslední době používán stále častěji, především v souvislosti s nástupem počítačové kartografie a úzce souvisí s pojmy jako vědecká vizualizace nebo geovizualizace.
V obecném pohledu je kartografická vizualizace specifickým případem vědecké vizualizace, jejímž hlavním cílem je prezentovat data nebo informace vizuální formou založenou na vědeckých metodách (viz
např. SLOCUM et al, 2005, str. 11 nebo MacEACHREN, 1995, str. 355). Geografická vizualizace, zkráceně geovizualizace, je specifický případ vědecké vizualizace, kdy jsou vizualizována geograficky vztažená
data (HŘEBÍČEK et al, 2007, str. 210). Kartografická vizualizace je potom ta část geovizualizace, která
prezentuje tato data kartografickými vyjadřovacími prostředky (KONEČNÝ, 2006, str. 9), a to především
v podobě map. Někteří autoři chápou kartografickou vizualizaci jako součást počítačové kartografie, resp.
počítačové tvorby map (PRAVDA et al, 2004, str. 186 nebo VOŽENÍLEK, 2005, str. 16), jiní naopak
zastávají názor, že s počítači přímo nesouvisí (MacEACHREN et al, 1992, str. 100).
6.2.1 Kartografická vizualizace senzorových dat
Kartografická vizualizace senzorových dat se řídí zavedenými kartografickými zásadami, ale zohledňuje
také specifika senzorových dat zmíněná v předchozí kapitole. Z hlediska kartografie představují vizualizace senzorových dat tzv. tematické mapy. Problematika tematické kartografické vizualizace je zpracována
autory (VOŽENÍLEK, 2011; SLOCUM et al, 2005). Při tvorbě vizualizace senzorových dat je potom
nutné zohlednit topografický podklad na straně jedné a senzorová data na straně druhé.
Topografický podklad jako hlavní lokalizační složka mapy je tvořen stabilními jednoznačně identifikovatelnými prvky krajiny pro dané měřítko. Typicky jsou využívány vodní objekty, sídla, budovy apod.
83
V případě tematických map je ovšem potlačen, aby nepoutal pozornost na úkor zobrazené tematiky.
Senzorová data je možné dále členit podle časového okamžiku pořízení na data pořízená v reálném čase a
data z předchozích měření. Zatímco v reálném čase jde o jeden konkrétní záznam, v případě již zaznamenaných měření mohou být k dispozici dlouhé časové řady.
6.3 Kartografická symbolika
S kartografickou vizualizací úzce souvisí pojmy grafická jednotka, znak a mapový znak. Grafická jednotka
je člověkem vnímatelný grafický útvar, který může mít různé vlastnosti, např. tvar, velikost, barvu, atd.
(PRAVDA, 1997, str. 19). Znak je potom grafická jednotka, která reprezentuje nějaký význam (např.
silnice 1. třídy). Mapový znak je grafická jednotka, která reprezentuje nějaký význam a je lokalizovaná v
mapě (PRAVDA, 1997, str. 19).
Mapový jazyk, resp. jazyk mapy, je specifický znakový systém, který používáme při zaznamenávání konkrétních objektů, jevů ze skutečnosti do mapy (DRÁPELA, 1987, str. 31 nebo KAŇOK, 1999, str. 36).
Mapový jazyk lze chápat též jako souhrn mapových znaků vytvářejících specifický formalizovaný jazyk
celé dané mapy (HOJOVEC et al, 1987, str. 257). Pro pojmy znak a mapový jazyk se používají i obecnější
označení, např. kartografické vyjadřovací prostředky (ČAPEK et al, 1992, str. 133) nebo kartografická
symbolika (KOZEL, 2009).
Termín kartografická, resp. mapová symbolika (angl. cartographic symbology, map symbology) vychází z
pojetí mapových znaků a mapového jazyka jako specifického systému symbolů ve smyslu grafické sémiotiky (BERTIN, 1983). Lze ji definovat následovně: Kartografická symbolika je systém znaků a pravidel,
podle kterých jsou prostorové objekty a jevy znázorněny na konkrétním mapovém díle, resp. dílech.
Kartografická symbolika jedné mapové vrstvy se blíží pojmu mapový znak, naopak kartografická symbolika celé mapy se blíží pojmu mapový jazyk. V návaznosti na předchozí kapitolu lze říci, že kartografická
vizualizace se zabývá mj. tvorbou kartografické symboliky pro konkrétní mapová díla.
6.3.1 Členění a vlastnosti mapových znaků
Kartografie běžně rozlišuje bodové, liniové a plošné mapové znaky. Toto členění je kartografy považováno
za nedostatečné (PRAVDA, 2003), ale z důvodu jeho jednoduchosti je stále používáno. Protože většina
existujících senzorových měření je bodového charakteru, budou se následující kapitoly věnovat možnostem kartografické vizualizace bodových znaků.
Mezi základní vlastnosti mapových znaků, jak je zmiňuje např. DRÁPELA (1983) komunikovatelnou,
názornost, interpretovatelnou a komprimovatelnost. BERTIN (1974) zmiňuje základní grafické proměnné, které jsou k dispozici pro konstrukci mapového znaku. Vliv základních grafických proměnných na
kvalitu (funkčnost) mapového znaku můžeme určit následovně:
• Velikost – obecně lze konstatovat, že větší velikost poskytuje výhodu pro lokalizaci daného znaku.
Na druhé straně ovšem vytváří nevýhodu vyššího grafického zaplnění a tím ztěžuje čtení mapy.
• Intenzita – vyšší intenzita použitého barevného odstínu opět poskytuje výhodu snazšího nalezení
mapového znaku, může ovšem působit rušivě na své okolí.
• Tvar – tvar je obecně jako charakteristika mapového znaku použitelný pouze u bodových mapových znaků. Omezení použití v případě liniových a plošných znaků je dáno tvarovou závislostí na
průběhu jevu, kterou může kartograf ovlivnit pouze omezeně.
• Orientace – ovlivnění orientace mapového znaku je podobně jako v případě tvaru omezeno na
bodové mapové znaky a pouze v omezené míře na objekty liniové a plošné.
• Barva – představuje nejvýraznější kartografický vyjadřovací prostředek. Volbou vhodného
barevného odstínu je možné zvýraznit důležité a potlačit méně důležité prvky mapy. Základním
84
předpokladem je nalezení míry mezi „uměřeností mapy“ a kontrastem, přičemž kontrast je
důležitější (FRIEDMANNOVÁ, 2007).
• Struktura – hraje podobnou roli jako barva, přičemž k barvě zde přistupuje vzor, který mapový
znak vyplňuje.
6.3.1.1 Bodové mapové znaky
Bodové mapové znaky zobrazují informace vztahující se k danému místu. Reálně by se naměřená data
měla vztahovat ke konkrétní souřadnici polohy senzoru. Výhodou senzorových měření může být také získávání různorodých informací z jednoho místa. Nejjednodušší metodou pro zobrazení více charakteristik
jednoho senzoru je použití vizualizace prostorového umístění senzoru a zobrazení měřených charakteristik v tabulce nebo grafu na vyžádání. Toto řešení je běžně používáno, příkladem může být Elektronický
digitální povodňový portál (http://www.edpp.cz). Sofistikovanější přístup je zobrazení alespoň jedné
charakteristiky pomocí mapového znaku a zbylých podobným způsobem jako v předchozím případě na
vyžádání. Uvedené řešení je použito na portál projektu EmoMap Technické univerzity ve Vídni.
Kartograficky elegantnějším řešením je ovšem zobrazení více informací prostřednictvím jednoho mapového znaku. Zmíněné mapové znaky potom zobrazují více měřených charakteristik. V anglické literatuře
používaný termín Multivariate ovšem stále nemá uspokojivý český ekvivalent.
6.3.1.2 Bodové mapové znaky zobrazující více charakteristik
SLOCUM et al (2005) uvádí pro tento typ mapových znaků několik možností. Jde o koláčový graf, hvězdicový graf, prostý sloupcový graf nebo metodu tzv. „Chernoff faces“. Všechny uvedené metody jsou vhodné i pro vizualizaci senzorových dat.
Při konstrukci těchto mapových znaků platí obecné zásady pro tvorbu mapových znaků. PRAVDA (2003)
uvádí tři základní principy a to konvečnost, libovolnost a asociativnost (motivovanost). Nejvíce možností
poskytuje princip motivovanosti, který naznačuje vztah mezi mapovým znakem a jeho předlohou.
Jako praktický příklad využívajícího zmíněných principů mohou sloužit mapové znaky zaměřené na vizualizaci zobrazující teplotu a vlhkost vzduchu a půdy vytvořené studenty předmětu Mapová sémiotika na
Geografickém ústavu Masarykovy univerzity v roce 2011 (viz obr. 6.1 na další stránce). Mimo zmíněné
charakteristiky byl přidán požadavek pro zobrazení kritických hodnot vzhledem k dalšímu sledovanému
jevu.
6.4 Formalizace mapového jazyka
Aby bylo možné provádět kartografickou vizualizaci automatizovaně, je nezbytné mapový jazyk formalizovat do podoby jasně definovaného formátu, který by byl srozumitelný pro výpočetní techniku. Otázka
formalizace mapového jazyka tedy vyvstala především v souvislosti s nástupem tvorby počítačových map,
ale její teoretické základy sahají hlouběji.
6.4.1 Historický vývoj
Již v 60. letech 20. století se objevují první náznaky tzv. jazykové koncepce mapy, která hraje v otázce
formalizace mapového jazyka důležitou roli, neboť nahlíží na mapu jako na specifický jazyk. PRAVDA
(1993) podrobně mapuje historii i význam jazykové koncepce mapy, kterou ovlivnili nebo utvářeli např.
J. Bertin, A. Koláčný, A. F. Aslanikašvili, L. Ratajski, C. Board, A. A. Ľutyj, a samozřejmě samotný Ján
Pravda. Ten ve své práci pokračoval i po rozmachu informačních technologií koncem 20. století (např.
PRAVDA et al, 2004).
85
Obr. 6.1 Návrhy mapových znaků pro zobrazení více charakteristik
První pokusy o formalizaci mapového jazyka ve světě informačních technologií však pravděpodobně
probíhaly víceméně nezávisle na teoretických poznatcích výše zmíněných autorů. Lze identifikovat dva
pravděpodobné důvody, proč tomu tak bylo. Zaprvé, kartografická symbolika v počítačovém prostředí
– především ve svých počátcích – vycházela z obecné počítačové grafiky. Dodnes je patrné, že mnohé
systémy pro popis kartografické symboliky využívají vyjadřovací prostředky, které jsou vhodnější spíše pro
počítačovou grafiku než pro kartografii (např. popis barvy v modelu RGB namísto pro kartografii většinou vhodnějšího modelu HSL). Zadruhé, za snahou o formalizaci mapového jazyka často stáli většinou
autoři počítačových programů, kteří byli spíše (geo)informatici než kartografové.
Zhruba od 80. let vzniklo v počítačovém světě mnoho formátů pro popis kartografické symboliky, které byly svázány s konkrétními aplikacemi. Většina z těchto formátů byla proprietárních a uzavřených. Z
otevřených formátů je známý formát MapFile, který je spojený s mapovým serverem UMN MapServer a
využívá se dodnes (FREIMUTH et al, 2005). Další zástupcem otevřených formátů je méně známý konfigurační formát programu Mapyrus (CHENERY, 2012), který podporuje i méně tradiční kartografickou
symboliku (např. náhodně rozmístěný prostorový vzor).
6.4.2 Otevřené specifikace kartografické symboliky
Na přelomu tisíciletí přišlo Open Geospatial Consortium (OGC) s do jisté míry revoluční snahou o vytvoření otevřeného formátu pro popis kartografické symboliky. Výsledkem byla v roce 2002 první verze spe-
86
cifikace Styled Layer Descriptor, SLD (OGC, 2002a), která byla později rozdělena do dvou samostatných
specifikací: Styled Layer Descriptor (OGC, 2007f ) a Symbology Encoding, SE (OGC, 2006). Vztah mezi
nimi je vysvětlen v následující podkapitole. Není náhodou, že vydání první verze SLD následovalo pouhý
rok po vydání specifikace Scalable Vector Graphics, SVG (W3C, 2006), která umožňuje otevřený popis
vektorové grafiky, a že SLD využívá prvky SVG.
Obě specifikace, SLD i SE, vznikly z podnětu komerčních společností a teoretická kartografie na ně neměla přímý vliv. Na druhou stranu v tuto chvíli zřejmě neexistují otevřené standardizované formáty s lepším
popisem kartografické symboliky. Důležitost a unikátnost obou specifikací budiž doložena i faktem, že je
pro popis kartografické symboliky využila i iniciativa Evropské unie Infrastructure for Spatial Information
in the European Community, INSPIRE (viz např. ŘEZNÍK, 2010).
Kartografické symboliky se dotýkají další dvě specifikace konsorcia OGC, Geography Markup Language
(GML) a Keyhole Markup Language (KML). Současná verze GML se kartografické symbolice věnuje
pouze velmi okrajově a neformálně (OGC, 2007b, Annex H). Specifikace KML (OGC, 2007c) se věnuje
popisu geografických dat i symboliky zároveň, přičemž z hlediska kartografické symboliky nedosahuje
možností SE.
6.5 Specifikace Symbology Encoding verze 1.1.0
Specifikace SLD 1.0.0 byla vydána v roce 2002 jako rozšíření specifikací Web Map Service (WMS) 1.1.1
(OGC, 2002b). Rozšíření spočívalo v možnosti nadefinování kartografické symboliky požadovaných map
a většinu specifikace tak tvořil popis formátu pro zápis kartografické symboliky. Právě tyto části se časem
začaly používat pro zápis kartografické symboliky i zcela nezávisle na specifikaci WMS. Logickým vyústěním bylo rozdělení specifikace SLD na část, která se věnuje pouze popisu kartografické symboliky
– Symbology Encoding (SE) 1.1.0 – a na část, která popisuje napojení SE na WMS – SLD 1.1.0. Pro
kartografickou vizualizaci a symboliku je důležitá především specifikace SE.
6.5.1 Struktura SE dokumentu
Podle specifikace SE je popis kartografické symboliky uložen v XML (eXtensible Markup Language) dokumentu se specifickou strukturou, jejíž definice je hlavním obsahem specifikace. Z obecného pohledu je
tedy SE dokument textový soubor zapsaný ve značkovacím jazyce XML.
SE dokumenty mohou či nemusí být svázány s konkrétní sadou geografických dat. Vytvářet SE dokument
bez návaznosti na konkrétní datovou sadu má ovšem zhruba takový smysl jako vytvářet značkový klíč bez
znalosti reprezentovaných dat.
Každý SE dokument je tvořený buď právě jedním stylem nebo právě jedním symbolizérem.
Styl (angl. style) je nositelem kartografické symboliky pro libovolnou množinu geografických objektů stejného typu (např. pro množinu sídel nebo silnic). Existují dva typy stylů, FeatureTypeStyle pro vektorová
data a CoverageStyle pro rastrová data. Každý styl je tvořený jedním či více pravidly.
Pravidlo (angl. rule) umožňuje v rámci jednoho stylu definovat různou symboliku pro různá měřítka i pro
různé podmnožiny objektů. V rámci jednoho stylu silnic je tedy možné nadefinovat různou symboliku
pro měřítkové rozsahy 1:10 000-1:25 000 a 1:25 000-1:100 000, případně různou symboliku pro dálnice
a silnice 1. třídy. Oba způsoby je možné kombinovat, takže lze vytvořit různou symboliku pro dálnice v
měřítku 1:10 000-1:25 000, dálnice v měřítku 1:50 000-1:100 000, atd. Měřítkové rozsahy mohou uzavřené oboustranně i jednostranně. Samotná symbolika každého pravidla je zapsána pomocí jednoho či
více symbolizérů.
Symbolizér (angl. symbolizer) je elementárním nositelem symboliky zobrazovaných geografických
objektů. Pomocí symbolizérů lze popsat figurální (PointSymbolizer), čárové (LineSymbolizer) i areálové
87
(PolygonSymbolizer) znaky včetně popisků (TextSymbolizer). Všechny tyto symbolizéry se týkají
vektorových dat, pro rastrová data existuje samostatný RasterSymbolizer. Díky tomu, že jedno pravidlo
může mít více symbolizérů, lze v rámci jednoho pravidla popsat např. plošný znak sídel a zároveň i podobu
jejich popisku.
6.5.2 Základní prvky SE dokumentu z hlediska kartografie
Styl obsahuje popis sady příbuzných znaků (příbuzných z hlediska typu objektu, který reprezentují), přičemž je možné v něm popsat i proměnlivost znaku s měřítkem. Je zřejmé, že se nejedná o kartografické
znaky, neboť zatím nejsou umístěny v mapě. Sada může být tvořena pouze jedním znakem.
Pravidlo je nejjednodušším nositelem kartografické symboliky a z kartografického hlediska je nejblíže
pojmu znak, neboť v sobě jednoznačně spojuje grafickou reprezentaci (v podobě symbolizéru) i význam
zobrazovaného objektu.
Symbolizér leží na pomezí pojmů grafická jednotka a znak. Podobnost s grafickou jednotkou je zřejmá.
Symbolizéry však mohou obsahovat (a v praxi často obsahují) odkazy na konkrétní atributy zobrazovaných objektů (např. TextSymbolizer většinou obsahuje odkaz na atribut názvu objektu, PointSymbolizer
může obsahovat odkaz na atribut velikostní kategorie sídel, apod.). V takovém případě lze symbolizér
považovat spíše za znak.
6.5.3 Symbolizéry
V následujících odstavcích jsou popsány výrazové možnosti symbolizérů. Použitá terminologie odpovídá
terminologii Jána Pravdy (PRAVDA, 1997), případně je doplněna o některé další, dnes běžně používané
termíny (např. průhlednost).
PointSymbolizer umožňuje definovat figurální znak reprezentující vektorová data čtyřmi způsoby:
• zvolit jeden z předdefinovaných tvarů – čtverec, kolečko, trojúhelník, hvězda, křížek nebo křížek
otočený o 45 ° – a nadefinovat mu požadovanou výplň a tah,
• zvolit jeden znak TrueType fontu a nadefinovat mu požadovanou výplň a tah,
• uvést odkaz na libovolný rastrový nebo vektorový obrázek, který je uložen v samostatném souboru
(a případně změnit jednu či více jeho barev) nebo
• nadefinovat libovolný obrázek rastrový nebo vektorový přímo v SE dokumentu (a případně změnit jednu či více jeho barev).
Takto nadefinovaným figurálním znakům lze v rámci tohoto symbolizéru dodatečně nastavit také velikost, průhlednost, orientaci, referenční bod a případně posun. Kromě toho lze v rámci jednoho symbolizéru provádět i další morfografické operace jako např. sdružování, skládání, uspořádání nebo afixace.
LineSymbolizer umožňuje definovat čárový znak reprezentující vektorová data. Lze popsat znaky jedno i
více tahové, jedno i více barevné, vyplněné barvou i vzorem, plné, přerušované i se vzorkem vč. lemovek.
Každému tahu lze nastavit barvu, šířku, průhlednost a typ ukončení. Především u složitějších kombinací
typu nesymetrický vícetahový čárový znak se vzorkem je třeba počítat s tím, že specifikace nenabízí dostatečné výrazové prostředky pro popsání veškerých souvislostí.
PolygonSymbolizer umožňuje definovat areálový znak reprezentující vektorová data. Lze popsat znaky
jedno i dvou vrstvové, ohraničené i neohraničené konturou, prázdné, vyplněné barvou, vzorem i figurálním znakem. Každé vrstvě lze nastavit barvu a průhlednost. Šrafuru lze popsat pouze pomocí opakujícího
se vzoru. Kontura areálového znaku má stejný popis jako čárový znak.
TextSymbolizer umožňuje definovat názvy na mapách (popisky) reprezentující vektorová data. Lze
popsat požadovaný řez písma (font) vč. jeho stylu (kurzíva, tučné, tučná kurzíva, normální) a velikosti.
Výplň písma má stejný popis jako výplň areálového znaku. Dále lze popsat umístění popisku figurálního
88
a liniového znaku. V případě popisku figurálního znaku lze nastavit referenční bod, posun a orientaci, v
případě liniového odsazení od linie, opakování, mezery v opakování a orientaci popisku rovnoběžně s linií
nebo horizontálně. Dále je možno popsat tzv. halo efekt.
RasterSymbolizer umožňuje nadefinovat areálové znaky reprezentující rastrová data. Lze popsat dva
typy znaků:
• jednoduchý areálový znak vymezený stykem barev (např. diskrétní barevná hypsografie) nebo
• spojitý složený areálový znak (např. snímky dálkového průzkumu Země nebo výškové modely terénu s možností vykreslení stínovaného reliéfu).
Obecně je možné nastavovat barvy a barevné přechody na základě hodnot buněk rastrových dat, případně
přiřadit pásmům rastrových dat barevné složky obrazu (R, G, B nebo stupně šedi). Dále je možné nastavit
průhlednost.
Symbolizéry umožňují v omezené míře popsat i kartografickou symboliku vyšší úrovně, jako např. kartogramy nebo kartodiagramy (KOZEL, 2009).
6.6 Hodnocení mapových znaků
Hodnocení mapových znaků a představuje komplexní problematiku, která je zaměřena na zjištění schopnosti mapy plnit účel ke kterému byla navržena, která má své místo i v případě vizualizace senzorových dat.
V současné době je používáno více přístupů k hodnocení mapových znaků. Zřejmě nejpoužívanější jsou
expertní a uživatelské hodnocení. Tyto přístupy jsou bohužel omezeny minimální možností jejich objektivizace a vyloučením uživatelů z hodnocení v případě expertního hodnocení. Expertní hodnocením mapových znaků navržených pro vizualizaci senzorových dat použila např. TYNKLOVÁ (2012), která navržené znaky klasifikuje do skupin z hlediska jejich vhodnosti pro použití v navrženém systému vizualizace.
Objektivizací hodnocení mapových děl se intenzivně zabýval např. MIKLOŠÍK (2002). Další variantu
objektivního hodnocení mapových znaků představuje tzv. kartograficko-psychologické testování. Výhodou tohoto přístupu je zahrnutí uživatelů do procesu hodnocení s možností objektivizace výsledků.
Prostředkem pro uvedené hodnocení může být SW nástroj MUTEP (Multivariantní testovací program)
vyvinutý na Geografickém ústavu MU. Testovací SW a jeho použití popisuje např. ŠTĚRBA et al (2011).
6.7 Závěr
S ohledem na charakter dat poskytovaných prostřednictvím senzorů se jejich vizualizace odehrává především prostřednictvím internetu. Výhody publikace map prostřednictvím webu zmiňuje např. PETERSON (2003). Přes výše zmíněná omezení umožňují existující standardy definování kartografické symboliky odpovídající zavedeným kartografickým zásadám a nástroje pro jejich hodnocení jejich optimalizaci.
Senzory a informace získané jejich prostřednictvím mají potenciál využití v celé řadě oborů lidské činnosti. Jejich vhodná kartografická vizualizace a jejich publikace prostřednictvím internetu vnáší do tohoto
procesu další přidanou hodnotu. Lze tedy předpokládat širší využití dostupných senzorových dat a také
zvyšování počtu dostupných senzorů.
89
REFERENCE
Knihy a další tištěné materiály
BERTIN, J. 1983. Semiology of Graphics. Madison: University of Wisconsin Press, 1983. 415 s. ISBN
0299090604.
CABRI, G. ET AL. 2009. Uncoupling Coordination. In Tarkoma, S.: Mobile middleware: architecture,
patterns and practice. Chichester: Wiley, 2009, s. 229 - 256 [cit. 2012-10-15]. ISBN 0470740736.
CHATZIGIANNAKIS, I. – MYLONAS, G. – NIKOLETSEAS, S. 2007. 50 ways to build your application: a survey of middleware and systems for Wireless Sensor Networks. ETFA 2007 12th IEEE International Conference on Emerging Technologies and Factory Automation: ETFA 2007 proceedings,
Patras, Greece. Piscataway, NJ: IEEE, 2007, p. 466 – 473. ISSN 978-1-4244-0826-9.
ČAPEK, R. – MIKŠOVSKÝ, M. – MUCHA, L. 1992. Geografická kartografie. Praha: Státní pedagogické nakladatelství, 1992. 373 s. ISBN 8004251536.
DENZER, R. – SCHLOBINSKI, S. – HELL, T. – GUTTLER, R. – GIDHAGEN, L. 2011. Towards
automation of model execution from a decision support environment. In 19th International Congress
on Modelling and Simulation, Perth, Australia, 2011.
DRÁPELA, M. V., 1983. Vybrané kapitoly z kartografie, Přírodovědecká fakulta J. Ev. Purkyně v Brně,
Katedra geografie, 128 s.
EXECUTIVE ORDER 12906. 1994. Coordinating Geographic Data Acquisition and Access: the National
Spatial Data Infrastructure. Edition of the Federal Register, Vol. 59, Is. 71, p. 17671-17674.
FRANK, A. ET AL. 2000. Panel-GI Compendium: A guide to GI and GIS. Vienna: GeoInfo Series 21,
2000. 141 s., ISBN 3-901716-22.
FRIEDMANNOVÁ, L. 2007. Kartografický znak v dynamické vizualizaci. In Súčasné trendy v kartografii: Zborník referátov 17. kartografickej konferencie. vyd. Bratislava.
HAVLIK, D. – SCHADE, S. – VAN WIJK, W. – USLÄNDER, T. – HIERRO, J. 2011. Leveraging
the Future Internet – Public Private Partnership for the Environmental Usage Area. In EnviroInfo
Conference 2011, Ispra, Italy, 2011.
HERMAN, L. 2011a. Moderní kartografické metody modelování měst. Brno: Masarykova univerzita. Přírodovědecká fakulta. Geografický ústav. 2011. 84 s., 25 s. příloh. Vedoucí diplomové práce Tomáš
Řezník.
HERMAN, L. 2011b. Sémantický přístup ke 3D modelování se nazývá CityGML. GeoBusiness, Praha:
Springwinter, 2011b roč. 10, č. 3, s. 40-42. ISSN 1802-4521.
HŘEBÍČEK, J. – KONEČNÝ, M. 2007. Introduction to Ubiquitous Cartography and Dynamic Geovisualization with Implications for Disaster and Crisis Management. In: The Geospatial Web: How
Geobrowsers, Social Software and the Web 2.0 are Shaping the Network Society, Springer, 2007.
s. 209214. ISBN 9781846288265.
HOJOVEC, V. ET AL. 1987. Kartografie. Praha: Geodetický a kartografický podnik, 1987. 660 s.
ISO. 2003. ISO 19115:2003 Geografická informace – Metadata.
ISO. 2005. ISO 19119:2005 Geografická informace – Služby.
ISO. 2007. ISO 19139:2007 Geografická informace – Metadata – XML schéma implementace.
KAŇOK, J. 1999. Tematická kartografie. Ostrava: Ostravská univerzita, 1999. 318 s. ISBN 8070427817.
KLOPFER, M. – SIMONIS, I. 2009. SANY - an open service architecture for sensor networks. SANY IP,
2009. 161 s. ISBN 978-3-00-028571-4.
KONEČNÝ, M. 1996. Národní prostorová informační infrastruktura: předpoklad rozvoje a plného využití
GIS. In Národní prostorová informační infrastruktura. 1. vyd. Vyškov: Antrim s.r.o., 1996.
90
KONEČNÝ, M. 1995. Jak dál s GIS na pozadí informačních dálnic? In Zpracování digitálních dat v GIS a
digitální kartografii. Sborník Kartografického sympozia Olomouc 95. 1. vyd. Olomouc: Kartografické
sympozium Olomouc 1995, 1995. s. 46-50.
KONEČNÝ, M. 1999. The Digital Earth:Spatial Data Infrastructures from Local to Global Concept. Beijing, China: Chief Guanhua Xu and Yuntai Chen, 1999. 7 s. ISBN 7-03-005600-0.
KONEČNÝ M. 2008. Digital Earth Idea: Quo Vadis? In Consideration of Alexander Martynenko Contributions and Ideas. In: Systems and Tools of Informatics. Special Issue: Geoinformation Technologies. - Russian Academy of Science. The Institute of Informatics Problems of the Russian Academy of
Sciences (IPI RAN)", Moscow, 2008. 400 s., s. 339-356. ISBN 978-5-902030-58-4.
KOZEL, J. 2009. Komplexní kartografická symbolika a specifikace Symbology Encoding. In: Geodny Liberec
2008 - Sborník příspěvků, Liberec: Technická univerzita, 2009. 7 s. ISBN 9788073724436.
LEWIS, F. L. 2005. Wireless sensor networks. In: COOK, D. J – DAS, S. K. Smart environments: technologies, protocols, and applications. Hoboken, New Jersey: Wiley, 2005, s. 13 - 31. ISBN 0-471-544485.
MacEACHREN, A. M. 1995. How Maps Work. New York: Guilford Press, 1995. 513 s. ISBN 0898625890.
MacEACHREN, A. M. et al. 1992. Visualization. In Geography’s Inner Worlds: Pervasive Themes in
Contemporary American Geography, New Brunswick: Rutgers University Press, 1992. s. 99-137.
MASSER, I. 1999. All Shapes and Sizes: The first generation of national geographic information strategies.
International Journal of Geographic Information Science Vol. 13 Is. 1. s. 67 – 84.
MASSER I. 2007. Building European Spatial Data Infrastructures. ESRI Press. Redlands. 2007.
MIKLOŠÍK, F. 2002. Objektivizace hodnocení map a mapových děl, Vojenská akademie v Brně, S-619,
Brno, 90 s.
PETERSON, M. P. 2003. Maps and the Internet. 1st ed. Oxford: Elsevier, 451 s. ISBN 0080442013.
PLEWE, B. 1997. GIS Online: Information Retrieval, Mapping, and the Internet. Santa Fe, New Mexico:
Onword Press, 1997. 336 s. ISBN 978-1566901376
Pravda, J. 1993. Jazyková koncepcia mapy, jej vývoj a súčasný stav. Kartografické listy, Bratislava: geografický ústav SAV, 1993, roč. 1, č. 1, s. 27-36. ISSN 13365274.
PRAVDA, J. 1997. Mapový jazyk. Bratislava: Univerzita Komenského, 1997. 88 s. ISBN 8022311022.
PRAVDA, J. 2003. Mapový jazyk, univerzita Komenského Bratislava, Prírodovedecká fakulta, Bratislava,
88s.
PRAVDA, J. – KUSENDOVÁ, D. 2004. Počítačová tvorba tematických máp. Bratislava: Univerzita Komenského, 2004. 264 s. ISBN 8022320110.
Rajabifard, A. et al. 2006. The Role of Subnational Government and the Private Sector in Future
Spatial Data Infrastructures. International Journal of GIS 20(7): s. 727-41, 2006.
Řezník, T. 2010. Kartografická vizualizace v souladu s datovými specifikacemi INSPIRE. Kartografické
listy, Bratislava: Geografický ústav SAV, 2010, roč. 18, č. 1, s. 96-104. ISSN 13365274.
SCHADE, S. – FOGARTY, B. – KOBERNUS, M. – SCHLEIDT, K. – GAUGHAN, P. – MAZZETTI, P. – BERRE, A., J. 2011. Environmental Information Systems on the Internet - A Need for
Change. In: Environmental Software Systems. Frameworks of eEnvironment, Proceedings of the 9th
IFIP WG 5.11 International Symposium, ISESS 2011, Brno, Czech Republic, 2011.
SLOCUM, T. ET AL. 2005. Thematic Cartography and Geographic Visualization. Upper Saddle River:
Pearson Education. 2005. 518 s. ISBN 0130351237.
STOLERU, R. – HE, T. – STANKOVIC, J. A. – LUEBKE, D. 2005. A high-accuracy, low-cost localization system for wireless sensor networks. In: SenSys ’05: Proceedings of the 3rd international conference
on Embedded networked sensor systems. New York: ACM Press, 2005, 13–26.
91
STRZALKA, A. – BOGDAHN, J. – COORS, V. – EICKER, U. 2011. 3D City Modelling for Urban
Scale Heating Energy Demand Forecasting. In HVAC&R Research, Vol. 17, Is. 4, 2011. 14 s. ISSN
1078-9669.
ŠTĚRBA, Z. – STACHOŇ, Z. – ŠAŠINKA, Č. – ZBOŘIL, J. - BŘEZINOVÁ Š. – TALHOFER V.
2011. Evaluace kartografických znakových sad v kontextu osobnosti uživatele. Geodetický a kartografický obzor, Praha: Český úřad geodetický a kartografický, 99/57, 8, 2011. 10 s. ISSN 0016-7096.
TYNKLOVÁ, K. 2012. Vybrané aspekty kartografické vizualizace dat senzorů. Masarykova univerzita. Přírodovědecká fakulta. Geografický ústav. 2012. Vedoucí diplomové práce Petr Kubíček.
VOŽENÍLEK, V. 2005. Cartography for GIS. Olomouc: Univerzita Palackého v Olomouci, 2005. 142 s.
ISBN 8024410478.
VOŽENÍLEK, V. 2009. Geoinformační aspekty státní informační politiky. 1. Vyd. Olomouc: Univerzita
Palackého v Olomouci, 2009. 187 s. ISBN 978-80-244-2253-4.
VOŽENÍLEK, V. – KAŇOK, J. ET AL. 2011. Metody tematické kartografie: vizualizace prostorových
jevů. 1. vyd. Olomouc: Univerzita Palackého v Olomouci, 2011. 216 s. ISBN 978-80-244-2790-4.
WALLACE, J. et al. 2006. Spatial information opportunities for Government, Journal of Spatial Science,
Vol. 51, No. 1, June 2006.
WILLIAMSON, I., RAJABIFARD, A., BINNS, A. 2007. The Role of Spatial Data Infrastructures in
Establishing an Enabling Platform for Decision Making in Australia. In: Research and Theory in
Advancing Spatial Data Infrastructure Concepts. Edited by H. Onsrud. ESRI Press. 293 s., s. 121132. ISBN 978-158948-162-6. 2007.
Online dostupné zdroje a webové stránky
AKYILDIZ, I. F. – SU, W. – SANKARASUBRAMANIAM, Y. – CAYIRCI, E. 2002. Wireless sensor
networks: a survey. Computer Networks [online]. 2002, Vol. 38, Is. 4, s. 393-422 [cit. 2012-10-15].
ISSN 13891286. < http://linkinghub.elsevier.com/retrieve/pii/S1389128601003024>
BECKER, T. – NAGEL, C. – KOLBE, T. H. 2010. UtilityNetworkADE – core model – modeling proposal [online]. 2010 [cit. 2012-9-22]. <http://www.citygmlwiki.org/upload/c/c2/UtilityNetworkADE_v0.1.0.pdf>
BENNETT, R.M. - RAJABIFARD, A. 2009. Spatially Enabling Government: A Snapshot from Victoria,
[on line]. 2009 [cit. 2012-10-15]. <http://www.csdila.unimelb.edu.au/publication/conferences/
spatially_enabling_government_snapshot_from_victoria.pdf>
BRÖRING, A. – ECHTERHOFF, J. – JIRKA, S. – SIMONIS, I. – EVERDING, T. – STASCH, C.
– LIANG, S. – LEMMENS, R. 2011. New Generation Sensor Web Enablement: A Survey. Sensors
[online]. 2011, Vol. 11, Is. 3. [cit. 2012-10-15]. ISSN 1424-8220. <http://www.mdpi.com/14248220/11/3/2652/>
Chenery, S. 2012. Mapyrus project. Version 1.202. 2005 [cit. 2012-10-14]. 150 s. <http://mapyrus.
sourceforge.net/mapyrus.pdf>
CT. 2012. D2.10.2: Coverage Types, Version 1.0rc2 [online]. 2012 [cit. 2012-11-10]. <http://inspire.jrc.
ec.europa.eu/documents/Data_Specifications/D2.10.2_CoverageTypes_v1.0rc2.pdf>
CZERWINSKI, A. – PLŰMER, L. 2008. Abschlussbericht EU-Umgebungslärmkartierung Stufe I in
Nordrhein-Westfalen [online]. 2008 [cit. 2012-9-21]. <http://www.umgebungslaerm.nrw.de/Dokumente/Berichte/Abschlussbericht_Kartierung_Stufe_1.pdf>
DELIN, K. – JACKSON, S. – SOME, R. 1999. Sensor Webs. In NASA Tech. Briefs [online]. 1999. [cit.
2012-10-15]. <http://geodynamics.jpl.nasa.gov/workshop/sensorweb/Delin-Jackson.pdf>
DÖLLNER, J. – KOLBE, T. H. – LIECKE, F. – SGOUROS, T. – TEICHMAN, K. 2006. The
Virtual 3D City Model of Berlin - Managing, Integrating and Communicating Complex Urban
Information [online]. 2006 [cit. 2012-9-23]. <http://www.citygml.org/fileadmin/citygml/docs/
udms_berlin3d_2006.pdf>
92
DoATaS. 2008. Drafting Team "Data Specifications" – deliverable D2.3: Definition of Annex Themes and
Scope [online]. 2008 [cit. 2012-9-27]. <http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/DataSpecifications/D2.3_Definition_of_Annex_Themes_and_scope_v3.0.pdf>
DS BM. 2012. D2.10.3: Generic Activity Complex, Version 1.0rc2 [online]. 2012 [cit. 2012-11-10].
<http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.10.3_GenericActivityComplex_v1.0rc2.pdf>
DS BUILDINGS. 2012. D2.8.III.2 INSPIRE Data Specification on Buildings – Draft Guidelines [online]. 2012 [cit. 2012-9-27]. <http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/
INSPIRE_DataSpecification_BU_v3.0rc2.pdf>
DS SOIL. 2011. D2.8.III.3 INSPIRE Data Specification on SOIL – Draft Guidelines [online]. 2011 [cit.
2012-11-10]. <http://inspire.jrc.ec.europa.eu/documents/ Data_Specifications/INSPIRE_Data_
Specification_SO_v3.0rc2.pdf>
DT METADATA. 2007. DT Metadata – Draft Implementing Rules for Metadata (D1.3) [online]. 2007
[cit. 2012-26-10]. <http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/draftINSPIREMetadataIRv2_20070202.pdf>
EDPP. 2012. Elektronický digitální povodňový portál [online]. 2012 [cit. 2012-18-10]. <http://www.
edpp.cz/>
EEA. 2012. Informace o GMES na stránkách EEA [online]. 2012 [cit. 2012-8-9]. <http://www.eea.
europa.eu/about-us/what/information-sharing-1/gmes>
E-ESDI. 2001. ESDI Organisation and E-ESDI Action Plan [online]. 2001 [cit. 2012-9-27]. <http://
inspire.jrc.ec.europa.eu/reports/ESDI_Action_plan1aa13.pdf>
EICKER, U. – STRZALKA, A. – SCHULTE, C. – BOGDAHN, J. – SCHUMACHER, J. – COORS, V. 2010. Large Scale Integration of Photovoltaics in Cities [online]. 2010 [cit. 2012-9-22].
<http://www.hft-stuttgart.de/Forschung/Kompetenzen/zafh/Publikationen/publikationen_
download/2010/Eicker_Strzalka_Schulte_Bogdahn_Schumacher_Coors_ICSU_2010.pdf>
ENVIROFI, 2012. The Environmental Observation Web and its Service Applications within the Future
Interne [online]. 2012 [cit. 2012-10-9]. <www.envirofi.eu>
ESA. 2012. Informace o vesmírné divizi GMES na stránkách ESA [online]. 2012 [cit. 2012-7-9].
<http://www.esa.int/esaLP/SEMBRS4KXMF_LPgmes_0.html>
ESA S1. 2012. Sentinel-1 - ESA’S Radar Observatory Mission for GMES Operational Services [online].
European Space Agency, March 2012 [cit. 2012-10-9]. <http://esamultimedia.esa.int/docs/S1-Data_Sheet.pdf>
ESA S2. 2012. Sentinel-2 – the Operational GMES Optical High Resolution Land Mission [online].
European Space Agency, March 2012 [cit. 2012-10-9]. <http://esamultimedia.esa.int/docs/S2-Data_Sheet.pdf>
ESA S3. 2012. Sentinel-3 – GMES Medium Resolution Land and Ocean Mission [online]. European
Space Agency, March 2012 [cit. 2012-10-9]. <http://esamultimedia.esa.int/docs/S3-Data_Sheet.
pdf>
EU. 2003. Směrnice Evropského parlamentu a Rady 2003/98/ES ze dne 17. listopadu 2003 o opakovaném použití informací veřejného sektoru [online; česká verze z Úředního věstníku Evropské
unie]. 2003 [cit. 2012-28-10]. <http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32003L0098:CS:HTML>
EU. 2006. Rozhodnutí Evropského parlamentu č. 1982/2006/EC z 18. prosince 2006 [online] 2006. [cit.
2012-13-10]. <http://cordis.europa.eu/documents/documentlibrary/90798681EN6.pdf>
EU. 2007. Směrnice Evropského parlamentu a Rady 2007/2/ES ze dne 14. března 2007 o zřízení Infrastruktury pro prostorové informace v Evropském společenství [online; česká verze z Úředního věstníku
Evropské unie] 2007. [cit. 2012-28-10]. <http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2007:108:0001:01:CS:HTML>
93
EU. 2008. Nařízení Komise (EU) č. 1205/2008 ze dne 3. prosince 2008, kterým se provádí směrnice Evropského parlamentu a Rady 2007/2/ES týkající se metadat [online; česká verze z Úředního věstníku
Evropské unie]. 2008 [cit. 2012-28-10]. <http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:326:0012:0030:CS:PDF>
EU. 2009a. Nařízení Komise (EU) č. 976/2009 ze dne 19. října 2009, kterým se provádí směrnice Evropského parlamentu a Rady 2007/2/ES, pokud jde o síťové služby [online; česká verze z Úředního věstníku Evropské unie] 2009 [cit. 2012-28-10]. <http://eur-lex.europa.eu/LexUriServ/LexUriServ.
do?uri=OJ:L:2009:274:0009:0018:CS:PDF>
EU. 2009b. Communication from the Commission to the European Parliament, the Council, the European
economic and social committee and the Commitee of the regions - Global Monitoring for Environment
and Security (GMES): Challenges and Next Steps for the Space Component. [online] 2009. [cit.
2012-18-10]. < http://ec.europa.eu/enterprise/policies/space/files/gmes/communication_589_
en.pdf>
EU. 2009c. Rozhodnutí Komise 2009/442/ES ze dne 5. června 2009, kterým se provádí směrnice Evropského parlamentu a Rady 2007/2/ES, pokud jde o sledování a podávání zpráv [online; česká verze
z Úředního věstníku Evropské unie] 2009 [cit. 2012-28-10]. <http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:148:0018:0026:CS:PDF>
EU. 2010a. Nařízení Komise (EU) č. 1089/2010 ze dne 23. listopadu 2010, kterým se provádí směrnice
Evropského parlamentu a Rady 2007/2/ES, pokud jde o interoperabilitu sad prostorových dat a služeb
prostorových dat [online; česká verze z Úředního věstníku Evropské unie] 2010 [cit. 2012-28-10].
<http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:323:0011:0102:CS:PDF>
EU. 2010b. Regulation (EU) No 911/2010 of the European Parliament and the Council of 22 September
2010 on the European Earth monitoring programme (GMES) and its initial operations (2011 to
2013) [online]. Official Journal of the European Union, L 276, 2010 [cit. 2012-18-10]. < http://
eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:276:0001:0010:EN:PDF >
EU. 2010c. NAŘÍZENÍ KOMISE (EU) č. 1088/2010 ze dne 23. listopadu 2010,kterým se mění nařízení (ES) č. 976/2009, pokud jde o služby stahování dat a transformační služby [online; česká verze
z Úředního věstníku Evropské unie] 2010 [cit. 2012-28-10]. <http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:323:0001:0010:CS:PDF>
EU. 2010d. NAŘÍZENÍ KOMISE (EU) č. 268/2010 ze dne 29. března 2010, kterým se provádí směrnice
Evropského parlamentu a Rady 2007/2/ES, pokud jde o poskytnutí přístupu k sadám prostorových
dat a službám prostorových dat členských států orgánům a subjektům Společenství za harmonizovaných podmínek [online; česká verze z Úředního věstníku Evropské unie] 2010 [cit. 2012-28-10].
<http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:083:0008:0009:CS:PDF>
EU. 2011a. Communication from the Commission to the European Parliament, the Council, the European
economic and social committee and the Commitee of the regions on the European Earth monitoring
programme (GMES) and its operations ( from 2014 onwards) [online]. 2011[cit. 2012-18-10].
<http://ec.europa.eu/enterprise/policies/space/files/gmes/com%282011%29831_en.pdf>
EU. 2011b. European Earth monitoring programme (GMES) and its initial operations (2011 – 2013) –
Work programme 2012 [online]. 2011 [cit. 10-9-2012]. <http://ec.europa.eu/enterprise/policies/
space/files/gmes/gio_wp2012_final_en.pdf>
EU. 2011c. Nařízení komise (EU) č. 102/2011 ze dne 4. února 2011, kterým se mění nařízení (EU) č.
1089/2010, kterým se provádí směrnice Evropského parlamentu a Rady 2007/2/ES, pokud jde o
interoperabilitu sad prostorových dat a služeb prostorových dat [online; česká verze z Úředního věstníku Evropské unie] 2011 [cit. 2012-28-10]. <http://eur-lex.europa.eu/LexUriServ/LexUriServ.
do?uri=OJ:L:2011:031:0013:0034:CS:PDF>
EUMETSAT. 2012. Informace o vesmírné divizi GMES na stránkách EUMETSAT [online]. 2012 [cit.
2012-8-9]. <http://www.eumetsat.int/Home/Main/AboutEUMETSAT/ InternationalRelations/
EuropeanPartners/EUEC/GMES/SP_1226310811300>
FAROOQ, M. O. – KUNZ, T. 2011. Operating Systems for Wireless Sensor Networks: A Survey. Sensors
[online]. 2011, Vol. 11, Is. 6, s. 5900-5930 [cit. 2012-10-15]. ISSN 1424-8220. <http://www.
mdpi.com/1424-8220/11/6/5900/>
94
FP6. 2012. Research & Innovation – Sixth Framework Programme 2002 – 2006 [online]. 2012 [cit.
-2012-9-9]. <http://ec.europa.eu/research/fp6>
Freimuth, P. – Christl, A. – Tveite, H. 2005. Cartographical Symbol Construction with
MapServer [online]. 2005 [cit. 2012-10-14]. <http://www.mapserver.org/mapfile/symbology/
construction.html>
GCM. 2012. D2.5: Generic Conceptual Model, Version 3.4rc2 [online]. 2012 [cit. 2012-11-10]. <http://
inspire.jrc.ec.europa.eu/documents/Data_Specifications/ D2.5_v3.4rc2.pdf>
GEO Portal. 2012. GEO Portal – uživatelské rozhraní pro vyhledávání dat projektu GEOSS [online].
2012 [cit. 2012-10-9]. <http://www.geoportal.org/web/guest/about_gci>
GEO. 2011. GEO 2012-2015 Work plan, revision 1 [online]. 2011 [cit. 2012-6-9]. <http://www.
earthobservations.org/documents/work%20plan/GEO%202012-2015%20Work%20Plan_Rev1.
pdf>
GoEoSD. 2011. D2.7: Guidelines for the encoding of spatial data, Version 3.1 [online]. 2011 [cit. 201211-10]. <http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.7_v3.1.pdf>
GEOSS 2012a. Geohazard Supersites & Natural Laboratories [online]. 2012 [cit. 2012-7-9]. <http://
supersites.earthobservations.org>
GEOSS. 2012b. Oficiální stránky skupiny pro pozorování Země GEO a projektu GEOSS [online]. 2012
[cit. 2012-7-9]. <http://www.earthobservations.org/>
GIGAS. 2010. GIGAS Technology Watch and Comparative Analysis. [online]. 2010 [cit. 2012-7-9].
<http://www.thegigasforum.eu/>
GMES CZ. 2012. Oficiální stránky GEOSS/GMES v ČR [online]. 2012 [cit. 2012-10-9]. <http://gmes.
gov.cz/>
GMES EU (2012) Oficiální stránky GMES [online]. 2012 [cit. 2012-10-9]. <http://www.gmes.info/>
GNM. 2012. D2.10.1: Generic Network Model, Version 1.0rc2 [online]. 2012 [cit. 2012-11-10].
<http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.10.1_GenericNetworkModel_v1.0rc2.pdf>
GR. 2010. Guidance on the 'Regulation on access to spatial data sets and services of the Member States by
Community institutions and bodies under harmonised conditions' [online]. 2010 [cit. 2012-11-10].
<http://inspire.jrc.ec.europa.eu/documents/Data_and_Service_Sharing/DSSDraftGuidancedocument_v4.1.pdf>
HAASE, K. – KOCH, R. 2010. Extension of Electronical Nautical Charts for 3D interactive Visualization via CityGML. [online]. 2010 [cit. 2012-9-22]. <http://www.geoinformatik2010.de/public/
abstracts/haase_koch.pdf>
IEEE. 2000. IEEE standard for a smart transducer interface for sensors and actuators network capable
application processor (NCAP) information model [online]. New York: Institute of Electrical and
Electronics Engineers, 2000 [cit. 2012-10-15]. ISBN 07-381-1768-4. <http://ieeexplore.ieee.org/
xpls/abs_all.jsp?arnumber=841361>
INSPIRE METADATA IMPLEMENTING RULES. 2010. INSPIRE Metadata Implementing Rules:
Technical Guidelines based on EN ISO 19115 and EN ISO 19119 (Version 1.2) [online]. 2010 [cit.
30-10-2012]. <http://inspire.jrc.ec.europa.eu/documents/Metadata/INSPIRE_MD_IR_and_
ISO_v1_2_20100616.pdf>
ISTWEB, 2012. Environmental Risk Management – Information Society Technologies [online]. 2012 [cit.
2012-12-9]. <http://cordis.europa.eu/ist/so/env-risk-management/home.html>
KONEČNÝ, M. 2006. Mobile and Adaptive Cartography and Geoinformatics in Early Warning and Crises Management. In: Seventeenth United Nations Regional Cartographic Conference for Asia and
the Pacific Bangkok [online]New York: United Nations, 2006 [cit. 2012-01-10]. 13 s. <http://
unstats.un.org/unsd/geoinfo/17thunrccapIP36.pdf>
KOLBE, T. H. 2012. CityGML Homepage [online]. 2012 [cit. 2012-19-10]. <http://www.citygml.org>
95
KOLBE, T. H. 2008. Representing and Exchanging 3D City Models with CityGML. [online] 2008 [cit.
2012-9-22]. <http://www.citygml.org/fileadmin/citygml/docs/CityGML_Paper_Kolbe_2008.
pdf>
KUBÍČEK, P. 2010. Prostorová informační infrastruktura a zdravotní data. [online; učební text MU
Brno]. 2010 [cit. 2012-15-10]. <https://is.muni.cz/www/64052/Prostorova_infrastruktura.pdf>
MfDoDS. 2008. Drafting Team "Data Specifications" – deliverable D2.6: Methodology for the development
of data specifications [online]. 2008 [cit. 2012-11-10]. <http://inspire.jrc.ec.europa.eu/reports/
ImplementingRules/DataSpecifications/D2.6_v3.0.pdf>
NAGEL, C. – BENNER, J. – HAEFELE, K. H. 2012. CityGML – City Geography Markup Language
[online]. 2012 [cit. 2012-20-10]. <http://www.citygmlwiki.org/>
NEMOFORUM. 2000. Národní geoinformační infrastruktura v ČR – program rozvoje v letech 20012005 [online]. 2000 [cit. 2012-10-14]. 8 s. <http:// www.cuzk.cz/nemoforum>
OGC. 2002a. Styled Layer Descriptor Implementation Specification. Version 1.0.0. [online]. 2002
[cit. 2012-10-14]. 107 s. <http://portal.opengeospatial.org/files/?artifact_id=1188>
OGC. 2002b. Web Map Service Implementation Specification. Version 1.1.1 [online]. 2002 [cit. 2012-1014]. 70 s. <http://portal.opengeospatial.org/files/?artifact_id=1081&version=1&format=pdf>
OGC. 2006. Symbology Encoding Implementation Specification. Version 1.1.0 [online]. 2006 [cit. 201210-14]. 55 s. <http://portal.opengeospatial.org/files/?artifact_id=16700>
OGC. 2007a. Catalogue Services Specification. Open Geospatial Consortium. Version 2.0.2 [online]. 2007
[cit. 2012-10-14]. <http://portal.opengeospatial.org/files/?artifact_id=20555>
OGC. 2007b. Geography Markup Language (GML) Encoding Standard. Version 3.2.1 [online]. 2007
[cit. 2012-11-14]. 427 s. <http://portal.opengeospatial.org/files/?artifact_id=20509>
OGC. 2007c. KML. Version 2.2.0 [online]. 2007 [cit. 2012-10-14]. 233 s. <http://portal.opengeospatial.org/files/?artifact_id=27810>
OGC. 2007d. Observations and Measurements – Part 1 - Observation schema. Version 2.0 [online]. 2007.
[cit. 2012-10-14]. <http://portal.opengeospatial.org/files/?artifact_id=41510>
OGC. 2007e. Sensor Observation Service. Version 1.0 [online]. 2007 [cit. 2012-9-14]. 109 s. <http://
portal.opengeospatial.org/files/?artifact_id=20994>
OGC. 2007f. Styled Layer Descriptor profile of the Web Map Service Implementation Specification. Version
1.1.0 [online]. 2007 [cit. 2012-10-14]. 45 s. <http://portal.opengeospatial.org/files/?artifact_
id=22364>
OGC. 2008. OpenGIS City Geography Markup Language (CityGML) Encoding Standard. Version
1.0.0 [online]. 2008 [cit. 2012-9-16]. 234 s. <http://portal.opengeospatial.org/files/?artifact_
id=28802>.
OGC. 2009. Uncertainty Markup Language (UnCertML). Version 0.6 [online]. 2009 [cit. 2012-10-16].
61 s. <http://portal.opengeospatial.org/files/?artifact_id=33234ciS6wpU1_PPNQ>
OGC. 2010a. Draft for Candidate OpenGIS Web 3D Service Interface Standard. Version 0.4.0 [online].
2010 [cit. 2012-9-18]. 95 s. <http://portal.opengeospatial.org/files?artifact_id=36390>
OGC. 2010b. Web View Service Discussion Paper. Version 0.3.0 [online]. 2010 [cit. 2012-9-22]. 138 s.
<http://portal.opengeospatial.org/files?artifact_id=37257>.
OGC. 2011. Observations and Measurements - XML Implementation. Version 1.0 [online]. 2011 [cit.
2012-9-22]. 72 s. <http://portal.opengeospatial.org/files/?artifact_id=22466>
OGC. 2012a. OGC 3D Portrayal Interoperability Experiment. Final Report. 2012 [cit. 2012-9-21]. 76 s.
<http://www.opengis.net/doc/ie/3dpie>
OGC. 2012b. OpenGIS City Geography Markup Language (CityGML) Encoding Standard. Version
2.0.0 [online]. 2012 [cit. 2012-9-20]. 346 s. <https://portal.opengeospatial.org/files/?artifact_
id=47842>
96
ONSURD, H. J. 1998. A global survey of national spatial data infrastructure activities. [online]. 1998 [cit.
2012-15-10]. <http://www.spatial.maine.edu/~onsurd/gsdi/surveysum.htm>
ORCHESTRA. 2012. Orchestra [online]. 2012 [cit. 2012-10-9]. <http://www.eu-orchestra.org>
SCHULTE, C. – COORS, V. 2009. Development of a CityGML ADE for dynamic 3D flood information
[online]. 2009 [cit. 2012-9-22]. <http://www.appliedgeoinformatics.org/index.php/agse/conference2009/paper/viewFile/6/26>.
SUDPLAN. 2012. SUDPLAN 3-D Project – Augmented Vision [online]. 2012 [cit. 2012-11-9].
<http://sudplan.kl.dfki.de/index.html>
TATOO, 2012. TaToo – FP7 Project [online]. 2012 [cit. 2012-9-9]. <http://www.tatoo-fp7.eu/tatooweb/>
TG. 2010a. Technical Guidance for the INSPIRE Schema Transformation Network Service. [online]. 2010
[cit. 2012-10-22]. 92 s. <http://inspire.jrc.ec.europa.eu/documents/Network_Services/JRC_INSPIRE-TransformService_TG_v3-0.pdf>.
TG. 2010b. Draft Technical Guidance for INSPIRE Coordinate Transformation Services. [online]. 2010
[cit. 2012-10-22]. 18 s. <http://inspire.jrc.ec.europa.eu/documents/Network_Services/INSPIRE_Draft_Technical_Guidance_Coordinate_Transformation_Services_(version_2%201).pdf>.
TG. 2011a. Technical Guidance for the implementation of INSPIRE Discovery Services [online]. 2011
[cit. 2012-9-22]. 49 s. <http://inspire.jrc.ec.europa.eu/documents/Network_Services/TechnicalGuidance_DiscoveryServices_v3.1.pdf>.
TG. 2011b. Technical Guidance for the implementation of INSPIRE View Services. [online]. 2011 [cit.
2012-9-22]. 114 s. <http://inspire.jrc.ec.europa.eu/documents/Network_Services/TechnicalGuidance_ViewServices_v3.1.pdf>.
TG. 2012 Technical Guidance for the implementation of INSPIRE Download Services [online]. 2012 [cit.
2012-9-22]. 82 s. <http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_3.0.pdf>.
VYHLÁŠKA č. 103/2010. VYHLÁŠKA ze dne 30. března 2010 o provedení některých ustanovení zákona o právu na informace o životním prostředí[online]. 2010 [cit. 2012-9-22]. <http://inspire.gov.
cz/sites/default/files/documents/103_2010.pdf>.
W3C. 2006. Scalable Vector Graphics (SVG) 1.0 Specification [online]. 2006 [cit. 2012-10-14]. <http://
www.w3.org/TR/2006/REC-xml11-20060816/>
WP. 2004. INSPIRE - work programme Preparatory Phase 2005 - 2006. [online]. 2004 [cit. 2012-1022]. 78 s. <http://www.ec-gis.org/docs/F8323/RHD040705WP4A_V4.5.3_FINAL-2.PDF>.
WP. 2007. INSPIRE Work Programme Transposition Phase 2007-2009. [online]. 2007 [cit. 2012-1022]. 45 s. <http://inspire.jrc.ec.europa.eu/reports/transposition/INSPIRE_IR_WP2007_2009_
en.pdf>.
YICK, J. – MUKHERJEE, B. – GHOSAL, D. 2008. Wireless sensor network survey. Computer Networks [online]. 2008, Vol. 52, Is. 12, s. 2292-2330 [cit. 2012-10-15]. ISSN 13891286. <http://
linkinghub.elsevier.com/retrieve/pii/S1389128608001254>
ZÁKON Č. 380/2009. ZÁKON č. 380/2009 ze dne 8. října 2009, kterým se mění zákon č. 123/1998
Sb., o právu na informace o životním prostředí, ve znění pozdějších předpisů, a zákon č. 200/1994
Sb., o zeměměřictví a o změně a doplnění některých zákonů souvisejících s jeho zavedením, ve znění
pozdějších předpisů [online]. 2009 [cit. 2012-11-10]. <http://inspire.gov.cz/sites/default/files/
documents/380_2009.pdf>
ZANDL, P. 2009. Internet věcí - Internet of Things. Lupa.cz [online]. 2009 [cit. 2012-10-15]. <http://
www.lupa.cz/clanky/internet-veci-internet-of-things/>
97
Datové infrastruktury pro prostorově informační společnost
Editoři: Milan Konečný, Petr Kubíček
Technická redakce: Lukáš Herman, Eva Mulíčková
Návrh a grafická úprava obálky: Jolana Folwarczná
Vydala: Masarykova univerzita v roce 2012
Vytiskla: Tiskárna DIDOT, s.r.o., Trnkova 119, Brno-Líšeň
1. vydání
200 výtisků
ISBN 978-80-210-6014-2

Datové infrastruktury pro prostorově informační společnost

Transkript

Podobné dokumenty

23456789 6

ArcGIS pro INSPIRE

Priorita 02/2013

1. ročník - Digitální technologie v geoinformatice, kartografii a

Téma prostorových dat Budovy

Sborník abstraktů - Západočeská univerzita

Standardy OGC mapových služeb - GISSERVER

roční zpráva 2014 - CENIA, česká informační agentura životního

Panel - GI (pan european link for geographical information)

GAKO 5/2015 - Asociace poskytovatelů služeb pro pozemkové úpravy

Český zahrádkářský svaz, (267 12 Loděnice 172

NÁVRH Strategie rozvoje infrastruktury pro prostorové informace v

Environmentální informační systémy

Metody studia globální změny Garant: Mgr. David Vačkář, Ph.D

diplomová práce - Západočeská univerzita

Smart Open Data

Mezinárodní spolupráce