deliverable

3 downloads 3888 Views 28MB Size Report
Mar 7, 2013 - HABITATS Networking Services and Service Toolkits. Doc. ...... server. The file can be also downloaded to local hard drive. ...... data manipulation and error recovery as described by your process definition. It supports both.
European Commission Information Society and Media

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 RE CO

Public Restricted to a group specified by the consortium (including the Commission Services) Confidential, only for members of the consortium (including the Commission Services)

X

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

European Commission Information Society and Media

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. 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

Revision History Revision

Date

V1.0

Author

Organization

Description

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 European Commission DG Information Society and Media Address:

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

TABLE OF CONTENTS 1

FIGURES........................................................................................................................7

2

TABLES ........................................................................................................................10

3

INTRODUCTION .......................................................................................................... 11 Terms ................................................................................................................................ 11 Abbreviations ....................................................................................................................12

4

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

5

INVOKING SERVICES .................................................................................................15 INVOKING service requirements and recommendations...................................................16

6

PROBLEMS OF POLICY DRIVEN SDI .........................................................................18 Neogeography ..................................................................................................................19

7

HABITATS NETWORKING SERVICES ........................................................................20 Reference Lab ..................................................................................................................20 Uniform Resource Management (URM) Concept ..............................................................23

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

RL NETWORKING SERVICES AND INVOKING TOOLS..............................................28 Authorization and Authentication tools ..............................................................................30 Liferay based geoportal solution .......................................................................................31

Customisation of the portal content.................................................................................. 33 WordPress based GeoSocial Network ..............................................................................36 Uniform Resource Management (URM) ............................................................................39

MICKA ............................................................................................................................. 39 Geoserver.......................................................................................................................... 43 Data management ......................................................................................................... 43 Data visualisation ......................................................................................................... 44 Map compositions ........................................................................................................ 45 Data publication ........................................................................................................... 45 Styler............................................................................................................................. 46 Vector data editing ........................................................................................................ 47 Layer hierarchy and thematic maps.............................................................................. 49 Metadata Extractor ........................................................................................................... 51 Networking Services and Invoking ....................................................................................52

Catalogue Services ........................................................................................................... 52 Invoking of discovery services ..................................................................................... 55 Experiences with sharing of metadata in INSPIRE and GEOSS and Super Catalogue implementation ............................................................................................................. 56 Catalogues interoperabity problems ................................................................................................................. 56 Central catalogue implementation .................................................................................................................... 57 Testing Results ................................................................................................................................................. 61 Practical Results ............................................................................................................................................... 61 Plans for future ................................................................................................................................................. 63

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

Map ............................................................................................................................... 65 Layer Switcher ............................................................................................................. 66 Logical structure............................................................................................................................................... 67

07 March 2013

1 of 44

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

OWS ............................................................................................................................. 67 Printing with HSLayers ................................................................................................ 68 Web Map Context ........................................................................................................ 70 Permanent link .............................................................................................................. 73 Embedded ..................................................................................................................... 73 Querying displayed layers ............................................................................................ 74 User graphics and measuring ....................................................................................... 75 OGC Web Processing Service client ............................................................................ 76 Server-side scripts ........................................................................................................ 77 HSProxy ........................................................................................................................................................... 78

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

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

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

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

Mobile solutions for RL ................................................................................................... 97 Using KML as common format .................................................................................. 101 Field editing ................................................................................................................ 102 9

PROCESSING WORKFLOW MANAGEMENT ........................................................... 104 Orchestration environment .............................................................................................. 104 Workflow Management System ....................................................................................... 104 Business Process Execution Language .......................................................................... 104

Engines and work-flow managers .................................................................................. 105 Apache ODE............................................................................................................... 105 Orchestra .................................................................................................................... 105 Taverna Server ............................................................................................................ 106 Workflow designers .................................................................................................... 107 52°North WPS Workflow Modeller and Orchestration API ...................................... 107 ECLIPSE BPEL ......................................................................................................... 108 HUMBOLDT Workflow Design and Construction Service....................................... 110 Taverna Workbench .....................................................................................................111 10

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

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

Wild Salmon Monitoring ................................................................................................ 115 La Palma Protected Marine Reserve .............................................................................. 119 MadoniE Hiking Trip Planner ........................................................................................ 122 Madonia Sheep and Goat Herding Management ........................................................... 123 Augmented Reality Natural Reserve .............................................................................. 125 Economical activity at marine coastal benthic habitats.................................................. 130 National Forest Programme............................................................................................ 133 11

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

07 March 2013

2 of 44

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

Interoperability and Enabling Services ............................................................................ 136 3.2 HABITATS “Quick Prototyping” Service Applets .................................................... 137 The interoperability tests IMCS RL .................................................................................. 138

IRISH test with RL ......................................................................................................... 138 La Palma Reserve Marine Pilot test with RL ................................................................. 139 Augmented Reality Nature Reserve Pilot test with RL.................................................. 140 FMI Liberec region test of Reference Laboratory......................................................... 141 Experimentation with Open Linked Data ....................................................................... 143 12

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

13

REFERENCES ........................................................................................................... 147

Figure 1 INSPIRE Networking Architecture............................................................................ 16 Figure 2 Reverse “pyramid” effect (Bregt 2012). .................................................................... 18 Figure 3 Spider Web Paradigm ................................................................................................. 19 Figure 4 The changing sources of spatial data (Harris & Lafone). .......................................... 19 Figure 5 Habitats Networking Architecture ............................................................................. 21 Figure 6 Habitats RL and pilots................................................................................................ 21 Figure 7 Habitats RL ................................................................................................................ 22 Figure 8 URM concept ............................................................................................................. 24 Figure 9 URM principles .......................................................................................................... 25 Figure 10 URM Spidernet ........................................................................................................ 26 Figure 11 Portal login ............................................................................................................... 30 Figure 12 Portal registration ..................................................................................................... 31 Figure 13 Liferay Interface....................................................................................................... 32 Figure 14 Customisation of RL I .............................................................................................. 33 Figure 15 Customisation of RL II ............................................................................................ 34 Figure 16 Customisation of RL III ........................................................................................... 35 Figure 17 Customisation of RL IV ........................................................................................... 36 Figure 18 WordPress Based RL................................................................................................ 37 Figure 19 WordPress Article Editing ........................................................................................ 38 Figure 20 Micka Metadata Editing ........................................................................................... 40 Figure 21 Micka Metadata Validation ...................................................................................... 40 Figure 22 Micka Metadata importing ....................................................................................... 41 Figure 23 Micka Metadata importing XML ............................................................................. 41 Figure 24 Micka metadata importing WMC ............................................................................ 42 Figure 25 Editing of Imported metadata .................................................................................. 42 Figure 26 Validation result ....................................................................................................... 43 Figure 27 Metadata records management ................................................................................ 43 Figure 28 Slyling ...................................................................................................................... 47 Figure 29 Editing of vector data ............................................................................................... 48 Figure 30 Data flow between HS Layers and Geoserver. ........................................................ 49 Figure 31 User (or administrator) can create thematic maps (map compositions) using standard OGC OWS client, part of the mapping application. .................................................. 50 Figure 32 Ordering layers into groups, without touching the physical structure of displayed maps.......................................................................................................................................... 50 Figure 33 Changing the physical structure of displayed layers. In the "Physical view" tab, layers cannot be structured into groups, but their position in the layer tree (using drag&drop) can be changed. ........................................................................................................................ 51 Figure 34 Metadata extractor ................................................................................................... 52 07 March 2013

3 of 44

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

Figure 35 Catalogue Search ..................................................................................................... 53 Figure 36 Advanced search ...................................................................................................... 53 Figure 37 Metadata Detail ........................................................................................................ 54 Figure 38 Metadata Spatial Exten ............................................................................................ 54 Figure 39 Catalogue Client architecture ................................................................................... 55 Figure 40 Catalogue Import ..................................................................................................... 56 Figure 41 Catalogue import ...................................................................................................... 56 Figure 42 SuperCat harvesting ................................................................................................. 58 Figure 43 Micka harvesting configuration ............................................................................... 59 Figure 44 RSS channel – harvesting results ............................................................................. 60 Figure 45 Heartbeat protocol .................................................................................................... 60 Figure 46 Portal – metadata catalogue client ........................................................................... 62 Figure 47 Mobile catalogue client ............................................................................................ 62 Figure 48 Mobile catalogue client connected to central catalogue and map viewer showing found WMS .............................................................................................................................. 63 Figure 49 Illustration of relation between ExtJS and OpenLayers libraries inside of HSLayers. .................................................................................................................................................. 63 Figure 50 HSlayers Map Portal ................................................................................................ 64 Figure 51 Map Window ............................................................................................................ 65 Figure 52 Physical and Logical Structure ................................................................................ 66 Figure 53 HSLayers.OWS - Open Web Services client ........................................................... 68 Figure 54 Printing with HSLayers............................................................................................ 69 Figure 55 Printing Result ......................................................................................................... 70 Figure 56 Web Map Content Editing........................................................................................ 72 Figure 57 Permanent Link ........................................................................................................ 73 Figure 58 Embedded ............................................................................................................... 74 Figure 59 Result of the point query on one vector layer. ......................................................... 75 Figure 60 User graphic ............................................................................................................. 75 Figure 61 OGC WPS client ...................................................................................................... 76 Figure 62 Image classifcation................................................................................................... 77 Figure 63 Buffering .................................................................................................................. 77 Figure 64 Sequence diagram of proxy4ows shows the negotiation between the client, proxy4ows middleware and the target server. .......................................................................... 79 Figure 65 Invoking from catalogue .......................................................................................... 79 Figure 66 WMS invoking ......................................................................................................... 80 Figure 67 WMS Sequence diagram. ......................................................................................... 81 Figure 68 WMS transformation result - left map coordinate system, right - transformed result from EPSG:4326 source. .......................................................................................................... 81 Figure 69 Composition Saving ................................................................................................. 82 Figure 70 Open Composition from local disk .......................................................................... 83 Figure 71 WFS invoking scheme ............................................................................................. 84 Figure 72 Get Map Scheme ...................................................................................................... 85 Figure 73 OWS Dispatch ......................................................................................................... 86 Figure 74 Geoportal, Filter Encoding....................................................................................... 90 Figure 75 Filter Encoding......................................................................................................... 91 Figure 76 Filtering of WFS ...................................................................................................... 91 Figure 77 WPS Invoking .......................................................................................................... 92 Figure 78 Proxy ........................................................................................................................ 93 Figure 79 HSLayers SOS client ............................................................................................... 95

07 March 2013

4 of 44

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

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

07 March 2013

5 of 44

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

Figure 127 Liberec Thematic Maps using standardised data from FMI ................................ 142 Figure 128 Flood portal as part of Geoportal ......................................................................... 143 Figure 129 Education and awareness ..................................................................................... 143 Figure 130 Integration of Open Linked data from skiing resorts ........................................... 144

1

07 March 2013

6 of 44

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

Figures Figure 1 INSPIRE Networking Architecture............................................................................ 16 Figure 2 Reverse “pyramid” effect (Bregt 2012). .................................................................... 18 Figure 3 Spider Web Paradigm ................................................................................................. 19 Figure 4 The changing sources of spatial data (Harris & Lafone). .......................................... 19 Figure 5 Habitats Networking Architecture ............................................................................. 21 Figure 6 Habitats RL and pilots................................................................................................ 21 Figure 7 Habitats RL ................................................................................................................ 22 Figure 8 URM concept ............................................................................................................. 24 Figure 9 URM principles .......................................................................................................... 25 Figure 10 URM Spidernet ........................................................................................................ 26 Figure 11 Portal login ............................................................................................................... 30 Figure 12 Portal registration ..................................................................................................... 31 Figure 13 Liferay Interface....................................................................................................... 32 Figure 14 Customisation of RL I .............................................................................................. 33 Figure 15 Customisation of RL II ............................................................................................ 34 Figure 16 Customisation of RL III ........................................................................................... 35 Figure 17 Customisation of RL IV ........................................................................................... 36 Figure 18 WordPress Based RL................................................................................................ 37 Figure 19 WordPress Article Editing ........................................................................................ 38 Figure 20 Micka Metadata Editing ........................................................................................... 40 Figure 21 Micka Metadata Validation ...................................................................................... 40 Figure 22 Micka Metadata importing ....................................................................................... 41 Figure 23 Micka Metadata importing XML ............................................................................. 41 Figure 24 Micka metadata importing WMC ............................................................................ 42 Figure 25 Editing of Imported metadata .................................................................................. 42 Figure 26 Validation result ....................................................................................................... 43 Figure 27 Metadata records management ................................................................................ 43 Figure 28 Slyling ...................................................................................................................... 47 Figure 29 Editing of vector data ............................................................................................... 48 Figure 30 Data flow between HS Layers and Geoserver. ........................................................ 49 Figure 31 User (or administrator) can create thematic maps (map compositions) using standard OGC OWS client, part of the mapping application. .................................................. 50 Figure 32 Ordering layers into groups, without touching the physical structure of displayed maps.......................................................................................................................................... 50 Figure 33 Changing the physical structure of displayed layers. In the "Physical view" tab, layers cannot be structured into groups, but their position in the layer tree (using drag&drop) can be changed. ........................................................................................................................ 51 Figure 34 Metadata extractor ................................................................................................... 52 Figure 35 Catalogue Search ..................................................................................................... 53 Figure 36 Advanced search ...................................................................................................... 53 Figure 37 Metadata Detail ........................................................................................................ 54 Figure 38 Metadata Spatial Exten ............................................................................................ 54 Figure 39 Catalogue Client architecture ................................................................................... 55 Figure 40 Catalogue Import ..................................................................................................... 56 Figure 41 Catalogue import ...................................................................................................... 56 Figure 42 SuperCat harvesting ................................................................................................. 58 07 March 2013

7 of 44

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

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

07 March 2013

8 of 44

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

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

07 March 2013

9 of 44

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

Tables Table 1 Testing WMS services results ...................................................................................... 61 Table 2 Comparison of INSPIRE solutions and current mobile solutions ............................... 98

3

07 March 2013

10 of 44

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

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 As reported in D5.2.1. 3 To be reported in D2.4.3 and D5.4.2 2

07 March 2013

11 of 44

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

• • • • • • • • •

network services and technologies; agreements on sharing, access and use; and coordination and monitoring mechanisms, processes and procedures, established, operated or made available in accordance with this Directive; [INSPIRE Directive] INSPIRE application schema – application schema specified in an INSPIRE data specification INSPIRE data specification – harmonised data product specification for a theme adopted as an Implementing Rule metadata – information describing spatial data sets and spatial data services and making it possible to discover, inventory and use them [INSPIRE Directive] services allowing – spatial data services to be invoked [INSPIRE Directive] spatial data – data with a direct or indirect reference to a specific location or geographic area [INSPIRE Directive] spatial data set – identifiable collection of spatial data [INSPIRE Directive] spatial object – abstract representation of a real-world phenomenon related to a specific location or geographical area [INSPIRE Directive] transformation services – services enabling spatial data sets to be transformed with a view to achieving interoperability [INSPIRE Directive] view services – services to display, navigate, zoom in/out, pan, or overlay viewable spatial data sets and to display legend information and any relevant content of metadata [INSPIRE Directive]

Abbreviations • • • • • • • • • • • • • • • • • • • • • • • •

API – Application Programming Interface CMS – content management systems CSW - Catalogue Service Web EC – European Commission EN - European Norm ESA – European Space Agency EU – European Union GEOSS - Global Earth Observation System of Systems GMES – Global Monitoring for Environment and Security GML – Geography Markup Language HTML – HyperText Markup Language INSPIRE – INfrastructure for SPatial InfoRmation in Europe ISO – International Organisation for Standardisation KML – Keyhole Markup Language OGC – Open Geospatial Consortium RL – Reference Laboratory SDI – Spatial Data Infrastructure SEIS – Shared Environmental Information System SOA – Service Oriented Architecture UML – Unified Modelling Language URI – Uniform Resource Identifier URM – Uniform Resource Management WCS – Web Coverage Map WFS – Web Feature Map Service

07 March 2013

12 of 44

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

• WMC – Web Map Context • WMS – Web Service Map • WPS – Web Processing Services

07 March 2013

13 of 44

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

4

INSPIRE, Networking Architecture and HABITATS

