OpenCPN Version 2.1.0 Beta

[idpnd]

Could it be blurry due to the angle of reorientation under chart up mode?

[bdbcat]

gaea....

Thanks for the input.

idpnd is correct. The current Beta uses a low definition rotation method for better performance.

Next Beta will use higher definition, but may be too slow for mouse dragging. Should be OK for boat-follow mode, though. We shall see....

Thanks
Dave

[manimaul]

Originally Posted by bdbcat

gaea....

Thanks for the input.

idpnd is correct. The current Beta uses a low definition rotation method for better performance.

Next Beta will use higher definition, but may be too slow for mouse dragging. Should be OK for boat-follow mode, though. We shall see....

Thanks
Dave

In the future, perhaps a caching mechanism could be employed here to improve drag response and chart display.

[Ptizef]

Originally Posted by manimaul

I'm wondering if part of the perfomance issues is because of being zoomed out too far where whole charts are scaled down to the size of a stamp.

Perhaps we should automatically change chart scale within a set percentage of truescale so this doesn't happen. I'm thinking -.25x to +4x. Any ramifications for this?

This would clean up the display in this situation also.

Hi All
I don't know if it's the solution but certainly there is something to do around this :
In test2 picture attached I zoomed + until I got an over zoom : Opencpn did'nt choice the right chart to be displayed
Then I zoomed - and opencpn hanged for a while ( test3 picture and after some seconds , picture test4)
If I click on the larger scale chart bar , then I can't zoom - more than picture test5 , and after opencpn use 50% of the CPU without doing nothing (picture test6)
In conclusion there is a probleme with the selection of the charts to be displayed and the relation between the true scale and charts displayed

Jean Pierre

[idpnd]

Opencpn did'nt choice the right chart to be displayed

Sorry to +1 this, but that's what I meant by "quilting aggressively" above, sometimes I can zoom into an area where smaller scale charts are present (but not included in the quilt) until I end up with a couple of very large pixels as in the example above.

Pressing the relevant chart tab button (usually the most detailed one is on the far left) causes the programme to re-evaluate the situation and -usually- build the correct quilt.

[bdbcat]

Ptizef, idpnd, et al...

The behavior you report is by (current) design.

The quilt control bar allows you to select the largest scale chart available at the viewport from which you wish to begin quilting. I call this the "reference chart". Quilting proceeds from large to small scale, (left to right).

If you choose a smaller scale chart to start the quilt, then charts of larger scale won't be displayed on the quilt, even if available..

This selection does not change when zoomin in or out. Overzoom is permitted.

We could change this, of course. Something like this, maybe:

On zoom-in, if the reference chart (left most hilight in the control bar) is overzoomed by xx percent, then Automatically change the reference chart selection to the next larger scale, if available.

On zoomout, if the reference chart is underzoomed by more than yy percent, change the reference chart to the next available smaller scale, and re-evaluate the quilt.

I think this would get Ptizef's desired result, although it might not be completely reversible on successive zoomin/zoomout....

This is somewhat similar to the Toolbox->Etc->Preserve Scale option in SingleChartMode. They could be coupled....

Its a design issue, and comments are certainly welcome.

Dave

[idpnd]

Here's the symptoms I'm experiencing:

Situation in the left screenshot:
When I start zooming in on a particular section of these French BSBs, the initial quilt is never modified, i.e. I am stuck with the initial chart down to the pixel level, although technically there are better charts for this zoom level. In this screenshot, my mouse is hovering over the far left chart tab with the popup showing the inactive, but more appropriate detailed chart for Les Usines in the centre. This chart is only "on offer" when it's location is in the centre of the screen.

Situation in the right screenshot:
Left-click on the far left chart tab has caused opencpn to compute the new quilting mix appropriate for that zoom level; the detail chart for Les Usines has been inserted. Note that the main chart for the area has also been changed to a more appropriate scale. When zooming out, the quilt pretty much stays the same. Panning actually gets a bit slow with this mix. The tabbed interface is really good news, as I can influence the quilting mix on the go, and I'm not entirely dependent on the algorithm.

(Uneducated) complaint:
The fact that the quilt uses an appropriate overview chart initially is actually rather advantageous in terms of computing power required, but in this situation it just "sticks with it" stubbornly.

Same as Jean Pierre above:

In test2 picture attached I zoomed + until I got an over zoom : Opencpn did'nt choice the right chart to be displayed

Detailed inlay charts are usually loaded when zooming into them with "zoom to cursor" (but not in this case) and the main chart is never swapped for the more appropriate one.

Possible design idea:
That's what I meant by more "aggressive" quilting - the behaviour would be more user-friendly if the software were to invest a few processing cycles to re-evaluate the quilting mix occasionally, perhaps as per your (Dave's) ideas.

Bit of a babble, I do find it hard to describe, sorry

[Ptizef]

Dave,Idpnd

Thanks for your answers.
I understand it's a disigned issue and yes the quilt control bar is
a very good tool , allowing the user entirely controlling algorithm
Personally , but off course it's only my point of view , I would have preferred a slightly more "automatic" algorithm , while keeping control on it.
regards
Jean Pierre

[gaea]

Originally Posted by idpnd

Could it be blurry due to the angle of reorientation under chart up mode?

