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

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.

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.
{lots of great verbosity}
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...

Very well said Ken... I think this last bit about trip planning is the gold nugget of this thread:

At the risk of "piling on", I gotta say that I have been greatly disappointed by Mapsource too: Years ago I had Delorme's trip planning software. Well, enough PC&OS upgrades, and major new roads, and that software is obsolete. I used GoogleEarth and it seemed to be relatively adequate given its price (free). Then I bought my Garmin and Mapsource was what we had, but it was quite poor compareed GE. About all I used it for was to manage data on my Garmin. GoogleEarth is where I continued to do the "heavy lifting" and then transfer the kml file to Mapsource and ultimately the device. Along came Basecamp and for me at least, it has been a great improvement over MS... largely for the reasons you are not happy: i.e. the way it keeps My Collection without having to worry about which file on the filesystem has what I need. But, true to your analysis above, and given what I just explain, that is because I use NEITHER application for trip planning, and only to manage and interact with my Garmin device.

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.

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.