Humboldt Annual Report 2007 - Overview – HUMBOLDT Project · 2010-06-21 · HUMBOLDT Annual...

A N N U A L R E P O R T 2 0 0 7

HUMBOLDT Annual Report 2007

3/28

Editor

HUMBOLDT Executive Board

Fraunhoferstrasse 5

D-64283 Darmstadt

Germany

Design, Layout and Typography

HUMBOLDT Project Office

co zeitform Internet Dienste OHG

Fraunhoferstrasse 5

D-64283 Darmstadt

Germany


4/28


5/28

Table of Contents

1. Introduction 7

Project outline 7

Introducing Humboldt 9

2. Activities and Results Achieved 10

General Activities 10

Scientific results 11

Technical Results 14

3. How to use HUMBOLDT 19

Scenario: Urban Planning 19

Scenario: Border Security 23

4. What is HUMBOLDT 26

Presentation of consortium and „Friends“ (Users@HUMBOLD ) 26

HUMBOLDT Consortium 27


6/28


7/28

Introduction

On the First of October 2006 the HUMBOLDT pro-

ject started. Since then the project has focussed on

the creation and testing of IT solutions to support

the harmonisation of spatial data to be used

within Spatial Data Infrastructures (SDIs). In HUM-

BOLDT harmonisation is understood as a process

of transforming the available data (SDIs of the

first generation) into data, which can be used in

various applications and information products

(SDIs of the upcoming second generation).

The project is funded by the GMES (Global Monitor-

ing for Environment and Security) programme and

aims at supporting the realisation of the European

Directive INSPIRE in GMES-related applications. But

HUMBOLDT is not limited to the goals of INSPIRE.

Furthermore, the project follows the goal of provid-

ing solutions that simplify the use of spatial data

almost where ver required. Following the inspiration

of Alexander von Humboldt, the project’s philoso-

phy is:

REUSE the existing, EXTEND by need, ARRIVE

at the ESDI and PROSPER by applications.

The project’s name was inspired by the work of

Alexander v. Humboldt whose primary aim was to

integrate the knowledge of his time to gain new

insights and to advance all areas of science. Follow-

ing the same path, it is the aim of the HUMBOLDT

project to build on the existing know-how within

and outside the GI community, and to manage and

advance the implementation process of a European

Spatial Data Infrastructure. This integrated network

of systems providing data and services will allow

the sustained use of existing services as well as the

development of new applications and business

models. The availability of data is – despite ongoing

efforts – still highly fragmented and heterogeneous.

Harmonisation can contribute to the creation of

new knowledge by combining data that previously

could not be integrated - or only with prohibitively

high cost. Furthermore, entirely new processes that

replace existing complicated activities and have a

higher efficiency can be developed on the basis of

the proposed system.

This document briefly summarises the main activities

carried out by HUMBOLDT during the first year of

the project and the possibilities for stakeholders

outside the project to engage with the project. Fur-

ther information can be found at the project’s web-

site http://www.esdi-humboldt.eu.

Project outline

High-quality and easily accessible geoinformation

can deliver enormous value to different fields of

application in politics, government, research and

business. Implementing Spatial Data Infrastructures

tries to open the potentials resulting from this situa-


8/28

tion. Accordingly legal, organisational and technical

aspects have to be combined to successfully imple-

ment an SDI. HUMBOLDT, as a research project,

focuses on a well-defined subset of these require-

ments, which will be conceptualised and evaluated

during the project period. The selected subset cov-

ers the harmonisation processes necessary to inte-

grate geodata acquired for one particular use into

several fields of application.

What harmonisation stands for in HUMBOLDT

and why is it important?

In HUMBOLDT harmonisation is understood as a

process transforming existing geodata into a

dataset that can easily be included in the use proc-

esses at the data-requiring organisation. Therefore

not only the format of the exchanged dataset has

to be well-defined, but also the conceptual model

describing the real word in the computer system

has to be common, to maximise the value of the

exchanged data. This goal can of course be

reached by organisational approaches defining one

(or several) common data model(s) which cover

every imaginable situation. But this approach will

not only be hard to agree but it also reduces flexi-

bility and limits the ability to handle specific situa-

tions with a reasonable amount of effort.

Knowing this, HUMBOLDT recognises the need to

retain flexibility and existing data models (including

the tools already working with them). So the HUM-

BOLDT approach defines harmonisation as a proc-

ess that data has to undergo whenever it is in-

tended to be used in a context other than the one

for which it was acquired. Several aspects of this

harmonisation process, for example identifying se-

mantic similarities (e.g. “house” equals “building”),

can only be handled by humans. Other aspects can

be carried out automatically as soon as knowledge

about the data models (both source and target)

and the relations between them is available. HUM-

BOLDT mainly supports the elements of the har-

monisation process that can be carried out auto-

matically or semi-automatically. Therefore the

HUMBOLDT framework delivers the necessary tool

