I have read the recent posts on the memory model and the new
Route Manager. Perhaps some of the points below... sorry if it is a bit long ;-)
I usually use only very simple routes, but I use tracks a lot.
From the data structure perspective, routes, tracks and waypoints all merge into a
single framework, and OCPN is amazingly logical and elegant about it.
But from the
navigation perspective they are very different.
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.