Shaping points and Via points

[BertM]

@Martin-Wilcke said in Shaping points and Via points:

• to the most logical point in the forward direction

This seems like an interesting point to me:
When following a track, you follow a line.

How does the program know what the next point is, i.e., the direction you want to go?
I believe a program can only calculate the nearest point, and unfortunately, that can also be in the wrong direction.

[Martin Wilcke]

@BertM said in Shaping points and Via points:

How does the program know what the next point is, i.e., the direction you want to go?

Trackpoints <trkpt> do have a specific order, and therefore a track <trk> has a direction. "Forward direction" means "Track forward direction".

[BertM]

@Martin-Wilcke said in Shaping points and Via points:

@BertM said in Shaping points and Via points:

How does the program know what the next point is, i.e., the direction you want to go?

Trackpoints <trkpt> do have a specific order, and therefore a track <trk> has a direction. "Forward direction" means "Track forward direction".

But you are not ON the track... your outside the track.
Lets assume you left the track on point 3, and now you near point 6, how does the app knows your best point to enter is 7 instead of 6?

[Martin Wilcke]

@BertM

From what I've experienced, the route back to the track is calculated as if you were planning a route—and in fact, some programs do exactly this: the track remains unchanged, and an additional route is generated.

Of course, I don't know the exact program logic, but I imagine it works like this:

• First, various entry points are determined (i.e., points where a routable path intersects the track), possibly as an initial approximation based on the straight-line distance.

• Then the resulting routes are calculated based on an explicit or implicitly assumed routing profile (fast, short, winding, etc.).

• The result that best matches the profile specifications is then used to generate the route back to the track

[Martin Wilcke]

@BertM
Here's a screenshot (actually a simulation with Stegra.io ) :

• the blue line is the original track

• the red/purple is the calculated (re-) route

• the green is the recorded track

[BertM]

I understand your point and

• to the most logical point in the forward direction

is the key:
You are going in the direction of the original track, so the heading is importent for calculation.
If you made a u-turn it will send you back to the point where you came from.

[Martin Wilcke]

@BertM said in Shaping points and Via points:

If you made a u-turn it will send you back to the point where you came from.

In the example above with Stegra.io?

No. As I'm currently navigating an A-B route, a U-turn or deviation from the route will force a recalculation, and the algorithm will always lead me to the route endpoint, the intersection with the track.

As soon as I reach this point, route navigation mode will stop, and track navigation mode will automatically take over, providing TBT instructions based on the track.

DMD works the same way.

[Paul Smith 3]

How about a compromise? Ask the developers to add an option in settings to specify on a given route how close to waypoint is close enough to move on. The figure is already hard-coded in the navigation software at somewhere around 25 meters, but I suggest making it dynamic. Even 25 meters can be too much in a medieval city center and 500 meters is more than enough on rural back roads.

[Herman Veldhuizen]

@Paul-Smith-3 This would just move but not solve the problem that the app can send you backwards on the track.

[Herman Veldhuizen]

Those who navigate a route as track do that because they prefer the stability of a track. My guess is that these users also have the auto recalculation setting to Off.
For me it would be a massiv improvement if the app would only offer navigation ON the track and not TO the track (but with the ETA info to the points ahead of me).
And this is maybe the easiest part to get right.