fly/flightgear
1
0
Fork 0
Code Activity
flightgear/src/Navaids/navrecord.cxx

146 lines
3.8 KiB
C++
Raw Normal View History

James Turner: Attached patch + new file make FGNavRecord have a .cxx file, and a constructor w hich allows all the parameters to be supplied. Along the way I also cleaned up t he navrecord.hxx header, lots more header pollution has been killed. Some long methods are no longer inline, but were all suspiciously long to meet c ompiler inlining criteria (I'm not clear if the 'inline' keyword is advisory or mandatory in this situation) - I don't expect this to affect performance in any way whatsoever. The constructor addition is to support some hacking I'm doing improving the star tup performance of the navDB by lazily loading the data, and caching it in a mor e efficient format than text. I'm submitting this change (and probably some othe r small tweaks in the future) since they are worthwhile as cleanups regardless o f how my current experiments work out.
2008-08-03 14:34:42 +00:00
// navrecord.cxx -- generic vor/dme/ndb class
//
// Written by Curtis Olson, started May 2004.
//
// Copyright (C) 2004 Curtis L. Olson - http://www.flightgear.org/~curt
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
// published by the Free Software Foundation; either version 2 of the
// License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
//
// $Id$
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <istream>
James Turner: 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.
2008-09-12 08:46:15 +00:00
#include <simgear/misc/sgstream.hxx>
#include <simgear/structure/exception.hxx>
#include <simgear/debug/logstream.hxx>
James Turner: Attached patch + new file make FGNavRecord have a .cxx file, and a constructor w hich allows all the parameters to be supplied. Along the way I also cleaned up t he navrecord.hxx header, lots more header pollution has been killed. Some long methods are no longer inline, but were all suspiciously long to meet c ompiler inlining criteria (I'm not clear if the 'inline' keyword is advisory or mandatory in this situation) - I don't expect this to affect performance in any way whatsoever. The constructor addition is to support some hacking I'm doing improving the star tup performance of the navDB by lazily loading the data, and caching it in a mor e efficient format than text. I'm submitting this change (and probably some othe r small tweaks in the future) since they are worthwhile as cleanups regardless o f how my current experiments work out.
2008-08-03 14:34:42 +00:00
James Turner: 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.
2008-09-12 08:46:15 +00:00
#include "Navaids/navrecord.hxx"
Refactor marker-beacons to be distinct from FGNavRecord. This is a big space 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).
2009-01-03 15:54:03 +00:00
#include "Navaids/navdb.hxx"
James Turner: 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.
2008-09-12 08:46:15 +00:00
#include "Airports/runways.hxx"
#include "Main/fg_props.hxx"
FGNavRecord::FGNavRecord(Type aTy, const std::string& aIdent,
FGPositioned clean-ups - apply some desirable changes (such as making members 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.
2008-12-24 14:48:30 +00:00
const std::string& aName, const SGGeod& aPos,
James Turner: 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.
2008-09-12 08:46:15 +00:00
int aFreq, int aRange, double aMultiuse) :
FGPositioned clean-ups - apply some desirable changes (such as making members 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.
2008-12-24 14:48:30 +00:00
FGPositioned(aTy, aIdent, aPos),
James Turner: Attached patch + new file make FGNavRecord have a .cxx file, and a constructor w hich allows all the parameters to be supplied. Along the way I also cleaned up t he navrecord.hxx header, lots more header pollution has been killed. Some long methods are no longer inline, but were all suspiciously long to meet c ompiler inlining criteria (I'm not clear if the 'inline' keyword is advisory or mandatory in this situation) - I don't expect this to affect performance in any way whatsoever. The constructor addition is to support some hacking I'm doing improving the star tup performance of the navDB by lazily loading the data, and caching it in a mor e efficient format than text. I'm submitting this change (and probably some othe r small tweaks in the future) since they are worthwhile as cleanups regardless o f how my current experiments work out.
2008-08-03 14:34:42 +00:00
freq(aFreq),
range(aRange),
multiuse(aMultiuse),
Remove all name and spatial queries from FGNavList. All remaining queries are 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.
2008-12-25 23:11:43 +00:00
_name(aName),
James Turner: Attached patch + new file make FGNavRecord have a .cxx file, and a constructor w hich allows all the parameters to be supplied. Along the way I also cleaned up t he navrecord.hxx header, lots more header pollution has been killed. Some long methods are no longer inline, but were all suspiciously long to meet c ompiler inlining criteria (I'm not clear if the 'inline' keyword is advisory or mandatory in this situation) - I don't expect this to affect performance in any way whatsoever. The constructor addition is to support some hacking I'm doing improving the star tup performance of the navDB by lazily loading the data, and caching it in a mor e efficient format than text. I'm submitting this change (and probably some othe r small tweaks in the future) since they are worthwhile as cleanups regardless o f how my current experiments work out.
2008-08-03 14:34:42 +00:00
serviceable(true),
trans_ident(aIdent)
James Turner: 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.
2008-09-12 08:46:15 +00:00
{
initAirportRelation();
// Ranges are included with the latest data format, no need to
// assign our own defaults, unless the range is not set for some
// reason.
if (range < 0.1) {
SG_LOG(SG_GENERAL, SG_WARN, "navaid " << ident() << " has no range set, using defaults");
switch (type()) {
case NDB:
case VOR:
range = FG_NAV_DEFAULT_RANGE;
break;
case LOC:
case ILS:
case GS:
range = FG_LOC_DEFAULT_RANGE;
break;
case DME:
range = FG_DME_DEFAULT_RANGE;
break;
default:
range = FG_LOC_DEFAULT_RANGE;
}
}
James Turner: Attached patch + new file make FGNavRecord have a .cxx file, and a constructor w hich allows all the parameters to be supplied. Along the way I also cleaned up t he navrecord.hxx header, lots more header pollution has been killed. Some long methods are no longer inline, but were all suspiciously long to meet c ompiler inlining criteria (I'm not clear if the 'inline' keyword is advisory or mandatory in this situation) - I don't expect this to affect performance in any way whatsoever. The constructor addition is to support some hacking I'm doing improving the star tup performance of the navDB by lazily loading the data, and caching it in a mor e efficient format than text. I'm submitting this change (and probably some othe r small tweaks in the future) since they are worthwhile as cleanups regardless o f how my current experiments work out.
2008-08-03 14:34:42 +00:00
}
James Turner: 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.
2008-09-12 08:46:15 +00:00
void FGNavRecord::initAirportRelation()
{
Refactor marker-beacons to be distinct from FGNavRecord. This is a big space 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).
2009-01-03 15:54:03 +00:00
if ((type() < ILS) || (type() > GS)) {
James Turner: 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.
2008-09-12 08:46:15 +00:00
return; // not airport-located
}
Refactor marker-beacons to be distinct from FGNavRecord. This is a big space 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).
2009-01-03 15:54:03 +00:00
FGRunway* runway = getRunwayFromName(_name);
// fudge elevation to the runway elevation if it's not specified
James Turner: 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.
2008-09-12 08:46:15 +00:00
if (fabs(elevation()) < 0.01) {
Refactor marker-beacons to be distinct from FGNavRecord. This is a big space 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).
2009-01-03 15:54:03 +00:00
mPosition.setElevationFt(runway->elevation());
James Turner: 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.
2008-09-12 08:46:15 +00:00
}
// align localizers with their runway
if ((type() == ILS) || (type() == LOC)) {
if (!fgGetBool("/sim/navdb/localizers/auto-align", true)) {
return;
James Turner: Attached patch + new file make FGNavRecord have a .cxx file, and a constructor w hich allows all the parameters to be supplied. Along the way I also cleaned up t he navrecord.hxx header, lots more header pollution has been killed. Some long methods are no longer inline, but were all suspiciously long to meet c ompiler inlining criteria (I'm not clear if the 'inline' keyword is advisory or mandatory in this situation) - I don't expect this to affect performance in any way whatsoever. The constructor addition is to support some hacking I'm doing improving the star tup performance of the navDB by lazily loading the data, and caching it in a mor e efficient format than text. I'm submitting this change (and probably some othe r small tweaks in the future) since they are worthwhile as cleanups regardless o f how my current experiments work out.
2008-08-03 14:34:42 +00:00
}
Remove all name and spatial queries from FGNavList. All remaining queries are 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.
2008-12-25 23:11:43 +00:00
double threshold
= fgGetDouble( "/sim/navdb/localizers/auto-align-threshold-deg", 5.0 );
James Turner: 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.
2008-09-12 08:46:15 +00:00
alignLocaliserWithRunway(runway, threshold);
}
James Turner: Attached patch + new file make FGNavRecord have a .cxx file, and a constructor w hich allows all the parameters to be supplied. Along the way I also cleaned up t he navrecord.hxx header, lots more header pollution has been killed. Some long methods are no longer inline, but were all suspiciously long to meet c ompiler inlining criteria (I'm not clear if the 'inline' keyword is advisory or mandatory in this situation) - I don't expect this to affect performance in any way whatsoever. The constructor addition is to support some hacking I'm doing improving the star tup performance of the navDB by lazily loading the data, and caching it in a mor e efficient format than text. I'm submitting this change (and probably some othe r small tweaks in the future) since they are worthwhile as cleanups regardless o f how my current experiments work out.
2008-08-03 14:34:42 +00:00
}
James Turner: 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.
2008-09-12 08:46:15 +00:00
void FGNavRecord::alignLocaliserWithRunway(FGRunway* aRunway, double aThreshold)
{
// find the distance from the threshold to the localizer
SGGeod runwayThreshold(aRunway->threshold());
double dist, az1, az2;
SGGeodesy::inverse(mPosition, runwayThreshold, az1, az2, dist);
// back project that distance along the runway center line
SGGeod newPos = aRunway->pointOnCenterline(dist);
double hdg_diff = get_multiuse() - aRunway->headingDeg();
// clamp to [-180.0 ... 180.0]
if ( hdg_diff < -180.0 ) {
hdg_diff += 360.0;
} else if ( hdg_diff > 180.0 ) {
hdg_diff -= 360.0;
}
if ( fabs(hdg_diff) <= aThreshold ) {
mPosition = newPos;
set_multiuse( aRunway->headingDeg() );
} else {
SG_LOG(SG_GENERAL, SG_WARN, "localizer:" << ident() << ", aligning with runway "
FGPositioned clean-ups - apply some desirable changes (such as making members 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.
2008-12-24 14:48:30 +00:00
<< aRunway->ident() << " exceeded heading threshold");
James Turner: 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.
2008-09-12 08:46:15 +00:00
}
}
James Turner: Attached patch + new file make FGNavRecord have a .cxx file, and a constructor w hich allows all the parameters to be supplied. Along the way I also cleaned up t he navrecord.hxx header, lots more header pollution has been killed. Some long methods are no longer inline, but were all suspiciously long to meet c ompiler inlining criteria (I'm not clear if the 'inline' keyword is advisory or mandatory in this situation) - I don't expect this to affect performance in any way whatsoever. The constructor addition is to support some hacking I'm doing improving the star tup performance of the navDB by lazily loading the data, and caching it in a mor e efficient format than text. I'm submitting this change (and probably some othe r small tweaks in the future) since they are worthwhile as cleanups regardless o f how my current experiments work out.
2008-08-03 14:34:42 +00:00
FGTACANRecord::FGTACANRecord(void) :
channel(""),
freq(0)
{
}
std::istream&
operator >> ( std::istream& in, FGTACANRecord& n )
{
in >> n.channel >> n.freq ;
//getline( in, n.name );
return in;
}
Copy permalink