Plan4all Networking Architecture

D5.2 Plan4all Networking Architecture
1/77
ECP-2008-GEO-318007
Plan4all
Plan4all Networking Architecture
Deliverable number D-5.2
Dissemination level Public
Delivery date 30 October 2010
Status Final
Authors
Flavio Camerata, Giuseppe De Marco,
Giuseppina Pellegrino (DipSU)
Runar Bergheim (AVINET)
Main contributors
Pēteris Brūns (TDF), Jachym Cepicky
(HSRS), Stelian Dimitrov (EPF), Petr
Horák (HF), Jan Jezek (UWB), Katharina
Mitterer-Reinisch (ISOCARP), Julia
Neuschmid (CEIT ALANOVA), Norma
Zanetti (Hyperborea)
eContentplus
This project is funded under the eContentplus programme1,
a multiannual Community programme to make digital content in Europe more accessible, usable and exploitable.
1 OJ L 79, 24.3.2005, p. 1.

2/77
Table of Contents
1. Purpose................................................................................................................................ 4
2. System overview................................................................................................................. 5
2.1. Mission of system........................................................................................................ 5
2.2. System stakeholders .................................................................................................... 5
2.3. System architecture...................................................................................................... 5
3. Methodology....................................................................................................................... 7
3.1. Methodology adopted for Plan4all .............................................................................. 7
3.2. Existing input to the definition of the architecture...................................................... 8
3.3. Requirement analysis................................................................................................... 8
3.4. Review of relevant standards....................................................................................... 9
4. Architectural description................................................................................................... 15
4.1. Application of RM-ODP approach to Plan4All: Plan4all-RM.................................. 15
5. Enterprise Viewpoint ........................................................................................................ 19
5.1. Concerns.................................................................................................................... 19
5.2. Stakeholders (actors) ................................................................................................. 19
5.3. Use cases/Activities................................................................................................... 21
5.4. Use cases.................................................................................................................... 23
5.5. Core elements ............................................................................................................ 35
6. Information Viewpoint...................................................................................................... 38
6.1. Information life-cycle................................................................................................ 38
6.2. Information flow model............................................................................................. 40
6.3. Information data model ............................................................................................. 41
6.4. Principal information types ....................................................................................... 43
6.5. Important findings for the implementation of the architecture.................................. 45
6.6. Formal Information Viewpoint language .................................................................. 45
7. Computational Viewpoint................................................................................................. 46
7.1. Concerns.................................................................................................................... 46
7.2. Access Control Services (ACOS).............................................................................. 46
7.3. Application services .................................................................................................. 47
7.4. Portrayal services....................................................................................................... 48
7.5. Metadata services ...................................................................................................... 48
7.6. Data services.............................................................................................................. 49
7.7. Processing services.................................................................................................... 49
7.8. Harmonisation services.............................................................................................. 50
7.9. Registry services........................................................................................................ 50
7.10. Relations among components ................................................................................ 52
8. Engineering Viewpoint ..................................................................................................... 53
8.1. Concerns.................................................................................................................... 53
8.2. Plan4All Technical Architecture ............................................................................... 53
8.3. Access Control Services (ACOS) – Technical Overview ......................................... 54
9. Technology Viewpoint...................................................................................................... 60
9.1. Concerns.................................................................................................................... 60
10. Implementation recommendations ................................................................................ 61
10.1. Examples of Open Source tools for implementing the Plan4all Networking
Architecture.......................................................................................................................... 61
10.2. Examples of commercial tools for implementing the Plan4all networking
architecture........................................................................................................................... 70
11. References ..................................................................................................................... 76

3/77
11.1. Standards, specifications and articles .................................................................... 76
11.2. Websites................................................................................................................. 76

4/77
1. Purpose
The objective of Task 5.2 is to define the architecture (platform neutral) and the basic set of
networking services in compliance with the INSPIRE Directive, for the sharing of spatial
planning data between public sector and all user groups involved in the planning process and
results (NGOs, citizens, private sector, education and science, and all those who play an
important role in spatial planning tasks). Plan4all will define the interfaces by which the
different parties will exchange the spatial planning data.
This document intends to formalise and describe the Plan4all networking and data sharing
architecture, and suggest its possible components. The starting point and requirements can be
found in the Plan4all deliverable D5.1 and in the results of the previous Work Packages.

5/77
2. System overview
2.1. Mission of system
The mission is to demonstrate the INSPIRE compliant (platform neutral) networking service
architecture implementation for the sharing of spatial planning data among the public sector
organisations and all the interested user groups, providing the following services:
- discovery;
- access to data and visualisation;
- machine-to-machine communication;
- work flow following the “publish-find-bind” design pattern;
- processing services;
- Geo-RM services.
2.2. System stakeholders
- Government sector (e.g. municipalities, provinces, states, federal states);
- private sector (e.g. investors, consultancy companies, contractors and development
companies);
- NGOs and the Third Sector (e.g. no-profit organisations, aid organisations,
environmental organisations);
- research and education sector (e.g. universities, research institutes, scientists,
students);
- citizens (e.g. people who are accessing systems without affiliation to associations,
NGOs or similar).
2.3. System architecture
From an architectural point of view, the system must have the following characteristics:
- service oriented;
- loosely coupled integration;
- persistent identifiers;
- trusted infrastructures.
The system design is based on the principles of the Service Oriented Architecture (SOA) and
is INSPIRE compliant. The INSPIRE requirements give to the overall system architecture a
loosely coupled integration based on OGC standard usage, which allows to use any OGC-
compliant software component and easy replace it with another if necessary.
In order to achieve interoperability, the main software interface among each particular
component has to be based on ISO standards and OGC specifications, following the INSPIRE
Directive.
These specifications are:
- OGC CSW;
- OGC WMS;
- OGC WFS;
- OGC WPS.
And other relevant standards are:
- ISO 19115;
- ISO 19110;
- Dublin Core metadata.

6/77
The communication interfaces are based on well known approaches used generally in SOA
(Service Oriented Architecture). These communication protocols are widely used in OGC
standards and mainly are:
- key-value-pairs sent via HTTP/GET request;
- key-value-pairs or XML sent via HTTP/POST request;
- SOAP sent via HTTP/POST request;
- REST communication via HTTP/GET/POST.

7/77
3. Methodology
3.1. Methodology adopted for Plan4all
The approach adopted is based on the standard Reference Model of Open Distributed
Processing (RM-ODP) (described in ISO/IEC 10746-1), which 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 RM-ODP allows to define an overall conceptual framework for building distributed
systems in an incremental and coordinated manner.
The ORM is based on RM-ODP and provides an overall conceptual framework for building
geo-processing services.
Furthermore, 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.
3.1.1 RM-ODP Overview
RM-ODP is a widely used international standard for designing open, distributed processing
systems.
RM-ODP provides a short, clear and explicit specification of concepts and constructs that
define semantics, independently from the representation, methodologies, tools and processes
used for the development of open distributed applications.
RM-ODP identifies five viewpoints, or perspectives, which address different aspects of a
system:
- Enterprise Viewpoint;
- Information Viewpoint;
- Computational Viewpoint;
- Engineering Viewpoint;
- Technology Viewpoint.
Viewpoint Name Definition of RM-ODP Viewpoint
Enterprise Focuses on the purpose, scope and policies for that system.
Information
Focuses on the semantics of information and information
processing.
Computational
Captures component and interface details without regard to
distribution.
Engineering
Focuses on the mechanisms and functions required to support
distributed interaction among objects in the system.
Technology Focuses on the choice of technology.
Description of the RM-ODP Viewpoints.