In order to validate the HABITATS networking services architecture defined in Task 4.2, a series of specific service applets were deployed and tested for data sharing using the HABITATS Reference Laboratory (RL) geoportal platform. Comparing network services and spatial data services, the INSPIRE Forum4 definitions are: • Spatial data services are all services (Discovery, View, Download, Transformation, Invoke, Other) regarding spatial data. • Network services (Discovery, View, Download, Transformation, Invoke): • non-compliant network services are INSPIRE compliant services with respect to functionality; • compliant network services are compliant services with respect to functionality and quality of service. The HABITATS networking architecture supports INSPIRE Network services, but needs to go behind this concept. INSPIRE networking services are in principle limited only to the management of existing data and metadata. The HABITATS Networking Services also support such functionality with data and metadata management, data and metadata collection, working with non-spatial data, etc. The HABITATS service applets re-use existing applications where possible and are themselves designed for re-use. The selection of the specific services to deploy is primarily a user-driven process, as defined in the user scenarios and requirements of task T2.3 and as required by the pilot validation platform of task T5.2. Task T4.3 has defined the prototype set of Network Service Applets to be installed in validation pilot platforms, as: • A series of specific networking service applets deployed and tested for data sharing within the project using the Network Service Architecture (of D4.2.1) • Interoperability Services • Enabling Services • Visualisation of information layers • Overlay of information from different sources • Spatial and Temporal Analysis • “quick” and “light” on-demand applets to meet validation pilot expectations and user needs • Usability, simplicity and openness to rapid prototyping mash-ups. • A set of specific service applets that allow users to identify, access, use and reuse habitats-related data, designed and deployed on-demand to meet user needs, • Users selected in the T2.3 user scenarios and T5.2 pilot validation platform. • Mobile Apps allowing use advantage of HABITATS RL • “Quick Prototyping” service applets respecting the HABITATS service architecture and developed on-demand. These are based on the outcomes from the earlier tasks and work with the HABITATS RL, and will now lead into the interface tools and toolkit.

4

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

07 March 2013

14 of 44

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

The HABITATS Networking Architecture aims to extend the principles of the INSPIRE networking architecture, because INSPIRE doesn’t cover important aspects such as data management and data collection. So all components of the INSPIRE networking architecture will be included in the HABITATS architecture, but this concept will be extended by other functionalities. From this point of view principles of GEOSS and GMES and also principles of Shared Environmental Information System (SEIS) and Single Information Space in Europe for the Environment (SISE) have influenced the HABITATS architecture and its networked services. The development of the network service architecture process of WP4 was initiated through a state of the art analysis of existing SDI, to find out more about already existing infrastructures and to examine how data should be shared and what services are required to enable sharing. When designing the networking architecture, a set of specific networking service applets was deployed and tested for data sharing within the project. Also the potential for re-use of existing application was taken into account. This Report deals also with the tools for invoking of Geospatial Services that arose within the HABITATS network architecture, interlinking different data sources and also interlinking data sources from different INSPIRE thematic areas.

5

Invoking services

The definition of spatial data services included in the INSPIRE directive is the following: ‘spatial data services’ means the operations which may be performed, by invoking a computer application, on the spatial data contained in spatial data sets or on the related metadata (INSPIRE 2007). ISO 19119 defines also taxonomy for Geospatial services (INSPIRE Invoke Services 2009): • Geographic human interaction services • Geographic model/information management services • Geographic workflow/task management services • Geographic processing services o Geographic processing services – spatial o Geographic processing services – thematic o Geographic processing services – temporal o Geographic processing services – metadata •

Geographic communication services

• Geographic system management services (HABITATS 2009) From INSPIRE Networking architecture, there are basic Networking services 1. Discovery Service (discovery): Is a services that makes it possible to search for spatial data sets and services on the basis of the content of the corresponding metadata and to display the content of the metadata. 2. View Service (view): Is a service that makes it possible, as a minimum, to display, navigate, zoom in and out, pan or overlay viewable spatial data sets and to display legend information and any relevant content of metadata. 3. Download Service (download): Is a service that enables copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly.

07 March 2013

15 of 44

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

4. Transformation Service (transformation): Is a service that enables spatial data sets to be transformed with a view to achieving interoperability. 5. Invoke Spatial Data Service (invoke): Is a service that allows defining both the data inputs and data outputs expected by the spatial service and a workflow point of view 5 The INSPIRE Spatial Data Service and Invoke Service – Draft, implements rules defining that Invoke service has to be accessible via Internet and offers a mean to invoke the linked spatial data services. Invoke shall support in order to allow clients invoking spatial data services. Taking into account the potentially wide diversity of interfaces and protocols, invoke services are services that allow access to sufficient service metadata to enable the activation or execution of the spatial data service. The document updated the basic INSPIRE architecture scheme and defined sets of requirements for INSPIRE Invoking services.

Figure 1 INSPIRE Networking Architecture

The requirements are divided into two groups of requirements: • IR Requirement - Are requirements that are reflected in the Implementing Rule on interoperability of spatial data sets and services are shown using this style. • SDS Requirement - Requirements that are not reflected in the Implementing Rule on interoperability of spatial data sets and services are shown using this style. Document INSPIRE Spatial Data Services and Invoke Service define also set of recommendation. INVOKING service requirements and recommendations • IR Requirement 1 The implementing rules are restricted to spatial data services that relate to spatial data sets in themes in Annex I-III, or to their related metadata. • Recommendation 1 There shall be no other requirements applicable to ALL spatial data services than the establishment of discovery metadata. • Recommendation 2 A spatial data service in this context shall have clearly defined interfaces for machine-to-machine communication. A Geographic Information System or other systems, understood as a set of tools for collecting, processing and storing 5

INSPIRE Spatial Data Services and Invoke Service – Draft, implementing rules, Draft_IR_SDS_and_Invoke_1.0.doc

07 March 2013

16 of 44

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

• •





• •

• • • •





spatial data, should not be considered an invokable spatial data service from the perspective of the relevant Implementing Rules. But any specific functionality included in it, and with a well-defined and exposed interface, could be an invokable spatial data service. IR Requirement 2 Interoperability arrangements in the INSPIRE context shall be related to invokable spatial data services. IR Requirement 3 Requirements for interoperability arrangements are only mandatory for spatial data services operating upon harmonised data (i.e. spatial data sets conformant to the regulation for IDSS). IR Requirement 4 A spatial data service conformant to interoperability arrangement shall support coordinate reference systems according to Annex II.1 of the Commission Regulation (EC) No 1089/2010 . IR Requirement 5 The default temporal reference system referred to in point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 shall be used, unless other temporal reference systems are specified for a specific spatial data theme in Annex I-III. IR Requirement 6 A spatial data service conformant to the interoperability arrangement shall be available 99% of time. IR Requirement 7 A spatial data service conforming to interoperability arrangement returning spatial objects as part of the output, shall encode those spatial objects according to Article 7 of Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services. IR Requirement 8 All spatial data services conformant to the interoperability arrangements shall include a Get Service Metadata operation. IR Requirement 9 Newly developed spatial data services operating upon harmonised data or their metadata shall be conformant with interoperability arrangements. IR Requirement 10 Any harmonised spatial data service shall follow the interoperability arrangements. IR Requirement 11 Any harmonised spatial data service shall have minimal performance criteria defined in the same way as network services, i.e. performance, capacity, and availability. The values will depend upon the character of the type of service. Recommendation 5 The gazetteer service should be related to harmonised datasets conforming to Addresses, Geographical names and Administrative boundaries. i.e. Location instances should be fetched from these three themes, and correspondingly the Location type should be either an address, a geographical name, or an administrative polygon. IR Requirement 12 A registry service shall be compliant with ISO 19135:2005, Geographic information -- Procedures for item registration.

07 March 2013

17 of 44

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

6

Problems of Policy Driven SDI

INSPIRE is politically driven top down approach. It is important to see how INSPIRE reflects local, regional and national needs. Currently, there is low awareness on regional level and the benefits for the local level are no clearly defined. During the JRC Cost benefit workshop in 2012 the schema depicted in next figure was presented.

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

The schema shows the relation between the level of governance and the amount of benefits. The HABITATS idea is to find a solution how to turn the green triangle upside down. It is also vital for successful implementation of INSPIRE. The authors identified three areas where special attention needs to be given for successful implementation of the INSPIRE Directive: • metadata; • networking architecture; The INSPIRE architecture doesn’t reflect the needs of regions regarding data collection and updating. Usually, for different pilots’ needs, the generic INSPIRE architecture has to be modified, extended or reduced. (Charvát 2011) Global SDI building is usually described in a form of a pyramid. Current practices prove that “spider web infrastructure building”, where different local or global levels are able to directly share data, is more efficient. The HABITATS intention is to shift SDI from the pyramid to the spider web paradigm.

07 March 2013

18 of 44

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

Figure 3 Spider Web Paradigm

Neogeography There exist a large number of different voluntary or bottom-up initiatives supporting building of different parts of SDI. The SDI world is changing with development of new GPS devices, smartphones, mobile cameras and tablets. More and more localised information is collected by citizens. For such type of data collection “people as sensors” or “human sensors” terms are often used. This means that “human observations” can be part of future real-time SDIs and serve as an input for spatial decision-making processes. Current use and collection of data by citizens is higher than collection of data by public bodies. Such process is depicted in next Figure.

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

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

07 March 2013

19 of 44

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

videos, photos or oral histories. The collected information can contribute to up-to-date data. The term neogeography is used for these methods. It is related to new Application Programming Interfaces (APIs), Web 2.0 and the mapping capabilities of the Geospatial Web. People can create “geotagged” information from mobile devices. This new technology opens new possibilities. Neogeography represents a new way of collection and geographic knowledge production using interactive technologies, interfaces and technical expertise. These methodologies bring serious challenges to SDIs and traditional forms of data acquisition, analysis, and publication. (Harris & Lafone forthcoming)

7

HABITATS Networking Services

The intention of the HABITATS Networking Services is to provide shift from classical INSPIRE (GEOSS, GMESS architecture) towards solution, which will support local and regional SDI building and their interaction with INSPIRE and also, which will move standards SDI model towards Neography and SpiderWeb paradigm. The way to test and provide it is Reference Laboratory as key tool of HABITATS Networking architecture. The HABITATS architecture defines a platform-neutral SDI with a basic set of networking services in compliance with the INSPIRE Directive for sharing environmental data, especially that related to the 4 INSPIRE themes of 16.Sea-Regions (SR), 17. Bio-geographical Regions (BR), 18. HABITATS and Biotopes (HB) and 19. Species Distribution (SD). This will result in a European Metadata profile for these four data themes, which will be an extension of the INSPIRE profile. Our intention is not only to follow the INSPIRE profile for discovery services, but to also reflect on the extension the profiles for using data; a link to data modelling activities is therefore necessary. This profile is further open to extension by single countries or user groups, but the aim is that it be respected as a minimum set. The set of HABITATS Networking Services have been implemented on the HABITATS Reference Laboratory (RL) geoportal platform6. This acts as a client of the 7 HABITATS pilots that provides a very rich set of cross-pilots, inter-regional and enabling services. Reference Lab The reference laboratory is the central hub of the HABITATS Networking Architecture. It consists of several layers, which are (HABITATS D4.2.2 2011): • Data layers – management data and files on storage, eventually guarantee access to external sensors Server (engine layer) – defines tools, which guarantee basic services on the server side – supplying service Client layer – is client side of web services, which guarantee access of users to services • Application layer is some form of wrapping elementary client services into application or into such form, which could be used by other web tools and social media. Presentation layer contain such web tools, which allow to combine and publish single objects from the application level as part of Web presentation The illustration below (taken from HABITATS D4.2.2 2011) shows the different layers of the HABITATS Networking Architecture.

6

www.habitats.cz

07 March 2013

20 of 44

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

Figure 5 Habitats Networking Architecture

The final implementation of the HABITATS Services anticipates that selected concrete services will be deployed for every pilot, and that there will be one central platform (i.e. the Reference Laboratory).

Figure 6 Habitats RL and pilots

07 March 2013

21 of 44

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

The HABITATS RL provides the Networking Architecture supporting both Networking Services and Spatial Data services, that support the SDI network services to enable transEuropean sharing of habitats-related spatial data between public authorities and other stakeholders in the Community, enabling the creation of value added services. The RL is focused on implementation of: • Cross pilot scenarios based on sharing of data among more pilots • Validation platform for testing of conformity of implemented pilot services • Services supporting global discovery, view and downloading • Repository for common metadata • Repository for pan European datasets such as Natura 2000, CLC, Urban Atlas and Open Street Maps • Interlink with social networks The RL provides the Networking Architecture, that supports the SDI network services to enable trans-European sharing of habitats-related spatial data between public authorities and other stakeholders in the Community enabling the creation of value added services. The RL enables deployment of specific service applets, including interoperability and enabling services, on-demand from user communities and the pilots for initial implementation and validation. It is being developed further to include an invoking service toolkit integrating the service applets with the goal of facilitating the development of end-user services accessing habitats-related spatial data over time However applications are the key objectives and final goal of using the HABITATS RL. As the RL is just a geoportal tool to help to build applications that address the Pilots’ typical use cases. The HABITATS RL is • an interface that enables interactive search, portrayal, evaluation, sharing, analyse and reuse of spatial and non-spatial data. • a solution based on interoperable standards (OGC, W3C, OASIS, ISO). It is interconnected to other resources through the Internet. It helps to create a distributed structure of information and knowledge with spatial position.

Figure 7 Habitats RL

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

07 March 2013

22 of 44

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

• • • • • • • • • •

Independent components Composition according to user requirements Based on SOA Possibility to integrate with other resources Maximum openness Open Source Open Standards Extension to non-GIS community Open Search Administration of other (non-spatial) data sources

The HABITATS RL allows deployment of the current state of the art of technological solutions, which will be tested and adopted by the HABITATS partners and user stakeholders. It allows testing of current existing technology and generation of further research tasks driven by users. The RL also collects information coming from other projects, which is an important input for the HABITATS analysis and public discussion. The methods of social assessment will be an increasingly important part of the RL. Thus the RL’s networking services aim to help HABITATS to extend user-centric, co-design approaches into the arena of standards design and adoption processes, considering standards initiatives such as INSPIRE, OGC, UNSDI to be significant social, economic and institutional innovations. The elements of the approach are maintained, applying the model at all levels from the global scale to the local and regional policies that frame many HABITATS validation pilots. Community building activities follow a Web 2.0 approach to capture the knowledge in active user communities with a strong interest in contributing to the standards development process. By inviting a broad multi-sectoral and inter-disciplinary range of concerned stakeholders to participate into the HABITATS network, a viral motivation spiral is set off. A peer-to-peer approach to opening up information sources and providing access to content ensures a rapid extension of the critical mass of environmental data established by project partners. Uniform Resource Management (URM) Concept Uniform Resource Management (URM) provides a framework in which communities can share information and knowledge through description, which is easily understandable inside of the community. It is based on a standardised schema supporting a uniform description of information and knowledge including common vocabularies. The schema defines the meaning, characteristics and relationships of a set of properties, and includes constraints on potential values and the inheritance of properties from other schemas. The URM concept has been defined and developed through the NaturNet-Redime project and extended by c@r to support knowledge sharing inside a community (Charvát et al. 2008).

07 March 2013

23 of 44

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

Figure 8 URM concept

Uniform Resource Management supports validation, discovery and access to heterogeneous information and knowledge. It is based on utilisation of metadata schemas. The URM models currently integrate different tools, which support sharing of knowledge. Geoportal contains common visualisation, data sharing, metadata and catalogue functionalities. It includes also tools for sensor observation management and spatial data transformation and processing. The principle of the URM allows to build a "spider web" infrastructure supporting interconnection of portals and effective exchange of information. This concept is also more related to GEOSS and Single Information Space for Environment (SISE) principles. Many context attributes characterize the environmental information or knowledge. From the point of view of context, the information or knowledge can involve different parties: • Information or knowledge provider i.e. a party supplying the resource; • Custodian accepts accountability and responsibility for the resources and ensures appropriate care and maintenance of the resource; • Owner of the resource; • User, who uses the resource; • Distributor who distributes the resource; • Originator who created the resource; • Point of Contact to be contacted for acquiring knowledge about or acquisition of the resource; • Principal investigator responsible for gathering information and conducting research; • Processor who has processed the data in a manner such that the original resource has been modified; • Publisher, i.e. party who published the resource; • Author, i.e. party who authored the resource. The HABITATS RL is a new integrated solution designed as a combination of previous technologies - Uniform Resource Management, Geohosting and new technological development of a visualization client based on HSLayers. The URM Geoportal is not one integrated solution, but a set of modules and services, which can communicate through interoperable services (OGC, W3C). The solution is modular and can be readily modified for 07 March 2013

24 of 44

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

