The route calculation seems to take very long. You can try resolving this by shortening your route, adding a waypoint between your current waypoints or using a different route profile.
(Debug information, this helps us helping you, you can remove this if you don’t want to share this data, it should not contain any personal or sensitive information)
Device: motorola - moto g200 5G - Android: 12 - WebView: 136.0.7103.60
App-Version: 3.5.8 - 5205
Screen: 432 x 984 px - 2.5dppx
Hi,
I was finishing my trip (that I should start this weekend ). I got this error at shape point 645. Is it 645 shape points a lot? Of course. Because I must hold algorithm by hand because he is unable to make straight route in city or highway intersection.
So I deleted WP 645 and it was OK. Algorithm likes 644 WPs. So I tried to find and delete another WP so I can add new one. So I delete WP on straight street in the city and set it to Beeline coz algorithm start to curve it. Now I want to add WP 644 (former 645) and I got this error again.
So I start deleting another WPs. I got this error every single time when I deleted WP.
I deleted about 10 WPs when algorithm said “OK it’s enough”.
From what I see in the video - 9000km is a lot, yes. I am not a developer of the app, so I am not trying to quantify the limitations - this is just my experience and my opinion as a user. Not placing the shaping ponts on the road may slow down things even more.
Every algorithm and app has its limits and you appear to be close to reaching them.
You may encounter similar problems with route recalculation if you try to navigate 9000km in one piece.
If you want, you can share the link to the route, so the team can have a look at it.
Anyway, I suggest splitting the route in smaller sections to improve planning experience.
I understand. Next time. I didn’t expect this problem (literally on the last waypoint).
Still does not explain (my video) why naming waypoints influences route length.
Ah. I think, I understand what you mean. You renamed a WP and the “long route” error message came - therefore you concluded that the route suddenly became longer, right?
I cannot tell for sure, but my perception is that the error message is not directly dependent on the actual length of the route (in km), but more on how much time it takes to calculate it on the server. So, I would even not exclude that it may be also dependent on the current server load/performance. As I already mentioned, with 9000km route and >600 WP you appear to be scratching on the limits of what the app and the server can comfortabely handle.
One thing that bothers me a bit - in your video I can see that renaming the WP is triggering the recalculation. I never really noticed it, but now I have tested it and it really does.
Question for @boldtrn - why does renaming a WP need to trigger the route recalculation?
If I am wrong and the issue is not the app limitation, but there is really some bug in there, it would be very helpful to share your route with the team, so they can try to reproduce the behavior and fix it.
To share the route, you need to open the “…” menu, click “Share”, copy the link and post it in this thread.
This way you might also get some tips from experienced users, how to improve your planning experience.
If you do not wish to share the route publicly, you can send it using a private message to someone from Kurviger team (e.g., @boldtrn or @Guenther )
In general - my recommendation is to split your route in at least 2 or 3 segments.
I didn’t watch your video. But I can work out from your question where the problem lies: Kurviger.com stores all the information of the planned route in the URL that you see at the top of your browser:
And with >600 waypoints (and their names) you reach the limit of the URL length of this browser. If you add waypoints or extend the names of existing waypoints, the URL is truncated …
Take this example (which of course does not come close to the limit):
That would then probably explain the recalculation as the URL needs to be updated with the new WP name and resent to the server and the server would then just recalculate the route, regardles of what has changed.
Not quite. If only the name of a waypoint is changed, example: waypoint (9) from the above URL: &pname.9=Burg+Hochosterwitz&point=46.79015%2C14.26174 nothing would have to be recalculated.
Or if only a waypoint is inserted between (17) and (18): &shaping.17=true&point=46.67744 %2C14.0574&shaping.18=true&point=46.6763%2C13.99569 then only the segments between (17), (18new) and (19new) would have to be recalculated.
I still not see a bug. It is a limitation, which is not communicated, as it was not necessary - until now (if this is the reason at all). Ok, 2^15 = 32768.
The devs could just create a page in the docs with limitations and some facts, perhaps create an error message and it is solved.
In my world 9000 km and 650 waypoints are really a whole lot. Kurviger has so many options what makes planning more comfortable. For example split the route, save parts into a dedicated folder, show parts / the folder as overlay, use the route history, and you are far away from any limits. A change of one part of the route is reflected in the overlay immediately after saving.
If recalculation is getting slow, then why not change the strategy for planning? Other apps like Calimoto have also (reasonable) limits.
Just for info - which browser and operating system are you running?
Here another couple of fun facts (not sure how accurate though):
I am not sure if it is really recalculating but it surely takes a couple of seconds to redraw even if I only rename one point on a route. Have a try with this one:
If you just change the name of the only Via Point on this route, the App takes a couple of seconds to “think”.
Neither a redraw nor a recalculation are necessary for a simple name change - but they are performed.
In your example, I have set 2 shaping points: (2) and (3). see: https://kurv.gr/k5QKR
If you now delete (2), the entire route is recalculated although only the segment between (1) and (3)[now 2new] is affected. The intelligent recalculation of only the changed segments would reduce the required server capacity (by more than 50%) and the response time for the user (in this example by ~10 seconds).
The URL string obviously needs to be maintained for nonTourer, but does not contain any routing data, only the chain of waypoints, which is why a shortlink must always be recalculated, unlike the *.kurviger file.
Primary Firefox, secondary Chrome.
Kurviger on Firefox is super slow (I think) which is known issue and DEVs don’t recommend it.
Not too accurate. I made 32k on Chrome. I saw info somewhere that Opera should have limit 190k characters. Tried it with no difference.
So 2 reasons: bad info and/or server limitations.
I created a 5000 km route on desktop and tried viewing it on the phone. This crashed the app and then the storage has to be cleared before the app can be used again as it keeps crashing imediately after launch. Has anyone tried this before?
I know that having that long of a route in a single navigation plan is dumb, but this is my first year of Tourer+, so I’m trying to find the limits and break the app, lol.
Debug info: OSM date stamp: 2/18/2026
Version: 3.6.0
Device: Google - Pixel 8 Pro - Android: 16 - WebView: 144.0.7559.132
App-Version: 3.6.0 - 6612
Screen: 448 x 998 px - 3dppx
). I got this error at shape point 645. Is it 645 shape points a lot? Of course. Because I must hold algorithm by hand because he is unable to make straight route in city or highway intersection.
Ok, 2^15 = 32768.
.