Routes
- are about the future,
- we want them as simple as feasible to get from A to B,
- rarely exceed one or two dozen points or so in practice (would be too optimistic for a sailboat),
- will not tolerate waypoint arrival too often,
- are hand-made
- routes should be safe.

Tracks
- are about facts from history,
- we want them as detailed as feasible to see where the boat was between A and B and when,
- run easily into thousands of points, still being useful and manageable,
- can be usefully recorded every couple of seconds
- are made automatically
- tracks should be real.

As the result, different things are expected from route and track management.
Yet very little needs to be done differently in the beginning.

I was just experimenting in this area and managed to tweak OCPN 1.3.6 into almost perfect (for me) behaviour.

I did the following (only a couple of lines of code changed, wonderful!!):

1. the Properties Dialog displays now -TimeToGo- for Route points, but -CreationTime- for TrackPoints
2. selecting a point inside the Dialog list highlights Route and Track points on the chart in the same way
3. for this to work nicely a Track is always created (and Exported) with mark type of "empty" rather than "xmred" (and "visible" rather than "invisible")

I experimented briefly with automatic conversion of tracks to routes, but dismissed this idea quickly: routes should be planned responsibly by a human, with accuracy, optimization, degree of hazard evaluation etc. appropriate to local situation. If a route is to be built along a recorded track, it can be easily done on the chart by hand, but for this...

4. I had to disallow suggested automatic re-using in routes of existing trackpoints (not a problem, just point to a place on the track as usual, with as much accuracy as needed, no questions asked). Isolated WPs behave as usual.

