OpenCPN Beta Version 4.8.10109

[Gilletarom]

Dave, Hakkan, Did-g,

Originally Posted by did-g

It's not a new issue if you used proportional arrows for currents, they are ugly for speed > 4, proportional is done by increasing line width and it doesn't work well then. It' worst with opengl .

Do not mix:.
- the problem of how the current arrows appear in the Grib plugin. This is an artefacts.
- the remark that I am trying to take into consideration regarding the arrows of currents that may have opposite directions or different where the OCPN displays current diamonds simoulteously whith a grib of currents..

These are two different topics.

[did-g]

Originally Posted by Gilletarom

Dave, hakkan,


Please, you have to :
- Zoom more, just under the island of Wight.
- Activate currents in the OCPN iconsbar
- using the gpx file that I send in my previous post.

Then you can see that I speak.

Yes some currents are different, may worth a look in case it's a bug in tc code, or not as resolution is so different. I double checked with ifremer data (they have 5 time more spatial points than your grib in this area) same difference (IFREMER model has actual experimental re-analysis with buoys measures) .

Anyway
- you would expect some effects from previous weather and rivers discharge there, obviously not accounted by TC current .

- sorry for the french and not in the same place but

Une comparaison a été réalisée en Mer d’Iroise entre les courants mesurés et ceux modélisés issus des rangs 0, 1 et 2 (modèle Finistère). Les résultats sont présentés Figure 23. Au large, les courants issus des différents rangs sont assez proches. Par contre en zone côtière, le rang 0 n’est pas de résolution suffisante (2km) pour permettre une bonne représentation du courant, que ça soit au niveau de l’île d’Ouessant (point de mesure 1010, voir Figure 16 pour la localisation des mesures) ou de la rade de Brest (mesures 980 et 799). Le rang 1 est plutôt satisfaisant, mais dans les zones très côtières, le rang 2 reste parfois plus précis, comme par exemple au niveau du point de mesure entre la côte ouest du Finistère et l’île d’Ouessant (mesure 986). Dans la rade de Brest (mesure 799), seul le modèle de rang 2 atteint une amplitude proche de la mesure: le rang 0 fournit un courant d’amplitude inférieure à 0.4 m/s, le rang 1 atteint les 0 .6 m/s, le rang 2 atteint les 0.8 m/s et la mesure dépasse les 0.9 m/s

rang 0 is 250 m , 1 is 700 m and 2 is 2 km ie twice your grib resolution but yet they have a 0.5 m/s error ie >0.5 knot you're seeing.

of if TC is from measures it could be reliable as this point.
TL;DR that's noise

[did-g]

Not a new bug and rather trivial but how s57expectedinput.csv has been computed?
There's values in attdecode.csv missing int it.

For example RESTRN 16;discharging prohibited; and above but they are actually used in RESARE and 'Object Query...' returns an unhelpful
16

[bdbcat]

did-g/Gille...

GRIB arrow artifact:
It's not a new issue if you used proportional arrows for currents, they are ugly for speed > 4, proportional is done by increasing line width and it doesn't work well then. It' worst with opengl .

I see this. We can do better, I think. Ill look at it tonight.

The other problem, with different actual predicted values of current:
This is not really an OCPN problem. Like any forecasting activity, different sources will produce different forecasts. It is up to the mariner to decide which is "best" for their own navigation.

In general, there is no way to judge the "accuracy" of a forecast until the event actually occurs. So I don't think we can objectively say which of TCWin or public GRIB file are the more accurate. And AFAIK, GRIBS are never actually corrected by hindcasting. They are only forecasts.

So, as always, mariner's sea-sense prevails.

Thanks
Dave

[P_Dub]

Absolutely correct. My experience over many decade prove me that winds and barometric pressure can alter the tides and currents substentially.
Best regards.

[nkiesel]

Hi,

the latest version of OpenCPN (compiled from Git master as of today) shows chart boundaries although I have the checkbox off for "Show Chart Outlines". I also see "A" and "B" letters along some of these outlines I did not see earlier.

There are also incorrect light renderings at chart boundaries which appear / disappar based on zoom level. However, these also existed for older versions of OpenCPN.

[nkiesel]

Hi,

I still see not only mangled light display (not nice but ok) but also disappearing lights on some zoom levels. Attached is a sequence of screenshots for different zoom levels for the same area (Catalina islands off Southern CA). All I did was to use the zoom buttons. I set "Chart Zoom/Scale Weighting" to 5 for vector charts (all charts are stanardfree NOAA ENC charts).

[Hakan]

Dave, All...
About AIS target size.
As discussed earlier the AIS symbol size has decreased since ver. 4.8.0 On my Win10 screen from ~8 mm to ~5 mm. I would say decreasing is good but 5 mm is slightly small. Especially to detect a inland blue paddle or similar.
What about ~6 mm instead?
Håkan

[Hakan]

Win10:
About: WP-list in tool Route & Mark manager.

The new icons(?) has made the rows in WP list very high. Could anyone decrease them so the list gets easier to browse?
Håkan

[Maelruan]

Originally Posted by bdbcat

Maelruan...

1. Unlikely that we will implement configurable AIS target list columns on this Release. Sorry. I see this as a persistent Feature Request, though.

2. You can already sort the rows by distance. Just click on the column heading for the parameter you would like to sort by, in this case distance. One click sorts increasing. Another click sorts decreasing.

