* Fixes errors selecting 'nearest' items, including duplicates
* Stable behaviour around the poles and dateline
* Decently efficient, even for 'everything within 500nm' queries
The quotes form is normally only used for headers with path relative
to the including file's path, though the standard doesn't strictly
mandate this. This is consistent with the rest of sg/fg, it makes the
code's intent clearer and helps to find headers. (And it's a few
milliseconds faster, too.)
instrument of the same name. In the future I'd prefer to rename the
instrument class instead (FGMarkerBeaconReciever?) but this is the safest
change for now.
Thanks (again) to Yon Uriarte for pointing out the problem (which seems to
affect MSVC more than gcc)
saving for beacons, but since they're surprisingly few (in nav.dat), not a
an enormous saving in real terms. The major motivation is that marker beacons
don't behave like other NavRecords for radio interaction - they have no ident,
frequency or range (in the sense that NavRecord means them).
airportList search function. At least for me (with a mutex-based SGAtomic),
large vectors of referenced-pointers is a Bad Thing - copying on vector
resize is thrashing the locks.
static FGAirport helpers. As a result, another global index goes away. Use
the helpers to avoid ugly FGPositioned down-casts in various places.
Also converts the environment/METAR code to deal with FGAirport pointers,
instead of string identifiers, and contains work-in-progress code to implement
the AirportList dialog using FGPositioned. This isn't enabled yet for various
reasons, but is the final piece to allow FGAirportList to be removed.
by frequency (which makes sense), and use the FGPositioned spatial data if
required. As a result, the marker beacon list is gone (since beacons are only
searched spatially). In the process, clean up various minor things - most
notably, all the 'airport-related' navaids (ILS, GS, LOC, and the beacons) now
store a FGRunway* instead of an airport id string. This is more precise, and
saves string allocations.
const) which were previously tricky but now easy. Make it possible not to
index certain types (used for taxiways) and exclude anonymous items from
the name index. Related to this, clean up FGRunway further - remove some public
members, and fix a dumb bug of mine, where we create reciprocal entries for
taxiways.
This should make startup (slightly) quicker, and shrinks FGRunway somewhat.
- updates how filtering is done on the various FGPositioned query functions - both spatial and ident-based.
- updates the KLN-89b / DCLGPS code to use FGPositioned for all Navaid/Airport queries.
me:
Add few include directives in globals.cxx to avoid such MSVC warning messages :
deletion of pointer to incomplete type 'FGAirportList'; no destructor called
deletion of pointer to incomplete type 'FGNavList'; no destructor called
deletion of pointer to incomplete type 'FGTACANList'; no destructor called
deletion of pointer to incomplete type 'FGFixList'; no destructor called
Attached patch updates the route-manager to use FGPositioned to search
for waypoints, instead of a manual airport / fix / navaid search. This
is good because it's now using the 'strictly closest' match, rather
than arbitrarily picking a distant fix over a nearby navaid. In my
case, the TLA VOR is significant to several EGPH procedures, but also
happens to be the ident of a fix a long, long way away.
Also updates the FGPositioned class to stop using Point3D, partly
because it's deprecated and partly because I had misunderstood the
interface and was using it wrong. For now, all FGPositioned distance
checks use SGGeodesy::inverse, which is accurate but inefficient. Once
FGPositioned queries are used for something on a hot path, I'll
probably store the cartesian position as well as the geodetic, to make
these checks fast.
Convert FGNavRecord to inherit FGPositioned. This is much more self-contained than the FGRunway change, since FGNavRecord already had good encapsulation of its state. However, it's a large diff due to moving around two nasty pieces of code - the 'align navaid with extended runway centerline' logic and the 'penalise transmitters at the opposite runway end' logic.
In general things are more readable because I've replaced the Navaid type enum, and the use of Robin's integer type codes, with switches on the FGPositioned::Type code - no more trying to recall that '6' is an outer marker in Robin's data. The creation code path is also pushed down from navdb into navrecord itself.
Convert FGRunway to be heap-based, and inherit FGPositioned. This is a large, ugly change, since FGRunway was essentially a plain struct, with no accessors or abstraction. This change adds various helpers and accessors to FGRunway, but doesn't change many places to use them - that will be a follow up series of patches. It's still a large patch, but outside of FGAirport and FGRunway, mostly mechanical search-and-replace.
An interesting part of this change is that reciprocal runways now exist as independent objects, rather than being created on the fly by the search methods. This simplifies some pieces of code that search for and iterate runways. For users who only want one 'end' of a runway, the new 'isReciprocal' predicate allows them to ignore the 'other' end. Current the only user of this is the 'ground-radar' ATC feature. If we had data on which runways are truly 'single-ended', it would now be trivial to use this in the airport loader to *not* create the reciprocal.
