OpenCPN Version 5.1.428 Beta Test

[P_Dub]

Dave, I finally got it adjusted with version 5.1.428. I had to put it with -1 and it sound me quite right. I will take a closer look on everythings.
Thanks and will come ack to you.

[wingssail]

I was disappointed not to see any mention of a fix for problem with OpenGL and waypoint visibility. (https://www.cruisersforum.com/forums...ml#post3020249)

I've run into more issues with waypoint visibility beyond the "route" issue (above) that all seem to be related to OpenGL.

I assumed from Transmitterdan's replay that this was a flyspray.DoI need to create one? Or report this as a bug in the beta?

[hoolie]

Originally Posted by bdbcat

Hoolie...


1. Click on "Update Plugin catalog:master". Wait for update to complete.
2. Click anywhere in oesenc entry panel on the list.
3. This should present the option "Upgrade to managed version 4.2.7". Select that.

Note: The little icon in the oesenc panel entry, on the right, shows an "up-arrow". This is your indication that an upgrade to oesenc is available.


Also note: "Import Plugin" is an option used in special cases, not needed normally.


Dave

Thanks! I had tried most of that except the vital click somewhere on oesenc panel. I now have v 4.2 7 and it seems to be working fine.

ps I had clicked on the "up-arrow" as I had expected that to update to the managed version - but it doesn't, even though clicking anywhere else does!

[.Paul.]

I have OpenCPN 5.1.428 Beta running on my 64-bit Windows 10. If I enable the dual panel Canvas Layout, and close OpenCPN, it fails to start again.

Here is OpenCPN 5.1.428 in dual panel mode.



This is what I see on the screen when I try to restart OpenCPN.



The CPU usage will be over 50 percent which corresponds to one core running at full speed plus a little more.



In order to restart the OpenCPN Beta, I have to change the canvas layout back to single panel. The easiest way to change the canvas layout is to run OpenCPN 5.0.0, and the layout can be changed there. After setting the canvas layout back to single panel, I can restart OpenCPN 5.1.428. It does not seem to make any difference if I close 5.0.0 or not before I restart 5.1.428.

Here is a picture showing both versions running.



The opencpn.log is attached. As usual, rename the file to remove the “.png” before attempting to open this as a text file.

opencpn.log.pdf

By the way, the capability of running more than one OpenCPN out of several that are installed in parallel is a very nice feature. I hope we keep it.

Paul

[Hakan]

Dave..
This Hoolie comment:

I had clicked on the "up-arrow" as I had expected that to update to the managed version - but it doesn't, even though clicking anywhere else does!

have come to me from other fellows as well. So it may be a intuitive reaction to click on the arrow icon and expect something to happen. Is it possible to make that to react as the surrounding area does?
Håkan

[P_Dub]

Dave,
Good aftenoon, things are working OK except the tide icons and arrows which are a bid oversize. I am using (-1) for chart object scale factor and user scale factor. with ( 0 ) it is a bid too large. Although the buoys are kind of smaller but still OK. On the overall I was preferring 5.0.604 layout. I will keep 5.1.428 till your next version.
Thanks for your kind help.
P_Dub

[.Paul.]

The Beta Test version of OpenCPN makes a rendering error at two places in the US ENC US5TX53M, "GALVESTON BAY ENTRANCE - GALVESTON AND TEXAS CITY HARBORS", latest update 2020-04-20.

Beta Test Version 5.1.428 uses a color for land where there is water. Release Version 5.0.0 correctly uses blue for water.

Slip between Pier 41 and Pier 40: 29° 18.3795' N, 094° 48.9297' W


Yacht Basin: 29° 18.9952' N, 094° 46.6593' W



Paul

[hoolie]

As a general comment about plugins, I like greater integration with the core OCPN. Although I understand their rationale, in some respects the plethora of plugins is a bit of a bugger's muddle. So having greater control and being able to manage them from within the main program is very welcome.

[Moo]

Originally Posted by .Paul.

I have OpenCPN 5.1.428 Beta running on my 64-bit Windows 10. If I enable the dual panel Canvas Layout, and close OpenCPN, it fails to start again.

I'm not seeing this. However I do not have a parallel install running.

W10 home, v 1909, 64bit

[Karanga]

I am hoping that I can manage to get 7mb mbtiles file sent...

I just tried.
I changed the suffix to pdf, which made it "eligible"
However, the file at 7mb is larger than the 2mb allowed by the forum.
So how do I send it?

Tim

Originally Posted by bdbcat

Karanga....
Seems to be some trouble with your MBTiles overlay files.

Will you post them here for analysis?


Thanks
Dave

[Ptizef]

Dave,

"But on my 10' under W10, figures seems very big."
Do you have the Windows screen scale size set above 100%
Dave

I suppose you are speaking about a MSW parameter as I can't find it in OCPN
So the display parameters I found are:
Scale factor texts font set at 100% (recommended)
Screen resolution set at 1366x768 (recommended)

Just for reference:
An individual tool on the toolbar is designed to be 9 mm square, at scale ="0".
Is this what you observe?
Dave

At 0 scale, I found roughly 10mm x 10mm which is the same in my 15' device and very near "your" 9 mm (my measure is approximate)




The problem is that the size in mm is the same in a 15' that in a 10'.
Why that choice?
Anyway, I can manage for the toolbar with the scale factor. It is a bit more annoying for the sounding text, as reducing it reduce at the same time the other objects who seem correct at 0 scale. , but too small at -1/-2.



Regards
JP

[wingssail]

Originally Posted by bdbcat

BlackSea...


"don't understand why mbtiles is only considered an overlay."


We have been over this before, and my opinion does not change.
MBTiles should not be considered "real" charts because:


1. They do not contain the correct metadata to ensure safe navigation. Example: Depth soundings, if they exist: Feet, meters, or fathoms? You say, well, obviously photo overlays do not contain soundings, so this is not relevant. But it is. There is no way to know what the content of an MBtiles represents. Could be a screen grab from some other charting app, could be Google data, could be SAP. The tiles are simply georeferenced PNG images, without backup information.



2. They are mostly homemade, with absolutely no provenance. Could be georeferenced totally in error, and there is no way to know, or even test for this.


In a place where only GSHHS and MBTiles are present, I would say that OCPN is simply a useful visualization tool, but certainly not suitable for navigation.

Dave

You've lost me on this one Dave, I've been making and using raster scan charts for years and they have all the disadvantages you mention yet they are handled in a consistent manner to all other charts, as far as I can see. I don't see the reason for an MBtile to by handled differently from home made .kap.

[bdbcat]

JP...
"The problem is that the size in mm is the same in a 15' that in a 10'.
Why that choice?"


You probably have "Enable Scaled Graphics Interface" ticked on. With this option set, the tools are normalized to 9 mm, to ensure that they are always accessible by finger on touch-screens.


Dave

[bdbcat]

Wingssail...


KAPs have metadata, intended to communicate to the chart system (OpenCPN) some critical information about the charts. Things like soundings units, scanning resolution, projection, etc. While not all of these items are normally populated in a home-made KAP file, the possibility is there. And each bit of data in the metadata adds to the confidence of the charting system.
MBTiles, on the other hand, have none of this metadata. And no general way of adding that metadata. It is disturbingly easy to build and distribute an MBTiles dataset that is just plain wrong. And if the tile coverage applies to an unfamiliar geographical area, the user will have no way of knowing that fact. The root problem is, in navigation as in many other technical endevours, being just a little bit wrong is often worse than having no information at all.



Dave

[Baikal]

Originally Posted by bdbcat

Wingssail...


KAPs have metadata, intended to communicate to the chart system (OpenCPN) some critical information about the charts. Things like soundings units, scanning resolution, projection, etc. While not all of these items are normally populated in a home-made KAP file, the possibility is there. And each bit of data in the metadata adds to the confidence of the charting system.
MBTiles, on the other hand, have none of this metadata. And no general way of adding that metadata. It is disturbingly easy to build and distribute an MBTiles dataset that is just plain wrong. And if the tile coverage applies to an unfamiliar geographical area, the user will have no way of knowing that fact. The root problem is, in navigation as in many other technical endevours, being just a little bit wrong is often worse than having no information at all.
Dave

Dave, users have problems with sources of relevant charts for OpenCPN. Using the old CM93/2 is unsafe, oeSenc is limited in coverage and does not display charts correctly. You give users the opportunity to easily and quickly make mbtiles from various sources (Sat, Marine chart) of the wonderful SasPlanet program, but limit their potential. Anyone who prepares mbtiles, geotiff, jpg, from SasPlanet sees and takes into account the projection metadata, Zoom, we ourselves are responsible for the use of such sources. Let me remind you that earlier mbtiles worked in CPN as a KAP chart, it was convenient and there were no problems with performance on large coverage. There was a proposal to make a hybrid mbtiles display with ENC FS#2529.
I propose making an open vote for users to display mbtiles as a chart!