Waypoint Manager

BaseCamp only allows you access only one database at a time and it does not allow you open the application more than once. Everything in one database always will be listed under “My Collection”. The creation of folders and lists allow you to organize data in a way you find suitable. But it also allows you organize data multiple ways.

As an example, let’s say you want to separate European data from US data. I would create two folders, one labeled Europe, one labeled USA. In the each folder I would create and name a new list.

I would probably switch to the Global Map just to cut down on time to redraw the map. Zoom out until you see of America. Select “My Collection” in the upper right pane.

With the Selection tool (the one that looks like an arrow) I would place the cursor in the Northwest corner of an imaginary box that would cover all of America. Hold down the left mouse button and drag the mouse to the Southeast corner of a box that would cover all of USA. All data within this box will be selected.

You can then click and hold on one of the highlighted objects in the lower left pane and drag and drop it to the list in the USA folder; or right click on one of the highlighted objects in the lower left pane and select Send to and choose the list in the USA Folder. Selecting the USA folder will show you only the USA data. It will still appear under My Collection along with everything else. Additional folders and lists can be used to organize the data further. And yes, an object can appear in more than one list. I would then do the same procedure selecting all of Europe.

In your case, the your sheer volume of data may make it a good idea to create more databases. Type ctrl-o to open the options window. Select General. In the Database Options area click on the “+” . This will allow you to create a new database in the location of your choice.

To get data from one database to another, you may have to export from one database and import into another. But it wouldn’t hurt to try copying data, switching databases and pasting.

Whether or not I can help you with the duplication of Waypoints for you upcoming trip depends on what is in the download files (again gpx right?) and whether or not the locations with the same Lat/Lon in different files use the same name and/or whether or not the same name is used for different locations.

BaseCamp only allows you access only one database at a time and it does not allow you open the application more than once. Everything in one database always will be listed under “My Collection”.

Agreed, and it's not the way I would do it, but it is an option if folks are struggling with a large database and would prefer to split it into smaller ones.

Thanks for the how-to on creating a fresh database. I understand there's no immediate way to move data from one to the other - too bad. I may well try to transfer the Alpine stuff and let it go at that. The other European stuff is almost all just waypoints with only a couple of planned routes which aren't necessary to copy. The rest of the collection is too scrambled to pull apart easily. Call it a learning experience. ;)

One small question: How are the various databases stored? That is, will a backup store the existing database fully? If so, then changing environments (one database to another) becomes a combination of backups and restores. That is, backup database A. Create Database B. Backup database B. Restore database A. Backup A. Restore B. Backup B. Wash, rinse, repeat.

ADDED: Kurviger is very good about avoiding duplicate way/shaping points. Even across routes. It's one of the reasons why I like it.

Things are coming into focus. I've built a new collection relating to the Alps trips. The folder and list distinctions are lost in the process of bringing in the material from the old collection. That's actually not a bad thing. It's giving me a chance to weed out extraneous waypoints, made redundant by BC's route calculations.

Great thanks, everybody!

Not sure whether this will help as I find organising data into numerous folders and lists are sufficient for me, but you can create multiple databases also should you so wish, which would enable you to create multiple MyCollections ...

Sorry I didn't get to this.

The problem with using folders and lists on any large scale is waypoints get lost. A waypoint may exist in a folder (and list) not obviously related to a new project. When it comes time to name a seemingly new waypoint, and seeing the name "rejected" as a duplicate, the fun begins. That the name is in use somewhere is now obvious. But where is it in the several folders and lists? As an experiment, I deliberately tried to create a duplicate waypoint and then read the references tab. That's not possible until the waypoint has a unique name. Of course it's no longer able to show the original waypoint's references, which might gave a hint as to how to find it.

In fact, this situation is exactly what started this thread: dealing with finding "lost" waypoints.

Losing data really shouldn’t be a problem. If something is imported that has an existing name, the name will have a number appended to it – this is why it is a good idea to import into an empty list. If you try to create an object with a name that is already used, it won’t be allowed. But now you know the object name and type.

All data must appear in My Collection. To find the “missing data” select “My Collection”. Half way up the left side of the map pane is a little tab. Click on this tab and it will swap the map pane with the lower left pane – ctrl-tab does this too. Above the headers you will see icons for each object type. Click on the object type of the “missing data”. The list should be in alphabetical order, if not, click on “Name”. A second click on “Name” will reverse the order. Now simply scroll to name of the “missing data”, right click on it and send it to your list so you can determine if it is what you want.

Other headers can be used to sort data as well. For example, Routes can be sorted by Distance, Creation Date or Activity Profile.

