Error in OpenCPN 4.6.1

[Fernando Lopes]

Please see anex
Windows Version VISTA

[Moo]

Originally Posted by Fernando Lopes

Please see anex
Windows Version VISTA

I see similar stuff with imported tracks. But I find that when I run "Reduce data" on a track the length gets corrected.

Often this generates false track points on the screen resulting in a fan of false legs radiating from the origin of the track. Splitting the track a point one often fixes this (I delete the 0 distance remnant); or closing O and reopening cleans it up.

[Fernando Lopes]

I do not know how run "Reduce data" on one track.

[Moo]

Originally Posted by Fernando Lopes

I do not know how run "Reduce data" on one track.

Right click on the track, click "Reduce Data"

I presume these are imported tracks?

[transmitterdan]

Originally Posted by Fernando Lopes

Please see anex

Windows Version VISTA

Fernando,

If you have imported the route from a .gpx file please post that file (rename it .doc). I will try to find the bug.

[Fernando Lopes]

Originally Posted by Moo

Right click on the track, click "Reduce Data"

I presume these are imported tracks?

Thanks for your answer. But … I return to the 4.4.0 version of the OpenCPN.
I have 2 computers running the OpenCPN:
On board, I have one economical Intel Phoenix running Windows 10 Pro that not use many batteries resources.
At home I have one powerful HP Pavilion machine running Windows Vista Home Premium.
The onboard machine is connected to the Data Bus of the boat that have one poor GPS device. But, simultaneously I collect the navigation data with one Garmin GPS Nuvi 2545. This data is discharged to my home computer for posterior analyze.
All this work fine in the 4.4.0 version of the OpenCPN, but appears some errors in the home version 4.6.0 and 4.6.1 of the OpenCPN. Your turn around procedure works, but is not user-friendly. So, I wait for one new release of the OpenCPN that works well with the Garmin imported data.
I annex one example of the Garmin data imported to my home PC.

[Fernando Lopes]

Originally Posted by transmitterdan

Fernando,

If you have imported the route from a .gpx file please post that file (rename it .doc). I will try to find the bug.

Thanks for your answer. But … I return to the 4.4.0 version of the OpenCPN.
I have 2 computers running the OpenCPN:
On board, I have one economical Intel Phoenix running Windows 10 Pro that not use many batteries resources.
At home I have one powerful HP Pavilion machine running Windows Vista Home Premium.
The onboard machine is connected to the Data Bus of the boat that have one poor GPS device. But, simultaneously I collect the navigation data with one Garmin GPS Nuvi 2545. This data is discharged to my home computer for posterior analyze.
All this work fine in the 4.4.0 version of the OpenCPN, but appears some errors in the home version 4.6.0 and 4.6.1 of the OpenCPN. Your turn around procedure works, but is not user-friendly. So, I wait for one new release of the OpenCPN that works well with the Garmin imported data.
I annex one example of the Garmin data imported to my home PC with DOC extention (original extention whas GPX).

[transmitterdan]

Fernando,

I confirm that the error in 4.6.1 is caused by the track data having points very close together. In 4.4.0 this did not cause any problem but some changes have occurred since 4.4.0 that result in a divide by zero error which causes the Nan message. This happens only when tracks contain points that are very close together with exactly the same latitude. I have not determined exactly when or what change since 4.4.0 caused the problem.

[bdbcat]

TDan...

Probably track.cpp : 966.

Dave

[transmitterdan]

Originally Posted by bdbcat

TDan...

Probably track.cpp : 966.

Dave

Yes, but it seems a bit more complicated than that. I can make the Nan go away easily by changing that line in Track.cpp (offset equal latitudes by 5e-6).

In 4.4.0 a track was drawn as a line. But in 4.6.1 there seem to be two kinds of lines drawn. See attached screen shot for Fernando's track file displayed in 4.6.1 after making line 966 look like this:

double dd = DistGreatCircle( fabs( l->m_lat - t->m_lat ) < 5e-6 ? l->m_lat + 5e-6 : l->m_lat , l->m_lon, t->m_lat, t->m_lon );

So no more Nan issue but...

It seems that importing a track file does not go through the same washing-machine cycle as a track created from ownship during a voyage. Fernando is worried I believe because he sees these yellow markers covering up the track line.

[transmitterdan]

Dave,

I will submit a PR on the Nan issue soon.

Dan