mvc print pdf : Print pdf to tiff SDK Library project winforms .net web page UWP IES_Spatial_Data_Infrastructures_(online)4-part160

4.3.9 Portrayal 
The graphic presentation of geographic information depends on many factors such as 
the  information  content,  the  medium  of  representation
33
,  the  eventual  portrayal 
conventions within the stakeholder communities, etc. In SDIs, the main emphasis is 
on reusing and combining data from different  sources, which creates an infinite 
variety of data that must coexist in the course of spatial analysis. The harmonisation 
of portrayal rules is therefore a complex task. 
Following the principle of step-wise implementation, the first step may aim to support 
the view service only, which is used in the discovery stage. This approach has been 
adopted in INSPIRE, where portrayal is addressed from the perspective of the single 
themes.  The  schema  for  portrayal  rules  and  symbology  for  geographic  features 
specify basic rules (layer structure) and a standardised set of default styles. 
The most frequently used visualisation methods are based on OGC Styled Layer 
Descriptor (SLD), which allows user-defined symbolisation and colouring when data 
is displayed in a Web Mapping Service (WMS). 
The  Keyhole  Markup  Language  (KML)
34
is  an  XML  language  that focuses  on 
geographic  display/visualisation,  including  annotation  of  maps  and  images. 
Geographic visualisation represents graphical data on the globe and guides the user's 
navigation in the sense of where to go and where to look. 
In order to avoid clashes of styles used in different themes, some basic harmonisation 
is necessary. Where there is no harmonisation, for example, the same blue line could 
be used to represent bathymetry, waterways, and boundaries of sea regions. Sharing 
SLDs in a registry can help this harmonisation process, e.g. by enabling queries for 
styles defined for different data themes. A registry may also be used to share user-
defined styles (e.g. for specific purposes, such as coastal zone mapping). 
4.3.10 
Data delivery 
For exchanging spatial data, efficient methods for encoding and data delivery are 
required. The encoding rule specifies the data types to be converted, as well as the 
syntax,  structure  and  coding  schemes.  It  presents  data  in  a  format suitable  for 
transport and  storage.  Clear  definition of data formats  helps  to  ensure syntactic 
interoperability. 
Because of the diversity of data present in the infrastructure (vector, raster, etc.) a 
unique encoding rule and output data structure cannot be mandated. Thus, every data 
specification should specify at least one encoding rule that is mandatory for that 
specific theme. 
While  flexibility  to  support  additional  encoding  rules  is  a  valid  approach, 
harmonisation and reduction of the spread of encoding rules is also important. It is 
reasonable to maintain the list of recognised encoding rules and output data structure 
schemas in a registry. Encoding rules should be based on international, preferably 
33
Paper map, computer screen, mobile devices, mobile phones, etc. 
34
SLD is recommended by INSPIRE, KLM is supported by GEOSS. 
Print pdf to tiff - SDK Library project:C# PDF Convert to Tiff SDK: Convert PDF to tiff images in C#.net, ASP.NET MVC, Ajax, WinForms, WPF
Online C# Tutorial for How to Convert PDF File to Tiff Image File
www.rasteredge.com
Print pdf to tiff - SDK Library project:VB.NET PDF Convert to Tiff SDK: Convert PDF to tiff images in vb.net, ASP.NET MVC, Ajax, WinForms, WPF
Free VB.NET Guide to Render and Convert PDF Document to TIFF
www.rasteredge.com
open, standards and should be compliant with ISO 19118 Geographic Information – 
Encoding. 
In INSPIRE, unless otherwise specified for a specific data theme, the recommended 
encoding is  the OGC’s Geography Markup Language (GML) as defined in ISO 
19136. For large volume coverage data such as orthoimagery or computer simulations 
(e.g. weather forecasts), other, more efficient, file-based encodings (e.g. geoTIFF) 
may be defined as the default encoding language. These encoding schemas are widely 
supported and can be inserted in the majority of GIS. 
In  an  SDI,  spatial  data  is  accessible  via  download  and  view  services.  This 
interoperability component also includes the services  used to deliver  data  and a 
reference to the encoding formats applied for exchanging data between systems. 
 Methodology for Data Specification Development 
