habitats d4.2.2 final

European Commission

Information Society and Media

This project is partially funded under the ICT Policy Support Programme as part of the Competitiveness and Innovation Framework Programme by the European Commission http://ec.europa.eu/ict_psp This document reflects only the author's views and the European Community is not liable for any use that might be made of the information contained herein. © HABITATS Consortium, 2010

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

HABITATS INSPIRE Networking Architecture

Document identifier: D 4.2.2

Date: July 28th, 2011

Nature: REPORT

Dissemination level: PU

WP Lead Partner: HSRS

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)

Date: 2011-08-01 Habitats INSPIRE Networking Architecture

Doc. Identifier: D-4.2.2

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

- 2 -

Abstract:

This document defines the generic architecture for the HABITATS project, but also include individual pilot applications and Reference Laboratory. The Architecture definition use RM-ODP methodology. The document is updating of first version of D4.2.1 and it was updated on the base of pilot works during period from Month 9 to Month 15. On the base of pilot user cases, generic user cases are defined. Architecture is defined as platform independent.

Key Words:

INSPIRE, Networking Architecture , RM ODP, Metadata, Data models, Reference Laboratory, Pilots implementation

Authors:

Karel Charvat HSRS

Gregorio Urquía Osorio TRAGSATEC

Lisa Maurer TUG

Peteris Bruns IMCS

John O’Flaherty MAC

Andrea Scianna Madonie

Filip Hajek, Marek Mlcousek, Jan Bojko FMI




- 3 -

Revision History

Revision Date Author Organization Description

2010-09-14 K.Charvat HSRS Table of Contents

2010-09-21 K.Charvat HSRS TOC, responsibilities

2011-01-31 K.Charvat HSRS Draft version

2011-02-10 G.Urquia TRAGSATEC Revision, detail modifications, comments

2011-02-10 K. Charvat HSRS Update of documents, user scenarios, generic scenarios, and single viewpoints

2011-02-15 L.Maurer TUG Comments

2011-02-17 K. Charvat HSRS Revision

2011-03-03 A.Sierra TRAGSA Format Revision

V1.0 2011-07-15 K. Charvat HSRS Document updating and including contribution from partners

V1.1 2011-07-21 K. Charvat HSRS Integration of contribution from MAC, IMCS and TRAGSATEC

V1.2 2011-07-25 K. Charvat HSRS Update of introduction

V1.3 2011-07-25 A. Sierra TRAGSA Format revision

Final 2011-07-28 All Final revision

Document Change Record

Issue Date Author Item Reason for Change




- 4 -

Project Officer: Krister Olson

Address:

European Commission

DG Information Society and Media

Project Officer

DG INFSO – E06

Office: EUFO – 01/177

L – 2920 LUXEMBOURG

Phone: +(352) 43 0134332

Fax: +(352)

E-mail: [email protected]

Project Manager: Mariano Navarro

Address: C/ Julián Camarillo, 6b, 28037, Madrid, Spain

Phone: + 34 91 322 65 21

Fax: + 34 91 322 63 23

E-mail: [email protected]

Date: 2011-08-01 Habitats INPIRE Networking Architecture

Doc. Identifier: D 4.2.2


5

TABLE OF CONTENTS

1. INTRODUCTION ..............................................................................................................................................7

1.1. TERMS ..........................................................................................................................................................7 1.2. ABBREVIATIONS ............................................................................................................................................8

2. METHODOLOGY .............................................................................................................................................9

2.1. BASIC PRINCIPLES OF RM ODP METHODOLOGY AND ITS APPLICATION FOR HABITATS .....................................9 2.2. GENERIC AND PILOT DESIGN ......................................................................................................................... 11

3. ENTERPRISE VIEWPOINT – USER SCENARIOS, USE CASES AND BUSINESS MODELLING .... 12

3.1. PILOT DEFINITION ........................................................................................................................................ 12 3.2. WILD SALMON MONITORING ....................................................................................................................... 12 3.3. LA PALMA PROTECTED MARINE AREA ........................................................................................................ 16 3.4. NATURAL RESERVE ..................................................................................................................................... 18 3.5. HIKING TRIP PLANNER................................................................................................................................. 20 3.6. SHEEP AND GOAT HERDING MANAGEMENT ................................................................................................ 22 3.7. ECONOMICAL ACTIVITY AT MARINE COASTAL BENTHIC HABITATS .............................................................. 25 3.8. NATIONAL FOREST PROGRAMME ................................................................................................................. 27

3.8.1. Cross pilot use cases ........................................................................................................................... 34 3.9. PILOT ACTORS ............................................................................................................................................. 38 3.10. GENERIC ACTORS AND USERS ..................................................................................................................... 39 3.11. ACTORS ACTIVITIES. ................................................................................................................................. 41 3.12. GENERIC USE CASES ................................................................................................................................... 43

4. INFORMATION VIEWPOINT – WHICH DATA AND HOW WILL BE SHARED .............................. 50

4.1. DATA TYPES USED IN HABITATS ARCHITECTURE AND HOW THE DATA ARE ACCESSED ................................. 50 4.2. INFORMATION LIFE-CYCLE ........................................................................................................................... 51

4.2.1. Reference data ..................................................................................................................................... 51 4.2.2. Satellite imagery .................................................................................................................................. 52 4.2.3. In-situ observation ............................................................................................................................... 52 4.2.4. Terrain measurement ........................................................................................................................... 53 4.2.5. User edited data .................................................................................................................................. 54 4.2.6. User derived data ................................................................................................................................ 54

4.3. DATA AND METADATA MODELS ................................................................................................................... 55 4.3.1. Metadata .............................................................................................................................................. 55

4.4. SEA REGIONS ........................................................................................................................................... 57 4.5. BIO-GEOGRAPHICAL REGIONS ........................................................................................................... 57 4.6. HABITATS AND BIOTOPES .................................................................................................................... 57 4.7. SPECIES DISTRIBUTION ........................................................................................................................ 58

4.7.1. Data models ......................................................................................................................................... 58 4.7.2. Feature catalogues for sea regions ..................................................................................................... 59

4.8. DATA HARMONISATION ............................................................................................................................... 60 4.8.1. COORDINATE TRANSFORMATION ................................................................................................. 60 4.8.2. FORMAT TRANSFORMATION .......................................................................................................... 60 4.8.3. SCHEMA TRANSFORMATION .......................................................................................................... 60

4.9. USED DATA SETS .......................................................................................................................................... 61 4.9.1. Reference laboratory data sets ............................................................................................................ 61 4.9.2. Wild Salmon Monitoring ..................................................................................................................... 67 4.9.3. LA PALMA PROTECTED MARINE AREA ......................................................................................... 69 4.9.4. NATURAL RESERVE .......................................................................................................................... 70 4.9.5. HIKING TRIP PLANNER and SHEEP AND GOAT HERDING MANAGEMENT ......................... 71 4.9.6. ECONOMICAL ACTIVITY AT MARINE COASTAL BENTHIC HABITATS ...................................... 72 4.9.7. NATIONAL FOREST PROGRAMME ................................................................................................. 73

5. COMPUTATIONAL VIEWPOINT-LOGICAL ARCHITECTURE ......................................................... 76

5.1. CONCERNS ................................................................................................................................................... 76 5.1.1. FILE SYSTEM ..................................................................................................................................... 76




6

5.1.2. RDBMS ................................................................................................................................................ 76 5.1.3. Sensor connector ................................................................................................................................. 77 5.1.4. ACES infrastructure ............................................................................................................................ 78 5.1.5. Web Map server ................................................................................................................................... 79 5.1.6. Metadata server ................................................................................................................................... 80 5.1.7. WPS ..................................................................................................................................................... 81 5.1.8. Sensors server ...................................................................................................................................... 81 5.1.9. Geographical extensions for RBDSM .................................................................................................. 81 5.1.10. Web Based GIS Analytical Tools ....................................................................................................... 81 5.1.11. Registry management ........................................................................................................................ 82 5.1.12. Authorisation/Authentication ............................................................................................................. 82 5.1.13. View ................................................................................................................................................... 84 5.1.14. WFS Gazetteer ................................................................................................................................... 85 5.1.15. Data services ..................................................................................................................................... 85 5.1.16. Transformation .................................................................................................................................. 86 5.1.17. Analysis ............................................................................................................................................. 87 5.1.18. Monitoring ......................................................................................................................................... 87 5.1.19. External services ............................................................................................................................... 88 5.1.20. Geo-portal BUS ................................................................................................................................. 88 5.1.21. Applications ....................................................................................................................................... 88 5.1.22. Applets ............................................................................................................................................... 88 5.1.23. Servlets .............................................................................................................................................. 89 5.1.24. Portlets .............................................................................................................................................. 89 5.1.25. WMC .................................................................................................................................................. 90 5.1.26. RSS/GeoRSS ...................................................................................................................................... 91 5.1.27. KML/KMZ ......................................................................................................................................... 91 5.1.28. iFrame ............................................................................................................................................... 92 5.1.29. DIV .................................................................................................................................................... 92 5.1.30. Augment reality ................................................................................................................................. 92 5.1.31. CMS ................................................................................................................................................... 93 5.1.32. Social Networks and Media ............................................................................................................... 93 5.1.33. Workflow management ...................................................................................................................... 93

5.2. PILOTS COMPUTATIONAL VIEW .................................................................................................................... 94 5.2.1. WILD SALMON MONITORING ......................................................................................................... 94 5.2.2. LA PALMA PROTECTED MARINE ARE ........................................................................................... 94 5.2.3. AUGMENTED REALITY - NATURAL RESERVE ............................................................................... 95 5.2.4. HIKING TRIP PLANNER and SHEEP AND GOAT HERDING MANAGEMENT ............................. 95 5.2.5. ECONOMICAL ACTIVITY AT MARINE COASTAL BENTHIC HABITATS ...................................... 95 5.2.6. NATIONAL FOREST PROGRAMME ................................................................................................. 95

6. ENGINEERING VIEWPOINT- DISTRIBUTION OF INFRASTRUCTURE .......................................... 97

6.1. RELATION OF PILOT IMPLEMENTATION AND REFERENCE LABORATORY ....................................................... 97 6.2. DESIGN FOR REFERENCE LABORATORY ....................................................................................................... 98

7. TECHNOLOGY VIEWPOINT – INFRASTRUCTURE MAPPING .................................................. - 100 -

7.1. EXAMPLES OF POSSIBLE COMPONENTS FOR IMPLEMENTATION ............................................................. - 100 - 7.2. REFERENCE LABORATORY IMPLEMENTATION ....................................................................................... - 102 - 7.3. PILOTS ARCHITECTURE ......................................................................................................................... - 111 -

7.3.1. WILD SALMON MONITORING .................................................................................................. - 111 - 7.3.2. LA PALMA PROTECTED MARINE AREA .................................................................................. - 112 - 7.3.3. NATURAL RESERVE ................................................................................................................... - 114 - 7.3.4. HIKING TRIP PLANNER and SHEEP AND GOAT HERDING MANAGEMENT ...................... - 115 - 7.3.5. ECONOMICAL ACTIVITY AT MARINE COASTAL BENTHIC HABITATS ............................... - 116 - 7.3.6. NATIONAL FOREST PROGRAMME .......................................................................................... - 116 -

8. CONCLUSION .......................................................................................................................................... - 119 -

9. REFERENCES .......................................................................................................................................... - 120 -




7

1. INTRODUCTION

The objective of Task 4.2 is to define generic architecture (platform neutral) and also architecture for pilot solutions. Important part basic set of networking services which are an extension of existing INSPIRE services, for the management, discovery, sharing, processing and publishing 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.

The objective of this task is to define such architecture for SDI, which will allow effective management of sensitive areas, support for tourism, education and research in this areas, and also promotion of these regions. HABITATS defines the tools and interfaces by which the different parties will be able to manage, discovery, share and reuse spatial data.

This D4.2.2 document provides final version of HABITATS networking and data sharing architecture, and suggests its possible logical components, but also possibilities, how provide practical implementation of this logical components. This architecture is based on user needs and is validated by users on the base of concrete implementations. The starting point and requirements can be found in the HABITATS deliverable D4.1, but document is mainly based on D4.2.1. Initial architecture design from D4.2.1 was modified in interaction with users to develop concrete pilot cases and led to the final architecture design. First version of the document was updated on the base on user response. In this process local technical expert’s plaid an important role, who and contributed to the testing of principles and of the architecture and cooperate on design of concrete local implementation. For this the Living Lab methodology was used.

1.1. TERMS

• infrastructure for spatial information – metadata, spatial data sets and spatial data services; network services and technologies; agreements on sharing, access and use; and coordination and monitoring mechanisms, processes and procedures, established, operated or made available in accordance with this Directive; [INSPIRE Directive]

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

• INSPIRE data specification – harmonized data product specification for a theme adopted as an Implementing Rule

• metadata – information describing spatial data sets and spatial data services and making it possible to discover, inventory and use them [INSPIRE Directive]

• spatial data – data with a direct or indirect reference to a specific location or geographic area [INSPIRE Directive]

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

• spatial object – abstract representation of a real-world phenomenon related to a specific location or geographical area [INSPIRE Directive]

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

• feature catalogue – catalogue(s) containing definitions and descriptions of the spatial object types, their attributes and associated components occurring in one or more spatial data sets, together with any operations that may be applied [ISO 19110 – modified]

• discovery services – search for spatial data sets and services on the basis of the content of the corresponding metadata and to display the content of the metadata [INSPIRE Directive]

• view services – services to display, navigate, zoom in/out, pan, or overlay viewable spatial data sets and to display legend information and any relevant content of metadata [INSPIRE Directive]

• download services – services to copy of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly [INSPIRE Directive]




8

• transformation services – services enabling spatial data sets to be transformed with a view to achieving interoperability [INSPIRE Directive]

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

1.2. ABBREVIATIONS

• INSPIRE – Infrastructure for Spatial Information in Europe • ISO – International Organisation for Standardisation • SDI – Spatial Data Infrastructure • WMS – Web Service Map • WFS – Web Feature Map • WCS – Web Coverage Map • WFS – G - Web Service Map Gazetteer • WMC – Web Map Context • WPS – Web Processing Services • CS – W - Catalogue Service Web • CNIG – National Centre of Geographic Data of Spain • URM – Uniform Resource Management • OGC – Open Geospatial Consortium • SOA – Service Oriented Architecture • CMS – content management systems • SOS – Sensor Observation Services • SAS – Sensors Alert Services • SES – Sensors Event Services • SEIS – Shared Environmental Information System • HTML – HyperText Markup Language • API – Application Programming Interface • ESA – European Space Agency • GMES – Global Monitoring for Environment and Security • GEOSS - Global Earth Observation System of Systems • EU – European Union • EC – European Commission • URI – Uniform Resource Identifier • KML – Keyhole Markup Language • GML – Geography Markup Language • RM-ODP - Reference Model of Open Distributed ProcessingINSPIRE – INfrastructure for

SPatial InfoRmation in Europe • ISO – International Organisation for Standardisation




9

2. METHODOLOGY

As was already described in D4.1, architecture design is realised on the base of a Reference Model of Open Distributed Processing (RM-ODP) (ISO/IEC 10746-1). This model is the architecture reference model used also within ISO/TC 211 “Geographic Information – Reference model” [ISO 19101:2002], and on Open Geospatial Consortium Reference Model (ORM).

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. This is important, because the objective of the document D4.2 is not to describe one unique technology solution, but to give general models, which could be used by different organisation across Europe. These models are then demonstrated on selected pilot cases that are part of the project, in order to demonstrate the feasibility of such solution

• 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. A previous analysis (D4.1) demonstrates that the basic principles for INSPIRE, GEOSS and GMES projects are very similar and that some basic building blocks could easily be re-used in different applications. Our objective is to extend these models to make them more oriented towards actual user needs.

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 The RM-ODP framework will have to be integrated with the Model Driven Architecture (MDA) approach, which allows to define the system through an abstract schema, independent from implementation tools and techniques.

2.1. BASIC PRINCIPLES OF RM ODP METHODOLOGY AND ITS APPLICATION FOR

HABITATS

The RM-ODP divides all process of architecture design into five generic and complementary steps, which are called viewpoints on the system and its environment. This viewpoints are:

• The enterprise viewpoint, which focuses on the purpose, scope and policies for the system. It describes the business requirements and how to meet them. It is based on user scenarios and user cases

• The information viewpoint, focuses on the semantics of the information and the information processing performed. It describes the information managed by the system and the structure and content type of the supporting data. This viewpoint is related to WP3, where data and metadata models are defined. The Information viewpoint extends these models and analyses also necessary operation

• The computational viewpoint provides functional decomposition of the system into objects which interact at interfaces. It describes the functionality provided by the system and its functional decomposition.

• The engineering viewpoint focuses on the mechanisms and functions required to support distributed interactions between objects in the system. It describes the distribution of processing performed by the system to manage the information and provide the functionality.

• The technology viewpoint focuses on the choice of technology of the system. It describes the technologies chosen to provide the processing, functionality and presentation of information. In




10

principle only this viewpoint is platform dependent. In our architecture design in this first document we will analyse potential components for implementation. In the second version of the document delivered in Month 15 concrete tools for single pilots will be defined.

For the architecture design of HABITATS we adapted RM ODP methodology to guarantee real adoption of user needs and to give real possibilities of an user involvement into the design process. The design process will be done iteratively with this as the first version, so all views will be modified on the basis of user validation and user experiences. It is necessary to take into consideration, that in many cases users are not familiar with newest technologies and also have no experience in the design of distributed systems. Another important aspect is also, that we don’t design one concrete solution, but a number of relatively independent services. In order to allow reuse of some components we have defined among pilots what common generic functions are that fulfil the requirements of different scenarios and what specific solution dependent components are. In the first version of the design, we will focus mainly on generic functionality, in the second version, we will try to add more pilot specific functions.

The relation of all these five viewpoints could be described by the following scheme:

The Enterprise viewpoint of the architecture design is focused on the analysis of pilot scenarios and the definition of a limited numbers of generic use cases, which are implemented to support basis functionalities required by more scenarios, but also supporting the process of data and metadata harmonisation based on outputs from WP3.

The Information viewpoint is focused on basic data and metadata sets, which could be shared among different scenarios and also will be focused on data and metadata related to HABITATS and INSPIRE specification. It is also focused on common infrastructure being accessible trough ReferenCe Laboratory

The Computational viewpoint is focused on generic components, which could be reused for more scenarios and which will be some basic parts of the infrastructure. Already here we extend the basic




11

principles of INSPIRE, GMES and GEOSS and add some new functionalities related to data management and updating.

The Engineering viewpoint defines a generic scheme, which can be reused for all pilot implementations and which could be modified for different scenarios. Also this viewpoint is platform independent.

The Technical viewpoint defines basic architecture modifications for single scenarios and suggests potential technical implementation. This solution is really basic definition and will give more option of implementation. Concrete implementation will be modified during the implementation and validation process.

2.2. GENERIC AND PILOT DESIGN

An important part of the methodology is to divide design of generic architecture and pilot dependent architecture. On the basis of user requirements, generic use cases will be defined and generics services will be designed for these generic use cases, which will be reusable for different pilot solutions. On the basis of these generic services pilot applications will be defined, which will be composed from generic services. Generic services will be available for developers so they can implement specific user applications using these generic services. Important is, that these applications can reuse existing components. Such a model was used in the past in the c@r project and also is used currently in the GENESIS project.

For the development of applications it will be possible to:

• Orchestrate existing services using some workflow management of language as BPEL

• Integrate existing services and components using standard programming tools




12

3. ENTERPRISE VIEWPOINT – USER SCENARIOS, USE CASES AND BUSINESS

MODELLING

3.1. PILOT DEFINITION

According to the HABITATS user-driven approach to standardisation, the full impact of results will be sparked off by the pilot service scenarios and their ability to attract new participants to the communities of adoption. Each pilot is therefore built on

a) existing concrete services currently carried out by project partners,

b) potentials of data access through network services and

c) enhancement through usage scenarios developed by user communities, in order to meet the three criteria of relevance, openness and responsiveness.

The pilots fall into the three forward-looking categories described above as follows:

• Management of natural resources

o Wild Salmon Monitoring (IE)

o La Palma Protected Marine Area (ES)

• Eco-tourism

o Hiking Trip Planner (IT)

o Natural Reserve (ES)

• Economic activities

o Sheep and Goat Herd Management (IT)

o Economical activity at marine coastal benthic habitats (LV)

• National policy

o Czech National Forest Programme (CZ)

Each of these validation pilots relies on trans-regional and trans-European data sharing between pilot settings within INSPIRE networks present in the project, and with collaborating members of the HABITATS User Communities.

3.2. WILD SALMON MONITORING

Partner: MAC

Location: Ireland; replicable in other Member States

Service and user scenario:

Ireland has best practice in Salmon Conservation and Management – so the processes and data-structures used in Ireland have pan-European significance for INSPIRE, and so are very relevant for the HABITATS project, and should also help to promote Irish fishing across Europe.




13

Inland Fisheries Ireland (IFI) have taken over responsibility for coordinating the monitoring and conservation of wild salmon in Ireland. MAC is working with the IFI National Salmon Monitoring Programme, Salmon Scientific Standing Committee, and other involved agencies such as the Irish Marine Institute (MI) to develop a Salmon Conservation Limits portal, to pilot the use of the HABITATS INSPIRE metadata profile, and bottom-up social validation process to improve presentation, accessibility and use of the data that is being collected, and get better buy-in by all stakeholders (particularly scientists, anglers, and angling related businesses) to be aware of, understand and engage in the salmon conservation procedures, regulations and catch limitations that are set each year. This will provide better intelligence to researchers, fishermen and decision makers on salmon conservation, so that they can better manage the wild-salmon resource in a sustainable manner and help prevent the extinction of wild salmon in rivers on the North Atlantic coast of Europe. Once operational in Ireland the process will be scaled up in collaboration with the FP7 SALSEA-Merge project which is investigating the migration and distribution of salmon in the North-East Atlantic, working with the North Atlantic Salmon Conservation Organisation (NASCO).

