OpenCPN Beta Version 3.3.2107 Released

[NahanniV]

Originally Posted by nohal

Nahanni...
It is obvious. Your version of Navigatrix is based on Ubuntu 13.04 (Raring), which is past it's end of life, not supported anymore by Canonical, so we can't build packages for it on Launchpad and the latest available is 3.3.1303.

Solution should be: Edit the file /etc/apt/sources.list.d/nohal-opencpn-raring.list (will have to do it as root, I just guess the filename, but should sure start with "nohal-opencpn")
and change the two lines that should look like

deb http://ppa.launchpad.net/nohal/opencpn/ubuntu raring main
deb-src http://ppa.launchpad.net/nohal/opencpn/ubuntu raring main

to

deb http://ppa.launchpad.net/nohal/opencpn/ubuntu precise main
deb-src http://ppa.launchpad.net/nohal/opencpn/ubuntu precise main

Then the normal sudo apt-get update etc. should do.

The big question is why the Navigatrix guys based their release on a non-LTS Ubuntu base. IMHO it is at least unfortunate...

Pavel

Thanks, that worked.

Hopefully they will update Navagatrix it is a very useful distribution.

Cheers,
JM.

[bcn]

Originally Posted by bdbcat

bcn...

OK, the shot you posted shows an issue with S63 overzoom. I see the trouble there, and will require a new S63_PI to fix fully. Current S63_PI does not allow quite as much overzoom as native S57 ENC.

Anyone NOT seeing overzoom indicator with other than S63 charts?

Dave

On Linux 32bit / S63-PI 0.9 and S63 we have no problem - big OVERZOOM as expected...

[Baikal]

Originally Posted by bdbcat

Baikal...

Attached is screenshot of overzoom at Irkutsk.

Not working for you?

Thanks
Dave

completely reinstalled opencpn
installed the latest build charts
overzoom is not displayed in any charts
including NOAA charts

[Baikal]

I really like how now working cell mapping charts
Great work!

[Baikal]

created build of last revisions
overzoom as before, not displayed

3.3.2118 Windows https://www.dropbox.com/s/g92c613e6m...encpn.exe?dl=0

[bcn]

3.3.2118 from OpenCPN.org
Win 8.1 S63 0.9
Overzoom now ok and correctly displayed

[BMD21]

I was up in Canada a couple of weeks ago, trying to use opencpn_3.3.1931. I had a heck of a time trying to get the tracking function to work. I checked "Automatic Daily Tracking" and the "Toggle Tracking" functions in all combinations I could think of and it would track intermittently. Finally quit tracking in the middle of a trip.

Any comments?

BTW, the radar function worked well with my Lowrance 3G, though I had problems trying to get the display up on the Lowrance MFD. The only comment the Lowrance customer support had was to check the power.

Boris

[PjotrC]

Originally Posted by BMD21

I checked "Automatic Daily Tracking" and the "Toggle Tracking" functions in all combinations I could think of and it would track intermittently.

Indeed, I think there is a problem with rendering disjoint tracks in the Beta, which might be involved here.

However, please note that if one toggles tracking off and on and off and on, the track will be non-contiguous and this is the desired behaviour.

The visible problem with the Beta - I think - is rendering of the track on chart. I made a quick test now, and the tracking did look incorrect in 3.3.2107, but when I quit the Beta and started up 3.2.2 all was recorded and shown as I would expect (i.e. also the part recorded by 3.3.2107).

I did use Automatic Daily Tracks in 3.2.2 underway recently and I think it did what it should.

One thing that may interfere with ADT is the "lazy recording" strategy, which optimizes the number of trackpoints stored. I think this mechanism was not in place at time of ADT implementation.

In 3.3.2107 I also see a delay in toggling the status indication on the tracking icon, which sometimes may be misleading to the user.

I am also not happy with the naming method for the tracks. The daily track ending at midnight effectively gets the name of the following day, because the midnight trackpoint is recorded on the new date... some manual discipline in prompt track naming is therefore necessary to maintain nice order.

-

[nohal]

Pjotr...
I believe I have fixed the segmented tracks rendering in https://github.com/OpenCPN/OpenCPN/c...c4afd15f234a22 and also improved the rendering of segments crossing the IDL in the later commits. Please check with 3.3.2118...

Pavel

Originally Posted by PjotrC

Indeed, I think there is a problem with rendering disjoint tracks in the Beta, which might be involved here.

However, please note that if one toggles tracking off and on and off and on, the track will be non-contiguous and this is the desired behaviour.

The visible problem with the Beta - I think - is rendering of the track on chart. I made a quick test now, and the tracking did look incorrect in 3.3.2107, but when I quit the Beta and started up 3.2.2 all was recorded and shown as I would expect (i.e. also the part recorded by 3.3.2107).

I did use Automatic Daily Tracks in 3.2.2 underway recently and I think it did what it should.

One thing that may interfere with ADT is the "lazy recording" strategy, which optimizes the number of trackpoints stored. I think this mechanism was not in place at time of ADT implementation.

In 3.3.2107 I also see a delay in toggling the status indication on the tracking icon, which sometimes may be misleading to the user.

I am also not happy with the naming method for the tracks. The daily track ending at midnight effectively gets the name of the following day, because the midnight trackpoint is recorded on the new date... some manual discipline in prompt track naming is therefore necessary to maintain nice order.

-

[PjotrC]

Originally Posted by nohal

I believe I have fixed the segmented tracks rendering .. Please check with 3.3.2118...

Pavel,

Thanks for the information - and for the corrections, of course... I managed to set up the test before midnight, and all looks good. Looks like the track naming is also improved, although a full test requires more than one midnight in a row... better done on a passage.

Thanks again,

Piotr

[nohal]

Well, I did nothing with the naming, so would perhaps attribute it to pure luck

[BMD21]

Thanks for the prompt reply. However, after 2 mos on a 25' boat, it'll be a few weeks (52?) before we're traveling again.

What's impressive is that this comment got a reply within a few hours. For open source software. And Lowrance, who charges money asks" "did you check for power?" after I tell them I can see the ethernet signal. I guess both were IQ tests, one pass, one fail.

Boris