8/77
Relationships among the five RM-ODP viewpoints.
3.1.2 ORM Overview
The OGC Reference Model (ORM) describes the OGC Standards Baseline focusing on
relationships between the baseline documents.
The OGC Standards Baseline (SB) consists of the approved OpenGIS Abstract and
Implementation Standards (Interface, Encoding, Profile, Application Schema) and Best
Practice documents.
Purpose of the ORM:
- provide an overview of OGC Standards Baseline;
- provide insight into the current state of the work of the OGC;
- serve as a basis for coordination and understanding of the documents in the OGC SB;
- provide a useful resource for defining architectures for specific applications
(Source: http://www.opengeospatial.org/standards/orm).
3.2. Existing input to the definition of the architecture
- INSPIRE;
- OGC;
- Plan4all WP2;
- Plan4all WPs 3 and 4;
- Plan4all T5.1.
3.3. Requirement analysis
As a preliminary work (May 2010), each involved partner has been invited to identify the use
cases. The results are reported in Annex I.
Moreover, during the project meeting held in Rome on 14th and 15th October 2010, all
partners participated in a group discussion and answered a set of questions related to the Task.
The results of these discussions are reported in Annex II. They are interesting not only for the
purpose of this specific Task, but can be useful also for the following WPs.

9/77
3.4. Review of relevant standards
3.4.1 Web Map Services
WMS is the standard protocol for the dynamic request of spatially referenced map images
over the internet using vector or raster data from geographic data resources. The WMS
specification was developed and first published by the OGC (Open Geospatial Consortium) in
1999. Today’s up-to-date WMS interface is version 1.3.0. WMS requests are always called
through URI parameters. The WMS operations are:
- service-level metadata (GetCapabilities request);
- map with well-defined geographic and dimensional parameters (GetMap request);
- optional: information about particular features shown on a map (GetFeatureInfo
request);
- optional: information about layers (DescribeLayer request);
- optional: legend creation (GetLegendGraphic request).
A WMS capable of serving the GetCapabilities and GetMap requests is referred to as “basic
WMS”, a WMS also serving GetFeatureInfo requests is called “queryable WMS”. The WMS
standard is mainly designed for producing maps, not to access attribute data beyond objects
on the map.
The WMS standard itself refers to these given standards:
- EPSG Geodesy Parameters for the definition of the geographic map projection;
- MIME for the correct encoding of the mapserver’s return document;
- URI (Uniform Resource Identifier) syntax for the correct spelling of the map requests;
- HTTP 1.1 (Hypertext Transfer Protocol) for data transmission over the Internet (it is
mandatory that WMS requests can be transferred using the GET method, POST
method is only optional and therefore hardly used in this context);
- ISO 8601:2000 for the correct representation of dates and times;
- ISO 19111, Geographic information – Spatial referencing by coordinates;
- ISO 19115:2003, Geographic information – Metadata;
- XML (Extensible Markup Language) for the non-graphical output of a mapserver.
Data can be retrieved from a mapserver in single layers. These layers can be combined with
each other. Using transparent output images (GIF or PNG) these layers can be overlaid in a
way that the layers underneath the top images can also be viewed. Data can be requested from
one or more different mapservers at a time, and data can also be passed through more than
one mapserver to produce output referred to as “cascading WMS”, which means that one
mapserver calls data from another mapserver and includes these data in its own output.
The section of the Earth being mapped is defined through the “bounding box” consisting of
the coordinates of a rectangle (format: min(x), min(y), max(x), max(y)) in the given
coordinate reference system (CRS). The output of a mapserver – i. e. the answer to a WMS
request – is always a computer readable file which is transferred from the server to the client.
The MIME type string defines whether this file shall be treated as image (usually type
“image/png”) or text (type “text/xml”). The table below explains some common WMS request
parameters (shown for the example of a GetMap request).

10/77
Common parameters of a GetMap request
(Source: OGC WMS 1.3 Interface Recommendation Paper).
The request is always composed as HTTP URI string like
http://myserver.com/mywmsname?SERVICE=WMS&REQUEST=GetMap&[ANOTHE
RPARAMETER]=[anotherValue].
Usually the request parameters are written in uppercase characters to enhance human
legibility of the request string, but also lowercase is possible.
The request parameters are not case-sensitive, however, the parameter values are. Each WMS
has a pre-defined style which tells the mapserver how to create an image from the geodata
used in the GetMap request. Some mapservers also allow the use of Styled Layer Descriptors
(SLD) so that different or user-defined map styles can be applied to map images. These SLD
information is stored in XML format and can either be located on the mapserver side or sent
to the mapserver as a URI parameter of the GetMap request.
3.4.2 Web Feature Services (WFS)
The OGC WFS Standard (WFS) allows the interchange of geographical features across the
web using platform-independent calls. While WMS only transfer images which are created
from the original data, WFS deliver the data itself. It is oriented for vector data exchange on
the Internet. WFS operations are used to retrieve or query features based on spatial and non-
spatial constraints and to create/delete/update feature instances. The current WFS standard is
version 1.1.0.
These requirements must be fulfilled for WFS (source: OGC WFS standard definition):
- the interfaces must be defined in XML;
- GML (Geographic Markup Language) must be used to express features within the
interface;
- at a minimum a WFS must be able to present features using GML;

11/77
- the predicate or filter language will be defined in XML and be derived from CQL
(Common Query Language) as defined in the OpenGIS Catalogue Interface
Implementation Specification;
- the data store used to store geographic features should be opaque to client applications
and their only view of the data should be through the WFS interface;
- a subset of XPath expressions for referencing properties must be used.
Both geometric and attribute information are transferred with GML. Also the OGC Web
Gazetteer Service profile is derived from this service. An extended capability of the service
enables transactional operations like insert/update/delete features on remote servers. WFS
uses also Filter Encoding for querying.
WFS requests are:
GetCapabilities A web feature service must be able to describe its capabilities.
Specifically, it must indicate which feature types it can service and
what operations are supported on each feature type.
DescribeFeatureType A web feature service must be able, upon request, to describe the
structure of any feature type it can service.
GetFeature A web feature service must be able to service a request to retrieve
feature instances. In addition, the client should be able to specify
which feature properties to fetch and should be able to constrain the
query spatially and non-spatially.
GetGmlObject A web feature service may be able to service a request to retrieve
element instances by traversing XLinks that refer to their XML IDs.
In addition, the client should be able to specify whether nested
XLinks embedded in returned element data should also be retrieved.
Transaction A web feature service may be able to service transaction requests. A
transaction request is composed of operations that modify features;
that is create, update, and delete operations on geographic features.
LockFeature A web feature service may be able to process a lock request on one or
more instances of a feature type for the duration of a transaction. This
ensures that serialisable transactions are supported.
Types of WFS requests.
Based on the operation descriptions above, three classes of web feature services can be
defined:
- basic WFS: implements the GetCapabilities, DescribeFeatureType and GetFeature
operations. It is a read-only WFS;
- XLink WFS: an XLink WFS would support all the operations of a basic web feature
service and in addition it would implement the GetGmlObject operation for local
and/or remote XLinks, and offer the option for the GetGmlObject operation to be
performed during GetFeature operations;
- transaction WFS: a transaction web feature service would support all the operations of
a basic web feature service and in addition it would implement the Transaction
operation.
The WFS Transaction (WFS-T) operation is used to describe data transformation operations
that are to be applied to web accessible feature instances. A web feature service may process a
Transaction operation directly or possibly translate it into the language of a target datastore to
which it is connected and then have the datastore execute the transaction. When the
transaction has been completed, a web feature service will generate an XML response

12/77
document indicating the completion status of the transaction. The Transaction operation is
optional and a WFS implementation does not need to support it to conform to this
specification. If the Transaction operation is supported, then this fact must be advertised in
GetCapabilities results.
The rules on how to compose the WFS request are the same as with WMS. While HTTP GET
requests use keyword-value pairs similar to WMS, HTTP POST operations require the use of
XML. Transaction operations can only be done with the POST method. Very often SOAP
(Simple Object Access Protocol) is used for communication between mapserver and client.
3.4.3 Web Coverage Services (WCS)
WCS can be seen as somewhere in between WMS and WFS. WFS deliver vector data; WCS
is WFS’s counterpart for raster data (images and grids). Coverages are usually transferred in
GeoTIFF, HDF-EOS, NITF or CF-NetCDF formats. The actual format is defined through a
MIME type string. WCS data may contain:
- series of points, such as locations of samples;
- regular grids of pixels or points (also photos or pictures);
- segmented curves, often used for road paths;
- Thiessen polygons;
- Triangulated Irregular Networks (TIN).
WCS provides three operations which are all mandatory:
- GetCapabilities: returns an XML document which describes the service and the
coverages that clients may request;
- DescribeCoverage: the client can request a full description of one or more coverages
served by a particular mapserver. The server returns an XML document describing the
coverages;
- GetCoverage: returns a coverage (i. e. values or properties of a set of geographic
locations) encoded in a well-known coverage format.
The requests are usually composed from key-value pairs and transferred via the HTTP GET
method. Support of the HTTP POST method is only optional for WCS.
3.4.4 Web Catalogue Service (CSW)
Catalogue services are the key technology for locating, managing and maintaining distributed
geo-resources (i. e. geospatial data, applications and services). They support the ability to
publish and search collections of descriptive information (metadata) for data, services, and
related information objects. Metadata in catalogues represent resource characteristics that can
be queried and returned through catalogue services for resource evaluation and, in many
cases, invocation or retrieval of the referenced resource. Catalogue services support the use of
one of several identified query languages to find and return results using well-known content
models (metadata schemas) and encodings.
With catalogue services, client applications are able to search for geo-resources through
standardised interfaces and operations and, ideally, they are based on a well-known
information model, which includes spatial references and further descriptive (thematic)
information that enables client applications to search for geo-resources in very efficient ways.
CSW relies on these standards:
- ANSI/NISO Z39.50-2003, Information Retrieval (Z39.50): Application Service
Definition and Protocol Specification;
- IETF RFC 2045 and IANA (MIME types);
- IETF RFC 2141 (URN Syntax);
- IETF RFC 2396 (URI Syntax);
- IETF RFC 2616 (HTTP);

