OpenCPN Beta test 4.1.1108 Release

[seandepagnier]

Originally Posted by juehoe

Hi,
I downloaded the files recently and could compile without much problems on Debian 8.2. On first test it runs smoothly and is very responsive.

For a while I have been specially interested in chart projections and therefore wrote a little test progam for the projection routines in georef. The program reads a pair of (lat,lon) coordinates from standard input, converts to (easting,northing) and back to (lat,lon). I found that the results for polyconic projection are totally weird and some others also did't reverse well.

I already know the polyconic routines are incorrect. It would be great if you could fix them. Once fixed I can verify this by viewing polyconic charts in polyconic mode and they should appear square. polyconic projections can use various latitudes so it's not clear to me which one to use as standard.

Looking at the code of georef (and studying the "Geological Survey Bulletin 1532" by J.P.Snyder, where most of the algorhythms seem to stem from) I noticed a couple of oddities and errors:

georef.h
--------
toTM: the data type of the arguments is float, while the other functions use double and all calculations are made in double

Maybe the calculations can be done with float with sufficient precision, if not, the arguments should be changed to double.

georeff.cpp
-----------
toPOLY: formulas 15-2, 15-3 and 15-4 are not coded correctly (page 128).
The effect is, that in formula 15-4 factor 'E' is wrong (sin phi not applied).
fromPOLY: iteration (formula 15-21) is also not correctly implemented, termination criterion not correct

Please correct and submit a pull request.

from SM_ECC: the series solution is not very precise, iteration is much better.

Maybe, but it's already too slow. Maybe you can get precision with some lookup tables?

in the routines for SM, SM_ECC, POLY the radius is multiplied with a factor k0_mercator of value 0.9996. In TM, you use a factor of 1.0. This doesn't make much sense to me. It seems, that someone just copied the boilerplate line "radius * k0_mercator".
According to Snyder, a factor k0=0.9996 is only in the context of TM. This is because TM is not true scale on the equator and to minimise some distortions.
In all other cases, the projection of an angle of 1' (one minute) on the equator should give 2piR/360/60. From my opinion, this k0 factor therefore needs to be taken out and applied in TM (exactly opposite from what it is now).
I made all changes as above, ran the test again and the results are much better.
The file test.c also contains a version of POLY_ECC.

I hope this makes sense,
Juergen

I agree, this seemed wrong so it should be fixed.

Originally Posted by .Paul.

JM,

The western part of US5NY25M quilts with US4NY25M in OpenCPN 4.1.925 (beta).

The eastern part does not quilt.

Both western and eastern parts of US5NY25M quilt in 4.1.915 (my build)and 4.1.602 (beta).

Paul

This is clearly a fallout of 026f7d371e249833af873960bb4b215c6caffba8 switching from rectangle regions in screen coordinates to polygon regions.

There are also plenty of cases which worked wrong before but work correctly now, especially with skewed ENC charts. Also we can quilt charts with different projections... but it appears you found a regression.

Is this a cm93 chart or? Which lat/lon? If I can reproduce it I can probably fix it.

[bdbcat]

Hakan...

re:
"There's, again, a miss in details using cm93."

Sorry, I cannot reproduce with the posted VDR playback. It all looks fine on linux and Win7, for me.

More info, please:

1. Which cm93 set?
2. Vector chart settings, especially cm93 detail level.
3. Screen scale factor when the effect appears.

Anyone else have a chance to try this VDR yet?

Thanks
Dave

[NahanniV]

Originally Posted by boat_alexandra

...
This is clearly a fallout of 026f7d371e249833af873960bb4b215c6caffba8 switching from rectangle regions in screen coordinates to polygon regions.

There are also plenty of cases which worked wrong before but work correctly now, especially with skewed ENC charts. Also we can quilt charts with different projections... but it appears you found a regression.

Is this a cm93 chart or? Which lat/lon? If I can reproduce it I can probably fix it.

This is with US ENCs from NOAA. I am using the state of NY.

One of the charts is at: 43 17.9764N 078 48.6493W

Cheers,
JM.

[bdbcat]

Sean...

Re: New York ENCs.

I'm on it now...

Dave

[rgleason]

Thanks Gerhard:

It is called GLview and is available for free also for Windows 32bit + 64bit: OpenGL Extensions Viewer

I added OpenGL testing and this software to the bottom of the OpenGL page
http://opencpn.org/ocpn/opengl

[bdbcat]

Folks...

Re: New York ENCs. (US5NY25M) failure to quilt eastern region.

Corrected in github now.

Good luck
Dave

[.Paul.]

Dave,

I just built OpenCPN for Windows with the latest source. That fixed the quilted display of the two cells, US5NY25M.000 and US5NY23M.000, that JM (NahanniV) identified.

Thanks,
Paul

[rgleason]

V4.1.1108 recent, Windows, I don't seem to be able to export a route, it hangs. Anyone else?

To test Ocpn_Draw Inclusion Boundary I would like to create a Route, convert it to a Nmea VDR file, so that I can Play the file in VDR and have the boat wander out of the Inclusive Boundary that I set up. I tried setting a route active thme activating successvie waypoints while Tracking was on, but of course that did not work.

So I am thinking there must be a way to easily record a set of waypoints as if it were nmea boat position and then play that back using VDR. ...Perhaps not. Maybe I just have to do it with a text editor. --Are there any better ideas out there?

