problem uploading gpx routes to basecamp

"Sgurr Thuilm and Sgurr nan Coireachan"

That's not easy enough to find.

Next time, when you have a problem, paste the URL (webpage). Make it easy for other people to know what you tried specifically.

Two weeks ago I picked a random one, and the gpx file was certainly invalid. Today I can't find an invalid one anymore, so I have been "lucky" two weeks ago, or they have fixed it in the mean time.

If your post on 6/10 was "two weeks ago", knowing what you tried is useful.

The proper order is elevation, time stamp. (it doesn't make sense though to add either of them to via points, since this information won't be used anyway; at least not by MapSource, BaseCamp or Garmin devices)

I could be wrong but I think the XML specification requires that the order of data on the same level shouldn't matter.

Elevation, clearly, is optional/secondary information.

The following is an example waypoint from a file from the http://www.walkhighlands.co.uk .

<rtept lat="55.6784051197122" lon="-5.7337275413676">
<ele>-0.227037100369483</ele>
<name>WPT 2</name>
</rtept>

I've found that the layout line (example below) in some files (eg, from mapmyride) is a problem. Replacing it with what Basecamp writes lets the Basecamp load the file.

<gpx xmlns="www.topografix.com/.../1" version="1.1" creator="Walkhighlands">

If your post on 6/10 was "two weeks ago", knowing what you tried is useful.

I downloaded a GPX file (can't remember which one), tried to open in BaseCamp (didn't work), opened in a text editor, noticed the problem.

the XML specification requires that the order of data on the same level shouldn't matter.

The GPX specification mandates a strict order.

I've found that the layout line (example below) in some files (eg, from mapmyride) is a problem. Replacing it with what Basecamp writes lets the Basecamp load the file.
<gpx xmlns="www.topografix.com/.../1" version="1.1" creator="Walkhighlands">

That line contains some mandatory elements and information of the schemas that are used in the document. Replacing it with the one that BaseCamp produces might help in a few cases.
The majority of problems with 3rd party created gpx files are:

• incorrect order of elements
  
• adding custom elements that aren't part of the gpx spec
  
• adding custom extensions without schema definition
  
• values in a wrong format
  

The gpx standard is open and well documented. This kind of problems is caused by the fact that developers don't care to read the documentation, and just mess around with it.

I downloaded a GPX file (can't remember which one), tried to open in BaseCamp (didn't work), opened in a text editor, noticed the problem.

The problem could have been with a particular file. It seems like many (all?) of the files work now. I don't know whether they generate the files on the fly or just store the gpx file.

That line contains some mandatory elements and information of the schemas that are used in the document. Replacing it with the one that BaseCamp produces might help in a few cases.

I know. It's a gamble as to whether replacing it will work but it's easy to try. Gpsbabel might be useful for putting elements in the correct order (an order that works).

The GPX specification mandates a strict order.

Apparently, for some things and not for others.

The OP, at least, should have provided a link. That would have made it easier to figure out what was going on.

It would be useful to report problems back to the site. It seems somebody did that.

For this,:
http://www.topografix.com/gpx/1/1/#type_wptType

Not for these:
http://www.topografix.com/gpx/1/1/#type_rteType
http://www.topografix.com/gpx/1/1/#type_trkType

This kind of problems is caused by the fact that developers don't care to read the documentation, and just mess around with it.

No doubt.

For this,:
http://www.topografix.com/gpx/1/1/#type_trkType

Not for these:
http://www.topografix.com/gpx/1/1/#type_rteType
http://www.topografix.com/gpx/1/1/#type_trkType

The first and and last of these three links point to the same item...
Anyway, click on the button before "Schema Component Representation" and you'll see an item <xsd:sequence>. That means that the data has to be in that specific order.
Neither of them do apply to the via point data; that's http://www.topografix.com/gpx/1/1/#type_wptType (there you will find <xsd:sequence> too)

you'll see an item <xsd:sequence>. That means that the data has to be in that specific order.

Thanks. Interesting.

I suppose the order is being required to make it easier for less capable devices to process the files. (The Edge 800, for example, can't do much with the schema.)

The Edge didn't exist when the GPX standard was defined...
GPX isn't a Garmin invention, and it wasn't designed to be used by devices in the first place.

The Edge didn't exist when the GPX standard was defined...

That's obvious.

GPX isn't a Garmin invention, and it wasn't designed to be used by devices in the first place.

There isn't any other apparent point to having it be so picky about field positions.

XML schema (XSD) offers very weak support for unordered content. Also, parsing sequential data is much easier than unordered data.

Also, parsing sequential data is much easier than unordered data.

If the field names are being considered or if missing fields are being handled, this isn't that true. It's just (a bit) faster.

If the program is looking at the field names anyway, it's easy enough to write the program to use the field names as "indexes". The problem with doing that is that it's "slower".

Anyway, given that the gpx documentation indicates the order is important, things should write the files accordingly.