13/77
- CORBA/IIOP, Common Object Request Broker Architecture, Version 2.X;
- ISO/IEC TR 10000-1:1998. Information Technology – Framework and taxonomy of
International Standardised Profiles – Part 1: General principles and documentation
framework;
- ISO/IEC 10746-2:1996. Information Technology – Open Distributed Processing –
Reference Model: Foundations. Common text with ITU-T Recommendation X.902.
- ISO 4217:2001, Codes for the representation of currencies and funds;
- ISO 8601:2000(E), Data elements and interchange formats - Information interchange -
Representation of dates and times;
- ISO 11180, Postal addressing;
- ISO/IEC 14977:1996, Information technology – Syntactic metalanguage – BNF;
- ISO 19106:2003, Geographic Information – Profiles;
- ISO 19115:2003, Geographic Information – Metadata;
- ISO/DIS 19119, Geographic Information – Services;
- ISO/TS 19139, Geographic Information – Metadata – Implementation Specification;
- OASIS/ebXML Registry Services Specification v3.0;
- and various OGC and W3C standards and/or recommendations.
Metadata structures, relationships, and definitions – known as conceptual schemas – exist for
multiple information communities. For the purposes of interchange of information within an
information community, a metadata schema may be defined that provides a common
vocabulary which supports search, retrieval, display, and association between the description
and the object being described. Although this specification does not require the use of a
specific schema, the adoption of a given schema within an information-sharing community
ensures the ability to communicate and discover information.
The metadata standard ISO 19115:2003 includes a proposal for core metadata elements in
common use. ISO Draft Technical Specification 19139 defines a formal encoding and
structure of ISO metadata for exchange. Where a catalogue service advertises such application
schemas, catalogues that handle geographic dataset descriptions should conform to published
metadata standards and encodings, e. g. ISO 19115:2003, and support XML encoding per ISO
19139 or profiles thereof. Service metadata elements should be consistent with ISO 19119.
CSW use their own query language which has a syntax similar to the SQL WHERE clause.
The expressiveness of the query does not require extensions to various current query systems
used in geospatial catalogue queries other than the implementation of some geo-operators.
The CSW query language is extensible. OGC_Common supports both tight and loose queries.
A tight query is defined where if a catalogue does not support an attribute or column specified
in the query, no entity or row can match the query and the null set is returned. In a loose
query, if an attribute is undefined, it is assumed to match.
CSW supports these types of operations according to the latest standard CSW 2.0.2:
- discovery (mandatory): implemented through the requests GetCapabilities,
DescribeRecord, GetRecords und GetRecordById. The selection is made by the search
engines of the geodata infrastructure providers to give the client information about
geoapplications, geotools or geodata ;
- transaction (optional): with a transaction metadata documents can be inserted, updated
or deleted. Transaction operations are done with web-based metadata editors which
are usually available to closed or restricted user groups;
- harvesting (optional): the operation harvestResource retrieves metadata from an
external CSW and stores it in the own CSW. In a GDI this is done by a coordination
office or data clearinghouse: the upper level CSWs harvest metadata from local or
regional catalogues and, therefore, can offer a centralised search. A disadvantage of
harvesting is the risk of redundancies through recursion.

14/77
3.4.5 Tools which can help to take local data and put them into the web effectively
“AVeiN!” or “AMeiN!” are Open Source software products that help the user to export a
view from ESRI ArcView or ArcMap into a UMN Mapserver map file. The application name
stands for “ArcView einfach ins Netz”/”ArcMap einfach ins Netz” which is German and
means “From ArcView easily into the web”/”From ArcMap easily into the web”. The
software is installed as extension to ArcView or ArcGIS and guides the user through a few
steps like a wizard so that a mapfile (including symbol and legend files) can be generated very
quickly. The output of AVeiN/AMeiN and the geodata (shapefiles) has just to be copied into
UMN Mapserver’s target directory on the web server and the data can be instantly accessed as
WMS.
AMeiN offers the following functions:
- transfer of ArcMap symbols, fonts, font symbols, colours, hatches, …;
- settings for legend, scale bar, querymap and overview map (WYSIWYG editor);
- definition of data source and direct data source connection;
- access to about 90 % of UMN’s functions.
Unfortunately, the development of AVeiN and AMeiN was stopped some years ago, so it is
not sure whether these extensions will be compatible with future versions of ArcGIS or UMN.
Together with shapefiles or geodatabase information, also attribute data are stored on the web
server. These attribute data can be accessed either with the WMS GetFeatureInfo request or
with WFS. To propagate document-based or non-spatial information along with geodata, the
easiest way seems to link such documents to the id of a geo-object in the database or
shapefile. With an URI given in the attribute table, the user can access an external database
where all files can be stored which are linked to certain geo-objects or groups of geo-objects.
Sources:
- http://www.opengeospatial.org/standards/wms
- http://www.opengeospatial.org/standards/wfs
- http://www.opengeospatial.org/standards/wcs
- http://en.wikipedia.org/wiki/Web_Map_Service
- http://en.wikipedia.org/wiki/Web_Feature_Service
- http://en.wikipedia.org/wiki/Web_Coverage_Service
- http://www.terrestris.de/2010/04/29/amein-handbuch-online

15/77
4. Architectural description
4.1. Application of RM-ODP approach to Plan4All: Plan4all-RM
Plan4all adopted the RM-ODP approach, in particular referring to OGC Reference Model
(ORM) to define its own architectural model, in order to comply to OGC standards and
specifications and to ISO/TC211 standard series, according to T.5.1 requirements about
services design.
Adopted within many current best practices, the RM-ODP approach has been chosen because
it eases the design and implementation of the Plan4all Networking Architecture, which is a
complex system, in order to give a clear idea on the interrelation among the different parts of
the Networking Architecture.
This approach will provide an overall conceptual model to develop the Networking
Architecture in an incremental manner, enabling partners’ data and services interoperability
achievement (Plan4all scope) and, on the other hand, granting an easy adaptation of the
Networking Architecture to future requirements (further services, new technical
specifications, etc).
In this work, UML will be used as the main notation language to describe all the aspects of
the Networking Architecture from the different “viewpoints”, and a service-oriented approach
will be adopted according to INSPIRE and Plan4all requirements defined in T5.1.
This work will be focused on the Enterprise, Information, Computational and Engineering
Viewpoints and the relationships among them.
The Technology Viewpoint will be analysed in the following WPs, using the specifications
defined in this WP.
The following diagram shows the relationships between the five RM-ODP viewpoints within
the Plan4all Networking Architecture.

16/77
Relationships between the five RM-ODP viewpoints within the Plan4all Networking Architecture.
The following diagram gives an overview on how some reference standards and specifications
play a role in the Plan4all reference model.

17/77
Overview on how some reference standards and specifications play a role in the Plan4all reference model.
The following table summarises the five RM-ODP Viewpoints addressing different aspects of
the Plan4all Networking Architecture, and the UML mapping containing the profiles used to
describe them.
Viewpoint Rationale UML technology mapping
Enterprise Description of P4a system from
the viewpoint of its users’
purpose, related to the reference
context and policies.
The Enterprise Viewpoint is defined
by a set of use cases and a class
diagram.
Information Definition of the conceptual
schema of the information
managed into P4a, related to the
Conceptual Data Models and
Metadata profile designed by
Work Packages 3 and 4. The
focus is on the information
semantics and processing.
The ISO/OGC General Feature
Model is adopted as information
meta-model.
The Information Viewpoint is
defined by a set of information
objects (classes) represented by class
diagrams.
Computational Definition of the reference
architecture (SOA) and
subdivision of the system into
services interacting through
interfaces, independently from
The Computational Viewpoint is
represented by UML component and
activity diagrams.

18/77
their “physical” distribution.
Engineering Definition of the engineering
schema and the interaction
between system components and
services.
The Engineering Viewpoint is
represented by a “block diagram”
and activity diagrams.
Technology Technological specifications for
the system implementation
(network nodes, communication,
software, etc). physical
deployment.
Mapping in WSDL in compliance
with OGC specifications, W3C Web
Services, UDDI etc.
The five RM-ODP Viewpoints

