BaseCamp 3.3.0.3 Beta available

Categories / Flagship model unit support (or lack thereof)....

I've been following posts here regarding categories...

Here's what really "irritates" me (for lack of a better term): (I wish someone with "clout" at Garmin would follow up on this and get back to me!!!) ~HINT TO FALAGAR !!!!! ;)

It's the total lack of category support (GPX waypoints) on the unit itself.... (FIRMWARE)* ~ There is no support whatsoever, for categories on Garmin's "flagship GPS" (outdoors) model, the Montana! Hence, without support in Basecamp, there is really no support for organizing waypoints whatsoever! :(

*The only waypoint category support (on Montana) is in the form of symbols.~ This would be fine if you could sort and pre-select categories on the unit. But you can't. There is no way to filter waypoints (on the unit iself) using these existing symbols.

IMPLEMENTATION NOTE: Ironically, this would be relatively simple to implement IN FIRMWARE (without effecting other models, and/or basecamp): The data field (symbol) is already there! It's just not being used as it should be.....! ~ For "usability", symbols should be used (optionally) as a category for filtering on the GPS unit itself. (and possibly on Basecamp too)

BaseCamp tries to be smart in picking a profile if it can.

I'm not sure I like a program making my decisions. I'd prefer a simpler approach, whatever the default profile is set in the taskbar is what imported routes get.

I thought it would be obvious from the list names I used (intentionally) to illustrate.

... [T]he TEST list that I created in the CATEGORIES folder is a category and was correctly added.

The ROUTE1 and ROUTE2 lists that I created in the My Collection root are for route planning so I do not want them to appear as categories on the device.
...
The point is that there are multiple reasons for lists. Only one of them is for categories.

So if I have a list that is holding a route or two and their associated waypoints the very last thing I want is for that list name to be added as a category to all the waypoints it contains. That list is for route planning in Basecamp, not for categorization of the waypoints for search purposes on the device.
...
Lists are used for organizing many things for many reasons. They are used for too many things to make the simple assumption that we want them all to be added as categories on the device..

...ken..

I have been trying to follow the discussion regarding CATEGORIES, but, I must say that I am hard pressed to understand the reasons behind your insistence that they must be different from lists because you don't want lists not used as CATEGORIES to be on the device. What is the downside for the device user given that the scheme proposed and implemented by the BaseCamp team will only entail the device user having to perhaps deal with a few additional lists?

Might not having the ROUTE1 and ROUTE2 route-planning lists available on the device be a benefit at times?

Finally, what can I not do with the BaseCamp implementation of CATEGORIES that I could do with the MapSource implementation?

I'm not sure I like a program making my decisions. I'd prefer a simpler approach, whatever the default profile is set in the taskbar is what imported routes get.

Imagine you have the automotive profile set in BaseCamp, and import a route with the vehicle type set to bicycle.

Would you really want that route to now use the automotive profile? It would most likely look very different after recalculating!

The goal is to keep the old settings (and not just change settings without the user knowing), while also trying to match a profile if a match can be made.

I feel that setting the imported route's options to the current default profile would be more confusing.

I was not aware of the fact that gdb files from MapSource include the routing properties. When I changed the BC automotive profile to match what I've got set in MS, the imports didn't use a custom profile for my routes, but assigned the automotive profile instead. [Update: Strange, I changed the route properties in MS, removing the U-turn avoidance, recalculated my routes and when I imported into BC, they still were assigned Automotive profile rather than None (Custom). It would be useful to know what triggers the BC activity assignments on imported routes.]

Would using the name "Custom" instead of "None" make for easier user understanding?

Swapping map and data views shows the profile assigned to each route and makes it easy to see all the summarized data for my routes.

I was not aware of the fact that gdb files from MapSource include the routing properties.

Would using the name "Custom" instead of "None" make for easier user understanding?

I do not think MapSource does, but BaseCamp puts the route options into GDB. MapSource doesn't have options on a per-route basis, it always uses the current default route options.

I agree that Custom might be a better name for that option. I am not sure if we can still change this for 3.3 (localization is pretty much done already), but we'll see.

Thanks for your feedback.

Wow, I've been humbled. As tech savvy as I am, I never thought I'd have to mess around with default windows theme settings to "un-hide" windows highlighting in cases like this...... Problem solved!

I resemble that remark!!

I haven't had as much problem with Basecamp but I've had a similar issue with Thunderbird that was driving me nuts. So I decided to try this out this morning and it did the trick.

I'm also not sure what caused it. It turned out, in my case, that all I had to do was switch from the Aero theme I had selected to Win7 Basic and then switch back to the same Aero theme and the contrast was back.

It's a trick I'll have to try to keep in mind.

...ken...

Scrolling the Data View

The lower left Data View pane could use some additional scrolling logic. Sometimes the bottom line is somewhat chopped off and selecting it with the mouse becomes difficult to rapidly do. It may operate better if there was always a 2 line buffer below the target selected data item. When moving off the existing view, always reset the selected data item at the top. It is extra effort when selecting a new data item on the map to need to look up and down the data view for which item is highlighted.

Another example is when I want to recalculate all my routes in a list. As I select a route, Advanced>Recalculate Route, the scrolling window needlessly scrolls so that route is the last line of the data view. I have to scroll up to get to the next route.

I'm not trying to write a spec. for this feature in this abbreviated forum, but I think you get the picture. The data view scrolling needs some user productivity enhancements.

What is the downside for the device user given that the scheme proposed and implemented by the BaseCamp team will only entail the device user having to perhaps deal with a few additional lists?

Let's start with the obvious: you now have a bunch of lists cluttering up your Collection that would otherwise be unnecessary. See my answer to your last question for others.

Might not having the ROUTE1 and ROUTE2 route-planning lists available on the device be a benefit at times?

I can't think of any benefit. Can you?

The lists I make for creating and experimenting with routes for trip planning purposes in Basecamp are exclusively for that purpose. And they are only there because there is no other alternative method in Basecamp (unlike in Mapsource). I don't want those "route" lists at all but in Basecamp I have no choice. So I can't think of a single reason why I would want those list names to show up as categories. And one very compelling reason why I don't: it clutters the search process on the device.

Hint: the only reason for categories is to make finding things on the device simpler and quicker.

Finally, what can I not do with the BaseCamp implementation of CATEGORIES that I could do with the MapSource implementation?

You can't add a category to a waypoint by simply selecting a category name in its properties. You have to create a list and then drag/drop a copy of the waypoint into the list.

You can't change a category in a waypoint by simply selecting a different category name in the waypoint properties. You need to drag a copy of the waypoint name from one list to another list and then delete it from the first list.

You can't bulk add/change categories in a bunch of waypoints at all. And never will be able to with this implementation in Basecamp. Not even if the developers get around to adding the ability to edit the "Lists" tab in the waypoint properties because the Lists tab doesn't even show up when you select a group of waypoints and right-click/properties.

If you have any waypoints that appear in non-category lists in your Collection you have no way to block the non-category names from appearing as categories in the waypoints when you transfer them back to your device. The only way to get rid of the unwanted categories is to edit the waypoints individually on the device. Which sort of defeats the purpose of using the PC to manage them in the first place!!

...ken...