OCPN Beta 4.8.1 PreAlpha

[rgleason]

Thanks Pavel, the Dave kindly upgraded to 5.6 at my request, so that we can run Dokuwiki SiteExport plugin.

On another matter. I just git fetched O and clean compiled. 0 fails 6 warnings.
I know you don't do much with these often, but perhaps at some point they get attended to.

Build succeeded.

"C:\Users\Frederick\Documents\GitHub\OpenCPN\build \package.vcxproj" (default ta
rget) (1) ->
"C:\Users\Frederick\Documents\GitHub\OpenCPN\build \ALL_BUILD.vcxproj" (default
target) (3) ->
"C:\Users\Frederick\Documents\GitHub\OpenCPN\build \plugins\chartdldr_pi\chartdl
dr_pi.vcxproj" (default target) (14) ->
"C:\Users\Frederick\Documents\GitHub\OpenCPN\build \opencpn.vcxproj" (default ta
rget) (16) ->
(ClCompile target) ->
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(1298):
warning C4005: 'M_PI' : macro redefinition (C:\Users\Frederick\Documents\GitHub
\OpenCPN\src\chcanv.cpp) [C:\Users\Frederick\Documents\GitHub\OpenCPN\build\ ope
ncpn.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(1298):
warning C4005: 'M_PI' : macro redefinition (C:\Users\Frederick\Documents\GitHub
\OpenCPN\src\navutil.cpp) [C:\Users\Frederick\Documents\GitHub\OpenCPN\build\ op
encpn.vcxproj]
C:\Users\Frederick\Documents\GitHub\OpenCPN\src\pl uginmanager.cpp(5831): warn
ing C4273: 'wxEVT_DOWNLOAD_EVENT' : inconsistent dll linkage [C:\Users\Frederic
k\Documents\GitHub\OpenCPN\build\opencpn.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(1298):
warning C4005: 'M_PI' : macro redefinition (C:\Users\Frederick\Documents\GitHub
\OpenCPN\src\viewport.cpp) [C:\Users\Frederick\Documents\GitHub\OpenCPN\build\ o
pencpn.vcxproj]


"C:\Users\Frederick\Documents\GitHub\OpenCPN\build \package.vcxproj" (default ta
rget) (1) ->
"C:\Users\Frederick\Documents\GitHub\OpenCPN\build \ALL_BUILD.vcxproj" (default
target) (3) ->
"C:\Users\Frederick\Documents\GitHub\OpenCPN\build \plugins\grib_pi\grib_pi.vcxp
roj" (default target) (20) ->
c:\users\frederick\documents\github\opencpn\plugin s\grib_pi\src\gribv1record.
cpp(272): warning C4717: 'GribV1Record::GribV1Record' : recursive on all contro
l paths, function will cause runtime stack overflow [C:\Users\Frederick\Documen
ts\GitHub\OpenCPN\build\plugins\grib_pi\grib_pi.vc xproj]
c:\users\frederick\documents\github\opencpn\plugin s\grib_pi\src\gribv2record.
cpp(1606): warning C4717: 'GribV2Record::GribV2Record' : recursive on all contr
ol paths, function will cause runtime stack overflow [C:\Users\Frederick\Docume
nts\GitHub\OpenCPN\build\plugins\grib_pi\grib_pi.v cxproj]

6 Warning(s)

PS: Grib and Weather_routing are working fine with the new version.

[did-g]

Originally Posted by rgleason

Thanks Pavel, the Dave kindly upgraded to 5.6 at my request, so that we can run Dokuwiki SiteExport plugin.

On another matter. I just git fetched O and clean compiled. 0 fails 6 warnings.
I know you don't do much with these often, but perhaps at some point they get attended to.

I will look at the recursive error, one day . It's in unused copy constructors, unused until unrelated changes blow it...

[nkiesel]

I still struggle with the size of AIS boat icons. They look ok if I set the "Chart Object Scale Factor" to -5, but then e.g. buoy etc. icons are so small they are hardly visible. One part of the problem is that the AIS boat icons do not scale with the maps. Is this really intended?

Attached screenshot is with "Chart Object Scale Factor" set to 0

[bcn]

What is your detected screen size?
And the mm/px

All from the log file...

[nkiesel]

Originally Posted by bcn

What is your detected screen size?
And the mm/px
All from the log file...

10:08:13 PST: Creating MyFrame...size(1344, 737) position(1920, 64)
10:08:13 PST: Metrics: m_display_size_mm: 344 wxDisplaySize: 4480:1440
10:08:13 PST: OpenGL-> Renderer String: AMD CAPE VERDE (DRM 2.50.0 / 4.14.0-2-amd64, LLVM 5.0.1)
10:08:15 PST: DPMM: 13.0233 ScaleFactorExp: 0.500074


For the record: this is from OpenCPN compiled from master brnach pulled earlier today (HEAD is fec4e37c) on Debian unstable 64bit

[cagney]

Still a problem with Own Ship using real scale bitmap.

Using 4.8.0, latest git


Using latest git 4.8.1


Thomas

[rgleason]

Thomas,
I have * master 2773135 Fix the compilation error with GCC.
Don't see that. What are you doing?

Have you entered the GPS offsets? What are they?

[bdbcat]

cagney...

regarding real scaled bitmap ownship:

1. I assume your screenshot labels are flipped, so that the trouble is with 4.8.1 from github. Or maybe not?

Anyway, I cannot reproduce on latest git, linux, nominal desktop display, GL +/-

How are your ownship parameters set?

More detail, please.

Thanks
Dave

[bdbcat]

nkiesel....

re: Large AIS targets.

Lets confirm that your display is following the intended algorithm.

Consider "size" as actual size measured on screen with a caliper and ruler. The algorithm specifies AIS target size at zero scale multiplier as:

1. Actual screen size (width in mm) divided by 60.
and
2. No larger than 10 mm.
and
3. No smaller than 6 mm.

For your screen, 344/60 = 5.7 mm
By the algorithm, clamped up to 6 mm.

So, caliper on the screen, please.

Thanks
Dave

[cagney]

Originally Posted by bdbcat

cagney...

regarding real scaled bitmap ownship:

1. I assume your screenshot labels are flipped, so that the trouble is with 4.8.1 from github. Or maybe not?

Anyway, I cannot reproduce on latest git, linux, nominal desktop display, GL +/-

How are your ownship parameters set?

More detail, please.

Thanks
Dave

Dave

Yes the labels were flipped.

Settings


Real Scale Vector looks like this


Very early in the alpha testing Hakan complained about the same thing, see
http://www.cruisersforum.com/forums/...ml#post2540311

Hakan, how does real scale bitmaps looks for you nowadays?

Thanks!

Thomas

[nkiesel]

Originally Posted by bdbcat

nkiesel....

re: Large AIS targets.

My screen size is reported wrong. I have a laptop connected to an external monitor w/o mirroring side-by-side. Laptop has 1920 px/344mm and monitor has 2560px/596mm. OpenCPN window is fullscreen on external monitor.

AIS icons on external monitor are 10mmx18mm. After moving OpenCPn windows to laptop screen, AIS icons are 8mmx15mm (i.e. still oversized).

When I unplug the external monitor and start OpenCPN, AIS icons have a resonable (i.e. much smaller) size.

Relevant (I think) log file differences :

Just laptop:
Creating MyFrame...size(1344, 737) position(0, 37)
Metrics: m_display_size_mm: 344 wxDisplaySize: 1920:1080
DPMM: 5.5814 ScaleFactorExp: 1

Laptop + external monitor:
Creating MyFrame...size(1344, 737) position(1920, 64)
Metrics: m_display_size_mm: 344 wxDisplaySize: 4480:1440
DPMM: 13.0233 ScaleFactorExp: 1

[bdbcat]

Thomas...

Thinking about LOA, and not Beam, from your screenshots, looks to me that the scaling to 10.7 m is about right, compared to the 50m circle.
But we seem not to be honoring the min size specification of 10 mm.

The beam scaling is calculated from the LOA scaling, but looks wrong, also.

Does this make sense? Try to boost the min size (mm) parameter, and see what happens.

Dave

[bdbcat]

nkiesel...

OK.
if you override the screen size calculation, and set it to the combined width (344 + 596), how do the icons appear?

I doubt we will be able to write code that reliably calculates, on all platforms, the width of side-by-side transient monitors providing super-wide workspaces. The possibilities are endless.

Thanks
Dave

[nkiesel]

[AIS icon size]

So the problem is that OpenCPN uses the physical width in mm from the default monitor (which in my instance is the laptop monitor) but the logical width in pixels from the "screen" which is in my instance the combined monitors.

We could fix that by using #pixels from default monitor, or use the resolution of the currently used monitor (and ideally adjust when the OpenCPN window is moved to another monitor). But I really wonder why AIS is special. Why are other icons (e.g. buoys) not equally inflated? Is the AIS code just trying too hard to be smart?

After looking at the code a bit I also realized that could override the screen size to work around my problem.

[nkiesel]

Originally Posted by bdbcat

nkiesel...

I doubt we will be able to write code that reliably calculates, on all platforms, the width of side-by-side transient monitors providing super-wide workspaces. The possibilities are endless.

Thanks
Dave

Yeah, and I could of course also have monitors stacked vertically. Simple improvement could be to use one of the monitors (seems we are currently using physical size of just one monitor but pixel size of the combined screen). Still trying to understand what makes the AIS icons special (i.e. why that does not affect anything else).