I wouldn’t say you are being anal, but a task like finding missing data is not at all difficult or time consuming.

If anything, using numbers to differentiate Waypoints is bad housekeeping. But you must remember that you are the housekeeper. It is your responsibility to catch and address these issues. That is why I generally suggest that importing/downloading directly into My Collection is probably not a wise idea. It is easy to add/remove lists and isolate/cross reference data using folders and lists.

Regardless of past experience, we all must adapt to new experiences. In BaseCamp, objects of a given type must have a unique name. BaseCamp is also general program where its users are involved in a variety of unique tasks – it is not design for just you or me.

BaseCamp prevents users from creating duplicate names within the program. It will accept and rename duplicated names when importing data.

The alternative is to open a pop-up window informing that the name has already been used and ask if you want to: 1. Do Not Import; 2. Replace Existing Object; 3. Rename. MapSource (BaseCamp’s predecessor) uses this approach, but you only have options 1 and 2.

Now, instead of motorcycling, suppose you were in forestry and completed a survey of some kind creating 50 Waypoints using the device’s default naming. Chances are those names would already be in BaseCamp. Would you really want to deal with 50 pop up windows just to get the data into BaseCamp?

So, if you were cataloging bouys only by name, would Bouy-21 be a good name? How many Bouy-21s are there in the world? How quickly could you find the right one?

What would you propose be done instead?

I've finally woken up to the concept of BC really being a huge database tool. Initially I looked at each waypoint as a single record. That is, if I started "sample" in list A and copied it to list B, I was thinking in terms of a record for "sample in A" and "sample in B". Which, viewed that way, struck me as space consuming. Continuing on, "sample1", etc. then become addition records and all of that just didn't light my lights.

If I'd woken up to BC being one big ISAM (or what style BC uses) database, "sample" is merely a pointer to a single record, and appearances in A and B are nothing more than two pointers to the same record, life would have been much easier. However, I do wonder if missing the "BC as database" concept influences users. Being able to create multiple collections, for example, avoids the nightmarish clutter that built up here. 'Course, that all depends on how much the using population uses BC. Occasional users probably don't care. :)

All of that said, I still find it at least annoying that there's no way to generate a report of what pointers and records exist in the database. At the moment, with the Alps planning, I have two main folders: last year's trip "ACT 1603" and this year's trip. Last year's trip is in one list, including the five routes actually traveled. The planning folder started with everything, in the old database's folder for planning, in one long list. For some reason, some of the routes now have only a start and finish. OK, it is what it is. I start to flesh out one of these routes "Andermatt-Prutz", that happens to coincide with part of "ACT 1603". No problem. Except as I go to fill out "Andermatt-Prutz" and create "Nauders", BC says "existing name". Fortunately, if "Nauders" isn't in "999 Everything", it can only be in "ACT 1603". But let's go forward a few years, and "Alps Trips" starts to fill up with previous years' routes and waypoints, and routes cross or parallel more often, managing the waypoints becomes more challenging. And that list report becomes more important. Or, if I could get onto Garmin, at least allow the waypoint selector, appearing when hitting "+" in the route window (i.e., double click a route), to list every waypoint in the collection. Since the selector accepts type-ins to point at a given waypoint (type "nau" and there's "nauders" and anything else beginning "nau"), it's relatively easy to include any waypoint in a route. No dount this feature will be in the next update. And beer will always be free, too. :D

For the forester who doesn't care about "name+number", hey, knock yourself out. I guess if I were plotting the Appalachian Trail, for example, I wouldn't sweat every little step along the way, and only mark the major landmarks (e.g., huts, trail intersections, etc.).

Buoy numbers... ooooh, I can tell you've never been anywhere with significant amounts of buoyage. Intersecting channels, branching channels, private channels and more - they can create some opportunities to excel. Oh my yes they can. One of the rules for buoys is the numbers go up as the channel heads to the head of, for example, a river. And it's always "red right returning". Red buoys on the right, green buoys on the left going up the river. But wait, there's a point where river A meets river B coming the other way (forks and some other features do this) and suddenly the numbers reset and it's red on the left and green as you now go down river for the new river. There's room for a lot of fun here. Opportunities to excel? We got 'em. :)

I've finally woken up to the concept of BC really being a huge database tool. Initially I looked at each waypoint as a single record. That is, if I started "sample" in list A and copied it to list B, I was thinking in terms of a record for "sample in A" and "sample in B". Which, viewed that way, struck me as space consuming. Continuing on, "sample1", etc. then become addition records and all of that just didn't light my lights.

