Skyview generated .gpx not accepted by MAPSOURCE

[Axel]

Reason: non standard tag
   <overfly>false</overfly>

   When these tags are deleted (for every route point), Skyview routes can be processed/modified by Garmin's MAPSOURCE software

Suggestion:
   Skyview should not generate this tag when exporting routes in .gpx format, since

- it seems to be default anyway
- flyby/overfly is not very useful (in general, and in particular) when exporting routes for other systems

 

[dynonsupport]

If we don't export these, then a flight plan re-imported into SkyView won't have the overfly status set like you want. Being able to toggle overfly is a critical operation for IFR flight planning.

The GPX format is designed to handle new tags that the importing software doesn't know about. In fact, Garmin adds stuff to their GPX files that are non-standard as well. So I'd suggest contacting Garmin and asking them why their program rejects these files instead of just ignoring these elements, since that is the standard way to deal with XML files with unknown tags.

 

[Axel]

The GPX format is designed to handle new tags that the importing software doesn't know about. In fact, Garmin adds stuff to their GPX files that are non-standard as well.

I agree.
But why generate tags providing attributes that are (considered by Dynon) default ? This makes no sense.
Omitting them would not change the semantics and would make Dynon's .gpx importable.

Being able to toggle overfly is a critical operation for IFR flight planning.

Huh? Not sure.
During decades I flew tons of IFR legs without toggling any "overfly".

 

[dynonsupport]

Check out the FAA's AIM on RNAV, 1-2-1, section b1 on why fly-over and fly-by is so important:

http://www.faa.gov/air_traffic/publications/atpubs/aim/aim0102.html

We do allow the user to toggle overfly in the flight planning menu. So we aren't including something that is always set the same. It's bad programming juju to not include something you know in your output. There is a difference between knowing that the file was export from a program that can set overfly and chose to set it false and a program that has no idea of overfly and thus you need to assume they wanted it to be false.

We'll happily import Garmin's GPX files with all their non-standard tags. Why not expect the same of Garmin instead of asking us to work around their bugs?