SlideShare ist ein Scribd-Unternehmen logo
1 von 47
Downloaden Sie, um offline zu lesen
European Commission
Information Society and Media



                                       DELIVERABLE



Project Acronym:                          HABITATS

Grant Agreement number:                   CIP- ICT-PSP-2009-3-250455

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




                                     D-4.4.1
                              HABITATS Service Toolkit



Document identifier:                      D4-4-1-HABITATS service toolkit

Date:                                     24.02.2012

Nature:                                   P

Dissemination level:                      PU

WP Lead Partner:                          Graz University of Technology

Revision                                  Final
                  Project co-funded by the European Commission within the ICT Policy Support Programme
                                                    Dissemination Level
PU      Public                                                                                                   X
RE      Restricted to a group specified by the consortium (including the Commission Services)
CO      Confidential, only for members of the consortium (including the Commission Services)




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, 2010
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

 Abstract:
 This deliverable presents the background of invoking services and their relevance to the HABITATS
 projects and examines the basic networking architecture and specific tools that are considered. The
 focus of this intermediate report is on the application of these aspects within the Reference
 Laboratory while the final report (D4.4.2) will also include the invoking of services at the level of
 the different pilots.


 Key Words:
 Invoke, service toolkit, architecture design, workflow management, Reference Laboratory




Authors: (in alphabetical order)
     Raitis Berzins
     Peteris Bruns
     Jachym Cepicky
     Karel Charvat (HSRS)
     Patrick Höfler (TUG)
     Lisa Maurer (TUG)
     Michal Sredl
     Martin Vlk
     Premysl Vohnout




       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.




02/04/2012                                                                                  -2-
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

Revision History

     Revision Date                            Organization                       Description
     01            28.11.2011                 TUG                                First structure, document focus
     02            10.12.2011                 HRSR                               Additions, invoking services, extensions
     03            05.01.2012                 TUG                                Additions, comments
     04            01.02.2012                 HRSR                               Comments, additions
     05            08.02.2012                 NSI                                Comments and suggestions
     06            9.2.2012                   TUG                                Editing
     07            9.2.2012                   MAC                                Editing suggestions.
     08            14.2.2012                  HSRS                               WMS coordinate transformation added, small
                                                                                 comments provided, answer on Ana comments
     09            20.2.2012                  TUG                                Summary, final editing




02/04/2012                                                                                                    -3-
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas



                                          Project Officer: Krister Olson
                                                        European Commission
                                                        DG Information Society and Media
                                                        Project Officer
                                         Address:
                                                        DG INFSO – E06
                                                        Office: EUFO – 01/177
                                                        L – 2920 LUXEMBOURG
                                           Phone: +(352) 43 0134332

                                               Fax: +(352)

                                           E-mail: Krister.olson@ec.europa.eu



                             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: mnc@tragsa.es




02/04/2012                                                                                  -4-
Date: 24/02/2012                                                        HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas


                                                          TABLE OF CONTENTS
1. INTRODUCTION ......................................................................................................................................... - 3 -
   1.1. OBJECTIVE AND CONTEXT OF THIS DOCUMENT ........................................................................................ - 3 -
   1.2. ORGANISATION OF THE DOCUMENT.......................................................................................................... - 3 -
2. INVOKING SERVICES ............................................................................................................................... - 4 -
   2.1. INVOKING SERVICE REQUIREMENTS AND RECOMMENDATIONS ............................................................. - 5 -
3. HABITATS NETWORKING ARCHITECTURE AND REFERENCE LABORATORY .................... - 7 -
   3.1. HABITATS NETWORKING ARCHITECTURE................................................................................................. - 7 -
   3.2. REFERENCE LAB ....................................................................................................................................... - 8 -
4. HABITATS INVOKING SERVICES ....................................................................................................... - 10 -
   4.1. INVOKING OF DISCOVERY SERVICES........................................................................................................ - 10 -
   4.2. INVOKING OF VISUALISATION SERVICES ................................................................................................. - 11 -
      4.2.1. HSLayers 3.3 .................................................................................................................................. - 11 -
      4.2.2. Invoking of WFS and WCS ............................................................................................................. - 17 -
      4.2.3. Filter Encoding Filtering WFS Layers ........................................................................................... - 21 -
   4.3. WPS INVOKING ...................................................................................................................................... - 26 -
   4.4. HSLAYERS SOS CLIENT ......................................................................................................................... - 29 -
   4.5. HSLAYERS EMBED COMPONENT ............................................................................................................ - 30 -
5. PROCESSING WORKFLOW MANAGEMENT.................................................................................... - 33 -
   5.1. ORCHESTRATION ENVIRONMENT ............................................................................................................ - 33 -
      5.1.1. Workflow Management System ....................................................................................................... - 33 -
      5.1.2. Business Process Execution Language........................................................................................... - 33 -
   5.2. ENGINES AND WORK-FLOW MANAGERS .................................................................................................. - 33 -
      5.2.1. Apache ODE ................................................................................................................................... - 34 -
      5.2.2. Orchestra ........................................................................................................................................ - 34 -
      5.2.3. Taverna Server ............................................................................................................................... - 35 -
   5.3. WORKFLOW DESIGNERS.......................................................................................................................... - 36 -
      5.3.1. 52°North WPS Workflow Modeller and Orchestration API ........................................................... - 36 -
   5.4. ECLIPSE BPEL ..................................................................................................................................... - 37 -
      5.4.1. HUMBOLDT Workflow Design and Construction Service ............................................................ - 38 -
      5.4.2. Taverna Workbench........................................................................................................................ - 40 -
6. CONCLUSION............................................................................................................................................ - 43 -

7. REFERENCES ............................................................................................................................................ - 44 -




02/04/2012                                                                                                                                          -2-
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas


1. INTRODUCTION

1.1. OBJECTIVE AND CONTEXT OF THIS DOCUMENT
The aim of WP4 (Network service architecture) is to define SDI network services to enable trans-
European sharing of habitats-related spatial data between public authorities and other stakeholders in
the community (HABITATS DoW 2010) and sharing of such data across regions and across countries.
This work builds on the data modelling of WP3 and also refers to the user requirements and scenarios
developed in WP2 and in cooperation with the pilots of WP5. The prototype versions of the single
services are on the other hand again relevant for the developments in the social validation process and
will therefore provide valuable feedback.
The development of the network service architecture process of WP4 is 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.
The Task 4.4 deals with the tools for invoking of Geospatial Services that arise within the HABITATS
network architecture, interlinking different data sources and also interlinking data sources from
different INSPIRE thematic areas. This is first version of the document, the update and final version
will be released in Month 27.


1.2. ORGANISATION OF THE DOCUMENT
The document is divided into five chapters”
     •    Introduction describing general problem of invoking services and implementation of invoking
          services in INSPIRE (Chapter 2)
     •    Basic description of Habitats Networking Architecture and Habitats Reference Laboratory
          (Chapter 3)
     •    Principles of basic services that are invoked in reference laboratory (Chapter 4)
     •    Analysis and Processing of Workflow Management for Spatial Data (Chapter 5)
     •    Conclusion and tasks for next period of development inside of Habitats (Chapter 6)




02/04/2012                                                                                     -3-
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas


2. INVOKING SERVICES
The definition of spatial data services included in the INSPIRE directive1 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. ISO 19119 define also taxonomy
for Geospatial services2:
     •    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 services3
From INSPIRE Networking architecture, there are basic Networking services
     1. Discovery Service (discovery): Is a service 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.
     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 4
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.

1
  Commission of the European Communities, 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). 2007, Commission of the European Communities: Brussels.
2
 INSPIRE Invoke Services, Roberto Lucchi, Michel Millot, European Commission, Joint Research
Centre, Institute for Environment and Sustainability
3
  HABITATS, CIP- ICT-PSP-2009-3-250455, Social Validation of INSPIRE Annex III Data
Structures in EU Habitats, D-3.2a – HABITATS - 250455
4
   INSPIRE Spatial Data Services                        and     Invoke       Service   –   Draft,   implementing   rules,
Draft_IR_SDS_and_Invoke_1.0.doc


02/04/2012                                                                                                   -4-
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




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

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


02/04/2012                                                                                  -5-
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

          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.




02/04/2012                                                                                  -6-
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas


3. HABITATS NETWORKING ARCHITECTURE AND REFERENCE LABORATORY

3.1. HABITATS NETWORKING ARCHITECTURE
The HABITATS Networking Architecture has the goal of defining a system able to ensure the
interoperability and security of provided data and services. In particular, since integration with the
INSPIRE initiatives is needed, it is based on:
    • A methodological approach able to define a system architecture that is scalable and adaptable to
      the specifications and standards currently being defined;
    • The adoption of a Service Oriented Architecture based on Web Services and SOAP technology.
