BaseCamp routes creating straight lines in my Nav V

Well, I don’t know whether to be happy or not.

All three routes, which are perfect in BaseCamp are arriving corrupted in my Navigator V.

The Spanish route of 152 miles / 3:38 hours - arrives as 428 miles in 6:10 hours

The German route of 152 miles / 4:24 hours - arrives as 425 miles in 7:45 hours

The UK route of 152 miles / 3:21 hours - arrives as 202 miles in 3:20 hours

All are offset from the roads and all have spikes in them.

Here’s the file with the three routes:

https://www.dropbox.com/s/c02xebc8t1thq4z/TEST ONLY.GPX?dl=0

Here’s the German route, as displayed in BaseCamp. If you zoom the screen shot, you can see the distance and the estimated journey time in the bottom left hand corner.



Here’s the German route, as imported into my Nav V. As you can see there’s the spikes. You can see the much longer distance and, when displayed in BaseCamp no estimated time at all, all in the bottom left hand corner.



I am left with the only conclusion that there is some new inherent fault in the Nav V's update(s). What it is, I have no idea, other than the cure being a fundamental route recalculation after import. That should not be necessary.

I will now try to recalculate the routes in my Nav V to see if that fixes the problem. I will start with Spain which is by default in fastest time, recalculate it as curvy roads and then switch it back into fastest time..... And BINGO! One perfect route for Spain at 152 miles in 3:15.

It is clearly a Nav V problem and mirrors Rustle's experience to the letter. If nothing else, I am happy (if that is the right word) to be in the same boat as him. Now to contact Garmin to alert them to the problem.

Jeezo, that's some effort and skill right there! As a minor courtesy to your sterling work I quickly (and untidily I think) created a vaguely circular route in Denmark. (Why there? Why not? Because it was there.....!)

Results:-

Basecamp - 113 miles 2hr 55mins

Nav 5 - Set on "Faster" - 117 and 2.30.
Convert to "Curvy" 109 and 3.05.
Revert to "Faster" 114 and 2.45

All seems pretty reasonable and approximately comparable? I'll need to mess with a French or Spanish route to confirm. My UK routes have been ok all along but I better try one of those too. I should manage to do that tomorrow afternoon.

Richard all your routes load perfect in all my gear and show correct in basecamp, or i should say what i have in basecamp transfers as is to my units perfectly.

All routes show as being made in motorcycle mode, and none have any spurious spikes, pics below from bascamp.

Its looking like some crazy software or firmware fault in the Nav V if that is the only unit that gives the issue, was there not a problem with certain versions of the V.

Richard emailed me about something completely different, but mentioned this thread. I thought I'd take a look - I don't visit this site too often.

No problems here with the routes loading from Basecamp into a Zumo 590. (I believe it is similar to the Nav V ??).

I've read and skimmed the 6 pages, and noticed a few things that just maybe are worth comment. You'll have to excuse me if they are wide of the mark, but they are well meant.

Basecamp - transfer of routes to the satnav.

Routes should not normally calculate on transfer or on import / load into the satnav. Basecamp has already done the hard work in plotting the route, and it stores and sends thousands of invisible points (you may have seen me refer to these as ghost points) which ensures that the Zumo receives the route exactly as it was drawn in Basecamp. So if it does calculate the route, then something isn't quite right.

This could be:

• Different map in Zumo from the one being used in the satnav. They have to be identical
• Possible two conflicting maps ticked in myMaps. This can cause all sorts of problems.
• Settings in Edit / Options / Device Transfer in BC are forcing recalculation. I prefer to untick all of the boxes on that screen.
• Route was obtained from elsewhere and has been drawn on a different map from the one that you have in Basecamp. Always check you have the correct map selected. Always recalculate the route before transferring it.

Vehicle Type.

The Zumo 590/595/XT (so I assume the Nav V as well), can store various settings for each vehicle type (Car, Motorcycle and maybe Off road). You can also set the routing preferences that are associated with each of these vehicles.

