OpenCPN Beta Version 3.3.2330 Released

[HappySeagull]

In case it hasn't been mentioned, Many old bsb/kaps have developed a westerly/counterclockwise skew.
This is Chart 344101 HaroStrait-BoundaryPass ...
This is new.They are fine in O 3.3.14
OpenGL is OFF
Header:

!Copyright 1996, NDI. All Rights Reserved
BSB/NA=HARO STRAIT- BOUNDARY PASS AND\ET SATELL,NU=3441,RA=11357,8093,DU=254
KNP/SC=40000,GD=NAD27,PR=MERCATOR
    PP=48.6000000, PI= 0.50000,SP=UNKNOWN,7 SK= 0.00
    UN=METERS,SD=LNT,DX= 4.00,DY= 4.00
CED/SE=3441,RE= 344102,ED=01/23/96
VER/1.0
OST/1
IFM/4
REF/1,277,7637,48.5364861,-123.6257528
REF/2,11128,7684,48.5364861,-123.0304750...and so forth

[Littlechay]

Originally Posted by bdbcat

Littlechay....

1. This is not new behaviour in Beta 3.3.x Exactly the same in 3.2.0.

2. If you like Maxsea better, use Maxsea. If you like O, then constructive Flyspray bug reports always get a response. Always. Piling-on in the Forum does not generally produce the expected results.

3. Especially, if you ( and others) think the O developers are intentionally hiding information, then I encourage you to look elsewhere for your charting solution.

Dave

Dave, No need to be so sensitive!

I'm simply pointing out an issue that I have noticed. If it was always there I didn't notice this particular issues, tidal arrows, not showing before. Sure there ! in circles have always been there and I thought they were only for unknown objects, now I realise that they also show on some standard symbols.

I don't know what you mean by piling on?

I noticed this in this version of O so I thought that this was the appropriate thread.

MaxSea is a very smooth bit of software, but being so nailed down, not being able to add my own charts etc.. not so versatile. O is getting there and I use both depending on where I am what I am doing; I am starting to use O more often and have been using and following development since almost day 1. I am not sure if you have noticed but there are more people with a lot of miles commenting and suggesting things ... this implies that that the people who matter are taking note of O..

I'll look at flyspray but as I don't even know that this is a bug why should that have been my first destination? Is this a bug? if so I'll report it.

I don't have always have internet access but when I am ashore and in contact I always download the latest beta and read this forum.

Cheers
Chris

[CarCode]

Originally Posted by bdbcat

Gerhard....

Re: Region leaks.

I don't know why the leaks would be called Hyperlinks.

Further, I run O in linux using valgrind. No Region leaks.
I run O in Windows using Visual Leak Detector, and built in VS2010 leak tracking. No Region leaks.
OSX /usr/bin/leaks from the console shows no leaks.
OSX Instruments shows no leaks.

So, pardon me, but I suspect something is not the same for our builds.

I would like to exactly reproduce your results.
What version of XCode are you using?

Thanks
Dave

Here is the output of your 3.3.2630 build using usr/bin/leaks:

$ leaks 4432
Process:         OpenCPN [4432]
Path:            /Applications/OpenCPN3.3.2330.app/Contents/MacOS/OpenCPN
Load Address:    0x1006b2000
Identifier:      org.opencpn
Version:         3.3.2330 (???)
Code Type:       X86-64
Parent Process:  ??? [1]

Date/Time:       2014-12-07 17:17:19.611 +0100
OS Version:      Mac OS X 10.10.1 (14B25)
Report Version:  7
Analysis Tool:   /Applications/Xcode.app/Contents/Developer/usr/bin/leaks
Analysis Tool Version:  Xcode 6.1.1 (6A2008a)
----

leaks Report Version:  2.0
Process 4432: 258723 nodes malloced for 57428 KB
Process 4432: 474 leaks for 29024 total leaked bytes.

among others there are several HyperlinkList:
Leak: 0x60000005daf0  size=48  zone: DefaultMallocZone_0x101b26000   HyperlinkList  C++  OpenCPN
    0x00c880c0 0x00000001 0x00000000 0x00000000     ................
    0xffffff00 0x00000000 0x00000000 0x00000000     ................
    0x00000000 0x00000000 0x00000000 0x00000000     ................
