07-NOV-2024

Author: A.Sabaydash CEO GeoPhone SW

Maritime navigation still remains an informal, intuitive process largely based on the decision-making skills of the navigator, which is regulated by a vast number of documents. These include electronic charts, their display systems, sailing directions, lights and signals, Notices to Mariners, and more. All of these must be interpreted by the navigator to create a safe route.

While these documents help by providing the necessary information on a computer screen in an easily accessible way, they often lead to a new problem—information overload. The navigator, overwhelmed by the sheer volume of data, is unable to fully process it. The computer, which should serve as an assistant, instead becomes the opposite, contributing to what is essentially information stress and overload for the navigator.

One of the main reasons for this situation is the mechanical replication of technologies originally designed for paper charts and documents. This occurs both in the compilation of modern ENCs (Electronic Navigational Charts) and in their use within ECDIS (Electronic Chart Display and Information Systems). The solution lies in a paradigm shift toward creating ENCs and navigational documents with the goal of automating data processing to provide the navigator with ready-made solutions, such as automatically generated routes.

Unfortunately, at present, there is no real progress in this direction. The traditional paradigm continues to overwhelm the captain with vast amounts of information that the computer can display on a monitor, but cannot simplify. The latest editions of IEC standards primarily address the format in which information is presented, rather than its substance. Data standards based on S-100 similarly focus on "better" representation for "easier" human interpretation, without prioritizing automation.

Meanwhile, we believe that the automation of navigation is the key modern challenge. This requires a critical rethinking of the content of existing ENCs, the methods used to create and publish them, and the development of new requirements and standards that would allow for the automatic generation of safe navigation routes without human intervention. Given the above, we define the research focus of this article as follows:

The purpose of this article is to examine the main shortcomings of implementing S-100 in navigational and hydrographic practice and to propose solutions aimed at overcoming them.

Clearly, the task is not a trivial one, but the worst possible solution would be to simply have the computer mimic the way a human navigates. Ships don't swim like fish, and airplanes don't fly like birds, even though both follow the same physical laws. In the same way, computers don't solve problems the way humans do.

At the core of our safe route generation algorithm is the concept of constructing NO GO ZONES on the ENC (Electronic Navigational Chart)—areas where a vessel cannot sail due to draft limitations and safe under-keel clearance. To achieve this, we extract all the bathymetric information available on the chart, including spot depths, depth contours, shorelines, depth areas, point dangers, swept areas, shore facilities, and so on. Using this data, we build a triangulated model of the seabed, which then allows us to generate a NO GO AREA for any vessel's draft value.

Based on the ship's current location and speed vector, we can calculate the distance to the boundary of the NO GO ZONE, allowing us to determine whether the current sailing parameters are safe. If not, we can suggest an alternative, safer route. This same approach is applied when automatically calculating a route from point A to point B.

An example where you can experiment with vessel parameters yourself is available at the following link: https://win1hetz.bgeo.fi/web_demo/mkart.html. Below are several screenshots from that site.

Using 3D model calculated as above one can set any Draught value, Sog and Cog to checkvoyage safety.

The approach described above has been incorporated into our mKart navigational products to automatically propose alternative safe routes.

To obtain statistically reliable assessments, we conducted a small study comparing the performance of this method with the actions of a navigator in similar situations. For this, we connected to AIS data via a live WEB stream to analyze the algorithm's operation alongside the actions of actual crew members on real vessels in real-time. While we did not have access to the actual routes being followed, our study allowed us to draw the following conclusions:

• In the vast majority of cases, the navigator’s actions were identical to those of the algorithm.
• In some cases, vessels sailed safely through areas that the algorithm marked as unsafe.

This latter observation sparked our interest, and after further investigation, we identified two contributing factors. First, incorrect data on the vessel’s draft and the omission of tidal height. Second, insufficient bathymetric information within the ENCs, which poses significant limitations on the implementation of automated navigation algorithms. We identified two common scenarios:

• The first issue is contradictory bathymetric information—interpolated data doesn’t match depths from other sources, such as fairways and recommended routes.
• The second issue is the clear absence of bathymetric data, which prevents the creation of a reliable 3D surface. In the simplest case, this manifests as degenerate triangles in the triangulation model, i.e., triangles whose vertices have zero depth values.

We analyzed the majority of official ENCs within the global collection and concluded that in coastal and challenging navigation waters, the presence of degenerate triangles, indicating a lack of bathymetric data, is a common occurrence.

The main reason for this situation is that modern ENCs are still being created in much the same way as outdated paper charts, especially when it comes to the selection of depths and other bathymetric information. In other words, the data is tailored for human visual perception, based on readability—ensuring there is enough space between numbers and symbols. As a result, ENCs often contain insufficient or contradictory data.

The approach to chart creation needs to be revised to ensure compatibility with machine processing for the purposes of automated navigation. The key criterion here is the adequacy of bathymetric information in ENCs to reliably construct a 3D model of the seabed terrain. There is no need to display high-density bathymetry on ENCs; it is sufficient to ensure during the chart compilation process that the interpolation error between adjacent nodes of the model does not exceed a specified threshold. In many cases, this would involve simply adding a few dozen depths to existing ENCs to make them suitable for automated navigation.

To maintain compatibility with traditional chart displays, the additional depths could be hidden or shown upon specific request at agreed scales.

In cases where, for various reasons, a Hydrographic Office (HO) does not wish to provide additional data (for example, for national security reasons), such areas should be marked as unsuitable for use in automatic navigation algorithms.

It is necessary to develop and implement a procedure for verifying the consistency of bathymetric information, likely within the framework of the S-58 standard.

At the same time, the form of ENC delivery is entirely irrelevant. This can be done either in S-57 or S-101, with the latter offering nothing new in this regard except for unjustified complexity and, as a result, a higher risk of data misinterpretation.