Navigation: Begin/Pause makes sense only when navigating from current location about poor-maps HOT 8 CLOSED

I understand that when rerouting, we'll want to auto-start, but why would these buttons not make sense when rerouting? For example, if you stop for a cup of coffee on a long trip and want to examine the map, you'll want to press pause so that you can examine the map with auto-center, auto-rotate and without losing the route, which you'll resume after the coffee break. This should be valid when rerouting too?

Maybe it's the button names that need to be changed. Now that I think of it, begin and pause could be combined like the play/pause button on media players. It could initially say "Start", after that "Pause" and if paused, "Resume". What do you think?

from poor-maps.

Sorry, I read the condition hastily, but still, why would there be a case where the buttons should be disabled? Say, you have inaccurate positioning, and because of that route from an address? Or, you do the routing at home, but set it to begin from the parking lot a kilometer from your home?

from poor-maps.

Let me try to explain the thought behind it.

Let's start with the simple part: Start/Pause/Resume would be great. Indeed, you can make a stop, pause navigation, look into the route and check all possible features that you wish, and then resume navigation.

In this new way, why do I think that Start should be used only if you start from "Current position"? Maybe its the simplest by examples:

When "Current position" is allowed only

• you start Poor Maps, select address where you want to go
• your location is way off, somewhere 100km away, the calculated route does not make sense.
• instead of waiting for the GPS fix, you accept the route and press Start
• while you drive/cycle/walk out from where you are, GPS position is enhanced 2-3 times and route recalculated.
• GPS fix is achieved, route recalculated and you can move along it.

This all works, assuming that you trust that the calculated route is fine.

When I can start navigation from address

• you start Poor Maps, select address where you want to go
• your location is way off, somewhere 100km away, so you find route from the known address. The calculated route makes sense.
• instead of waiting for the GPS fix, you accept the route and press Start
• while you drive/cycle/walk out from where you are, GPS position is enhanced 2-3 times. Now the question is, when would you recalculate the route? If its recalculated while GPS is searching for location, then there is no big difference major scenarios.
• GPS fix is achieved and you are moving along original route. Again, should the route be recalculated?

As you could see, it boils down to making decision on when to recalculate the route. The both cases are probably fine assuming that if we start route which was found from address to address and then recalculate it as soon as we are too far from it (as given by 200 meters + positioning_precision). Originally, I didn't have positioning_precision component and then the difference between scenarios was significant. With it, the both cases are probably OK and you can pick and choose.

I can see positives in the both cases, so maybe you could pick the solution you prefer and then we''ll do it that way.

from poor-maps.

I somewhat understand the problem now, but still not the solution. Two things come to mind

1. We need an option poor.conf.reroute anyway. That could default to false if routing from an address.

2. Rerouting should only happen when positioning accuracy is below 40 meters or so, otherwise it doesn't really make sense.

What do you think?

from poor-maps.

While replying last time, I realized that my position is not as polarized as it is represented by the title of the issue. You presented a good case, so, with the rerouting option it would be fine to reroute with the root based on addresses. I was considering the routing from current position and from address as two different modes, but it makes sense not to distinguish them and assume that user knows better than GPS sometimes.

As for questions:

1. poor.conf.reroute is needed, indeed. However, we may cause large confusion if it will start to get enabled and disabled by "magic". Maybe we should assume that if the user pressed "Begin" (or Start) then we are, as soon as we get the GPS fix, rerouting if the user had selected poor.conf.reroute=true before.

2. Taking into account that rerouting via online routers costs API calls, it would probably make sense to have some minimal accuracy. However, we actually have accuracy setting offsetting these 200 meters and maybe its sufficient. In my latest tests, rerouting started to work only when it got quite accurate position anyway. Have you tried yourself? Did it started to reroute too early? If it did then we have to add this cut-off, but otherwise, its not really needed. But note that I don't have strong opinion on this either. If you think that 40m is adequate, let's add that condition.

from poor-maps.

I was considering the routing from current position and from address as two different modes, but it makes sense not to distinguish them and assume that user knows better than GPS sometimes.

Indeed, I don't see them as different modes. One common use case I didn't mention was calculating the route while still at home, inside, with poor GPS accuracy, and thus using one's home address. Another thing I sometimes use myself is starting the route a couple blocks away from home to "force" the route to the alternative which I know is best (e.g. due to road works not accounted for by routers).

I haven't done any testing, so I have no opinion on the parameters yet, but anyway, I'd like you to update the PR and remove all the app.navigationCanStart stuff. After that I can start tweaking the details, do some testing and we can return the parameters after that.

from poor-maps.

Its done in e728c7c. The only condition where app.navigationReroutable = false is when the route was calculated to current position. I guess, we can close this issue/discussion and move on, right?

from poor-maps.

Yep.

from poor-maps.