"deviations"

Hi, when I load a GPX route into the kurviger website sometimes a couple of things happen, sometimes the route becomes “spaghetti” and many times a suggestion about “deviations” appears. What exactly are these deviations? is the application simply trying to suggest I could use a different route or is the system failing to recognise the route that was imported.

Here is an example. The original red route was part of a motorcycle trip with off-road sections. Is the website/ kurviger simply trying to suggest an alternative. If not, why doesn’t it just import the GPX route as originally made? Thanks

The algorithm is actually failing to match the imported route - it is not a “suggestion of a better route”. There are several reasons for this, here are some of them:

  1. there is a restriction in OSM (e.g. road closure), which prevents the routing that would match the GPX file
  2. The GPX file is inaccurate - there are not enough points or the points have a significant offset to the used map (might be a problem in urban areas with dens road network and poor GPS signal).
  3. The algorithm is not trying hard enough to make a match. It is true that sometimes it is difficult to reproduce with software what human can do in split second. However, there is already the function “Optimize waypoints” that usually delivers better match automatically shows that SW can do better. What I do not understand - Kurviger cannot match 100% the track recorded by itself, but other apps can - surely there is room for improvement.

The import of a gpx tries to create a route. Check the header text Import Route. Means, the trackpoints must fit to a routable way. If not, then you have a lot of deviations.

Try to click on the red line to add shaping points, but if the point is not routable, then it will probably not work.

Another option is to first load the track as Overlay, import the track as route, try to set SP to best fit, then fix non routable ways for example with beeline.

The rough logic is to reduce or simplify the thousands of trackpoints to a manageable amount of points. The curvynes is assumed as curvy. The app tries to best fit the track to make a route. Remaining (mostly very small) deviations can be fixed by walking through the displayed hints and to click the red line to add SP.

Can you edit these routes the other apps import? Because usually you can’t.

In app68 and MRA you can also edit the imported route.

I have done this test months ago, shortly after the reworked import was introduced in Kurviger. It might be that I just got lucky and the one app got 100% mach and Kurviger did not - yet it did happen.

Today, I have tried again with a different (2 year old GPX) and got mixed results.
MRA seemingly did the most accurate import (up to the last 2km in the city) and used 90 waypoints on 265km.
App68 and Kurviger both had 5 deviations (6 before optimization) and both apps used 15 waypoints. App68 deviations appeared to be shorter on average, but not less strange than those of Kurviger.

Of course this is just a single sample which does not say much more than that there is obviously impovement potential in all of them. Probably not the highest priority, but still.

Thank you for these likely possibilities. I doubt that it is road closures as this has happened many times and the tracksuit usually avoids our dirt roads. It is almost like it is trying to deviate me from the original suggestions using dirt roads.

And thanks for trying to help. The points are usually route ago so I don’t think it’s option one.

Option three beginning “the rough logic” I have experienced a few times and then added the odd shaping point, and that cleared it up. I will try option two at some point

There is not one and only reason for all deviation - every has its own.

This is interesting. One of the deviations in my test file today was exactly that - taking the unpaved road for no apparent reason:

How many deviations on unpaved roads you got? Maybe there is something basic that develepers could have a look into.

Here is my snipplet: https://kurv.gr/zQBSy

Gravel with maxspeed = 60. Seems to be the faster way. :astonished_face:

It is a point every 3 km, and still not perfect? It might be more accurate - but when I must / want to change the route, it will be a lot of work (road block ..).

In my imagination more work than fixing the remaining deviations in Kurviger through the guided wizard just by tapping the red line. Ok, above a lot of deviations, but without having the gpx, we can only give common advices.

As you said ..

to clarify the router wanted to divert AWAY FROM unpaved roads, which were part of the route and re-routed onto asphalt roads.

As you import the gpx as a route, it might be that the from OSM-data the unpaved way is not allowed.

Or - as Kurviger simplifies the track points with a strategy to reduce the waypoints (@t00thl355 above: 90 waypoints every 3 km versus 15 points in Kurviger) - Kurviger calculates the asphalt as an alternative.

But - in the wizard the deviations are displayed. Try to fix in the wizard just by tapping on the red line. It is easy, and as I said above, for me the smarter way than to set unnecessary points, which must be deleted in case of a change.

just out of interest, this isn’t only kurviger just tried to load a route I had created on krviger to br router and i got spaghetti .

here is the route

S3DAM-KATO VOR15.gpx (87.7 KB) checked and perfect on kurviger

Plus a screenshot of the spaghetti !!!

My screenshot just after importing your gpx-file:


No problems at all …

Can you also try in Brouter?

sure:

. . . .

Route and track . . . . . . . . . . . . . . . . . . . . . . . . . . only track

Ah, @greekmountains has profile Trecking bike?
At least a track, that imports properly in Kurviger with unpaved sections. So there must be something special with the gpx of initial question.

I don’t understand this whole discussion…
Are we talking about BRouter or Kurviger here?
And the screenshot from the first post can’t have come from the GPX file.

Looks like the import manager.

It is about Kurviger. Also about the expectation that a gpx / track should be imported by 100% accurancy to a route. And also about how other software handles import, just to learn, getting ideas for possible improvements.

Still, on this section there is plenty of recorded track points:

How comes that neither the initial import nor the “optimize waypoints” algorithm is smart enough to take any of those as a shaping point and try to match the track? It does not seem like a rocket science to me, just a simple trial and error. The algorithm is smart enough to know where the deviation is, could pick the track point in the middle of the interval and check if the matching improves.

Or does the algorithm simply stop trying to match when you hit 95% without ever trying to go higher? IMHO 3 seconds longer optimization is nothing compared to the time it takes to do manual corrections.

There are certainly more important aspects of Kurviger’s development than improving what I consider to be an already optimal import process. And if there are a few deviations when importing a track with a high proportion of gravel that I can fix manually, that’s absolutely okay.

Here’s a section of the TET in the Pyrenees: TET-E_14.gpx (226,0 KB)

During import, there are 11 deviations (79 waypoints); after optimizing the waypoints, there are 7 left (73 waypoints). 5 can be corrected with few clicks. For the two remaining deviations, the only option left is “beeline” because “Path” and “Motor-Vehicle=No” were defined in OSM. It’s up to you to decide whether you still want to drive it.
Result: https://kurv.gr/AyBxJ