Pentti Junni , Ralf Lindgren
The Hydrographic Information System - Co-operation, Concept
and Future
Abstract
In the world of maritime transport new technology is
rapidly being taken into use for navigational purposes. The
main important components in this development are GIS and
GPS. Producers of nautical charts are facing the task to
deliver their information in a suitable digital form and the
demand is increasing. A global standard to define this
product (Electronic Nautical Chart - ENC ), has been
established by the International Hydrographic Organization
(IHO).
The Finnish and Swedish Maritime Administrations are
engaged in a co-operation since 1994 with the aim to define
the next generations information system for management of all
the hydrographic and nautical information needed in our
products.
The paper will present the major steps of our co-operation
in design and specification of the Hydrographic Information
System (HIS). The system will be described from a conceptual
point of view. Future phases of the system implementation
will be discussed.
Background
The ability to meet the increasing demand for nautical
charts in a digital form is a challenge to hydrographic
offices around the world. There are several aspects of this
new digital product that will enforce major changes to the
operations and systems within our offices.
- The digital product recquires a well structured
information (topology , attributage etc.) which we
can not provide easily with existing systems.
- The use of GPS and DGPS for navigation leads to what
you could call a paradigm shift in the use of chart
data, from relative navigation to absolute
navigation. As a result the positional quality of the
delivered information has to be improved.
In discussions between the hydrographic
offices of Finland and Sweden we found that the situation is
very similar in both countries. The present systems are
primarily focused towards output of printed charts. The
control of new information is not satisfactory. Updates are
performed directly in a lot of products with potential risk
of omissions or errors.
Reasons and Motives for Co-operation
We found that there were several good reasons to
investigate further the possibility of a more close
co-operation with the first aim to define and model the flow
of information within our offices. If we could reach a common
view here we would have a ground for continuing with the
specification of improvements to our existing information
systems.
- A large resemblance in existing operations and
procedures.
- Similar geographic conditions. (The Baltic Sea with
archipelagos and shallow waters.)
- Essentially similar organisations and conditions.
- Present systems capable of dataprocessing primarily
for printed output.
- The advantage of combining resources and knowledge.
- Potentially a more interesting customer to vendors.
Steps in the Design Process
Flow of information, conceptual model
A number of work items were activated within our
co-operation in order to establish the common ground for
systems specification. We investigated data models, updating
procedures, pre-processing of incoming new information etc.
The fundamental result of this preparatory work early in the
project was what we called the Conceptual Model. This model
describes the different processes that we saw needed to
handle the information in an efficient way.
The conceptual model identifies three clearly separated
steps of the data processing within our hydrographic
departments.
- Source Data Management includes all the necessary
preprocessing of incoming data. A number of dedicated
applications for treatment of hydrographic surveys
etc. are already in place here. The unit of
processing is the data set.
- Product Management handles output of information to
product systems for printed charts, publications as
well as digital products. The unit of processing is
the product.
- Information Management is a central part of the
information flow where all the necessary information
is handled in a product independent way. The unit of
processing is the feature. The data model must be
sophisticated enough to handle our abstraction of
"the real world". This includes a complete
set of attributes as well as relations with other
features in the database.
We also identified the need for an overall systems layer
with process- and quality control. We need functionality to
control and monitor the information flow and to record status
at important check points.
Compared with the present situation the information
management as well as process control are the parts we have
to establish or improve. These parts are more or less missing
today.
Prototypes
Based on our conceptual model a
specification for a prototype test (or benchmark) was
written. A number of different GIS vendors participated and
prepared a prototype based on their GIS. The aim of the
prototypes from the offices point of view was to investigate
how our ideas could be implemented in GIS’s that
represent state-of-the-art in the GIS business. The vendors
should achieve this in their respective system without adding
major functionality by programming.
Major functionality in the prototype was:
- Registration of new incoming data
sets.
- Validation. Verify new data
internally and compare with existing data.
- Perform topological and
consistency checks.
- Update the database and create
history objects.
- Simulate process control by
writing into log files between steps.
The prototypes were evaluated thoroughly
and we got a good understanding of the capability of modern
GIS's. The trend towards database driven solutions was
obvious. We learned a lot and most importantly we learned
that a system that fulfilled our requirements completely did
not exist. We realised that a lot of development is needed to
build our Hydrographic Information System (HIS).
Final specification
Based on the experience gained from the
prototype evaluation the final specification for phase 1 of
the HIS was produced and proposals were requested from GIS
vendors. Phase 1 of the systems include the Information
Management part and Process Control.
This process of specification and
evaluation required quite some time, about 8 months. In the
first step of evaluation we reduced the list of proposals
into a short-list with three systems. More clarifications
were requested and discussions with these system suppliers
took place.
A contract for development of the HIS for
Finland and Sweden was signed in May 1996 and delivery is now
planned for the autumn 1997. The database solution will be
implemented in SDE and ArcView as well as ArcInfo will be
used to manage the information.
Detailed design
After the selection of supplier for the
development work a lot of design work has been performed. At
the time of writing this paper there is still work to be done
on this level. Our requirements have to be broken down into
manageable pieces that will fit the choosen software
environment. This work requires a lot of interaction between
the supplier and the customer. The supplier has choosen a
method of design by prototypes. A series of prototypes are
delivered to test design issues and show the evolution of the
system. On the customer side this activates both endusers as
well as developers and designers.
Major and Vital Functionality
The requirements for functionality in HIS in many ways
goes beyond and expands the possibilities of the basic GIS
components. Dedicated functionality will be implemented and
the most important expansions are described below.
Process and input unit control
When new data (completely new features or changes to
existing features ) enters HIS this is always performed in
what is called a Job. The Job links a selected process with a
set of new data and the process contains several steps
normally. The results, statistics and any comments of each
process step is recorded in a process log.
Furthermore the source and general quality information of any
new data is always described in a meta object or Source
Document which is stored in the database. Each feature is
linked to a valid Source Document.
The important issue is to maintain a defined audit trail
with regard to processing and source information.
Validation and integrity checks
Validation is a process step where new information is
carefully controlled and evaluated both internally within the
data set and against already existing information. The
process step may be defined so that validation requires a
"sign off " of two operators (or operator and
supervisor). A comprehensive toolbox of integrity checks will
be implemented to assist in this process. This toolbox will
provide tests for internal and external consistency as well
as geometrical and topological conditions.
Multiple scales management
Within the database there is a need to maintain the
information prepared for different scale layers in addition
to the base layer where the best available data is managed.
The main reason for the existence of these scale layers in
the HIS database is the fact that we can not rely on
automated methods (generalisation etc.) for producing
products in large scales. The transfer of new information
from base layer to a range of scale layers is controlled in a
similar way as input to base layer. This will be based on a
transfer queue where references to new ,changed and deleted
features automatically appear after commit to base layer.
History management
The HIS will have functionality to view the situation in
the database at a given previous date and time. This is may
be required to check the contents of an issued product. There
will also be functionality to backtrace into history for an
individual feature.
Complex and composite features (object management)
The data model includes relations to other features which
enables what define as complex feature. A complex feature
consists of a number of complete features (each with its own
geometry and attributes) somehow related to each other. When
editing or changing any part of a complex feature the
operator has to be informed that the feature is a part of a
complex. A good example is a fairway area consisting of
navigational aids, fairway area, navigational lines etc.
The composite feature is a feature which is built up by a
set of components. The components are sometimes not complete
features of their own ( the may lack geometry). You normally
navigate to the components through its parent object. An
example of a composite could be a lighthouse with radar
reflector and lights.
Editing
The editing functionality of ArcView will be expanded and
customised for the specific purpose of HIS. For some tasks
the functionality of ArcInfo will be used.
ENC output
Export of information for electronic nautical charts
according to the standard of the International Hydrographic
Organization ( IHO S57e3) will be implemented in phase I of
HIS.
Future Phases of HIS
Within the co-operation between Sweden and Finland we have
outlined the next two phases of HIS. In phase II we will
establish the product management part of our conceptual
model. It is essential to get the information from HIS easily
transferred to the product systems for printed charts and
publications. There is most probably a need also to define
digital products other than ENC. The work in phase II may
involve modification of existing product systems as well as
implementing new ones.
Phase III is planned to result in a complete quality
management system for the total information flow of our
hydrographic departments including Source Data Management and
Product Management.
References
Junni, Pentti: A Next Generation Hydrographic Information
System. Presented paper at the International Hydrographic
Conference, Monaco, 1997.
Lindgren, Ralf: ECDIS - an onboard navigational system for
marine traffic and how to provide data for it. Presented
paper at the AM/FM-GIS Nordic Region Conference, Lahtis,
Finland, 1996.
Authors
Pentti Junni, M.Sc.
Development Manager, Hydrography and Waterways Department
Finnish Maritime Administration
P.O.Box 171, FIN-00181 Helsinki, Finland
Telephone: +358 204484 485
E-mail: pentti.junni@mkl.fi
Ralf Lindgren, M.Sc.
Development Manager, Hydrographic Service
Swedish Maritime Administration
S-60178 Norrk�ping, Sweden
Telephone: +46 11 191371
E-mail : ralf.lindgren@shipadm.se