The Hydrographic Information System for the Swedish and Finnish Maritime Administrations is a single system for capturing, managing and controlling the quality of hydrographic data. Information management, data edit, quality control and Electronic Nautical Chart production are some core capabilities of the HIS.

The quality of data is a hydrographic organizations main concern. Starting with the capture of data or importing from existing systems, HIS manages the flow of data, capturing quality information that is essential to verifying the acceptability of a dataset. HIS meets the high requirements put on data structure (topology, attributes etc.) by standards for nautical chart production. The increasing use of GPS for navigation leads to high demands for positional accuracy in charts. HIS has the tools to move and position objects with high precision in un-projected as well as projected datasets.

The system design of the HIS has been a joint effort between the Swedish and the Finnish Maritime Administrations, and Meridian Systems OY and T-Kartor Sweden AB. The system has been developed jointly by Meridian Systems OY and T-Kartor Sweden AB, with support on specific technical issues from Esri Redlands.

The introduction of a new hydrographic data processing system is an evolutionary process that requires both organizational and methodological changes, changes to existing systems, and the addition of totally new systems. The implementation strategy of HIS is therefore gradual and three main phases are defined.

Phase one is the start of the HIS evolution. The main parts of phase one are Information Management and Process Control (Figure 1). HIS phase 1 has interfaces to existing source data and production management systems. Selected parts of Source Data Management and Product Management are included into the system.

With HIS phase one data integrity can be maintained. All features are stored and maintained in one place. All features have a unique feature ID. Data structures and processing rules of the features are the same. Dependencies and links between the features are controlled and both internal quality and the quality between the features is provided. In addition, the number of interfaces between existing systems are minimized.

HIS facilitates information management for the user because the user interface and the way of working is uniform. Software and hardware tools are standardized which makes the maintenance of the system more efficient.

Figure 1. Information Management with HIS Phase 1.

The implementation of Phase 2 will complete the full functionality of product management by implementing a cartographic production system which retrieves data from the HIS databases. In Phase 3 (figure 2) the system will be fully implemented and in full scale operation. All source data management systems are integrated to the system. Pre-processing of various types of measurements are handled in the HIS System and main other systems like navaid databases are moved to the same architecture.

Figure 2. HIS Phase 3.

HIS has a client-server architecture, where NT-clients are connected to a UNIX server (figure 3). The client-server setup allows sharing of datasets, workflow control, supervisor distribution of tasks to technicians, centralized data archiving and optimized client data processing. SDE and Oracle on the server store the master database from which clients extract hydrographic data for updates or ENC production, or to which the clients place newly input and validated datasets. Staffware, a commercial software for workflow management, handles system workflow control. ArcView on the clients provides tools for hydrographic data editing, viewing, querying, importing and output.

HIS for the Finnish and Swedish Maritime administrations is designed for up to 80 simultaneous client users (50 viewers and 30 operators).

Figure 3. The Client Server Architecture of HIS

The system is primarily based on hardware from Digital and software from Esri.

The hydrographic data is stored in SDE for Oracle. SDE allows for efficient management, search and retrieval of geographic data inside a relational database management system (RDBMS). The RDBMS provides the data integrity and security required by the Maritime Administrations.

Table 1. HIS hardware and software

HIS contains 13 sub-systems (figure 4). Data can be input via direct connections to other hydrographic systems, imported through custom designed importers, digitized or manually entered. The HIS registers the new data and tags it so that data history is instantly recallable. HIS data management includes meta data management, multiple scales management and history management. The goal is to keep a high level of data traceability through all aspects of data processing.

Figure 4. Sub-systems of HIS

The client application is designed for flexibility and modularity, to allow for easy customization to the needs of other similar organizations. The application has been built as a set of more than 50 extensions to standard ArcView.

The HIS client is built on a flexible framework for multiple language management. Support for three languages has been implemented: English, Swedish, and Finnish. This can easily be extended to include other languages.

The graphical user interface of the HIS client is based mainly on ArcViews users interface, which gives Windows look-and-feel to menus, buttons, tools and dialogs, with context sensitive help functionality. The GUI adapts to the current tasks of the operator and only those functions which are applicable at a certain point of processing are actually available.

