Sharing Basecamp Data

<snip> But why don't you just import and export files with BaseCamp? No one is forcing you to use the database. <snip>

In the short time I've been here I've appreciated the time you spend on these forums and the trouble you have taken to answer the queries.

That said, I think you are labouring under the misapprehension that export and import in Basecamp are just the same as open and save in Mapsource:

Double click a file associated with Mapsource and the file opens. Associate the file type with Basecamp and double click it - it doesn't open the file.

Click save in Mapsource and it will overwrite the previous file. The only way to do that in Basecamp is to export, select the file then answer the "Do you want to overwrite" question.

Attempt to exit Mapsource with unsaved changes and it will prompt you to see if you want to save them. Exit Basecamp and it just saves the data in its database, the original file remains as it was before you started.

Decide you want to discard the changes in Mapsource and you just exit and say no to the "Do you want to save?" question. Decide you want to discard changes in Basecamp...well you'd better hope you did an export or a copy before you started.

We've already done this one but sharing files in Mapsource is a doddle. It really isn't in Basecamp.


I could go and (and I probably have!) but I hope there's enough here to convince you that Basecamp's import/export are nothing like Mapsource's open/save; there is no similarity whatsoever.

Yes, it is possible to overcome Basecamp's shortcomings in this area but it's convoluted. This isn't a reaction to something 'diffierent', it's a reaction to a huge step backwards in functionality and usability for many, many users.

And you're right, we can continue to use Mapsource. Unless you come with a killer feature in Basecamp I'm sure that's what will happen but, as I said previously, at some point in the future an unsupported Mapsource will no longer be compatible with the maps and then we have no choice at all if we wish to continue to use Garmin products.

Kevin

You are of course correct that export/import isn't exactly the same as open/save.

However, it accomplishes pretty much the same thing, even though it is of course less comfortable if all you want to do is edit one gpx file.

But, BaseCamp is not a document-based application, it's not supposed to just edit gpx files. The "normal" use-case is that you would run the app, accumulate and manage all your data and close the app without ever encountering any files whatsoever. In a way, you are purposefully making your life harder by choosing not to take advantage of the database. You will not get the most out of BaseCamp if you forgo its strengths. BaseCamp will never be MapSource 7.0. All I can offer is work-arounds.

But like I said before, we will try very hard to listen (and make the appropriate changes) to valid complaints about MapSource functionality that didn't make it into BaseCamp or is more cumbersome that it should be.

The export/import vs. open/save unfortunately is of those things that are very hard to fix without totally changing BaseCamp's data approach. (Which like Ken correctly observed, is a very unlikely thing to happen).

I thought we would import gpx files when associating gpx files with BaseCamp. I just checked and we don't. That's definitely something we could do. Somewhat related, we just added drag-and-drop support in 3.2.

<snip> The "normal" use-case is that you would run the app, accumulate and manage all your data and close the app without ever encountering any files whatsoever. In a way, you are purposefully making your life harder by choosing not to take advantage of the database. You will not get the most out of BaseCamp if you forgo its strengths. <snip>

I think we've reached the unresolvable crux of the issue. Your 'normal' use case is not how I have ever used Mapsource (or any other Windows application for that matter). Several Windows programmes I use have a database concept - Media Monkey, Calibre, iTunes, Squeezebox Server - but all of them recognise the concept of separate files. None of them force me to put my files in a specific place and I am free to name them as I want. Consequently the files all sit on the network where they can be shared and backed up.

It's not a matter of choice, Garmin's current model for Basecamp doesn't fit any sort of collaborative operation without significant workarounds. What you see as a strength I see as a weakness.

Thanks for your help but, as I said, I think this is unresolvable in the current climate so I'll leave you in peace now.

Kevin

I think exporting/importing would be the way to go.

In MapSource you had to open/save. In BaseCamp have you to import/export.

You could probably pull some shenanigans to make both your BaseCamp copies use the same database (make both %APPDATA%\BaseCamp folders point to a shared location using symbolic links), but I am not sure I can recommend that. Then you definitely would not want to use BaseCamp at the same time.

What would be really nice is to provide a mechanism within BaseCamp to move the database from ~/library/Application Support/... to another shared location such as DropBox. It would make it easy then to synchronise one's data between two machines (provided you didn't use them at the same time of course).

...If all the lemmings want to just go along ...

