Nautical charts: 2m depth contour

[sonora]

I received feedback that our nautical contour line depth do not contain (or perhaps not sufficiently accentuate) the 2m contour, a critical line for many boaters with small vessels to observe.

[miramikes]

I have even saw on some maps that darker blue color has been used for sea with smaller depth than some threshold. 2m is critical depth. https://webapp.navionics.com/?lang=en#boating@11&key=mxchJoht_A

[quantenschaum]

Yes, this is the way areas of certain water depth are displayed in nautical charts.

• white = deep water
• blue = shallow water
• green = drying heights (tidal flats)

see INT1 section I

OsmAnd should adopt this. It looks like this:

[miramikes]

Yes, this is the way areas of certain water depth are displayed in nautical charts.

• white = deep water
• blue = shallow water
• green = drying heights (tidal flats)

see INT1 section I

Yes ... looking at INT1 section I ... page 47

Quote from ChartNo1.pdf: "Blue tint, in one or more shades, or tint ribbons are shown to different limits according to the scale and purpose of the chart and the nature of the bathymetry."

Shallow water can be displayed in two or four shades ... according to ChartNo1.pdf So I would suggest to use four shades concept to make it as much informative as possible.

• white = deep water
• very light blue = shallow water 10-20m depth
• light blue = shallow water 5-10 m depth
• blue = shallow water 2-5 m depth
• dark blue = shallow water 0-2 m depth
• green = drying heights (tidal flats)

[quantenschaum]

This seems to me to be very good default. Since you can add user configurable variables to the render.xml, it is possible to supply several color schemes for depth contours for different scenarios, so the user can choose the one the he likes best. Possibly with fewer blue areas for a shallow draft boat or may an emphasized (red) 2m line. The Navionics map allows you to set the safety depth in the menu. Everything shallower than this is blue, deeper water is white.

So, this is the rendering side of depth data. But how is depth data tagged in the OSM database? There are 3 types of depth information AFAIK

• spot soundings (single points)
• contour lines (lines)
• contour areas (closed polygons)

:question: Is there an existing tagging scheme for this kind of information that is already handled by the render engine?

[quantenschaum]

Another coloring scheme that could be made available for the user to select is the ECDIS style (right most column in the INT1).

Maybe it is desirable to have an entire ECDIS like style for nautical charts.

[miramikes]

Another coloring scheme that could be made available for the user to select is the ECDIS style (right most column in the INT1).

Maybe it is desirable to have an entire ECDIS like style for nautical charts.

ECDIS coloring scheme looks also good to me ... I'd like 4 sea depths in well-distinguishable blue colors plus tidal flats in green ... still well visible on display on sunny days ;)

[quantenschaum]

Here I have something to offer concerning tidal flat in green.

[quantenschaum]

Styling depth contours is one thing, but there is no reliable depth data available for OsmAnd.

https://github.com/osmandapp/OsmAnd/discussions/12502

[miramikes]

Here I have something to offer concerning tidal flat in green.

Oh ... I like what have you done in your "marine style" a lot Both light and dark style looks great

[miramikes]

Styling depth contours is one thing, but there is no reliable depth data available for OsmAnd.

12502

Don't know what is resolution of this data ... Maybe worth to try https://www.gebco.net/data_and_products/gridded_bathymetry_data/#global

According to this project only cca 25% of ocean floor is mapped at the moment, but plan is to complete all till 2030 https://seabed2030.org/our-mission/

[quantenschaum]

For marine navigation (of leisure craft) the ocean floor is actually not very interesting. What is more important are the shallow areas near the coast with a depth of about 10m and less. There accurate data colored as described above is very important.

[sonora]

@quantenschaum Great work https://github.com/quantenschaum/mapping/blob/master/USAGE.md#marine-style! Would it make sense to use your Marine style directly in OsmAnd, replacung/conbining with the current OsmAnd Nautical renderer, or is there a justification to keep both?

[quantenschaum]

The marine style is based on the nautical style. I just took the nautical style and modified it to fit my personal preferences. If the OsmAnd folks like this style better than the current one, they are free to use it. IMHO it doesn't make sense to have both styles, but since everyone has different preferences, different styles for nautical charts do make sense. Maybe the best way to satisfy different needs is to have have nautical style with subsettings to tweak it to your liking. And maybe there should be two main style, one that looks like a paper chart and one ECDIS like style.

