OpenCPN Version 2.4 Beta Build 324

[HappySeagull]

Dave,the cm93s have never been really useful for me around here anyways.I couldn't even see them until OpenCPN showed em to me!Otherwise,they're just for armchair navigation ...and I wouldn't myself downgrade back to 2.3 to nix the correction-reading you laboured to include.

[bdbcat]

HS...

More and more variation.

Which version of cm93 are you using? I have cm93_may2009 and cm93_Jan2010.

These editions do not even include an E cell at 4180707.... The best they have is D scale.

I will load up an older version and check again.


Dave

[bdbcat]

HappySeagull....

OK, I found a cm93 chart set which includes a 4180707 E scale.
The file name, btw, is {cmroot}/03900660/E/04180707.E

It has the offsets you quote, but looks nothing like your chart. There is no rock.

I think that (once again), we prove that cm93 charts are to used with care, just like any other navigation instrument or system, and backed up with local direct observation at large scale.

Thanks a lot for working this with me tonight. We learn something.....

I recall crawling through this during the 2.2 Beta cycle. I finally concluded that the best compromise was to ignore the offsets for Version 2.3 release, and see what the real life situation produced. Surprisingly, we got few squawks about inaccurate cm93/wgs84 georeferencing.

Maybe we should do that again for 2.4, but with the ability to enter user offsets for those places that really need them, and for which a user can directly calibrate the inaccurate cells. Just a thought....

Comments, anyone?

Dave

[Viking Sailor]

Dave,

AFAIK, all GPS receivers by default calculate and output position data referenced to the WGS84 datum. Thus, using the WGS84 corrections provided in the CM93 chart data to place the cells would make the most sense.

Paul

[ratsea]

