Reroute when driver deviates from the path

[rinigus]

Sometimes, for one reason or another, its better to alter the route proposed by the mapping application and drive differently. In these situations (since we are driving already), Poor Maps should realize that the proposed route was not accepted by the driver and it should get a new one. Few restrictions:

1. The new route and its use should be done hands free - don't want to interact with the device while navigating. So, we cannot ask whether new route is needed, for conformation of the proposed route, and starting navigation again.
2. Request should be done in background, without altering map display.

When long routes are used, it should significantly simplify routing calculations if significant number of points along the previously calculated route are used in query. It may create other problems though - router could consider them as a points of stops. So, maybe this aspect could be looked into later...

[otsaloma]

This would be very useful. The most common case probably is simply missing turn. Especially on motorways, where exits are far between, it's not easy for the driver to improvise on his own.

The current architecture doesn't make rerouting easy -- significant changes would be needed.

When long routes are used, it should significantly simplify routing calculations if significant number of points along the previously calculated route are used in query.

This is probably too difficult for us to know which points could be used or when. It's better to just do a full reroute and accept the cost.

Imagine for example a case where the route follows a river, but the driver ends up on the wrong side. Bridges to cross the river exist, but far between. Using existing routepoints could suggest the driver make a U-turn to go back to a bridge instead of taking another bridge far ahead.

[rinigus]

I agree with the river scenario - let's see how bad full recalculation is in practice.

As for the architecture: if the changes are needed, maybe it could also take into account for future extension in terms of adding voice commands.

I don't know internals of Poor Maps and never programmed QML+python combination, hence the question: do you use signals in qt5 + python? If you do, maybe adding new signal(s) to indicate that the driver is far away from the route can help?

[rinigus]

Hi, I am planning to start looking into this issue in the foreseeable future. There is still some work to be done with polishing OSM Scout Server, but I think I am getting soon to the stage where I can look into some other aspects of SFOS maps and this issue is surely one of the major ones for me.

So, I wonder, when you debug navigation, do you use some kind of artificial GPS signal feed? If not, I would probably start with implementing that and link it to PositionSource.qml allowing us to debug navigation and re-routing more efficiently.

[otsaloma]

I just hook the position to the center of the map, so that panning the map moves the position too. I don't have time to test it right now, but if I remember correctly, just the below two changes.

diff --git a/qml/NarrationTimer.qml b/qml/NarrationTimer.qml
index 385cd78..ea39270 100644
--- a/qml/NarrationTimer.qml
+++ b/qml/NarrationTimer.qml
@@ -37,7 +37,7 @@ Timer {
     onTriggered: {
         // Query maneuver narrative from Python and update status.
         if (!py.ready) return;
-        var coord = map.position.coordinate;
+        var coord = map.center;
         if (coord.distanceTo(timer.coordPrev) < 10) return;
         var args = [coord.longitude, coord.latitude];
         py.call("poor.app.narrative.get_display", args, function(status) {
diff --git a/qml/PositionMarker.qml b/qml/PositionMarker.qml
index 21feb0d..da52662 100644
--- a/qml/PositionMarker.qml
+++ b/qml/PositionMarker.qml
@@ -26,7 +26,7 @@ MapQuickItem {
     id: marker
     anchorPoint.x: sourceItem.width/2
     anchorPoint.y: sourceItem.height/2
-    coordinate: map.position.coordinate
+    coordinate: map.center
     height: sourceItem.height
     visible: map.ready
     width: sourceItem.width

[rinigus]

Brilliant! Thank you - I get the idea and should be able to proceed from here. Thank you very much!

[otsaloma]

Fixed via commits in PR #43.