set to describe the data model(s), to specify map-

ping at the level of the data models and to transfer

the data itself. The flexibility of the HUMBOLDT

framework will allow the integration of the HUM-

BOLDT based solution into several SDI architectures,

to support, for example, both offline and online

harmonisation processes.

By following this idea and by bringing together rele-

vant concepts and developments in an easy-to-

handle HUMBOLDT framework, the project aims at

a broader use of geodata by overcoming the hur-

dles between the different domains and supporting

the reuse of data without further processing. To

ensure this, developments are driven by several

application scenarios within HUMBOLDT. The sce-

narios have been collected to cover a broad range

of potential geodata applications in the GMES con-

text. Therefore, the scenarios cover different do-

mains and actors, different scales, different lan-

guages, different cultures, and more. Of course the

project is not limited to the current number of sce-

narios and aims to extend the scenario applications

in cooperation with other initiatives.


9/28

Introducing Humboldt

Natural phenomena are inherently international and do not respect national borders. The necessary political

decisions and challenges resulting from natural disasters or concerning the protection of conservation areas are,

consequently, also transboundary concerns. The spatial data required for this in Europe, however, show an

extensive heterogeneity.

HUMBOLDT will provide a framework for geo data

harmonisation and service integration. Commencing

in October 2006 it aims to facilitate cross-national

harmonisation of spatial data. Under the coordina-

tion of Fraunhofer IGD 27 partners from 14 Euro-

pean countries are working on the four-year EU

project with a total value of 13.5 million EURO.

HUMBOLDT contributes to the implementation of a

European Spatial Data Infrastructure (ESDI) that

integrates the diversity of spatial data available from

the multitude of European organisations. It is the

aim of the project to manage and advance important

parts of the implementation process of this ESDI.

The main goal of HUMBOLDT is to enable organisa-

tions to document, publish and harmonise their geo-

spatial data. The software tools and processes cre-

ated in HUMBOLDT will also help to demonstrate the

feasibility and advantages of an Infrastructure for

Spatial Information in Europe as postulated by the

INSPIRE directive. The intended goal is to facilitate

geo data and metadata management to support

European and member states’ policy needs by meet-

ing the requirements of the Global Monitoring for

Environment and Security (GMES) initiative.

The HUMBOLDT project aims to facilitate the har-

monisation of spatial data and metadata by auto-

mating the necessary processes as far as possible.

The project commenced with a comprehensive state

of the art analysis on related themes. The methods

and tools for geo data and metadata management

were investigated and evaluated. Suitable software

architectures were described and basic user re-

quirements documented. On this basis HUMBOLDT

will undertake a process analysis, which will show

the steps necessary to harmonise data and meta-

data. Finally, a software framework and diverse

tools will be developed and integrated into the ESDI

to support spatial data and service providers in of-

fering standardized spatial information. An essential

element of the project is the development of scenar-

ios in which the different components are applied

and tested under realistic conditions.

HUMBOLDT results may also support applications in

disaster management: when facing natural disas-

ters, such as the Elbe floods in 2002 and 2006,

European countries typically need to exchange in-

formation on spatial data with each other. Often

several countries are affected at the same time, for

rivers and weather effects do not respect national

boundaries. However, the spatial data necessary for

the prevention and protection of natural disasters is

provided in different formats and systems in the

different countries. As a result, today cross-national

cooperation in support of more effective monitoring

and planning is at best difficult, and frequently im-

possible without the HUMBOLDT results.

Humboldt is embedded in the scope of GMES and

several other projects deal with other ESDI-relevant

aspects. Therefore, cooperation has been initiated

with other projects in order to ensure information

exchange and the re-use of expertise, of which both

sides can profit.


10/28

Activities and Results Achieved

Main activities during the first year of the project were the implementation of an environment

necessary to successfully carry out projects of the size of HUMBOLDT. This project environment cov-

ers decision and management structures, the establishment of relationships to other projects and

initiatives relevant for HUMBOLDT, dissemination strategies and materials, and ways of communica-

tion to experts and others in related fields.

General Activities

Due to the amount and heterogeneity of the part-

ners’ contribution to the HUMBOLDT project, special

attention has been paid to lever knowledge across

the partner structures to avoid misunderstandings,

and to ensure efficient cooperation between the

partners without loss of information. Therefore train-

ing for consortium members and others external to

the project have taken place. To ensure a fruitful

interaction with other actors in the field of SDI de-

velopment, HUMBOLDT has made substiantial efforts

to ensure a broad visibility of HUMBOLDT within the

GI community. In addition to several presentations at

national and international events, publications in

scientific and non-scientific journals, press releases,

newsletters and on the website, HUMBOLDT has

established contacts and an exchange of information

with other projects such as BOSS4GMES, CASCA-

DOSS, eSDI-Net+, RISE, MOTIIVE and other projects.

Following the ideas of Alexander von Humboldt, the

initial phase of the project has been used to look

