routes with street intersections as viapoints, NOT POIs

You might not want to duplicate your 'Home' waypoint if the duplicated route contained that point.

True, but for points that are only associated with a route (via points or shaping points) there should be no problem with duplicating these.

Steve

BC 3.2.2 Error Report

Attached is a simple route from Estes Park Best Western to Winter Park Best Western with a stop in Hot Springs. I used the insert tool to add 3 points to make the route go through Rocky Mountain NP. I sent this to my Zumo from BC. I also sent it to a gpx file (attached) and manually copied it to an SD card. I imported both versions into my Zumo 665. Both routes behave the same in the Zumo.

1. when looking at Custom Routes, select the route, Map and the flags for the 3 Waypoints appear and those for the 3 inserted points do not display. (Nice!)

2.With either route, I go to Add/Remove points to review the points. The Zumo crashes with a Data Abort (register and cpsr available if you need it). Try again and the first page, 4 points of the route display. The first of these 3 via points is erroneously named "& &" in the Zumo "Fall River Rd" is the name in BC. Hit page forward and the Zumo crashes with another Data Abort. Try again and the second page appears. The next via point name correctly "Trail Ridge Rd". The third via point is named "& &", not "Trail Ridge Rd2" as in BC.

I opened this gpx file in MapSource and moved the two bad via points off, then back to the original locations, which makes MapSource recreate them with its logic. Comparing the two GPX files shows the difference is in the middle of the Subclass field for those points. Below is first the BC, then the MS Subclass fields for the first of this malformed points. Note the center of the BC one is FFFFFFFF, which would be strange if these were parameter fields.
<gpxx:Subclass>0000AB617F00FFFFFFFF0F1CB400FABAC4EA</gpxx:Subclass>
<gpxx:Subclass>02C0AB617F00232097070F1CB400FABAC4EA</gpxx:Subclass>

I believe BaseCamp was somewhat modeled after iTunes. .... Now, we could of course discuss whether this is the best approach for an application like BaseCamp. (I think I know your answer already. ;) )

I have refrained from mentioning the obvious similarities to iTunes out of politeness and respect for the forum participants. I will continue to be polite and simply say that your guess is probably spot on. Especially if you were imagining copious expletives. :eek:

I will take the opportunity to mention that even many hardcore Apple fanboys find it nearly impossible to say anything positive about iTunes. Regardless of its worthiness as a model, I sincerely hope you folks plan to eventually implement Basecamp a whole lot better than that other evil app.

In other words, I hope you do better in future than Basecamp 3.2.1 and Mobile PC 5.00.70. These are benchmarks that should be fairly simple to exceed.

...ken...

I have refrained from mentioning the obvious similarities to iTunes out of politeness and respect for the forum participants. I will continue to be polite and simply say that your guess is probably spot on. Especially if you were imagining copious expletives. :eek:

I will take the opportunity to mention that even many hardcore Apple fanboys find it nearly impossible to say anything positive about iTunes. Regardless of its worthiness as a model, I sincerely hope you folks plan to eventually implement Basecamp a whole lot better than that other evil app.

In other words, I hope you do better in future than Basecamp 3.2.1 and Mobile PC 5.00.70. These are benchmarks that should be fairly simple to exceed.

...ken...

And as a Mac user I agree and have mentioned it many times on the Mac BaseCamp forum...... It's not a good thing.

Okay, time to be serious about the limitations of the Basecamp data model. Your analogy of playlists versus tunes is either a really Good example or a really good Bad example, depending upon your perspective.

If I want to just play tunes and already have a library of tunes, it makes sense that I just want a list of the names and locations of the tunes for my tune player.

I'll go another step and agree that even if I want to maintain the tune contents of multiple players, lists of names and locations are a great way to do it.

But there is something that makes this as sensible as it is. I don't use the list maintenance tool for anything else, e.g. if I want to edit the tunes themselves I use another tool. The tune management tool doesn't pretend to be anything else so a model that is based on single copies of things with a bunch of indexes (Basecamps lists, tune player playlists) works fine.

Mapsource and Basecamp have some functions where lists perhaps also serve us well. But they also have functions related to trip planning and route and track editing that are not served well by lists of pointers. For these functions we need the ability to play with a complete independent copy.

