OpenCPN Beta Version 3.3.2316 Released

[bcn]

Originally Posted by Hakan

[FONT=Arial]
I have two examples when fogging is disturbing.
In a place where I have to enter a narrow passage and I know for sure, since I’ve been there before, that the chart is reliable. If the picture is fogged I may not see the stone I know how to pass.

The next is to have a look at the attached screen shoots. On the first we see a straight line to the island in the middle. When I zoom in to see what the line is it’s obvious that there are more details but fogging is already wiping the shore contour out.


Håkan

Håkan

perhaps it's due to the upload of the screenshots but I don't see any difference or lost details. The chart is scaled up and the contrasts are lower, but the drawn vector of the chart is the same for me.

At over zoom there is no additional information - just the same content magnified. Or what did I got wrong?

Hubert

[Hakan]

Hubert..
Doubleclick the pics and you'll see that the second shows the half line to be an electric cable and the third shows that actually is the whole line electrified.
Håkan

[bcn]

Yeah,

but what has this to do with fogging/making Xtreme over zoom visible? All details are present.

What me surprises here - what you are pointing at - is that at different Overzoom scale some details are still rendered differently (the cable). For me this is not correct

In this case: Is this a real issue? Is that cable a hazard? Interesting anyhow.

The shore and the rocks are at the same place and visible. For our debate.

Hubert

[Hakan]

Hubert..
Yes it's very strange that the cable detail is not shown in an earlier zoom level, I agree. But this example was more to support my feeling I don't like the fogging. - I can judge the reliability myself and don't you touch my chart's contrast!
But we are coming to feelings here and I don't have words enough to express them correct in English.
I haven't followed this debate so I'm not really aware of why you think it's so important to fog, but I will have look back. But so far I would appreciate if I could be able to switch it off.
Thanks/ Håkan

[Hakan]

More fogging....
Debate is for me finalised, found the .ini way to inactivate it.
Again: All of you and OCPN are splendid, thanks/ Håkan

[Gilletarom]

Originally Posted by Gilletarom

"389. This is a "fogging" effect on excessive overzoom. It is a linear fade, starting at OZ=10, and the chart detail is almost completely gone when OZ=30......

Just a question.
In the "User interface" tab, there is a new slider. What connection exists between the slider and the subject (389) that made me react in this thread. Who can with good quality English, using simple words and phrases explain it.

Thank you in advance. Gilletarom.

[nohal]

Gilletarom...
The answer is simple: There is no connection between the slider and point 389.

The slider sets how soon higher resolution charts are used in the quilt, as described in http://www.cruisersforum.com/forums/...ed-135728.html under point 367.

Pavel

[Viking Sailor]

Originally Posted by Gilletarom

Just a question.
In the "User interface" tab, there is a new slider. What connection exists between the slider and the subject (389) that made me react in this thread. Who can with good quality English, using simple words and phrases explain it.

Thank you in advance. Gilletarom.

Gilletarom,

389 exists because the developers do not believe that sailors are smart enough to figure out how overzooming effects display accuracy.

[Gilletarom]

Hello Viking35

Originally Posted by Viking Sailor

Gilletarom,

389 exists because the developers do not believe that sailors are smart enough to figure out how overzooming effects display accuracy.

Hum .... With all due respect I have for those who develop OpenCPN, especially for Dave, I think they are wrong. They have left office developer to pass in the moralizing function ....

I also add an idea that often saddens me about OpenCPN. At first, it was really simple, very simple and therefore easy to use software. This is no longer an easy to use software. And for many users, we have reached a level of complexity as it must put off a lot.

It could be also that I make out of those who begin to find that O is less convenient to use.

Best regards to Everyone. Gilletarom.

[Hakan]

But, Gilletarom, there is still the opportunity to install a stable OCPN, point to a bunch of charts covering my home waters, add a simple GPS and let go. All without a very complicated process.
The complexity starts with; what if I would like to see that and that and.... Then you have to start to understand how different things comes together and read the wiki OR you go to a dealer and point out where you want the screen, transfer a huge portion of Dollars/EUR and wait for the start button.
If you're happy with the first option there's not so much to bother about - or?

[Gilletarom]

Hello Everyone, Hello Hakan,

Originally Posted by Hakan

But, Gilletarom, there is still the opportunity to install a stable OCPN, point to a bunch of charts covering my home waters, add a simple GPS and let go. All without a very complicated process.
The complexity starts with; ...
If you're happy with the first option there's not so much to bother about - or?