For a noobie on this forum you certainly are pushing the envelope by casting aspersions on those members who are actively attempting to influence the development of Basecamp in positive ways. Open your eyes and look around this forum before you rant if you want any credence. There is an L word used for those who not only refuse to accept change but make an effort to interfere: luddite.

Basecamp works for me and I have hundreds of gpx files with thousands of waypoints hundreds of which are duplicates simply because it is so difficult in Mapsource to go back through all the files and find the duplicates. Same thing with tracks and routes. Basecamp is enabling me to sort those out. Basecamp manages that stuff so I don't have to. Computers are good at that, people aren't. I want my computer to do the stuff that its good at and let me do the stuff I'm good at. For me, Basecamp is a big step in the right direction.

What would be really nice is to provide a mechanism within BaseCamp to move the database from ~/library/Application Support/... to another shared location such as DropBox. It would make it easy then to synchronise one's data between two machines (provided you didn't use them at the same time of course).

That is a very good point actually. We'll see if we can make that happen for a future feature release (not necessarily the next one, the plate for 3.3 is pretty full already).

BTW, I believe your post referenced the Mac location of BaseCamp's database, but the point is equally valid on both Mac and Pc.

Thanks for your feedback.

compromise to flexibility

Like AUGUSTFALCON, I do find the integrated "library" approach in BC easier to manage than a bunch of files for MS... but I agree with KWELLER that BC needs more flexibility. For example, I would find it useful to keep different "profiles" to allow a completely different db for different purposes.

IDEA: How about if a db element in BC could be made to "reference" an alternate database (Coders would call it a "$INCLUDE")?.

So, for example: a user might have one DB for his handheld, and another DB for his car device (I rarely drive to a deer-stand, and rarely walk across 4 state lines) . Or he might have one for his work stuff (land management) and another for his personal stuff (friends' homes, hangouts, etc). Or maybe a DB dedicated only to saving all his tracks for historical/archival purposes, to only be viewed as needed. Or any number of collections at his choosing. Each DB could be anywhere on the file system: on a shared drive, his personal local directory, a "public" folder on the local drive, etc etc.

With this, a sophisticated user like KWELLER might set up his main db (in the default %APPDATA location) to contain NOTHING but $INCLUDE references... so when he lauches BC with no argument, all of his data is there. But, he could also double click any DB file and BC would open to work only on that one.

The interface would need a little work to properly represent the references, and segregate them correctly.... probably more of a tree structure with the ability to check/uncheck entire branches to show/hide the groupings. One could copy a waypoint, list, or other element between DBs (like say "home" and "work") but would not have to. And you'd need at least one "My Collection (all)" to display every element from every DB, and a "MyCollection ($DB)" for each DB as well, with "lists" that could be created distinctly within any of them. Garmin could even make some use of the filesystem/OS's file-locking to prevent multiple users from clobbering a shared DB thru simultaneous modification.

Google Earth has sort of implemented this, but fell short. You can use a "network link", or whatever they call it to display an "external" kml file, but the result is that said kml is "read-only".

I think being able to switch databases is a good idea.

Nesting databases sounds fun (for a nerd like me), but that might be a little more complicated than we'd like to get. I am not sure the complication of the UI, the coding headaches (and inevitable bugs) would be worth it.

I see the usefulness of it, but I am skeptical that enough users would make use of it to make it worth the development effort and the complication of the user interface.

Switching DBs sounds like a much more doable solution with much less risk.

I think being able to switch databases is a good idea. <snip> Switching DBs sounds like a much more doable solution with much less risk.

Assuming I can place those databases on a network share I think that would work for me, especially if there was a locking flag to ensure they could be read-by-many but only-updated-by-one. In fact I quite like that idea - it's a good suggestion.

Now, about that 'Optimise route' feature...;)

Kevin

As a professional software developer I can understand the position the basecamp dev team is in - its hard to please everyone. As a long time GPS user I can understand the need for multiple database concepts - especially when it comes to large file organization and or collaboration.

I am still new to basecamp, as I am reluctant to leave MapSource. I have hundreds of gdb files built over years and years of mapping work. However the new features of basecamp are alluring. But the aspect of a single database is too limiting. So I wrote some powershell scripts that would allow me to have multiple databases. I dont like this hacking technique and would much rather have it in the Basecamp software.

So I fully support having a feature in basecamp that can support multiple databases. If this took the form of a menu item: File-> Open Database -> then a common dialog box for directory open - it would make me *very* happy!