19/77
5. Enterprise Viewpoint
5.1. Concerns
The enterprise viewpoint deals with the purposes, scope and policies of the system. The
concepts of this viewpoint are independent of both distribution and implementation details.
The design of the Plan4all Networking Architecture from the Enterprise Viewpoint consists in
three steps:
- definition of the “stakeholders” (actors) and of the “roles”;
- identification of the “activities” (use cases) for each stakeholder;
- identification of the “core elements”, described through class diagrams.
5.2. Stakeholders (actors)
A stakeholder is an individual or a group with an interest in the success of a system in
delivering its intended results and maintaining the viability of its products. Stakeholders either
affect the Plan4all system or are affected by it.
The following diagram shows the stakeholders of the system, as defined by WP2.
Stakeholders of the system.

20/77
The following table briefly describes the stakeholders involved with their respective activities
into the Plan4all Networking Architecture.
Stakeholder Description Activities
End User
(application,
human)
Stakeholder who uses Portal
without registration on the
Portal.
 Uses services without
registration;
 searches through metadata;
 analyses metadata view and
downloads free data;
 joins free services.
Expert User Stakeholder registered on the
Portal, who connects to
data/services according to his
rights, but he does not
publish his own data.
 Searches through metadata;
 analyses metadata;
 views and downloads data and
joins services according to his
rights;
 creates and publishes
composition from external
sources – defines policies for
this publication.
Content Provider Stakeholder registered on the
Portal, who provides his own
data or services; he accesses
data/services according to his
rights.
 Searches through metadata.
 analyses metadata;
 update metadata;
 views data, downloads data and
joins services according to his
rights;
 creates and publishes
composition from external
sources – defines policies for
this publication;
 provides data on the web;
 produces metadata;
 assures quality of data and
metadata;
 defines policies and license
agreements.
Policy maker Stakeholder not directly
registered on the Portal, but
having a secondary influence
on access to the data/service
(politician, not registered
data owner, ...)
Influences data access policies.
Administrator System administrator with
full access to the Portal.
Technically manages the System.
Stakeholders’ activities.
WP2 defined several groups of users and captured requirements from them. The next table
shows these user groups in relation to the actors of the proposed system.

21/77
User group/stakeholder Content
provider
Expert
user
End user Policy
maker
Spatial planning authorities
Other civil service authorities
Owners of transport and technical
infrastructure
Planning engineers, city planners
Firms
NGO
Investors, real estate owners
Real estate agents
Research institutes, students
Public
User groups in relation to the actor of the proposed system.
5.3. Use cases/Activities
A use case is the specification of a set of actions performed by a system, which yields an
observable result that is, typically, of value for one or more actors or other stakeholders of the
system.
The purpose of the Plan4all Networking Architecture may be defined in terms of the use of
the system made by the stakeholders. Every activity can be represented through a UML “Use
Case”, the performer of the activity is defined “Actor”.
A top-level diagram shows the primary use cases in the following figure.

22/77
Primary use cases.
List of use cases:
- user administration and security:
o stakeholder registration;
o user deregistration;
o user login;
o setting user roles;
- search and discovery:
o search metadata;
o browse metadata;
o join a new catalogue;

23/77
- data management:
o import data;
o compose data/service;
o publish data/service;
o view data;
o download data;
- metadata management:
o produce metadata;
o import metadata;
o edit/update metadata and service.
- policies:
o DRM specification;
o access to data with DRM;
- monitoring and control service:
o monitor registration process;
o monitor requests for access with DRM;
o web analytics tool.
5.4. Use cases
5.4.1 Administration and Security
Use case UC 1-01 – Stakeholder registration
Task Stakeholder can use the Plan4all portal with or without registration. If
he wants to access to extended functionality or restricted data, he needs
to register himself:
- anyone can register as a portal User for extended functionality;
- anyone can register as Content Provider (to publish his own
data);
- Users may associate themselves with one or more content
providers;
- User’s roles within a Content Provider context will be
restricted.
Actors User, Administrator, Content Provider.
Preconditions
Normal Flow 1. User opens the default portal site.
2. User selects “Registration” from the main page.
3. Portal displays a registration form. The page includes help
links. The form includes:
o user name, password, name, company, contact
information (address, email, phone, etc.), optional list of
roles and list of content providers that could be
associated.
4. User fills in requested data.
5. Portal validates User information (see Alternate Flow 1).
6. Portal sends a confirmation of registration to the new User. The
message is also sent to the Portal Administrator (see Alternate
Flow 2).

24/77
7. Portal sends a message to Content Providers specified by User,
indicating the new User, his role and request for access to the
Content Provider’s data (See Alternate Flow 2).
8. Portal presents a welcome page for a new User. The page
includes links to Getting Started, User Documentation and
Personalisation pages.
Alternate Flow 1. Required information is missing or invalid.
o Portal presents indication of invalid application and
points out mistakes, with details on invalid or missing
fields.
o Portal logs invalid submission.
o Use case continues with Step 3, with fields populated
with previous information.
2. Notification cannot be sent to the User.
o Portal sends an e-mail message to the Portal
administrator notifying problem with Provider's e-mail.
o Use case terminates.
o Portal Administrator notifies the User directly by email
and investigates communication failure.
Postconditions,
Results
1. Normal Flow.
o User is registered on the Portal.
o Appropriate Content Providers are notified about the
new User and his role and are asked to confirm user’s
access to their data.
o Message is sent to User, welcoming him to Portal.
2. Alternate Flow 1.
o Message is displayed, indicating a failed registration
with details on invalid fields.
o Portal has logged the registration failure.
o Use Case continues with Step 3, the registration form is
populated with user content.
3. Alternate Flow 2.
o A communication failure event has been created.
o Portal Administrator detects the communication failure.
o Portal Administrator communicates directly with
Content Provider, informing of Service approval.
o Portal Administrator evaluates the communication
failure.
o Use case terminates.
Notes Standard registration is done by the system.
The access to Content Provider’s data is possible after the request is
approved by him.
Status of the request will be indicated on the Users’ personal page.
Use case UC 1-02 – User Deregistration
Task Registered User wants to cancel his registration in the Portal.
Actors User, Administrator, Content Provider.

25/77
Preconditions User has got a valid registration on the Portal.
Normal Flow 1. User logs in the portal.
2. User goes to the User’s Personal Page.
3. User selects “Cancel Registration”.
4. Portal presents Warning message.
5. User confirm deregistration (see Alternate Flow 1).
6. Portal presents “Your registration has been cancelled”.
7. Portal logouts the User.
8. Portal provides a log of the user’s last active settings.
9. Portal cancel User’s registration.
10. Portal sends deregistration notice to User, Administrator and
relevant Content Provider (see Alternate Flow 2).
Alternate Flow 1. User doesn’t confirm deregistration.
o Portal presents the notice “Deregistration has been
canceled”.
o Portal goes to User’s Personal Page.
o Use case is finished.
2. Deregistered User plays the role of Content Provider.
o System sends deregistration notice also to every User
who has indication (on Personal Page) of using Content
Providers data/services.
o System indicates on Personal Page of every User, that
the data/service is not available any longer.
Postconditions
Notes
Use case UC 1-03 – Login
Task In order to access to extended portal functionality or to restricted
data/services, the Stakeholder needs to be logged in the Portal.
Actors User.
Preconditions User has got valid registration on the Portal.
Normal Flow 1. User opens the default portal site.
2. User types username/password in the login box.
3. User clicks “Login” button.
4. Portal runs Authentication routine - verifying the Stakeholder
(see Alternate Flow 1).
5. Portal runs Authorisation routine (permission to access to
extended functionality or restricted data/services).
6. Portal logs the User in the portal.
7. Portal presents the Main Page according to User’s settings.
Alternate Flow 1. Authentication is failed.
o Portal displays the message “Wrong Username or
Password”.
o Portal goes to the default portal site (step 1 of the
Normal Flow).
Postconditions

26/77
Notes
Use case UC 1-04 – Setting User Roles
Task When the Stakeholder is registered, he can play the role of Expert
User (access to extended functionality or restricted data/services) or
Content Provider (the same as Expert User and the possibility to
publish own data).
Actors User, Administrator
Preconditions Stakeholder has got valid registration with the Portal and is logged in.
Normal Flow 1. User goes to his Personal Page.
2. User selects the “Role Settings” table and chooses the Role.
3. User confirms his choice.
4. The Portal sets the new role.
5. The Portal displays message “Your new role has been set”.
6. Portal sends message to the administrator.
Alternate Flow
Postconditions
Notes
5.4.2 Search, Discovery and Display
Use case UC 2-01 – Search Metadata
Task User searches for data/service using metadata catalogue implemented
into the Portal.
Actors User.
Preconditions Portal includes Data and Metadata Repository.
Portal includes a solution supporting CSW 2.02.
Normal Flow 1. User selects a search functionality.
2. User types a simple keyword (see Alternate Flow 1).
3. Metadata Catalogue Server searches in the internal Data and
Metadata Repository.
4. Metadata Catalogue Server sends a request for metadata to the
External CSW.
5. Catalogue client displays a result of searching.
Alternate Flow 1. Advanced Parameter Searching.
o User selects the Advanced Parameter Searching
button.
o System displays the Advanced Parameter Searching
window with the extended list of parameters,
geographical extent input; relevant Thesaurus should
be included.
o User specifies searching conditions.
o Use case continues in the Step 3 in the Normal Flow.