different purposes. The URM Geoportal is based on Open Source technologies, but it can be integrated with different technologies such as MS SQL or ArcSDE. The Uniform Resource Management (URM) supports validation, discovery and access to heterogeneous information and knowledge. It is based on utilization of metadata schemas. The URM models currently also integrate different tools, which support sharing of knowledge. The URM Geoportal contains:  Metadata  Catalogue client  Visualization client  Metadata Editor  Geoserver  Styler  Metadata Extractor  Enterprise management tools  Content management  Social Networks tools

Figure 9 URM principles

The HABITATS RL geoportal contains common visualization, data sharing, metadata and catalogue functionalities. Additional parts of the solution can also be tools for management of sensor observation and spatial data transformation and processing. The core part of the RL is the metadata system, which guarantees access to all information stored in the portal

07 March 2013

25 of 44

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

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 8

See www.naturnet.org See www.envirogrids.net

07 March 2013

26 of 44

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

also an important part of the portal. The portal supports those users searching for information dealing with the subjects of sustainability, environmental protection and management and is also a place for others to publish related information and resources. It is possible to search by terms within several categories (this list of categories is not limited and can be changed or increased). Firstly, the user can choose from one of several possible folders (‘all’, ‘documents only’, ‘projects’, ‘maps’, etc.) by selecting the tabs at the top of the page, which enable the user to search using their SEARCH TERM either more generally or within a restricted range. The (main panel) window then displays the results of a search within the catalogued information. The user can check the metadata for any of the listed items or can run the application or view the document in those cases where the listed items are directly linked to a document or an application. An extended search allows searching for information in a variety of ways. Users can choose from any of the parameters listed in the left window or use the map window. The map window offers a way to select the geographic area in which the user is particularly interested. Users can select by country or a smaller detailed area from the whole of Europe using the selection rectangle for zooming. A combination of both windows provides a better opportunity to precisely specify the required information. • Publishing user documents on the URM portal. o Users can use the Metadata Extractor, to find their file on their computer; using the Metadata Extractor (file searching), ask for extraction of the available metadata, then complete the missing metadata and publish their file and its metadata on the URM portal. • Publishing of user Web pages on the URM portal. o Users can publish any Web content through the URM portal. They put their web address (URL) into the metadata extractor and extract the metadata. Edit the missing records in the metadata (including a selection for the type of their content) and then save the metadata. • Registration of user metadata system on the URM portal. o If a user has a catalogue system supporting the following profiles (ISO 19115, ISO 19119 and Dublin Core ISO 15836-2003 and supporting the Catalogue Service for the Web (for instance using MICKA or GeoNetwork) they can ask for registration of their catalogue on the URM portal. • Registration of data or services directly from a user application. o An applications developer who directly publishes interactive Web data or services, can ask for the CSW client, which will support direct registration of their results in the catalogue. • Publishing using URM tools. o Users may use the independent URM tools for working with their data, or for their integration into new systems and presentation in e-learning or web services forms. URM Tools that are available on the HABITATS RL are described in the following subsections.

07 March 2013

27 of 44

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

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 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 10

07 March 2013

28 of 44

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

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 client13 - allows searching through connected metadata catalogues by the catalogue service OGC CSW. Data can be searched by text or by elements defined in standards (OGC CSW 2.0.2, AP ISO, INSPIRE). Basic elements can be extended by user demands. These elements are not searchable in other connected catalogues. The first version of the catalogue uses cascading of multiple services. o MapViewer - (developed by HSRS) is a JavaScript-based WebGIS map application built using the HSLayers JavaScript library. It extends OpenLayers and adds new functionalities including WMS and WFS client, printing of hard copy maps, vector editing capabilities and others. Several features, which are still in the INSPIRE proposal stage (e.g. transformation service), are used as well.

In addition the HABITATS RL can connect different desktop GIS tools as external applications. These tools are not directly part of the solution, as they are more related to educational content.

13

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

07 March 2013

29 of 44

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

Authorization and Authentication tools The RL is composed of independent components (modules). The information provided can be made publicly available and every user is authorised to access it without authentication. For the cases where the information can be for example viewed or modified by only restricted group of people, the authentication and authorisation mechanisms are put in place. Authorisation and authentication terms are often used interchangeably. The following definitions should clarify the difference between them. Authentication is a mechanism that securely identifies user within a system. It verifies the identity of the user by for example a password or a fingerprint. Authorisation is a mechanism that specifies access rights to the content or other resources. In other words, authentication is the process of verifying that "you are who you say you are", authorisation is the process of verifying that "you are permitted to do what you are trying to do." Authorisation thus presuppose authentication. (Wikipedia contributors 2012a). The RL enables users to control access to all their resources stored on the geoportal using the authentication and authorisation mechanisms. Registered users can be authenticated by credentials including the email address and a password.

Figure 11 Portal login

Unregistered users can create an account using a simple form by filling in a name, date of birth, gender, username and email address. The creation of the user account is protected by CAPTCHA14 ensuring that the form is filled by a person.

14

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

07 March 2013

30 of 44

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

Figure 12 Portal registration

The registration of users as well as the provision of permissions (authorisation) can be managed by the system administrator. RL uses its own mechanism for authentication/authorisation by LDAP (Lightweight Directory Access Protocol). This will ensure that each server will act independently from the others. It will also provide better data protection and better access control on the corresponding level. Upper level portal users may have access to private data by cascading user rights through the infrastructure. Each node will have mechanism for saving user access to other servers for authorised users. Also a masking mechanism will be used to avoid access to restricted datasets. Liferay based geoportal solution The RL is based on Liferay15 solution. It is a web platform orchestrating all the geoportal components and other gadgets, portlets, pages etc. Liferay allows editing the web pages (part of the geoportal interface) and their content. Liferay enables administrators to: • define the content and the system of the menu; • publish articles, images, links etc.; • publish predefined map compositions;

15

http://www.liferay.com/

07 March 2013

31 of 44

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



publish RSS channels.

There are many other functions that can be used and that are described in detail in the manual of Liferay available at http://www.liferay.com/. Liferay is focused on usability and simplicity for end users but also on clarity and security of the implementation. The administrator can define the menu of the geoportal and its submenus. Any menu or submenu can incorporate external web links. The user can publish articles using the content holders. A WYSIWYG16 editor provides a good user experience for beginners. The content holders support HTML code for advanced users. The editor allows inserting various multimedia content including You Tube videos, photos, SlideShare presentation etc. The print screen of the content editor is in next Figure.

Figure 13 Liferay Interface

The geoportal supports RSS and GeoRSS feeds that can be displayed from remote sites. This enables a straightforward and easy way of promoting the RL services. RSS (most commonly expanded as Really Simple Syndication) is a family of web feed formats used to publish frequently updated works—such as blog entries, news headlines, audio, and video—in a standardised format. An RSS document (which is called a "feed", "web feed", or "channel") includes full or summarized text, plus metadata such as publishing dates and authorship. Web feeds benefit publishers by letting them syndicate content automatically. They benefit readers 16

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

07 March 2013

32 of 44

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

who want to subscribe to timely updates from favored websites or to aggregate feeds from many sites into one place. (Wikipedia contributors 2012c). GeoRSS is an emerging standard for encoding location as part of a Web feed. In GeoRSS, location content consists of geographical points, lines, and polygons of interest and related feature descriptions. (Wikipedia contributors 2012b). CUSTOMISATION OF THE PORTAL CONTENT The portal administrator can customise the content of each web page. Texts, images, You Tube videos, SlideShare presentations and other content can be easily added. Next figures show the steps of adding web content to the website including texts and images.

.

Figure 14 Customisation of RL I

07 March 2013

33 of 44

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

Figure 15 Customisation of RL II

07 March 2013

34 of 44

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

Figure 16 Customisation of RL III

07 March 2013

35 of 44

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

Figure 17 Customisation of RL IV

WordPress based GeoSocial Network WordPress is web software you can use to create a beautiful website or blog. WordPress is both free and priceless at the same time. WordPress plugins can extend WordPress to do almost anything. Plugins are developed by the community and to find proper plugin is sometimes difficult. This is also the case of adding geospatial information to each blog or static page. None of the plugins fulfil the expected behaviour and features. Features we were looking for are: 1. User can draw mark region, which has some relation to written blogpost. 2. Region will be displayed in the map while reader of the blog post is reading. 3. There is standardized way how to collect this geospatial information across the whole blog.

This features are developed in the new plug-in.

07 March 2013

36 of 44

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

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

07 March 2013

37 of 44

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

Figure 19 WordPress Article Editing

Based on geolocated blog posts, GeoRSS is generated, which can be consumed by various services and clients.

07 March 2013

38 of 44

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

Uniform Resource Management (URM) MICKA MICKA17 is a meta information catalogue that fully complies with the ISO 19115 standard and is fully compliant with the INSPIRE principles. It can be integrated with map applications. It is multilingual. The web catalogue service uses OGC specifications. MICKA is a complex system for metadata management used for building Spatial Data Infrastructure (SDI) and geoportal solutions. It contains tools for editing and management of metadata for spatial information, web services and other sources (documents, web sites, etc.). It includes online metadata search engine , portrayal of spatial information and download of spatial data to local computer. MICKA is compatible with obligatory standards for European SDI building (INSPIRE). Therefore it is ready to be connected with other nodes of prepared networked metadata catalogues (its compatibility with pilot European geoportal is continuously being tested). Functions include: • Spatial data metadata (ISO 19115) • Spatial services metadata (ISO 19119) • Dublin Core metadata (ISO 15836) • Feature catalogue support (ISO 19110) • OGC CSW 2.0.2 support (catalogue service) • User defined metadata profiles • INSPIRE metadata profile • Web interface for metadata editing • Multilingual (both user interface and metadata records). Currently 16 languages are supported. It is possible to dynamically extend the system for other languages. • Context help (multilingual) • Import from the following metadata formats are supported: o ESRI ArcCatalog, o ISO 19139, o OGC services (WMS, WFS, WCS, CSW) o Feature catalogue XML • Export – ISO 19139, GeoRSS • Support of thesauri and gazetteers. • Display of changes with GeoRSS • Template base interface with possibilities to change according to user requirements • Possibility of deep cooperation with any map clients for display of on-line map services.

17

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

07 March 2013

39 of 44

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

Figure 20 Micka Metadata Editing

MICKA stores metadata in a relational database and it is edited by dynamically generated forms. Therefore it is possible to amend other standards or profiles. It is possible to switch between profiles while editing. Individual profiles can be distributed into sections. With the help of control elements it is possible to duplicate individual items, select from code lists or connect to supporting applications. Checking of mandatory items is enabled while editing. The MICKA integrated application is divided into 3 independent components: • Metadata creation • Metadata importing • Metadata Management Metadata editing tools and metadata importing tools communicate with Metadata Management through the CSW protocol. This allows use of two tools independently on the one MICKA system (for instance a user could integrate with GeoNetwork). Metadata editing supports the editing of metadata records using a selected profile, as follows:

Figure 21 Micka Metadata Validation

07 March 2013

40 of 44

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

While downloading storage and validation is handled as follows:

Figure 22 Micka Metadata importing

Metadata importing support from xml files is as follows:

Figure 23 Micka Metadata importing XML

or directly harvest metadata from GetCapabilities of selected OGC services, as follows:

07 March 2013

41 of 44

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

Figure 24 Micka metadata importing WMC

After harvesting, metadata can be edited, downloaded, stored or validated, as illustrated in the following screen grabs:

Figure 25 Editing of Imported metadata

07 March 2013

42 of 44

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

Figure 26 Validation result

The MICKA metadata management system supports deleting, updating and copying metadata records.

Figure 27 Metadata records management

GEOSERVER

Data management Data are uploaded to the system on portal upload page. If necessary the FTP server is provided to enable upload of larger datasets. Two basic concepts of handling the data are considered: • File based approach – this approach is suitable for static data that are not going to be updated too often. This approach uses original file as source of the data without any

07 March 2013

43 of 44

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

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.



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.

Features:

Data visualisation To be able to display newly uploaded data there are possibility to configure the way how they will be provided to user. In general two basic concepts are considered: 1. Data are provided in raster format – in this case the data are rendered on server

07 March 2013

44 of 44

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

side by applying data Style in SLD format on original data. Rendered raster are then served using WMS service (Web map service). For performance booth this rendered data can be efficiently cached on server side. This approach is optimal for large scale data that doesn't change too often. 2. Data are provided as a vector data and they are rendered directly in Java script client. For this case the OGC WFS or KML is used. This approach is ideal for overlay data that might be frequently edited. For data service there is Geoserver used. The user interface functionality that are configure such services are: • Administrator can choose and configure particular data from Data Store (directory of shape files, directory of raster data, spatial database) so that they can be published on portal as new Data Layer. • Administrator can configure particular form of the web service for this Data Layer. WMS, WFS and KML will be supported. • Administrator can assign predefined style in SLD format to particular Data Layer. • Administrator can configure user rights that will limit the access to these data. Generally each Data Layer can have a access mode to be read, written or administrated. • Configure the caching strategy and other caching details. •

Data Layers can be also grouped to Workspaces where the whole Workspace can have common rights or restrictions.

Map compositions The map composition can contain the user’s own data from the internal server as well as other external data sources. All these data sources can be used for the creation of new map compositions in the web interface. The web services can be accessed in two ways. Either by typing the address of the web service or by searching the web service in the connected metadata catalogue. Data can be in raster as well as in vector form. Vector data can be visualised in various colours and/or symbols. Access rights can be defined for each map composition. Each composition is also tagged with a metadata sentence and registered in the metadata catalogue.

Data publication The user can set up the parameters for the publication of the new composition according to the requirements. This enables access by other users. Such new map compositions can be portrayed by the user by two means. It can be done either using web browsers (Open Layers, Google Map, DHTML client) or using desktop viewers (GoogleEarth). The map compositions can be published as a brand new web service (WMS or WFS).

07 March 2013

45 of 44

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

The new map compositions can be used for example in mobile devices and e-learning applications. This solution is of particular advantage to those working in a big team or supplying information to the public. The system is fully compliant with the INSPIRE principles. Web Map Server includes tools, which support publishing of locally stored data (filesystem, RDBMS) in the form of web services. The basic required services are: •





A Web Map Service (WMS) is a standard protocol for serving geo-referenced map images over the Internet that are generated by a map server using data from a GIS database A Styled Layer Descriptor (SLD) is an XML schema specified by the Open Geospatial Consortium (OGC) for describing the appearance of map layers. It is capable of describing the rendering of vector and raster data. A typical use of SLDs is to instruct a Web Map Service (WMS) of how to render a specific layer. Web Feature Service Interface Standard (WFS) provides an interface allowing requests for geographical features across the web using platform-independent calls. One can think of geographical features as the "source code" behind a map, whereas the WMS interface or online mapping portals like Google Maps return



only an image, which end-users cannot edit or spatially analyse. Web Coverage Service Interface Standard (WCS) provides an interface allowing requests for geographical coverages across the web using platform-independent calls. The coverages are objects (or images) in a geographical area, whereas the WMS interface or online mapping portals like Google Maps return only an image, which end-users cannot edit or spatially analyse.

Styler In order to be able to style uploaded vector data files, SLD editor is used. We setup Styler application, where the user can prepare his/her layer styles, using easy-to-use graphical tool. User can create styles for each feature type based on its geometry type (point/line/polygon) or attribute features. Styles are stored in form of SLD within the GeoServer administration interface, for later usage.

07 March 2013

46 of 44

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

Figure 28 Slyling

Vector data editing Logged-in user is able to provide basic vector data editing including modifying vector features geometries as well as their attributes. 1. In the first step, user has to activate the editing panel. 2. In the second step, user has to define which vector features will be modified. The application doesn’t allow the user to edit the whole dataset in place due to high client load. Only several (1-5) features at once are changed. 3. When the editing operation is done and user is satisfied with modifications, data are sent back to the server. Communication between the server and the client will be provided using OGC WFS.

07 March 2013

47 of 44

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

Figure 29 Editing of vector data

07 March 2013

48 of 44

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

Figure 30 Data flow between HS Layers and Geoserver.

Layer hierarchy and thematic maps The map application enables user to create thematic map compositions using services published by GeoServer or any other OGC OWS server.

07 March 2013

49 of 44

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

Figure 31 User (or administrator) can create thematic maps (map compositions) using standard OGC OWS client, part of the mapping application.

The map application offers two ways how to look at the map content: • Logical view, where layers can be organized into groups and sub-groups, without impact in their physical order in the map window, and • Physical view – where user can change layer order and hierarchy. Created map compositions can be stored and recorded in metadata catalogue for later use (e.g. by another user).

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

07 March 2013

50 of 44

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

Figure 33 Changing the physical structure of displayed layers. In the "Physical view" tab, layers cannot be structured into groups, but their position in the layer tree (using drag&drop) can be changed.

METADATA EXTRACTOR Metadata extractor is a tool to extract available metadata directly from different files (documents, presentation, etc.), edit this metadata and publish metadata and files on an URM portal. It can also extract metadata (and then edit) directly from existing URL addresses and store metadata on an URM portal. Access to information is then through direct URL addresses. Currently the metadata extractor supports • publishing documents on the portal – users can select any type of file on their computer, extract and edit metadata and published this file on a portal; • publishing of links to existing Web pages only putting URL of Web pages to extractor; • or published directly new Web pages stored in Zip file. These Web pages are directly accessible through an URM portal.

07 March 2013

51 of 44

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

Figure 34 Metadata extractor

Networking Services and Invoking The HABITATS Reference Laboratory currently has two types of networking services: • Catalogue services • View services CATALOGUE SERVICES The Catalogue client allows searching through connected metadata catalogues by OGC CSW catalogue services. Data can be searched by text or by defined elements defined in various standards (including OGC CSW 2.0.2, AP ISO, INSPIRE). Basic elements are datasets and services. Basic elements can be extended by user demands but they are not searchable on other catalogues. While the initial version of catalogue services used cascading of multiple services, the current version supports adding services independently on each other. This application interacts with a map viewer and allows map services to be added into a map by just one click. Another interaction is with the metadata extractor. Documents or web pages stored by the extractor can be opened also by one click. Services can be added from list of predefined services or can be added by direct links.

07 March 2013

52 of 44

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

Technical description: • Written in PHP (server part), ExtJS Javascript framework (client part) • Client components (may be used separately): • Basic search form (search row) – provides basic Google-like fulltext search

Figure 35 Catalogue Search •

Advanced search form – over all INSPIRE queryables. User required queryables can be added.

Figure 36 Advanced search •

Result list – presents a brief record list from GetRecordsResponse from catalogue. Pagination and user-defined templates with different levels of detail are supported. Clicking on the record allows the user to get detailed metadata.

07 March 2013

53 of 44

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

Figure 37 Metadata Detail



Map panel – enables interactively enter search bounding box and shows spatial extent of found metadata records.

Figure 38 Metadata Spatial Exten

07 March 2013

54 of 44

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

Figure 39 Catalogue Client architecture

The Catalogue Client architecture is as shown: Its functionality includes: • Support of OGC Catalogue Service for Web (CSW) 2.0.2. • Support of csw:Record (Dublin Core) and gmd:MD_Metadata type names. • Multilingual user interface • Multilingual metadata records are displayed in actual user interface language. If not present, the main metadata record language is used. • Printing of metadata record (PDF format) • Mechanism displaying and linking coupled and aggregated resources (operatesOn for service, parent / children metadata and other types of link between metadata records). • Support for thesauri service (thesauri SKOS client) • Parallel searches across multiple CSW servers (each service may be presented in separate tab) • Adding predefined CSW or user defined • Caching results for better performance • Saving/restoring application status between page visits • Configurable integration with map viewers to display found on-line services (WMS, WFS) The catalogue client is an independent Metadata Management System that can be used for example with GeoNetwork.

Invoking of discovery services The reference laboratory uses its own catalogue, but there are also possibilities to invoke another catalogue from a remote platform into the system. There are two possibilities: • To harvest metadata into the reference laboratory. • To provide direct search of remote catalogues. For both possibilities it is necessary to register the remote catalogue in the metadata system of the reference laboratory. This can be done using the Import functionality of the remote catalogue services.

07 March 2013

55 of 44

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

Figure 40 Catalogue Import

After registration of these services, this catalogue could be used for harvesting or multisearching on the side of the Reference Laboratory discovery services.

Figure 41 Catalogue import

Experiences with sharing of metadata in INSPIRE and GEOSS and Super Catalogue implementation CATALOGUES INTEROPERABITY PROBLEMS During our testing of different “INSPIRE and GEOSS catalogues „we detected these problems in some implementations: 1. Not functioning catalogue (catalogue moved to another address, temporarily unavailable, password protected). 2. Catalogue does not implement properly CSW 2.0.2 (older version, errors etc…) or it is based on another standard 3. In current version of CSW 2.0.2 specification many things are unclear or missing so vendors implement them different way (e.g. harvesting of catalogues, behaviour of different typenames, queryables etc. ) 07 March 2013

56 of 44

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

4. CSW should support Dublin core (csw:Record), but other profiles are optional. There are implementations of ebRIM, ISO, FGDC and other. For INSPIRE ISO AP 1.0 is mandatory, but not all catalogues support it. 5. Protocols: CSW should support GET, POST and optionally SOAP protocol, for most implementations POST AND SOAP are used. Not all catalogues implements these protocols for GetRecord as well as GetRecordById operations. 6. Query languages. CQL and OGC Filter should be supported. Some catalogues has errors in implementation or does not support full language properties. 7. Queryables. There are mandatory set of queryables but INSPIRE requires additional queryables. Not all catalogues implements the INSPIRE queryables, we register some problems (response times, empty set of results) with some queries. Idea of Super Catalogue - SuperCAT There are many OGC web services available worldwide which may be widely use in different scale of applications. But if the SDI or other applications should be operable, it is crucial to have the services available and reliable all the time. In real life many problems have revealed regarding services access and operability: 1. Not all services have public metadata record to be found with. They are not catalogued. 2. If the services are registered on catalogues where may be accessed (e.g. OGC CSW, on portals etc.). Because of using “deep web” methods, occasional users are not able to simply search these resources by common search engines like Google or Bing. So the metadata are available only for users, who know the catalogue address or address of portal offering the human interface to catalogue. 3. Topicality of single catalogues. Many metadata records are not up to date and links to services are not valid in many cases. Sometimes the provided ULR links to web page or viewer rather than service connect point. 4. Some catalogues don’t respond. (The same problem like other services) 5. Services metadata are catalogued many ways, because there are no common “global” rules how to uniquely code some element e.g. serviceType and other elements. The query results may not give clean results. 6. If the services are running, the service metadata are very often quite poor, especially layers metadata URL are not available. CENTRAL CATALOGUE IMPLEMENTATION To provide our users clean access to running services, we attempted to build services metadata repository on our server. • The catalogue is CSW 2.0.2 ISO AP 1.0 compliant (MICKA) • Supports INSPIRE metadata profile and queryables • Enables to register remote catalogues and harvest them periodically (Figure 1) • Enables to harvest other services (WMS, WFS, WCS, CSW) and individual metadata files • Enables monitoring registered services if they are running properly (Figure 2, 3) Processing: • These metadata catalogues were registered to catalogue for harvesting in first phase: 07 March 2013

57 of 44

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

o ISPIRE national nodes: Austria, Belgium, Czech republic, Finland, France, Germany, Luxembourg, Poland, Portugal, Slovakia, United Kingdom o CIDP o EEA SDI o ENVIROGRIDS o EuroGEOSS o GEOSS o HABITATS o One Geology Europe o Plan4all o WHO • The resources are harvested daily with filter to services only (type=service) • Harvest protocol is generated for checking the availability of the catalogues. Mail notifications are sent to corresponding users to ensure feedback. • Test of availability is performed for all services daily (only WMS at this phase). It the service is not running, the corresponding metadata record is not deleted but only hidden for the case the service is temporarily not available. So next day the record may be set to public if the service is alive again.

Figure 42 SuperCat harvesting

07 March 2013

58 of 44

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

Figure 43 Micka harvesting configuration

07 March 2013

59 of 44

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

Figure 44 RSS channel – harvesting results

Figure 45 Heartbeat protocol

07 March 2013

60 of 44

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

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 Responding (%) (count) 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-getcapabilities, but it varies from service to service) PRACTICAL RESULTS Central catalogue enables smooth access to dozens of services on one portal. We also provide mobile solution, where the SDI may be simple accessed from mobile devices.

