Feature Requests

[Hakan]

Hubert..
Yes, nice! But would need some more extended development than to just replace data with "---" at timeout.

So if we can agree on critical data list to present this simple timeout it can be a quick change.

The red dot feature would go to Flyspray I think.

[rgleason]

I don't know why we spend time improving dashboard when dashboard-tactics_pi has been thoroughly tested and improved by Petri [canne]. I think dashboard-tactics_pi should replace the current dashboard_pi as an included plugin.


Dashboard_tactics_pi Documentation


Dashboard-tactics_pi Readme


It is too bad there is this diversion, when clearly dashboard-tactics_pi is a huge step forward.


Also please see https://github.com/OpenCPN/OpenCPN/issues/1481


Additionally Petri has many "watchdogs" and has probably already solved those problems. It seems fruitless to improve the old Dashboard when Dashboard-Tactics has been tested and improved so much.

[transmitterdan]

Dashboard-tactics is quite good. It should be recommended to anyone who thinks Dashboard isn’t good enough.

But for now they are in parallel paths. Until someone takes the challenge to integrate it.

Frankly from my point of view (which isn’t worth all that much) neither plugin should be “integrated”. So i would vote for a fly spray issue that says make old Dashboard a stand-alone plugin. That’s a much easier task.

[Hakan]

t-dan's point is good.
@rgleason..
If Dashboard-Tactics is ready what about try to add it to OpenCPN official plugin download page so even those not frequent on this forum can find it? (I suppose it will take some time to finalize the Plugin installer beta?)


I'll try it out the coming days.


BTW: Neither XDR baro-pressure nor temp watchdogs are implemented in Dashboard-Tactic.
Håkan

[skipperearly]

Originally Posted by Hakan

Hubert..
Yes, nice! But would need some more extended development than to just replace data with "---" at timeout.

So if we can agree on critical data list to present this simple timeout it can be a quick change.

The red dot feature would go to Flyspray I think.

may I suggest following list for critical data:
- gps (already done)
- depth
- SOG or STW
- barometer (speed of pressure change would be even better but thats definitely another feature request)

I am not a programmer but from a users point of view any data which is not updated (timeout) should be marked in some way - depth logs typically start blinking last received value alternative the suggested "---" - or even change of color.

[transmitterdan]

Originally Posted by Hakan

t-dan's point is good.
@rgleason..
If Dashboard-Tactics is ready what about try to add it to OpenCPN official plugin download page so even those not frequent on this forum can find it? (I suppose it will take some time to finalize the Plugin installer beta?)


I'll try it out the coming days.


BTW: Neither XDR baro-pressure nor temp watchdogs are implemented in Dashboard-Tactic.
Håkan

Right now dashboard-tactics has conflicts with dashboard. You cannot enable both at the same time without strange things happening. I have been unsuccessful in convincing anyone this issue is an impediment to getting dashboard-tactics more wide usage. Users simply don’t expect a plugin to affect another plugin. They expect to be able to run them side by side. But others don’t agree with me.

[bcn]

Originally Posted by Hakan

Hubert..
Yes, nice! But would need some more extended development than to just replace data with "---" at timeout.

So if we can agree on critical data list to present this simple timeout it can be a quick change.

The red dot feature would go to Flyspray I think.

Lodged two feature requests for dashboard
- signal timeout of updates
- allow calibration of values presented

[rgleason]

Dashboard-Tactics and Dashboard

TDan: "Dash-T is quite good" ...neither plugin should be “integrated”...make old Dashboard a stand-alone plugin. That’s a much easier task.
TDan: "You cannot enable both at the same time without strange things happening."

rgleason: Yes, Making Dashboard standalone would partially solve that issue.

Hakan: -dan's point is good. @rgleason.. If Dashboard-Tactics is ready what about add it to official plugin download page

rgleason: I thought it was already added! I had sent that in some time ago. I will check and send the information again. It will be a normal package type installation for the the time being, as the Plugin Manager interface for Windows to does not really work and that is a development version of O.

@TDan and @Hakan Meanwhile... How do we get Dashboard made into a standalone plugin again? Then users can choose which one.

@Hakan Is there a way to update Dashboard-Tactics if it is missing your added watchdog features? (I believe Petri had delt with that issue in his testing, but I honestly do not remember.)

[Maelruan]

Originally Posted by bdbcat View Post
"All...
The simple answer is:
"OpenCPN v5 does not decode Type 27 messages"
Source code reference: AIS_Decoder.cpp:1685
Accepting Feature Requests on Flyspray.....
Thanks for the heads up
Dave"

[bcn]

Maelruan...


Dave was talking about "Flyspray", the bug tracker at OpenCPN.org


Cheers


Hubert

[Hakan]

Originally Posted by rgleason

Dashboard-Tactics and Dashboard

@TDan and @Hakan Meanwhile... How do we get Dashboard made into a standalone plugin again? Then users can choose which one.

@Hakan Is there a way to update Dashboard-Tactics if it is missing your added watchdog features? (I believe Petri had delt with that issue in his testing, but I honestly do not remember.)

