routes with street intersections as viapoints, NOT POIs

I know we're just voices crying in the wind and the Basecamp model is not going to change but I really can't let posts that perpetuate the myth that MS+File=Complicated and Bad and Basecamp+Database=Easy and Good go without comment as I'm afraid it's nonsense.

And I never said it like that. The reason I am trying to explain what we have done with BaseCamp is that some people seem to say the opposite: MS+File=Awesome and Basecamp+Database=Totally unusable. Which is also not quite nuanced enough in my opinion.

I can appreciate concerns about the usability of the BaseCamp model (and we have been and will be making constant improvements in no small part due to user feedback right on this forum), I can also understand that people have gotten used to MapSource and prefer to use files to organize their data.

I just try to weigh in when it seems that personal preference equals a general rule. BaseCamp has a different approach to how it manages your data, you are of course free to not like this approach. But that fact alone doesn't make BaseCamp unusable and bad.

Maybe we are wrong in assuming that a file-less all-in-one approach is easier to grasp for the average user. I personally don't think so. That doesn't mean we think BaseCamp is perfect. There is a lot we'd like to improve.

While the basic model of BaseCamp is unlikely to change, we are committed to improving its short-comings as best as we can.

Feel free to vent, but it's more realistic to point out things we can improve or fix in BaseCamp. (You are also more likely to get a developer response then, I can only manage to find the courage to reply to 'MapSource > BaseCamp' threads every so often.) ;)

I guess I am also asking to try to look at BaseCamp with fresh eyes, don't try to do things exactly like you did in MapSource, embrace the numerous BaseCamp-only features (it's quite a long list already, BaseCamp 3.3 will make this list quite a bit longer yet) and see what happens.

Thank you for your feedback, we appreciate it.

My last comment on this particular topic then I promise to shut up.

And I never said it like that.