I just turned off course up mode and it improves the picture a lot, turned it on and it is blurry again.

Gerard

[idpnd]

Hello Gerard,

see above, its blurry due to the way the chart is displayed in chart up mode, expect some improvement in next beta.

[gaea]

Originally Posted by idpnd

Hello Gerard,

see above, its blurry due to the way the chart is displayed in chart up mode, expect some improvement in next beta.

Yeah, that's what I confirmed.
Course up mode is not very useful without 'radarmode' anyway. (See my posts in 'feature request' thread)
I have to zoom in at least 1:10000 to see enough detail.
Then I can't see far enough ahead of the own vessel.
A 22" monitor in portrait mode is quite useful here.

Gerard

[ozjon69]

OpenCPN.txt formatted to read in Notepad in minimised window size.

Hi Guys,

A Great Programme!
I now use it at sea in preference to "C-Map" and "MaxSea"
Congratulations and thanks to the authors!

I've just downloaded 1.3.6 and 2.1.0 beta. Haven't used them seriously at sea yet, but I've noted a few remaining "bugs/improvement possibilities" while my boat is at anchor.

1) Tide display still shows "today"/"tomorrow" every 7 days (past and future) from the current date. Trivial, but a bug!

2) My copies don't show any additional "currents" beyond the CM93 chart info when I click the "currents" button. Maybe I need to download another file with "currents" data? Where can I find that file?

3) My older (pre 1.3.6) version either stopped GPS updating/plotting boat position at low boat speeds(<3kts?) or only updated/plotted intermittently. This is a bad feature - is it a bug?. Up-to-date position plot is particularly important when slowly entering harbour or confined spaces. I haven't yet tested versions 1.3.6 or 2.1.0 beta while moving to see if that (bug?) remains.

4) I note that you have fixed the measurung accuracy problem. Works well now. Automaticaly changing units from decimal miles to metres for short distances was a good idea - Well done!

5) Improvement? - The right-click "move boat here" function restores too quickly to be very useful. Suggest increasing dwell-time - or better - change the command to "show/hide boat icon" with default "show".

6) Improvement? - Add a "lock/release marks" facility with default "locked" - This would prevent accidental moving of marks while clicking to centre/zoom-in the display. Happens to me frequently when zooming in and re-centring from large-small scale. You have "lock/release waypoints" facility already - same facility for marks would be good.

7) Improvement? - add an "undo" button. If you do something wrong now its "too bad" the info is lost - no recovery available!

8) I haven't yet found an "anchor alarm" facility in these latest versions - That would be a very useful additional feature if it output an alarm condition (active Hi/Lo) on an I/O pin or output sound on a headphone jack so that an external "loud alarm" could be implemented.

In summary - a great little programme! - but, as with all software, there is "always 1 more bug" and "room for improvements"! Not too many improvements though, please! - it's KISS concept and obvious intuitive operation is a great feature!

Regards, John Macey <ozjon69@yahoo.com.au>
sv Andiamo IV, Melbourne, Australia (currently anchored at Cairns)

ps. Re my 8) - I now see from this forum that a windows (Vista) patch is needed to implement this - where can I get it?

[idpnd]

Hello ozjon,

1) Tide display still shows "today"/"tomorrow" every 7 days (past and future) from the current date. Trivial, but a bug!

Wow! a bug! Leave this one to the experts.

Originally Posted by ozjon69

2) My copies don't show any additional "currents" beyond the CM93 chart info when I click the "currents" button. Maybe I need to download another file with "currents" data? Where can I find that file?

You are limited to the dataset at hand, I don't believe AU publishes any freebies.

3) My older (pre 1.3.6) version either stopped GPS updating/plotting boat position at low boat speeds(<3kts?) or only updated/plotted intermittently. This is a bad feature - is it a bug?

The software is entirely dependent on gps data, it does not modify the data in any way. Perhaps the gps has an excessive damping factor. Please compare to other software such as Seaclear to see if problem remains.

5) Improvement? - The right-click "move boat here" function restores too quickly to be very useful. Suggest increasing dwell-time - or better - change the command to "show/hide boat icon" with default "show".

I assume you mean restored by incoming gps data? Move boat here is really supposed to be used for testing purposes when no gps is available.

8) I haven't yet found an "anchor alarm" facility in these latest versions ... ps. Re my 8) - I now see from this forum that a windows (Vista) patch is needed to implement this - where can I get it?

There's one being tested for 2.1.0, thread here.

Improvement?

These are tracked at sourceforge. Note that a lot of daydreams are being added all the time and there's very few programmers around..

Enjoy

[MarkJ]

I don't know if this is a bug.

I am using th elatest Version 2.1.0 Build 501 on WIN7

Previous versions of OpenCpn havent had this problelm:

Google Erath and OpenCpn seem to be having a bit of a fight. I can't get a GPS multi port thing to work with my Garmin 76cx so I have to turn off Opencpn and then get the GPS working on Google Earth and visaversa.

This newest version they seem to black out both programs when changing the GPS between them.

As I said I don't know if its a big problem on not.

Could OpenCpn share GPS's?

Mark

[idpnd]

Hello Mark,

what do you use for sharing the GPS? Have you tried navmonpc or Polarcom?