I am going to copy some information here for future reference that I posted elsewhere:
There are several different legitimate versions of content within a *.gpx file. It is even possible to have more than one version of this content within a single *.gpx file. Two are supported by TomTom. The third is not, but so closely resembles the use of an *.itn file that one can be readily substituted for the other. The tool (or device) you use to create a *.gpx file will determine which type of content the *.gpx file contains. Some tools allow you to select which content is used, and some use their own default. Most devices generate the second flavor () as described below.
First type of content of a *.gpx file is known as <rte>/<rtept>. This file format IS supported by TomTom. Critical points within the route are identified with entries.
A routing engine is expected to use the points to create the route in the sequence in which these points occur within the *.gpx file. More than one can be defined within the file, each with a unique name, each with its own series of entries to create the route. How the routing engine chooses to achieve each within a route is left to the routing engine's logic, and of course, traffic may be taken into account. Typically, entries are defined for each 'turn' in a route, so as more are added, the routing engine has less leeway in its ability to make decisions about the route.
Second type of content of a *.gpx file is known as <trk>/<trkpt>. This file format IS supported by TomTom. This is the true 'overkill' method of defining a route, and assures that any routing engine will take all users of the file along the exact same path -- though some may include logic to avoid blocked points along the <track>, while others may just leave the user stuck at any known blockage.
As with <rte>, more than one can be defined within a file, each with a unique name. Further, each contains one or more segments <trk>, within which will be the segment's individual points identified as <trkpt>.
This is a traditional 'breadcrumb' track where points are typically defined either in terms of distance (a point every x miles or x km) or by time (every x seconds). These files tend to be huge, especially when the resolution of the points in time or distance is small. The consequence of using a file of this flavor is that the routing engine is bound to each point, and hence, the logic of the routing engine rarely, if ever, comes into play. The route is forced to follow each point in sequence as originally built by whatever tool was employed.
More often than not, this format is used to RECORD a journey rather than to build one, though these are then also often used to reverse an existing journey after reaching its end. Picture taking a hike, and then turning around and using the recording of the outbound journey to backtrack to the start. The point recording interval is typically set by the user (not so in the case of TT when it builds tracks on Nav4 units -- one second per point is locked into the code).
Third type of content of a *.gpx file is known as <wpt>. This file format is NOT supported by TomTom. Within this format, individual locations that are to be visited are identified in the xml as entries.
This style of *.gpx is very similar to the manner in which *.itn files are used, and may be why TT chose not to bother to support it, though there are quite a number of tools that build *.gpx files using this method, which must then be converted by some other tool to one of the two formats that TT does accept.
Hybrids
It is possible to generate and find 'in the wild' *.gpx files that contain combinations of the above. Sometimes, we see tools creating these hybrid files with a combination of <trk> and <rte> entries. For example, if exporting a *.gpx file from TYRE that contains a number of individually identified waypoints that are to be visited, you may well find that the original content has been rendered into a combination of to identify each point, but also an entire run of that could be used to force the exact routing to the entries. It's all a bit odd. It is up to the routing engine to decide what to do when presented with this kind of schizophrenic mix. Ideally, a routing engine is allowed its own leeway in generating a route between <rtept>, but at the same time, it is being presented with <trkpt> which allow no leeway at all. It would be interesting to understand the author's intentions in this regard. Perhaps the objective was to produce a file that could be parsed by engines that did not understand one or the other?