My perception of what you typed is that you gave a description of what appears to me to be the complicated way Basecamp forces you to work then came up with a complicated, and unrealistic IME, file example for comparison. How else would you describe it? (that's a rhetorical question)

I can also understand that people have gotten used to MapSource and prefer to use files to organize their data.

I hope this isn't going to sound like a rude question but do you actually use Windows on a day-to-day basis? It's not just Mapsource that uses files, most Windows software uses files. My 76 year old Mother easily grasped the concept of files, it's not difficult.

You talk about using the iTune's model and iTunes does indeed have a database but it still deals with individual files and doesn't mandate where I store those files. I'm free to store them where I want and can freely manipulate them outside of iTunes without having to use any import or export commands.

But that fact alone doesn't make BaseCamp unusable and bad.

I think you're becoming defensive as I haven't suggested Basecamp is 'unusable' or 'bad'. What I have suggested is that using files isn't complicated and that I personally find them easier to use than the Basecamp database.

Maybe we are wrong in assuming that a file-less all-in-one approach is easier to grasp for the average user. I personally don't think so.

Forgive me but it's not about your personal opinion, it's about what your users think. Has Garmin ever run any customer tests to see what they think of the software? Not just with the 'average user' but also with people who have the capability to really put the software through its paces.

Feel free to vent, but it's more realistic to point out things we can improve or fix in BaseCamp.

I see this is one of those irregular verbs: You explain, I vent...

Anyway, I'm done. There's not going to be a change in the Basecamp model so I'm really wasting mine and everyone's time. As promised, I'll shut up now.

[whispers] Actually, I have a question. Databases have a nasty habit of becoming corrupt from time to time. With all my route information being in that database I'd like to know that I have some chance of repairing it. What happens when Basecamp starts if it finds the database is corrupt? I probably ought to ask that in a separate topic.

Kevin

Thanks. I need to include those files in my back-up regime.

Kevin

We also recommend using BaseCamp's Backup functionality. But that is something you would also do with MapSource to prevent data loss in the case of a hard-drive failure.

Hi Falagar,

Is there a description somewhere of what gets backed up with BaseCamp's backup function? Well, I'm actually more interested in a list of what does not get backed up.

.......

Hmmmm.... Now that I think about it a bit, I actually don't care what gets backed up. What I really care about is what does not get restored if I have to restore a backup.

So the real question is, what, if anything, do I lose if I have to use BaseCamp's Restore function to restore from a BaseCamp Backup?

Knowing I could easily restore things exactly to a known starting point would make me much more sanguine about experimenting with BaseCamp's features. It would mean I could just do a Backup immediately before starting to mess about, knowing that if I'm not happy with the results I can just restore. That would save having to always start with an empty library and import the stuff I want to work with before I can start doing anything.

Can I do that? E.g. will I be restoring absolutely everything I might have in the library to exactly the condition, with all the details, it had at the point the Backup was done?

...ken...

BC backup/restore

I've found BC backup/restore to be a good solution to protecting my data and to have various slates for different projects:

CustomPOIs.Backup = All my Custom POIs. I can restore it cleanly, add my MapSource trip routes, select the various POIs I want to include in my routes, copy each waypoint, paste it into the MS trip routes. Nobody says you can't use both programs and get the best of both worlds.

BCclear.Backup = BC with empty My Collection. Good when you want to look at a route without any other clutter.

AllMyRides.Backup = 9 years of routes and POIs so I can see where I haven't been or where old rides were in areas I'm planning a return trip.

2012 LA State Rally.Backup = One example of a backup for a trip plan for next year, containing just the trip details and afterwards will contain the tracks also.

Tutorial.Backup = Wiki Tutorial, the tutorial some of us on zumoforums are working on to help others learn more about the BC basics.

Just as with a business, there's no reason to limit yourself to one database. Have as many as are productive for your activities. It takes seconds to switch to another database.

These backups have another very useful purpose. They can be copied from my desktop to my laptop so each working slate is available when I'm on the road and can be updated back to the desktop when I return.

Hi Falagar,

Is there a description somewhere of what gets backed up with BaseCamp's backup function? Well, I'm actually more interested in a list of what does not get backed up.

.......

Hmmmm.... Now that I think about it a bit, I actually don't care what gets backed up. What I really care about is what does not get restored if I have to restore a backup.

So the real question is, what, if anything, do I lose if I have to use BaseCamp's Restore function to restore from a BaseCamp Backup?

Knowing I could easily restore things exactly to a known starting point would make me much more sanguine about experimenting with BaseCamp's features. It would mean I could just do a Backup immediately before starting to mess about, knowing that if I'm not happy with the results I can just restore. That would save having to always start with an empty library and import the stuff I want to work with before I can start doing anything.

Can I do that? E.g. will I be restoring absolutely everything I might have in the library to exactly the condition, with all the details, it had at the point the Backup was done?

...ken...

What Backup\Restore does is pretty easy to explain: it zips up everything in the %APPDATA%\Garmin\BaseCamp folder. Restore deletes everything in %APPDATA%\Garmin\BaseCamp and unzips the contents of the backup file there.

So you can rename the .Backup files to .zip and can inspect them to your liking.

So you do back up all your user data (routes, waypoints, tracks, geotagged photos, custom maps, birdseye etc.). It does not back up maps or settings.

Just as some added info: we keep old databases around, so for example on my current machine I have 3 database folders:

%APPDATA%\Garmin\BaseCamp\Database\3.0
%APPDATA%\Garmin\BaseCamp\Database\3.1
%APPDATA%\Garmin\BaseCamp\Database\3.2

BaseCamp 3.2.2 only uses the 3.2 folder.

We do keep old databases around just so you have something to fall back to in case something goes wrong with a new version (as happened with 3.2.1 unfortunately for some users).

However, this could get pretty bloated if you use Backup/Restore as a tool to switch databases. So you might think about deleting the older folders that are no longer needed if you worry about the size of the Backup.

Just as with a business, there's no reason to limit yourself to one database. Have as many as are productive for your activities. It takes seconds to switch to another database.

This is where I wish the development team in both OS camps had looked at Aperture instead of iTunes. Create as many databases as you want and easily switch between them. Import and export as little or as much as you want between them. A choice as to how to handle individual files that are imported. Organizational tools that are light years ahead of iTunes. Naming conventions that make sense... and on and on.

Tutorial.Backup = Wiki Tutorial, the tutorial some of us on zumoforums are working on to help others learn more about the BC basics.

I almost missed this. Great work, thanks for sharing!

We'll definitely keep an eye on that tutorial.