07 March 2013

61 of 44

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

Figure 46 Portal – metadata catalogue client

Figure 47 Mobile catalogue client

07 March 2013

62 of 44

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

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, 07 March 2013

63 of 44

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

PNG, ...), web services (OGC WMS, OGC WFS, ...), various vector formats (KML, GML, GeoRSS, ...), proprietary formats (Google maps, OpenStreetMap, ...), working with projections and great user experience with the map. ExtJS was used because of its well design and source code structure, which enables to create various elements of UI (panels, tree structures, grids, forms), in a very simple and fast way. HSLayers are designed as set of basic stones and components, which can be put together and custom application can be build. There are provides such top all-including class, which incorporates nearly all features of HSLayers: MapPortal.

Figure 50 HSlayers Map Portal

The HSLayers18 set of tools is used in new generations of map applications, and includes: • HSLayers Components • HSLayers Portal • Server scripts (Transformation, Print) • Editing with HSLayers • Special HSLayers.Layer.MapServer type From a developer’s point of view, HSLayers/OpenLayers is a pure JavaScript library for displaying map data in most modern web browsers, with no server-side dependencies. OpenLayers implements an object-oriented JavaScript API for building rich web-based geographic applications, similar to the Google Maps and MSN Virtual Earth APIs. OpenLayers can display various types of raster and vector data formats. It inherently supports OGC WMS specification, as well as common Image formats (in PNG, GIF or JPEG format). There is also support for multiple proprietary formats, such as Google Maps, Yahoo maps and 18

http://redmine.ccss.cz/projects/hslayers, see also http://gis.vsb.cz/GIS_Ostrava/GIS_Ova_2010/sbornik/Lists/Papers/EN_2_11.pdf

07 March 2013

64 of 44

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

others. OpenLayers uses tiling of raster data. A numbers of vector (and text) data formats are also supported. The system allows the rendering of vector features in GML, OGC WFS, GeoRSS, KML formats. Creation of regular shapes (boxes, circles, ...) is also supported. Points can be displayed as special point features with image icon or vector point features. Many controls are available to support map interactivity and customization. Among others, these include: zoom bar, overview map, layer switcher, various toolbars and mouse action handlers can be used. Thanks to its advanced event model, custom map control can also be readily programmed. (Cepicky et al. 2008). So it is an ideal platform for the HABITATS RL to support all of the possible Network Service requirements of the pilots. HSLayers features are coming up from OpenLayers and therefore their characteristics are as follows: • Portrayal of various types of data: o Raster: OGC WMS(-T), Image (PNG, JPEG, GIF), … o Vector: OGC WFS(-T), GML, GeoRSS, KML, GPX, GeoJSON, … o Data sources from commercial servers: Google Maps, Virtual Earth, Yahoo Maps, …

Map

Figure 51 Map Window

07 March 2013

65 of 44

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

HSLayers.MapPanel is container for the map. The map usually interacts with the user through mouse gestures, so it zooms in/out, pans etc. There usually is graphical tool for setting the desired region - bar for panning and zooming. Several other tools, which do enable the interaction with the map are available too, namely zoom history, measuring of lines and areas, tool for querying the layers and other custom tools. Tools for working with the map content, such as saving/restoring web map content (WMC) files, printing the map content or generating the permanent link for current map state are available too. MapPanel contains various map layers, it enables to the user to work with the map (zooming, panning, ...). Zoom bar together with overview map are available. Tools for direct interaction with the map are available too, such as navigation, navigation history, measuring, querying and others. The top toolbar and bottom toolbar are used for other informative tools, or tools for working more with the map content, than in the map itself. We can see buttons for saving and restoring OGC WMC files, printing, permanent link generator, scale, mouse position and copyright information.

Layer Switcher With LayerSwitcher, user can change visibility of available layers, change their order in the layer stack, set transparency and other features and use shortcut links to layer metadata or remove them from the map. LayerSwitcher is one of the most complex components of HSLayers. We do introduce two different views at the layer stack: the physical structure and the logical structure.

Figure 52 Physical and Logical Structure

07 March 2013

66 of 44

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

LOGICAL STRUCTURE Represents the view on the application, where layers are organized into groups (or folders) according to some user-defined logic. Layers can be sorted into folders according to their original service, or based on their content Physical structure corresponds with the layer stack, how it is displayed in the map. User can change layer order (using drag & drop) etc. LayerSwitcher is able to display also legend to all layers, perform user searches in the layer stack, display basic information and settings in the layer menu (such as abstract, scale range, title, ...). User can move the layer, drop the layer or change layer’s name. There is also basic work done, on WFS filtering, SLD defining, transparency settings etc. User can use several shortcut links to layer’s metadata, copyright information and others. The Layerswitcher also uses 3-state checkbox. Every folder checkbox has three states - on (all layers within the folder are visible), off (everything is invisible) and custom.

OWS HSLayers contains complex OGC OWS client, which is capable to work with OGC WMS data directly, with OGC WFS and OGC WCS via server-side script Proxy4ows. HSLayers contain mechanism, how to read parameters from URL directly, so the application can start with OWS Client opened and Capabilities document parsed.

07 March 2013

67 of 44

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

Figure 53 HSLayers.OWS - Open Web Services client

Working with OWS Client is straight forward - user gives the URL, where the service is running and type of the service (usually OWS). After capabilities are loaded, form with service parameters is displayed (image format, query format, etc.) together with layer tree, where several layers can be checked. Service metadata (service provider, abstract, title, etc.) are displayed in separate tab. After that, layers can be added into map. When user wants to display some on-line available files, such as GeoRSS, GML, KML or similar, she just need to specify the URL and file format. After that, user is requested for the layer name and it is added to the map as well.

Printing with HSLayers HSLayers includes printing setup, so that content of the map can be printed at any printer or used in other desktop GIS workstation. The printing client enables the user, to choose between printing a map to a pre-defined template (PDF or HTML output) or saving the content of the map into a raster image (image output). When the user makes a choice, that he wants to create a raster image with the map’s current content, he can either directly click the button, and a copy of the map window will be 07 March 2013

68 of 44

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

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 HTMLbased, and they are converted from HTML to PDF using webkit renderer.

07 March 2013

69 of 44

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

Figure 55 Printing Result

Printing result - based on given HTML template with several additional keywords (easy to setup for everybody), user will get PDF output with title, map, legend and overview map rendered.

Web Map Context The important new issue is the support for Web Map Context (WMC). Web Map Context (WMC) describes how to save a map view comprised of many different layers from different Web Map Servers. A ‘context’ can be encoded and saved so that Web maps created by users can be automatically reconstructed and augmented by the authoring user or by other users in the future. A Context document is structured using eXtensible Markup Language (XML). Potential uses for context include creating default initial views for Web maps for different hazards, saving the state of a user’s work on a viewer client to preserve information such as how geospatial layers are added or modified, and saving the state of a client session for sharing with other users. This mechanism is valuable for efficiently communicating across shift transitions. Also, context documents can be catalogued and discovered for reuse by others •

Define WMC on the base current composition on portal



Save composition on local disk



Save composition with metadata on server

07 March 2013

70 of 44

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



Open composition from local disk



Open composition from server



Open composition from remote servers using metadata description

The implementation of the WMC concept presents a new way to the future upcoming solution, when the system will support easier collaboration and sharing of results. It also supports the reuse of results of work done on portal by other applications.

07 March 2013

71 of 44

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

Figure 56 Web Map Content Editing

This figure represents the basic configuration of form, which will save (to local drive, not upload to some server-service) WMC file, containing information about current map composition. OGC WMC is rather old standard, which does not support all possible types of layers, which

07 March 2013

72 of 44

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

can be displayed in HSLayers. On the other hand, it is only one standardized format. For saving map content more precisely, we’ve developed custom JSON format, which is used among others in Permalink. The main disadvantage of WMC is, that is is able to store WMS and WFS layers only, while having Image, WMST, Raw vector data and other layer types in the map. For storing complete web content, including user-defined data, Permanent link can be used.

Permanent link Users often spend hours with creating ideal map compositions, based on various web services, custom user graphics and other data sources. How to save the map content? Another issue is, how to send custom map composition, or just simple user graphics (e.g. parcel specification), zoomed into particular location? For this, permalink has been developed. Unlike permalink which is wildly used among various mapping applications, we cannot store information about displayed layers into the map’s URL. For this purpose, special JSON structure with the map content is stored on the server. The file can be also downloaded to local hard drive. Unlink OGC WMC (which is supported by HSLayers too), every layer type displayed in the map can be stored into this structure. User sends just the link to another user, and whole map content will be reconstructed at the other computer.

Figure 57 Permanent Link

