Add option to turn Garmin RoutePointExtension into regular points

[fbonzon]

The way Garmin BaseCamp software encodes a GPX route is with regular <rtept> elements describing the navigation hints at intersections (referred as primary route points below), and, for each of these primary route points (except the final one), many <gpxx:rpt> sub-elements in a <gpxx:RoutePointExtension>, describing a more precise path along roads.

Simplified example with relevant parts:

<rtept lat="46.544628096744418" lon="6.658079791814089">
  <extensions>
    <gpxx:RoutePointExtension>
      <gpxx:rpt lat="46.544483928009868" lon="6.658018603920937"/>
      <gpxx:rpt lat="46.544415950775146" lon="6.658358573913574"/>
      <gpxx:rpt lat="46.544415950775146" lon="6.658358573913574"/>
    </gpxx:RoutePointExtension>
  </extensions>
</rtept>

Full file example: Lavaux 001 1 à Lavaux 001 48.GPX.zip

It would be nice to add support to read these <gpxx:rpt> points. A new option to make these sub-elements regular points. E.g. for a conversion from GPX to GPX format, building on the previous example, we would obtain:

<rtept lat="46.544628096744418" lon="6.658079791814089"/>
<rtept lat="46.544483928009868" lon="6.658018603920937"/>
<rtept lat="46.544415950775146" lon="6.658358573913574"/>
<rtept lat="46.544415950775146" lon="6.658358573913574"/>

It would work for a conversion to any other formats too, like to CSV. These subpoints would become regular points in the route.

There are already references to RoutePointExtension in GPSBabel code, and some support for Garmin specific GPX extensions, but not the feature I suggest here.

Reference

The XML DTD from Garmin defining these RoutePointExtension:
http://www8.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd

[GPSBabelDeveloper]

This actually works less well in practice than you'd hope. Basecamp, like their routing GPSes, doesn't encode "turn left at the intersection of X and Y" , it encodes "turn left at LAT/LONG" which may be a one-way street and wwill, in practice, send you on lots of one block round-abouts if you try to use these on another routing engine where the basemap may differ by a few meters.

I won't close the request as unreasonable, but I've spent enough effort trying to make this work that I won't personally be coding it. I'll review and incorporporate it in case anyone else can make it work sensibly, include enough disclaimers why it won't work in the general case, and be willing to field the support traffic.

[fbonzon]

It seems to me that my request is simpler. Why is the way to encode navigation hints relevant?

I'm not suggesting to parse or infer any navigation hints. I'm suggesting only to keep the geometry (LAT/LONG) of the gpxx:rpt sub-elements, currently discarded by GPSBabel.

Actual

Primary routing points are read and converted.
gpxx:rpt sub-elements are discarded.

Expected

Primary routing points are read and converted. (no change from actual)
LAT/LONG of gpxx:rpt sub-elements are parsed, and inserted as new points after their primary point.