OpenCPN Version 2.4 Beta Build 324

[bdbcat]

HS...

Grid: I caught that. On the list. Thanks

Dave

[HappySeagull]

OOPs,crossposting-already answered.Sorry!
but I'll leave it here for info.
It's the offset thing again.The grid apparently is linked to CM93.



This might be a good thing! to assist fixing the offset?
BUT given all of the above,whichever way offsets are handled,it need be known the grid is compromised,if I'm correct.

Edit I better save this Beta-it could be very handy!

[Gilletarom]

Hello Dave,

Originally Posted by bdbcat

Cruisers....

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.

Dave

I read the post 73.

However, I would like to know how the files containing the data to offset for CM93 V2 have been obtained or made?

Thank you in advance.

Best regards

Gilletarom.

[bdbcat]

Gilletarom....

Not sure I understand the question. The offset we are referring to are encoded as attributes to the chart data, within the cm93 database. User offsets are stored locally on the users system, as entered by the user. Initially, of course, all user offsets are zero.

Answer?
Dave

[Gilletarom]

hello,

Originally Posted by bdbcat

Gilletarom....

Not sure I understand the question. The offset we are referring to are encoded as attributes to the chart data, within the cm93 database. User offsets are stored locally on the users system, as entered by the user. Initially, of course, all user offsets are zero.

Answer?
Dave

We prepared to talk on the forum, with Yoruk, because we identified with the help of several sailors, cells (in Turkey and the Caribbean) where compensation gave malfunctioning cells shifted

This explains my first question.

If the values ​​that are contained in the files CM93 are attributes of the database CM93, I understand that there was no calculation on your part to get them.

How can there be, then, errors that lead to aberrant cell offsets?

Thank you by advance.

Gilletarom.

[bdbcat]

Gilletarom....

You have asked the critical question. We do not know why the standard offsets in the cm93 cell attributes are sometimes wrong. There are several theories.....

For now, our best judgement is to ignore the offsets, thus assuming that they have already been pre-applied to the cell data.

Dave

[Patg]

Originally Posted by bdbcat

You have asked the critical question. We do not know why the standard offsets in the cm93 cell attributes are sometimes wrong. There are several theories.....

For now, our best judgement is to ignore the offsets, thus assuming that they have already been pre-applied to the cell data.

Dave

Hi Dave

I guess this is the correct approach. Track from our harbour entry
at Bodrum last week with and without correction.

Patrick

[GPS-Marco]

Hello

to test OpenCPN precision vs reality, bing or google maps may help.

if you have a WGS84 coordinate of a place (a lighouse, a rock, a pier, etc.) taken from OpenCPN with CM93 or other maps, go to Bing Maps, use the satellite view and type in the seach box the coordinates. Something like:

41.924403, 12.452127

You will see the same exact location on Bing. Precision seems excellent.

Note that the above are the WGS84 coordinates of the vetex of the Roma 1940 Datum, that is marked on ground with a cilindrical stone on top of Monte Mario (in Rome).

The same can be done in Google Earth: put the coordinates in the search box and go...

Ciao, Marco.

[HappySeagull]

Originally Posted by 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

Are you sure you want to drop this?Don't be hasty!The more I use it,the more like genius it is...I recently discovered that using the scroll arrows (on the user offset entry) is the ez way!And that selecting a chart from the offset list highlights its border-a big help where two charts are in the window....I mean,it's looking like genius to me!Some of my CM93charts are ok as is without offset correction ,some are not.
USAGE:I make a datum waypoint on what I consider as a proven accurate bsb/kap chart-say a lightstation.then,in CM93 offset dialogue,I use the XY correction scrollers to move that Datum waypoint.Now,kap and cell agree!
I haven't been on a cruise to check it out properly but it looks as good as it could be from my armchair .

[bdbcat]

HS...

Thanks for the good words.

We will keep the User Offset dialog as-is. We will simply not use any embedded wgsox/y offsets which may be found in the cm93 cell attributes. Users may tweak their own user offsets as they see desirable, cell-by-cell.

I hope this is clear.

Thanks
Dave

[HappySeagull]

Yes!good oh!(I'm just busy comparing the cm93 light positions (in it's info windows) to an online source....an even better way to "shift" CM93 charts.ooh this IS a sharp tool!gotta be careful!)

per the grid,I was wrong,wasn't I -it doesn't "follow the cm93" does it?Because it's ok in CM93 and wrong on the Raster charts...

[HappySeagull]

Boy,that makes it tricky.The official List of Lights doesn't agree with "ObjectQuery's" idea of where the towers are!...But wrong thread for this.

[Gilletarom]

Hello Dave,

Originally Posted by HappySeagull

Are you sure you want to drop this?Don't be hasty! .

This is a very personal opinion.

We, along with several other sailors and Yoruk been very careful to positioning errors of CM93 in "OpenCPN 240-324. It was too important for that to be left like that.

I agree with you that it is removed from the next beta.

But if we were able to have files with more correct offset data, it would be really good.
Because the idea of displaying all the cells, automatically, at exactly the right place is a really good idea.

Do not throw any. Put 0 and 0, for all cells in "Cell X" and "Cell Y".

And look to see if anyone can find files to correct quality.
There will be time later to remove the Cell columns "Cell. X" and "Cell. Y".

Another idea: For the sailors are well aware of the existence of this correction tool, why not make a plug-in with it ?

Best regards

Gilletarom.

[CarCode]

Gilletarom,

in my opinion a warning for the user might be sufficient that the georeferencing of CM93 might be wrong for a mile. Nobody knows which version of CM93 the user is running and I suppose all them are pirated versions.

There are other bugs since long times never corrected: When you scroll the chart you will see at the borders of the chart truncated depth values, e.g. before scrolling it was 28.5 meters and after scrolling back and forth you will see 8.5 for the same place.

Gerhard

[yoruk]

Bonjour…
My English is very poor… but I try

The problem is not is right or wrong
The problem is: the sailor must know

If the chart is ... correct… Ok It is just
If the chart is wrong ... Ok It is false.

The browser must not disturb the data. It is the work of the sailor.
Here in Turkey, c-map cards are wrong twice, once because of geodesy is false and another time because the record is very old ...
No sailing program will not solve these two problems at once ...
It is the work of the sailor ... But it needs data it controls ...
Cordially
Michel