Permalink window, which is displayed after copy of current map content is saved to the server. User can now download the JSON structure or send the link to another user.

Embedded Some users do want to prepare their map composition and display the result in their own web page. For this purpose HSLayers Embedded is here. It generates HTML snippet, which can be add to any web page and after the page is re-loaded, map pops up. 07 March 2013

73 of 44

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

Embedded uses same JSON format for saving the structure of the map content, as for example Permalink does. All layers displayed in the map portal are transferred in to the embedded map. This particular component needs little PHP-based script, which generates the desired form of embedded map. Pure HTML, Simple ExtJS and Advanced ExtJS output are supported, based on the complexity, the user wants to have the resulting map.

Figure 58 Embedded

Form, which generates HTML code, which can be later used in user’s web page.

Querying displayed layers HSLayers.Control.Query is tool, which enables to the user to point with mouse in the map at some place and perform spatial query. Following layer types are queryable: •

OGC WMS with capability to display information in text, html, GML or other format



Vector layer of any type, such as KML



Proprietary MapServer layer (not only point, but also box query is allowed).

It works in very straight-forward way. User does not need to take care about layer query type or server output format. HSLayers tries to display result of the query in a grid form, if possible. All visible layers are queried automatically. Along with query result, mouse position is displayed as well, so that user can copy and re-use it.

07 March 2013

74 of 44

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

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

User graphics and measuring HSLayers do offer possibility of measurement of lengths and areas. Unlike most other systems, HSLayers do enable to the user to measure several objects at once - not only one line can be drawn, but many. User can also combine lines with areas. HSLayers extended the measuring function into the user graphics concept. User can draw any geometry feature, set its attributes. Along this, areas are lengths are calculated and continually recalculated. Use can draw new graphics, delete existing once, set attributes (simple or complex). Resulting graphics can be printed or used in Permalink or Embedded map.

Figure 60 User graphic

Several geometries with their dimensions drawn in user graphics layer.

07 March 2013

75 of 44

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

OGC Web Processing Service client HSLayers contains first version of generic OGC WPS client. Client is able to parse GetCapabilites response, generate form for input data on-the-fly and submit the Execute request. User can at the end download the resulting data. Since the standard is very vague in some cases, and server-side implementations are changing a lot in the time, it is always necessary to test the client against particular server and eventually fix some issues. When dealing with ComplexInput data, HSLayers WPS client is able to send any type of Vector layer displayed in the map, as well as send direct link of WFS GetFeatures or WCS GetCoverage request. User can also draw custom graphics and send the data to the server, to be analysed. When data are returned back, user can either add them to the map, or download them directly.

Figure 61 OGC WPS client

Generic WPS Client with on-the-fly generated form for data inputs for the Buffer process.

07 March 2013

76 of 44

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

. Figure 62 Image classifcation

Simple presentation of OGC WPS - satelite image classification.

Figure 63 Buffering

Complex presentation of OGC WPS client as well as functionality of Proxy4OWS

Server-side scripts Although HSLayers can be considered as pure JavaScript library, it is designed to work with several server-side components (scripts), which are enabling more advanced features, such as •

warping script for on-the-fly raster data projection



printing script for creating hard-copy maps

07 March 2013

77 of 44

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



ability to work with OGC WCS and WFS services



session management



OGC WMC handling

HSPROXY HSProxy is Python script, which enables calls from the map application to various remote servers, for example to WMS server, which is (for security reasons) not possible to do directly. For this purpose, little server-side proxy script needs to be setup, which performs this remote-call operations. HSproxy deals as proxy for Ajax calls from JavaScript to various remote servers (used for Query, WMS, ...). It also converts mimetypes headers of coming XMLs, to text/xml, so that browsers can read it and parse them easy. Often it is the case, that for examples WMS Capabilities document, which is returned by the server has different header, which is not recognized by the web browser as simple XML file, and parsing is than very difficult. Converts coming files from various encodings to UTF-8, to make sure, every response from the server, using various encodings, is displayed correctly in the map.

StatusManager server script Status Manager is PHP script, which •

Reads and writes state of the map (using PHP Session id and JSON format with description of the map content), so that user, while page reloading, gets the state, she got before leaving.



Is used as server-side file-handler. Often we need some data, to be offered to the user as file for downloading. Or user sends file, and we need to get its content. This simple script enables this javascript file object connection.

When user needs to upload an image or for example GeoRSS file, which needs to be displayed by the map, certain server-side interaction (but very small one) is needed. StatusManager is helping us to provide such interaction. PROXY4OWS In the web environment, we are are often facing a problem, how to display data, which are not suited for direct visualization (for example large GeoTIFF files). Proxy4OWS tries to overcome this problem. It generates OGC WMS service from OGC WCS, WFS or even from another WMS on-the-fly. This generated WMS can be then consumed by any WMS client easy. Reason for this is, wen so display large vector data (produced by WFS servers), large raster GeoTIFFs (produced by WCS servers) and data, services, which coordinate reference system does not correspond with client’s coordinate reference system (in case of some WMS servers).

07 March 2013

78 of 44

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

It is written in python, using standard MapServer and GDAL components.

Figure 64 Sequence diagram of proxy4ows shows the negotiation between the client, proxy4ows middleware and the target server.

Invoking with HSlayers INVOKING OF VIEW (WMS) SERVICES The WMS services can be invoked into the visualisation client in two ways: The first is to discover WMS services from catalogues and visualise WMS services directly from catalogues.

Figure 65 Invoking from catalogue

The second possibility is to add the WMS URL directly to the visualisation client HSlayers. The URL could be added using OWS services.

07 March 2013

79 of 44

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

Figure 66 WMS invoking

WMS COORDINATE TRANSFORMATION In the real-life, we are often facing a problem, how to display map from the server, which does not support coordinate system of the displayed map. This is implemented with help of Proxy4OWS (described later in this document). It is assumed, that Capabilities document is already parsed, it is expecting GetMap request from the client to Proxy4OWS directly. The GetMap request is expected to have - next to original WMS parameters - also three add-on options: - owsService - this is going to be WMS - owsUrl - URL of the original service, which is expecting to handle the GetMap request - fromCRS - CRS of the original coordinate system, from which shall the result of GetMap be transformed to. Proxy4OWS generates MapServer's mapfile on-the-fly. Only one layer is attached to the mapfile - layer of type WMS. MapServer then formulates the necessary request, fetches the data from remote server and provides image transformation on them. Result is always little bit distorted, because the resolution is not always fine enough, but the it can be used and displayed in the mapping application.

07 March 2013

80 of 44

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

Figure 67 WMS Sequence diagram.

Figure 68 WMS transformation result - left map coordinate system, right - transformed result from EPSG:4326 source.

07 March 2013

81 of 44

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

Thanks to Proxy4OWS, we can now display seam-less data from several WMS resources, which do not support coordinate system of the map, displayed in user's browser. INVOKING OF MAP COMPOSITIONS – WEB MAP CONTEXT The important new issue is the support for Web Map Context (WMC). Web Map Context (WMC) describes how to save a map view comprised of many different layers from different Web Map Servers. A 'context' can be encoded and saved so that Web maps created by users can be automatically reconstructed and augmented by the authoring user or by other users in the future. A Context document is structured using eXtensible Markup Language (XML). Potential uses for context include creating default initial views for Web maps for different hazards, saving the state of a user's work on a viewer client to preserve information such as how geospatial layers are added or modified, and saving the state of a client session for sharing with other users. This mechanism is valuable for efficiently communicating across shift transitions. Also, context documents can be catalogued and discovered for reuse by others; this allows analysts to benefit from lessons learned in previous episodes. 19 In URM there is now implemented strong support for discovery and defining new WMC based on information displayed on portal. The system allows to: • Define WMC on the base current composition on portal

Figure 69 Composition Saving

• Save composition on local disk • Save composition with metadata on server • Open composition from local disk

19 http://www.eu-orchestra.org/TUs/Standards/en/html/Unit4_learningObject6.html

07 March 2013

82 of 44

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

Figure 70 Open Composition from local disk

• Open composition from server • Open composition from remote servers using metadata description The implementation of the WMC concept presents a new way to the future upcoming solution, when the system will support easier collaboration and sharing of results. It also supports the reuse of results of work done on portal by other applications. INVOKING OF WFS AND WCS For the invoking of WFS and WCS for visualisation proxy4ows is used. When working with large vector datasets, we are usually facing limits of current browsers. Google Maps 1 for example has limited the number of displaying vector features to 1000. In OpenLayers 2, there is no limit for the number of features used, but displaying e.g. cadastral map makes browsers often freeze. An advantage of working with vector data directly is (among others), the direct possibility of editing vector data, a more interactive way of user experience and speed (when dealing with reasonable amounts of data). While vector data can be displayed using current technologies, some popular raster data formats, such as GeoTIFF, cannot be. According to W3C , only few formats for raster data are supported, none of them is really used or usable in GIS, usually because of the compression method they are using. In the internet, raster graphics format focus on possibly low amount of data transferred from the server to the client, while losing the accuracy of the data being transferred. In GIS, we are focusing on data quality, regardless of file size. Raster and vector data are usually distributed using OGC OWS standards. Vector and raster data are distributed via OGC Web Feature and Raster Service respectively. Both services are offering lists of datasets and metadata. Another problem might occur, when some OGC Web Mapping Service does not offer a coordinate reference system, in which the web mapping application is configured. Some middle-ware has to be established between the map application and the server, which will transform the images from server coordinate reference system to the one accepted by the client. Proxy4ows is a server script, which is between the client mapping application and OGC OWS server (WCS, WFS or WMS). It is transforming OGC WMS request types from the client, into WCS or WFS requests, so that the target server can accept them. On the way back, it downloads the data distributed by the server (raster or vector), creates image and sends it back to the client. It also transforms the GetCapabilities request-response pair, so that the (WMS) client can deal with it. As result, data is processed on the server, into the form, common web browser mapping application are able to display without big demands on system resources.

07 March 2013

83 of 44

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

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. 4

http://mapserver.org http://gdal.org 6 http://sourceforge.net/apps/trac/owslib/wiki 5

07 March 2013

84 of 44

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

GetMap

When a GetMap request arrives, an image is generated based on the previously generated mapfile, using OWSDispatch method. At this point, a WFS filter is applied, if the target server is WFS. In both cases, Proxy4ows is looking for existing MapServer MapFile (it creates one, if it does not exist) and lets MapServer do the work. Proxy4ows takes care of the proper MapFile configuration.

Figure 72 Get Map Scheme

When a WMS GetCapabilities request arrives, OWSProxy generates a MapFile with list of layers, corresponding to either feature types (WFS) or coverages (WCS) of the target service. For configuring the MapFile properly, GDAL, OGR and OWSLib libraries are used. WFS Layers are configured, using MapServer as WFS Client, while WCS layers are using GDAL as WCS Client. Then MapFile is generated, OWSDispatch method is called and the Capabilities response arrives.

07 March 2013

85 of 44

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

Figure 73 OWS Dispatch

When the WMS GetMap request arrives, OWSProxy finds the existing MapFile (creates it anew, if it does not exist) and performs OWSDispatch function of MapServer, which generates the output image and sends it back to the server.

Invocation Proxy4ows was originally designed as a WMS server. But it can also be used as WFS or WCS server, so that it can only transform original data into a coordinate system unsupported by the target server. Therefore, the client can use basically any type of OWS request using proper parameters. In addition to this, two more parameters will have to be appended to the request URL: • owsservice notes the target server service type (WCS, WFS or WMS) • owsurl is the URL of original server FILTER ENCODING FILTERING WFS LAYERS Filter Encoding is an Open Geospatial Consortium standard20 defining the syntax of expressions used to filter data provided by the geospatial web services. It describes a rich predicate language that enables to filter data based on their IDs, type-specific properties, geospatial properties, and to combine filters using logical expressions, call server-defined functions, encode arithmetical expressions and more. Filter Encoding is defined in XML. Often it is referred to as FE or FES, with S standing for 'Standard' or 'Specification'.

FE Examples:21 Simple comparison filter can look like that: 20

http://www.opengeospatial.org/standards/filter

21

All the examples in here are using FES 1.1.0, unless specified otherwise

07 March 2013

86 of 44

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

DEPTH 20 Example 1. Spatial filter can, among other things, define a polygon that the desired features should overlap: Geometry ... Example 2. Logical filter allows to combine filters: ... ... Example 3. More examples can be found in the Filter Encoding standard. FILTER ENCODING AND WFS Filter Encoding was originally designed as part of the Web Feature Service standard, but then it was separated into a standalone document as it can serve also for filtering of other services, such as Web Coverage Service, Gazetteer or Web Registries . When filtering data is provided by Web Feature Service, several WFS operations are involved: GetCapabilities As a part of GetCapabilities response, Filter_Capabilities of the server are announced. This 07 March 2013

87 of 44

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

section specifies the filter capabilities of the particular server. It can look as follows: gml:Point gml:LineString gml:Polygon gml:Envelope LessThan GreaterThan LessThanEqualTo GreaterThanEqualTo EqualTo NotEqualTo Like Between SIN COS TAN Example 4. DescribeFeatureType Properties that can be used to filter features of a specific type are advertised in the response to the DescribeFeatureType request. In the example below, four properties can be used to filter

07 March 2013

88 of 44

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

the features of the type location: DEPTH, SURFACE, AREA and CODE. 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/cgibin/ows?REQUEST=GetFeature&VERSION=1.1.0&SERVICE=WFS&TYPENAME=locatio n&FILTER=D EPTH20 Example 6. In the HABITATS Geoportal, Filter Encoding is used to filter WFS layers. To do it, first add a WFS layer to your map. Then right-click on the layer name in the Layer Switcher and select Filter:

07 March 2013

89 of 44

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

Figure 74 Geoportal, Filter Encoding

The filter window appears with a form for simple comparison filter. From the first drop-down list select a property that will be used for filtering (these have been parsed out from the DescribeFeatureType response). From the second drop-down list select the operator that will be used. (The list of available operators has been parsed out from the GetCapabilities response.) In the text field the value to compare it with is entered. Click 'Apply' and the layer will be filtered.

07 March 2013

90 of 44

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

Figure 75 Filter Encoding

Implementation of the Filter Encoding is shown on the following illustration:

Figure 76 Filtering of WFS

The processing works as follows: WFS layers are displayed as WMS in the HSLayers Web Client (see Proxy4ows for details). 1. WFS GetCapabilities request is sent directly to the WFS server. Capabilities document is parsed and filter capabilities are saved. 2. WFS DescribeFeatureTypes request is sent directly to the WFS server. Reply is parsed and properties of the feature type are saved. 3. User creates the filter in the GUI, saved information from steps 1-2. is used. 07 March 2013

91 of 44

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

4. User-created filter is written to FES and new WMS request is sent to Proxy4ows, accompanied with the filter in an additional parameter. 5. Proxy4ows takes the filter, creates new WFS request involving the filter, and sends it to the WFS server. Server replies with filtered layer. 6. Proxy4ows transforms the returned WFS layer to WMS and sends it to the client. WPS INVOKING In HSLayers, a new class WPSClient was introduced. The class implements generic OGC WPS client with graphical user interface. HSLayers WPSClient performes GetCapabilities request on the server and creates a list of available processes. Processes are rendered into a drop-down menu. When a user chooses the process he wants to run, DescribeProcess is called. Based on ProcessDescription response, a generic input form is generated. After all input data is specified, and when users click the button, an Execute request is called, and when it is finished, an execute response is parsed and outputs of the form are filled. Complex input and BoundingBox input are relatively easy to be implemented. Writing the complex data handler in the web environment is a real challenge. Generic HSLayers WPS Client. Form is generated automatically.

Figure 77 WPS Invoking

First, input is identified as raster or vector. Then, the map layers are scanned and HSLayers.Layer.WCS (for rasters) HSLayers.Layer.WFS and OpenLayers. Layer.Vector (for vectors) are identified and added to the drop-down select box. The Custom URL option is attached, for custom raster or data link pasting (e.g. for direct WFS or WCS request) and, if the input data shall be vectors, also Custom drawings option is added, so that the user can define some geometry on the map by hand. When an Execute request is called, HSLayers collects URLs for HSLayers.Layer.WFS or HSLayers.Layer.WCS with GetFeature or GetCoverage request types – the client is not sending the data, but only reference to the data (which is possible according to OGC WPS). HSLayers.Layer.WFS and HSLayers.Layer.WCS are special types of layers, used in HSLayers. They are based on OpenLayers.Layer.WMS class, but they are not working with WCS or WFS server directly, but communicating via server-side proxy called Proxy4ows

07 March 2013