27/77
Postconditions The result set includes:
- Total number of results.
- Basic information about each result (e.g. thumbnail, title,
abstract, organisation, etc.).
- Expand results to display additional information (e.g. full
metadata record) from the Catalogue.
- A function to display data/service preview.
- A function to add selected data/service into User’s Map Client.
Notes Metadata are regularly harvested.
Use case UC 2-02 – Browse Metadata
Task User searches for data (use case 2-01) and gets a result set. The record
set may contain a great number of metadata records. He needs to work
with the result and find the appropriate record.
Actors User.
Preconditions A set of results of metadata records from searching is available on the
metadata client.
The metadata is sorted by a source catalogue.
Normal Flow 1. User browses the list of metadata. The metadata is signed as
metadata for data or services.
2. User clicks on the metadata preview to get a full metadata
record. The record is shown in a new window; it is better to
use a split window for the list and the detail (See Alternate
Flow 1).
3. User clicks on the Button to get preview of the data/service.
The data/service is displayed in Map Client of the Portal.
4. User goes back to the list or to the detail of the metadata
record.
5. User looks at the detail of other records.
6. If needed, User can join a new catalogue for searching. Then
he repeats searching (see UC 2-02).
Alternate Flow 1. Grouping by parameters.
o User can group a list of results by pre-defined
parameters (owner, year, ...). User selects “Group by
parameters”.
o Portal displays list of results by groups.
o Use case continues by Step 2 of the Normal Flow.
Postconditions User gets information about appropriate data/service.
User is able to view or join data/service into his project/application.
Notes
Use case UC 2-03 – Join a new catalogue (CSW) for searching
Task User searches for data (use cases 2-01, 2-02) and gets a result set. But
the results are not satisfactory, so User needs to extend searching with

28/77
other catalogue.
Actors User.
Preconditions Metadata searched by default catalogue are not satisfactory.
Joined catalogue is relevant to CSW 2.0.2.
Normal Flow 1. To add a new catalogue, User clicks on the button “Add
CSW”.
2. User selects one of the pre-defined catalogues (see Alternate
Flow 1).
3. User clicks on “Add” button.
Alternate Flow 1. Add Custom CSW.
o User types name (title) of the CSW.
o User types URL of CSW.
o If needed, User selects SOAP using.
o User click on “Add” button.
Postconditions New CSW is added to the list. When User makes new search for
metadata, the new CSW is running together with the default one.
Notes
5.4.3 Data Management
Use case UC 3-01 – Import Data
Task Content Provider intends to publish his data on the web. The first step
is to get data from a local storage into the Portal Repository.
Actors Content Provider.
Preconditions Content Provider has set his competence by the Portal’s Authorisation
Service.
Normal Flow 1. Content Provider goes to the Data Management module of the
Portal.
2. Content Provider runs the “Upload Data” function.
3. Content Provider selects data on his computer to upload it on
the Portal.
4. Content Provider chooses the upload into File Repository or
import into Database.
5. Content Provider sets the rights for access to data.
6. Content Provider specifies Licence Condition for the data
utilisation.
7. Content Provider fills in an appropriate metadata record.
Alternate Flow
Postconditions User’s data is stored in the Internal Portal Repository and is
searchable through metadata catalogue.
Notes
Use case UC 3-02 – Compose Data/Service

29/77
Task User wants to create a new map project which integrates internal and
external data sources. This new map project will be published and
then will be available for other users.
Actors Content Provider, User.
Preconditions Content Provider has set his competence by the Portal’s Authorisation
Service.
Data for publication is stored in the Internal Portal Repository.
External data sources are known or discoverable through CSW 2.0.2.
Portal.
2. Content Provider runs “Create Composition” function.
3. Content Provider specifies basic settings of the map project
(name, keywords, referential system, extent, ...).
4. Content Provider selects data sources – Internal Data
Repository (files or database) or External Web Services
(WMS, WFS) or sources accessible through the implemented
CSW.
5. From the selected data source, Content Provider selects
appropriate data/services and adds the map project (see
Alternative Flow 1).
6. Content Provider sets parameters of the content – symbols,
colours, visibility, layers order, ... (see Alternative Flow 1).
7. Content Provider sets/updates metadata of the map project.
8. Content Provider saves the final map project.
Alternate Flow 1. To check the work, Content Provider can display the in-
process map project in the Map Client.
Postconditions The new map project is stored and published as a Map View, or a
standardised web service (WMS, WFS) is established and searchable
through metadata catalogue.
Notes
Use case UC 3-03 – Publish Data/Service
Task Data Provider wants to publish his data as web services.
Actors Data Provider.
Preconditions The competence of the Content Provider is set by the Portal’s
Authorisation Service.
Portal.
2. Content Provider runs “Publication” function.
3. Content Provider selects data for publication.
4. Content Provider sets type of publication (Map View, WMS,
WFS, ...).
5. Content Provider sets the rights for access to data.
6. Content Provider specifies Licence Condition for the service
utilisation.

30/77
7. Portal displays metadata records (going from dataset) and
offers metadata update.
8. Content provider edits metadata record (the data should not be
published without appropriate metadata).
9. Content Provider confirms the service establishment.
Postconditions New service is established and searchable through metadata catalogue.
Notes Publication of Map View means generating a private or public URL
address showing window with map client and User’s data (in this case
one layer).
Use case UC 3-04 – View Dataset
Task User needs to look at the spatial planning data, find detail information
about objects, compare them with the referential data.
Actors User.
Preconditions Map client supporting Open Web Services implemented onto Portal.
Data set available for the map client in the Portal internal repository or
via standardised Open Web Services (WMS, WFS).
Map Client window integrates a box for catalogue searching.
Normal Flow 1. User opens Map Client on the Portal. He can open Map Client
with the specific map project (e.g. municipal plan of city) or he
can use a default project.
2. User can join new dataset from internal Portal Repository. If
needed, data is transformed using transformation service.
3. User can join a new Web Service (see Alternate Flow 1). If
needed, data is transformed using transformation service.
4. User uses available Map Client functionality (zoom, info, ...)
to get relevant information.
Alternate Flow 1. Join Service from the catalogue.
o User can look for new data/service through
implemented CSW.
o User types keyword into catalogue searching box.
o Next steps – see use cases 2-01 and 2-03.
o Continue with step 4 of the Normal Flow.
Postconditions User gets a map or a map composition with relevant information in the
Map Client.
Notes
Use case UC 3-05 – Download Dataset
Task User needs data on his computer (to use them in desktop application,
to update them, ...). He downloads data from the Internal Portal
Repository or from an external data source.
Actors User.

31/77
Portal.
2. Content Provider runs “Download” function.
3. Content Provider searches for data through the CSW (see
Alternate Flow 1, 2).
4. Content Provider selects datasets for download.
5. Content Provider sets parameters for download (see Alternate
Flow 3).
6. Content Provider downloads the data.
Alternate Flow 1. Download from Internal Portal Repository.
o Content Provider accesses file repository or database
according to his authorisation.
o Content Provider selects data to download.
o Content Provider sets download parameters.
o Content Provider downloads the data.
2. Dataset defined by WFS query.
3. Transformation service.
o If transformation process for data is needed (based on
the set parameters), the Portal provides transformation
of data into the requested format.
Postconditions Downloaded data are stored in PC in the requested format.
Transformation service is applied if needed.
Notes
5.4.4 Metadata Management
Use case UC 4-01 – Produce Metadata
Task Content Provider, Expert User authorised for data/service publication
should provide also metadata. When the data/service is prepared for
publication, metadata record is created and stored together with new
data/service.
Actors Content Provider, Expert User.
Preconditions The competence of the Content Provider or Expert User is set by the
Portal’s Authorization Service.
Metadata creator is integrated into the Portal or the Metadata record
has to be in the appropriate profile.
Normal Flow 1. Content Provider or Expert User logs in the Portal.
2. Content Provider or Expert User publishes a new service or
data.
3. Before confirmation, the user chooses the metadata record
creation or updating.
4. Portal runs metadata editor (integrated or external).
5. Content Provider or Expert User updates metadata record.
6. Content Provider or Expert User confirms data/service storing.
7. Portal stores data/service and appropriate metadata record.