It is not commonly recognised that when you load a route that was created with the motorcycle profile, it switches the Zumo into motorcycle mode. So any suggestion that using car mode in the Zumo is better may be suspect if it has just loaded a motorcycle route !. I'm not saying that you cannot do it or that it doesn't make a difference (Tech support assure me that Car & Motorcycles behave differently on the XT). I'm saying that if you set your Zumo in Car mode, and then load a motorcycle route - it will use the motorcycle method of transport. Also not commonly known is that if you specify something other than car or motorcycle as your vehicle type / route profile in Basecamp, the Zumo will automatically select Motorcycle. (I'm leaving Off Road out of this comment as Off Road does something different in the 590, the 595 and the XT).

Avoidances set in Basecamp are not transferred with the route. So if the Zumo recalculates a motorcycle route it will use the Zumos avoidances that are stored in the Zumo for the motorcycle. That may result in a very different route from the one that Basecamp calculated.


MyRoute App

MRA does not mention the vehicle type in the transferred gpx file. The Zumo will default to a motorcycle route.
MRA does not transfer the route - the shape of the magenta line. It only transfers the route points (both Via and Shaping if 1.1 gpx (route,track, POI) is selected. Routes from MRA will always be calculated by the Zumo.


Odd straight line which appear at right angles to the route to reach a point will occur when the point is plotted off road. I mean that the Zumo doesn't know that there is a road there to navigate on. Perhaps a rogue map is selected. Perhaps two conflicting maps are selected. Perhaps a very basic map has been selected with many roads not available for navigation. If this happens, setting your maps correctly and then forcing the Zumo to recalculate will fix the issue. You can force a recalculation by changing the routes vehicle type or the routes navigation method - and then change it back again.

Sometimes when a 'foreign' route is loaded in, the route itself is drawn using straight lines between route points. For some reason the route is plotted using 'straight lines', 'direct' or 'off road' I haven't discovered the precise circumstance when this happens. But selecting the correct vehicle, route calculation method and forcing a recalc will sort out this problem.

The route itself

Sometimes a gpx file can become corrupted. Basecamp is pretty good at sorting out corrupted routes. But sometimes they just have to be re-drawn. It doesn't happen very often thank goodness.

Basecamp - transfer of routes to the satnav.

Routes should not normally calculate on transfer or on import / load into the satnav. Basecamp has already done the hard work in plotting the route, and it stores and sends thousands of invisible points (you may have seen me refer to these as ghost points) which ensures that the Zumo receives the route exactly as it was drawn in Basecamp. So if it does calculate the route, then something isn't quite right.

This could be:

Different map in Zumo from the one being used in the satnav. They have to be identical
Possible two conflicting maps ticked in myMaps. This can cause all sorts of problems.
Settings in Edit / Options / Device Transfer in BC are forcing recalculation. I prefer to untick all of the boxes on that screen.
Route was obtained from elsewhere and has been drawn on a different map from the one that you have in Basecamp. Always check you have the correct map selected. Always recalculate the route before transferring it.



Vehicle Type.

The Zumo 590/595/XT (so I assume the Nav V as well), can store various settings for each vehicle type (Car, Motorcycle and maybe Off road). You can also set the routing preferences that are associated with each of these vehicles.

It is not commonly recognised that when you load a route that was created with the motorcycle profile, it switches the Zumo into motorcycle mode. So any suggestion that using car mode in the Zumo is better may be suspect if it has just loaded a motorcycle route !. I'm not saying that you cannot do it or that it doesn't make a difference (Tech support assure me that Car & Motorcycles behave differently on the XT). I'm saying that if you set your Zumo in Car mode, and then load a motorcycle route - it will use the motorcycle method of transport. Also not commonly known is that if you specify something other than car or motorcycle as your vehicle type / route profile in Basecamp, the Zumo will automatically select Motorcycle. (I'm leaving Off Road out of this comment as Off Road does something different in the 590, the 595 and the XT).

Avoidances set in Basecamp are not transferred with the route. So if the Zumo recalculates a motorcycle route it will use the Zumos avoidances that are stored in the Zumo for the motorcycle. That may result in a very different route from the one that Basecamp calculated.

Click to expand...

Thank you for your very full and clear post, John. Appreciated. It is a very good reminder of things to check.

I was confident that my Nav V was ‘in harmony’ as it were with BaseCamp, so as to rule out any mismatches. That being said, when trying to help others I sometimes change settings to see if I can replicate their problem and then have to remember to change them back. I did though check through each of your checklist and can confirm that my Nav V / BaseCamp is not set up in such a way that a problem with the display of a route is inevitable.

