Beta Test / Technical

[cagney]

Originally Posted by nohal

Source builders,
I finally got some time to have a look at the regressions in navobject management and GPX handling discovered since the 2.3 release.
The patch with some brief list of problems that it should fix is posted in flyspray as FS#349 : GPX and navobject management regressions
If you have some time, please try to test it a little bit as all I have here are very artificial data. Builds and runs on Windows, didn't have time and CPU cycles to build on Linux yet.

Thanks

Pavel

Pavel
Your patches compiles on Linux, and seems to work OK. I have briefly tested the different scenarios in #244, 324, 327 and 343.
More testing later.

Thomas

[Sailing Hanse37]

Can the crash be video-card dependent ... ?
As you guess, i'm not inventing this crash

[PjotrC]

OpenCPN routine for converting lat/long to text format for display has two variants:

- low precision gives DD MM.MMMM (4 fractional digits for minutes)
- high precision gives DD MM.MMMMMM (6 fractional digits for minutes)

In current code the high precision is never used.

A quick check tells me that:

- DD MM.MMMM gives 18.6 cm accuracy (at 0 latitude, less elsewhere)
- DD MM.MMMMMM gives 1.86 mm accuracy

probably *sqrt(2) or something like that ...

In day-to-day navigation I think at most DD MM.M format is used.
My GPS sends DD MM.MMMM over NMEA and displays DD MM.MMM max.

I use max (3) digits only for anchor watch, for waypoints I try to minimize typing, so usually put them on whole minutes.

I think lots of digits on the screen is tiring to look at... so maybe:

- low precision display should be DD MM.M
- high precision display should be DD MM.MMMM

Highest precision can be computed and recorded and drawn (e.g. in tracks), but needs not be displayed always in so many digits...

Is the 6-digit format worth keeping?
Is the 4-digit format worth displaying so often?

P.

[dougwm10]

Hi to the DEVELOPERS

Can anyone give a date estimated or factual when we avid OpenCPN users can expect the release of the 2.4 Beta

[cagney]

Originally Posted by dougwm10

Hi to the DEVELOPERS

Can anyone give a date estimated or factual when we avid OpenCPN users can expect the release of the 2.4 Beta

I'm not a developer, more like a baby sitter for the project, while Dave is far away from a decent WiFi connection..

It is reasonable to expect a new beta late this month or early next month.

Thomas

[John Slduer]

OSX version 2.4 wx 2.9 Build has MANY bugs

Once an extra window is open it freezes?

How can I help?

[nohal]

John...
The Mac guys working on improving the OSX support were recently talking at SourceForge.net: Topic: OpenCPN for Mac developers discussion
Most of the work is currently done by PatG - his code is at https://github.com/patg You should probably talk to him.

Pavel

[CarCode]

Originally Posted by John Slduer

OSX version 2.4 wx 2.9 Build has MANY bugs
Once an extra window is open it freezes?
How can I help?

Mac version is still in beta status and each some days a new version with less bugs is out. When do you have downloaded your version and where from? Actually the properties window of route manager still freezes the app. So do not use it at the moment. Because it is not sure if some bugs results from older files left on the machine from earlier installs, the new installer deletes all old config files during a new install of the actual version.

It will be nice also to have a detailled bug report.

Gerhard

[HamishB]

Originally Posted by PjotrC

Highest precision can be computed and recorded and drawn (e.g. in tracks), but needs not be displayed always in so many digits...

Is the 6-digit format worth keeping?
Is the 4-digit format worth displaying so often?

yes & yes, please.

6-digit arc-minute: On our research ship we use RTK survey grade GPS which gives position to 2mm. This is recorded at 10Hz so we can filter out and quantify instantaneous heave, pitch, and roll, so our sea floor mapping and current speed measurements are not affected by the roll of the boat and sea state so much.

4-digit arc-minute: this preserves standard consumer grade D-GPS signal at full precision.
we use this to record sample sites, dropped gear, etc. Meters count when you have to send a diver back to find it six months later!

please don't throw away precision, it is useful to some of us.

Perhaps what you wish for is a third "low clutter" precision option?

thanks,
Hamish

[HamishB]

Originally Posted by dougwm10

Can anyone give a date estimated or factual when we avid OpenCPN users can expect the release of the 2.4 Beta

the classic answer to this: "When it's ready. Sooner if you help."

[PjotrC]

Originally Posted by HamishB

Perhaps what you wish for is a third "low clutter" precision option?

