Huge BC Database Potential

Former Member over 12 years ago

Okay, I think I've learned that I need to get used to putting EVERYTHING I ever plan to save into a single database that's stored in the "cloud" (or wherever). We don't need no stinkin' folders and discrete files.

Given that, I need to look at how I've used MapSource over the past decade or so. I have a folder for every year going back to 1997, with files in each related to separate trips, some lasting two weeks or more, with tracks and waypoints related to each specific trip. I never wanted to carry every waypoint to every file, let alone every track.

With the BC approach, every waypoint I've ever saved is going to be in the file, along with every track and any routes I see fit to leave in there. it won't take very long until this database is going to get well beyond unmanageable, or perhaps I'm missing something.

Is the solution putting the stuff from my Nuvi (which has much better reception and other features) back into MS so that I can file it in a manageable fashion? I've been driving (or riding) for almost 50 years, and I use Garmin software to keep track of the last 15 years or so, as well as documenting (via routes) earlier journeys. They tend to blend together otherwise.

0 stuartmw over 12 years ago

Well BaseCamp is a (single) database oriented application. MapSource is a file oriented application. There are drawbacks with both approaches. You've pointed out possible issues with the former.

My advice is to use whichever suits you best (I use MapSource).

0 Former Member over 12 years ago

You can still archive your old routes and tracks into files using the export function of Basecamp. These can then be opened in Mapsource or imported back into Basecamp.

To me, the big advantage of Mapsource is that I have a single database of waypoints that I can easily use in multiple routes. I can filter the waypoints using lists and I can organise these lists into groups using folders. Each route is just an ordered list of waypoints. I can choose to store tracks in Basecamp or I can import them from files when required.

You are not forced to store everything in a single database. You can even use multiple databases, but the interface is a bit clunky as you need to use backup and restore to switch between them at the moment.

0 stuartmw over 12 years ago

You can even use multiple databases, but the interface is a bit clunky as you need to use backup and restore to switch between them at the moment.

I take the view that BaseCamp is database oriented (by design) and switching them, or allowing different ones to be opened, is making it a hybrid file/database oriented mess. Ack! But each to his/her own--MapSource works for me.

0 C14_Rider over 12 years ago

I switched to BC about 6 months ago after much foot-dragging, and I'm happy enough with it now that I don't use MS at all any more. I consider a BC "list" to be the equivalent of a MS "File" and that seems to fill the bill for me. I start with one master waypoints list that I imported from MS and has every waypoint I've ever created and saved, almost all starting points or intermediate and final destinations. For a new trip, I create any new waypoints and all required routes in that waypoint list to start with, getting them just the way I want them. Then I create a new list in a "trips" folder and name it with a date and description like "120905 (Short Trip Description)" for a trip starting on 5 September. This sorts all trip lists by date. I name the routes for that trip like "0905 1 B from A", 0905 2 C from B", 0906 1 D from C" etc., so they are sorted within the list in the order I will do them.

Then I go back to the waypoints list and I select and "show on map" all the routes, then draw a selection rectangle on the map that generously includes all routes, and thus also all waypoints within the rectangular area, then I "send" all the selected items to the newly created list. This works very fast. After checking to ensure all waypoints and routes got sent ok (they always have) I go back and delete the routes only from the master waypoints list. So I end up with a list for each trip, with multiple routes and all waypoints in the area of the routes in that list. Then I clean all previous data off my Zumo and send that trip list to it and it gives me everything I need for the trip.