32/77
Alternate Flow
Postconditions Metadata is available for searching by CSW2.0.2.
Notes
Use case UC 4-02 – Import Metadata
Task Content Provider doesn’t need to create metadata on the Portal, but he
may import existing metadata records created in external editors.
Data is imported onto the portal together with metadata. Metadata
needs to be in the appropriate structure (profile).
Normal Flow 1. Content Provider logs in the Portal.
2. Content Provider imports data on the server (see Alternate
Flow 1).
3. Portal offers also an import of metadata, if it exists.
4. Content Provider selects appropriate metadata xml and uploads
it on the server together with data.
5. Portal stores imported data and appropriate metadata record.
Alternate Flow 1. Import metadata without data. In some cases, metadata could
be imported individually and joined to data on the server. It is
for example when metadata is created ex post or in external
metadata editors without portal connection.
o Content Provider selects data on the Portal which will
join metadata too.
o Continue with step 3 Normal Flow.
Postconditions Metadata is available for searching by CSW 2.0.2.
Notes
Use case UC 4-03 – Edit/Update Metadata
Task Content Provider, Expert User needs to update or edit metadata stored
on the Portal.
Actors Content Provider, Expert User.
Preconditions The competence of the Content Provider or Expert User is set by the
Portal’s Authorisation Service.
Metadata is stored on the portal in the appropriate profile. Metadata
editor is integrated into the Portal.
Normal Flow 1. Content Provider or Expert User logs in the Portal.
2. Content Provider, Expert User searches for metadata record
that he wants to edit in metadata catalogue.
3. Portal displays metadata record.
4. Content Provider or Expert User runs metadata editor.
5. Content Provider or Expert User updates/edits metadata

33/77
record.
6. Content Provider or Expert User confirms changes.
7. Portal stores updated record.
Alternate Flow
Postconditions
Notes
5.4.5 Data Right Management (DRM)
Use case UC 5-01 – Specification of DRM for Data/Services
Task Content Provider wants to set DRM for his Data/Service.
Preconditions In relevant cases, this use case is included into Data Management (see
use cases UC 3-01 Data Import and UC 3-03 Publish Data/Service).
Content Provider has his own text of the License Agreement on
Data/Service.
Normal Flow ... UC 3-01, UC 3-03: Content Provider sets the access rights to data.
1. Content Provider selects the choice “Set DRM for
Data/Service”.
2. The Portal offers predefined types of DRM.
3. Content Provider selects the relevant DRM type.
4. The Portal offers uploading of the License Agreement text (in
pdf).
5. Content Provider uploads the relevant pdf.
UC 3-01, UC 3-03 continue...
Postconditions
Notes The Portal doesn’t solve any business contract between Content
Providers and Users, only accesses to the data based on the License
Agreement.
Use case UC 5-02 – Access to the Data/Services with DRM
Task User needs to access the data with DRM.
Actors User, Content Provider.
Preconditions To access the data with DRM, User needs to have a valid registration
to the Portal.
Normal Flow 1. User looks for data using catalogue and finds data with DRM.
2. The Portal warns that the data is with DRM.
3. User wants to use data with DRM and sends request for an
access.
4. The Portal notices to relevant Content Provider that the data is
requested. The message contains User’s identification and
details.
5. Content provider approves the request (see Alternate Flow 1).

34/77
6. The Portal notices the approval to the User and offers
acceptation of a License Agreement.
7. User accepts the License Agreement (see Alternate Flow 2).
8. The Portal extend User’s Authorisation.
9. User can work with data with DRM.
Alternate Flow 1. Content Provider refuses the request.
o System notices the refusing to the User.
o System blocks User’s access to the data.
o Use case finishes.
2. User doesn’t accept the License Agreement.
o The Portal warns the User that data will not be
accessible.
o The Portal blocks User’s access to the data.
o The Portal sends notification to the Content Provider.
o Use case finishes.
Postconditions - All requests and decisions are stored in a log.
- Content Provider can list his data and given accesses.
- Content Provider can cancel his approval.
Notes
5.4.6 Monitoring and Control Services
Use case UC 6-01 – Monitoring of the Registration Process
Task Administrator needs a summary of the registration requests.
Actors Administrator.
Preconditions
Normal Flow 1. Administrator goes to his profile.
2. Administrator selects the “Monitoring of registration
requests”.
3. The Portal displays list of the registration requests in the table,
that covers:
o Date.
o Registration is successful/unsuccessful.
o User name (content link to the user’s profile).
o Role.
o User’s IP.
4. Administrator can display user’s profile by clicking on the
“Name”.
5. Administrator can search the table.
Postconditions
Notes
Use case UC 6-02 – Monitoring of the Requests for an access to the
data/service with DRM

35/77
Task Administrator or Content Provider needs a list of the requests for
access to the data with defined DRM.
Actors Administrator, Content Provider.
Preconditions Administrator has the access to all requests. Content Provider can
display only the requests concerning his own Data/Services.
Normal Flow 1. Administrator or Content Provider goes to his profile.
2. Administrator or Content Provider selects “Monitoring of
DRM data access”.
3. The Portal displays list of all requests (depending on
Administrator’s or Content Provider’s rights) for the access to
the Data/Service with defined DRM. The table covers:
o Date.
o User Name (contents link to the User’s profile).
o User’s IP.
o Requested Data/Service.
o Relevant Content Provider (contents link to the Data
Provider profile).
o Request confirmed/refused.
o Licence (link to the text of the relevant licence).
4. Administrator or Content Provider can display text of the
licence and the profile of the User or Content Provider.
Postconditions
Notes
Use case UC 6-3 – Web Analytics Tool
Task Administrator needs web analytics regarding website traffic.
Actors Administrator.
Preconditions
Normal Flow 1. Administrator goes to his profile.
2. Administrator selects “Web Traffic Analysis”.
3. The Portal Analytical component displays the data groups:
o Number of users connected to the web in different
periods.
o Sources of the connection.
o Visited pages/services.
4. Administrator can export or print the Web traffic analytical
report.
Postconditions
Notes
5.5. Core elements
Within the Plan4all system, the core elements are:
- policies;
- services;
- harmonisation;

36/77
- metadata;
- Content Provider and Data.
Particularly important is the element “policies”, which includes the mechanisms necessary to
guarantee security to the services. A proper technical infrastructure has been defined to
support the whole system and will be described in detail in section 8.3.
The following diagram represents the different kinds of policies.
Different kinds of policies.
The Authentication allows verification of the unique identity of the user that ensure the access
to the services.
The Authorisation provides the user with the privileges necessary to access specific
functionalities.
Digital Rights Management (DRM) deal with the management of rights and licenses.
For the implementation of these mechanisms, OASIS and W3C specifications have been
adopted, especially geoDRM specifications for the definition of DRM policies.
Each actor may interact with one or more elements in a different way depending on their
roles.
The following figure shows the high-level object model.

37/77
High-level object model.
The Plan4all system consists in metadata, policies and services. Through these services, the
stakeholders can have access to the Content Providers’ data.
The data provided by the different Content Providers interact with the system through the
Harmonisation Tools and the services implemented by Plan4all.

38/77
6. Information Viewpoint
The Information Viewpoint describes the way that the Plan4all Networking Architecture
stores, manipulates, manages, and distributes information. The major issues which are
analysed and assessed are:
- information structure and content with a clear focus on the metadata and data models
developed through Work Packages 3 and 4;
- information 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;
- management of transactions and recovery of information;
- issues related to data quality including completeness, validity, consistency, timeliness
and accuracy;
- considerations related to data volumes;
- archiving and data retention issues and;
- adherence to regulations and policies.
By assessing these aspects of the Information Viewpoint, a number of findings have been
described which are of impact to the design of the Plan4all Networking Service architecture.
6.1. Information life-cycle
The information life-cycle of spatial planning data (maps) and documents as envisaged within
the framework of Plan4all consists of the following steps:
Step Description
Creation Data (maps) and documents are born through the creative planning process
whereby areas, lines and point features are assigned functions according to
national/regional spatial planning regulations.
The input to this phase is typically any thematic information plus preceding
or higher-level spatial plans for the same area. It is also relevant to identify
“neighbouring” plans on the same level created by the same or parallel
administrations.
Refinement Throughout the planning process, data (maps) and documents are exposed to
additional stakeholders to those who are directly involved in the creative
process for feedback. Following this feedback, initial data (maps) and
documents are modified and new versions are presented for further
comments and inputs.
Approval Following the completion of the creative planning process and any legally
mandated public hearing processes, the spatial planning data and documents
are printed and raised to the appropriate political body for approval.
In most EU Member State legislations, with the exception of the
Netherlands, the legally adopted spatial plan is the hard-copy version – not
the digital data. The plan is therefore a composite of base map data, thematic
data and planned land-use polygons. This leads to a split management
regime from this point onwards.
The reason for this is partly dated legislations and governmental practices
and partly legal precedent in terms of property disputes resulting from