The core of the HIS is the database, which consists of the main database and several scale databases (figure 5). Multiple scale databases are required for the system to maintain highly accurate base data, the geographic database, as well as generalized data suitable for presentation on specific scale ranges, cartographic databases. The number of scale databases is not fixed, but the system supports any reasonable number of scale databases (typically 3-10).

The main database (the geographic database) contains data at its most accurate level. Normally new data of good quality are first entered into the main database, and thereafter transferred to one or many scale databases. The scale databases (the cartographic databases) contain data generalized for cartographic output at a certain scale range.

The object types, their attributes, methods, logical and topological relationships, as defined by the Swedish/Finnish Offices data model, are implemented into these databases. On the client side the database structure is described in the HIS Data Dictionary, to allow for application code which is largely data independent.

Meta data is stored in a meta database, and supporting information, for example logs, is stored to the support database.

The HIS database is implemented as an Oracle and SDE instance, while the internal databases (main, scale(n), support, meta) are implemented as Oracle user schemas. The implementation of the HIS database and the HIS data dictionary has been facilitated by the use of the modeling software GeoCase by Geographic Business Systems Pty Ltd

Figure 5. The HIS database.

The following feature object types are supported:

• simple objects - spatial without attribute level relations to other objects
• complex objects - spatial or non-spatial with attribute level relations (links) to other objects
• composite objects - objects with parent-child relations ships where the child objects cannot exist without their parent objects.
  

The feature object classes fall into four categories (table 2).

Table 2. Categories of feature object classes

HIS supports historical viewing and querying of data, through the implementation of history tables. History tables are duplicates of the tables in the Main Database and the Scale databases, with additional fields for start date and end date of the validity of the feature. Whenever an object in the main or scale databases is edited, the previous versions of the object is copied to its history table. This allows the application to reconstruct the situation of the database at a certain point in time by consulting both the main and historical tables. It allows the user to track the changes made to a specified feature.

Due to the length of time that may be required to perform complex edits of spatial features in the SDE database, long transactions are supported in HIS. This is to prevent users from copying out features for edit that have already been copied out for editing by another user, but have not yet been returned to the database.

Long transactions are handled on an individual feature basis, locking the features which are being edited, as well as all related features. Avoiding conflicts resulting from two operators working in the same area but with different data is a task for the system supervisor. This is facilitated through the concepts of rough polygons, which outline the geographical extent of any one ongoing job.

A long transaction starts with a check-out of data from the data base and ends with a commit of data to the database. Commit itself is a short transactions. It is also an atomic operation, which means that either all data or no data goes into the database, thus avoiding inconsistencies in the data.

HIS offers versatile functionality to view and query features, feature meta data and history or processing history of the features. The system supports multiple view management with zoom-in views for full display of details, as well as full cartographic display of data with point, line and area symbols. The system is delivered with a set of basic symbol libraries, with the possibility to easily build additional libraries. The point symbols are in True Type Fonts.

The HIS database is stored in geographical coordinates. All import/export functionality includes datum and projection conversions as needed. The datum and projection properties of incoming data is stored in the meta database, and can be retrieved at will. Data in the view can be projected on-the-fly to any projection known by the system. Projection parameters for any projection can be entered by the system administrator.

Object classes are edited one-by-one. The appropriate line, point or polygon tools are made available depending on data type (figure 7). For some complex object classes, additional special purpose geometry tools have implemented. Most importantly there are linking tools which allow the operator to build up critical relations between objects (figure 8), for example between navigation lines and their leading marks (navaids).

Figure 7. Dialogs for geometrical editing and attribute transfer.

HIS has extensive support for input of features by coordinates, since the exact position is crucial for many hydrographic measurements and features. Trough the concept of "non-draggable" objects graphical drag-and-drop is prohibited for extra sensitive object classes . HIS has full support for datum and projection conversion during coordinate input. Various methods for coordinate input are supported, e.g. absolute coordinates, relative coordinates to existing objects, and relative coordinates by distance and bearing to/from existing objects.