In Mapsource, we load a copy of the original (the original is still in the GPX/GDB file on disk until/unless we do a Save). We can play with the copy safely in the knowledge that as long as we don't save it we can screw it up as badly as we wish and still go back to the original.

Restoring a backup is not comparable for a couple of reasons. First, you have to consciously make a backup before you start messing with something. How many of us have such foresight? Secondly, as has already been pointed out, we are backing up and restoring the entire collection when we only want to be able to work with a subset of it.

Have you ever considered adding the ability to do trip planning or track editing "projects"? A project would be different from a list in one crucial way. Everything in a project is a real copy and cannot change anything back in the collection, e.g. since there is no access from the project back into the rest of the collection, if I don't have a copy of something in the project I can't use it until I make a copy into the project. This would require the ability to save a project and even copy a project to use as the basis for another similar project.

Think of a project as a mini collection. .... Heck, as I think about it, just give us the ability to have multiple collections and save individual collections as named GDB files.

That would honour the current data model and still provide the necessary trip planning and track editing abilities.

Just out of curiousity, how aware is the Basecamp team of its importance as a trip planning tool? Or even what features are necessary for a good trip planning tool?

The importance of its trip planning capabilities will only increase with the demise of Mapsource. If you think there is noise now, just wait until we can't use Mapsource effectively any more and are forced to use Basecamp for everything rather than just cherry picking between the two of them.

...ken...

Well stated Ken. Everything you've said applies to the Mac version as well.

If I find a 3rd-party trip planning tool superior to GE that integrates with my Garmin.... or even a "plugin" to GoogleEarth that links well with my device... I'd pay genuine cash money for it.

I think this sums up what the various development teams are up against. I'd pay for a version of a Mac equivalent MapSource 6.13.7 that included all of the additional tools in BaseCamp for Mac.

It's also the reason, I'm afraid, that what we have is basically what we'll get for the foreseeable future.

Think of a project as a mini collection. .... Heck, as I think about it, just give us the ability to have multiple collections and save individual collections as named GDB files.

Just out of curiousity, how aware is the Basecamp team of its importance as a trip planning tool? Or even what features are necessary for a good trip planning tool?

The importance of its trip planning capabilities will only increase with the demise of Mapsource. If you think there is noise now, just wait until we can't use Mapsource effectively any more and are forced to use Basecamp for everything rather than just cherry picking between the two of them.

...ken...

The suggestion for multiple collections is an excellent one Ken. It's what I was hoping for when he was telling me to create a folder rather than a list. I've spent a fair amount of time trying to duplicate my folder structure and naming system using the lists format and without the ability to have sub-lists it's not very feasible.

To illustrate:

Say I have a list for the State of Kentucky. I have rides I've done over the years in different parts of the state, street or off road, alone or with a couple groups I hang with, along with differing versions of the same route or track under all that. With a list for Kentucky and no ability to filter except by BC's filters it is a huge bunch of info to wade through to find what I'm looking for. There could easily be 50 routes, 100 tracks and 500 waypoints (without categories to help there).

For instance I have a folder 'kentucky\eastern\daniel_boone_NF\dirt' and it has 13 files each with saved tracks, waypoints for various things in the forest, preplanned routes and their modded decendants. Now that gets dumped into one big list with the rest of the state and all organization is lost. I could have a list with the same name as the directory string I suppose but there is still no single entry point for Kentucky. And to make it all the more confusing I have a html page in each with links to more info on each area such as the Forest Service and their offices. How do I get that into BC?

I like the file system and fine grain control it provides. Not a library fan in the operating system or programs.

The other thing on my mind is open source, If Garmin is abandoning MS would they release it into the wild to be developed and maintained by the open source community. I think that would create huge good will amongst the folks who want more than BC is going to provide.

John

Sojourn,
Would being able to put tags on each element be helpful if you could later view/filter/etc based on those tags? For example, you might put:
Motorcycle, KY, 2011, BandidosMC, food, dirt
on a waypoint. Then you could do things like look at all dirt tracks in KY, or all the rides you did with the Bandidos in KY, etc etc.

I've often felt that supporting free-form tags on all elements, and giving a method to filter/search/display/manage by said tags would give people much more flexibility to do as they wish.

P.S. I have no idea if you hang with Bandido's.... no offense meant either way, to you or to them. Just a random example I came up with.