routes with street intersections as viapoints, NOT POIs

By comparison, in Mapsource, moving the route cursor over the intersection, a popup window will appear letting you know when you've captured the intersection (defined by the two street names).

Which is why I use MapSource for creating routes. Fortunately that doesn't cause issues with my units. I use map points (not POI's) in my routes often, just as you're trying to do, principally to force certain roads to be used.

I agree that route creation in BaseCamp is "clunky" by comparison. It'd be nice if MapSource's route line drag'n'drop was supported without having to go into edit mode first.

Unfortunately it appears, to me, that MapSource is being abandoned by Garmin in favor of BaseCamp. Hopefully that is not the case. In any event MapSource supports my devices so unless I buy a new unit I'll be ok.

I have no answer to your question but I do have a suggestion regarding viapoint placement: instead of at the intersection put them just past the intersection and on the road you wish to be on. If nothing else it makes it easier to see if the route as transferred and recalculated actually follows the route you developed on the computer. It also helps in route shaping.

Unfortunately it appears, to me, that MapSource is being abandoned by Garmin in favor of BaseCamp. Hopefully that is not the case. In any event MapSource supports my devices so unless I buy a new unit I'll be ok.

This is what I fear as well - for what I need, in its current version, Basecamp is not a step forward.

instead of at the intersection put them just past the intersection and on the road you wish to be on. If nothing else it makes it easier to see if the route as transferred and recalculated actually follows the route you developed on the computer. It also helps in route shaping.

Jack, interesting option that I hadn't considered. My understanding is that a point on the intersection is a shaping point (i.e. an unannounced via point). Placed off of the intersection it would be a via point (i.e. be announced on the gps). Is there some margin or buffer whereby if the point is just past (or just before) the intersection it is still a shaping point (i.e. unannounced)?

Also, what happens when one inverts the route - does that create problems with it being announced (now it is just before the intersection)?

Regards

I'll create a case for better via-point routing in BaseCamp. The distinction between announced and unannounced via-points has always been a bit too subtle for me (and I assume a lot of our users). So hopefully there is something we can do about this.

And I am sorry to disappoint, but yes, MapSource has not been worked on in quite a while, and there will be no new releases of that software.

You are of course welcome to keep using MapSource, we will keep it on the website for the foreseeable future.

I'll create a case for better via-point routing in BaseCamp. The distinction between announced and unannounced via-points has always been a bit too subtle for me (and I assume a lot of our users). So hopefully there is something we can do about this.

I'm heartened to hear that you'll make the case for improvements in Basecamp but discouraged about future support for Mapsource.

Here are some points especially for many of us who take 'roads less traveled', scenic or secondary roads either by bike, motorcycle or car and build routes in Mapsource or Basecamp.

The ability to create a dependable route of travel that can be viewed on the gps without clutter is the highest priority. For example, a significant number of us ride bikes for pleasure. The routes have plenty of curves and deviations - they are anything but long straight segments with occasional turns. We don't want the shortest distance or fastest time but rather the most enjoyable journey.

To accomplish this (and keep the software from finding the shortest distance or fastest time) we end up using multiple viapoints whose only purpose is to keep us on the designed route. Unless I need to turn onto a different road, I want my attention focused on the road and do not want an unwelcomed voice announcing that I'm approaching a meaningless viapoint that was only placed there to keep the software from setting up a different route.

With Mapsource, I know that I can put this viapoint on an intersection as the pop-up window tells me its on the intersection by naming the two streets. I also know that the zumo is not going to make a voice announcement for something that momentarily distracts me and is irrelevant. I take safety very seriously and do give attention to that gps voice. If I'm constantly being interrupted then I'm concerned I'll tune it out.

If Basecamp is the future, then it should have the capability to achieve the same outcome. As is (at least as far as I can tell), you hope you've found the intersection (unannounced viapoint) and not some POI that is just down the street. But its a shot in the dark and I haven't found a way to go back and fix it unless I create a waypoint each time Basecamp selects a POI instead of the intersection.

And then there's the issue of the flags for unwanted viapoints not on intersections which flags I can't just turn off or at least reduce it to a dot. It is quite frustrating to preview a map on a small screen and see it cluttered with flags that have been placed there by the software, not by my choosing. I might have 4 different routes to the same destination all slightly different. I want to preview each on the gps and then decide. When I see a cluster of flags it seems like another step backward and just doesn't encourage brand loyalty.

Recently, I loaded a route that calculated correctly in Mapsource but when loaded and recalculated in Basecamp, at a 'Y' intersection on a divided highway, instead of going left, Basecamp had the route going right, making a U-turn and then turning right again to go back to the correct road. I tried to create this segment in Basecamp but could not get the precision needed to place a viapoint on the intersection where it needed to turn left.

Finally, I don't understand the business model that stops supporting one software while launching another that is so lacking in critical functionality. It causes a lot of frustration for those of us who are only users (I don't consider myself an expert nor do I want to be) when we come upon these problems.

Recently, I loaded a route that calculated correctly in Mapsource but when loaded and recalculated in Basecamp, at a 'Y' intersection on a divided highway, instead of going left, Basecamp had the route going right, making a U-turn and then turning right again to go back to the correct road. I tried to create this segment in Basecamp but could not get the precision needed to place a viapoint on the intersection where it needed to turn left.

Finally, I don't understand the business model that stops supporting one software while launching another that is so lacking in critical functionality. It causes a lot of frustration for those of us who are only users (I don't consider myself an expert nor do I want to be) when we come upon these problems.

Thank you for your clarifications, that makes perfect sense. I linked this thread in our feature case, so it should definitely be taken into consideration.