[QUOTE=Maybe we should do that again for 2.4, but with the ability to enter user offsets for those places that really need them, and for which a user can directly calibrate the inaccurate cells. Just a thought....

Comments, anyone?

Dave[/QUOTE]
I would prefer to stick with V2.3 Logic and let the user adjust if required. I have had many example in Europe where the Offsets shown have been correctly applied. A good example is my current position.

If I open the same CM93 Chart with the Original CMap Software, they apply the 2.3 logic, ie the Charts have been adjusted, see the snip of my area. It shows a narrative to confirm this. It clearly says Source Horizontal datum = Rome 1940, Long Offest to WGS84 -39.m etc. I rest my case - its already done in the base chart.

If there is discrepancy like this, maybe there needs to be a Global Setup parameter for users to let them choose to apply offsets or not. I am using CM93 charts dated May 2010 downloaded from (CNF.SeaSoft). These are mostly adjusted to WGS84, but not all. I shall stick with version 2.3 for the time being, as I believe you have a rogue example that needs a manual correction rather than an automatic blanket one!! 900m is a huge adjustment and would make me very wary. Have you looked at a real paper chart of the area?

We need more inputs - and some checking of the base paper charts that the CM93 was derived from as that will show the corrections necessary to convert to WGS84.
Richard

[PjotrC]

I don't think I would dare to change manually the offsets without a hard record and a tool to rollback/rollforward the changes, that would eliminate my mistakes and omissions.

I guess a survey is needed, where and how many errors there are.
In the case of Graciosa/Pta Corrales I would probably never use scale E at all, just jump to F if nearby enough.

In theory, it should be possible to detect automatically on a rezoom, that the mid-screen pixel does jump coordinates... and flash a warning...

Piotr

[bdbcat]

Folks...

Ratsea makes a good argument. His reading of the dialog notation is quite reasonable.

I think it would be instructive to find out if the offset from Rome1940 datum to WGS84 is, in fact, equal to the offsets specified for this cell. If we find that to be true, it reinforces his interpretation, i.e. that the offsets have already been applied.

I'll check that, and report back.

Dave

[sailorF54]

Originally Posted by bdbcat

All interested....

Regarding wgsox/y parameters:

I interpret these parameters as follows:

"In order to display this cell as WGS84, you must apply these offsets (wgsox, wgsoy) to the raw geographical locations in this cell in order to convert the cell to WGS84 before drawing".

Ratsea would read it as:

"This cell has already been adjusted to WGS84 by applying the wgsox,wgsoy parameters to the original survey data. wgsox/y are noted for information only."

Which is correct?

My favorite test location is E scale cm93 at
022 10.1250 N
075 44.0090 W

Without using the wgsox/y offsets, the chart is wrong by 900 metres (!!)
With the supplied wgsox/y, it is spot on.

So, I dunno....

Any more anecdotal stories?

Dave

Here are some preliminary facts on offsets

Position 47° 03' N 002° 12' W (Pierre Moine tower in Baie de Bourgneuf, south of the Loire river esturary)
at 54 100 scale, CM93 2010_5 is based on SHOM charts 7395.
My paper copy of this chart says that
- this chart is based on the ED50 geodetic system.
- To convert it to WGS84, the positions must be shifted 0.06' N and 0.08' E.
However I fail to see how to convert these angle shifts to the distance shifts given in the CM93 'coverage' info box
_wgsox -149.0(m)
_wgsoy -166.0(m)

(I'd expect 111 m N and 101 m east)

But more disturbing is this
Using Maxsea (12.6) with the mapmedia raster version of same chart, the position of the tower is
47°03.361 / 2°12.347

Using OpenCpn 2.4.324 with 'built-in' offset, the position is
47°03.425 / 2°12.274

Now, manually suppressing this offset yields
47° 03.365 / 2° 12.355

A MUCH BETTER MATCH...

On this single test point, the offset introduced in version .324 seems to deteriorate the positioning of this AtoN !

[bdbcat]

All...

Well, it is still inconclusive.
I find various numbers for the offset from Rome1940 to WGS84. The most common is:

x: -225 m
y: -66 m

Does not match the wgsox/y numbers encoded in the cell, and worse, the polarity is not consistent.

Still thinking....
Dave

[HappySeagull]

Originally Posted by bdbcat

HS...

More and more variation.

Which version of cm93 are you using? I have cm93_may2009 and cm93_Jan2010.

These editions do not even include an E cell at 4180707.... The best they have is D scale.

I will load up an older version and check again.


Dave

...my version from the OpenCPN chart bar is 2000-01-01.I've dragged em across so many hardrives, that may be as accurate as I'll ever know!

[CarCode]

Originally Posted by ratsea

I am using CM93 charts dated May 2010 downloaded from (CNF.SeaSoft).

It seems you are all using illegal copied and pirated charts. It is quite dangerous to also publicate this.

Gerhard

[HappySeagull]

Dave,perhaps it's best to keep your "offset reader" but maybe the offset should show in the chart bar?in red!and Maybe just allow offsets to be applied on the vector chart config page.

SailorF54:That describes my case too....wrong offsets!It may be that the CM93 folks were trying to fudge the charts to suit some parameters that changed at every update..I for instance have CHS Raster UTM,TM, Polyconics among the majority Mercators but these 1996 charts are all no doubt the base of the 2000-01-01 cm93 version I have.This might explain the various versions of offsets =more fudging by CM93 as new charts are inserted,or complaints arise.
...Applying the offsets of all these versions automatically...shows the user some of the mechanics of this confusion and the argument is, is that a good thing?
It really should be in a navigator's to understand the digital charts,but if all the offsets are wrong...?So far,judging by these posts,too many are.

[bdbcat]

Cruisers....

...and we got a well documented Flyspray bug (fs393) regarding cm93 offsets.

So, the conclusion seems clear.

We will revert to no wgsox/y offset correction in the next Beta. We will retain the user offset capability for those cells that individual users may wish to correct.

So, we learn. That's why we call this a Beta process......

Thanks all for your comments. I consider this issue resolved upstream, and we shall see the results in the next Beta.

btw, if it is not obvious by now, I do not recommend critical navigation with Beta versions of OpenCPN....

Dave

[sailorF54]

Another more direct test

Pornichet Marina (c. 47°15 N - 2°21° W)

CM93 2010_5 : drop a mark on the green tower on outer breakwater. (see pic #1) there is no x/y offset with the recent SHOM chart used

Use CM93 2002: This set uses an older SHOM chart, hence offset (see pic #2). The mark is way off the green tower

Manually 'revert' the offset. The mark is back on the tower. (see Pic #3)

IMHO, that should settle the point.
'built-in' offset from CM93 data in version 324 should be suppressed ASAP...

[HappySeagull]

Moving right along and back.....the GRID is wrong....post 53.

If I make a mark,say 50N,125W,it doesn't agree with the grid feature.It agrees with the chart (BSB/KAP)..in that case (post 53)the original paper chart was NAD83 so even the drawn LatLong agree pretty well