carefully into available technologies and concepts

both from within the GI environment and from other

fields. Furthermore the definition of potential HUM-

BOLDT users has been developed and the require-

ments resulting from this group have been selected.

To create this overview of user needs, both the

HUMBOLDT scenarios and public consultation have

been used. Based on these overviews the important

tool sets for HUMBOLDT have been identified and


11/28

used to develop the concept of the technical proto-

type and the first version of the HUMBOLDT frame-

work. All the outcomes have been bundled into

documents and other results. A list of the publicly

available results can be found at the HUMBOLDT

website http://www.esdi-humboldt.eu.

Scientific results

The first year of activities in HUMBOLDT concentrated mainly on the state of the art in data harmonisation and

management and related issues, such as the state of the art in harmonisations tools, software architectures, user

needs and requirements. Based on the results of the analysis, the deficiencies of existing approaches were

documented and a guideline for the scientific research to be carried out in HUMBOLDT was developed.

General remarks

The analysis of the documents collected during the

state of the art analysis showed the broad range of

the usage of geographic and spatial data, and con-

sequently, the range in types of heterogeneity that

have to be resolved in projects where information

from different data providers is shared. Based on

this still limited amount of documents a number of

observations can be made.

The Ocean and atmospheric community depend on

imagery and sensor data, and consequently here

the focus of harmonisation activities is on metadata

and metadata registries, standardised terminology,

and a standardised reference grid, so that meas-

ured and forecast data from different data provid-

ers can be compared and linked.

The National Mapping Agencies on the other hand

seem to be less involved in metadata (ISO 19115),

although this is changing. They focus currently on

the specification of common data models mainly for

cadastre and official surveying purposes.

There is a broad usage and acknowledgement of

metadata in the community providing environ-

mental-related data. Nevertheless, although several

data harmonisation activities are reported, there

are only a few general approaches and reliable

results.

Harmonisation solutions

An overview of specific harmonisation goals and

purposes was developed, the possible solutions

were presented, and specified whether they were

already an (open source) product that can be used,

or a project that can serve as an example.

Harmonising data models

This section provides a short description of the

different options for transforming data sets to the

new common target model in the case of data

model harmonisation.

It is possible to distinguish at least two phases:

creating a common model and transforming data to

that common model.


12/28

Creating common target model

This also involves creating the transformation rules

from source data set to target data set. This is ob-

viously an 'off-line' set of steps, resulting e.g. in

one or more UML class diagrams, and in case of an

XML encoding format also one or more XML

schema files. The generation of the XML schema

(or GML) files can be handled by software: e.g. the

INTERLIS-tools and/or the UGAS/ShapeChange tool.

In addition, codelists, classifications, portrayal rules

etc. can be defined.

It is critical for HUMBOLDT that the mapping rules

can be described in a formal, machine-processable,

declarative language, so that the transformation of

the data to the common model can be automated.

A second requirement is that this mapping lan-

guage is based on a non-proprietary standard.

Apart from the mapping rule language, there is

another requirement for this phase: that the collect-

ing of expert knowledge to create (develop) the

new common target model should be supported by

software that helps extracting knowledge, and that

can produce artefacts other than UML diagrams.

Transforming data to target model

There are a number of possibilities here. They are

called: off-line migration, off-line replication, server-

side schema translation, translation by mediator

services, and client-side translation. Their specific

definition and harmonisation requirements were

documented.

Harmonisation processes: best practices

There are a number of steps, which have to be

executed while fulfilling a data harmonisation task.

They can be grouped into three major

tasks/phases:

1. Specifying the harmonisation goals and ap-

proach

2. Executing harmonisation process steps

3. Collecting feedback on the harmonisation re-

sult

All methods and approaches investigated showed

that data harmonisation involves the knowledge of

human beings. Only, after a first complete execu-

tion of a whole harmonisation process, can some

process steps or even the whole process be auto-

mated.


13/28

Open issues

The investigation of documents for the state of the art analysis resulted in several open issues, which may lead to

interesting research topics in the scope of HUMBOLDT and which are currently the basis for the approach on data

specification in HUMBOLDT, especially for the HUMBOLDT scenarios.

The following provides a selection of the most im-

portant aspects which were identified:

• Find a formal 'mapping rule' language that is

expressive enough to define detailed 'mapping'

/ matching / transformation rules between

source and target data sets, not only of struc-

ture changes, but also of classification changes

(and other changes in attribute values).

• Find tools for testing whether a model or data

set is semantically consistent and correct.

• In the case of harmonisation of metadata a

number of examples were identified where local

metadata was transformed to the agreed com-

mon metadata profile for that information com-

munity, but which might still need cross-

metadata model harmonisation, either between

19115, ANZLIC, FGDC, Z3950 (for global coop-

eration, outside Europe), or between different

ISO 19115 profiles.

• Find an integrated solution for data and meta-

data harmonisation, involving the same tools

and methods for both. This includes providing

an integrated solution for raster and vector

data.

• How to connect conceptual data models, meta-

data, classification for portrayal, and taxono-

mies for thematic generalisation (consistent

switching between aggregation levels)?

• In relation to the previous point: the need to

pay more attention to situations where vector

and image data must be combined: here meta-

data plays an important connecting role, and

also the portrayal rules could be influenced by

the combination of e.g. satellite images with on

top topographic or vegetation vector data set.

• Investigate the existence of tools and methods

to help in the process of capturing the 'domain

knowledge' and terminology in an application

domain (Humboldt scenario).

• Model-driven Approach (MDA): from conceptual

to technical, guidelines for data modelling to be

incorporated in the HUMBOLDT framework


14/28

Technical Results

In this section the processes, methodologies, and HUMBOLDT results from a technical point of view are briefly

summarised.

State of the Art & Development Process Specifications

A study concerning the state of the art of collabora-

tive software development has been carried out. It

provides an overview of current practice in interna-

tional projects and developers communities for col-

laborative software development, with a special

focus on the processes that aim at defining how

distributed developers work concurrently toward the

same goal.

The information is available in the deliverable A4.1-

D1 State of the art of the collaborative software

development, which provides a general view of the

domain of collaborative software development and

helps to identify new practices and new ideas to

manage, process and integrate the HUMBOLDT

developments.

Furthermore, eight general specifications on eight

important aspects of the process of collaborative

software development for the HUMBOLDT Frame-

work have been defined and can be found in A4.2-

D1 Prototypical process specification:

• Test Areas and Datasets. Specifications about

the themes which will be harmonized in the ap-

plication relating to national and international

geographic locations.

• Prioritization of Developments. To cover this

specification a Development Review team has

been set up. The Development Review is com-

posed of members representing the different

parties interested in the Humboldt Framework:

Developers – Users – Scenario providers – Ar-

chitecture Team – Executive Board – Project Of-

fice – European Community – Inspire – GMES.

The Technological Manager and the Application

Manager of the Humboldt Project are also

members.

• Recommendations to developers. Specific rec-

ommendations to developers are provided due

to the differences between them - spatially, lin-

guistically, technologically and/or culturally sepa-

rated.

• Documentation of developments. Specifications

have been created for the required metadata

and made available for consultation.

• Integration of developments. Several integration

rules have been defined.

• Backtracking mechanisms. It is necessary to

have traceability of the developments, specifica-

tions have been created in this respect.

• Evaluation and improvements.

• Experience of the first months. Specifications on

what works best, what does not work and

what needs experimenting based on the experi-

ence gained in the project.


15/28

Guidelines for Developers

A set of documents that serve as guidelines for developers have been created:

• Programming guidelines: The Humboldt Programming Guidelines document lists some general coding recom-

mendations based on established standards collected from a number of sources, individual experience and

local requirements/needs. It includes general guides but also specific rules (especially naming rules) that

needed to be established.

• Development Rules: The Humboldt Development Rules document establishes the rules and steps to follow for

the development process of the Humboldt Prototype. It serves as a guide on how the developer teams

should work together

• Specification Methodology has been set up:

Figure 1 – An overview of the specification and implementation process used in the HUMBOLDT prototype phase.

• Building and Testing .Net and Java components: An important issue in the development of the Humboldt

Prototype lies with the build and test processes that involve both .NET components and Java components.

The document describes the recommended tools to use in the build and test processes and the general build

process description.


16/28

Prototype Interfaces, Models and Architecture

A set of activities have been carried out in order to provide developers with the organisational tools and teams to

design and specify the interfaces, models and architecture of the prototype. One of the core components is the

creation of the Architecture Team. The called A-Team or AT is a comprehensive working group under the lead of

WP05. It consists of individuals from WP05 and also contains a representative from each of the technical Work

Packages. The AT's main responsibility is the coordination and cooperation for the framework specification and

implementation activities. It collects requirements for the software products to be created in HUMBOLDT and

creates specifications that fulfil these requirements and which are implemented later.

Regarding the main tools that are common for all

developers it is worth mentioning the use of a Po-

larion Repository which is the primary source for all

requirements, tasks and issues and the use of a

SVN Repository with a Subversion Repository in

order to manage all source code, both the specifi-

cation code and the actual implementation code.

Prototype Framework Specifications

The Prototype Framework specification has been

developed following a system architecture approach

to system design known as the Reference Model of

Open Distributed Processing [ISO/IEC 10746]. The

Reference Model for Open Distributed Processing

(RM-ODP) is an international standard for designing

open, distributed processing systems. It provides an

overall conceptual framework for building distrib-

uted systems in an incremental manner.

RM-ODP defines standard concepts and terminology

for open, distributed processing. In a generic way,

the model identifies the top priorities for architec-

tural specifications and provides a minimal set of

requirements—plus an object model—to ensure

system integrity.

Accordingly the HUMBOLDT framework viewpoints

based on the RM-ODP model are:

• Enterprise viewpoint of the HUMBOLDT frame-

work. Information on typical business processes

to be supported by the usage of the HUM-

BOLDT framework prototype and scenarios as

well as use cases prepared for the HUMBOLDT

prototype development.

• Computational viewpoint of the HUMBOLDT

framework. This viewpoint shows the compo-

nents of the framework, their collaboration and

the interfaces used for that purpose (see Figure

2). It is described by the overall, logical architec-

ture and the descriptions of individual compo-

nents of the architecture as well as the collabo-

ration of components.

• Information viewpoint of the HUMBOLDT frame-

work. Data structures that are being used for

storage and exchange between the services

components defined in the computational view-

point.

• Engineering viewpoint of the HUMBOLDT frame-

work. It covers mainly the overall technical

architecture of HUMBOLDT, the deployment and

integration aspects of the framework including

computers, networks etc.

• Technology viewpoint of the HUMBOLDT

framework. Technology mapping for the logical

and physical architectures of HUMBOLDT. The

mapping of the logical components to physical

components. The mapping of logical and physi-

cal components to the real libraries, protocols

and other technical artefacts.


17/28

All the details about these formal specifications can

be found in deliverable A5.1-D1 Prototype Frame-

work Specification.

Furthermore the AT has made several prototype

component evaluations to assess if each component

is ready for the prototype implementation. The most

recent agreement approves the release of the fol-

lowing components from formal specifications to

prototype development phase:

• Context Service

• Information Grounding Service

• Mediator Service Core Modules (Request Bro-

ker, Workflow service, Access Queue Manager

and transformation Queue Manager)

• Context Service Web Frontend

• Standard GIS Client

• Model Repository

• Data Access Component Manager

Figure 2 – Component diagram for the prototype framework showing its logical, static structure.


18/28

Prototype development

Following the instructions of the AT and the technical Work Packages, the implementation of the prototype has

been carried out within WP08 during this first year of the project. The idea with the prototype has been to make

a proof of concept on some of the technologies that will be used later in the different versions of the HUMBOLDT

Framework.

The Agile Unified Process methodology by Ubisoft

has been proposed to be used in the implementa-

tion. The Agile UP is a test driven development

process. This means that for each coded unit cre-

ated a test application or process has to be devised.

This forces the development process to be more

robust. This Methodology also introduces a certain

degree of interactivity in the development process.

That ensures that the product has undergone

stakeholder or user scrutiny whilst being developed

which ensures that the final outcome is closer to the

intended functionality.

Currently the inception phase has been completed

and the only item absent from the Elaboration Phase

is the process acceptance creation of the plans and

risk assessment.

Rapid progress has been made into the construction

phase as the model of the prototype has already

been completed. The construction phase has been

initiated in sub-phases. The architecture vision has

become stable for some parts of the prototype; given

the nature of the process that has been applied.

Because this is the prototype and has been mainly

prepared by HUMBOLDT Partners in the specification

phase, it is not entirely clear which stakeholders with

which interaction is possible. Also, at the moment

due to the lack of separation from modellers and

developers there are no secondary checks on the

specification fulfilment. To solve this problem it has

been proposed that the stakeholders of each module

are the developers of the other modules that interact

with that module. So each stakeholder has had to

interact with the developers of the other group and

make sure that their interface, ontology and logical

requirements have been fulfilled.

Currently the entire software of the HUMBOLDT

prototype has been integrated into the HUMBOLDT

laboratory where it can be easily accessible to de-

velopers. The three virtual machines that correspond

to the three different elements of the prototype can

be found in the laboratory: Client, Mediator and

Grounding.

Figure 3 – Component diagram showing the mapping of service components to virtual machines


19/28

How to use HUMBOLDT

In this section two of eight HUMBOLDT scenarios are briefly described in order to illustrate the use

of the HUMBOLDT framework in applications.

Scenario: Urban Planning

The primary objective of the Urban Planning Sce-

nario is to demonstrate the usability and the use-

fulness of HUMBOLDT research and development

activities. The scenario responds to the planning

information needs arising from the deep administra-

tive and political reforms that have taken place in

the Czech Republic in the past 15 years, as well as

the more recent impacts that followed the 1997

and 2002 flood disasters in the Czech Republic. The

re-establishment of the municipality system, forming

more than 6000 local authorities, 205 new districts

and 14 regions was supported by new legal provi-

sions for the planning process based on the 1976

law, and subsequently replaced by a new spatial

planning law from 2007.

The new law has created new rules for spatial

planning influencing planning data usage, whilst

the 1997 and 2002 flood disasters in the Czech

Republic, have further redefined the key tasks of

spatial planning and data needs placing greater

emphasis on the management of natural threats

and preventative measures. Increasing attention is

being paid to the Integrated Emergency System,

which integrates firemen, police, health rescue

service etc. and complements existing spatial plan-

