OpenCPN Version 1.3.5 Beta Technical

[bdbcat]

idpnd....

It looks to me like the opencpn_de_DE.po is set for utf-8.
But I am inexpert at these things....

Where do you see reference to iso-8859?

Dave

[bdbcat]

Marco...

Sorry, I have no Italian ENCs

What is the object type and attributes of the dry rock object in the ENC?
I do not recognize the graphics library item which is being drawn here.

I do recognize the object on cm93, however.

Thanks
Dave

[champ8242]

Originally Posted by bdbcat

idpnd....

It looks to me like the opencpn_de_DE.po is set for utf-8.
But I am inexpert at these things....

Where do you see reference to iso-8859?

Dave

As far as i can see, if you open the .po file with a texteditor you will find an entry: "Content-Type: text/plain; charset=utf-8\n" (this is in my .po file). I guess you can change that to any character set

bart

[GPS-Marco]

Originally Posted by bdbcat

Marco...

Sorry, I have no Italian ENCs

What is the object type and attributes of the dry rock object in the ENC?
I do not recognize the graphics library item which is being drawn here.

I do recognize the object on cm93, however.

Thanks
Dave

Dave, it seems a point labelled "Land Area"

Here is a shot. Ciao, Marco.

[idpnd]

Originally Posted by champ8242

As far as i can see, if you open the .po file with a texteditor you will find an entry: "Content-Type: text/plain; charset=utf-8\n" (this is in my .po file). I guess you can change that to any character set

Thanks, this one fixed itself upon getting a fresh copy off the CVS..

[cagney]

Originally Posted by bdbcat

Marco/cagney....

Could you email me a few representative charts with the panning problem? I think most of my NZ charts are from old conversions and obsolete....

Thanks
Dave

To clarify:

I agree, there is a delay that creates jerkiness when dragging the chart with a mouse. It is noticeable now, can't say in which beta it started.

This was a general observation not only applicable to the nz charts. I hope Marco sent you his "problem" charts so the matter can be sorted out.

Thomas

[bdbcat]

Cagney/Marco....

I agree that 1226 panning with some BSB charts is poor.

Poor panning performance on 1226 is directly related to Georef accuracy. Specifically, if the georef solution is not everywhere monotonic up to second order (or derivative), then things like reverse panning and "stuck" zones on slow pans can occur.

This lack of monotonicity results from applying a cubic cross term polynomial to a Mercator coordinate space, and is nearly inevitable for charts with large latitude range.

Note also that a georef solution displaying this pathological feature may be otherwise fine for point navigation to the standards we require, namely "1.5mm at the compilation scale".

This can happen on any chart. For example, NOAA 50_1.kap is terrible, even though it is a BSB3.0 chart with embedded georef constants. Here opencpn just follows the instructions of the cartographer, and uses the supplied georef equation. It is not everywhere monatonic.....

I've looked at the code, and cannot immediately see where the panning algorithm has changed since 1.3.4. Cagney, do you sense a change over the 1.3.5 Beta time with well georef'ed charts?

What to do:
I have been experimenting with a panning algorithm which does not depend on the BSB chart georef solution at all. It merely pans the canvas as if it were a perfect Mercator projection. This is, by the way, exactly what happens with cm93 and S57ENC.

I may get this algorithm in for 1.3.6. So far, the impact seems confined to panning, so the chances for regression problems are minimal. I'll keep you posted.

Comments welcome
Dave

[GPS-Marco]

Originally Posted by bdbcat

Cagney/Marco....

I agree that 1226 panning with some BSB charts is poor.

Poor panning performance on 1226 is directly related to Georef accuracy. Specifically, if the georef solution is not everywhere monotonic up to second order (or derivative), then things like reverse panning and "stuck" zones on slow pans can occur.

This lack of monotonicity results from applying a cubic cross term polynomial to a Mercator coordinate space, and is nearly inevitable for charts with large latitude range.

Note also that a georef solution displaying this pathological feature may be otherwise fine for point navigation to the standards we require, namely "1.5mm at the compilation scale".

This can happen on any chart. For example, NOAA 50_1.kap is terrible, even though it is a BSB3.0 chart with embedded georef constants. Here opencpn just follows the instructions of the cartographer, and uses the supplied georef equation. It is not everywhere monatonic.....

I've looked at the code, and cannot immediately see where the panning algorithm has changed since 1.3.4. Cagney, do you sense a change over the 1.3.5 Beta time with well georef'ed charts?

What to do:
I have been experimenting with a panning algorithm which does not depend on the BSB chart georef solution at all. It merely pans the canvas as if it were a perfect Mercator projection. This is, by the way, exactly what happens with cm93 and S57ENC.

I may get this algorithm in for 1.3.6. So far, the impact seems confined to panning, so the chances for regression problems are minimal. I'll keep you posted.

Comments welcome
Dave