To explore use of the HABITATS approach, the initial Irish Salmon CL pilot is focusing on one specific area and community (such as a catchment or sub-catchment), where users can link to the various data for that area, including a range of static data (such as catch regulations, WFD fish data, water quality etc) as well as more dynamic data partially generated by users themselves there (e.g. by online listing of their catches etc). Part (or a tributary) of the river Nore in the South-East of Ireland could be a good pilot site, as discussions with the community of active local groups and stakeholders there are proving to be quite positive. However the final pilot location is to be made by the IFI in the coming weeks.

In line with IFI policy, the Salmon CL Portal will have special focus on the involvement and feedback from tourist (mainly foreign) anglers, local angling-related businesses and awareness/education of users for the social validation aspects of HABITATS. User feedback so far indicates that this could supplement and link to the many existing local angling groups and sites, to pilot a bottom-up and consultative approach that IFI could subsequently use in other contexts in Ireland and across Europe (with NASCO and SALSEA-Merge).

IFI are currently undertaking internal deliberations with their staff for their inputs and support of the Salmon CL Portal and to agree its initial community/location-focus. Once it goes active, the external stakeholders, including scientists, anglers and angling-related businesses will be brought into the process through the HABITATS validation process on the Salmon CL portal.

From an IFI business perspective this is a very worthwhile pilot that introduces IFI’s staff to the whole INSPIRE process, and also allows them and other government and public agencies to explore use of social networking to involve communities of users, improve and promote fishing, and ultimately help conserve and manage the vital wild salmon stocks.

Use of environmental data:

Wild salmon data that is being collected by the IFI and other public agencies such as the Marine Institute will be made accessible through the Salmon CL Portal to provide better intelligence to researchers, fishermen and decision makers on salmon conservation, so that they can better participate in the management of the wild-salmon resource in a sustainable manner and help prevent the extinction of wild salmon in rivers on the North Atlantic coast of Europe.

By merging genetic and ecological investigations, to advance understanding of stock specific migration and distribution patterns and overall ecology of the marine life of Atlantic salmon and gain an insight into the factors resulting in recent increases in marine mortality. Textual and map-based data from the project as it progresses is available on their website under the following headings:




14

• Background • Ecological Studies • Genetic Identification Methodology • Migration Modelling • Marine Surveys • Documents • Genetic Stock Identification

The SALSEA Group are developing 2 major databases that will be issued as a unit in the same format:

• Genetic database – the big one. Brand new work – very valuable as it allows salmon to be traced back to their rivers of origin. Keen to keep these aspects of the database private.

• Sea database – based on WGNAPES (ICES). Much simpler – smaller database. Less sensitive. Sea-going fish data. Maintained in the Faroh’s by the same people who developed the original WGNAPEs database.

Stakeholders involved:

The SALSEA Group has extensive data bases, and is currently developing 2 new ones. It is only recently that they have accepted the value of INSPIRE and its principles, but now fully accept that all of their data should be INSPIRE compliant.

Inland Fisheries Ireland (IFI), and the Irish Marine Institute (MI) collect and own the data, but collaborate with other Agencies and the North Atlantic Salmon Conservation Organisation (NASCO). The service being piloted is packaging and providing that data as better intelligence to researchers, fishermen and decision makers on salmon conservation. The main stakeholders (IFI and MI) are currently benefiting from the project in getting a clearer appreciation of INSPIRE requirements and the potential of social networking to engage all of the other stakeholders.

Once operational, the Salmon CL pilot will 1. Provide better communication, consultation and involvement of all stakeholders in the process

of specifying fishing conservation measures in Ireland and beyond. 2. Make formulation of the Irish Wild Salmon Fishing Regulations more participatory and

interactive by involving all relevant actors proactively in the process, 3. Make the datasets open and widely available (and INSPIRE complaint), 4. Enable users (such as anglers and scientists) to provide feedback on how to make the data

more useful for them. However the key and very clear long-term objective is the sustainable management, conservation and exploitation of the wild salmon stocks.

Users involved

The Pilot Service will enable Citizens, including researchers, anglers, fishermen, fishing-related businesses and public agencies (policy and regulations decision makers) to be involved, for future exploitation of the Salmon CL Portal and HABITAT’s results.

Policy / Business Model

The data collection is part of the Irish National Policy in line with its NASCO, International Council for the Exploration of the Sea (ICES) and EU Habitats Directive obligations.. Currently the data is mainly documented rather provided online. The HABITATS pilot is making it available as an online service.




15

Cooperation/ data sharing:

• La Palma Protected Marine Area (ES) • Economical activity at marine coastal benthic habitats (LV) • FAO • HSRS • IMCS

Use cases

Use case Wild Salmon Fishing Conservation in Ireland

Actors Fishermen, Anglers, Angling Researchers, Decision Makers, other actors related to the salmon fishing industry in Ireland.

Task To provide participatory input to the early stages of the formulation of the Irish wild salmon fishing conservation measures by involving all relevant actors interactively in the data monitoring process, making their databases more open and widely available (and INSPIRE complaint), and enable users to engage and provide feedback on how to make the data and related services more useful for them. For instance, anglers could provide real-time rod-catch data using a smart phone application – where catch and release fishing is allowed on rivers.

Assumptions That the proprietary databases can be made INSPIRE-compliant using the HABITATS Metadata profile to be accessible on the Irish Spatial Data Exchange (ISDE) using the HABITATS Reference Laboratory tools and portal.

So far, of the 4 HABITATS themes, the Habitats and Biotopes, and Species Distribution appear to be most relevant using the HABITATS metadata profiles (from D3.2.1) and the IFI scientist’s salmon conservation process best practice classification and naming schemas.

Description The Irish Standing Scientific Committee (SSC) on the status of Irish Salmon Stocks (or Salmon Advisory Group) scientifically analyses all data on wild salmon in Ireland and issues recommendations every December on the conservation of salmon stocks in each of the 148 Irish salmon fishing rivers for the coming year. This is a statutory based process that has a major direct impact on anglers, commercial fishermen and fishing-related businesses such as guest houses, hotels and lodges, associated with each of these individual rivers. From discussions with the various stakeholders it has become clear that the decision makers are concerned that a social validation pilot could end up doing more harm than good in this very sensitive, legal and highly political process. So the Salmon CL Portal pilot will aim to involve users in the collection and monitoring of the data at the early stages to informally feed into the formal statutory process. This allows the HABITATS social validation approach to be piloted with the wider process of wild salmon monitoring and conservation that feeds into the SSC, without upsetting its legal process. But in a broader context it also provides a useful model and experience to make the regulation process more participative in the future, and for use by the National Inland Fisheries Forum that is being established in Ireland and to tie in with IFI’s outreach work to the wider community, especially schools and school-children later on. The IFI could also use the HABITATS social validation / INSPIRE open data access approach, with a similar social networking methodology to address other environmental issues, such as addressing Invasive Species and water research coordination in Ireland.

Comments The aim is to use the HABITATS INSPIRE Social Validation approach to transform the data and modes of operation of this community from being mainly “information




16

push” to be being a lot more “User pull” by making the data open and usable online based on INSPIRE principles, open standards, and social networks to validate the utility and acceptability of the data. This will enable the development of services based on economies of scale using spatial information that adheres to a standard format that is widely adopted.

This fits well into the HABITATS “Management of Natural Resource Management” cluster, and will engage Citizens (fishermen, anglers, fishing-related business, researchers and administrators/decision-makers) to be involved, for future sustainable operation.

Use case Wild Salmon Monitoring and Management Internationally

Actors Researchers, and Decision Makers

Task The International SALSEA Group through collaboration in the FP7 SALSEA-Merge project is investigating and recording in 2 major databases, the migration and distribution of salmon in the North-East Atlantic. The Use Case is to make their extensive data open and accessible using INSPIRE principles. Based on their existing best-practice, this group is likely to impact on the proposed salmon-related data, metadata and services that will be input to the INSPIRE TWGs.

Assumptions As the SALSEA Group wish to focus all of their efforts on their scientific work until the end of the SALSEA Merge project, it will be late 2011 before they will allow their data to be made available to a HABITATS pilot. They also wish to see how the Irish National pilot gets on and reuse its learning and approach.

Description This group uses the widely used best-practice ICES WGNAPES database structure. WGNAPES is a permanent Group that will continue after the SALSEA-Merge project ends in 2011. ICES/WGNAPES is an Internal database composed of National databases. With some fields added for SALSEA-Merge and the Genetic database. So it is good practice and a permanent working group which should lead to very useful inputs to the 4 HABITATS INSPIRE themes.

Comments This case with SALSEA-Merge is complex, and touches on the potentially high commercial value of the genetic databases, which is the reason for the reticence of the scientists involved in opening up their information to be INSPIRE compliant. On the other hand, interfacing INSPIRE-compliant databases with commercial services might be the most effective means for them to profit from their research. These issues will be further explored when MAC is able to more actively engage with the SALSEA-Merge stakeholders, after their current project work ends.

3.3. LA PALMA PROTECTED MARINE AREA

Partner: TRAGSATEC

Location: The pilot takes place in the La Palma Protected Marine Reserve in the Canary Islands.


Protected Marine Areas (PMA) are areas where it is intended to maintain a high environmental quality in order to protect and even regenerate the flora and fauna in the area. For the development of this pilot, the La Palma’s Protected Marine Reserve (Canary Islands) in the Atlantic Sea has been chosen. The island of La Palma is suffering from a peculiar environmental sea degradation due to the coast plantations (basically banana plantations).

The objective of this pilot is to develop a system based on ICT to automatically control the environment. The system will get data based on indicators from the coast area of the PMA, then




17

process them, analysed them and make them available so the authorities can take the best decisions. Data can be obtained through the use of sensors or, like in the case of the flora and fauna data, with human intervention.

When using sensors and in order to make it simple for our purpose, the coast area of this PMA has been divided into two sub-areas that will be defined as open sea (not more than 600 m from the coast) and border sea. With the same criteria, indicators that we will take into account will be: biological parameters or physical-chemical parameters and only the three among the most relevant ones will be taken for each one of the sub-areas.

This division allows us to apply to each of the sub-areas the correct indicators since for example there is no need to measure pesticides on the open sea. Here there are the indicators that will be measured for each of the sub-areas.

When human intervention is necessary, the use of images and voice recognition systems will be studied. All these data will be georeferenced in cartographic maps.


If we want the public administration to accomplish environmental rules and regulations concerning water, they must know the quality of it and investigate which activities are the main factors in water degradation. With the data obtained from this pilot, environmental information related to the quality of the water in the coast should be accessible to the authorities in order to help them to take correct decisions concerning the environment.

Some of these rules and regulations are the 2008/56/CE DIRECTIVE of JUNE 17th, 2008 where the environmental management policy for marine areas is mandatory for the member states.


The main stakeholder involved in the development of this pilot is TRAGSATEC. Some other collaborators are companies manufacturing sensors and developing voice.

Users involved:

In the development of the pilot the users are the La Palma Protected Marine Reserve but in future exploitation any Public Administration could be involved.

Policy / business model:

Coherent with TRAGSA role towards the Spanish Government.


• Wild Salmon Monitoring (IE)

• Economical activity at marine coastal benthic habitats (LV)

• FAO

• HSRS

• IMCS

Use cases

Use case Indicators calculation and reporting

Scenario La Palma Protected Marine Area (ES)

Actors • La Palma Public Administration




18

• Tragsa

Task To analyse sensor measurements, and to calculate indicators on everyday basis to measure the quality of the sea. To publish this information.

Assumptions Sensor data will be made available using standardised interfaces and will be accessible by analytical tools

Description The data captured from sensors will be analysed on a regular basis and reports about quality of the sea will be prepared. The results of this analysis will be stored in form of tables, graphs, etc.

Comments The analysis and indicators will be used by other use cases

Use case Visualisation of results

Scenario La Palma Protected Marine Area (ES)

Actors • La Palma Public Administration

• Tragsa

• Citizens, Scientists

Task Visualise reference data, sensors measurement and calculated indicators

Assumptions Visualisation will help to make different types of data available in a user friendly form to support visualisation both on computers but also on mobile devices

Description The system will support selection of data, maps and indicators and support visualisation in right form

Comments On the basis of user access rights different possibilities of visualisation will be available for users

3.4. NATURAL RESERVE

Partner: TRAGSATEC

Location: This pilot is going to be developed for a small area in Madrid (Spain), El Campo del Moro, but the strength of the pilot is that if a standardization of the data and metadata modelling for this kind of environmental tourism is defined, some other standards will appear for the specific hardware that is needed for its representation, and the idea of environmental tourism could equally be developed in the whole Europe.


The objective within a Nature Restricted Areas (NRA), as the European Nature 2000 Network defines it, is the survival of species in danger of extinction, contributing at the same time to soften the impact of human activities. They are the instrument to nature conservation in the European Union.

For the development of this pilot obviously it is not possible to choose a NRA, but for the purposes of this pilot an interesting place has been chosen in Madrid.

The objective of this pilot is to develop a system that, using real nature information and adding metadata to real images (texts, images, sounds, etc.), allows improving environmental tourism with a




19

real nature observation. Introducing interpretation information and augmented reality we will particularly protect fragile areas.

The base information will be:

• Cartographic information for long distance scenes (landscape)

• Topographic information for short distance scenes (some trees, flowers, rocks…)

On top of this cartographic/topographic information there are a lot of metadata that could be georeferenced, as for example:

• Nature data: species, flora and fauna, names,

• Historic data: reconstruction of ruins, dates and facts

• Landscape: name of villages, mountains, etc.


Environmental information can be used in a wide range of areas apart from environmental education or nature interpretation, it can also be used for historical or cultural heritage, evaluation of new edification impact, etc.


The main company involved in the development of this pilot is TRAGSATEC. Some other collaborators are hardware manufacturing companies. The National Heritage of Spain is the main stakeholder for this pilot.

Users involved:

In the development of the pilot the users are the Public Administration and tourists.


Coherent with TRAGSA role towards the Spanish Government.


• Hiking Trip Planner (IT)

• Sheep and Goat Herd Management (IT)

• Czech National Forest Programme (CZ)

• FAO

• HSRS

• IMCS

Use cases

Use case Using augmented reality for educational, research and awareness purposes

Scenario Natural Reserve (ES)

Actors • Public Administration

• Tragsatec




20

• Citizens, Scientists, Students

Task Using augmented reality tools in terrain to combine reality with mapped objects or with artificial objects.

Assumptions

To be able to select data on the basis of user position and user preferences from existing catalogues. To design methods of visualisation of three dimensional objects on the basis of available data

Description Users will use tools supporting user reality visualisation for educational or research purposes. On the basis of his position and user preferences (topic of interest) available data will be selected for visualisation. It will be necessary to not only design data models, but also methods of visualisation for concrete types of data. When a person move around in the terrain, augmented reality will be displayed to him

Comments The task will require additional types of information, like DSM information. It will be necessary to take not only the position, but also the azimuth of the view of a subject into consideration.

Use case Using augmented reality for inventory and manage purposes

Scenario Natural Reserve (ES)

Actors • Public Administration

• Tragsatec

• Citizens, Scientists, Students

Task Using augmented reality tools in terrain to add and edit real objects with photo included.

Assumptions

To be able to select data on the basis of user position and user preferences from existing catalogues. To design methods of visualisation of three dimensional objects on the basis of available data. To add points and take photos for each of these.

Description Users will use tools supporting user reality visualisation for editing geodata. On the basis of his position and user preferences (topic of interest) available data will be selected for visualisation and edition. It will be necessary allow add a photo to each new point.

Comments The task will require additional types of information, like DSM information. It will be necessary to take not only the position, but also the azimuth of the view of a subject into consideration.

3.5. HIKING TRIP PLANNER

Partner: Madonie

Location: Madonie Park, Sicily (IT); widely replicable throughout the Mediterranean




21


The Madonie Park in Sicily attracts thousands of visitors every year, including hikers who explore the mostly mountainous 35,000 hectares; there are 6 mountains over 1,500m and several others well over 1,000m. The highest, Pizzo Carbonara is 1,979m, second in Sicily only to the mighty Etna (3,323m).

Hikers are attracted, in addition to the landscape, particularly by the park’s flora and wildlife. Indeed, there are over 2,600 different species of plants, many of which are endemic to the area.

The Park Authority is currently developing a multimedia repertory of many of the park’s main features – including both natural elements and places of traditional farming and herding – and, in the context of on-going initiatives, is developing an interactive multimedia map of the area that will allow hikers to plan visits as a function of the natural elements to see.

The validation pilot in HABITATS will integrate habitats-related data into this map, to allow to view bio-geographical regions within the park. In addition, use of mobile platforms (where coverage is available) will also be tested.

Finally, the currently planned facility allowing for users to upload multimedia content and insert comments and suggestions, will be enhanced to validate the possibility for users to insert content through the SDI. The possibility to signal sightings of different species (i.e. through digital photos with time date and location stamp) will also be integrated.


This pilot will make significant use of the information in the regional Carta Natura database, and will also access databases from other regions in order, for example, to compare habitats in different geographical contexts.

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

The pilot will also explore the organisational issues in validating user-provided data.


This pilot is carried out within the Territorial Living Lab-Sicily partnership, which already includes a range of regional stakeholders including the Sicilian regional government, the CRES research centre, the University of Palermo, the ARCA innovation incubator, the Confindustria business association, etc. In addition, the pilot will also be carried out in collaboration with the national research centre CNR’s ICAR (Istituto di Calcolo e Reti ad Alte Prestazioni).

Users involved:

In the development of the pilot the users are the Public Administration and tourists.


The pilot is coherent with the Park’s mission but is also an element of the TLL-Sicily partnership’s innovation piloting strategy.


• Natural Reserve (ES)


• ISPRA

• FAO

• HSRS




22

• IMCS

Pilot use cases

Use case Park Management

Scenario Hiking Trip Planner (IT)

Actors Park employers

Task • Planning support

• Operative terrain management

Assumptions New, and mainly mobile, access can bring better and more operational management into the park

Description The system will offer access to relevant information to park management in office and terrain. The system will support planning and also realisation of activities in the park.

Comments

3.6. SHEEP AND GOAT HERDING MANAGEMENT

Partner: Madonie

Location: Madonie Park, Sicily (IT); widely replicable throughout Europe


In the Madonie Park, over 1,500m is dominated by the Madonie Forest while lower down the slopes, the locals continue to pursue millennial agricultural activities including sheep and cattle farming and the cultivation of wheat, olives and fruit. This gives rise to specific traditions such as the seasonal “transumanza” when herds are moved from their summer to winter pastures and back, and contributes to the Madonie’s gastronomic specialties of meat, sausages, salami, cheese, olives, mushrooms, and fresh seasonal vegetables.

Grazing, as is well known, has a significant environmental impact and therefore needs to be carefully managed in order to guarantee the long-term sustainability of the grazing habitat. For this reason, the Park Authority adopted a grazing plan and releases licences; according to the grazing plan the Park Authority rotates the assignment and utilization of grazing areas in order to not damage areas of environmental interest with an excessive pressure due to the presence of herding activities. All this should be carried out also by adding new layers on the current condition of pastures and other environmental parameters regarding the same areas. Besides the Park Authority is responsible for other actions of monitoring, maintaining the necessary fencing and other infrastructures, etc.

This management activity uses the Park’s GIS system, but the decision-making processes, in the past has been generally based on experience and implicit knowledge. The validation pilot will provide updated environmental data to support better informed decisions, but it it will also be a starting point to regulate the production of data according to Inspire recommendations.

The system is important as it is replicable in other Italian mountain parks which have the sane problem.





23

This pilot will make significant use of the grazing plan imported in the WEBGIS as well as of some other geospatial layers as the ‘areas assignment plan’ and ‘animals position’ (the position is uploaded on Park Authority databases by tracking collars mounted on the neck of animal).

Management activity is also based on information contained in the ISPRA Carta Natura-like database realized by Madonie Park Authority at a more detailed scale and also on recommendations coming from ISPRA partner itself that could be both partner and user (this last role for using webgis data and services in order to write recommendations on the use of Madonie grazing areas). Joint management scenarios are possible through the interconnection with similar habitats management systems in other countries of Mediterranean area.


The pilot activity is useful not only for Park Authority, which is interested to manage grazing areas in a sustainable way, but also for different classes of stakeholders as:

- Sheep and goat farmers; they are interested to obtain licence to use some areas inside the park for grazing of their animals;

- Owners of private areas usable for grazing

- Dairy farming

Users involved:

The information made available in the development of project pilot e pilot activity could be used daily by Madonie Park Authority personnel which has to manage the area using GIS.

Information could be also useful to sheep and goat farmers that want to know the situation regarding areas assignment. But the information available as web services will be useful to researchers and in general to people that could develop an activity based on Dairy farming (allevamento).

Besides, and this is one of the most important aspects, the base data constitute the map on which the position of animals will be shown thank to geospatial web service deployed by the WEBGIS server.

Other categories indirectly interested are:

- Schools

- Hikers

Policy / Business Model

The data collection, once available through web service is in-line with Sicily Region policy for building of an SDI, to be realized with contribution of different public body or institutions.


The data are shared with all people interested to know about the use of grazing areas and related information inside the park.

From other pilots here will be cooperation with


• Economical activity at marine coastal benthic habitats (LV)


• ISPRA

• FAO

• HSRS




24

• IMCS

Pilot use cases

There are many different use cases, two of which are here reported.

Use case 1 Sheep and Goat Herding Management

Actors Personnel at Madonie Park Authority

Task This is mostly an internal but fundamental task at Madonie Park Authority the requires the availability of geospatial data inside the whole Office and for external consultants (mainly researchers) that must help internal staff in managing the areas of the park.

All this people access data by their GIS software or the WEBGIS platform, through geospatial web services INSPIRE compliant.

Assumptions The proprietary databases can be made INSPIRE-compliant using the HABITATS Metadata profile in order to be accessed through the Sicily Region Portal using GIS or WEBGIS software compliant to OGC web services.

Description

People at Madonie Park Authority deal with the management of grazing areas in a sustainable way allowing shepherds to access to areas, assigned to each of them, for grazing of sheep and goats.

The control of the impact of grazing on assigned areas is carried out by Park Authority Personnel and external experts. This requires also the production of new layers on the state of areas the must be in a format compliant to ISPIRE directive in order to be used in an appropriate way.

Comments

Data used for this task are: 1. Grazing plan; 2. Animals position distributed over the whole period of grazing; 3. State of conservation of areas (this includes some information such as level

of pressure caused by animals).

