Cteating waypoint file from several trips

I wonder if we are doing it the same way? You mention that you "pasted the data into Excel" but the way I did it there is no pasting to do. With the list selected, I went to File/Export/Export "listname" then selected csv in the file format, then Save. A file "listname.csv" is created, which can then be opened in Excel, and has multiple categories of data, one of which is headed "wpt", and all waypoints are listed in this section. I think if you select data and copy/paste it into Excel, it is less predictable what you'll get.

I am running BC 4.1.2, not the latest, but I can't imagine they've changed the export format significantly between versions...

Hi,
I am doing the saying to csv, and then delimitation the flles using csv format, but the column wpt is NOT the waypoint description that the spread sheet generates. I must be doing something wrong. see the attached file.

Ah. You just didn't look down far enough. The category "wpt" starts in row 437. From there to row 634 is your list of 196 waypoints with all their associated data.

Small niggle: In row 437 it's still "Wpt ID"; it's just split into two cells (A437, A438). But that's definitely the most useful section for DEERHEAD's purpose.

...ken...

Even smaller niggle -- the heading of that section of the file is "wpt" in 437, and "ID" is the first column heading within that section. That's consistent with the others sections of the file, i.e. a heading title, then column headings in the next row. Wow, really splitting hairs here. :p

Ah! Y'all are correct. I thought anything below line 425 was useless!!

Although if you look at a track or route's properties, you will see that both are made up of waypoints.

Certainly not... routes are made up af via points and tracks are made up of track points; they are not the same as waypoints.
Waypoints are isolated points that don't have a connection with routes or tracks (other than possibly sharing the location with one of the via points in a route).
Routeconverter may give the option to show via points or track points as individual "way"points on a map, but technically this isn't correct.

And KMZ files are essentially compressed KML files. ...Also, I think that's what the "Z" (in KMZ) actually stands for "Zipped!"

That is correct. You can simply extract them with Winzip or another unzip program after you change the file extension from KMZ to ZIP (that isn't necessary when you use a command line unzip program, but GUI programs only accept certain file extensions)

The others (KML & KMZ) cannot, as they are "cryptic" to the naked eye.

KMZ needs to be decompressed first, but KML is just as "readable" as GPX. Both KML and GPX are XML based formats that can be viewed with a text editor.

Certainly not... routes are made up af via points and tracks are made up of track points; they are not the same as waypoints.
Waypoints are isolated points that don't have a connection with routes or tracks (other than possibly sharing the location with one of the via points in a route).
Routeconverter may give the option to show via points or track points as individual "way"points on a map, but technically this isn't correct.

Semantics really.....

I was "over-simplifying" things a bit too much. The point I was making is routes & tracks contain a series of multiple location "points" aka coordinates which can readily be parsed from a .gpx files and "interpreted" in different ways.
You can display each of these points individually, or show them in a "highway conforming route" or in a "direct line of sight"/aka direct route. And the noticeable difference between routes and tracks (looking at the .GPX file with "the naked eye") is: Tracks typically contain a "much higher sample rate" than routes. (There is a lot of data/detail with very small distances between each point enabling you to follow a precise "track" because you're not relying on a highway to "connect the via points.") ~ And of course, even in Basecamp (while editing route properties), there is an option to convert individual route points from "via points" to regular "track points."

Breaking it all down into the "building blocks": Waypoints are individual points of data. Tracks are an "assembly" of waypoints. Routes are also an "assembly" of "mostly special waypoints" (as few as two aka "via points") with roads and logic added in to get you from one point to the other point....

Anyways, with the software that I suggested (to easily see duplicates in multiple routes): There is a toggle to "interpret" (and display) any given .GPX file as either a bunch of waypoints, a track (ignoring roads to "connect the dots" in straight lines), or a "classic route" (using the roads to navigate from point to point.) Offering these options for any given .GPX file may not be "technically correct", but in some ways it's almost "elegant" IMO. And when toggling between views, RouteConverter visually displays (on-screen) the different ideology between the three types of data. (waypoints, tracks, and routes)

One other thing: The way in which many Garmin GPSr units "save data" is confusing IMO. (I'm referring to the logic, aka the way the GPSr combines data in some instances, and not in others.) For instance, (referring to a Montana 650):
Favorite tracks (and all waypoints) are contained in numerous (ever growing) number of .gpx files on the unit. Multiple tracks can be stored in the same .GPX file, but not always. This appears to be a function of date. And when a track is "archived" it is first located/parsed/removed from it's .GPX file and the data is "moved" into a separate file containing only that one track using the track name as the file name. (Data is re-written to the /archive sub directory: garmin/gpx/archive) Although waypoints cannot be archived, the same confusing storage schema exists: Multiple waypoints can be stored in a single .GPX file. Yet multiple .GPX files exist on the unit which contain varying quantities of individual "waypoints." (Again, this appears to be date related.) Note: A singl .GPX "container" (file) never stores both data meant for display as a "waypoint" and data meant for display as a "track." On the unit, fortunately i's easy to tell track.gpx files from waypoint.gpx files. The words "track" and "waypoint" are included/used in the names of the files respectively. ~ Hope that didn't confuse anyone.....

PS JAVAWA: I know that you're the "pro." I was just trying to make sense of what kind of info is contained in the different file types. (in layman terms) ~ People tend to get confused/lost in the "terminology!" (even when the basic concepts are quite simple) :)

Using the wrong terminology only adds to the confusion...

Using the wrong terminology only adds to the confusion...

Maybe, but in this instance I'm not convinced. (In general, that's how I learn. And once you properly understand the fundamental "building blocks", the rest usually comes much easier. Understanding these "basics" is critical IMO.) ~ Besides, unless you have a good starting point, all the terminology in the world doesn't help one bit. It hinders IMO. Besides, some of the terminology (IMO) has been poorly chosen and is also used ambiguously in these forums which is confusing in itself.
This reminds me of trying to explain how either a web server or a computer works. (and how they become unresponsive from too much load) ~ And the notion of how a single CPU/computer appears to do many things at once.... The basics are simple, but people have to understand them first, or the rest is meaningless.

At the lowest level, the notion of a web server serving many users at once , or a PC doing many things at once (single processor) is absurd (and a mystery to most.) ~ The truth is, it's a ridiculous statement that most people "just believe" yet don't begin to understand. ~ It only seems that way when everything is "going right." In reality, processing zero's and ones a processor can only do one thing at once. It's all about timing & sharing..... Explaining this with the "spokes of a wheel" terminology/analogy always made people understand: The spoke of a wheel going round and round (aka a web server or a computer) can only spin so fast. There are only "so many spokes (user slots to get things done)" ~ and when each one is being used/full, you're at full capacity. Beyond that there are going to be delays... And if one of those spokes (slots) "gets stuck" (waiting for something else), the wheel can come grinding to a "halt/freeze.".

Here I've obviously used totally wrong terminology, but it is what it is and it makes total sense. ~ More sense then much of the technical jargon actually IMO.) (Much of which I don't even care about, because I "understand what's going on.") Beyond that, everything else is "just semantics."

To be honest: It's all the initial confusion around the usage of different "point" terminology which originally got me "off-track." (Garmin has not helped here as they created confusion from changed the way in which they used this terminology in their own documentation fairly recently as I recall.) I believe there is a post here somewhere from a Garmin employee "making reference/apologizing" for this ambiguity/confusion. ~ The best way for me to understand it initially was to avoid the ambiguous terminology completely and "learn from scratch" by intuitive exploration. (Searching for answers via this terminology led to more questions than answers.) ~ Thus I do see your point!

"I'd better get back to work or I'll have no choice but to fire myself!"