39/77
detailed planning in high-value urban areas where the line-thickness of a
land-use polygon boundary has a great economic significance in terms of
e.g. compensation for expropriation. This does however put some limitations
on how the digital data may be re-used.
Use Having been approved, the spatial planning data (maps) and documents enter
into the “production” phase where they are used as underlying decision and
guidance documents for controlling large and small-scale physical
development.
The traditional stakeholders of this type of use are public administrations
with sector or overall responsibilities for approving and issuing no-
objection-certificates for public, private and individual development and
construction projects.
Publishing The traditional publishing of spatial planning data (maps) and documents
was in the form of printed copies available for review and consultation from
the local planning office.
A more recent addition to the life-cycle of spatial planning data and one that
is critical to the vision of Plan4all is the publishing of spatial planning data
as data and services over the public Internet indiscriminate of the intended
purpose of any re-using party.
This involves making data available through open protocols like WMS (view
services) and WFS (download services) and providing a suitable cartography
and metadata to support third parties in understanding the quality and nature
of the data.
While the named protocols above enable re-use of spatial planning data, an
essential step of the publishing is to expose the materials in such a manner as
to make it discoverable for potential users. This is typically achieved through
the implementation of interoperable catalogue services (e.g. CS-W).
Re-use The re-use domain for spatial planning data is largely “uncharted territory”
in that there is an infinite number of use-cases which may exist among re-
users.
Envisaged use-cases include geospatial analysis for location of new
businesses and development areas as well as real-estate advisory services.
The recent developments of the Web 2.0 and Semantic Web communities
and their mash-ups based on light-weight web services and Linked Open
Data have shown that it is impossible to pre-empt or even predict potential
uses of data. The ruling philosophy is therefore to make as much “raw data”
as possible available with as little effort as possible.
Periodical
revision
Planning data typically has a validity period which is defined by the national
or regional legal spatial planning framework.
Upon expiry of this validity period the plan shall be replaced by a revision,
taking into account new or additional spatial development trends and
requirements.
Information life-cycle of spatial planning data.
For the purpose of Plan4all, the Publishing and Re-use steps of the information life-cycle are
of great importance and the analysis of the Information Viewpoint therefore dwells
specifically on this topic.
The Publishing step is a new and somewhat alien concept to the spatial planning process in
that it involves technical rather than planning skills. Due to spatial plans largely being treated

40/77
as complete maps rather than individual land-use polygon datasets, the disciplines involved in
publishing a spatial planning map and its associated documents are equally complex as in
running a full-fledged spatial data infrastructure (SDI).
“Zooming” in on the publishing step, we will see that it consists of the following elements:
- preparation of data in accordance with the Plan4all/INSPIRE data models;
- preparation of metadata in accordance with the Plan4all/INSPIRE metadata models;
- installation of Internet infrastructure and server hardware;
- installation of web and application server software for discover, view and download
services;
- configuration of cartography for view services;
- configuration of security;
- monitoring, running and maintenance of data, software and hardware infrastructure.
These tasks are comprehensive and technology intensive and require additional skills to those
commonly found in local planning authorities. This puts a constraint on the Plan4all
networking service architecture that it must be implementable with minimal capital
investment and work effort.
6.2. Information flow model
The flow of information between the different processes and actors in the Plan4all networking
service architecture has great significance for the specification. In order to understand the
flow it is important to understand which parts of the communication is publishing based and
which are based on user interaction through open services interfaces.
The above diagram shows the information flow between planners and re-users of planning data in the Plan4all networking
service architecture.
The originating point for planning data is the local planning authority, symbolised by the
planner. He or she creates the planning data (maps) and documents throughout the creative
planning process using CAD or GIS tools – providing basic data as output.
From the planner, data can find two ways to the overall INSPIRE/Plan4all infrastructure: a)
directly from a local administration acting as both data and service provider or; b) through

41/77
third-party service providers acting as “web hotels” for planning data (maps) on behalf of
planning authorities or administrations which for one reason or the other are unable or
unwilling to run their own infrastructure.
The service provider is responsible for exposing OWS interfaces to the Internet, to be
consumed by the INSPIRE and the Plan4all Geo-portals and pan-European registry, as well as
by end-users making individual requests to Discover, View or Download services.
The sequence of events is that the re-user queries the INSPIRE/Plan4all Geo-portal for data
sets of a specific type for a specific area. The query returns metadata on a number of
resources which may then be accessed directly from the service provider over OWS request
protocols like WMS (view services), WFS (download services) and CS-W (discover
services).
6.3. Information data model
Understanding the relationships among the individual types of information involved in the
Plan4all architecture is essential to be able to satisfy service provider and end-user
requirements.

42/77
The above data model shows the relationships among the individual information components of the Plan4all Networking
Architecture.

43/77
At the heart of the information model lies the spatial plan. A spatial plan is an abstract
information entity which consists of three parts:
- one or more spatial planning documents;
- zero or more spatial planning data sets;
- zero or more map compositions.
For this reason, a spatial plan may not be treated as one individual file or entity – but as a
group of heterogeneous resources with strong dependencies. The data model and nature of the
spatial plans will vary significantly between different planning legislations – and to secure
interoperability, a harmonised view or transformation of the data model must be provided as a
distinctive data set.
The spatial plan and the harmonised data set are both associated with metadata which are
published through a discovery interface which is called a catalogue service. This service will
provide discovery and web service interfaces for performing searches and look-up in
metadata.
The metadata will cover four different aspects:
- metadata for the abstract spatial plan including an URI reference to an online
accessible version of the planning documents;
- structured metadata for the harmonised spatial planning datasets;
- geo-rights management metadata to handle restrictions and legal obligations
associated with the spatial data;
- spatial services metadata to provide the ability to connect to actual OWS web services
based on query result data from the catalogue service.
The underlying data will be exposed through a set of INSPIRE services as described below:
- original datasets, harmonised datasets and metadata will be exposed through spatial
planning services like discover, view and download;
- harmonised datasets may be created through online transformation of original datasets
through transformation services using the Plan4all data model as input.
In the absence of a functional INSPIRE Geo-portal with a pan-European registry-layer, the
Plan4all geo-portal temporarily serves this purpose and provides both a metadata profile and
an exchange data model for spatial planning related data.
6.4. Principal information types
In this section the most important information types in the architecture are defined and
discussed in greater detail.
6.4.1 Spatial plan
Spatial planning refers to the methods used by the public sector to influence the distribution
of people and activities in spaces of various scales. Spatial planning includes all levels of
land use planning including urban planning, regional planning and environmental planning,
etc.
While from a GIS perspective, spatial plans are often thought of as maps and data – these are
usually mere visualisations which support a comprehensive textual description of the spatial
development policies for an administrative area.
This means that spatial plans may not be shared successfully if one only considers spatial data
service protocols. Access to underlying documents is equally or more important to interpret
and contextualise the information contained in the spatial data sets.

44/77
6.4.2 Metadata
Metadata is loosely defined as data about data. Metadata is a concept that applies mainly to
electronically archived or presented data and is used to describe the a) definition, b)
structure and c) administration of data files with all contents in context to ease the use of the
captured and archived data for further use. For example, a web page may include metadata
specifying what language it’s written in, what tools were used to create it, where to go for
more on the subject etc.
When taking information out of its original scope and making it available out of context, a lot
of metadata which are considered implicit (and therefore redundant) by the local
administration or planning authority is very important.
There are hundreds of common coordinate systems in active use across Europe using all sorts
of datum points, ranging from the corner of the town-hall to UTM. When creating data in a
local application this information is given – but when the data are received by a third-party
this becomes crucial metadata in order to successfully understand and use the data.
For maps created using CAD tools, there may occasionally not even be real-world coordinates
for the maps – and they must be manually registered to geographical space.
6.4.3 Spatial data
Spatial data are data which define a location. Spatial data are usually expressed in the form
of graphic primitives that are usually either points, lines, polygons or pixels and associated
one- or multi-dimensional attributes.
Spatial data can originate from multiple sources. In the planning world, detailed plans are
very often made in CAD systems – reflecting the fact that the legal documents often are the
printed ones – not the digital data. For this reason CAD tools are very good for making quick
and accurate drawings which correspond to the drawing and cartographic visualisation rules
of planning legislations.
The Plan4all architecture considers spatial planning data as GIS datasets – that is, geometrical
primitives representing logical planning features, carrying rich information attributes. In order
to bridge the gap between the two information paradigms, it is necessary to introduce services
which are able to translate back and forth between the two software environments.
The two-way translation is important because it is not possible to envisage that a data sharing
infrastructure will impact the way in which data are created and used at all planning
authorities across Europe – but will have to adapt flexibly to the existing conditions.
6.4.4 Document data
An original or official paper relied upon as the basis, proof, or support of anything else,
including any writing, book, or other instrument conveying information pertinent to such
proof or support.
While the spatial data standards have sophisticated protocols for look-up and use via OWS
protocols, document data are completely free-form and therefore allow for more limited
capabilities in terms of information integration and cross-searches.
However, in order to understand a spatial planning map or dataset it is essential to have access
to the document providing the description and detail of the different land-use purposes which
are assigned to polygons, lines and points. It is therefore necessary to identify a standard way
of publishing the spatial planning documents in such a way that they are strongly linked with
the spatial data.
While foreign language is an issue in attribute data and code lists, it is a more severe issue
when it comes to planning documents written in national languages. This is of course an
impediment to successful interpretation of spatial planning documents – but may to a certain
degree be mitigated by automated translation tools which will not produce semantically
correct output but which may prove evidence towards the meaning of the original text and

