Garmin Extensions may not be correctly written in GPX

Given a file that clearly contains Garmin Format Specific stuff, we can see it written by unicsv: ./gpsbabel -i gdb -f reference/gdb-sample-v3-autoroute.gdb -o unicsv -F - No,Latitude,Longitude,Name,Altitude,Description,Notes,Symbol,Date,Time,Address,City,PostalCode,State,Country,Phone [ ... ] 39,44.390710,-68.045377,"1 Birch Harbor Rd",,"1 Birch Harbor Rd,Winter Harbor, ME, 04693, USA","1 Birch Harbor Rd,Winter Harbor, ME, 04693, USA","Flag, Blue",2020/06/08,13:39:00,"1 Birch Harbor Rd","Winter Harbor","04693","ME","USA",

If we write this file back to GPX, turning on garminextensions (which does set gpxver = 1.1) we might expect to find a City written by garmin_fs_xml_fprint(). We don't: $ ./gpsbabel -i gdb -f reference/gdb-sample-v3-autoroute.gdb -o gpx,garminextensions -F - | grep gpxx:City $

If we chase this into gpx_waypt_pr(), we see the lone call to garmin_fs_xml_fprint is inside a block that's blocked by: if (!(opt_humminbirdext || opt_garminext)) {

This evaluates true only if both options are false. This means we ONLY go grub around inside gmsd if we have neither flag. Since garminextensions set gpx_1_1, this means we only hit garmin_fs_xml_fprint if we explicitly set gpxver and to NOT set garminextensions

gpsbabel % make && ./gpsbabel -i gdb -f reference/gdb-sample-v3-autoroute.gdb -o gpx,garminextensions,gpxver=1.1 -F - | grep gpxx:City make: Nothing to be done for all'. gpsbabel % make && ./gpsbabel -i gdb -f reference/gdb-sample-v3-autoroute.gdb -o gpx,garminextensions=1,gpxver=1.1 -F - | grep gpxx:City make: Nothing to be done forall'. gpsbabel % make && ./gpsbabel -i gdb -f reference/gdb-sample-v3-autoroute.gdb -o gpx,garminextensions=0,gpxver=1.1 -F - | grep gpxx:City make: Nothing to be done for `all'.

Winter Harbor Gouldsboro Twn Winter Harbor Twn That's pretty counterintuitive. Do we have that outer test backward? Of course, "fixing" this has fallout in our test suite, but I *think* the fallout is good and should be accepted. I think. We have this same mind-bending logic in a the track and route cases, too. Our test here has gotten out of hand. If we have either extensions option set, we have gpx 1.1 set, so some of this can just go away.

GPSBabel / gpsbabel

Garmin Extensions may not be correctly written in GPX #623