I think the two can also cooperate with the origin still left as inbound and DB-Tactics as external able to install. As long both are not activated simultaneously they won't disturb each other what I've found out. I've on the other hand not tested all possible instruments in DB-Tactics.


Watchdogs: Dashboard is about to be completed in this matter and that would be possible to copy past?
Håkan

[transmitterdan]

Dashboard tactics uses the same persistent storage names and old Dashboard. But they are not 100% the same. So when you run tactics then return to dashboard your dashboard no longer looks the same.

I still think this was a poor design decision. The persistent storage should not be shared between plugins no matter how similar they may be. It just doesn’t make sense to me. And it’s a trivial change to make it so.

[Jon Hacking]

This is difficult for me to explain, so please bear with me.

I've found that creating mbTiles (with SAS Planet & Sat2Chart) from just the most detailed zoom level results in OpenCPN having to choose which pixels to throw out to display a (less detailed) version of the layer when I'm zoomed out in OpenCPN. This takes a LOT of time, even on my quad-proc ex-gaming machine. It's even worse than trying to pan around with a bunch of KAPs displayed.

So I make my mbTiles with several zoom levels embedded, which makes OpenCPN pan & zoom much faster, presumably because it simply reads the layer data from the mbTile without having to process it significantly.

The problem when I'm zoomed IN is that neighboring mbTiles (which only provide very low-resolution imagery for where I'm looking) also show up in the piano-keys at the bottom, & trying to work out which mbTiles I really want to work with requires that I click on all of them to see which ones are in focus for where I'm looking.

MbTiles that only have zoom levels that are far lower than what the user is looking at, & are therefore fuzzy & out of focus, aren't very useful, & clutter the piano-keys display. They may also pose a performance hit, as OpenCPN seems to work out how & where to display them, even if another mbTile has priority (piano-key is further to the left).

Would it be possible for OpenCPN, when it's deciding which mbTile piano keys to display, to filter out the ones that don't have a useful zoom for where the user is looking, even though the edge of that tile may well extend over the area of interest? Thanks!

Also, I really (REALLY) hope the powers that be decide to let OpenCPN wake up with NO mbTiles displayed, like it does with KAPs (assuming there's a nice, easy CM93 or something to display instead). PLEASE! It's a HUGE performance drain, as well as a pain in the patootie to have to turn them all off manually.

Thanks!

[bdbcat]

Jon...


Interesting points.
Do you have some screenshots that might gives us more graphic insight?


Thanks
Dave

[Jon Hacking]

Hi Dave,

When I make mbTiles with SAS & Sat2Chart, I usually make them in sets of 5: ArcGIS, Bing, CMap, Navionics, & GE (which comes out last because they get named "Satellite" for reasons lost in history). I also make them with Zoom levels 10-18, so OpenCPN can pan & zoom easily (generally better than KAPs). We're in the Philippines now, so the islands are fairly close together. Zoom 10 is fairly far out, so it doesn't have much detail but it covers a fairly large area.



CF makes it difficult to post a screen-shot (or I haven't learned the trick). You need to blow this up because it ended up wide, but at the bottom you can see 15 piano keys (all ON!). I've turned off the first 2 to show a CMap image, which shows the effect better. The area in the extreme right is very detailed, the area in the middle not so much, & the area at the far left is even bigger (& fuzzier when I zoom in).

This is not a very good representation of the problem, but if I zoom in on the area to the left, all 15 piano keys are still displayed, since the mbTiles cover that area (at low res), but only 1 set of 5 is actually useful. The others are all too low resolution. But which one? I have to open them all to find out. And panning around changes which quintet is in focus, so I have to go looking all over again.

Since OpenCPN is (presumably) opening those mbTiles, I'd think it would know what zoom levels are available for the area displayed. What I'm proposing is for OpenCPN to not bother displaying the piano-keys for those mbTiles that only have imagery at significantly lower resolution than the current display (OpenCPN zoom level, if you will). In the image here, the leftmost quintet of piano keys WOULD be displayed, because the area at right has good detail. But if I zoom in to the left, only the quintet for that area should be displayed.

And, of course, I'm proposing for OpenCPN to NOT turn mbTile piano keys ON until told to do so, the way it treats KAPs. I can't think of a good reason to have mbTiles default to On, but presumably there is one or they wouldn't default to On. If so, then maybe a preference switch (mbTiles default to ON [on/off]) would be a useful option.

At the risk of fuzzing up my above proposal, I'd also VERY much like mbTiles piano-keys to work like any other piano-keys, where clicking on a different piano key takes you to that chart, instead of having to turn each one on/off. I appreciate that mbTiles *can* have transparent sections, & some folks might want multiple mbTiles turned on at the same time, so again, I'd propose a user settable switch. The mbTiles produced by SAS seem to always be opaque, with no transparency, so having to turn each one on & off is a pain in the patootie (& breaks the nice original paradigm).

Thanks! Let me know if you'd like to see more images.