ning documentation. In the context of hazard as-

sessment, spatial planning is now being coordi-

nated with the Ministries of Agriculture (water

management), Environment (water protection) and

of the Interior (Firemen), and new types of dissemi-

nation tools to ensure public awareness.

In the Czech Republic the some appropriate author-

ity must finished the first version of Territorially

Analytic Backgrounds (TAB, in Czech UAP) by the

year end (31.12.2008). Territorially Analytic Back-

grounds contain findings and evaluation of status

and the development of territory by reasons of pub-

lic policy, sustainable growth and change monitor-

ing (Act 183/2006). TAB must be continuously up-

dated. The complete updating must be undertaken

every two years. In the Czech Republic there are

219 responsible regions and some municipalities. In

this context activities connected with acquisition,

processing and provision of urban planning data in

the Czech Republic are formulated.


20/28

Harmonisation Objectives

The Urban Planning scenario is focussed on the processing of geospatial data in urban planning in the Czech

Republic. But the similar situation is also in other European countries (e.g. Latvia).

Data Management

• No clear responsibility for data

• Data sets with no known origin

• No clear data properties (e.g. data models,

data formats, portrayal rules etc.)

• Most of municipalities use proprietary closed

desktop solutions

Metadata

• almost no metadata at the level of municipali-

ties ‏

• no interoperable solutions

• does not support standards

Urban Planning Harmonisation Process:

1. Metadata harmonisation according Urban Planning metadata profile (combination of ISO standard, INSPIRE

directive and Czech legislative rules).

2. Harmonisation of different data sets properties (e.g. data models, data formats, terminology etc.) so that

the data sets could be catalogued.

3. Harmonisation of catalogued data leading to visualisation through web services.

Figure 4 – Harmonisation of data catalogues


21/28

Urban Planning Functionality

System development - general process and baseline

for the development of the ICT system:

• Search incoming information necessary for multi-

criteria decisions; validation description, and

preparation of metadata to assist in publishing

the information (using web context files);

• Initial virtual brainstorming (multi-participant)

using analytical and decision support tools to

set up and apply the decision model;

• Modelling of alternative scenarios using a com-

bination of GIS (commercial and open source)

and CDP in a common workspace;

• Discussions to validate the different scenarios

and models and to agree on commonly accept-

able solutions;

• Finalisation and visualisation of accepted plan.

Relation to GMES and INSPIRE

Scenarios are dealing with INSPIRE and GMES har-

monization as a primary objective, and they provide

an environment for demonstrationn of new methods

and principles for harmonization. This approach

can be used for both putting relevant INSPIRE im-

plementation specifications into practice offering

“how-to” guidelines and best-practice examples on

how tools and standards can be used to create the

ESDI. The Scenarios also assist in bringing spatial

information into new fields of application, this latter

being critical to the ambition and development dy-

namic of GMES. The Urban planning scenario will

assist in developing the GMES Land Monitoring

Core Service in the provision of monitoring informa-

tion concerning Community and Member States’

policies related to the environment (cohesion, agri-

culture & forestry, water management soil protec-

tion, sustainable urban development, transport,

etc.). It will also support the development of

“downstream services” related to specific themes

and areas, including urban zones, nature sites,

areas subject to rapid changes or high environ-

mental risks such as flooding, landslides, and ero-

sion etc.

Connection to other HUMBOLDT Scenarios

Scenarios are in different stages of development,

with different objectives, and in different contexts,

representing a situation-specific collection of data,

local and regionally based knowledge, user com-

munities, and policy relations etc. Nonetheless the

Scenarios also show important similarities, and op-

portunities to share and utilize the Scenario re-

sources providing the basis for exploitation of net-

work synergies and the establishment of efficient

and effective collaboration and sharing resources

between Scenarios. The development of the Inte-

grated Emergency System, identified above, pro-

vides a very clear example of the policy related

connections that exist between Scenario applica-

tions in different thematic areas, and the need to

harmonise a great variety of thematic datasets (e.g.


22/28

the borders of forests /HS Forest/ are very impor-

tant for a prevention of a spread of forest fires in

urbanized areas). Exploiting these synergies means

collaboration between Scenarios in sharing meth-

odologies, tools, applications, technologies, know-

how as well as the experience of applying them

and forms the basis for close cooperation with

other HUMBOLDT scenarios that will bring major

benefits in terms of information to support policy

and other service outputs.

Current Scenario Status

Meetings in Chotebor (CR) with the mayor, and

others responsible for urban planning, environment

protection and informatics as well as planners and

IT experts from the Regional Government of Vyso-

cina, to which Chotebor belongs confirm:

• Chotebor planning documentation in digital form

already exists

• Chotebor and Vysocina basic spatial infrastruc-

ture permitting sharing of data and services in-

cluding metadata also exists

The existing data sets in Chotebor and Vysocina

have been studied and the metadata systems for

their future description have been investigated,

