Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of route calculation to intermediate destinations #5017

Open
kreuzschnabel opened this issue Feb 11, 2018 · 4 comments
Open

Handling of route calculation to intermediate destinations #5017

kreuzschnabel opened this issue Feb 11, 2018 · 4 comments
Labels
Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning

Comments

@kreuzschnabel
Copy link

Yesterday, I was driving home from a private visit. I had some 200 kms to go and route calculation (I would have found it on my own, but it feels better) took about one minute. Well, we are used to OsmAnd not being the fastest offline router at all.

A few seconds after I started, I realised I needed refueling. So I picked a nearby filling station and set that as "first intermediate destination". That caused the ENTIRE route calculation to start over, taking another minute or so – while I was already on my way, and just a few kms off my first destination!

Having lost my patience, and before missing the station because the calculation would take longer than my way there, I cancelled the routing and requested a route to the filling station as final destination, which came up after 4 seconds – just in time to turn at the next junction!

My question: When an intermediate destination is added while already in routing directions mode, why not calculate the first leg to the new sub-destination first AND display it asap – and then, while the user is already following that direction, calculate the rest in the background? That way, closer sub-destinations would come up much quicker, and users wouldn’t have to wait a few minutes unnecessarily for a few-miles-drive to their first destination just because the route after that is considerably longer.

--ks

@scaidermern
Copy link
Contributor

Slightly related to #3683.

Calculating and displaying the route to the first destination immediately sounds like a good idea.

@vshcherb vshcherb added the Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning label Mar 20, 2018
@vshcherb
Copy link
Member

Sounds good

@pebogufi
Copy link

For me not only sounds good but a very important improvement to the calculation, which is known as not so fast.

@jkufner
Copy link
Contributor

jkufner commented Aug 16, 2019

This seems to be very good idea.

I would also extend this to long-distance navigation without intermediate destinations. Osmand could use some heuristics to guess a likely direction of travel and start navigating instantly while still calculating the rest of the journey. When traveling 200+ km, we almost always use highways; therefore, Osmand could guess the likely highway to use and immediately start navigating to nearest exit where we can join the highway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning
Projects
None yet
Development

No branches or pull requests

5 participants