habitats d4.3.2 networking services and service toolkit final

European Commission

Information Society and Media

This project is partially funded under the ICT Policy Support Programme as part of the Competitiveness and

Innovation Framework Programme by the European Commission http://ec.europa.eu/ict_psp

This document reflects only the author's views and the European Community is not liable for any use that might

be made of the information contained herein. © HABITATS Consortium, 2012

DELIVERABLE

Project Acronym: HABITATS

Grant Agreement number: 3-250455

Project Title: Social Validation of INSPIRE Annex III Data Structures in EU HABITATS

D4.3.2 HABITATS networking services and

service toolkit

Document identifier: D4.3.2

Date: 07 March 2013

Nature: P

Dissemination level: Pu

WP Lead Partner: HSRS

Revision V1

Project co-funded by the European Commission within the ICT Policy Support Programme Dissemination Level

PU Public X

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

European Commission

Information Society and Media

This project is partially funded under the ICT Policy Support Programme as part of the Competitiveness and

Innovation Framework Programme by the European Commission http://ec.europa.eu/ict_psp

This document reflects only the author's views and the European Community is not liable for any use that might

be made of the information contained herein. © HABITATS Consortium, 2012

Abstract: This deliverable presents the final status of the HABITATS Networking Services

and service toolkits. Networking services are series of specific networking service applets

deployed and tested for data sharing within the project. This deliverable also presents the

background of invoking services and their relevance to the HABITATS project and examines

the basic networking architecture and specific tools that are considered. The focus of this

final report is not only on the application of these aspects within the Reference Laboratory

but also includes the invoking of services at the level of the different pilots. The rich

prototype set as implemented on the HABITATS Reference Laboratory geoportal platform

and its relationship to the pilot architecture are also described.

Key Words: HABITATS, networking services, service toolkits, invoking prototype applet,

data sharing, Reference Laboratory, social media, social networking

Authors: Karel Charvat (HSRS) Jachym Cepicky (HSRS) Premysl Vohnout (HSRS) Stepan Kafka (HSRS) Michal Sredl (HSRS) Tomas Mildorf (HSRS) John J O’Flaherty (MAC) Joe Cantwell (MAC) Raitis Berzins (IMCS) Peteris Bruns (IMCS) G. .Osorio (Tragsa) Jan Bojko (FMI) A. Sciana (Madonia)

Statement of originality:

This deliverable contains original unpublished work except where clearly

indicated otherwise. Acknowledgement of previously published material and

of the work of others has been made through appropriate citation, quotation

or both.

Revision History

Revision Date Author Organization Description

V1.0 08/10/2012 K. Charvat HSRS First draft

V0.3 06/01/2013 K. Charvat HSRS Integration of contributions