When I zoom in on the Nav V, the magenta line is offset from the roads. The offset magenta line follows the major roads in parallel to them. Any part of the route that takes a smaller road (I can zoom in to confirm that the detailed smaller roads are present) the magenta line does not follow. The magenta line simply goes straight to the shaping point in a spike. Later today I will take some screen shots to show this. I will also take some screen shots to show the route snapped back into place, after the conversion from fastest time to curvy roads and back again.

What I am thinking is:

A. The Nav V knows it has been sent a route.

B. The route the Nav V displays looks as if it was created in just the undetailed base map. It wasn’t but it looks that way.

C. The Nav V seems to lack the breadcrumbs between shaping points and / or what your refer to in your excellent manual on the XT as the ‘ghost’ shaping points. Without these, the device cannot snap the route onto the detailed map’s roads. You end up with the route being straight lines with spikes.

What I cannot understand is why.

What I also cannot understand is why the Nav V can then take the route, convert it from fastest time to ‘curvy roads’ and in doing so snap it onto the map. I can understand that this may well change the route between the shaping points but at least the magenta line is no longer offset and has no spikes. What I then can’t understand is why, when you then ask the device to switch back from curvy roads to fastest time, it displays the route pretty much correctly and matching that as was originally created in BaseCamp. In other words, what brings the breadcrumbs back to life and why weren’t they used in the first place? That inability to use the breadcrumbs the first time around can only be a fault inside the Nav V; it cannot be anything else.

I can have the same route displayed perfectly in MyRoute, in Pocket Earth, in my XT, in BMW Connect and in Garmin Drive. It is only when I display the route in my Nav V, that the corruption appears. The only way that I can then persuade the Nav V to cure the corruption is to ask the device to convert it from fastest time (corrupted) to curvy roads (uncorrupted but inevitably altered) and back to fastest time (uncorrupted and - near enough - correct). Those changes should NOT be necessary nor are they anything I have ever seen on my Nav V before. Something has altered within the Nav V itself but I have no idea what.

In post #83, Lee (an experienced BaseCamp and Garmin user) confirms that my three test routes in Spain, Germany and the UK are fine and display properly on his devices, none of which are a Nav V. His findings match my own, in that I can display the three routes properly in my XT and in other softwares, like Pocket Earth, MyRoute and BMW Connect. It is only with the Nav V that I get the problem. A problem that I have never, in years of Nav V ownership, encountered before.

I can only hope that other users of the Nav V (it’s a very popular device) come forward with their experiences. There has to be an answer to it somewhere.

Lee, many thanks for your efforts. Like you, I cannot understand what is happening inside my Nav V and why - as with Rustle’s - it is doing what it is.

I am now going to return my Nav V to its factory settings (wiping everything) then update its soft and firmware, to see if that cures the problem. I don’t see why it should, not least as the device is up-to-date already and / or I cannot think why the problem is now occurring.

I do though realise one thing. It is some time since I used the Nav V. I have been using my Nav VI, which is working fine. I have then been Bluetoothing the routes from my VI to the V, which has been fine. But maybe the fact that the route comes vis a Nav VI and not direct from BaseCamp, cures the problem?

Maybe this corruption problem has been going on for some time but I simply haven’t noticed because I have been bouncing routes through my Nav VI? That though seems odd as surely other people who use a Nav V would have been posting up on the internet that they are having a problem? I can’t find anything recent that says that they are. I know someone has to be first; maybe it’s Rustle and then me? What an honour!

Here are the screen shots of my Nav V, showing the German test route.

The German test route, created from scratch in BaseCamp, is 152 miles / 4:24 hours.

My Nav V has the full detailed maps installed fully and is set to fastest time.

The route, when imported directly into my Nav V, is 425 miles / 7:45 hours



The route consists of straight lines, with spikes radiating off to the blue dot shaping points, all of which you can see in these screen shots:







You can see that the device knows where the blue dot shaping points are and can fix their position absolutely. You can also see that the magenta line is straight and sort of follows the underlying detailed map’s roads but the magenta line is not what I would call ‘snapped onto’ the road. In other words, to my mind, the breadcrumbs that fill in the spaces between the shaping points is missing.