92 of 44

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 22

[6] (more on other place). Proxy4ows is sitting between the client (generic web browser) and the server (WCS or WFS) and is transforming the requests and responses into a form that can be handled in the web environment. GeoTIFFs are transformed into PNG and JPEGs, GML's are transformed into picture (PNG) form. Using this approach, there is virtually no limit to the amount of features, which can be displayed in the client or any image format issues.

Figure 78 Proxy

HSlayers.Layer.WCS and WFS are derived from Layer WMS. As a proxy between the client (the map) and the WFS|WCS server, Proxy4ows is placed. Proxy4ows transforms the WMS requests coming from the client into WFS|WCS calls and also the responses are transformed to WMS responses or images, displayable in the web browser. Features in vector layers (which are handling vector data, not raster representation) are transformed into the format, desired by the user, according to the server-supported MimeType (this is very vague estimation, see above). Usually this is GML and the data are then sent to the server as part of the XML-encoded request. When a response arrives, HSLayers WPSClient does prefer reference to output data, so it can be handled more easily (as Reference=True). When vector data are send back (usually in GML format), they are added to the map as features of OpenLayers.Layer.Vector. The GML is parsed using OpenLayers tools. Direct link for downloading is also provided. Raster data (usually GeoTIFFs) are only available for downloading. Client does not send a direct link to the original WFS or WCS server, but the link to Proxy4ows. One of key features of Proxy4ows is, that it ensures the data it is providing will 22

http://redmine.ccss.cz/project/owsproxy

07 March 2013

93 of 44

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

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 measurementdata via a spatio-temporal query that can be filtered by phenomena and value constraints Future versions of components will contain also operations from OGC SOS Enhanced Profile and will offer more functionality for working with data from OGC SOS services. How does it work • User invokes HSLayers SOS Client UI dialog • User inputs URL of required OGC SOS • HSLayers SOS Client sends GetCapabilities request to OGC SOS, parses its response and displays available information about OGC Service (name, abstract) in UI

07 March 2013

94 of 44

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

• User selects offering and all parameters for required observations (procedure, observed property, date-time interval) • User invokes getting observations • HSLayers SOS Client sends GetObservation request with all passed parameters to OGC SOS, parses its response and display all obtained data in table and chart • If HSLayers SOS Client is used within map application based on HSLayers, user can displays location of obtained observations in map

Figure 79 HSLayers SOS client

HSLAYERS EMBED COMPONENT HSLayers contains the component Embed for inserting map into any HTML pages. User can create a map in a Geoportal or in any map application which is based on HSLayers and 07 March 2013

95 of 44

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

contains the Embed component. Users can also define parameters which affect how the map will be look in the target HTML page. There are three types of a resulting inserted map window: • Pure HTML – this type is based on pure HTML and does not contain any other UI components • Simple ExtJS – this type uses ExtJS library for generating UI container • Advanced ExtJS – this type uses ExtJS library also as Simple ExtJS type and also contains another UI components (tree with list of all layers in map) The HSLayers Embed component consists of several parts on the client and on the server side. • Embed Generator – this part is responsible for displaying the UI form to enter the parameters affecting the resulting inserted map window. When the user enters all required parameters, the actual map is serialized and sent to the Status Manager on the server. The Status Manager is an external service which is responsible for saving actual state of any component and getting it back later. • Embed Client – this part is responsible for rendering map windows in target HTML page in dependence on parameters entered by user. • Embed Script – this part is responsible for rendering main HTML part of map window and for calling Embed Client in target HTML page.

Figure 80 HSLayers Embeded

Generating HTML code 1. User invokes UI to enter the parameters of inserted map window. 2. User inputs parameters affecting map window (type of map window, size of window). 3. Embed Generator serialize actual map and send it to Status Manager. 4. Status Manager returns URL for later accessing state of actual map (when it will be rendered in target HTML page). 5. Embed Generator returns complete HTML code. User can paste this HTML code to any HTML page.

07 March 2013

96 of 44

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

Figure 81 Rendering Map

Rendering map window in target HTML page 1. Target HTML page renders initial JavaScript code which creates new IFRAME element. URL of this IFRAME element is set to Embed Script and contains all parameters. 2. When IFRAME is activated, the Embed Script is called. The Embed script generates the main part of HTML code for IFRAME. This HTML code contains references for all required JavaScript files and Cascade Style Sheets (CSS) files. These files are different in dependence on type of map window. 3. HTML code in IFRAME calls the Embed Client for creating the map window. 4. Then it reads the state of the map from the Status Manager and restores the complete map from this state. MOBILE SOLUTIONS FOR RL Massive mobile technologies growth during last few years brings brand new view on GIS technologies. Location based services and spatial information comes to everyday life for everybody. It is a big challenge for classical GIS technologies. New areas of applications reveals for wide community of users. The INSPIRE and mobile mapping apps infrastructure differs in many thing in philosophy, application area and technical solution. (table 2).

07 March 2013

97 of 44

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

Features Formats, protocols Standardization Projections Users

INSPIRE Based on heavy formats (SOAP, GML, WFS, WCS, CSW, …) Standardized services (OGC, ISO) European (LAEA, LCC, …) For “experts” - government, EU comission Application area Environment, administrative Difficulty Difficult to use Open system Open possibilities of view different maps Typical app Map portal Network traffic On-line / offline Unsaid purpose

Existing mobile map apps Lite formats (JSON, KML, GeoSMS) Proprietary services (Google, Apple) Universal (Spherical Mercator) For “ordinary people” Navigation, entertainment Easy to use Bind with proprietary (licensed) maps

heavy On-line

Single purpose map app (e.g. navigation) Optimized for slow networks Mixed, e.g. caching tiles on device

European real estate market

Big brother ? / advertising

Table 2 Comparison of INSPIRE solutions and current mobile solutions

The challenge is how to connect both these worlds. INSPIRE may bring many useful data for everybody to mobile apps (e.g. cadastral maps), on the other hand ease of use and low costs may be challenge for experts for specialized apps, e.g. data capture and other field work. So we need to build some bridges for mobile apps to access INSPIRE infrastructure. On other hands social networks and mobile apps may contribute SDI with user data (e.g. illegal dumps, water quality monitoring, …). Android “Google maps” (used in Irish pilot) application is limited for use (maps licensing, proprietary formats), so we looed for alternative which enables users to support more functionality. For Reference Laboratory we choose popular tourist app Locus https://play.google.com/store/apps/details?id=menion.android.locus.pro&feature=more_from_ developer#?t=W251bGwsMSwyLDEwMiwibWVuaW9uLmFuZHJvaWQubG9jdXMucHJvIl 0 ). Because of primary application area, it is widespread (500 000-1 000 000 installations worldwide) and it has very rich functionality given by log-term development based user community discussion. It provides published API which enables control the application from other apps and write own extension. We developed these extensions to enable work with INSPIRE infrastructure • •



Catalogue client Cadaster info (https://play.google.com/store/apps/details?id=cz.hsrs.parcelinfo&feature=search_result#?t=W 251bGwsMSwxLDEsImN6LmhzcnMucGFyY2VsaW5mbyJd ) Online feature editing (not published yet)

With using these tools typical work flow may look this way: 1. User opens the map and zoom to his location than presses catalogue client button 2. Catalog client opens with selected coordinates. Alternatively user may edit the coordinates and enter other search criteria 3. After pressing search button the result list is displayed 07 March 2013

98 of 44

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

4. User may see metadata detail on next screen 5. If the corresponding service is available on-line, the map button enables to go to Locus app and show it on the map. The GetFeatureInfo and GetLegendInfo operations are also supported.

Figure 82 Locus map app, Catalogue client

07 March 2013

99 of 44

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

Figure 83 WMS displayed in Locus app, map legend

Cadastral info application is based on cadastral map WMS and WFS provided by Cadastral office of the Czech Republic. It enables see property information and search for cadaster parcels in the map

Figure 84 Parcel Info app

07 March 2013

100 of 44

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

Using KML as common format The KML is another OGC format not used in INSPIRE now. The advantage of KML over WFS is • Common use in Google Map apps (desktop and mobile) • Adoption in other software (Geoserver, Mapserver, ESRI, OpenLayers, Locus…) • Scalability, simple implementing of time series etc… • Symbology may be wrappend together with data • Using of W3C CSS rather than OGC SLD for symbology KML may be used as common format for mobile apps rather than INSPIRE supported formats. There are two ways how to implement it: 1. Direct support of servers as alternative to WFS/WMS (Geoserver) 2. Thru conversion modules which on-fly transform provided WFS/WMS/SLD to KML When KML is available, it is compelling to register it the same way in catalogue as other services with services metadata. Than it may be searched and displayed simple way.

Figure 85 KML metadata in the catalogue client

07 March 2013

101 of 44

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

Figure 86 Displaying KML in Google Maps and Locus

Field editing Big mobile apps advantage is possibility to capture field data simple way and low cost. Because lack of mobile signal coverage in some areas or no mobile internet account, several alternatives form mobile data captures should be taken into account: • Off-line editing. Data are stored on device, posted to server when connection is available or manually at home. • On-line editing - when internet connection is available. • SMS – when no mobile internet is available and quick response is required. All of these alternatives will be probably combined depended on application in real life.

07 March 2013

102 of 44

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

Figure 87 Simple mobile editing application

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

07 March 2013

103 of 44

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

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-touse way of specifying the tasks that have to be performed during a specific in silico experiment. The need to combine several tools into a single research analysis still holds, but technical details of workflow execution are now delegated to Workflow Management Systems. Business Process Execution Language Business Process Execution Language (BPEL), short for Web Services Business Process Execution Language (WS-BPEL) is an OASIS standard XML based executable language for specifying actions within business processes with web services. Processes in Business Process Execution Language export and import information by using exclusively web service interfaces. It defines a set of basic control structures like conditions or loops as well as elements to invoke web services and receive messages from services. BPEL's messaging facilities depend on the use of the Web Services Description Language (WSDL) 1.1 to describe outgoing and incoming messages. Message structures can be manipulated, assigning parts or the whole of them to variables that can in turn be used to send other messages.

07 March 2013

104 of 44

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

ENGINES AND WORK-FLOW MANAGERS To make tests we collected several workflow execution engines and managers. From the collected engines the biggest part is using BPEL and only one of the solutions is oriented on data flow execution.

Apache ODE  Name: Apache ODE + Eclipse Plugin  Version: 1.3.5  Platform: Java  Standards: WS-BPEL 2.0  Vendor: Apache Software Foundation, OASIS  Licence Apache ODE: Apache Software License (ASL), version 2.0.  Licence Eclipse BPEL: Incubation phase, version 0.5  Homepage: http://ode.apache.org/ Apache ODE (Orchestration Director Engine) executes business processes written following the WS-BPEL standard. It talks to web services, sending and receiving messages, handling data manipulation and error recovery as described by your process definition. It supports both long and short living process executions to orchestrate all the services that are part of your application. ODE comes with easy to use web-based management interface (Figure 1). Ode can be deployed in three different environments:  As a simple Web Service in Axis 2, ODE is bundled in a WAR than can be deployed in any application server and is invoked using plain SOAP/HTTP.  As a JBI service assembly, ODE is bundled in a ZIP that can be deployed in any JBI container and is invoked using the NMR.  SMX4 OSGi bundle

Figure 89 Apache ODE

Orchestra  Name: Orchestra 07 March 2013

105 of 44

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

 Version: 4.7.1  Platform: Java  Standards: WS-BPEL 2.0  Vendor: OW2 - Object Web  Licence: LGPL 2.1  Homepage: http://orchestra.ow2.org/ Orchestra is a complete solution to handle long-running, service oriented processes. It provides out of the box orchestration functionalities to handle complex business processes. It is based on the OASIS standard BPEL. In Orchestra server is bundled with web based workflow management Console.

Figure 90 Orchestra

Taverna Server  Name: Taverna Server  Version: 2.2a1  Platform: Java  Standards:  Vendor: myGrid, OMII-UK  Licence: LGPL  Homepage: http://www.taverna.org.uk/ Taverna Server enables you to set up a dedicated server for executing workflows remotely. 07 March 2013

106 of 44

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

Server is using workflows designed by Taverna Workbench. The Server exposes REST and SOAP APIs; either can be used to access the functionality of the Server. As demonstration manager the Taverna Demonstrator interface is used written in Ruby language. The demonstrator is simple GUI to manage workflow execution and can be used as inspiration for custom and more complicated workflow management solution development. (Figure 3) Taverna Demonstrator can not be used in a production environment.

Figure 91 Taverna

Workflow designers An integral part of orchestration engines and workflow managers are designers to prepare executable workflow documents.

52°North WPS Workflow Modeller and Orchestration API • Name: 52°North WPS Workflow Modeller • Version: WPS 2.0-RC6, Revision 1647 • Platform: independent, language Java • Vendor: 52north • Licence: GPL • Homepage: http://52north.org/ The open source software initiative 52°North is an international network of partners from research, industry and public administration. Its mission is to foster the development of new concepts and technologies in Geo-informatics through a common innovation process. All software developed within this collaborative development process is published under an open source license.

07 March 2013

107 of 44

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

The 52°North partners have a long and outstanding record in the Geo-IT domain. They are actively contributing to the development of international standards, e.g. at W3C, ISO, OGC or INSPIRE. The Geoprocessing community aims at designing a pluggable web service architecture for orchestrating and executing geo-processes, as well as researching innovative spatio-temporal data analysis processing techniques. The WPS Workflow Modeller allows the visual modelling of geoprocessing workflows. In a lightweight Browser environment, WPS services can be easily chained and equipped with literal or complex data inputs from i.e. other OGC services such as WFS. This graphical WPS Workflow Modeller is based on the WPS Orchestration API which allows the programmatically chaining of WPS in a very straight forward manner. The work was has been conducted in cooperation with Sejong University through funding from the Seoul R&BD programme (10540) The Workflow Modeller uses a standard Openlayers implementation to visualize input and result layers (Figure 4). Along with this standard implementation comes the default controls for panning and zooming as well as a layer switcher to turn on/off overlay layer and to select base layers (see section 1.1). In the following the specific functions of the Workflow Modeller to interact with the map are described.

Figure 92 Workflow modeller

ECLIPSE BPEL  Name: Eclipse BPEL  Version: WS-BPEL 2.0  Platform: independent, language Java  Vendor: The Eclipse Foundation  Licence: Eclipse Public License (EPL)  Homepage: http://www.eclipse.org/bpel/ BPEL Project adds comprehensive support to Eclipse for the definition, authoring, editing, deploying, testing and debugging of WS-BPEL 2.0 processes. WS-BPEL (Web Services Business Process Execution Language), or BPEL, is a vendor-neutral specification being 07 March 2013

108 of 44

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

developed by OASIS to specify business processes as a set of interactions between web services. The goal of the BPEL Project is to add comprehensive support to Eclipse for the definition, authoring, editing, deploying, testing and debugging of WS-BPEL 2.0 processes. WS-BPEL (Web Services Business Process Execution Language), or BPEL, is a vendor-neutral specification being developed by OASIS to specify business processes as a set of interactions between web services. By providing these tools, this project aims to build a community around support for BPEL in Eclipse. The implementation will be extensible to third-party vendors in a number of ways. The editor will be extensible to support new activity types, property pages for extensibility of existing constructs, an extensible palette, and product-specific branding capabilities. The runtime deployment framework will be extensible so that third parties may add support for a variety of runtime engines. The model will support extensions to provide new activities or attributes, and the validator will allow for validation of these extensions. The Key Features are:  Designer. A GEF-based editor that provides a graphical means to author BPEL processes (Figure 5).  Model. An Eclipse Modelling Framework (EMF) model that represents the WS-BPEL 2.0 specification.  Validation. A validator which operates on the EMF model and produces errors and warnings based on the specification.  Runtime Framework. An extensible framework which will allow for deployment and execution of BPEL processes from the tools into a BPEL engine.

Figure 93 Eclipse BPEL

07 March 2013

109 of 44

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

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 geoprocessing components into workflows. Second, a web service, called the Workflow Repository Service, that accepts requests for workflows and delivers them to clients (in HUMBOLDT, the Mediator Service). Basic Functionality of the WDCS:  Allow users to visually compose the workflow graph out of geo-processing components (out of WPS / java processes / WSDL?) and data sources  Manual Workflow Definition, Automated Execution  Allow users to register processes to the system  Exports such workflows in different workflow dialects via a WSDL / SOAP interface (priority: the dialect used by the HUMBOLDT Mediator Service)  Help the user in the composition process, by:  type checking inputs and outputs when connecting  type checking user entered input values  Some small graphical features that make the composition process easier The Graphical User Interface of the WDCS, called the Workflow Editor, can be used by users to register processing components and to specify chains / compositions of such components (i.e. workflows). The GUI offers therefore quite a similar functionality as e.g. the GUI of the ArcGIS Model Builder or a BPEL Workflow Designer but additionally provides assistance to the user in the composition process by e.g. comparing the input/output type definitions of the components to be connected. For example, this prevents users from connecting components processing raster data with processing component accepting vector data and hence reduces the risk of runtime errors when executing the composition. Currently, the processes to be composed can either be exposed as OGC WPS Processes or directly implemented in java and accessible to the HUMBOLDT Mediator Service. The Workflow Editor acts as a client application to the Workflow Repository and allows users to deploy the workflows such that they will be subsequently offered via the web service interface of the Workflow Service. The geo-processing workflows to be built with the Workflow Editor follow the structure of dataflow graphs, a well-know concept in software engineering. A dataflow graph is a graph G = (V,E) with V=GD being a set of nodes and E= (D×GG) a set of directed edges. G is the set of processing nodes associated with computational components, in the case of the workflow editor, geo-processing components. D is the set of data-providing nodes associated with data providing components. A directed edge E connects a node associated with a data providing or computational component to another computational component. In case a computational component has multiple inputs (often called input ports), there can be multiple edges pointing to it, each one associated with a different input. In case a processing node has multiple outputs or the output shall be pushed as input to multiple input ports of a single or multiple other processing nodes, several edges from such a processing node might exist. The computational components represented by the nodes G in a dataflow graph are required to 07 March 2013

110 of 44

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

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

07 March 2013

111 of 44

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

of tools used to design and execute scientific workflows and aid in silico experimentation. Taverna has been created by the myGrid team and funded through the OMII-UK. The project has guaranteed funding until 2014. The Taverna suite is written in Java and includes the Taverna Engine (used for enacting workflows) that powers both the Taverna Workbench (the desktop client application, Figure 7) and the Taverna Server (which allows remote execution of workflows). Taverna is also available as a Command Line Tool for a quick execution of workflows from a terminal. Taverna allows you to define how your data flows between the services, without having to worry how you are going to invoke these services. It will automate and pipeline processing of data.

Figure 95 Taverna Workbench

Suite of tools to design, edit and execute workflows  Workflow design and execution in Taverna Workbench  Command line execution of workflows  Remote execution of workflows on a Taverna server  Invoke workflows from the Internet Wide range of services and extensible architecture - Service discovery - Various service types available: WSDL-style and RESTful Web services, BioMart, BioMoby, SoapLab, R, Beanshell, Excel and csv spreadsheets, pyWPS - Service creation for external tools or Java libraries - Extensible service plug-in architecture for adding new service types Secure  Support for secure services  Secure management of users’ credentials Versatile Workbench 07 March 2013

112 of 44

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

 Tabs for finding, designing and executing workflows  Fully graphical workflow design  Drag and drop workflow components  Comprehensive undo/redo  Built-in help facility  Annotations for describing workflows, services, inputs, outputs  Workflow validation and debugging Create your own or start from existing workflows - Easy design of new workflows - Load existing workflows (from a disk, myExperiment or a URL) - View workflow layout and logic - Modify existing workflows - Load workflows in off-line mode (when disconnected from the Internet) - Nested workflows (sub workflows) - Workflow validation during design time for debugging while composing a workflow - Built-in detection when a service’s interface changes or a service go off-line during design time Find workflows created by others and share yours  Full myExperiment search options for browsing workflows  Publish workflows on myExperiment for use by others Execute and debug your workflows • Execute workflows • Remember previously used workflow inputs • Save workflow input values used to a file • Load workflow input values from a file • Pipelining and streaming of data • Implicit iteration of service calls • Conditional and repeated calling of services • Customizable looping over a service • Failover and retry of service calling • Parallel execution and configurable number of concurrent threads • Improved error handling and reporting for debugging during run time • Monitor workflow execution • Pause/resume or cancel workflow execution • Manage previous runs and workflow results • View intermediate results and debug workflows at run time • Filter and save intermediate and final workflow results Track workflow runs and results • Record workflow execution provenance • Review provenance of previous workflow runs

10

HABITATS Pilots’ Network Services

HABITATS deals with 7 pilot implementations in different regions of Europe and the different regions use different technologies. The objective of HABITATS is to demonstrate the sharing of data among such heterogeneous solutions. D4.1 indicates that SDI tools can be applied in

07 March 2013

113 of 44

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

HABITATS on the basis of analysis of user needs and user scenarios, the project plans to define a set of application independent services (GENESIS model of Generic services) and interactions of these services for concrete pilots. D4.1 gives a good overview of current regulations, trends and recommendations coming from research projects, as well as information on how different commercial and voluntary initiatives can be integrated. From the analysis it is clear that INSPIRE is a minimum set, which has to be taken into consideration, for the HABITATS architecture, allowing each pilot to work with its own methods and technologies, while adhering to the conditions of the INSPIRE Directive concerning: • Metadata • Interoperability of spatial datasets and services • Network services • Data sharing • Monitoring and reporting For the (i) Metadata, (ii) Network Services, (iii) Monitoring and (iv) Reporting INSPIRE has published first implementing rules. The rules for the second and fourth have been published recently. The metadata for HABITAT’s four themes must wait until 2012. With these conditions the HABITATS pilots must build their SDIs and successfully share their data. The first step for all pilots is to create metadata for their data and services. The second important step may be to prepare some network services, following the ISO and OGC recommendations for data specifications and data sharing, and then complete them when the implementing rules will be published. The model of D4.1 and the other examples inside it show the way to build the HABITATS infrastructure. Experiences from different European projects demonstrate that the INSPIRE architecture is not enough for implementation of real practical pilot applications. Some basic architecture principles and also basic generic architecture are very similar. The analysis demonstrates, that it is important for pilot implementations to analyse user needs and describe these needs by Use Cases. Concrete Use Cases can define changes in concrete architecture. Integration of commercial and voluntary services can also increase functionality in applications such as tourism. Experiences from other projects demonstrate the advantage when the first level architecture is designed as an independent platform and then concrete components are selected for implementation. There exists a large list of basic components, both proprietary and Open Sources. According to the HABITATS user-driven approach to standardisation, the full impact of results will be sparked off by the pilot service scenarios and their ability to attract new participants to the communities of adoption. Each of the HABITATS pilots is therefore built on: a) existing concrete services currently carried out by project partners, b) potentials of data access through network services and c) enhancement through usage scenarios developed by user communities, in order to meet the three HABITATS criteria of relevance, openness and responsiveness. Much of the success of this will be based on cross-regional Services and data access. The 07 March 2013