Use case 2 Tracking position of animals on a grazing area inside the park

Actors Sheep and goat farmers

Task To know, when necessary, the position of animals inside the grazing areas in order to retrieve them.

Assumptions There is a server that, on demand by Sheep and goat farmers or shepherds, answers with the position of animals shown on a map of the area surrounding them, whose position is uploaded to the server, periodically, by gps-gprs tracking collars mounted on the neck of some animals.

Description The system is composed by different segments or parts.

The first one is a tracking collar that is mounted on the neck of each animal (shep or goat) whose position must be tracked; the collar contains a gps receiver and a gprs




25

transmitter through which the position of the animal is sent at predefined time interval to a server in which position of animals is saved.

The second one is the server on which the position of animals is saved: The server makes available web services which allow to show on a map the position of animals when this is requested by shepherds by their mobile smart-phone.

The third one is the mobile phone by which is possible to call the phone number which corresponds to a specific collar or animal; this mobile phone should be equipped with an internet browser by which the position of animals is shown on a map downloadable from the server at Madonie Park Authority.

.

Comments

.

3.7. ECONOMICAL ACTIVITY AT MARINE COASTAL BENTHIC HABITATS

Partner: IMCS

Location: Marine coastal areas of Latvia; replicable in other sites of the Baltic Sea


IMCS will cooperate with the Latvian Institute of Aquatic Ecology using the monitoring data of coastal benthic communities and related environmental parameters. The needs and requirements of various stakeholders will be researched and afterwards IMCS will pilot the use of advanced interfaces to improve presentation, accessibility and use of the data. It will help in decision making for port construction measures, fisheries policy, wind mill development actions in order to use the benthic habitats in a sustainable way. The benthic habitats in Latvian coastal waters are the areas with the highest biological diversity and partly covered by NATURA 2000 territories.


The data on composition, abundance and dynamics of the benthic communities together with the related environmental parameters (physico-chemical measurements) collected by the Institute of Aquatic Ecology, will be made accessible to provide scientifically based information to various stakeholders carrying out different types of economical activity at the coastal areas of Latvian marine waters.


Latvian Institute of Aquatic Ecology (LIAE) collects and owns the data, but reports it to the national environmental authorities and international data base of ICES. The data are used also in HELCOM environmental assessments. LIAE collaborates with several marine research institutes around the Baltic Sea. The service to be piloted will provide that data as high quality information to different groups involved in economical activities at the coastal areas.

Users involved:

The Pilot Service will enable citizens (fishermen) and institutions (ports, environmental boards) to be involved, for future exploitation.





26

The data collection is part of the Latvian National environmental policy, according to EU Water Framework Directive and Habitats Directive. It is vaguely represented online and therefore the HABITATS pilot will explore making it available as an online service.


• Wild Salmon Monitoring (IE)

• La Palma Protected Marine Area (ES)


• FAO

• HSRS

• IMCS

Use cases

Use case Marine coastal habitat data for construction activities and maritime spatial

planning

Scenario Economical Activities (LV)

Actors • Latvia Institute of Aquatic Ecology

• IMCS

• Citizens, Scientists, Students, Businessman’s

Task Using WEB tools provide in well understandable way information about allowed activities in selected sea areas. Give information about limitations and information about involved/responsible organizations where to contact for more detailed information.

Assumptions User to be able select interested area, choose interested activity and receive information about possibilities, rejection or acceptance of activity. To design solution for allowed restricted area identification and representation.

Description Users will use tool to identify interested area for business or research purposes. On the basis of selected/drawn area (polygon of interest) using all available data will be calculated and returned information about limitations in selected area and list of recommended organizations to visit for more detailed clarifications.

Comments The task will require additional types of information, like methodology of different factor combination results from GORWND project, and also additional data, like wind maps for best wind turbine locations.




27

Use case Data access, management and maintenance

Scenario Economical Activities (LV)

Actors • Latvia Institute of Aquatic Ecology

• IMCS

• Scientists, students

Task Using tools users are able to find and access collected data and data sets, view and download data, users with rights are able to edit and add new data to defined layers.

Assumptions To be able search and find data on the basis of selected area or selected theme from existing catalogue. To be possible to view or download found data. To be possible to add new spatial objects and to existing objects load new measurement and analysis records, add documents and pictures.

Description All user will be able to search in existing catalogue and after that view and download data. Users with rights will be able to edit existing data and add new records. User will be able to load new survey and measurement and analysis result tables and link to existing spatial objects (e.g. monitoring stations), possibility to add any type remarks and documents to selected record/object in database.

Comments

3.8. NATIONAL FOREST PROGRAMME

Partner: FMI

Location: Czech Republic


The purpose of this use case to deliver and share the harmonised forest site data to be used as basis for the definition of the suitable forest management practices. The geographic data of the forest site classification describe the permanent ecological conditions, ie. division of forests into segments with similar growth conditions. The outputs of forest site classification serves as a basis for determining the economic measures, and operational and production goals (Forest management plans, forest management scheme). The importance of the outputs of forest typology was further strengthened in the new political-economic-environmental conditions, which has also become the basis for the evaluation functions of forest ecosystems, forest valuation, or the creation of management plans for specially protected areas.

Tool for the classification of environmental conditions is the Forest site classification system that describes the ecosystems with the potential vegetation. The major differentiation within the ecological conditions are:

1. Vegetation tiers (altitudinal vegetation zones) - taking into account the gradient of vertical zoning of vegetation (LVS)

2. Edaphic categories - reflecting a gradient of trophic conditions and hydricity

3. Forest type complex - combination of vegetation tier and the edaphic category is means unit (SLT)




28

Vegetation tier represents biocenological (geobiocenological) building unit, which reflects the influence of climate on the composition of biota of chtonophytic synusia (geobiocenoses) and which is determined by this composition. Vegetation tiers are differentiated by species that are in the first place trees, or. shrub determinants of main canopy level of indigenous forest and shrubs communities and all chtonophytes, that react decisively to the length of the growing season and the negative effects of climate. This means that vegetation tiers are determinated according to presence and expressions of living trees. There are 10 vegetation zones

1. Oak

2. Beech-oak

3. Oak-beech

4. Beech

5. Fir-beech

6. Spruce-beech

7. Beech-spruce

8. Spruce

9. dwarf pine

10. alpine

Forest type complex is a basic unit, which involves similar elementary units (Forest type) according to ecological affinity, according to their phytosociological similarity undergrowth and site conditions. Forest type complex is given by the combination of Vegetation tier and edaphic category. Forest type complex represent a natural forest ecosystems and all managed forests with same ecological conditions. Forest type complex are mapping units in the reconstruction maps.

Timber transport technologies have the direct connection (link) with natural conditions of the site. According to the forest road network can be constructed the basic infrastructure for access to forest site and is important for forest management. Based on transport accessing forestry harvesting technologies, silvicultural treatment and forest road network are constructed. Background of Joint rescue service aimed at navigation improvement for rescue service access in the forest complex (e.g. fire) is another significant area of model analysis in terms of Habitats project.

The information from the FMI forest road network database serve the integrated rescue system to localize and reach the event of forest fire in short time. The further information derived from the forest site maps (SLT) and digital terrain model (DTM) enhances the driver’s orientation and time estimations. As there are similar activities in other the neighbouring countries (Slovakia, Austria), this pilot scenario can be used for the cross-border cooperation within the Habitats project.

The biomass estimation from NFI data - The purpose of the use case is to test the Habitats technology (data models, metadata profiles, geoportal technology,…) for the presentation of the stand volume estimates from the National Forest Inventory (NFI). This is the key estimate in several issues of the Czech National Forest Programme such as permanent forest monitoring, and the biomass estimation for energetic purposes. Stand volume estimates can be also used in forest valuation processes, carbon stock reporting on both national and European level.


The development of the forest scenario is focused on harmonisation of metadata, coordinate system, geometry, data models and sensor standardisation. For harmonisation tasks the following software




29

tools and modules will be used: MIcKA, UMN MapServer, Intergraph platform, Geoserver, MapMan etc. Several meeting and discussions with different stakeholders were organised to describe the Habitats Forest management pilot. The main purpose was to receive the feedback for the particular user scenarios and to find out about their requirements. The questioners were structured according to the stakeholder categories.

The stand volume estimates from the National Forest Inventory (NFI) estimated for the district (regional) level, serve to identify the suitable candidate areas for wood and biomass energy industry (e.g. sites for building biomass power plants). Stand volume estimates can be also used in forest valuation processes, carbon stock reporting, etc.

NFP KA4 expert group, large variety of stakeholders is keen for using well-structured data of biomass potentials from forests. The data of NFI will provide basic information on forests needed not only at the national level. The problem is also assessed from the EU level.

The Standing Forestry Committee ad hoc Working Group on mobilisation and efficient use of wood and wood residues for energy generation emphasized that:

1. Better understanding of the resource is only possible with sound basic data, which are often lacking in the context of predicting wood potential for mobilisation. There is a crucial need to analyse in greater detail the potential of wood supply on MS and regional level

taking into account local conditions such as costs, ownerships patterns, quality requirements, infrastructure and environmental considerations. MS and regions should also conduct surveys on household consumption of wood for energy to gain a clear picture on energy usage. The Commission can facilitate the efforts through information exchange. Short to mid-term action required.

2. Monitoring and evaluation data are continuously needed in order to follow the developments in wood potential, supply and demand and to evaluate mobilisation efforts. The current levels of activity need to continue and be developed further. The Commission, MS and relevant international bodies need to periodically (3 – 5 years) update wood supply and wood use information, including wood for energy, processed wood fuels, post consumer recycled wood and wood waste streams. MS should also undertake wood fuel market reviews based on standardised nomenclature for trade statistics and conversion factors (e.g. MWh/GJ into cbm solid wood) to increase market transparency. The Commission and the MS should continue to cooperate on renewable energy statistics. Short-term and continuous action required.


The forest owners can be divided in 3 main categories:

• Small forest owner - area up to 50 ha • Medium forest owner - area 50-500 ha • Large forest owner - area more then 500 ha

The small forest owners need the information about the forest management scheme (LHO), where they find the basic information and claims for the management practices. Further, the information about the subsidies and subsidy programmes in forestry.

Data updates are performed online via a secure channel. All databases have mirror backup on the different location due to safety. FMI began discussions with representatives of the firefighters, because of need to integrate data of forest road network for the system used. These steps require the design of an interoperable data model, so that every data transfer can be carried out periodically. Both




30

organisations using own metadata system and therefore descriptive informations about silvicultural data should be handled and shared only by FMI, to avoid duplication.

Firefighters

The discussion showed that firefighters see great potential in information, which FMI currently lacks. Some of them can be obtained from the analysis and synthesis of existing datasets. However, some require a new survey in the field. Examples are listed below:

• information about available water resources (artificial and nature) • obstacles on the road (gateway documentation) • road width • road quality • road curvature and corner radius (according to demands of the firefighters - special vehicles) • etc.

Data are requested to be in a standard ESRI Shapefile exchange format and S-JTSK coordinate system. These source data are imported using internal tools into the data warehouse. The Agreement for the provision of data have to be concluded between data provider and user. Data are shared with units of fire protection, rescue services, police of the Czech Republic and civil protection.