Thanks for replying, I was just wondering...

Are you using the same code base? The recording and display should not be changed in current OCPN, except for Route Properties. I did not find any call to the 6-digit display/printout in the code, that's why I asked ...

Piotr

[HamishB]

Originally Posted by PjotrC

Are you using the same code base? The recording and display should not be changed in current OCPN, except for Route Properties. I did not find any call to the 6-digit display/printout in the code, that's why I asked ...

I'm not sure of what's in the current git code or currently user-visible. Check the bug/wish tracker for an item about a month or so ago which added the high-precision code. I think there was my patch, bdbcat's improved commit, then another minor bugfix patch from me.
I'd have to look at that to refresh my memory.

Are you concerned about too-much irrelevant info in the bottom status bar "Cursor: lat lon" (I see %02.4f)? or in the dashboard pos? (which for me looks like %02.3f right now)

IMHO the distance calcs, waypoint properties editor, ship's track and GPX export should always work at full precision (but no point reporting to the nanometer); the choose-your-level-of-visual-detail could be user-settable.


Hamish

[PjotrC]

Originally Posted by HamishB

Are you concerned about too-much irrelevant info in the bottom status bar "Cursor: lat lon" (I see %02.4f)? or in the dashboard pos? (which for me looks like %02.3f right now)

IMHO the distance calcs, waypoint properties editor, ship's track and GPX export should always work at full precision (but no point reporting to the nanometer); the choose-your-level-of-visual-detail could be user-settable.

Of course, all internal operation should be carried out at full precision...

It would be nice if all at-a-glance displays (status line, routepoint list) would show as few digits as practical (i.e. "dd mm.m"), but high precision should be always available at a click, in Properties Dialogs: AIS Target, Mark/Waypoint.

The Cursor position precision in the status line might be matched to zoom level.

However, there is no corresponding "Ships Properties" dialog, so really no place to go to for high precision data on current lat-lon. There were a few requests for "Ships Data" dialog (GPS offsets, hull dimensions etc), but until this is eventually provided looks like it must be the high precision here. Not everyone does use the Dashboard.

GPX works in different format anyhow - "dd.ddddddddd" (no minutes-of-arc).
opencpn.log - LOGBOOK: "dd.ddddd" (i.e. <1 mtr), starting position and MOB: "dd.dddd" (i.e. <10 mtr)

BTW, it would be nice if this format could be pasted into WP Properties as well.

I did not try yet the logbook plugin.

In 2.4.423, as before, all calls to "toSDMM()" are made with default precision, except in RouteProp, where I require low precision now. Default precision was and is "dd mm.mmmm"

It looks like for the 2mm requirement three formats would have to be supported, if minutes-of-arc are to be displayed. Would it be sufficient to support this for Mark Properties only or perhaps adopt the GPX format for ultra precision output?

Most nav software allow configuring the preferences for coordinate formats (decimal degrees or degrees+minutes).

Piotr

[NAV]

Originally Posted by HamishB

6-digit arc-minute: On our research ship we use RTK survey grade GPS which gives position to 2mm.

But I suppose you use professional software for survey tasks, isn't it? I can't imagine you use OpenCPN for survey work.

[HamishB]

Originally Posted by NAV

But I suppose you use professional software for survey tasks, isn't it? I can't imagine you use OpenCPN for survey work.

Why not? The challenge is to write software which leaves possibilities open for others who are not limited by our finite imaginations. :-)

It is no fun to get out there and have the thing break with no way to fix it, calls on the satphone to 5 timezones away to debug the dongle /every bloody time/ etc. I'm over it. OpenCPN is not the primary/only means of navigation on the bridge, and typically wouldn't be hooked up to the 10Hz 3D attitude feed*, but it sure is nice to have the flexibility there and is sufficient for many tasks, including those on land where the precision gains are more obvious.
[*] although in a pinch I have connected it to the 10Hz trimble RTK feed, thanks to the 38400 baud input option.

IIRC the patch started out in an effort to not degrade the precision of GPX, wpt input/output, and also to not degrade the internal positioning which led to noticeable track staircasing, even with 1m DGPS. I've never argued that 2mm precision should be the default displayed (that should be MM.MMMM ;-) only that the software should not degrade that precision if available.

btw, if you are interested in such things check out YoNav II from the USGS.
http://walrus.wr.usgs.gov/marfac/YonavSoftware.html
http://schwehr.org/blog/archives/2009-05.html#e2009-05-21T13_25_44.txt


Hamish