Thanks
Dave

Thanks Dave, that's great!
Regards,

Maelruan

[seandepagnier]

Originally Posted by nkiesel

Hi,

I still see not only mangled light display (not nice but ok) but also disappearing lights on some zoom levels. Attached is a sequence of screenshots for different zoom levels for the same area (Catalina islands off Southern CA). All I did was to use the zoom buttons. I set "Chart Zoom/Scale Weighting" to 5 for vector charts (all charts are stanardfree NOAA ENC charts).

The rendering logic, only allows objects from a given chart to be rendered within that chart's region. This also is important to deal with rendering order.

Now, we could modify things, and relax light sectors (as well as other stuff gets clipped like text), but they would have to be rendered _after_ all the charts are rendered in a separate pass.

This would in many cases be undesirable, as the same light sector often exists in both charts, and would result in two circles and this is confusing as well. Basically, you would solve some problems, but cause new problems.

The solution is not so simple. The best way would be to improve the charts themselves rather than modifying opencpn at all.

As for the disappearing circles... Maybe that sub-chart doesn't have the light sectors at all? What happens with quilted mode off?

[did-g]

Originally Posted by boat_alexandra

The rendering logic, only allows objects from a given chart to be rendered within that chart's region. This also is important to deal with rendering order.

Now, we could modify things, and relax light sectors (as well as other stuff gets clipped like text), but they would have to be rendered _after_ all the charts are rendered in a separate pass.

This would in many cases be undesirable, as the same light sector often exists in both charts, and would result in two circles and this is confusing as well. Basically, you would solve some problems, but cause new problems.

The solution is not so simple. The best way would be to improve the charts themselves rather than modifying opencpn at all.

As for the disappearing circles... Maybe that sub-chart doesn't have the light sectors at all? What happens with quilted mode off?

Text is no more clipped since 4.6 or 4.8 but at some point we'll have to do it proper, lights is one thing, masked buoys is a bigger issue.
I think in 4.8 lights circles where always the same size so it wasn't that visible, all charts in the stack overwrote the same circle.

Rendering only objects in charts visible areas would be slower of course but I'm already doing this for finding hazards and it's not that bad. Maybe could be done in opengl ?

Disappearing circles is likely the SCAMIN issue.
Let say you have a chart I at 80 000 and a chart II at 20 000 with a light's SCAMIN at 39 999, light is visible in chart I, zoom so O switches to chart II at 50 000, light is no more visible until display scale < 39 999. For testing you can unset 'reduce detail at small scale' .

I hate this misfeature, I have my eyes locked on some object, I zoom, it disappears and now I'm lost.

Not all charts use the same SCAMIN scale, maybe we should store in the db something about it but I'm not sure what.


For A/B line it's likely OCPN reset some parameters during upgrade, unset 'char information Objects' for not displaying them. Double check your depth setting and units too!

[nkiesel]

Originally Posted by boat_alexandra

As for the disappearing circles... Maybe that sub-chart doesn't have the light sectors at all? What happens with quilted mode off?

"Quilt off" mostly fixes the problems:
- lights appear at a certain zoom level and stay always visible when zooming in further
- no "rouge" or broken (at chart boundaries) light rings

However, especially for CA with that zoo of charts, not using quilted mode is really not an option - at least not for planning, routing, etc.

I turned off the "Reduced Detail At Small Scale" and that at least avoids the "lights go missing" problem. Thanks for that tip!

I also noticed that there is now a _second_ light ring which appears when hovering over the light itself: a fluorescent yellow ring with diameter adjusting while zooming (i.e. unlike the "classic" light rings, the new one always has the same diameter in miles/kilometers). Why do we need both? It seems the radius is not identical to the visibility of the light (which would be really nice!). Also only shown if light display is on which somehow defeats the purpose: I could see the advantage of an additional ring on hover over the light that is always shown even in "lights off" mode, but currently I see either none or 2 rings.

Another interesting fact of the "hover rings" is that they also draw a second set of light sector lines (solid thinner lines compared to the classical dashed lines). And it seems (only checked a few lights so far) that these new sector lines are actually as long as the visibility of the light!!! So why can't we draw the new hover circles with the same radius? BTW: the new hover rings are always full circles even for sectored lights, while the classical one show a black line instead of a yellow ring for unlit sectors.

Showing (optionally?) light rings adjusted to the real visibility of the light was always a dream. Approaching an unknown location with many navigation lights always creeps me out because I'm not sure which lights I really see. Having a display mode that shows which lights are really visible from the current boat location either by turning off the invisible rings or by zooming all of them to their actual visibility would be _really_ helpful!

[bdbcat]

did-g...

The "A/B" line seen in vector charts is a chart feature (M_NSYS), Navigational system of Marks. It is part of "Standard" category of display.

Corrected rendering in O4.8.1, so now we see it.

Dave

[nkiesel]

Originally Posted by bdbcat

did-g...

The "A/B" line seen in vector charts is a chart feature (M_NSYS), Navigational system of Marks. It is part of "Standard" category of display.

Corrected rendering in O4.8.1, so now we see it.

Dave

YEAH! Turning that off made the "A/B" and the chart outlines disappear!!!

One question: I missed that first because it was not in the lexigrographically sorted first part of vector chart options list (instead it shows up in a semi-sorted list at the end).