Still some of the strange rendering of CM93 charts as in previous version.
Also if you move the charts a bit to fast, you will get strange rendering(happened a few times, cannot reproduce anymore).
See screenshots.
This happens only in True scale: 123200-30700
__________________
Best Regards OpenCPN Norge - Norwegian OpenCPN community Frode
A screenshot using XP, with full screen quilting on. See all the black rendered in the ENCs. They are pylons.
Somehow they seems to dominate more than other objects.
I suppose this is Nohals territory.
Thomas,
pretty clear here. Pylons use the POSGEN03 symbol which is one of the few vectors we still didn't replace with the more subtle bitmaps as they are pretty rare to encounter. Need to look at the priority they should have according to the various standards also.
Noted it to my todo list, so once I get to the pixelart mood again it will be done.
By the way - are the Korean ENCs available on the web? Thought that KHOA has just those pdf chartlets available...
Have a look at FS#346, it will help you......
For some reason there are heaps of pylons in certain Korean locations.
No big deal, just a minor observation while checking Daves bug fix.
Back in the US now, should be much more connected by Wifi in near future.
Here is a little background on the numerous cm93 display difficulties in Beta 324.
We implemented a "blit accelerator" for chart moves by mouse click. The idea is to improve responsiveness to user input while browsing. We cache chart screenimages aggressively, and move the pixels around on the screen as necessary, all in an attempt to avoid relatively costly full screen rendering. We render (by access to chart data) only those parts of the screen that have been "uncovered" by a mouse move/click.
Obviously, the algorithms are not quite right yet. As far as I can tell, the problems seen in this Beta appear only on cm93, in quilted mode. I can also reproduce the problems, and is my top priority for now.
Another issue:
Anyone using Garmin GRMN host mode for route uploads on Win7? This is a casually reported error here in another thread, and I am trying to confirm.
Until the screen, window and child window problem is not solvedOpenCPN at Mac OS X is useless. OpenCPN is intended for navigation and that is a severe task.
I just came back yesterday from a nice yacht transfer of an old Amel Maramu from Bodrum to Fethie in Turkey. We pimped the boat a bit, installed new Navman instruments, Navtex and AIS-Receiver. I used my MAC with OpenCPN 2.4 Beta 310 (and of course also paper charts) for navigation without any problems. AIS worked flawlessly. Thanks to it I got an alarm and could get the spinnaker down in time to avoid getting trapped in the net of a fishtrawler
The current beta is usable within certain limits for naviagtion, the mac version has still a lot of modal gui bugs, i.e. the routemanager doesn't notice that the route-properties window has closed and locks the application etc., but I'm sure we can find a suitable solution to all these problems.
Today I merged my sourcetree with the latest patches from Dave and pushed them back to github (patg/OpenCPN), builds cleanly under OSX.
OCPN Beta 310 and 324 now fully utilize the WGS84 offsets programmed into the cm93 database. At the location you indicate, the various cm93 scale charts have different offsets. You can study this using the cm93 offset tool in the context menu.
For instance, at this location,
C scale cell has offsets around +/- 200 metres.
D scale cell has no offsets.
E scale cell has offsets around +/-200 metres.
But as you can see, with the "correct" database offsets applied, the charts are inconsistent.
So, the question is, "Where exactly is Pte Corrales?"
We have seen this problem before with cm93.... caveat emptor....
It may be in this case that the uncorrected D scale cell is in error in the database. Independent verfication is probably wise here.
Fortunately, we now have a method of adding user offsets.....
Today I merged my sourcetree with the latest patches from Dave and pushed them back to github (patg/OpenCPN), builds cleanly under OSX.
Welcome, back, have you noticed Carcodes, problem with the coordinates updating even outside the window. It's like wxWidgets, don't notice or don't act when focus is lost on the panel.
I have been using the various versions of OpenCPN for a couple of years and am a real fan. This latest version has confused me. It seems to handle chart offsets differently. Using CM93 (May 2010) charts with an offset of
wgsox -39.0(m) wgsoy 88.0(m) and version 2.3.1, I am happily afloat along side a pontoon in Cagliari. When I load version 2.4.324, I am now on the breakwater some 75m 335Deg (NWish). I can see I can adjust the user offsets, but as the charts change, I can't keep adjusting the offsets. Surely this is for fine tuning or a known error. If I put the opposites for the offsets ie -88 and +39 as a user correction, it's about right.
Am I missing something, but I do not like this change - it is not fail safe at all.
Richard
OCPN prior to Version 2.4 did not use the embedded WGS offsets (wgsox/y).
We found empirically that the offsets were inconsistent at various locations worldwide.
But it seemed "wrong" to ignore the offsets intended by the database. They are there for a reason.
So, Version 2.4 uses the offsets. And the result is what you observe. cm93 cells of various scales have questionable offsets at various locations. However, In some locations, they seem to be quite accurate, and are are absolutely necessary to make the cells georef properly.
Other threads report the same results for Version 2.4.
We have added user offsets capability. I agree with you that employing the user offsets to "de-correct" bad database offsets also seems "wrong", in some sense.
We need some discussion on this topic. I'm not sure what is the best approach for general use. I entertain all ideas.....
BTW, can you give us a lat/lon for your observations?
For instance, at this location,
C scale cell has offsets around +/- 200 metres.
D scale cell has no offsets.
E scale cell has offsets around +/-200 metres.
...
It may be in this case that the uncorrected D scale cell is in error in the database. Independent verfication is probably wise here.
Actually, it looks like it is the E scale cell which is wrong. On the attached shots one can see also that the breakwaters are not positioned as they are in the Google Chart, and as I remember from sailing by.
But what now?
Do we need a global list of Position Doubtful points, and a corresponding list of Position Certified points (per each edition of Charts) and then a growing file of offsets to apply .... ?
PS. With 2.3.1 the error is also there, but much smaller - hard to notice.
OCPN prior to Version 2.4 did not use the embedded WGS offsets (wgsox/y).
We found empirically that the offsets were inconsistent at various locations worldwide.
But it seemed "wrong" to ignore the offsets intended by the database. They are there for a reason.
So, Version 2.4 uses the offsets. And the result is what you observe. cm93 cells of various scales have questionable offsets at various locations. However, In some locations, they seem to be quite accurate, and are are absolutely necessary to make the cells georef properly.
Other threads report the same results for Version 2.4.
We have added user offsets capability. I agree with you that employing the user offsets to "de-correct" bad database offsets also seems "wrong", in some sense.
We need some discussion on this topic. I'm not sure what is the best approach for general use. I entertain all ideas.....
BTW, can you give us a lat/lon for your observations?
Looking for more comments....
Thanks
Dave
My boat's position is 039 12.1 N 009 07.5 E. (Cagliari, Sardinia)
I have two charts covering the same area, a local Italian and CMap. Until now (post 2.4.3...) they agreed with each other and I could switch between them and nothing changed. Now with the adjustable offset, they are different. I always thought the Offset you could see in the chart details was the offset already applied to convert the original chart to WGS, not what was now needed. The Italian chart has a different offsetting scale of:
Feature Class: M_HOPA
Attributes
HORDAT (92)
SHIPAM (0.037 -0.021)
I don't understand this.
I am a bit worried you have mended something that wasn't broken!! It is very good to be able to manually adjust offsets where you know there is an error, but I think you (opencpn) have got to assume all charts are right to a common datum (WGS). Users need to be responsible for their charts so if they want to use a non wgs, they need to be able to apply the correction. I have uploaded 2 snips of the same position on different charts. I should be afloat, not as CM93 on the right!!. See also how the position of a wreck changes.
I shall be returning to the boat in about month, so could checking out again.
I don't think it feasible to start a 'doubtful position' database - you will have to start doing 'Notice to OpenCPN Mariners' world wide with weekly updates!!
Please review this as it is fundamental to the safety of all users, and I have only found a couple of errors in the all the charts from Southampton (UK) to Sardinia (Italy) - approx 5000Nm of sailing.
Richard
While chasing around in CM93 to check different offsets I had a few crashes when clicking the "CM93 offset dialog". Back to ddd.
I think that I eventually got what I was looking for.
This came after switching between RNC and CM93 a few times to see the effect of undoing corrections in Southern Martinique.It eventually happened happened as described above.
I had repeatable crashes just using CM93 when zooming in from a very small scale. Crashes occurred at about 1:45.000 (scale). Strangely enough this, was not repeatable when not using the debugger ?? It looks very much like the linux bug I have reported earlier, and that ever was resolved.
And what about CM93. The result of my brief checks on six different places showed no consistency what so ever. What Dave said. There is no good solution to the problem. Just don't trust CM93 without checking other sources of information.
Linear Mode
Recent Discussions