The platform neutral networking architecture of HABITATS and the basic set of networking services
can be seen as an extension of existing INSPIRE services, for the management, discovery, sharing and
processing of spatial planning data by public and commercial sector, NGOs, citizens, private sector,
education and science, and all those who play an important role in biodiversity and see region
protection and also exploitation. (HABITATS D4.2.1 2010)
As already described in D4.1, the architecture design is realised on the basis of a Reference Model of
Open distributed Processing (RM-ODP) (ISO/IEC 10746-1) The use of RM-ODP will give us two
opportunities: To define the basic design of the solution as platform neutral and to support different
local implementation, and to build on positive experiences of previous European research projects, as
this methodology is used by most European (mainly research) projects and some recommendations
already exist. The architecture design provides an overall conceptual framework for building geo-
processing services for biodiversity, sea region protection and for effective management and utilisation
of sensitive areas. (HABITATS D4.2.1 2010)
The HABITATS networking services will be ultimately applied on two levels: The HABITATS
Reference Laboratory (see also chapter 3) as a central portal with the support of global data, but also
supporting cross scenarios implementations, and the HABITATS pilot applications, as
implementations of single HABITATS pilot cases, which will also be used for testing the sharing of
local data and metadata. (HABITATS D4.3.1 2011)
The inter-linkage of the Reference Lab and the pilot implementations is visualized in the illustration
below (taken from HABITATS D4.2.2 2011).




02/04/2012                                                                                   -7-
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




The reference laboratory has the following roles:
•    To offer a possibility for testing new services
•    To offer access to global data for pilots
•    To support implementation of cross-pilot scenarios
•    To make the Habitats services discoverable for external platforms

The pilot implementations will implement only the functionality required by the respective pilot users,
the Reference Laboratory will implement the full functionality. (HABITATS D4.2.2 2011)


The RM-ODP divides all processes of architecture design into five generic and complementary steps,
which are called viewpoints of the system and its environment. These viewpoints are the:
     •    Enterprise viewpoint: Focusing on the analysis of pilot scenarios and the definition of a
          limited number of generic use cases,
     •    Information viewpoint: Focusing on the basic data and metadata sets that could be shared
          among the different scenarios
     •    Computational viewpoint: Focusing on generic components that could be reused for more
          scenarios
     •    Engineering viewpoint: Defining a generic scheme that can be reused for all pilot
          implementations
     •    Technology viewpoint: Defining basic architecture modifications for single scenarios and
          suggesting potential technical implementations


3.2. REFERENCE LAB
The reference laboratory, as already mentioned in the previous chapter, is the central hub of the
HABITATS Networking Architecture. It consists of several layers, which are (HABITATS D4.2.2
2011):


02/04/2012                                                                                  -8-
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

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




02/04/2012                                                                                 -9-
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas


4. HABITATS INVOKING SERVICES
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. In the final version (D4.4.2. - due June 2012) we will extend this approach also to the pilot
platform.

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




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




02/04/2012                                                                                  - 10 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

4.2. INVOKING OF VISUALISATION SERVICES
Visualisation services WMS (similar to WPS5 or SOS) are invoked through HSlayers on Reference
Laboratory

4.2.1. HSLayers6 3.3
HSLayers combines capabilities of ExtJS (part of Sencha7) and OpenLayers and several helping
scripts to establish truly Web GIS applications. The development started in 2007. In 2009, after 2
years of development, it was released under conditions of the GNU General Public License 3.




OpenLayers8 is a JavaScript toolkit for the creation of mapping applications in the web browsers.
OpenLayers is in some ways more powerful than Google Maps toolkit:
     • It can show maps based on various raster and vector formats.
     • It has connectors to many standards and quasi-standards such as MapServer, OGC Web
       Mapping Service, ArcIMS, simple Image layer, GML, GeoRSS, KML, Text and others and
       Google, Yahoo and VirtualEarth for commercial data providers.
     • The user – creator of mapping applications – does not need to take care about differences
       between various web browsers and their JavaScript implementation or between various data
       formats.
ExtJS is a multi-browser JavaScript library for building rich internet applications. It consists of
customisable User Interface widgets, ready to be used by designers of Graphical User Interface,
similar to desktop widgets, which among others are text field and text area input controls, date fields
with a pop-up date-picker, numeric fields, list box, radio and checkbox buttons, wysiwyg html editor,
text grids, suitable for spreadsheets, trees, tab panels, toolbars, menus and sliders. ExtJS was originally



5
    http://opengeospatial.org/standards/wps
6
      http://bnhelp.cz/hslayers
7
    http://sencha.com
8
    http://openlayers.org/


02/04/2012                                                                                    - 11 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

built as an add-on library extension of Yahoo UI, but now it is a standalone project. In HSLayers, we
are still using ExtJS version 3.x.
HSLayers features are coming up from OpenLayers and therefore their characteristics are as follows:
    • Portrayal of various types of data:
              • Raster: OGC WMS(-T), Image (PNG, JPEG, GIF), …
              • Vector: OGC WFS(-T), GML, GeoRSS, KML, GPX, GeoJSON, …
              • Data sources from commercial servers: Google Maps, Virtual Earth, Yahoo Maps, …
    • The user interface (use control) adheres to current conventions in web map portals.
    • Information about queried objects in text bubbles.
HSLayers additional functions include:
    • Dynamic adding of OGC (Open Geospatial Consortium) services into map - clients for WMS,
          WFS, WCS, KML, GeoRSS and others.
    • Basic WFS filtering
    • Transformation (warping) of services, with different coordinate reference system.
    • Portrayal of independent data sources on the client side. Map composition is composed on the
          basis of requests to various servers. It is thus not necessary to install a map server.
    • Saving of map composition according to WMC (Web Map Context) OGC specification on
          user computer for repeated future use or for sharing between users.
    • Extension of compute functions based on WPS (Web Processing Service ) OGC service -
                                                                                           9

          according to user needs – generic WPS Client available.
    • Multilingual environment
    • Map requests to various types of data stored on various servers, with automatic processing of
          results
    • Work with micro-formats
    • Search on the map using various Gazetteers services.
    • Connection of the application with catalogue client (OGC CSW) in the geoportal, which
          enables display of the searched service from catalogue directly on the map.
    • Vector editing function including snapping to chosen layers on the server.
    • Possibilities for advanced configuration of user requests
    • Advanced measuring of length and surfaces
    • Printing of map compositions - possibility of large print outs (up to A0 format), user
          configuration of print settings using HTML templates. PDF output as well as various image
          formats.

4.2.1.1. LayerSwitcher
LayerSwitcher has now a two panel interface, which makes it easy for the user to manipulate a large
list of layers in the map application. The first panel represents the “logical view” on the layer list –
layers can be organized into folders and so user can keep logical structure of displayed data. The
second panel represents the “physical view” - order of layers, displayed in the map window in the
stack. Usually, aerial photos are organized at the bottom of the stack, and cadaster maps are displayed
at the top of the stack and their organization into folders does not make much sense.




9
    http://en.wikipedia.org/wiki/Web_Processing_Service


02/04/2012                                                                                 - 12 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




This version of HSLayers also brings the ability to hide used components to side panel of the
application (dock) and whenever needed, it can be undocked again into a separate window.
Users on smaller screen resolutions can enlarge some tool they need to use and so they are not
limited to the size of the side panel.




4.2.1.2. Copyrights
HSlayers also support publishing of information about copyrights related to single services.
Information is taken from metadata


02/04/2012                                                                            - 13 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




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




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




02/04/2012                                                                             - 14 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

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




WMS Sequence diagram.




02/04/2012                                                                                 - 15 -
Date: 24/02/2012                                           HABITATS service toolkit
 Doc. Identifier: D4-4-1
 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




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



 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.


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




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




 02/04/2012                                                                                   - 16 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




     •    Save composition on local disk
     •    Save composition with metadata on server
     •    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.

4.2.1.6. Printing
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 or saving the content of the map into a raster image.
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 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 layed out 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.

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


02/04/2012                                                                                   - 17 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

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




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:


4
    http://mapserver.org


02/04/2012                                                                                   - 18 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

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




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


02/04/2012                                                                                 - 19 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




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.




02/04/2012                                                                               - 20 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

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.

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



4.2.2.2. Further development
Currently, when full featured Capabilities response is sent back from the server to the client, for some
servers, with high amounts of data, this can take a long time.
For WFS for example, GetCapabilities, DescribeFeatureType and sometimes even GetFeature requests
are to be called, before all necessary metadata are filled to MapFile. This certainly makes the
Capabilities response come back after a long time. In the future, we would like to eliminate this, so
that only the smallest amount of requests (GetCapabilities) would have to be requested, and WMS
Capabilities response could possibly be returned faster. Of course, when a user chooses the particular
layer to be displayed, additional non-standard calls would have to be done, in order to get addition
attributes, so that the client has all of the necessary information (which can be normally taken from the
Capabilities document).
Also up to now, virtually no configuration caching is created. For each GetCapabilities request, new
temporary MapFile configuration is established. A proper way would be to use already existing
MapFile for a particular service if it is already generated, and to evaluate the difference between the
cached version and the potentially upgraded service.
Proxy4ows is not caching any data. It is open for further investigation, if it would make sense to pre-
cache some original data at the Proxy4ows side, in order to make the performance better.

