2.1.n Feature Request Discussion

[cagney]

The OpenCPN Version 2.1.0 Beta thread has been closed. Lets go forward and, while Dave takes a few days of, think about feature request for the future. There has been many requests in different threads, now is the time to raise these suggestions again, in one thread, so it will be easy for Dave to get a handle on.
There is a separate thread for bugs found in 2.1.0.

Thomas

[bluearcus]

2.1.0 is excellent. The one or two things I'd like to see to make it even better:

1. Vector chart depths toggle
We have a toolbar button to turn labels on and off
Can we also have a button to turn depths on and off please? Rather than in the settings dialog...

2. Vector chart lit marks animation
Could a facility be added to allow light patterns to be animated? Very useful for mark identification at night. Simply glance at the chart, note the timing, then look for the real mark

3. AIS target list ranking
Devise some sort of target ranking, and show targets by this. Probably lowest CPA with a TCPA between 0 and 15 minutes would do fine... then show all the others thereafter. Of course, show CPA and TCPA on the list (they are the most important fields!)

4. AIS target ID memory
Make OpenCPN record AIS IDs and basic vessel details, so that they are available immediately when a vessel is subsequently seen on AIS without having to wait for the vessel details packet each time.

Regards,

Mike

[champ8242]

4. AIS target ID memory
Make OpenCPN record AIS IDs and basic vessel details, so that they are available immediately when a vessel is subsequently seen on AIS without having to wait for the vessel details packet each time.

This could become quite a large dataset

[bluearcus]

I'd supect 5000 vessels would take 500kb to store. Not all details from the messages are required... should be relatively small beer in terms of performance assuming it's implemented sensibly.

[SethDart]

Originally Posted by bluearcus

3. AIS target list ranking
Devise some sort of target ranking, and show targets by this. Probably lowest CPA with a TCPA between 0 and 15 minutes would do fine... then show all the others thereafter. Of course, show CPA and TCPA on the list (they are the most important fields!)

I sent a patch a few days ago to add such feature:

http://www.cruisersforum.com/forums/...tml#post471152

This patch has some ugly parts I don't like. First we must think about what it can be usefull for, think KISS. Is it really needed to have all these columns displayed (say ETA for example) ? What you're asking here is a "danger list", not a "target list" as it is currently. Should we have both? Only the former, or only the latter? One that fits all? I guess we have as many choices as user of navigation software all around.

Some may ask for "buddy" list or displaying these differently on chart/on list. So many users, so many features.

I guess the easyest reply is to say: display all fields available, let user select wich ones he wants to see, saving his choice in config ; same for sorting. IMHO it's not KISS at all!

1/ What columns should be displayed? Static list (as currently) or dynamic (with right button selection as this patch for example)

2/ Sorting... by name / CPA / Range, static or user choice

The current AIS Target List was a first try/guess from me. Now we have to think about it for the best features, keeping it as clear & simple as possible.

[donradcliffe]

The AIS target list should be name/mmsi, range, bearing, cog, sog, TCPA, and CPA, in that order, and sorted by CPA. The only tricky part is that the list will jump around so quickly when the action is fast and furious that its hard to read one line--maybe if you clicked on one entry it would highlight it, and it would remain highlighted no matter where the target jumped in the sorted list.

[donradcliffe]

I'll bring up the two open problems which AFAIK haven't been addressed:

1. A longer cog predictor on 'your boat' icon. If you want to put some sort of speed indicator on it, fine, but right now, I have to guess by eyeball extending its past track, and that's not good enough to see if you are going to hit the reef/buoy/etc.

2. A SOG/COG data smoothing algorithm which averages SOG/COG for up to 20 seconds to eliminate the jumping around with instantaneous data you get from cheap GPS's, and helps solve problem #1.

[bdbcat]

SethDart.....
Implementation note for AIS list: (warning, tech talk follows)

wxList Ctrl is pretty lame. We need a whole new class, that does what we want in terms of sorting, column selection, widths, wxSizer support, night colors, multiselection, cut/past, etc.

We also need to render the liist by a bunch of dc.???() calls on a wxMemoryDC with a wxBitmap, then Blit it to the window on the screen, This will avoid the objectionable flickering which we now have. There seems to be no way to render a wxControl off screen.....


Lots of fiddly stiff here, but I think well worth the effort. A really useful AIS list could be a real advance.

Dave

[bluearcus]

Hi all,

I've assembled a few design thoughts on AIS target lists below.

Originally Posted by donradcliffe

The AIS target list should be name/mmsi, range, bearing, cog, sog, TCPA, and CPA, in that order, and sorted by CPA. The only tricky part is that the list will jump around so quickly when the action is fast and furious that its hard to read one line--maybe if you clicked on one entry it would highlight it, and it would remain highlighted no matter where the target jumped in the sorted list.

I agree Don that rapid change in a 'danger vessels' list can be a problem, but I think that can be reduced significantly if the algorithm for sorting the list is good, and it is used with a suitable facility to employ a smoothed COG/SOG value for OwnShip in the CPA/TtCPA calcs. Most reasonable sized vessels report pretty consistant COG/SOG values, so it is normally mostly the rapid changes in OwnShip COG/SOG data that causes the list to jump around. I suspect a 30 second filter would help a lot.

As for what should be in the targets list, I reckon all AIS targets should be present, so that the list can be used for purposes other than collision risk assessment, but the primary role of the list is to indicate vessels of concern for collision avoidance, so fields for that purpose are vital and should be visible immediately on the list... other fields if need be could be accessed by popup shown on double or right click on either the list entry or the actual on-chart vessel icon, or both. I reckon that means the list should show

