Feature Requests

[Hakan]

Oceanrider..
You can make a single Dashboard with the instrument graph called "App & True wind angle"
See more here.

[GSilvegren]

Greetings!

Thanks again for the excellent help we received with the Route & mark manager issue we had last year. The ETAs worked as a charm all summer!

Here's a request for an additional feature in the route and mark manager:

We are using the manager extensively in the planning of our small shipping business, but are struggling to get it right sometimes, as we cannot add "stop times" (struggle to find a suitable term in English, sorry) to the waypoints. For example, we plan for 5 deliveries in a day and communicate ETA's to the consignees. However, we have to "manually" add some cushion to each ETA as the planning obviously does not take into account when the boat is moored for a while.

In a perfect world (for us ), there should be an option to add eg. "Stop: 15 minutes" on a specific waypoint in order to adjust ETA's further down the route. I trust other navigators could benefit from this too, when they stop for refueling for example. The feature could perhaps be something you could toggle on/off in the settings.

Don't know if this is a sensible request but it would help us out immensely in our work. Thanks again for the incredible work you do with OpenCPN!

Best,
Gustav

[Franziska]

Originally Posted by GSilvegren

Greetings!



Thanks again for the excellent help we received with the Route & mark manager issue we had last year. The ETAs worked as a charm all summer!



Here's a request for an additional feature in the route and mark manager:



We are using the manager extensively in the planning of our small shipping business, but are struggling to get it right sometimes, as we cannot add "stop times" (struggle to find a suitable term in English, sorry) to the waypoints. For example, we plan for 5 deliveries in a day and communicate ETA's to the consignees. However, we have to "manually" add some cushion to each ETA as the planning obviously does not take into account when the boat is moored for a while.



In a perfect world (for us ), there should be an option to add eg. "Stop: 15 minutes" on a specific waypoint in order to adjust ETA's further down the route. I trust other navigators could benefit from this too, when they stop for refueling for example. The feature could perhaps be something you could toggle on/off in the settings.



Don't know if this is a sensible request but it would help us out immensely in our work. Thanks again for the incredible work you do with OpenCPN!



Best,

Gustav

Great idea.

Could make planning longer routes also easier. One long route with multiple harbours. Add a stop time of x hours or days and see once you will arrive at final destination.

[Fuga]

I keep hoping that this would be addressed, but do not appear to have posted about it before.


When using the track feature, sometimes position data gets lost between the GPS in use (on the old Seatalk) via translation in NMEA I/F and serial port to PC. The effect is to show a diversion to the equator, greenwich, or some arbitrary location, and makes the display untidy. What it does to someone following a track can only be imagined.



If a short term history stack was used to save the last, or last few locations, a new position reading could be tested against the historical readings, and if more than the reasonable distance travelled * a factor of say 2 or so, the new incoming reading could be discarded, to await the next.

[Antipole]

Originally Posted by Fuga

When using the track feature, sometimes position data gets lost between the GPS in use (on the old Seatalk) via translation in NMEA I/F and serial port to PC. The effect is to show a diversion to the equator, greenwich, or some arbitrary location, and makes the display untidy. What it does to someone following a track can only be imagined.

If a short term history stack was used to save the last, or last few locations, a new position reading could be tested against the historical readings, and if more than the reasonable distance travelled * a factor of say 2 or so, the new incoming reading could be discarded, to await the next.

You could do this using the JavaScript plugin.

Write a script that reads through the tracks in question examining the distance between successive points. If the distance is more than what is acceptable, or its position is unreasonable, delete that point. Once a track as been filtered, update the copy in OpenCPN or, more safely, add a filtered track and delete the old one if all looks good.

[Fuga]

Originally Posted by Antipole

You could do this using the JavaScript plugin.

Write a script that reads through the tracks in question examining the distance between successive points. If the distance is more than what is acceptable, or its position is unreasonable, delete that point. Once a track as been filtered, update the copy in OpenCPN or, more safely, add a filtered track and delete the old one if all looks good.

That is beyond my current pay grade, I am afraid - my limit is C++ and it is a while since I used that. Logically, the best place to do this is when the position is first input to the track generation routine - then the display of the track does not get mucked up.



But thanks. I do not save my tracks, but tend to use them as in indication of tidal effects, etc. over time.

[wholybee]

Originally Posted by Fuga

I keep hoping that this would be addressed, but do not appear to have posted about it before.


When using the track feature, sometimes position data gets lost between the GPS in use (on the old Seatalk) via translation in NMEA I/F and serial port to PC. The effect is to show a diversion to the equator, greenwich, or some arbitrary location, and makes the display untidy. What it does to someone following a track can only be imagined.



If a short term history stack was used to save the last, or last few locations, a new position reading could be tested against the historical readings, and if more than the reasonable distance travelled * a factor of say 2 or so, the new incoming reading could be discarded, to await the next.

I have considered asking for this as well. It is fairly common on longer voyages that my GPS will reset at somepoint, and give positions of 0S , 0E while it is restarting. OpenCPN then plots a line to off the coast of Africa. When I am trying to keep the track or rely on it for some reason, want to track miles sailed, etc. it is quite difficult to sort that out.

I don't think "write it yourself" with a Javascript plugin is a very good answer. If it is so easy, incorporate it into the program so it addresses the issue with all users? I do realize that isn't an official answer from the developers, but it does come across a bit arrogant. The vast majority of users haven't the slightest idea how to write even a simple javascript, so it isn't at all helpful.

[rgleason]

Tracks generally have many points. Pavel wrote something to filter tracks points, I think it is in the process to convert a track to a route, adding an additional filter for wayward waypoints greater than 2xs the average speed might do this.

[bbalan]

Originally Posted by Fuga

I keep hoping that this would be addressed, but do not appear to have posted about it before.


When using the track feature, sometimes position data gets lost between the GPS in use (on the old Seatalk) via translation in NMEA I/F and serial port to PC. The effect is to show a diversion to the equator, greenwich, or some arbitrary location, and makes the display untidy. What it does to someone following a track can only be imagined.



If a short term history stack was used to save the last, or last few locations, a new position reading could be tested against the historical readings, and if more than the reasonable distance travelled * a factor of say 2 or so, the new incoming reading could be discarded, to await the next.

Absolutely agree. Would be awesome if OpenCPN threw away data that clearly is wrong. Thanks! Bruce

[bbalan]

COLOR CHANGE for ACTIVE ROUTE?


Maybe this can be done but would love to be able to change the default color of the active route.
Thanks,
Bruce

[bbalan]

Again, maybe you can do this and I don't know...


Would be nice to have an option to play a sound ("ding!") upon waypoint arrival in a route.
Thanks,
Bruce

[bdbcat]

Wholybee/bbalan...


The filtering of clearly bad points is implemented in upcoming version 5.8.
FYI, it was implemented for O562, but contained a minor bug rendering it useless. Fixed now.



Thanks
Dave

[ChrisJHC]

Wouldn’t mind the ability to change the order of the columns in a route table.

Alternatively, move the “Heading” column so that it’s next to the “Distance” column.

[bbalan]

Originally Posted by bdbcat

Wholybee/bbalan...


The filtering of clearly bad points is implemented in upcoming version 5.8.
FYI, it was implemented for O562, but contained a minor bug rendering it useless. Fixed now.



Thanks
Dave

Awesome. Thank you, Dave.
B

[wholybee]

Originally Posted by bdbcat

Wholybee/bbalan...


The filtering of clearly bad points is implemented in upcoming version 5.8.
FYI, it was implemented for O562, but contained a minor bug rendering it useless. Fixed now.



Thanks
Dave

Thank you.