Table of Contents

Foreword 2
1. Introduction to the Guidelines 3
1.1 Objectives 3
1.2 Audience 3
1.3 Overview 4
1.4 How to read the guidelines 4
1.5 Benefits 4
2. Assessment of the eu and see situation as regards the municipal administration working
process and services: methods (questionnaire) and Best Practice examples 7
3. The Back Office 9
3.1 The EDMS 9
3.2 Interface to external Information resources 9
3.3 The Mayor's Office Information Network 9
4. The Front Office 10
4.1 The Municipality and City Portal 10
4.2 Citizens' tool set 10
4.3 Interface tool set 10
5. Implementation solutions 11
5.1 E-municipality Offices 11
5.2 Municipality portal 11
5.3 Kiosk for services to citizens 11
6. GEO-Information and Municipality Information Systems 12
7. Checklist for selecting and implementing e-service applications 13
7.1 Introduction to the checklist 24
7.2 General requirements for the e-service implementation 24
7.3 Organisational requirements 24
7.4 Promotional requirements 24
7.5 Back Office requirements 24
7.6 Front Office requirements 24
7.7 Geographical Information requirements 24
8. Conclusions 25
ANNEX 1: Template for action plan 27
ANNEX 2: Web links 28
ANNEX 3: Glossary (IT/MIS) 31
FOREWORD

