OpenCPN Beta Build 2.6.1210

[bdbcat]

HamishB...

The patch for GPSD V 2.96 in Flyspray #595 works fine for GPSD 2.96. It does not support previous versions of GPSD.

The Beta 2.6.1210 should support pre- and post- 2.96, although we may still have problems.

Dave

[bdbcat]

cagney....

Please check your log. There should now be some more informative messages regarding GPSD library API selection.

Thanks
Dave

[bdbcat]

Nohal...

I need more info on FS#604. The images in Flyspray are not accessible.

Thanks
Dave

[teotwawki]

Originally Posted by bdbcat

cagney....

Please check your log. There should now be some more informative messages regarding GPSD library API selection.

Thanks
Dave

I'm seeing the same issue with libgpsd on Fedora 16, which uses GPSD 2.95 (libgps.so.19). The issue seems to be in the API selection logic in nmea.cpp; according to the log opencpn is using API=20, but I think 19 is appropriate for 2.95 As a quick test I changed nmea.cpp to force the API version to 19 -- the error dialog does not appear and gps looks to be functioning correctly

[cagney]

Originally Posted by bdbcat

cagney....

Please check your log. There should now be some more informative messages regarding GPSD library API selection.

Thanks
Dave

There are two lines in the log written when the error message pops up.
This happens as the data source is picked as "Network LIBGPS"

17:16:32 CET: NMEA Data Source is....LIBGPS:localhost
17:16:32 CET: LIBGPS: Using libgps API=20

The only thing in the log that mentions gpsd is

11:27:34 CET: NMEA Data Source is....GPSD:localhost

Which comes from testing Network GPSD as a data source.

Thomas

[cagney]

Originally Posted by bdbcat

Thomas....
Any sign of Peru? I never really found a smoking gun for this one.....

Dave

Dave
Not so far. I have tried though.
Last time it took a couple of days before I could recreate the problem.
Meanwhile, I'm keeping my fingers crossed that it was a side effect of the resource problem.
Thomas

[PjotrC]

Originally Posted by cagney

What about using Ctrl + M as a dedicated anchor mark??

Carryover from previous thread...

Thomas...

I do not think that the Anchor Watch deserves coding / testing / documenting / remembering another keyboard shortcut.

As much as I would always like to drop a mark the instant the anchor goes down, in practice (unless seriously overcrewed) it never happens. There's simply too much to do up on deck - test the holding, watch the transits, watch the neighbouring boats... the need to reanchor is always a possibility... so the Anchor Alarm is only set after all this is done, and the sundowner / nightcap (or whatever the time of day happens to be) drinks are served.

No need to have a quick mode of doing that.

In practice, alas, I always estimate the anchor position from the track plot and some guessing (more if using OpenCPN, less if using MaxSea).

Having said that, 2.6.x brings in some new issues...

1. The 2.6.1012 Anchor Alarm circle seems to be blank filled now, obscuring the anchor watch mark (should be transparent, as in 2.5.0 example - last attachement).

2. The 2.6.x track display at medium scale cleverly shows the history of path crossings (the later one comes on top), but at large scale is hardly useful at all...

I consider a detailed track plot to be much more effective tool for safe anchoring than the Anchorwatch, which is the last-resort safeguard. I attach again a plot from MaxSea, where one can at a glance see how the anchor did hold over past hours - every gust of wind, tensioning of the chain, turn of the tide is clearly visible. All what is needed is the ability to change the plot colour now and then...

Piotr

[Rik-lu]

Not important and not fixed since some versions:
the image query window cannot be closed with the X on upper right but only with the OK button.
I 'm so used to close with the X-button....

[sailorF54]

Originally Posted by Rik-lu

I 'm so used to close with the X-button....

I'm quite proud of the fact that I remember to hit the OK button instead of the upper X on about half of the occasions...
A power user, I am set to become...

[nohal]

Originally Posted by bdbcat

Nohal...

I need more info on FS#604. The images in Flyspray are not accessible.

Thanks
Dave

Dave...
Added a new set of imagery to the ticket, including a reference rendering from SeeMyENC.
Just in case - the charts themselves are at doris.bmvit: Inland ECDIS Standard 2.0

Pavel

[bdbcat]

PjotrC....

The opaque circle is a bug, introduced with OpenGL...
On the list, though it never made FlySpray.....

Your large scale tracks may be more useful with an adjustment to smaller values value on the Toolbox->Etc->Tracks parameters.

Maybe it would be better to eliminate the yellow highlighting. This was/is meant to show a 20m width, arbitrarily chosen and fixed in the code. The idea of the highlighting was to remind us that following a previous track exposes us to the inherent inaccuracy of GPS, and that the real track followed is most likely within the highlight region, but not necessarily in the middle. And this says nothing about the accuracy of the underlying cartography.

Comments?
Dave

[ktcanuck]

There seems to be a recurrence of an earlier issue whereby Polyconic charts (eg, St Lawrence River) and routes do not render properly. Upgrading to the latest beta positions the route incorrectly by a large margin.

[bdbcat]

ktcanuck....

Hmmmm..... Still works for me in St Lawrence with say 14773_1.KAP (Gananoque), for example.

Could we see some examples (lat/lon, chart, pictures)?

Thanks
Dave

[ktcanuck]

In making up a before and after pair of images, I unchecked "show skewed raster charts as north-up" with "enable chart quilting" off and the chart displays fine with the route. With either of those conditions selected the route is not shown correctly. The chart in use was NOAA 14772_1, a polyconic projection.

I recall when I raised this some months ago someone found there was an error present with the NOAA raster chart meta data. Unchecking "enable chart quilting" fixed the issue. I sent a note to the folks at NOAA but I cannot determine if they ever corrected the fault. It exists with the sequence of polyconic charts for the St Lawrence.

The difference between Open CPN 2.5.0 and 2.6.1210 is that with the latter I have to also uncheck "show skewed raster charts as north-up" as well as "enable chart quilting" to make the route overlay properly. I can still post pictures if you want but you should be able to re-create this now I think. Let me know if you need images.

Thanks

Keith

[ktcanuck]

I made the images so I will post them anyway...

First is 2.5.0. Second is 2.6.1210 immediately after installing with no changes to settings: