INSPIRE
Infrastructure for Spatial Information in Europe
Detailed definitions on the INSPIRE
Network Services
Title
Detailed definitions on the INSPIRE Network Services
Creator
Joint Research Centre, Institute for Environment and Sustainability, Land
Management Unit, ESDI Action
Date
2005-07-22
Subject
INSPIRE Implementing Rules for Network Services
Status
First Version
Publisher
JRC-Institute for Environment and Sustainability, Ispra
Type
Text
Description
The INSPIRE Directive proposed by the European Commission calls for
Implementing Rules on a number of topics. This report provides
definition of the Network Services and the associated draft Implementing
Rules. It is the first version of deliverable D 3.1 foreseen in the INSPIRE
Work Programme Preparatory Phase 2005-2006.
Format
MS Word 95/2000 (doc)
Source
Not applicable
Rights
INSPIRE working group members. © Commission of the European
Communities.
Identifier
Detailed Definitions on the INSPIRE network Services V1.1.doc
European Commission, Joint Research Centre, 2005
Language
En
Relation
Proposal for a Directive on the establishment of an Infrastructure for
Spatial Information in the Community (INSPIRE) - COM(2004) 516
INSPIRE Work Programme Preparatory Phase 2005-2006
Coverage
Temporal: name=start=2005-07-11 end=2006-12-31
EU25
These are Dublin Core metadata elements. See for more details and examples http://www.dublincore.org/.
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
Version history:
Version number
0.1
0.2
1.0
1.1
Date
2005-07-11
2005-07-21
2005-07-22
2005-09-07
Comments
First Draft
First Review Cycle
First Release
Second Review Cycle
9/7/2005
Page ii of 19
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page iii of 19
Table of contents
Introduction............................................................................................................................................ 1
Scope ...................................................................................................................................................... 1
Definitions .............................................................................................................................................. 1
High level requirements ....................................................................................................................... 1
Detailed Definitions .............................................................................................................................. 2
Link with the other Chapters............................................................................................................. 2
Technical Clarification ...................................................................................................................... 2
Services Definition ........................................................................................................................ 2
Services Context........................................................................................................................... 3
Functional Requirements ................................................................................................................. 4
Upload Services............................................................................................................................ 4
Discovery Services ....................................................................................................................... 4
View Services ............................................................................................................................... 6
Download Services ....................................................................................................................... 7
Transformation Services............................................................................................................... 8
“Invoke Spatial Data Services” Service ...................................................................................... 10
Implementing Rules Definitions...................................................................................................... 10
Overall Content ........................................................................................................................... 10
Detailed Content ......................................................................................................................... 11
Service Requirements............................................................................................................. 11
Functional and Technical Specifications................................................................................. 11
Interoperability......................................................................................................................... 12
Reference material.................................................................................................................. 12
Assessment of Fitness for Purpose ........................................................................................ 15
Network Services Implementation Strategy ............................................................................ 15
Procedures for Conformance Assessment ............................................................................. 15
Strategy for Maintenance ........................................................................................................ 16
Cost benefit analyses.............................................................................................................. 16
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 1 of 19
Introduction
The INSPIRE Directive proposed by the European Commission calls for the development and
adoption of Implementing Rules on a number of topics. This report provides detailed definition of the
Network Services, by:
- Extracting from the directive the requirements directly applicable to the Network Services
- Providing for each service, a proposed understanding and whenever applicable a list of
assumptions and issues.
- Developing the content of the Network Services Implementing Rules.
It is also the first draft of deliverable D 3.1 foreseen in the INSPIRE Work Programme Preparatory
Phase 2005-2006.
Scope
The scope of this document is twofold:
- For the Network Services Drafting Team and the JRC to reach a common understanding of
the INSPIRE Network Services technical requirements.
- To create a reference point for the development of the Network Services Implementing Rules.
Definitions
High level requirements
The INSPIRE Proposal requires Member States:
• To establish and operate upload services for making metadata and spatial data sets and
services accessible through the Network Services (Article 17).
• To establish and operate a network of the Network Services for the spatial data sets and
services for which metadata have been created (Article 18).
The Network Services Implementing Rules shall be based on the following principles:
• Ease of use and accessibility via the Internet or any other appropriate means of
telecommunication available to the public (Article 18, 1).
• take into account technological progress and minimum performance criteria (Article 22, a)
• based on infrastructures for spatial information established and operated by the Member
States (Directive recitals).
The Implementing Rules for the Network Services will in particular address:
•
•
•
•
•
•
General architectural model
Security (access to the service and data transfer) when applicable
Multilingualism as requested by INSPIRE.
Compliance with services metadata and impact
Technical architectures and protocols
End-users’ needs.
And the development of the technical specifications of the Network Services, its schedule and priority
setting will be driven by:
• Maturity of available reference materials
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
•
9/7/2005
Page 2 of 19
Schedule for the development and implementation of the other Implementing Rules.
Detailed Definitions
Link with the other Chapters
The Arrangements for the exchange of spatial data and the Geo-Portal are not formally part of the
Network Services Implementing Rules development, but will nevertheless play an important role.
Following the INSPIRE proposal, the arrangements for the exchange of spatial data links specifically to
the harmonized data specifications implementation rules for its technical content, while the geo-portal
will not be part of the Network Services Implementing Rules as it is a commission internal
development.
A separate document will detail the architecture and requirements of the Geo-Portal in line with the
requirements and developments in the network services chapter.
Service metadata are not only for INSPIRE Network Services, but for spatial data services as indicated
in article 6 of the Directive proposal.
For what concerns the e-commerce services specifications and Implementing Rules, they may refer to
existing European/National legal frame and relative technical documents whenever applicable such as
the Directive 2000/31/EC of the European Parliament and of the Council of 8 June 2000 on certain
legal aspects of information society services, in particular electronic commerce, in the Internal Market
('Directive on electronic commerce'). A special attention may be required on Digital Rights
management and its impact on e-commerce services..
The multilingualism is only mentioned in the frame of the interoperability of spatial data sets and
services for their key attributes and the corresponding multilingual thesauri commonly required for a
wide range of thematic policies. The Network Services will most certainly provide access to these
attributes and will therefore have to address the multilingualism issue. Therefore questions like the
following will have to be answered with the other drafting teams:
- Granularity: should the list of available languages be a service feature or at the data set or
even at the feature attribute level ?
- Metadata/Data: should only metadata be multilingual or datasets as well ?
- Attributes label versus Attribute value: Should only attributes label be multilingual or should
the attribute’ values be as well multilingual?
Technical Clarification
Services Definition
A proposal to the Drafting Team is to consider the services called for in the directive as Web Services,
defined by W3C in http://www.w3c.org/TR/ws-arch/. According to this a Web service is a software
system designed to support interoperable machine-to-machine interaction over a network. It has an
interface described in a machine-processable format (specifically WSDL). Other systems interact with
the Web service in a manner prescribed by its description using SOAP messages, typically conveyed
using HTTP with an XML serialization in conjunction with other Web-related standards.
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 3 of 19
Services Context
Figure 1 schematically represents the objectives of the services technical specifications, more
precisely:
-
-
The back end of the Network Services is out of the technical specifications scope. The way the
services will effectively access the Member State data is explicitly excluded. The main
justification is based on our understanding of the existing infrastructure where these interfaces
are implemented in different ways,
For the services requiring technical specifications (article 22) the User Interface and in
particular its design, functionality and layout is not included in the technical specifications, the
only requirement in the directive related to look and feel is that those services shall be easy to
use and accessible via the Internet or any other appropriate means of telecommunication
available to the public.
INSPIRE
SERVICE
SPECIFICATIONS
INSPIRE
SERVICE
DATA
AND
METADATA
Figure 1 Service Technical Specifications
The link with legacy systems and the constraints they put on the technical specifications and the
definition of the Implementing Rules is also to be explicitly considered.
To better set-up the scene, the following assumptions, still to be confirmed by the Drafting Teams, are
an example of the kind of issue that may need to be resolved early in the Network Services
Implementing Rules development process:
- When data is involved in a service, by default it is INSPIRE harmonized data, except for the
upload service.
- When metadata is involved in a service, it is exclusively INSPIRE metadata.
- A set of default coordinate reference systems is assumed available for all “data” services (e.g.
a set of European Coordinate Reference Systems) with the potential exception of the upload
service.
- A unique way to identify datasets and spatial services is available
- The metadata contains a cross reference to the data or spatial service.
- they Spatial Data Services are wide range and not only “on-line” services, they could include
as well services like consultancy services.
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 4 of 19
Functional Requirements
Upload Services
Definition
Member States shall establish and operate upload services for making metadata and spatial data
sets and services accessible through the services referred to in Article 18(1).
Potential Interpretations
One of the following:
•
•
Data and Service Physical Transfer to a Member State storage facility
Data and Service Availability Declared in a Member State facility
Proposed Assumptions
Only the upload of data and metadata (of data and services) are to be considered; more precisely
uploading software packages is outside the upload service scope.
Figure 1 applies to the upload services meaning that only the communication between the user and
the MS upload facility are in the scope.
The content and format of the uploaded data and metadata shall not be part of the upload service
technical specification as these are covered in the harmonized data and metadata specifications
Potential Issue
Scope of service
The above given understanding also excludes management (like handling updates, contents,
confidence and consistency checks, creation of UIDs,…). This understanding has to be confirmed also
with the other drafting teams and may still require a close collaboration with the other Drafting teams..
Operation Outcome Status and Content Compliancy Check
It is customary in the most recent implementation of an upload service to provide a feedback on the
status of the outcome of the upload operation and to perform a content compliancy check on the
provided information, the level of specification for this functionality is still to be defined as it could
range from overall success or failure with or without few generic error messages to a more thorough
and complex diagnostic tool.
Originator Profile
For property rights, moderation of the content, maintenance, update and other considerations such as
access control, it may be seen beneficial to link the upload service to an authentication/authorisation
mechanism whose implication and level of acceptance are still not fully comprehended.
Discovery Services
Definition
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 5 of 19
The MS shall establish and operate discovery services making it possible to search for spatial data
sets and spatial data services on the basis of the content of the corresponding metadata and to display
the content of the metadata;
For the purposes of the discovery services, as a minimum the following combination of search criteria
shall be implemented:
a) keywords;
b) classification of spatial data and services;
c) spatial data quality and accuracy;
d) degree of conformity with the harmonised specifications provided for in Article 11;
e) geographical location;
f) conditions applying to the access to and use of spatial data sets and services;
g) the public authorities responsible for the establishment, management, maintenance and
distribution of spatial data sets and services.
Proposed Interpretation
Self Explanatory, no further interpretation needed.
Proposed Assumptions
The handling of the catalogues distribution is out of the scope of the discovery services technical
specifications and Implementing Rules.
Search criteria are available in the metadata, even the ones not explicitly listed in article 8 of the
directive (i.e. Keywords, classification of spatial data and services, geographical location)
Potential Issues
Link with INSPIRE data metadata technical specifications
In an ideal world, the discovery services technical specifications could be fully independent of the
chosen metadata conceptual schema therefore allowing easy evolution and promoting independence
from it, but past experience has proved it not to be always the case for example for fields cross linkage
or formal dependencies.
Query Language Complexity
The technical specification of a discovery service implies implicitly or explicitly the choice of a query
language which complexity and completeness requirements will be defined with the drafting teams. It
could rely on existing and complex standards for example ISO/IEC 9075 and could be decoupled from
the discovery service specifications.
Independence from Metadata Catalogue Schema
To ensure flexibility, a discovery service technical specification should be fully independent of the
target metadata catalogue schema.. That way the Member States are free to design, implement and
operate metadata catalogues according to their own needs
Link between Data and Service Metadata
Some metadata elements will be in common between the data and service metadata, the sharing of
this information and the commonalities will have to be defined and managed (for example the spatial
accuracy that is applicable as well to spatial data services such as coordinate transformation services).
Ranking of Results
Should there be a significant of results for a query, the issue of results ranking becomes critical and
should therefore be addressed in the technical specifications of the discovery service
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 6 of 19
Single Access to Data and Services
It is still to be confirmed that a unique technical specification can satisfy both data and services
discovery.
View Services
Definition
The MS shall establish and operated view services making it possible, as a minimum, to display,
navigate, zoom in/out, pan, or overlay spatial data sets and to display legend information and any
relevant content of metadata;
Proposed Interpretation
The minimum set of features is straightforward with the potential exception of the display of the
relevant content of metadata that needs to be further refined once the spatial datasets metadata
content is known
Proposed Assumptions
The mentioned metadata are to be considered as the INSPIRE metadata requested in the directive
proposal.
Potential Issues
Availability of metadata
It is not yet clear what are the constraints and consequences of the availability in the view service of
the data metadata to be provided and accessed by the discovery service, both services being
considered as independent (see encapsulation and unique ID assumptions above). For example the
availability of a metadata URL in the first response to a view request transaction would assume that:
- The dataset ID is unique and available to the view service.
- The discovery service URL is known to the view service,
- The discovery service supports the HTTP get method
- The discovery service does not request preliminary transaction (version negotiation,…) before
accepting a metadata request.
- The discovery service supports the dataset ID as a query parameter
Nature of the Metadata request
The directive asks for metadata to be available, the issue is then about the underlying dataset
described by this metadata, is it metadata of the view (e.g. map) provided by the service or is it
metadata of the original representation of the data (e.g. electronic version).
Legend Availability and Handling
The directive asks for the legend to be provided and to overlay views of different datasets. The issue is
then should the legend be provided as machine readable (e.g. XML) for further
harmonization/customization of the different views.
Multiple View Geometry
The directive asks for the view service to allow the overlay of different datasets. These datasets could
use different Coordinate Reference Systems. There are 2 issues that will then need to be addressed:
- Link the Annex I Spatial Data Theme “Coordinate Reference Systems”
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
-
9/7/2005
Page 7 of 19
The definition of default Coordinate Reference Systems for the simultaneous view of different
datasets.
Multiple View Output Format
The directive asks for the view service to allow the overlay of different datasets. The view of different
datasets could use different formats, therefore should a default output format be requested?
Even if potentially less advanced in terms of availability in geographic Information Systems and
potentially less widely accepted for technical and data distribution policy reasons, the MANDATORY
availability of the Scalable Vector Graphics format (http://www.w3.org/Graphics/SVG/) and associated
tools may represent a viable alternative to the raster based visualisation of maps especially if the
harmonised data specifications requires and XML-like representation therefore potentially easing the
transformation from data XML format to SVG. The handling of native raster data such as Earth
Observation Data would therefore have to be taken specifically into account.
Restriction of access and e-commerce
The functionality and display format shall be compatible with digital right managements and restriction
of access and use as envisioned in the directive proposal.
Download Services
Definition
The Member States shall establish and operate download services, enabling copies of complete
spatial data sets, or of parts of such sets, to be downloaded;
In addition, where public authorities levy charges for the download services, Member States shall
ensure that e-commerce services are available.
Proposed Interpretation
This service aims at providing a user with the ability to access freely or not subsets of datasets. The
definition of the subset is left to interpretation as it could be only through the definition of a region of
interest, but could also encompass layers/features selection and even attributes linked with the
features
Proposed Assumptions
The download service technical specifications shall be independent of the data reference model, data
format and content, For example, a user through a land cover dataset metadata discovers that he/she
could request the spatial theme forest without been requested to know the internal organisation of the
dataset or its format.
For what concerns the explicit mention of e-commerce service, we are proposing that is follows the
communication scheme of figure 2 with the download service technical specifications covering only
the definition of the spatial dataset subset of interest and fully compliant with the INSPIRE metadata
Implementing Rules.
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 8 of 19
Subset
Definition
DOWNLOAD
SERVICE
Subset
Data
Subset
Metadata
MS
E-COMMERCE
SERVICE
e-commerce
Transaction
Figure 2 Download and E-commerce services
Potential Issues
Independence from the data model/content
The Independence from the data model/content is true as long as the subset selection can be done
through the metadata associated with the dataset, so should the attribute level be considered (e.g.
extract the authorised usage for a cadastral parcel that could contain the name of the owner as well), it
would imply that a dataset has only one set of attributes and the metadata contains this list of
attributes
Content of metadata
To support the functionality listed above requires the availability of metadata containing fairly low level
description of the content. Therefore the issue is to ensure this availability.
Transformation Services
Definition
The Member States shall establish and operate transformation services, enabling spatial data sets to
be transformed.
The transformation services shall be combined with the other services referred to in that paragraph in
such a way as to enable all those services to be operated in conformity with the Implementing Rules
laying down the following:
(a) harmonised spatial data specifications;
(b) Arrangements for the exchange of spatial data.
Proposed Interpretation
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 9 of 19
This set of services is the one with the widest range of potential interpretation, as it can go from the
change of coordinate systems, to schema mapping, encoding or generalisation.
The first proposal to the drafting team is to limit it to coordinate transformation services and
generalisation (to the extent of feasibility)
For what concerns the combination with other services a schematic scenario is depicted in figure 3
involving the combination of the discovery, download, and transformation services with the output and
input of each Network Service always being compliant with the harmonised data specification and
rules for the exchange of spatial data.
DISCOVERY
SERVICE
DOWNLOAD
SERVICE
MS
E-COMMERCE
SERVICE
TRANSFORMATION
SERVICE
Figure 3 Combination of Services
With the preservation of the constraints and characteristics
Proposed Assumptions
The allowed transformation would be from a set of National SRS to the harmonised spatial data theme
“coordinate reference systems” and from the harmonised spatial data theme “coordinate reference
systems” to the same set of National SRS (TBC). An example for the latter is to help an end user to
use a specific tool working directly on the original data set using the original SRS.
Potential Issues
Relationship with the spatial data services
In the directive proposal the spatial data services are defined as the “operations which may be
performed, by invoking a computer application, on the spatial data contained in those data sets or on
the related metadata”.
So should an unambiguous split be sought, Statements like “a coordinate Transformation Service is as
well a Spatial Data Service” should be avoided. Therefore a classification scheme must be put in place
in agreement with all interested parties.
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 10 of 19
The distinction could be done on the following:
Through the transformation service definition (everything a transformation service is not)
- Availability on the internet: A transformation service must be available for activation on the
internet a spatial data service does not have to be (off-line processing, stand-alone
applications, …)
- Output: a spatial data service does not have to, it could be a numerical or statistical
computation, or even a complex simulation or modelling.
Combination of Services
The proposed understanding implicitly requires to precisely define the interactions between the
INSPIRE Network Services should these services be integrated in national access points and more
importantly will be integrated in the Community geo-portal.
“Invoke Spatial Data Services” Service
Definition
The Member States shall establish and operate “invoke spatial data services” services, enabling data
services to be invoked.
Where public authorities levy charges for the “invoke spatial data services” services, Member States
shall ensure that e-commerce services are available.
Proposed Interpretation
For spatial data services performing a mathematical calculation and available on the Internet, the
“invoke spatial Service” service will enable a user to run it without requiring the availability of a GIS.
Proposed Assumptions
Only the generic description of the spatial data service algorithms and specific parameters are in the
scope of the specifications and Implementing Rules for the “Invoke Spatial Data Services” service.
Potential Issues
Combination of Services
As with the transformation service, the orchestration/combination of Spatial Data Service with other
services will require to precisely define the interactions between the services.
Implementing Rules Definitions
Overall Content
It is envisioned that the Draft Implementing Rules will:
•
•
Indicate its intended scope.
lay down the requirements for each Network Service and its interfaces/dependencies with
other Network Services Implementing Rules, other directive chapters Implementing Rules and
more generally vis-à-vis reference material;
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
•
•
•
•
•
•
•
•
9/7/2005
Page 11 of 19
Establish the functional and technical specifications to be met by the Network Service and
its interfaces vis-à-vis other systems. If needed, these specifications may vary according to the
use of the Network Service (e.g. access by a public authority or a third party).
Determine the interoperability constituents and interfaces which must be covered by
European specifications, including European standards, which are necessary to achieve
interoperability;
List the Reference Material considered during the development and whenever applicable
describe its contribution to the Implementing Rules.
Describe tests or analysis performed and include their results to assess the fitness for
purpose.
Indicate a proposed strategy for implementing the Network Services. In particular, it may
be necessary to specify the stages to be completed in order to make a gradual transition from
the existing situation to the final situation in which compliance with the implementing rule shall
be the norm.
Indicate how compliance testing should be implemented and if applicable outline a strategy
for interoperability testing.
Outline the strategy for the operation and maintenance of the Network Service including the
maintenance of the Implementing Rule.
Provide a cost/benefit analysis if requested.
What should be included in the final legislative act is still to confirmed and its technical content is
assumed to be a subset of the draft Implementing Rules.
Detailed Content
Service Requirements
The aim is to describe the detail of the requirements included or to be derived from the directive
proposal taking into account:
- The directive proposal itself and the potential interpretations.
- The dependency with the other directive chapters (data, metadata, …).
- Any non technical requirement impacting the development process, for example the
specifications shall be mainly derived from existing specifications.
- The existing and future directives reporting requirements
Functional and Technical Specifications
The development of the Implementing Rules will consider a range of standards and practices. The
result must be a set of functionality elements (the so-called INSPIRE core) of which only the "minimum
common denominator" will become mandatory to comply with the service requirements.
On top of functionality elements, other elements need to be considered such as quality and
performance (article 22).
Prior to specify each Network Service, a Network Services Reference Model should be defined
following for example the methods/models given by RM-ODP or MDA.
We can envision different levels of specifications, named differently in different development models
and phases, we propose in this context 2 level of specifications, the abstract and full specifications
detailed as:
Abstract Specification
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 12 of 19
It should focus on the key concepts and mechanisms of the Network Service, not all details are to be
provided. These details will be explicitly added in the full specifications.
The purpose of the abstract specifications is to get the high level pervasive issues correct before
tackling the more specific details; they do not need to cover the full range of implementations options
as they focus on the semantic intent.
Full Specifications
These specifications shall include all the information required to build the target Network Service in its
context. It must not only include the logical semantic and the algorithms, data structure and
mechanisms that ensure proper performance, but also organisational decision about the service
components and also dedicated platforms or protocols for example.
Interoperability
Development of Implementing Rules for the Network Services is to be based on European and
international standards and it will link to relevant initiatives such as:
• e-Government at European (i.e. IDABC) and national levels.
• e-ContentPlus programme
• Sectorial Industry
, To ensure interoperability inside the INSPIRE realm and with other relevant interoperability initiatives.
Reference material
The availability of reference material is central to the drafting of the Network Services Implementing
rules as defined in the work programme 2005-2006. More precisely figure 4, extracted from the work
programme, defines 3 scenarios that all define external reference material as the only formal source of
information for the Implementing Rules.
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 13 of 19
Figure 4 Drafting Phase Scenarios
The central role played by the reference material plays a critical role on the way the Implementing
Rules for the Network Services will be drafted. Figure 5 contains a first proposal on the way the draft
Implementing Rules could be developed around the Reference Material.
It is therefore necessary to fully document the impact and use of the reference materials to ensure full
traceability.
More precisely, the role and activity needed to handle the reference material is depicted in figure 5 that
provides a first proposal of the development process for the Network Services Drafting team.
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 14 of 19
Figure 5 Network Services Draft Implementing Rules Development Process
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 15 of 19
Assessment of Fitness for Purpose
In addition to checking the compliance with the consolidated requirements, the Spatial Data Interest
Communities will review the drafts and provide feedback during the development process through their
representative in the Drafting teams or during the global assessment by the SDICs.
Network Services Implementation Strategy
The implementation strategy should address topics like:
• Specifications of the stages to be completed in order to make a gradual transition from the
existing situation to the final situation in which compliance with the Implementing Rule shall be
the norm.
• Priority of implementation of the Network Services in the Member States
• Time synchronisation of the implementation with the other directive chapters.
• Suggest the organisation/constraints to be put in place for a successful implementation in the
MS.
• Consider Generic Migration parameters/recommendations taking as much as possible account
of National/Regional and local characteristics.
• Minimum system requirements for each NS.
Procedures for Conformance Assessment
Following the OpenGeospatial Consortium, 2 levels of testing can be defined:
•
Compliance Testing determines that a product implementation of a particular Implementation
Specification fulfills all mandatory elements as specified and that these elements are operable.
Compliance testing may be more stringent (especially as a particular Implementation Specification
matures). For example, a more stringent version may test that a product implementation of a
particular Implementation Specification fulfils all mandatory and implemented optional elements as
specified and that these elements are operable, accurate (to a reasonable level of measure), and
that the elements handle all reasonable cases correctly including errors (NOTE: Compliance
testing WILL NOT ensure, or even test, interoperability of software products, however, as the
specifications mature the likelihood of interoperability will be higher),
•
Interoperability Testing determines that a product implementation of an Implementation
Specification interoperates with other product implementations of the same Implementation
Specification, different but related Implementation Specification(s), or within a particular computing
environment.
The compliancy testing is directly applicable to the Network Services and will need to defined, mainly
based on the work done by Standard bodies.
In addition questions like:
•
•
•
certification policy
availability of automatic conformance (compliance/interoperability) testing
combination with conformance assessment methods developed for the metadata and the data
specification Implementing Rules,
will need to be answered
Infrastructure for Spatial Information in Europe
Reference: Detailed Definitions on the INSPIRE network
Services V1 1.doc
JRC/CT Detailed definitions on the INSPIRE Network Services
9/7/2005
Page 16 of 19
Strategy for Maintenance
Once adopted, it is foreseen that the Implementing Rules for the Network Services will be maintained.
The maintenance strategy should take into account in particular:
• Feedback from operation in the Member States and through the Community Geo-portal.
• Technical progress (article 22)
• Organisation/procedure required for the maintenance.
Cost benefit analyses
LMOs will express their view of the draft Implementing Rule. They will make an analysis of the impact
of the Implementing Rule. At the same time a process is to be put in place that is able to capture the
benefit of the Implementing Rule, for example through projects funded by the eContentPlus
programme, other EC funded projects, and collection of case-studies at national, and regional levels.