Contribution to OpenCPN Development

[1000 islands]

Sorry to be so stupid, but what exactly is CPN?

[JesperWe]

Originally Posted by rolker

Is this an issue where merge vs rebase might make a difference?
.....
I'm worried that a future pull request from my branch will result in similar commit issues as encountered by Registry. Any git gurus can shed some light on how to avoid such problems?

In my experience it is much better to update your underlying master by "git pull origin/master --rebase" or similar. This avoids the extra "Merging bla bla bla" commit.

...and by the way, CPN is short for Chart Plotter Navigator.

[registry]

Hi Jesper and co,

so, another try to pull a request.

I've placed a new pull request with a name "Adding the "routeplanning": printing a route as a table with list of waypoints and their description" .

It containst a single commit, where are only my changes as a diff visible. It is not a synchron with the HEAD of OpenCPN/master , but i guess, it is not needed by git.

Please tell me, if i messed up something again. Or comments to change something in code.
I'm open for any kinds of comments.

Cheers,
Registry

[JesperWe]

Your new commit looks much better in terms of Git use. An understandable commit name and the correct content. Been in sync with the current HEAD is not important here, what is important is that anyone can now cherry-pick your commit on top of any HEAD position.

So next step: You are not following the Code Formatting guidelines very well. Note also the section on comments.

Look for example at something like:

/// Target height
int height;

- Why three slashes? Use two.
- Why a comment at all? If you feel it is not clear from the name of the variable what it is used for, then change the name of the variable, don't write a comment:

int targetHeight;

Your code also has lots of commented out dead code. We do not want that. Git takes care of telling us what was deleted by your patch.

[registry]

that is good news for myself, that i managed the correct pullrequest.
Now i will bring the code to the needed form.

Step by step, i get closer....

Thnx for help and
cheers,
Registry

[rolker]

For everyone's learning enjoyment, here are the mistakes I made and how I fixed them when submitting a pull request.

The first mistake I made was to make changes and commit to my local master branch instead of creating a feature branch. The changes I made (fixing some AIS TCP code) never got submitted since I learned about that functionality getting re-written. I then did a few pulls to update my master branch, and I needed to merge and commit to complete those.

Now, I wanted to add another feature, so to avoid my first mistake, I now created a branch to do so. I still made a mistake I here by creating my ais_an_query branch off my master, which already contained commits. In my defense, I did need the TCP code I had fixed to test my new code.

The next mistake I made is submitting a pull request from my ais_an_query which included the commit I was intending to submit, but also the previous unsent commits including some merges.

Here's how I fixed it:

Since my master branch no longer reflects the upstream master, I renamed it ais_tcp so I wouldn't loose those changes.

git branch -m master ais_tcp

I then re-fetched the upstream master branch

git branch master upstream/master

To push my fixed local master to my fork on github, I needed to use to force option.

git push -f origin

Now, I'm ready to start a new clean branch with the purpose of submitting only my last commit to my ais_an_query branch.

git checkout -b ais_an_query_submit master

Now, here's the magic part, cherry picking the commit I want. First, find out it's id.

git checkout ais_an_query
git log

Copied the commit id (the long hex string) from the output. Switched back to my new branch and cherry picked the commit.

git checkout ais_an_query_submit
git cherry-pick (id copied above)

The last step is to push it up to github.

git push origin ais_an_query_submit

The result was a branch I could submit cleanly as a pull request.

Now, the above shouldn't be followed as a series of steps for submitting code to OpenCPN, I'm just sharing it as an example of how to fix your local fork if you happen to have made similar mistakes as I did.

From now on, if I properly understand how this all works I should follow a few rules.

Don't commit or merge my branches into my master. I should only use master to pull and rebase from upstream!

git pull --rebase upstream master

Create a new branch for a new feature from my untainted master branch. Don't try pulling new changes once this is done.

Any other tips?

[JesperWe]

Originally Posted by rolker

....
Don't commit or merge my branches into my master. I should only use master to pull and rebase from upstream!

git pull --rebase upstream master

Create a new branch for a new feature from my untainted master branch. Don't try pulling new changes once this is done.

Very good tips and great writeup!

I'll just add that as long as you "pull --rebase" you are quite fine pulling new changes from master, since your new work will be rebased on top of the newly pulled commits.

You will then need to force push to your github repo, but when you "Pull request" that branch, it will only issue a pull request for the commits that differ from OpenCPN/master, which is still just your original commit.

[JesperWe]

Another trick that I use often is this: Let's say you have a branch to develop some new or changed feature called "newstuff". It's a good habit to commit often as you are developing, so in the end when you are satisfied with your new code you have a branch with maybe dozens of commits.

Now, to make a nice single cherry-pickable commit you want to create one commit that contains all of those development steps, one commit which has all the differences between master and your current code.

To do that:

1. Create a new branch from master, let's call it "newstuff1" and check out.

2. Do a reset --hard to the last commit of your "newstuff" development branch. This puts your index and development tree in the state of the latest code for the new feature.

3. Do a reset --soft to the last commit of master. This makes git think your branch is on master, but leaves your index in the latest code state.