Leak: 0x60000005e000  size=48  zone: DefaultMallocZone_0x101b26000   HyperlinkList  C++  OpenCPN
    0x00c880c0 0x00000001 0x00000000 0x00000000     ................
    0xffffff00 0x00000000 0x00000000 0x00000000     ................
    0x00000000 0x00000000 0x00000000 0x00000000     ................
Leak: 0x60000005e210  size=48  zone: DefaultMallocZone_0x101b26000   HyperlinkList  C++  OpenCPN
    0x00c880c0 0x00000001 0x00000000 0x00000000     ................
    0xffffff00 0x00000000 0x00000000 0x00000000     ................
    0x00000000 0x00000000 0x00000000 0x00000000     ................
Leak: 0x60000005f260  size=48  zone: DefaultMallocZone_0x101b26000   HyperlinkList  C++  OpenCPN
    0x00c880c0 0x00000001 0x00000000 0x00000000     ................
    0xffffff00 0x00000000 0x00000000 0x00000000     ................
    0x00000000 0x00000000 0x00000000 0x00000000     ................
Leak: 0x60000005f290  size=48  zone: DefaultMallocZone_0x101b26000   HyperlinkList  C++  OpenCPN
    0x00c880c0 0x00000001 0x00000000 0x00000000     ................
    0xffffff00 0x00000000 0x00000000 0x00000000     ................
    0x00000000 0x00000000 0x00000000 0x00000000     ................
Leak: 0x60000005f2f0  size=48  zone: DefaultMallocZone_0x101b26000   HyperlinkList  C++  OpenCPN
    0x00c880c0 0x00000001 0x00000000 0x00000000     ................
    0xffffff00 0x00000000 0x00000000 0x00000000     ................
    0x00000000 0x00000000 0x00000000 0x00000000     ................
Leak: 0x60000005f350  size=48  zone: DefaultMallocZone_0x101b26000   HyperlinkList  C++  OpenCPN
    0x00c880c0 0x00000001 0x00000000 0x00000000     ................
    0xffffff00 0x00000000 0x00000000 0x00000000     ................
    0x00000000 0x00000000 0x00000000 0x00000000     ................
Leak: 0x60000005f5c0  size=48  zone: DefaultMallocZone_0x101b26000   HyperlinkList  C++  OpenCPN
    0x00c880c0 0x00000001 0x00000000 0x00000000     ................
    0xffffff00 0x00000000 0x00000000 0x00000000     ................
    0x00000000 0x00000000 0x00000000 0x00000000     ................
Leak: 0x60000005fa10  size=48  zone: DefaultMallocZone_0x101b26000   HyperlinkList  C++  OpenCPN
    0x00c880c0 0x00000001 0x00000000 0x00000000     ................
    0xffffff00 0x00000000 0x00000000 0x00000000     ................
    0x00000000 0x00000000 0x00000000 0x00000000     ................

It is the same as my build. Might be scrambled memory so I will try another maschine.
Gerhard

[CarCode]

BTW there was just fixed a problem in init.cpp also in the 3.0 branch of wxWidgets:

    // for example), we remember the converted argv here because we'll have to
    // free it when doing cleanup to avoid memory leaks
    wchar_t **argv;

    // we also need to keep two copies, one passed to other functions, and one
    // unmodified original; somebody may modify the former, so we need to have
    // the latter to be able to free everything correctly
    int argcOrig;
    wchar_t **argvOrig;

If it has something to do with the observed leaks?
Gerhard

[cagney]

Originally Posted by HappySeagull

In case it hasn't been mentioned, Many old bsb/kaps have developed a westerly/counterclockwise skew.Attachment 93172
This is Chart 344101 HaroStrait-BoundaryPass ...
This is new.They are fine in O 3.3.14
OpenGL is OFF
Header:

