Copying data to/from BaseCamp

I agree that this would be a nice feature.

It's on our list of possible future additions.

Thank you for your feedback.

Falagar, I thought you said in a different thread that Basecamp checks the actual content of a waypoint when importing from a file or transfering from a device and only renames (appending an incrementing digit) if the content was different, e.g. the incoming waypoint is actually unique and should not destroy the existing one with the same name.

Or am I misremembering? I recall that you tested file import and said it only makes a unique waypoint if the content is different. I can't recall if you tested the same thing with transfering from a unit and what the results were. Doesn't it work the same? If not, shouldn't it? (Sorry, I'm getting old and my memory shows it. :eek: )

...ken...

The feature asked for here (at least how I understood it) was to offer a way for the user to decide what to do if the user data does not match.

We already do the checking if some user data with identical name is the same (then we ignore it). If it is not the same, we copy and rename it.

The feature that would be nice to have would be something similar to what Windows file explorer does when you copy a file and it finds files with the same name in the destination. (Something like: overwrite, rename or ignore? do you want to keep that selection for the next X files?).

Thanks for the clarification, Falagar. Yes, a choice of how to handle identically named waypoints would be a great addition. And I agree with your example of something similar to the Windows 7 Explorer method.

But it has to be complete, e.g. it needs to give enough information about both copies to allow you to make a sensible choice. Win Explorer gives you things like the file date, time and size. The Basecamp selector would need to give us something similar ... enough about the properties to let us decide how to proceed.

That might include the coordinates and other significant info, like category/symbol, address, comment. Enough info to make a good decision.

Simply pointing out that there are waypoints with the same name in the incoming file import or device transfer and the collection is not helpful by itself.

...ken...

This is the reason I have not upgraded my 62st's firmware to v3.4. I'm told to export my data to BaseCamp then delete my gpx folder then perform the upgrade then import back from BaseCamp. But I have multiple waypoints with identical names and I like it that way ('W' for walleye hot spots, for example) I do not wish to have W54, W92, W203, etc. Nor do I wish to spend the better part of my evenings changing them all back. I can see that they are all at different locations on the map; why do they need to be unique waypoint names?

Multiple waypoints with identical names must be a new feature of the 62. Neither my 60CSx nor my Zumo will allow that and I guess that's why BC and MS won't allow them, either.

However, I have an idea for the developers: can we have identical waypoint names in different lists? If you tried to load these into devices that don't support them then BC would have to give a warning, but at least we could import data from GPS units or files into lists and keep them separate and unique that way.

Just an idea.

Peter.

DAKNUDSEN...I too found that message bothersome saying to move all that stuff back and forth. Trying to think back but, I believe I copied the gpx folder on my 62s using Windows explorer (outside of Basecamp), did the update and moved the folder back.

However, I have an idea for the developers: can we have identical waypoint names in different lists? If you tried to load these into devices that don't support them then BC would have to give a warning, but at least we could import data from GPS units or files into lists and keep them separate and unique that way.

What you are suggesting can't be done. ..... Well, it can but it won't work the way you expect.

It has to be emphasized that the items you have in your collection are the ONLY items you have. There are no items in lists. None

I know that sounds kind of silly but it's true. The item -- waypoint, route, track, whatever -- only exists in the collection. Nowhere else. (See this discussion.)

When you create a list, all that gets put in the list is a copy of the NAME of the item, not the item itself. The name in the list is just a "pointer" back to the real, and only, copy of the item in the collection.

If you drag something, say a waypoint, into four different lists, there are NOT five different copies of that waypoint in your library (e.g. one in the collection and one in each of the four lists). There is still only one, the one in the collection. The others are just a name in each list, each with a pointer to the real waypoint in the collection.

If you create something "new", say a waypoint, in a list, the waypoint you create actually gets created in the collection. The list only gets the name and a pointer to the waypoint in the collection.

This has all sorts of issues, many of which are discussed in other threads. Bottom line here is that it prevents what you suggest from ever being implemented.

...ken...

I understand all that, but that doesn't mean that the database design can't be changed, so that lists are actual different data sets. Not that I think that it's likely to happen.

All these issues mean that I have to stick with MS, because it just works.

The feature asked for here (at least how I understood it) was to offer a way for the user to decide what to do if the user data does not match...The feature that would be nice to have would be something similar to what Windows file explorer does when you copy a file and it finds files with the same name in the destination. (Something like: overwrite, rename or ignore? do you want to keep that selection for the next X files?).

Ah, we are in the modern data management era so how about adding a merge
option with individually selectable fields per record to the now somewhat dreary overwrite, rename or ignore Windows type prompt :)