4. Commit your current state, giving the new commit a good name describing the new feature.

Newstuff1 now has a single commit on top of master with all your changes. This you can push to github and pull request, or just send a mail to other developers to alpha test if you want.

[registry]

Hi Jesper and others,

after some struggeling with git slowly i get an idea how it works...

Now i've changed code style formatting (use published on opencpn.org beautify.cfg for uncrustify tool) , removed doxygen tripple /// comments (although, they are present in other parts of OpenCPN source)....

I didn't know, that i could change things without removing pull request... So, i closed previous one and opened another "Added printing of the route as a table for route planning"

I hope, now it is better and i'm closer to merge into trunk, so i can proceed developing...

If im not wrong, if i perform now some changes in this branch, it is automatically updated for pull request and i dont have to remove it (pull request) and create again?


Cheers,
Registry


PS. Sometimes i think that i have to make first all possible errors and mistakes before i do it on right way.... what mistake is next... ? :-)

[registry]

Hi 2 all,

i'm wondering, what is now decision about my pull request? No one is interessted in this feature?

Cheers,
Registry

[registry]

Hi 2 all,

ok, my first pull request went through....

Now i proceed with developing of the "Route planning" part.
Having printed route with instructions for the watch officer is helpful.

Now is another situation: approach to marina by night. On charter boats plotters are usually(very often) inside of the boat and not in cockpit.
While navigation to the marina it is important to control and see all navigation lights and passed buoys.
For that one compares passed buoy number with the checklist. Having chart inside of the boat makes skipper either to run all the time there and back, or to scream to helmsman.

Better, if and as usually it is done, one has the printed table for every approach with the list of buoys and their numbers, position, lights and check marks.
If one passes one, one marks. If one is missing -> slow down and control.

I would like to extend a waypoint property by "Part of approach" and " Name of approach" ( harbor name for example).

While route print out they are listed grouped in separate table with checkmark column and name as a approach title. This printout one can have in the hand while navigation.

Additionally it is useful to load and have printed picture of the harbor of interest. For that one can use property "link" of the Waypoint.
I would just extend it so far, that OpenCPN loads a picture and stores locally as a file. While printout this image is used as preprint or postprint for the approach table.
( For example see here:
Rudkøbing S12/12 | nv-pedia
or
http://www.nv-pedia.de/pedia/files/i...rahmen.rcw.png
or
OpenSeaMap: Startseite
)

On such way one has the picture of the harbor right in the hand.

For that i would need to extend content of the GPX export file content by two fields: isApproach and ApproachName.

What is the policy of OpenCPN developers in such case? Is GPX format fixed or flexible and can be extended easily?

Do i have to sync with someone if i make changes of such kind?

Cheers,
Registry.

[nohal]

Originally Posted by registry

For that i would need to extend content of the GPX export file content by two fields: isApproach and ApproachName.

What is the policy of OpenCPN developers in such case? Is GPX format fixed or flexible and can be extended easily?

GPX format is flexible in this matter and we already use this feature - have a look at navobj.xml where the <extensions> tag is used for all the objects for OpenCPN specific metadata. More info in the format specs at GPX: the GPS Exchange Format

Do i have to sync with someone if i make changes of such kind?

Basically it's wise to let Dave know about big features and core changes to avoid merging headache...
I have a long standing wish to revisit the GPX code once again so that we handle well even the third-party <extensions> to the gpx format which we currently simply ignore and throw away on load. The next step in this plan is to expose the navobjects in the plugin API - if it's done, even bigger features like the one you plan won't have to change the core at all... What I really don't know is how much time and when I will be able to devote to it If someone was interested in working on this or at least using the functionality, I would definitely try harder

Pavel

[bdbcat]

registry/pavel...

The extended Route Planning interface should definitely be a PlugIn. It is way too specific a use-case for inclusion in the core., although surely useful to some navigators.

I stand ready to implement new PlugIn APIs to support this and other PlugIn proposals.

Dave

[oem]

Originally Posted by registry

Hi 2 all,

ok, my first pull request went through....

Now i proceed with developing of the "Route planning" part.
Having printed route with instructions for the watch officer is helpful.

Now is another situation: approach to marina by night. On charter boats plotters are usually(very often) inside of the boat and not in cockpit.
While navigation to the marina it is important to control and see all navigation lights and passed buoys.
For that one compares passed buoy number with the checklist. Having chart inside of the boat makes skipper either to run all the time there and back, or to scream to helmsman.

Better, if and as usually it is done, one has the printed table for every approach with the list of buoys and their numbers, position, lights and check marks.
If one passes one, one marks. If one is missing -> slow down and control.

I would like to extend a waypoint property by "Part of approach" and " Name of approach" ( harbor name for example).

While route print out they are listed grouped in separate table with checkmark column and name as a approach title. This printout one can have in the hand while navigation.

Additionally it is useful to load and have printed picture of the harbor of interest. For that one can use property "link" of the Waypoint.
I would just extend it so far, that OpenCPN loads a picture and stores locally as a file. While printout this image is used as preprint or postprint for the approach table.
( For example see here:
Rudkøbing S12/12 | nv-pedia
or
http://www.nv-pedia.de/pedia/files/i...rahmen.rcw.png
or
OpenSeaMap: Startseite
)