114 of 44

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

pilots, as described in the DoW, fall into the following trans-regional categories: 1. Management of natural resources o Wild Salmon Monitoring (IE) o La Palma Protected Marine Area (ES) 2. Eco-tourism o Hiking Trip Planner (IT) o Soria Natural Reserve (ES) 3. Economic activities o Sheep and Goat Herd Management (IT) o Economic activity at marine coastal benthic habitats (LV) 4. National policy o Czech National Forest Programme (CZ) While D2.4.1 identified the following trans-regional groupings. 1. Potential benefits of user involvement influence data modeling and standards adoption. • Wild Salmon Monitoring (IE) • Economic Activity of Marine HABITATS (LV) • Forest Management (CZ) 2. Direct expert/end-user interaction with a data modeling process. • Monitoring Protected Marine Area (ES) • Environmental Education in a Natural Reserve (ES) 3. User-driven co-design of services leading to “demand pull” INSPIRE adoption. • Hiking Trip Planner (IT) • Sheep and Goat Herding Management (IT) D2.4.2 found that all Pilots have much to be learned, shared and potential for collaboration with the other Pilots particularly with regard to common pan-European data themes and sources on (i) Tourism, (ii) Education and (iii) Environmental Conservation/Management. Each of these validation pilots relies on trans-regional and trans-European data sharing between pilot settings, within INSPIRE networks present in the project and with collaborating members of the HABITATS User Communities. Pilot actors include stakeholders participating in the management of platforms, data owners and producers and contributors to services and user groups of all pilots. D4.2.1 tabulates the generic use cases from the pilots, as well their user groups and generic roles. From these it identifies that the services based on external data in HABITATS requires the following basic operations: • Data discovery • Storage metadata about services on server • Data visualisation • Data download PILOTS DESCRIPTIONS WILD SALMON MONITORING MAC works with the Irish Marine Institute (www.marine.ie) at its Aquaculture and Catchment

07 March 2013

115 of 44

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

Management Facility in Newport, Co. Mayo, Ireland (www.marine.ie/home/aboutus/organisationstaff/serviceareas/ACMS.htm), focusing on the monitoring and analysis of wild salmon stock dynamics. Wild salmon data that have been collected by the Marine Institute is accessible to provide better intelligence to researchers, fishermen and decision makers on salmon conservation, so that they can better manage the wild-salmon resource in a sustainable manner and help prevent the extinction of wild salmon in rivers on the North Atlantic coast of Europe Irish Marine Institute collects and owns the data, but collaborates with other Marine Institutes and the North Atlantic Salmon Conservation Organisation. The service to be piloted package and provide that data as better intelligence to researchers, fishermen and decision makers on salmon conservation. Also MAC focused the Irish HABITATS pilot on the wider communities’ identification, reporting, and recording for subsequent eradication of AIS instances as they relate to salmon and all inland and coastal native fish species conservation in Ireland and Europe, by developing a phone app and system that involves the wider communities through awareness, using social media, crowd-sourcing and open map-based geo-data for the identification, reporting, and recording for subsequent eradication of AIS. The HABITATS AIS Phone App is easy to download from the Google Play Store and use.

Figure 96 Aquatic Invasive Species

It empowers everyone to record an instance of an Aquatic Invasive Species with an user-ID, photograph, text report, time and GPS location on their smartphone, with guidance and advice on how best to record and photograph each sighting.

Figure 97 Aquatic Invasive Species App

07 March 2013

116 of 44

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

The App also shows a map of the previous verified AIS sightings to foster each user’s social networking/community building, with a link to the IFI Facebook site, to allow users tell/discuss with their friends about their sightings and use of the App. To increase awareness of AIS and the threat that they pose, the App includes much on-phone information and images of aquatic invasive species, with advice and plans on aquatic biosecurity for anglers and fishermen in particular (as their practices can have a huge impact on the spread of AIS).

Figure 98 AIS classification

When a sighting is reported, it is verified and the AIS classified on a private Management Console space at www.habitats.ie by IFI researchers and experts.

Figure 99 Integration with RL

07 March 2013

117 of 44

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

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 bestpractice recommendations for the INSPIRE habitats-related themes, as they pertain to salmon and other inland and coastal fish species.

Figure 101 Ireland Pilot architecture

This architecture allows an open transfer to other applications and pilots as follows:

07 March 2013

118 of 44

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

Figure 102 Publishing



The back-end (blue items) can be reused and transferred for any App. -



To run on MAC’s existing Server or be transferred to another Server (such as Madonie Park)

The App structure can be reused if it follows the same generic process -

find something on a list

-

record it by its location and an uploaded picture.

-

for instance the Active Hiker App in Madonie Park.

The Irish Pilot’s architecture allows its data to be published using WMS and WFS services using GeoNetwork and GeoServer on the Irish Portal at www.habitats-ireland.eu, to make the HABITATS services discoverable and usable by external platforms.23 LA PALMA PROTECTED MARINE RESERVE The pilot takes place in the La Palma Protected Marine Reserve in the Canary Islands. However, harmonization and standardization of this kind of data and making them available in a national or European level is considered to be useful for any coast area with similar problematic. When using sensors and in order to make it simple for our purpose, the coast area of this PMA has been divided into two subareas that is defined as open sea (not more than 600 m from the coast) and border sea. With the same criteria, indicators that we will take into account will be: biological parameters or physical-chemical parameters and only the three among the most relevant ones will be taken for each one of the subareas. 23

KML may also be adopted later, see http://en.wikipedia.org/wiki/Keyhole_Markup_Language

07 March 2013

119 of 44

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

Figure 103 Sea Monitoring

The use of images and voice recognition systems have been studied when the human intervention is needed. All these data is georeferenced in cartographic maps. The main stakeholder involved in the development of this pilot is TRAGSATEC. Some other collaborators are companies manufacturing sensors and developing voice, fishermen, diving clubs, hotels, farmers, etc. Its business model is based in the service funded & extended by public agency responsible for PMAs in Spain. The pilot scheme that is:

Figure 104 La Palma Pilot Scheme

07 March 2013

120 of 44

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

In this pilot there were obtained data from a sensor system and from a sensor connector we store these data in a database. This first database is a SQL DBMS in the form of tables and the relationship among the data is also stored in tables. From these tables, the representative geodata were got in shapefile format. The platform to publish these data is composed by Geoserver, Geonetwork with PostgreSQL. This platform works with WMS, WFS, WCS and CSW standards and allows View and Discovery services. The download service has been deployed for the shapefiles and the results of the harmonization through the ESRI software. The metadata profile was filled with CatMDEdit. The viewer done in FLEX allows us to do pan, zoom, change the numeric scale, add favourite views, switch off/on layers, change the opacity of the layers, add external layers (currently only WMS), check the layer info, situation minimap, table of contents, hide/show, etc. The URL to the geoportal is http://habitatspre.tragsatec.es/visorhabitats/ .

Figure 105 La Palma portal

In the catalogue section we can search more layers, watch the metadata and use the metadata editor if we have got the permission access.

07 March 2013

121 of 44

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

Figure 106 La Palma metadata

We are working to allow the addition of elements metadata themes to the metadata profile. It is really hard and it’s generating bugs in the Geonetwork catalogue. Also we are migrating from version 2.6.3 to 2.6.4. Currently we use Geoserver 2.0.2 that serve WMS 1.1.1 but we are migrating to Geoserver 2.2. that allows WMS 1.3 and it’s completely INPIRE compliant. Part of work was focused on publishing the spatial data in other formats like WFS or KML. Lately we are working with NSI to develop a Business Intelligence platform based in SpagoBI. MADONIE HIKING TRIP PLANNER This pilot is situated inside the Madonie Park, Sicily (Italia), but could be widely replicable throughout the Mediterranean. The Park Authority developed a multimedia repertory of many of the park’s main features – including both natural elements and places of traditional farming and herding – and, in the context of on-going initiatives, developed an interactive multimedia map of the area that allows hikers to plan visits as a function of the natural elements to see. The validation pilot in HABITATS integrates habitats-related data into this map, to allow to view bio-geographical regions within the park. In addition, use of mobile platforms (where coverage is available) is a great tool. Finally, the currently planned facility allowing for users to upload multimedia content and insert comments and suggestions are enhanced to validate the possibility for users to insert content through the SDI. The possibility to signal sightings of different species (i.e. through digital photos with time date and location stamp) also is being integrated. This pilot makes significant use of the information in the regional Carta Natura database, and also access databases from other regions in order, for example, to compare habitats in different geographical contexts. 07 March 2013

122 of 44

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

MADONIA SHEEP AND GOAT HERDING MANAGEMENT In the Madonie Park, over 1,500m is dominated by the Madonie Forest while lower down the slopes, the locals continue to pursue millennial agricultural activities including sheep and cattle farming and the cultivation of wheat, olives and fruit. This gives rise to specific traditions such as the seasonal “transumanza” when herds are moved from their summer to winter pastures and back, and contributes to the Madonie’s gastronomic specialties of meat, sausages, salami, cheese, olives, mushrooms, and fresh seasonal vegetables. Also the pilot is coherent with the Park’s mission but is also an element of the TLL-Sicily partnership’s innovation piloting strategy.

Figure 107 Madonia Architecture

