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

75 lines
2.2 KiB
C++
Raw Normal View History

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
// markerbeacon.cxx -- marker beacon class
//
// Written by James Turner, started December 2008.
//
// Copyright (C) 2008 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 <simgear/structure/exception.hxx>
#include <simgear/debug/logstream.hxx>
turn a few #include paths from the "foo" form to <foo> 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.)
2009-05-14 20:55:09 +00:00
#include <Navaids/markerbeacon.hxx>
#include <Airports/runways.hxx>
#include <Navaids/navdb.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
using std::string;
FGPositioned::Type
Rename FGMarkerBeacon to FGMarkerBeacon record, to avoid a clash with the 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)
2009-01-04 20:12:43 +00:00
FGMarkerBeaconRecord::mapType(int aTy)
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
{
switch (aTy) {
case 7: return FGPositioned::OM;
case 8: return FGPositioned::MM;
case 9: return FGPositioned::IM;
default:
throw sg_range_exception("Got a non-marker-beacon-type",
Rename FGMarkerBeacon to FGMarkerBeacon record, to avoid a clash with the 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)
2009-01-04 20:12:43 +00:00
"FGMarkerBeaconRecord::mapType");
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
}
}
Rename FGMarkerBeacon to FGMarkerBeacon record, to avoid a clash with the 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)
2009-01-04 20:12:43 +00:00
FGMarkerBeaconRecord*
FGMarkerBeaconRecord::create(int aTy, const string& aName, const SGGeod& aPos)
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
{
Type fgpTy = mapType(aTy);
FGRunway* runway = getRunwayFromName(aName);
marker beacon: catch NULL pointer when runway not in navdb (affects incomplete/inconsistent nav data only).
2012-03-26 21:04:23 +02:00
if (!runway)
{
Reduce severity of a failure to create a marker beacon due to an unknown runway from ALERT to WARN. Not particularly relevant error message for most users.
2012-06-30 20:50:57 +01:00
SG_LOG(SG_GENERAL, SG_WARN, "Failed to create beacon for unknown runway '" << aName << "'.");
marker beacon: catch NULL pointer when runway not in navdb (affects incomplete/inconsistent nav data only).
2012-03-26 21:04:23 +02:00
return NULL;
}
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
SGGeod pos(aPos);
// fudge elevation to the runway elevation if it's not specified
if (fabs(pos.getElevationFt()) < 0.01) {
pos.setElevationFt(runway->elevation());
}
Rename FGMarkerBeacon to FGMarkerBeacon record, to avoid a clash with the 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)
2009-01-04 20:12:43 +00:00
return new FGMarkerBeaconRecord(fgpTy, runway, pos);
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
}
Rename FGMarkerBeacon to FGMarkerBeacon record, to avoid a clash with the 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)
2009-01-04 20:12:43 +00:00
FGMarkerBeaconRecord::FGMarkerBeaconRecord(Type aTy, FGRunway* aRunway, const SGGeod& aPos) :
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
FGPositioned(aTy, string(), aPos),
_runway(aRunway)
{
Fix bug 150 (airports not found in GPS search) Overhaul and simplify the GPS search logic based on experience and testing with the API. Also fix search-by-name, which was broken.
2010-08-14 19:16:28 +01:00
init(true); // init FGPositioned
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
}
Copy permalink