"The route cannot be calculated. No roads are near the destination."

Former Member over 11 years ago

Here is an e-mail and response I got from Garmin support regarding a Basecamp error I am having with my RoadTech Zumo 660. Does this sound like BS to you? How is Basecamp not compatible with the 660?? Any advice appreciated. Thanks!

Subject: Route error
>> Message: My old laptop finally bit the dust so I bought a new one. I have a Garmin Zumo 660 and reloaded Mapsource using the DVD that came with the Zumo. I then went online to download the latest updates. I updated maps and software for both the computer and GPS. MapSource is now running version 6.16.3 and the Zumo is now running software version 4.90. Maps are City Navigator North America NT 2014.30 on both the computer and the 660. The latest update also downloaded Basecamp Version 4.2.5 to my computer. Yesterday I started playing with Basecamp to learn the new interface and made a 230 mile route (all pavement on secondary two-lane roads). Today I went for a ride using the custom route and had a re-occurring error. Several times along the route the screen switched from the map to an error screen stating "The route cannot be calculated. No roads are near the destination." I could click "OK" and the screen would return to the map but not the custom route. I could then go thru the menu and re-select and start the custom route again and it would work fine. This error happened about 15 or 20 times on the ride. Very aggravating to say the least. It never happened before so I assume it is related to the map/software update. A quick Google search didn't reveal much. It seems that several people have experienced the same issue but no one has a good solution. I found one suggestion to reload the GPS firmware as it could be corrupt. I re-ran the Garmin WebUpdater and reloaded version 4.90 to the GPS but haven't had a chance to try it out yet. Is this a known bug? If so what are the possible solutions. I searched the Garmin support site but found nothing regarding this error. Having to restart custom routes multiple times during a day-long ride is frustrating. Any help is greatly appreciated. Thank you, XXX

>>>Dear Ron Franks,

Thank you for contacting Garmin International. I am sorry to hear you are having troubles with your zumo. I would be happy to help you with this route error message. There is most likely an issue with the route transferred over. It is possible this issue is because BaseCamp is not compatible with the Roadtech zumo 660. Please try creating the route in MapSource to see if you have the same issue.

With Best Regards, XXX

0 BTLAAKE over 11 years ago

This is off the top of my head, so it may well be wrong. After a recent BaseCamp update, some devices were having a problems with routes failing on their devices. The same routes loaded from MapSource seemed to work fine.

I believe there was an issue with data field <gpxx:Subclass> - they differed for some of the points in the gpx files generated from MapSource and BaseCamp. I think this field gives instructions on whether a point should be in the route directions, what announcement to give if any etc. So, a unrecognized hex code could screw things up. I am not sure it has been fixed or thought to have been fixed.

Trying the same route from MapSource is a means of trouble shooting. So it really is more of a BaseCamp bug than a compatibility issue. Granted, you may not want to do your 230 mile ride again, but you could try a shorter route using the same settings. I would keep the problem route and also create it in MapSource. This would help the software engineers sort out the problem if it is indeed an issue with subclass data field.

I’m sure others will chime in with more info.

0 SUSSAMB over 11 years ago

I suspect this is simply a map error somewhere along your route.

I'm unclear how you get though to some of your comments, or what this is aimed at:

Additionally, whoever made the executive decision to release an non-debugged, unproven, untested, non-robust software package to the public should be fired.

Do other routes work? Does breaking it into smaller routes work? Are you able to post details of your route so it can be checked?

0 SUSSAMB over 11 years ago

Just right click the route and select send to ... you can then send it to any connected device/usb stick etc. To place it on your hard drive select File, Export.

If you still have that multi-day route try sending it to Basecamp, it should work fine.

Basecamp should also work with a normal zumo 660, so I wouldn't jump ship just yet :)

It's possible though the Roadtech version is different :confused:

0 BTLAAKE over 11 years ago

Additionally, I can post the route here for checking, but I am having difficulty finding the file location. In MapSource I stored all my routes in a folder. In Basecamp, they appear to be embedded in the program. Is this correct? Is there a way to extract a route as a stand alone file?

Thanks.

As SUSSAMB wrote, you will have to Export the route as a gpx file.

One of the ways BaseCamp differs from MapSource is that an organizational system is built into the application. With MapSource, the Windows folder/file system was used to organize date in separate files where each file can be thought of as a separate database. BaseCamp uses an internal system of folders and lists, but there is only one database.

Current versions of BaseCamp are kind of a jumble of multiple folders/files to handle the new types of objects (custom maps, geo-tagged photos, Birdseye imagery etc) and that is why it is hidden. The location will vary slightly with operating system. On XP it is C:\Documents and Setting\USER NAME\Application Date\GARMIN\BaseCamp and the Database sub-folder.