On such way one has the picture of the harbor right in the hand.

For that i would need to extend content of the GPX export file content by two fields: isApproach and ApproachName.

What is the policy of OpenCPN developers in such case? Is GPX format fixed or flexible and can be extended easily?

Do i have to sync with someone if i make changes of such kind?

Cheers,
Registry.

Hi Registry.

Interesting ideas you have :-) It's always critical to approach whatever destination you have, especially unknown harbours. .

But I think it's fair to classify your ideas as a plugin as Dave does, since the main reason for your functionality seems to be that there is no plotter with charts visible to the helmsman. If I understand you correctly?

If charts, - including geocalibrated harbourplans (like the ones for Rudkøbing), were available to the helmsman on a plotter, then there would be no problem. He could see his position directly on the chart, showing the approach to Rudkøbing e.g. (I know that harbour btw :-).

Now I have a plotter right in front of me in the cockpit, as helmsman. And I would guess that many others would have also. My problem is that I frequently don't have harbour-plans as geo-calibrated charts. Only as images.

Now my question: If you have all harbour plans as .KAP files, wouln't that make it easyer. Even when the helmsman does not have visible access?

I'm asking because I have been working on geo-calibrating all danish harbours, I'm about 50% through. But I have so far no sailing experience with then. Attached an example from Bornholm, Hammerhavnen.

[registry]

Originally Posted by oem

Hi Registry.

Interesting ideas you have :-) It's always critical to approach whatever destination you have, especially unknown harbours. .

But I think it's fair to classify your ideas as a plugin as Dave does, since the main reason for your functionality seems to be that there is no plotter with charts visible to the helmsman. If I understand you correctly?

If charts, - including geocalibrated harbourplans (like the ones for Rudkøbing), were available to the helmsman on a plotter, then there would be no problem. He could see his position directly on the chart, showing the approach to Rudkøbing e.g. (I know that harbour btw :-).

Now I have a plotter right in front of me in the cockpit, as helmsman. And I would guess that many others would have also. My problem is that I frequently don't have harbour-plans as geo-calibrated charts. Only as images.

Now my question: If you have all harbour plans as .KAP files, wouln't that make it easyer. Even when the helmsman does not have visible access?

I'm asking because I have been working on geo-calibrating all danish harbours, I'm about 50% through. But I have so far no sailing experience with then. Attached an example from Bornholm, Hammerhavnen.

Hi, oem

well, decision, whether this functionality should be a plug-in or a part of a core of OpenCPN should be done not by looking at frequency of possible usage, but if it is a essential part of route planning and navigation or not. If it is not such one and can be observed as the "nice to have" part - then it should be a plug-in... like Konni's Logbook ....

I agree that the crucial situation, when one would take advantage of it - is approach by night... but isn't a good habit, to minimize probability of an error in precisely the situation, when errors of navigation are more likely to happen?

My motivation is simple.
I'm planning now a more or less long voyage (2 weeks) with partly experienced crew. And i know that i will have to approach some, for me currently unknown, harbours at the evening and possibly at night.
I don't know, if my boat (i do charter one) has plotter in cockpit and how actual charts are.
But i know, that i will have a lot of stress, having only responsibility on me.
So, i try to arrange already now, during planning, things so, that i can do it easily, without unnecessary stress.

And i just don’t want to run there and back while approach (how i had to do it already couple of times). I want to be on deck and control approach, even if am not a helmsman (i'm the skipper :-) ).

So, how i learned from my teacher, well experienced captain with more than 40 years of sailing with idio... guests :-), that in precisely this situation one has to be on deck to control approach. And that is how he did it -> with a list of approach way points with check marks "passed or not".
So, that cannot be wrong. It is just a part of good seamanship.

That majority of sailors don't do that is not an argument...

I wanted to do it just using LaTex to make me a beautiful table... but it is more logical and comfortable to do it in an application, where i work with the route directly.... and i don’t have to change this table if i modify my route...



Another part of my motivation is that i want to prepare myself for sailing exam, where route planning is asked and checked. This is a part of SHS exam (in germany) and RYA Yachtmaster Offshore/Ocean (GB).

And if OpenCPN allows such level of route planning - that is only good for OpenCPN... especially because i like it and use it. And novices which did pass sailing exams will more likely choose OpenCPN for daily usage.

Here is the deal.
I will implement this missing part in my cloned repository (github.com: registry/OpenCPN) and ask everyone (well, important everyones...) to take a look. If afterwards developers of OpenCPN are still of the opinion, that that should be a plug-in... then that will be a plug-in... but i hope, one can do it with "little blood"... I hope to finish till end of this or next week (i'm not an expert neither in wxWidgets nor in OpenCPN...).




To your second question... I don't know for what .KAP files are good :-) I mean, i don't know, where they are used.... not an expert... so, i cannot answer that question.


By the way, i have still places on the boat.
So, if anyone from Germany or ... or not from Germany is interessted to sail along polish coast to Kaliningrad and back via Sweden and Bornholm -> just contact me and we can talk.


Cheers,
Registry