Kurviger 1.10.4 (Beta)

The beta version was available now. The first impression of the new extensions are good.

Die Beta Version war jetzt verfügbar. Der erste Eindruck der neuen Erweiterungen sind gut.

1 Like

(I moved the post in Beta version’s topic to discuss here)

@Rolf_B thanks for the feedback!

First question: not problematic, but not that quick as before… there is little laziness in screen setup. Is this due to the beta?

Can you please explain the exact difference between rerouting options?
nearest waypoint is nearest to gps position with the effect that a roundrip stops short after starting by deleting all waypoints between --> only good if the trip is not a round trip and if wanting to drive quickly to the destination, correct?

what is the difference between nearest point on route and next unvisited waypoint?

and when getting the rerouting context menu it asks for rerouting from Start or Standard. What is the best solution then to drive according to the new options? Is this “Standard” then?

Beta just contains new features, everything else should work as always.

  • Nearest point on route: it’s the nearest coordinates on the route path (not waypoint).
  • Nearest waypoint: it’s the nearest waypoint (i.e. via points, destination) of the route.
  • Next unvisited waypoint: it’s the next waypoint (i.e. via points, destination) that has not been passed yet. Thus making sure that new route’s waypoints remain unchanged during rerouting.

When begin navigation and be away from route, the rerouting asks what to do:

  • Start: reroute from user location to route’s start.
  • Default: reroute from user location using the rerouting profile selected above.
1 Like

cool, if this works, then it’s pretty much perfect… together with skip next waypoint if necessary, it can be used individually.

Will the option to define mandatory and optional waypoints (which would then best fit to the option “nearest waypoint”) still be developed then or is this obsolete by these new functions?

Mean the waypoint types (shaping, etc.), that still can be useful and exists in our list.

Navigation: voice instructions frequency options

The “route missed” voice info is now missing!?
You can only select a (repeating) signal tone between 1s and 60s. A repeting signal every 1s is way to often. IMHO even 60s is quite often.

I am missing a one time info that you have missed the route.


There were many complaints for the mandatory “Route missed” message, usually because of sudden GPS jumps during navigation.

An optional and less annoying way is to signal a tone when something is wrong. If max 60" seems too often, we can increase the limit.

Just jumped on the Beta and everything works fine for now. Maybe I can give it a test-ride on the weekend, fingers crossed!

1 Like

Great, that the user can set this!

There is a similar setting option for Navigation: route indicator improvements (Pro)
:thinking: Is it really useful, to have separate settings for rerouting and for route indicator?
Is there any use case where the route indicator should have a different setting than the rerouting option?
I am afraid, that this would confuse novice users.
Why not simply inherit the route indicator setting from the rerouting option setting? :thinking:



Good question and already exists in my mind too. :slightly_smiling_face:

Route indicator has an extra 4th option for disable (not very useful).
So can indeed merge the two settings to avoid too much confusion.

1 Like

I do think that these two are different. For example you might want the indicator to show to the next waypoint, but the rerouting to the nearest point.

Route indicator was not meant as a waypoint guide. It was always connected to rerouting, that’s why has exactly same options.


I tried the function “Avoid Roadblock” today an it worked very well. The distance was 500m. That’s an important and useful function. Thanks a lot!



Just tested with a few “fake blocks” :no_entry:: the routing seems to be very reasonable. Helpful new function!

Tested using the “next unvisited waypoint” option with a few special scenarios to see what the behaviour will be. And I was really happy with it: I think now it’s unlikely that rerouting will mess up your route. Very good: if missing a waypoint due to a detour Kurviger still automatically omits it if getting near the next one. It’s just the behaviour I’d expect if being rerouted (and very convenient if being used together with the “skip next waypoint” function, like Tom already mentioned). Perfect! :grin:

But I’ve the same opinion like linux-user: maybe it would make sense to combine this option with the “route indicator” setting to keep things easy.

I would really appreciate if this feature will nevertheless be implemented in the future. Still would offer additional functionality.

I really like this new look. Especially the fact that the distance to the indicated point is shown. This helps to estimate your way even if not seeing the route at the moment. :railway_track:

Helpful. But I would really appreciate if this layer would also be available on Kurviger’s website. Gastronomy locations are also important while planning a rotue, not only for spontaneous stops during your roadtrip. :coffee: :hamburger:

Hmmm - I don’t understand how to use that function. I looked up a location in Google Maps, copied the Plus Code and pasted it in the search field in the Kurviger app. Nothing happened. Also tried to use the “share” function but this also didn’t work. I think I’m doing something wrong. :thinking: What would be the best way to import a looked up location from Google Maps directly into Kurviger? :world_map:

I also had the feeling that the display refresh rate is a little bit slower than it was before (even on a Huawei P20 Pro). Maybe because I had actived the gastronomy layer? :broccoli: :turtle:

All in all this a very valuable update. Thumbs up! :+1:t3:


I will see that.

It works in search, write a (global) plus code, e.g. 7HQQ57WG+66.
Or if long press a point on map and in Share.
Share contains: OSM link, Plus code, what3words.

As mentioned in feature topic, Google Maps produce (local) plus codes (area name + local code), not the offline specification, it’s something different (see their documentation).

Local plus codes need extra work with online search for the area name.
It’s their own online implementation, usable inside their online ecosystem.
Third party apps need extra work just to be compatible with Google Maps.

Gastronomy layer contains too much content, that’s why all maps show such POI from a sufficient zoom (e.g. 17) to avoid hurting map performance. Currently we show it from zoom 15, cannot do it earlier and probably need to do it in larger zoom.
It’s like house numbers or vegetation layers, too much data needs large min zoom.

Looks like avoid roadblock for 100m does not work reliably.

  • Here my short test route https://kurv.gr/f1EZD
  • My position is at the Start.
  • avoid roadblock 100m
  • route is unchanged.
  • avoid roadblock 500m is working.

I’ve tried different routes, and most of the time it is working as expected.


Short distances in avoid road block are usually more dependent on route geometry.
In example the 100 m are just after 1st turn, so routing may cannot use it for calculation.
Also important role plays the user direction, as cannot (re)route on a street backwards.

To demonstrate, I’ve stopped shortly before “Führholzerstraße”.
In the left (first) screenshot the next turn instruction is 160m away.
Kurviger could have used a route like e.g. in right (second) screenshot, but roadblock 100m doesn’t change route.

roadblock 500m in the same situation takes basically this route


I can see if 100 m case can be improved. Though since all that depend on route geometry, cannot expect wonders for such short distances.
Current values came from forum discussion here, not sure if they’re the best.
500 m and more are far more reliable options in routing for avoid road blocks.