BaseCamp 4.0.0.6 is available

using the measuring tool to find out distances, is there a way to turn off the sq metres and the orange trangles formed by the tool as i dont want the area only the mileage it does clutter up the screen? thank u

Unfortunately that is not currently possible.

Just in case it's got forgotten ...

Dragging the internal storage folder from my nuvi 1490 into BC no longer retains the Favorite 'categories', instead everything is listed in one huge list. I raised this before and was told the intent was that categories would be retained, so hopefully will be fixed prior to the full release of 4.0?

This is an intentional change (one that I am personally not happy about). Hopefully we can fix that at some point, but not in 4.0.

how can i move routes from the desktop into the library please?

In what format do you have these routes? If they are in a gpx or gdb file, you can import them and drag and drop them into BaseCamp.

"Backwards Planning" using the new trip planning features

We've had a discussion going on the ZumoForum about the new trip planning features. We think it has great potential, and is a welcome addition to the product.

One of the guys suggested a nice workflow where you would set the arrival time at your destination, then work backward to see at what time you would need to depart to achieve that.

That use case seems to work great for a trip with only starting and ending waypoints.

We tried to add an intermediate waypoint with some stoppage time, as for a lunch stop, and that's when things got interesting.

Here's the end result of the discussion and some tests that some of us ran; hopefully it will help get this sorted. If you're interested, you can follow the entire thread at zumoforums.com. The link is for the entire 4.0.0.6 beta thread; the discussion about the route planning starts about halfway down the first page.
---
I can't figure out exactly what it's doing either, but I totally concur that its ability to magically support Don's "work backwards" planning is limited (and buggy) when there's an intervening waypoint.

I did manage to get it to work by helping it out a bit.

Scenario: We're meeting some friends for lunch at the Hard Eight BBQ in Stephenville at 12:00. On the way there, we want to stop and have coffee with some other friends at Storm's in Lampasas. When should we plan to meet in Lampasas?

First, I set the 12:00 arrival time for lunch. I observe that BC now tells me to leave Storm's (coffee) by 10:42 to make it to the lunch on time. OK, so I manually then "lock in" the departure time at Storm's for 10:42, and manually set the arrival time at Storm's for 10:00 to allow 42 minutes for coffee. Then BC will automatically calculate my departure time as 8:43 to make it all work.

I have to manually set the departure and arrival times at the intermediate waypoint or it will not work correctly.

If I set only the arrival time for coffee at 10:00, it will show me leaving there at 10:00, which obviously is not what I want. In other words, it will not magically calculate a layover time to get me to lunch exactly on time. Fair enough...that might be asking a little much of it.

If I set only the departure time for coffee at 10:42, it gets totally wigged out, and shows me arriving there (at coffee) at 7:10. That corresponds to its calculation of 1:18 from my starting point, if I leave now. This is what Tom saw...it freaks and wants you to leave right now. Kind of like a nagging spouse (not mine, of course).

So here's my takeaway. If you want to use Don's approach to ride planning, working backward from arrival times, you need to do it a piece at a time. Set your arrival time, then work backwards through each waypoint, locking in its departure time to whatever BC calculated, and setting its arrival time to allow for whatever layover you want. It seems to work just fine using multiple waypoints, each with potentially different arrival and departure times (I'm avoiding using the term layover time to avoid confusion with the "layover time" setting in BC).

Corollary takeaway: don't try to use the BC "layover time" feature if you're planning backwards.

FALAGAR-

I'd like to second YOUNGRIGHTY's observations. The trip planning with layover works great going from a start to finish, but ya gotta trick it with his method to get it to to calculate a start time to arrive at a destination by a specific time if you want to stop at some points along the way (working the feature backwards).

If I may, I'd like to ask a related hardware question. Please don't shoot! It's related to the recent changes in BC.

We've seen at least two really good changes to BC that aren't supported by the hardware. Those are the ability to select/deselect way/via point announcements and this new trip planning feature where layovers can be set (one that I've wanted for a long time and think is terrific!).

Neither are supported by the Zumo 66X hardware. When might we see firmware that will make this possible?

Thanks!

Tom

Those are the ability to select/deselect way/via point announcements...Neither are supported by the Zumo 66X hardware.

Tom,
There actually is a way to make the "don't announce" feature work. Here's a post I made on zumoforum:
The shaping point "don't announce" feature definitely works on my Navigator IV (a 660), but you have to hold your mouth just right.

If your original route was created using waypoints, even if you later go in and mark them as shaping points (i.e. set them to "don't announce"), they will still show up as flagged and announced vias when you download to your device.

If instead, you use the rubber band to interactively put in the shaping points, it will work as advertised.

Then there's another little wrinkle to this. I almost always create my routes by starting with a beginning and end point, letting BC calculate an initial route, then shaping it interactively using the "insert" tool. The resulting points will default to shaping (unannounced) points. If, however, you draw the route from scratch using the "create route" tool, those points will default to announced vias; but you can still go in and set them to "don't announce" and make them work correctly.

I have played around with this a lot, probably to the point of OCD-ness. I had a route that had a bunch of vias, all but one of which had been created using the insert tool, and all of which had been set to "don't announce". One of the vias had been a waypoint that I inserted into the via point list. That point kept flagging even after I set it to "don't announce". Only by putting in a shaping point just down the road, then deleting the via that came from the waypoint and deleting the waypoint from my list, could I get the device to quit flagging it.

I had one case once where I had a shaping point that kept flagging on the device; the only way I could explain it was that it was very close to a state park. The best theory I could come up with was that it was so close to the device's point of interest for the park, that it put the flag on there. I still haven't got that particular subtlety completely characterized.

One of these days I'm going to curl up with a few gpx files and figure out exactly why it behaves this way.

Give that a try and see if it works for you.
Jim

Jim -

Thanks for that! I'm going to take my usual route home and add several way points and via points and see if I can make this work. I think I'll let it announce the usual waypoints, but add several new way and vias and set them to not announce.

Of course, I'll have to remember to turn Jill on.

Oh, sorry... family forum.

Tom

Thank you guys for pointing out the 'backwards planning' issue. This is hopefully something we can fix, this won't make it into 4.0.1, but it's definitely something we should be able to make happen.

Regarding the hardware question: full shaping point support is coming to hardware, the Zumo 350 supports it, e.g., and the old ones could as well if they get a firmware upgrade. Unfortunately that part is not in my hands. As YOUNGRIGHY pointed out, currently the older Zumos support shaping points as long as they are not "real" waypoints (just route points created with the route tool) and they are located on either an intersection or an address.

I don't think there is BaseCamp trip planning support on any devices yet, but the idea is definitely to make that work on devices as well. BaseCamp exists to enhance your device experience, so that is definitely something that we want to make happen.

Library/Map Separation Line Moving

Something wrong under Win 7, the left hand pane width increases from where you set it, and the toolbars don't remember where you put them either. On the plus side the unlisted data seems to work well now :)

Everytime I open the BaseCamp Beta 4.0.0.6, the line that separates the Libray window from the Map window moves to the right about 2 inches, and makes the Library window wider and the Map window smaller.