Thank you. Your description matches everything I have measured
from inside a SuuntoPlus feature, and it explains the one result I
could not account for.
Here is what I can add, measured rather than guessed, in case it is
useful to you or to anyone else reading.
The trigger really is the direct distance
A feature can read /Navigation/Poi/Active/Distance. While a route
is being navigated, that is the direct distance to the next named
waypoint, and it is accurate to about a meter: I logged it once a
second for a whole walk and checked all 495 samples against the
route’s GPX, and the best match is the expected waypoint every time,
to within 1m. /Navigation/Poi/Active/Name gives that waypoint’s
name and switches at the passage.
So the concept you describe from the outside is visible from the
inside too, and it is the only usable thing a feature is given about
a waypoint. There is no resource for a waypoint’s coordinates, and
none for a bearing to it.
Off route it all stops, exactly as you say
On one walk I left the route deliberately. For 178 seconds
Poi/Active/Distance, /Name, /Coordinates, /Bearing and
Routes/NavigatedRoute/DistanceToDestination all went silent
together. ClosestPoint and Position kept answering. Coming back
on route brought everything back.
This is the part I find hardest to accept as a design. Being off
track is the moment you most need the watch to tell you where the
next waypoint is, because that is the information you need to get
back on the route at all. On the line, where everything still works,
you can already see where you are going. The data is withheld exactly
where it becomes necessary, and for a pilot or a skipper pushed off
track by wind or current that is not a rare corner case, it is a
normal part of the trip.
Your point about reversing explains a result I had left open
I walked a short loop whose start and end sit 26m apart. The very
first sample, before a step was taken, read Position 1.000 and 50 m
to the destination, and the watch never ran waypoint navigation at
all for that walk. Position then went negative for the rest of it.
I could not explain it and left it unexplained. Your description of
the navigation reversing on an out and back, and then listing the
waypoints back to the start, fits it exactly.
What I did about the missing bearing
Since the distance to the next waypoint is exposed and its position
is not, the position can be recovered from the distance alone. Each
measurement says the waypoint lies on a circle of known radius around
a known position, and circles taken from a moving observer meet at
one point. Solving that over a leg puts the waypoint within a few
meters of where the GPX says it is, and from then on the bearing is
computed locally, so it survives the watch going quiet.
It works, but only for the waypoint the watch is currently offering.
Once off route there is no new waypoint to learn, so it carries the
current leg and no further.
The question I am left with
Is there any resource, documented or not, that gives a feature the
coordinates of a route’s waypoints? I have tried about twenty
spellings across Routes/NavigatedRoute and found none, and after
your answer I understand why: if the list is recomputed rather than
stored, there is nothing to read.
If that is so, then the only stored thing with coordinates that a
feature can reach is the POI library, through /Navigation/Poi/Count
and /Navigation/Poi/<index>/Coordinates, which do answer. Is that a
supported way to read them, and is it expected to keep working?