At first I thought VDR record would do what I wanted by simply "move the boat here" but the recorder is just listening to the Nmea stream.

[Hakan]

Dave,
re: More info, please:

1. Which cm93 set?
>> _2012. Is there any ID I can read somewhere ?? (But still: 4.0 is fine using the same set)
2. Vector chart settings, especially cm93 detail level.
>> All - Level 4.(Text-on, Soundings-on, Lights-on)
3. Screen scale factor when the effect appears.
>> Scale around 28000 (0.7x)

Only when OpenGl is on.
Quilt is on. When off there's another but connected behavior.
It's most obvious after passing 57.90 N
VDR replay speed ~20%

OpenGl log report:

9:30:23 PM: OpenGL-> Renderer String: Intel(R) HD Graphics 3000
9:30:23 PM: OpenGL-> Version reported:  3.1.0 - Build 9.17.10.4229
9:30:23 PM: OpenGL-> Detected Intel renderer, disabling stencil buffer
9:30:23 PM: OpenGL-> Texture rectangle format: de1
9:30:23 PM: OpenGL-> glGenerateMipmap unavailable
9:30:23 PM: OpenGL-> Detected Windows Intel renderer, disabling Vertexbuffer Objects
9:30:23 PM: OpenGL-> Vertexbuffer Objects unavailable
9:30:23 PM: OpenGL-> Using Framebuffer Objects
9:30:23 PM: OpenGL-> Using FBO Stencil buffer
9:30:23 PM: OpenGL-> Using Depth buffer clipping
9:30:23 PM: OpenGL-> Using s3tc dxt1 compression
9:30:23 PM: OpenGL-> Compressed tile size: 128kb (6:1)
9:30:23 PM: OpenGL-> Minimum cartographic line width:  1.0
9:30:23 PM: OpenGL-> Minimum symbol line width:  1.0

Håkan

[.Paul.]

Originally Posted by rgleason

V4.1.1108 recent, Windows, I don't seem to be able to export a route, it hangs. Anyone else?.

Rick,

As a test, I just used Route Manager on the task bar to export a four waypoint route. It worked okay in 4.1.1108 in Windows 10. I ran today's build (Windows) and it also exported the route.

Paul

[rgleason]

Thanks Paul,
Just git and compiled. Then deleted navobj.change, still a problem. Deleted all waypoints, tracks and routes. Close and restart O, stilll a problem with export routes, O hangs.
Then because the OpenGL seems choppy, I deleted the cache (because I got errors that had to be skipped when I tried to rebuild it from the Opengl Advanced tab), so deleting was best.

Then I tried export a route again. No dice, hang.
I can import and right click on a route and save to clipboard as Kml.

Tomorrow I will try deleting the navobj.xmls and if that does not work I will move my opencpn.ini to another directory and start over. I don't really want to do that.

Maybe I will remove or unenable all unused plugins first.

Any ideas for what is causing this?

Tried unenabling all plugins (ocpn_draw, weather, VDR, watchdog) other than the standards. No dice routes don't export. It hangs.

Using O Latest commit f7ad89b 8 hours ago

[bdbcat]

Rick...

Have you tried without OpenGL?

Also, if you are running in VS2013 debugger environment, and it seems to hang, try toolbar Debug->Break All and see where it is stuck.


Dave

[did-g]

Originally Posted by bdbcat

Hakan...

re:
"There's, again, a miss in details using cm93."

Sorry, I cannot reproduce with the posted VDR playback. It all looks fine on linux and Win7, for me.

More info, please:

1. Which cm93 set?
2. Vector chart settings, especially cm93 detail level.
3. Screen scale factor when the effect appears.

Anyone else have a chance to try this VDR yet?

Thanks
Dave

Dave...

Yes I have.
It could be 4a15c8f268082fea4de820505e2a5e0f6fca406d
'changes to make cm93 charts use -180 to 180 longitude to simplify logic and fix bugs'

Hakan...
for double checking can you recompile after changing in

src/cm93.cpp
bool cm93chart::IsPointInLoadedM_COVR ( double xc, double yc )
{
#if 1
    return m_region.Contains(yc, xc);
#else


#if 1
with 
#if 0

?

Sometimes LLRegion.Contains returns the wrong result and the display switches quickly between cm93 scales.

Not a proper fix as:
- viewport > 180 aren't fully drawn.
- In cm93 There's loops for which LLRegion::PointsCCW is true but which don't cross 180 and LLRegion::AdjustLongitude returns an empty region.
- some NODTA regions aren't rendered (not introduced by this patch, but related with the new region code).

[Hakan]

did-g, Dave
No, didn't helped, still the same.

And to complete my list from above when this happens:
- the occasionally missing details issue is only valid when "auto follow - F2" is active.

Thanks
Håkan

[seandepagnier]

Sometimes LLRegion.Contains returns the wrong result and the display switches quickly between cm93 scales.

Is this for degenerate cases? The point lies on the border or?

Not a proper fix as:
- viewport > 180 aren't fully drawn.

It must be missing some longitude resolves

- In cm93 There's loops for which LLRegion::PointsCCW is true but which don't cross 180 and LLRegion::AdjustLongitude returns an empty region.

Is this also a degenerate case? There is a border in the loop which lies exactly along the 180 meridian?

- some NODTA regions aren't rendered (not introduced by this patch, but related with the new region code).

Which ones? Do you have a specific example with lat and lon on a particular chart? Before the new region logic, there were nodta regions which weren't rendered but now they are...