The Flight-plan leg data computation was omitting certain data for the final waypoint, which in turn made some of the route-manager data bogus when flying the final leg. Fill in some sensible values which we can compute.
Avoid the application becoming unresponsive during nav-cache rebuilds. We still have to wait for the rebuild, but perform it on a helper thread so the main GUI thread stays responsive and hence doesn't trigger a beach-ball / 'not responding' alert. Also ensures there's some feedback (the spinner) during the rebuild operation, so users don't think we've hung.
In preparation for caching the groundnet in the NavCache, make taxi-nodes and parkings inherit from FGPositioned. As part of this, make them heap (as opposed to value) classes, disable their copy-constructors, remove many mutating operations, and give them real constructors.
Keep distro packagers happy by having the option to use the system's sqlite library instead of our bundled version. Set SYSTEM_SQLITE=1 when running cmake to use the system one.
Cache the parsed navigation and airport data in a binary file to reduce
startup times and memory consumption (since only referenced FGPositioned
elements are held in memory).
Data will be reimported when the mod-time of any input file is changed.
If a global file is changed (nav.dat, awy.dat, apt.dat, etc), the cache
will be completely rebuilt, which takes approximately 30 seconds on
moderate hardware. (Future work may reduce this).
When inserting with an invalid index, ensure we return the leg based on the fixed-up index, not the original one. Thanks to Matthias Götz for the catch!
The glideslope station was only searched once whenever the NAV station
changed. However, sometimes a mismatching G/S station is found, since
another G/S station is still closer when the NAV station changes.
When this happened, the G/S station was never updated again (while the
NAV station stayed in range), resulting in the NAV receiver providing
correct localizer, but bad G/S data (data matching another, remote station).
Issue is fixed by alternating between searching NAV and G/S stations.
The routing behaviour now happens entirely in Nasal,
using a delegate, and can be over-ridden or disable
by aircraft authors. Default behaviour should be
unchanged.
Convert the route-manager to use a flight-plan internally, and expose
flightplan, leg and procedure data to Nasal. Move the Level-D parser
into its own file.
This fixes at least the startup process.
If an ambigous fix name was presented with --vor=ID or --ndb=ID
present a list of matching records along with frequency and
position in the console to give the user the chance to pick
the correct one by adding the frequency with --vor-frequency=nnn.nn
It does not yes solve the issue when the user relocates using the
GUI dialog. This requires some GUI and Nasal hacking along with a
new Nasal helper function "navaidinfo".