V0.2 07/01/2013 J. O`Flaherty MAC Update of document

V0.1 01/03/2013 G. .Osorio Tragsa Update of document

V2 03/03/2012 K.Charvat HSRS Finalisation of document

Document Change Record

Issue Date Author Item Reason for Change

Project Officer: Krister Olson

Address:

European Commission

DG Information Society and Media

Project Officer

DG INFSO – E06

Office: EUFO – 01/177

L – 2920 LUXEMBOURG

Phone: +(352) 43 0134332

Fax: +(352)

E-mail: [email protected]

Project Manager: Mariano Navarro de la Cruz

Address: C/ Julian Camarillo, 6b, 28037, Madrid, Spain

Phone: +34 91 322 65 21

Fax: +34 91 322 63 23

E-mail: [email protected]

Date: 7-Mar-13 HABITATS Networking Services and Service Toolkits

Doc. Identifier: D4.3.2

Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

07 March 2013 1 of 44

TABLE OF CONTENTS

1 FIGURES ........................................................................................................................ 7

2 TABLES ........................................................................................................................ 10

3 INTRODUCTION .......................................................................................................... 11

Terms ................................................................................................................................ 11

Abbreviations .................................................................................................................... 12

4 INSPIRE, NETWORKING ARCHITECTURE AND HABITATS....................................... 14

5 INVOKING SERVICES ................................................................................................. 15

INVOKING service requirements and recommendations ................................................... 16

6 PROBLEMS OF POLICY DRIVEN SDI ......................................................................... 18

Neogeography .................................................................................................................. 19

7 HABITATS NETWORKING SERVICES ........................................................................ 20

Reference Lab .................................................................................................................. 20

Uniform Resource Management (URM) Concept .............................................................. 23

Use of the URM in the HABITATS RL ........................................................................... 26

8 RL NETWORKING SERVICES AND INVOKING TOOLS .............................................. 28

Authorization and Authentication tools .............................................................................. 30

Liferay based geoportal solution ....................................................................................... 31

Customisation of the portal content .................................................................................. 33

WordPress based GeoSocial Network .............................................................................. 36

Uniform Resource Management (URM) ............................................................................ 39

MICKA ............................................................................................................................. 39

Geoserver .......................................................................................................................... 43

Data management ......................................................................................................... 43

Data visualisation ......................................................................................................... 44

Map compositions ........................................................................................................ 45

Data publication ........................................................................................................... 45

Styler............................................................................................................................. 46

Vector data editing ........................................................................................................ 47

Layer hierarchy and thematic maps .............................................................................. 49

Metadata Extractor ........................................................................................................... 51

Networking Services and Invoking .................................................................................... 52

Catalogue Services ........................................................................................................... 52

Invoking of discovery services ..................................................................................... 55

Experiences with sharing of metadata in INSPIRE and GEOSS and Super Catalogue

implementation ............................................................................................................. 56 Catalogues interoperabity problems ................................................................................................................. 56 Central catalogue implementation .................................................................................................................... 57 Testing Results ................................................................................................................................................. 61 Practical Results ............................................................................................................................................... 61 Plans for future ................................................................................................................................................. 63

View Services ................................................................................................................... 63

Map ............................................................................................................................... 65

Layer Switcher ............................................................................................................. 66 Logical structure ............................................................................................................................................... 67




07 March 2013 2 of 44

OWS ............................................................................................................................. 67

Printing with HSLayers ................................................................................................ 68

Web Map Context ........................................................................................................ 70

Permanent link .............................................................................................................. 73

Embedded ..................................................................................................................... 73

Querying displayed layers ............................................................................................ 74

User graphics and measuring ....................................................................................... 75

OGC Web Processing Service client ............................................................................ 76

Server-side scripts ........................................................................................................ 77 HSProxy ........................................................................................................................................................... 78

StatusManager server script ......................................................................................... 78 Proxy4OWS ..................................................................................................................................................... 78

Invoking with HSlayers ................................................................................................ 79 Invoking of view (WMS) services.................................................................................................................... 79 WMS coordinate transformation ...................................................................................................................... 80 Invoking of Map Compositions – Web Map Context ....................................................................................... 82 Invoking of WFS and WCS .............................................................................................................................. 83

Invocation ..................................................................................................................... 86 Filter Encoding Filtering WFS Layers ............................................................................................................. 86

FE Examples: ............................................................................................................... 86 Filter Encoding and WFS ................................................................................................................................. 87 WPS invoking .................................................................................................................................................. 92 HSLayers SOS client ........................................................................................................................................ 94 HSLayers Embed component ........................................................................................................................... 95

Mobile solutions for RL ................................................................................................... 97

Using KML as common format .................................................................................. 101

Field editing ................................................................................................................ 102

9 PROCESSING WORKFLOW MANAGEMENT ........................................................... 104

Orchestration environment .............................................................................................. 104

Workflow Management System ....................................................................................... 104

Business Process Execution Language .......................................................................... 104

Engines and work-flow managers .................................................................................. 105

Apache ODE ............................................................................................................... 105

Orchestra .................................................................................................................... 105

Taverna Server ............................................................................................................ 106

Workflow designers .................................................................................................... 107

52°North WPS Workflow Modeller and Orchestration API ...................................... 107

ECLIPSE BPEL ......................................................................................................... 108

HUMBOLDT Workflow Design and Construction Service ....................................... 110

Taverna Workbench .....................................................................................................111

10 HABITATS PILOTS’ NETWORK SERVICES ............................................................... 113

PILOTS DESCRIPTIONS ............................................................................................... 115

Wild Salmon Monitoring ................................................................................................ 115

La Palma Protected Marine Reserve .............................................................................. 119

MadoniE Hiking Trip Planner ........................................................................................ 122

Madonia Sheep and Goat Herding Management ........................................................... 123

Augmented Reality Natural Reserve .............................................................................. 125

Economical activity at marine coastal benthic habitats .................................................. 130

National Forest Programme ............................................................................................ 133

11 INTEROPERABILITY AND INVOCATION TESTS ...................................................... 136




07 March 2013 3 of 44

Interoperability and Enabling Services ............................................................................ 136

3.2 HABITATS “Quick Prototyping” Service Applets .................................................... 137

The interoperability tests IMCS RL .................................................................................. 138

IRISH test with RL ......................................................................................................... 138

La Palma Reserve Marine Pilot test with RL ................................................................. 139

Augmented Reality Nature Reserve Pilot test with RL .................................................. 140

FMI Liberec region test of Reference Laboratory ......................................................... 141

Experimentation with Open Linked Data ....................................................................... 143

12 CONCLUSIONS AND RECOMMENDATIONS ............................................................ 145

13 REFERENCES ........................................................................................................... 147

Figure 1 INSPIRE Networking Architecture ............................................................................ 16

Figure 2 Reverse “pyramid” effect (Bregt 2012). .................................................................... 18

Figure 3 Spider Web Paradigm ................................................................................................. 19

Figure 4 The changing sources of spatial data (Harris & Lafone). .......................................... 19

Figure 5 Habitats Networking Architecture ............................................................................. 21

Figure 6 Habitats RL and pilots ................................................................................................ 21

Figure 7 Habitats RL ................................................................................................................ 22

Figure 8 URM concept ............................................................................................................. 24

Figure 9 URM principles .......................................................................................................... 25

Figure 10 URM Spidernet ........................................................................................................ 26

Figure 11 Portal login ............................................................................................................... 30

Figure 12 Portal registration ..................................................................................................... 31

Figure 13 Liferay Interface ....................................................................................................... 32

Figure 14 Customisation of RL I .............................................................................................. 33

Figure 15 Customisation of RL II ............................................................................................ 34

Figure 16 Customisation of RL III ........................................................................................... 35

Figure 17 Customisation of RL IV ........................................................................................... 36

Figure 18 WordPress Based RL................................................................................................ 37

Figure 19 WordPress Article Editing ........................................................................................ 38

Figure 20 Micka Metadata Editing ........................................................................................... 40

Figure 21 Micka Metadata Validation ...................................................................................... 40

Figure 22 Micka Metadata importing ....................................................................................... 41

Figure 23 Micka Metadata importing XML ............................................................................. 41

Figure 24 Micka metadata importing WMC ............................................................................ 42

Figure 25 Editing of Imported metadata .................................................................................. 42

Figure 26 Validation result ....................................................................................................... 43

Figure 27 Metadata records management ................................................................................ 43

Figure 28 Slyling ...................................................................................................................... 47

Figure 29 Editing of vector data ............................................................................................... 48

Figure 30 Data flow between HS Layers and Geoserver. ........................................................ 49

Figure 31 User (or administrator) can create thematic maps (map compositions) using

standard OGC OWS client, part of the mapping application. .................................................. 50

Figure 32 Ordering layers into groups, without touching the physical structure of displayed

maps. ......................................................................................................................................... 50

Figure 33 Changing the physical structure of displayed layers. In the "Physical view" tab,

layers cannot be structured into groups, but their position in the layer tree (using drag&drop)

can be changed. ........................................................................................................................ 51

Figure 34 Metadata extractor ................................................................................................... 52




07 March 2013 4 of 44

Figure 35 Catalogue Search ..................................................................................................... 53

Figure 36 Advanced search ...................................................................................................... 53

Figure 37 Metadata Detail ........................................................................................................ 54

Figure 38 Metadata Spatial Exten ............................................................................................ 54

Figure 39 Catalogue Client architecture ................................................................................... 55

Figure 40 Catalogue Import ..................................................................................................... 56

Figure 41 Catalogue import ...................................................................................................... 56

Figure 42 SuperCat harvesting ................................................................................................. 58

Figure 43 Micka harvesting configuration ............................................................................... 59

Figure 44 RSS channel – harvesting results ............................................................................. 60

Figure 45 Heartbeat protocol .................................................................................................... 60

Figure 46 Portal – metadata catalogue client ........................................................................... 62

Figure 47 Mobile catalogue client ............................................................................................ 62

Figure 48 Mobile catalogue client connected to central catalogue and map viewer showing

found WMS .............................................................................................................................. 63

Figure 49 Illustration of relation between ExtJS and OpenLayers libraries inside of HSLayers.

.................................................................................................................................................. 63

Figure 50 HSlayers Map Portal ................................................................................................ 64

Figure 51 Map Window ............................................................................................................ 65

Figure 52 Physical and Logical Structure ................................................................................ 66

Figure 53 HSLayers.OWS - Open Web Services client ........................................................... 68

Figure 54 Printing with HSLayers ............................................................................................ 69

Figure 55 Printing Result ......................................................................................................... 70

Figure 56 Web Map Content Editing ........................................................................................ 72

Figure 57 Permanent Link ........................................................................................................ 73

Figure 58 Embedded ............................................................................................................... 74

Figure 59 Result of the point query on one vector layer. ......................................................... 75

Figure 60 User graphic ............................................................................................................. 75

Figure 61 OGC WPS client ...................................................................................................... 76

Figure 62 Image classifcation ................................................................................................... 77

Figure 63 Buffering .................................................................................................................. 77

Figure 64 Sequence diagram of proxy4ows shows the negotiation between the client,

proxy4ows middleware and the target server. .......................................................................... 79

Figure 65 Invoking from catalogue .......................................................................................... 79

Figure 66 WMS invoking ......................................................................................................... 80

Figure 67 WMS Sequence diagram. ......................................................................................... 81

Figure 68 WMS transformation result - left map coordinate system, right - transformed result

from EPSG:4326 source. .......................................................................................................... 81

Figure 69 Composition Saving ................................................................................................. 82

Figure 70 Open Composition from local disk .......................................................................... 83

Figure 71 WFS invoking scheme ............................................................................................. 84

Figure 72 Get Map Scheme ...................................................................................................... 85

Figure 73 OWS Dispatch ......................................................................................................... 86

Figure 74 Geoportal, Filter Encoding ....................................................................................... 90

Figure 75 Filter Encoding ......................................................................................................... 91

Figure 76 Filtering of WFS ...................................................................................................... 91

Figure 77 WPS Invoking .......................................................................................................... 92

Figure 78 Proxy ........................................................................................................................ 93

Figure 79 HSLayers SOS client ............................................................................................... 95




07 March 2013 5 of 44

Figure 80 HSLayers Embeded ................................................................................................. 96

Figure 81 Rendering Map ......................................................................................................... 97

Figure 82 Locus map app, Catalogue client ............................................................................. 99

Figure 83 WMS displayed in Locus app, map legend............................................................ 100

Figure 84 Parcel Info app ....................................................................................................... 100

Figure 85 KML metadata in the catalogue client ................................................................... 101

Figure 86 Displaying KML in Google Maps and Locus ........................................................ 102

Figure 87 Simple mobile editing application ......................................................................... 103

Figure 88 Filed editing results displayed online in Google Earth as KML ............................ 103

Figure 89 Apache ODE .......................................................................................................... 105

Figure 90 Orchestra ................................................................................................................ 106

Figure 91 Taverna ................................................................................................................... 107

Figure 92 Workflow modeller ................................................................................................ 108

Figure 93 Eclipse BPEL ......................................................................................................... 109

Figure 94 Humboldt Workflow Design ...................................................................................111

Figure 95 Taverna Workbench................................................................................................ 112

Figure 96 Aquatic Invasive Species ....................................................................................... 116

Figure 97 Aquatic Invasive Species App ............................................................................... 116

Figure 98 AIS classification ................................................................................................... 117

Figure 99 Integration with RL ................................................................................................ 117

Figure 100 AIS sighting ......................................................................................................... 118

Figure 101 Ireland Pilot architecture ...................................................................................... 118

Figure 102 Publishing ............................................................................................................ 119

Figure 103 Sea Monitoring ..................................................................................................... 120

Figure 104 La Palma Pilot Scheme ........................................................................................ 120

Figure 105 La Palma portal .................................................................................................... 121

Figure 106 La Palma metadata ............................................................................................... 122

Figure 107 Madonia Architecture ........................................................................................... 123

Figure 108 Madonia implementation ..................................................................................... 124

Figure 109 Augment Reality Technology ............................................................................... 125

Figure 110 Android App ......................................................................................................... 126

Figure 111 Augment Reality Scheme ..................................................................................... 126

Figure 112 Augment Reality Implementation ........................................................................ 127

Figure 113 Pilot portal ............................................................................................................ 128

Figure 114 Pilot Metadata ...................................................................................................... 128

Figure 115 Coastal HABITATS pilot is design ...................................................................... 130

Figure 116 Latvian Pilot Implementation ............................................................................... 131

Figure 117 Latvian portal ....................................................................................................... 132

Figure 118 Processing services .............................................................................................. 132

Figure 119 FMI pilot scheme ................................................................................................. 134

Figure 120 OPRL Data ........................................................................................................... 135

Figure 121 Harmonised data publishing on RL ..................................................................... 138

Figure 122 Invasive species on RL ........................................................................................ 139


Figure 124 The screen capture shows the data as it appears on the HABITATS RL Geoportal:

http://www.habitats.cz/view?permalink=44b2ad495fd262b365f8fdb5310a1458 ................. 140


http://www.habitats.cz/view?permalink=8555142bd2d6f5462d4f766015bc4776 ................ 141

Figure 126 Liberec Basic portal functionality ........................................................................ 142




07 March 2013 6 of 44

Figure 127 Liberec Thematic Maps using standardised data from FMI ................................ 142

Figure 128 Flood portal as part of Geoportal ......................................................................... 143

Figure 129 Education and awareness ..................................................................................... 143

Figure 130 Integration of Open Linked data from skiing resorts ........................................... 144

1




07 March 2013 7 of 44

Figures

Figure 1 INSPIRE Networking Architecture ............................................................................ 16

Figure 2 Reverse “pyramid” effect (Bregt 2012). .................................................................... 18

Figure 3 Spider Web Paradigm ................................................................................................. 19

Figure 4 The changing sources of spatial data (Harris & Lafone). .......................................... 19

Figure 5 Habitats Networking Architecture ............................................................................. 21

Figure 6 Habitats RL and pilots ................................................................................................ 21

Figure 7 Habitats RL ................................................................................................................ 22

Figure 8 URM concept ............................................................................................................. 24

Figure 9 URM principles .......................................................................................................... 25

Figure 10 URM Spidernet ........................................................................................................ 26

Figure 11 Portal login ............................................................................................................... 30

Figure 12 Portal registration ..................................................................................................... 31

Figure 13 Liferay Interface ....................................................................................................... 32

Figure 14 Customisation of RL I .............................................................................................. 33

Figure 15 Customisation of RL II ............................................................................................ 34

Figure 16 Customisation of RL III ........................................................................................... 35

Figure 17 Customisation of RL IV ........................................................................................... 36

Figure 18 WordPress Based RL................................................................................................ 37

Figure 19 WordPress Article Editing ........................................................................................ 38

Figure 20 Micka Metadata Editing ........................................................................................... 40

Figure 21 Micka Metadata Validation ...................................................................................... 40

Figure 22 Micka Metadata importing ....................................................................................... 41

Figure 23 Micka Metadata importing XML ............................................................................. 41

Figure 24 Micka metadata importing WMC ............................................................................ 42

Figure 25 Editing of Imported metadata .................................................................................. 42

Figure 26 Validation result ....................................................................................................... 43

Figure 27 Metadata records management ................................................................................ 43

Figure 28 Slyling ...................................................................................................................... 47

Figure 29 Editing of vector data ............................................................................................... 48

Figure 30 Data flow between HS Layers and Geoserver. ........................................................ 49

Figure 31 User (or administrator) can create thematic maps (map compositions) using

standard OGC OWS client, part of the mapping application. .................................................. 50

Figure 32 Ordering layers into groups, without touching the physical structure of displayed

maps. ......................................................................................................................................... 50

Figure 33 Changing the physical structure of displayed layers. In the "Physical view" tab,

layers cannot be structured into groups, but their position in the layer tree (using drag&drop)

can be changed. ........................................................................................................................ 51

Figure 34 Metadata extractor ................................................................................................... 52

Figure 35 Catalogue Search ..................................................................................................... 53

Figure 36 Advanced search ...................................................................................................... 53

Figure 37 Metadata Detail ........................................................................................................ 54

Figure 38 Metadata Spatial Exten ............................................................................................ 54

Figure 39 Catalogue Client architecture ................................................................................... 55

Figure 40 Catalogue Import ..................................................................................................... 56

Figure 41 Catalogue import ...................................................................................................... 56

Figure 42 SuperCat harvesting ................................................................................................. 58




07 March 2013 8 of 44

Figure 43 Micka harvesting configuration ............................................................................... 59

Figure 44 RSS channel – harvesting results ............................................................................. 60

Figure 45 Heartbeat protocol .................................................................................................... 60

Figure 46 Portal – metadata catalogue client ........................................................................... 62

Figure 47 Mobile catalogue client ............................................................................................ 62

Figure 48 Mobile catalogue client connected to central catalogue and map viewer showing

found WMS .............................................................................................................................. 63


.................................................................................................................................................. 63

Figure 50 HSlayers Map Portal ................................................................................................ 64

Figure 51 Map Window ............................................................................................................ 65

Figure 52 Physical and Logical Structure ................................................................................ 66

Figure 53 HSLayers.OWS - Open Web Services client ........................................................... 68

Figure 54 Printing with HSLayers ............................................................................................ 69

Figure 55 Printing Result ......................................................................................................... 70

Figure 56 Web Map Content Editing ........................................................................................ 72

Figure 57 Permanent Link ........................................................................................................ 73

Figure 58 Embedded ............................................................................................................... 74

Figure 59 Result of the point query on one vector layer. ......................................................... 75

Figure 60 User graphic ............................................................................................................. 75

Figure 61 OGC WPS client ...................................................................................................... 76

Figure 62 Image classifcation ................................................................................................... 77

Figure 63 Buffering .................................................................................................................. 77

Figure 64 Sequence diagram of proxy4ows shows the negotiation between the client,

proxy4ows middleware and the target server. .......................................................................... 79

Figure 65 Invoking from catalogue .......................................................................................... 79

Figure 66 WMS invoking ......................................................................................................... 80

Figure 67 WMS Sequence diagram. ......................................................................................... 81


from EPSG:4326 source. .......................................................................................................... 81

Figure 69 Composition Saving ................................................................................................. 82

Figure 70 Open Composition from local disk .......................................................................... 83

Figure 71 WFS invoking scheme ............................................................................................. 84

Figure 72 Get Map Scheme ...................................................................................................... 85

Figure 73 OWS Dispatch ......................................................................................................... 86

Figure 74 Geoportal, Filter Encoding ....................................................................................... 90

Figure 75 Filter Encoding ......................................................................................................... 91

Figure 76 Filtering of WFS ...................................................................................................... 91

Figure 77 WPS Invoking .......................................................................................................... 92

Figure 78 Proxy ........................................................................................................................ 93

Figure 79 HSLayers SOS client ............................................................................................... 95

Figure 80 HSLayers Embeded ................................................................................................. 96

Figure 81 Rendering Map ......................................................................................................... 97

Figure 82 Locus map app, Catalogue client ............................................................................. 99

Figure 83 WMS displayed in Locus app, map legend............................................................ 100

Figure 84 Parcel Info app ....................................................................................................... 100

Figure 85 KML metadata in the catalogue client ................................................................... 101

Figure 86 Displaying KML in Google Maps and Locus ........................................................ 102

Figure 87 Simple mobile editing application ......................................................................... 103




07 March 2013 9 of 44

Figure 88 Filed editing results displayed online in Google Earth as KML ............................ 103

Figure 89 Apache ODE .......................................................................................................... 105

Figure 90 Orchestra ................................................................................................................ 106

Figure 91 Taverna ................................................................................................................... 107

Figure 92 Workflow modeller ................................................................................................ 108

Figure 93 Eclipse BPEL ......................................................................................................... 109

Figure 94 Humboldt Workflow Design ...................................................................................111

Figure 95 Taverna Workbench................................................................................................ 112

Figure 96 Aquatic Invasive Species ....................................................................................... 116

Figure 97 Aquatic Invasive Species App ............................................................................... 116

Figure 98 AIS classification ................................................................................................... 117

Figure 99 Integration with RL ................................................................................................ 117

Figure 100 AIS sighting ......................................................................................................... 118

Figure 101 Ireland Pilot architecture ...................................................................................... 118

Figure 102 Publishing ............................................................................................................ 119

Figure 103 Sea Monitoring ..................................................................................................... 120

Figure 104 La Palma Pilot Scheme ........................................................................................ 120

Figure 105 La Palma portal .................................................................................................... 121

Figure 106 La Palma metadata ............................................................................................... 122

Figure 107 Madonia Architecture ........................................................................................... 123

Figure 108 Madonia implementation ..................................................................................... 124

Figure 109 Augment Reality Technology ............................................................................... 125

Figure 110 Android App ......................................................................................................... 126

Figure 111 Augment Reality Scheme ..................................................................................... 126

Figure 112 Augment Reality Implementation ........................................................................ 127

Figure 113 Pilot portal ............................................................................................................ 128

Figure 114 Pilot Metadata ...................................................................................................... 128

Figure 115 Coastal HABITATS pilot is design ...................................................................... 130

Figure 116 Latvian Pilot Implementation ............................................................................... 131

Figure 117 Latvian portal ....................................................................................................... 132

Figure 118 Processing services .............................................................................................. 132

Figure 119 FMI pilot scheme ................................................................................................. 134

Figure 120 OPRL Data ........................................................................................................... 135

Figure 121 Harmonised data publishing on RL ..................................................................... 138




http://www.habitats.cz/view?permalink=44b2ad495fd262b365f8fdb5310a1458 ................. 140


http://www.habitats.cz/view?permalink=8555142bd2d6f5462d4f766015bc4776 ................ 141

Figure 126 Liberec Basic portal functionality ........................................................................ 142

Figure 127 Liberec Thematic Maps using standardised data from FMI ................................ 142

Figure 128 Flood portal as part of Geoportal ......................................................................... 143

Figure 129 Education and awareness ..................................................................................... 143

Figure 130 Integration of Open Linked data from skiing resorts ........................................... 144

2




07 March 2013 10 of 44

Tables

Table 1 Testing WMS services results ...................................................................................... 61

Table 2 Comparison of INSPIRE solutions and current mobile solutions ............................... 98

3




07 March 2013 11 of 44

Introduction

The INSPIRE Directive considers that spatial information is needed for the implementation of

Community policies which must integrate environmental protection in accordance with

Article 6 of the Treaty, and establishes the basis for an infrastructure for spatial information

in Europe in order to support EU environmental policies and those activities which may have

an impact on the environment. It defines 34 spatial data themes related to environmental

applications and requires, in order to ensure that infrastructures of the Member States are

compatible and usable in a trans-boundary context, that common Implementing Rules are

adopted for all Member States, in specific areas: Metadata, Data Specifications, Network

Services, Data and Service Sharing and Monitoring and Reporting.

The HABITATS project (Social Validation of INSPIRE Annex III Data Structures in EU

HABITATS) focuses on the adoption of INSPIRE standards through a participatory process to

design and validate data, metadata and services specifications with real citizens and

businesses.

This deliverable presents the current status, the ongoing work, and the plans for the

HABITATS Networking Services, which are series of specific networking service applets

deployed and tested for data sharing within the project. The HABITATS networking services

will be ultimately deployed at two levels:

• On the HABITATS Reference Laboratory as a central portal with the support of global

data, but also supporting cross scenarios implementations;

• HABITATS pilot applications, as implementations of single HABITATS pilot cases,

which will also be used for testing the sharing of local data and metadata.

The prototype set of services as implemented on the HABITATS Reference Laboratory

geoportal platform are described in the context of future pilot implementations.

These follow from the HABITATS generic networking and data sharing architecture1, and its

possible logical components, based on user needs that were found in the pilots2 and will be

validated by users on the basis of concrete implementations in second phase of the project3.

Terms

• discovery services – search for spatial data sets and services on the basis of the content of

the corresponding metadata and to display the content of the metadata

[INSPIRE Directive]

• download services – services to copy of spatial data sets, or parts of such sets, to be

downloaded and, where practicable, accessed directly [INSPIRE Directive]

• feature – abstraction of real world phenomena [ISO 19101]

• feature catalogue – catalogue(s) containing definitions and descriptions of the spatial

object types, their attributes and associated components occurring in one or

more spatial data sets, together with any operations that may be applied [ISO

19110 – modified]

• infrastructure for spatial information – metadata, spatial data sets and spatial data services;

1 Developed in D4.2.1 and D4.2.2

2 As reported in D5.2.1.

3 To be reported in D2.4.3 and D5.4.2




07 March 2013 12 of 44

network services and technologies; agreements on sharing, access and use; and

coordination and monitoring mechanisms, processes and procedures,

established, operated or made available in accordance with this Directive;

[INSPIRE Directive]

• INSPIRE application schema – application schema specified in an INSPIRE data

specification

• INSPIRE data specification – harmonised data product specification for a theme adopted

as an Implementing Rule

• metadata – information describing spatial data sets and spatial data services and making it

possible to discover, inventory and use them [INSPIRE Directive]

• services allowing – spatial data services to be invoked [INSPIRE Directive]

• spatial data – data with a direct or indirect reference to a specific location or geographic

area [INSPIRE Directive]

• spatial data set – identifiable collection of spatial data [INSPIRE Directive]

• spatial object – abstract representation of a real-world phenomenon related to a specific

location or geographical area [INSPIRE Directive]

• transformation services – services enabling spatial data sets to be transformed with a view

to achieving interoperability [INSPIRE Directive]

• view services – services to display, navigate, zoom in/out, pan, or overlay viewable spatial

data sets and to display legend information and any relevant content of

metadata [INSPIRE Directive]

Abbreviations

• API – Application Programming Interface

• CMS – content management systems

• CSW - Catalogue Service Web

• EC – European Commission

• EN - European Norm

• ESA – European Space Agency

• EU – European Union

• GEOSS - Global Earth Observation System of Systems

• GMES – Global Monitoring for Environment and Security

• GML – Geography Markup Language

• HTML – HyperText Markup Language

• INSPIRE – INfrastructure for SPatial InfoRmation in Europe

• ISO – International Organisation for Standardisation

• KML – Keyhole Markup Language

• OGC – Open Geospatial Consortium

• RL – Reference Laboratory

• SDI – Spatial Data Infrastructure

• SEIS – Shared Environmental Information System

• SOA – Service Oriented Architecture

• UML – Unified Modelling Language

• URI – Uniform Resource Identifier

• URM – Uniform Resource Management

• WCS – Web Coverage Map

• WFS – Web Feature Map Service




07 March 2013 13 of 44

• WMC – Web Map Context

• WMS – Web Service Map

• WPS – Web Processing Services




07 March 2013 14 of 44

4 INSPIRE, Networking Architecture and HABITATS

In order to validate the HABITATS networking services architecture defined in Task 4.2, a

series of specific service applets were deployed and tested for data sharing using the

HABITATS Reference Laboratory (RL) geoportal platform.

Comparing network services and spatial data services, the INSPIRE Forum4 definitions are:

• Spatial data services are all services (Discovery, View, Download, Transformation,

Invoke, Other) regarding spatial data.

• Network services (Discovery, View, Download, Transformation, Invoke):

• non-compliant network services are INSPIRE compliant services with respect

to functionality;

• compliant network services are compliant services with respect to functionality

and quality of service.

The HABITATS networking architecture supports INSPIRE Network services, but needs to go

behind this concept. INSPIRE networking services are in principle limited only to the

management of existing data and metadata. The HABITATS Networking Services also

support such functionality with data and metadata management, data and metadata collection,

working with non-spatial data, etc.

The HABITATS service applets re-use existing applications where possible and are

themselves designed for re-use. The selection of the specific services to deploy is primarily a

user-driven process, as defined in the user scenarios and requirements of task T2.3 and as

required by the pilot validation platform of task T5.2. Task T4.3 has defined the prototype set

of Network Service Applets to be installed in validation pilot platforms, as:

• A series of specific networking service applets deployed and tested for data sharing

within the project using the Network Service Architecture (of D4.2.1)

• Interoperability Services

• Enabling Services

• Visualisation of information layers

• Overlay of information from different sources

• Spatial and Temporal Analysis

• “quick” and “light” on-demand applets to meet validation pilot expectations

and user needs

• Usability, simplicity and openness to rapid prototyping mash-ups.

• A set of specific service applets that allow users to identify, access, use and reuse

habitats-related data, designed and deployed on-demand to meet user needs,

• Users selected in the T2.3 user scenarios and T5.2 pilot validation platform.

• Mobile Apps allowing use advantage of HABITATS RL

• “Quick Prototyping” service applets respecting the HABITATS service architecture

and developed on-demand.

These are based on the outcomes from the earlier tasks and work with the HABITATS RL,

and will now lead into the interface tools and toolkit.

4 http://inspire-forum.jrc.ec.europa.eu/mod/groups/topicposts.php?topic=11135&group_guid=8651




07 March 2013 15 of 44

The HABITATS Networking Architecture aims to extend the principles of the INSPIRE

networking architecture, because INSPIRE doesn’t cover important aspects such as data

management and data collection. So all components of the INSPIRE networking architecture

will be included in the HABITATS architecture, but this concept will be extended by other

functionalities. From this point of view principles of GEOSS and GMES and also principles

of Shared Environmental Information System (SEIS) and Single Information Space in Europe

for the Environment (SISE) have influenced the HABITATS architecture and its networked

services.

The development of the network service architecture process of WP4 was initiated through a

state of the art analysis of existing SDI, to find out more about already existing infrastructures

and to examine how data should be shared and what services are required to enable sharing.

When designing the networking architecture, a set of specific networking service applets was

deployed and tested for data sharing within the project. Also the potential for re-use of

existing application was taken into account.

This Report deals also with the tools for invoking of Geospatial Services that arose within the

HABITATS network architecture, interlinking different data sources and also interlinking data

sources from different INSPIRE thematic areas.

5 Invoking services

The definition of spatial data services included in the INSPIRE directive is the following:

‘spatial data services’ means the operations which may be performed, by invoking a computer

application, on the spatial data contained in spatial data sets or on the related metadata

(INSPIRE 2007). ISO 19119 defines also taxonomy for Geospatial services (INSPIRE Invoke

Services 2009):

• Geographic human interaction services

• Geographic model/information management services

• Geographic workflow/task management services

• Geographic processing services

o Geographic processing services – spatial

o Geographic processing services – thematic

o Geographic processing services – temporal

o Geographic processing services – metadata

• Geographic communication services

• Geographic system management services (HABITATS 2009)

From INSPIRE Networking architecture, there are basic Networking services

1. Discovery Service (discovery): Is a services that makes it possible to search for spatial

data sets and services on the basis of the content of the corresponding metadata and to

display the content of the metadata.

2. View Service (view): Is a service that makes it possible, as a minimum, to display,

navigate, zoom in and out, pan or overlay viewable spatial data sets and to display

legend information and any relevant content of metadata.

3. Download Service (download): Is a service that enables copies of spatial data sets, or

parts of such sets, to be downloaded and, where practicable, accessed directly.




07 March 2013 16 of 44

4. Transformation Service (transformation): Is a service that enables spatial data sets to

be transformed with a view to achieving interoperability.

5. Invoke Spatial Data Service (invoke): Is a service that allows defining both the data

inputs and data outputs expected by the spatial service and a workflow point of view 5

The INSPIRE Spatial Data Service and Invoke Service – Draft, implements rules defining that

Invoke service has to be accessible via Internet and offers a mean to invoke the linked spatial

data services. Invoke shall support in order to allow clients invoking spatial data services.

Taking into account the potentially wide diversity of interfaces and protocols, invoke services

are services that allow access to sufficient service metadata to enable the activation or

execution of the spatial data service. The document updated the basic INSPIRE architecture

scheme and defined sets of requirements for INSPIRE Invoking services.

Figure 1 INSPIRE Networking Architecture

The requirements are divided into two groups of requirements:

• IR Requirement - Are requirements that are reflected in the Implementing Rule on

interoperability of spatial data sets and services are shown using this style.

• SDS Requirement - Requirements that are not reflected in the Implementing Rule on

interoperability of spatial data sets and services are shown using this style.

Document INSPIRE Spatial Data Services and Invoke Service define also set of

recommendation.

INVOKING service requirements and recommendations

• IR Requirement 1 The implementing rules are restricted to spatial data services that

relate to spatial data sets in themes in Annex I-III, or to their related metadata.

• Recommendation 1 There shall be no other requirements applicable to ALL spatial

data services than the establishment of discovery metadata.

• Recommendation 2 A spatial data service in this context shall have clearly defined

interfaces for machine-to-machine communication. A Geographic Information System

or other systems, understood as a set of tools for collecting, processing and storing

5 INSPIRE Spatial Data Services and Invoke Service – Draft, implementing rules,

Draft_IR_SDS_and_Invoke_1.0.doc




07 March 2013 17 of 44

spatial data, should not be considered an invokable spatial data service from the

perspective of the relevant Implementing Rules. But any specific functionality

included in it, and with a well-defined and exposed interface, could be an invokable

spatial data service.

• IR Requirement 2 Interoperability arrangements in the INSPIRE context shall be

related to invokable spatial data services.

• IR Requirement 3 Requirements for interoperability arrangements are only

mandatory for spatial data services operating upon harmonised data (i.e. spatial data

sets conformant to the regulation for IDSS).

• IR Requirement 4 A spatial data service conformant to interoperability arrangement

shall support coordinate reference systems according to Annex II.1 of the Commission

Regulation (EC) No 1089/2010 .

• IR Requirement 5 The default temporal reference system referred to in point 5 of part

B of the Annex to Commission Regulation (EC) No 1205/2008 shall be used, unless

other temporal reference systems are specified for a specific spatial data theme in

Annex I-III.

• IR Requirement 6 A spatial data service conformant to the interoperability

arrangement shall be available 99% of time.

• IR Requirement 7 A spatial data service conforming to interoperability arrangement

returning spatial objects as part of the output, shall encode those spatial objects

according to Article 7 of Commission Regulation (EU) No 1089/2010 of 23 November

2010 implementing Directive 2007/2/EC of the European Parliament and of the

Council as regards interoperability of spatial data sets and services.

• IR Requirement 8 All spatial data services conformant to the interoperability

arrangements shall include a Get Service Metadata operation.

• IR Requirement 9 Newly developed spatial data services operating upon harmonised

data or their metadata shall be conformant with interoperability arrangements.

• IR Requirement 10 Any harmonised spatial data service shall follow the

interoperability arrangements.

• IR Requirement 11 Any harmonised spatial data service shall have minimal

performance criteria defined in the same way as network services, i.e. performance,

capacity, and availability. The values will depend upon the character of the type of

service.

• Recommendation 5 The gazetteer service should be related to harmonised datasets

conforming to Addresses, Geographical names and Administrative boundaries. i.e.

Location instances should be fetched from these three themes, and correspondingly the

Location type should be either an address, a geographical name, or an administrative

polygon.

• IR Requirement 12 A registry service shall be compliant with ISO 19135:2005,

Geographic information -- Procedures for item registration.




07 March 2013 18 of 44

6 Problems of Policy Driven SDI

INSPIRE is politically driven top down approach. It is important to see how INSPIRE

reflects local, regional and national needs. Currently, there is low awareness on regional level

and the benefits for the local level are no clearly defined. During the JRC Cost benefit

workshop in 2012 the schema depicted in next figure was presented.

Figure 2 Reverse “pyramid” effect (Bregt 2012).

The schema shows the relation between the level of governance and the amount of benefits.

The HABITATS idea is to find a solution how to turn the green triangle upside down. It is also

vital for successful implementation of INSPIRE.

The authors identified three areas where special attention needs to be given for successful

implementation of the INSPIRE Directive:

• metadata;

• networking architecture;

The INSPIRE architecture doesn’t reflect the needs of regions regarding data collection and

updating. Usually, for different pilots’ needs, the generic INSPIRE architecture has to be

modified, extended or reduced. (Charvát 2011)

Global SDI building is usually described in a form of a pyramid. Current practices prove that

“spider web infrastructure building”, where different local or global levels are able to directly

share data, is more efficient. The HABITATS intention is to shift SDI from the pyramid to the

spider web paradigm.




07 March 2013 19 of 44

Figure 3 Spider Web Paradigm

Neogeography

There exist a large number of different voluntary or bottom-up initiatives supporting building

of different parts of SDI. The SDI world is changing with development of new GPS devices,

smartphones, mobile cameras and tablets. More and more localised information is collected

by citizens. For such type of data collection “people as sensors” or “human sensors” terms are

often used. This means that “human observations” can be part of future real-time SDIs and

serve as an input for spatial decision-making processes. Current use and collection of data by

citizens is higher than collection of data by public bodies. Such process is depicted in next

Figure.

Figure 4 The changing sources of spatial data (Harris & Lafone).

Local and community activities capture local knowledge in multiple media forms including




07 March 2013 20 of 44

videos, photos or oral histories. The collected information can contribute to up-to-date data.

The term neogeography is used for these methods. It is related to new Application

Programming Interfaces (APIs), Web 2.0 and the mapping capabilities of the Geospatial Web.

People can create “geotagged” information from mobile devices. This new technology opens

new possibilities. Neogeography represents a new way of collection and geographic

knowledge production using interactive technologies, interfaces and technical expertise. These

methodologies bring serious challenges to SDIs and traditional forms of data acquisition,

analysis, and publication. (Harris & Lafone forthcoming)

7 HABITATS Networking Services

The intention of the HABITATS Networking Services is to provide shift from classical

INSPIRE (GEOSS, GMESS architecture) towards solution, which will support local and

regional SDI building and their interaction with INSPIRE and also, which will move

standards SDI model towards Neography and SpiderWeb paradigm. The way to test and

provide it is Reference Laboratory as key tool of HABITATS Networking architecture.

The HABITATS architecture defines a platform-neutral SDI with a basic set of networking

services in compliance with the INSPIRE Directive for sharing environmental data, especially

that related to the 4 INSPIRE themes of 16.Sea-Regions (SR), 17. Bio-geographical Regions

(BR), 18. HABITATS and Biotopes (HB) and 19. Species Distribution (SD). This will result

in a European Metadata profile for these four data themes, which will be an extension of the

INSPIRE profile. Our intention is not only to follow the INSPIRE profile for discovery

services, but to also reflect on the extension the profiles for using data; a link to data

modelling activities is therefore necessary. This profile is further open to extension by single

countries or user groups, but the aim is that it be respected as a minimum set.

The set of HABITATS Networking Services have been implemented on the HABITATS

Reference Laboratory (RL) geoportal platform6. This acts as a client of the 7 HABITATS

pilots that provides a very rich set of cross-pilots, inter-regional and enabling services.

Reference Lab

The reference laboratory is the central hub of the HABITATS Networking Architecture. It

consists of several layers, which are (HABITATS D4.2.2 2011):

• Data layers – management data and files on storage, eventually guarantee access to

external sensors

Server (engine layer) – defines tools, which guarantee basic services on the server side

– supplying service

Client layer – is client side of web services, which guarantee access of users to

services

• Application layer is some form of wrapping elementary client services into application

or into such form, which could be used by other web tools and social media.

Presentation layer contain such web tools, which allow to combine and publish single objects

from the application level as part of Web presentation

The illustration below (taken from HABITATS D4.2.2 2011) shows the different layers of the

HABITATS Networking Architecture.

6 www.habitats.cz




07 March 2013 21 of 44

Figure 5 Habitats Networking Architecture

The final implementation of the HABITATS Services anticipates that selected concrete

services will be deployed for every pilot, and that there will be one central platform (i.e. the

Reference Laboratory).

Figure 6 Habitats RL and pilots




07 March 2013 22 of 44

The HABITATS RL provides the Networking Architecture supporting both Networking

Services and Spatial Data services, that support the SDI network services to enable trans-

European sharing of habitats-related spatial data between public authorities and other

stakeholders in the Community, enabling the creation of value added services. The RL is

focused on implementation of:

• Cross pilot scenarios based on sharing of data among more pilots

• Validation platform for testing of conformity of implemented pilot services

• Services supporting global discovery, view and downloading

• Repository for common metadata

• Repository for pan European datasets such as Natura 2000, CLC, Urban Atlas and

Open Street Maps

• Interlink with social networks

The RL provides the Networking Architecture, that supports the SDI network services to

enable trans-European sharing of habitats-related spatial data between public authorities and

other stakeholders in the Community enabling the creation of value added services.

The RL enables deployment of specific service applets, including interoperability and

enabling services, on-demand from user communities and the pilots for initial implementation

and validation. It is being developed further to include an invoking service toolkit integrating

the service applets with the goal of facilitating the development of end-user services accessing

habitats-related spatial data over time

However applications are the key objectives and final goal of using the HABITATS RL. As

the RL is just a geoportal tool to help to build applications that address the Pilots’ typical use

cases.

The HABITATS RL is

• an interface that enables interactive search, portrayal, evaluation, sharing, analyse and

reuse of spatial and non-spatial data.

• a solution based on interoperable standards (OGC, W3C, OASIS, ISO). It is

interconnected to other resources through the Internet. It helps to create a distributed

structure of information and knowledge with spatial position.

Figure 7 Habitats RL

However the RL is not a central data storage or a closed web application with maps. It is a

geoportal with




07 March 2013 23 of 44

• Independent components

• Composition according to user requirements

• Based on SOA

• Possibility to integrate with other resources

• Maximum openness

• Open Source

• Open Standards

• Extension to non-GIS community

• Open Search

• Administration of other (non-spatial) data sources

The HABITATS RL allows deployment of the current state of the art of technological

solutions, which will be tested and adopted by the HABITATS partners and user stakeholders.

It allows testing of current existing technology and generation of further research tasks driven

by users. The RL also collects information coming from other projects, which is an important

input for the HABITATS analysis and public discussion. The methods of social assessment

will be an increasingly important part of the RL.

Thus the RL’s networking services aim to help HABITATS to extend user-centric, co-design

approaches into the arena of standards design and adoption processes, considering standards

initiatives such as INSPIRE, OGC, UNSDI to be significant social, economic and institutional

innovations. The elements of the approach are maintained, applying the model at all levels

from the global scale to the local and regional policies that frame many HABITATS validation

pilots. Community building activities follow a Web 2.0 approach to capture the knowledge in

active user communities with a strong interest in contributing to the standards development

process. By inviting a broad multi-sectoral and inter-disciplinary range of concerned

stakeholders to participate into the HABITATS network, a viral motivation spiral is set off. A

peer-to-peer approach to opening up information sources and providing access to content

ensures a rapid extension of the critical mass of environmental data established by project

partners.

Uniform Resource Management (URM) Concept

Uniform Resource Management (URM) provides a framework in which communities can

share information and knowledge through description, which is easily understandable inside

of the community. It is based on a standardised schema supporting a uniform description of

information and knowledge including common vocabularies. The schema defines the

meaning, characteristics and relationships of a set of properties, and includes constraints on

potential values and the inheritance of properties from other schemas. The URM concept has

been defined and developed through the NaturNet-Redime project and extended by c@r to

support knowledge sharing inside a community (Charvát et al. 2008).




07 March 2013 24 of 44

Figure 8 URM concept

Uniform Resource Management supports validation, discovery and access to heterogeneous

information and knowledge. It is based on utilisation of metadata schemas. The URM models

currently integrate different tools, which support sharing of knowledge. Geoportal contains

common visualisation, data sharing, metadata and catalogue functionalities. It includes also

tools for sensor observation management and spatial data transformation and processing.

The principle of the URM allows to build a "spider web" infrastructure supporting

interconnection of portals and effective exchange of information. This concept is also more

related to GEOSS and Single Information Space for Environment (SISE) principles.

Many context attributes characterize the environmental information or knowledge. From the

point of view of context, the information or knowledge can involve different parties:

• Information or knowledge provider i.e. a party supplying the resource;

• Custodian accepts accountability and responsibility for the resources and ensures

appropriate care and maintenance of the resource;

• Owner of the resource;

• User, who uses the resource;

• Distributor who distributes the resource;

• Originator who created the resource;

• Point of Contact to be contacted for acquiring knowledge about or acquisition of the

resource;

• Principal investigator responsible for gathering information and conducting research;

• Processor who has processed the data in a manner such that the original resource has

been modified;

• Publisher, i.e. party who published the resource;

• Author, i.e. party who authored the resource.

The HABITATS RL is a new integrated solution designed as a combination of previous

technologies - Uniform Resource Management, Geohosting and new technological

development of a visualization client based on HSLayers. The URM Geoportal is not one

integrated solution, but a set of modules and services, which can communicate through

interoperable services (OGC, W3C). The solution is modular and can be readily modified for




07 March 2013 25 of 44

different purposes. The URM Geoportal is based on Open Source technologies, but it can be

integrated with different technologies such as MS SQL or ArcSDE. The Uniform Resource

Management (URM) supports validation, discovery and access to heterogeneous information

and knowledge. It is based on utilization of metadata schemas. The URM models currently

also integrate different tools, which support sharing of knowledge.

The URM Geoportal contains:

� Metadata

� Catalogue client

� Visualization client

� Metadata Editor

� Geoserver

� Styler

� Metadata Extractor

� Enterprise management tools

� Content management

� Social Networks tools

Figure 9 URM principles

The HABITATS RL geoportal contains common visualization, data sharing, metadata and

catalogue functionalities. Additional parts of the solution can also be tools for management of

sensor observation and spatial data transformation and processing.

The core part of the RL is the metadata system, which guarantees access to all information

stored in the portal




07 March 2013 26 of 44

The URM concept also allows access to any information stored on one portal with other

portals that use the URM principles.

Figure 10 URM Spidernet

So the URM allows a "spidernet" SISE (Single Information Space for the Environment in

Europe) infrastructure supporting interconnection of portals to be built with the effective

exchange of information

USE OF THE URM IN THE HABITATS RL

The HABITATS RL portal is based on the Uniform Resource Management (URM) concept

and was designed to aid awareness raising, training, presentation and sharing of knowledge

and tools within Living Labs (LL). Its first design was made in the Naturnet Redime research

project7, it is also used by EnviroGrids BlackSee project for implementation of GEOSS

infrastructure8 and its design and development continues into the current HABITATS project.

It is built as an interoperable network for an effective exchange of the information,

knowledge, and services relating to its multi- and interdisciplinary subject matters inside of

LL or among LLs. The portal is implemented using AJAX technology (WEB 2) supporting an

easy management of information within the portal and enabling an easy context awareness for

knowledge discovery using the URM. This URM concept supports a sharing of knowledge

within the community using metadata and catalogue standards for information description and

discovery. The system for authorization and support for a unique login for all components is

7 See www.naturnet.org

8 See www.envirogrids.net




07 March 2013 27 of 44

also an important part of the portal.

The portal supports those users searching for information dealing with the subjects of

sustainability, environmental protection and management and is also a place for others to

publish related information and resources.

It is possible to search by terms within several categories (this list of categories is not limited

and can be changed or increased). Firstly, the user can choose from one of several possible

folders (‘all’, ‘documents only’, ‘projects’, ‘maps’, etc.) by selecting the tabs at the top of the

page, which enable the user to search using their SEARCH TERM either more generally or

within a restricted range. The (main panel) window then displays the results of a search within

the catalogued information. The user can check the metadata for any of the listed items or can

run the application or view the document in those cases where the listed items are directly

linked to a document or an application.

An extended search allows searching for information in a variety of ways. Users can choose

from any of the parameters listed in the left window or use the map window. The map window

offers a way to select the geographic area in which the user is particularly interested. Users

can select by country or a smaller detailed area from the whole of Europe using the selection

rectangle for zooming.

A combination of both windows provides a better opportunity to precisely specify the required

information.

• Publishing user documents on the URM portal. o Users can use the Metadata Extractor, to find their file on their computer; using

the Metadata Extractor (file searching), ask for extraction of the available

metadata, then complete the missing metadata and publish their file and its

metadata on the URM portal.

• Publishing of user Web pages on the URM portal. o Users can publish any Web content through the URM portal. They put their

web address (URL) into the metadata extractor and extract the metadata. Edit

the missing records in the metadata (including a selection for the type of their

content) and then save the metadata.

• Registration of user metadata system on the URM portal. o If a user has a catalogue system supporting the following profiles (ISO 19115,

ISO 19119 and Dublin Core ISO 15836-2003 and supporting the Catalogue

Service for the Web (for instance using MICKA or GeoNetwork) they can ask

for registration of their catalogue on the URM portal.

• Registration of data or services directly from a user application. o An applications developer who directly publishes interactive Web data or

services, can ask for the CSW client, which will support direct registration of

their results in the catalogue.

• Publishing using URM tools. o Users may use the independent URM tools for working with their data, or for

their integration into new systems and presentation in e-learning or web

services forms.

URM Tools that are available on the HABITATS RL are described in the following

subsections.




07 March 2013 28 of 44

8 RL Networking Services and Invoking Tools

The HABITATS RL is designed and implemented as a virtual database. It uses principles of

web services, Uniform Resource Management (URM)9, social network sites,

Geoportal4everybody10

and the Semantic Web. It integrates different technologies such as

GIS, e-learning, multimedia, and virtual reality. An important element is its integration of

social networking tools supporting social assessment. These services are not implemented on

the HABITATS portal directly, but are implemented as virtual services in different places

across Europe.

In HABITATS we are dealing with the broader understanding of Invoking Services. We will

consider this as a possibility to invoke any type of geospatial services according to ISO19119

classification with platform. This means running services without the necessity to have any

application on the client side. In this first version of the deliverable we are dealing with

invoking service using Reference Laboratory.

The HABITATS RL includes the following types of tools:

• Authorization and authentication tools

• Content management, Enterprise Management System and Social networking tools

o Professional version based on Liferay

o Light version based on WordPress

• Uniform Resource Manager tools, including

o Metadata management tools

o SDI management supporting tools,

• HABITATS Networking Services and Invoking tools

These are currently implemented with the following specific tools:

• Authorization and authentication tools - guarantee access to all applications on the RL

• Liferay or WordPress - allows editing of the home page of the Unified Resource

Management portal.

• Uniform Resource Management (URM) which includes:

o MICKA11

- for spatial data / services metadata management according to ISO,

OGC and INSPIRE standards. The system can implement any standard based

on XML documents.

o Data Management Tools including

� Geoserver- an application for management of spatial data.

� Styler - The software tool allowing users to prepare map composition

and visualisation.

• Metadata extractor12

– The main purpose of the HABITATS RL is to take care of

spatial data, but there can also be a need to publish non-spatial

data (e.g. documents, web pages). This is done by the Metadata

9 Described at www.habitats.cz/simplecms/?articleId=19&action=article&presenter=ArticleDetail

10 See http://www.habitats.cz/simplecms/?articleId=16&action=article&presenter=ArticleDetail

11 See http://www.ccss.cz/en/?menuID=49&articleID=76&action=article&presenter=ArticleDetail

12 See www.ccss.cz/en/?menuID=49&articleID=76&action=article&presenter=ArticleDetail




07 March 2013 29 of 44

Extractor, which is very easy to use, and only requires to specify

which file or URL is to be published. The Metadata Extractor

extracts the metadata and stores them on the portal. Metadata is

stored by MICKA in the Dublin Core standard which is

designed for non-spatial data. The Metadata extractor also

allows whole pages to be published. This is done by uploading a

Zip file which contains these pages.

• Networking Services o Catalogue client

13 - allows searching through connected metadata catalogues

by the catalogue service OGC CSW. Data can be searched by

text or by elements defined in standards (OGC CSW 2.0.2, AP

ISO, INSPIRE). Basic elements can be extended by user

demands. These elements are not searchable in other connected

catalogues. The first version of the catalogue uses cascading of

multiple services.

o MapViewer - (developed by HSRS) is a JavaScript-based WebGIS map

application built using the HSLayers JavaScript library. It

extends OpenLayers and adds new functionalities including

WMS and WFS client, printing of hard copy maps, vector

editing capabilities and others. Several features, which are still

in the INSPIRE proposal stage (e.g. transformation service), are

used as well.

In addition the HABITATS RL can connect different desktop GIS tools as external

applications. These tools are not directly part of the solution, as they are more related to

educational content.

13

http://ccss.posterous.com/?page=3




07 March 2013 30 of 44

Authorization and Authentication tools

The RL is composed of independent components (modules). The information provided can be

made publicly available and every user is authorised to access it without authentication. For

the cases where the information can be for example viewed or modified by only restricted

group of people, the authentication and authorisation mechanisms are put in place.

Authorisation and authentication terms are often used interchangeably. The following

definitions should clarify the difference between them.

Authentication is a mechanism that securely identifies user within a system. It verifies the

identity of the user by for example a password or a fingerprint.

Authorisation is a mechanism that specifies access rights to the content or other resources.

In other words, authentication is the process of verifying that "you are who you say you are",

authorisation is the process of verifying that "you are permitted to do what you are trying to

do." Authorisation thus presuppose authentication. (Wikipedia contributors 2012a).

The RL enables users to control access to all their resources stored on the geoportal using the

authentication and authorisation mechanisms. Registered users can be authenticated by

credentials including the email address and a password.

Figure 11 Portal login

Unregistered users can create an account using a simple form by filling in a name, date of

birth, gender, username and email address. The creation of the user account is protected by

CAPTCHA14

ensuring that the form is filled by a person.

14

http://en.wikipedia.org/wiki/CAPTCHA




07 March 2013 31 of 44

Figure 12 Portal registration

The registration of users as well as the provision of permissions (authorisation) can be

managed by the system administrator.

RL uses its own mechanism for authentication/authorisation by LDAP (Lightweight

Directory Access Protocol). This will ensure that each server will act independently from the

others. It will also provide better data protection and better access control on the

corresponding level.

Upper level portal users may have access to private data by cascading user rights

through the infrastructure. Each node will have mechanism for saving user access to other

servers for authorised users. Also a masking mechanism will be used to avoid access to

restricted datasets.

Liferay based geoportal solution

The RL is based on Liferay15

solution. It is a web platform orchestrating all the geoportal

components and other gadgets, portlets, pages etc. Liferay allows editing the web pages (part

of the geoportal interface) and their content. Liferay enables administrators to:

• define the content and the system of the menu;

• publish articles, images, links etc.;

• publish predefined map compositions;

15

http://www.liferay.com/




07 March 2013 32 of 44

• publish RSS channels.

There are many other functions that can be used and that are described in detail in the

manual of Liferay available at http://www.liferay.com/. Liferay is focused on usability and

simplicity for end users but also on clarity and security of the implementation.

The administrator can define the menu of the geoportal and its submenus. Any menu or

submenu can incorporate external web links. The user can publish articles using the content

holders. A WYSIWYG16

editor provides a good user experience for beginners. The content

holders support HTML code for advanced users. The editor allows inserting various

multimedia content including You Tube videos, photos, SlideShare presentation etc. The print

screen of the content editor is in next Figure.

Figure 13 Liferay Interface

The geoportal supports RSS and GeoRSS feeds that can be displayed from remote sites. This

enables a straightforward and easy way of promoting the RL services. RSS (most commonly

expanded as Really Simple Syndication) is a family of web feed formats used to publish

frequently updated works—such as blog entries, news headlines, audio, and video—in a

standardised format. An RSS document (which is called a "feed", "web feed", or "channel")

includes full or summarized text, plus metadata such as publishing dates and authorship. Web

feeds benefit publishers by letting them syndicate content automatically. They benefit readers

16

http://en.wikipedia.org/wiki/WYSIWYG




07 March 2013 33 of 44

who want to subscribe to timely updates from favored websites or to aggregate feeds from

many sites into one place. (Wikipedia contributors 2012c).

GeoRSS is an emerging standard for encoding location as part of a Web feed. In GeoRSS,

location content consists of geographical points, lines, and polygons of interest and related

feature descriptions. (Wikipedia contributors 2012b).

CUSTOMISATION OF THE PORTAL CONTENT

The portal administrator can customise the content of each web page. Texts, images, You Tube

videos, SlideShare presentations and other content can be easily added. Next figures show the

steps of adding web content to the website including texts and images.

.

Figure 14 Customisation of RL I




07 March 2013 34 of 44

Figure 15 Customisation of RL II




07 March 2013 35 of 44

Figure 16 Customisation of RL III




07 March 2013 36 of 44

Figure 17 Customisation of RL IV

WordPress based GeoSocial Network

WordPress is web software you can use to create a beautiful website or blog. WordPress is

both free and priceless at the same time. WordPress plugins can extend WordPress to do

almost anything. Plugins are developed by the community and to find proper plugin is

sometimes difficult. This is also the case of adding geospatial information to each blog or

static page. None of the plugins fulfil the expected behaviour and features. Features we were

looking for are: 1. User can draw mark region, which has some relation to written blogpost.

2. Region will be displayed in the map while reader of the blog post is reading.

3. There is standardized way how to collect this geospatial information across the whole blog.

This features are developed in the new plug-in.




07 March 2013 37 of 44

Figure 18 WordPress Based RL User can add, delete and modify any type of geometry




07 March 2013 38 of 44

Figure 19 WordPress Article Editing

Based on geolocated blog posts, GeoRSS is generated, which can be consumed by various

services and clients.




07 March 2013 39 of 44

Uniform Resource Management (URM)

MICKA

MICKA17

is a meta information catalogue that fully complies with the ISO 19115 standard

and is fully compliant with the INSPIRE principles. It can be integrated with map

applications. It is multilingual. The web catalogue service uses OGC specifications.

MICKA is a complex system for metadata management used for building Spatial Data

Infrastructure (SDI) and geoportal solutions. It contains tools for editing and management of

metadata for spatial information, web services and other sources (documents, web sites, etc.).

It includes online metadata search engine , portrayal of spatial information and download of

spatial data to local computer.

MICKA is compatible with obligatory standards for European SDI building (INSPIRE).

Therefore it is ready to be connected with other nodes of prepared networked metadata

catalogues (its compatibility with pilot European geoportal is continuously being tested).

Functions include:

• Spatial data metadata (ISO 19115)

• Spatial services metadata (ISO 19119)

• Dublin Core metadata (ISO 15836)

• Feature catalogue support (ISO 19110)

• OGC CSW 2.0.2 support (catalogue service)

• User defined metadata profiles

• INSPIRE metadata profile

• Web interface for metadata editing

• Multilingual (both user interface and metadata records). Currently 16

languages are supported. It is possible to dynamically extend the system for

other languages.

• Context help (multilingual)

• Import from the following metadata formats are supported:

o ESRI ArcCatalog,

o ISO 19139,

o OGC services (WMS, WFS, WCS, CSW)

o Feature catalogue XML

• Export – ISO 19139, GeoRSS

• Support of thesauri and gazetteers.

• Display of changes with GeoRSS

• Template base interface with possibilities to change according to user

requirements

• Possibility of deep cooperation with any map clients for display of on-line

map services.

17

See http://www.ccss.cz/en/?menuID=49&articleID=76&action=article&presenter=ArticleDetail




07 March 2013 40 of 44

Figure 20 Micka Metadata Editing

MICKA stores metadata in a relational database and it is edited by dynamically generated

forms. Therefore it is possible to amend other standards or profiles. It is possible to switch

between profiles while editing. Individual profiles can be distributed into sections. With the

help of control elements it is possible to duplicate individual items, select from code lists or

connect to supporting applications. Checking of mandatory items is enabled while editing.

The MICKA integrated application is divided into 3 independent components:

• Metadata creation

• Metadata importing

• Metadata Management

Metadata editing tools and metadata importing tools communicate with Metadata

Management through the CSW protocol. This allows use of two tools independently on the

one MICKA system (for instance a user could integrate with GeoNetwork).

Metadata editing supports the editing of metadata records using a selected profile, as follows:

Figure 21 Micka Metadata Validation




07 March 2013 41 of 44

While downloading storage and validation is handled as follows:

Figure 22 Micka Metadata importing

Metadata importing support from xml files is as follows:

Figure 23 Micka Metadata importing XML

or directly harvest metadata from GetCapabilities of selected OGC services, as follows:




07 March 2013 42 of 44

Figure 24 Micka metadata importing WMC

After harvesting, metadata can be edited, downloaded, stored or validated, as illustrated in the

following screen grabs:

Figure 25 Editing of Imported metadata




07 March 2013 43 of 44

Figure 26 Validation result

The MICKA metadata management system supports deleting, updating and copying metadata

records.

Figure 27 Metadata records management

GEOSERVER

Data management

Data are uploaded to the system on portal upload page. If necessary the FTP server is

provided to enable upload of larger datasets.

Two basic concepts of handling the data are considered:

• File based approach – this approach is suitable for static data that are not going to be

updated too often. This approach uses original file as source of the data without any




07 March 2013 44 of 44

change. This solution enables uploading of new version of while as whole but is not

ideal for making changes of data subsets. This solution is also ideal for raster data but

can be considered for vectors as well.

• Database approach – Data are imported into database. Data changes can be then

maintained inside the database and each spatial feature or subset can be updated. This

solution is more demanding for implementation as well as data maintenance policy.

Details must be fixed during the second step of implementation. This solution is ideal

for vector data that are changing frequently.

Supported formats are:

• Shapefile for vector data;

• GeoTIFF for raster data. Shapefile is physically represented by several files (at least *.shp, *.dbf, *.shx). Due to this

fact these files must be zipped into one file for upload. The zip name will not be used for

server-side processing.

After uploading of data in file format, the data might be converted from original format to the

relational database management system (PostgreSQL + PostGIS). This step is not necessary

and can be discussed during the second step of implementation. Handling the data in the

database brings more capabilities for data maintenance.

User interface functionality:

• Data upload;

• Browsing existing data on the server;

• Renaming or deleting data;

• Importing data into database. Database can track changes in data and log all

updates. The policy how data are going to be updated depends on particular

use case.

• Uploaded data will be automatically exposed as data sources for Geoserver. Features:

• Uploaded zip file will be unzipped on the server and put in user’s directory.

• Name conflicts will be automatically solved by adding suffix or overwriting

may be allowed if confirmed.

• Uploaded file maximum size may be configured by the portal administrator.

• Coordinate system will be automatically read form shapefile *.prj file, if

present. If not, the user must set it in Geoserver manually.

Data visualisation

To be able to display newly uploaded data there are possibility to configure the way how they

will be provided to user. In general two basic concepts are considered:

1. Data are provided in raster format – in this case the data are rendered on server




07 March 2013 45 of 44

side by applying data Style in SLD format on original data. Rendered raster are

then served using WMS service (Web map service). For performance booth this

rendered data can be efficiently cached on server side. This approach is optimal

for large scale data that doesn't change too often.

2. Data are provided as a vector data and they are rendered directly in Java script

client. For this case the OGC WFS or KML is used. This approach is ideal for

overlay data that might be frequently edited.

For data service there is Geoserver used. The user interface functionality that are configure

such services are:

• Administrator can choose and configure particular data from Data Store

(directory of shape files, directory of raster data, spatial database) so that they

can be published on portal as new Data Layer.

• Administrator can configure particular form of the web service for this Data

Layer. WMS, WFS and KML will be supported.

• Administrator can assign predefined style in SLD format to particular Data Layer.

• Administrator can configure user rights that will limit the access to these data.

Generally each Data Layer can have a access mode to be read, written or

administrated.

• Configure the caching strategy and other caching details.

• Data Layers can be also grouped to Workspaces where the whole Workspace can

have common rights or restrictions.

Map compositions

The map composition can contain the user’s own data from the internal server as well as other

external data sources. All these data sources can be used for the creation of new map

compositions in the web interface. The web services can be accessed in two ways. Either by

typing the address of the web service or by searching the web service in the connected

metadata catalogue. Data can be in raster as well as in vector form. Vector data can be

visualised in various colours and/or symbols. Access rights can be defined for each map

composition. Each composition is also tagged with a metadata sentence and registered in the

metadata catalogue.

Data publication

The user can set up the parameters for the publication of the new composition according to the

requirements. This enables access by other users. Such new map compositions can be

portrayed by the user by two means. It can be done either using web browsers (Open Layers,

Google Map, DHTML client) or using desktop viewers (GoogleEarth). The map compositions

can be published as a brand new web service (WMS or WFS).




07 March 2013 46 of 44

The new map compositions can be used for example in mobile devices and e-learning

applications. This solution is of particular advantage to those working in a big team or

supplying information to the public. The system is fully compliant with the INSPIRE

principles.

Web Map Server includes tools, which support publishing of locally stored data (filesystem,

RDBMS) in the form of web services. The basic required services are:

• A Web Map Service (WMS) is a standard protocol for serving geo-referenced

map images over the Internet that are generated by a map server using data from

a GIS database

• A Styled Layer Descriptor (SLD) is an XML schema specified by the Open

Geospatial Consortium (OGC) for describing the appearance of map layers. It is

capable of describing the rendering of vector and raster data. A typical use of

SLDs is to instruct a Web Map Service (WMS) of how to render a specific layer.

• Web Feature Service Interface Standard (WFS) provides an interface allowing

requests for geographical features across the web using platform-independent

calls. One can think of geographical features as the "source code" behind a map,

whereas the WMS interface or online mapping portals like Google Maps return

only an image, which end-users cannot edit or spatially analyse.

• Web Coverage Service Interface Standard (WCS) provides an interface allowing

requests for geographical coverages across the web using platform-independent

calls. The coverages are objects (or images) in a geographical area, whereas the

WMS interface or online mapping portals like Google Maps return only an

image, which end-users cannot edit or spatially analyse.

Styler

In order to be able to style uploaded vector data files, SLD editor is used. We setup Styler

application, where the user can prepare his/her layer styles, using easy-to-use graphical tool.

User can create styles for each feature type based on its geometry type (point/line/polygon) or

attribute features. Styles are stored in form of SLD within the GeoServer administration

interface, for later usage.




07 March 2013 47 of 44

Figure 28 Slyling

Vector data editing

Logged-in user is able to provide basic vector data editing including modifying vector

features geometries as well as their attributes.

1. In the first step, user has to activate the editing panel.

2. In the second step, user has to define which vector features will be modified. The

application doesn’t allow the user to edit the whole dataset in place due to high client

load. Only several (1-5) features at once are changed.

3. When the editing operation is done and user is satisfied with modifications, data are

sent back to the server.

Communication between the server and the client will be provided using OGC WFS.




07 March 2013 48 of 44

Figure 29 Editing of vector data




07 March 2013 49 of 44

Figure 30 Data flow between HS Layers and Geoserver.

Layer hierarchy and thematic maps

The map application enables user to create thematic map compositions using services

published by GeoServer or any other OGC OWS server.




07 March 2013 50 of 44

Figure 31 User (or administrator) can create thematic maps (map compositions) using standard OGC OWS client, part of the mapping application.

The map application offers two ways how to look at the map content:

• Logical view, where layers can be organized into groups and sub-groups, without

impact in their physical order in the map window, and

• Physical view – where user can change layer order and hierarchy. Created map compositions can be stored and recorded in metadata catalogue for later use (e.g.

by another user).

Figure 32 Ordering layers into groups, without touching the physical structure of displayed maps.




07 March 2013 51 of 44

Figure 33 Changing the physical structure of displayed layers. In the "Physical view" tab, layers

cannot be structured into groups, but their position in the layer tree (using drag&drop) can be changed.

METADATA EXTRACTOR

Metadata extractor is a tool to extract available metadata directly from different files

(documents, presentation, etc.), edit this metadata and publish metadata and files on an URM

portal. It can also extract metadata (and then edit) directly from existing URL addresses and

store metadata on an URM portal. Access to information is then through direct URL

addresses.

Currently the metadata extractor supports

• publishing documents on the portal – users can select any type of file on their

computer, extract and edit metadata and published this file on a portal;

• publishing of links to existing Web pages only putting URL of Web pages to extractor;

• or published directly new Web pages stored in Zip file. These Web pages are directly

accessible through an URM portal.




07 March 2013 52 of 44

Figure 34 Metadata extractor

Networking Services and Invoking

The HABITATS Reference Laboratory currently has two types of networking services:

• Catalogue services

• View services

CATALOGUE SERVICES

The Catalogue client allows searching through connected metadata catalogues by OGC CSW

catalogue services. Data can be searched by text or by defined elements defined in various

standards (including OGC CSW 2.0.2, AP ISO, INSPIRE). Basic elements are datasets and

services. Basic elements can be extended by user demands but they are not searchable on

other catalogues. While the initial version of catalogue services used cascading of multiple

services, the current version supports adding services independently on each other.

This application interacts with a map viewer and allows map services to be added into a map

by just one click. Another interaction is with the metadata extractor. Documents or web pages

stored by the extractor can be opened also by one click. Services can be added from list of

predefined services or can be added by direct links.




07 March 2013 53 of 44

Technical description:

• Written in PHP (server part), ExtJS Javascript framework (client part)

• Client components (may be used separately):

• Basic search form (search row) – provides basic Google-like fulltext search

Figure 35 Catalogue Search

• Advanced search form – over all INSPIRE queryables. User required queryables can

be added.

Figure 36 Advanced search

• Result list – presents a brief record list from GetRecordsResponse from catalogue.

Pagination and user-defined templates with different levels of detail are supported.

Clicking on the record allows the user to get detailed metadata.




07 March 2013 54 of 44

Figure 37 Metadata Detail

• Map panel – enables interactively enter search bounding box and shows spatial extent

of found metadata records.

Figure 38 Metadata Spatial Exten




07 March 2013 55 of 44

Figure 39 Catalogue Client architecture

The Catalogue Client architecture is as shown:

Its functionality includes:

• Support of OGC Catalogue Service for Web (CSW) 2.0.2.

• Support of csw:Record (Dublin Core) and gmd:MD_Metadata type names.

• Multilingual user interface

• Multilingual metadata records are displayed in actual user interface language. If not

present, the main metadata record language is used.

• Printing of metadata record (PDF format)

• Mechanism displaying and linking coupled and aggregated resources (operatesOn for

service, parent / children metadata and other types of link between metadata records).

• Support for thesauri service (thesauri SKOS client)

• Parallel searches across multiple CSW servers (each service may be presented in

separate tab)

• Adding predefined CSW or user defined

• Caching results for better performance

• Saving/restoring application status between page visits

• Configurable integration with map viewers to display found on-line services (WMS,

WFS)

The catalogue client is an independent Metadata Management System that can be used for

example with GeoNetwork.

Invoking of discovery services

The reference laboratory uses its own catalogue, but there are also possibilities to invoke

another catalogue from a remote platform into the system. There are two possibilities:

• To harvest metadata into the reference laboratory.

• To provide direct search of remote catalogues.

For both possibilities it is necessary to register the remote catalogue in the metadata system of

the reference laboratory. This can be done using the Import functionality of the remote

catalogue services.




07 March 2013 56 of 44

Figure 40 Catalogue Import

After registration of these services, this catalogue could be used for harvesting or multi-

searching on the side of the Reference Laboratory discovery services.

Figure 41 Catalogue import

Experiences with sharing of metadata in INSPIRE and GEOSS and Super

Catalogue implementation

CATALOGUES INTEROPERABITY PROBLEMS

During our testing of different “INSPIRE and GEOSS catalogues „we detected these

problems in some implementations:

1. Not functioning catalogue (catalogue moved to another address, temporarily

unavailable, password protected).

2. Catalogue does not implement properly CSW 2.0.2 (older version, errors etc…) or it is

based on another standard

3. In current version of CSW 2.0.2 specification many things are unclear or missing so

vendors implement them different way (e.g. harvesting of catalogues, behaviour of

different typenames, queryables etc. )




07 March 2013 57 of 44

4. CSW should support Dublin core (csw:Record), but other profiles are optional. There

are implementations of ebRIM, ISO, FGDC and other. For INSPIRE ISO AP 1.0 is

mandatory, but not all catalogues support it.

5. Protocols: CSW should support GET, POST and optionally SOAP protocol, for most

implementations POST AND SOAP are used. Not all catalogues implements these

protocols for GetRecord as well as GetRecordById operations.

6. Query languages. CQL and OGC Filter should be supported. Some catalogues has

errors in implementation or does not support full language properties.

7. Queryables. There are mandatory set of queryables but INSPIRE requires additional

queryables. Not all catalogues implements the INSPIRE queryables, we register some

problems (response times, empty set of results) with some queries.

Idea of Super Catalogue - SuperCAT There are many OGC web services available worldwide which may be widely use in different

scale of applications. But if the SDI or other applications should be operable, it is crucial to

have the services available and reliable all the time. In real life many problems have revealed

regarding services access and operability:

1. Not all services have public metadata record to be found with. They are not

catalogued.

2. If the services are registered on catalogues where may be accessed (e.g. OGC CSW, on

portals etc.). Because of using “deep web” methods, occasional users are not able to

simply search these resources by common search engines like Google or Bing. So the

metadata are available only for users, who know the catalogue address or address of

portal offering the human interface to catalogue.

3. Topicality of single catalogues. Many metadata records are not up to date and links to

services are not valid in many cases. Sometimes the provided ULR links to web page

or viewer rather than service connect point.

4. Some catalogues don’t respond. (The same problem like other services)

5. Services metadata are catalogued many ways, because there are no common “global”

rules how to uniquely code some element e.g. serviceType and other elements. The

query results may not give clean results.

6. If the services are running, the service metadata are very often quite poor, especially

layers metadata URL are not available.

CENTRAL CATALOGUE IMPLEMENTATION

To provide our users clean access to running services, we attempted to build services metadata

repository on our server.

• The catalogue is CSW 2.0.2 ISO AP 1.0 compliant (MICKA)

• Supports INSPIRE metadata profile and queryables

• Enables to register remote catalogues and harvest them periodically (Figure 1)

• Enables to harvest other services (WMS, WFS, WCS, CSW) and individual metadata

files

• Enables monitoring registered services if they are running properly (Figure 2, 3)

Processing:

• These metadata catalogues were registered to catalogue for harvesting in first phase:




07 March 2013 58 of 44

o ISPIRE national nodes: Austria, Belgium, Czech republic, Finland, France,

Germany, Luxembourg, Poland, Portugal, Slovakia, United Kingdom

o CIDP

o EEA SDI

o ENVIROGRIDS

o EuroGEOSS

o GEOSS

o HABITATS

o One Geology Europe

o Plan4all

o WHO

• The resources are harvested daily with filter to services only (type=service)

• Harvest protocol is generated for checking the availability of the catalogues. Mail

notifications are sent to corresponding users to ensure feedback.

• Test of availability is performed for all services daily (only WMS at this phase). It the

service is not running, the corresponding metadata record is not deleted but only

hidden for the case the service is temporarily not available. So next day the record may

be set to public if the service is alive again.

Figure 42 SuperCat harvesting




07 March 2013 59 of 44

Figure 43 Micka harvesting configuration




07 March 2013 60 of 44

Figure 44 RSS channel – harvesting results

Figure 45 Heartbeat protocol




07 March 2013 61 of 44

TESTING RESULTS

2222 services were harvested from registered catalogues. WMS services were analysed

detailed (see table 1). The 87% responding services is quite good result.

Table 1

Service type code count Responding

(count)

Responding (%)

WMS 96 88 92

OGC:WMS 1418 1351 95

View 343 190 55

View 1 1 100

VIEW 2 2 100

View Service 73 73 100

Together 1860 1632 87

Table 1 Testing WMS services results

But we met these problems:

1. serviceType is ambiguous in many cases (see table 1). INSPIRE directive brings more

confusion into service classification.

2. There is no thematic classification for services and metadata are poor in general. Then

the catalogue queries are not efficient. (At least INSPIRE theme keywords or other

commonly used code list would be good step to introduce some thematic

classification)

3. Unique service URL is not stated. INSPIRE says, it would be Capabilities document

URL (e.g. distributionInfo/*/transferOptions/*/onLine/*/linkage= ¡Error! Referencia

de hipervínculo no válida.), but it is coded in different way (only service connect

point in most cases and additionally

distributionInfo/*/transferOptions/*/onLine/*/protocol=OGC:WMS-1.1.1-http-get-

capabilities, but it varies from service to service)

PRACTICAL RESULTS

Central catalogue enables smooth access to dozens of services on one portal. We also provide

mobile solution, where the SDI may be simple accessed from mobile devices.




07 March 2013 62 of 44

Figure 46 Portal – metadata catalogue client

Figure 47 Mobile catalogue client




07 March 2013 63 of 44

Figure 48 Mobile catalogue client connected to central catalogue and map viewer showing found

WMS

PLANS FOR FUTURE

• More detailed services checking (now only capabilities document is tested)

• More catalogues and services will be harvested

• WFS, KML and WCS metadata will be processed

• Provide web interface to be searched by commonly used search engines (Google …)

View Services

HSLayers is yet another OpenLayers & ExtJS based mapping framework. Its development has

been started in 2007 and is still provided mainly by Help Service - Remote Sensing. HSLayers

is released under GNU/GPL. Currently, 3.0 development branch is the actual.


OpenLayers are used for their capabilities of geodata visualization, such as raster maps (JPEG,




07 March 2013 64 of 44

PNG, ...), web services (OGC WMS, OGC WFS, ...), various vector formats (KML, GML,

GeoRSS, ...), proprietary formats (Google maps, OpenStreetMap, ...), working with

projections and great user experience with the map.

ExtJS was used because of its well design and source code structure, which enables to create

various elements of UI (panels, tree structures, grids, forms), in a very simple and fast way.

HSLayers are designed as set of basic stones and components, which can be put together and

custom application can be build. There are provides such top all-including class, which

incorporates nearly all features of HSLayers: MapPortal.

Figure 50 HSlayers Map Portal

The HSLayers18

set of tools is used in new generations of map applications, and includes:

• HSLayers Components

• HSLayers Portal

• Server scripts (Transformation, Print)

• Editing with HSLayers

• Special HSLayers.Layer.MapServer type

From a developer’s point of view, HSLayers/OpenLayers is a pure JavaScript library for

displaying map data in most modern web browsers, with no server-side dependencies.

OpenLayers implements an object-oriented JavaScript API for building rich web-based

geographic applications, similar to the Google Maps and MSN Virtual Earth APIs.

OpenLayers can display various types of raster and vector data formats. It inherently supports

OGC WMS specification, as well as common Image formats (in PNG, GIF or JPEG format).

There is also support for multiple proprietary formats, such as Google Maps, Yahoo maps and

18

http://redmine.ccss.cz/projects/hslayers, see also

http://gis.vsb.cz/GIS_Ostrava/GIS_Ova_2010/sbornik/Lists/Papers/EN_2_11.pdf




07 March 2013 65 of 44

others. OpenLayers uses tiling of raster data. A numbers of vector (and text) data formats are

also supported. The system allows the rendering of vector features in GML, OGC WFS,

GeoRSS, KML formats. Creation of regular shapes (boxes, circles, ...) is also supported.

Points can be displayed as special point features with image icon or vector point features.

Many controls are available to support map interactivity and customization. Among others,

these include: zoom bar, overview map, layer switcher, various toolbars and mouse action

handlers can be used. Thanks to its advanced event model, custom map control can also be

readily programmed. (Cepicky et al. 2008). So it is an ideal platform for the HABITATS RL

to support all of the possible Network Service requirements of the pilots.

HSLayers features are coming up from OpenLayers and therefore their characteristics are as

follows:

• Portrayal of various types of data:

o Raster: OGC WMS(-T), Image (PNG, JPEG, GIF), …

o Vector: OGC WFS(-T), GML, GeoRSS, KML, GPX, GeoJSON, …

o Data sources from commercial servers: Google Maps, Virtual Earth, Yahoo

Maps, …

Map

Figure 51 Map Window




07 March 2013 66 of 44

HSLayers.MapPanel is container for the map. The map usually interacts with the user through

mouse gestures, so it zooms in/out, pans etc. There usually is graphical tool for setting the

desired region - bar for panning and zooming. Several other tools, which do enable the

interaction with the map are available too, namely zoom history, measuring of lines and areas,

tool for querying the layers and other custom tools. Tools for working with the map content,

such as saving/restoring web map content (WMC) files, printing the map content or

generating the permanent link for current map state are available too.

MapPanel contains various map layers, it enables to the user to work with the map (zooming,

panning, ...). Zoom bar together with overview map are available.

Tools for direct interaction with the map are available too, such as navigation, navigation

history, measuring, querying and others.

The top toolbar and bottom toolbar are used for other informative tools, or tools for working

more with the map content, than in the map itself. We can see buttons for saving and restoring

OGC WMC files, printing, permanent link generator, scale, mouse position and copyright

information.

Layer Switcher

With LayerSwitcher, user can change visibility of available layers, change their order in the

layer stack, set transparency and other features and use shortcut links to layer metadata or

remove them from the map.

LayerSwitcher is one of the most complex components of HSLayers. We do introduce two

different views at the layer stack: the physical structure and the logical structure.

Figure 52 Physical and Logical Structure




07 March 2013 67 of 44

LOGICAL STRUCTURE

Represents the view on the application, where layers are organized into groups (or folders)

according to some user-defined logic. Layers can be sorted into folders according to their

original service, or based on their content

Physical structure corresponds with the layer stack, how it is displayed in the map. User can

change layer order (using drag & drop) etc.

LayerSwitcher is able to display also legend to all layers, perform user searches in the layer

stack, display basic information and settings in the layer menu (such as abstract, scale range,

title, ...). User can move the layer, drop the layer or change layer’s name.

There is also basic work done, on WFS filtering, SLD defining, transparency settings etc.

User can use several shortcut links to layer’s metadata, copyright information and others.

The Layerswitcher also uses 3-state checkbox. Every folder checkbox has three states - on (all

layers within the folder are visible), off (everything is invisible) and custom.

OWS

HSLayers contains complex OGC OWS client, which is capable to work with OGC WMS

data directly, with OGC WFS and OGC WCS via server-side script Proxy4ows.

HSLayers contain mechanism, how to read parameters from URL directly, so the application

can start with OWS Client opened and Capabilities document parsed.




07 March 2013 68 of 44

Figure 53 HSLayers.OWS - Open Web Services client

Working with OWS Client is straight forward - user gives the URL, where the service is

running and type of the service (usually OWS). After capabilities are loaded, form with

service parameters is displayed (image format, query format, etc.) together with layer tree,

where several layers can be checked. Service metadata (service provider, abstract, title, etc.)

are displayed in separate tab.

After that, layers can be added into map. When user wants to display some on-line available

files, such as GeoRSS, GML, KML or similar, she just need to specify the URL and file

format. After that, user is requested for the layer name and it is added to the map as well.

Printing with HSLayers

HSLayers includes printing setup, so that content of the map can be printed at any printer or

used in other desktop GIS workstation. The printing client enables the user, to choose between

printing a map to a pre-defined template (PDF or HTML output) or saving the content of the

map into a raster image (image output).

When the user makes a choice, that he wants to create a raster image with the map’s current

content, he can either directly click the button, and a copy of the map window will be




07 March 2013 69 of 44

displayed, according to the selected image format (which can be one of PNG, JPEG, GIF and

geo-referenced GeoTIFF). The desired scale and region can be set as well. When a user

chooses to print a map to a pre-defined template, a new box is drawn, representing the paper

box.

Users can move the paper over the map and define the desired region. The size of the paper

box is always adjusted according to the selected scale. Additional information can be added as

well (map title, description, icon). The map is then layouted according to selected pre-defined

template to PDF or HTML output. The template is prepared as a HTML page. Printing is

provided by a server script, which is able to work with standard WMS services, tiled-layer,

vector data and other inputs. The paper is dependent on prepared templates - it can be virtually

anything from A5 to A0.

Figure 54 Printing with HSLayers

Printing form. The orange square represents the paper. User can move the paper on the map

and define the printing area. In this case, HTML output page will be generated, according to

selected template.

For the printing, server component is used, which uses MapServer mapscript for preparing the

mapfile according to displayed map layers (raster, service or vector) and layouts the map in

the desired form (PDF according to template or simple image). Output templates are HTML-

based, and they are converted from HTML to PDF using webkit renderer.




07 March 2013 70 of 44

Figure 55 Printing Result

Printing result - based on given HTML template with several additional keywords (easy to

setup for everybody), user will get PDF output with title, map, legend and overview map

rendered.

Web Map Context

The important new issue is the support for Web Map Context (WMC). Web Map Context

(WMC) describes how to save a map view comprised of many different layers from different

Web Map Servers. A ‘context’ can be encoded and saved so that Web maps created by users

can be automatically reconstructed and augmented by the authoring user or by other users in

the future. A Context document is structured using eXtensible Markup Language (XML).

Potential uses for context include creating default initial views for Web maps for different

hazards, saving the state of a user’s work on a viewer client to preserve information such as

how geospatial layers are added or modified, and saving the state of a client session for

sharing with other users. This mechanism is valuable for efficiently communicating across

shift transitions. Also, context documents can be catalogued and discovered for reuse by

others

• Define WMC on the base current composition on portal

• Save composition on local disk

• Save composition with metadata on server




07 March 2013 71 of 44

• Open composition from local disk

• Open composition from server

• Open composition from remote servers using metadata description

The implementation of the WMC concept presents a new way to the future upcoming

solution, when the system will support easier collaboration and sharing of results. It also

supports the reuse of results of work done on portal by other applications.




07 March 2013 72 of 44

Figure 56 Web Map Content Editing

This figure represents the basic configuration of form, which will save (to local drive, not

upload to some server-service) WMC file, containing information about current map

composition.

OGC WMC is rather old standard, which does not support all possible types of layers, which




07 March 2013 73 of 44

can be displayed in HSLayers. On the other hand, it is only one standardized format. For

saving map content more precisely, we’ve developed custom JSON format, which is used

among others in Permalink.

The main disadvantage of WMC is, that is is able to store WMS and WFS layers only, while

having Image, WMST, Raw vector data and other layer types in the map. For storing complete

web content, including user-defined data, Permanent link can be used.

Permanent link

Users often spend hours with creating ideal map compositions, based on various web services,

custom user graphics and other data sources. How to save the map content?

Another issue is, how to send custom map composition, or just simple user graphics (e.g.

parcel specification), zoomed into particular location?

For this, permalink has been developed. Unlike permalink which is wildly used among

various mapping applications, we cannot store information about displayed layers into the

map’s URL. For this purpose, special JSON structure with the map content is stored on the

server. The file can be also downloaded to local hard drive. Unlink OGC WMC (which is

supported by HSLayers too), every layer type displayed in the map can be stored into this

structure. User sends just the link to another user, and whole map content will be

reconstructed at the other computer.

Figure 57 Permanent Link

Permalink window, which is displayed after copy of current map content is saved to the

server. User can now download the JSON structure or send the link to another user.

Embedded

Some users do want to prepare their map composition and display the result in their own web

page. For this purpose HSLayers Embedded is here. It generates HTML snippet, which can be

add to any web page and after the page is re-loaded, map pops up.




07 March 2013 74 of 44

Embedded uses same JSON format for saving the structure of the map content, as for example

Permalink does. All layers displayed in the map portal are transferred in to the embedded

map.

This particular component needs little PHP-based script, which generates the desired form of

embedded map. Pure HTML, Simple ExtJS and Advanced ExtJS output are supported, based

on the complexity, the user wants to have the resulting map.

Figure 58 Embedded

Form, which generates HTML code, which can be later used in user’s web page.

Querying displayed layers

HSLayers.Control.Query is tool, which enables to the user to point with mouse in the map at

some place and perform spatial query. Following layer types are queryable:

• OGC WMS with capability to display information in text, html, GML or other

format

• Vector layer of any type, such as KML

• Proprietary MapServer layer (not only point, but also box query is allowed).

It works in very straight-forward way. User does not need to take care about layer query type

or server output format. HSLayers tries to display result of the query in a grid form, if

possible. All visible layers are queried automatically. Along with query result, mouse position

is displayed as well, so that user can copy and re-use it.




07 March 2013 75 of 44

Figure 59 Result of the point query on one vector layer.

User graphics and measuring

HSLayers do offer possibility of measurement of lengths and areas. Unlike most other

systems, HSLayers do enable to the user to measure several objects at once - not only one line

can be drawn, but many. User can also combine lines with areas.

HSLayers extended the measuring function into the user graphics concept. User can draw

any geometry feature, set its attributes. Along this, areas are lengths are calculated and

continually recalculated. Use can draw new graphics, delete existing once, set attributes

(simple or complex). Resulting graphics can be printed or used in Permalink or Embedded

map.

Figure 60 User graphic

Several geometries with their dimensions drawn in user graphics layer.




07 March 2013 76 of 44

OGC Web Processing Service client

HSLayers contains first version of generic OGC WPS client. Client is able to parse

GetCapabilites response, generate form for input data on-the-fly and submit the Execute

request. User can at the end download the resulting data. Since the standard is very vague in

some cases, and server-side implementations are changing a lot in the time, it is always

necessary to test the client against particular server and eventually fix some issues. When

dealing with ComplexInput data, HSLayers WPS client is able to send any type of Vector

layer displayed in the map, as well as send direct link of WFS GetFeatures or WCS

GetCoverage request. User can also draw custom graphics and send the data to the server, to

be analysed. When data are returned back, user can either add them to the map, or download

them directly.

Figure 61 OGC WPS client

Generic WPS Client with on-the-fly generated form for data inputs for the Buffer process.




07 March 2013 77 of 44

.

Figure 62 Image classifcation

Simple presentation of OGC WPS - satelite image classification.

Figure 63 Buffering

Complex presentation of OGC WPS client as well as functionality of Proxy4OWS

Server-side scripts

Although HSLayers can be considered as pure JavaScript library, it is designed to work with

several server-side components (scripts), which are enabling more advanced features, such as

• warping script for on-the-fly raster data projection

• printing script for creating hard-copy maps




07 March 2013 78 of 44

• ability to work with OGC WCS and WFS services

• session management

• OGC WMC handling

HSPROXY

HSProxy is Python script, which enables calls from the map application to various remote

servers, for example to WMS server, which is (for security reasons) not possible to do

directly. For this purpose, little server-side proxy script needs to be setup, which performs this

remote-call operations.

HSproxy deals as proxy for Ajax calls from JavaScript to various remote servers (used for

Query, WMS, ...). It also converts mimetypes headers of coming XMLs, to text/xml, so that

browsers can read it and parse them easy. Often it is the case, that for examples WMS

Capabilities document, which is returned by the server has different header, which is not

recognized by the web browser as simple XML file, and parsing is than very difficult.

Converts coming files from various encodings to UTF-8, to make sure, every response from

the server, using various encodings, is displayed correctly in the map.

StatusManager server script

Status Manager is PHP script, which

• Reads and writes state of the map (using PHP Session id and JSON format with

description of the map content), so that user, while page reloading, gets the state, she

got before leaving.

• Is used as server-side file-handler. Often we need some data, to be offered to the user

as file for downloading. Or user sends file, and we need to get its content. This simple

script enables this javascript <–> file object connection.

When user needs to upload an image or for example GeoRSS file, which needs to be

displayed by the map, certain server-side interaction (but very small one) is needed.

StatusManager is helping us to provide such interaction.

PROXY4OWS

In the web environment, we are are often facing a problem, how to display data, which are not

suited for direct visualization (for example large GeoTIFF files). Proxy4OWS tries to

overcome this problem. It generates OGC WMS service from OGC WCS, WFS or even from

another WMS on-the-fly. This generated WMS can be then consumed by any WMS client

easy.

Reason for this is, wen so display large vector data (produced by WFS servers), large raster

GeoTIFFs (produced by WCS servers) and data, services, which coordinate reference system

does not correspond with client’s coordinate reference system (in case of some WMS servers).




07 March 2013 79 of 44

It is written in python, using standard MapServer and GDAL components.

Figure 64 Sequence diagram of proxy4ows shows the negotiation between the client, proxy4ows

middleware and the target server.

Invoking with HSlayers

INVOKING OF VIEW (WMS) SERVICES

The WMS services can be invoked into the visualisation client in two ways: The first is to

discover WMS services from catalogues and visualise WMS services directly from

catalogues.

Figure 65 Invoking from catalogue

The second possibility is to add the WMS URL directly to the visualisation client HSlayers.

The URL could be added using OWS services.




07 March 2013 80 of 44

Figure 66 WMS invoking

WMS COORDINATE TRANSFORMATION

In the real-life, we are often facing a problem, how to display map from the server, which

does not support coordinate system of the displayed map. This is implemented with help of

Proxy4OWS (described later in this document). It is assumed, that Capabilities document is

already parsed, it is expecting GetMap request from the client to Proxy4OWS directly. The

GetMap request is expected to have - next to original WMS parameters - also three add-on

options:

- owsService - this is going to be WMS

- owsUrl - URL of the original service, which is expecting to handle the GetMap request

- fromCRS - CRS of the original coordinate system, from which shall the result of

GetMap be transformed to.

Proxy4OWS generates MapServer's mapfile on-the-fly. Only one layer is attached to the

mapfile - layer of type WMS. MapServer then formulates the necessary request, fetches the

data from remote server and provides image transformation on them. Result is always little bit

distorted, because the resolution is not always fine enough, but the it can be used and

displayed in the mapping application.




07 March 2013 81 of 44

Figure 67 WMS Sequence diagram.


from EPSG:4326 source.




07 March 2013 82 of 44

Thanks to Proxy4OWS, we can now display seam-less data from several WMS resources,

which do not support coordinate system of the map, displayed in user's browser.

INVOKING OF MAP COMPOSITIONS – WEB MAP CONTEXT

The important new issue is the support for Web Map Context (WMC). Web Map Context

(WMC) describes how to save a map view comprised of many different layers from different

Web Map Servers. A 'context' can be encoded and saved so that Web maps created by users

can be automatically reconstructed and augmented by the authoring user or by other users in

the future. A Context document is structured using eXtensible Markup Language (XML).

Potential uses for context include creating default initial views for Web maps for different

hazards, saving the state of a user's work on a viewer client to preserve information such as

how geospatial layers are added or modified, and saving the state of a client session for

sharing with other users. This mechanism is valuable for efficiently communicating across

shift transitions. Also, context documents can be catalogued and discovered for reuse by

others; this allows analysts to benefit from lessons learned in previous episodes. 19

In URM there is now implemented strong support for discovery and defining new WMC

based on information displayed on portal. The system allows to:

• Define WMC on the base current composition on portal

Figure 69 Composition Saving

• Save composition on local disk

• Save composition with metadata on server

• Open composition from local disk

19 http://www.eu-orchestra.org/TUs/Standards/en/html/Unit4_learningObject6.html




07 March 2013 83 of 44

Figure

70 Open Composition from local disk

• Open composition from server

• Open composition from remote servers using metadata description

The implementation of the WMC concept presents a new way to the future upcoming

solution, when the system will support easier collaboration and sharing of results. It also

supports the reuse of results of work done on portal by other applications.

INVOKING OF WFS AND WCS

For the invoking of WFS and WCS for visualisation proxy4ows is used. When working with

large vector datasets, we are usually facing limits of current browsers. Google Maps 1 for

example has limited the number of displaying vector features to 1000. In OpenLayers 2, there

is no limit for the number of features used, but displaying e.g. cadastral map makes browsers

often freeze. An advantage of working with vector data directly is (among others), the direct

possibility of editing vector data, a more interactive way of user experience and speed (when

dealing with reasonable amounts of data).

While vector data can be displayed using current technologies, some popular raster data

formats, such as GeoTIFF, cannot be. According to W3C , only few formats for raster data are

supported, none of them is really used or usable in GIS, usually because of the compression

method they are using. In the internet, raster graphics format focus on possibly low amount of

data transferred from the server to the client, while losing the accuracy of the data being

transferred. In GIS, we are focusing on data quality, regardless of file size.

Raster and vector data are usually distributed using OGC OWS standards. Vector and raster

data are distributed via OGC Web Feature and Raster Service respectively. Both services are

offering lists of datasets and metadata.

Another problem might occur, when some OGC Web Mapping Service does not offer a

coordinate reference system, in which the web mapping application is configured. Some

middle-ware has to be established between the map application and the server, which will

transform the images from server coordinate reference system to the one accepted by the

client.

Proxy4ows is a server script, which is between the client mapping application and OGC OWS

server (WCS, WFS or WMS). It is transforming OGC WMS request types from the client,

into WCS or WFS requests, so that the target server can accept them. On the way back, it

downloads the data distributed by the server (raster or vector), creates image and sends it back

to the client.

It also transforms the GetCapabilities request-response pair, so that the (WMS) client can deal

with it.

As result, data is processed on the server, into the form, common web browser mapping

application are able to display without big demands on system resources.




07 March 2013 84 of 44

Figure 71 WFS invoking scheme

HSlayers.Layer.WCS and WFS are derived from Layer WMS. As proxy between the client

(the map) and the WFS|WCS server, OWSProxy is placed. OWSProxy transforms WMS

requests coming from the client into WFS|WCS calls and also responses are transformed to

WMS responses or images, displayable in the web browser.

Proxy4ows can also deal with OGC WMS service in the way, that it transforms the coordinate

reference system of the original service into the client-preferred one in the case the server

does not support the coordinate system of the client. The resulting image is usually slightly

distorted, but displayable.

Proxy4ows is written in the Python programming language. The following libraries are used: MapServer 4:

MapServer is the core of Proxy4ows. Proxy4ows generates the Map object configuration

and after that dispatch method of MapServer is used, which deals with the request,

downloads all necessary data from servers and generates the resulting image.

From the client-point of view, it is used for working directly with vector data (deals as

OGC WFS client). GDAL/OGR 5

GDAL is used for reading OGC WFS and OGC WCS service metadata, so that the WMS

response from Proxy4ows to the client, has all of the necessary information.

While for OGC WFS service, MapServer is directly acting as a client, OGC WCS is

configured as GDAL data source.

Also for WMS transformation service, WMS interface of GDAL is used, as it is able to

deal with tiled requests, preserving the large dataset exceptions issue. OWSLib 6

OWSLib is Python library, which acts as OWS client. With the help of OWSLib, metadata

of particular target services are being collected easily.

Once again: Proxy4ows acts as WMS server to the client and acts as WFS, WCS or even

WMS client to the target server. GetCapabilities

When a GetCapabilities request arrives from the client, Proxy4ows checks for an existing

cached directory with mapfile, or creates a new one, if it doesn’t exist.

4http://mapserver.org

5http://gdal.org

6http://sourceforge.net/apps/trac/owslib/wiki




07 March 2013 85 of 44

GetMap

When a GetMap request arrives, an image is generated based on the previously generated

mapfile, using OWSDispatch method. At this point, a WFS filter is applied, if the target

server is WFS.

In both cases, Proxy4ows is looking for existing MapServer MapFile (it creates one, if it does

not exist) and lets MapServer do the work. Proxy4ows takes care of the proper MapFile

configuration.

Figure 72 Get Map Scheme

When a WMS GetCapabilities request arrives, OWSProxy generates a MapFile with list of

layers, corresponding to either feature types (WFS) or coverages (WCS) of the target service.

For configuring the MapFile properly, GDAL, OGR and OWSLib libraries are used.

WFS Layers are configured, using MapServer as WFS Client, while WCS layers are using

GDAL as WCS Client.

Then MapFile is generated, OWSDispatch method is called and the Capabilities response

arrives.




07 March 2013 86 of 44

Figure 73 OWS Dispatch

When the WMS GetMap request arrives, OWSProxy finds the existing MapFile (creates it

anew, if it does not exist) and performs OWSDispatch function of MapServer, which

generates the output image and sends it back to the server.

Invocation

Proxy4ows was originally designed as a WMS server. But it can also be used as WFS or WCS

server, so that it can only transform original data into a coordinate system unsupported by the

target server. Therefore, the client can use basically any type of OWS request using proper

parameters. In addition to this, two more parameters will have to be appended to the request

URL:

• owsservice notes the target server service type (WCS, WFS or WMS)

• owsurl is the URL of original server

FILTER ENCODING FILTERING WFS LAYERS

Filter Encoding is an Open Geospatial Consortium standard20

defining the syntax of

expressions used to filter data provided by the geospatial web services. It describes a rich

predicate language that enables to filter data based on their IDs, type-specific properties,

geospatial properties, and to combine filters using logical expressions, call server-defined

functions, encode arithmetical expressions and more.

Filter Encoding is defined in XML. Often it is referred to as FE or FES, with S standing for

'Standard' or 'Specification'.

FE Examples:21

Simple comparison filter can look like that:

20 http://www.opengeospatial.org/standards/filter 21 All the examples in here are using FES 1.1.0, unless specified otherwise




07 March 2013 87 of 44

<Filter>

<PropertyIsLessThan>

<PropertyName>DEPTH</PropertyName>

<Literal>20</Literal>

</PropertyIsLessThan>

</Filter>

Example 1. Spatial filter can, among other things, define a polygon that the desired features should

overlap:

<Filter>

<Overlaps>

<PropertyName>Geometry</PropertyName>

<gml:Polygon

srsName="http://www.opengis.net/gml/srs/epsg.xml#63266405">

<gml:outerBoundaryIs>

<gml:LinearRing>

<gml:posList> ... </gml:posList>

</gml:LinearRing>

</gml:outerBoundaryIs>

</gml:Polygon>

</Overlaps>

</Filter>

Example 2. Logical filter allows to combine filters:

<Filter>

<And>

<PropertyIsLessThan>

...

</PropertyIsLessThan>

<Overlaps>

...

</Overlaps>

</And>

</Filter>

Example 3. More examples can be found in the Filter Encoding standard.

FILTER ENCODING AND WFS

Filter Encoding was originally designed as part of the Web Feature Service standard, but then

it was separated into a standalone document as it can serve also for filtering of other services,

such as Web Coverage Service, Gazetteer or Web Registries .

When filtering data is provided by Web Feature Service, several WFS operations are involved:

GetCapabilities

As a part of GetCapabilities response, Filter_Capabilities of the server are announced. This




07 March 2013 88 of 44

section specifies the filter capabilities of the particular server. It can look as follows:

<ogc:Filter_Capabilities>

<ogc:Spatial_Capabilities>

<ogc:GeometryOperands>

<ogc:GeometryOperand>gml:Point</ogc:GeometryOperand>

<ogc:GeometryOperand>gml:LineString</ogc:GeometryOperand>

<ogc:GeometryOperand>gml:Polygon</ogc:GeometryOperand>

<ogc:GeometryOperand>gml:Envelope</ogc:GeometryOperand>

</ogc:GeometryOperands>

<ogc:SpatialOperators>

<ogc:SpatialOperator name="BBOX"/>

<ogc:SpatialOperator name="Equals"/>

<ogc:SpatialOperator name="Disjoint"/>

<ogc:SpatialOperator name="Intersect"/>

</ogc:SpatialOperators>

</ogc:Spatial_Capabilities>

<ogc:Scalar_Capabilities>

<ogc:LogicalOperators/>

<ogc:ComparisonOperators>

<ogc:ComparisonOperator>LessThan</ogc:ComparisonOperator>

<ogc:ComparisonOperator>GreaterThan</ogc:ComparisonOperator>

<ogc:ComparisonOperator>LessThanEqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>GreaterThanEqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>EqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>NotEqualTo</ogc:ComparisonOperator>

<ogc:ComparisonOperator>Like</ogc:ComparisonOperator>

<ogc:ComparisonOperator>Between</ogc:ComparisonOperator>

</ogc:ComparisonOperators>

<ogc:ArithmeticOperators>

<ogc:SimpleArithmetic/>

<ogc:Functions>

<ogc:FunctionNames>

<ogc:FunctionName nArgs="1">SIN</ogc:FunctionName>

<ogc:FunctionName nArgs="1">COS</ogc:FunctionName>

<ogc:FunctionName nArgs="1">TAN</ogc:FunctionName>

</ogc:FunctionNames>

</ogc:Functions>

</ogc:ArithmeticOperators>

</ogc:Scalar_Capabilities>

<ogc:Id_Capabilities>

<ogc:EID/>

<ogc:FID/>

</ogc:Id_Capabilities>

</ogc:Filter_Capabilities>

Example 4. DescribeFeatureType

Properties that can be used to filter features of a specific type are advertised in the response to

the DescribeFeatureType request. In the example below, four properties can be used to filter




07 March 2013 89 of 44

the features of the type location: DEPTH, SURFACE, AREA and CODE.

<complexType name="locationType">

<complexContent>

<extension base="gml:AbstractFeatureType">

<sequence>

<element name="msGeometry" type="gml:SurfacePropertyType" minOccurs="0"

maxOccurs="1"/>

<element name="DEPTH" type="Integer"/>

<element name="SURFACE" type="Character"/>

<element name="AREA" type="Real"/>

<element name="CODE" type="Character"/>

</sequence>

</extension>

</complexContent>

</complexType>

Example 5. GetFeature

When the filter capabilities of the server are known as well as the properties of the particular

feature type, the filter can be created following the FE standard. Consider the filter from

Example 1, this time extended with the namespaces. It selects all the features whose DEPTH

property is less than 20. To the GetFeature request the FILTER parameter is added and the

filter is provided as the value:

http://localhost/cgi-

bin/ows?REQUEST=GetFeature&VERSION=1.1.0&SERVICE=WFS&TYPENAME=locatio

n&FILTER=<ogc:Filter

xmlns:ogc="http://www.opengis.net/ogc"><ogc:PropertyIsLessThan><ogc:PropertyName>D

EPTH</ogc:PropertyName><ogc:Literal>20</ogc:Literal></ogc:PropertyIsLessThan></ogc:

Filter>

Example 6. In the HABITATS Geoportal, Filter Encoding is used to filter WFS layers. To do it, first add a

WFS layer to your map. Then right-click on the layer name in the Layer Switcher and select

Filter:




07 March 2013 90 of 44

Figure 74 Geoportal, Filter Encoding

The filter window appears with a form for simple comparison filter. From the first drop-down

list select a property that will be used for filtering (these have been parsed out from the

DescribeFeatureType response). From the second drop-down list select the operator that will

be used. (The list of available operators has been parsed out from the GetCapabilities

response.) In the text field the value to compare it with is entered. Click 'Apply' and the layer

will be filtered.




07 March 2013 91 of 44

Figure 75 Filter Encoding

Implementation of the Filter Encoding is shown on the following illustration:

Figure 76 Filtering of WFS

The processing works as follows:

WFS layers are displayed as WMS in the HSLayers Web Client (see Proxy4ows for details).

1. WFS GetCapabilities request is sent directly to the WFS server. Capabilities document is

parsed and filter capabilities are saved.

2. WFS DescribeFeatureTypes request is sent directly to the WFS server. Reply is parsed and

properties of the feature type are saved.

3. User creates the filter in the GUI, saved information from steps 1-2. is used.




07 March 2013 92 of 44

4. User-created filter is written to FES and new WMS request is sent to Proxy4ows,

accompanied with the filter in an additional parameter.

5. Proxy4ows takes the filter, creates new WFS request involving the filter, and sends it to the

WFS server. Server replies with filtered layer.

6. Proxy4ows transforms the returned WFS layer to WMS and sends it to the client.

WPS INVOKING

In HSLayers, a new class WPSClient was introduced. The class implements generic OGC

WPS client with graphical user interface. HSLayers WPSClient performes GetCapabilities

request on the server and creates a list of available processes. Processes are rendered into a

drop-down menu. When a user chooses the process he wants to run, DescribeProcess is called.

Based on ProcessDescription response, a generic input form is generated. After all input data

is specified, and when users click the button, an Execute request is called, and when it is

finished, an execute response is parsed and outputs of the form are filled.

Complex input and BoundingBox input are relatively easy to be implemented. Writing the

complex data handler in the web environment is a real challenge. Generic HSLayers WPS

Client. Form is generated automatically.

Figure 77 WPS Invoking

First, input is identified as raster or vector. Then, the map layers are scanned and

HSLayers.Layer.WCS (for rasters) HSLayers.Layer.WFS and OpenLayers. Layer.Vector (for

vectors) are identified and added to the drop-down select box. The Custom URL option is

attached, for custom raster or data link pasting (e.g. for direct WFS or WCS request) and, if

the input data shall be vectors, also Custom drawings option is added, so that the user can

define some geometry on the map by hand.

When an Execute request is called, HSLayers collects URLs for HSLayers.Layer.WFS or

HSLayers.Layer.WCS with GetFeature or GetCoverage request types – the client is not

sending the data, but only reference to the data (which is possible according to OGC WPS).

HSLayers.Layer.WFS and HSLayers.Layer.WCS are special types of layers, used in

HSLayers. They are based on OpenLayers.Layer.WMS class, but they are not working with

WCS or WFS server directly, but communicating via server-side proxy called Proxy4ows




07 March 2013 93 of 44

22[6] (more on other place). Proxy4ows is sitting between the client (generic web browser)

and the server (WCS or WFS) and is transforming the requests and responses into a form that

can be handled in the web environment. GeoTIFFs are transformed into PNG and JPEGs,

GML's are transformed into picture (PNG) form. Using this approach, there is virtually no

limit to the amount of features, which can be displayed in the client or any image format

issues.

Figure 78 Proxy

HSlayers.Layer.WCS and WFS are derived from Layer WMS. As a proxy between the client

(the map) and the WFS|WCS server, Proxy4ows is placed. Proxy4ows transforms the WMS

requests coming from the client into WFS|WCS calls and also the responses are transformed

to WMS responses or images, displayable in the web browser.

Features in vector layers (which are handling vector data, not raster representation) are

transformed into the format, desired by the user, according to the server-supported MimeType

(this is very vague estimation, see above). Usually this is GML and the data are then sent to

the server as part of the XML-encoded request.

When a response arrives, HSLayers WPSClient does prefer reference to output data, so it can

be handled more easily (as Reference=True). When vector data are send back (usually in

GML format), they are added to the map as features of OpenLayers.Layer.Vector. The GML is

parsed using OpenLayers tools. Direct link for downloading is also provided. Raster data

(usually GeoTIFFs) are only available for downloading.

Client does not send a direct link to the original WFS or WCS server, but the link to

Proxy4ows. One of key features of Proxy4ows is, that it ensures the data it is providing will

22

http://redmine.ccss.cz/project/owsproxy




07 March 2013 94 of 44

be in the same projection as the web mapping application.

Further development is moving towards a closer usage of already described Proxy4ows.

Raster and Vector data will be stored on the HSLayers-server and client will consume their in

web browser usable rasterized form (PNG image).

GetCapabilities and DescribeProcess are parsed directly with OpenLayers tools. For the

Execute request with complex data, a reference to Proxy4ows is used. The WPS Server gets

reference to Proxy4ows and not to the original server, because Proxy4ows makes sure,

resulting data will have the same coordinate reference system as the map application has.

As a result, HSLayers does contain a generic OGC WPS 1.0.0 version client. The client is

capable to parse capabilities, to generate automatically from based on ProcessDescription

response and is able to submit Execute requests and to parse the response.

It works with raster and vector data displayed in the mapping application. It is also possible to

submit external dataset (using URL). The result can either be added to the map or can be

downloaded and storeed on the local hard drive.

The displaying of output vector or raster complex data is only limited. If e.g. GeoTIFF is

returned back as a result, it can be only downloaded. Proxy4ows will be modified, so it does

accept GeoTIFF file and produces PNG out of it.

The development of the input form, based on ProcessDescription document, needs to be more

robust. Also the literal value type of data needs to be controlled according to input type

(integer, string, date, ...).

Even some patches based on this are already accepted in OpenLayers, a more robust

WPSExecute patch will be prepared and submitted into OpenLayers code base.

HSLAYERS SOS CLIENT

The SOS client in HSLayers is a component which can be used for browsing data from any

OpenGIS Sensor Observation Service (OGC SOS) compliant services. The component can be

used together with map application based on HSLayers, or independently with any non map

application.

Th actual version of component supports only operations from OGC SOS Core Profile which

must be implemented in every OGC SOS compliant services.

Operations supported in the actual version are:

• GetCapabilities - returns a service description containing information about the service

interface and the available sensor data

• DescribeSensor - returns a description of one specific sensor, sensor system or data

producing procedure

• GetObservation - provides pull-based access to sensor observations and measurement-

data via a spatio-temporal query that can be filtered by phenomena and value constraints

Future versions of components will contain also operations from OGC SOS Enhanced Profile

and will offer more functionality for working with data from OGC SOS services.

How does it work

• User invokes HSLayers SOS Client UI dialog

• User inputs URL of required OGC SOS

• HSLayers SOS Client sends GetCapabilities request to OGC SOS, parses its response

and displays available information about OGC Service (name, abstract) in UI




07 March 2013 95 of 44

• User selects offering and all parameters for required observations (procedure, observed

property, date-time interval)

• User invokes getting observations

• HSLayers SOS Client sends GetObservation request with all passed parameters to OGC

SOS, parses its response and display all obtained data in table and chart

• If HSLayers SOS Client is used within map application based on HSLayers, user can

displays location of obtained observations in map

Figure 79 HSLayers SOS client

HSLAYERS EMBED COMPONENT

HSLayers contains the component Embed for inserting map into any HTML pages. User can

create a map in a Geoportal or in any map application which is based on HSLayers and




07 March 2013 96 of 44

contains the Embed component. Users can also define parameters which affect how the map

will be look in the target HTML page.

There are three types of a resulting inserted map window:

• Pure HTML – this type is based on pure HTML and does not contain any other UI

components

• Simple ExtJS – this type uses ExtJS library for generating UI container

• Advanced ExtJS – this type uses ExtJS library also as Simple ExtJS type and also

contains another UI components (tree with list of all layers in map)

The HSLayers Embed component consists of several parts on the client and on the server side.

• Embed Generator – this part is responsible for displaying the UI form to enter the

parameters affecting the resulting inserted map window. When the user enters all

required parameters, the actual map is serialized and sent to the Status Manager on the

server. The Status Manager is an external service which is responsible for saving

actual state of any component and getting it back later.

• Embed Client – this part is responsible for rendering map windows in target HTML

page in dependence on parameters entered by user.

• Embed Script – this part is responsible for rendering main HTML part of map

window and for calling Embed Client in target HTML page.

Figure 80 HSLayers Embeded

Generating HTML code

1. User invokes UI to enter the parameters of inserted map window.

2. User inputs parameters affecting map window (type of map window, size of window).

3. Embed Generator serialize actual map and send it to Status Manager.

4. Status Manager returns URL for later accessing state of actual map (when it will be

rendered in target HTML page).

5. Embed Generator returns complete HTML code. User can paste this HTML code to

any HTML page.




07 March 2013 97 of 44

Figure 81 Rendering Map

Rendering map window in target HTML page

1. Target HTML page renders initial JavaScript code which creates new IFRAME

element. URL of this IFRAME element is set to Embed Script and contains all

parameters.

2. When IFRAME is activated, the Embed Script is called. The Embed script generates

the main part of HTML code for IFRAME. This HTML code contains references for

all required JavaScript files and Cascade Style Sheets (CSS) files. These files are

different in dependence on type of map window.

3. HTML code in IFRAME calls the Embed Client for creating the map window.

4. Then it reads the state of the map from the Status Manager and restores the complete

map from this state.

MOBILE SOLUTIONS FOR RL

Massive mobile technologies growth during last few years brings brand new view on GIS

technologies. Location based services and spatial information comes to everyday life for

everybody. It is a big challenge for classical GIS technologies. New areas of applications

reveals for wide community of users.

The INSPIRE and mobile mapping apps infrastructure differs in many thing in philosophy,

application area and technical solution. (table 2).




07 March 2013 98 of 44

Features INSPIRE Existing mobile map apps

Formats,

protocols

Based on heavy formats (SOAP,

GML, WFS, WCS, CSW, …)

Lite formats (JSON, KML, GeoSMS)

Standardization Standardized services (OGC, ISO) Proprietary services (Google, Apple)

Projections European (LAEA, LCC, …) Universal (Spherical Mercator)

Users For “experts” - government, EU

comission

For “ordinary people”

Application area Environment, administrative Navigation, entertainment

Difficulty Difficult to use Easy to use

Open system Open possibilities of view

different maps

Bind with proprietary (licensed) maps

Typical app Map portal Single purpose map app (e.g.

navigation)

Network traffic heavy Optimized for slow networks

On-line / off-

line

On-line Mixed, e.g. caching tiles on device

Unsaid purpose European real estate market Big brother ? / advertising

Table 2 Comparison of INSPIRE solutions and current mobile solutions

The challenge is how to connect both these worlds. INSPIRE may bring many useful data for

everybody to mobile apps (e.g. cadastral maps), on the other hand ease of use and low costs

may be challenge for experts for specialized apps, e.g. data capture and other field work. So

we need to build some bridges for mobile apps to access INSPIRE infrastructure. On other

hands social networks and mobile apps may contribute SDI with user data (e.g. illegal dumps,

water quality monitoring, …).

Android “Google maps” (used in Irish pilot) application is limited for use (maps licensing,

proprietary formats), so we looed for alternative which enables users to support more

functionality.

For Reference Laboratory we choose popular tourist app Locus

https://play.google.com/store/apps/details?id=menion.android.locus.pro&feature=more_from_

developer#?t=W251bGwsMSwyLDEwMiwibWVuaW9uLmFuZHJvaWQubG9jdXMucHJvIl

0 ). Because of primary application area, it is widespread (500 000-1 000 000 installations

worldwide) and it has very rich functionality given by log-term development based user

community discussion. It provides published API which enables control the application from

other apps and write own extension. We developed these extensions to enable work with

INSPIRE infrastructure

• Catalogue client

• Cadaster info

(https://play.google.com/store/apps/details?id=cz.hsrs.parcelinfo&feature=search_result#?t=W

251bGwsMSwxLDEsImN6LmhzcnMucGFyY2VsaW5mbyJd )

• Online feature editing (not published yet)

With using these tools typical work flow may look this way:

1. User opens the map and zoom to his location than presses catalogue client button

2. Catalog client opens with selected coordinates. Alternatively user may edit the

coordinates and enter other search criteria

3. After pressing search button the result list is displayed




07 March 2013 99 of 44

4. User may see metadata detail on next screen

5. If the corresponding service is available on-line, the map button enables to go to Locus

app and show it on the map. The GetFeatureInfo and GetLegendInfo operations are

also supported.

Figure 82 Locus map app, Catalogue client




07 March 2013 100 of 44

Figure 83 WMS displayed in Locus app, map legend

Cadastral info application is based on cadastral map WMS and WFS provided by Cadastral

office of the Czech Republic. It enables see property information and search for cadaster

parcels in the map

Figure 84 Parcel Info app




07 March 2013 101 of 44

Using KML as common format

The KML is another OGC format not used in INSPIRE now. The advantage of KML over

WFS is

• Common use in Google Map apps (desktop and mobile)

• Adoption in other software (Geoserver, Mapserver, ESRI, OpenLayers, Locus…)

• Scalability, simple implementing of time series etc…

• Symbology may be wrappend together with data

• Using of W3C CSS rather than OGC SLD for symbology

KML may be used as common format for mobile apps rather than INSPIRE supported

formats. There are two ways how to implement it:

1. Direct support of servers as alternative to WFS/WMS (Geoserver)

2. Thru conversion modules which on-fly transform provided WFS/WMS/SLD to KML

When KML is available, it is compelling to register it the same way in catalogue as other

services with services metadata. Than it may be searched and displayed simple way.

Figure 85 KML metadata in the catalogue client




07 March 2013 102 of 44

Figure 86 Displaying KML in Google Maps and Locus

Field editing

Big mobile apps advantage is possibility to capture field data simple way and low cost.

Because lack of mobile signal coverage in some areas or no mobile internet account, several

alternatives form mobile data captures should be taken into account:

• Off-line editing. Data are stored on device, posted to server when connection is

available or manually at home.

• On-line editing - when internet connection is available.

• SMS – when no mobile internet is available and quick response is required.

All of these alternatives will be probably combined depended on application in real life.




07 March 2013 103 of 44

Figure 87 Simple mobile editing application

Figure 88 Filed editing results displayed online in Google Earth as KML




07 March 2013 104 of 44

9 Processing workflow MANAGEMENT

The objective of this chapter is to provide information about available orchestration and

workflow management tools. It also explains the tool functionalities and possibilities to

integrate and use with HABITATS services for complex chained service orchestration and

deployment.

Orchestration environment

We assume that we will use Open Geospatial Consortium (OGC) compliant Web Processing

Service 1.0.0. standard services provided by GeoServer WPS extension, 52north WPS

solution and byWPS as input sources in orchestration and work flow management.

Another assumption is that in the future different service chaining will be able to be developed

also by non technical and IT highly skilled personnel.

Workflow Management System

Workflow Management System (WMS) is a piece of software that provides an infrastructure

to setup, execute, and monitor scientific workflows. In other words, the WMS provide an

environment where in experiments can be defined and executed.

An important function of a WMS during the workflow execution or enactment is the

coordination of operation of individual components that constitute the workflow – the process

also often referred to as orchestration.

As research becomes more data-intensive and more reliant on the use of computers, larger

volumes of experimentation data are recorded quicker and with greater precision. This trend

has spurred a significant increase in the complexity of scientific simulation software. Many

tools only perform a small well-defined task, thus necessitating that several of them are joined

in a pipeline to model a useful experiment.

Additional difficulties arise from the need to deal with the incompatible data formats that

various services produce or consume. It is evident that considerable amount of computer

science knowledge is required to overcome the outlined problems. However, domain scientists

across disciplines do not have sufficient relevant expertise.

Scientific workflows and WMSs have emerged to solve this problem and provide an easy-to-

use way of specifying the tasks that have to be performed during a specific in silico

experiment. The need to combine several tools into a single research analysis still holds, but

technical details of workflow execution are now delegated to Workflow Management

Systems.

Business Process Execution Language

Business Process Execution Language (BPEL), short for Web Services Business Process

Execution Language (WS-BPEL) is an OASIS standard XML based executable language for

specifying actions within business processes with web services. Processes in Business Process

Execution Language export and import information by using exclusively web service

interfaces. It defines a set of basic control structures like conditions or loops as well as

elements to invoke web services and receive messages from services. BPEL's messaging

facilities depend on the use of the Web Services Description Language (WSDL) 1.1 to

describe outgoing and incoming messages. Message structures can be manipulated, assigning

parts or the whole of them to variables that can in turn be used to send other messages.




07 March 2013 105 of 44

ENGINES AND WORK-FLOW MANAGERS

To make tests we collected several workflow execution engines and managers. From the

collected engines the biggest part is using BPEL and only one of the solutions is oriented on

data flow execution.

Apache ODE

� Name: Apache ODE + Eclipse Plugin

� Version: 1.3.5

� Platform: Java

� Standards: WS-BPEL 2.0

� Vendor: Apache Software Foundation, OASIS

� Licence Apache ODE: Apache Software License (ASL), version 2.0.

� Licence Eclipse BPEL: Incubation phase, version 0.5

� Homepage: http://ode.apache.org/

Apache ODE (Orchestration Director Engine) executes business processes written following

the WS-BPEL standard. It talks to web services, sending and receiving messages, handling

data manipulation and error recovery as described by your process definition. It supports both

long and short living process executions to orchestrate all the services that are part of your

application. ODE comes with easy to use web-based management interface (Figure 1).

Ode can be deployed in three different environments:

� As a simple Web Service in Axis 2, ODE is bundled in a WAR than can be deployed in

any application server and is invoked using plain SOAP/HTTP.

� As a JBI service assembly, ODE is bundled in a ZIP that can be deployed in any JBI

container and is invoked using the NMR.

� SMX4 OSGi bundle

Figure 89 Apache ODE

Orchestra

� Name: Orchestra




07 March 2013 106 of 44

� Version: 4.7.1

� Platform: Java

� Standards: WS-BPEL 2.0

� Vendor: OW2 - Object Web

� Licence: LGPL 2.1

� Homepage: http://orchestra.ow2.org/

Orchestra is a complete solution to handle long-running, service oriented processes. It

provides out of the box orchestration functionalities to handle complex business processes. It

is based on the OASIS standard BPEL.

In Orchestra server is bundled with web based workflow management Console.

Figure 90 Orchestra

Taverna Server

� Name: Taverna Server

� Version: 2.2a1

� Platform: Java

� Standards: -

� Vendor: myGrid, OMII-UK

� Licence: LGPL

� Homepage: http://www.taverna.org.uk/

Taverna Server enables you to set up a dedicated server for executing workflows remotely.




07 March 2013 107 of 44

Server is using workflows designed by Taverna Workbench. The Server exposes REST and

SOAP APIs; either can be used to access the functionality of the Server.

As demonstration manager the Taverna Demonstrator interface is used written in Ruby

language. The demonstrator is simple GUI to manage workflow execution and can be used as

inspiration for custom and more complicated workflow management solution development.

(Figure 3) Taverna Demonstrator can not be used in a production environment.

Figure 91 Taverna

Workflow designers

An integral part of orchestration engines and workflow managers are designers to prepare

executable workflow documents.

52°North WPS Workflow Modeller and Orchestration API

• Name: 52°North WPS Workflow Modeller

• Version: WPS 2.0-RC6, Revision 1647

• Platform: independent, language Java

• Vendor: 52north

• Licence: GPL

• Homepage: http://52north.org/

The open source software initiative 52°North is an international network of partners from

research, industry and public administration. Its mission is to foster the development of new

concepts and technologies in Geo-informatics through a common innovation process.

All software developed within this collaborative development process is published under an

open source license.




07 March 2013 108 of 44

The 52°North partners have a long and outstanding record in the Geo-IT domain. They are

actively contributing to the development of international standards, e.g. at W3C, ISO, OGC or

INSPIRE.

The Geoprocessing community aims at designing a pluggable web service architecture for

orchestrating and executing geo-processes, as well as researching innovative spatio-temporal

data analysis processing techniques.

The WPS Workflow Modeller allows the visual modelling of geoprocessing workflows. In a

lightweight Browser environment, WPS services can be easily chained and equipped with

literal or complex data inputs from i.e. other OGC services such as WFS.

This graphical WPS Workflow Modeller is based on the WPS Orchestration API which allows

the programmatically chaining of WPS in a very straight forward manner.

The work was has been conducted in cooperation with Sejong University through funding

from the Seoul R&BD programme (10540)

The Workflow Modeller uses a standard Openlayers implementation to visualize input and

result layers (Figure 4). Along with this standard implementation comes the default controls

for panning and zooming as well as a layer switcher to turn on/off overlay layer and to select

base layers (see section 1.1). In the following the specific functions of the Workflow Modeller

to interact with the map are described.

Figure 92 Workflow modeller

ECLIPSE BPEL

� Name: Eclipse BPEL

� Version: WS-BPEL 2.0

� Platform: independent, language Java

� Vendor: The Eclipse Foundation

� Licence: Eclipse Public License (EPL)

� Homepage: http://www.eclipse.org/bpel/

BPEL Project adds comprehensive support to Eclipse for the definition, authoring, editing,

deploying, testing and debugging of WS-BPEL 2.0 processes. WS-BPEL (Web Services

Business Process Execution Language), or BPEL, is a vendor-neutral specification being




07 March 2013 109 of 44

developed by OASIS to specify business processes as a set of interactions between web

services.

The goal of the BPEL Project is to add comprehensive support to Eclipse for the definition,

authoring, editing, deploying, testing and debugging of WS-BPEL 2.0 processes. WS-BPEL

(Web Services Business Process Execution Language), or BPEL, is a vendor-neutral

specification being developed by OASIS to specify business processes as a set of interactions

between web services. By providing these tools, this project aims to build a community

around support for BPEL in Eclipse.

The implementation will be extensible to third-party vendors in a number of ways. The editor

will be extensible to support new activity types, property pages for extensibility of existing

constructs, an extensible palette, and product-specific branding capabilities. The runtime

deployment framework will be extensible so that third parties may add support for a variety of

runtime engines. The model will support extensions to provide new activities or attributes, and

the validator will allow for validation of these extensions.

The Key Features are:

� Designer. A GEF-based editor that provides a graphical means to author BPEL

processes (Figure 5).

� Model. An Eclipse Modelling Framework (EMF) model that represents the WS-BPEL

2.0 specification.

� Validation. A validator which operates on the EMF model and produces errors and

warnings based on the specification.

� Runtime Framework. An extensible framework which will allow for deployment and

execution of BPEL processes from the tools into a BPEL engine.

Figure 93 Eclipse BPEL




07 March 2013 110 of 44

HUMBOLDT Workflow Design and Construction Service

� Name: HUMBOLDT Workflow Design and Construction Service

� Version: svn


� Short description

� Vendor: NATURE-SDI project

� Licence:

� Homepage: http://community.esdi-humboldt.eu/wiki/5

The HUMBOLDT Workflow Design and Construction Service consists of two sub-systems, a

graphical user interface, called the Workflow Editor, allowing users to compose geo-

processing components into workflows. Second, a web service, called the Workflow

Repository Service, that accepts requests for workflows and delivers them to clients (in

HUMBOLDT, the Mediator Service).

Basic Functionality of the WDCS:

� Allow users to visually compose the workflow graph out of geo-processing

components (out of WPS / java processes / WSDL?) and data sources

� Manual Workflow Definition, Automated Execution

� Allow users to register processes to the system

� Exports such workflows in different workflow dialects via a WSDL / SOAP interface

(priority: the dialect used by the HUMBOLDT Mediator Service)

� Help the user in the composition process, by:

� type checking inputs and outputs when connecting

� type checking user entered input values

� Some small graphical features that make the composition process easier

The Graphical User Interface of the WDCS, called the Workflow Editor, can be used by users

to register processing components and to specify chains / compositions of such components

(i.e. workflows). The GUI offers therefore quite a similar functionality as e.g. the GUI of the

ArcGIS Model Builder or a BPEL Workflow Designer but additionally provides assistance to

the user in the composition process by e.g. comparing the input/output type definitions of the

components to be connected. For example, this prevents users from connecting components

processing raster data with processing component accepting vector data and hence reduces the

risk of runtime errors when executing the composition. Currently, the processes to be

composed can either be exposed as OGC WPS Processes or directly implemented in java and

accessible to the HUMBOLDT Mediator Service.

The Workflow Editor acts as a client application to the Workflow Repository and allows users

to deploy the workflows such that they will be subsequently offered via the web service

interface of the Workflow Service.

The geo-processing workflows to be built with the Workflow Editor follow the structure of

dataflow graphs, a well-know concept in software engineering. A dataflow graph is a graph G

= (V,E) with V=GD being a set of nodes and E= (D×GG) a set of directed edges. G is the set

of processing nodes associated with computational components, in the case of the workflow

editor, geo-processing components. D is the set of data-providing nodes associated with data

providing components. A directed edge E connects a node associated with a data providing or

computational component to another computational component. In case a computational

component has multiple inputs (often called input ports), there can be multiple edges pointing

to it, each one associated with a different input. In case a processing node has multiple outputs

or the output shall be pushed as input to multiple input ports of a single or multiple other

processing nodes, several edges from such a processing node might exist.

The computational components represented by the nodes G in a dataflow graph are required to




07 March 2013 111 of 44

be function-like in the sense that they generate the same output given the same input and do

not depend on some changing states (such as a global variable that is not a direct parameter).

Further, the direct edges represent the dataflow between nodes. A node in a dataflow graph

can be “executed”, if the data of all other input nodes that provide the input via a dataflow

edge is available. Due to the function-like nature of the processing nodes, the outcome of a

whole dataflow graph of such components is determined solely by the input passed to it and

can therefore be treated similar as a simple or atomic node and composed.

Figure 94 Humboldt Workflow Design

This project collects the HUMBOLDT Service Integration Framework sub-projects,

specifically:

� the Mediator Service (MS), a harmonization work-flow execution engine,

� the Workflow Construction and Design Service (WDCS), an harmonisation needs

analysis and workflow construction component,

� the Model Repository (MR), a conceptual schema and mappings repository,

� the Context Service (CS), a service for managing product descriptions for

transformation results and

� the Information Grounding Service (IGS), a bridge component to existing catalogue

services.

Taverna Workbench

� Name: Taverna Workbench

� Version: 2.2


� Vendor: myGrid, OMII-UK

� Licence: LGPL

� Homepage: http://www.taverna.org.uk/

Taverna is an open source and domain independent Workflow Management System – a suite




07 March 2013 112 of 44

of tools used to design and execute scientific workflows and aid in silico experimentation.

Taverna has been created by the myGrid team and funded through the OMII-UK. The project

has guaranteed funding until 2014.

The Taverna suite is written in Java and includes the Taverna Engine (used for enacting

workflows) that powers both the Taverna Workbench (the desktop client application, Figure 7)

and the Taverna Server (which allows remote execution of workflows). Taverna is also

available as a Command Line Tool for a quick execution of workflows from a terminal.

Taverna allows you to define how your data flows between the services, without having to

worry how you are going to invoke these services. It will automate and pipeline processing of

data.

Figure 95 Taverna Workbench

Suite of tools to design, edit and execute workflows

� Workflow design and execution in Taverna Workbench

� Command line execution of workflows

� Remote execution of workflows on a Taverna server

� Invoke workflows from the Internet

Wide range of services and extensible architecture

- Service discovery

- Various service types available: WSDL-style and RESTful Web services, BioMart,

BioMoby, SoapLab, R, Beanshell, Excel and csv spreadsheets, pyWPS

- Service creation for external tools or Java libraries

- Extensible service plug-in architecture for adding new service types

Secure

� Support for secure services

� Secure management of users’ credentials

Versatile Workbench




07 March 2013 113 of 44

� Tabs for finding, designing and executing workflows

� Fully graphical workflow design

� Drag and drop workflow components

� Comprehensive undo/redo

� Built-in help facility

� Annotations for describing workflows, services, inputs, outputs

� Workflow validation and debugging

Create your own or start from existing workflows

- Easy design of new workflows

- Load existing workflows (from a disk, myExperiment or a URL)

- View workflow layout and logic

- Modify existing workflows

- Load workflows in off-line mode (when disconnected from the Internet)

- Nested workflows (sub workflows)

- Workflow validation during design time for debugging while composing a workflow

- Built-in detection when a service’s interface changes or a service go off-line during

design time

Find workflows created by others and share yours

� Full myExperiment search options for browsing workflows

� Publish workflows on myExperiment for use by others

Execute and debug your workflows

• Execute workflows

• Remember previously used workflow inputs

• Save workflow input values used to a file

• Load workflow input values from a file

• Pipelining and streaming of data

• Implicit iteration of service calls

• Conditional and repeated calling of services

• Customizable looping over a service

• Failover and retry of service calling

• Parallel execution and configurable number of concurrent threads

• Improved error handling and reporting for debugging during run time

• Monitor workflow execution

• Pause/resume or cancel workflow execution

• Manage previous runs and workflow results

• View intermediate results and debug workflows at run time

• Filter and save intermediate and final workflow results

Track workflow runs and results

• Record workflow execution provenance

• Review provenance of previous workflow runs

10 HABITATS Pilots’ Network Services

HABITATS deals with 7 pilot implementations in different regions of Europe and the different

regions use different technologies. The objective of HABITATS is to demonstrate the sharing

of data among such heterogeneous solutions. D4.1 indicates that SDI tools can be applied in




07 March 2013 114 of 44

HABITATS on the basis of analysis of user needs and user scenarios, the project plans to

define a set of application independent services (GENESIS model of Generic services) and

interactions of these services for concrete pilots.

D4.1 gives a good overview of current regulations, trends and recommendations coming from

research projects, as well as information on how different commercial and voluntary

initiatives can be integrated. From the analysis it is clear that INSPIRE is a minimum set,

which has to be taken into consideration, for the HABITATS architecture, allowing each pilot

to work with its own methods and technologies, while adhering to the conditions of the

INSPIRE Directive concerning:

• Metadata

• Interoperability of spatial datasets and services

• Network services

• Data sharing

• Monitoring and reporting

For the (i) Metadata, (ii) Network Services, (iii) Monitoring and (iv) Reporting INSPIRE has

published first implementing rules. The rules for the second and fourth have been published

recently. The metadata for HABITAT’s four themes must wait until 2012. With these

conditions the HABITATS pilots must build their SDIs and successfully share their data. The

first step for all pilots is to create metadata for their data and services. The second important

step may be to prepare some network services, following the ISO and OGC recommendations

for data specifications and data sharing, and then complete them when the implementing rules

will be published. The model of D4.1 and the other examples inside it show the way to build

the HABITATS infrastructure.

Experiences from different European projects demonstrate that the INSPIRE architecture is

not enough for implementation of real practical pilot applications. Some basic architecture

principles and also basic generic architecture are very similar. The analysis demonstrates, that

it is important for pilot implementations to analyse user needs and describe these needs by

Use Cases. Concrete Use Cases can define changes in concrete architecture. Integration of

commercial and voluntary services can also increase functionality in applications such as

tourism.

Experiences from other projects demonstrate the advantage when the first level architecture is

designed as an independent platform and then concrete components are selected for

implementation. There exists a large list of basic components, both proprietary and Open

Sources.

According to the HABITATS user-driven approach to standardisation, the full impact of

results will be sparked off by the pilot service scenarios and their ability to attract new

participants to the communities of adoption. Each of the HABITATS pilots is therefore built

on:

a) existing concrete services currently carried out by project partners,

b) potentials of data access through network services and

c) enhancement through usage scenarios developed by user communities, in order to

meet the three HABITATS criteria of relevance, openness and responsiveness.

Much of the success of this will be based on cross-regional Services and data access. The




07 March 2013 115 of 44

pilots, as described in the DoW, fall into the following trans-regional categories:

1. Management of natural resources

o Wild Salmon Monitoring (IE)

o La Palma Protected Marine Area (ES)

2. Eco-tourism

o Hiking Trip Planner (IT)

o Soria Natural Reserve (ES)

3. Economic activities

o Sheep and Goat Herd Management (IT)

o Economic activity at marine coastal benthic habitats (LV)

4. National policy

o Czech National Forest Programme (CZ)

While D2.4.1 identified the following trans-regional groupings.

1. Potential benefits of user involvement influence data modeling and standards adoption.

• Wild Salmon Monitoring (IE)

• Economic Activity of Marine HABITATS (LV)

• Forest Management (CZ)

2. Direct expert/end-user interaction with a data modeling process.

• Monitoring Protected Marine Area (ES)

• Environmental Education in a Natural Reserve (ES)

3. User-driven co-design of services leading to “demand pull” INSPIRE adoption.

• Hiking Trip Planner (IT)

• Sheep and Goat Herding Management (IT)

D2.4.2 found that all Pilots have much to be learned, shared and potential for collaboration

with the other Pilots particularly with regard to common pan-European data themes and

sources on (i) Tourism, (ii) Education and (iii) Environmental Conservation/Management.

Each of these validation pilots relies on trans-regional and trans-European data sharing

between pilot settings, within INSPIRE networks present in the project and with collaborating

members of the HABITATS User Communities.

Pilot actors include stakeholders participating in the management of platforms, data owners

and producers and contributors to services and user groups of all pilots. D4.2.1 tabulates the

generic use cases from the pilots, as well their user groups and generic roles. From these it

identifies that the services based on external data in HABITATS requires the following basic

operations:

• Data discovery

• Storage metadata about services on server

• Data visualisation

• Data download

PILOTS DESCRIPTIONS

WILD SALMON MONITORING

MAC works with the Irish Marine Institute (www.marine.ie) at its Aquaculture and Catchment




07 March 2013 116 of 44

Management Facility in Newport, Co. Mayo, Ireland

(www.marine.ie/home/aboutus/organisationstaff/serviceareas/ACMS.htm), focusing on the

monitoring and analysis of wild salmon stock dynamics. Wild salmon data that have been

collected by the Marine Institute is accessible to provide better intelligence to researchers,

fishermen and decision makers on salmon conservation, so that they can better manage the

wild-salmon resource in a sustainable manner and help prevent the extinction of wild salmon

in rivers on the North Atlantic coast of Europe Irish Marine Institute collects and owns the

data, but collaborates with other Marine Institutes and the North Atlantic Salmon

Conservation Organisation. The service to be piloted package and provide that data as better

intelligence to researchers, fishermen and decision makers on salmon conservation.

Also MAC focused the Irish HABITATS pilot on the wider communities’ identification,

reporting, and recording for subsequent eradication of AIS instances as they relate to salmon

and all inland and coastal native fish species conservation in Ireland and Europe, by

developing a phone app and system that involves the wider communities through awareness,

using social media, crowd-sourcing and open map-based geo-data for the identification,

reporting, and recording for subsequent eradication of AIS.

The HABITATS AIS Phone App is easy to download from the Google Play Store and use.

Figure 96 Aquatic Invasive Species

It empowers everyone to record an instance of an Aquatic Invasive Species with an user-ID,

photograph, text report, time and GPS location on their smartphone, with guidance and advice

on how best to record and photograph each sighting.

Figure 97 Aquatic Invasive Species App




07 March 2013 117 of 44

The App also shows a map of the previous verified AIS sightings to foster each user’s social

networking/community building, with a link to the IFI Facebook site, to allow users

tell/discuss with their friends about their sightings and use of the App.

To increase awareness of AIS and the threat that they pose, the App includes much on-phone

information and images of aquatic invasive species, with advice and plans on aquatic

biosecurity for anglers and fishermen in particular (as their practices can have a huge impact

on the spread of AIS).

Figure 98 AIS classification

When a sighting is reported, it is verified and the AIS classified on a private Management

Console space at www.habitats.ie by IFI researchers and experts.

Figure 99 Integration with RL




07 March 2013 118 of 44

Figure 100 AIS sighting

Once the AIS sighting and classification is verified, it is automatically uploaded and recorded

as a point for display on an OGC-compliant layer of IFI’s ESRI/ArcGIS Viewer. Each point is

colour coded to indicate its status, such as eradication action taken and reports on the results

achieved, for subsequent feedback to all stakeholders.

The process of transferring the data to the IFI GIS format for monitoring and reporting, allows

the exploration of the INSPIRE/metadata aspects (e.g. using the HABITATS Metadata profile

adapted to HB V2 Data Spec, use of EUNIS, etc) that HABITATS aims to provide best-

practice recommendations for the INSPIRE habitats-related themes, as they pertain to salmon

and other inland and coastal fish species.

Figure 101 Ireland Pilot architecture

This architecture allows an open transfer to other applications and pilots as follows:




07 March 2013 119 of 44

Figure 102 Publishing

• The back-end (blue items) can be reused and transferred for any App.

- To run on MAC’s existing Server or be transferred to another Server (such

as Madonie Park)

• The App structure can be reused if it follows the same generic process

- find something on a list

- record it by its location and an uploaded picture.

- for instance the Active Hiker App in Madonie Park.

The Irish Pilot’s architecture allows its data to be published using WMS and WFS services

using GeoNetwork and GeoServer on the Irish Portal at www.habitats-ireland.eu, to make the

HABITATS services discoverable and usable by external platforms.23

LA PALMA PROTECTED MARINE RESERVE

The pilot takes place in the La Palma Protected Marine Reserve in the Canary Islands.

However, harmonization and standardization of this kind of data and making them available in

a national or European level is considered to be useful for any coast area with similar

problematic. When using sensors and in order to make it simple for our purpose, the coast

area of this PMA has been divided into two subareas that is defined as open sea (not more

than 600 m from the coast) and border sea. With the same criteria, indicators that we will take

into account will be: biological parameters or physical-chemical parameters and only the three

among the most relevant ones will be taken for each one of the subareas.

23

KML may also be adopted later, see http://en.wikipedia.org/wiki/Keyhole_Markup_Language




07 March 2013 120 of 44

Figure 103 Sea Monitoring

The use of images and voice recognition systems have been studied when the human

intervention is needed. All these data is georeferenced in cartographic maps.

The main stakeholder involved in the development of this pilot is TRAGSATEC. Some other

collaborators are companies manufacturing sensors and developing voice, fishermen, diving

clubs, hotels, farmers, etc. Its business model is based in the service funded & extended by

public agency responsible for PMAs in Spain.

The pilot scheme that is:

Figure 104 La Palma Pilot Scheme




07 March 2013 121 of 44

In this pilot there were obtained data from a sensor system and from a sensor connector we

store these data in a database. This first database is a SQL DBMS in the form of tables and the

relationship among the data is also stored in tables.

From these tables, the representative geodata were got in shapefile format. The platform to

publish these data is composed by Geoserver, Geonetwork with PostgreSQL. This platform

works with WMS, WFS, WCS and CSW standards and allows View and Discovery services.

The download service has been deployed for the shapefiles and the results of the

harmonization through the ESRI software. The metadata profile was filled with CatMDEdit.

The viewer done in FLEX allows us to do pan, zoom, change the numeric scale, add favourite

views, switch off/on layers, change the opacity of the layers, add external layers (currently

only WMS), check the layer info, situation minimap, table of contents, hide/show, etc. The

URL to the geoportal is http://habitatspre.tragsatec.es/visorhabitats/ .

Figure 105 La Palma portal

In the catalogue section we can search more layers, watch the metadata and use the metadata

editor if we have got the permission access.




07 March 2013 122 of 44

Figure 106 La Palma metadata

We are working to allow the addition of elements metadata themes to the metadata profile. It

is really hard and it’s generating bugs in the Geonetwork catalogue. Also we are migrating

from version 2.6.3 to 2.6.4.

Currently we use Geoserver 2.0.2 that serve WMS 1.1.1 but we are migrating to Geoserver

2.2. that allows WMS 1.3 and it’s completely INPIRE compliant.

Part of work was focused on publishing the spatial data in other formats like WFS or KML.

Lately we are working with NSI to develop a Business Intelligence platform based in

SpagoBI.

MADONIE HIKING TRIP PLANNER

This pilot is situated inside the Madonie Park, Sicily (Italia), but could be widely replicable

throughout the Mediterranean. The Park Authority developed a multimedia repertory of many

of the park’s main features – including both natural elements and places of traditional farming

and herding – and, in the context of on-going initiatives, developed an interactive multimedia

map of the area that allows hikers to plan visits as a function of the natural elements to see.

The validation pilot in HABITATS integrates habitats-related data into this map, to allow to

view bio-geographical regions within the park. In addition, use of mobile platforms (where

coverage is available) is a great tool.

Finally, the currently planned facility allowing for users to upload multimedia content and

insert comments and suggestions are enhanced to validate the possibility for users to insert

content through the SDI. The possibility to signal sightings of different species (i.e. through

digital photos with time date and location stamp) also is being integrated.

This pilot makes significant use of the information in the regional Carta Natura database, and

also access databases from other regions in order, for example, to compare habitats in

different geographical contexts.




07 March 2013 123 of 44

MADONIA SHEEP AND GOAT HERDING MANAGEMENT

In the Madonie Park, over 1,500m is dominated by the Madonie Forest while lower down the

slopes, the locals continue to pursue millennial agricultural activities including sheep and

cattle farming and the cultivation of wheat, olives and fruit. This gives rise to specific

traditions such as the seasonal “transumanza” when herds are moved from their summer to

winter pastures and back, and contributes to the Madonie’s gastronomic specialties of meat,

sausages, salami, cheese, olives, mushrooms, and fresh seasonal vegetables.

Also the pilot is coherent with the Park’s mission but is also an element of the TLL-Sicily

partnership’s innovation piloting strategy.

Figure 107 Madonia Architecture

In order to go toward a system “INSPIRE compliant” is necessary to make people, at Madonie

Park, works in a way useful to realize some INSPIRE instances (such as metadata definition,

organized way to archive data (both spatial and non-spatial, use of data located on a remote

server accessible by web services, publication of web service for data locally managed).

The scheme of work of this pilot is like it:




07 March 2013 124 of 44

Figure 108 Madonia implementation

Some activities on data regarding both two pilot projects have been carried out:

� Data conversion for existing database (conversion of format, native SRS to

UTM-WGS84 zone 33);

� Georeferencing of non-spatial data (data in pictorial format);

� Vector format acquisition and database structuring;

� Definition of thematic data structure – according to GEMET (

http://www.eionet.europa.eu/gemet/inspire_themes ) - useful to allocate data

sets.

� Selection of some hiking paths available in vector format (shapefiles);

� Selection of waypoints to be superimposed to path (also for selection by

queries);

� Acquisition of management plan of the park area;

� Definition of path and geographic objects representation (symbols useful to

represent land structure, infrastructures present in the park, etc.);

� Acquisition of grazing plan from paper maps or .pdf files;

� Structuring and filling the database for grazing plan;

� Definition of new layer based on the way adopted for the assignment of

grazing area to each shepherd or breeder (work in progress);

� Definition of an agreement between Sicily Region Administration and Madonie

Park by which metadata of new dataset will be published on Geoportal of

Sicily Region at ARTA Sicilia, while data should remain available for the

access, by web services, on the site of Madonie Park WEBGIS Application

(work in progress);




07 March 2013 125 of 44

� Some adaptation work in order to made data set suitable to be accessed as web

service;

� Selected data in raster and/or vector format moved inside a thematic structure

in order to easily manage of find them;

� In this preliminary stage only one platform has been put up with the main goal

to interact with staholders speaking on tangible example. This WEBGIS is

based on MapServer + Pmapper 4.0 and operates:

� with a typical WEBGIS interface the will be the final interface only for the

pilot on Sheep and Goat Herd Management;

� on data sets regarding both two Pilot Projects;

� on data sets made available from Inspire GeoPortal of ARTA Scilia (Sicily

Region Land and Environmet Administration);

� web services on local data-sets are to be published.

AUGMENTED REALITY NATURAL RESERVE

The strength of the pilot is that if a standardization of the data and metadata modelling for this

kind of environmental tourism is defined, some other standards will appear for the specific

hardware that is needed for its representation and the idea of environmental tourism could

equally be developed in the whole Europe.

The objective of this pilot have been to develop a system that, using real nature information

and adding metadata to real images (texts, images, sounds, etc.), allows improving

environmental tourism with a real respective nature observation. Introducing interpretation

information and augmented reality we will particularly protect fragile areas.

There were developed two ways in the Augmented Reality:

� Augmented reality device on a outdoor stage

Figure 109 Augment Reality Technology

� Augmented reality app for Android




07 March 2013 126 of 44

Figure 110 Android App

This technology works for us as the following way:

Figure 111 Augment Reality Scheme

Some aspects must be clear:

� The data model depends on the themes that we choose to show in the

augmented reality.




07 March 2013 127 of 44

� We must work only with graphic data (spatial data)

To do that we have used the following tools:

� Proprietary software based on Android for mobile.

� Proprietary software based on Linux for the augmented reality device.

� ArcGIS software to process data.

� GeoServer to publish our spatial data.

The initial working schema of this pilot is like it:

Figure 112 Augment Reality Implementation

The View service must be process through our Augmented Reality software to be displayed in

the AR devices and mobile phones. From these platforms we could work to implement the

Web 2.0 for the users. The data was processed in shape format. There were launched the

platform also in Geoserver with the Geonetwork software to get a catalogue. With this

platform we have created WMS services and the metadata profile.

As metadata editor was used the Geonetwork catalogue. The ISO 19115 and ISO 19139 are

the standards to comply the INSPIRE mandatory profile.

The address to access to geoportal is http://habitatspre.tragsatec.es/visorRa/ .




07 March 2013 128 of 44

Figure 113 Pilot portal

As the above pilot, in the catalogue section we can search more layers, watch the metadata

and use the metadata editor if we have got the permission access. Anyway, the metadata

profile was filled with CatMDEdit. Also the download service has been deployed for the

shapefiles and the results of the harmonization through the ESRI software.

Figure 114 Pilot Metadata

Currently we use Geoserver 2.0.2 that serve WMS 1.1.1 but we are migrating to Geoserver

2.2. that allows WMS 1.3 and it’s completely INPIRE compliant.

We are working to allow the addition of elements metadata themes to the metadata profile. It




07 March 2013 129 of 44

is really hard and it’s generating bugs in the Geonetwork catalogue. Also we are migrating

from version 2.6.3 to 2.6.4.

Additionally the possibility to download the shapefiles exists in the Download section.

And finally we uploaded the app for Android devices to the Google Play (Android market).

Everybody can install the app for free.




07 March 2013 130 of 44

ECONOMICAL ACTIVITY AT MARINE COASTAL BENTHIC HABITATS

IMCS cooperate with the Latvian Institute of Aquatic Ecology using the monitoring data of

coastal benthic communities and related environmental parameters. The needs and

requirements of various stakeholders are researched and afterwards IMCS pilot the use of

advanced interfaces to improve presentation, accessibility and use of the data. It will help in

decision making for port construction measures, fisheries policy, wind mill development

actions in order to use the benthic habitats in sustainable way. The benthic habitats in Latvian

coastal waters are the areas with highest biological diversity and partly included covered by

NATURA 2000 territories.

The architecture of the Latvia Coastal HABITATS pilot is designed in this way:

Figure 115 Coastal HABITATS pilot is design

The work with data and meta-data is the following:

� Data

� For OGC WMS,WFS services uses MapServer

� As default web client is used modified OpenLyers but can be replaced

by any other client (e.g. HSLayers, MapFish);

� As desktop data management tool is used QuantumGIS that can be

replaced by any other desktop solution;

� As main database is used PostgreSQL with PostGIS;




07 March 2013 131 of 44

� Meta-data

� For metadata it uses the meta-data system Micka.

� Meta-data system in use is (http://geoportal.tdf.lv )

Some sources of these data to build a base dataset have provided only from one organization

(biotopes, water bodies, monitoring data, Natura2000), the Latvian Institute of Aquatic

Ecology.

Figure 116 Latvian Pilot Implementation




07 March 2013 132 of 44

Figure 117 Latvian portal

Also the basic requirements for Web Processing Service (WPS) content was formalized.

Regarding the meta-data for datasets, a ISO19115 compliant form has been created in Latvian

and English language.

Implementation of INSPIRE requirements in Latvia is gradual and motivation to be involved

depends on the pressure by Directive/respective national legislation.

Figure 118 Processing services

The basic requirements for Web Processing Service (WPS) content are being formalized and

the WPS implementation is in progress. Service implementation is according OGC standard.




07 March 2013 133 of 44

The end user web application can use in background WPS, but interface and usage for end

users must follow KISS principle.

For economic activity decision by running WPS the following information is needed:

� Natura 2000.

� Other important national sites with restrictions.

� Military zones.

� Traffic, transportation and communication infrastructure areas

� Depth data (depth over -30m is not economically reasonable and supported),

� Distance form coastline\, it is possible to be calculated using coastline and

choosed location data.

� Ice in winter.

� Identified areas with allowed buildings but with strict identification of type and

purpose.

The conclusions are:

� We have OGC service (WMS, WFS) platform based on MapServer.

� The spatial data were collected from available data. They are harmonized by

corresponding theme.

� Meta-data profile preparation in meta-data system Micka is in progress by HS-

RS.

� Based on HABITATS meta-data profile created first Latvian pilot data meta-

data descriptions. Since HABITATS profile is not implemented in our meta-

data system meta-data are describe in ISO standard since HABITATS and

INSPIRE profiles are subset from ISO.

� View and download services are working.

� And we have got a web based platform.

NATIONAL FOREST PROGRAMME

Scenarios from NFP centres are coordinated with border cross countries. Metadata, geometric

and semantic harmonisation of multiple representations and different sources of geodata are

concentrated according to GMES.

Simple scheme for the First use case - "Forest site classification data for sustainable

management and utilization of forest road network" is displayed bellow:




07 March 2013 134 of 44

Figure 119 FMI pilot scheme

FMI has a long experience with MapServer, so this experience and the know-how will be

developed further. However, we have huge data warehouse, which need to be restructured.

Metadata for all datasets in Use case 1 has been created and will be placed on both geoportals:

the National and the HABITATS portals.

The pilot can offer:

� Datasets for HABITATS reference laboratory

� WMS service

� Validated metadata (available both in English and Czech language)




07 March 2013 135 of 44

Figure 120 OPRL Data

There were urdates data models to be suitable for new technologies. Nowadays our

stakeholders are using our geoportal (http://geoportal2.uhul.cz/wms_oprl?SERVICE=WMS)

with only WMS service and not quite so interoperable client, which has serious problems

across different browsers. Geoportal client side uses modified Openlayers and on the server

side is working UMN mapserver.

There were tested software architectures with Geonetwork/Geoserver and Geohosting/Micka

and both are more or less suitable for our purposes. The FMI uses LDAP authentication

protocol for all Microsoft and Unix desktop clients, therefore administrative part of the

geoportal should have the same login backend




07 March 2013 136 of 44

11 Interoperability and invocation tests

Interoperability and Enabling Services

D4.2.1 identified that the following interoperability and enabling services that will be required

in HABITATS:

• Discovery - provides the access to HABITATS and external metadata to users or to other

system components. It implements search/discovery services, thus exposes catalogue

services.

• View - view services perform the rendering of “generic data” (catalogue entry, map

image,…) into an output format that will be delivered to the user through the “horizontal

service” and then through the application services.

• Data services - implements view and download services, thus exposes map/feature

services.

• View: view services allow display, navigate, zoom in and out, pan or overlay

viewable spatial data sets and display legend information and any relevant content

of metadata.

• Download: download services allow extracting copies of spatial data sets, or parts

of such sets, to be downloaded and, where practicable, accessed directly24

.

• Transformation is designed to carry out the mapping between the application schemas of

HABITATS and the application schemas of the data provided by the partners.

• Analysis - implements transform services (as per D3.5 – INSPIRE Network Services

Architecture v2.0), thus exposes map/feature transform services.

• Monitoring - as basic tools will be established monitoring based on logins of users. A full

log analysis will be provided:

• External services - Discovery, view, data, transformation, analysis, authorization and

authentication services can be implemented as internal, or can be used as external services

coming from remote servers. Interfaces are the same as for internal services.

• Applications - The geo-portal is not tools for standard users. For most users there are

important applications. The idea of the HABITATS architecture is to ensure that

Applications are not developed as independent proprietary solutions, but are composed

from existing services, using the HABITATS RL portal infrastructure.

• Applets – are programs written in the Java programming language that can be included in

an HTML page, much in the same way as an image is included in a page. When a user

uses a Java technology-enabled browser to view a page that contains an applet, the applet's

code is transferred to their system and executed by the browser's Java Virtual Machine

(JVM).

• Servlets - is a Java class in Java EE that conforms to the Java Servlet API, a protocol by

which a Java class may respond to HTTP requests. They are not tied to a specific client-

server protocol, but are most often used with this protocol. A Servlet is an object that

receives a request and generates a response based on that request.

• Portlets - are pluggable user interface software components that are managed and

displayed in a web portal. Portlets produce fragments of markup code that are aggregated

into a portal .

• WMC - Web Map Context (WMC) describes how to save a map view comprised of many

24

From D3.5 – INSPIRE Network Services Architecture v2.0




07 March 2013 137 of 44

different layers from different Web Map Servers.

• RSS/GeoRSS - RSS (most commonly expanded as Really Simple Syndication) is a family

of web feed formats used to publish frequently updated works—such as blog entries, news

headlines, audio, and video—in a standardized format. An RSS document (which is called

a "feed", "web feed", or "channel") includes full or summarized text, plus metadata such

as publishing dates and authorship. Web feeds benefit publishers by letting them syndicate

content automatically.

• KML/KMZ - Keyhole Markup Language (KML) is an XML schema for expressing

geographic annotation and visualization within Internet-based, two-dimensional maps and

three-dimensional Earth browsers.

• CMS - A content management system (CMS) is the collection of procedures used to

manage work flow in a collaborative environment. These procedures can be manual or

computer-based. The procedures are designed to do the following:

◦ Allow for a large number of people to contribute to and share stored data

◦ Control access to data, based on user roles (defining which information users or

user groups can view, edit, publish, etc.)

◦ Aid in easy storage and retrieval of data

◦ Reduce repetitive duplicate input

◦ Improve the ease of report writing

◦ Improve communication between users

• Social Networks and Media - Social media are media for social interaction, using highly

accessible and scalable publishing techniques. Social media use web-based technologies

to turn communication into interactive dialog. A common thread running through all

definitions of social media is a blending of technology and social interaction for the co-

creation of value.25

• Workflow management - A workflow consists of a sequence of connected steps. It is a

depiction of a sequence of operations, declared as the work of a person, a group of

persons, an organization of staff, or one or more simple or complex mechanisms.

Workflow may be seen as any abstraction of real work.

3.2 HABITATS “Quick Prototyping” Service Applets

During phase 2 of the project, the pilots implemented “quick” and “light” on-demand applets

to meet the validation pilot expectations and user needs. These “Quick Prototyping” service

applets will run within the HABITATS service architecture and will be developed on-demand.

They include:

• Discussion forums with the ability to pre-set data layers on map views

• Timeline services to visualize the evolution of spatial phenomena over time

• Transformation and harmonisation services

• Tools for sharing data and services

• Services for the bottom-up introduction of spatial data by local citizens and businesses

and validation by the relevant local authorities

• Other specific components supporting participatory and social innovation processes.

25

http://en.wikipedia.org/wiki/Social_media




07 March 2013 138 of 44

The interoperability tests IMCS RL

During project validation phase we provide tests of discovery, visualization and analysis of

data from IMCS pilot. The focus was on usage of IMCS harmonized data services in

HABITATS reference laboratory together with additional pilot data and provide integration

with additional Pan European Data as Natura 2000, Corine Land Cover and OSM data.

Figure 121 Harmonised data publishing on RL

IRISH TEST WITH RL

The Irish data of invasive spices was published using Geoserver as WMS and KML and was

tested using the RL.

The following show views of the data as it appears on the HABITATS RL Geoportal.




07 March 2013 139 of 44

Figure 122 Invasive species on RL

Figure 123 Invasive species on RL

LA PALMA RESERVE MARINE PILOT TEST WITH RL

The data of La Palma Reserve Marine, bathymetry, sample points, marine area, reserve

marine, and land use, using Geoserver as WMS was tested using the RL.




07 March 2013 140 of 44


http://www.habitats.cz/view?permalink=44b2ad495fd262b365f8fdb5310a1458

AUGMENTED REALITY NATURE RESERVE PILOT TEST WITH RL

The data used in the Augmented Reality Nature Reserve pilot, surface waters, species

distribution, buildings, and geographical names, using Geoserver as WMS was tested using

the RL.




07 March 2013 141 of 44

Figure 125 The screen capture shows the data as it appears on the HABITATS RL Geoportal: http://www.habitats.cz/view?permalink=8555142bd2d6f5462d4f766015bc4776

FMI LIBEREC REGION TEST OF REFERENCE LABORATORY

Region Liberec decided to use and implement HABITATS Reference Laboratory for the

purpose of environmental management and risk protection services in region. Liberec region

with assistance of HSRS implement RL on their servers and provided customisation of RL for

their own purposes. There were implemented full operational services based on RL.

As second part of experiment, the harmonised data from Forest Management Institute was

used for the purpose of forestry protection policies in Liberec region

Liberec Geoportal includes standard RL Geoportal components.




07 March 2013 142 of 44

Figure 126 Liberec Basic portal functionality

But geoportal include set ot thematic maps based on Geoportal functionality and

implementation of WMC standards

Figure 127 Liberec Thematic Maps using standardised data from FMI

Sets of applications solving crises management, protection of citizens, environment protection

etc.




07 March 2013 143 of 44

Figure 128 Flood portal as part of Geoportal

And also materials for education and awareness

Figure 129 Education and awareness

For this solution, there are two important facts. There were applied Living Lab and Open

Innovation methodology, applied methods of HABITATS design and development (Liberec

Geportal is implementation of HABITATS Reference Laboratory Concept) and main

important fact is, that the content is prepared by non-programmers, specialist on Environment.

In next chapter the general principles of HABITATS development and architecture will be

explain

EXPERIMENTATION WITH OPEN LINKED DATA

As test for interlinked Open Linked data was design testing application, which tries to collect

as much as possible data sets, process them to acquire relevant information and present the

information in intelligible and simple way. The information are collected from many




07 March 2013 144 of 44

information resources (with open or free access to data) and transformed to the common data

structure (with own schema taken account of metadata related to original source and time

information) based on Extensible Markup Language (XML) format. The collected information

are evaluated according to importance and reliability of particular resources. The original data

are transformed to uniform data set with using XSLT (Extensible Stylesheet Language –

Transformation) templates and open-source Saxon-HE processor. Users get the most relevant

information, including links to original sources and a possibility to compare it with other

collected data. Data is presented as the KML (Kyehole Markup Language) file of ski resorts

(including information derived from the input sources) and web pages in HTML (Hypertext

Markup Language) 5 format connected to other features such as map or graph components.

The application uses ECMA script libraries such as Google Chart Tools or RGraph.

Figure 130 Integration of Open Linked data from skiing resorts




07 March 2013 145 of 44

12 Conclusions and Recommendations

This report presents the status of the work of HABITATS towards Networking Services and

Invoking tools. HABITATS Networking Services are a series of specific networking service

applets deployed and tested for data sharing within the project. The set of services was

implemented on the HABITATS Reference Laboratory (RL) geoportal platform, which is

described in detail. These include both interoperability services and enabling services, such as

the

• visualisation of information layers,

• overlay of information from different sources,

• spatial and temporal analysis etc.

The set of HABITATS Networking Services has been implemented on the HABITATS

Reference Laboratory (RL) geoportal platform. This acted as a client of the seven HABITATS

pilots and provides a very rich set of cross-pilot, inter-regional and enabling services and tools

that were validated by users on the basis of concrete implementations in phase 2 of the

project. The applets for specific applications were developed in response to user requests at

each pilot during phase 2 of the project.

The following cross-pilot themes are identified, where common sharing of data and

networking services will be important to all of the HABITATS pilots:

1. Tourism – pan-European search for data

2. Education

3. Environmental Conservation and Management

The HABITATS RL provided the common services and tools, and acts as a clearing house for

such data, based on cross pilot use cases. The following functionality was required and was

developed for use in phase 2 of the project.

� Connected different catalogue

� Harvest metadata from catalogues

� Multi search for catalogues

� Discovery data

� Upload and download data

� Publish data

� Prepare data composition

� Harmonise data

� Provide transformation to other type of services

� Generate iFrame with pre prepared maps for re use on other portals (with well

defined API)

� Light WordPress based Social portal

� Mobile catalogue clients

� Mobile applications

� Augment reality tools

From the testing, we can conclude, that for broader utilisation of SDI on local and regional

level it is necessary to go beyond the frame of the current INSPIRE Networking Services and

Invoking tools specification. The current INSPIRE based solutions are not sufficient for local

and regional users. It leads in some cases to a negative view by local stakeholders on




07 March 2013 146 of 44

INSPIRE implementation. The HABITATS RL and pilots demonstrate such an approach and

the result is infrastructure, which is accepted by users’ communities. It is necessary to

continue in such way. The HABITATS experimentation demonstrates, that in the case, that we

are able to extend the current concept of INSPIRE, the services and toolkits could help in the

everyday lives of local and regional users.

On other hand HABITATS demonstrates, that most of current GIS Web based solutions are

until now poor applications; they are not building on the principle of services. This concept

doesn’t give the possibility to take full advantage of SDI. Proprietary applications are often

based on data replication and don’t support integration of distributed services. Spatial data is

used only in one application and it is a problem to use them in another Web or desktop

applications. This application based system doesn’t allow building new types of service and

really open SDI. Such a way will in the future make life easier for all developers, system

providers and also users.

But on the other hand it is an important fact. Current INSPIRE (but also GEOSS and partly

GMES) architectures are mainly focused on development of Geoportals. But a normal user

doesn’t need Geoportals, which are only a framework for experts, allowing them to build

solutions for final users. We have to change the concept of Geoportals to being a tool, that

support the building of new levels of “applications”. It has to be applications that use all of the

advantages of existing SDI. It is important to design methods, which allow building of service

orientated solutions. And it is also important, not to be only so called “GIS centred”, but to

build a new generation of applications combining geospatial and non-geospatial information,

in line with the initial intentions of SISE. So we tried in HABITATS to introduce a new

generation of applications which fully benefit from SDI:

• service based – with limiting data replication, re usage of existing components.

• supporting integration with other systems

• supporting also integration with social networks

The main extension, which was demonstrate by HABITATS are:

• To extend the classical three layer architectural model of HABITATS, by two new

levels – application and presentation layers

• To support building of user applets, which could be easily modified by non-specialist?

This idea is in line with current activities of the Future Internet

• Not to be focused on standard geospatial data and services, but also support initiatives

related to Open Linked Data, which could bring new quality into existing SDI

applications.

• Mobility, smartphones and tablets will probably be the main interfaces in the future for

accessing SDI generally, and concretely the INSPIRE infrastructure.

• Social Networks and Media has to be integrated with SDI

• As the way for easy integration of heterogeneous data the KML format should be

considered.




07 March 2013 147 of 44

13 References

1. D2.2.1 HABITATS User Communities, CIP- ICT-PSP-2009-3-250455, Social Validation

of INSPIRE Annex III Data Structures in EU HABITATS

2. D2.3.1 HABITATS State of Art, Scenarios and Requirements, CIP- ICT-PSP-2009-3-

250455, Social Validation of INSPIRE Annex III Data Structures in EU HABITATS

3. D2.4.1 & D2.4.2 HABITATS Impact Assessment, CIP- ICT-PSP-2009-3-250455, Social

Validation of INSPIRE Annex III Data Structures in EU HABITATS

4. D3.1 HABITATS Conceptual Data Models, CIP- ICT-PSP-2009-3-250455, Social


5. HABITATS, CIP- ICT-PSP-2009-3-250455, Social Validation of INSPIRE Annex III Data

Structures in EU Habitats, D-3.2a – HABITATS - 250455

6. D3.2.1 & D3.2.2 HABITATS Metadata profile, CIP- ICT-PSP-2009-3-250455, Social


7. D3.3.1 & D3.3.2 HABITATS Data models, CIP-ICT-PSP-2009-3-2504553-250455, Social


8. D3.4.1 HABITATS Transformation Process, CIP-ICT-PSP-2009-3-2504553-250455,

Social Validation of INSPIRE Annex III Data Structures in EU HABITATS

9. D4.1 State-of-art of Existing SDIs, CIP-ICT-PSP-2009-3-2504553-250455, Social


10. D4.2.1 & D4.2.2 HABITATS INSPIRE Networking Architecture, CIP-ICT-PSP-2009-3-

2504553-250455, Social Validation of INSPIRE Annex III Data Structures in EU

HABITATS

11. D5.2.1 HABITATS Pilot Validation Platforms, CIP-ICT-PSP-2009-3-2504553-250455,

Social Validation of INSPIRE Annex III Data Structures in EU HABITATS

12. Description of Work, Social Validation of INSPIRE Annex III Data Structures in EU

HABITATS, 2009-10-16

13. Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007

establishing an Infrastructure for Spatial Information in the European Community

(INSPIRE)

14. http://java.sun.com/applets/

15. INSPIRE Network Services Drafting Team (2007), D3.5 – INSPIRE Network Services

Architecture v2.0

16. ISO (2005), ISO 19119: Geographic information – Services

17. ISO 19119 and OGC Service Architecture, George PERCIVALL, USA,

http://www.fig.net/pub/fig_2002/JS4/JS4_percivall.pdf

18. Open Geospatial Consortium Inc. (2004), Geospatial Portal Reference Architecture - A

Community Guide to Implementing Standards-Based Geospatial Portals

19. Open Geospatial Consortium Inc. (2004), OGC Web Map Service Interface

20. Open Geospatial Consortium Inc. (2007), OpenGIS Catalogue Services Specification

21. Percivall G. (2002), ISO 19119 and OGC Service Architecture¸ FIG XXII International

Congress, Washington, D.C., USA

22. Güting 2005: Ralf Hartmut Güting, Markus Schneider. Moving Objects Databases.2005,

ISBN 978-0120887996.

23. HABITATS DoW 2010: Description of Work, “Social Validation of INSPIRE Annex II

Data Structures in EU HABITATS”




07 March 2013 148 of 44

24. HABITATS D4.2.2 2011: D4.2.2 – INSPIRE Networking Architecture Design, 2011

25. HABITATS D4.3.1 2011: D4.3.1 – HABITATS networking services

26. ISO/IEC 10746-1 Information technology – Open Distributed Processing – Reference

model: Overview, ISO (1998)

27. TAVERNA 2011: Taverna, What is a Workflow Management System? Taverna home page

2011. (http://www.taverna.org.uk/introduction/what-is-a-workflow-management-system/).

28. Bregt, A., 2012. Cost-Benefit Analysis in Perspective.

29. Harris, T. & Lafone, F., forthcoming. Toward an informal Spatial Data Infrastructure:

Voluntary Geographic Information, Neogeography, and the role of citizen sensors. In O.

Čerba & K. Čerbová, eds. SDI, Communities, and Social Media.

30. Charvát, K., 2011. Social Validation of INSPIRE Annex III Data Structures in EU

Habitats.

31. Charvát, K. et al., 2008. Uniform Resource Management. In IST Africa. Windhoek,

Namibia.

32. Wikipedia contributors, 2012a. Authentication. Wikipedia, the free encyclopedia.

Available at: http://en.wikipedia.org/w/index.php?title=Authentication&oldid=508518815

[Accessed September 4, 2012].

33. Wikipedia contributors, 2012b. GeoRSS. Wikipedia, the free encyclopedia. Available at:

http://en.wikipedia.org/w/index.php?title=GeoRSS&oldid=503593540 [Accessed

September 5, 2012].

34. Wikipedia contributors, 2012c. RSS. Wikipedia, the free encyclopedia. Available at:

http://en.wikipedia.org/w/index.php?title=RSS&oldid=507169125 [Accessed September

5, 2012].

35. Jachym Cepicky, Pavel Gnip, Stepan Kafka, Irena Koskova and Karel Charvat Geospatial

data management and integration of geospatial web services, IAALD AFITA WCCA2008,

Tokyo.

36. INSPIRE Invoke Services 2009, Roberto Lucchi, Michel Millot, European Commission,

Joint Research Centre, Institute for Environment and Sustainability