As to database size, I now have 634 saved waypoints, 188 routes in 34 trips comprising 24,000 miles, and 7 tracks (I don't use tracks much). The database is 2.8 Mb, so perhaps you can extrapolate some from there. It seems to me I can go a long time before running into any database size issues. But we'll see.

0 Former Member over 12 years ago

As to database size, I now have 634 saved waypoints, 188 routes in 34 trips comprising 24,000 miles, and 7 tracks (I don't use tracks much). The database is 2.8 Mb, so perhaps you can extrapolate some from there. It seems to me I can go a long time before running into any database size issues. But we'll see.

Thanks for the feedback. It seems we all have methods that best meet our needs. Unlike you, I use tracks a lot, mostly to keep track of when things happened, plus which the elevation profile is helpful in the mountains in the winter -- good to know when I'm going to get to the summit, or better yet, down to below the snow on the other side. In any event, I think tracks are bigger memory hogs than routes are, but I could be wrong.

I used to think I was a sophisticated GPS user, but having spent quite a bit of time reviewing these threads, it's apparent that I'm a rank amateur. I've never gone into the raw data files or done any of dozens of other things that seem to be commonplace to the members of this community. Live and learn.

0 -ceej over 12 years ago

nice organization

I like your organization of trips. I do mine (currently) by location or sometimes by 'name of trip'.
I mention the following not because it is 'better' than what you do, but to see if my understanding of what you are doing how things work is correct.
Couldn't you select and drag all of the waypoints that you need for your new trip into your new trip-list, then create the routes there? You would not have to do any 'clean up' from the waypoint list itself? If as you were creating those routes you discovered that you omitted copying a waypoint that you needed, you could just create/copy the missing one(s).
But in any case, I like your description.
-ceej

I switched to BC about 6 months ago after much foot-dragging, and I'm happy enough with it now that I don't use MS at all any more. I consider a BC "list" to be the equivalent of a MS "File" and that seems to fill the bill for me. I start with one master waypoints list that I imported from MS and has every waypoint I've ever created and saved, almost all starting points or intermediate and final destinations. For a new trip, I create any new waypoints and all required routes in that waypoint list to start with, getting them just the way I want them. Then I create a new list in a "trips" folder and name it with a date and description like "120905 (Short Trip Description)" for a trip starting on 5 September. This sorts all trip lists by date. I name the routes for that trip like "0905 1 B from A", 0905 2 C from B", 0906 1 D from C" etc., so they are sorted within the list in the order I will do them.

Then I go back to the waypoints list and I select and "show on map" all the routes, then draw a selection rectangle on the map that generously includes all routes, and thus also all waypoints within the rectangular area, then I "send" all the selected items to the newly created list. This works very fast. After checking to ensure all waypoints and routes got sent ok (they always have) I go back and delete the routes only from the master waypoints list. So I end up with a list for each trip, with multiple routes and all waypoints in the area of the routes in that list. Then I clean all previous data off my Zumo and send that trip list to it and it gives me everything I need for the trip.

As to database size, I now have 634 saved waypoints, 188 routes in 34 trips comprising 24,000 miles, and 7 tracks (I don't use tracks much). The database is 2.8 Mb, so perhaps you can extrapolate some from there. It seems to me I can go a long time before running into any database size issues. But we'll see.

0 C14_Rider over 12 years ago

You are absolutely right, I could do it that way. But the "clean up" is really quite trivial, only a click, shift-click, and press the delete key, and it's done.

Probably the reason I do it as described is two-fold: 1) I am more confident to draw the selection rectangle around (generously and completely enclosing) the routes after they exist and I can clearly see their extents, rather than having to imagine where they will go. Sometimes as I'm planning a route, various alternatives or interesting side trips may extend it in a direction I hadn't thought of until I do it. And 2) I really do want ALL the waypoints I have EVER created that are anywhere near my route to be on the Zumo when I am on the route. This is so if I have a whim to re-visit some place, or just want to see how far away some place is that I have a waypoint for (say a highway oasis or a nice food stop), it will be there for me to use. That's why I use a selection rectangle to get EVERY route and waypoint and send it to the list and subsequently to the Zumo for that trip. (Note that before I hit 500 waypoints, I always used to just send them all, but now my 600+ waypoints will generate an error message since my 550 is limited to 499 or 500 waypoints, thus the selection rectangle which always excludes enough waypoints to get me within the limit.)

There are definitely many approaches to doing this and surely whatever works for you is the right way.

BTW, you mention "dragging" to lists. I have tried that, but notice that at least in the case of dragging hundreds of waypoints to another list, it seems to take forever. Whereas doing the same thing by right clicking on one of the selected items and selecting "send to" seems to work many times faster. Not sure why there's such a difference, but that's why I use "send to" all the time.