5.1 
Definition of the scope of the data themes 
Defining the scope of the data themes 
and the infrastructure requires careful 
considerations and consensus building 
among the stakeholders, including the 
data  users,  producers,  technology 
providers, and politicians responsible 
for the strategic development of the 
relevant  field.  Surveys,  state-of-play 
studies, formal written opinions, web 
consultations, and public hearings are 
some examples of instruments that can 
be employed in this process. 
The definition of the INSPIRE themes started with 
analysis  of  the  requirements  of  European 
environmental legislation. The preliminary list drawn in 
the  position  paper  of  the  Environmental  Thematic 
Coordination Group was discussed  in  wide  before 
being defined in the annexes of the Directive. Because 
of the changes introduced in the consultation process, 
it  was  necessary  to revisit the  theme descriptions 
before the data specification process started. This has 
been carried out by the Data Specification Drafting 
Team in the “Definition of Annex Themes and Scope” 
document.  Defining interdependencies between the 
themes, this document represented an important input 
for the data specification process. 
For historical and organisational reasons, spatial data is collected and maintained by 
many different organisations. Since their activities are not necessarily coordinated, 
there can be overlaps or gaps in the data content. As redundancies are important 
sources of data inconsistency, it is necessary to outline the borders between the data 
themes. A clear definition of the scope of the data themes will help stakeholders to 
judge how their interests might be influenced by the emerging infrastructure, and 
where they may need to interact.  
When overlaps between two or more themes are discovered, the following decisions 
have to be taken: 
Are the apparently overlapping parts justified from a conceptual point of view? 
Do the spatial objects describe 
different
abstractions of the same real world entity 
(e.g. a river section as part of hydrography vs. a river section as part of waterway 
navigation)? If yes, the spatial objects should be modelled in both themes. If not, 
it should be decided which theme is the most appropriate to deal with the spatial 
object in question. 
If the separation is conceptually justified, how can the difference be made visible 
(choice of terminology), what are the critical points that make the difference, and 
SDK Library project:C# PDF Print Library: Print PDF documents in C#.net, ASP.NET
Annotate PDF. WPF: Export PDF. WPF: Print PDF. PDF Create. Create PDF from Word. Create PDF from Excel. Create PDF from PowerPoint. Create PDF from Tiff. Create
www.rasteredge.com
SDK Library project:VB.NET PDF Print Library: Print PDF documents in vb.net, ASP.NET
Annotate PDF in WPF. Export PDF in WPF. Print PDF in WPF. PDF Create. Create PDF from Word. Create PDF from Excel. Create PDF from PowerPoint. Create PDF from Tiff
www.rasteredge.com
should a relationship between the two concepts be established (e.g. identifying the 
hydrological river section(s) to which a water transport river section corresponds)? 
It should  be  noted  that  the  conceptual  framework  does  not  consider  or  resolve 
organisational constraints (i.e. in case of unjustified overlaps, which organisation is 
duplicating the information?); it only flags where efforts for coordination are needed. 
Coordination is equally necessary when interdependencies between two or more data 
themes are discovered. 
Based on prominent use cases and reference materials, the scoping process also 
outlines the possible content of the data themes in terms of key spatial object types 
and their attributes. This non-exhaustive list should not be an attempt to define the full 
content, it is rather an illustration for better understanding. The proper analysis of 
references and the definition of data requirements should occur during the course of 
the data specification development. The main outcome of the scoping process is well-
defined starting point for the data specification process. 
5.2 
Principles of data specification development 
As part of the conceptual framework, the specification development methodology 
guides the process so that the general principles of the SDI such as reuse, feasibility, 
and proportionality are followed. The methodology gives instructions as to which 
actions need to be taken at the different steps of the process. 
The specification development process can be driven by data providers and/or data 
users.  In  a  provider-driven  approach,  the  main  principle  is  to  find  a  common 
denominator between the existing datasets belonging to a specific theme. Without 
external benchmarks, however, interoperability requirements may remain unclear in 
this approach, which could lead to the following problems: 
The data delivered according to the interoperability arrangement does not meet 
the requirements of the users; 
Rather  than  seeking  an  optimum  level  of  interoperability,  the  strongest 
stakeholders may promote their solutions in order to minimise the potential 
transformations/changes to the datasets they produce. 
In the user-driven approach, the external benchmarks stem from the requirements of 
the users,  which  are  carefully analysed  and  formalised at  the  beginning  of the 
specification  development  process.  This  approach  may  be  associated  with  the 
following risks: 
It is difficult to capture detailed user requirements up front, 
The expressed requirements might be too ambitious, leading to excessive costs 
or the impossibility of implementation based on the existing data, 
Instead  focusing  on reuse, the  specification  process  may  yield a  product 
specification fulfilling the needs of a “strong” user. 
Experience shows that, in practice, a combination of these two approaches tends to be 
used, balancing aspirations with technical and financial viability. 
The  methodology  described  in  this  chapter  provides  the  details  of  the  data 
specification  development  process  used  for  INSPIRE.  This  methodology  has 
SDK Library project:C# Create PDF from Tiff Library to convert tif images to PDF in C#
Create PDF from Tiff. |. Home ›› XDoc.PDF ›› C# PDF: Create PDF from Tiff. C#.NET PDF - .NET PDF Library for Creating PDF from Tiff in C#.
www.rasteredge.com
SDK Library project:VB.NET PDF - Print PDF with VB.NET WPF PDF Viewer
Annotate PDF in WPF. Export PDF in WPF. Print PDF in WPF. PDF Create. Create PDF from Word. Create PDF from Excel. Create PDF from PowerPoint. Create PDF from Tiff
www.rasteredge.com
incorporated the results and experience of scientific research projects
35
as well as best 
practices of  SDI  development. Furthermore, this  methodology has  been formally 
described  and tested, delivering tangible results  for  each of the 34 data themes 
included  in  INSPIRE.  INSPIRE takes  an  iterative  approach  to an  incrementally 
growing SDI, which is based on stakeholders’ commitment. This predictable and 
repeatable  development  process  model  allows  feasible  and  mutually  satisfactory 
system solutions to be reached. The main steps of the process are shown in Figure 9. 
Maintenance
Implementation, 
testing and validation
Data specification
development
Gap analysis
As‐is analysis
Use case development
Identification of user
requirements and spatial 
object types
Cost‐benefit considerations
Figure 9: Steps in the data specification cycle 
This approach helps to balance ambitions and feasibility. If ambitions are too high, 
this may lead to complex specifications, which will be difficult and expensive to 
implement. Furthermore, if specifications are too complex, there is a risk that they 
will not be supported by the data provider communities and that they will not be 
adopted  by  the  users.  However,  overly  simple  data  specifications  may  lead  to 
insufficient  interoperability,  and  the  critical mass  that  makes  the  related  efforts 
worthwhile  may  not  be  achieved,  rendering  the  benefits  of  the  infrastructure 
intangible. The main points of the challenge to be solved are illustrated in Figure 10. 
35
RISE ftp://ftp.cordis.europa.eu/pub/ist/docs/environment/rise_en.pdf
MOTIIVE https://www.seegrid.csiro.au/wiki/Marineweb/MOTIIVE
SDK Library project:C# WPF PDF Viewer SDK to view, annotate, convert and print PDF in
as well. Users can export and convert PDF to Word, Tiff, TXT and various of image file formats. Print PDF in WPF PDF Viewer. By using
www.rasteredge.com
SDK Library project:C# WPF PDF Viewer SDK to print PDF document in C#.NET
Annotate PDF. WPF: Export PDF. WPF: Print PDF. PDF Create. Create PDF from Word. Create PDF from Excel. Create PDF from PowerPoint. Create PDF from Tiff. Create
www.rasteredge.com
Which level of interoperability is “just right”?
Simple
Complex
Too simple:
• Identified requirements aren’t 
sufficiently supported
• Insufficient harmonisation
• Few benefits
Too complex:
• Difficult technical implementation
• Substantial benefits available 
only to few users
• High costs
Figure 10: The challenge of finding a balance in the data specification process 
A good approach to finding a balance is to apply two principles: 
1.
The  focus  of  activities  should  be  on  generating  consistent  spatial  (and 
temporal) information for wider use, leaving out information regarding the 
execution of business processes, scientific simulations, or specific reporting 
requirements. 
2.
Extension mechanisms should be provided for the models and it should be 
shown how other spatial and non-spatial aspects can be linked to the models. 
The following sections describe in greater detail the steps to be taken in the data 
specification process. 
5.3 
The data specification development cycle 
‘Use case’ collection and development 
The scoping phase of the infrastructure outlines what 
user needs are to be supported. These are further refined 
and documented during the initial phase of  the data 
specification  process.  Use  cases  are  widely  used  in 
information technology to formalise the descriptions of 
how users interact with the system to be developed. In 
SDI development, they illustrate the possible uses of 
data. 
use case  defines  a  goal-
oriented  set  of  interactions 
between actors and the system 
under consideration. Use cases 
help  to  understand  the 
requirements of the users and 
define the data that is necessary 
to fulfill them. 
A use case may cover several data themes. For example, a use case describing flood 
risk analysis in a  particular area may require  data  from hydrography, elevation, 
meteorology, etc., and may result in input for the “Natural risk zones” data theme. 
Common use cases also help to clarify eventual cross-theme dependencies. Therefore, 
use cases considered in the infrastructure should reflect the multiplicity of data usage. 
For proper weighting of requirements, the use cases have to be ranked according to 
priority. High priority should be assigned to those use cases that are part of many user 
scenarios or are time-critical (disaster management, flooding, etc.). These are “quick 
win” areas where the benefits of SDI yield immediate and tangible results. 
SDK Library project:VB.NET Create PDF from Tiff Library to convert tif images to PDF
Word, C# extract text from PDF, C# convert PDF to Jpeg, C# compress PDF, C# print PDF, C# merge PDF files, C# view PDF online, C# convert PDF to tiff, C# read
www.rasteredge.com
SDK Library project:VB.NET PDF - WPF PDF Viewer for VB.NET Program
annotate PDF document with various notes and shapes, convert PDF to Word document, Tiff image, TXT file and other images file formats, and print PDF document.
www.rasteredge.com
In practice, however, it can be difficult to collect use cases from the stakeholders. 
Data users are less aware of the benefits of SDIs or of SDI development initiatives. 
This  should  not  jeopardise  the  specification  development  process.  Specification 
development can start with preliminary use cases provided by the data providers, 
since they are usually aware of the tasks for which their clients use the data. Data 
users can be activated in parallel. The consultations included in the later phases of the 
data  specification  development  cycle  may  provide  the  necessary  feedback  for 
improvements and convergence with users’ needs. 
Identification of user requirements and spatial object types 
Use cases are used to identify the spatial data requirements in the ‘first cut’ data 
model. This model contains the candidate list of spatial object types, draft definitions 
and descriptions, and an initial set of other data specification elements. Each of these 
elements is defined according to the level of detail, which is determined based on user 
requirements. The concepts of spatial object types should be shared and harmonised 
across the different themes. A useful tool in this context is the Feature Concept 
Dictionary
36
‘As-is’ analysis 
Pursuing the principle that the SDI should bring existing data together, the data 
requirements  from  the  use  cases  should  be  compared  with  the  existing  ‘as-is’ 
situation. This analysis reveals whether the requested data can be supplied by the data 
providers. If so, it also shows the complexity of the related transformation work. If 
there is no one-to-one relationship between the proposed harmonised schema and the 
theme-related datasets, data integration might be still required at the level of the data 
sources or by the users. The ‘as-is’ analysis is frequently performed in parallel with 
the gap analysis. 
Gap analysis 
Gap analysis identifies user requirements that cannot be met by the current available 
data. There are two kinds of gaps. Technical gaps can be filled by integrating data 
from any relevant dataset or data transformation, while content gaps can be addressed 
only by data collection. Existing state-of-the-art studies may provide a baseline for 
comparison. 
Filling technical gaps provides undisputable value for the users, but may involve 
substantial costs to data producers. Technically sound and cost effective approaches 
may help, such as automatic tools for data integration and transformation. However, 
such transformation tools are not always available at the current technology level. 
Therefore a prudent approach that compares the benefits with the possible costs must 
be taken. 
Data specification development 
“First cut” data models and the other initial data specification elements outlined in 
the requirement analysis have to be adjusted according to the result of the ‘as-is’ and 
gap analyses. In order to respect technical and financial feasibility, the content of data 
specification can be earmarked for mandatory or optional implementation. 
36
See section 4.1.8 
According to the practice in INSPIRE, the data models 
should  be  implemented  in  their  entirety;  no  spatial 
object  type  can  be  omitted.  If  there  is  a  need  to 
distinguish between more and less “important” spatial 
object  types,  the  two  groups  must  be  packaged  in 
separate  data  models  that  are  also  referred  to  as 
“profiles”.  Spatial  objects  that  are  indispensable  to 
supporting the key requirements are placed in the core 
model. The extended models may guide voluntary implementation and the stepwise 
and coherent development of the infrastructure by setting targets for consecutive data 
collections and maintenance. 
In  INSPIRE,  the  mandatory 
elements  are  defined  as 
“requirements”  while  the 
optional elements are defined 
as “recommendations”. 
Profiles have been applied, for 
example, in the Protected sites 
and the Buildings data themes. 
In  addition  to  the  technical  elements,  the  data  specifications  may  also  contain 
explanations and examples to support better understanding and implementation. 
Implementation, testing, and validation 
Specifications  must  be  reviewed  and 
tested by a wider stakeholders group in 
order  to  verify  whether  data 
specifications are fit for the purposes of 
the infrastructure and  contain enough 
information to support implementation.  
Specification testing can be carried out 
to  deliver  feedback  on  feasibility  or 
fitness  for  use.  Feasibility  testing 
assesses  the  efforts of  data  providers 
required to transform their data to be 
compliant  with  the  interoperability 
target  specification.  This  results  in 
feedback  on  technical  feasibility  and 
the associated costs of implementation.  
In INSPIRE, three iterations were carried out. After 
the  first  iteration,  the  data  specifications  were 
reviewed by the Thematic Working Groups. The main 
purpose  of  this  phase  was  to  eliminate 
inconsistencies between the specifications between 
the  various  data  themes.  The  second  iteration 
comprised a review and a testing phase in which all 
the  stakeholder  communities  could  participate.  In 
order to accelerate the process, consultative meetings 
–  the  ‘comment  resolution  workshops’  –  were 
convened  to  resolve  divergent  opinions  of  the 
stakeholders.  Based  on  the  outcomes  the 
specifications were again revised and published as 
implementation  guidelines  in  the  third  iteration. 
Selected parts of the guidelines have been included in 
the legislative acts mandating the implementation of 
INSPIRE by  the Member States of the  European 
Union. 
Application testing assesses how much interoperability has facilitated the work of 
users. This test is performed by the data users to assess whether the data provided in 
conformity with the interoperability target specifications facilitates their performance.  
The results of testing and stakeholder consultations can be used for reiterating the data 
specification process from any step, most probably from the ‘as-is’ and the gap 
analyses.  The  iterations  can  be  repeated  until  consensus  is  reached.  After  this 
validation process, the specifications are published so that they can be used by the 
general public. 
For legally reinforced SDIs, an additional step 
is necessary. The technical drafts should be 
made into legal acts fulfilling the legislative 
requirements while maintaining the technical 
content.  One  way  of  ensuring  legal 
reinforcement  is  to  mandate  only  the 
parameters for the services through which the 
data is made available in the infrastructure, 
Commission 
Regulation 
1089/2010 
implementing interoperability of spatial data-
sets and services contains a subset of the 
INSPIRE Generic Conceptual Model and the 
data specifications. While there is one data 
specification  for  each  theme,  the  legally 
mandated sections are collected in a singe 
“implementing” rule. 
leaving the semantic models in the guidelines. Another option is to select a subset of 
the data specifications, comprising the semantic model, based on technical feasibility 
and cost-benefit issues. In this case the data specifications with the full technical 
content  serve  as  guidelines  for  the  stakeholders,  enabling  further  coherent 
development of the infrastructure. 
5.4 
Maintenance of specifications 
Changes in requirements or in an ‘as-is’
37
situation may trigger a revision of the data 
specification,  and  the  associated  registers,  documents  and  tools  necessary  for 
supporting technical and documentation activities. The request for changes in data 
specification may be triggered by the following: 
Issues detected at a later stage in the course of the step-wise data specification 
process and in the implementation phase, 
Changes in the legislative frame with an impact on the requirements for spatial 
data,  
New initiatives and programmes influencing the development of SDIs (emerging 
SDI initiatives at higher level, eGovernment, etc.), 
Need for harmonisation with international standards and other initiatives,  
New relevant user requirements and use cases, 
Changes in the ‘as-is’ situation of the stakeholders and progress in technology, 
Errors or ambiguities within the documents, 
Inconsistencies with other building blocks of the infrastructure, 
Cost-benefit considerations. 
From an organisational point of view, the maintenance procedure should be as open 
and  participatory  as  the  specification  development  process,  which  guarantees 
coherence between implementation,  development and maintenance. Therefore the 
persons and organisations that have to be involved in the process, as well as the 
methods and workflows have to be defined. 
The maintenance process basically follows three methods of change. The “fix and 
align”  method  serves  to  correct  errors  and  (re)establish  consistency  with  other 
components or building blocks of the infrastructure. The “depreciate” method is used 
to discard elements
38
that are no longer used or that are replaced with new items, 
while the “add” method allows new items to be introduced. 
Minor corrections allow for a backwards compatible revision, i.e. all datasets that 
conform  to  the  previous  version  are  still  conformant  with  the  revision.  Major 
revisions introduce significant changes. Where feasible and  appropriate, a  major 
revision should remain backwards compatible. This type of revision is allowed when 
absolutely  necessary  for  the  domain,  e.g.  to  introduce  a  significant  number  of 
additional spatial object types to a theme, or to upgrade the Generic Conceptual 
Model or a data specification in a fundamental way. 
In order to support the maintenance process, it is recommended that version control 
systems of repositories be used both for the consolidated data model and the technical 
documents. 
37
See section 5.3. 
38
In the interests of traceability, no item should be simply deleted.  
5.5 
Cost-benefit considerations 
Besides being based on technical feasibility, the interoperability arrangements should 
be based on careful analysis of the related costs and the benefits, as shown in Figure 
10 in page 43. Cost-benefit analysis in the data specification development process 
must be carried out throughout the specification process. 
In cost-benefit analysis, the expected costs and benefits are converted into comparable 
units, usually monetary values. Carrying out a strict cost-benefit analysis is rather 
difficult for SDIs, especially in terms of benefits. Benefits are generally incurred by 
the users and society in general. Furthermore, before being visible, the benefits of 
SDIs may need time to mature, i.e. a transition period during which a critical mass of 
available datasets is transformed to reach interoperability.  
Cost-benefit considerations give an overall presentation of quantitative and qualitative 
assessment criteria for SDIs. Instead of trying to convert each cost-benefit aspect into 
comparable (monetary) units, they contain statements as to 
Where and how costs and benefits are likely to occur, 
How to avoid or reduce costs by undertaking appropriate decisions and technical 
measures, 
How to highlight the possible benefits and make them visible to stakeholders. 
The main means of detecting the possible costs related to the implementation of the 
interoperability specifications is the testing process, where data providers can record 
the investments necessary to reach interoperability in terms of expertise, time, new 
software and hardware, and educational needs. In INSPIRE, this type of testing is 
called ‘transformation testing’. 
The other type of testing - application testing - helps to quantify the benefits to the 
users by comparing the time necessary for performing a specific task using data that is 
compliant with the interoperability specifications and the data supplied in its original 
form.  If  data  in  conformity  with  interoperability  specification  facilitates  the 
performance of users’ tasks, the benefits of the infrastructure are visible. The benefits 
can be quantified in terms of time reduction, performing the tasks with less qualified 
personnel, etc.  
In order to get a broader picture of the costs and benefits of the infrastructure, an 
extended impact assessment and a direct survey among the stakeholders have been 
carried out for INSPIRE. Table 5 summarises the main points relevant to SDI cost-
benefit considerations. 
COSTS 
BENEFITS 
Costs  related  to  the 
development 
of 
the 
specifications 
Costs  of  reengineering  the 
databases 
As  an  alternative,  costs  in 
developing  schema  mapping 
from old to new specifications 
Hardware and software costs if 
new systems were required 
Costs 
in 
running/ 
checking/validating 
the 
transformation 
Direct User Value/Benefit 
Increased data availability 
Increased ease of use 
Better data sharing ability 
Reduced  cost  of  integrating 
data 
Social Value 
Enables  better  decision 
making 
Reduces  barriers  between 
organisations 
Increases 
institutional 
effectiveness 
Promotes more efficient use of 
(taxpayer) funds 
Operational 
benefits 
for 
institutions 
Promotes 
intra-institutional 
collaboration 
Promotes 
inter-institutional 
collaboration 
Reduces data integration cost 
across institutions 
Promotes  reuse  of  existing 
datasets 
Decreases  costs  of  IT/ 
information management 
Overall cost savings for info 
management 
Achieves cost avoidance (as 
opposed to savings) 
Fosters  closer  working 
relationships 
Supports  improved  decision 
making 
Supports  other  information 
infrastructure 
Table 5: Aspects involved in cost-benefit analyses of SDIs 
5.6 
Actors in the data specification process 
The organisational structure of establishing the data component of the SDI is defined 
by the following conditions: 
1.
The process should be based on consensus building; 
2.
Establishing and running an SDI aiming at cross-theme interoperability needs 
the involvement of numerous organisations; 
3.
Cross-theme interoperability requires tools and organisational measures for 
continuous flow of information between the stakeholders. 
These conditions imply the need for coordination in order to ensure communication, 
planning, providing and maintaining the tools during the specification process. 
The more data themes are included in the infrastructure, the bigger is the demand for a 
well-structured  process.  A  modular  approach  allows  more  freedom  from  an 
organisational point of view. It might be difficult to engage the necessary resources to 
develop the interoperability specification for many data themes in parallel. When the 
modules are scheduled in the right order, the knowledge accumulated at the beginning 
can be used for the later stages. It is worthwhile to start the process with reference 
data, where stakeholders are “spatially aware”. 
Meaningful discussions with stakeholder communities can only take place based on 
good proposals. The technical drafts for the interoperability target specifications have 
to be proposed by a competent body. Following the participatory principle in SDIs, 
the  best  organisational  forms  are  the  technical  expert  groups,  composed  of 
representatives of the stakeholders. The expertise of these groups includes: 
-
Expertise in geographic information modelling and the relevant standards, 
Documents you may be interested
Documents you may be interested