If I then change the device’s setting from fastest time to curvy roads, it forces (not surprisingly) a recalculation. When the recalculation is complete it offers up:



The distance is now much closer to the original and the time is closer too. That they differ a bit does not surprise me in that the device will (if it can) amend the route between the blue dot shaping points, if it can find a more curvy road. More importantly, the magenta route line is no longer dead straight but is snapped directly onto the detailed roads. There are no more spikes. To my mind, the Nav V has somehow found the breadcrumbs.

Here’s some screen shots to confirm:




If I then change the mode back to fastest time, it (quite correctly) forces another recalculation, which gives:



In other words, something almost identical to the original route I created in BaseCamp. Here’s the screenshots to confirm:







Why my Nav V needs a recalculation to render up a correct route straight away, I do not understand. Why it takes a recalculation to find the breadcrumbs between shaping points, I do not understand either. Why it now has this glitch, when it never had it before, is beyond my imagination.

Richard here is a link to a route i have just created in base camp could you try this in your nav V if any route would throw an error it would be this as its made on a different map set to yours and i would expect there to be errors. route also pictured below. also a copy of settings in basecamp.

https://www.dropbox.com/s/rjqcby83r...ignous to Route de Tournon and D102.gpx?dl=0

Thank you Lee, I’ll give it a go and report back here.

Really appreciate you helping.

Lee, your route confirms my worst fears.

It imports perfectly into BaseCamp on my Mac but with one key exception, it has no estimated journey time. Other than that, it looks OK. It follows the roads and has the shaping points. Why it has no estimated journey time, I have no idea. I don’t know why but I think this lack of an estimated journey time might be significant.





When I import the route into my Nav V I get a much longer distance of 379 miles versus your route’s .116 miles and a longer journey time of six hours 30 minutes versus your route’s time of three hours 14 minutes



I also get the straight lines.





Here is what it looks like displayed back in BaseCamp:




I then asked my Nav V to convert the corrupted route from fastest time to curvy roads, which brought things back closer to your original route, its distance, shape and estimated time:






I then asked my Nav V to convert the route back to fastest time from curvy roads, which gave something pretty much like your original. A matching distance of 116 miles and a time difference that is well within tolerance.





In a way I’m happy that the same corruption is happening, as it at least confirms that it is not happening only on routes that I create.

What I am going to do next is to try it with a route I created well into the past, to see what it makes of that. Not least, these have estimated journey times in them. I am also going to try asking my Nav V to create a route, too.

Richard

Well at least it is a consistent fault and occurs with more than your own made routes. Richard can you send me a route that is faulty from the nav V or does it revert back to what it should be once it's left the nav V

Update:

I can create perfect routes directly inside the Nav V itself, 100% reliably. I have just made a complex one of over 500 miles, with no problems at all. What I haven’t done is them exported it to BaseCamp and reimported it back.

Routes on BaseCamp that I created last year, three and five years ago, that I know are OK, become corrupted when sent to my Nav V.

This tells me (or at least to my mind confirms) that it’s a misfit between BaseCamp and the Nav V.

leedude03 said:

Well at least it is a consistent fault and occurs with more than your own made routes. Richard can you send me a route that is faulty from the nav V or does it revert back to what it should be once it's left the nav V

Click to expand...

Hi Lee,

Indeed, it's consistent, which (with your help) is good to know.

I’ll save one or two to Dropbox for you.

leedude03 said:

Well at least it is a consistent fault and occurs with more than your own made routes. Richard can you send me a route that is faulty from the nav V or does it revert back to what it should be once it's left the nav V

Click to expand...

Wapping said:

Hi Lee,

Indeed, it's consistent, which (with your help) is good to know.

I’ll save one or two to Dropbox for you.

Click to expand...

Here you are:

https://www.dropbox.com/s/z6oya8wwa5qf6b1/For Lee - 04.1 - Petry to Peronne.GPX?dl=0

https://www.dropbox.com/s/8qts7ol7i...ve glitch before and thro' Rochefort.GPX?dl=0

Here is an even better one, as it has two routes one file.

Original OK - I created in BaseCamp just now. It is fine at 72 miles and taking three hours 12

CORRUPT - Original OK is what arrived on my Nav V. 236 miles in a bizarre two hours 50

