Habitats d4.3.2 networking services and service toolkit final
-
Upload
karel-charvat -
Category
Technology
-
view
104 -
download
2
description
Transcript of 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
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 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
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 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
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 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
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 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 123 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
Figure 125 The screen capture shows the data as it appears on the HABITATS RL Geoportal:
http://www.habitats.cz/view?permalink=8555142bd2d6f5462d4f766015bc4776 ................ 141
Figure 126 Liberec Basic portal functionality ........................................................................ 142
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 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
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 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
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 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
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
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
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 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
Figure 122 Invasive species on RL ........................................................................................ 139
Figure 123 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
Figure 125 The screen capture shows the data as it appears on the HABITATS RL Geoportal:
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
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 10 of 44
Tables
Table 1 Testing WMS services results ...................................................................................... 61
Table 2 Comparison of INSPIRE solutions and current mobile solutions ............................... 98
3
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 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
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 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
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 13 of 44
• WMC – Web Map Context
• WMS – Web Service Map
• WPS – Web Processing Services
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 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
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 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.
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 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
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 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.
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 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.
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 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
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 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
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 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
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 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
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 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).
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 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
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 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
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 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
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 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.
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 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
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 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
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 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
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 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/
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 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
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 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
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 34 of 44
Figure 15 Customisation of RL II
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 35 of 44
Figure 16 Customisation of RL III
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 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.
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 37 of 44
Figure 18 WordPress Based RL User can add, delete and modify any type of geometry
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 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.
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 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
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 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
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 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:
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 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
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 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
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 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
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 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).
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 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.
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 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.
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 48 of 44
Figure 29 Editing of vector data
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 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.
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 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.
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 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.
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 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.
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 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.
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 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
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 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.
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 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. )
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 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:
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 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
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 59 of 44
Figure 43 Micka harvesting configuration
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 60 of 44
Figure 44 RSS channel – harvesting results
Figure 45 Heartbeat protocol
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 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.
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 62 of 44
Figure 46 Portal – metadata catalogue client
Figure 47 Mobile catalogue client
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 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.
Figure 49 Illustration of relation between ExtJS and OpenLayers libraries inside of HSLayers.
OpenLayers are used for their capabilities of geodata visualization, such as raster maps (JPEG,
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 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
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 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
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 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
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 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.
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 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
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 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.
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 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
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 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.
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 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
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 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.
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 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.
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 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.
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 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.
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 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
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 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).
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 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.
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 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.
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 81 of 44
Figure 67 WMS Sequence diagram.
Figure 68 WMS transformation result - left map coordinate system, right - transformed result
from EPSG:4326 source.
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 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
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 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.
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 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
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 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.
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 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
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 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
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 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
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 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:
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 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.
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 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.
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 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
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 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
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 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
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 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
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 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.
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 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).
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 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
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 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
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 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
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 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
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 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.
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 103 of 44
Figure 87 Simple mobile editing application
Figure 88 Filed editing results displayed online in Google Earth as KML
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 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.
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 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
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 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.
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 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.
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 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
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 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
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 110 of 44
HUMBOLDT Workflow Design and Construction Service
� Name: HUMBOLDT Workflow Design and Construction Service
� Version: svn
� Platform: independent, language Java
� 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
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 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
� Platform: independent, language Java
� 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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:
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 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
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 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
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 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.
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 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.
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 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:
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 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);
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 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
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 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.
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 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/ .
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 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
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 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.
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 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;
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 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
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 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.
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 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:
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 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)
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 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
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 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
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 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
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 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.
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 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.
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 140 of 44
Figure 124 The screen capture shows the data as it appears on the HABITATS RL Geoportal:
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.
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 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.
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 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.
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 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
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 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
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 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
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 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.
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 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
Validation of INSPIRE Annex III Data Structures in EU HABITATS
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
Validation of INSPIRE Annex III Data Structures in EU HABITATS
7. D3.3.1 & D3.3.2 HABITATS Data models, CIP-ICT-PSP-2009-3-2504553-250455, Social
Validation of INSPIRE Annex III Data Structures in EU HABITATS
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
Validation of INSPIRE Annex III Data Structures in EU HABITATS
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”
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 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