4.2.3. Filter Encoding Filtering WFS Layers
Filter Encoding is an Open Geospatial Consortium standard11 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'.

4.2.3.1. FE Examples:12
Simple comparison filter can look like that:
     Filter
         PropertyIsLessThan



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

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


02/04/2012                                                                                   - 21 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

                PropertyNameDEPTH/PropertyName
                Literal20/Literal
          /PropertyIsLessThan
     /Filter


Example 1.
Spatial filter can, among other things, define a polygon that the desired features should overlap:
     Filter
         Overlaps
                PropertyNameGeometry/PropertyName
                gml:Polygon
                srsName=http://www.opengis.net/gml/srs/epsg.xml#63266405
                    gml:outerBoundaryIs
                           gml:LinearRing
                                gml:posList ... /gml:posList
                        /gml:LinearRing
                     /gml:outerBoundaryIs
                /gml:Polygon
          /Overlaps
     /Filter


Example 2.
Logical filter allows to combine filters:
     Filter
         And
                PropertyIsLessThan
                    ...
                /PropertyIsLessThan
                Overlaps
                     ...
             /Overlaps
          /And
     /Filter


Example 3.
More examples can be found in the Filter Encoding standard.

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


02/04/2012                                                                                   - 22 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas



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 section
specifies the filter capabilities of the particular server. It can look as follows:
 ogc:Filter_Capabilities
  ogc:Spatial_Capabilities
     ogc:GeometryOperands
      ogc:GeometryOperandgml:Point/ogc:GeometryOperand
      ogc:GeometryOperandgml:LineString/ogc:GeometryOperand
      ogc:GeometryOperandgml:Polygon/ogc:GeometryOperand
      ogc:GeometryOperandgml:Envelope/ogc:GeometryOperand
     /ogc:GeometryOperands
     ogc:SpatialOperators
      ogc:SpatialOperator name=BBOX/
      ogc:SpatialOperator name=Equals/
      ogc:SpatialOperator name=Disjoint/
      ogc:SpatialOperator name=Intersect/
     /ogc:SpatialOperators
   /ogc:Spatial_Capabilities
   ogc:Scalar_Capabilities
     ogc:LogicalOperators/
     ogc:ComparisonOperators
      ogc:ComparisonOperatorLessThan/ogc:ComparisonOperator
      ogc:ComparisonOperatorGreaterThan/ogc:ComparisonOperator
      ogc:ComparisonOperatorLessThanEqualTo/ogc:ComparisonOperator
      ogc:ComparisonOperatorGreaterThanEqualTo/ogc:ComparisonOperator
      ogc:ComparisonOperatorEqualTo/ogc:ComparisonOperator
      ogc:ComparisonOperatorNotEqualTo/ogc:ComparisonOperator
      ogc:ComparisonOperatorLike/ogc:ComparisonOperator
      ogc:ComparisonOperatorBetween/ogc:ComparisonOperator
     /ogc:ComparisonOperators
     ogc:ArithmeticOperators
      ogc:SimpleArithmetic/
      ogc:Functions
        ogc:FunctionNames
          ogc:FunctionName nArgs=1SIN/ogc:FunctionName
          ogc:FunctionName nArgs=1COS/ogc:FunctionName
          ogc:FunctionName nArgs=1TAN/ogc:FunctionName
        /ogc:FunctionNames
      /ogc:Functions


02/04/2012                                                                              - 23 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

     /ogc:ArithmeticOperators
   /ogc:Scalar_Capabilities
   ogc:Id_Capabilities
     ogc:EID/
     ogc:FID/
   /ogc:Id_Capabilities
 /ogc:Filter_Capabilities


Example 4.
DescribeFeatureType
Properties that can be used to filter features of a specific type are advertised in the response to the
DescribeFeatureType request. In the example below, four properties can be used to filter the features
of the type location: DEPTH, SURFACE, AREA and CODE.
complexType name=locationType
 complexContent
  extension base=gml:AbstractFeatureType
   sequence
    element name=msGeometry type=gml:SurfacePropertyType minOccurs=0
     maxOccurs=1/
    element name=DEPTH type=Integer/
    element name=SURFACE type=Character/
    element name=AREA type=Real/
   element name=CODE type=Character/
   /sequence


  /extension
/complexContent
/complexType


Example 5.
GetFeature
When the filter capabilities of the server are known as well as the properties of the particular feature
type, the filter can be created following the FE standard. Consider the filter from Example 1, this time
extended with the namespaces. It selects all the features whose DEPTH property is less than 20. To the
GetFeature request the FILTER parameter is added and the filter is provided as the value:


http://localhost/cgi-
bin/ows?REQUEST=GetFeatureVERSION=1.1.0SERVICE=WFSTYPENAME=locationFIL
TER=ogc:Filter
xmlns:ogc=http://www.opengis.net/ogcogc:PropertyIsLessThanogc:PropertyNameDEPTH/
ogc:PropertyNameogc:Literal20/ogc:Literal/ogc:PropertyIsLessThan/ogc:Filter


Example 6.



02/04/2012                                                                                 - 24 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

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:




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.




02/04/2012                                                                                   - 25 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




4.2.3.3. Implementation

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




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

4.2.3.4. Next Steps
In terms of standards, FES 1.0.0 and FES 1.1.0 is supported. From various types of filters, only the
comparison filter is currently supported by the GUI. As next steps, more filter types can be added.
That covers logical filter enabling to combine various filters, spatial filter, expression editor, filtering
based on feature IDs, support for server-side functions and filtering based on time.

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


02/04/2012                                                                                     - 26 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

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.