[miramikes]

For marine navigation (of leisure craft) the ocean floor is actually not very interesting. What is more important are the shallow areas near the coast with a depth of about 10m and less. There accurate data colored as described above is very important.

Agree I believe the shallow areas around the coastline will be best covered especially in more populated places. https://www.gebco.net/data_and_products/gridded_bathymetry_data/#global Again I am not sure what resolution these data are ... 1m would be great 5m good 10m acceptable?

[quantenschaum]

Concerning depth data, contour lines and areas I did some work to get nicer, more useful and up to date maps. You can get a nautical chart like this.

Please have a look at
https://github.com/quantenschaum/mapping/blob/master/DEPTH.md

If you like it, feel free to use it in OsmAnd.

[quantenschaum]

Agree I believe the shallow areas around the coastline will be best covered especially in more populated places. https://www.gebco.net/data_and_products/gridded_bathymetry_data/#global Again I am not sure what resolution these data are ... 1m would be great 5m good 10m acceptable?

The data has a resolution of 15 arcsec which is about 500m, so this is far too coarse.

[vshcherb]

BTW if you prepare data you can probably create lighthouse sectors cause it's solely based on map geometry. These sectors could be "drawn" in JOSM or generated as osm.xml first

We can't implement this feature cause we don't have the way yet to generate extra data (especially for live udpates).

[quantenschaum]

That is indeed possible but an ugly workaround. The sectors should be drawn multiple times, so that you have them in the right size for different zoom levels. Instead of rendering the sectors in the app, which does currently no work, extra geometry is generated before creating the OBF. The render.xml is extended to show these newly generated lines and labels in the right style and at the right zoom level. I will give it a try.

In QGIS you can use the geometry generator to do exactly this. So you can load OSM data or an ENC into QGIS and produce something like that form the sector information.

[vshcherb]

As I see sectors are drawn based on visibility: 200m - 200m sector, only that they can different radius. Otherwise we don't have any possibility to render now except "Large icon"

[ivanPyrohivskyi]

TODO: 2 - 5 - 7 - 10 meters contours 1) Generate contours based on the vector ENC 2) Generate contours based on the raster (whole world)

[xmd5a2]

USA depth contour data from NOAA: 1.Contains some "zoom levels": US1-US6. The coverage of these levels varies. These data are often fragmentary and torn. It is not clear how to combine these "zoom levels" to one single data layer because of their different coverage. For example "zoom level 4" (all files prefixed with US4* for this area):

and "zoom level 5" for same area:

We see that level 5 is more detailed than level 4 but some parts are only available at level 4 while other parts are only at level 5

[quantenschaum]

This is something I've stumbled upon already.

I solved this problem using QGIS. It is somewhat tedious.

1. convert the ENCs with ogr2ogr to some format readable by QGIS, one file per usage band
2. load the data into QGIS
3. figure out the highest usage band for each area covered by multiple ENCs.
4. use the DEPARE or M_COVR layers and operations like fix//difference/merge/dissolve to prepare masks for each usageband
5. use these masks to cut the depth data from each usageband
6. merge the data
7. calculate new fields as needed for OsmAnd
8. export to geopackage/geojson
9. import into JOSM using OpenData plugin
10. save as OSM
11. convert to OBF with OsmAndMapCreator

There are cases where an area is covered by multiple ENCs of the same usageband but with contours in meters vs feet. Well, it's like that. :shrug:

It is also possible to put contours of UB3 to zoom levels <10 and contours from UB4+ to zoom levels >=10 in the OBF.

examples can be found here

[RZR-UA]

Important links:

http://waddenzee.duckdns.org/download/

http://waddenzee.duckdns.org/download/usage/

https://community.openstreetmap.org/t/noaa-enc-import/104179

[quantenschaum]

I would like to add these as well

• https://github.com/osmandapp/OsmAnd/discussions/18116
• https://github.com/osmandapp/OsmAnd/issues/16894
• https://github.com/quantenschaum/mapping/blob/master/docs/depth.md (to be moved soon)