Sounding size adjustment on Vector Charts

[nohal]

Originally Posted by rgleason

Pavel, when you say "try somewhere else, where the chart cells are composing your view are different" are you saying that different charts handle this differently?



I guess that's not surprising really. I hope it does not mean trouble if we move the size changes up to end at the Overzoom warning.

I have checked in several places and I believe that working with NOAA charts this would work.

Yes, I will file a feature request for this, directly.

Thank you Pavel! and Bdcat!

Rick...
The scale values resulting from your test, as RD already suggested, are a nonsense and totally depending on the local set of charts.
And instead of buying new glasses (or a bigger monitor), you can for now do a local build with the following patch applied It is also a place where you can start looking at the code to understand how this thing actually works...

diff --git a/src/s52plib.cpp b/src/s52plib.cpp
index 5c25933..8b4862e 100644
--- a/src/s52plib.cpp
+++ b/src/s52plib.cpp
@@ -2316,7 +2316,7 @@ bool s52plib::RenderRasterSymbol( ObjRazRules *rzRules, Rule *prule, wxPoint &r,
     
     if(g_oz_vector_scale && vp->b_quilt){
         double sfactor = vp->ref_scale/vp->chart_scale;
-        scale_factor = wxMax((sfactor - g_overzoom_emphasis_base)  / 4., 1);
+        scale_factor = wxMax((sfactor - g_overzoom_emphasis_base)  / 4., 1.75);
         scale_factor = wxMin(scale_factor, 20);
     }

Happy New Year

Pavel

[rgleason]

RDr - Ok, I think that sounds like a good suggestion. Will do this tomorrow. Thanks.
Happpy Neww Year. Nite.

[rgleason]

Pavel AWESOME. I did not catch your post last night. Thankyou. Will learn next how to apply a patch rather than hand code the change. I am afraid I just learn in small steps the power of code because the wiring is different (or maybe mine is different). I will crack a c++ book thid year.

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[HappySeagull]

and here I thought I was going to try and mess up the .rle file but this might be a lifeline!!

[rgleason]

Opencpn Wiki Options Settings > Display > Advanced Tab
Scaled Vector charts (default) on Overzoom
I removed the local scale as suggested. Thanks.
Setting Options | Official OpenCPN Homepage

Apply Pavel's Patch
This https://docs.moodle.org/dev/How_to_create_a_patch
made me realize that Pavel used the Linux diff command to create a patch, and not git diff.

Then this webpage How to read a patch or diff and understand its structure to apply it manually » markusbe.com was helpful, telling me I had a "unified diff" with @@ and +++ and --- and explained how a "unified diff" worked, which I had figured out all ready.

This webpage about git diff suggests: https://ariejan.net/2009/10/26/how-t...atch-with-git/

To make creating patches easier, there are some common git practices you should follow. It’s not necessary, but it will make your life easier.
If you fix a bug or create a new feature – do it in a separate branch!

The corollary question is should I create a new separate branch to apply the linux diff patch?
--I am going to make a new branch before I apply the patch called "soundings" to preserve my "master" branch. This article also suggested testing the patch first.

Using Git shell, with a cd to c:/github/OpenCPN type "diff --help" lordy it worked there is a program like this in Windows...and it has lots of instructions. Usage: diff [OPTION]... FILE1 FILE2

patch --help has a similar long list
Usage: patch [OPTION]... [ORIGFILE [PATCHFILE]]

This should be useful
patch - Linux Command - Unix Command
--dry-run
--verbose
diff - Linux Command - Unix Command

----

Make a new branch called soundings

git branch
*master
git pull
- downloads from upstream github.com/OpenCpn because it is set up that way.
git branch soundings
git branch
*master
soundings
git checkout soundings
git branch
master
*soundings

Apply Pavel's patch

Saved a file 'soundings-pavel.txt' in the c:/github/opencpn directory.
There may be some problem about hard endings <cntrl><end> because this is in windows.

diff --git a/src/s52plib.cpp b/src/s52plib.cpp
index 5c25933..8b4862e 100644
--- a/src/s52plib.cpp
+++ b/src/s52plib.cpp
@@ -2316,7 +2316,7 @@ bool s52plib::RenderRasterSymbol( ObjRazRules *rzRules, Rule *prule, wxPoint &r,
     
     if(g_oz_vector_scale && vp->b_quilt){
         double sfactor = vp->ref_scale/vp->chart_scale;
-        scale_factor = wxMax((sfactor - g_overzoom_emphasis_base)  / 4., 1);
+        scale_factor = wxMax((sfactor - g_overzoom_emphasis_base)  / 4., 1.75);
         scale_factor = wxMin(scale_factor, 20);
     }

C:\..\GitHub\OpenCPN>
patch --dry-run --verbose src/s52plib.cpp  soundings-pavel.txt
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/s52plib.cpp b/src/s52plib.cpp
|index 5c25933..8b4862e 100644
|--- a/src/s52plib.cpp
|+++ b/src/s52plib.cpp
--------------------------
Patching file `src/s52plib.cpp' using Plan A...
Hunk #1 succeeded at 2316 with fuzz 1.
done

Then ran successfully
patch --verbose src/s52plib.cpp soundings-pavel.txt

cd build
cmake ..
cmake --build . 
cmake --build . --config release
cpack

compiled fine

[rgleason]

There is a noticeable difference in the 1.75 factor. While it may seem a little crowded when zoomed out, just hit "S" and the depths go away. Zoom in and hit "S" and its better than glasses.

I think what Pavel's change did was increase all soundings size by 1.75 because when I zoom into 33x the characteristic scale change still occurs there, rather than at just above the "Overzoom Warning". He may be doing this to maintain some compliance with ECDIS, although, I would think having the soundings reduce in size after the first overzoom might be more visual that what ECDIS mandates now.
Below are some screen shots and one comparison. I have taken care not to "resize" anything, just crop, so that what you see is pretty real.
A. 1.75-2.0x Left (enlarged soundings) - 1.0-2.0x Right (standard)
B. 1.75-0.30x (enlarged soundings shown)
C. 1.75-0.30x (Hit "S" to turn off soundings)
D. 1.75-1.2x
E. 1.75-2.0x
F. 1.75-4.0x
G. 1.75-33.0x

I think I like this, but of course, there is room for improvements. Thank you. Pavel.

PS You have to click on the upper 4 images to get the full scale! The bottom ones are full scale.

[rgleason]

By the way, Pavel. Since I've compiled a different version now, I was looking for where I could modify the Minor Version number or something, because my dear Gille.. had several kittens when I did not change the number. However I could not find it because its become some parameter in about.cpp and my bet is that the parameter is somewhere in the cmake file now. Any suggestons?

It would also make installation easier for comparison I think.

Perhaps the best thing to do is not upload it....?
As things get too accessible...until people have a chance to think about it.

[RhythmDoctor]

I think you should also test the soundings in meters and fathoms. Those units will also present the first decimal place in the sounding, which may create unacceptable clutter and/or "box overflow" issues at the larger symbol size.

I'm not a fan of the decimal place, since it's unnecessary clutter IMO. I only started using ENC when Dave removed the decimal from the charts when showing "feet" units. But it still is there for meters and fathoms, and perhaps justifiable since 0.1 fathom probably is significant.

[rgleason]

RDr - Agreed about fathoms, but I think of fathoms as being more use for deep water but haven't a clue how large vessels use it.

Your concern is somewhat true, but with several changes it would not be a problem.

1. Zoomed out there is some overlap and greater density.
2. "S" toggle to turn/off on depth is good, but not so good for Tablets..might want to teach Launcher plugin to do toggles, or have a button...?
3. Also if we were able to keep the soundings scale as it is for zoomed out, but have the scale of the sounding increase to maximum when zoom level hits the "Overzoom Warning" condition, that would work much better. When zoomed out, it would be just as it is now in the normal Opencpn.
4. In my opinion there is not a lot of difference between sounding "density" when in Meters, Fathoms or Feet. It's been engineered and adjusted that way anyway.
5. I could see a use for a soundings toggle "B" between normal and some user enlargement setting between 1 and 1.75. "A" is Anchorage toggle which includes bottom features, so "B" for bottom is good.
6. There is a possibility that just changing the lighter text for darker would help.
7. I could see a use for a setting to put depth at cursor in the bottom bar if the text is bigger,
8. But of course, we should not forget the actual depth off the sounder to the Dashboard, but that is not as flexible...

Its possible all these ideas will break the ECDIS requirements...just trying to make it better for us.
---------------------------------------
Now the screenshots:
1.75x0.30x-Fathoms.png
1.75-0.30x-Meters.png
1.75-0.60x-Fathoms-CM98-Off-Isla-Cerros
1.75-1.8x-Fathoms-CM98-Off-Isla-Cerros

[wdkester]

RGleason,

I too have difficulty seeing depths on vector charts, and that's with glasses. I cannot use Vector charts in the cockpit for this reason.

I would prefer a simple scale factor for depths regardless of the zoom level. Settable in Options>Charts>Vector Chart Display.

Personally I consider the very large "OverZoom" to be warning enough. No need to start "biggering" the depths after the Nth level of OverZooming.

[rgleason]

I agree woth "no need to start biggering the depths afyer thr Nth level of OverZooming".

I am suggesting it should END after the first OverZoom! This accomplishes several.things hopefully:
1. On the second ovetzoom soundings drop in size which is a second notice of overzoom.
2. In close circumstances when you need soundings the size is increased in steps up to the first ocerzoom.
3. When zoomed out the sounding go back to mormal size, use of the colored soundings indicator kicks in and the soundings do not dominate the screen.

Finally I do agree that a general options setting would be very useful. I have not figured out how this will "break" ECDIS compliance but I know one of the shatp eyed bright individuals on the forum will advise.

Pavel has been very helpful in "breaking:" opencpn ecdid compliance, but this is not his fault.

I hope to take this further in the coming days.

It seems to me that raster charts are best for those with need for glasses (dislike the darn things, never needed them before) because zoom in increases sounding size proportionally! What is wrong with that?

Maybe we shoulf have a ln optiom to make raster sounding symbols act like raster charts? Sounding symbols scaled to zoom level like raster charts. That action must meet some ECDIS standard!

Just waiting for those sharp eyed individuals to advise!

Thanks for you comment and ideas.

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[RhythmDoctor]

I've been thinking about this a lot the last couple days, and I am a little concerned that you guys are getting too much "into the weeds" and overthinking this. There are some useful websites on ECDIS (use Google), and Dave is right to seek compliance. But I have not yet seen any absolute guidelines on any mandated display size for depth soundings.

I am very concerned about this issue because of the wide range of pixel densities found in tablets. In the Windows8 tablet world, they are as low as 135 ppi (Acer Switch 11 HD model) and as high as 224 ppi (Miix2 10"). These are destined to go even higher as manufacturers strive to match Apple retina specs of 264-401 ppi found in new devices. All of these are much higher than typical desktop monitors, which can be as low as 90-100 ppi.

As far as I can tell, the way O currently handles soundings (aside from intentional Overzoom pixelation) is to display them at a fixed number of pixels. A higher density monitor or tablet display leads to very small soundings, and they will get smaller as the "pixel wars" continue. I am already seeing issues with my relatively low density tablet - the soundings are too small, just like Rick complains about.

Regardless of what ECDIS might say, the cartography standard should be a sounding size in mm - just like it would be for old-fashioned printed charts. O needs to adjust the pixel dimensions of the soundings to maintain a fixed sounding size in mm. As new displays and tablets get higher in pixel density, more pixels sould be used to maintain the same sounding size (in mm).

Dave has already adopted this methodology for the toolbar icons. User can manually enter his display width (from which O calculates the ppi of the display), and the icons are then adjusted to by 9 mm square (if "Tablet Scaled Graphics" is selected). Dave needs to employ the exact same methodology to resize the depth soundings. It would also be nice if there could be a manually input scaling factor so the user could tweak this to his needs, say 120% for oversize. This will become increasingly important for tablets, since the viewing distance can vary radically when users are holding it in their hands, to users mounting it on a binnacle or bulkhead and viewing it from several arm-lengths of distance. (Plus the eyesight differences that Rick mentions.) Tweaking the sounding size will accommodate these differences.

Viewability of the soundings should take a very high priority. Compliance with ECDIS should be the default, but common sense tells us that there needs to be consideration of the display's pixel density in calculating the default, and the ability to override these defaults for different viewing scenarios.

[HappySeagull]

Good work, Rick! if you can make an exe for usrs I'd be happy to try it.
As to fathoms, yer wrong-a fathom is a handy thing for small craft...A man can drown in a fathom, but not less usually... and just to be plain as I read "since 0.1 fathom probably is significant."...there are no decimal fathoms. You will never see the little number go beyond 5 ! (feet!)

[wdkester]

After a quick reading of one version of the standards, I believe that OpenCPN is, to a large degree, in compliance with those standards, which for the most part coincide with the needs of the recreational sailor. However.........

**Cherry Picker Warning**

From http://www.nauticalcharts.noaa.gov/s...mstandards.pdf

"10.2 ECDIS should be designed following ergonomic principles for user-friendly
operation."

I would venture that not being able to view depth soundings clearly at two feet from the screen would violate this requirement. I do understand that making them larger might violate some other requirement; but, I think most requirement writers would rule in favor of legibility.

1. After a quick reading of the standards, I think , that while largely compliant, we are probably in violation in more than one area, especially the alarms area and probably the data update and security area(s).

2. I can't imagine that making the soundings more readable would be frowned upon as long as they didn't obscure some other feature.

3. The screen size and character size were given. The screen size was about 11". I bet there are ships with larger screens. My guess is that screen and character sizes were are minimums (although this was not stated)

4. There seems to be a facility to test for compliance.

I'm wondering what the main authors of OpenCPN think about ECDIS compliance? Should we be fully compliant? or compliant to the extent that it meets the needs of the small boat sailor?

[bcn]

Some first ideas about Compliance:

- 100% where safety related points are in play: presentation/rendering of charts (RNC and ENCs) and objects. Plus operations on those like zooming/panning/quilting.
The debates about Datum, Overzoom and now the size of texts/soundings come here into my mind.
Integration with boat sensors (GPS/Heading/Sounder)
AIS and Radar

- looking for "best practices" used by the professional world
OpenCON can improve here in fields like
· presentation of the key information (Pjotrs remarks about AIS/CPA for example)
· VRM and EBL, safety zones
· Route planning (automatic warnings about hazards)
· Dead Reckoning

I will try to pull a list of (non)compliance against IEC 61174 together.

But anyhow: an official compliance includes a process of homologation of hardware and software. So something we definitely will not do.
A commercial supplier would be free to take OpenCPN, modifying it accordingly (giving the modifications back into O) and go for an homologation.

And there is another aspect: Official bodies are discussing or putting in place the use of electronic devices as the main media for navigation. No "minimum requirements" are defined up to now.
If we check against the ECDIS criteria we will be in a good shape.

Hubert