Navdata cache

See also Fgfs.pid.

The navdata cache, navdb, (sometimes also navcache) is automatically built by FlightGear during startup by parsing/processing the gzipped nav.dat file and building a spatial SQLite-based database in $FG_HOME so that more efficient queries can be run at run-time. The memory consumption is lower since it doesn't keep airports / fixes / taxiways / runways in memory until they're needed.

Technical details

The nav-cache is versioned, it will be wiped when the cache schema version changes.

The DB schema version is tracked internally in the file, and if the schema changes during a development version it will force a drop and rebuild.

The naming scheme is why the first run of a new stable release of FG always does a cache rebuild - which means you can run stable and dev versions side by side without continual cache rebuilds of course.

At launch time a Sqlite verification check on the DB is also run - this should catch many kinds of file-/index- level corruption.

The cache is stored in $FG_HOME/navdata.cache, and is rebuilt if the timestamps on any of the data files change (apt.dat, nav.dat, fix.dat and so on). When the cache needs to be rebuilt, startup will take a bit longer than before, but when the cache is valid, startup is much faster, especially for debug builds - because all the usual parsing/processing will be skipped, and the corresponding data will be read from the binary cache instead.

Access

You can use any SQLite editor/browser to access the navcache file and visualize it There are basically two ways to access this via Nasal 1) the "proper" way is to use/extend the NasalPositioned(_cpbind).cxx file in $FG_SRC/Scripting - with 2), being direct SQLite access using the sqlite module from the Nasal github repo.

Accessing via Nasal

See Nasal library for the main article about this subject.

Several Nasal functions exist to query the navdata cache of 'positioned' objects, i.e items with a defined location in the simulation world. (These objects all inherit from FGPositioned internally). The functions return either one, or a vector, of wrapped Nasal objects. These are efficient, but unlike a hash they cannot simply be debug.dump() to view all their members and methods, many of which are computed in a lazy fashion (i.e. on demand).

When the query functions take a position, the default value is the current aircraft location. An alternative location can be supplied by passing two number (lat, lon), a Geo.Coord object, or any positioned object or waypoint retrieved from another query.

References