I created the original in BaseCamp in 'Curvy roads' made, to see if that made any difference. It didn't.

The green route in the screen shot is the original, the red the corrupt.

https://www.dropbox.com/s/0vbyj9vmpxrtzwx/For Lee - Test in Curvy route.GPX?dl=0

I dont know about you Richard but the corrupt route in your last link looks like a route that is set to take the fastest way but is going to each point on the curvy motorcycle route and back. that route is possibly the most bizzare i have seen, what could cause that, i have not got a clue.
sent the corrupt route to my 660 transferred over corrupted recalculated it to fastest in the 660 and got a route of 26 mile.
The none corrupt route transferred perfect. also bare in mind that my maps will be earlier than yours because i loaded my 20.21 maps, and not the latest and it still transfered the none corrupt route perfectly,

Hi Lee, it is absolutely bizarre. I agree, the red route is indeed looking like the quickest way (straight lines A to B to C to D…..) to join the shaping points up.

I have just sent a good (uncorrupted) route from my XT into my Nav V. It displayed absolutely perfectly. This, to me at least, confirms again that it’s some problem between BaseCamp and the Nav V.

I think I have now just about tried every combination of routes, settings, routing types, shoe and collar sizes, that I can think of and, with help from you and others tried other things. I have also tried a complete hard re-set of the Nav V, which made no difference. I am now stuffed as to knowing or even thinking what the cause might be, other than it starts life in BaseCamp and manifests itself in the Nav V. If I had my Nav VI I could try that but as you have no problem with the uncorrupted routes, I can only assume it would be OK.

It really has to be one for Garmin to resolve, unless someone can find a cause and a cure. Until then, it’s: Import > check (no change there) > recalculation in a different transport mode > check > recalculate back into fastest route > check again > hopefully use. Or I can just stick to my XT and MyRoute but that just avoids the problem.

What is strange is that the internet doesn’t seem to be filling up with comments about the problem.

Wapping said:

Thank you for your very full and clear post, John. Appreciated. It is a very good reminder of things to check.

What I also cannot understand is why the Nav V can then take the route, convert it from fastest time to ‘curvy roads’ and in doing so snap it onto the map. I can understand that this may well change the route between the shaping points but at least the magenta line is no longer offset and has no spikes. What I then can’t understand is why, when you then ask the device to switch back from curvy roads to fastest time, it displays the route pretty much correctly and matching that as was originally created in BaseCamp. In other words, what brings the breadcrumbs back to life and why weren’t they used in the first place? That inability to use the breadcrumbs the first time around can only be a fault inside the Nav V; it cannot be anything else.

I can have the same route displayed perfectly in MyRoute, in Pocket Earth, in my XT, in BMW Connect and in Garmin Drive. It is only when I display the route in my Nav V, that the corruption appears. The only way that I can then persuade the Nav V to cure the corruption is to ask the device to convert it from fastest time (corrupted) to curvy roads (uncorrupted but inevitably altered) and back to fastest time (uncorrupted and - near enough - correct). Those changes should NOT be necessary nor are they anything I have ever seen on my Nav V before. Something has altered within the Nav V itself but I have no idea what.

Click to expand...

Ah - I knew that I had forgotten something in my summary points. But in fact, your comment here is useful - because it has made me realise that I had misunderstood the behaviour.

What I thought that I had gleaned from previous posts was that BASECAMP was not plotting the magenta line on top of the roads. I thought that the magenta line was perfectly drawn but it is displaced slightly to the right and slightly higher than the road that it is supposed to be on the base camp map. I have seen this a few times and I know the solution. The Map Controls - a vertical slider and a NSWE circle which can be turned on and off under View->Map Controls in BC. Rotate circular control so that north isn't at the top. Let the map redraw if it needs to. Then rotate it again so that it 'snaps' to having north at the top. Let it re-draw. The roads and the magenta line should then lie on top of each other.

So that was the answer that I would have given. But now you explain it like that, that doesn't sound like the issue at all. Although it sounds like the Zumo is doing somtheing similar - so it might be worth trying on the map screen after tapping the Map and cycling through the arrow head symbols 'north up', 'route up' and '3D views'. I've never seen it before, I've never had to fix it, but it is a straw that is worth clutching at !!