In order to go toward a system “INSPIRE compliant” is necessary to make people, at Madonie Park, works in a way useful to realize some INSPIRE instances (such as metadata definition, organized way to archive data (both spatial and non-spatial, use of data located on a remote server accessible by web services, publication of web service for data locally managed). The scheme of work of this pilot is like it:

07 March 2013

123 of 44

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

Figure 108 Madonia implementation

Some activities on data regarding both two pilot projects have been carried out:  Data conversion for existing database (conversion of format, native SRS to UTM-WGS84 zone 33);  Georeferencing of non-spatial data (data in pictorial format);  Vector format acquisition and database structuring;  Definition of thematic data structure – according to GEMET ( http://www.eionet.europa.eu/gemet/inspire_themes ) - useful to allocate data sets.  Selection of some hiking paths available in vector format (shapefiles);  Selection of waypoints to be superimposed to path (also for selection by queries);  Acquisition of management plan of the park area;  Definition of path and geographic objects representation (symbols useful to represent land structure, infrastructures present in the park, etc.);  Acquisition of grazing plan from paper maps or .pdf files;  Structuring and filling the database for grazing plan;  Definition of new layer based on the way adopted for the assignment of grazing area to each shepherd or breeder (work in progress);  Definition of an agreement between Sicily Region Administration and Madonie Park by which metadata of new dataset will be published on Geoportal of Sicily Region at ARTA Sicilia, while data should remain available for the access, by web services, on the site of Madonie Park WEBGIS Application (work in progress); 07 March 2013

124 of 44

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

  

   

Some adaptation work in order to made data set suitable to be accessed as web service; Selected data in raster and/or vector format moved inside a thematic structure in order to easily manage of find them; In this preliminary stage only one platform has been put up with the main goal to interact with staholders speaking on tangible example. This WEBGIS is based on MapServer + Pmapper 4.0 and operates: with a typical WEBGIS interface the will be the final interface only for the pilot on Sheep and Goat Herd Management; on data sets regarding both two Pilot Projects; on data sets made available from Inspire GeoPortal of ARTA Scilia (Sicily Region Land and Environmet Administration); web services on local data-sets are to be published.

AUGMENTED REALITY NATURAL RESERVE The strength of the pilot is that if a standardization of the data and metadata modelling for this kind of environmental tourism is defined, some other standards will appear for the specific hardware that is needed for its representation and the idea of environmental tourism could equally be developed in the whole Europe. The objective of this pilot have been to develop a system that, using real nature information and adding metadata to real images (texts, images, sounds, etc.), allows improving environmental tourism with a real respective nature observation. Introducing interpretation information and augmented reality we will particularly protect fragile areas. There were developed two ways in the Augmented Reality:  Augmented reality device on a outdoor stage

Figure 109 Augment Reality Technology



Augmented reality app for Android

07 March 2013

125 of 44

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

Figure 110 Android App

This technology works for us as the following way:

Figure 111 Augment Reality Scheme

Some aspects must be clear: 

The data model depends on the themes that we choose to show in the augmented reality.

07 March 2013

126 of 44

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



We must work only with graphic data (spatial data)

To do that we have used the following tools: 

Proprietary software based on Android for mobile.



Proprietary software based on Linux for the augmented reality device.



ArcGIS software to process data.



GeoServer to publish our spatial data.

The initial working schema of this pilot is like it:

Figure 112 Augment Reality Implementation

The View service must be process through our Augmented Reality software to be displayed in the AR devices and mobile phones. From these platforms we could work to implement the Web 2.0 for the users. The data was processed in shape format. There were launched the platform also in Geoserver with the Geonetwork software to get a catalogue. With this platform we have created WMS services and the metadata profile. As metadata editor was used the Geonetwork catalogue. The ISO 19115 and ISO 19139 are the standards to comply the INSPIRE mandatory profile. The address to access to geoportal is http://habitatspre.tragsatec.es/visorRa/ .

07 March 2013

127 of 44

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

Figure 113 Pilot portal

As the above pilot, in the catalogue section we can search more layers, watch the metadata and use the metadata editor if we have got the permission access. Anyway, the metadata profile was filled with CatMDEdit. Also the download service has been deployed for the shapefiles and the results of the harmonization through the ESRI software.

Figure 114 Pilot Metadata

Currently we use Geoserver 2.0.2 that serve WMS 1.1.1 but we are migrating to Geoserver 2.2. that allows WMS 1.3 and it’s completely INPIRE compliant. We are working to allow the addition of elements metadata themes to the metadata profile. It 07 March 2013

128 of 44

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

is really hard and it’s generating bugs in the Geonetwork catalogue. Also we are migrating from version 2.6.3 to 2.6.4. Additionally the possibility to download the shapefiles exists in the Download section. And finally we uploaded the app for Android devices to the Google Play (Android market). Everybody can install the app for free.

07 March 2013

129 of 44

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

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

07 March 2013



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;

130 of 44

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



Meta-data 

For metadata it uses the meta-data system Micka.



Meta-data system in use is (http://geoportal.tdf.lv )

Some sources of these data to build a base dataset have provided only from one organization (biotopes, water bodies, monitoring data, Natura2000), the Latvian Institute of Aquatic Ecology.

Figure 116 Latvian Pilot Implementation

07 March 2013

131 of 44

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

Figure 117 Latvian portal

Also the basic requirements for Web Processing Service (WPS) content was formalized. Regarding the meta-data for datasets, a ISO19115 compliant form has been created in Latvian and English language. Implementation of INSPIRE requirements in Latvia is gradual and motivation to be involved depends on the pressure by Directive/respective national legislation.

Figure 118 Processing services

The basic requirements for Web Processing Service (WPS) content are being formalized and the WPS implementation is in progress. Service implementation is according OGC standard.

07 March 2013

132 of 44

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

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 HSRS.



Based on HABITATS meta-data profile created first Latvian pilot data metadata descriptions. Since HABITATS profile is not implemented in our metadata system meta-data are describe in ISO standard since HABITATS and INSPIRE profiles are subset from ISO.



View and download services are working.



And we have got a web based platform.

NATIONAL FOREST PROGRAMME Scenarios from NFP centres are coordinated with border cross countries. Metadata, geometric and semantic harmonisation of multiple representations and different sources of geodata are concentrated according to GMES. Simple scheme for the First use case - "Forest site classification data for sustainable management and utilization of forest road network" is displayed bellow:

07 March 2013

133 of 44

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

Figure 119 FMI pilot scheme

FMI has a long experience with MapServer, so this experience and the know-how will be developed further. However, we have huge data warehouse, which need to be restructured. Metadata for all datasets in Use case 1 has been created and will be placed on both geoportals: the National and the HABITATS portals. The pilot can offer:  Datasets for HABITATS reference laboratory 

WMS service



Validated metadata (available both in English and Czech language)

07 March 2013

134 of 44

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

Figure 120 OPRL Data

There were urdates data models to be suitable for new technologies. Nowadays our stakeholders are using our geoportal (http://geoportal2.uhul.cz/wms_oprl?SERVICE=WMS) with only WMS service and not quite so interoperable client, which has serious problems across different browsers. Geoportal client side uses modified Openlayers and on the server side is working UMN mapserver. There were tested software architectures with Geonetwork/Geoserver and Geohosting/Micka and both are more or less suitable for our purposes. The FMI uses LDAP authentication protocol for all Microsoft and Unix desktop clients, therefore administrative part of the geoportal should have the same login backend

07 March 2013

135 of 44

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

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 clientserver protocol, but are most often used with this protocol. A Servlet is an object that receives a request and generates a response based on that request. • Portlets - are pluggable user interface software components that are managed and displayed in a web portal. Portlets produce fragments of markup code that are aggregated into a portal . • WMC - Web Map Context (WMC) describes how to save a map view comprised of many 24

From D3.5 – INSPIRE Network Services Architecture v2.0

07 March 2013

136 of 44

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











3.2

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 cocreation 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. HABITATS “Quick Prototyping” Service Applets

During phase 2 of the project, the pilots implemented “quick” and “light” on-demand applets to meet the validation pilot expectations and user needs. These “Quick Prototyping” service applets will run within the HABITATS service architecture and will be developed on-demand. They include: • Discussion forums with the ability to pre-set data layers on map views • Timeline services to visualize the evolution of spatial phenomena over time • Transformation and harmonisation services • Tools for sharing data and services • Services for the bottom-up introduction of spatial data by local citizens and businesses and validation by the relevant local authorities • Other specific components supporting participatory and social innovation processes.

25

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

07 March 2013

137 of 44

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

The interoperability tests IMCS RL During project validation phase we provide tests of discovery, visualization and analysis of data from IMCS pilot. The focus was on usage of IMCS harmonized data services in HABITATS reference laboratory together with additional pilot data and provide integration with additional Pan European Data as Natura 2000, Corine Land Cover and OSM data.

Figure 121 Harmonised data publishing on RL

IRISH TEST WITH RL The Irish data of invasive spices was published using Geoserver as WMS and KML and was tested using the RL. The following show views of the data as it appears on the HABITATS RL Geoportal.

07 March 2013

138 of 44

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

Figure 122 Invasive species on RL

Figure 123 Invasive species on RL

LA PALMA RESERVE MARINE PILOT TEST WITH RL The data of La Palma Reserve Marine, bathymetry, sample points, marine area, reserve marine, and land use, using Geoserver as WMS was tested using the RL.

07 March 2013

139 of 44

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

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.

07 March 2013

140 of 44

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

Figure 125 The screen capture shows the data as it appears on the HABITATS RL Geoportal: http://www.habitats.cz/view?permalink=8555142bd2d6f5462d4f766015bc4776

FMI LIBEREC REGION TEST OF REFERENCE LABORATORY Region Liberec decided to use and implement HABITATS Reference Laboratory for the purpose of environmental management and risk protection services in region. Liberec region with assistance of HSRS implement RL on their servers and provided customisation of RL for their own purposes. There were implemented full operational services based on RL. As second part of experiment, the harmonised data from Forest Management Institute was used for the purpose of forestry protection policies in Liberec region Liberec Geoportal includes standard RL Geoportal components.

07 March 2013

141 of 44

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

Figure 126 Liberec Basic portal functionality

But geoportal include set ot thematic maps based on Geoportal functionality and implementation of WMC standards

Figure 127 Liberec Thematic Maps using standardised data from FMI

Sets of applications solving crises management, protection of citizens, environment protection etc.

07 March 2013

142 of 44

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

Figure 128 Flood portal as part of Geoportal

And also materials for education and awareness

Figure 129 Education and awareness

For this solution, there are two important facts. There were applied Living Lab and Open Innovation methodology, applied methods of HABITATS design and development (Liberec Geportal is implementation of HABITATS Reference Laboratory Concept) and main important fact is, that the content is prepared by non-programmers, specialist on Environment. In next chapter the general principles of HABITATS development and architecture will be explain EXPERIMENTATION WITH OPEN LINKED DATA As test for interlinked Open Linked data was design testing application, which tries to collect as much as possible data sets, process them to acquire relevant information and present the information in intelligible and simple way. The information are collected from many 07 March 2013

143 of 44

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

information resources (with open or free access to data) and transformed to the common data structure (with own schema taken account of metadata related to original source and time information) based on Extensible Markup Language (XML) format. The collected information are evaluated according to importance and reliability of particular resources. The original data are transformed to uniform data set with using XSLT (Extensible Stylesheet Language – Transformation) templates and open-source Saxon-HE processor. Users get the most relevant information, including links to original sources and a possibility to compare it with other collected data. Data is presented as the KML (Kyehole Markup Language) file of ski resorts (including information derived from the input sources) and web pages in HTML (Hypertext Markup Language) 5 format connected to other features such as map or graph components. The application uses ECMA script libraries such as Google Chart Tools or RGraph.

Figure 130 Integration of Open Linked data from skiing resorts

07 March 2013

144 of 44

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

12

Conclusions and Recommendations

This report presents the status of the work of HABITATS towards Networking Services and Invoking tools. HABITATS Networking Services are a series of specific networking service applets deployed and tested for data sharing within the project. The set of services was implemented on the HABITATS Reference Laboratory (RL) geoportal platform, which is described in detail. These include both interoperability services and enabling services, such as the • visualisation of information layers, • overlay of information from different sources, • spatial and temporal analysis etc. The set of HABITATS Networking Services has been implemented on the HABITATS Reference Laboratory (RL) geoportal platform. This acted as a client of the seven HABITATS pilots and provides a very rich set of cross-pilot, inter-regional and enabling services and tools that were validated by users on the basis of concrete implementations in phase 2 of the project. The applets for specific applications were developed in response to user requests at each pilot during phase 2 of the project. The following cross-pilot themes are identified, where common sharing of data and networking services will be important to all of the HABITATS pilots: 1. Tourism – pan-European search for data 2. Education 3. Environmental Conservation and Management The HABITATS RL provided the common services and tools, and acts as a clearing house for such data, based on cross pilot use cases. The following functionality was required and was developed for use in phase 2 of the project.  Connected different catalogue  Harvest metadata from catalogues  Multi search for catalogues  Discovery data  Upload and download data  Publish data  Prepare data composition  Harmonise data  Provide transformation to other type of services  Generate iFrame with pre prepared maps for re use on other portals (with well defined API)  Light WordPress based Social portal  Mobile catalogue clients  Mobile applications  Augment reality tools From the testing, we can conclude, that for broader utilisation of SDI on local and regional level it is necessary to go beyond the frame of the current INSPIRE Networking Services and Invoking tools specification. The current INSPIRE based solutions are not sufficient for local and regional users. It leads in some cases to a negative view by local stakeholders on

07 March 2013

145 of 44

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

INSPIRE implementation. The HABITATS RL and pilots demonstrate such an approach and the result is infrastructure, which is accepted by users’ communities. It is necessary to continue in such way. The HABITATS experimentation demonstrates, that in the case, that we are able to extend the current concept of INSPIRE, the services and toolkits could help in the everyday lives of local and regional users. On other hand HABITATS demonstrates, that most of current GIS Web based solutions are until now poor applications; they are not building on the principle of services. This concept doesn’t give the possibility to take full advantage of SDI. Proprietary applications are often based on data replication and don’t support integration of distributed services. Spatial data is used only in one application and it is a problem to use them in another Web or desktop applications. This application based system doesn’t allow building new types of service and really open SDI. Such a way will in the future make life easier for all developers, system providers and also users. But on the other hand it is an important fact. Current INSPIRE (but also GEOSS and partly GMES) architectures are mainly focused on development of Geoportals. But a normal user doesn’t need Geoportals, which are only a framework for experts, allowing them to build solutions for final users. We have to change the concept of Geoportals to being a tool, that support the building of new levels of “applications”. It has to be applications that use all of the advantages of existing SDI. It is important to design methods, which allow building of service orientated solutions. And it is also important, not to be only so called “GIS centred”, but to build a new generation of applications combining geospatial and non-geospatial information, in line with the initial intentions of SISE. So we tried in HABITATS to introduce a new generation of applications which fully benefit from SDI: • service based – with limiting data replication, re usage of existing components. • supporting integration with other systems • supporting also integration with social networks The main extension, which was demonstrate by HABITATS are: • To extend the classical three layer architectural model of HABITATS, by two new levels – application and presentation layers • To support building of user applets, which could be easily modified by non-specialist? This idea is in line with current activities of the Future Internet • Not to be focused on standard geospatial data and services, but also support initiatives related to Open Linked Data, which could bring new quality into existing SDI applications. • Mobility, smartphones and tablets will probably be the main interfaces in the future for accessing SDI generally, and concretely the INSPIRE infrastructure. • Social Networks and Media has to be integrated with SDI • As the way for easy integration of heterogeneous data the KML format should be considered.

07 March 2013

146 of 44

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

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-3250455, 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-32504553-250455, Social Validation of INSPIRE Annex III Data Structures in EU HABITATS 11. D5.2.1 HABITATS Pilot Validation Platforms, CIP-ICT-PSP-2009-3-2504553-250455, Social Validation of INSPIRE Annex III Data Structures in EU HABITATS 12. Description of Work, Social Validation of INSPIRE Annex III Data Structures in EU HABITATS, 2009-10-16 13. Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) 14. http://java.sun.com/applets/ 15. INSPIRE Network Services Drafting Team (2007), D3.5 – INSPIRE Network Services Architecture v2.0 16. ISO (2005), ISO 19119: Geographic information – Services 17. ISO 19119 and OGC Service Architecture, George PERCIVALL, USA, http://www.fig.net/pub/fig_2002/JS4/JS4_percivall.pdf 18. Open Geospatial Consortium Inc. (2004), Geospatial Portal Reference Architecture - A Community Guide to Implementing Standards-Based Geospatial Portals 19. Open Geospatial Consortium Inc. (2004), OGC Web Map Service Interface 20. Open Geospatial Consortium Inc. (2007), OpenGIS Catalogue Services Specification 21. Percivall G. (2002), ISO 19119 and OGC Service Architecture¸ FIG XXII International Congress, Washington, D.C., USA 22. Güting 2005: Ralf Hartmut Güting, Markus Schneider. Moving Objects Databases.2005, ISBN 978-0120887996. 23. HABITATS DoW 2010: Description of Work, “Social Validation of INSPIRE Annex II Data Structures in EU HABITATS”

07 March 2013

147 of 44

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

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

07 March 2013

148 of 44