All this seems to work very well. I just have two issues left (there's always the last two, right?):
- a problem with currently open track - it crashed (once since the last build) on selecting it
- a problem with the same coordinates repeated in multiple trackpoints in the same track (still, they are part of the track; if the boat stays in the same place for some time, or swings back and forth at anchor... it is all history, potentially interesting, why lose this data?) - once I've seen strange 3-4 horizontal lines in the xmred colour across most of the screen.
I cannot reproduce any of them...

I handle simultaneously a couple of tracks 7000 points each without performance problems. A limit of 10000 points/track would not bother me, if the enforcement mechanism would be nice.

It seems this area was being addressed in the past, but the development effort moved into other direction.

I would be really very happy with just this behaviour. And if I could set tracks in a couple of different colours... And if the Properties Dialog would show speed (instead of distance) for each leg, and Named Waypoints passed on the way (in the empty name field)...

The great value of OCPN is the clear and simple user interface. MaxSea with all its power is impractically complicated and requires a lot of experience.

What do you think?

Piotr

RE: AIS & bells
I have the patch ready for displaying Pleasure Vessel type in AIS, but perhaps there will be more fixes to include. There is a 1-character change in the bells code already waiting.

I don't think Opencpn currently switches flexibly between waypoints. As one rarely actually passes the exact coordinates of a waypoint, I feel perhaps it should decide that one wishes to approach the next one once passed within a certain level of tolerance.

Quote:

And if the Properties Dialog would show speed (instead of distance) for each leg, and Named Waypoints passed on the way

Yes, wonderful, average speed for each leg. Perhaps it should still show distance for the legs. Correlation with the waypoints would be rather difficult, as above.. On top it shows "planned speed", hence "total time travelled as per planned speed x distance", it should say total time and average speed (as travelled) really..

Quote:

re-using in routes of existing trackpoints (not a problem, just point to a place on the track as usual, with as much accuracy as needed, no questions asked)

You are probably right about that one.. just zoom in on the track as far as necessary, then draw a route over the top, otherwise the software would have to decide where the key points are to cut down 10K tracked waypoints into 5 for a route.

I have a small but important request regarding the accessability of the queery box.
Presently it is not possible to copy any of the info. It would save a lot of time and
effort searching around for a pen and paper in a dimly lit cockpit if the contents
could be simply copied to the clipboard for addittional info searches in ship databases.

Another great feature would be a one line addition in the right-click box,taking the users to a small selection box containing a list of user-configurable links to his favourite URL's. This could also avoid cluttering OpenCPN up with programs slowing it down.

Do you have a Vista version ready configured I could download?

Thanks for your contributions and ideas.

__________________"And all I ask is a tall ship and a star to steer her by."

Thanks for trying! There's probably some more testing & review needed, and discussion as to the moored & Class B representation, that I have just chosen arbitrarily. Other points are rather straightforward to accept, I hope, except for the AIS icon, where I have unknowingly broken an UI design principle... As I said, it's only a proof-of-concept.

If the opencpn.log.log file exists when opencpn.log overflows, it will be overwritten, so older contents will be lost. Before this happens, the user needs to say YES twice to a warning dialog, and in normal mode the log does not grow that fast.

Hi Sinbad7...

I do not think there is a mechanism in this Forum for transferring a 4MB executable image, but I will email it to you if you send me an address. My email is in the readme in the patch, and I think there is also some messaging feature in the Forum.

Re: your requests I am afraid they are beyond my ability today, but it is a challenge... I also loaded wxWidgets and MSVC only after Mark posted his .vcproj file... thanks, Mark!

Cheers,

Piotr

PS.
For those who want to compile, I attach the source patch #2 for Pleasure Craft AIS display. It should be applied after the first patch in the same way to ais.cpp file.

...average speed for each leg. Perhaps it should still show distance for the legs. Correlation with the waypoints would be rather difficult, as above.. On top it shows "planned speed", hence "total time travelled as per planned speed x distance", it should say total time and average speed (as travelled) really..

Digging deeper, there are two kind of tracks, one logbook-style, coarse-grained (yes, written on the bell), and the fine-grained trail-style (written every, say, 10 seconds or configurable). The logbook log message will do for the 1st kind, with a little helper application to extract it and convert to GPX for viewing. Still, there are differences - for the fine trail the distance between points is just for curiosity, for the hourly trail - is equivalent to average speed. Total time travelled, exactly as you say...

Correlation with waypoints should not be so difficult if one keeps in sight only the handful of objects related to current voyage or analysis. The hundreds of other waypoints, routes and tracks should be stored (e.g. in GPX files or Route&Object Manager) somewhere outside...

Good tracks display is excellent for anchor watch, but let's see how the classical anchor alarm might work...

An anchor watch can be set on any isolated waypoint, lying not more than a fixed distance from own ship (I use 0.5 mile as fixed constant, in practice should be a ship-specific parameter).
Setting an anchor watch means that if own ship moves away more than xx meters from the waypoint, alarm is activated.
This defines a circular zone around the waypoint with radius of xx meters.

It is possible to set anchor watch on one or two waypoints simultaneously, but no more.
Depending on the position of centres and choice of each radius one can have a quasi-sector-shaped guard zone, narrow or wide.

Selecting and clearing of anchor watch is done on right-click menu. The program keeps track of number of watches set, and offers to set or clear a watch only when appropriate.

Waypoints with alarms set can be moved and edited as usual.

Deleting a waypoint with anchor watch set clears the watch.
Deleting <All Waypoints> does not delete waypoints involved in active watch.

If anchor watch is set on a mark with "anchor" or "anchorage" icon, automatic anchor marking will consider this location marked, otherwise an automatic "anchorage" mark will be added as usual on own ship position.

It works very nice...

For the moment it is a prototype, so I do not want to build any new dialogs, etc. For simplicity I interpret now the mark name as radius size (number of meters).
For the moment I use ModalDialog for alarm, which blocks updating of the position, etc. until acknowledged. This should be changed in the production version. Maybe it is better to move the anchor check to AIS thread and use the same dialog as AIS alarm?

What do you think? Too early to test? Would be nice to draw the rings showing guard zones, too.

An anchor watch can be set on any isolated waypoint, lying not more than a fixed distance from own ship [...] It is possible to set anchor watch on one or two waypoints simultaneously, but no more. Depending on the position of centres and choice of each radius one can have a quasi-sector-shaped guard zone, narrow or wide.

Pjotr, sounds like the most straightforward way to implement it. You inspired me to take a look around and I ran into this excellent article containing a model very similar to the one you're describing above. Perhaps waypoints and marks could have a general "proximity to" or "deviation from" alarm? That way we can designate arbitrary points to avoid with an alarm (beach), as well as points you want to stay close to (anchor). This article on panbo also discusses an anchor watch with exclusion zones.

Quote:

If anchor watch is set on a mark with "anchor" or "anchorage" icon, automatic anchor marking will consider this location marked, otherwise an automatic "anchorage" mark will be added as usual on own ship position.

The automatic anchorage mark didn't really do anything so far (except in combination with tracking). I think the icon could be used for the anchor watch. Anchor watch marks could have a certain radius each, and they could be combined to make up an asymmetrical sector as a safe zone in accordance with your idea. Using waypoints for this static alarm is perhaps confusing?

Quote:

For the moment it is a prototype, so I do not want to build any new dialogs, etc. For simplicity I interpret now the mark name as radius size (number of meters).

Impressed, you got a testing version?

Quote:

Maybe it is better to move the anchor check to AIS thread and use the same dialog as AIS alarm?

That would also help on the KISS front..

Quote:

What do you think? Too early to test? Would be nice to draw the rings showing guard zones, too.

It would be nice.. I would test it any time, thanks for your attention

... waypoints and marks could have a general "proximity to" or "deviation from" alarm? That way we can designate arbitrary points to avoid with an alarm (beach), as well as points you want to stay close to (anchor)...

Yes, just after switching off the machine yesterday I scribbled a note on a piece of envelope for "proximity alarm" with negative value.

But I think more than 2 such points are not productive. I'm sure a well visible track and someone who knows (s)he should watch it is worth more than all alarms combined. I'd rather go on deck to look around than calculate intersections and exclusions down below.

I will make a source patch, maybe after moving this to AIS thread and deciding on the patch sequence. I still have the unsolved open track issue. For the full source of changed files, any time.

Pjotr, I don't dispute that any alarm system, however sophisticated, could not replace a watch on deck. The only issue being that everyone's usually asleep around 0300 when at anchor.

Regarding the types of zones, I thought two would give lots of flexibility, e.g. one type you do not want to deviate from, perhaps two rings to make up an 8 (for two tidal directions at anchor) and another for directions you do not want to swerve to (as the shoal in the example).