OpenCPN Beta Version 3.3.2330 Released

[Hakan]

Originally Posted by bdbcat

Håkan...

On your printout garbled problem, are you using OpenGL?

Thanks
Dave

Dave..
Yes I am.
Håkan

[bdbcat]

Håkan

re:
A strange shift between vector and raster charts.

The .KAP chart indicated is a Transverse Mercator projection.
We do not attempt to quilt TM charts. They just don't play nice with our Mercator canvas. Long discussions in the past about this, various attempts, but nothing satisfactory.

Not sure why you actually see the raster chart in Shot 3. You should not, really, according to the code. On my linux I cannot ever see it in quilt mode.

You will need to shift to SingleChart Mode ("q") to view TM charts.

Thanks
Dave

[HappySeagull]

Originally Posted by HappySeagull

Thomas is right again.Pixel Error arises for many (or all) kap headers simply modified from UTM,TM, and Polyconic to "Mercator". (EZ is Sleazy)
Still, I don't expect this to be cause of my tilt. Still working on that...

...actually, just a few EZ "mercator" header changes needed fixing.

NOAA Chart Reprojector fixed this chart "easily", if not EZ.

http://coast.noaa.gov/digitalcoast/tools/chartreprojector

because I love quilting .

[Gilletarom]

I realized last few days, several trials on a question I asked myself for a long time. I made the test with the 332 330 version, but I know it is not unique to this version there.

Here are some screenshots. I used a chart in NV verlag for this example. It shows the port of Den Helder in the Netherlands. The official scale of the map is 1/25000.

The settings of OpenCPN:
"Quilting": OFF
"Scale: Do not change When using an other chart": checked.
"OpenGL": OFF

I traced a route which measures 1 nautical mile long.

On the screen, I posted the chart at a scale close to the official scale.

Under these conditions, on my screen, the route has a length of 4.7 cm

Knowing that a nautical mile is 185 200 cm, it is deduced that on this screen, the actual scale is 1/39400. Assuming a measurement error of 1 mm, one can frame the scale between 1/38580 and 1/40260. We are far from the scale announced in the bottom of the screen to the right: 1/24300, zoom level: 1.0 X. To go from 24,300 to 39,400, multiply by 1.62.

If I click once on the ZOOM + button, the same road measuring 9.3 on my screen. An actual scale of 1/19913. Also taking a measurement error of 1 mm, one can frame the actual scale between 1/19700 and 1/20130. This time, it says at the bottom of the screen, right: 1/12100, zoom level: 2.1 X. To go from 12100 to 19913, multiply by 1.57.

Similarly, if I click again ZOOM +, the same route 18,6cm extent on my screen, an actual scale of 1/9956. Always taking into account measurement error 1mmm, it makes coaching the scale between 1/9850 and 11/9955. This time, it says at the bottom of the screen, right: 1/6000, level zomm 4.1. To go from 6000-9903, multiply by 1.65.

To sum up, with my PC and my screen for this chart there, to know the real scale of the map on the screen, I have to multiply by 1.6 (I round because there must be other factors involved)

I made some tests with CM93 with SHOM S57, S63 with SHOM and with NV-Verlag charts. Whenever, the actual display scale is very different from the scale announced bottom of the screen on the right.

I was able to experiment with another PC with a larger screen and 800x600. In all cases, the value declared in the bottom of the screen to the right, does not correspond to the scale of the display. I should point out, moreover, that the multiplier are not always 1.6.

Dave :
- how do you explain this?
- This defect in the value of announced scale can be corrected?

Note: It would be nice if other users were doing a similar study and give here the results (using the same settings as I mentioned earlier in this post.).

B.R. Gilletarom.

[CarCode]

Gilletarom,
have you ever take into account the small vertical scale line at the left of the screen? It shows different measures of miles depending of the scale.
Gerhard

[Mollymawk]

Originally Posted by Gilletarom

To sum up, with my PC and my screen for this chart there, to know the real scale of the map on the screen, I have to multiply by 1.6
[...]
I was able to experiment with another PC with a larger screen and 800x600. In all cases, the value declared in the bottom of the screen to the right, does not correspond to the scale of the display. I should point out, moreover, that the multiplier are not always 1.6.
[...]
It would be nice if other users were doing a similar study and give here the results (using the same settings as I mentioned earlier in this post.).

Yes, I have noticed this problem; on various computers the stated scale is much bigger than the real scale.

Here are some tests from my MacBook Pro, 17" monitor, ~130dpi.

Stated scale 1:5200
1NM = 192mm
Real scale 1:9646
Multiplier 1.86

Stated scale 1:10400
1NM = 94mm
Real scale 1:19702
Multiplier 1.89

Stated scale 1:20900
1NM = 48mm
Real scale 1:38583
Multiplier 1.85

It looks like O probably assumes the monitor is 72dpi, which old monitors used to be... (72/130 = 1.806, not far from my multipliers above) but this is an increasingly inaccurate assumption nowadays with many monitors up to 200dpi and almost all over 100dpi.

Obviously O should take into account the true screen pixel density, if it is possible for it to detect that.

Otherwise, perhaps we could have a setting for it in the options.
It could probably actually replace the "chart zoom/scale weighting" slider, since I am sure the "ideal" value for that slider depends almost entirely on the screen density.
Alternatively, perhaps we can do it backwards: keep that slider, and use its value as a weighting when calculating the chart scale.