Indeed, one can be satisfied with a minimum of equipment, a GPS and then install a small PC O. But this does not solve the problem of complexity screens O. For many users, it is difficult to make sort through all the options, among those who will actually use and others.

As for reading the wiki, I'm French and it is well known that most French do not read English properly (I know something and I have to make a lot of efforts dice that writing in English is not not made into a simple language).

And using integrated software is in English, it is unusable by most French users.

It is therefore absolutely necessary that the software is as intuitive as possible. And what is true for the French is certainly for many other users worldwide.

Fortunately, by example, there are two French web sites that explain the software:
- "Plaisance Practice", written by Yoruk,
- "Shoreline" that I write.

B.R. Gilletarom.

[bdbcat]

Gilletarom...

I am sorry you feel that O is becoming more complicated. That is not the intent.

The idea is that OCPN will "do the right thing", with very minimal input on the configuration screens, as initially installed.

And I think 3.3.x does that better than 3.2.x ever did.

Agreed, the options tabs are complex. But then so is electronic navigation in general. We intend to provide configuration options for a wide variety of installations and equipment, so we have a lot of options.

But virtually none of those complex options are required for initial use by novices. As has been said, get a GPS, get some charts, and go. O works fine with default settings.

About the fogging:
I feel pretty strongly about the dangers of overzoom. I cruise in the real world, full time 12 months/year, covering thousands of miles per year, in areas where the best charts are unvalidated cm93.

I personally observed a the results of wreck in the Bahamas where overzoomed charts were one proximal cause of the wreck.
http://www.cruisersforum.com/forums/...mas-98087.html

So I know it happens in the real world.

Simply, it would be remiss of us to show highly overzoomed vector charts with implied single pixel accuracy. The accuracy is just not there.

Also, please recognise that the implied accuracy on overzoom applies mainly to vector charts. Raster charts, when overzoomed, show the characteristic "blockiness" of pixels. I am sure we would agree that any navigator could see that a small scale raster is unreliable at overzoomed scales.


Lets take a specific example and analyse it with real numbers.

Using Håkan's example location. The cm93 cell shown in the attached image (ozx1) is at a native scale of 1/50,000.

Recall that virtually all vector charts come from tracing or digitizing original paper charts, and that the compilation scale of vector charts is seldom known precisely.

So, apply the rule of thumb that cartographic details are accurately charted to a position of one pencil width( 1mm) at twice the stipulated nominal scale.

This means that at a screen scale of 1/2400, the accuracy of geographic features on this particular chart at this particular screen scale is about 10mm. I hope that math is clear...

I have taken the liberty of manually editing the screen shot to blur the geographical features out to 10 mm at 1/2900 and attached as ozx2. This is a rough equivalent of what one might see on a raster chart of the same native scale, if one were available.

Would you navigate with this chart at this scale in a place you have never been before, or at night? I would not, and that is my essential argument.

By the way, how did I learn the native scale and get an un-fogged image to work with? Press F9, switching to single chart mode. Chart piano bar key rollover will show the chart scale, and OZ fogging is disabled for single chart mode.

Let us continue the discussion with real examples, and with native scales noted. That is the only way to make sense of this admittedly complex issue.

Thanks for listening
Dave

[cagney]

Dave

Here is a picture of the relevant raster chart.

fog.jpg Views: 189 Size: 354.3 KB ID: 91993" style="margin: 2px" />

Swedish chart 932 in a scale of 1:25.000. There is no info available about the survey it's base on. There is no source diagram on my chart from 1999. That the scale of the chart is 1:25.000, is most likely due to a well surveyed shipping channel 2.3 M to the east.

Thomas

[bdbcat]

Hubert...

re:

"And one additional observation:
Menu enabled and dragging, zooming or just clicking on the canvas will disable the menu.
This under Windows as well. Feature or bug?"

As you discovered, when you push the "Alt" key you get a temporary menubar. The bar will stay visible and active until the next mouse click on the chart, of any type (move, drag, zoom, etc.). Then the temporary menubar will disappear.

Is this intuitive, or too distracting? We could change this to do something else...

Thanks
Dave

[bdbcat]

cagney...

re:
"There seems to be a bug in the route properties.
Any value entered as "Plan Speed" in the Route properties dialog, is saved in the ini file value "PlanSpeed=XX".
Currently it looks like this value is not read back. Any new route always use a default 5 kts irrespective of the ini file value of "PlanSpeed"."

Yep. Fixed in github now.

Thanks for the catch
Dave