The both universities are providing MSc. /PhD. education in the field of forestry, landscape management, ecology, or nature protection. The forestry data requirements are similar on both institutions. The utilisation of open formats, open-source technologies and the independent platform is generally preferred in the data access fro this user groups. All data and metadata should be accessible via one website – the geoportal (http://geoportal.gov.cz/).This is the key concept of the national geoportal, which is supported by the national legislation (the transposition of the INSPIRE directive into Czech law). The national geoportal will by included into the system of the European platform.

The state administration, regional and local administration bodies, municipalities

• Ministry of Agriculture, Ministry of Environment • Moravia-Silesian Region (NUTS 2), Liberec region administration (NUTS3) • municipalities

Our ministry requires integration of the data (presented in Use Case 1 as a component of RPFD – Regional Plans of Forest Development) into the eAGRI. The eAGRI (http://eagri.cz/public/web/mze/) portal is operated by The Ministry of Agriculture. The Forest type complex and the Vegetation tier data are framework for differentiation of management principles and depend on nature conditions of

the site.

The administration on different levels requires different kinds of information:

Ministry of Agriculture: SLT LDS LVS TDK 4. total increment +

5. forest accessibility – length and state of roads + 6. potential technology ratio + 7. ecologically acceptable technology ratio +

Ministry of Environment unique biotops +

typical biotops + +

ecologically acceptable technology ratio +




31

Regions 1. grow conditions + +

2. ecologically acceptable yield

3. sources of reproduction/ seeding material +

4. transfers of reproduction/ seeding material +

5. ecologically acceptable technology ratio +

Municipalities: unique biotops +

typical biotops +

natural points of interest + +

forest accessibility – forest road network + wood volume transported on the roads + mean transpiration distances +

(http://geoportal1.uhul.cz/mapy/framesetup.asp)

Fire rescue department ČR (HZS) is the main coordinator and serves as the backbone of the emergency system. Regional and local fire information infrastructure, working with a wide range of data sets; mainly focused on inhabitant register, transport infrastructure and others. Datasets are stored in Oracle database and data models are designed to suit the very sophisticated and proprietary applications. Fire fighters and rescuers are also using data sources, which can be shared and used through map services and web applications/portals. Other spatial and non-spatial datasets are collected from national organizations, which are cornerstones of the national spatial infrastructure, for example: Czech Hydrometeorological Institute, Czech Cadastre Institute, and Czech Environmental Information Agency etc. The main software tools are products of ESRI, and other unspecified proprietary software.

The medium and large forest owners require more detailed information about the forest site classification (division of forests into segments with similar growth conditions) to assess the environmental conditions and to draw appropriate conclusions for forestry management. Specifically, the assessment of the forest site conditions serve as a base to construct so-called the management framework directives. The information about the Vegetation tiers (altitudinal vegetation zones) define and limit the transfers of the genetic material (seeds, seeding, tree plantations,…).

The information about the Vegetation tier and the Forest type complex also serve to determine the type and the amount of subsidies in forest management - It is used to plan the reforestation of the target tree species in respect with their natural conditions.

The information about the Forest road network is very important especially for the large forest owners. This dataset is used to optimise the network, planning the investments, evaluate the specific site accessibility. In combination with the information about slope, exposition, terrain type, and terrain obstacles, the forest road data serve for terrain typology to estimate the potential for the harvester technology




32

Users involved:

All Czech citizens and businesses, participants in cross-border cooperation, etc.


The Czech Republic, in terms of area, is one of the smaller states in Europe, but it can be proud of its highly diverse natural wealth. Forests are undoubtedly one of the most valuable of its assets - their value can be expressed by purely economic indicators, but the true significance of forests far exceeds their economic importance. National Forest Programme (NFP) has been prepared in a harmony with the ongoing policy discussion on forestry issues on European level.


• Hiking Trip Planner (IT)



• FAO

• HSRS

• IMCS

Use case Forest site classification data for sustainable management and utilization of forest road

network

Scenario Forest management, Fire management

Actors FOREST MANAGEMENT INSTITUTE

Stakeholders Forest Owners, Fire Fighters and Rescuers, Universities, Research and development institutes, Decision makers (regional authority)

Community Municipalities, landscape managers, wide public

Task To deliver and share the harmonised data about forest site to be used as basis for the definition of the suitable forest management practices. Timber transport technologies have the direct connection (link) with natural conditions of the site. According to the forest road network can be constructed the basic infrastructure for access to forest site and is important for forest management. The information from the FMI forest road network database serve the integrated rescue system to localize and reach the event of forest fire in short time

Assumptions RPFD (Regional Plans of Forest Development) digital forest maps:

� Vegetation tiers (altitudinal vegetation zones) layer

� Forest type complex layer

� Forest road network layer

Description The geographic data of the forest site classification describe the permanent ecological conditions, i.e. division of forests into segments with similar growth conditions. The outputs of forest site classification serves as a basis for determining the economic measures, and operational and production goals (Forest management plans, forest management scheme). The importance of the outputs of forest typology was further strengthened in the new political-economic-environmental conditions, which has also become the basis for the evaluation functions of forest ecosystems,




33

forest valuation, or the creation of management plans for specially protected areas.


� Vegetation tiers (altitudinal vegetation zones) - taking into account the gradient of vertical zoning of vegetation (LVS)

� Edaphic categories - reflecting a gradient of trophic conditions and hydricity

� Forest type complex - combination of vegetation tier and the edaphic category is means unit (SLT)

Timber transport technologies have the direct connection (link) with natural conditions of the site. According to the forest road network can be constructed the basic infrastructure for access to forest site and is important for forest management. The information from the FMI forest road network database serve the integrated rescue system to localize and reach the event of forest fire in short time. The information in the Forest road network layer are periodically updated by the field survey. There are four road categories distinguished in the database:

� 1L: asphalt (bitumen) surface - truck road, primary logging road

� 2L: gravel surface - truck road, main logging road

� 3L: skidding road, drag road, dragging road

� 4L: extraction track, extraction lane

� 5L: trail, singletrail, doubletrail

Comments There are similar activities also in Slovakia http://lvu.nlcsk.org/LC/, Austria (data from NFI), and Germany http://www.navlog.de/,

http://www.holzlogistik.iff.fraunhofer.de/index.php?id=104261000100. Therefore this scenario represents an example of the cross-border cooperation within Habitats project.

Use case The biomass estimation from NFI (the National Forest Inventory) data

Scenario Forest management, wood and biomass industry

Actors FOREST MANAGEMENT INSTITUTE

Stakeholders Private and state forest owners, Forest and regional administration, Wood and energy industry, Research and development institutes (faculties, scientific institutes, NGOs)

Community landscape managers, forest valuation, national carbon policy, public

Task The purpose of the use case is to test the Habitats technology (data models, metadata profiles, geoportal technology,…) for the presentation of the stand volume estimates from the National Forest Inventory (NFI). This is the key estimate in several issues of the Czech National Forest Programme such as permanent forest monitoring, and the biomass estimation for energetic purposes. Stand volume estimates can be also used in forest valuation processes, carbon stock reporting on both national and European level.

Assumptions NFI output:

� stand volume estimates

Description Biomass is one of the cheapest forms of renewable energy and the energetic utilization of biomass is consequently an important topic lately. Many studies




34

showed that the forest stand volume is highly correlated with the above-ground biomass, and consequently to the organic carbon stock estimates. The biomass was agreed an important sustainable energy resource by the Ministerial Conference on the Protection of Forests in Europe (1990 – 2007). In the Czech context, the biomass production is a key estimate in several issues of the NATIONAL FOREST PROGRAMME. Specifically the NFP KeyAction (KA)4 and KA8 expressed to need of the permanent forest monitoring, and the biomass estimation for energetic purposes. The goal of the output is to estimate total volume of the standing stems (trees), and the volume calculated for the unit per area. Unit: m3, m3/ha

Accuracy: 5%

Comments There is certain call for relevant biomass data from national forest inventories. As we have seem in NFP KA4 expert group, large variety of stakeholders is keen for using well-structured data of biomass potentials from forests. The data of NFI will provide basic information on forests needed not only at the national level. The problem is also assessed from the EU level.

3.8.1. Cross pilot use cases

We recognise, that there exist list of use cases, which are valid cross scenarios. This use cases demonstrate mainly needs for data harmonisation. We recognise common use cases focused on tourism. Education, environment protection and research

Use case Fishing

Scenario Cross scenario

Actors Fishers

Task Interaction of an end-user with the system: - Presentation of the regions allowed for the some kind of fishing

- Presentation of the species distribution

- Warnings and distribution of invasive species or different alerts

Assumptions • Fishers are close to nature and landscape

• The presentation of information has to be done in a logical and easy way to be understandable for the end-user

Description Information support for fishing will solve next tasks:

• Characteristic of possibility of fishing in a region depends on rules and condition of the region

• It does not depend on too physical condition but on permit for fishing and rules of administration of the region

• Parameters (knowledge and experience with fishing, equipment natural condition, accessibility, season, etc.)

• Fishing can be pursued by – (a family with children, pensioners, the disabled, sport fishers, young people, professionals)




35

• Description of the possibility of fishing (to read and print, with maps)

• GPS-coordinates of samples point

• Information about the species (photos, maybe videos, 2D-maps)

• Communication with another modules trough space and time coordinate (nature, history, events, accommodation, food services, healthcare services, shopping, etc.)

• Information about weather conditions

Comments

Use case Food services

Scenario Cross-scenario

Actors • Hikers

• Divers

• Bikers

• Tourist

• Sportsmen

• Families with children

• Seniors

• The disabled

• Fishers

Task Category

Menu

Working hours

Geographical presentation

Assumptions Food service is one from most important tourist services

Description The task will offer possibilities of food services in region. This food services must be described by parameters:

• Categories (restaurant, farms, buffet, fast food)

• Working hours

• Menu

• Additional services




36

Position

Comments

Use case Professionals


Actors • Park management

• Entrepreneurs of recreational sector

• Divers

• Fishers

• Farmers

• Householders

• Researchers

Task • System for Reserve management

• Information support for enterprises and householders and farmers

Assumptions The situation in the Reserve is under influence not only Reserve management, but also enterprises and householders in a region. It is necessary to offer relevant information about possible activities

Description HABITATS system will offer an information support to peoples, whose activities have influence on the park. There exist more players, where exist direct relations between their economic activities and the park.

• Park management

• Entrepreneurs of recreational sector

• Citizens

• Farmers

• Divers

• Fishers

• Householders

• Researchers

Comments




37

Use case Education


Actors • Teachers

• Students

Task • System for preparation of information environmental maps from different regions

• Teachers prepare dynamic map context, which could be stored

• Teacher prepare educational lecture with embedded dynamic maps

• Students used this maps and educational materials

Assumptions There exists global discovery services, which support access to environmental data across Europe

Description HABITATS system will offer an information support for education. There will be developed common discovery services supporting search about metadata from all regions.

The system will support composition of maps and their storage or in the form of map context or as embedded objects, which could be used in educational materials (for example part of e learning courses)

Comments

Use case Research and park protection


Actors • Researchers

• Policymakers

Task • Support for discovery of needed data from European Nature Protection Parks

• Storage of discovered information and making this information publicly available

Assumptions There exists global discovery services, which support access to environmental data across Europe. There exist possibilities for storage of map context and their sharing

Description HABITATS system will offer an information support for education. There will be developed common discovery services supporting search about metadata from all regions.

The system will support composition of maps and their storage or in the form of map context or as embedded objects, which could be used in educational materials (for example part of e learning courses)




38

Comments

3.9. PILOT ACTORS

Pilot actors include stakeholders participating on management of platform, data owners and producers and contributors to services and user groups of all pilots. Here are list of pilots actors:

• Wild Salmon Monitoring

o Irish Marine Institute

o Citizens (fishermen and researchers)

• La Palma Protected Marine Area

o TRAGSATEC

o La Palma Protected Marine Reserve

o Public Administration

o Hiking Trip Planner

o CRES research centre, the University of Palermo,

o ARCA innovation incubator,

o Confindustria business association,

o CNR’s ICAR (Istituto di Calcolo e Reti ad Alte Prestazioni).

o Public Administration and tourists

• Natural Reserve

o TRAGSATEC

o National Heritage

o Public Administration

o Tourists

• Sheep and Goat Herding Management

o CRES research centre,

o University of Palermo,

o ARCA innovation incubator,

o Confindustria business association,

o CNR’s ICAR (Istituto di Calcolo e Reti ad Alte Prestazioni).

o farmers

o herders




39

o citizens

• Economical activity at marine coastal benthic habitats

o Latvia Institute of Aquatic Ecology (LIAE)

o citizens (fishermen)

o public administration

o scientists and researchers

o students

o business

o institutions (ports, environmental boards)

• National Forest Programme

o National public authorities

o citizens

o businesses

• Cross pilots

o Teachers

o Students

o Researchers

o Policymakers

3.10. GENERIC ACTORS AND USERS

Generic actors could be organisations, individuals or groups of individuals with a common interest on the functionality of HABITATS solutions. They will play a role in the deployment and utilisation of the HABITATS infrastructure. Users Description Activities

Non registered End User

Users, who can use HABITATS system without registration for searching and accessing information in infrastructure and using public services

− Uses services without registration;

o Search for data

o Search for information

o Personal content composition

o Visualise information

o Downloaded free information

o Use free services.

Registered User Users, who are registered in o Search for data




40

infrastructure. They can search and visualise content and who can also publish some type of user driven content






o Publish metadata

o Personalised profile

o Publish information

o Share content with others

o Use advanced services

Expert User Users registered on the Portal, who connect to data/services according to their rights, and have some limited possibility to publish their own data and results of their analysis

o Search for data








o Publish metadata


o Manage context among servers

o Define analysis

o Prepare reporting

o Use advanced services

Content Provider Users registered on the HABITATS platform, who publish and make their own data or services accessible; who access data/services according to their rights.

o Search for data









41




o Manage context among servers

o Define analysis

o Prepare reporting

o provides data on the web;

o produces metadata;

o assures quality of data and metadata;

o defines policies and license agreements.

Administrator System administrator with full access to the Portal.

Technically manages the System.

3.11. ACTORS ACTIVITIES.

User groups recognised previously could be sorted into the following groups:

• Technological partners

• Research organisation

• Public servant

• Park administration

• Policy makers

• Professionals groups (fisherman’s, farmers...)

• Teachers

• Citizens

• Students

• Tourists




42

The following table assigns single recognised user groups to generic users. The same role will not be present in all pilots, but they present a generic division

User group/stakeholder End user Registered

users

Expert

user

Content

provider Administrator

Technological partners Research organisation Public servant Park administration Policy makers Professionals groups Teachers

Citizens

Students

Tourists




43

3.12. GENERIC USE CASES

The defined user cases are initial list, which is based on pilot use cases. This generic use cases will be further elaborated in final version of this deliverable. List of use cases: Generic use case Generic tasks Scenario relevance Description Actors involved User administration and security:

User groups definition All scenarios To define user groups and their access rights to single services of system

Administrator

Stakeholder registration All scenarios Every user can register himself in the system. The system generates a password for him.

Registered User, Expert User, Content Provider, Administrator

User approvement All scenarios Administrator has to approve, so users can have access to system

Administrator

Setting user roles All scenarios Administrator can define for eache user, to which groups he belongs

Administrator

Digital Rights Settings (DRM)

All scenarios It is necessary that it can be defined, which groups of users have access to concrete data, metadata and services

Content Provider, Administrator

User priority definition All scenarios Every user can select priorities from a prepared list. This helps to customise the system for them





44

User deregistration All scenarios Every user can decide about deleting his registration in the system. In such cases all information about them has to be deleted from the system. In some cases, the administrator could decide to deregistered a user.


User login All scenarios A user can log or unlog himself to switch required functionality


Search and discovery Search metadata; All scenarios To use simple or extended search in connected catalogues

Non registered users, Registered User, Expert User, Content Provider, Administrator

Browse metadata All scenarios Every user can see metadata detail from searched data


Join a new catalogue All scenarios Every user can temporally selected a new catalogue for search


Search for objects All scenarios Every user can provide search for existing objects


Data and metadata management

Uploaded data All scenarios Data could be uploaded on a server in predefined formats

Registered User, Expert User, Content Provider,




45

Administrator Delete data All scenarios System has to support

delegating data Expert User, Content Provider, Administrator

Change data format All scenarios System has to support changes of data format


Change data model All scenarios System has to support changes of data model


Metadata uploading and editing

All scenarios System has registered, edited and deleted metadata for data


Service registration All scenarios System has registered, edited and deleted metadata for services


Catalogue registration All scenarios System has registered, edited and deleted new catalogues for harvesting and switch parameters for harvesting

Expert User, Content Provider, Administrator

Coordinate transformation All scenarios System has to support changes among different coordinate system


Downloaded data All scenarios Data can be downloaded by users according to their rights


Sensor data collection La Palma Protected Marine Area (ES)

Data are automatically collected from sensors


On line terrain collection All scenarios Data are online stored in a system using mobile

Registered User, Expert User, Content Provider,




46

equipment with positioning systems

Administrator

Off line terrain collection All scenarios Data are stored on mobile system and then uploaded on server


Off line terrain collection with laboratory analysis

Wild Salmon Monitoring (IE) La Palma Protected Marine Area (ES) Economical activity at marine coastal benthic habitats (LV)

Position of measurement is stored on mobile equipment and then uploaded on server. After data analysis in laboratory, results of measurement are connected to position


Web based Data vectorisation

All scenarios The client allows to visualise objects and stored attributes


Visualisation Compose data and service All scenarios User can compose its own data composition from services. The composition description could be stored on local computer


Publish composition of data and services

All scenarios User can compose its own data composition from services. The composition description could be stored on local computer and on server





47

Visualisation of composition

All scenarios The selected composition could be visualised


2D View data All scenarios Client for Web based visualisation


Selection of objects All scenarios Client for Web based visualisation


Thick client for 2D visualisation

All scenarios Desktop solution has to allow visualisation of web based data


3D Visualisation All scenarios Client for Web based visualisation


Thick client for 2D visualisation

All scenarios Desktop solution has to allow 3D visualisation of web based data


Terrain visualisation All scenarios Mobile equipment has to allow online access to web based data and visualise this data





48

Off line Terrain visualisation

All scenarios Mobile client has to allow download of data from server and then visualise this data


Augment reality La Palma Protected Marine Area (ES)

System has to support on line augment reality visualisation


Off line Augment reality La Palma Protected Marine Area (ES)

Mobile client has to allow download of data from server and then support augment reality visualisation


Analysis Web based Tracking analysis

System has to support basic tracking functionality


Off line tracking analysis Wild Salmon Monitoring (IE) Hiking Trip Planner (IT)

Mobile clients has to support navigation functions


Image processing La Palma Protected Marine Area (ES) Wild Salmon Monitoring (IE)

System has to support analysis of satellite images


Sensors data analysis La Palma Protected Marine Area (ES)

System has to support on line and on demand sensors data

Non registered users, Registered User, Expert User,




49

analysis Content Provider, Administrator

Other type of analysis All scenarios There is need for such analyses like buffering, overlapping, attribute analysis etc.


Modelling and scenarios building

All scenarios System has to support a complex analysis like for example analysis of chemical distribution in water


Registry management To manage information in thesaurus

Thesaurus like Gemet has to be supported


Manage gazetteers All scenarios System has to support gazetteers for searching geographical terms


Manage other registries All scenarios Need for support registries like list of organisations, etc.


Monitoring and control service

Monitor registration process All scenarios It is necessary to monitor, who is registered, logged in etc.


Monitor requests for access with DRM

All scenarios For data it is necessary to monitor, who accesses data


Monitor requests services All scenarios For services it is necessary to monitor, who uses concrete services





50

4. INFORMATION VIEWPOINT – WHICH DATA AND HOW WILL BE SHARED

The Information Viewpoint describes the way that the HABITATS Networking Architecture stores, collects, updates, manipulates, manages, and distributes information. The major issues which are analysed and assessed are:

- basic data types used in HABITATS

- tasks related to HABITATS data

- information structure and content with a clear focus on the metadata and data models developed through Work Packages 3;

- how information can flow among the different actors and components in the architecture;

- the ownership of the data and the responsibilities associated with its creation and maintenance;

- references and mappings between different metadata and data sets;

4.1. DATA TYPES USED IN HABITATS ARCHITECTURE AND HOW THE DATA ARE

ACCESSED

Data in HABITATS architecture are divided according to their origin and their usability. Basic types of data can be found in next table.

Data type Description Examples of data How data are used

How are data accessible

Reference data Reference data are data, which are coming from other systems, and which are not changed inside of HABITATS

Topographic maps, Pan European data sets, administrative borders, cadastre, orthophotos,

Data are primarily used for visualisation, in some tasks they could be used also as background data for analysis (could define areas of analysis, buffers, etc.)

Data could be stored locally, or their could be accessible using Web Services (Web Mapping Services for visualisation, Web Feature Services or Web Coverage services for data analysis)

Satellite imagery Data coming from Earth observation, which are used for analysis and visualisation

SPOT IMAGE, Quick Bird, MODIS (Aqua and Terra)

Data are primary used for data analysis, partly for visualisation

Primary data will be accessible trough external catalogues using Web coverage services

In-situ observation

Data measured by sensors and stored in databases

Meteorological data, quality water measurement

Data are used for analysis (including temporal) and partly for visualisation. Usually visualisation is necessary using graphs etc.

Data from sensors are usually stored in database and then are accessible through services like Sensor Observation Services, or Web Processing Services




51

Terrain measurement

Data collected in the field using specific measurement equipment

GPS measurement, geometrical measurement, photography with positioning etc.

Data are validated and then used for updating of existing data, next analysis or visualisation

Data are accessible from equipment in proprietary formats or using Web services

User edited data Specific data layers, where groups of people could on line edit data and attributes

Point of interests, user collected data about objects, user observation

Data are validated and then used for updating of existing data, next analysis or visualisation

Data are stored in database using system middleware, accessible could be using web services

User derived data Results of analysis of previous types of data

Image classification, extrapolation from sensors

Data are used for reporting and visualisation

Data are stored on server (often temporally) and are accessible using Web services

4.2. INFORMATION LIFE-CYCLE

Each of the previous data types has its own life cycle. This cycle also depends on whether the data are stored locally or are externally accessible using Web services. For the design of the HABITATS architecture mainly the data managed locally are important. For external data usually the following operations will apply:

• Data discovery

• Storage metadata about services on server

• Data visualisation

• Data downloaded

4.2.1. Reference data The basic operations are:

• Data upload, which could include

o Data upload

o Data format transformation

o Data model transformation

o Metadata import or description

• Data publishing

o Publishing Web services (WMS, WFS, WCS)

o Publishing metadata for services

• Using data for analysis

o Services related to published data are used as part of processing services

• Visualisation

o Data are visualised using WMS

• Data querying




52

o Attribute queering

o Graphical querying

• Data analysis

o Buffering,

o Overlapping,

o Tracking

• Data updating

o Data upload



o Existing data replacement

o Updating metadata

• Data deleting

o Deleting data

o Deleting related services

o Deleting related metadata for data and services

4.2.2. Satellite imagery

The basic operations are:

• Discovery of existing satellite images using external catalogues

• Ordering of data

• Accessibility data using Web services (WCS)

• Data download

• Data publishing including

o Data storage on server

o Publishing related services (WMS, WCS)

o Publish metadata for data and services

• Visualisation


• Data analysis

• Data deleting

o Deleting data



4.2.3. In-situ observation The basic operations are:

• Data transmission from sensors to server

• Data storage in database

• Publishing data from database as service (SOS, WFS, WMS, SAS) including




53

o Publishing services

o Publishing related metadata

• Visualisation of sensor data

o Visualisation in maps

o Graph visualisation

• Data analysis

o Processing of sensor data

o Queering of sensor data

• Data deleting

o Deleting data



4.2.4. Terrain measurement


• Preparing reference data for terrain measurement

• Terrain measurement

• Data uploading, which could include

o Data upload



o Metadata import or description

• Data publishing



• Visualisation


• Data querying



• Using data for analysis

o Services related to published data are used as part of processing services

• Visualisation


• Data updating

o Data upload



o Existing data replacement

o Updating metadata

• Data deleting




54

o Deleting data



4.2.5. User edited data The basic operations are:

• Definition of data models for online data editing

• Definition DRM for online data editing

• Definition metadata record for data

• Data publishing

o Publishing Web services (WMS, WFS)


• Data collection and storing including

o Object selection

o Web vectorisation

o Attribute editing

o Metadata updating

• Visualisation


• DEata querying



• Data deleting

o Deleting data



4.2.6. User derived data


• Discovery of data (services), which are incoming for operation

• Discovery of related services

• Operation execution

• Data storage including

o Data storage

o Metadata storage

• Data publishing



• Visualisation


• Data querying




55



• Data deleting

o Deleting data



4.3. DATA AND METADATA MODELS

Data and metadata models are defined in detail in WP3 (deliverable D3.1, D3.2.a and D3.3.).

4.3.1. Metadata

For metadata, HABITATS metadata1 profiles are based on ISO standards 19115/19119/19139 and on INSPIRE profile. To define a common structure which describes spatial data, the international standard ISO 19115 was created. After the participation of 33 member countries of ISO/TC211 and 16 more through their experts, it was approved in 2003 as an International Standard Metadata and was also adopted as European Standard by CEN/TC 287 in 2005.

ISO 19119, "Geographic Information - Services," has been developed jointly with the Services Architecture SIG of the OpenGIS Consortium (OGC). As a project in ISO TC211, ISO 19119 has reached the Draft International Specification stage. OGC has adopted ISO19119 as part of OpenGIS Abstract Specification, Topic 12 "System Architecture." The OGCWeb Mapping Testbed activities provided implementation experience in the development of ISO 19119.

ISO 19139 is a technical specification that developed an implementation of metadata profiles described by ISO 19115/19119 in XML. The XML markup language is used to create documents that contain structured information. For the creation of these documents is necessary to define tags and relations between them. XML-Schema is a technology related with XML and one of the ways to define the syntax of its files. For each language derived from XML, we must create a "XML Schema" following the specifications in XML-Schema. It will describe the structure of documents and will validate them.

The INSPIRE metadata profile was adopted on December 3, 2008. It represents the minimum set of metadata elements necessary to comply with Directive 2007/2/EC while allowing the possibility for organisations to document the information resources more extensively with additional elements derived from international standards or working practices in their community of interest.

As noted above, there is a mandatory INSPIRE profile to which the services and datasets must comply, regardless of the theme to which they belong. The mandatory elements are:

Reference Metadata elements Multiplicity Condition

1.1 Resource title 1

1.2 Resource abstract 1

1.3 Resource type 1

1.4 Resource locator 0..* Mandatory if a URL is available to obtain more information on the

1 D-3.2a Metadata profile, CIP- ICT-PSP-2009-3-250455, Social Validation of INSPIRE Annex III Data

Structures in EU Habitats




56

resource, and/or access related services.

1.5 Unique resource identifier 1..*

1.7 Resource language 0..* Mandatory if the resource includes textual information.

2.1 Topic category 1..*

3 Keyword 1..*

4.1 Geographic bounding box 1..*

5 Temporal reference 1..*

6.1 Lineage 1

6.2 Spatial resolution 0..* Mandatory for data sets and data set series if an equivalent scale or a resolution distance can be specified.

7 Conformity 1..*

8.1 Conditions for access and use 1..*

8.2 Limitations on public access 1..*

9 Responsible organisation 1..*

10.1 Metadata point of contact 1..*

10.2 Metadata date 1

10.3 Metadata language 1

There are other profiles that contain common elements with the mandatory profile elements, but also other specific elements not recorded in the mandatory profile to complement our list. After reviewing these profiles, some elements seems to be of interest to add to the list:

Reference Metadata elements Multiplicity Condition

10.4 Metadata standard name 1

10.5 Metadata standard version 1

11 Reference system 1

12 Specific usage 0..*




57

The next points will specify the elements for each INSPIRE theme related to the HABITATS project.

4.4. SEA REGIONS

Regarding the first theme, Sea Regions, after analyzing various options, a great diversity of possible forms, uses and layers has been observed. Therefore we have tried to establish data about the measurement to identify data sets with similar characteristics.

Reference Metadata elements Multiplicity Explanation

13 Sea type 1 Ocean, opened sea, internal sea

14 Physiographic province 1 Indication of the physiographical province in which the sample/core was taken

15 Unit standard 1

16.1 Water depth 1

16.2 Measurement depth 1..* Medition depth at the sampling location

17.1 Measured parameters 1..* Parameters derived from tests on the samples

17.2 Measuring method 1 Method used in taking samples (vessel, buoy, immersion)

4.5. BIO-GEOGRAPHICAL REGIONS

The bio-geographical regions theme seems to be more defined. We could choose to first identify the classification system for the object and then continue with identifying details of the region.


13 Classification system 1

14 Name of class 1

15 Source 1

4.6. HABITATS AND BIOTOPES

In this theme the first task is to identify through metadata what kind of entity is addressed. After determining its nature, the ideal is to make clear which classification system is used. It will be possible to identify the names of the next metadata. Additionally, the typical species data of the object are included to better locate the data related to the same species:




58


13 Type 1 Habitat or biotope


15 Category name 1 Item name

16 Typical species 0..* Scientific name

4.7. SPECIES DISTRIBUTION

This theme would take a choice that seems to Habitats and Biotopes theme. To identify the type of species it is necessary to establish a hierarchy of identification and classification types. This will help greatly to relate our data to other similar data.



14.1 Family 1 Scientific name

14.2 Category name 1 Scientific name

15 Status 1 Threatened, extinct, etc

16 Update 1 Yearly, monthly

4.7.1. Data models

The aim of the T3.1 (Conceptual data models) of HABITATS project is to define conceptual data models for the following spatial data themes declared in the Annex III of INSPIRE Directive (INSPIRE, 2007):

• Sea regions

Physical conditions of seas and saline water bodies divided into regions and sub-regions with common characteristics.

• Bio-geographical regions

Areas of relatively homogeneous ecological conditions with common characteristics.

• Habitats and biotopes

Geographical areas characterised by specific ecological conditions, processes, structure, and (life support) functions that physically support the organisms that live there. Includes terrestrial and aquatic areas distinguished by geographical, abiotic and biotic features, whether entirely natural or semi-natural.

• Species distribution

Geographical distribution of occurrence of animal and plant species aggregated by grid, region, administrative unit or other analytical unit.

SeaRegions unique class identifier in the data model. Inside this class we have included three basic feature types:




59

• SeaRegionArea

• SeaSubRegionArea

• SamplingPoints

The HABITATS data model for bio-geographical regions is a simplified version of the INSPIRE specification and consists only of the class EcoRegion. At the time of writing, no bio-geographical regions are defined or referenced by any of the HABITATS pilots – therefore, the simplified version is sufficient for the time being. Should the need arise it could be extended with further attributes and / or import or reference external classes.

Habitats and biotopes conceptual data model imports and implements six packages:

• INSPIRE Basic Types – the main INSPIRE Conceptual Data Model Package used in all data specifications.

• MD_Metadata – classes imported from metadata standard describing the relation of elements of habitats and biotopes data model to original (source) data.

• ISO 00639 Language Codes – declaration of languages used in string types.

• Natural Risk Zones – INSPIRE application scheme provided the attribute determinationMethod and its values.

• Geographical Names – INSPIRE application scheme specified the attribute habitatsName.

• EUNIS Habitat Classification System – taxonomy of habitats embed in current version of documentation of habitats and biotopes data specification.

• PESI (Pan-European Species directories Infrastructure)

Species distribution conceptual data model imports and implements following packages:



• ISO 00639 Language Codes – declaration of languages used in string types.

• Geographical Names – INSPIRE application scheme specified the attribute habitatsName.

• EUNIS Classification System – taxonomy of species embed in current version of documentation of Species distribution data specification.

4.7.2. Feature catalogues for sea regions

The Sea Regions theme can have multiple features as many as parameter measured. This is because measurements are mostly done on samples or points. Only measurements from airborne sensors, orbital, or sonars show us a grid. In the other cases we get points and from them could assign measurements and means to default polygons. We may also perform an interpolation of the points for a parameter thus obtaining a feature polygon. So we said we can have as many features as parameters. Currently our distinguished as follows:

• Polygon:

◦ Sea Region

◦ Sub-Areas

◦ Species distribution

◦ Habitats and Biotopes

◦ Other parameters:




60

▪ Ph-value

▪ Temperature

▪ Salinity

▪ ...

• Point

◦ Sampling points:

▪ Dives

▪ Land samplings

▪ Buoys

• Line:

◦ Batthymetry

◦ Coastline

• Grid:

◦ Bathymetry

◦ Temperatures

◦ Biological activity

4.8. DATA HARMONISATION

In its networking architecture, INSPIRE assumes, that the data will be published in one common format across Europe, in several pre-defined common coordinate systems. Since usually, this is not the case for most of EU-located organizations, it is needed, that either all data are converted to target format and CRS or, download and view services will provide in their metadata description also link to particular transformation service, which will be available free of any charge.

INSPIRE definition of data harmonization says:

Harmonisation is the “process of developing a common set of data product specifications in a way that allows the provision of access to spatial data through spatial data services in a representation that allows for combining it with other harmonised data in a coherent way.

4.8.1. COORDINATE TRANSFORMATION

INSPIRE defines several coordinate systems, in which the data should be available. Usually, the data are stored in national coordinate reference system, so transformation has to be performed.

The data do not change their existing structure or attributes, only coordinate system and data geometry is changed.

4.8.2. FORMAT TRANSFORMATION

Since now data in EU are complain to any format defined in any of INSPIRE Annexes, format transformation has to be performed. In this case, structure of input data is usually changed completely, as well as their format. INSPIRE defines, that the output format should be GML 3.2. However, nowadays common software packages do have difficulties with this task.

4.8.3. SCHEMA TRANSFORMATION

Special case of format transformation is Schema transformation. It deals with input data in basically same or very similar format of input and output data (XML), with different schema of both files. Transformation is in this case to be done with help of XML templating system (XSLT).




61

4.9. USED DATA SETS

4.9.1. Reference laboratory data sets

Reference laboratory will integrate Pan European and Worldwide public data sets, which will be publicly available. The next Data Sets are supported by Reference Laboratory accessible as service (WMS, WFS, KML)

4.9.1.1. OpenStreetMap

The maps are created using data from portable GPS devices, aerial photography, other free sources or simply from local knowledge. Both rendered images and the vector graphics are available for download under a Creative Commons Attribution-ShareAlike 2.0 licence.

OpenStreetMap does not have any content restrictions on tags that can be assigned to OSM-Elements (Nodes Node, Ways Way or Relations Relation). Users can use any tags you like as long as the values are verifiable.

The basic objects are:

1 Physical

1.1 Highway

1.2 Barrier

1.3 Cycleway

1.4 Tracktype

1.5 Waterway

1.6 Railway

1.7 Aeroway

1.8 Aerialway

1.9 Public Transport

1.10 Power

1.11 Man Made

1.12 Leisure

1.13 Amenity

1.13.1 Sustenance

1.13.2 Education

1.13.3 Transportation

1.13.4 Financial

1.13.5 Healthcare

1.13.6 Entertainment, Arts & Culture

1.13.7 Others

1.14 Office

1.15 Shop

1.16 Craft

1.17 Emergency

1.18 Tourism

1.19 Historic

1.20 Landuse




62

1.21 Military

1.22 Natural

1.23 Geological

2 Non Physical

2.1 Route

2.2 Boundary

2.3 Sport

2.4 Abutters

2.5 Accessories

2.6 Properties

2.7 Restrictions

3 Naming

3.1 Name

3.2 References

3.3 Places

3.4 Addresses2

4.9.1.2. Natura 2000

Natura 2000 is the key instrument to protect biodiversity in the European Union. It is an ecological network of protected areas, set up to ensure the survival of Europe's most valuable species and habitats. Natura 2000 is based on the 1979 Birds Directive and the 1992 Habitats Directive. The green infrastructure it provides safeguards numerous ecosystem services and ensures that Europe's natural systems remain healthy and resilient.

The scheme of Natura 2000 is on next image

2 http://wiki.openstreetmap.org/wiki/Map_Features




63

3

4.9.1.3. Urban Atlas

The Urban Atlas is providing pan-European comparable land use and land cover data for Large Urban Zones with more than 100.000 inhabitants as defined by the Urban Audit. The GIS data can be downloaded together with a map for each urban area covered and a report with the metadata.

The type of objects are given by next list

1 Artificial surfaces

1.1 Urban fabric

1.1.1 Continuous Urban fabric (

1.1.2.1 Discontinuous Dense Urban Fabric

1.1.2.2 Discontinuous Medium Density Urban Fabric

1.1.2.3 Discontinuous Low Density Urban Fabric

1.1.2.4 Discontinuous Very Low Density Urban Fabric

1.1.3 Isolated Structures

1.2 Industrial, commercial, public, military, private and transport units

1.2.1 Industrial, commercial, public, military and private units

1.2.2 Road and rail network and associated land

3 http://www.eea.europa.eu/data-and-maps/data/natura-2000




64

1.2.2.1Fast transit roads and associated land

1.2.2.2 Other roads and associated land

1.2.2.3 Railways and associated land

1.2.3 Port areas

1.2.4 Airports

1.3 Mine, dump and construction sites

1.3.1 Mineral extraction and dump sites

1.3.3 Construction sites

1.3.4 Land without current use

1.4 Artificial non-agricultural vegetated areas

1.4.1 Green urban areas

1.4.2 Sports and leisure facilities

2 Agricultural Areas, semi-natural areas and wetlands

3 Forests

5 Water

4.9.1.4. Corine Land Cover (CLC2006, CLC2000)

The CORINE CLC contain next classes:

GRID

CODE

CLC

CODE LABEL1 LABEL2 LABEL3

COLOR in

RGB

1 111 Artificial surfaces Urban fabric Continuous urban fabric 230-000-077

2 112 Artificial surfaces Urban fabric

Discontinuous urban fabric 255-000-000

3 121 Artificial surfaces

Industrial, commercial and transport units

Industrial or commercial units 204-077-242


Industrial, commercial and transport units

Road and rail networks and associated land 204-000-000


Industrial, commercial and transport units Port areas 230-204-204


Industrial, commercial and transport units Airports 230-204-230


Mine, dump and construction sites Mineral extraction sites 166-000-204


Mine, dump and construction sites Dump sites 166-077-000


Mine, dump and construction sites Construction sites 255-077-255


Artificial, non-agricultural Green urban areas 255-166-255




65

vegetated areas


Artificial, non-agricultural vegetated areas Sport and leisure facilities 255-230-255

12 211 Agricultural areas Arable land Non-irrigated arable land 255-255-168

13 212 Agricultural areas Arable land Permanently irrigated land 255-255-000

14 213 Agricultural areas Arable land Rice fields 230-230-000

15 221 Agricultural areas Permanent crops Vineyards 230-128-000

16 222 Agricultural areas Permanent crops

Fruit trees and berry plantations 242-166-077

17 223 Agricultural areas Permanent crops Olive groves 230-166-000

18 231 Agricultural areas Pastures Pastures 230-230-077

19 241 Agricultural areas

Heterogeneous agricultural areas

Annual crops associated with permanent crops 255-230-166



Complex cultivation patterns 255-230-077



Land principally occupied by agriculture, with significant areas of natural vegetation 230-204-077


Heterogeneous agricultural areas Agro-forestry areas 242-204-166

23 311

Forest and semi natural areas Forests Broad-leaved forest 128-255-000

24 312

Forest and semi natural areas Forests Coniferous forest 000-166-000

25 313

Forest and semi natural areas Forests Mixed forest 077-255-000

26 321

Forest and semi natural areas

Scrub and/or herbaceous vegetation associations Natural grasslands 204-242-077

27 322


Scrub and/or herbaceous vegetation associations Moors and heathland 166-255-128

28 323


Scrub and/or herbaceous vegetation Sclerophyllous vegetation 166-230-077




66

associations

29 324


Scrub and/or herbaceous vegetation associations

Transitional woodland-shrub 166-242-000

30 331


Open spaces with little or no vegetation Beaches, dunes, sands 230-230-230

31 332


Open spaces with little or no vegetation Bare rocks 204-204-204

32 333


Open spaces with little or no vegetation Sparsely vegetated areas 204-255-204

33 334


Open spaces with little or no vegetation Burnt areas 000-000-000

34 335


Open spaces with little or no vegetation

Glaciers and perpetual snow 166-230-204

35 411 Wetlands Inland wetlands Inland marshes 166-166-255

36 412 Wetlands Inland wetlands Peat bogs 077-077-255

37 421 Wetlands Maritime wetlands Salt marshes 204-204-255

38 422 Wetlands Maritime wetlands Salines 230-230-255

39 423 Wetlands Maritime wetlands Intertidal flats 166-166-230

40 511 Water bodies Inland waters Water courses 000-204-242

41 512 Water bodies Inland waters Water bodies 128-242-230

42 521 Water bodies Marine waters Coastal lagoons 000-255-166

43 522 Water bodies Marine waters Estuaries 166-255-230

44 523 Water bodies Marine waters Sea and ocean 230-242-255

4.9.1.5. DEMIS

The DEMIS WMS services contain next layers:

World Map

• Bathymetry

• Countries

• Topography

• Hillshading

• Builtup areas

• Coastlines

• Waterbodies

• Inundated

• Rivers




67

• Streams

• Railroads

• Highways

• Roads

• Trails

• Borders

• Cities

• Settlements

• Spot elevations

• Airports

• Ocean features

4.9.1.6. GoogleMaps

GoogleMaps are composed from three layers:

• satelit

• teren,

• topo

4.9.2. Wild Salmon Monitoring

The major information flows between the different actors in both Wild Salmon Monitoring Use Cases are summarised (from D2.4.1) as follows:

1. Anglers, Fishermen and Fishing related businesses using the system

1. To track salmon fishing conservation regulations and limitations

2. To download information

3. To upload/maintain information

4. To participate in and contribute to salmon conservation measures.

2. Scientific Researchers using the system



3. To monitor, record and analyze salmon stocks.

4. To recommend salmon fishing conservation limits.

3. Decision Makers using the system

1. For socioeconomic planning purposes

2. To support environmental interventions

3. To issue salmon fishing conservation regulations

4. To support salmon fishing related businesses and promote local tourism

The Irish Pilot Salmon CL Portal uses




68

• Reference Data o from many official sources, such as the Scientific Standing Committee’s regulations

for 2011 on limits in specific rivers to ensure salmon conservation4, fishing information and wider regulations5 especially for foreign tourist anglers, who are a particular target of the Portal (so multilingual aspects will be included), the Irish Spatial Data Exchange6 and key Irish angling associations and clubs7.

• In-situ observations o from various sources, such as the IFI Salmon Monitoring Programme8, WFD water

quality monitoring9, wild salmon census data from the Marine Institute10 and scientific wild salmon conservation data11.

• Terrain measurement o from a number of sources, such as the Irish Spatial Data Exchange, IFI Salmon

Monitoring Programme and Water Framework Directive water quality measurements (as above).

• User edited data o from users of the Salmon CL portal itself, and various discussion forums12.

• User derived data o from users of the Salmon CL Portal’s own services (such as “Where are the local

Salmon biting”).

The Irish Pilot is mainly focusing on the Habitats and Biotopes (HB), and Species Distribution (SD) INSPIRE themes, using the HABITATS Metadata profiles defined in D3.2.1 and the IFI Salmon Conservation process best practice classification and naming schemas, in conjunction with a conceptual data model that imports and implements the following:



4 www.fishinginireland.info/salmon/salmontagging.htm 5 Such as www.fishinginireland.info/regulations.htm, www.irelandflyfishing.com/fishing.php, www.fishinginireland.info/salmon, www.flyfishireland.net, www.salmon-ireland.com/contacts/salmon-websites.jsp, and www.shannon-fishery-board.ie/links-fishing-sites.htm 6 www.isde.ie 7 Such as www.fissta.com, www.sstrai.ie, www.salmon-ireland.com/irish-fishing-clubs/irish-fishing-clubs.jsp, www.fishinginireland.info/links/clubslinks.htm 8 www.fisheriesireland.ie/Projects/national-salmon-monitoring-programme.html 9 www.wfdfish.ie 10 At www.marine.ie/home/services/operational/stock/Wild+Salmon+Census.htm 11 Such as www.marine.ie/home/services/operational/stock/Analysis+of+annual+and+historical+catch+statistics+and+their+trends.htm 12 Such as www.salmon-ireland.com, www.flyforums.co.uk/european-rest-world-fishery-updates/64639-lough-corrib.html, www.troutandsalmonfishingforum.com/forumdisplay.php?f=20, http://forum.iww.ie/viewforum.php?f=2 www.salmonfishingforum.com/forums/forumdisplay.php?27-Irish-Rivers , www.salmonireland.com/salmon-fishing-blog/blogs/salmon-fishing-blog-1.jsp ,

www.fishy-forum.com/forum/index.php?topic=595.0, http://thebigfish.proboards.com/index.cgi?board=7&action=display&thread=211,

www.salmonatlas.com/forums/salmon-fishing-talk-fly-fishing-forums/10030-atlantic-salmon-fishing-reports-irelands-cork-blackwater-river.html, www.theflyfishingforum.com/forums/coldwater-fly-fishing/12951-atlantic-salmon-fishing-reports-irelands-cork-blackwater-river.html , www.fishing.net/index.php?page=forum&section=forum&frm_id=100009, www.boards.ie/vbulletin/showthread.php?t=2055386003, http://fishinginscotland.yuku.com/forums/1/sort/updated_at/direction/DESC/mode/or/addtags/blackwater,fishing,ireland%20salmon%20fishing,salmon%20fishing/




69

• ISO 00639 Language Codes13 – declaration of languages used in string types. • Geographical Names – INSPIRE application scheme specified the attribute habitatsName. • EUNIS Classification System14 – taxonomy of species embed in current version of

documentation of Species distribution data specification.

In addition, the HB theme uses the following:

• Natural Risk Zones – INSPIRE application scheme provided the attribute determinationMethod and its values.

• PESI (Pan-European Species directories Infrastructure)15

4.9.3. LA PALMA PROTECTED MARINE AREA

The project is developed in the the marine reserve on the island of La Palma. The data will feed this system come from different sources:

• An oceanographic buoy located in the middle of the marine reserve, which provides the physico-chemical data of water, including: speed and direction of flow, dissolved oxygen, salinity, conductivity, pH, flourometría, turbidity, etc.

• Manual multiparametric sensors: measure many chemical parameters of water including: chrome, nickel, nitrates, phosphates, chlorine, bromine, etc.

• Socio-economic data of use of the reserve: acquired through the use of PDA for the surveillance of the marine reserve.

• Biological data: acquired through independent professional divers using underwater communication masks.

• Microbiological sensor manual: measuring the fecal contamination of water through the test of presence or absence of certain indicators.

13 See http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes 14 http://eunis.eea.europa.eu/ 15 At www.eu-nomen.eu/portal/




70

Figure : Data Flows in the Protected Marine Area Pilot

The data is harvested through different samples. This samples have got XY coordinates that means a point feature. With this points and its data we could create new polygons features or assign this data to existing areas. SeaRegions class is the unique in the data model. Inside this class we have included three basic feature types:

• SeaRegionArea

• SeaSubRegionArea

• SamplingPoints

Also we could obtain features about one parameter. A example of this option are two features very related with that overlaps with other themes:

• HabitatsAndBiotopesArea

• SpeciesDistributionArea

We may show the information in a geo-portal for predefined zones and the parameters associated with them and also specific features for each parameter with its spatial variation.

4.9.4. NATURAL RESERVE

We could use any type of information available in the environment, which in future will allow external layers to add and interoperable with INSPIRE. But initially we are working with issues identified in INSPIRE as:

- Hydrography,

- Administrative units,

- Land cover,




71

- Land use,

- Area management / restriction / regulation zones and reporting units,

- Buildings,

- Cadastral parcels,

- Orthoimagery,

- Elevation,

- Protected sites,

- Environmental monitoring facilities,

- Geographical names ,

- Species distribution,

- Transport networks, and

- Utility and Governmental Services.

We work with this information in varying degrees, for example the use of Buildings is much greater than the Transport networks.

The information comes from two means of public agencies and own harvest. Spatial data are mostly public and come mostly from the city government, their access is also free. Cover the Park environment and general aspects.

However, the data collected by us are the core of the application, contain the most important objects and points to represent. These can be species, buildings or other points of interest and are likely to be modified by the preferences of users.

4.9.5. HIKING TRIP PLANNER and SHEEP AND GOAT HERDING MANAGEMENT

The geospatial information is accessed by different actors according to the task to carry out:

• Personnel at Madonie Park Authority Office access geospatial data in order to:

1. To upload/maintain information about the assignment of grazing areas;

2. To download information on GIS software through OGC web services;

3. To monitor the presence of animals in the park area;

4. To control the level of pressure on grazing areas due to the presence of sheep, goats or cows.

• Researchers dealing with environmental aspects use the system



3. To study the effects of the presence of animals in the different areas of the park.

Other than from Habitats Portal, all the resources coming from Habitats project will be accessible, for two different pilots projects of Madonie Park, by unique geo-portal reporting all the link to data available in the different servers through web services; besides on the free and open source software server has been activate a WEBGIS application by which it is possible browsing the spatial data and querying operations.




72

The Madonie System uses some data coming from different sources:

Reference Data

They comes from many official sources, such as Sicily Region Administration web site 16 ; data can be downloaded but they can also be accessed through geospatial web services OGC compliant17.

6. Tracking data

1. Data coming from ‘tracking collars’ mounted on the neck of animals are saved in a POSTGIS database, so they can be show in the map area of web gis interface superimposed to grazing area plan and assignment of grazing areas in order to monitor the presence of animal of different owners;

7. User edited data

1. These are the data regarding the assignment of grazing areas that are updated by personnel internal to Madonie Park Authority Office, each time an area is assign to a shepherd;

The interaction between shepherds and Madonie Park Authority should take place through the social forum as part of the living lab action, and in particular using the social forum active in the TLL Sicily site.

4.9.6. ECONOMICAL ACTIVITY AT MARINE COASTAL BENTHIC HABITATS

IMCS has a cooperation with Latvian Institute of Aquatic Ecology (LIAE) which is a leading marine research institution and responsible for the marine environment monitoring. The aim of mutual work is to make easier accessible the environmental data that is being collected by the LIAE to provide updated information to fishermen, potential developers, decision makers and researchers in the Baltic Sea area on the marine coastal habitats of Latvia. The LIAE collects and holds the data but is involved into data submission activity as a part of Helsinki Commission (HELCOM)18 data policy.

The LIAE data are collected on the basis of regular monitoring and various scientific projects. Therefore data are having several formats and covering differing aspects regarding the coastal habitats. The implementation of the INSPIRE Directive is at the very first stage in Latvia and the activities have not introduced the data themes 17-20 yet. A small part of coastal environment data is available online through database of the International Council for the Exploration of the Seas (ICES)19 which provides the database service for HELCOM. However, the largest part of data and already produced information is stored offline. Thus the HABITATS pilot services will explore making it available as an open online service.

Table 1: Latvian Marine Coastal Habitats Data Summary

Type Quantity

and

Definition

Format

and

Quality

IPR Current Use Existing

Metadata

Language

Monitoring data of coastal benthic communities

Database of annually sampled marine benthic communities

Raw data, quality controlled, mostly MS Excel files

LIAE Internal use, for preparation of environmental assessments and research. Available for research upon request.

Proprietary English/Latvian

16 Such as http://www.artasicilia.eu/

17 Such as http://www.sitr.regione.sicilia.it/geoportale

18 www.helcom.fi 19 www.ices.dk




73

and substrate in 1985-2008, Gulf of Riga coast

Monitoring data of coastal benthic communities

Video recordings of marine benthic communities and substrate coverage, site at the Baltic Sea coast, 2006-2007

Collection of videos, avi.format and samping points in ESRI Shapefiles

LIAE Use for preparation of project reports and research


Monitoring data of related physico-chemical measurements

Database of water temperature, salinity, Secchi depths, basic nutrients, Latvian coastal zone, 1988-2008

Raw data, quality controlled, Borland Paradox, MS Access files

LIAE Internal use, for preparation of environmental assessments and research. Available for research upon request.


Table 2: Key Objectives of the Marine Habitats Pilot

Pilot in the category of

economic activities

Economical activity at marine coastal benthic habitats

Current platform Data stored in off-line databases.

HABITATS

enhancement

Use the HABITATS INSPIRE data structures and advanced interface to improve presentation, accessibility and use of the data collected by the Latvian Institute of Aquatic Ecology.

As the coastal region encompasses also protected areas (Natura 2000) with limited allowed actions the knowledge on location of habitats and their value is essential for all types of economical activities. Construction of wind parks and other types of renewable energy devices, building in ports and marinas, fishing, recreational and tourism-related arrangements – any stakeholder involved in mentioned processes should be aware of the habitats’ status in the respective area. Besides, the same knowledge is necessary for the authorities as ministries, environmental boards and coastal municipalities as the economical activities should be overseen and regulated to ensure sustainable management of the natural resources.

Taking into account the cross-border nature of any marine processes the data on habitat situation is relevant also for the countries sharing the Baltic Sea area. So the regional research and regulatory institutions will appreciate possibility on following the creation and test of structure and tools aimed at the involvement of national users through providing data products as a pilot case for the implementation of INSPIRE Directive.

4.9.7. NATIONAL FOREST PROGRAMME




74

The purpose of this use case to deliver and share the harmonised forest site data to be used as basis for the definition of the suitable forest management practices. The geographic data of the forest site classification describe the permanent ecological conditions, ie. division of forests into segments with similar growth conditions. The outputs of forest site classification serves as a basis for determining the economic measures, and operational and production goals (Forest management plans, forest management scheme). The importance of the outputs of forest typology was further strengthened in the new political-economic-environmental conditions, which has also become the basis for the evaluation functions of forest ecosystems, forest valuation, or the creation of management plans for specially protected areas.


1. Vegetation tiers (altitudinal vegetation zones) - taking into account the gradient of vertical zoning of vegetation (LVS)

2. Edaphic categories - reflecting a gradient of trophic conditions and hydricity

3. Forest type complex - combination of vegetation tier and the edaphic category is means unit (SLT)

Vegetation tier represents biocenological (geobiocenological) building unit, which reflects the influence of climate on the composition of biota of chtonophytic synusia (geobiocenoses) and which is determined by this composition. Vegetation tiers are differentiated by species that are in the first place trees, or. shrub determinants of main canopy level of indigenous forest and shrubs communities and all chtonophytes, that react decisively to the length of the growing season and the negative effects of climate. This means that vegetation tiers are determinated according to presence and expressions of living trees. There are 10 vegetation zones

1. Oak

2. Beech-oak

3. Oak-beech

4. Beech

5. Fir-beech

6. Spruce-beech

7. Beech-spruce

8. Spruce

9. dwarf pine

10. alpine

Forest type complex is a basic unit, which involves similar elementary units (Forest type) according to ecological affinity, according to their phytosociological similarity undergrowth and site conditions. Forest type complex is given by the combination of Vegetation tier and edaphic category. Forest type complex represent a natural forest ecosystems and all managed forests with same ecological conditions. Forest type complex are mapping units in the reconstruction maps.

Timber transport technologies have the direct connection (link) with natural conditions of the site. According to the forest road network can be constructed the basic infrastructure for access to forest site and is important for forest management. Based on transport accessing forestry harvesting technologies, silvicultural treatment and forest road network are constructed. Background of Joint rescue service aimed at navigation improvement for rescue service access in the forest complex (e.g. fire) is another significant area of model analysis in terms of Habitats project.

The information from the FMI forest road network database serve the integrated rescue system to localize and reach the event of forest fire in short time. The further information derived from the forest site maps (SLT) and digital terrain model (DTM) enhances the driver’s orientation and time




75

estimations. As there are similar activities in other the neighbouring countries (Slovakia, Austria), this pilot scenario can be used for the cross-border cooperation within the Habitats project.




76

5. COMPUTATIONAL VIEWPOINT-LOGICAL ARCHITECTURE

5.1. CONCERNS

The computational viewpoint is functional decomposition of the system into basic objects which interact at interfaces. It describes the functionality provided by the system and its functional decomposition. This viewpoint focuses on the components of the system, not considering distribution aspects, which are managed within the Engineering and Technology viewpoints. The proposed architecture extends principles of Service Oriented Architecture, based on publish-find-bind paradigm. The primary components identified for HABITATS are described below.

5.1.1. FILE SYSTEM

A file system (often also written as filesystem) is a method of storing and organizing computer files and their data. Essentially, it organizes these files into a database for the storage, organization, manipulation, and retrieval by the computer's operating system. Most file systems make use of an underlying data storage device that offers access to an array of fixed-size physical sectors. , The file system is responsible for organizing these sectors into files and directories, and keeping track of which sectors belong to which file and which are not being used. Most file systems address data in fixed-sized units called "clusters" or "blocks" which contain a certain number of disk sectors. This is the smallest amount of disk space that can be allocated to hold a file. However, file systems need not make use of a storage device at all. A file system can be used to organize and represent access to any data, whether it is stored or dynamically generated.

A file name (or filename) is a name assigned to a file in order to secure storage location in the computer memory. Whether the file system has an underlying storage device or not, file systems typically have directories which associate file names with files, usually by connecting the file name to an index in a file allocation table of some sort, such as the FAT in a DOS file system, or an inode in a Unix-like file system. Directory structures may be flat, or allow hierarchies where directories may contain subdirectories. In some file systems, file names are structured, with special syntax for filename extensions and version numbers. In others, file names are simple strings, and per-file metadata is stored elsewhere.

A network file system is a file system that acts as a client for a remote file access protocol, providing access to files on a server. Examples of network file systems include clients for the NFS, AFS, SMB protocols, and file-system-like clients for example FTP. 20

File system could be used for storing spatial data in proprietary format (shp, dgn, dwg, dgn and others) or also for storing non spatial data for example documents, photos etc.

Required functions are upload and download of data and deleting of data.

5.1.2. RDBMS

A relational database management system (RDBMS) is a database management system (DBMS) that is based on the relational model. Most popular commercial and open source databases currently in use are based on the relational database model. A short definition of an RDBMS may be a DBMS in which data is stored in the form of tables and the relationship among the data is also stored in the form of tables.21

A relational database matches data by using common characteristics found within the data set. The resulting groups of data are organized and are much easier for many people to understand. For example, a data set containing all the real-estate transactions in a town can be grouped by the year the

20

Wikipedia File system, http://en.wikipedia.org/wiki/File_system

21 Wikipedia Relational database management system,

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




77

transaction occurred; or it can be grouped by the sale price of the transaction; or it can be grouped by the buyer's last name; and so on.

Such a grouping uses the relational model (a technical term for this is schema). Hence, such a database is called a "relational database”.

A relation is defined as a set of tuples that have the same attributes. A tuple usually represents an object and information about that object. Objects are typically physical objects or concepts. A relation is usually described as a table, which is organized into rows and columns. All the data referenced by an attribute are in the same domain and conform to the same constraints.

The relational model specifies that the tuples of a relation have no specific order and that the tuples, in turn, impose no order on the attributes. Applications access data by specifying queries, which use operations such as select to identify tuples, project to identify attributes, and join to combine relations. Relations can be modified using the insert, delete, and update operators. New tuples can supply explicit values or be derived from a query. Similarly, queries identify tuples for updating or deleting. It is necessary for each tuple of a relation to be uniquely identifiable by some combination (one or more) of its attribute values. This combination is referred to as the primary key.

Relational databases are currently the predominant choice in storing financial records, medical records, manufacturing and logistical information, personnel data and much more. A stored procedure is executable code that is associated with, and generally stored in, the database. Stored procedures usually collect and customize common operations, like inserting a tuple into a relation, gathering statistical information about usage patterns, or encapsulating complex business logic and calculations.22 Frequently they are used as an application programming interface (API) for security or simplicity. Implementations of stored procedures on SQL DBMSs often allow developers to take advantage of procedural extensions (often vendor-specific) to the standard declarative SQL syntax. Stored procedures are not part of the relational database model, but all commercial implementations include them. SQL, is a database computer language designed for managing data in relational database management systems (RDBMS), and originally based upon relational algebra and calculus. Its scope includes data insert, query, update and delete, schema creation and modification, and data access control. SQL was one of the first commercial languages. 23

Currently relation databases could be also used for storing spatial data, registries, images, textual files etc.

Required functions are upload and download of data and deleting of data.

5.1.3. Sensor connector

Data from sensor networks or sensors are usually coming on the server in proprietary form. The role of sensor connector is to store sensors data into RDBMS. The In-Situ Data Access Service shall offer the DescribeSensor operation as defined in the OGC SOS standard, for requesting information about the sensor itself, encoded in a Sensor Model Language (SensorML) instance document. For data storing are important tables:

units

List of Gateways located in sensor network. sensors

List of sensor types located in sensor network, sensors are attached to units (m:n) phenomenons

Phenomenons of measured values observations

particular sensor observations

22

Wikipedia Relational database, http://en.wikipedia.org/wiki/Relational_database,

23 WIKIPEDIA, SQL http://en.wikipedia.org/wiki/Structured_Query_Language,




78

alert_events

Real events of alert situation (e.g. temperature is exceeding predefined threshold) alerts

General description of alert situation that should be monitored

5.1.4. ACES infrastructure As the geo-portal consists in various applications with different purposes, a single point of user login and application permissions discovery are required. For this goal, the system is required to provide an application that is capable of using various required data backends due to deployment specifics. Also, it needs to provide a communication frontend for various “clients”, where client means everything from desktop application to mobile service.




79

The Server part of Access Control Service is composed from

• Core:

o Authentication Core – contains functions for communication with authentication connectors for specific authentication method (LDAP, SAML, …);

o Authorization Core – contains functions for communication with authorisation connectors;

o Administration Core – contains functions for manage objects inside ACOS (users, user groups, permissions, parameters).

• Connectors:

o a separate connector exists for each authentication and authorisation method.

5.1.5. Web Map server

Web Map Server includes tools, which support publishing of locally stored data (filesystem, RDBMS) in the form of web services. The basic required services are:

• A Web Map Service (WMS) is a standard protocol for serving geo-referenced map images over the Internet that are generated by a map server using data from a GIS database

• A Styled Layer Descriptor (SLD) is an XML schema specified by the Open Geospatial Consortium (OGC) for describing the appearance of map layers. It is capable of describing the




80

rendering of vector and raster data. A typical use of SLDs is to instruct a Web Map Service (WMS) of how to render a specific layer.

• Web Feature Service Interface Standard (WFS) provides an interface allowing requests for geographical features across the web using platform-independent calls. One can think of geographical features as the "source code" behind a map, whereas the WMS interface or online mapping portals like Google Maps return only an image, which end-users cannot edit or spatially analyze.

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

5.1.6. Metadata server

A metadata server is a software server that performs metadata, administrative, and storage-management services and provides clients with shared, coherent access to shared storage (or global namespace). They process requests to create and manage filesets, storage pools, volumes, and policies; enforces the policies to place files in appropriate storage pools; and sends alerts when any threshold established for the filesets and storage pools are exceeded.

The regester functionality is to support:

• ISO19115, which is is a standard of the International Organization for Standardization (ISO). It is a component of the series of ISO 191xx standards for Geospatial metadata. ISO 19115 defines how to describe geographical information and associated services, including contents, spatial-temporal purchases, data quality, access and rights to use.

• ISO 19119:2005 identifies and defines the architecture patterns for service interfaces used for geographic information, defines its relationship to the Open Systems Environment model, presents a geographic services taxonomy and a list of example geographic services placed in the services taxonomy. It also prescribes how to create a platform-neutral service specification, how to derive conformant platform-specific service specifications, and provides guidelines for the selection and specification of geographic services from both platform-neutral and platform-specific perspectives.

• ISO 19139 provides the XML implementation schema for ISO 19115 specifying the metadata record format and may be used to describe, validate, and exchange geospatial metadata prepared in XML

• Dublin Core ISO 15836:2009 defines the elements typically used in the context of an application profile which constrains or specifies their use in accordance with local or community-based requirements and policies. However, it does not define implementation details, which is outside the scope of ISO 15836:2009.

• The OGC Catalog Service defines common interfaces to discover, browse, and query metadata about data, services, and other potential resources. Web Catalog Service includes several profiles including Catalog Service - Web. Metadata server has support standard and also transastional services.

Catalogue Services shall be able:

• Search for list of records on the base of requirements

• to return associated meta information instances of features selected by user

• support for harvesting

• support transactional editing

• discovery query on the base of INSPIRE (Habitats specification)




81

5.1.7. WPS

Web Processing Service (WPS) is designed to standardize the way that GIS calculations are made available to the Internet. WPS can describe any calculation (i.e. process) including all of its inputs and outputs, and trigger its execution as a Web Service. WPS supports simultaneous exposure of processes via HTTP GET, HTTP POST, and SOAP, thus allowing the client to choose the most appropriate interface mechanism. The specific processes served up by a WPS implementation are defined by the owner of that implementation. Although WPS was designed to work with spatially referenced data, it can be used with any kind of data.

WPS makes it possible to publish, find, and bind to processes in a standardized and thus interoperable fashion. Theoretically it is transport/platform neutral (like SOAP), but in practice it has only been specified for HTTP.

WPS has support operations:

• GetCapabilities

• DescribeProcess

• Execute

• Workflow creation

5.1.8. Sensors server

A sensor web is a type of sensor network or geographic information system (GIS) that is especially well suited for environmental monitoring.[ The term describes a specific type of sensor network: an amorphous network of spatially distributed sensor platforms (pods) that have wireless communication with each other. This amorphous architecture is unique since it is both synchronous and router-free, making it distinct from the more typical TCP/IP-like network schemes. The architecture allows every pod to know what is going on with every other pod throughout the sensor web at each measurement cycle. For the purpose of HABITATS the accessibility of measurement in sensor database has to be done using next services:

• Sensor Observation Service Interface Standard (SOS) provides an API for managing deployed sensors and retrieving sensor data and specifically “observation” data. Whether from in-situ sensors (e.g., water monitoring) or dynamic sensors (e.g., satellite imaging), measurements made from sensor systems contribute most of the geospatial data by volume used in geospatial systems today.

• Sensor Alert Service (SAS) provides a push-based access to observations. The SAS can be compared with an event notification system, where the sensor is the object of interest. Each sensor has to register (advertise) the observations it will send to the SAS via the publish operation. A consumer interested in certain events may subscribe to alerts disseminated by the SAS. If an event occurs the SAS will notify all clients subscribed to this event type.

• The Sensor Event Service (SES) is an enhancement of the Sensor Alert Service (SAS). Both are used to provide a publish / subscribe based access to sensor data and measurements. They also provide optional methods to dynamically add new sensors and send notifications to the service

• Additionally sensors measurement could be accessed using WFS and visualized using WMS

5.1.9. Geographical extensions for RBDSM

Geographical extensions for RBDSM support for geographic objects to the SQL object-relational database. In effect, its "spatially enables" the SQL server, allowing it to be used as a backend spatial database for geographic information systems (GIS)

5.1.10. Web Based GIS Analytical Tools




82

The part of architecture are GIS analytical tools, which could provide analysis and transformation of spatial data. This tools will be usually hidden and will be accessible trough WPS. Principally this analytical tools could also be a desktop application, which is used by WPS as analytical engine.

5.1.11. Registry management

The system need to use different registers like register organisation, GEMET, etc. The registry management support management of information in RDBMS. The registry services component acts as a “service repository” in a basic SOA “publish/find/bind” pattern for distributed system.

This component implements the “publish-find-bind” pattern:

• publish: register a service in the registry, along with service metadata suitable for further use from a consumer;

• find: query the service registry to allow discovery (search) and locate a service to be invoked; the search is performed onto services metadata stored in the repository;

• bind: returns the “service metadata” for services stored in the registry to allow the bind and invoke from a service consumer, allowing the service consumer to bind to the service provider.

SOA publish/find/bind pattern.

Basically, this pattern can be described as follows:

• the service provider publishes a service into the registry, providing also the service description (capabilities) through service metadata;

• the registry (the services repository) allows the search of services and retrieval of their descriptions, by which to locate a service;

• the service consumer finds services via the registry and binds to the provider using service metadata.

Operations

• - register service through its metadata;

• - search service (query service metadata repository);

• - get service metadata (get capabilities).

The component operations are accessed through the following interfaces:

• - register;

• - publish;

• - search.

Also, the component uses the following interfaces from other components:

• - horizontal services : control.

5.1.12. Authorisation/Authentication

Access Interface is given by next functions

• SOAP – whole functionalities of ACOS Core are available throw SOAP WebService interface. This is very important for use from many different devices (server, desktop, mobile) and platform (Windows, .NET, Java, …)

• OAuth – allows users to share their private resources stored on geo-portal (in any application of geo-portal) with another site / application without having to handout their credentials.

• OpenID – each user registered on ACOS (geo-portal) have automatically OpenID identification which allows users login to external applications with it




83

5.1.12.1. Authorization Service

• Description - SOAP WebService for obtaining permissions and parameters for logged user

• Methods

o GetParameter

o GetPermission

5.1.12.2. Administration service

• Description - SOAP Web Service (maybe RESTful will be better) for manage objects inside ACOS (users, user groups, permissions, custom objects)

• Methods

o AddUser, EditUser, DeleteUser

o AddGroup, EditGroup, DeleteGroup

o AddPermission, RemovePermission

o AddObject, EditObject, DeleteObject

5.1.12.3. OpenID

• Description - OpenID provider service

• Methods - related to OpenID specification

5.1.12.4. OAuth

• Description - OAuth provider service

• Methods - related to OAuth specification

5.1.12.5. Discovery

This component provides the access to HABITATS and external metadata to users or to other system components. It implements search/discovery services, thus exposes catalogue services.

Search/discovery: the goal of discovery is to support discovery, evaluation and use of spatial data and services through their metadata properties (source: D3.5 – INSPIRE Architecture v2.0).

Thus, metadata services perform:

• search/discovery (CSW):

o search the metadata catalogue for record that matches the user’s search criteria;

o extract the results list and pass it to the “portrayal service” through the horizontal service;

• extract a single record from the metadata catalogue and pass it to the “portrayal service” through the horizontal service;

• allow the content provider to produce, upload and import metadata;

• allow the content provider to edit/update metadata.




84

Operations

• get discovery service metadata (get capabilities);

• discover metadata:

o get metadata records (through search);

• get metadata record (by resource unique ID identification).

Interfaces

The component operations are accessed through the interface capture metadata.

5.1.13. View

The view services perform the rendering of “generic data” (catalogue entry, map image,…) into an output format that will be delivered to the user through the “horizontal service” and then through the application services.

The generic “rendering” to the application service can be specialised to allow:

• rendering of the output from search/discovery service (e.g. list of metadata item found from a search):

o build the link to the catalogue item, allowing the user to direct access it.

• rendering of a metadata item:

o build, if available in the metadata record, the link to the resource, allowing the user to direct access it.

• rendering of the output from view service (e.g. image with overlays);

• rendering of the output from download service (e.g. a shapefile or a GML);

• rendering of the output from transform service.

The rendering is accessed through the interface view delivery.

• services client shall support OGC Catalogue Service (CSW) specification, version 2.0.2, Application Profile ISO19115/19119

• services client shall allow users to query and select data

• services client shall allow users to access Table of Contents and switch layers on/off YES

• services client shall allow users to retrieve maps and/or data, adding layers as:

.1. Web Map Services

.2. Web Feature Services

.3. Web Coverage Services

• services client shall allow users to add layers to the map in the following ways:

• URL (OWS GetCapabilities)

• services client shall allow users to remove layers

• services client shall allow users to change the opacity of each layer

• services client shall allow users to export and save locally the context of the map in the following graphic formats:

• services client shall allow users to export and save locally the context of the map as hyperlink




85

• services client shall allow users to export and save locally the context of the map as Web Map Context (WMC) document

• services client shall allow users to export and save locally the context of the map as Keyhole Markup Language (KML) document

• Zoom/Scale numeric and with bar

• Pan

• Favorite Views

• Minimap of situation

• Hide table of contents and/Minimap

• Info bar of projection and coordinates

• services client shall allow users to change the Coordinate Reference System (CRS) of the map. The minimum set of CRSs available to the user shall be the following:

• EPSG:4326 YES

• EPSG:4979 , EPSG:4327 , EPSG:4937

• WGS84 UTM covering Europe (roughly ranging from EPSG:32628 to EPSG:32638 )

• EPSG:4258 (aka ETRS89)

• EPSG:4156

• EPSG:4818

• EPSG:4156

• EPSG:3763

• EPSG:3035 (aka ETRS89-LAEA)

• EPSG:3034 (aka ETRS89-LCC)

• EPSG:3038 to EPSG:3051 (aka ETRS89-TMzn)

5.1.14. WFS Gazetteer

The WFS-G serves has to be fully ISO 19112-compliant deployment of Gazetteer data. WFS-G include:

• Easy access to well-known place-name vocabularies

• Facilitates geo-information discovery in GeoPortal applications

• Promotes real-time access and maintenance of Geonames

• Facilitates data currency of Geonames within Web Feature Services

• Enables testing of collaborative maintenance of Geonames using transactions

• Facilitates automated geosynchronization of data across multiple datasets

• Support ISO 19112 information models

• Supports development of a variety of location-based applications

5.1.15. Data services

This component implements view and download services, thus exposes map/feature services.

View: view services allow display, navigate, zoom in and out, pan or overlay viewable spatial data sets and display legend information and any relevant content of metadata.




86

Download: download services allow extracting copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly (source: D3.5 – INSPIRE Network Services

Architecture v2.0).

Thus, this component exposes using services to:

• produce the layer in raster format (view – WMS) and pass it, “through” the horizontal service, to the “view service”:

o produce the “view” (PNG, GIF, …) of a whole data set or a part of in a coordinate system supported optionally through the transformation service exposed by “processing services”);

• produce the data in vector format (download – WFS – GML, shapefile) and pass it, “through” the horizontal service, to the “portrayal service”:

o allow the download of a whole data set or a part of it;

o allow direct access to a whole data set or a part of it;

o allow direct access to a feature and to its attributes (structured attributes are managed at the data model level/information viewpoint, e.g. structured attributes inherit the spatial attribute from the feature).

This component can use the harmonisation service.

Operations:

• View services operations (WMS, WFS):

o get service metadata (get capabilities);

o get map;

o get feature information.

• Download services operations

o get download service metadata (get capabilities);

o get spatial objects (get feature);

o describe spatial object type (describe feature type);

o query spatial objects.

Interfaces:

The component operations are accessed through the interface capture data.


• harmonisation services :: mapping data;

• horizontal services :: control.

5.1.16. Transformation

This component is designed in order to carry out the mapping between the application schemas of HABITATS and the application schemas of the data provided by the partners.

The main goal of this component is to perform transformation of data starting from:

• input schema (can be a WFS also);

• target schema;

• schema mapping (metadata/transformation rules).

This service can be exploited on two scenarios:




87

• on-the-fly transformation;

• upload unharmonised data.

The main sub-components should be:

• transformation engine (the transformer), which exposes the service to perform the physical transformation; the result is then passed, through the horizontal service, to the “portrayal service”;

• the transformation designer, to build the mapping between schemas.

This component is used, through horizontal services, by the application services and data services in response to a user agent request.

Operations:

• transform data.

The component operations are accessed through the interface data mapping.



5.1.17. Analysis

This component implements transform services (D3.5 – INSPIRE Network Services Architecture v2.0), thus exposes map/feature transform services.

It exposes services to:

• transform a data set from the native coordinate system to the required coordinate system (SRS transform – e.g. from Gauss Boaga to WGS84);

• transform the format of a data set (e.g. from shapefile to GML).

• Invoke: for spatial data services available on the Internet

Operations

• get transformation service metadata (get capabilities);

• transform (transform coordinates).

• Getprocessing services

Interfaces

The component operations are accessed through the interface data delivery.


• data services :: capture data;


5.1.18. Monitoring

As a basic tool monitoring, based on logins of users, will be established. A full log analysis will enable to show you the following information:

• Number of visits, and number of unique visitors,




88

• Visits duration and last visits,

• Authenticated users, and last authenticated visits,

• Days of week and rush hours (pages, hits, KB for each hour and day of week),

• Domains/countries of hosts visitors (pages, hits, KB, 269 domains/countries detected, GeoIP detection),

• Hosts list, last visits and unresolved IP addresses list,

• Most viewed, entry and exit pages,

• Files type,

• Web compression statistics (for mod_gzip or mod_deflate),

• OS used (pages, hits, KB for each OS, 35 OS detected),

• Browsers used (pages, hits, KB for each browser, each version ,

• Visits of robots ,

• Worms attacks

• Search engines, key phrases and keywords used to find your site,

• HTTP errors (Page Not Found with last referrer, ...),

• Other personalized reports based on url, url parameters, referrer field for miscellaneous/marketing purpose,

• Number of times your site is "added to favourites bookmarks".

• Screen size (need to add some HTML tags in index page).

• Ratio of Browsers with support of: Java, Flash, RealG2 reader, Quicktime reader, WMA reader, PDF reader (need to add some HTML tags in index page)

In accordance with INSPIRE directive services requests and services conformity monitoring the use of network services. The indicator will count all the requests to the service. Second part will be the monitoring of the conformance of network services.

Separate monitoring will be also provided by single applications, like catalogue. Then all results of the monitoring will be available trough reporting client.

5.1.19. External services

Discovery, view, data, transformation, analysis, authorization and authentication services could be implemented as internal, as describe in previous chapters or could be used as external services coming from remote servers. Interfaces are the same as for internal services.

5.1.20. Geo-portal BUS

Core of geo-portal is REST or SOAP service. SOA was used mainly because there was a need of independence on language and flexibility of the whole system. SOAP implementation is used in older version which is now used in most geo-portal installations. Python language was used for this implementation using Soaplib and Suds client.

5.1.21. Applications

The geo-portal is not a tool for standard users. For most of users applications are important. The idea of HABITATS architecture is, that Applications are not developed as independent proprietary solutions, but they are composed from existing services, using portal infrastructure.

5.1.22. Applets

An applet is a program written in the Java programming language that can be included in an HTML page, much in the same way an image is included in a page. When you use a Java technology-enabled




89

browser to view a page that contains an applet, the applet's code is transferred to your system and executed by the browser's Java Virtual Machine (JVM). For information and examples on how to include an applet in an HTML page, refer to this description of the <APPLET> tag.24

5.1.23. Servlets

A Servlet is a Java class in Java EE that conforms to the Java Servlet API, a protocol by which a Java class may respond to HTTP requests. They are not tied to a specific client-server protocol, but are most often used with this protocol. The word "Servlet" is often used in the meaning of "HTTP Servlet". Thus, a software developer may use a servlet to add dynamic content to a Web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML. Servlets are the Java counterpart to non-Java dynamic Web content technologies such as CGI and ASP.NET. Servlets can maintain state in session variables across many server transactions by using HTTP cookies, or URL rewriting.

The servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of a Web container and a servlet. A Web container is essentially the component of a Web server that interacts with the servlets. The Web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights.

A Servlet is an object that receives a request and generates a response based on that request. The basic servlet package defines Java objects to represent servlet requests and responses, as well as objects to reflect the servlet's configuration parameters and execution environment. The package javax.servlet.http defines HTTP-specific subclasses of the generic servlet elements, including session management objects that track multiple requests and responses between the Web server and a client. Servlets may be packaged in a WAR file as a Web application.25

5.1.24. Portlets

Portlets are pluggable user interface software components that are managed and displayed in a web portal. Portlets produce fragments of markup code that are aggregated into a portal. Typically, following the desktop metaphor, a portal page is displayed as a collection of non-overlapping portlet windows, where each portlet window displays a portlet. A portlet (or collection of portlets) resembles a web-based application that is hosted in a portal. Some examples of portlet applications are email, weather reports, discussion forums, and news. Portlet standards are intended to enable software developers to create portlets that can be plugged in to any portal supporting the standards.

The purpose of the Web Services for Remote Portlets protocol is to provide a web services standard that allows for the "plug-n-play" of remote running portlets from disparate sources. Portelts allows to registered users to personalise their view of the website by turning on or off portions of the webpage, or by adding or deleting features. The Portlet specification defines a portlet as a "Java-technology-based web component, managed by a portlet container that processes requests and generates dynamic content. The Java Portlet Specification (JSR168, JSR286) enables interoperability for portlets between different web portals. This specification defines a set of APIs for interaction between the portlet container and the portlet addressing the areas of personalization, presentation and security. Liferay Portal supports JSR168 standards.

Portal functionality can be divided into three main parts:

1. Portlet container: every portlet is deployed inside a portlet container that controls the life cycle of the portlet and provides it with necessary resources and information about its environment. A portlet container is responsible for initializing and destroying portlets and also

24

http://java.sun.com/applets/

25 http://en.wikipedia.org/wiki/Java_Servlet




90

for passing user requests to it and collecting responses. URM allows to describe portlets by metadata

2. Content aggregator: As defined in the Portlet Specification, one of the main jobs of a portal is to aggregate content generated by various portlet applications.

3. Common services: One of the main strengths of a portal server is the set of common services that it provides. Services are not part of the portlet specification, but portal implementations provide a rich set of common services. A few common services are:

o Single sign on: Allows you to get access to all other applications once you log into the portal server, meaning you don't have to log into every application separately. For example, once I log in to my intranet site, I should get access to my mail application, IM messaging application, and other intranet applications, without having to log into each of these applications separately.

A portal server provide a secured credentials store.

Personalization: The basic implementation of personalization service allows a user to customize his page in two ways. The user can decide what colors he wants for title bars and what icons he wants for controls. User can decide which portlets are wanted on his page.

Portlets do provide some additional functionality.

1. Persistent storage for preferences: Portlets provide a PortletPreferences object for storing user preferences. These preferences are stored in a persistent data store, so they will be available across server restarts.

2. Request processing: Portlets provide much more refined request handling. A portlet may get a request when user takes some action on it (a state called action phase), or because the user took action on some other portlet and the page needs to be refreshed. A portal server provides different callback methods for handling both situations.

3. Portlet modes: Portlets use a concept of mode to indicate what user is doing. Portlets normally provide this in VIEW mode. But there are other activities, like specifying a refresh time or (re-)setting the username and password. These activities allow the user to configure the behavior of the application, so they come under EDIT mode.

4. Window state: The window state determines how much space should be given to content generated by a portlet on a portal page.

5. User information: Commonly, portlets provide content personalized to the user making the request. The Portlet API provides the concept of user attributes for this. A developer can access these attributes in a standard way, and it is the responsibility of the administrator to map these attributes to an actual user information repository.

5.1.25. 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 other users in the future. A Context document is structured using eXtensible Markup Language (XML). Potential uses for context documents in the risk management environment 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. 26

26

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




91

5.1.26. RSS/GeoRSS

RSS (most commonly expanded as Really Simple Syndication) is a family of web feed formats used to publish frequently updated works—such as blog entries, news headlines, audio, and video—in a standardized format. An RSS document (which is called a "feed", "web feed", or "channel") includes full or summarized text, plus metadata such as publishing dates and authorship. Web feeds benefit publishers by letting them syndicate content automatically. They benefit readers who want to subscribe to timely updates from favored websites or to aggregate feeds from many sites into one place. RSS feeds can be read using software called an "RSS reader", "feed reader", or "aggregator", which can be web-based, desktop-based, or mobile-device-based. A standardized XML file format allows the information to be published once and viewed by many different programs. The user subscribes to a feed by entering into the reader the feed's URI or by clicking a feed icon in a web browser that initiates the subscription process. The RSS reader checks the user's subscribed feeds regularly for new work, downloads any updates that it finds, and provides a user interface to monitor and read the feeds. RSS allows users to avoid manually inspecting all of the websites they are interested in, and instead subscribe to websites such that all new content is pushed onto their browsers when it becomes available.27

GeoRSS is an emerging standard for encoding location as part of a Web feed. (Web feeds are used to describe feeds ("channels") of content, such as news articles, Audio blogs, video blogs and text blog entries. These web feeds are rendered by programs such as aggregators and web browsers.) The name "GeoRSS" is derived from RSS, the most known Web feed and syndication format.

In GeoRSS, location content consists of geographical points, lines, and polygons of interest and related feature descriptions. GeoRSS feeds are designed to be consumed by geographic software such as map generators. By building these encodings on a common information model, the GeoRSS collaboration is promoting interoperability and "upwards-compatibility" across encodings.

At this point, the GeoRSS collaboration has completed work on two primary encodings that are called GeoRSS Geography Markup Language (GML) and GeoRSS Simple. GeoRSS-Simple is a very lightweight format that supports basic geometries (point, line, box, polygon) and covers the typical use cases when encoding locations. GeoRSS GML is a formal Open Geospatial Consortium (OGC) GML Application Profile, and supports a greater range of features than GeoRSS Simple, notably coordinate reference systems other than WGS84 latitude/longitude. There is also a W3C GeoRSS serialization, which is older and partly deprecated but still the most widely used.28

5.1.27. KML/KMZ

Keyhole Markup Language (KML) is an XML schema for expressing geographic annotation and visualization within Internet-based, two-dimensional maps and three-dimensional Earth browsers. KML was developed for use with Google Earth, which was originally named Keyhole Earth Viewer. KML is an international standard of the Open Geospatial Consortium. Google Earth was the first program able to view and graphically edit KML files. Other projects such as Marble have also started to develop KML support.

The KML file specifies a set of features (place marks, images, polygons, 3D models, textual descriptions, etc.) for display in Google Earth, Maps and Mobile, or any other 3D Earth browser (geobrowser) implementing the KML encoding. Each place always has a longitude and a latitude. Other data can make the view more specific, such as tilt, heading, altitude, which together define a "camera view". KML shares some of the same structural grammar as GML. Some KML information cannot be viewed in Google Maps or Mobile.

KML files are very often distributed in KMZ files, which are zipped files with a .kmz extension. These must be legacy (ZIP 2.0) compression compatible (e.g. deflate method), otherwise the .kmz file might

27

http://en.wikipedia.org/wiki/RSS 28

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




92

not uncompress in all geobrowsers. The contents of a KMZ file are a single root KML document (notionally "doc.kml") and optionally any overlays, images, icons, and COLLADA 3D models referenced in the KML including network-linked KML files. The root KML document is typically a file named "doc.kml" at the root directory level but the first .kml file entry in the KMZ file is the actual one selected in Google Earth regardless of its name. By convention the root KML document is at root level and referenced files are in subdirectories (e.g. images for overlay images).29

5.1.28. iFrame

The <iframe> tag defines an inline frame that contains another document. HTML frames allow authors to present documents in multiple views, which may be independent windows or subwindows. Multiple views offer designers a way to keep certain information visible, while other views are scrolled or replaced. For example, within the same window, one frame might display a static banner, a second a navigation menu, and a third the main document that can be scrolled through or replaced by navigating in the second frame. An HTML document that describes frame layout (called a frameset document) has a different makeup than an HTML document without frames. A standard document has one HEAD section and one BODY. A frameset document has a HEAD, and a FRAMESET in place of the BODY. The FRAMESET section of a document specifies the layout of views in the main user agent window. In addition, the FRAMESET section can contain a NOFRAMES element to provide alternate content for user agents that do not support frames or are configured not to display frames. Elements that might normally be placed in the BODY element must not appear before the first FRAMESET element or the FRAMESET will be ignored.30

5.1.29. DIV

The <div> tag defines a division or a section in an HTML document. The <div> tag is often used to group block-elements to format them with styles. In HTML, the span and div elements are used where parts of a document cannot be semantically described by other HTML elements. Most HTML elements carry semantic meaning – i.e. the element describes, and can be made to function according to, the type of data contained within. For example, a p element should contain a paragraph of text, while an h1 element should contain the highest-level header of the page; user agents should distinguish them accordingly. However, as span and div have no innate semantic meaning besides the logical grouping of the content, they can be used to specify non-standard presentation or behavior without superfluous semantic meaning.31

5.1.30. Augment reality

Augmented reality (AR) is a term for a live direct or indirect view of a physical, real-world environment whose elements are augmented by computer-generated sensory input, such as sound or graphics. It is related to a more general concept called mediated reality, in which a view of reality is modified (possibly even diminished rather than augmented) by a computer. As a result, the technology functions by enhancing one’s current perception of reality. By contrast, virtual reality replaces the real-world with a simulated one.

Augmentation is conventionally in real-time and in semantic context with environmental elements, such as sports scores on TV during a match. With the help of advanced AR technology (e.g. adding computer vision and object recognition) the information about the surrounding real world of the user becomes interactive and digitally manipulable. Artificial information about the environment and its objects can be overlaid on the real world. Research explores the application of computer-generated imagery in live-video streams as a way to enhance the perception of the real world. AR technology

29

http://en.wikipedia.org/wiki/Keyhole_Markup_Language 30 http://www.w3.org/TR/html4/present/frames.html

31 http://en.wikipedia.org/wiki/Span_and_div




93

includes head-mounted displays and virtual retinal displays for visualization purposes, and construction of controlled environments containing sensors and actuators.32

5.1.31. CMS

A content management system (CMS) is the collection of procedures used to manage work flow in a collaborative environment. These procedures can be manual or computer-based. The procedures are designed to do the following:

• Allow for a large number of people to contribute to and share stored data

• Control access to data, based on user roles (defining which information users or user groups can view, edit, publish, etc.)

• Aid in easy storage and retrieval of data

• Reduce repetitive duplicate input

• Improve the ease of report writing

• Improve communication between users

In a CMS, data can be defined as nearly anything: documents, movies, pictures, phone numbers, scientific data, and so forth. CMSs are frequently used for storing, controlling, revising, semantically enriching, and publishing documentation. Serving as a central repository, the CMS increases the version level of new updates to an already existing file. Version control is one of the primary advantages of a CMS.33

5.1.32. Social Networks and Media

Social media are media for social interaction, using highly accessible and scalable publishing techniques. Social media use web-based technologies to turn communication into interactive dialog. Andreas Social media as could be also defined as "a group of Internet-based applications that build on the ideological and technological foundations of Web 2.0, which allows the creation and exchange of user-generated content". Businesses also refer to social media as consumer-generated media (CGM). A common thread running through all definitions of social media is a blending of technology and social interaction for the co-creation of value.34

5.1.33. Workflow management

A workflow consists of a sequence of connected steps. It is a depiction of a sequence of operations, declared as work of a person, a group of persons, an organization of staff, or one or more simple or complex mechanisms. Workflow may be seen as any abstraction of real work. For control purposes, workflow may be a view on real work under a chosen aspect, thus serving as a virtual representation of actual work. The flow being described often refers to a document that is being transferred from one step to another. A workflow is a model to represent real work for further assessment, e.g., for describing a reliably repeatable sequence of operations. More abstractly, a workflow is a pattern of activity enabled by a systematic organization of resources, defined roles and mass, energy and information flows, into a work process that can be documented and learned. Workflows are designed to achieve processing intents of some sort, such as physical transformation, service provision, or information processing. Workflow concepts are closely related to other concepts used to describe organizational structure, such as silos, functions, teams, projects, policies and hierarchies. Workflows may be viewed as one primitive building block of organizations. The relationships among these

32 http://en.wikipedia.org/wiki/Augmented_reality

33 http://en.wikipedia.org/wiki/Content_management_system

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




94

concepts are described later in this entry. The term workflow is used in computer programming to capture and develop human-to-machine interaction.35

A workflow management system is a computer system that manages and defines a series of tasks within an organization to produce a final outcome or outcomes. Workflow Management Systems allow you to define different workflows for different types of jobs or processes. So, for example, in a manufacturing setting, a design document might be automatically routed from designer to a technical director to the production engineer. At each stage in the workflow, one individual or group is responsible for a specific task. Once the task is complete, the workflow software ensures that the individuals responsible for the next task are notified and receive the data they need to execute their stage of the process. Workflow management systems also automate redundant tasks and ensure uncompleted tasks are followed up. Workflow management systems may control automated processes in addition to replacing paper work order transfers.

5.2. PILOTS COMPUTATIONAL VIEW

5.2.1. WILD SALMON MONITORING

The Irish Pilot Salmon CL portal integrates inputs from many sources, as listed in section 4.9.2. The portal is being implemented at www.habitats.ie using GeoNetwork36 for the metadata definition and maintenance, and GeoServer37 to expose the various data. Using the HABATATS metadata (defined in D3.2.1) this data is being made Discoverable and Viewable as Catalogues on the Irish Spatial Data Exchange (ISDE) and HABITATS RL Portal to demonstrate and validate its “INSPIRE Compliance” and use in the WP5 pilot validation.

The Salmon CL portal will also contain various Salmon Angling services and applications that are constructed from the various data sources in response to users’ requests and suggestions, and will be constantly evolved throughout the WP5 Validation Pilots.

Thus the pilot will implement the following services:

• The data management

• The metadata management

• Catalogue service platform

• The HABITATS metadata profile is being applied.

• View, share and download services will be in the geoportal

• Next step expected is to develop smatphones apps

5.2.2. LA PALMA PROTECTED MARINE ARE

In this pilot we obtain data from a sensor system and from a sensor connector we store these data in a database. This first database is a SQL DBMS in the form of tables and the relationship among the data is also stored in tables.

From these tables, we get the representative geodata in shapefile format. The platform to publish these data is composed by Geoserver, Geonetwork with PostgreSQL. This platform works with WMS, WFS, WCS and CSW standards and allows View and Discovery services. Also we get Authetication service and from this we could manage groups, roles and users with different levels of permission, it allows a profiling and open the door to Download an Metadata Editor services.

35 http://en.wikipedia.org/wiki/Workflow 36 http://geonetwork-opensource.org 37 http://geoserver.org/display/GEOS/Welcome




95

5.2.3. AUGMENTED REALITY - NATURAL RESERVE

We have harvested the representative geodata in shapefile format, mainly interesting points. The platform to publish these data is composed by Geoserver, Geonetwork with PostgreSQL. This platform works with WMS, WFS, WCS and CSW standards and allows a Discovery service. Also we get Authetication service and from this we could manage groups, roles and users with different levels of permission, it allows a profiling. It opens the possibilities to Download, Metadata Editor, and View services. The last case could be oriented to different users.

The View service must be process through our Augmented Reality software to be displayed in the AR devices and mobile phones. From these platforms we could work to implement the Web 2.0 for the users.


The platform will be use:

- Data management

- WMS,

- WFS,

- CSW services

- WPS

- Download services


In pilot are collected all Latvia Institute of Aquatic Ecology maintained data and datasets. Historically data are collected and maintained in ESRI Shapefiles, Microsoft XLS and CSV files. These data has been normalized, created data models and imported in SQL relation database management system with spatial data support. Using in database created data model and stored data in the platform is possible to create and manage as OGC WMS, WFS, WPS, WCS services and manage access and publishing options. Since data are not maintained in INSPIRE equivalent or extended data model will be provided INSPIRE compliant WFS view on data. Meta-data system are stored information about datadatasets and services, meta-data system is able to read WMS, WFS and WCS service meta-data information.


FMI currently we can offer:

- Datasets for Habitats reference laboratory

- WMS service

- Validated metadata (available both in English and Czech language)

We are trying to update our data models to be suitable for new technologies. Nowadays our stakeholders are using our geoportal (http://geoportal2.uhul.cz/wms_oprl?SERVICE=WMS) with only WMS service and not quite so interoperable client, which has serious problems across different browsers. Geoportal client side uses modified Openlayers and on the server side is working UMN mapserver.

We have tested software architectures with Geonetwork/Geoserver and Geohosting/Micka and both are more or less suitable for our purposes. The FMI uses LDAP authentication protocol for all Microsoft and Unix desktop clients, therefore administrative part of the geoportal should have the same login backend.

The conclusions about The Forest site classification data for sustainable management and utilization of forest road network:




96

- • Platform used - UMN Minnesota, Openlayers and Micka

- • Validated metadata (available both in English and Czech language)

- WMS, WFS, CSW services

- Download services




97

6. ENGINEERING VIEWPOINT- DISTRIBUTION OF INFRASTRUCTURE

The engineering viewpoint focuses on the mechanisms and functions required to support distributed interactions among objects in the system. It describes the distribution of processing performed by the system to manage the information and provide the functionalities. This section defines the HABITATS Logical 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 an 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 WebServices and SOAP technology.

6.1. RELATION OF PILOT IMPLEMENTATION AND REFERENCE LABORATORY

The reference laboratory will have next roles in project!

• To offer possibility for testing new services

• To offer access to global data for pilots

• To support implementation of cross pilot scenarios

• To making discoverable Habitats services for external platforms

The objective of RL is implement such functions, which will guarantee this functions. Interlinkage of RL with pilots will be based on next schemes.

\

Pilot implementation will implement only functionality required by pilot user needs, Reference Laboratory will implement full functionality.




98

6.2. DESIGN FOR REFERENCE LABORATORY

In reference to the Computational Viewpoint (described above), which proposes a view of the system as a set of functional components (or blocks) that communicate through defined interfaces, the system is configured as an architecture made of levels or functional layers:

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

• Server (engine layer) – define 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 application level as part of Web presentation

The basic scheme is on next picture




99




100

7. TECHNOLOGY VIEWPOINT – INFRASTRUCTURE MAPPING

The Technology Viewpoint describes the technological specifications for the physical deployment of the system implementation. In particular, it focuses on:

• the choice of technology in the system;

• how specifications are implemented;

• specification of relevant technologies;

• support for testing.

The Technology Viewpoint will be analysed deeply in D4.2.2. The current version only gives only some ideas for implementation of some components of architecture. This list is not complete and will be updated during the second phase of design.

7.1. EXAMPLES OF POSSIBLE COMPONENTS FOR IMPLEMENTATION

RDBMS

• PostgreSQL

• Oracle

• Microsoft SQL

• MySQL

SENSOR CONNECTOR

• CCSS daemon

WEB MAP SERVER

• MapServer

• Geoserver

• ArcGIS

• GeoMedia WebMap

• Topol Internet Server

METADATA SERVER

• MIcKA

• GeoNetwork

• Conterra

• Degree

WPS

• PyWPS

• Nord52

• ZOO




101

SENSORS SERVER

• North 52

• Maplog

GEOGRAPHICAL EXTENSIONS FOR RBDSM

- PostGIS

- SDO

- ArcSDE

- Jaspa

WEB BASED GIS ANALYTICAL TOOLS

GRASS with any WPS extension

R or any other custom analyses and processing tool with pyWPS

DISCOVERY

- MIcKA catalogue

VIEW

- Open layers

- HSlayers

- Mapfish

- Mapbender

- pMapper

DATA SERVICES

- Geohosting

- Geoserver

TRANSFORMATION

- Hale

- Topol

- ArcGIS

- GeoKettle

- Spatial data integrator

VIRTUAL MODELLING

- GoogleEarth

- NASA Wind

CMS

- Liferay

- SimpleCMS




102

- WordPress

- Joomla

- Drupal

SOCIAL NETWORKS AND MEDIA

- MediaWiki

WORKFLOW MANAGEMENT

- Liferay

- Taverna Workbench

- Apache Orchestra

- 52n Workflow modeller (it is more modeller than manager, but is able to work with native WPS services)

7.2. REFERENCE LABORATORY IMPLEMENTATION

For reference laboratory the design was dan on the base of next scheme

The Reference Laboratory architecture provides functionality through modular, re-usable and interoperable application services. Each modular service have to have a clear, standards-based interfaces so that the services underlying technology, which could be replaced if or when the current base-technology is upgraded to a new version - or when a competitors technology platform emerges




103

takes over as technology leader. As a consequence, the architecture is extensible, especially in terms of plug-ins for additional, non-standard or "modified standard" protocols. which have been applied on national or regional level. The modular architecture secures that any third party is free to create his or her own extension points to the core architecture.

The data layer consists of two parts:

a) A registry of web service end-points for standard, interoperable spatial data access services like WMS, WFS, WCS and CSW accessible over TCP/IP on the Internet and; b) A data store implementing storage for remotely retrieved cached data, locally stored base maps, indexes and lookup data such as a geographical names gazeteer, administrative division and addresses.

• A Map Server Module which will consist of the two leading open source map servers: MapServer and GeoServer. The reason for including two different servers at this stage is to enable easy switching between the two and to secure that the solution is not locked into one specific product. All communication with the map server will go via standards based interfaces.

• A Catalog Module which is based on Micka (HSRS professional edition catalogue

service application) will serve the purpose of OGC-compliant CS-W server and will provide functionality for both external catalog web services as well as be the foundation for the Catalog Viewer. This product is chosen over its two principal alternatives Geonetwork and Degree as it is an older and more mature product which has supported the CS-W specification much longer than the other two and hence has rooted out many issues which will be found in less mature code bases. Also here, all communication will be performed via standard interfaces. For this reason, any of the three catalog software products mentioned may be substituted for each other pending the Client's request, it is however our assessment that the proposed product will provide best performance and robustness.

• A CMS Module provides content management functionality for the Geoportal including the ability to write and publish articles according to an editorial workflow, publish and syndicate content using HTML and XML-based protocols like WWW, (Geo)RSS/ATOM etc. For this purpose we provide the open source product Simple CMS as it is scaled to suit the specific purpose without adding the overhead of complicated systems targeted at running online newspaper sites.

• A Thesauri Module which will inherit functionality from the Thesauri Service offered by EEA GEMET API, extending this component to support upload, management and dissemination of any SKOS-based thesauri/vocabulary - including mapping between different vocabularies using skos:mapping attributes. This component will be re-usable within several domains and may play a key role in the infrastructure required for content harmonization of INSPIRE data themes in scenarios where not only field-mapping from schema to schema is required but also harmonization of content values between classification systems of varying granularity.

The Client layer offers three different types of end-user interfaces which will be available to human and machine end-users over the Internet. Access to any or all of these may be controlled by flexible authentication mechanisms as described in the proposal. The services are:




104

• The Geoportal client interface offers end-users access to Portal Content as created in

the underlying CMS, a sophisticated Map Viewer, a Catalogue Viewer enabling directory and search access to the overall INSPIRE metadata holdings as well as a Thesauri Viewer which will enable search and lookup functionality for GEMET (and other SKOS-based thesauri as required by the Client).

• The Administration Console interface provides Geoportal administrators and privileged users with tools required to add and manage resources to the Registry including look-up tables, SLD definitions etc. Furthermore, the console allows administration of the Map Viewer and Catalog Viewer including content, access control, display and formatting.

• The Web Services interface provides standards based OWS and Linked Data web services which may be consumed by applications in the Users and external platforms layer. One of the most important functions of the INSPIRE Geoportal will likely be to serve as a look-up web service for 3rd party applications to connect to data layers from the INSPIRE domain.

Management of distributed spatial data sources is one is the key requirements on current Geospatial portals. Current principles of SDI building required such systems that would facilitate spatial data management and publication. Main requirements are

• the ability of fast access to up-to-date information,

• searching and classification of information,

• possibility of their use in other systems/subsystems and also their publication.

• Connect in situ sensors measurement

These functions related to searching and accessibility of spatial data are relatively common in different client applications, but the possibility of publication and sharing of spatial data by users is till now problematic remains. Users data could be used in a number of web applications, but there are missing tools supporting users to make geodata accessible in the form of web services. For users is problem to making their data publicly accessible.

The system has to guarantee possibilities publishing of spatial and non spatial data. Data Management has to include four main modules:

• Non spatial data and metadata publishing

• Spatial Data module for importing spatial data on the

• Maps and maps services publishing module for creating and publication of map

• Module for creating projects for mobile editing of data in situ

The module for Data Management has to be designed for making users data accessible on the Internet, creating new map compositions by combining various data sources (users’ sources or external ones) and their publication on the web, possibly also for other work with data saved on the server.

Data for creating a new map composition has to be integrated from the following sources:

• A WMS server with a known address

• A WFS server with a known address

• A WMS or WFS server found by an integrated catalogue service

• The File Repository of the portal




105

• The Geodatabase of the portal

• A geodatabase connected through ODBC

Projects of new map compositions have to be defined by XML files. Till now there is no standard form supporting such compositions storing. For example Web Map context support only composition from WMS. The data and their composition has to be accessible by several ways:

• Using different visualization clients for example Openlayers, Googlemaps, DHTML clients etc.

• By a desktop map browser

• Through the OGC Web Map Service (WMS)

• Through the OGC Web Feature Service (WFS)

• Used by other analytical tools trough Web Processing Services (WPS)

For the integration of Sensor environment with other data there is necessary to support next functionality:

• Describe sensors in a standardized way

• Standardize the access to observed data

• Standardize the process of what is commonly known as sensor planning,

• Building a framework and encoding for measurements and observations

• Some sensors are already on the Web and able to return their location information as well as observations and measurements.

The integration has to be based on Open Geospatial Consortium standard framework Sensor Web Enablement (SWE) ,

There are reused some common well known software like Mapserver or Geoserver, OpenLayers, Ext. Other components are own development of contractors (Micka, HSlayers, SimpleCMS, MapMan, Authorisation module). Some components are already published as Open Source under GPL licence. Metadata catalogue server and client Micka are now prepared to be published as Open Source under GPL licence.

The main requirements for the Geo-portal are:

• Demand for multi-lingual content (dynamic and static) - Translation of application captions and language-specific design elements should be done on application level preferably using gettext. This will secure a flexible expansion to new languages using one master-language as a spine.

• Choose and store user preferred language - When the user will be providing first login (or first visit) to the geo-portal, the default language will be detected by GeoIP mechanisms. Should this prove to be provide the wrong language by default, the user preferred language will be saved for future visits based on a stored user profile and/or client-cookies.




106

As basic tools will be established monitoring based on logins of users. A full log analysis will enable to show you the following information:

• Number of visits, and number of unique visitors, • Visits duration and last visits, • Authenticated users, and last authenticated visits, • Days of week and rush hours (pages, hits, KB for each hour and day of week), • Domains/countries of hosts visitors (pages, hits, KB, 269 domains/countries detected,

GeoIp detection), • Hosts list, last visits and unresolved IP addresses list, • Most viewed, entry and exit pages, • Files type, • Web compression statistics (for mod_gzip or mod_deflate), • OS used (pages, hits, KB for each OS, 35 OS detected), • Browsers used (pages, hits, KB for each browser, each version , • Visits of robots , • Worms attacks • Search engines, key phrases and keywords used to find your site, • HTTP errors (Page Not Found with last referrer, ...), • Other personalized reports based on url, url parameters, referrer field for

miscellaneous/marketing purpose, • Number of times your site is "added to favourites bookmarks". • Screen size (need to add some HTML tags in index page). • Ratio of Browsers with support of: Java, Flash, RealG2 reader, Quicktime reader,

WMA reader, PDF reader (need to add some HTML tags in index page)

To speed-up access to data some type of caching should be provided on central portal. Proposal:

• cache tiles of harmonized view services of member states

• cache only small and middle scale data, more detailed data should be provided directly from MS

• cache tiles in one European projection (LAEA ) - more available, but consume capacity of repository

• Querying (GetFeatureInfo) should be processed to original services

• mechanism must distinguish extent of original service to provide request only to corresponding ones not to all

• inter-state boundaries will be processed to enable seamless look and feel

• metadata records will be periodically queried for detecting changes (date of update) in original data to perform updating of tiles

In future central vector database should be maintained to give unique access to download and views services (should be generated from here)




107

• again based on metadata detection of changes

• using download services to central repository

• generate view + download services (WMS / WFS), tiles etc.

Gazetteer will be based on Open StreetMap as well as other INSPIRE themes. Hierarchy structure is supposed to be used. But there is no this kind of service at the moment. Some

With the Semantic Web currently proving itself as a key delivery channel for content, the importance of multi-lingual thesauri for creating relationships between "atomic" information resources is increasingly important. Beyond the GEMET thesauri, there is also a wide array vocabularies, classification systems and thesauri used on national and even regional level. The publishing of common thesauri with global URIs as Linked Data will enable efficient re-use of this system for classification of pan-European metadata.

Thesaurus REST service is provided by EEA. ZOPE/Python. The software is available as OS and may be used as is without problems on INSPIRE portal servers. So the service may be used directly from EEA and/or from local servers to increase the performance. For the INSPIRE Geoportal will be installed GEMET directly as part of registries Some kind of replication shall be used.

New thesauri may be defined in GEMET underlying database. SO it is open for introducing new thesauri in the future according to INSPRIE/MS needs.

• ExtJS Based already existing Open Source GEMET client will be used to provide access to thesaurus service - for more sophisticated Thesaurus browsing

• input fields with suggestions will be available in the metadata search form too.

MapViewer is based on known Open Source libraries OpenLayers and Sencha (formerly ExtJS) and HSLayers. Display, navigate, zoom in/out, pan or overlay spatial data sets or layers, transparency




108

control, print and display legend information and any relevant content of metadata are part of functionality. System also allows play legends of each map layer.

User can choose, which format he/she prefers the data to be displayed in, while adding new WMS layer to exiting map composition. Display legends of each map layer. It is part of HSLayers,

Supported coordinate systems are:

• ETRS89 EPSG:4258

• ETRS-LAEA EPSG:3035

• ETRS-LCC EPSG:3034

• ETRS-TM26 to ETRS-TM39 EPSG:3039 to EPSG:3051

• ETRS89/(X,Y,Z)

• ETRS89 ellipsoidal heights

• World Geodetic System 1984 EPSG:4326

• Thematic and parametric CRSs covering e.g. Meteorology or Oceanography (see ISO19111-2)

• Universal Polar Stereographic (UPS) (used in Meteorology)

User can choose with special tool, in which coordinate system he/she wants to work. The map is redrawn on-the-fly.

The Map Project Manager is a software tool for users who want to create new map projects and compositions. User can use the tool for displaying of different GIS data in the Internet environment. MapMan is capable of creating various map compositions and users can use different data sources – data on the local server, but also the data available through web services, which are saved on an external server. User can define coordinate system and data sources available through web services – Web Map Services (WMS), Web Features Services (WFS), Metadata Catalogue or data stored on internal data server in geo-database or files. The data can be in both raster and vector forms, for vector objects the new definition of their colour and symbol is possible. Search component connect metadata catalogue to user be able better find special data sets. MapMan can be closely linked to different map visualization clients – DHTML or JAVA clients, Google Maps, Google Earth and others. New map composition should be published as independent Web Service (WMS, WFS).

• Coordination System – any coordinate reference system defined in EPSG database

• Map extend – area of interest defined in local coordinate reference system

• List of data layers - raster or vector data from different data sources

• Sources for vector data

o Files – ESRI shapefile (SHP), GML, DGN, the formats supported by OGR library (http://www.gdal.org/ogr)




109

o Server sources – ESRI ArcSDE, OGC WFS, PostGIS (PostgreSQL), Oracle Spatial Database

• Sources for raster data

o Files – TIFF, GeoTIFF, JPEG, the formats supported by GDAL library (http://www.gdal.org)

o Server sources – ESRI ArcSDE Raster, OGC WMS, OGC WCS

Definition of visualisation is provided by SLD (Styled Layer Descriptor). Each data layer may have its own definition of visualization using:

• user interactive definition in the application (embedded SLD Editor)

• loading of existing visualization style from the user storage accessible from the application

• loading of existing SLD definition from XML

• loading of existing SLD definition through URL

The visualization loaded from external sources (XML, URL) may be updated interactive way in the application. User can export the final definition:

• into file with SLD definition

• into user storage with defined access permission

If the layers of the project have got definition of visualization it is possible to display them in the map viewer. Portal map viewer is based on HSLayers library (extended OpenLayers) and supports all current important technologies (Web 2.0, OGC Web Services, etc.)

• Publication of the map project as WMS – the functionality gives a possibility to create new WMS sources composed from different data sources. These new WMS has standardized metadata record (INSPIRE) stored in metadata catalogue Micka

• Publication of the project as WFS – map project with vector data can be published also as WFS. This functionality gives a possibility to create new WFS sources composed from different data sources. These new WFS has standardized metadata record (INSPIRE) stored in metadata catalogue Micka




110

Content management system should be focused on usability and simplicity for end users on its mind. It should be prefered CMS which will be tailored to be used with Geoportal. Development should be focused on using frameworks. Proper using of this frameworks guarantees security on application side. There should be integrated WYSIWYG for this purpose. This editor will simplify content creation for end users.Editor should allow inserting various multimedia content user can think of, videos, photos, etc. This media can be inserted directly into text or as attachments under created content (e.g. article). The CMS should support including any RSS feeds from remote sites. This functionally allows gathering all requested information into one place. Content should be also exported as RSS. This should allow exporting per menu or more specific. Content should be also exported in raw code (HTML) to another web site which will allow dynamic integration.

MIcKa is a complex solution for metadata management (not only Metadata editor) and for Spatial Data Infrastructure (SDI) and geoportal building. It contains tools for editing and management of metadata for spatial information, web services and other sources (documents, web sites, etc.). It includes their search on the Internet, portrayal in map or download to local computer. MIcKA is compatible with obligatory standards for European SDI building (INSPIRE). Therefore it is ready to be connected with other nodes of prepared network of metadata catalogues (its compatibility with pilot European geoportal is continuously tested). Functions:

• Spatial data metadata (ISO 19115) • Spatial services metadata (ISO 19119) • Dublin Core metadata (ISO 15836) • Feature catalogue support (ISO 19110) • OGC CSW 2.0.2 support (catalogue service) • User defined metadata profiles




111

• INSPIRE metadata profile • Web interface for metadata editing • Multilingual (both user interface and metadata records). Currently 16 languages

supported. It is possible to dynamically extend the system for other languages. • Context help (multilingual) • Import from the following metadata formats are supported:

o ESRI ArcCatalog, o ISO 19139, o OGC services (WMS, WFS, WCS, CSW) o Feature catalogue XML

• Export – ISO 19139, GeoRSS • Support of thesauri and gazetteers. • Display of changes with GeoRSS • Template base interface with possibilities to change according to user requirements • Possibility of deep cooperation with any of map clients for display of on-line map

services. Support of the INSPIRE:

• INSPIRE metadata profile is included • selecting keywords from GEMET thesaurus • selecting keywords from code list of INSPIRE services • Continuous checking of metadata completeness according to the INSPIRE profile • Batch checking of completeness of INSPIRE profile • Implementation of catalogue service according to OGC CSW 2.0.2 / AP ISO 1.0

Catalogue service is an integral part of the system. It is based on OpenGIS® Catalogue Services Specification – profile Catalogue Service for Web (CSW) and OpenGIS® Catalogue Services Specification 2.0.2 - ISO Metadata Application Profile standards.

1. Supported operations: 2. Basic: GetCapabilities, DescribeRecord, GetRecords, GetRecordById 3. Editing: (CSW-T): Transaction, Harvest 4. Queryable elements: according to used standards (OGC, INSPIRE). May be extended

according to user needs 5. Extensions:

o OpenSearch standard is implemented. These formats are supported: � GeoRSS, RDF, HTML, KML � Web browsers integration is enabled

o OAI-PMH harvesting support

7.3. PILOTS ARCHITECTURE

7.3.1. WILD SALMON MONITORING

The Irish Pilot Salmon CL follows all of the primary components of the HABITATS SOA architecture based on the publish-find-bind paradigm.




112

The portal is implemented using GeoNetwork38 and GeoServer39, and includes data and services from many sources including the SSC regulations for 2011 on limits in specific rivers, fishing information and wider regulations, the Irish Spatial Data Exchange, IFI Salmon Monitoring Programme, WFD water quality monitoring, Wild Salmon census data from the Marine Institute and scientific wild salmon conservation data (see section 4.9.2).

The Salmon CL portal will also contain various Salmon Angling Services and Applications that are constructed from the various data sources such as

• Salmon Angling current Information. • Where are the local Salmon biting. • When Can I fish. • Fishing License • Catch recording (on a map) • Feedback (as a tourist Angler). • Etc

These are being developed in response to users’ requests and suggestions using Microsoft Silverlight40 in a Visual Studio IDE41, and will be constantly evolved throughout the WP5 Validation Pilots. In addition the Salmon CL Portal data layers will be exposed through GeoServer to be merged into the IFI ArcGIS Interactive Map Viewer42.

7.3.2. LA PALMA PROTECTED MARINE AREA

The architecture design is according following scheme

38 http://geonetwork-opensource.org 39 http://geoserver.org/display/GEOS/Welcome 40 www.microsoft.com/silverlight/ 41 www.microsoft.com/visualstudio/en-us 42 At www.fisheriesireland.ie/Projects/interactive-gis-map.html




113

The first implementation based on selected infrastructure will be described in D4.3.1 HABITATS Networking Services and D-5.2.1, D-5.3.1, D-5.4.1 Pilot Platform Integration, Execution & Interim Evaluation Report




114

7.3.3. NATURAL RESERVE The architecture design is according following scheme





115


The architecture design is according following scheme





116


he architecture design is according following scheme



Simple scheme for the First use case - "Forest site classification data for sustainable management and utilization of forest road network" is displayed bellow:




117

FMI has a long experience with MapServer




118





119

8. CONCLUSION

This document is based on first Architecture design. Second release was prepared on the base of discussion with all pilots. The document contain as generic model, but also suggestion for implementation of pilot applications, and reference laboratory. The document is used as input for D4.3 and WP5. Where all architecture design will be validate. Transformation services will be developed under D-3.4 HABITATS Transformation Service




120

9. REFERENCES

• D-3.2a Metadata profile, CIP- ICT-PSP-2009-3-250455, Social Validation of INSPIRE Annex III Data Structures in EU Habitats

• D-3.3a HABITATS Data models, CIP-ICT-PSP-2009-3-2504553-250455, Social Validation of INSPIRE Annex III Data Structures in EU Habitats

• Wikipedia File system, http://en.wikipedia.org/wiki/File_system

• Wikipedia Relational database management system, http://en.wikipedia.org/wiki/Relational_database_management_system

• Wikipedia Relational database, http://en.wikipedia.org/wiki/Relational_database,

• WIKIPEDIA, SQL http://en.wikipedia.org/wiki/Structured_Query_Language, • http://java.sun.com/applets/

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

• http://en.wikipedia.org/wiki/RSS

• http://en.wikipedia.org/wiki/GeoRSS

• http://en.wikipedia.org/wiki/Keyhole_Markup_Language • http://www.w3.org/TR/html4/present/frames.html

• http://en.wikipedia.org/wiki/Span_and_div

• http://en.wikipedia.org/wiki/Augmented_reality

• http://en.wikipedia.org/wiki/Content_management_system

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

• http://en.wikipedia.org/wiki/Web_Coverage_Service

• http://en.wikipedia.org/wiki/Web_Feature_Service

• http://en.wikipedia.org/wiki/Web_Map_Service

• IEEE (1998), Std 830-1998 IEEE Recommended Practice for Software Requirements

Specifications – Description

• IEEE (2000), Std 1471-2000 IEEE Recommended Practice for Architectural Description of

Software-Intensive Systems – Description • INSPIRE Network Services Drafting Team (2007), D3.5 – INSPIRE Network Services

Architecture v2.0 • ISO (1998), ISO/IEC 10746-1 Information technology – Open Distributed Processing –

Reference model: Overview

• ISO (1996), ISO/IEC 10746-3 Information technology – Open Distributed Processing –

Reference Model: Architecture • ISO (2002), ISO 19101: Geographic information – Reference model

• ISO (2005), ISO 19109: Geographic information – Rules for application schema

• ISO (2005), ISO 19110: Geographic information – Methodology for feature cataloguing

• ISO (2003), ISO 19115: Geographic information – Metadata

• ISO (2005), ISO 19119: Geographic information – Services

• ISO/IEC JTC (2008), Information technology – Open distributed processing – Use of UML for

ODP system specifications

• JRC (2009), SOAP Primer for INSPIRE Discovery and View Services

• Open Geospatial Consortium Inc. (2004), Geospatial Portal Reference Architecture - A

Community Guide to Implementing Standards-Based Geospatial Portals

• Open Geospatial Consortium Inc. (2008), OGC Reference Model

• Open Geospatial Consortium Inc. (2004), OGC Web Map Service Interface




121

• Open Geospatial Consortium Inc. (2007), OpenGIS Catalogue Services Specification • Open Geospatial Consortium Inc. (2007), OpenGIS Web Processing Service

• Open Geospatial Consortium Inc. (2005), Web Feature Service Implementation Specification

• Percivall G. (2002), ISO 19119 and OGC Service Architecture¸ FIG XXII International

Congress, Washington, D.C., USA • Plan4all (2009), D2.1 – Cluster of Leading Organisations in SDI for Spatial Planning

• Plan4all (2009), D2.2 – Analysis of Innovative Challenges

• Plan4all (2009), D2.3 – INSPIRE Requirement Analysis

• Plan4all (2009), D2.4 – User Analysis Report

• Plan4all (2010), D3.1 – Analysis of National Requirements on Spatial Planning Metadata

• Plan4all (2010), D3.2.1 – European Spatial Planning Metadata Profile (First version)

• Plan4all (2010), D4.1 – Analysis of Conceptual Data Models for Selected Schemes Used in

Single Countries

• Plan4all (2010), D5.1 – Analysis of Demand on European Spatial Planning Data Sharing

• Plan4all (2010]) D5.2 – Plan4all Networking Architecture

• United Nations (),United Nations Spatial Data Infrastructure Compendium (A UNSDI Vision,

Implementation Strategy and Reference Architecture)

• W3C (2001), Web Services Description Language (WSDL) 1.1

• W3C Working Group (2004), Web Services Architecture