forming the basis for examination of existing data

models and the needs for harmonisation of this

data, as well as the analysis of the metadata model

necessary for the urban planning data description.

Cooperation with projects c@r, focused on collabo-

rative models and tools in spatial planning, and

NaturNet Redime, focused on training of local and

regional stakeholders has been developed.

In cooperation with Chotebor and Vysocina region

the aim is to develop a system which makes possi-

ble the unification and harmonization of all proc-

esses connected with urban planning background

data acceptance and publishing. At present data

providers hand in data in different data models

(e.g. GIS model, CAD model), data formats (e.g.

SHP, GML, DGN etc.), mediums (e.g. web services,

files on CD, printed map etc.), quality, metadata

records, portrayal rules and others. This implies

difficult conditions for the management of these

data sets and their publishing for other clients (e.g.

planners, public administration, general public etc.).


23/28

Scenario: Border Security

Border Security is one of 8 scenarios developed by HUMBOLDT. The primary objective of the scenario is to

demonstrate the usability and the usefulness of HUMBOLDT research and development activities for border

security activities.

It demonstrates how border security guard decision

makers can access geographic data from different

sources. Typically these data sources are created

and maintained by third parties, but the information

is relevant for the decision-making processes of the

border security guards. However, border security

guards also create and possess a large amount of

spatial information collected by sensors, mobile

units, Command and Control offices (C&C), etc.

The scenario aims to demonstrate the benefits of

the combined use of harmonized information for the

post hoc analysis of events, including security rele-

vant incidents such as an emergency call, large

demonstrations, or any other kind of hazard, lead-

ing to the evaluation of arrangements and planned

measures along the border, with subsequent prepa-

ration of new, adjusted action plans.

The Border Security scenario focuses on the analytic aspects of border protection. It addresses the following

steps:

• access remote datasets, harmonise the data, and present in a single harmonised data model

• combination of border security data with data from external sources,

• undertake analysis of this data,

• visualisation of analysed results,

• reporting,

• data sharing with persons authorized to access these data1.

data access harmonisation combination analysis visualisation reporting sharing

Figure 5 – Seven steps of the analytical process

1 Border security data and results of data analysis are (mainly) potentially sensitve data and subject to data protection and security clearence. Therefore only authorized persons and organisations can access them.


24/28

Border Security functionality

The scenario will involve two main groups of func-

tionality:

1. Data acquisition (HUMBOLDT deliverables)

2. Data analysis (Border Security functionality)

As mentioned above, border guards do not collect

topographic data, but topographic information is

important for their activities. For decisions, analysis

and reporting it is preferable to have fresh data

coming from relevant sources. From the Border Se-

curity point of view it is preferable to have access

to these datasets via web services.

From the HUMBOLDT Integration Framework (IF) the

following support for the Border Security demon-

strator is anticipated: identification of datasets –

evaluation of datasets – harmonisation and access.

Border Security functionality will develop the capac-

ity to conduct incident mapping and management

analysis, providing a map that provides intelligence

on increases or decreases in border incidents,

rather than simply raw data that does not support

accurate decision making. This represents a major

advance in communicating problems to all manage-

ment levels.

Relation to GMES and INSPIRE

INSPIRE

It is not the responsibility of the Border Security

guard or any other security or emergency organiza-

tion to collect data that falls within the INSPIRE

annexes, such as topographic data or specific the-

matic data. Border Security guards anticipate that a

European Spatial Data Infrastructure will enable

them to search for available data sources (topog-

raphic as well as thematic) in a standardised man-

ner, evaluate the datasets and obtain access to the

data sources. In this regard, the scenario is directly

connected to the INSPIRE initiative.

GMES

For the Border Security scenario the following GMES

activities are important:

Mapping – topography, road maps, land use, for-

estry, water resources maps and in specific cases

also natural resources represent important inputs

for border security activities. These dataset will not

be directly collected by Border Security but will

make use of this information for undertaking their

responsibilities.

Support – Border Security will provide most up to

date information from border security guards, i.e.

outputs from analysis, reports and other shareable

data.

It is anticipated that some of these Border Security

datasets will be subject to data protection as sensi-

tive information, and therefore will only be available

for authorized users.


25/28

Connection to other HUMBOLDT scenarios

Border Security needs to access a large variety of

thematic datasets. These datasets play an impor-

tant role in other HUMBOLDT scenarios like Forest,

Water, Planning, ERiskA etc. Consequently close

cooperation with other HUMBOLDT scenarios will

bring major benefits in terms of information to sup-

port policy and other service outputs. In this way

the scenarios can deliver knowledge about data

availability as well as direct connection to functional

service and data levels. Border Security as a result

of border guard operations and needs is clearly

related to the scenarios Urban Planning, Forest,

Protected Areas, ERiskA and Water. These sce-

narios reflect knowledge about border guard needs

on thematic spatial data and services. Concrete

cooperation between scenarios is being actively