Caesar

[wdkester]

Originally Posted by RhythmDoctor

I still think that, as a general design principle, all keyboard shortcuts should have a way to accomplish them without keyboard. The shortcut is just a quicker way to do it with the keyboard. But it should not be the only way, especially in a world with keyboard-less tablets.

+1 This has been mentioned by several others as well.

I would also support some sort of immediate access (think Icon, Plugin, right click, or super shortcut) to the complete list of shortcut definitions.

User defined shortcuts would be great, but as has been mentioned before, perhaps too difficult. It might be easier to provide a way to enable/disable any or all shortcuts. I think this would imply that all actions would have a non shortcut method for invoking.

[bdbcat]

leeward128...

In the next Beta, due very soon, I have added a hidden config item to set the NMEA APB output sentence XTE field precision. It will default to x.xx, but is setable by manual config file edit.

Let me know how this works, please.

Thanks
Dave

[bdbcat]

Folks:

re:

I still think that, as a general design principle, all keyboard shortcuts should have a way to accomplish them without keyboard.

Me too. Tablets are coming...

Who will volunteer to (yet again) survey the shortcut list and determine which shortcut(s) have no accessible mouse or finger equivalent?

Which, of course, means that we need an updated shortcut list. Can this be resurrected, and settled finally before the Release? Volunteer?

Thanks
Dave

[bdbcat]

Gilletarom, et al...

Re on-screen scale.

This issue is a bit annoying, really. OCPN uses the native operating system's idea of monitor resolution and actual pixel density. It makes no assumptions or conversions from that.

However, it turns out that Windows intentionally does not report the true physical dimensions of the screen, even if it knows.
I guess Mac does not either. This really surprises me, since Mac has historically been a relatively closed environment. Surely it knows, especially on a laptpop?
Both report a screen physical size that assumes something, but that something is not well documented.

So, what to do?
We could put a Options setting field to allow the user to enter the true monitor DPI, if known. We would default to something that makes sense for an "average" display, what ever that might be. Probably mine

Or, we could simply state in the Wiki that the scale reported on screen is a relative number, not intended for actual measurement with a caliper.

Opinions?

Dave

[nohal]

Dave...
It looks like nowadays a reasonable default value when we can't get it from the OS is somewhere between 100 and 120 (200+ for hiDPI screens)
For a normal user a sensible way to enter it probably is resolution vs. screen size - something like https://www.sven.de/dpi/
And actually the default must be 128. Until I change my machine

Pavel

[wdkester]

While testing the function keys (F5, F6) I got the following strange result for the right click context menu.

I did a reinstall and it doesn't go away. Is there anything to do (say in the ini file) to reset this?

[wdkester]

Originally Posted by bdbcat

Folks:

re:

I still think that, as a general design principle, all keyboard shortcuts should have a way to accomplish them without keyboard.

Me too. Tablets are coming...

Who will volunteer to (yet again) survey the shortcut list and determine which shortcut(s) have no accessible mouse or finger equivalent?

Which, of course, means that we need an updated shortcut list. Can this be resurrected, and settled finally before the Release? Volunteer?

Thanks
Dave

Using the current help shortcut list-

I think most of the orphans have found a home in the new menu bar,
the exceptions are F5, F6, F11. Maybe these too can have a presence in the menu bar. F6 as a slider maybe.

[Hakan]

Originally Posted by bdbcat

Håkan

re:
A strange shift between vector and raster charts.

The .KAP chart indicated is a Transverse Mercator projection.
We do not attempt to quilt TM charts. They just don't play nice with our Mercator canvas. Long discussions in the past about this, various attempts, but nothing satisfactory.

Not sure why you actually see the raster chart in Shot 3. You should not, really, according to the code. On my linux I cannot ever see it in quilt mode.

You will need to shift to SingleChart Mode ("q") to view TM charts.

Thanks
Dave

Ahaa!! That's how it is!. I've missed that discussion.
I've a couple of these really fantastic charts not produced by the official Swedish authority for charts but a local company carrying out there own hydrography and make charts adapted for cruisers.
Based on your information I should maybe be very happy since my charts actually are mostly useful in quilt mode, especially in combination with BSB raster charts. Though I have to force CM93 back in "business" but that's doable. Could we then even stretch us to claim Windows is not totally lost.
Thanks for your answer/
Håkan

[fgd3]

Originally Posted by nohal

Fabbian...
Don't worry, you can change it in the GUI in the current master. And yes, it is treated "like raster" as well.

Pavel

That's good news. I knew it was coming because it was mentioned earlier in the thread. One of the problems with overzooming a vector chart is the text doesn't get any bigger, so making it "like raster" will be a welcome improvement. Does that mean "like raster" will replace the blur?

On my Linux installation I had a dickens of a time making the change. The config file is in a hidden folder and I didn't know how to make it visible. Fortunately I had Internet access to help. I went the long way around, using terminal to rename .opencpn to opencpn, then going back to the File Manager to edit the now visible file with a text editor (couldn't remember how to use vi). Then I renamed opencpn back to .opencpn. Later I discovered I could have simply made the hidden files visible in File Manager from the View menu. ( I'm still used to looking for the menu at the top of the window, Windows style.) I'm not sure why I thought knowing Unix 30 years ago would make me knowledgeable enough to run Linux. It's working fine now.

Fabbian