This book has been produced under the project PANEL-GI (A Pan European Link for
Geographical Information; http://www.gisig.it/panel-gi), co-ordinated by the GISIG Association.
PANEL-GI is a concerted action funded within INCO-COPERNICUS, the Programme
launched by the European Commission for promoting the scientific and technological
cooperation with Central and Eastern European Countries (CEEC)
(http://www.cordis.lu/inco/src/projcop.htm )
PANEL-GI is then a European Network aimed at involving partners from the CEEC in the
process of creating a Pan European GI Forum. The network gives an important contribution to
realise in perspective, a full and integrated European GI context and to stimulate or enable GI
business in CEEC.
The wider goal of the project is to contribute to the establishment of shared foundations for
the Information Society in CEEC, in the particular area of GIS. The Network’s main focus lies on
the following GI issues: European Geographical Information Infrastructure (EGII), GIS
Interoperability and Open GIS, metadata, data availability, GIS applications and European
dimension.
This “PANEL-GI Compendium. A Guide to GI and GIS” is one of the main outputs of the
project. It has been designed as a reference book useful to have a vision of the key issues of the
GI/GIS framework. The Compendium aims at offering to the reader a synthesis of the main GI
topics and should support to orient her/him in the GI/GIS field, stimulating as well new business
approaches and initiatives for the development of new projects and products.
The PANEL-GI partnership has decided to pursue the policy of a wide dissemination of the
project results and so anybody interested in can find the PANEL-GI Compendium also on the
Web, together with other useful material and information organized in the so-called PANEL-GI
Extended Package (http://www.gisig.it/panel-gi/package/pack.htm).
We do hope that this Compendium could give a significant improvement of a common
awareness and a share of the most important GI issues under discussion at a European level
and that it would contribute to an efficacious transfer of knowledge among European Countries
and to an effective development of a Pan European GI infrastructure.
We also hope that the PANEL-GI Network and its effort for GI and GIS could give an
additional contribution in pushing the development of the GI Market in Europe.
 Introduction 3

1. INTRODUCTION TO THE GUIDELINES

Geographic Information (GI) is a complex, rapidly growing and important part of the
Information Society. New Geographic Information technologies are developing rapidly. The great
advantage of GI is that it has the capability of summing up and visualising graphically what vast
amounts of data are trying to tell one about the relationship between various phenomena on the
Earth surface (such as the relationship between climate and certain health risks). There are
many applications in international, national and local government, business and research, and in
various commercial sectors. Geographic Information is important because of its value for
planning, land management, marketing studies, environment, renewable energy resources,
emergency services, health care, political analysis and many other uses (GI2000).
Geographic Information Systems (GIS) are tools for the management of geographic
information, for spatial analysis and the visualisation of this information. GIS are complex yet
general purpose tools, serving many types of users, but a frequently stated problem is that this
complex functionality is not accessible to end-users in administration, planning, decision making
and other work domains because the technology has been developed for technical experts. Due
to ergonomic deficits, today GIS user interfaces are not easy to use and require much time to
learn. Because task performance with GIS imposes high workload on users, the results may not
be as optimal as required.
The quality of GIS user interfaces is a key-factor for efficiency and effectiveness of GIS use,
for user satisfaction, and therefore for GIS diffusion. This quality must be improved for end-
users, especially since the technology is becoming more inexpensive and is therefore reaching
more, normally non-expert, users within the general public.
A key issue in GIS application development is the design of user-system interaction.
However, the needs and requirements of real GIS users - a prerequisite for good user interface
design - are not taken into account to a satisfactory degree for the development of GIS
applications.

1.1 Objectives
These ”Guidelines for the Best Practice in User Interface Development for GIS” have been
produced by the BEST-GIS project based on the experience of GIS end-users and experts.
The objectives are to increase user and customer awareness regarding the development and
customisation of GIS applications. GIS end-users will be able to define more precisely their
requirements and tasks. GIS customers will be able to understand the relevant cost and benefit
factors to be taken into account for GIS procurement decisions.
GIS developers, experts involved in GIS customisation, end-users and other stakeholders in
the GIS life cycle will be introduced to the user-centred design (UCD) approach and will find
methods applicable to GIS user interface evaluation.

1.2 Audience
The target audience of the guidelines are GIS end-users, i.e. persons who sit at a workstation
and have (or intend to have) hands-on experience with a GIS, both technology users and
domain specialists. Some information will also guide GIS customers to make reasonable GIS
purchase decisions.
In addition the guidelines will be useful for GIS developers and experts who customise GIS to
specific user requirements.
4

1.3 Overview
Section 2 describes the development process of GIS applications and the status of usability
engineering in this domain. The most important GIS user interface issues are described. The
discussion about GIS user interfaces standards is summarised.
Section 3 is an introduction to the user-centred design approach. The emphasis is on the role
of end-users and customers in user-centred design of GIS applications. An overview of
appropriate methods for GIS user interface evaluation is given.
Section 4 explains how to perform user requirements and task analysis. GIS stakeholders
and user groups will be described together with typical task and workflow scenarios.
Section 5 contains a check list for the selection and definition of user requirements for a
specific GIS application. The list is useful as a starting point in order to derive user requirements
for a GIS application. Readers are invited to adapt and extend this list for their own purposes
and to future GIS technology.
The checklist in section 6 gives an overview of the most relevant GIS specific technical
features.
Section 7 provides recommendations for the best use of significant GIS user interface
functions described in section 6. This section is addressed in particular to those users looking for
useful hints on the usability and drawbacks of GIS functions.
A checklist for testing the conformance of GIS user interfaces to the European Directive
90/270 on minimum requirements for health and safety of display screens equipment is provided
in section 8
The guidelines end with recommendations on how to perform a cost / benefit analysis of GIS
usage in section 9. This section emphasises consideration of the whole GIS life cycle for the
analysis and lists the most relevant and important cost and benefit factors to be taken into
account for the analysis.

1.4 How to read the guidelines

Section 2 introduces the reader to the problem with GIS user interfaces. This section will be
useful for readers who are not at all familiar with the GIS domain.
Readers having no basic knowledge about usability engineering should read the introduction
to the user-centred design approach in section 3. The overview in this section will be useful for
end-users and customers as well as for developers and customisers.
Sections 4 to 8 are especially useful for end-users who are responsible for requirements
specification.
Section 9 is intended for customers who want to find out more about the relation of costs
caused by GIS usage and its benefits.

1.5 Benefits
Today, in public or private organisations, many architects, civil engineers, geologists, and
many others, who could make use of GIS tools in their work domains, either do not exploit the
technology or rely on the expertise of a GIS expert. On the other hand, the expert may be highly
familiar with GIS technology but often has limited experience in different domain problems.
The short term benefits of these best practice guidelines will be:
for end-users to improve the statement of their needs and requirements,
for customers to improve cost / benefit calculations of GIS usage,
for developers and customisers to better understand user needs and requirements and thus
taking these into account,
• resulting in a better exploitation of GIS which are currently available on the market.
in the long term making use of these best practice guidelines should lead to:
• user-centred development of GIS user interfaces with higher quality,
 Introduction 5

• GIS user interfaces which can be applied by the end-users more efficiently (speed
up work) and effectively (do the right thing) and which are accepted by the end-
users,
• improvement and speed up of the GIS development process,
• reduction of customisation effort.
 7

2. ASSESSMENT OF THE EU AND SEE SITUATION AS REGARDS THE

MUNICIPAL ADMINISTRATION WORKING PROCESS AND SERVICES: METHODS
(QUESTIONNAIRE) AND BEST PRACTICE EXAMPLES
 Conclusions 9

3. THE BACK OFFICE

3.1 The EDMS

3.2 Interface to external Information resources

3.3 The Mayor's Office Information Network

10

4. THE FRONT OFFICE

4.1 The Municipality and City Portal

4.2 Citizens' tool set

4.3 Interface tool set

 Conclusions 11

5. IMPLEMENTATION SOLUTIONS

5.1 E-municipality Offices

5.2 Municipality portal

5.3 Kiosk for services to citizens

12

6. GEO-INFORMATION AND MUNICIPALITY INFORMATION SYSTEMS

 Conclusions 13

7. CHECKLIST FOR SELECTING AND IMPLEMENTING E-SERVICE

APPLICATIONS

This section introduces a checklist for driving the end user in requirement collection for a specific GIS
application. The granularity of the checklist, that is, the degree of detail of its points, has been chosen
having in mind two contrasting objectives: completeness and applicability. The former objective has been
pursued by splitting the requirement collection into general (steady) aspects and other (evolving) aspects
related to single application fields. The latter takes advantage of the checklist organisation into
homogeneous modules that should focus user attention on clear and distinct subjects.
The section is subdivided into three sections. The first section justifies the need for such a checklist and
explains how the underlying requirement collection criteria have been identified and validated. The second
section gives brief indications on how the checklist should be used effectively by the end user and what
the expected result is after its application. Finally, the third section proposes the checklist in terms of
seven general modules (Project organisation, Project outcome, Map acquisition, Derivation process, User
interface, Map visualisation, Database organisation) and two application-oriented modules (Environment
Control, Urban Planning).

7.1. Task rationale and procedure for criteria identification

It is widely recognised that end users find it difficult to clearly define what their requirements are when
facing the development of a new GIS project. As domain experts they usually know quite well what the
project is aimed at, but the distance existing between their culture and lexicon with that of the adopted GIS
technology still constitutes a huge obstacle. The solution most commonly pursued is informally transferring
these requirements to a GIS technology expert, relying on his/her ability to understand (and possibly
complete) the representation of the project objectives.
Requirements specification with the guidance of this checklist if communicated to the developers is the
beginning of a full user-centred application development.

7.1.1 The user requirements checklist

The near future will probably see the definition of proper requirements representation models conceived
for a direct use by the end user, and proper GIS-Office technologies that will put the end user in a position
to operate alone on the geographic database to select maps and derive new territory representations.
However, much can already be done starting from the current practice by taking advantage of the
experience gained in many different GIS projects.
We consider a significant step forward the possibility, for the user, to collect alone his/her own
requirements. This knowledge can be used as a basis for the preparation of good bid requests and
contracts with the candidate application developers, and as a guide for the systematic control of the
project intermediate and final results. A very simple and familiar mean to help the user in this task is
providing him/her with a checklist that recalls all the main requirement collection aspects. In fact, one of
the most important issues of requirement collection is completeness in both functional and nonfunctional
terms. Then, the checklist helps the user to not forget significant aspects and to structure the collected
requirements so as to favour comparison, verification and (possibly) the reuse of previous documentation.
In order to understand which are the requirements that allow the user to represent his/her needs and
objectives, it is useful to consider the view the user has of the GIS application. In general the user is
neither interested in, nor informed of what happens inside the GIS platform; rather he/she tends to keep
thinking in terms of the concepts and objects that are familiar in his/her world: maps, symbols, scales,
drawings. The image the user has of a GIS application is exactly that resulting from the application
interface which, in some sense, plays the role of a ”window” on the underlying GIS system. In other words,
all what happens on the interface is a matter of requirement specification, the rest being necessarily left to
developer experience.
The second consideration to take into account in defining the user requirements checklist refers to the fact
that, typically, a GIS application is aimed at deriving information (usually a new map) from the data
available in the geographical database. When facing a new project the user traditionally describes to the
application developer the characteristics of the map to be derived and the sequence of operations to be
performed on the available data in order to achieve such a result. In short, user mental model is strongly
focused on the idea of the derivation process, hence the application cannot but adapt to, and possibly
reinforce, it. The checklist itself, in particular the part concerning the functional requirements, must be
defined clearly in this respect.

7.1.2 The procedure for criteria identification

14

The end user has a deep knowledge of the application domain and of the problem to be solved, but
normally s/he is not used to expressing in some structured and disciplined way his/her requirements. This
difficulty is due to at least two reasons: (i) every GIS project takes years to be carried out, thus the user is
seldom involved in requirement specification; (ii) analysis techniques constitute a rather specialised
competence, which is difficult to acquire and normally known only to the application developer.
In turn, the application developer is interested in collecting and interpreting the user needs with the aim of
identifying the most convenient solution to them. Convenience means, in GIS projects, limit the very high
costs of data collection and deliver a minimal set of functions in the shortest possible time. This habit is
not negative in itself as it tries to meet the user needs in reasonable economical conditions: unfortunately,
it can lead to misunderstandings and, ultimately, to the well-known and very diffused user dissatisfaction.
For these reasons we consider it unlikely that the user alone or the application developer alone are able to
propose a valuable and complete checklist. The user’s important contribution should be concentrated on
the indication of requirements for single GIS projects and on the final checklist validation and improvement
activity. Similarly, the application developer’s contribution is mainly focused on providing practice
knowledge from which a project (and hence an interface) design best practice can be drawn. A further
contribution comes, in this case, from those organisations that play the role of intermediary user, as they
represent the interests of user groups with respect to technology providers and application developers.
The BEST-GIS Consortium includes representatives of all these categories, which joined their efforts and
skills to draw a general and flexible checklist. The procedure followed in the identification of the
requirement specification criteria was based on four main steps:
1. A tentative checklist was prepared as a synthesis of experiences and practices
identified within the Consortium, and taking advantage of the study of some
particularly interesting application projects.
2. The checklist was submitted to users within and outside the BEST-GIS consortium
for validation, i.e. applying it to the collection of requirements of ongoing and new
projects.
3. The checklist below is an improved version based on the validation results.
4. The checklist has now been disseminated to collect further comments from a wider
audience which can lead to its periodic improvement, extension and possible
specialisation by type of application field.

7.2. How to use the checklist

Collecting and specifying the requirements for a GIS application is a difficult and critical work, especially
for the end user. The difficulty mainly arises from the need to explicitly determine all the aspects and
constraints that can have an impact on the application design and development. The criticism arises from
the fact that incompleteness and possible ambiguities have a negative effect on the following phases of
the application development cycle and introduce misunderstandings that require much effort in order to be
removed. For these reasons, and for the role that requirements play in the definition of a new project,
particular care must be spent in their collection and compilation.
In this section we give brief indications on how the checklist should be used effectively by the end user
and what the expected result is after its application.

7.2.1 Requirements specification (RS)

Generally speaking, requirements are intended as a description of the user problems which GIS
application must solve and the constraints the solution must satisfy. In order to understand their role it is
useful to remember that the requirements specification (RS) phase precedes the design and development
phases in the application development cycle. Thus, it enables the developer to fully understand the overall
nature and the specifics of the application, and also acts as an opening for the establishment of adequate
user contacts throughout the remaining phases of the cycle.
In particular, for very complex and innovative systems (as GIS applications are) a full RS is needed as a
basis for feasibility estimation in order to reduce contractual risks. It means that the RS document is
fundamental in establishing a correct and unambiguous contract with the developer organisation where all
the significant aspects are clarified and evaluated in their development cost and time. Besides, it is vital
that the specified requirements be verified at the end of the development cycle and during testing. This
document is valuable throughout the whole project as it is a clear and complete statement of the required
functionality for the intended application, jointly prepared and agreed upon by both the user and the
involved developer.
The application requirements represent the conversion of broad-based user needs into a working
specification document upon which development effort can be focused. The RS output should present all
 Conclusions 15

the functional and non-functional system requirements (or, at least, those identified at this early stage) and
indicate design and implementation directives of the intended application:
• Functional requirements display the functionality of the application. It means making
explicit the actions and operations which the application must provide to the user,
and the data types to which these functions are applied.
• Non-functional requirements tend to be constraints that the completed system must
fulfil. In addition to performance issues (e.g.: response time, data volume, execution
frequency) they include indications on user role, application audience, data
accessibility.
• Design directives are user constraints upon the structure of the system solution and
could detail hardware selection, data storage and transfer methods such as
communication protocols. Implementation directives constrain the developer by
defining choice of implementation language or database management system.

While the checklist proposed in this section deals with the first two points, design and implementation
directives are considered in sections 6 and 7 of these Guidelines.
An important aspect to consider when compiling an RS document is the form that this document should
take. Most of the RS models proposed in the literature are informal, in that they simply suggest a
reasonable organisation of the RS document into chapters and sections without defining a formal syntax
to fill it. One reason is that, at the specification time, many aspects are still open or not completely
decided: the RS document must be complete but it remains independent of implementation issues.
Another reason is that a formal RS language could hardly be employed by the end user and this would
limit its role and autonomy. Finally, the RS phase cannot consume too much effort as it consists in a
preliminary phase of a development cycle that could terminate at the feasibility stage.

7.2.2 Checklist application

Preparing the RS document means collecting and synthesising the viewpoints of the different identified
application users. In fact, because of its high cost, only a long life cycle and the benefits it can bring to a
number of users justify a GIS application. Each of these users tends to have his/her own focus on the
functions the application will make available: taking into account all of them is a necessary condition to
create a useful application. We see two alternative ways of using the proposed checklist to derive the
synthesis requirements:
• Every user collects and specifies his/her own requirements by following the checklist alone
(obviously, not all the users will consider all the points of the checklist). Then, the resulting
documents must be discussed and unified into the final RS document. This requires meetings
on the different sections, with the participation of interested users and, possibly, the
application developer. The main advantage of this approach is the total freedom of the single
user in expressing his/her viewpoint and, hence, the completeness of the final document. The
main drawback is the redundancy of the specification work as many users may give the same
indications on many points.
• Users organise meetings for the different sections of the checklist with the purpose of
discussing requirements point by point. The outcome of this work is directly the final RS
document. A first important by-product of this approach is a very early constitution of a
working group where all members are aware of the common interest and objectives. Besides,
convergence on a single point is likely to be reached faster than with the previous approach.
The drawback is that some users tend to become meeting leaders and impose their
viewpoints.
Going through the checklist sections, it is worth taking into account the following suggestions for a good
use of the checklist itself:

0. General requirements. This section recalls some general requirements that are applicable to
different projects and especially to software based projects. The requirements listed in this
section are general, and the accomplishment of each of them may depend on different items
among those which are listed in subsections 1 - 8.
16

1. Project organisation requirements. When compiling this section, the user must keep in
mind that a success key in every project is stating clearly, from the beginning the purpose and
scope of the intended initiative. In fact, many problems (high cost, long delivery time,
insufficient or overspent resources, changes with work in progress, conflicts with the
developer) often arise from starting a project whose content boundaries are not well
understood. Another aspect that is worth capturing is the user roles and the management
responsibilities along the project. This is necessary to avoid user participation only in the early
and final phases of the development cycle, and also to avoid vague developer identification of
his/her counterparts.

2. Project outcome requirements. As the project is usually aimed at producing maps,

characterising the project outcome is a very important issue. It is well known that starting from
outcome description makes it easier to describe all the other aspects of an application (input
data, computation process): this is the reason why we put this section first. Another
justification of the importance we assign to this section is that project feasibility is better
carried out by comparing the benefits expected from the project outcome (and the desired
due time) with the cost of its production (and the planned delivery time). This also holds for
those cases when the project result is not a map but, for instance, an analysis or simulation
package.

3. Map acquisition requirements. Once the project outcome has been described completely
the user has all the elements for understanding what the input data are for the application
he/she will use. In general, only some of them are already available in the user organisation
databases, hence a specific acquisition activity is often required. We suggest paying much
attention to this aspect since the acquisition of geographical data is a very time and resource
consuming task. Planning an application which relies on the acquisition of many new data
introduces risk elements that must be carefully evaluated. A better approach consists in
distinguishing the data to be fully acquired from those that can be imported from other
organisations or obtained by adaptation and completion. This checklist section includes points
that help the user in taking into account this possibility, and also suggests considering volume
and cost issues.

4. Derivation process requirements. Most GIS applications are aimed at studying and
comparing territory properties, that is, deriving new maps from those already available. After
having described the expected outcome and the input maps (that represent the analysed
territory properties) the derivation process is illustrated. This is, more than others, an end user
task (intended as the application domain expert) since he/she is the only one in condition to
say how the input data contribute to the construction of the project result. In fact, the
derivation process should be the exact image of the idea the user has of the problem to be
solved with the intended application. We suggest answering this checklist section by
preparing very clear and detailed information, that is, a precise representation of the functions
to perform on the input data. This requires, compared to the other sections, a higher degree
of formalization in describing the functions to be executed at every derivation step. For this
reason we propose that a catalogue be made available to the user which contains the
description of common or already developed functions(see section 6 and 7).

5. User interface requirements. Many requirements on the possibilities the application

interface should offer to the user are collected according to points of the other checklist
sections. In fact it is worth remembering that the application interface corresponds, for the
user, to the way the application is thought of. Here we invite the user to focus again on the
 Conclusions 17

interface to make explicit aspects that might have been neglected, so as to avoid their
specification while the development work is in progress. Aspects that require particular
attention are help and navigation capabilities, as well as protection against user errors or
unauthorised accesses. We suggest that this section be compiled in collaboration with the
developer, as it deals with technical issues.

6. Map visualisation requirements. A distinctive aspect of GIS applications is the role that
map rendering has for the users. The user is in charge of the complete definition of map
visualisations (size, colours, fonts, symbols, legends and the like) with respect to every
rendering means. We suggest considering the three main means available today, namely
workstation display, paper (through different plotting technologies) and the Internet. Although
the user is the only one in a condition to decide upon the aspect of visualised maps, important
help can come from having proper look-up tables available or, as an alternative, by
collaborating with the application developer.

7. Database organisation requirements. Geographical data have usually associated attribute

(quantitative, descriptive) data. This means that the GIS application is provided with both a
graphics database and an attribute database. While the application developer derives the
content of the former from requirements concerning project outcome, inputs and derivation
process, the latter needs further specifications. With this section we aim at driving the user to
consider which attribute data are useful, which are available and to which territory entities
they are associated. We suggest the user describe the application attribute data by means of
a simple and semi-formal conceptual model, possibly with the aid of the developer.

8. Specific application requirements. The two last sections are aimed at proposing further
points that are specific in a certain application context. After the user has compiled the
previous sections in all their aspects, he/she can consider the application section of specific
interest. Here he/she can find hints on needs and functions that are peculiar in such field:
they are derived from previous experiences and hence can be enriched every time the
checklist is used. The richer these sections become, the more effective their use in capturing
exhaustive requirements.

7.3 Checklist of functional and nonfunctional requirements

The following checklist is proposed as a guide to drive the end user in collecting and expressing the
requirements of a new GIS application project. In fact, going through the checklist the user has the
opportunity of ascertaining whether the comprehension he/she has of the application is sufficiently clear
and whether the collected requirements are complete and properly organised. In other terms, compiling
this checklist means building up the documentation which is recalled by each of the identified points.
At the time of its delivery the checklist corresponds to the knowledge, on the project development process,
that has been found within the BEST-GIS Consortium. Validation of the checklist showed that the degree
of completeness of this checklist is indeed rather high, the most important aspects on which a GIS project
relies are taken into account. Nevertheless, further points can be conveniently added as soon as they are
considered capable of capturing other aspects here neglected or collapsed.
An interesting direction to follow in making this checklist more and more effective is that of its
specialisation by type of application field. As shown in the last two sections, devoted respectively to
Environment Control and Urban Planning, it is useful to integrate the general aspects with application-
oriented points. These are mainly focused on recalling user needs that have often been met in concluded
and ongoing projects of the single application type. These sections can hence increase in number and
richness of points and thus constitute the principal evolution path for the checklist itself.
18

7.3.1 General requirements

This section concerns the specification of some general requirements aimed at satisfying fundamental
user needs. These requirements have to be accomplished not only in GIS projects, but in almost any
type of software based project. For each considered item a short description is provided. These general
requirements have to be considered as a general reference framework when addressing more specific
requirements listed in subsection 5.3.2 to 5.3.10.

0.1 Are the level of the detail and the accuracy of the work defined ?
0.2 Are the necessary speed of access and manipulation defined ?
0.3 Is the complexity of task under control?
0.4 Is the size of involved data under control ?
0.5 Are security requirements defined ?
0.6 Are reliability requirements defined ?
0.7 Is the use of legacy systems identified ?

7.3.2 Project organisation requirements

This section concerns the specification of requirements relative to the project intended as a whole and its
organisation and control. In particular, it is aimed at pushing the user to explicitly describe project aspects
that are often neglected or left to the initiative of the application developer. Because of the general view it
suggests, this section essentially refers to non-functional requirements.

1.1 Are the GIS project overall objectives and results clearly understood and
explicitly expressed?
1.2 Are the parties interested in the GIS project identified and the expected use of
the project results described?
1.3 Are general rules fixed to regulate the accessibility of the GIS project audience
to the project results?
1.4 Are the GIS project financial, temporal and other constraints clearly understood
and explicitly expressed?
1.5 Are the GIS project stakeholders identified with their respective decisional role
and priority?
1.6 Has the user organisation nominated a manager for the GIS project, who is
responsible for the relations with stakeholders and the application developer?
1.7 Is the GIS project workplan formally established with indication of the main
phases, precedence, milestones and checkpoints?
1.8 Are evaluations of the GIS project progress planned and the responsible person
for conformity verification and replanning identified?
1.9 Are installation procedures and acceptance tests explicitly established and
included in the GIS project contract?
 Conclusions 19

7.3.3 Project outcome requirements

This section is intended to be replicated for every single result (typically, a derived map) expected from the
GIS project execution. Main aspects are the explicit definition of the output map itself, the associated
descriptive and quantitative information and the representation of possible constraints on its use and
diffusion.

2.1 Is the output map properly described in terms of its meaning and expected use,
and unambiguously characterised by its component layers?
2.2 How critical is this product in terms of calculation frequency and (human and
computer) resource occupation, with respect to the other project outcomes?
2.3 Are the desired map features (scale, tiles, accuracy, quality, topographical
constraints, etc.) expressed?
2.4 Are the envisaged accesses to the output map (open, export, etc.) and to the
single layer coded so as to make the developer realise the corresponding
interface commands?
2.5 For each layer, is the relative content clearly described and its graphic
representation (points, lines, etc.) correctly determined?
2.6 For each layer, are the associated descriptive and quantitative data identified
and declared?
2.7 For each layer, is a default presentation (colours, symbols, data, etc.) decided
so as to make the developer realise the corresponding interface commands? (*)
2.8 Is the set of the input maps used to derive the output map in discourse clearly
identified and explicitly declared?
(*) The user could be facilitated by having proper look-up tables available for the selection
of the most suitable colours, styles, symbols and other effects. The tables should be
progressively extended with the introduction of new options decided by the user.

7.3.4 Map acquisition requirements

This section expresses the requirements on how to obtain the basic maps that constitute the input to the
GIS project. The following points must be replicated for every single map expected from the execution of
the GIS project. Generally speaking, they can be already available in some databases, or be imported
from other organisations, or even be acquired from a finalised territory survey. A complete identification of
the input maps is fundamental in planning the application development work.

3.1 Is the input map properly described in terms of its meaning and unambiguously
characterised by its component layers?
3.2 Are the envisaged accesses to the input map (open, import, etc.) and to the
single layer coded so as to make the developer realise the corresponding
interface commands?
3.3 For each layer, is the relative content clearly described and its graphic
representation (points, lines, etc.) known?
3.4 For each layer, are the associated descriptive and quantitative data identified
and declared?
3.5 For each layer, is a default presentation (colours, symbols, data, etc.) decided
so as to make the developer realise the corresponding interface commands? (*)
3.6 Is the input map source (local or remote database, adaptation of an existing
map, import from another organisation, result of on-field survey, etc.)
recognised?
3.7 In case of adaptation, is the required preparatory transformation or completion
activity described?
20

3.8 In case of import, is a format or other conversion required and, if any, is it

clearly described?
3.9 In case of a survey, are the survey aims focused, the data to collect identified,
and the digitisation criteria specified?
3.10 Is the size of the map to be acquired clearly understood and the acquisition or
adaptation cost evaluated?
(*) The user could be facilitated by having proper look-up tables available for the selection
of the most suitable colours, styles, symbols and other effects. The tables should be
progressively extended with the introduction of new options decided by the user.

7.3.5 Derivation process requirements

This section is aimed at stimulating the end user to express his/her own idea on how each GIS project
outcome can be obtained from the input maps. This information should be replicated for every output map,
although some phases can be common to more derivation processes. The sequence of operations and
transformations is split into elementary steps and each of these must be described in terms of the input
data, output data and operation performed. In particular, the operation description is very critical as it
impacts on software development.

4.1 Is the derivation process unambiguously described in terms of steps, each of

which can be represented separately from the others?
4.2 How critical is this derivation process and each of its steps in terms of execution
frequency and (human and computer) resource occupation, with respect to the
other project processes?
4.3 Is the process univocally denoted, and its representation and management
functions (do, undo, redo, etc.) explicitly requested, so as to make the
developer realise the corresponding interface commands?
4.4 For each step, are its input and output data identified, denoted and
characterised in graphical and descriptive terms?
4.5 For each step, is the transformation or derivation operation described in detail,
possibly taking advantage of an operation catalogue? (*)
4.6 Is the set of step input data, output data and operations properly classified so as
to make the developer realise the interface commands to access and activate
them?
4.7 Is a test and validation plan established to perform an early conformity control of
the operations as they are realised by the application developer?
(*) Having available a catalogue where the most common operations are already
characterised makes this task much simpler. The user can identify the operation of interest
within the catalogue, or describe it as a specialisation or a variant of an existing operation, or
add a new operation whenever it must be defined from scratch.
 Conclusions 21

7.3.6 User interface requirements

This section concerns the specification of requirements relative to the final user interface. The user
interface defines the way to access geographical data. Customisation of interface windows, menus,
buttons, and the like plays an important role for the usability of the system, defining the basic interactions
with data. Moreover, the user interface provides navigation capabilities so that he/she may find the
needed information. Hereafter the term view indicates a complete interface item or window possibly with
its map, menu, buttons, icons, tool bars and others. A complete interface consists of multiple views
connected by a set of (logical) links which provide one or more navigation paths.

5.1 Is the overall design of the user interface, views, navigation paths and links,
clearly defined by the application developer in a form suitable for user
evaluation?
5.2 Is an analysis of the proposed interface carried out to ensure that it provides an
efficient navigation to limit the number of steps necessary to get to the searched
data/map?
5.3 Is the design of each interface view properly defined to provide a clear and
efficient access to a consistent piece of information?
5.4 Does the interface design provide suitable help and is it simple enough to make
the beginners able to operate with its major features without using manuals?
5.5 Is the interface efficient enough to avoid tedious and time-consuming
interactions for the experienced, smart user?
5.6 Does the interface protect data against input errors, and provide help to check
input validity?
5.7 Does the interface protect data against unauthorised accesses?
5.8 Are the characteristics of the overall environment (single application, centralised
or distributed control) taken into account by the interface design?

7.3.7 Map visualisation requirements

This section collects the requirements on the desired aspect of map rendering. The following points apply
to every single rendered map, no matter if it is an input datum, an output datum, an intermediate datum or
any combination of them. At least three different representation media should be considered: display,
paper and the Internet. Indications on the aspect that every map and its single layers will take on the
alternative media, and the definition of possible freedom degrees for the user in deciding the rendering
form, are taken into account.

6.1 Is map visualisation clearly and fully described in general terms

(scale, style, legend, etc.)? (*)
6.2 For each layer, is the desired rendering (colours, symbols, data, etc.) decided
so as to make the developer realise the corresponding interface commands? (*)
6.3 Are the relations between layer visualisations within the map (overlapping,
transparency, and other effects) made explicit? (*)
6.4 For each display map, are the required interactive graphical functions (zooming,
highlighting, changes in colour and other aspects, etc.) decided so as to make
the developer realise the corresponding interface commands? (*)
6.5 For each paper map, is the resulting sheet quality (size, type of paper, type of
plotter, etc.) classified so as to make the developer realise the corresponding
interface commands? (*)
6.6 For each Internet map, is the simplified aspect of the resulting map, and the
possible links to other data, decided so as to make the developer realise the
corresponding interface commands? (*)
(*) The user could be facilitated by having proper look-up tables available for the selection
22

of the most suitable colours, styles, symbols and other effects. The tables should be
progressively extended with the introduction of new options decided by the user.

7.3.8 Database organisation requirements

This section is intended to provide help in evaluating the requirements for databases associated to a GIS
project. The database main goal is here to hold information that cannot be adequately represented in a
graphical manner, and to provide an alphanumeric integration of graphical information. In any case, most
data contained in the database are normally geo-referenced. Hereafter we use the term attribute data to
indicate data contained in the database.

7.1 Are the meaning and function of attribute data clearly specified?
7.2 Are the sources of attribute data clearly identified and the procedures for data
update defined?
7.3 Is the correspondence between geo-elements and classes of attribute data
clearly established?
7.4 Are the relationships between attribute data expressed at the conceptual level?
7.5 Are data import/export problems clearly identified and addressed?
7.6 Are the volumes of attribute data understood and the acquisition cost
evaluated?

7.3.9 Environment Control requirements

This section represents an example of specialised points with respect to the single application context.
While general-purpose requirements are collected with the previous sections, here the focus is on content
and method issues that are typical of the considered context. A progressive extension of this section is
expected by those organisations that have acquired experience in the Environment Control field.

8.1 Are the features of the required Digital Terrain Model (DTM) clearly understood
so as to drive the developer in choosing the right model?
8.2 Does the application require visibility analysis (i.e. determination of the territory
extent visible from a given point) by using a DTM?
8.3 Does the application require hydrological flow analysis (i.e. determination of
water flow paths) by using a DTM and a fluid pressure model or ground water
model?
8.4 Does the application require real time hydraulic simulation (i.e. simulation for
flood management, simulation for surface pollution propagation)?
8.5 In general, which kind of integration is expected between the GIS system and
external packages for environmental modelling?
8.6 Does the application require the loading of external data sets coming from
environmental monitoring (e.g. on line acquisition, real time information from
sensors)?
8.7 Does the application require the combination of raster images with vector
maps?
8.8 Does the application require the support to raster analysis functions (e.g.
analysis of satellite images)?

7.3.10 Urban Planning requirements

This section represents an example of specialised points with respect to the single application context.
While general-purpose requirements are collected with the previous sections, here the focus is on content
and method issues that are typical of the considered context. A progressive extension of this section is
expected by those organisations that have acquired experience in the Urban Planning field.
 Conclusions 23

9.1 Does the application require the integration of the different levels of Urban
Planning committed to different decision levels?
9.2 How should data and information sharing among the different users be
managed?
9.3 Do any functions of this application need to be accessible to users not skilled in
GIS technology (e.g. decision-makers)?
9.4 Does the application require reading CAD formats directly, without importing
them (as urban planners may have large heritage of CAD maps)?
9.5 Does the application require calculating parallel buffers to street centre lines, so
as to determine affectation to private land?
9.6 Does the application require simulation functions (e.g. for evaluating future
scenarios according to hypothesised development models or planned
decisions)?
9.7 Does the application require performing network analysis with real time data
(e.g. traffic analysis, traffic lights management)?
9.8 Does the application require performing dynamic segmentation?
9.9 Does the application require performing ”roving window” neighbourhood
analysis?
24

7.1 Introduction to the checklist

7.2 General requirements for the e-service implementation

7.3 Organisational requirements

7.4 Promotional requirements

7.5 Back Office requirements

7.6 Front Office requirements

7.7 Geographical Information requirements

 Conclusions 25

8. CONCLUSIONS
This book describes how Geographical Information is used and produced with today’s
Information Technology. It attempts to give an overview of the situation in Europe. We have
seen the contributions provided by the technology to change the way Geographical Information
is collected, managed and distributed. We witness a transformation of the Geographical
Information industry from cartography to GI business. The transformation is gradual and follows
the potential provided by the technology with a delay of several years, because the industry
consists not only of the technology – which could be changed quickly – but also of organisations
and institutions, which are much slower to change.
When the first cars were designed, they appeared as “horse drawn carriages without horses”,
but had the same form, the same basic parts as horse drawn carriages. It took more than fifty
years to develop a “car” structure that was emancipated from the horse carriage. Similarly, when
information technology was initially applied to cartography, the product was still a map and
distributed as a printed paper map. Slowly, we find new, more suitable solutions where
information is produced and communicated on demand in small units – just what is needed.
We hope to have shown the availability of the technology to improve the methods used for
collecting, managing and distributing Geographical Information. The technology is here. We
have also provided a glimpse at the thousands of useful applications, where Geographical
Information can help people, citizens, companies, organisations and governments to make
better decisions and thus help us to make better use of the limited resources of the world and to
improve citizen wealth and the environment at the same time. The demand is here.
Many of these applications need relatively simple, often used geographical data, topographic
map data, demographic data as collected by the national statistical offices, which is all stored on
some computers. The computers are linked together and technically the bits can be transferred
from the source to the place where they are needed. There are challenges in providing the
organisational structure to make this happen.
The world is not only technology and not everything that is technically feasible should be
done. The unlimited collection of information about people and their communication would
change the way we interact socially and is potentially dangerous for human society. It is
necessary to carefully assess the dangers and the benefits and to establish rules that preserve
important values of society (e.g. personal freedom, privacy etc.). These values are not the same
for every society and therefore the rules must be adapted to the particulars of different countries.
The organisations that are involved today with Geographical Information, National Mapping
agencies in particular have an important role to play in the future Information Society.
Geographical Information is widely used and it has been proposed to consider it as an
“infrastructure” which a country must provide as it provides roads, police or education. The role
of agencies for Geographical Information Infrastructures is different from the role of today’s
National Mapping Agencies – not less important, but very different. Every organisation involved
with Geographical Information today is facing the challenge to find the new role it plays in the
future Geographical Information Infrastructure.
The future for Geographical Information is bright: there is a strong demand that is increasing
rapidly. New technology makes the production and distribution of Geographical Information
much more feasible. Geographical Information Systems move from systems designed by
specialists for specialists and having few users within closed organisations to systems designed
for use by the population at large. The market will truly explode if we can provide the services
requested.
To make this happen, the technology must be made simpler to use through standardisation:
unnecessary complications that result from proprietary solutions have no place in the Information
Society of the twenty-first century. Organisations must adapt to the Information Technology –
which is not a problem specific to Geographical Information as the general discussion of
copyright etc. testifies. The spatially aware professionals, that is surveyors, geographers,
environmentalists, and all the other professionals working with spatial data can jointly contribute
to allow progression at the turn of the millennium.
 Annex I1 27

ANNEX 1: TEMPLATE FOR ACTION PLAN

28

ANNEX 2: WEB LINKS

This annex will contain links (URL’s) and keywords to EU-related sites and big initiatives such as
European commission, joint research Centre GIS page, Centre for Earth Observation, Agenda
2000, agenda 21, GNSS etc. this list of links can also be found at the PANEL-GI website
http://www.gisig.it/panel-gi/.

European Commission

Europa, European Union web server http://www.europa.eu.int/

European Commission Community Research and
http://www.cordis.lu/
Development Information Service (Cordis)
European Commission Information Dissemination on
http://ams.egeo.sai.jrc.it/
GI and GIS
Joint Research Centre (JRC) http://www.jrc.org/
JRC Space Applications Institute (SAI) http://www.sai.jrc.it/
Information Society Technologies Programme http://www.cordis.lu/ist/
Information Society Promotion Office (ISPO) http://www.ispo.cec.be/
GI and GIS Project (JRC) http://gi-gis.aris.sai.jrc.it/
European Commission Directorate General http://europa.eu.int/comm/dgs/information_society/in
Enterprise and the Information Society dex_en.htm
GISCO (Eurostat) http://europa.eu.int/comm/eurostat/
Centre for Earth Observation (CEO) http://www.ceo.org/
Agenda 2000 http://europa.eu.int/comm/agenda2000/
National/International links

European Environment Agency (EEA) http://www.eea.dk

Multipurpose European Ground Related Information
http://www.megrin.org/
Network (MEGRIN)
Association Française pour l’Information
http://www.cnig.fr
Géographique (AFIGEO)
The Association for Geographical Information
http://www.uniroma1.it
Laboratories in Europe (AGILE)
Association for Geographical Information (AGI) (UK) http://www.agi.org.uk/
Portuguese National Infrastructure for Geographical
http://snig.cnig.pt
Information (SNIG) (Portugal)
The Citizen component of the SNIG (GEOCID)
http://geocid-snig.cnig.pt/
(Portugal)
National Land Survey of Finland (NLS) http://www.nls.fi
The National Mapping Agencies of Europe (CERCO) http://www.cerco.org/
National Centre for Geographical Information and
http://www.ncgia.ucsb.edu/
Analysis (NCGIA) (USA)
The Association of the Geological Surveys of the
http://www.eurogeosurveys.org/
European Union
Geocommunity http://www.geocomm.com/links/education/
 Annex I1 29

ESRI http://www.esri.com/
INTERGRAPH http://www.intergraph.com/
LASERSCAN http://www.laserscan.com/
SICAD Geomatics http://www.sicad.com/
PCI Geomatics http://www.pcigeomatics.com/
Data and Metadata

European Spatial Metadata Infrastructure (ESMI) http://esmi.geodan.nl/

National Geospatial Data Clearinghouse (NSDI)
http://nsdi.usgs.gov/
(USA)
MEGRIN‘s Geographical Data Description Directory
http://www.megrin.org/gddd/
(GDDD)
National Spatial data Infrastructure (NSDI) (USA) http://www.fgdc.gov/
Global Spatial Data Infrastructure (GSDI) http://www.gsdi.org/
Interoperability

GIS Interoperability Stimulating the Industry in

http://gipsie.uni-muenster.de/
Europe (GIPSIE)
Open GIS Consortium (OGC) http://www.opengis.org/
PANEL GI Project partners

Geographical Information Systems International

http://www.gisig.it
Group GISIG (Italy)
CNIG (Portugal) http://snig.cnig.pt
European Umbrella Organisation for Geographical
http://www.eurogi.org/
Information (EUROGI)
Technical University of Vienna (Austria) http://www.geoinfo.tuwien.ac.at/
National Institute for Research and Development in
http://td1.ici.ro/
Informatics, ICI (Romania)
National Land Information Systems Users
http://www.gispol.org.pl
Association (GISPOL, Poland)
Masaryck University (Czech Republic) http://www.geogr.muni.cz/
FOMI (Hungary) http://www.fomi.hu/
HUNAGI (Hungary) http://www.fomi.hu/hunagi/index.htm
Technical University Sofia (Bulgaria) http://www.vmei.acad.bg/
University of Zilina (Slovakia) http://www.utc.sk/
Examples of GIS Applications Projects

DISGIS http://www.disgis.com
Tele Atlas http://www.teleatlas.com/
Web Mapping testbed http://www.opengis.org/
Geobusiness http://www.geomarketing.net
http://www.gismo.nl
http://www.wigeogis.at
30

Crop Growth Monitoring System (CGMS) http://gi-gis.aris.sai.jrc.it/agro-meteo/

City Council of Genova http://www.comune.genova.it/
City Council of Vienna http://service.magwien.gv.at/wien-grafik/wo.html
EURSIS http://gi-gis.aris.sai.jrc.it/soils/esb.html
CORINE http://etc.satellus.se
TREES (Tropical deforestation monitoring) http://www.gvm.sai.jrc.it
Cadastre http://www.bev.gv.at
Radioactivity Environmental Monitoring http://java.ei.jrc.it/
MURBANDY (Monitoring urban dynamics) http://murbandy.sai.jrc.it
 Annex III 31

ANNEX 3: GLOSSARY (IT/MIS)

The table below is a subset1 of entries kindly made available from:

• the AGI dictionary (http://www.agi.org.uk/pag-es/dict-ion/dict-agi.htm),
• the ESRI Glossary2 (http://www.esri.com/library/glossary/glossary.html) and
• the glossary from OGC’s “OpenGIS guide” (http://www.opengis.org/techno/guide.htm).
One of the interesting aspects of GIS is that many people are still struggling with its definition.
Plenty of definitions exist, each with a (slightly) different focus. Some are limited to the
technological aspect; others include the scientific or even organisational side. As an illustration,
here are five different definitions. For the main glossary, we have selected the AGI definition,
mentioned here first.
GIS is:
1. A computer system for capturing, storing, checking, integrating, manipulating, analysing and
displaying data related to positions on the Earth's surface. Typically, a Geographical
Information System (or Spatial Information System) is used for handling maps of one kind or
another. These might be represented as several different layers where each layer holds data
about a particular kind of feature. Each feature is linked to a position on the graphical image
of a map. (AGI)
2. A set of tools for collecting, storing, retrieving at will, transforming and displaying spatial data
from the real world for a particular set of purposes. (Burrough, 1998)
3. An organized collection of computer hardware, software, geographical data, and personnel
designed to efficiently capture, store, update, manipulate, analyse, and display all forms of
geographically referenced information. (ESRI)
4. A database system in which most of the data are spatially indexed, and upon which a set of
procedures are operated in order to answer queries about spatial entities in the database.
(Smith, 1987)
5. A special-purpose digital database in which a common spatial coordinate system is the
primary means of reference. GISs contain subsystems for: 1) data input; 2) data storage,
retrieval, and representation; 3) data management, transformation, and analysis; and 4) data
reporting and product generation. It is useful to view GIS as a process rather than a thing. A
GIS supports data collection, analysis, and decision-making and is far more than a software
or hardware product. Other terms for GIS and special-purpose GISs include: Land-Base
Information System, Land Record System, Land Information System, Land Management
System, Multipurpose Cadastre, and AM/FM (automated mapping and facilities management)
system. (OGC)

1 The criteria for an entry to be included in the Panel-GI glossary are:

• The entry appears in the text of the package, or
• the entry is part of basic, essential GIS jargon, and
• the entry is not part of common sense general language.
Where duplicates occur, preference has been given to use entries from the AGI dictionary, as this is European and
non-proprietary.
2 Selected terms and definitions reprinted courtesy of Environmental Systems Research Institute, Inc. Copyright ©
1986-2000 Environmental Systems Research Institute, Inc. All rights reserved. www.ESRI.com.
32

Acceptance Test A series of tasks performed by either hardware or software to assess performance.
Test data is used as input and the response is analysed regarding suitability for
operational use. Usually conducted under the control of the procurer of the product,
rather than the vendor, to determine whether a product lives up to the claims of the
vendor and whether it is fit for purpose.
Accessibility An aggregate measure of how reachable locations are from a given location.
Accuracy The closeness of observations, computations or estimates to the true value as
accepted as being true. Accuracy relates to the exactness of the result, and is
distinguished from precision that relates to the exactness of the operation by which
the result was obtained.
Address A mechanism for relating two files using address as the relate item. Geographical
Matching coordinates and attributes can be transferred from one address to the other. For
example, a data file containing student addresses can be matched to a street
coverage that contains addresses creating a point coverage of where the students
live.
Aggregation The grouping together of a selected set of like entities to form a single entity. For
example, grouping sets of adjacent areal units to form larger units, such as
grouping UK electoral wards to form districts. Any associated attribute data is also
aggregated into a single group.
AI Artificial Intelligence. A term that applies to that branch of computer science, which
aims to imitate the thought, processes of the human brain. There are a number of
different methods of achieving this, these include creating a computer with a similar
although greatly simpler structure), as the human brain through the use of neural
networks, or alternatively, to simply imitate the thought processes through the use
of software. The latter approach is perhaps the most common and has resulted in
the development of expert or knowledge based systems
Algorithm A finite ordered set of well-defined rules for the solution of a problem.
AM/FM Automated Mapping and Facilities Management. Geographical Information System
designed for the optimal processing of information about utilities and infrastructures
such a pipes, cables networks and power lines. These systems combine digital
mapping functionality with systems for managing spatial and non-spatial
databases.
ANSI American National Standards Institute. A US institute which co-ordinates standards
relating to many different aspects of computing. It has strong links with ISO, the
International Standards Organisation; consequently many ANSI standards are ISO
approved.
API See Application Program Interface
Application A process that uses data or performs some function on a computer system.
Application An API is a set of system calls or routines for application programs to access
Program services from operating systems or other programs. An API allows your program to
Interface work with other programs, possibly on other computers. API is fundamental to
client-server computing.
Arc An ordered string of vertices (x,y coordinate pairs) that begin at one location and
end at another. Connecting the arc's vertices creates a line. The vertices at each
endpoint of an arc are called nodes.
Architecture Internal structure of a computer system, including the organisation of the major
components, memory storage, I/O operations and the user interface. Often
displayed as a schematic diagram.
Archive A store of information on permanent storage media, usually off-line
Area A bounded continuous two-dimensional object usually defined in terms of an
external polygon or in terms of a continuous set of grid cells.
ASCII American Standard Code for Information Interchange. A set of codes for
representing alphanumeric information. For example, the letter 'A' is stored as the
value 65, and 'B' as 66 and so on until the letter 'Z' which is 90.
 Annex III 33

Attribute 1. A trait, quality or property describing a geographical feature.

2. A fact describing an entity in a relational data model, equivalent to the column in
a relational table.
Back-up A copy of a file, a set of files, or whole disk for safekeeping in case the original is
lost or damaged.
Bandwidth A measure of the volume of data that can flow through a communications link.
Base Map A map containing geographical features used for locational reference. Roads, for
example, are commonly found on base maps.
Benchmark A standard test devised to enable comparisons to be made between computer
systems.
Benchmark A variety of tests undertaken on computer software or hardware to ensure products
Testing meet all user requirements and conform to the claims made by vendors regarding
product performance. Typically these tests involve data and operations most likely
to be encountered in the workplace.
Binary A number system of base 2. Numbers are represented simply as a series of 0's or
1's in contrast to base 10 number systems that represent numbers using the
characters 0-9.
Bit Short for binary digit. A bit can take one of two possible binary values, 0 or 1. It is
the smallest unit of storage and information within a computer. The values 1 and 0
can represent on/off, yes/no or true/false.
Bitmap The representation of an image on a computer screen whereby each pixel
corresponds to one or more bits.
Buffer A zone of a specified distance around coverage features. Both constant- and
variable-width buffers can be generated for a set of coverage features based on
each feature's attribute values. The resulting buffer zones form polygons-areas that
are either inside or outside the specified buffer distance from each feature. Buffers
are useful for proximity analysis (e.g., find all stream segments within 300 feet of a
proposed logging area).
Byte A unit of computer storage of binary data usually comprising 8 bits, equivalent to a
character. Hence Megabyte one million bytes, and Gigabyte, one thousand million
bytes.
CAD See Computer Aided Design.
Cadastre A public register or survey that defines or re-establishes boundaries of public
and/or private land for purposes of ownership and taxation.
Calibration In spatial analysis, calibration is the process of choosing attribute values and
computational parameters so that a model properly represents the real-world
situation being analysed. For example, in pathfinding and allocation, calibration
generally refers to assigning or calculating appropriate values to be entered in
impedance and demand items.
CAM See Computer Aided Mapping
Cartesian A two-dimensional, planar coordinate system in which x measures horizontal
Coordinate distance and y measures vertical distance. Each point on the plane is defined by
System an x,y coordinate. Relative measures of distance, area, and direction are constant
throughout the Cartesian coordinate plane.
Cartography The organisation and communication of geographically related information in either
graphic or digital form. It can include all stages from data acquisition to
presentation and use.
CD-ROM A read only optical disk similar to a commercial audio compact disk. The storage
capacity of CD-ROM's is approximately 650 Megabytes.
CEN Comitée Européen de Normalisation. The regional standards group for Europe. It is
not a recognised standards development organisation, and so cannot contribute
directly to ISO. It functions broadly as a European equivalent of ISO and its key
goal is to harmonise standards produced by the standards bodies of its member
countries. Membership is open to EC and EFTA countries.
Central That part of a computer where essential arithmetic and logical operations are
Processing Unit performed, often considered as the heart of a computer.
34

CERCO Comitée Européen des Responsables de la Cartographie Officielle.

The European Committee of Representatives of Official Cartography, under the
auspices of the Council of Europe.
Class Group of entities that share given attribute values.
Classification A method of generalisation. In the process of classification, an attempt is made to
group data into classes according to some common characteristics thereby
reducing the number of data elements. Classification tends to be
based upon the attributes or characteristics of data rather than their geometry. In
digital image processing, images are usually classified according to the spectral
properties of the pixels composing the image. In spatial analysis, a map can be
classified according to any attribute value, for example, soil types, population
density, unemployment etc. The result of performing classification is a thematic
derived map.
Client A computer system or process that requests a service of another computer system
or process (a server). For example, a GIS workstation requesting data from a
database server is a client of the database server.
Client-Server A software partitioning paradigm in which a distributed system is split between one
or more server tasks which accept requests, according to some protocol, from
(distributed) client tasks, asking for information or some action. There may be
either one centralised server or several distributed ones. This model allows clients
and servers to be placed independently on nodes in a network. GIS are usually
based upon client-server architecture. The database may exist upon a central
server, however the graphics subsystem exists upon a local workstation, and the
two communicate via a local area network.
COM Component Object Model.
Microsoft's underlying object architecture for allowing objects written by different
companies in different programming languages to interact.
Computer Aided 1. The design activities, including drafting and illustrating, in which information
Design processing systems are used to carry out functions such as designing or improving
a part or a product.
2. Software packages designed for high quality graphical output regarding the
design of products.
Computer Aided Software packages designed for graphical output in the form of maps. These
Mapping packages usually contain no analytical or manipulative qualities as the data has no
topological links.
Conceptual A database modelling technique that defines the types of entities or objects which
Model are of immediate interest and the relationships between them without being
specific to any particular database semantics. Thus a conceptual model can
theoretically be implemented in any type of database management system.
Configuration The particular arrangement of computer hardware and software for use within
specific applications.
Continuous Data A surface for which each location has a specified or derivable value. Typically
represented by a tin or lattice (e.g., surface elevation).
Contour A line connecting points of equal surface value.
Control Point A system of points with established horizontal and vertical positions which are used
as fixed references in positioning and relating map features, aerial photographs or
remotely sensed images.
Coordinate A reference system used to measure horizontal and vertical distances on a
System planimetric map. A coordinate system is usually defined by a map projection, a
spheroid of reference, a datum, one or more standard parallels, a central meridian,
and possible shifts in the x- and y-directions to locate x,y positions of point, line,
and area features.
CORBA Common Object Request Broker Architecture.
The basic distributed object scheme developed by the Object Management Group
(OMG), a consortium similar to OGC but focused on object technology instead of
distributed geoprocessing. Object Request Brokers (ORBs) help clients find
servers.
 Annex III 35

CPU See Central Processing Unit.

Currency The level to which data is kept up to date.
Data Conversion The translation of data from one format to another.
Data Dictionary A repository of information in a database in which information is stored on all the
objects within the database and their relationships.
Data Model An abstraction of the real world which incorporates only those properties thought to
be relevant to the application at hand. The data model would normally define
specific groups of entities, and their attributes and the relationships between these
entities. A data model is independent of a computer system and its associated data
structures. A map is one example of an analogue data model.
Data Quality Indications of the degree to which data satisfies stated or implied needs. This
includes information about lineage, completeness, currency, logical consistency
and accuracy of the data.
Data Set A named collection of logically related data items arranged in a prescribed manner.
Data Type The characteristic of columns and variables that defines what types of data values
they can store. Examples include character, floating point and integer.
Database A logical collection of interrelated information, managed and stored as a unit,
usually on some form of mass-storage system such as magnetic tape or disk. A
GIS database includes data about the spatial location and shape of geographical
features recorded as points, lines, areas, pixels, grid cells, or tins, as well as their
attributes.
Database Formally, database design can be regarded as the third stage in the development
Design of a database. It is where the conceptual model, developed during the data
modelling or second stage, is applied to a specific database management system.
Database A collection of software for organising the information in a database. Typically a
Management DBMS contains routines for data input, verification, storage, retrieval and
System combination.
Datum A set of parameters and control points used to accurately define the three-
dimensional shape of the Earth (e.g., as a spheroid). The datum is the basis for a
planar coordinate system. For example, the North American Datum for 1983
(NAD83) is the datum for map projections and coordinates within the United States
and throughout North America.
DBMS See Database Management System.
De Facto A standard that has been informally adopted, often because a particular vendor
Standard was first to market with a product that became widely adopted. MS-DOS and
Microsoft Windows are examples.
De Jure An official standard created in a formal “juried” process, such as the International
Standard Organization for Standards Technical Committee 211 (ISO TC/211).
DIGEST The Digital Geographical Information Exchange Standard is produced under
authority of NATO's Digital Geographical Information Working Group. DIGEST is a
standard for digital Geographical Information which will enable interoperability and
compatibility among national and multinational systems and users.
Digital Elevation A digital representation of a continuous variable over a two- dimensional surface by
Model a regular array of z values referenced to a common datum. Digital elevation
models are typically used to represent terrain relief. Also referred to as 'digital
terrain model' (DTM).
Digital Map The representation of data in graphical form, whereby the data are divided into
discrete quantified units.
Digital Terrain See digital elevation model.
Model
Discrete Data Geographical features containing boundaries: point, line or area boundaries.
Distributed A database for which different components are located on different nodes in a
Database computer network. This network can be a simple LAN with a small number of
users, to a database that is connected via a WAN such as the Internet with
possibly thousands of users.
36

Distributed A complex computer system where the workload is spread between two or more
System computers linked together by a communications network.
DOS Disk Operating System. Originally created by Microsoft for the IBM PC as one of
the first operating systems. Operations are carried out through command line,
rather than menu-driven instructions. Has become a de-facto standard within the
industry.
DTM Digital terrain model. See digital elevation model.
DXF Data Exchange Format. A format for storing vector data in ASCII or binary files.
Used by CAD software for data interchange.
EDI See Electronic Data Interchange
EDIFACT Electronic Data Interchange For Administration, Commerce and Transport.
A set of syntax rules for the preparation of messages to be interchanged.
Electronic Data The interchange of processable data between computers electronically.
Interchange
Encoding The assignment of a unique code to each unit of information, such as encoding of
English using the ASCII character set.
Entity A collection of objects (persons, places, things) described by the same attributes.
Entities are identified during the conceptual design phase of database and
application design.
Entity A graphical representation of the entities and the relationships between them.
Relationship Entity relationship diagrams are a useful medium to achieve a common
Diagram understanding of data among users and application developers.
Entity- A logical way of describing entities and their relationships within relational
Relationship databases. An entity-relationship model is often used in the conceptual design
Model phase of creating a relational database and is usually expressed as a diagram
showing the entities and the linkages that exist between them.
Eurostat The European Community statistical agency.
Expert System A computer system that provides for solving problems in a particular application
area by drawing inferences from a knowledge base acquired by human expertise, it
is a form of artificial intelligence. Knowledge based systems, or more commonly,
expert systems have been used for purposes of automated map generalisation.
This is an area that they have particular application within the field of Geographical
Information Systems.
Feature A set of points, lines or polygons in a spatial database that represent a real-world
entity. The terms feature and object are often used synonymously.
Federal A US organisation composed of representatives of several federal agencies and
Geographical GIS vendors, the FGDC has the lead role in defining spatial metadata standards.
Data Committee
FGDC See Federal Geographical Data Committee
Field A set of one or more alphanumeric characters comprising a unit of information.
Format The pattern into which data are systematically arranged for use on a computer. A
file format is the specific design of how information is organized in the file.
Generalisation Simplification of map information, so that information remains clear and uncluttered
when map scale is reduced. Usually involves a reduction in detail, a resampling to
larger spacing, or a reduction in the number of points in a line. Traditionally this has
been done manually by a cartographer, but increasingly semi-automated and even
automated methods have been used, particularly in conjunction with a GIS.
Geodata Information that identifies the geographical location and characteristics of natural or
man-made features and boundaries of the Earth. Geodata represent abstractions
of real-world entities, such as roads, buildings, vehicles, lakes, forests and
countries.
Geographical See Spatial Analysis
Analysis
Geographical Data that record the shape and location of a feature as well as associated
Data characteristics, which define and describe the feature.
 Annex III 37

Geographical Information about objects or phenomena that are associated with a location relative
Information to the surface of the Earth. A special case of spatial information.
Geographical A computer system for capturing, storing, checking, integrating, manipulating,
Information analysing and displaying data related to positions on the Earth's surface. Typically,
System a Geographical Information System (or Spatial Information System) is used for
handling maps of one kind or another. These might be represented as several
different layers where each layer holds data about a particular kind of feature. Each
feature is linked to a position on the graphical image of a map.
Geometry The shape of the represented entity or entities, in terms of its stored co-ordinates
and the lines connecting those co-ordinates.
GI See Geographical Information
GIS See Geographical Information System
Global A satellite based navigational system allowing the determination of any point on the
Positioning earth's surface with a high degree of accuracy given a suitable GPS receiver.
System
GPS See Global Positioning System
Graphical User The use of pictures rather than just words to represent the input and output of a
Interface computer program.
Grid A geographical data model representing information as an array of equally sized
square cells arranged in rows and columns. Each grid cell is referenced by its
geographical x,y location. See also raster.
Ground Control Any point which is recognisable on both remotely sensed images, maps and aerial
Point photographs and which can be accurately located on each of these. This can then
be used as a means of reference between maps or, more commonly, between
maps and digital images. Often used in the geometric correction of remotely
sensed images and surveying.
GUI See Graphical User Interface.
Hardware All or part of the physical components of an information processing system. For
example, hardware might include the monitor, printer/plotter, network, digitising
tables, scanners as well as the computers themselves.
I/O Input/Output. Refers to the ability to input data for processing or display purposes,
through peripheral devices, and subsequently produce either hard or soft copy
output from these processes. Peripheral devices which can be used to input data
are digitising stations, photogrammetric workstations, alphanumeric workstations
and scanners. Output devices include plotters and printers.
IEC International Electrotechnical Committee.
This organisation has the same status as ISO, but focuses on electrical and
electrotechnical issues, especially electricity measurement, testing, use and safety.
IEEE Institute of Electrical and Electronics Engineering Inc.
A major international professional body and an accredited standards setting
organisation.
Interface For communication, a hardware and/or a software link that connects two computer
systems, or a computer and its peripherals, or between a computer and its user.
Interoperability The ability of different software systems to exchange information and requests,
using methods, through an object request broker in accordance with OMG
standards. It allows different applications from different vendors to work together
seamlessly.
Interpolation The estimation of z values of a surface at an unsampled point based on the known
z values of surrounding points.
ISDN Integrated Services Digital Network. Provides combined transmission of analogue
and digital services. It is a set of communications standards allowing a single wire
or optical fibre to carry voice, digital network services and video.
38

ISO International Standards Organisation. A world-wide federation of national

standards bodies that develops international standards. A Technical Committee
(ISO/TC211) is developing international Geographical Information standards.
Among many other computing standards, ISO also maintains an SQL standard and
is developing an extended version, SQL3, which will support queries on
geographical data sets.
Java Java is an object oriented application development language written by Sun
Microsystems. It is an interpreted object oriented programming language similar to
C, but has been designed to run with minimum resources. It is entirely platform
independent and is intended to be used to create Java applet (small application)
objects which can be stored on public servers and downloaded to PCs or other
network devices when needed.
Knowledge A computer system that provides for solving problems in a particular application
Based System area by drawing inferences from a knowledge base acquired by human expertise, it
is a form of artificial intelligence. Knowledge based systems, or more commonly,
expert systems have been used for purposes of automated map generalisation.
This is an area that they have particular application within the field of Geographical
Information Systems.
LAN See Local Area Network
Land A system for capturing, storing, checking, integrating, manipulating, analysing and
Information displaying data about land and its use, ownership and development.
System
Lineage The ancestry of a dataset describing its origin and the processes by which it was
derived from that origin. Lineage is synonymous with provenance, but is more than
just the original source or author.
LIS See Land Information System
Local Area Computer data communications technology that connects computers at the same
Network site. Computers and terminals on a LAN can freely share data and peripheral
devices, such as printers and plotters. LANs are composed of cabling and special
data communications hardware and software.
Macro A text file containing a sequence of commands that can be executed as one
command. Macros can be built to perform frequently used, as well as complex,
operations.
Map Projection A mathematical model that transforms the locations of features on the Earth's
surface to locations on a two-dimensional surface. Because the Earth is three-
dimensional, some method must be used to depict a map in two dimensions. Some
projections preserve shape; others preserve accuracy of area, distance, or
direction. See also coordinate system. Map projections project the Earth's surface
onto a flat plane. However, any such representation distorts some parameter of the
Earth's surface be it distance, area, shape, or direction.
Metadata Data about data and usage aspects of it.
Middleware Software that enables applications to access data and computing resources
distributed across networked computers, regardless of incompatible operating
systems and networks.
Model A simplified representation of reality used to simulate a process, understand a
situation, predict an outcome, or analyse a problem. A model can be viewed as a
selective approximation which, by elimination of incidental detail, allows some
fundamental aspects of the real world to appear or be tested.
Multimedia A combination of a variety of user interfaces and communication elements such as
still and moving pictures, sound, graphics and text.
National Institute National Institute of Standards and Technology is the agency that produces the
of Standards Federal Information Processing Standards (FIPS) for all US government agencies
and Technology except the Department of Defence.
 Annex III 39

National Land The National Land Information Service is an ongoing project with the aim of
Information providing easier access to all land and property data in Britain. It is a direct result of
Service the Citizen's Charter of 1992. Based upon BS7666, the NLIS is a hub-based
network with access to data held by HMLR, The Valuation Office, OS and local
government. The NLIS is a precursor to the development of a National Geospatial
Database.
National Spatial Established as a result of an Executive Order from the United States government,
Data this is an attempt to promote the sharing of Geographical Information and increase
Infrastructure its use in policy formation. The aim of this initiative is to enhance the United States
economy and maintain a competitive edge.
Network 1. An interconnected set of arcs representing possible paths for the movement of
resources from one location to another.
2. A digital map representing linear features containing arcs or a route-system.
3. When referring to computer hardware systems, a local area network (LAN) or a
wide area network (WAN).
NIST See National Institute of Standards and Technology
NLIS See National Land Information Service
Node The beginning and ending locations of an arc. A node is topologically linked to all
arcs that meet at the node.
Normalisation A data modelling method first devised as a database design tool for relational
databases, but has since been found a useful tool for conceptual modelling.
Normalisation is a bottom-up approach to data modelling.
NSDI See National Spatial Data Infrastructure
NTF National Transfer Format.
British Standard BS7567, used for the transfer of geographical data, administered
by AGI.
Object A set of points, lines or polygons in a spatial database that represent a real-world
entity. The terms feature and object are often used synonymously.
Object The Object Management Group, founded in 1989, is a computing industry
Management collaboration to promote object-oriented interoperability among heterogeneous
Group computing environments. They continue to develop specifications which address
the many aspects of this problem, the most popular of which is the Common Object
Request Broker Architecture (CORBA).
Members include all the main hardware and software vendors, as well as leading
users of object technology. Further details can be found at http://www.omg.org.
OGC See Open GIS Consortium
OLE Object Linking and Embedding.
Microsoft's specification for object technology, which it is using throughout its
operating systems, development tools and applications. Based upon the underlying
Component Object Model (COM), OLE is the foundation for component software to
interact and co-operate. OLE also makes it easy to create compound documents
consisting of multiple sources of information from different applications, for
example, embedding a MS Excel spreadsheet into a MS Word document.
OMG See Object Management Group
Open GIS The Open GIS Consortium is a voluntary, non-governmental, non-profit
Consortium organisation dedicated to the development of an open systems approach to
geoprocessing.
Open System An information processing system that complies with the requirements of open
systems interconnection (OSI) standards in communication with other such
systems.
Operating The low-level software which schedules tasks, allocates storage, handles the
System interface to peripheral hardware and presents a default interface to the user when
no application program is running.
Oracle A relational database management system.
40

OSI Open systems interconnection.

This defines the accepted international standard by which open systems should
communicate with each other. It takes the form of a seven-layer model of network
architecture, with each layer performing a different function.
Picture Element See Pixel
Pixel Square shaped cell comprising the smallest unit that makes up a computer image.
Pixel size determines resolution of an image and the quality of graphical output.
Pixels can be assigned a number of attribute values.
Plotter Peripheral device used in the making of hard copy maps or graphical output.
Polygon A feature used to represent areas. A polygon is defined by the lines that make up
its boundary and a point inside its boundary for identification. Polygons have
attributes that describe the geographical feature they represent.
Precision The exactness with which a value is expressed, whether the value be right or
wrong.
Projection See map projection.
Protocol Protocols are a fixed set of rules used to specify the format of an exchange of data.
Quadtree The expression of a two dimensional object, such as a digital image, as a tree
structure of quadrants which are formed by recursively subdividing each non-
homogeneous quadrant until all quadrants are homogeneous with respect to a
selected property, or until a predetermined cut-off 'depth' is reached.
Query A statement expressing a set of conditions that forms the basis for the retrieval of
information from a database. Queries are often written in a standardised language
such as SQL.
Query Language Method of communicating data manipulation and definition commands to a
database. Command driven interface rather than menu-based. Commands are
typed by the user and then analysed by the query compiler which subsequently
passes them to the processor. The de facto standard in use is the Standard Query
Language (SQL). Query languages allow data to be inserted, modified and
retrieved. Query languages are more highly structured than earlier command-
based systems, approaching English in syntax.
Raster A method for the storage, processing and display of spatial data. Each given area
is divided into rows and columns, which form a regular grid structure. Each cell
must be rectangular in shape, although not necessarily square. Each cell within
this matrix contains an attribute value as well as location co-ordinates. The spatial
location of each cell is implicitly contained within the ordering of the matrix, unlike a
vector structure which stores topology explicitly. Areas containing the same
attribute value are recognised as such, however, raster structures cannot identify
the boundaries of such areas as polygons. Also raster structures may lead to
increased storage in certain situations, since they store each cell in the matrix
regardless of whether it is a feature or simply 'empty' space.
RDBMS See Relational Database Management System
Record 1. In an attribute table, a single 'row' of thematic descriptors. In SQL terms, a
record is analogous to a tuple
2. A logical unit of data in a file.
Reference Provides the complete scientific and engineering contextual framework for a
Model technology area. The underlying elements, rules and behaviours.
Relational A database management system with the ability to access data organized in
Database tabular files that can be related to each other by a common field. An RDBMS has
Management the capability to recombine the data items from different files, providing powerful
System tools for data usage.
Remote Sensing The technique of obtaining data about the environment and the surface of the earth
from a distance, for example, from aircraft or satellite.
Resolution A measure of the ability to detect quantities. High resolution implies a high degree
of discrimination but has no implication as to accuracy. Resolution is a term that is
used often within remote sensing.
 Annex III 41

Scale The ratio of the distance measured on a map to that measured on the ground
between the same two points.
SDM See Systems Development Methodology
Server A computer which provides some service for other computers connected to it via a
network. The most common example is a file server which has a local disk and
services requests from remote clients to read and write files on that disk.
Spatial Analysis Analytical techniques associated with the study of locations of geographical
phenomena together with their spatial dimensions and their associated attributes.
Spatial analysis is useful for evaluating suitability, for estimating and predicting,
and for interpreting and understanding the location and distribution of geographical
features and phenomena.
Spatial Information that includes a reference to a two or three-dimensional position in
Information space as one of its attributes.
Spatial Analytical procedures applied with a GIS. There are three categories of spatial
Modelling modelling functions that can be applied to geographical features within a GIS: 1,
geometric models, such as calculating the Euclidean distance
between features, generating buffers, calculating areas and perimeters; 2,
coincidence models, such as overlays; and 3, adjacency models (pathfinding,
redistricting, and allocation).
Spatio-temporal Data that is concerned with both space and time.
data
Spatio-temporal Databases designed for the storage and management of spatio-temporal data.
Database Most GIS only have limited capabilities for storing and manipulating temporal data,
although specifically designed to cope with spatial data.
Spiral Model A model of the software development process in which the constituent activities,
typically requirements analysis, preliminary and detailed design. Coding,
integration, and testing, are performed iteratively until the software is complete.
See also: Waterfall Model.
SQL Structured Query Language. A syntax for defining and manipulating data from a
relational database. Developed by IBM in the 1970s, it has become an industry
standard for query languages in most relational database management systems
Systems An integrated set of techniques and methods for effective and efficient planning,
development analysis, design, construction, implementation and support of computer systems.
Methodology
TCP/IP Transmission Control Protocol/Internet Protocol. A communication protocol layered
above the Internet Protocol. These are low-level communication protocols, which
allow computers to send and receive data. It is the communication standard that
underlies the Internet.
Temporal A database containing information indexed by time. Time can either be
Database represented as discrete steps, or less commonly, as a continuous variable.
TIGER Topologically Integrated Geocoding and Referencing.
A data format developed by the US Bureau of Census for the 1990 US census.
TIN Triangulated Irregular Network.
A form of the tesseral model based on triangles. The vertices of the triangles form
irregularly spaced nodes. Unlike the grid, the TIN allows dense information in
complex areas, and sparse information in simpler or more homogeneous areas.
The TIN dataset includes topological relationships between points and their
neighbouring triangles. Each sample point has an X,Y co-ordinate and a surface,
or Z-Value. These points are connected by edges to form a set of non-overlapping
triangles used to represent the surface. Tins are also called irregular triangular
mesh or irregular triangular surface model.
Topographic 1. A map containing contours indicating lines of equal surface elevation (relief),
Map often referred to as topo maps.
2. Often used to refer to a map sheet published by the U.S. Geological Survey in
the 7.5-minute quadrangle series or the 15-minute quadrangle series.
42

Topology The spatial relationships between connecting or adjacent coverage features (e.g.,
arcs, nodes, polygons, and points). For example, the topology of an arc includes its
from- and to-nodes, and its left and right polygons. Topological relationships are
built from simple elements into complex elements: points (simplest elements), arcs
(sets of connected points), areas (sets of connected arcs), and routes (sets of
sections, which are arcs or portions of arcs). Redundant data (coordinates) are
eliminated because an arc may represent a linear feature, part of the boundary of
an area feature, or both. Topology is useful in GIS because many spatial modelling
operations don't require coordinates, only topological information. For example, to
find an optimal path between two points requires a list of the arcs that connect to
each other and the cost to traverse each arc in each direction. Coordinates are
only needed for drawing the path after it is calculated.
Triangulated See TIN.
Irregular
Network
Triangulation A process of subdividing a 2D space into bounding regions that are triangles.
Tuple A row in a relational table; synonymous with record, observation.
Turn-key A term that describes a system (hardware and software) which can be used for a
System specific application without requiring further programming or software installation.
The user can just 'turn the key' (switch it on) and use it.
User Interface A method by which a user controls operation of a computer system. Typical types
of user interface include command line, conversational mode and graphical user
interfaces (GUI).
User A study of the needs of a user of a system conducted prior to system development.
Requirement
Analysis
UTM Universal Transverse Mercator.
A grid system based upon the Transverse Mercator projection. The UTM grid
extends North-South from 80 o N to 80 o S latitude and, starting at the 180 o
Meridian, is divided eastwards into 60, 6 o zones with a half degree overlap with
zone one beginning at 180o longitude. The UTM grid is used for topographic maps
and georeferencing satellite images.
Vector One method of data type, used to store spatial data. Vector data is comprised of
lines or arcs, defined by beginning and end points, which meet at nodes. The
locations of these nodes and the topological structure are usually stored explicitly.
Features are defined by their boundaries only and curved lines are represented as
a series of connecting arcs. Vector storage involves the storage of explicit
topology, which raises overheads, however it only stores those points that define a
feature and all space outside these features is 'non-existent'.
Vertex One of a set of ordered x,y coordinates that constitutes a line.
Visualisation A term that is applied to the field of computer graphics that attempts to address
both analytical and communication issues of visual representation. Visualisation in
GIS often refers to the visual representation of geographical data for purposes of
spatial analysis.
WAN See Wide Area Network
Waterfall Model A model of the software development process in which the constituent activities,
typically a concept phase, requirements phase, design phase, implementation
phase. test phase, installation and checkout phase, and operation and
maintenance, are performed in that order, possibly with overlap but with little or no
iteration. Contrast with rapid prototyping; spiral model.
Wide Area Computer data communications technology that connects computers at remote
Network sites. WANs are composed of special data communications hardware and software
and usually operate across public or dedicated telephone networks.
 Annex III 43

Workstation A general purpose computer designed to be used by one person at a time and
which offers higher performance than normally found in a personal computer,
especially with respect to graphics, processing power and the ability to carry out
several tasks at the same time. This performance difference however is
decreasing, and in time the distinction between a desktop and a workstation will be
meaningless in terms of performance.
Z-Value The value of a surface at a particular X,Y location, for example, elevation. The Z-
value usually refers to 3D features, but in GIS it can also refer to what is known as
2.5D features.