A Universal Hydrographic Database

The idea of a Universal Hydrographic Database is well known within the hydrographic community. Years of discussion and technological development have made UHD an attractive goal for those striving to improve the quality of navigation products. As seekers of this ‘Holy Grail’, the authors dare to suggest requirements for such a database and even analyse approaches to implementation.

The main task for a HO is, as stated in regulation 9 of SOLAS Chapter V, to provide for safe navigation within its zone of responsibility. All other tasks are just incremental steps toward fulfilling this main objective. They include survey, production and maintenance of navigational charts (both paper and electronic), production and maintenance of navigational publications and exchange of relevant information with other government institutions, at home or abroad.

Single Source
A truly Universal Hydrographic Database should thus be a tool for all HO activities and any product they produce (e.g. a navigational chart). Such products should simply be a ‘subset’ of information stored in the database. In other words, such a database should be the single source for all HO products. And the UHD must guarantee that a product derived from it is fully compliant with various national and international laws, standards and requirements, because navigational products, among other properties, carry legal responsibilities. In theory such a database should be capable of storing and maintaining:

• raw survey materials and processed bathymetry
  
• navigational aids information
  
• other hydrographic entities used in vector electronic charts
  
• cartographic and typographic entities used in paper charts and books
  
• NtM source and metadata
  
• raster data.

The database must also guarantee data consistency and security, and allow a product to be retrieved with minimal effort and time; it must guarantee that a product is correct, complete and current; it should provide interfaces for external information systems. To make it all work, all of the above must be coupled with traceability and workflow management. And of course the database must be reliable to the highest degree to guarantee fulfilment of the main objective: safe navigation. From the user’s point of view it is not really important how data is organised technically within the UHD. What is important is the ability of the database as a production system to produce the safest possible product, with minimum effort and complexity. These requirements lead to the conclusion that a Universal Hydrographic Database is much more than just a data storage system or, regardless of computational power it delivers, a database engine. It is a complex of task-specific tools, methods for using these tools and a management system that guarantee the generation of safe navigational products.

Nature of Data
To be a single source for all products, including ENC, the database must contain a single, complete model of hydrographic reality, preferably in terms of S-57. The nature of hydrographic data is such that all entities are naturally divided into two groups: those that possess identical spatial characteristics in all products and those that change their shape depending on the scale of the product (this is true for all possible products, ENC, AML, paper chart, etc.) The first group comprises features such as aids to navigation, traffic schemes, some special areas and state boundaries. The second group comprises seabed, land, coastline and bathymetry in general. In entities of the first group, scale-independent features, everything is really simple; such features are either in a product with no change or are not in at all. The rest, scale-dependent features, must be generalised before they can be used in a product (it goes without saying that the UHD stores such features at the best achievable accuracy, meaning at the largest scale).

Implementation
Today, two main approaches are visualised to UHD implementation. The first is the ‘All-in-one’ approach and the second the ‘Tool-for-the-purpose’ approach.

All-in-one UHD
The ‘All-in-one’ approach is based on the idea that a UHD should be built as one physical database, provided that a powerful enough database engine can be employed. Supporters of this approach say: "Let us utilise the newest data exchange standards, let us take the newest database engine available, let us utilise the powerful data tracking methods of this engine and this will fulfil all requirements for HO production. Each hydrographic feature will be stored in the database just once and it will easily go into various products made out of the same source." However, although the ‘all-in-one’ approach looks extremely attractive, combining as it does the natural desire for a simple solution with a common belief that powerful technology is able to solve all issues, difficulties arise from the very beginning: with scale-dependent features.
In hydrographic practice, generalising is a semi-automatic procedure where ‘good cartographic judgement’ is unavoidable. To accommodate this fact, a UHD must be structured into scale bands and one feature description will have multiple geometry links. From a hydrographic perspective this generates multiple models of reality, because some features may disappear in some scale bands. Technically there cannot be too many scale bands; consequently, the generalised geometry will correspond to several ‘standard’ scales only. Thus the idea of a single source for all products changes to a ‘single-source-for-all-products-in-a-scale-band’ idea – still not bad, but less ‘Holy Grail-like’ than before.
Let us analyse an ENC cell product (provided the database is S-57-based, this is the simplest case scenario). Among other requirements, ENC Product Specification contains some not directly connected with hydrography: chain-node topology, clipping areas and lines at cell boundaries and unique feature IDs. When a cell is generated, due to clipping, source database features must be modified and one feature may turn into several features with different shapes, each with a unique ID. A product may even require manual editing: for instance, when the scale of a cell gets in between two database scale bands and more generalising becomes necessary. For products like paper charts or NtM booklets, editing after extraction is unavoidable. Thus there are several instances of the same real-world feature: each scale level and each product contains its own instance and they may not be fully identical! As a result, to maintain a product, this must be stored in the UHD as a separate entity.
So the all-in-one database idea now looks like this:

• database contains a set of models of hydrographic reality made at fixed scales
  
• products derived from these scale bands must also be stored in the database
  
• information in the database naturally multiplies; it is impossible to have just one instance of a scale-dependant feature, and hence changes must be executed several times
  
• product extraction may require manual operation.

One must also keep in mind that to extract a single product a HO has to set up, deploy and populate the database; there is no step-by-step implementation. Introduction of all-in-one UHD really implies revolution at a HO, because it requires a total restructuring of the organisation.

Tool-for-the-purpose UHD
The tool-for-the-purpose approach is based on the following premise: a continuous coverage of S-57 cells works as a hydrographic database. This is so because S-57 cells are organised in scale levels, each level being seamless (no data overlap). Also, each cell is complete and suitable for safe navigation, and, from a software point of view, it is a matter of a query engine where to search for data: in database or in a set of cells, the user will get the same result. In accepting this idea, two immediate benefits become evident as compared to the ‘all-in-one’ approach: firstly, no complicated extraction is required; cells are ready products that can be distributed and maintained directly. And secondly, cells can be used as a source for highly automated paper-chart production.
As we have seen, the idea of a single source does not really work, even for all-in-one UHD. Therefore we have to accept this fact and minimise the complexity of the solution by breaking the whole database down into specialised tools responsible for a certain HO product. Each tool can be used independently but when combined into a common environment and working together tools will form a Hydrographic Database meeting the requirements for a UHD. These tools being:

• feature database for scale-independent features (Feature Object Database), the source for scale-independent ENC features and for Light List book
  
• file-based database (Archive) that stores S-57 cells, survey data, raster and paper charts
  
• database that keeps and processes source information for changes in hydrographic reality (Source Message Database); these changes initiate cell updates, paper chart corrections and NtM production
  
• software interfaces between tools and interfaces to the outer world: GML, Web-based publishing and so on
  
• workflow management system that organises and monitors the production process according to existing HO guidelines.

The resulting UHD will possess the same functionality as an ‘all-in-one’ database with the following advantages:

• 
  
• modular structure, an HO is able to use just the parts it really needs and there is no need to install and deploy all parts at once
  
• more reliable operation because information is maintained in the same form it will be used onboard a ship
  
• product quality is achieved with less effort because there is no need for complicated product-extraction routines
  
• less data duplication because hydrographic database storage and product storage is the same
  
• easier expansion, as there is no need to modify the main database structure if a new product is not S-57 compatible.

Conclusion
The main function of a Universal Hydrographic Database is its capability to produce safe navigational products. A technical solution selected for UHD implementation must allow achieving this goal using the safest and most reliable methods. In this respect, the ‘tool-for-the-purpose’ implementation approach is preferred over the traditional ‘all-in-one’ database organisation.