!Copyright 1996, NDI. All Rights Reserved
BSB/NA=HARO STRAIT- BOUNDARY PASS AND\ET SATELL,NU=3441,RA=11357,8093,DU=254
KNP/SC=40000,GD=NAD27,PR=MERCATOR
    PP=48.6000000, PI= 0.50000,SP=UNKNOWN,7 SK= 0.00
    UN=METERS,SD=LNT,DX= 4.00,DY= 4.00
CED/SE=3441,RE= 344102,ED=01/23/96
VER/1.0
OST/1
IFM/4
REF/1,277,7637,48.5364861,-123.6257528
REF/2,11128,7684,48.5364861,-123.0304750...and so forth

Hello Happy!

I can't say that my chart display 100% perfect, a bit better than yours, but mine is in projection= UTM. Here is the header.

!Copyright 1996, NDI. All Rights Reserved
BSB/NA=HARO STRAIT- BOUNDARY PASS AND\ET SATELL,NU=3441,RA=11357,8093,DU=254
KNP/SC=40000,GD=NAD27,PR=UTM
    PP=-123.00000, PI= 0.50000,SP=UNKNOWN,7 SK= 0.00
    UN=METERS,SD=LNT,DX= 4.00,DY= 4.00
CED/SE=3441,RE= 344102,ED=01/23/96
VER/1.0
OST/1
IFM/4
REF/1,277,7637,48.5364861,-123.6257528
REF/2,11128,7684,48.5364861,-123.0304750
REF/3,11130,319,48.8048194,-123.0304750
REF/4,338,274,48.8048194,-123.6257528
REF/5,8636,316,48.8048194,-123.1679750

I vaguely remember that O had some problems with these a long time ago, and that the quick fix was to change the PR to Mercator. Could it be that this quick fix now is coming back to "bite" us? Dave has done a few changes to Tmercs, and then we have the general OGL optimization....

Do you have the original files tucked away somewhere to test?

Thomas

[bdbcat]

Happy Seagull...

I don't have that chart (344101 Haro Strait) available for test. Can you email it to me privately?

Thanks
Dave

[HappySeagull]

Originally Posted by cagney

Hello Happy!

I can't say that my chart display 100% perfect, a bit better than yours, but mine is in projection= UTM. Here is the header.

!Copyright 1996, NDI. All Rights Reserved
BSB/NA=HARO STRAIT- BOUNDARY PASS AND\ET SATELL,NU=3441,RA=11357,8093,DU=254
KNP/SC=40000,GD=NAD27,PR=UTM
    PP=-123.00000, PI= 0.50000,SP=UNKNOWN,7 SK= 0.00
    UN=METERS,SD=LNT,DX= 4.00,DY= 4.00
CED/SE=3441,RE= 344102,ED=01/23/96
VER/1.0
OST/1
IFM/4
REF/1,277,7637,48.5364861,-123.6257528
REF/2,11128,7684,48.5364861,-123.0304750
REF/3,11130,319,48.8048194,-123.0304750
REF/4,338,274,48.8048194,-123.6257528
REF/5,8636,316,48.8048194,-123.1679750

I vaguely remember that O had some problems with these a long time ago, and that the quick fix was to change the PR to Mercator. Could it be that this quick fix now is coming back to "bite" us? Dave has done a few changes to Tmercs, and then we have the general OGL optimization....

Do you have the original files tucked away somewhere to test?

Thomas

ah,so! the "quick fix" is of course what I did ... but Stand By!...it'll take me awhile to rustle through stuff for the truly Original which only exists on a cd., I bet.

[HappySeagull]

No, the original (indeed it is a TM) displays the same.

BUT it might be my machine or the OS

because on XP, original UTM and Happyedit-Merc are both tilted UP as per my screen grab .

On Win 7 , they are both tilted a little less, but down.. I wonder if that's what you see with your TM?

always Interesting to me is that many of these ol' charts state NAD27 datum but are actually WGS 84 (or NAD83 maybe) in display. O does not react to PR=NAD27?

[HappySeagull]

Originally Posted by bdbcat

Happy Seagull...

I don't have that chart (344101 Haro Strait) available for test. Can you email it to me privately?....etc

sent PM .If it worked.

[bdbcat]

Gerhard...

Leaks:

I suppose HyperlinkList is a valid object, and could be leaking. I made some improvements here to avoid leaks in the latest commits. 3.3.2222 leaks some if you have shared waypoints.

If we truly are leaking HyperlinkList, then it must come from the navobj.xml file contents (route, waypoints, etc.). This is the only place we use a HyperlinkList.

Could you try with a blank, or empty navobj.xml, just for comparison?

I do see more leaks to consider, especially cm93 soundings display. I will address these, too. But I really wish to understand the Region thing.

Thanks
Dave

[bdbcat]

Happy...

Got the chart from GoogleBox, or whatever. Thanks.

And...
It works fine for me on linux and XP. If I manually change it from UTM to MERCATOR, there is a slight difference, I think. But nothing skewed like your picture in any case. I also get a georef inaccuracy warning in the log.

Does this effect happen on very many charts? Any pattern you can see?

Thanks
Dave

[rgleason]

I'm going to tell a short story about programs. I got annoyed enough at the "progress" that I expected for our CAD program, which I invested time in very early and helped program macros and promote with other architects, and decided to purchase another program that I thought was better. I soon learned that the user interface was so complex that I could not use it quickly (designed by and for engineers), yet it did many wondrous things that I wanted to do. So I persevered using both programs for a number of years. Finally our small office had to face reality, we were using the program that had fallen out of disfavor far more effectively (like tool or pencil and T-square) than the "new" program, and so we decided to drop the "new" program.

What's the moral? It may look greener, but you may not like it. So my advice if you are impatient like I was, is to go very quietly (this is the key) and try some other programs now, (sure you might need to write a check too) and give it a real trial, if you don't like it, please come back, you won't be as red-faced as I was when I came back.

The folks here are all good folks.

[cagney]

Originally Posted by bdbcat

'Hoy testers...

OK, here is design question:

You are loading chart directories (Options->Charts->Chart files)

1. You load one directory, exit options, and all is well.
2. You go to Options and load another directory.
3. Depending on your chart directory layout and what directory you select, the second directory contains, in the tree somewhere, a chart with the exact same name and timestamp as a chart that is already in place from step(1). This can happen, for instance, if you download and install NOAA raster charts by region, one-by-one. Some small scale charts will appear in several Region collections as downloaded from NOAA.

What is the "right" thing to do?

In OCPN today, we load both charts. The logic is that if you use groups sorted by Region, say, you want the small scale duplicates to appear in each Region. As a result of this logic, when you show "all Available Charts" group you will see duplicates in the chart selector bar. This is confusing. Try it and you will see.

Alternatively, we could elect not to load duplicates. But that might break someone's idea of Group layout by Region/directory.

I prefer not to bring up a cryptic dialog while loading, asking the user what policy they want. Loading charts is an area where novices get bogged down pretty quickly. Talking of groups and duplicates perhaps minutes after they have installed O for the first time will be "not friendly". We should choose a policy and just do it quietly.

So, what say ye?

Thanks
Dave

Dave
Not loading duplicates would be the best, I think.
Would this actually break groups with duplicates?
The fact should be logged.

Thomas

[CarCode]

Originally Posted by bdbcat

Gerhard...

Leaks:

I suppose HyperlinkList is a valid object, and could be leaking. I made some improvements here to avoid leaks in the latest commits. 3.3.2222 leaks some if you have shared waypoints.

If we truly are leaking HyperlinkList, then it must come from the navobj.xml file contents (route, waypoints, etc.). This is the only place we use a HyperlinkList.

Could you try with a blank, or empty navobj.xml, just for comparison?

I do see more leaks to consider, especially cm93 soundings display. I will address these, too. But I really wish to understand the Region thing.

Thanks
Dave

Thank you for the hint.
With a fresh navobj.xml it is now wxFileTypeImpl as leaked object. I will investigate that function.
Gerhard

[LeaseOnLife]

Originally Posted by cagney

Dave
Not loading duplicates would be the best, I think.
Would this actually break groups with duplicates?
The fact should be logged.

Thomas

Is a duplicate defined by

filename?
filename & filesize?
filename & header comparison?
filename, file size, md5sum?
if not totally equal, will O display both or the 'newer' one?