This is probably the most common misconception for most new users and those migrating from the MapSource. My opinion is that Garmin has really messed documenting this program and explaining the concepts behind it.

If I'd woken up to BC being one big ISAM (or what style BC uses) database, "sample" is merely a pointer to a single record, and appearances in A and B are nothing more than two pointers to the same record, life would have been much easier. However, I do wonder if missing the "BC as database" concept influences users. Being able to create multiple collections, for example, avoids the nightmarish clutter that built up here. 'Course, that all depends on how much the using population uses BC. Occasional users probably don't care. :)

Yes, this the key concept to grasp. But I would argue that the nightmarish clutter arose from not from making multiple collections, but from poor "housekeeping". For some things multiple collections make sense. In your case separate databases for Europe and North America makes sense. But one shouldn't go overboard making collections. This has the potential to create other problems. Our devices also require unique names for objects of a given type. Now suppose you try to upload data from different Collections to the device. How is it suppose to know if "sample" in collection A is the same as "sample" in collection B, what should it do if it is not?

All of that said, I still find it at least annoying that there's no way to generate a report of what pointers and records exist in the database. At the moment, with the Alps planning, I have two main folders: last year's trip "ACT 1603" and this year's trip. Last year's trip is in one list, including the five routes actually traveled. The planning folder started with everything, in the old database's folder for planning, in one long list. For some reason, some of the routes now have only a start and finish. OK, it is what it is. I start to flesh out one of these routes "Andermatt-Prutz", that happens to coincide with part of "ACT 1603". No problem. Except as I go to fill out "Andermatt-Prutz" and create "Nauders", BC says "existing name". Fortunately, if "Nauders" isn't in "999 Everything", it can only be in "ACT 1603". But let's go forward a few years, and "Alps Trips" starts to fill up with previous years' routes and waypoints, and routes cross or parallel more often, managing the waypoints becomes more challenging. And that list report becomes more important. Or, if I could get onto Garmin, at least allow the waypoint selector, appearing when hitting "+" in the route window (i.e., double click a route), to list every waypoint in the collection. Since the selector accepts type-ins to point at a given waypoint (type "nau" and there's "nauders" and anything else beginning "nau"), it's relatively easy to include any waypoint in a route. No dount this feature will be in the next update. And beer will always be free, too. :D

Well this is partly a housekeeping issue. Searching for user data is limited to the active folder/list. It would be nice if one had the option to open a Route Properties window and not have it close when switching lists so one could look for a Waypoint to add in "My Collection". Or perhaps a means to toggle between My Collection or current folder/list. But knowing this limitation allows us to kludge things a bit. For example, you could put both your main folders in to an "Alps Rides" folder. Selecting this folder would allow you to search and access data in both main folders and all there sub-folders. Anticipating future problems, you may decide to maintain a Waypoint list at the highest level in "Alps Rides" and send it to sub folders as needed.

For the forester who doesn't care about "name+number", hey, knock yourself out. I guess if I were plotting the Appalachian Trail, for example, I wouldn't sweat every little step along the way, and only mark the major landmarks (e.g., huts, trail intersections, etc.).

LOL Well, that wasn't really my point. The point was the BaseCamp is a general application and not designed for a specific task and that the issue of bringing in data from different sources how to deal with it is a real and not so simple problem. I find Garmin's solution to be reasonable - don't allow creation within BaseCamp and automatically rename by appending a number when downloading/importing. I'm sure a better solution would be appreciated if you have one.
But, again knowing how BaseCamp deals with this allows us to minimize issues if we think ahead.

Buoy numbers... ooooh, I can tell you've never been anywhere with significant amounts of buoyage. Intersecting channels, branching channels, private channels and more - they can create some opportunities to excel. Oh my yes they can. One of the rules for buoys is the numbers go up as the channel heads to the head of, for example, a river. And it's always "red right returning". Red buoys on the right, green buoys on the left going up the river. But wait, there's a point where river A meets river B coming the other way (forks and some other features do this) and suddenly the numbers reset and it's red on the left and green as you now go down river for the new river. There's room for a lot of fun here. Opportunities to excel? We got 'em. :)

Again, LOL. I'm a land lover thru and thru. But, surely you see that some "housekeeping" or "planning" was done prior to numbering and placing the buoys. Suppose those in charge had randomly numbered and randomly placed those bouys and only now are trying to make sense out it? You've foreseen future issues with your Alps adventures. You have a better understanding of the concepts in BaseCamp and its limitations. But are you going to make use of it? Housekeeping sucks, but for it is an important job.