OpenCPN Version 5 Beta Release 4.99.1426

[Hakan]

- "Should we follow the global "Units" setting for range rings?" -



If default unit for range rings was kilometers I who use NM would have answered: Yes if possible! So those using an other unit than NM would probably also answer yes.
Håkan

[Gilletarom]

Hello,

Originally Posted by bdbcat

Rick...
Let us not widen the discussion here, but maybe elsewhere regarding potential Feature Requests to the present design.

The question here is:
"Should we follow the global "Units" setting for range rings?"
Dave

For me, yes. (if global units settings are choiced in "Options/Display/Units")

[did-g]

Originally Posted by bdbcat

did-g...


The display concept of MBTiles has been changed. Now, tile charts are rendered as "last stage" overlays on whatever base charts would be normally rendered. We do it this way to accommodate various tilesets that are sparsely populated, allowing the base charts to appear where there is no corresponding tile.


As mentioned before, we do not expect MBTiles to be used as primary navigation source, but rather as supplemental assists to safe navigation.


What world mbtiles chart are you testing?


Examples of "- when zooming in/out quilt selected charts list is very different vs without mbtiles.", please.


Dave

I'm not sure Stuff I got from the forum. the World mbtiles was more or less working before , some rendering glitches around 180E.

total 723M
-rw-r--r-- 1 didier didier 669M Feb 20 2018 World.mbtiles
-rw-rw-r-- 1 didier didier 54M Mar 4 07:32 ria.mbtiles

I can put them somewhere but I'd take some time, big files.


Example with quilt:
picture 1: raster scale 3.5 M selected, chart not overzoom , mbtiles claiming scale 2 M is displayed but not highlighted in the piano.


picture 2: select mbtible same viewpoint, raster 3.5 M is not displayed but a 10M is, it's the one at the bottom.

[stelian]

Pavel, and others...

Originally Posted by nohal

Stelian...
When we have you around, can you have a look if the current recommended gdk_screen_get_width_mm replacements from https://developer.gnome.org/gdk3/stable/GdkMonitor.html work any better? I have no physical Linux machine, so my tests are completely useless...