Folders and lists have the same naming convention as Windows. Objects use the same naming convention as in MapSource. Lists differ from MapSource files in that they do not contain objects (waypoints, routes, tracks) but a reference to an object in the database. This means you only make a waypoint like Home once. References to Home can be placed in multiple lists. This has a consequence that a change made to an object in any list will change the object in all lists. So, if you want to build a new route off of an old one and keep the old one you will need to duplicate the route first. Copy/paste does not create a new object, it only copies and pastes the reference from one list to another.

Regarding breaking up a long route in to smaller portions, I doubt this was your issue. Automated Routes (Any profile except Direct) have a limit of around 50 user points (the points a user adds to define the route) on most devices. I suspect you did not use that many on a 230 mile route.

Best would be to post the route that recently failed and the same route built and exported from MapSource for comparison. You might be able to get by with coping and pasting the route from BaseCamp to MapSource and then doing a recalculation in MapSource, but rebuilding it would be safer. You could post all three.

0 Former Member over 11 years ago

Document is a valid XML

Just checked the file using an online xml validator and the file is valid.

Maybe a map problem on the 660. What map is on the device? (Sorry, I don't have a 660, I have a BMW Nav-V which is somewhat similar)

0 Former Member over 11 years ago

The Zumo only uses its internal memory (RAM). The externally accessible memory (your 3.65 GB) is only used for storing files. The only files that are written to this memory are AFAIK the track log archive files and the current.gpx file.

Our Australian Zumos come with only 500 MB of storage as our mapsets are quite small, so your 470 MB is more than enough.

0 SUSSAMB over 11 years ago

Device internal memory used for calculating routes is entirely different from the memory where maps are stored. The fact therefore you got an error while calculating a route is immaterial.

0 JaVaWa over 11 years ago

What RSTANTON wrote is correct, but it may need some clarification:

The zumo uses an internal memory for calculation of routes and to store waypoints, routes and the active tracklog.
This memory isn't accessible from the computer; every time you connect the zumo it saves the contents of the internal memory into the file current.gpx on the external accessible memory.

Apart from this file and archived track logs the zumo doesn't write anything to the external memory; it only reads stuff (like maps and poi's).
Actually you don't need more than a few MB free space of your 3.65 GB (for archived track logs); the available space there never influences the ability to calculate routes. (it will affect the possibilities of future map updates though, that's why Express warns you, but "on the road" this isn't important)

A master reset doesn't erase stuff from the external memory (it would be a bad thing to loose your maps); it only erases the internal memory.

The problems you are experiencing are probably caused by the complexity of the route. Some important factors are: length of the route, number of via points (a higher number of via points requires less calculations for the zumo), avoidance settings (more avoidances makes route calculation harder), and last but not least, the complexity of the map.

0 BTLAAKE over 11 years ago

I compared the Subclass field generated in BaseCamp and MapSource (I loaded your route into MapSource, recalculated and made appropriate changes) for your 200 mile route. I have a different map version then you, so I had to recalculate your route for the comparison. Anyway, I found ~20 differences out of ~280 subclass entries. This may or may not be related to your initial issue. Approximately 8 occurred before you reached the loop portion of the route – did you have problems in that stage (ca. first 30 miles)?

I also noticed that some of the points you entered are not actually on a road ( for my map version). I do not know if this will cause a problem with Zumos or not. It’s something you can ask other Zumo users.

As others have said, your external memory is not the problem. Garmin gives external storage values based no maps or only a base map present. I believe your unit came with city navigator installed. Almost all of the files below Drive in your jpg are related to maps. That accounts for over 2gb of the memory and is a reasonable figure for city navigator NA.

0 BTLAAKE over 11 years ago

I’ll answer your second question first. I have a different version of city navigator NA (2012.1). Besides adding/removing roads and POI, I wouldn’t be surprised if they tweak existing roads occasionally. These tweaks could be an adjustment to the location of points, as well as the change in the number of points or choice of points used to create the graphic lines we see on the map. So, for example when I zoom in tight on your 698 Hwy4 point I see it ~20 feet off the road in my version. This is why I had to recalculate the route you supplied so that I could compare a BaseCamp route to a MapSource route. To do the comparison I needed the same route points and locations to align the two routes.

As for the first part, I can’t give you one. The subclass field is part of the Garmin extension and they are not required to explain it. In addition the entry is in hex and could easily contain multiple instructions with what to do with a particular point or the next series of points. Somehow, the applications (BaseCamp, MapSource or Device) have to know which points belong in the route directions (and which don’t), to provide a proximity alert for these points, what instruction should be given at a point in the route directions (verbal/written) etc. At other times, a section of points may require no action. My guess is that the subclass field provides this information, but this is only a guess.

With respect to the section prior to the loop, there were differences around US 377 (entering and exiting), the intersection prior to reaching US 377 (Ben Day Murrin Rd) and also when entering Aledo at the intersection with Hwy 5. If your recollection agrees any of these locations, then the subclass field may be the issue.