For skin of the earth object classes, holes are not allowed and objects cannot cross or overlap each other. The edit tools can work under skin-of-the-earth constraints, and there are special purpose tools to fill gaps and check that overlap does not occur.

Quality Checks have been developed to verify feature internal quality and the quality between the features. The checks can be run against the current workspace or against the database to ensure that attributes, geometry and topology are correct inside a feature and between the features. The quality checks are partly intended as pre-checks for the database checks in commit, but they also handle complex geometric and topology constrains which cannot be implemented on an Oracle level.

Figure 8 Object Management dialog for viewing and editing object attributes and relations.

The HIS workflow management, or process control, is the computer assisted management of hydrographic data processing through the execution of ArcView software. The order of execution is controlled by a computerized representation of the business processes. This computerized representation is implemented in Staffware which is a commercial workflow system specially customized to work with ArcView.

All tasks that involves modifications to the main and scale databases, as well as all ENC production is under workflow control. Jobtypes, pre-defined sequences of steps (processes), have been defined for these tasks. Jobs are instances of jobtypes, and ongoing jobs can be monitored and managed through the Staffware work queue. Work queue management is provided for individual users, user groups and supervisors

On the client side, the workflow steps are implemented as process extensions which are loaded and unloaded to provide the functionality the operator needs inside each process. The client application also manages the job workspace, where data is securely kept during the duration of the job.

The main task during the first months of system operation is to load data from existing databases. Entering data into the HIS in a controlled manner is achieved by a workflow controlled job type, where data goes through the following steps of processing: registration, import, edit, quality control, validation, and commit. All user functionality is part of the ArcView client application.

The workflow for updating the HIS database is identical to that of building the database. Meta data is registered, which describe the cause of the modification. Relevant data is checked out from the database during the input process, edited and quality checked, validated and committed back to the database. Previous versions of the data go to the history tables. The multiscale transfer queue is updated, so that the modifications are forwarded to the scale databases.

MultiScale Management is concerned with managing data at multiple scale levels in a controlled manner. The control mechanism for multiscale management is the Transfer Queue. It is a mechanism by which data which is entered into the main database automatically gets queued for transfer to the scale databases. The records in the transfer queue can be sorted and prioritized based on a number of different criteria, thus enabling a flexible workflow. All multiscale transfer is workflow controlled.

The data transfer is done manually, with tools to aid the operator in generalizing features when they are transferred from the main database to the scale databases. There are also tools to transfer modifications or deletion of features from the main database to the scale databases. The links to meta data are kept after the features have been transferred.

The ENC production line provides functionality to export data for Electronic Nautical Charts in IHO S57v3 data format. The production line is intended for operational production of Electronic Nautical Charts in a timely and accurate manner.

Key features of the ENC Production Line are:

• Creation and maintenance of a database of ENC cell definitions (spatial extent and attributes)
• Translation from internal object model to S57 version 3 object model
• Datum and projection conversions (if needed)
• EN(new cell) and ER (revised cell) production
• Automated extraction of modified data from the HIS database for ER cells
• ENC meta data management
• Custom defined contents of the output ENC cells
  

The HIS is a full-fledged system for hydrographic information management in organizations such as National Hydrographic Offices. It works in a multi-user mode based on an NT-UNIX client-server architecture. All data is stored inside a relational database management system. Workflow controlled input, edit, transfer and export of data is supported. During editing data is securely managed in workspaces both on the server and on the client side. The system has database support for cartographic product definition, and is expandable to a full cartographic production system. Electronic Nautical Chart production is one of the key features of the system.

The entire HIS development team has contributed to the contents of this document, specifically Matti Palosuo and Petteri Soikkonen of Meridian Systems OY and Kevin Howald, formerly of T-Kartor Sweden AB. The system has been built based on requirements and design by the Swedish and Finnish Maritime Administrations.

Katarina Johnsson,
Team leader, T-Kartor Sweden AB
kj@t-kartor.se

Veli-Matti Kiviranta,
Project manager, Meridian Systems OY, Finland
veli-matti.kiviranta@meridian.fi