Fran-
Under the "wrench" icon, go to charts, vector charts, and there are options to set "shallow depth" "safety depth" "deep depth". By setting the first two at your draft and comfort levels, you get a very good picture very easily.
In my experience, this color highlighting has to correspond to the contour lines that are embedded in the charts. In the US, these are usually at 6 ft, 12 ft, 18 ft, etc. I don't think that OpenCPN will interpolate to create custom contour lines.
One possibility might be to draw a route to encircle areas that you want to avoid. I've done that to mark areas of the Chesapeake Bay that are known to have a high density of crab pots.
Tore that works to some degree, but I can not draw any shape I want & need with that, can I?
Still for the time being its a work around. Thanks for your thoughts.
Maybe the wish can go in the "wishlist"? Or will it be complicated?
Why not just use the Route function and select the line color/thickness and give it a name. You can also select in the Route Manager whether or not to make it visible.
Tore
__________________ "And all I ask is a tall ship and a star to steer her by."
RD-
My understanding of the vector charts maybe incorrect, but "contour lines" should not be included in the charts. Individual depths should be encoded, one at each sounding. Which allows to vector client software (OPN) to read the data points and draw the actual lines as needed. Perhaps someone knows for sure how NOAA is providing this data, on the vector charts.
RD-
My understanding of the vector charts maybe incorrect, but "contour lines" should not be included in the charts. Individual depths should be encoded, one at each sounding. Which allows to vector client software (OPN) to read the data points and draw the actual lines as needed. Perhaps someone knows for sure how NOAA is providing this data, on the vector charts.
CM93 charts and S57 ENCS works very similar in this area.The charts contains depth area features according to fixed depth cutoff zones, usually 5, 10, and 20 meters. Intermediate values are not available in the database,if you select a value between those available, OpenCPN chooses the next higher value available for display of color.
I'll go out on a branch here and guess that means, in order to keep the database on each ENC chart small, they haven't encoded every sounding. That would require a lat/lon position for each sounding and each sounding perhaps to be a separate record in the database. As a compromise, putting in three records (5, 10, 20 meter) and just encoding the multiple locations in each one, should really compact the data. At the cost of "blurring" the charts and only showing those three depths.
Otherwise, if they are showing more soundings...that other data is out there somewhere, and some other invisible trade-offs are being made. Still, it beats "Here be dragons!".
I'll go out on a branch here and guess that means, in order to keep the database on each ENC chart small, they haven't encoded every sounding. That would require a lat/lon position for each sounding and each sounding perhaps to be a separate record in the database. As a compromise, putting in three records (5, 10, 20 meter) and just encoding the multiple locations in each one, should really compact the data. At the cost of "blurring" the charts and only showing those three depths.
Otherwise, if they are showing more soundings...that other data is out there somewhere, and some other invisible trade-offs are being made. Still, it beats "Here be dragons!".
I use mostly raster charts, but I've looked at a lot of ENC charts for NOAA, and I can tell you from observations that they must store both individual soundings and contour lines. There are depth contours near me that have far more detail than could be constructed from any interpolation algorithm of the soundings that are displayed. (see example attachments, and note how the shape of the 6' contours around the island exactly match in both the raster and vector charts)
Also, I believe that the ENC format must include depth, lat, and long. for each sounding. These things are needed for OpenCPN to be able to rotate text to keep it vertical when the chart spins in course-up mode. Note in the attached pics that NOAA's ENC soundings are also in the exact same locations for their raster charts. Same values too, although they display depths in 1/10 foot precision. (I'd still like to see OpenCPN give the option of rounding off to whole number values.)
You are correct. NOAA ENCs include individual soundings, as well as separate contour lines. The spacing of the contour lines depends on the chart native scale, and is not selectable in OCPN.
The contours may, however, be turned on and off as a group using the Mariners Standard display category. They are called (strangely enough) "Depth Contour" in the Mariners Standard object filter list.
All those "x.9" soundings in Feet mode are indeed annoying. I never noticed this before, since I usually look at ENCs in Meters setting. The roundoff error must be coming due to the conversion from the ENC native encoding as Meters, to Ft. displayed on the chart.
Make the ability to save data in layers.
Now with each new launch CPN has to re-load the data into layers. What does not work efficiently with GuideBook based on GPX.
The Garmin GLO bluetooth GPS has a refresh rate of 10hZ. Intend using the GLO to feed the GPScompass on Dashboard to assist the adjustment of magnetic compasses. Ok, COG etc well understood!
A lubbers line on the display of the 'card' would be very useful when the digital display of heading is flickering a degree or three either way. It is sometimes easier to read the heading from the card. Could this be added to a future update.
My own adapted Dashboard plugin which includes the lubbers line is attached. Also a screenshot.
Make the ability to save data in layers.
Now with each new launch CPN has to re-load the data into layers. What does not work efficiently with GuideBook based on GPX.
Just a word on why the layers are made the way they are, i.e. managed completely outside of OpenCPN. Two major reasons for that:
- minimum additional functionality added to OpenCPN (less code, less work, less errors)
- no need to keep a log/backup of layer contents (faster runtime operation)
Please note that the requirement for OpenCPN to restart always in the last known configuration (as it is now), makes necessary to keep track of all changes to WP/RTE/TRK set. Just saving 100's of these may cost a lot of time. It is envisaged that only a fairly static set of objects should be stored in a layer, so the effort of building/maintaining the GPX file for it with some other tools is well justified. This is the reason for dividing the set of objects into (presumably small) dynamic set and (selectable) static set of layers, which do not ever need to be saved.
Using layers should improve the program efficiency at the cost of extra effort needed to prepare the layer files.
I hope this is so indeed... There are many nice tools for managing GPX files.