Route Properties Bug (5.6.0)

[sadiiqi]

In creating a route for a distance race (out to a mark and return) I used the same waypoints for some of the outward and return legs. I noticed that the route properties was missing some of the legs.
To test I created a simple search pattern route - when I started to backtrack using the same waypoints, the bug appeared with legs corrupted.
Attached are screen shots to assist if anyone can help.
In the interim I'm having to ensure I don't use a waypoint more than once on a route, not ideal.

[bdbcat]

By "backtrack", do you mean:
a)Create another route using the same points (in reverse)
or
b)Append to the route, starting at the end, and use the existing points in reverse?


Thanks
Dave

[sadiiqi]

backtrack - b).
Am creating a route for a race - out to a distant mark, round it, and return using the same WP.

[bdbcat]

OpenCPN 5.60 does not fully support re-use of routepoints within a single route. The function was judged to be not frequently used, so not worth the extra coding and test time. Some situations work fine, others not so. One can imagine some truly pathological routes to stress the logic, but these have no real useful navigational utility value.
In practical navigation use, if you truly mean to retrace a route in reverse, the simple and quick solution is right-click->Reverse Route.


Dave

[Antipole]

I have done extensive testing of this under OCPNv5.6 on MacOS Monterey for the purposes of developing my Housekeeper script. For the creation of the routepoints themselves I have seen no issues and have been unable to fault OpenCPN on this aspect.

The issue is with the derived parameters and here OpenCPN makes mistakes. It is likely that when it needs to derive, say, bearing from 003 -> 004 and there is more than one occurrence of 003 and/or 004, it gets confused about which occurrence to use. I assume, although have not tested, that OpenCPN will navigate the route correctly. It is the derived attributes in the properties window that it gets wrong.

If you subsequently delete or remove points in such a route, you can end up with successive repeating points e.g. A -> B -> B ->A and, in this case, if you remove the Bs you can even get A -> A which is of course nonsensical. OpenCPN allows this without complaining. Housekeeper cleans these up and, in the last case, will offer to delete the nonsensical route.

[rgleason]

Maybe Opencpn should simply not allow selection of a WPT twice?

Should this be entered into tracker or issues?

[bdbcat]

Yes, for reference and collective memory.

[Antipole]

Originally Posted by rgleason

Maybe Opencpn should simply not allow selection of a WPT twice?

Should this be entered into tracker or issues?

I see several uses for a closed route.

I and others use it to mark out an area such as a firing range. Yes OCPN Draw could do this but a quick closed route can be simpler.

Others create a closed route to demark an area and export it as a GPX file for generating mbTiles of satellite images or even Navionics chart tiles (dubious use but yesterday I saw it part of a recipe somewhere on this forum).

The problem only effects the Properties window - not the use of the route - I think. Tell me if that is wrong.

So perhaps that window should include a warning that the route contains repeated use of routepoints and the derived data (bearings, ties etc.) will probably be wrong. This is not ideal but, as Rick says, it is a rare situation and probably best to leave the existing uses available. After all, if you use it to mark an area, you will not be interested in the derived data anyway.

[bdbcat]

Antipole...


As I said, some re-use of points is OK, some not.
Simple closed routes, as used to demark an area for whatever reason, work fine. Properties info seems accurate to me.


I have a hard time thinking of the practical application for other cases of point reuse.


I suppose we could write condition code to allow this one use-case (simple route closure, last point is first point), and disallow all others. Something to discuss, anyway.


Dave