A Universal Hydrographic Database01/01/1970 |
| In search of ‘The Holy Grail’ |
| 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. |
| Andrey Dmitriev and Eivind Eik Mong, HydroService A/S, Norway |
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.
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:
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:
The resulting UHD will possess the same functionality as an ‘all-in-one’ database with the following advantages:
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. |
| Biography of the author Andrey Dmitriev is production manager at HydroService AS, St. Petersburg in Russia. He is involved in all development projects, including the dKart Office production system and dKart Inspector. Eivind Mong is a technical support engineer at HydroService AS, based in Toronto, Canada. He is involved in dKart Office support, installation, training and S-57 and S-58 standards development and implementation. |
|
| Archive |
| Archive > October 2005, Volume 9, Number 8 > A Universal Hydrographic Database |
|