Hi Dave, If I've understood what you described above, I shall say:

apart for mercator and some others, I guess there are projections that are not monotonic on the second order for the latitude.

For longitude, things are even worse since also mercator is "only" linear and then the second derivative is theoretically zero but with many chances to oscillate between small positive and negative values depending on the small distorsion of chart scan or small georef errors (at pixel level).

I think you shouldn't assume that second order of geroref poly is -always- monotonic. So, I do support for an algo that makes independent the georef poly and the panning.

Ciao, Marco.

[cagney]

Dave

I've looked at the code, and cannot immediately see where the panning algorithm has changed since 1.3.4. Cagney, do you sense a change over the 1.3.5 Beta time with well georef'ed charts?

I really can't say, as this is not something I test regularly. The only thing I'm sure about is that the response was better "some time(months!) ago". This may have nothing at all to do with 1.3.5 changes.

Marco
As I said earlier I have a few charts that is built with the "headers" that you have released. On quite a few of these, OpenCPN indicates geo referencing errors by displaying red/yellow/brown color in the chart-name bar. This is accompanied by logg messages such as this:

06:02:47 PM: Georeference Chart_Error_Factor on chart /opt/Navigation/Raster2Bsb/NZ_Marco/NZ14903.kap is 161.196

A quick check revealed similar problems with NZ 26, 27, 14900, and 14903.

I have had similar problems, but in the end it almost always comes down to some silly mistake in the geo-referencing. I do mine manually, but you, if I understand things right, use MapCal, and ought to be saved from my kind of errors.

I have not analyzed your calibrations in depth, to find the cause.

What is your opinion about this problem?

Thomas

[GPS-Marco]

You will love this one.

I installed old versions of OCPN (to test the georef problems), then I tried to re-install latest 1226 (msi):

Installer asks me only if I want to repair or unistall OCPN. I choosed Repair and after few seconds (after I heard my floppy drive looking for a disk!) i got the attached one.

Ciao, Marco.



Windows XP SP3

[GPS-Marco]

Originally Posted by cagney

Dave

I really can't say, as this is not something I test regularly. The only thing I'm sure about is that the response was better "some time(months!) ago". This may have nothing at all to do with 1.3.5 changes.

Marco
As I said earlier I have a few charts that is built with the "headers" that you have released. On quite a few of these, OpenCPN indicates geo referencing errors by displaying red/yellow/brown color in the chart-name bar. This is accompanied by logg messages such as this:

A quick check revealed similar problems with NZ 26, 27, 14900, and 14903.

I have had similar problems, but in the end it almost always comes down to some silly mistake in the geo-referencing. I do mine manually, but you, if I understand things right, use MapCal, and ought to be saved from my kind of errors.

I have not analyzed your calibrations in depth, to find the cause.

What is your opinion about this problem?

Thomas

Thomas, I've noticed the orange display and I count to analize the issue in the future...

So far, as soon as I finish a georef I test the chart in OCPN and I verify there is no error in georef (I check putting the mouse on various places on the lat/long grid and checking that the OCPN Cursor:Lat/Lon information is consistent.

Of course some problem may still exist on some ref point but I will re-check all the portfolio when I will have finished it. If you find some specific errors, please tell me.

Ciao, Marco.

[GPS-Marco]

Hi all, maybe I found something:

installing all old versions I have and testing on chart NZ28, I discovered 2 things:

1) when the overzoom was not an OCPN "feature", the panning problem was much less evident...

2) something bad happened between beta 1122 and beta 1210. Testing NZ28 with both versions reveals a problem; 1122 pans almost correctly, 1210 pans oddly (sometimes you pan horizzontaly and the chart pans vertically too revealing a cross coefficient problem).

Now I'll fight to reinstall 1226...

Ciao, Marco.

[Ptizef]

Hi Dave
The same rule for colors is not applyed on all the surface of a map . On the screen-shot below , the right part is OK but the left part , no .
I've set shallow depth =5 , deep depth =10 , security depht=8
CM93 & vista
regards
Jean pierre

[bdbcat]

Marco....

Could you send me NZ28? I don't seem to have it.

Thanks
Dave

[bdbcat]

Marco/Cagney...

Here is the deal:

1122 and 1210 differ in georef development, (surprise...)

Beta1122: if nRef <12, use order = 2; if nRef > 12 use order = 3

Beta1210+: if nRef <= 20, user order = 2; if nRef > 20 use order = 3.

NZ28 has 18 Ref points. So, on 1122 it uses cubic polynomial.
on 1210+ it uses quadratic polynomial...

It seems that the cubic fit is "better", at least for panning.

This is the old polynomial problem reappearing in a new form. We have gone back and forth on this 12 or 20 value several times. Results vary by chart.

I guess this is all FYI. I'm still looking at georef-independent panning. More on that later.

Ideas?
Dave