While trying to look at the code, I noticed that my opencpn is compiled against GTK2 (it's historic, the last time I've run cmake it was on an older version of Ubuntu which didn't support wxwidgets + gtk3).

GdkMonitor isn't supported on gtk2, so the only output I can give is:
(cmake -DOCPN_FORCE_GTK3=0)
gdk_screen_get_width_mm = 847
gdk_screen_get_monitor_width_mm = 290

I have now configured opencpn to build agains gtk3 (cmake -DOCPN_FORCE_GTK3=1), and the results are quite good:

gdk_screen_get_width_mm = 290
gdk_screen_get_monitor_width_mm = 290
gdk_display_get_n_monitors = 1
gdk_monitor_get_width_mm(gdk_display_get_monitor(d , 0)) = 290

I suspect the function to be used is gdk_display_get_monitor_at_window() but I didn't bother to find the GdkWindow to pass as parameter.

BUT, the new and bad thing is that opencpn crashes just a bit later, see the stack trace below:

Thread 1 "opencpn" received signal SIGSEGV, Segmentation fault.
0x00007ffff56adf29 in XQueryExtension () from /usr/lib/x86_64-linux-gnu/libX11.so.6
(gdb) bt
#0 0x00007ffff56adf29 in XQueryExtension () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#1 0x00007ffff0516862 in () at /usr/lib/x86_64-linux-gnu/libGLX.so.0
#2 0x00007ffff05128e5 in glXQueryVersion () at /usr/lib/x86_64-linux-gnu/libGLX.so.0
#3 0x00007ffff75a3ac5 in wxGLCanvasX11::GetGLXVersion() ()
at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#4 0x00007ffff75a4165 in wxGLCanvasX11::ConvertWXAttrsToGL(int const*, int*, unsigned long) ()
at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#5 0x00007ffff75a4998 in wxGLCanvasX11::InitXVisualInfo(int const*, __GLXFBConfigRec***, XVisualInfo**)
() at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#6 0x00007ffff75a5aa0 in wxGLCanvas::Create(wxWindow*, int, wxPoint const&, wxSize const&, long, wxString const&, int const*, wxPalette const&) () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#7 0x00007ffff75a5c43 in wxGLCanvas::wxGLCanvas(wxWindow*, int, int const*, wxPoint const&, wxSize const&, long, wxString const&, wxPalette const&) () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#8 0x0000555555a8a704 in glTestCanvas::glTestCanvas(wxWindow*)
(this=0x5555563ded10, parent=0x5555564f4090) at /usr/include/wx-3.0/wx/gdicmn.h:258
#9 0x0000555555a45488 in OCPNPlatform::BuildGLCaps(void*) (this=<optimized out>, pbuf=0x5555564ff0e0)
at /home/stelian/TMP/OpenCPN_stelian.git/src/OCPNPlatform.cpp:639
#10 0x0000555555a45acf in OCPNPlatform::IsGLCapable() (this=0x55555600fe00)
at /home/stelian/TMP/OpenCPN_stelian.git/src/OCPNPlatform.cpp:727
#11 0x0000555555a45ae9 in OCPNPlatform::Initialize_3() (this=<optimized out>)
at /home/stelian/TMP/OpenCPN_stelian.git/src/OCPNPlatform.cpp:586
#12 0x0000555555778204 in MyApp::OnInit() (this=0x555555f3fbf0)
at /home/stelian/TMP/OpenCPN_stelian.git/src/chart1.cpp:2114
#13 0x00007ffff5c49b3a in wxEntry(int&, wchar_t**) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#14 0x0000555555739498 in main(int, char**) (argc=<optimized out>, argv=<optimized out>)
at /home/stelian/TMP/OpenCPN_stelian.git/src/chart1.cpp:970

Something I can to about this ?

[bdbcat]

did-g....


This is new behaviour.
As implemented now, MBtiles display independent of base chart scale, but only if the displayed canvas scale is greater than 20x the declared tileset scale. In other words, we always show MBTiles if available, unless they would be so significantly underzoomed as to be useless.

To hide an MBTiles chart, right-click on piano key and "Hide".
Or set up groups....



Once again, OCPN considers MBTiles as supplemental info, not primary charts.


Dave

[did-g]

Originally Posted by bdbcat

did-g....



Once again, OCPN considers MBTiles as supplemental info, not primary charts.


Dave

Ok with this behavior, make a lot of sense but:
- in my picture 1 shouldn't the mbtile chart being highlighted in the piano? It's displayed.


- shouldn't picture 2 being like picture 1, ie currently clicking on the mbtile in the piano hides the chart below?

[stelian]

To continue about my Ubuntu + gtk3 crash, I tried with Xorg instead of Wayland.

It crashes again, but this time later (the main window is partially rendered):

Thread 1 "opencpn" received signal SIGSEGV, Segmentation fault.
0x00007ffff630e2bb in wxControlContainerBase::HasAnyFocusableChildren() const
() from /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
(gdb) bt
#0 0x00007ffff630e2bb in wxControlContainerBase::HasAnyFocusableChildren() const () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#1 0x00007ffff630e319 in wxControlContainerBase::UpdateCanFocusChildren() ()
at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#2 0x00007fffb64f0bc5 in wxNavigationEnabled<wxTopLevelWindow>::AddChild(wx WindowBase*) () at /usr/local/lib/opencpn/libocpn_draw_pi.so
#3 0x00007ffff6260a4d in wxWindow:oAddChild(wxWindow*) ()
at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#4 0x00007ffff62ddc2f in wxToolBar::Create(wxWindow*, int, wxPoint const&, wxSize const&, long, wxString const&) ()
at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#5 0x00007fffb65a01d6 in ODToolbarDialog::ODToolbarDialog(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long) ()
at /usr/local/lib/opencpn/libocpn_draw_pi.so
#6 0x00007fffb65a4e72 in ODToolbarImpl::ODToolbarImpl(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long) ()
at /usr/local/lib/opencpn/libocpn_draw_pi.so
#7 0x00007fffb64dceeb in ocpn_draw_pi::Init() ()
at /usr/local/lib/opencpn/libocpn_draw_pi.so
#8 0x00005555559b3093 in PlugInManager::LoadPlugInDirectory(wxString const&, bool, bool)
(this=0x55555644af80, plugin_dir=..., load_enabled=<optimized out>, b_enable_blackdialog=<optimized out>) at /usr/include/wx-3.0/wx/log.h:886
#9 0x00005555559b3405 in PlugInManager::LoadAllPlugIns(wxString const&, bool, bool)
(this=0x55555644af80, plugin_dir=..., load_enabled=true, b_enable_blackdialog=false)
at /home/stelian/TMP/OpenCPN_stelian.git/src/pluginmanager.cpp:407
#10 0x0000555555784583 in MyFrame::OnInitTimer(wxTimerEvent&) (this=0x55555643fed0, event=...)
at /home/stelian/TMP/OpenCPN_stelian.git/src/chart1.cpp:6657
#11 0x00007ffff5d3b4be in wxEvtHandler::ProcessEventIfMatchesId(wxEventTable EntryBase const&, wxEvtHandler*, wxEvent&) ()
at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#12 0x00007ffff5d3b5c3 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#13 0x00007ffff5d3b98b in wxEvtHandler::TryHereOnly(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#14 0x00007ffff5d3ba13 in wxEvtHandler::ProcessEventLocally(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#15 0x00007ffff5d3ba75 in wxEvtHandler::ProcessEvent(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#16 0x00007ffff5d3b7d7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#17 0x00007ffff5c9f661 in wxTimerImpl::SendEvent() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#18 0x00007ffff6254e91 in () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#19 0x00007ffff3c9d573 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007ffff3c9cae8 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007ffff3c9ced8 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007ffff3c9d1d2 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007ffff0e99df5 in gtk_main () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#24 0x00007ffff6242895 in wxGUIEventLoop:oRun() () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#25 0x00007ffff5bf7a93 in wxEventLoopBase::Run() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#26 0x00007ffff5bbf0a6 in wxAppConsoleBase::MainLoop() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#27 0x00007ffff5c49ae9 in wxEntry(int&, wchar_t**) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#28 0x0000555555739498 in main(int, char**) (argc=<optimized out>, argv=<optimized out>)
at /home/stelian/TMP/OpenCPN_stelian.git/src/chart1.cpp:970

After disabling ocpn-draw-pi, it crashes again:


#0 0x00007ffff63876db in wxImage::InitAlpha() () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#1 0x00007fffc01b63a8 in wmm_pi::SetPositionFix(PlugIn_Position_Fix&) (this=0x555559ee9bf0, pfix=...)
at /home/stelian/TMP/OpenCPN_stelian.git/plugins/wmm_pi/src/wmm_pi.cpp:595
#2 0x000055555599cde5 in PlugInManager::SendPositionFixToAllPlugIns(Generic PosDatEx*) (this=0x55555644aeb0, ppos=0x7fffffffc200)
at /usr/include/wx-3.0/wx/dynarray.h:837
#3 0x000055555577d2f7 in MyFrame::OnFrameTimer1(wxTimerEvent&) (this=0x555556440450, event=...)
at /home/stelian/TMP/OpenCPN_stelian.git/src/chart1.cpp:7093
#4 0x00007ffff5d3b4be in wxEvtHandler::ProcessEventIfMatchesId(wxEventTable EntryBase const&, wxEvtHandler*, wxEvent&) ()
at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#5 0x00007ffff5d3b5c3 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#6 0x00007ffff5d3b98b in wxEvtHandler::TryHereOnly(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#7 0x00007ffff5d3ba13 in wxEvtHandler::ProcessEventLocally(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#8 0x00007ffff5d3ba75 in wxEvtHandler::ProcessEvent(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#9 0x00007ffff5d3b7d7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#10 0x00007ffff5c9f661 in wxTimerImpl::SendEvent() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#11 0x00007ffff6254e91 in () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#12 0x00007ffff3c9d573 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff3c9cae8 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffff3c9ced8 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007ffff3c9d1d2 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007ffff0e99df5 in gtk_main () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#17 0x00007ffff6242895 in wxGUIEventLoop:oRun() () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#18 0x00007ffff5bf7a93 in wxEventLoopBase::Run() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#19 0x00007ffff5d127f3 in wxAppTraits::RunLoopUntilChildExit(wxExecuteData&, wxEventLoopBase&) ()
at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#20 0x00007ffff626c022 in wxGUIAppTraits::WaitForChild(wxExecuteData&) () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#21 0x00007ffff5d18f5c in wxExecute(char**, int, wxProcess*, wxExecuteEnv const*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#22 0x00007ffff5d19d99 in wxExecute(wxString const&, int, wxProcess*, wxExecuteEnv const*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#23 0x00007ffff5d43c5a in () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#24 0x00007fffba325b50 in IsDongleAvailable() () at /home/stelian/TMP/ocpn_pi/oesenc_pi.git/src/oesenc_pi.cpp:3719
#25 0x00007fffba32d340 in oesenc_pi::Init() (this=<optimized out>) at /home/stelian/TMP/ocpn_pi/oesenc_pi.git/src/oesenc_pi.cpp:684
#26 0x00005555559b3093 in PlugInManager::LoadPlugInDirectory(wxString const&, bool, bool)
(this=0x55555644aeb0, plugin_dir=..., load_enabled=<optimized out>, b_enable_blackdialog=<optimized out>)
at /usr/include/wx-3.0/wx/log.h:886
#27 0x00005555559b3405 in PlugInManager::LoadAllPlugIns(wxString const&, bool, bool)
(this=0x55555644aeb0, plugin_dir=..., load_enabled=true, b_enable_blackdialog=false)
#28 0x0000555555784583 in MyFrame::OnInitTimer(wxTimerEvent&) (this=0x555556440450, event=...)
at /home/stelian/TMP/OpenCPN_stelian.git/src/chart1.cpp:6657
#29 0x00007ffff5d3b4be in wxEvtHandler::ProcessEventIfMatchesId(wxEventTable EntryBase const&, wxEvtHandler*, wxEvent&) ()
at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#30 0x00007ffff5d3b5c3 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#31 0x00007ffff5d3b98b in wxEvtHandler::TryHereOnly(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#32 0x00007ffff5d3ba13 in wxEvtHandler::ProcessEventLocally(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#33 0x00007ffff5d3ba75 in wxEvtHandler::ProcessEvent(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#34 0x00007ffff5d3b7d7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#35 0x00007ffff5c9f661 in wxTimerImpl::SendEvent() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#36 0x00007ffff6254e91 in () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#37 0x00007ffff3c9d573 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#38 0x00007ffff3c9cae8 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#39 0x00007ffff3c9ced8 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#40 0x00007ffff3c9d1d2 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#41 0x00007ffff0e99df5 in gtk_main () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#42 0x00007ffff6242895 in wxGUIEventLoop:oRun() () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_core-3.0.so.0
#43 0x00007ffff5bf7a93 in wxEventLoopBase::Run() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#44 0x00007ffff5bbf0a6 in wxAppConsoleBase::MainLoop() () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#45 0x00007ffff5c49ae9 in wxEntry(int&, wchar_t**) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#46 0x0000555555739498 in main(int, char**) (argc=<optimized out>, argv=<optimized out>)
at /home/stelian/TMP/OpenCPN_stelian.git/src/chart1.cpp:970


Stelian.

[cagney]

Originally Posted by bdbcat

Rick...


Let us not widen the discussion here, but maybe elsewhere regarding potential Feature Requests to the present design.



The question here is:
"Should we follow the global "Units" setting for range rings?"


Dave

Dave

Yes I think so. Apart from avoiding the possible confusion with different units on the screen, there is also the issue of limiting range rings to only M and km. The global setting also contains Statue Miles and m. Surprising that no US-inland- user has complained...

-----

The current implementation has bugs as well. If you decide to keep it, there are some corrections needed. To illustrate....



I have set units to km with 1 km between the two range rings in Options-Ships-Routes/Points.
Global unit is set to meters, in this case. Then I create a new wpt and open properties. Look at "Distance". 1852m equal to 1 M, does not make any sense here. Either "Distance" is the distance between the range rings and should read 1000m (1 km) or it is the total distance to the outer ring and should read 2000m (2 km).

Thomas

[robertmfranklin]

Dave and Open CPN Team.

I am new to relatively new Cruisers Forum and brand new to Open CPN, so please re-direct me if I am in the wrong location for this question.

I have spent hours - no days - trying to get Open CPN working on my Macbook Pro. I don't think is is a CPN problem, but I can not seem to get my computer and/or the program to recognize my GPS antenna, which is a BU 353. I have done a lot of reading of comments on the Internet, but just am not getting anywhere. I know the 353 is good because I used it a long time ago for Sea Clear. Also, I have two of them and both seems to be blinking red as they should to indicate a signal has been received. I am indoors, but near a window.

The comments on line from others with the same lap top I have, (Mac running Siera 10.12.60 range from "impossible" to "I added a driver and works fine.

I have the BU 353 installation disc and my lap top will take a CD.

I am getting to the point where, at my hourly rate, I could buy the fancy GPS chart plotter. But that's no what I want to do. No fun in that.

I feel confident I can get past this problem, but right now I am stuck.

Thanks
Bob Franklin
Pearson 36-1 "Arion"
Boston, MA

[nohal]

Rob...

The driver is here: Products

Nice post with step by step instructions is here: Using BU-353 GPS Receiver with Newer MacOS - CONTINUOUSWAVE

I do not have the BU-353, but do have the Prolific driver on my system for other purposes and can't confirm any stability problems with it, yet I would definitely recommend another GPS with another USB interface chip for use with any OS, especially macOS.
Very good units with modern u-blox GPS chips may be acquired from China very cheap now thanks to the boom of drones and internet of things...

Good luck

Pavel

[bcn]

Originally Posted by nohal

Rob...


Very good units with modern u-blox GPS chips may be acquired from China very cheap now thanks to the boom of drones and internet of things...

Good luck

Pavel

uBlox is btw. a Swiss company.
In Europe Navilock is a source for uBlox GNSS receivers with decent driver support.
M8 based systems are the latest multi GNSS devices.
It will be interesting to see their new F9 dual frequency receivers for consumer devices.

That said: sailing there are very few (or none but hurricane induced rain falls - tunnels in Inland canals are others..) outages due to satellite issues. And 1.8m precision as of today with EGNOS or other WAAS corrections shall be ok for all of our purposes.

[bdbcat]

Thomas...


I agree it is scrambled now.


Can we all agree that we shall use and show exactly the distance unit selected in settings->display->units, whatever that is?


Also, in Waypoint properties, we should change "Distance" to "Spacing" or "Interval". Any preference?


Dave

[bcn]

"Interval" for me in the case of Range Rings. And agree, same units for all objects.

[nohal]

Originally Posted by bdbcat

Thomas...


I agree it is scrambled now.


Can we all agree that we shall use and show exactly the distance unit selected in settings->display->units, whatever that is?


Also, in Waypoint properties, we should change "Distance" to "Spacing" or "Interval". Any preference?


Dave

That is what everything around the route properties dialog does already and the thing works very well AFAICT - and we keep hearing calls for unification even in the plugins all the time, while we "never" here anything against...

Pavel

[bdbcat]

did-g...


I will review the UI for MBTiles. Needs a tweak, I think. Or at least better explanations.


There is a current task on Flyspray regarding this subject.


https://opencpn.org/flyspray/index.p...s&task_id=2516


Dave