Opencpn 4.1.1108 Documentation

[.Paul.]

Rick,

OpenCPN Beta test 4.1.1022 Release

contains Changelog items 63 through 77.

Paul

[bdbcat]

Rick....

The Changelog is in the first post of each Beta Release thread.

But, to make sure you have it in one place, here it is:

Starting from O4 Release...

Changelog
1.   Implement configurable waypoint range rings  (FS#1560)
2.   Implement configurable NMEA Talker ID  (FS#1557)
3.   Harmonize autopilot APB and XTE precision settings to be the same always.
4.   Improve 2-bells audio file. (FS#1673)
5.   Correct to disable selectability of hidden AIS targets.  (FS#1666)
6.   Grib:  Add Fixed spacing option for arrows and numbers.
7.   Grib:  Correct data interpolation error at 180 E/W longitude.
8.   Grib:  Improve email request dialog to allow requests crossing 180 E/W longitude.
9.   Correct dialog text for magnetic variation sense.  (FS#1694)
10.  Add extended AIS Aton rendering according to IEC6228_Ed2.
11.  Make initial page selection on options dialog more consistent in GTK.
12.  Correct ENC UWTROC, OBSTRN,WRECKS visibility in Base and Standard modes. (FS#1717)
13.  Correct uninitialized member causing crash on DSC message with incorrect checksum(FS#1697)
14.  Correct to ignore DSC messages with "Unspecified" position (FS#1711)
15.  Correct VERCCL and VERCOP height decode and rendering on ENCs (FS#1704)  Thanks TransmitterDan
16.  Correct to ignore invisible marks on selection/query (FS#1670)
17.  Correct keyboard accelerator logic for WXOSX (FS#1698/1655)
18.  Correct RouteProperties dialog to "Stay on top" for WXOSX build (FS#1698)
19.  Correct help launcher on wxWidgets 3.x. (FS#1702)
20.  Correct uninitialized variables (FS#1679)
21.  Correct for "GD=" missing datum in KAP chart header. (FS#1683)
22.  Correct depth unit display for BSB charts with KNP/...UN=METRIC (FS#1654)
23.  Correct cm93 failure to show some soundings on keyboard pan (FS#1689)
24.  Correct automatic route creation properties on MOB event (FS#1699)
25.  Improve toolbar tooltip placement for right-located toolbar. (FS#1657)
26.  Correct datum initialization for quilted non-WGS84 charts in OpenGL mode. (FS#????)
27.  Correct occasional linux focus loss (FS#1684)
28.  Preserve visibility attributes for GPX files originating from OpenCPN (FS#1667)
29.  Improve formatting of S57 object attributes as decoded  (FS#1713)
30.  Correct ENC SENC file creation math for ARMHF systems.
31.  Implement quilting of skewed raster charts in OpenGL mode.
32.  Implement manual/timed automatic toolbar hiding option.
33.  Update Windows build tool to VS2103
34.  Update Windows wxWidgets version to wx3.0.2
35.  Implement automatic reload of updated PlugIns by visiting options->Plugins screen.
36.  Improve GUI for GRIB PlugIn, better fitting the small screen.
    https://github.com/OpenCPN/OpenCPN/pull/270
37.  Correct duplicate routepoint delete logic, FS#1743
38.  Correct for inadvertent waypoint dragging on double-click (FS#1748)
39.  Correct route line width in selected and activated modes. (FS#1735)
40.  Correct ownship predictor rendering when ownship is off-screen (FS#1754)

Release 4.1.602

41.  Improve RouteManagerDialog sizing and rotation behavior. (FS#1757, FS#1755)
42.  Correct DC mode HPGL vector symbol rendering with wxGraphicsContext active.
43.  Correct quilt operations on highly zoomed skewed quilt regions.
44.  Correct shutdown process to avoid accessing PlugIn chart orphans.
45.  Correct AIS target age logic when DST is active (FS#1809).
46.  Correct rotated clip region calculation when using depth-buffer clipping. (FS#1801)
47.  Fix Grib Particle Looping (FS#1794)
48.  Correct XML Changes file handling on crash restart and point dragging.  (FS#1824, FS#1785)
49.  Correct console canvas location for alternate compass layouts. (FS#1851)
50.  Correct OpenGL options "accelerated panning" initial value.
51.  Implement greatly improved mipmap generation algorithm using SSE intrinsics where available.
52.  Improve cm93 zoom logic to show more detail where desired, especially small islands in a big sea.
53.  Correct chart group logic for similar chart file location prefix. (FS#1060)
54.  Improve OpenGL raster cache build time by optimizing progress dialog updating.  Thanks, did-g.
55.  Add filter string control to NMEA debug window.  Thanks Sean.
56.  Add support for mingw compiler on Windows.
57.  Correct rendering of TSS arrows in DC mode (FS#1858)
58.  Correct CenterView dialog text edit control behaviour on Windows (FS#1765)
59.  Correct textual description for AIS Target Status 11 and 12 (FS#1848)
60.  Correct waypoint icon selector dropdown size on MSW (FS#1815)
61.  Correct initialization of UserIcons ownship preference. (FS#1769)
62.  Improved support for accurate polyconic and Transverse Mercator projection rendering.

Release 4.1.925

63.  Correct and extend Raster Chart PlugIn API for revised OpenGL access methods.
64.  Correct active track rendering logic to Ownship.
65.  Correct cm93 region and detail level calculation logic around Longitude 0.
66.  Correct longitude grid text rendering on OpenGL.
67.  Correct occasional loss of toolbar during mode switches and dialog access.
68.  Improve sectored light rendering performance on Windows OpenGL systems.
69.  Correct Vector chart PlugIn rendering methods.
70.  Implement GUI scale factor for toolbar effective on all platforms.
71.  If specified, require NMEA checksums to be valid before sending sentences to PlugIns.
72.  Correct initialization of Polyconic charts without embedded georef coefficients (FS#1866)
73.  Modify AIS SART target acknowledge timeout policy to honor global ACK timeout (FS#1856)
74.  Correct AIS Target Query dialog sizing logic
75.  Correct Grid text formatting for "degree" symbol (FS#1870)
76.  Extend PlugIn API for Waypoint list access.
77.  Correct Dashboard context menu actions when multiple dashboards are defined.

Release Beta 4.1.1022

78.  Add Follower/Buddy to MMSIEditDialog to suppress AIS alert.
79.  Correct occasional loss of reduced toolbar on chart stack change.  Thanks, Chuck.
80.  Correct memory corruption on high overzoom DC mode raster chart rendering. (FS#1885)
81.  Correct memory leaks on SENC file creation.
82.  Improve AIS Alert Dialog sizing algorithm.
83.  Suppress some un-necessary log error messages on exit.
84.  Correct polyconic & transverse Mercator chart outline calculation method.  (FS#1882)
85.  Correct operation of Anchor Information hotkey ("A") in vector chart display.  Thanks nkiesel...
86.  In Responsive mode, set basic toolbar tool and compass size to 6 mm nominal.
87.  Correct chartbar switching behavior on touch enabled configurations.
88.  Re-enable install log on MSW Installer Package.
89.  Correct toolbar submerge grabber logic in various cases.  Thanks, chuck.
90.  Refactor to allow building with USE_S57=OFF (FS#1903)
91.  Correct some formula errors in georef transforms.  Thanks, juehoe..
92.  Correct IENC zoom/pan behavior at very small scale.


Release 4.1.1108


91.  Correct config file location for portable (-p) operation.
92.  Fix uncompensated skewed chart display. (FS#1904)  Thanks Chuck.
93.  Correct cm93 quilt logic in OpenGL for some especially complex situations.
94.  Correct rendering of disjoint, large scale S57 cells.
95.  Implement mag variation calculation at object location if WMM is available.
96.  Update Authors list, adding Didier Gautheron.
97.  Correct Windows Generic GDI OpenGL driver initialization.
98.  Improve DUSK/NIGHT color presentation by eliminating bright decorations.
99.  Correct display of very long routes (FS#1896)
100.  Implement scaled icons for Settings top icons in responsive mode.
101.  Handle NMEA V4 messages with prepended tags.
102.  Re-enable ability to add a single chart to a group.
103.  Improve initial responsivness of Option dialog.
104.  Modify OpenGL texture logic to support non-compliant MSW "GDI Generic" driver.

Thanks again
Dave

[.Paul.]

Rick,

OpenCPN Beta test 4.1.925 Release

contains Changelog items 41 through 61.


Paul

[rgleason]

Great, thank you both.
We have a pretty clear task ahead now, and its probably not as hard or difficult as it may look. Who will give us a hand? Together we can get this done with relative ease, and with a little experience, Thomas will have some guys he can depend on, and a team that shares the load and keeps the document at a high standard.

That was the first thing I looked at when I found OpenCpn. It impressed me and I knew this was not some sloppy software effort, as I used the program I became more impressed.

So lets keep the tradition as Thomas did.

[rgleason]

If I can find two other editors who will join me and do twenty items on the list, I will do items 1-20 notations on doc changes needed and I will actually complete the changes in the documentation. If I have two volunteers by tomorrow morning I will start tomorrow.

[rooiedirk]

@Rick
I'm not much of a writer, but I can add some pictures. (And a picture is a thousend words)
Almost forgot I had still point 10 on the change log.
First picture all possible AtoN's. From top, Real, Real off position, Virtual and Virtual off position. Where Virtual off position in practice is a bit impossible.
Dirk

[Littlechay]

I would like to help, but there are two major factors.

The current beta is not stable enough to use for real navigation, therefore I don't/can't.

Currently I have occasional internet via cellphone but offshore I use sailmail.

Git, wikis etc are not practical for me to use.

Perhaps some kind of email reflector / repository / collector could be set up so that suggested texts could be email in for final editing by somebody with internet?

I'm working on some techniques for making charts from Landsat images that is simple and effective that is one thing that I'd like to contribute to the general manual.

Once there is a more stable version of the beta available I can run it help with general editing .

Chris
--
http://www.tweedsworld.com


Sent from my iPhone using Cruisers Sailing Forum

[rgleason]

Chris thank you for volunteering. As you find document sections which need improvement we could have you email the original text and the changes below that, with the information for where in the outline the section should be placed.
Right now I am trying to determine an email address.. I could give you mine, but others should have access too. Also others who are sailing may want to use this address. Perhaps it should be a running page of comments on the website that we all could refer to? Titled something like "Opencpn Document Revision Submittal"

Perhaps someone could set that up for us? So it would accept sailmail? Would we need some way to authenticate with user and pass ? Perhaps use the auth for opencpn website? Or is that a big problem for sailmail? Yes I think so. --Need ideas how to do this.

[bcn]

Originally Posted by Littlechay

Currently I have occasional internet via cellphone but offshore I use sailmail.

Git, wikis etc are not practical for me to use.

Perhaps some kind of email reflector / repository / collector could be set up so that suggested texts could be email in for final editing by somebody with internet?

Chris

One thing we can do is to create an e-mail account at o-charts which acts as a simple mailbox. Incoming mail gets then automatically forwarded to the "guardians of the Wiki" as members of a mailing list.

Feedback to the authors or requesters should be done directly with the option to cc to the OPCN-docu mailbox to keep the rest of maintainers of the WiKi informed.
Would need to define the list of maintainers and to forward us the corresponding mail addresses. We would maintain the list then on request.

Would this help?

Hubert

[rgleason]

Hubert, Yes this would be great. We need a list of volunteers now.

Could they opt in to be a "Wiki Maintainer" and add it to their profile on the opencpn.org website?

Could we have a list of "Wiki Maintainers" somewhere on the website?

Maybe we could have a simple link to sign up as a "Wiki Maintainer"?

This would really help get a team going.

[Roel Smidt]

Originally Posted by rgleason

We need to be systematic.

Rick, I am no editor and know virtually nothing about programming and HTML but I agree about the "systematic" bit. And of course the ideas of standardisation of screenshots and other illustrations. But I think we should also try to keep things simple textwise. Especially as English is for me (and for a lot of other O-users) a foreign language.

I have put my thoughts (focused on the pi-documentation) in the attached document. Can that be of any help? Feel free to dismiss it!

@Aart K.: Aart, I'm willing to take on the Draw-pi also (for translation into Dutch). It might be handy to exchange thoughts/ideas in Dutch. As we can't do that on this forum I suggest we exchange via PM. OK with you?

Roel

[rgleason]

Roel,
First of all your english is far better than my Dutch, and it is fine.
Secondly, I like your outline and would heartily support that format.

I think we should put your Recommended Outline for Plugin Documentation in the Wiki somewhere for reference.

I thought Thomas had written an introduction to working on the Wiki, but I can't find it from opencpn.org. Does anyone recall where that was posted recently? Maybe we should add to

• Opencpn Manual
• Developer Manual
• Supplementary Hardware
• Supplementary Software

another entry called "Manual Guidelines" where we can add these types of things?

Also I will try to get WatchDog and Ocpn_Draw into that format.

[wdkester]

I would like to help with documentation. But what I don't know is overwhelming!

Random thots-

1. Change log items that start "Correct" have little explanation and may (or may not) effect documentation.

2. Change Log entries with no FS# may require lots of exploration.

3. I don't know how to compile, so I would need to download the latest compile to see a feature in order to document it.

4. I think the text is in HTML. There are several markup editors for HTML. Would it enhance the process to pick one and organize around it?

5. Given a section of the documentation, I would :
a. Check the change log
b. Exercise the latest compile in the relevant area
c. Markup changes to text and submit to editor
6. There need to be guidelines for nits. e.g. I think the Safety depth check box should be Safety depth contour; because that's what happens.

Have I said enough to disqualify myself?

[bcn]

David and al.,

it is really not required or even recommendable to adopt the documentation to every daily build.
We all know that sometimes changes will disappear again for example.

The documentation at opencpn.org should reflect the latest official beta, so there is a) always plenty time to explore new or modified functionalities and b) no need to compile on day by day schedule.

Anyhow: Rick or Håkan are always sources to get the latest build if somebody has not access to it.

One can edit the WiKi directly, just logging in.

So - no valid excuses as far I can see

And happy new year for everybody

Hubert

[rgleason]

wdkester wrote:

Random thoughts-

1. Change log items that start "Correct" have little explanation and may (or may not) effect documentation.

2. Change Log entries with no FS# may require lots of exploration.

3. I don't know how to compile, so I would need to download the latest compile to see a feature in order to document it.

4. I think the text is in HTML. There are several markup editors for HTML. Would it enhance the process to pick one and organize around it?

5. Given a section of the documentation, I would :
a. Check the change log
b. Exercise the latest compile in the relevant area
c. Markup changes to text and submit to editor
6. There need to be guidelines for nits. e.g. I think the Safety depth check box should be Safety depth contour; because that's what happens.

Have I said enough to disqualify myself?

No you have not, in fact disqualified yourself, I hope you join us in the effort. You are thoughtful and careful.

I try to have a reasonably current version in Opencpn Beta File Thingie if possible (Pavel's version takes precedence, depending on your purpose).
If we are updating the manual to Pavel's version, that's probably the best one for you to use. If you are testing new work, the more current one is best.

1.& 2. Change Logs are an excellent way to determine potential changes to documentation. Yes, many items are just under the hood improvements, bug fixes. Looking in Github at the Closed Issues could also be a way to learn more about a particular Change.Log item in addition to Tracker FS#.

3. No need to compile.

4. The HTML markup tools and editor are built in to the Editing mode and they are quite simple and useful. No HTML knowledge is necessary, but occasionally it is useful. However it is not necessary.

5. Yes, there are two tracks to editing the manual as I see it:
The way you outline here - Sequentially through the whole documentation and checking it to the current beta program.
The other way is using the Change.log to identify any Screenshot and Interface changes.

Both ways are valid and both tracks should be followed. This means two methods and approaches.

Yes, we need you on the team! Thank you WD. Pick either approach, but I would suggest that if you would do the one you outlined in #5 that would be great.