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.
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.
<wpt lat="53.97308349609375" lon="-1.875228881835938"><name>Point A</name></wpt>
<wpt lat="53.993682861328125" lon="-1.740646362304688"><name>Point B</name></wpt>
|
Waypoints. These are the defined waypoints in the route. In this case, just the start and the finish point.
The fact that they are defined separately causes the Zumo to add these to 'Saved' or 'Favourites'.
|
<rte>
<name>A59 Point A to Point B</name>
<extensions>
<trp:Trip><trp:TransportationMode>Motorcycling</trp:TransportationMode></trp:Trip>
</extensions>
|
The start of the route definition, and the name of the route. The end of the route definition is at the bottom.
The Transportation Mode declared in Basecamp for the route. This causes the Zumo to switch to Motorcycle preferences.
|
<rtept lat="53.97308349609375" lon="-1.875228881835938">
<name>Point A</name>
<extensions>
<trp:ViaPoint><trp:CalculationMode>FasterTime</trp:CalculationMode></trp:ViaPoint>
<gpxx:RoutePointExtension>
<gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF </gpxx:Subclass>
|
The first point of the segment. The lat/long are the same asfor one of the waypoints previously declared.
The calculationmode of 'Faster Time' is assigned to this segement. Some Garmin devices must be able to use
different preferences for different segments of the same route. Not the Zumo though.
I believe that the subclass is hexadecimal coded information for the following section of road. Eg type of road, speed limit, sutiable for HGV, height limit, traffic data.
I don't know, I cannot find any information about it. Hexadecimal characters represent number from 0 to 15 (so it is base 16). So a single character can represent 16
different features. 2 characters can represent 256 different features. They use hexadecima as it is easy to conver to binary. eg F is 1111 in binary. 15 in decimal.
|
<gpxx:rpt lat="53.973134625703096" lon="-1.875266600400209">
<gpxx:Subclass>02002565C401FD970B00211600000E002200</gpxx:Subclass>
</gpxx:rpt>
|
Here again - the first point of a segment of road. A new subclass for new features from this point on.
|
<gpxx:rpt lat="53.973426818847656" lon="-1.874113082885742" />
<gpxx:rpt lat="53.973426818847656" lon="-1.874113082885742" />
<gpxx:rpt lat="53.973426818847656" lon="-1.874113082885742" />
<gpxx:rpt lat="53.973426818847656" lon="-1.874113082885742">
<gpxx:Subclass>02002565C401FD970B001F000F005D931401</gpxx:Subclass>
</gpxx:rpt>
<gpxx:rpt lat="53.973426818847656" lon="-1.874113082885742" />
<gpxx:rpt lat="53.973619937896729" lon="-1.873297691345215" />
<gpxx:rpt lat="53.973684310913086" lon="-1.873061656951904" />
<gpxx:rpt lat="53.973984718322754" lon="-1.871860027313232" />
<gpxx:rpt lat="53.974156379699707" lon="-1.871237754821777" />
<gpxx:rpt lat="53.974285125732422" lon="-1.870744228363037" />
<gpxx:rpt lat="53.975036144256592" lon="-1.868641376495361" />
<gpxx:rpt lat="53.975250720977783" lon="-1.868019104003906" />
<gpxx:rpt lat="53.975400924682617" lon="-1.867632865905762" />
<gpxx:rpt lat="53.975679874420166" lon="-1.866946220397949" />
<gpxx:rpt lat="53.975894451141357" lon="-1.866345405578613" />
|
The following two segments of the route. The gpxx:rpt command indicates an invisible point that pins the route onto a road. Or more precisely, it pins the
point to a very precise set of co-ordinates. So far there have been 16 points. They are not evenly spaced, but in this case, those 16 points cover 0.6 miles of the route.
There are hundreds and thousands of these points. I have just copied the first few of the long list that is actually in the gpx file.
If I was to replace the <gpxx:rpt lat="53.975894451141357" lon="-1.866345405578613" /> with <trkpt lat="53.975894451141357" lon="-1.866345405578613" />
and use the <trkseg> command rather then the route command- <rte> - then the gpx file would contain a track. For a programmer, it is easy to convert a Basecamp
route into a track.
|
</extensions>
</rtept>
|
That is the end of the ghost point extension for this particular segment of track (which started with Point A).
|
<rtept lat="53.993682861328125" lon="-1.740646362304688">
<time>2022-03-03T14:31:36Z</time>
<name>Point B</name>
<extensions>
<trp:ViaPoint>
<trp:CalculationMode>FasterTime</trp:CalculationMode>
<trp:ElevationMode>Standard</trp:ElevationMode>
</trp:ViaPoint>
<gpxx:RoutePointExtension>
<gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF</gpxx:Subclass>
</gpxx:RoutePointExtension>
|
So off we go again with the start of the next segement of track from Point B. Although in this case, it is the end of this very short route.
|
</extensions>
</rtept>
</rte>
|
These are just the closing commands for the extensions, route point (rtept) and the entire route (rte) which were opened further up. Like opening and closing brackets.
(If you don't close brackets, it looks really odd.
|
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.