45/77
give sufficient background for knowledgeable users to determine if they want to translate the
passage or not.
6.5. Important findings for the implementation of the architecture
The following are the most important findings from the analysis of the Plan4all networking
service architecture from the Information Viewpoint:
- the architecture must serve documents in addition to spatial data types;
- the architecture must be able to consume and deliver data to and from GIS and CAD
software environments;
- there must be a strong link between metadata and data in order to secure effective re-
use of data discovered through the INSPIRE Geo-portal metadata catalogue;
- there must be a facility in place to provide transformation from local coordinate
reference systems to well-known, standard coordinate reference systems;
- the implementation of the infrastructure must be applicable in an environment where
the stakeholders’ principal skills lie in thematic disciplines like planning and who have
limited knowledge of the disciplines required to run an SDI.
6.6. Formal Information Viewpoint language
In the ISO/IEC 19793-2008, an international standard defining UML profiles for use when
modelling system architectures in conformance with RM-ODP, the Information Viewpoint
language is defined as follows:
“...The individual components of a distributed system should share a common understanding
of the information they communicate when they interact, or the system will not behave as
expected. These items of information are handled, in one way or another, by information
objects in the system. To ensure that the interpretation of these items is consistent, the
information language defines concepts for the specification of the meaning of information
stored within, and manipulated by, an ODP system, independently of the way the information
processing functions themselves are to be implemented.
Information held by the ODP system about entities in the real world, including the ODP
system itself is modelled in an information specification in terms of information objects, and
their relationships and behaviour. Basic information elements are modelled by atomic
information objects. More complex information is modelled as composite information objects
each modelling relationships over a set of constituent information objects.
The information specification comprises a set of related schemata, namely, the invariant,
static and dynamic schemata:
- an invariant schema models relationships between information objects that must
always be true, for all valid behaviours of the system;
- a static schema models assertions that must be true at a single point in time. A
common use of static schemata is to specify the initial state of an information object;
- a dynamic schema specifies how the information can evolve as the system operates.
...”.
RM-ODP in its native form is a methodology which is good to define in detail technical
system architectures for and by technical experts. Due to the nature of the stakeholders in the
Plan4all architecture, a simplified approach has been chosen in modelling the different
viewpoints. The purpose of this is to enhance the understanding of the model for non-GIS-
professional, non-technical stakeholders who play key roles in the information flow.

46/77
7. Computational Viewpoint
7.1. Concerns
The computational viewpoint enables distribution through functional decomposition of the
system into 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 is Service Oriented, based on publish-find-bind paradigm.
The primary components identified for P4All are described below.
7.2. Access Control Services (ACOS)
As the Geoportal 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 communication
frontend for various “clients”, where client means everything from desktop application to
mobile service.
The Access Control Service in composed by:
- Access Interface:
o SOAP – whole functionalities of ACOS Core are available throw SOAP
WebService interface. This is very important for use by many different devices
(server, desktop, mobile) and platform (Windows, .NET, Java, …);
o OAuth – allows users to share their private resources stored on geoportal (in
any application of geoportal) with another site/application without having to
hand out their credentials;
o OpenID – each user registered on ACOS (Geoportal) has automatically an
OpenID identificator which allows users to login to external applications with
it.
- 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.
- Management console:
o web application for managing objects inside ACOS (users, user groups,
permissions, parameters).
7.2.1 Interfaces
The component proposes itself to the system through the only interface control.

47/77
7.3. Application services
It is a fundamental component including all the processes necessary to the users in order to
employ the functionalities supplied by the system.
The application services allow to:
- search metadata:
o through the horizontal service, invoke the search metadata service of “metadata
services”;
o receive the “package” of results to display from the “portrayal services”,
“through” the horizontal service, and display it to the user in terms of list of
metadata records that match search criteria.
- “receive” a metadata record (the user can be human or another system):
o invoke the get metadata service of “metadata services” through the horizontal
service, to request a specific record;
o receive the metadata record to be displayed to the user from “portrayal
services”, through the horizontal service, and return it to the user.
- “manage” (produce, import, upload, edit/update) metadata, through the horizontal
service, using the metadata services;
- view or download a dataset:
o view:
 through the horizontal service, invoke data services;
 allow the user to interact with data (pan, zoom, overlay) calling “view”
services of data services;
 return to the user the data (map, overlays, …) to be displayed from the
“portrayal services”;
o download:
 through the horizontal service, invoke “download” data services;
 return to the user the features data received from the “portrayal
services”.
- send the request to appropriate services transformation to transform data:
o through the horizontal service, invoke the service SRS transform of
“processing services”;
o through the horizontal service, invoke the format transformation service of
“processing services”;
o return to the user the data received from the “portrayal services”.
- perform a transformation of unharmonised data (the user can be human or another
system):
o through the horizontal service, invoke the “harmonization service”:
 the user input – such as source and target schema and mapping
metadata – is passed to the harmonisation service.
- register or invoke services in the service registry:
o “register” – the service provider will use this service to “publish” a service
onto the service registry: through the horizontal service, invoke the publish
service of the “registry services” component;
o “search” – the user or a generic service consumer will use this service to
search/discover a service into the registry: through the horizontal service,
invoke the find service of the “registry services” component;
o “locate” – the user or a generic service consumer will use this service to obtain
service metadata for a service registered into the repository: through the
horizontal service, invoke the bind service of the “registry services”
component.

48/77
7.3.1 Interfaces
The component does not expose interfaces.
7.4. Portrayal services
The task of this component is to visualise the results from the component Application
services.
This component is essentially a renderer.
The portrayal 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.
7.4.1 Interfaces
The rendering is accessed through the interface portrayal delivery.
7.5. Metadata services
This component provides the access to Plan4All 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.
7.5.1 Operations
- get discovery service metadata (get capabilities);
- discover metadata:
o get metadata records (through search);
- get metadata record (by resource unique ID identification).

49/77
7.5.2 Interfaces
The component operations are accessed through the interface capture metadata.
7.6. 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.
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 “portrayal 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.
Moreover, this component uses the GeoRM services to apply access limitations.
7.6.1 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.
7.6.2 Interfaces
The component operations are accessed through the interface capture data.
Also, the component uses the following interfaces from other components:
- harmonisation services :: mapping data;
- horizontal services :: control.
7.7. Processing services
This component implements transform services (D3.5 – INSPIRE Network Services
Architecture v2.0), thus exposes map/feature transform services.
It exposes services to:

50/77
- 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).
7.7.1 Operations
- get transformation service metadata (get capabilities);
- transform (transform coordinates).
7.7.2 Interfaces
The component operations are accessed through the interface data delivery.
- data services :: capture data;
7.8. Harmonisation services
This component is invoked by the component Data Services in order to carry out the mapping
between the application schemas of Plan4all 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:
- 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.
7.8.1 Operations
- transform data.
7.8.2 Interfaces
The component operations are accessed through the interface data mapping.
7.9. Registry services
This component implements invoke services.
Invoke: for spatial data services available on the Internet, the “Invoke Spatial Data Service”
service will enable a user or client application to run them without requiring the availability of

51/77
a GIS. This requires that a client application can discover the service, bind to it and invoke it
(source: D3.5 – INSPIRE Network Services Architecture v2.0).
In this scenario, 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.
The following diagram shows the “publish-find-bind” pattern.
Provider
Service
Repository
(Registry)
Consumer
(Client)
publish
find
bind
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 locate a service;
- the service consumer finds services via the registry and binds to the provider using
service metadata.
7.9.1 Operations
- register service through its metadata;
- search service (query service metadata repository);
- get service metadata (get capabilities).
7.9.2 Interfaces
The component operations are accessed through the following interfaces:
- register;
- publish;
- search.

52/77
7.10. Relations among components
The relations among the components may be schematised as follows.
General schema.

Plan4all Networking Architecture

Plan4all Networking Architecture

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (18)

Similar to Plan4all Networking Architecture

Similar to Plan4all Networking Architecture (20)

More from plan4all

More from plan4all (20)

Plan4all Networking Architecture