Increasing Efﬁciency of Nautical Chart Production and Accessibility to Marine Environment Data through an Open-Science Compilation Workﬂow

: Electronic Navigational Chart (ENC) data are essential for safe maritime navigation and have multiple other uses in a wide range of enterprises. Charts are relied upon to be as accurate and as up-to-date as possible by the vessels moving vast amounts of products to global ports each year. However, cartographic generalization processes for updating and creating ENCs are complex and time-consuming. Increasing the efﬁciency of the chart production workﬂow has been long sought by the nautical charting community. Toward this effort, approaches must consider intended scale, data quality, various chart features, and perform consistently in different scenarios. Additionally, supporting open-science initiatives through standardized open-source workﬂows will increase marine data accessibility for other disciplines. Therefore, this paper reviews, improves, and integrates available open-source software, and develops new custom generalization tools, for the semi-automated processing of land and hydrographic features per nautical charting speciﬁcations. The robustness of this approach is demonstrated in two areas of very different geographic conﬁgurations and the effectiveness for use in nautical charting was conﬁrmed by winning the ﬁrst prize in an international competition. The presented rapid data processing combined with the ENC portrayal of results as a web-service provides new opportunities for applications such as the development of base-maps for marine spatial data infrastructures.


Introduction
The Electronic Navigational Chart (ENC) is a database containing essential information about the marine and coastal environment specifically designed to support mariners in planning and executing their voyages. ENCs are utilized by safety of life at sea (SOLAS)regulated and non-regulated vessels, loaded on shipborne navigational systems (such as the Electronic Chart System (ECS) and Electronic Chart Display and Information System (ECDIS) (see [1][2][3])) and displayed following strict International Hydrographic Organization (IHO) portrayal rules [4].
ENC compilation is the result of a compromise between the four product constraints: safety, topology, legibility, and morphology [5]. Among the four, safety is of utmost importance and must be always respected (i.e., that the expected depth, based on the charted information, must not appear deeper than the source bathymetry). Failing to do so may lead to maritime accidents, environmental pollution, and loss of life. Research has ISPRS Int. J. Geo-Inf. 2023, 12,116 3 of 25 facilitate the discovery, access, management, distribution, reuse, and preservation of data in the coastal environment [42]. MSDIs, in conjunction with open data initiatives, are essential tools in digital government transformation (DGT) programs for data sharing and provision of marine services among diverse stakeholders. MSDIs realization is driven by the IHO's S-100 data model for marine domain interoperability, the Open Geopatial Consortium (OGC) APIs, and the World Wide Web Consortium's (W3C) best practices for spatial data publishing on the Web. The services provided through a MSDI can be used for safe and efficient operation of maritime traffic, exploration and exploitation of marine resources, marine spatial planning (MSP), integrated coastal zone management (ICZM), enforcing environmental protection regulations, and charting maritime security information [43][44][45][46].
ENC data are often used to derive base-maps for the front-end of MSDI systems; however, with only a couple of exceptions globally (e.g., the United States National Oceanic and Atmospheric Administration Office of Coast Survey (NOAA/OCS)), nautical charts produced by national nautical charting authorities (referred to as Hydrographic Offices (HOs)) are sold by retailers and not freely available online. Furthermore, the display of ENCs requires specialized systems (ECS, ECDIS) and software (e.g., ESRI ENC Viewer and ArcGIS Maritime extension). Thus, bathymetry is often depicted as a gridded surface with a color ramp (see, e.g., the European EMODNet bathymetry and that of general bathymetric chart of the oceans (GEBCO)). Understanding and interpreting bathymetry under such visualization techniques can be both challenging and burdensome. GIS software is required for investigating regions and features of the data relevant to the application, thus limiting accessibility to the broader community and non-professional users. Furthermore, additional features found on nautical charts (e.g., wrecks, navigation lanes, aids to navigation) may not be available with the above bathymetric datasets, requiring users to query multiple data sources. Cartographically generalized vector bathymetry and features (e.g., spot soundings, depth contours, wrecks, rocks) at the appropriate viewing scale and visualized per nautical chart rules can aid in the standardization of products and increase readability under multiple data representation conditions. Thus, developing open-science tools and workflows can contribute to increasing the discoverability and accessibility of relevant geospatial data.
With the aim to contribute to the efforts for expanding the holistic automated generalization approaches to the maritime domain, reduce the compilation time of fundamental chart features (land areas, depth areas and contours, soundings, buildings) and develop ENC-like products for applications beyond nautical charting, this work reviews available data sources and investigates the integration, testing, and improvement of existing generalization approaches. The work builds upon the professional experience of authors with nautical charting workflows and their research efforts to automate data collection [47] and individual data generalization tasks [15,32], to validate chart data requirements [6,35,[48][49][50][51][52], to model the nautical chart compilation workflow and generalize ENC Skin-of-the-Earth features with no topological errors [34], to shed light and gain knowledge on the capabilities of free and open software for use in ocean mapping workflows [53,54], to build innovative chart symbology [8,46,[55][56][57][58] and custom chart web services [45].
This work is one more building block toward automating chart compilation, but, most importantly, presents a pragmatic semi-automated solution where existing open-source algorithms are leveraged for expediting the compilation process. The importance of this work was confirmed in a recent international nautical charting competition, named the Speed Mapping Challenge (SMC), where the proposed solution won first prize as the preferred solution, unanimously, by all of the judges. Demonstrated under two case studies of very different geographic configurations, this paper illustrates how much of the generalization burden for cartographers can be alleviated by utilizing a hybrid compilation approach, where tools perform the majority of the work and cartographers manually adjust outputs to improve the cartographic representation. The workflow described in this paper may be used for the query, acquisition, processing, and visualization of hydrographic and relevant data for uses other than marine navigation (e.g., research, coastal land development, commercial transportation, and recreational boating and fishing). More so, by lifting the nautical charting safety constraints, this workflow can rapidly produce ENC-view-like base-maps (i.e., mapping products for general use (not for marine navigation), hereinafter called Vector Nautical Maps (VNMs)) for, e.g., MSDI or swiftly distributing crowd-sourced bathymetry back to the community (thus decreasing the lag between data collection, its consolidation, and use).
Hereafter, the paper is organized in the following manner: Section 2 presents the Methodology, Section 3 the Results of our workflow in two test beds, and Section 4 is the Concluding Remarks.

Methodology
This Section outlines the process for obtaining, processing, and visualizing data for either an ENC or VNM (Figure 1). It can be divided into three broad phases: Data preparation (e.g., setting chart extent, data querying and acquisition, formats, and defining features for mapping), data processing (e.g., data cleaning, generalization, enrichment, and output validation), and data portrayal (rendering and symbology). paper may be used for the query, acquisition, processing, and visualization of hydrographic and relevant data for uses other than marine navigation (e.g., research, coastal land development, commercial transportation, and recreational boating and fishing). More so, by lifting the nautical charting safety constraints, this workflow can rapidly produce ENC-view-like base-maps (i.e., mapping products for general use (not for marine navigation), hereinafter called Vector Nautical Maps (VNMs)) for, e.g., MSDI or swiftly distributing crowd-sourced bathymetry back to the community (thus decreasing the lag between data collection, its consolidation, and use).
Hereafter, the paper is organized in the following manner: Section 2 presents the Methodology, Section 3 the Results of our workflow in two test beds, and Section 4 is the Concluding Remarks.

Methodology
This Section outlines the process for obtaining, processing, and visualizing data for either an ENC or VNM (Figure 1). It can be divided into three broad phases: Data preparation (e.g., setting chart extent, data querying and acquisition, formats, and defining features for mapping), data processing (e.g., data cleaning, generalization, enrichment, and output validation), and data portrayal (rendering and symbology).

Data Preparation
The Data Preparation phase includes all the necessary steps for building the source database, such as defining the map limits (Area of Interest (AOI)), determining the necessary feature classes for the product, identifying open data sources, querying and downloading data, collating data (e.g., satellite derived bathymetry (SDB) and data digitization), and validating and correcting data attributes. AOI extent, for both an ENC or VNM, should have maximal coverage of the area of interest at the appropriate scale for the purpose (e.g., a port for a berthing chart) (see [59]). Traditionally, nautical chart AOIs are determined by intended use and chart scale [60], but ENCs are recommended to follow a gridded canonical design (see, e.g., [61]).
Additionally, the feature classes to compose the product, with their geometric primitive and attributes, must be determined. The ENC database is "standardized as to content, structure and format [...], contains all the chart information useful for safe navigation, and may contain supplementary information in addition to that contained in the paper [...] necessary for safe navigation" [3]. The database consists of points (e.g., soundings, navigational aids), polylines (e.g., depth contours, coastline), and polygonal spatial data (e.g., depth areas, land areas), encoded using chain-node topology, as well as various attribute data [59]. There are 170 different geo-features defined for ENCs [59] with seven comprising the, so-called, "skin-of-the-earth" (SOE) features, i.e., the polygon feature classes of depth area (ENC geo-feature "DEPARE"), land area (LNDARE), dredged area (DRGARE), unsurveyed area (UNSARE), floating dock (FLODOC), hulk (HULKES), and pontoon (PONTON). When any of these seven feature classes exist in the AOI, they must be part of the output so that they fully cover the charted area (ENC meta-object "M_COVR") without gaps or overlaps. Among the plethora of the remaining 163 feature classes, soundings and depth contours must also be included, along with aids to navigation (e.g., lights, buoys), dangers to navigation (e.g., wrecks, rocks), and shoreline constructions (e.g., piers, wharfs), if any. Moreover, features such as buildings, roads, spot heights, and elevation contours provide context to the chart, but care must be taken to avoid cluttering essential information for ship navigation.
Data for nautical charts are primarily collected by or on the authority of a HO, normally using echo-sounders, satellites, and LIDAR sensors, following strict rules (see, e.g., [62]). Community sourced data are also evaluated for use (e.g., NOAA charts users may report an error or danger to navigation through NOAA ASSIST [63]); however, HOs are generally reluctant in using unofficial data, mainly due to liability concerns for the final product (the nautical chart). Nonetheless, unofficial data may be used to identify uncharted features (e.g., new piers or rocks) not present in the database, thereby triggering new in situ surveys. Furthermore, due to the limited resources and extensive data gaps, there has been an initiative within the IHO in recent years to explore methods for ingesting bathymetry collected from end users (known as crowd-sourced bathymetry, see e.g. [64,65]). When liability concerns do not exist, e.g., in the case of the general use VNM, open unofficial data can be particularly useful. This data should still be carefully examined, which can be achieved by using multiple data-sources to verify the data presence of features, investigating the data collector (e.g., official data supersedes unofficial), and assessing the collection date (newer data supersedes old). Data conflict, reliability, and prioritization is a problem that HOs encounter as well (see [66]).
Three main data repositories are the National Centers for Environmental Information (NCEI) [67] and the USGS Earth Explorer [68] in the United States, and the European Marine Observation and Data Network (EMODnet) and the Copernicus Open Access hub in Europe. NCEI, in particular, is one of the most significant archives for environmental data globally, hosting and providing public access to over 37 petabytes of atmospheric, coastal, oceanic, and geophysical data [42]. In Canada, Canadian Vector (CanVec) [69] and the Geospatial Data Extraction tool [70] is a multiscale product that originates from the best available geospatial data sources covering the Canadian territory. Furthermore, the Canadian Hydrographic Service (CHS) offers a complete inventory of bathymetric data free to the public for non-navigational use called "CHS NONNA" for the "NON-Navigational" purpose of the data. The product is available in spatial resolutions of 10 and 100 m, horizontally referenced to the World Geodetic System 1984 (WGS84) and vertically referenced to Chart Datum (CD).
There are also non-authoritative sources of hydrographic and relevant data. Google Earth and OpenStreetMap are bountiful sources of coastal geospatial data that can be used to enrich authoritative data, with the aim to enhance representation of reality on the product (pursuant to those discussed previously for the ENC vs. VNM). OpenStreetMap is a collaborative crowd-sourced project to create a free editable geographic database of the world, where some of the data themes have relevance to nautical charting (e.g., jetties and lights). The data can be accessed and viewed with Overpass turbo, a dedicated webbased data tool for OpenStreetMap that runs API queries. Google Earth maps the Earth by superimposing satellite images, aerial photography, and GIS data onto a 3-dimensional globe, allowing users to view cities and landscapes from various angles.
Where the seabed is unsurveyed (i.e., no data exists in the downloaded bathymetry), SDB may be used to fill the gaps. There are various SDB techniques (e.g., [71][72][73][74][75]) that utilize imagery from satellites to estimate bathymetry. Sentinel-2 is an Earth observation mission from the Copernicus Programme that acquires optical imagery at resolutions 10 m to 60 m. Sentinel data can be accessed and viewed online in the Sentinel Hub EO Browser. The USGS Earth Explorer also provides imagery from a multitude of sensors.

Data Processing
Following the data acquisition phase, the source data are generalized to derive a lower level of detail dataset appropriate for the scale of the product based on the compilation requirements. For nautical charting, requirements are described in national and international standards, e.g., NOAA/OCS Nautical Charting Manual [76], IHO S-4 Regulations for International (INT) Charts and Chart Specifications [77], and IHO S-57 Transfer Standard for Digital Hydrographic Data [78]. This work focuses, primarily, on the fundamental SOE features and, secondarily, those from the additional 163 feature classes discussed in previous section.
One of the first tasks is to ensure vertical and horizontal datum agreement with ENC specifications. Bathymetry data in nautical charting are referenced to a low-water level (e.g., Lowest Astronomical Tide or Lowest Low Water) (see, e.g., [78,79]), whereas the heights (elevations) are referenced to a high-water level (Mean Sea Level or higher). Both the selections of a low water level for the depths and a high-water level for the elevations aim to ensure safety. Thereby, the calculated under keel and overhead clearances based on the chart values are extreme (rarely observed), whereas the actual clearances are generally bigger and, thus, are safer for the vessel.
Subsequently, land and water bodies are separated and encoded, making sure that there are no gaps or overlaps between those that represent ENC land areas and depth areas as they both comprise SOE features. Water bodies that are not navigable at the compilation scale, such as lakes and rivers, are not SOE objects and are encoded on top of the land areas. Furthermore, coastlines are separated into natural (COALNE) and man-made (shoreline constructions) (SLCONS). This is achieved by referencing data from satellite imagery and OpenStreetMap.
Elevation (land) contours (LNDCNT) are processed to derive round values at appropriate intervals (e.g., 20 m, 40 m, and so on). When the source elevation contours are referenced to a local geodetic datum (i.e., IGLD85), a datum transformation is required to reference them to the High-Water Level (HWL). The elevation contours' vertices are then converted to a Triangulated Irregular Network (TIN), and the new contours are extracted with linear interpolation.
For the unsurveyed areas, among the various techniques, we utilize the method by Stumpf et al. [75] in this work with Sentinel-2 imagery and depths from the official bathymetry as control points.
Bathymetry data are made available in many different formats (e.g., XYZ, CSAR, GeoTiff) and were downloaded from NONNA as Bathymetric Attributed Grid (BAG) files. Point clouds are extracted from the elevation bands of the downloaded BAG files, which serve as the input for chart sounding selection and the generation of the depth contours. The bathymetric grid is first queried to remove values above the water line, i.e., land elevations, and then converted to point features in an x, y, z format. Areas between the low and high-water levels were used to create intertidal depth areas. The same approach is used for the associated surrounding bathymetric surveys acquired by NONNA. Utilizing the surrounding to the AOI areas is essential for building a model of the seabed for the depth contouring and sounding selection processes, as well as for safety validation (see, e.g., [80,81]).
Both the depth areas and contours are, subsequently, generalized following the nautical chart requirements and constraints (e.g., always toward deep-water and the length of the individual line segments must be longer than 0.3 mm to the scale). Small deep areas may be eliminated, whereas small peaks must be retained for safety. Here, we adopt a hybrid approach that consists of manually adjusting the output of an accepted depth contour generalization method. Following the concept that cartographic outputs must be consistent across boundary extents, the bathymetry of the AOI and surrounding area are combined and converted to a TIN surface model. The isobaths and respective depth area polygons are then extracted using linear interpolation [82] and the double-buffering method for contour generalization [20] is applied. This approach has the advantage of both smoothing the edges of the polygons as well as aggregating those in proximity. On the other hand, the result of the double buffering method has an unnatural appearance [4] and is composed of line segments shorter than the allowed 0.3 mm at scale. Once depth contours are derived, spot soundings can be selected. For sounding selection, based on IHO [77] and NOAA [76] standards, five distinct types of soundings can be identified (in descending order of importance) [32]:

1.
Least Depth: the shallowest sounding of a seafloor feature, e.g., the pinnacle of a seamount, dome, or ridge, delineated by a depth contour.

2.
Shoal: the shallowest local sounding representing the depth over an isolated shoal, which may or may not be delineated by a depth contour. A least depth is always a shoal, but not vice versa; the location is the determining factor. 3.
Deep: the deepest local sounding, e.g., a depression.

4.
Supportive: soundings that portray additional information about the seafloor morphology, e.g., changes in slope away from least depth, shoal, and deep soundings.

5.
Fill: soundings used to estimate depths between widely spaced depth contours.
Least depths are the first soundings selected. For each generalized depth area, the shallowest sounding in the source data is selected. Subsequently, shoal, supportive, and deep soundings are selected. First, the Label-Based Hydrographic Sounding Selection (LBHSS) ( Figure 2) by Dyer et al. [15] is applied to retrieve a hydrographic sounding selection without sounding label overlap and fewer safety violations compared to the commonly used radius and grid-based thinning techniques. The method is product driven, and the only parameter required is the scale of the final product.
The hydrographic sounding selection is combined with the bathymetry surrounding the study area and converted into a TIN surface model using a Delaunay triangulation of the points; maxima points correspond to the shallow soundings, minima to deep soundings, and saddles to supportive soundings [32] (Figure 3). The benefit of using the Hydrographic Sounding Selection for the surface critical points extraction (rather than working on the source bathymetric data) is that it sets the neighborhood distance based on product driven criteria (i.e., the scale of the chart) rather than an arbitrary user-defined search (neighborhood) distance. The hydrographic sounding selection is combined with the bathymetry surrounding the study area and converted into a TIN surface model using a Delaunay triangulation of the points; maxima points correspond to the shallow soundings, minima to deep soundings, and saddles to supportive soundings [32] (Figure 3). The benefit of using the Hydrographic Sounding Selection for the surface critical points extraction (rather than working on the source bathymetric data) is that it sets the neighborhood distance based on product driven criteria (i.e., the scale of the chart) rather than an arbitrary user-defined search (neighborhood) distance. Finally, fill soundings are extracted by applying a radius-based generalization [10] to the hydrographic sounding selection. We use a variable length radius that increases with depth to achieve a denser sounding distribution in shallow waters and less dense in deeper waters. Additional soundings are manually selected or omitted by assessing the safety and legibility constraints. Safety violations are added to the selection and soundings overlapping depth contours are removed in favor of legibility.
Other processing tasks include correcting the position of the objects (such as those derived from OpenStreetMap, e.g., lights may be slightly off their true position and on the sea areas, therefore, they must be moved on the pier after visually confirming their position on Google Maps), generalization of buildings and road network, as well as validation of outputs (and making corrections based on the validation results) to ensure that they meet the guidelines/product requirements.
The IHO S-58 ENC Validation Checks [83] sets out the minimum validation checks that ENC producers must perform before ENCs are released. This work's focus is on the  The hydrographic sounding selection is combined with the bathymetry surrounding the study area and converted into a TIN surface model using a Delaunay triangulation of the points; maxima points correspond to the shallow soundings, minima to deep soundings, and saddles to supportive soundings [32] (Figure 3). The benefit of using the Hydrographic Sounding Selection for the surface critical points extraction (rather than working on the source bathymetric data) is that it sets the neighborhood distance based on product driven criteria (i.e., the scale of the chart) rather than an arbitrary user-defined search (neighborhood) distance. Finally, fill soundings are extracted by applying a radius-based generalization [10] to the hydrographic sounding selection. We use a variable length radius that increases with depth to achieve a denser sounding distribution in shallow waters and less dense in deeper waters. Additional soundings are manually selected or omitted by assessing the safety and legibility constraints. Safety violations are added to the selection and soundings overlapping depth contours are removed in favor of legibility.
Other processing tasks include correcting the position of the objects (such as those derived from OpenStreetMap, e.g., lights may be slightly off their true position and on the sea areas, therefore, they must be moved on the pier after visually confirming their position on Google Maps), generalization of buildings and road network, as well as validation of outputs (and making corrections based on the validation results) to ensure that they meet the guidelines/product requirements.
The IHO S-58 ENC Validation Checks [83] sets out the minimum validation checks that ENC producers must perform before ENCs are released. This work's focus is on the Finally, fill soundings are extracted by applying a radius-based generalization [10] to the hydrographic sounding selection. We use a variable length radius that increases with depth to achieve a denser sounding distribution in shallow waters and less dense in deeper waters. Additional soundings are manually selected or omitted by assessing the safety and legibility constraints. Safety violations are added to the selection and soundings overlapping depth contours are removed in favor of legibility.
Other processing tasks include correcting the position of the objects (such as those derived from OpenStreetMap, e.g., lights may be slightly off their true position and on the sea areas, therefore, they must be moved on the pier after visually confirming their position on Google Maps), generalization of buildings and road network, as well as validation of outputs (and making corrections based on the validation results) to ensure that they meet the guidelines/product requirements.
The IHO S-58 ENC Validation Checks [83] sets out the minimum validation checks that ENC producers must perform before ENCs are released. This work's focus is on the validation of the spatial topology of land and depth areas (i.e., absence of gaps and overlaps), contours (i.e., self-crossing) and soundings (i.e., safety of selection), as well as the proper attribution of features so that they portray according to the rules in IHO S-57 [78]. Most of the above spatial validation tests are performed with spatial queries on the features topological relations (e.g., "overlap") (see, e.g., [84]). In terms of sounding selection, IHO S-4 [77] proposed the use of two tests, the triangle and edge test, while Kastrisios et al. (e.g., [6,49]) proposed a comprehensive test (surface test) that superseded the other two as it identified discrepancies that the two IHO tests failed to detect. The triangle and edge tests are based on the concept that end users mentally triangulate soundings and they do not expect a sounding shallower than the least of the two or three soundings forming an edge or a triangle, whereas the surface test is based on the concept that mariners interpolate charted bathymetry for estimating depth at a location.
Various commercial software is in use for nautical chart compilation, e.g., those by CARIS, ESRI, QPS, D-Kart. Open tools combined with commercial software can enhance existing production workflows, support entrepreneurship, and the efforts of developing countries to develop their own charting capabilities. The following open-source software were used in this work for data processing: MutliBeam-systems (MB-systems), Global Oceanographic Bathymetry Explorer (GLOBE), Quantum GIS (QGIS), WhiteBoxTools, Geographic Resources Analysis Support System (GRASS), System for Automated Geoscientific Analyses (SAGA), LBHSS, HydrOffice, and various Python Libraries. MB-systems [85], a software for processing and display of raw multi-beam bathymetry and backscatter, was used through the online free service NEANIAS Bathymetry Mapping from Acoustic Data service (UW-BAT) [86] in the form of jupyter notebooks in an Amazon Web Services hosted docker machine. MB-system and GLOBE [87] were used to explore and analyze the raw bathymetry from the NCEI repository that may provide additional soundings within the areas of interest. QGIS [88], a free and open-source cross-platform desktop GIS software that supports the viewing, editing, printing, and analysis of geospatial data, served as the main platform for data processing, outputs validation, and chart database compilation. The WhiteBoxTools [89], GRASS [90], and SAGA [91] plugins were utilized for spatial analysis tasks. LBHSS [15] is a software for processing the source bathymetry into a, more manageable, "hydrographic sounding selection" that may, subsequently, serve for the final "cartographic sounding selection". HydrOffice [92] Quality Control Tools includes a validation tool for the sounding selection. Lastly, Python [93] libraries (e.g., Geopandas, Rasterio, Fiona, Pyproj) facilitate the development of custom scripts.

Data Portrayal
ENCs are visualized using dedicated systems and software (e.g., ECDIS, ESRI ENC Viewer) following strict IHO rules. As explained in the Introduction section, there are applications and users (other than maritime navigation) that can benefit from vector mapping products of the coastal and marine environment portrayed following the ENC visualization. For ENC-like visualization of data for VNM products, the MapLibre (opensource fork of Mapbox GL JS) web mapping technology is used. Interpreting the open S-101 portrayal catalog, through the Mapbox styles specification, the visual appearance of the various cartographic features on the map is defined. This includes their draw order and style, i.e., colors and symbols (see the examples in Figure 4), along with their labels. The portrayal conditional symbology rules as well as the visualization order, minimum and maximum display scales are based on S-4 [77], S-52 [4], and S-101 [94] IHO standards, following the work by Contarinis et al. [45].
Furthermore, a MapTiler background is used (based on OpenStreetMap data) from where highways and aeroways are included in the VNM product. Table 1 summarizes the features depicted, their geometric primitive, and display order.  Furthermore, a MapTiler background is used (based on OpenStreetMap data) from where highways and aeroways are included in the VNM product. Table 1 summarizes the features depicted, their geometric primitive, and display order.

Results
This Section presents the results (at 1:15,000 compilation scale) of the approach described in Section 2 in two sites: Thunder Bay and Ottawa River, Canada ( Figure 5). The two areas were selected to demonstrate the robustness and flexibility of our approach as they comprise two different geographic situations that pose unique challenges. In detail, Thunder Bay has a, roughly, half full seabed coverage, with the other half being spot soundings. The seabed is relatively smooth/evenly sloped with land being on the one side only. Bathymetry in Ottawa River consisted of survey lines with a few intertidal areas and an unsurveyed area, with water areas being surrounded by land and with the presence of two islands in the study area. Table 2 provides the AOI coordinates and the datum separation information between elevations and bathymetry for the tested sites.
This Section presents the results (at 1:15,000 compilation scale) of the approach described in Section 2 in two sites: Thunder Bay and Ottawa River, Canada ( Figure 5). The two areas were selected to demonstrate the robustness and flexibility of our approach as they comprise two different geographic situations that pose unique challenges. In detail, Thunder Bay has a, roughly, half full seabed coverage, with the other half being spot soundings. The seabed is relatively smooth/evenly sloped with land being on the one side only. Bathymetry in Ottawa River consisted of survey lines with a few intertidal areas and an unsurveyed area, with water areas being surrounded by land and with the presence of two islands in the study area. Table 2 provides the AOI coordinates and the datum separation information between elevations and bathymetry for the tested sites.

Compilation of Land Features
The Geospatial Data Extraction tool [70] was used to extract the required topographic data from CanVec Themes (see Section 2.1), i.e., lakes and rivers (hydrographic features theme), transportation networks (Transport features), constructions and land use (Manmade features), wooded areas, saturated soils and landscape (Land features), and elevation features. The data were provided by CanVec as an OGC GeoPackage, in WGS 84/Pseudo-Mercator (EPSG:3857), at a scale of 1:50,000 (the highest level of detail available) ( Figure 6).
In processing land features, the first step was to create the coverage polygon (M_COVR) in QGIS using the coordinates in Table 1. Accordingly, we separated the Lake areas and Rivers from the ocean water body using the QGIS Geoprocessing tools (Figure 7a) (due to the fact that lakes and rivers are not SOE features). The Land areas (LNDARE) polygon was then extracted from the difference between the coverage polygon and the clipped water body polygon (Figure 7b).

Compilation of Land Features
The Geospatial Data Extraction tool [70] was used to extract the required topographic data from CanVec Themes (see Section 2.1), i.e., lakes and rivers (hydrographic features theme), transportation networks (Transport features), constructions and land use (Manmade features), wooded areas, saturated soils and landscape (Land features), and elevation features. The data were provided by CanVec as an OGC GeoPackage, in WGS 84/Pseudo-Mercator (EPSG:3857), at a scale of 1:50,000 (the highest level of detail available) ( Figure 6). In processing land features, the first step was to create the coverage polygon (M_COVR) in QGIS using the coordinates in Table 1. Accordingly, we separated the Lake areas and Rivers from the ocean water body using the QGIS Geoprocessing tools ( Figure  7a) (due to the fact that lakes and rivers are not SOE features). The Land areas (LNDARE) polygon was then extracted from the difference between the coverage polygon and the clipped water body polygon (Figure 7b). Regarding the shoreline, the obtained from CanVec (for both the Thunder Bay and Ottawa River sites) was a single continuous polyline without the required distinction between natural shoreline (COALNE) and man-made shoreline constructions (SLCONS). To (EPSG:3857), at a scale of 1:50,000 (the highest level of detail available) ( Figure 6). In processing land features, the first step was to create the coverage polygon (M_COVR) in QGIS using the coordinates in Table 1. Accordingly, we separated the Lake areas and Rivers from the ocean water body using the QGIS Geoprocessing tools ( Figure  7a) (due to the fact that lakes and rivers are not SOE features). The Land areas (LNDARE) polygon was then extracted from the difference between the coverage polygon and the clipped water body polygon (Figure 7b). Regarding the shoreline, the obtained from CanVec (for both the Thunder Bay and Ottawa River sites) was a single continuous polyline without the required distinction between natural shoreline (COALNE) and man-made shoreline constructions (SLCONS). To Regarding the shoreline, the obtained from CanVec (for both the Thunder Bay and Ottawa River sites) was a single continuous polyline without the required distinction between natural shoreline (COALNE) and man-made shoreline constructions (SLCONS). To separate the two, first, in Google Earth, we visually inspected the shoreline to mark the vertices separating artificial and natural coastline in both sites. The obtained vertices from Google Earth were used in QGIS to split the shoreline and encode the COALNE and SLCONS polylines (e.g., the example of Figure 8 in Thunder Bay).
To further enrich the representation of shorelines on the final product, we utilized Overpass Turbo Wizard to query the OpenStreetMap database and download the shoreline constructions (e.g., piers, jetties), seamarks, and landmarks (e.g., lighthouses, chimneys, airports, places of worship) not present in the CanVec dataset. Figure 9a shows the places of worship in Ottawa River, and Figure 9b shows those of lights in Thunder Bay. separate the two, first, in Google Earth, we visually inspected the shoreline to mark the vertices separating artificial and natural coastline in both sites. The obtained vertices from Google Earth were used in QGIS to split the shoreline and encode the COALNE and SLCONS polylines (e.g., the example of Figure 8 in Thunder Bay). To further enrich the representation of shorelines on the final product, we utilized Overpass Turbo Wizard to query the OpenStreetMap database and download the shoreline constructions (e.g., piers, jetties), seamarks, and landmarks (e.g., lighthouses, chimneys, airports, places of worship) not present in the CanVec dataset. Figure 9a shows the places of worship in Ottawa River, and Figure 9b shows those of lights in Thunder Bay. The downloaded elevation contours from CanVec were vertically referenced to the IGLD85 Geodetic Datum, which required their transformation to a HWL for use on charts (see Section 2.1). Table 2 shows the datum information for the two study areas. The transformation resulted in unconventional elevation contour values, e.g., the 200 m elevation contour referenced to IGLD85 is 15.87 m above the HWL. To derive elevation contours of round values at appropriate intervals, using QGIS we extracted the vertices forming the contours and converted them to a TIN model to derive contours every 25 m using linear interpolation ( Figure 10). Accordingly, the highest spot elevations of peaks are added to the final product. SLCONS polylines (e.g., the example of Figure 8 in Thunder Bay). To further enrich the representation of shorelines on the final product, we utilized Overpass Turbo Wizard to query the OpenStreetMap database and download the shoreline constructions (e.g., piers, jetties), seamarks, and landmarks (e.g., lighthouses, chimneys, airports, places of worship) not present in the CanVec dataset. Figure 9a shows the places of worship in Ottawa River, and Figure 9b shows those of lights in Thunder Bay. The downloaded elevation contours from CanVec were vertically referenced to the IGLD85 Geodetic Datum, which required their transformation to a HWL for use on charts (see Section 2.1). Table 2 shows the datum information for the two study areas. The transformation resulted in unconventional elevation contour values, e.g., the 200 m elevation contour referenced to IGLD85 is 15.87 m above the HWL. To derive elevation contours of round values at appropriate intervals, using QGIS we extracted the vertices forming the contours and converted them to a TIN model to derive contours every 25 m using linear interpolation ( Figure 10). Accordingly, the highest spot elevations of peaks are added to the final product. The downloaded elevation contours from CanVec were vertically referenced to the IGLD85 Geodetic Datum, which required their transformation to a HWL for use on charts (see Section 2.1). Table 2 shows the datum information for the two study areas. The transformation resulted in unconventional elevation contour values, e.g., the 200 m elevation contour referenced to IGLD85 is 15.87 m above the HWL. To derive elevation contours of round values at appropriate intervals, using QGIS we extracted the vertices forming the contours and converted them to a TIN model to derive contours every 25 m using linear interpolation ( Figure 10). Accordingly, the highest spot elevations of peaks are added to the final product.
Other land features downloaded from CanVec generalized to the scale of the final product were point and polygon buildings. Visual inspection of the two study areas on Google Earth showed that the topography of both areas was relatively smooth and densely vegetated. Due to that, in building generalization, our focus was on those near the shoreline due to the fact that those inland were not expected to be conspicuous from the sea, with the possible exception of chimneys and places of worship. Other land features downloaded from CanVec generalized to the scale of the final product were point and polygon buildings. Visual inspection of the two study areas on Google Earth showed that the topography of both areas was relatively smooth and densely vegetated. Due to that, in building generalization, our focus was on those near the shoreline due to the fact that those inland were not expected to be conspicuous from the sea, with the possible exception of chimneys and places of worship.

Compilation of Bathymetric Features
Both the Thunder Bay and Ottawa River datasets contained un-surveyed areas (e.g., the area marked in green in Figure 11 in Thunder Bay area). To fill the data gaps, we investigated extracting bathymetric information from satellite imagery. The effort was successful in the Thunder Bay area, whereas, in the Ottawa River the derived bathymetry was of low quality (noisy data) and, therefore, the areas were encoded as un-surveyed areas (UNSARE) for the final product. For the SDB process, the procedure described in the GEBCO Cookbook [95] was adapted in QGIS with satellite data from Sentinel-2 multispectral imagery, obtained from the Sentinel Hub EOB Browser portal. Figure 11 illustrates the derived bathymetry (in the green box) in the area, which was combined with the authoritative bathymetric grid obtained from NONNA for the AOI (red box) and the surrounding areas (blue boxes) (following those described in Section 2.1). As Figure 11 illustrates, Thunder Bay (red box) has a, roughly, half full seabed coverage, with the other half being spot soundings.

Compilation of Bathymetric Features
Both the Thunder Bay and Ottawa River datasets contained un-surveyed areas (e.g., the area marked in green in Figure 11 in Thunder Bay area). To fill the data gaps, we investigated extracting bathymetric information from satellite imagery. The effort was successful in the Thunder Bay area, whereas, in the Ottawa River the derived bathymetry was of low quality (noisy data) and, therefore, the areas were encoded as un-surveyed areas (UNSARE) for the final product. For the SDB process, the procedure described in the GEBCO Cookbook [95] was adapted in QGIS with satellite data from Sentinel-2 multispectral imagery, obtained from the Sentinel Hub EOB Browser portal. Figure 11 illustrates the derived bathymetry (in the green box) in the area, which was combined with the authoritative bathymetric grid obtained from NONNA for the AOI (red box) and the surrounding areas (blue boxes) (following those described in Section 2.1). As Figure 11 illustrates, Thunder Bay (red box) has a, roughly, half full seabed coverage, with the other half being spot soundings.
Depth areas are the first features extracted from the bathymetric grids. For the depth areas generalization, following the hybrid-approach described in Section 2.2, a value of 1 mm to the scale (15 m) was used for the double-buffering method, which was found to be reasonable for a scale of 1:15,000 in the work of Skopeliti et al. [26]. To solve the unnatural appearance and short segments issues of the double buffering method (see Section 2.2) and fix the topology errors, the final depth areas were created by tracing the double-buffered polygons using geometry editing in QGIS. This is shown in the figure below, where the red area is the double-buffer polygon and the curve traced around the red area is the final depth area (Figure 12).
For the sounding selection, we adapted the taxonomy and hierarchy of soundings described in Section 2.1. The least depths are extracted from the source bathymetry using the generalized depth areas, i.e., the shallowest sounding in every depth area is selected and added to the list of selected soundings. To extract the shoal, supportive, and deep soundings, we first applied a label-based generalization algorithm using the LBHSS software to achieve a hydrographic sounding selection without sounding label overlap at the scale of the final product (here 1:15,000).
Based on the method described in Dyer et al. [32], the hydrographic sounding selection was, subsequently, combined with the bathymetry surrounding the study area ( Figure 11). The critical points of the TIN surface model correspond to the shallow soundings (local maxima), deep soundings (local minima), and supportive soundings (saddles). For the fill soundings, the starting and ending lengths of the radius-based generalization [6] for the Thunder Bay dataset was found to be 7.5 mm to the scale (approximately 110 m) and 30 mm (450 m), respectively. For the Ottawa River dataset a suitable density was achieved using a starting and ending radius of 50 m and 150 m, respectively. Depth areas are the first features extracted from the bathymetric grids. For the d areas generalization, following the hybrid-approach described in Section 2.2, a valu mm to the scale (15 m) was used for the double-buffering method, which was found reasonable for a scale of 1:15,000 in the work of Skopeliti et al. [26]. To solve the unna appearance and short segments issues of the double buffering method (see Section and fix the topology errors, the final depth areas were created by tracing the doubleered polygons using geometry editing in QGIS. This is shown in the figure below, w the red area is the double-buffer polygon and the curve traced around the red area final depth area ( Figure 12). For the sounding selection, we adapted the taxonomy and hierarchy of sound described in Section 2.1. The least depths are extracted from the source bathymetry u the generalized depth areas, i.e., the shallowest sounding in every depth area is sel and added to the list of selected soundings. To extract the shoal, supportive, and Figure 11. Thunder Bay (red box) and surrounding areas (blue boxes) bathymetry acquired from CanVec, the unsurveyed area (green box), and the satellite derived bathymetry using Sentinel-2 imagery. Figure 11. Thunder Bay (red box) and surrounding areas (blue boxes) bathymetry acquired from CanVec, the unsurveyed area (green box), and the satellite derived bathymetry using Sentinel-2 imagery.
Depth areas are the first features extracted from the bathymetric grids. For the depth areas generalization, following the hybrid-approach described in Section 2.2, a value of 1 mm to the scale (15 m) was used for the double-buffering method, which was found to be reasonable for a scale of 1:15,000 in the work of Skopeliti et al. [26]. To solve the unnatural appearance and short segments issues of the double buffering method (see Section 2.2) and fix the topology errors, the final depth areas were created by tracing the double-buffered polygons using geometry editing in QGIS. This is shown in the figure below, where the red area is the double-buffer polygon and the curve traced around the red area is the final depth area (Figure 12). For the sounding selection, we adapted the taxonomy and hierarchy of soundings described in Section 2.1. The least depths are extracted from the source bathymetry using the generalized depth areas, i.e., the shallowest sounding in every depth area is selected and added to the list of selected soundings. To extract the shoal, supportive, and deep The final selected sounding set for the chart display was chosen from the extracted soundings described above, with least depth soundings always retained. The remaining soundings were selected by assessing the safety and legibility constraints. The selected sounding set was iteratively validated for safety and any errors were adjusted in the selected soundings ( Figure 13). Additionally, the label-based hydrographic sounding selection algorithm does not account for overlap with depth contours; therefore, unreadable soundings that overlapped depth contours were removed in favor of legibility.
The final selected sounding set for the chart display was chosen from the extracted soundings described above, with least depth soundings always retained. The remaining soundings were selected by assessing the safety and legibility constraints. The selected sounding set was iteratively validated for safety and any errors were adjusted in the selected soundings ( Figure 13). Additionally, the label-based hydrographic sounding selection algorithm does not account for overlap with depth contours; therefore, unreadable soundings that overlapped depth contours were removed in favor of legibility. Figure 13. Results of sounding validation in Thunder Bay using a custom Python script prior to error fixing.

Mapping Products
This section presents the results as an ENC-like (VNM) product at 1:15,000 compilation scale, following the IHO portrayal rules and using the methods described in Contarinis et al. [45]. An overview of the two areas is illustrated in Figure 14

Mapping Products
This section presents the results as an ENC-like (VNM) product at 1:15,000 compilation scale, following the IHO portrayal rules and using the methods described in Contarinis et al. [45]. An overview of the two areas is illustrated in Figure 14 (Thunder Bay at 1:80,000 viewing scale) and Figure 15 (Ottawa River at 1:40,000 viewing scale). Figures 16-18 focus on smaller regions at the 1:15,000 compilation scale. A safety depth of 3 m has been selected. Figure 16 shows the derived bathymetry (soundings and approximate contours) in the (originally) un-surveyed area on Thunder Bay. For inadequately surveyed areas (which can be considered to be the case for SDB), IHO standards allow the encoding of either an unsurveyed area with soundings and contours on top of the UNSARE or regular encoding of depth areas. The latter was what we chose, i.e., populating the unsurveyed area as "approximate" in the respective field Positional Accuracy (POSACC) (visualized as dashed contour lines in Figure 16). It also illustrates the separated shoreline constructions (piers) (which, per IHO portrayal rules, are visualized with thick lines), as well as the jetties (north-east area) and seaplane base, downloaded from OpenStreetMap to enhance the representation of reality in the area.
On the contrary, Figure 17 illustrates the encoded unsurveyed areas in the Ottawa River region due to the derived SDB being noisy and, thus, not used in the final output. Two of the three areas are "dead-ends" where the mariner cannot navigate through. Additionally, the third area is adjoint to the southern bank of the island, which should be avoided as the deeper water lies south of this area. Figure 18 illustrates several piers not included in CanVec that were downloaded from OpenStreetMap: road network, selected buildings, elevation contour, and an intertidal area (in green).   either an unsurveyed area with soundings and contours on top of the UNSARE or regular encoding of depth areas. The latter was what we chose, i.e., populating the unsurveyed area as "approximate" in the respective field Positional Accuracy (POSACC) (visualized as dashed contour lines in Figure 16). It also illustrates the separated shoreline constructions (piers) (which, per IHO portrayal rules, are visualized with thick lines), as well as the jetties (north-east area) and seaplane base, downloaded from OpenStreetMap to enhance the representation of reality in the area. On the contrary, Figure 17 illustrates the encoded unsurveyed areas in the Ottawa River region due to the derived SDB being noisy and, thus, not used in the final output. Two of the three areas are "dead-ends" where the mariner cannot navigate through. Additionally, the third area is adjoint to the southern bank of the island, which should be avoided as the deeper water lies south of this area. Figure 18 illustrates several piers not included in CanVec that were downloaded from OpenStreetMap: road network, selected buildings, elevation contour, and an intertidal area (in green).

Evaluation
The effectiveness of the methodology described in this paper was confirmed in a recent international competition called the "Speed Mapping Challenge", where this work was awarded the first prize, unanimously, by all judges.
The competition was initiated by the Canadian Hydrographic Association (CHA), the CHS, and the Canadian Ocean Mapping Research and Education Network (COMREN) in early 2022 [96]. The task for competing teams was to prototype a cartographic production chain using only open-source data and software. The goal was the production of a "good navigational chart", that being defined as "a simplified but safe representation of our knowledge of the bathymetry" [96]. Teams were asked to demonstrate their workflows in two sites among five (Thunder Bay and Ottawa River being among them), with processing to 1:15,000 chart scale the coastline, land areas, depth areas, bathymetric contours (0 m, 2 m, 5 m, 10 m, 20 m, 50 m, and 100 m), soundings, aids to navigation, unsurveyed areas, and other features (and exported in a GeoJSON format). The competition occurred from 4 April to 6 May 2022, and the final rankings were announced on the last day of the international 2022 Canadian Hydrographic Conference in early June.
The proposals were evaluated by a panel of experts from academia, the industry, and the CHS (the official nautical charting authority of Canada). The evaluation criteria of the proposed compilation workflows were representative of the requirements of a nautical chart and successful automation works. Specifically, the outputs were judged based on accuracy, i.e., that the product consists of safe bathymetric contours, safe sounding selection, and correct topology; legibility, i.e., that the elements composing the chart are well chosen so that the chart is legible and understandable at a glance from a navigator who only has a few moments to make a decision; flexibility, i.e., that the methodology is applicable to different sites, and robustness i.e., that the result obtained is repeatable and stable.

Concluding Remarks
This paper presented an effort to explore and consolidate open-source data and software, while increasing the efficiency of data processing and reducing the time needed to create or update electronic navigational charts and maps of the marine environment for uses beyond marine navigation. While chart compilation remains mostly manual, this work demonstrated that a hybrid approach, where cartographers validate and fix the output of generalization algorithms, is a feasible and pragmatic solution.
The presented semi-automated approach continuously considered and made efforts to satisfy the fundamental requirements of nautical charts, i.e., safety, topology, and legibility. The safety of depth contours was largely ensured by the double-buffering method as the produced polyline is on the deep water (safe) side. The unnatural appearance of the doublebuffered line was addressed by tracing it on the safe side. To ensure safety of sounding selection, internal validation in the selection process and an external validation, once the automated selection was complete, were utilized. The discrepancies identified by the internal validation were automatically fixed by the algorithm, whereas those by the external validation were manually corrected. Topology among skin-of-the-earth features was largely ensured by the differing method for creating land and depth areas. Topology errors from the depth areas/contours generalization, e.g., self-crossings of contours after the automated double-buffering method and short line segments, were addressed simultaneously with addressing the safety issues and improving the line appearance. The legibility of the soundings was largely ensured by the Label-Based Hydrographic Sounding Selection algorithm and was further enforced by the automated cartographic selection process. As it is demonstrated in Section 3.3, the result is legible and aesthetically pleasing in both test sites, however, overlaps of depth contours and sounding labels may still exist. We regard this as less important because it is easier for one to discern a depth label from a crossing line (compared to two coalescence soundings), yet we will investigate improvements as part of future work.
Another advantage of the method is its flexibility and robustness, as it was demonstrated in two test areas with different geographic characteristics that posed different challenges. Fundamental in achieving this was the implementation of a product driven approach, and particularly that for the sounding generalization. Contrary to solutions that rely on arbitrary values, the scale of the chart and the portrayal rules (i.e., the resulting footprint of soundings on the cartographic model) is the driving factor for the hydrographic selection, while the chart shallow and deep soundings represented the critical points of the respective generalized seabed surface. Nevertheless, the approach can be further improved as part of future work. For example, chart features (e.g., wrecks, rocks) with their actual dimensions on the product, as well as the density of fill soundings in the existing chart may be incorporated in the automated process. Particularly for the latter, in this work, we determined the minimum and maximum density of soundings with width measurements of navigable waters. Part of our future work is to calculate the density of sounding on the existing chart as a guide or, should a chart of the target scale not exist, utilize the statistics of the entire chart portfolio in areas with similar characteristics.
The work presented in this paper is one more building block in the efforts for automating chart compilation. In addition to the above tasks, automation of more tasks will be investigated in the future, e.g., the generalization of buildings and road networks, while new, more efficient, automated algorithms will be incorporated as they become available to further automate the process and reduce the collection-to-product-dissemination times. Lastly, the methodology described in this paper may be used for the rapid processing of bathymetric and relevant data for the compilation of an intuitive, user-friendly, easily understandable by policy makers, professionals, and novice users, vector "ENC-like" basemap background of the coastal land and sea environment for use with a Marine Spatial Data Infrastructure (MSDI) or other relevant web services and uses.