developed between scenario leaders.

Current Scenario status

Communication has been established with the Bor-

der Guard in the Slovak republic and negotiations

are in progress with FOMI. Cooperation has also

been established with FRONTEX (European Agency

for the Management of Operational Cooperation at

the External Borders of the Member States of the

European Union), which coordinates operational

cooperation between Member States in the field of

the management of external borders.

User stories and the use cases required from the

integration framework have been defined as fol-

lows:

• Human Intrusion

• Nature Impact

• High Level Management

• Strategic Analysis

• Strategic planning.


26/28

What is HUMBOLDT

The HUMBOLDT project proposes an optimised, community-centred implementation process. Besides

a technological-focussed framework, which is being developed, the project has also set up a num-

ber of scenarios which use the developed framework components in real-world conditions, and

which are used as promoters for the target users of the project.

Presentation of consortium and „Friends“ (Users@HUMBOLD )

The core philosophy of this project is that success

comes from acceptance, use and continual improve-

ment of the results of its work. Establishing a HUM-

BOLDT User Community is thus a crucial point of our

strategy. Therefore, a User Involvement Strategy has

been elaborated and is regularly updated.

In the first year, the focus was mainly on raising

awareness about the project. Several dissemination

instruments were therefore used. The public website

of the project (www.esdi-humboldt.eu) was created

and is updated regularly. The HUMBOLDT Whitepa-

per has been created and was published in several

media in multiple languages. A project brochure was

also created and distributed at several important

SDI- and GI-related events. All the above dissemina-

tion materials are available for download via the

project website.

In the next phase, a User Community with high in-

teractivity will be established. The creation of the

User@HUMBOLDT Platform was an important step

towards this goal. Users can now enrol themselves

via the public Website, where a „Get Involved!”

section has been created. On the other hand, the

project also builds on the well-established partner

networks of the Consortium Members themselves.

Therefore, Consortium Members have contacted

their well-trusted partners and identified those in-

terested in the project and willing to join the User

Community. These users will then be contacted di-

rectly by the Project Office and involved in the Key

User Community.

No user community could be built without motivating

the users to join. Starting from the first public ver-

sion of the Framework, registered HUMBOLDT users

will be enabled to use and test the successive ver-

sions of the Framework itself for their own use

cases, and to provide feedback to the Project. This

is in itself a motivation for the users to join the

User@HUMBOLDT Platform. A HUMBOLDT training

package assisted by a training framework is being

elaborated to support the HUMBOLDT dissemination

and exploitation policy, and the effective involve-

ment of the users. The training package will be

available for download through the project website

for the registered HUMBOLDT users. Registered us-

ers will also have the right to browse all the public

deliverables created during the project. Besides this,

it is intended to provide public summaries of the

project results (non-public deliverables, etc.) created

within each WP. Until the first public version of the

Framework is available, it is still possible to motivate

users by providing some software tools created by

the Consortium in the framework of the HUMBOLDT

project, which will either be part of the Framework

or are used for other purposes within the project.


27/28

HUMBOLDT Consortium

The HUMBOLDT project is undertaken by 28 partners supported by a Review and Advisory Board consisting of

outstanding persons from the geospatial community.

Photo: The HUMBOLDT Consortium


28/28

HUMBOLDT Project Partners

1. Fraunhofer-Institut für Graphische Datenverarbeitung IGD, Germany

2. ETRA Investigacion y Desarrollo, Spain

3. Help Service Remote Sensing, Czech Republic

4. LogicaCMG UK, UK

5. Institut Géographique National, France

6. Intergraph CZ, Czech Republic

7. ETHZ - Swiss Federal Institute of Technology Zurich, Switzerland

8. Delft University of Technology, Netherlands

9. University of Rome "La SAPIENZA", Italy

10. Institute of Geodesy, Cartography and Remote Sensing (FOMI), Hungary

11. Marine Information Service 'MARIS' BV, Netherlands

12. KTU Regional Science Park, Lithuania

13. INI-GraphicsNet Stiftung, Germany

14. Technische Universität München, Germany

15. University of the West of England, UK

16. Institut Français de Recherche pour l'Exploitation de la Mer, France

17. National Environment Research Council, UK

18. Hellenic Centre for Marine Research, Greece

19. Swedish Meteorological and Hydrological Institute, Sweden

20. Telespazio, Italy

21. GISIG - Geographical Information Systems International Group, Italy

22. Consiglio Nazionale delle Ricerche, Italy

23. Forest Management Institute, Czech Republic

24. Instituto Geográfico Português, Portugal

25. Collecte Localisation Satellites, France

26. Högskolan i Gävle, Sweden

27. Promitheas Business Innovation Center Limited, Cyprus

28. Intergraph Germany, Germany

Date post:	16-Jul-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Humboldt Annual Report 2007 - Overview – HUMBOLDT Project · 2010-06-21 · HUMBOLDT Annual...

Documents