We didn't intentionally make it harder to create the routes you are creating, that's just something that unfortunately slipped in.

We will keep working on making BaseCamp better, we really try to listen to what our customers say. We just can't please everyone, and sometimes it just takes a little longer to make things happen.

Do you happen to still have a copy of the route that didn't recalculate correctly in BaseCamp? I'd be happy to take a look. Please also include the version of the map you were using. Which version of BaseCamp did that happen on?

About the cluttering of flags, that is exclusively an issue on the GPS, correct? What symbols do you see in BaseCamp for these via-points?

Re. MapSource abandonment

I'll create a case for better via-point routing in BaseCamp. The distinction between announced and unannounced via-points has always been a bit too subtle for me (and I assume a lot of our users). So hopefully there is something we can do about this.

I'm surprised that BC development wouldn't have shaping points in the design specifications, test plans, etc. These shaping points have been used for years with the Zumo products. Via points that are on intersections where the designation is "road1 and road2" that are not Waypoints are treated special on the Zumo series.

None of us users has been able to interpret what is contained in a shaping point that identifies it to the Zumo as such. My guess is that something in the Subclass field contains that identifier, <gpxx:Subclass>010068027F00432051060F1DC000D66A38AB</gpxx:Subclass> is not a simple discovery though.

BC doesn't show hovering points while routing (try to select the intersection of the exit ramp from westbound I-88 and the southbound I-39 in Western Illinois). So getting non announced, non flagged points (shaping points) on a route for the Zumo is trial and error in BC. I have not tested them to see if BC properly specifies what the Zumo needs to define a shaping point.

Because motorcycle riders shape their routes with these points and there are many of them, riding a route where each is announced would drive one crazy with all the "approaching poi name", "arriving at poi name", etc. when all we want to do is route along a specific road. Waypoints and the flags they display on our routes are used for stops while touring, a pitstop or an attraction, not for every turn. The specialized routing algorithms that MS or BC do for some users are useless to me. I want a routing algorithm identical to how the GPS recalculates. That way, I know when I've got enough shaping points to follow my route and a deviation from my route will not totally mess up the route when I get back on track and the Device recalculates to exactly what I previously had. This shaping feature is one of the distinguishing characteristics of the Zumo series that makes it a motorcycle GPS.

Thank you for your clarifications, that makes perfect sense. I linked this thread in our feature case, so it should definitely be taken into consideration.

We didn't intentionally make it harder to create the routes you are creating, that's just something that unfortunately slipped in.

We will keep working on making BaseCamp better, we really try to listen to what our customers say. We just can't please everyone, and sometimes it just takes a little longer to make things happen.

Do you happen to still have a copy of the route that didn't recalculate correctly in BaseCamp? I'd be happy to take a look. Please also include the version of the map you were using. Which version of BaseCamp did that happen on?

About the cluttering of flags, that is exclusively an issue on the GPS, correct? What symbols do you see in BaseCamp for these via-points?

From what I observe it looks like Basecamp probably operates much better on Macs but it is very 'buggy' on Windows. For example, I'm using Windows XP with all the service packs and plenty of memory. Cntl + Z will seldom work. Instead I have to open up the edit window and press 'undo'. Right now I'm using a laptop and can't open the properties window. Why? when I last had it open, the laptop was hooked up to double monitors and the properties window was last opened on the secondary monitor. To use it, I'll have to hook up the monitors and move the properties window over to the primary monitor. I could go on but won't. The important part is that I only started using Basecamp 3 days ago to do straight forward maps - nothing complicated.

I'm using the latest version of Basecamp

Per the flags, they show up on the zumo 550 (with the latest firmware) as orange flags and correspond to all the unwanted POIs and announced viapoints. These announced viapoints almost always result when there are POIs nearby even though one is trying for an unannounced viapoint which is almost impossible if there are any businesses in the vicinity of the intersection. On Basecamp the flags only show in the properties window, not on mapview.

I will send the Basecamp gpx file with the route that created the U-turn. It is on the west side towards the middle of the route.

I'm surprised that BC development wouldn't have shaping points in the design specifications, test plans, etc. These shaping points have been used for years with the Zumo products. Via points that are on intersections where the designation is "road1 and road2" that are not Waypoints are treated special on the Zumo series.

None of us users has been able to interpret what is contained in a shaping point that identifies it to the Zumo as such. My guess is that something in the Subclass field contains that identifier, <gpxx:Subclass>010068027F00432051060F1DC000D66A38AB</gpxx:Subclass> is not a simple discovery though.

BC doesn't show hovering points while routing (try to select the intersection of the exit ramp from westbound I-88 and the southbound I-39 in Western Illinois). So getting non announced, non flagged points (shaping points) on a route for the Zumo is trial and error in BC. I have not tested them to see if BC properly specifies what the Zumo needs to define a shaping point.

Because motorcycle riders shape their routes with these points and there are many of them, riding a route where each is announced would drive one crazy with all the "approaching poi name", "arriving at poi name", etc. when all we want to do is route along a specific road. Waypoints and the flags they display on our routes are used for stops while touring, a pitstop or an attraction, not for every turn. The specialized routing algorithms that MS or BC do for some users are useless to me. I want a routing algorithm identical to how the GPS recalculates. That way, I know when I've got enough shaping points to follow my route and a deviation from my route will not totally mess up the route when I get back on track and the Device recalculates to exactly what I previously had. This shaping feature is one of the distinguishing characteristics of the Zumo series that makes it a motorcycle GPS.

+1 to what Dave726 is saying. In fact, most if not all, zumo users who create their own routes would say the same.