Name, MMSI, CPA, TimeToCPA, Distance, Bearing, COG, SOG

As for sorting the list, I would prefer that the list includes all vessels, but that it is normally sorted in two groups

Vessels 'of concern'. These would be all non-stationary vessels with TimeToCPA of between 15 and 0 (or maybe -2) minutes and with CPA less than a 'concern' distance set as a parameter in the AIS config page. A setting in the AIS config page allowing stationary vessels to be either included or excluded from the concern list could also be worthwhile.

These 'vessels of concern' would be shown first in the list, ordered by CPA.

Vessels 'not of concern'.

These would be shown after the vessels of concern, and ordered by distance.

I'd suggest that clicking on any column would allow the list to be re-sorted by that column, and that the list window has a button 'Show targets according to level of concern' which, when the list has been re-ordered, becomes enabled and can be clicked to restore to the original 'concern' ordering.

If an alarm is sounding, perhaps the list should be shown only in order of concern until the alarm clears or is cancelled.

Colour coding in the list might also be worthwhile, for example

Red - vessel generating an alarm state
Black - vessel of concern
Green - vessel 'not of concern'
Grey - vessel with stale AIS data (ie no AIS message received in last x seconds)

Hope that load of opinion is useful...

Regards,

Mike

[cagney]

Originally Posted by donradcliffe

I'll bring up the two open problems which AFAIK haven't been addressed:

1. A longer cog predictor on 'your boat' icon. If you want to put some sort of speed indicator on it, fine, but right now, I have to guess by eyeball extending its past track, and that's not good enough to see if you are going to hit the reef/buoy/etc.

...

This is already implemented, just read about the settings tab in the toolbox here:Toolbox (Settings)

Thomas

[bdbcat]

I have a little list.

1. Garmin private protocol support.
Background: In my circles, a common configuration for sailboats is a PC at the nav station, and a waterproof garmin chart plotter at the cockpit helm. The idea is to do your planning, route layout, etc. in the warm cabin, then upload routes to the Garmin unit for guidance underway. The Garmin may be the NMEA source for the autopilot. We don't do this very well now. Modern Garmins will not upload routes using the generic NMEA format. We need to implement the proprietary, but well documented, Garmin protocol.

2. We must, must come up with a dashboard screen similar to NavMonPC, if only to throttle my email traffic. This is the number one request. We have had sporadic effort on this, but no releasable code. It is a LOT of work, when you consider all the gauge types, user preferences, config file interaction, testing, etc.

3. We need a releaseable Mac port. Again, some effort, but no follow through. I don't know if it even compiles on Mac.....

4. Design/implement a plug-in architecture. First candidate is GRIB. This way, the GRIB support can be removed from the base code, isolated, and understood as a unit. Optimization will follow. With a plugin methodology, we could add KML support, GE overlay, etc.
Its a way to get more programming effort applied with a somewhat eased learning curve. The base code is now too complicated and large for an average developer to approach without a major time commitment. This is one reason that we have a hard time releasing contributed code....Plug-ins can release on their own schedule, and be used or not as they fulfill individual user needs. If a plug-in crashes opencpn, just remove it....

Just a little stream of consciousness....

Dave

[jan eulen]

Good morning,

Thanks for the great program opencpn.
I do have an important feature request and in mine opinion not to much work.
VMG, velocity made good, is for mariners in a sailing boat very important information.
VMG is the speed to a waypoint, single or in a route. The calculation is VMG = cos(course of the boat - the bearing to a waypoint) * speed of the boat. This information in the rout/leg window is a great help for sailers to decide when to tack.

good sailing

Jan Eulen

[CarinaPDX]

Good Morning -

Great job on the new release.

I don't want to hijack the thread but I did want to answer Dave's implicit question about compiling on the Mac.

I am a Mac user, and tried to compile the package. First, I should point out that the last programming I did was nearly 40 years ago with FORTRAN IV on a timesharing system, so keep expectations in check...

I fixed one minor issue with a pragma formatting conflict and will submit that later. It looks like at least 11 if not all 13 errors relate to an inability to include RouteManagerDialog.h because it cannot be found (and yes, it is in the include directory). I need to puzzle over that for a while. The 16 warnings are repetitions of just 2 messages. And the build at least nominally succeeded. So it is not a big leap to get it built, but it may take awhile with my baby steps. I will be visiting my guru brother next weekend (GPSd contributor) and hope to get his help if I haven't figured out the problems by then. If anyone is in the mood to help it will be appreciated.

Fair winds,

Greg

[champ8242]

Hi Greg,

I was able to compile OpenCPN two weeks ago on OSX with Xcode. I did get into a loop (don’t know where yet) at initialization. I will continue this week with the project PM me to get in touch to see if we can exchange our progress

Bart

[JPC Téthys]

Bonjour
Suggestion about grib files :
Grib files obtained through chopper-maxsea contain more informations and from different models, GFS of course, but Wave3 also.
6 month ago, Zygrib could not display these files correctly. I had discussions with Zygrib-author : he modified Zygrib so that gribfiles from chopper-maxsea are now correctly displayed in Zygrib ! thanks to him...
Opencpn uses 'Zygrib-engine' to display grib files on charts. New Opencpn still uses the old Zygrib-engine.
Is it possible that Opencpn use today's Zygrib-engine ??
Thanks
Fair winds for everybody
JPC de Téthys