4.3.1.1. HSLayers WPSCLient ComplexData handler
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 13[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.




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



02/04/2012                                                                                  - 27 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




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


02/04/2012                                                                                    - 28 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

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.



4.4. HSLAYERS SOS CLIENT
The SOS client in HSLayers is a component which can be used for browsing data from any OpenGIS
Sensor Observation Service (OGC SOS) compliant services. The component can be used together with
map application based on HSLayers, or independently with any non map application.
Th actual version of component supports only operations from OGC SOS Core Profile which must be
implemented in every OGC SOS compliant services.
Operations supported in the actual version are:
    • GetCapabilities - returns a service description containing information about the service interface
      and the available sensor data
    • DescribeSensor - returns a description of one specific sensor, sensor system or data producing
      procedure
    • GetObservation - provides pull-based access to sensor observations and measurement-data via a
      spatio-temporal query that can be filtered by phenomena and value constraints
Future versions of components will contain also operations from OGC SOS Enhanced Profile and will
offer more functionality for working with data from OGC SOS services.


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




02/04/2012                                                                                   - 29 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




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



02/04/2012                                                                            - 30 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

The HSLayers Embed component consists of several parts on the client and on the server side.
   • Embed Generator – this part is responsible for displaing 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.




4.5.1.1. How does it work
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.




02/04/2012                                                                                - 31 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




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




02/04/2012                                                                                - 32 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas


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

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

5.1.1. Workflow Management System
Workflow Management System (WMS) is a piece of software that provides an infrastructure to setup,
execute, and monitor scientific workflows. In other words, the WMS provide an environment where in
experiments can be defined and executed.
An important function of a WMS during the workflow execution or enactment is the coordination of
operation of individual components that constitute the workflow – the process also often referred to as
orchestration.
As research becomes more data-intensive and more reliant on the use of computers, larger volumes of
experimentation data are recorded quicker and with greater precision. This trend has spurred a
significant increase in the complexity of scientific simulation software. Many tools only perform a
small well-defined task, thus necessitating that several of them are joined in a pipeline to model a
useful experiment.
Additional difficulties arise from the need to deal with the incompatible data formats that various
services produce or consume. It is evident that considerable amount of computer science knowledge is
required to overcome the outlined problems. However, domain scientists across disciplines do not
have sufficient relevant expertise.
Scientific workflows and WMSs have emerged to solve this problem and provide an easy-to-use way
of specifying the tasks that have to be performed during a specific in silico experiment. The need to
combine several tools into a single research analysis still holds, but technical details of workflow
execution are now delegated to Workflow Management Systems.

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

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




02/04/2012                                                                                 - 33 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

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




5.2.2. Orchestra
        Name: Orchestra
        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.


02/04/2012                                                                                 - 34 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

In Orchestra server is bundled with web based workflow management Console (Figure 2).




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




02/04/2012                                                                              - 35 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




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

5.3.1. 52°North WPS Workflow Modeller and Orchestra tion 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.
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.


02/04/2012                                                                             - 36 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

The WPS Workflow Modeller allows the visual modeling 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 RBD program(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.




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



02/04/2012                                                                                 - 37 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

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




5.4.1. HUMBOLDT Workflow Design and Construction Service
        Name: HUMBOLDT Workflow Design and Construction Service
        Version: svn
        Platform: independent, language Java
        Short description
        Vendor: NATURE-SDI project
        Licence:
        Homepage: http://community.esdi-humboldt.eu/wiki/5
The HUMBOLDT Workflow Design and Construction Service consists of two sub-systems, a
graphical user interface, called the Workflow Editor, allowing users to compose geo-processing
components into workflows. Second, a web service, called the Workflow Repository Service, that
accepts requests for workflows and delivers them to clients (in HUMBOLDT, the Mediator Service).



02/04/2012                                                                                   - 38 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

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




02/04/2012                                                                                   - 39 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




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.

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




02/04/2012                                                                             - 40 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas




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



02/04/2012                                                                            - 41 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas

       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




02/04/2012                                                                                 - 42 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas


6. CONCLUSION
This report gives a brief overview of the tools for invoking Geospatial Services that arise within the
HABITATS network architecture. Invoking services are described and a few examples of invoking
services in the Reference Laboratory are demonstrated, and possibilities of Workflow management are
analysed.
Basically the architecture design is realised on the basis of a Reference Model of Open distributed
Processing (RM-ODP), while the HABITATS networking services will be ultimately applied on the
two levels of the Reference Laboratory as a central portal and on the level of the pilot cases for local
data testing and sharing. This first version of the deliverable examines the invoking services used in
the Reference Laboratory. As invoking strongly depends on the used platform, this first report mainly
reflects the developments in the reference Laboratory in order to support developers to implement or
invoke their services.
In the next phase (which will be reported in D4.4.2) the focus will be on invoking the services at the
level of the pilots and on the implementation of workflow management systems for the purpose of
HABITATS.




02/04/2012                                                                                 - 43 -
Date: 24/02/2012                                           HABITATS service toolkit
Doc. Identifier: D4-4-1
Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas


7. REFERENCES
Güting 2005: Ralf Hartmut Güting, Markus Schneider. Moving Objects Databases.2005, ISBN 978-
0120887996.

HABITATS DoW 2010: Description of Work, “Social Validation of INSPIRE Annex II Data
Structures in EU Habitats”

HABITATS D4.2.1 2010: D4.2.1- INSPIRE Networking Architecture Design, 2010

HABITATS D4.2.2 2011: D4.2.2 – INSPIRE Networking Architecture Design, 2011

HABITATS D4.3.1 2011: D4.3.1 – HABITATS networking services

ISO/IEC 10746-1 Information technology – Open Distributed Processing – Reference model:
Overview, ISO (1998)

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




02/04/2012                                                                            - 44 -

Weitere ähnliche Inhalte

Ähnlich wie Habitats deliverable 4.4.1

LoCloud - D3.7: Report on services developed for local cultural institutions
LoCloud - D3.7: Report on services developed for local cultural institutionsLoCloud - D3.7: Report on services developed for local cultural institutions
LoCloud - D3.7: Report on services developed for local cultural institutionslocloud
 
Stork Deliverable D7.3 List Of Commission A2 A Services Of Common Interest
Stork Deliverable D7.3   List Of Commission A2 A Services Of Common InterestStork Deliverable D7.3   List Of Commission A2 A Services Of Common Interest
Stork Deliverable D7.3 List Of Commission A2 A Services Of Common InterestFriso de Jong
 
Open Source Technologies for Contents and Maps
Open Source Technologies for Contents and MapsOpen Source Technologies for Contents and Maps
Open Source Technologies for Contents and MapsTsungWei Hu
 
Рынки, бизнес-модели и выручка промышленного интернета
Рынки, бизнес-модели и выручка промышленного интернетаРынки, бизнес-модели и выручка промышленного интернета
Рынки, бизнес-модели и выручка промышленного интернетаSergey Zhdanov
 
Emerging Technoethics of Human Interaction with Communication, Bionic and Rob...
Emerging Technoethics of Human Interaction with Communication, Bionic and Rob...Emerging Technoethics of Human Interaction with Communication, Bionic and Rob...
Emerging Technoethics of Human Interaction with Communication, Bionic and Rob...Karlos Svoboda
 
PATHS first paths prototype
PATHS first paths prototypePATHS first paths prototype
PATHS first paths prototypepathsproject
 
PATHS Second prototype-functional-spec
PATHS Second prototype-functional-specPATHS Second prototype-functional-spec
PATHS Second prototype-functional-specpathsproject
 
requirements engineering - technologies
requirements engineering - technologiesrequirements engineering - technologies
requirements engineering - technologiesKatrien Verbert
 
Cloud based Projects at Belfast eScience Centre
Cloud based Projects at Belfast eScience CentreCloud based Projects at Belfast eScience Centre
Cloud based Projects at Belfast eScience CentreEduserv
 
FIBRE Deliverable 6.1 - Dissemination Plan
FIBRE Deliverable 6.1 - Dissemination PlanFIBRE Deliverable 6.1 - Dissemination Plan
FIBRE Deliverable 6.1 - Dissemination PlanFIBRE Testbed
 
BYTE Project Overview
BYTE Project OverviewBYTE Project Overview
BYTE Project OverviewBYTE Project
 
D7.2 Data Deployment Stage 1
D7.2 Data Deployment Stage 1D7.2 Data Deployment Stage 1
D7.2 Data Deployment Stage 1plan4all
 
D2.3 Inspire Requirements Analysis
D2.3 Inspire Requirements AnalysisD2.3 Inspire Requirements Analysis
D2.3 Inspire Requirements Analysisplan4all
 
PATHS Final state of art monitoring report v0_4
PATHS  Final state of art monitoring report v0_4PATHS  Final state of art monitoring report v0_4
PATHS Final state of art monitoring report v0_4pathsproject
 
European Policies for High Performance Computing
European Policies for High Performance ComputingEuropean Policies for High Performance Computing
European Policies for High Performance ComputingCarl-Christian Buhr
 
Skill Intelligence in the Steel Sector mc 220329.pdf
Skill Intelligence in the Steel Sector mc 220329.pdfSkill Intelligence in the Steel Sector mc 220329.pdf
Skill Intelligence in the Steel Sector mc 220329.pdfBEYOND4.0
 
Research engagement in EUDAT| www.eudat.eu |
Research engagement in EUDAT| www.eudat.eu | Research engagement in EUDAT| www.eudat.eu |
Research engagement in EUDAT| www.eudat.eu | EUDAT
 
e-SENS D2.1 Project Website and social media_v1
e-SENS D2.1 Project Website and social media_v1e-SENS D2.1 Project Website and social media_v1
e-SENS D2.1 Project Website and social media_v1Monica ANGHEL
 
Data bio d6.2-data-management-plan_v1.0_2017-06-30_crea
Data bio d6.2-data-management-plan_v1.0_2017-06-30_creaData bio d6.2-data-management-plan_v1.0_2017-06-30_crea
Data bio d6.2-data-management-plan_v1.0_2017-06-30_creaWirelessInfo
 

Ähnlich wie Habitats deliverable 4.4.1 (20)

LoCloud - D3.7: Report on services developed for local cultural institutions
LoCloud - D3.7: Report on services developed for local cultural institutionsLoCloud - D3.7: Report on services developed for local cultural institutions
LoCloud - D3.7: Report on services developed for local cultural institutions
 
Stork Deliverable D7.3 List Of Commission A2 A Services Of Common Interest
Stork Deliverable D7.3   List Of Commission A2 A Services Of Common InterestStork Deliverable D7.3   List Of Commission A2 A Services Of Common Interest
Stork Deliverable D7.3 List Of Commission A2 A Services Of Common Interest
 
Open Source Technologies for Contents and Maps
Open Source Technologies for Contents and MapsOpen Source Technologies for Contents and Maps
Open Source Technologies for Contents and Maps
 
Рынки, бизнес-модели и выручка промышленного интернета
Рынки, бизнес-модели и выручка промышленного интернетаРынки, бизнес-модели и выручка промышленного интернета
Рынки, бизнес-модели и выручка промышленного интернета
 
Emerging Technoethics of Human Interaction with Communication, Bionic and Rob...
Emerging Technoethics of Human Interaction with Communication, Bionic and Rob...Emerging Technoethics of Human Interaction with Communication, Bionic and Rob...
Emerging Technoethics of Human Interaction with Communication, Bionic and Rob...
 
PATHS first paths prototype
PATHS first paths prototypePATHS first paths prototype
PATHS first paths prototype
 
PATHS Second prototype-functional-spec
PATHS Second prototype-functional-specPATHS Second prototype-functional-spec
PATHS Second prototype-functional-spec
 
requirements engineering - technologies
requirements engineering - technologiesrequirements engineering - technologies
requirements engineering - technologies
 
Cloud based Projects at Belfast eScience Centre
Cloud based Projects at Belfast eScience CentreCloud based Projects at Belfast eScience Centre
Cloud based Projects at Belfast eScience Centre
 
FIBRE Deliverable 6.1 - Dissemination Plan
FIBRE Deliverable 6.1 - Dissemination PlanFIBRE Deliverable 6.1 - Dissemination Plan
FIBRE Deliverable 6.1 - Dissemination Plan
 
BYTE Project Overview
BYTE Project OverviewBYTE Project Overview
BYTE Project Overview
 
D7.2 Data Deployment Stage 1
D7.2 Data Deployment Stage 1D7.2 Data Deployment Stage 1
D7.2 Data Deployment Stage 1
 
D2.3 Inspire Requirements Analysis
D2.3 Inspire Requirements AnalysisD2.3 Inspire Requirements Analysis
D2.3 Inspire Requirements Analysis
 
PATHS Final state of art monitoring report v0_4
PATHS  Final state of art monitoring report v0_4PATHS  Final state of art monitoring report v0_4
PATHS Final state of art monitoring report v0_4
 
European Policies for High Performance Computing
European Policies for High Performance ComputingEuropean Policies for High Performance Computing
European Policies for High Performance Computing
 
Skill Intelligence in the Steel Sector mc 220329.pdf
Skill Intelligence in the Steel Sector mc 220329.pdfSkill Intelligence in the Steel Sector mc 220329.pdf
Skill Intelligence in the Steel Sector mc 220329.pdf
 
Research engagement in EUDAT| www.eudat.eu |
Research engagement in EUDAT| www.eudat.eu | Research engagement in EUDAT| www.eudat.eu |
Research engagement in EUDAT| www.eudat.eu |
 
e-SENS D2.1 Project Website and social media_v1
e-SENS D2.1 Project Website and social media_v1e-SENS D2.1 Project Website and social media_v1
e-SENS D2.1 Project Website and social media_v1
 
D3.2 1.0 wp3_prototyping platform implemented_20130228
D3.2 1.0 wp3_prototyping platform implemented_20130228D3.2 1.0 wp3_prototyping platform implemented_20130228
D3.2 1.0 wp3_prototyping platform implemented_20130228
 
Data bio d6.2-data-management-plan_v1.0_2017-06-30_crea
Data bio d6.2-data-management-plan_v1.0_2017-06-30_creaData bio d6.2-data-management-plan_v1.0_2017-06-30_crea
Data bio d6.2-data-management-plan_v1.0_2017-06-30_crea
 

Mehr von Karel Charvat

Foodie Geoss aip 8 presentation new
Foodie Geoss aip 8 presentation newFoodie Geoss aip 8 presentation new
Foodie Geoss aip 8 presentation newKarel Charvat
 
ISAF 2015 Farmtelemetry
ISAF 2015 FarmtelemetryISAF 2015 Farmtelemetry
ISAF 2015 FarmtelemetryKarel Charvat
 
Envirofi FOODIE Data model
Envirofi FOODIE Data modelEnvirofi FOODIE Data model
Envirofi FOODIE Data modelKarel Charvat
 
Ict for a sustainable agriculture – public support needs
Ict for a sustainable agriculture – public support needsIct for a sustainable agriculture – public support needs
Ict for a sustainable agriculture – public support needsKarel Charvat
 
Aplication of remote sensing in Foodie
Aplication of remote sensing in FoodieAplication of remote sensing in Foodie
Aplication of remote sensing in FoodieKarel Charvat
 
Plan4 business vison for suistenable future final
Plan4 business   vison for suistenable future finalPlan4 business   vison for suistenable future final
Plan4 business vison for suistenable future finalKarel Charvat
 
Invitation for P4b end user-ws
Invitation for P4b end user-wsInvitation for P4b end user-ws
Invitation for P4b end user-wsKarel Charvat
 
The habitats approach to build the inspire infrastructure
The habitats approach to build the inspire infrastructureThe habitats approach to build the inspire infrastructure
The habitats approach to build the inspire infrastructureKarel Charvat
 
Plan4business technical solution
Plan4business technical solutionPlan4business technical solution
Plan4business technical solutionKarel Charvat
 
Smart opendata ISESS 2013
Smart opendata ISESS 2013Smart opendata ISESS 2013
Smart opendata ISESS 2013Karel Charvat
 
Statement club of ossiach
Statement club of ossiachStatement club of ossiach
Statement club of ossiachKarel Charvat
 
Inspire in pocket dresden 2
Inspire in  pocket dresden 2Inspire in  pocket dresden 2
Inspire in pocket dresden 2Karel Charvat
 
Gi2013 presentation mildorf+team_plan4_business_dresden
Gi2013 presentation mildorf+team_plan4_business_dresdenGi2013 presentation mildorf+team_plan4_business_dresden
Gi2013 presentation mildorf+team_plan4_business_dresdenKarel Charvat
 
Gi2013 vohnout&team-enviro grids
Gi2013 vohnout&team-enviro gridsGi2013 vohnout&team-enviro grids
Gi2013 vohnout&team-enviro gridsKarel Charvat
 

Mehr von Karel Charvat (20)

Process Model
Process ModelProcess Model
Process Model
 
Foodie Geoss aip 8 presentation new
Foodie Geoss aip 8 presentation newFoodie Geoss aip 8 presentation new
Foodie Geoss aip 8 presentation new
 
ISAF 2015 Farmtelemetry
ISAF 2015 FarmtelemetryISAF 2015 Farmtelemetry
ISAF 2015 Farmtelemetry
 
Envirofi FOODIE Data model
Envirofi FOODIE Data modelEnvirofi FOODIE Data model
Envirofi FOODIE Data model
 
Pomodore@1
Pomodore@1Pomodore@1
Pomodore@1
 
Hive OS
Hive OSHive OS
Hive OS
 
Ict for a sustainable agriculture – public support needs
Ict for a sustainable agriculture – public support needsIct for a sustainable agriculture – public support needs
Ict for a sustainable agriculture – public support needs
 
Aplication of remote sensing in Foodie
Aplication of remote sensing in FoodieAplication of remote sensing in Foodie
Aplication of remote sensing in Foodie
 
Plan4 business vison for suistenable future final
Plan4 business   vison for suistenable future finalPlan4 business   vison for suistenable future final
Plan4 business vison for suistenable future final
 
Centralab workshop
Centralab workshopCentralab workshop
Centralab workshop
 
Invitation for P4b end user-ws
Invitation for P4b end user-wsInvitation for P4b end user-ws
Invitation for P4b end user-ws
 
The habitats approach to build the inspire infrastructure
The habitats approach to build the inspire infrastructureThe habitats approach to build the inspire infrastructure
The habitats approach to build the inspire infrastructure
 
Plan4business technical solution
Plan4business technical solutionPlan4business technical solution
Plan4business technical solution
 
Smart opendata ISESS 2013
Smart opendata ISESS 2013Smart opendata ISESS 2013
Smart opendata ISESS 2013
 
Statement club of ossiach
Statement club of ossiachStatement club of ossiach
Statement club of ossiach
 
Inspire in pocket dresden 2
Inspire in  pocket dresden 2Inspire in  pocket dresden 2
Inspire in pocket dresden 2
 
Agrixchange dresden
Agrixchange dresdenAgrixchange dresden
Agrixchange dresden
 
Gi2013 presentation mildorf+team_plan4_business_dresden
Gi2013 presentation mildorf+team_plan4_business_dresdenGi2013 presentation mildorf+team_plan4_business_dresden
Gi2013 presentation mildorf+team_plan4_business_dresden
 
Gi2013 vohnout&team-enviro grids
Gi2013 vohnout&team-enviro gridsGi2013 vohnout&team-enviro grids
Gi2013 vohnout&team-enviro grids
 
Apps4 europe 2
Apps4 europe 2Apps4 europe 2
Apps4 europe 2
 

Kürzlich hochgeladen

9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesHow to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesThousandEyes
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServicePicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServiceRenan Moreira de Oliveira
 
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataCloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataSafe Software
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.francesco barbera
 

Kürzlich hochgeladen (20)

9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesHow to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServicePicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
 
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataCloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.
 

Habitats deliverable 4.4.1

  • 1. European Commission Information Society and Media DELIVERABLE Project Acronym: HABITATS Grant Agreement number: CIP- ICT-PSP-2009-3-250455 Project Title: Social Validation of INSPIRE Annex III Data Structures in EU Habitats D-4.4.1 HABITATS Service Toolkit Document identifier: D4-4-1-HABITATS service toolkit Date: 24.02.2012 Nature: P Dissemination level: PU WP Lead Partner: Graz University of Technology Revision Final Project co-funded by the European Commission within the ICT Policy Support Programme Dissemination Level PU Public X RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services) 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, 2010
  • 2. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas Abstract: This deliverable presents the background of invoking services and their relevance to the HABITATS projects and examines the basic networking architecture and specific tools that are considered. The focus of this intermediate report is on the application of these aspects within the Reference Laboratory while the final report (D4.4.2) will also include the invoking of services at the level of the different pilots. Key Words: Invoke, service toolkit, architecture design, workflow management, Reference Laboratory Authors: (in alphabetical order) Raitis Berzins Peteris Bruns Jachym Cepicky Karel Charvat (HSRS) Patrick Höfler (TUG) Lisa Maurer (TUG) Michal Sredl Martin Vlk Premysl Vohnout 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. 02/04/2012 -2-
  • 3. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas Revision History Revision Date Organization Description 01 28.11.2011 TUG First structure, document focus 02 10.12.2011 HRSR Additions, invoking services, extensions 03 05.01.2012 TUG Additions, comments 04 01.02.2012 HRSR Comments, additions 05 08.02.2012 NSI Comments and suggestions 06 9.2.2012 TUG Editing 07 9.2.2012 MAC Editing suggestions. 08 14.2.2012 HSRS WMS coordinate transformation added, small comments provided, answer on Ana comments 09 20.2.2012 TUG Summary, final editing 02/04/2012 -3-
  • 4. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas Project Officer: Krister Olson European Commission DG Information Society and Media Project Officer Address: DG INFSO – E06 Office: EUFO – 01/177 L – 2920 LUXEMBOURG Phone: +(352) 43 0134332 Fax: +(352) E-mail: Krister.olson@ec.europa.eu 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: mnc@tragsa.es 02/04/2012 -4-
  • 5. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas TABLE OF CONTENTS 1. INTRODUCTION ......................................................................................................................................... - 3 - 1.1. OBJECTIVE AND CONTEXT OF THIS DOCUMENT ........................................................................................ - 3 - 1.2. ORGANISATION OF THE DOCUMENT.......................................................................................................... - 3 - 2. INVOKING SERVICES ............................................................................................................................... - 4 - 2.1. INVOKING SERVICE REQUIREMENTS AND RECOMMENDATIONS ............................................................. - 5 - 3. HABITATS NETWORKING ARCHITECTURE AND REFERENCE LABORATORY .................... - 7 - 3.1. HABITATS NETWORKING ARCHITECTURE................................................................................................. - 7 - 3.2. REFERENCE LAB ....................................................................................................................................... - 8 - 4. HABITATS INVOKING SERVICES ....................................................................................................... - 10 - 4.1. INVOKING OF DISCOVERY SERVICES........................................................................................................ - 10 - 4.2. INVOKING OF VISUALISATION SERVICES ................................................................................................. - 11 - 4.2.1. HSLayers 3.3 .................................................................................................................................. - 11 - 4.2.2. Invoking of WFS and WCS ............................................................................................................. - 17 - 4.2.3. Filter Encoding Filtering WFS Layers ........................................................................................... - 21 - 4.3. WPS INVOKING ...................................................................................................................................... - 26 - 4.4. HSLAYERS SOS CLIENT ......................................................................................................................... - 29 - 4.5. HSLAYERS EMBED COMPONENT ............................................................................................................ - 30 - 5. PROCESSING WORKFLOW MANAGEMENT.................................................................................... - 33 - 5.1. ORCHESTRATION ENVIRONMENT ............................................................................................................ - 33 - 5.1.1. Workflow Management System ....................................................................................................... - 33 - 5.1.2. Business Process Execution Language........................................................................................... - 33 - 5.2. ENGINES AND WORK-FLOW MANAGERS .................................................................................................. - 33 - 5.2.1. Apache ODE ................................................................................................................................... - 34 - 5.2.2. Orchestra ........................................................................................................................................ - 34 - 5.2.3. Taverna Server ............................................................................................................................... - 35 - 5.3. WORKFLOW DESIGNERS.......................................................................................................................... - 36 - 5.3.1. 52°North WPS Workflow Modeller and Orchestration API ........................................................... - 36 - 5.4. ECLIPSE BPEL ..................................................................................................................................... - 37 - 5.4.1. HUMBOLDT Workflow Design and Construction Service ............................................................ - 38 - 5.4.2. Taverna Workbench........................................................................................................................ - 40 - 6. CONCLUSION............................................................................................................................................ - 43 - 7. REFERENCES ............................................................................................................................................ - 44 - 02/04/2012 -2-
  • 6. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 1. INTRODUCTION 1.1. OBJECTIVE AND CONTEXT OF THIS DOCUMENT The aim of WP4 (Network service architecture) is to define SDI network services to enable trans- European sharing of habitats-related spatial data between public authorities and other stakeholders in the community (HABITATS DoW 2010) and sharing of such data across regions and across countries. This work builds on the data modelling of WP3 and also refers to the user requirements and scenarios developed in WP2 and in cooperation with the pilots of WP5. The prototype versions of the single services are on the other hand again relevant for the developments in the social validation process and will therefore provide valuable feedback. The development of the network service architecture process of WP4 is 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. The Task 4.4 deals with the tools for invoking of Geospatial Services that arise within the HABITATS network architecture, interlinking different data sources and also interlinking data sources from different INSPIRE thematic areas. This is first version of the document, the update and final version will be released in Month 27. 1.2. ORGANISATION OF THE DOCUMENT The document is divided into five chapters” • Introduction describing general problem of invoking services and implementation of invoking services in INSPIRE (Chapter 2) • Basic description of Habitats Networking Architecture and Habitats Reference Laboratory (Chapter 3) • Principles of basic services that are invoked in reference laboratory (Chapter 4) • Analysis and Processing of Workflow Management for Spatial Data (Chapter 5) • Conclusion and tasks for next period of development inside of Habitats (Chapter 6) 02/04/2012 -3-
  • 7. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 2. INVOKING SERVICES The definition of spatial data services included in the INSPIRE directive1 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. ISO 19119 define also taxonomy for Geospatial services2: • 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 services3 From INSPIRE Networking architecture, there are basic Networking services 1. Discovery Service (discovery): Is a service 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. 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 4 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. 1 Commission of the European Communities, 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). 2007, Commission of the European Communities: Brussels. 2 INSPIRE Invoke Services, Roberto Lucchi, Michel Millot, European Commission, Joint Research Centre, Institute for Environment and Sustainability 3 HABITATS, CIP- ICT-PSP-2009-3-250455, Social Validation of INSPIRE Annex III Data Structures in EU Habitats, D-3.2a – HABITATS - 250455 4 INSPIRE Spatial Data Services and Invoke Service – Draft, implementing rules, Draft_IR_SDS_and_Invoke_1.0.doc 02/04/2012 -4-
  • 8. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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 2.1. 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 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 02/04/2012 -5-
  • 9. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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. 02/04/2012 -6-
  • 10. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 3. HABITATS NETWORKING ARCHITECTURE AND REFERENCE LABORATORY 3.1. HABITATS NETWORKING ARCHITECTURE The HABITATS Networking Architecture has the goal of defining a system able to ensure the interoperability and security of provided data and services. In particular, since integration with the INSPIRE initiatives is needed, it is based on: • A methodological approach able to define a system architecture that is scalable and adaptable to the specifications and standards currently being defined; • The adoption of a Service Oriented Architecture based on Web Services and SOAP technology. The platform neutral networking architecture of HABITATS and the basic set of networking services can be seen as an extension of existing INSPIRE services, for the management, discovery, sharing and processing of spatial planning data by public and commercial sector, NGOs, citizens, private sector, education and science, and all those who play an important role in biodiversity and see region protection and also exploitation. (HABITATS D4.2.1 2010) As already described in D4.1, the architecture design is realised on the basis of a Reference Model of Open distributed Processing (RM-ODP) (ISO/IEC 10746-1) The use of RM-ODP will give us two opportunities: To define the basic design of the solution as platform neutral and to support different local implementation, and to build on positive experiences of previous European research projects, as this methodology is used by most European (mainly research) projects and some recommendations already exist. The architecture design provides an overall conceptual framework for building geo- processing services for biodiversity, sea region protection and for effective management and utilisation of sensitive areas. (HABITATS D4.2.1 2010) The HABITATS networking services will be ultimately applied on two levels: The HABITATS Reference Laboratory (see also chapter 3) as a central portal with the support of global data, but also supporting cross scenarios implementations, and the HABITATS pilot applications, as implementations of single HABITATS pilot cases, which will also be used for testing the sharing of local data and metadata. (HABITATS D4.3.1 2011) The inter-linkage of the Reference Lab and the pilot implementations is visualized in the illustration below (taken from HABITATS D4.2.2 2011). 02/04/2012 -7-
  • 11. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas The reference laboratory has the following roles: • To offer a possibility for testing new services • To offer access to global data for pilots • To support implementation of cross-pilot scenarios • To make the Habitats services discoverable for external platforms The pilot implementations will implement only the functionality required by the respective pilot users, the Reference Laboratory will implement the full functionality. (HABITATS D4.2.2 2011) The RM-ODP divides all processes of architecture design into five generic and complementary steps, which are called viewpoints of the system and its environment. These viewpoints are the: • Enterprise viewpoint: Focusing on the analysis of pilot scenarios and the definition of a limited number of generic use cases, • Information viewpoint: Focusing on the basic data and metadata sets that could be shared among the different scenarios • Computational viewpoint: Focusing on generic components that could be reused for more scenarios • Engineering viewpoint: Defining a generic scheme that can be reused for all pilot implementations • Technology viewpoint: Defining basic architecture modifications for single scenarios and suggesting potential technical implementations 3.2. REFERENCE LAB The reference laboratory, as already mentioned in the previous chapter, is the central hub of the HABITATS Networking Architecture. It consists of several layers, which are (HABITATS D4.2.2 2011): 02/04/2012 -8-
  • 12. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas • 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 • 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. 02/04/2012 -9-
  • 13. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 4. HABITATS INVOKING SERVICES 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. In the final version (D4.4.2. - due June 2012) we will extend this approach also to the pilot platform. 4.1. 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. After registration of these services, this catalogue could be used for harvesting or multi-searching on the side of the Reference Laboratory discovery services. 02/04/2012 - 10 -
  • 14. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 4.2. INVOKING OF VISUALISATION SERVICES Visualisation services WMS (similar to WPS5 or SOS) are invoked through HSlayers on Reference Laboratory 4.2.1. HSLayers6 3.3 HSLayers combines capabilities of ExtJS (part of Sencha7) and OpenLayers and several helping scripts to establish truly Web GIS applications. The development started in 2007. In 2009, after 2 years of development, it was released under conditions of the GNU General Public License 3. OpenLayers8 is a JavaScript toolkit for the creation of mapping applications in the web browsers. OpenLayers is in some ways more powerful than Google Maps toolkit: • It can show maps based on various raster and vector formats. • It has connectors to many standards and quasi-standards such as MapServer, OGC Web Mapping Service, ArcIMS, simple Image layer, GML, GeoRSS, KML, Text and others and Google, Yahoo and VirtualEarth for commercial data providers. • The user – creator of mapping applications – does not need to take care about differences between various web browsers and their JavaScript implementation or between various data formats. ExtJS is a multi-browser JavaScript library for building rich internet applications. It consists of customisable User Interface widgets, ready to be used by designers of Graphical User Interface, similar to desktop widgets, which among others are text field and text area input controls, date fields with a pop-up date-picker, numeric fields, list box, radio and checkbox buttons, wysiwyg html editor, text grids, suitable for spreadsheets, trees, tab panels, toolbars, menus and sliders. ExtJS was originally 5 http://opengeospatial.org/standards/wps 6 http://bnhelp.cz/hslayers 7 http://sencha.com 8 http://openlayers.org/ 02/04/2012 - 11 -
  • 15. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas built as an add-on library extension of Yahoo UI, but now it is a standalone project. In HSLayers, we are still using ExtJS version 3.x. HSLayers features are coming up from OpenLayers and therefore their characteristics are as follows: • Portrayal of various types of data: • Raster: OGC WMS(-T), Image (PNG, JPEG, GIF), … • Vector: OGC WFS(-T), GML, GeoRSS, KML, GPX, GeoJSON, … • Data sources from commercial servers: Google Maps, Virtual Earth, Yahoo Maps, … • The user interface (use control) adheres to current conventions in web map portals. • Information about queried objects in text bubbles. HSLayers additional functions include: • Dynamic adding of OGC (Open Geospatial Consortium) services into map - clients for WMS, WFS, WCS, KML, GeoRSS and others. • Basic WFS filtering • Transformation (warping) of services, with different coordinate reference system. • Portrayal of independent data sources on the client side. Map composition is composed on the basis of requests to various servers. It is thus not necessary to install a map server. • Saving of map composition according to WMC (Web Map Context) OGC specification on user computer for repeated future use or for sharing between users. • Extension of compute functions based on WPS (Web Processing Service ) OGC service - 9 according to user needs – generic WPS Client available. • Multilingual environment • Map requests to various types of data stored on various servers, with automatic processing of results • Work with micro-formats • Search on the map using various Gazetteers services. • Connection of the application with catalogue client (OGC CSW) in the geoportal, which enables display of the searched service from catalogue directly on the map. • Vector editing function including snapping to chosen layers on the server. • Possibilities for advanced configuration of user requests • Advanced measuring of length and surfaces • Printing of map compositions - possibility of large print outs (up to A0 format), user configuration of print settings using HTML templates. PDF output as well as various image formats. 4.2.1.1. LayerSwitcher LayerSwitcher has now a two panel interface, which makes it easy for the user to manipulate a large list of layers in the map application. The first panel represents the “logical view” on the layer list – layers can be organized into folders and so user can keep logical structure of displayed data. The second panel represents the “physical view” - order of layers, displayed in the map window in the stack. Usually, aerial photos are organized at the bottom of the stack, and cadaster maps are displayed at the top of the stack and their organization into folders does not make much sense. 9 http://en.wikipedia.org/wiki/Web_Processing_Service 02/04/2012 - 12 -
  • 16. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas This version of HSLayers also brings the ability to hide used components to side panel of the application (dock) and whenever needed, it can be undocked again into a separate window. Users on smaller screen resolutions can enlarge some tool they need to use and so they are not limited to the size of the side panel. 4.2.1.2. Copyrights HSlayers also support publishing of information about copyrights related to single services. Information is taken from metadata 02/04/2012 - 13 -
  • 17. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 4.2.1.3. 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. The second possibility is to add the WMS url directly to the visualisation client HSlayers. The URL could be added using OWS services. 02/04/2012 - 14 -
  • 18. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 4.2.1.4. 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. WMS Sequence diagram. 02/04/2012 - 15 -
  • 19. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas WMS transformation result - left map coordinate system, right - transformed result from EPSG:4326 source. 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. 4.2.1.5. 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. 10 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 10 Orchestra http://www.eu-orchestra.org/TUs/Standards/en/html/Unit4_learningObject6.html 02/04/2012 - 16 -
  • 20. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas • Save composition on local disk • Save composition with metadata on server • 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. 4.2.1.6. Printing 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 or saving the content of the map into a raster image. 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 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 layed out 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. 4.2.2. 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 02/04/2012 - 17 -
  • 21. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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 3, 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. 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: 4 http://mapserver.org 02/04/2012 - 18 -
  • 22. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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. 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. 5 http://gdal.org 6 http://sourceforge.net/apps/trac/owslib/wiki 02/04/2012 - 19 -
  • 23. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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. 02/04/2012 - 20 -
  • 24. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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. 4.2.2.1. 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 4.2.2.2. Further development Currently, when full featured Capabilities response is sent back from the server to the client, for some servers, with high amounts of data, this can take a long time. For WFS for example, GetCapabilities, DescribeFeatureType and sometimes even GetFeature requests are to be called, before all necessary metadata are filled to MapFile. This certainly makes the Capabilities response come back after a long time. In the future, we would like to eliminate this, so that only the smallest amount of requests (GetCapabilities) would have to be requested, and WMS Capabilities response could possibly be returned faster. Of course, when a user chooses the particular layer to be displayed, additional non-standard calls would have to be done, in order to get addition attributes, so that the client has all of the necessary information (which can be normally taken from the Capabilities document). Also up to now, virtually no configuration caching is created. For each GetCapabilities request, new temporary MapFile configuration is established. A proper way would be to use already existing MapFile for a particular service if it is already generated, and to evaluate the difference between the cached version and the potentially upgraded service. Proxy4ows is not caching any data. It is open for further investigation, if it would make sense to pre- cache some original data at the Proxy4ows side, in order to make the performance better. 4.2.3. Filter Encoding Filtering WFS Layers Filter Encoding is an Open Geospatial Consortium standard11 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'. 4.2.3.1. FE Examples:12 Simple comparison filter can look like that: Filter PropertyIsLessThan 11 http://www.opengeospatial.org/standards/filter 12 All the examples in here are using FES 1.1.0, unless specified otherwise 02/04/2012 - 21 -
  • 25. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas PropertyNameDEPTH/PropertyName Literal20/Literal /PropertyIsLessThan /Filter Example 1. Spatial filter can, among other things, define a polygon that the desired features should overlap: Filter Overlaps PropertyNameGeometry/PropertyName gml:Polygon srsName=http://www.opengis.net/gml/srs/epsg.xml#63266405 gml:outerBoundaryIs gml:LinearRing gml:posList ... /gml:posList /gml:LinearRing /gml:outerBoundaryIs /gml:Polygon /Overlaps /Filter Example 2. Logical filter allows to combine filters: Filter And PropertyIsLessThan ... /PropertyIsLessThan Overlaps ... /Overlaps /And /Filter Example 3. More examples can be found in the Filter Encoding standard. 4.2.3.2. 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 . 02/04/2012 - 22 -
  • 26. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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 section specifies the filter capabilities of the particular server. It can look as follows: ogc:Filter_Capabilities ogc:Spatial_Capabilities ogc:GeometryOperands ogc:GeometryOperandgml:Point/ogc:GeometryOperand ogc:GeometryOperandgml:LineString/ogc:GeometryOperand ogc:GeometryOperandgml:Polygon/ogc:GeometryOperand ogc:GeometryOperandgml:Envelope/ogc:GeometryOperand /ogc:GeometryOperands ogc:SpatialOperators ogc:SpatialOperator name=BBOX/ ogc:SpatialOperator name=Equals/ ogc:SpatialOperator name=Disjoint/ ogc:SpatialOperator name=Intersect/ /ogc:SpatialOperators /ogc:Spatial_Capabilities ogc:Scalar_Capabilities ogc:LogicalOperators/ ogc:ComparisonOperators ogc:ComparisonOperatorLessThan/ogc:ComparisonOperator ogc:ComparisonOperatorGreaterThan/ogc:ComparisonOperator ogc:ComparisonOperatorLessThanEqualTo/ogc:ComparisonOperator ogc:ComparisonOperatorGreaterThanEqualTo/ogc:ComparisonOperator ogc:ComparisonOperatorEqualTo/ogc:ComparisonOperator ogc:ComparisonOperatorNotEqualTo/ogc:ComparisonOperator ogc:ComparisonOperatorLike/ogc:ComparisonOperator ogc:ComparisonOperatorBetween/ogc:ComparisonOperator /ogc:ComparisonOperators ogc:ArithmeticOperators ogc:SimpleArithmetic/ ogc:Functions ogc:FunctionNames ogc:FunctionName nArgs=1SIN/ogc:FunctionName ogc:FunctionName nArgs=1COS/ogc:FunctionName ogc:FunctionName nArgs=1TAN/ogc:FunctionName /ogc:FunctionNames /ogc:Functions 02/04/2012 - 23 -
  • 27. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas /ogc:ArithmeticOperators /ogc:Scalar_Capabilities ogc:Id_Capabilities ogc:EID/ ogc:FID/ /ogc:Id_Capabilities /ogc:Filter_Capabilities Example 4. DescribeFeatureType Properties that can be used to filter features of a specific type are advertised in the response to the DescribeFeatureType request. In the example below, four properties can be used to filter the features of the type location: DEPTH, SURFACE, AREA and CODE. complexType name=locationType complexContent extension base=gml:AbstractFeatureType sequence element name=msGeometry type=gml:SurfacePropertyType minOccurs=0 maxOccurs=1/ element name=DEPTH type=Integer/ element name=SURFACE type=Character/ element name=AREA type=Real/ element name=CODE type=Character/ /sequence /extension /complexContent /complexType Example 5. GetFeature When the filter capabilities of the server are known as well as the properties of the particular feature type, the filter can be created following the FE standard. Consider the filter from Example 1, this time extended with the namespaces. It selects all the features whose DEPTH property is less than 20. To the GetFeature request the FILTER parameter is added and the filter is provided as the value: http://localhost/cgi- bin/ows?REQUEST=GetFeatureVERSION=1.1.0SERVICE=WFSTYPENAME=locationFIL TER=ogc:Filter xmlns:ogc=http://www.opengis.net/ogcogc:PropertyIsLessThanogc:PropertyNameDEPTH/ ogc:PropertyNameogc:Literal20/ogc:Literal/ogc:PropertyIsLessThan/ogc:Filter Example 6. 02/04/2012 - 24 -
  • 28. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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: 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. 02/04/2012 - 25 -
  • 29. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 4.2.3.3. Implementation Implemenation of the Filter Encoding is shown on the following illustration: 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. 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. 4.2.3.4. Next Steps In terms of standards, FES 1.0.0 and FES 1.1.0 is supported. From various types of filters, only the comparison filter is currently supported by the GUI. As next steps, more filter types can be added. That covers logical filter enabling to combine various filters, spatial filter, expression editor, filtering based on feature IDs, support for server-side functions and filtering based on time. 4.3. 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, 02/04/2012 - 26 -
  • 30. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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. 4.3.1.1. HSLayers WPSCLient ComplexData handler 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 13[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. 13 http://redmine.ccss.cz/project/owsproxy 02/04/2012 - 27 -
  • 31. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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 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. 02/04/2012 - 28 -
  • 32. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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. 4.4. HSLAYERS SOS CLIENT The SOS client in HSLayers is a component which can be used for browsing data from any OpenGIS Sensor Observation Service (OGC SOS) compliant services. The component can be used together with map application based on HSLayers, or independently with any non map application. Th actual version of component supports only operations from OGC SOS Core Profile which must be implemented in every OGC SOS compliant services. Operations supported in the actual version are: • GetCapabilities - returns a service description containing information about the service interface and the available sensor data • DescribeSensor - returns a description of one specific sensor, sensor system or data producing procedure • GetObservation - provides pull-based access to sensor observations and measurement-data via a spatio-temporal query that can be filtered by phenomena and value constraints Future versions of components will contain also operations from OGC SOS Enhanced Profile and will offer more functionality for working with data from OGC SOS services. 4.4.1.1. 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 • 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 02/04/2012 - 29 -
  • 33. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 4.5. 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 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) 02/04/2012 - 30 -
  • 34. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas The HSLayers Embed component consists of several parts on the client and on the server side. • Embed Generator – this part is responsible for displaing 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. 4.5.1.1. How does it work 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. 02/04/2012 - 31 -
  • 35. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 4.5.1.2. 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. 02/04/2012 - 32 -
  • 36. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 5. 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. 5.1. 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. 5.1.1. Workflow Management System Workflow Management System (WMS) is a piece of software that provides an infrastructure to setup, execute, and monitor scientific workflows. In other words, the WMS provide an environment where in experiments can be defined and executed. An important function of a WMS during the workflow execution or enactment is the coordination of operation of individual components that constitute the workflow – the process also often referred to as orchestration. As research becomes more data-intensive and more reliant on the use of computers, larger volumes of experimentation data are recorded quicker and with greater precision. This trend has spurred a significant increase in the complexity of scientific simulation software. Many tools only perform a small well-defined task, thus necessitating that several of them are joined in a pipeline to model a useful experiment. Additional difficulties arise from the need to deal with the incompatible data formats that various services produce or consume. It is evident that considerable amount of computer science knowledge is required to overcome the outlined problems. However, domain scientists across disciplines do not have sufficient relevant expertise. Scientific workflows and WMSs have emerged to solve this problem and provide an easy-to-use way of specifying the tasks that have to be performed during a specific in silico experiment. The need to combine several tools into a single research analysis still holds, but technical details of workflow execution are now delegated to Workflow Management Systems. 5.1.2. 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. 5.2. 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. 02/04/2012 - 33 -
  • 37. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 5.2.1. 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 5.2.2. Orchestra Name: Orchestra 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. 02/04/2012 - 34 -
  • 38. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas In Orchestra server is bundled with web based workflow management Console (Figure 2). 5.2.3. 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. 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. 02/04/2012 - 35 -
  • 39. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 5.3. WORKFLOW DESIGNERS An integral part of orchestration engines and workflow managers are designers to prepare executable workflow documents. 5.3.1. 52°North WPS Workflow Modeller and Orchestra tion 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. 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. 02/04/2012 - 36 -
  • 40. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas The WPS Workflow Modeller allows the visual modeling 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 RBD program(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. 5.4. 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 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. 02/04/2012 - 37 -
  • 41. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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 Modeling 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. 5.4.1. HUMBOLDT Workflow Design and Construction Service Name: HUMBOLDT Workflow Design and Construction Service Version: svn Platform: independent, language Java Short description Vendor: NATURE-SDI project Licence: Homepage: http://community.esdi-humboldt.eu/wiki/5 The HUMBOLDT Workflow Design and Construction Service consists of two sub-systems, a graphical user interface, called the Workflow Editor, allowing users to compose geo-processing components into workflows. Second, a web service, called the Workflow Repository Service, that accepts requests for workflows and delivers them to clients (in HUMBOLDT, the Mediator Service). 02/04/2012 - 38 -
  • 42. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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 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. 02/04/2012 - 39 -
  • 43. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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. 5.4.2. 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 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. 02/04/2012 - 40 -
  • 44. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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 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 02/04/2012 - 41 -
  • 45. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 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 02/04/2012 - 42 -
  • 46. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 6. CONCLUSION This report gives a brief overview of the tools for invoking Geospatial Services that arise within the HABITATS network architecture. Invoking services are described and a few examples of invoking services in the Reference Laboratory are demonstrated, and possibilities of Workflow management are analysed. Basically the architecture design is realised on the basis of a Reference Model of Open distributed Processing (RM-ODP), while the HABITATS networking services will be ultimately applied on the two levels of the Reference Laboratory as a central portal and on the level of the pilot cases for local data testing and sharing. This first version of the deliverable examines the invoking services used in the Reference Laboratory. As invoking strongly depends on the used platform, this first report mainly reflects the developments in the reference Laboratory in order to support developers to implement or invoke their services. In the next phase (which will be reported in D4.4.2) the focus will be on invoking the services at the level of the pilots and on the implementation of workflow management systems for the purpose of HABITATS. 02/04/2012 - 43 -
  • 47. Date: 24/02/2012 HABITATS service toolkit Doc. Identifier: D4-4-1 Project: Social Validation of INSPIRE Annex III Data Structures in EU Habituas 7. REFERENCES Güting 2005: Ralf Hartmut Güting, Markus Schneider. Moving Objects Databases.2005, ISBN 978- 0120887996. HABITATS DoW 2010: Description of Work, “Social Validation of INSPIRE Annex II Data Structures in EU Habitats” HABITATS D4.2.1 2010: D4.2.1- INSPIRE Networking Architecture Design, 2010 HABITATS D4.2.2 2011: D4.2.2 – INSPIRE Networking Architecture Design, 2011 HABITATS D4.3.1 2011: D4.3.1 – HABITATS networking services ISO/IEC 10746-1 Information technology – Open Distributed Processing – Reference model: Overview, ISO (1998) 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/ ). 02/04/2012 - 44 -