So thinking about the problem that was actually of concern, rather than one that I ahd an answer for .......

... we first need some information about routes from Basecamp to the Zumo.

When you send a route from Basecamp, the route normally includes all of the thousands of Ghost Points that locate the magenta line firmly in position on the map.

Here is a (very) edited version of a gpx file of a very short route linking two points on the A59 heading west to east.




The point that I am making here probably gets lost in all of the detail. But there is no map data here. There is just a route that is plotted using lat / long co-ordinates onto a screen.

When a map is drawn on the screen, it too has to be manipulated so that the position on the screen can be represented by lat / long coordinates. The result is that when both the map and the route are plotted onto the same screen, it looks as though the route is drawn onto the map. But it isn't.
The process is complicated by the fact that a rectangular grid system doesn't work very well with a map that represent the squashed orange of our earth. The top part of a lat/long grid in our part of the world (northern hemisphere) is narrower than the bottom of the grid. Yet it has to be drawn on a rectangular screen. That means that the image has to be manipulated.

Both the map and the route need to be using the same point of reference in order to achieve this. This route has been loaded onto a number of different satnavs without problem. The satnav in question has loaded a number of different routes without problem.
So it isn't the route. It isn't the satnav. All that is left is the map that is on the satnav.

I have MemoryMap at home. I can use it for displaying my routes on Ordnance Survey Maps. I can take screen shots of other maps and use them. Or I can use the CenterParcs holiday village map. But before one will work with the other, I have to tell the computer where on the earth the four corners of my screen shot represent. I have to have reference file which plots the lat / long coordinates of the screen shot. Then it can work out the coordinates of any other point on my captured map.

So that brings me to this little section that I haven't mentioned yet. The boundary corneres of the route.
Every route from Basecamp has something similar to this:

<metadata>
<bounds maxlat="53.994498252868652" maxlon="-1.74060202203691" minlat="53.97308349609375" minlon="-1.875266600400209" />
</metadata>


I think that somewhere, for whatever reason the calibration data for the route or for the map are out of synch.

Which is one very good reason for making absolutely certain that the map on Basecamp is identical to the map on the Zumo.

sorry jfheath i disagree with this comment (Which is one very good reason for making absolutely certain that the map on Basecamp is identical to the map on the Zumo) unless i misunderstand what you are saying. i have just used 2021 maps that are NT maps to load Richards Routes that i will presume are from the latest 20.22 NTU maps i say presume but feel sure he updated them yesterday, and his routes work spot on every time when transferred to any one of my satnavs, and going back possibly 10 years i have never had an issue with any of Richards routes.
So what are we saying is out of sync, Richards map on his nav 5 but not on his xt or nav 6 and also that Rustle sat nav map is out of sync on his nav V, or am i missing your point altogether.
Richard is also saying he has never had this happen with his nav V before, so has something been downloaded to change this eg firmware software??.

I agree with Lee, John.

Lee is indeed using a map set older than mine, yet my test routes are arriving on his devices perfectly. Similarly, I can display his test route perfectly in BaseCamp (though the estimated time is missing, which I don’t understand) but it becomes corrupted only when I send it to my Nav V. This is exactly the same as Rustle found, whose post started the whole thread.

Similarly, it doesn’t explain why, a route I create in BaseCamp, then bounce through my XT into my Nav V displays perfectly.

I also can’t explain why a corrupted route on my Nav V, uncorrupts itself in a recalculation triggered by changing the device’s routing method from fastest time, to curvy road and back to fastest time. What happens to remove the corruption and cause a corrupted route, which didn’t follow any roads, to now follow the roads exactly?

To my mind, something is missing (or just not working) in the route when it is processed in the Nav V, which causes the route to be rendered up in straight lines which sometimes run close to known major(ish) roads but which always follow the shaping points. These straight lines then spike off (a bit like a porcupine) to go in straight lines to any shaping points that are on minor roads. You end up, as in the pictures, with a route that looks like the branch of a tree with twigs coming off it. Clearly the Nav V knows where all the shopping points are, it just doesn’t know how to join them up, other than with straight lines. But, in a change of driving mode recalculation, the Nav V suddenly remembers how to join the shaping points up and that the previously straight lines need to be shaped to match the roads. What had it forgotten the first time and how did the recalculation help it to remember?