Feature Requests

[Hakan]

All..
Please help me....:
I got a question about any function to save sounding data for example at the own track data points. Or a plugin having a similar function.
I believe this has been discussed before. And that there is a method.
Anyone remember better than me?
Thanks
Håkan

[nohal]

Hakan...
Some options do already exist:
VDR plugin

Survey plugin (I kind of abandoned it for lack of time and interest, but think Rasbats did some more work on it)

There is nothing that would allow storing it with the track, as it exists in the core program, at the moment (And if such a feature request has to be created, we have to keep on mind that the tracks may get simplified so the trackpoint position is not the actual boat position)

Pavel

[Hakan]

Nohal..
Thanks.
VDR I know but it's not really feasible for the requested purpose.
The Survey plugin I know very little about. I'll have check.
Håkan

[Jon Hacking]

Originally Posted by Hakan

... any function to save sounding data for example at the own track data points...

This is something I've wanted for some time. MaxSea's .PTF track format saves most sensor data, including depths, & I've found it useful several times. Since .GPX is basically XML, I was hoping it could be extended to include depths (& possibly other data, but depths are most important). We publish our tracks & I know others use them, so letting them show depths would be very useful to someone following our tracks. TIA!

[transmitterdan]

A common concern about crowd sourced bathymetric data is there is no uniform standard for defining tide levels when the depth data is captured. Neither is there any standard to define the depth of the transducer and the offset applied to the raw data. So it becomes a real challenge to control the integrity of the data when moved from one platform to another platform.

These issues do not plague position data.

[Jon Hacking]

Dan, I agree. One possible solution is to register your boat, so the database server knows who posted the data. This registration info could also include xducer depth. The collected data being sent would need to include depth & position, but including time with that data would allow the database server to remove tide components, leaving normalized depth data.

[rgleason]

We really should be able to easily copy and paste lat/long from one place to another without having to worry about format (dec.degrees, degree & dec.min, or deg,min,sec)!

This is currently possible within Opencpn but not so with plugins. This problem has lead to the incorrect declaration that SAR_pi is dangerous when the wrong format copied from a waypoint was used.

I would submit that the plugin is dangerous because it does not "know" wbat format the main program is using from the setting Options > Display > Units Tab > Lat/long setting.

I believe we should have a new Plugin API addition which informs all plugins what format all Lat/Long is to be in, when copied, maybe even when shown.

This value would be used for many plugins, SAR, Weather_routing, Tactics, Route, Cel_nav, Ocpn_draw, Watchdog, vfkaps

Additionally, there should be a standard code snippet for plugins to achieve this interoperability.

[skipperearly]

Originally Posted by rgleason

We really should be able to easily copy and paste lat/long from one place to another without having to worry about format (dec.degrees, degree & dec.min, or deg,min,sec)!

This is currently possible within Opencpn but not so with plugins. This problem has lead to the incorrect declaration that SAR_pi is dangerous when the wrong format copied from a waypoint was used.

I would submit that the plugin is dangerous because it does not "know" wbat format the main program is using from the setting Options > Display > Units Tab > Lat/long setting.

I believe we should have a new Plugin API addition which informs all plugins what format all Lat/Long is to be in, when copied, maybe even when shown.

This value would be used for many plugins, SAR, Weather_routing, Tactics, Route, Cel_nav, Ocpn_draw, Watchdog, vfkaps

Additionally, there should be a standard code snippet for plugins to achieve this interoperability.

TOTALLY AGREE! Interoperability with/between the pi's is generally a weak point. Last example waypoints in weatherrouting_pi have no N/S or E/W and dont recognize the waypoints already available in ocpn.

[rgleason]

RE Copy L/L waypoint interoperability FYI

FS#2342 - API 1.15 Lat/Long Format for waypoint copy/paste Interoperability

FS#2110 - Conversion error. Dangerous result!
This problem is due to user error, but should be fixed. It should not happen, particularly with SAR plugin.

[Rasbats]

It could be useful to add to the plugin API to allow retrieval of PICREP as well as OBJNAM from S57 ENC.

Similar to:
virtual void SendVectorChartObjectInfo(wxString &chart, wxString &feature, wxString &objname, double lat, double lon, double scale, int nativescale);

Above from 'ocpn_plugin.h' API 112.

Both U.S. and European Inland ENC have useful .JPG images which add to pilotage information.

'Objsearch_pi' could be extended to add PICREP to the database and allow a link for displaying the .JPG.

Intend adding this request to Flyspray.

Mike

[Moo]

Originally Posted by nohal

Unfortunately OpenCPN is not a text editor, where the undo actions behaviour is clear - revert changes to one widget containing text, but a collection of very different functions, often having nothing to do with each other. With the plugins, which are very independent in what they do, even more complicated.
So yes, we will need that list and we will need to go through it item by item to asses whether we really need that type of undo and whether there is someone willing to implement it. It honestly never even came to my mind that I would want it for a pan or zoom of the map for example (And probably have never seen a mapping application with such a functionality, including Apple's own Maps.app)


It si hard(ish), not impossible. The questions for a lot of things are "Is it needed?" and "Is it worth the effort?"

Pavel

I would really like to see an undo feature for function like deleting waypoints or track sections which I have done accidentally often enough!

[cagney]

Originally Posted by Moo

I would really like to see an undo feature for function like deleting waypoints or track sections which I have done accidentally often enough!

It's already there to help you.
Right click -> Undo delete waypoint or Ctrl+Z

For tracks and routes tick the box:Options->Display->Advanced->Controls->Confirm deletion of tracks and routes

Thomas

[Moo]

Originally Posted by cagney

It's already there to help you.
Right click -> Undo delete waypoint or Ctrl+Z

For tracks and routes tick the box:Options->Display->Advanced->Controls->Confirm deletion of tracks and routes

Thomas

You know I thought it should be. But noted that it wasn't working when I was on my boat last weekend and working with some tracks.

Just tried on my laptop and it works with waypoints but it doesn't work with tracks, no right click option and nothing happens with CTRL+Z

OCPN 4.8.2 on Windows 10

Cheers
Chris

[cagney]

Originally Posted by Moo

You know I thought it should be. But noted that it wasn't working when I was on my boat last weekend and working with some tracks.

Just tried on my laptop and it works with waypoints but it doesn't work with tracks, no right click option and nothing happens with CTRL+Z

OCPN 4.8.2 on Windows 10

Cheers
Chris

Please read my post again. The user protection against mistakes is not the same in the two cases.

For tracks and routes tick the box:Options->Display->Advanced->Controls->Confirm deletion of tracks and routes

So if you by mistake delete a track, you will get a pop-up where you have to confirm the deletion, if the feature is activated.

Thomas

[rgleason]

Is there any need to have Routes and Tracks work the same? Seems to me it would be preferable. If so, what is the preferred way?