1
0
Fork 0
flightgear/src/Airports/simple.hxx

186 lines
5.3 KiB
C++
Raw Normal View History

// simple.hxx -- a really simplistic class to manage airport ID,
1998-08-25 17:19:13 +00:00
// lat, lon of the center of one of it's runways, and
// elevation in feet.
//
// Written by Curtis Olson, started April 1998.
// Updated by Durk Talsma, started December 2004.
1998-08-25 17:19:13 +00:00
//
// Copyright (C) 1998 Curtis L. Olson - http://www.flightgear.org/~curt
1998-08-25 17:19:13 +00:00
//
// 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
2006-02-21 01:16:04 +00:00
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
1998-08-25 17:19:13 +00:00
//
// $Id$
2003-08-28 20:53:08 +00:00
#ifndef _FG_SIMPLE_HXX
#define _FG_SIMPLE_HXX
1998-08-25 17:19:13 +00:00
#ifndef __cplusplus
# error This library requires C++
#endif
2000-04-27 03:26:36 +00:00
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
#include <simgear/math/point3d.hxx>
2000-02-15 03:30:01 +00:00
#include <simgear/compiler.h>
//#include <simgear/xml/easyxml.hxx>
2000-02-15 03:30:01 +00:00
#include STL_STRING
2003-08-28 20:53:08 +00:00
#include <map>
#include <set>
2003-11-27 23:37:03 +00:00
#include <vector>
#include "runwayprefs.hxx"
#include "parking.hxx"
#include "groundnetwork.hxx"
#include "dynamics.hxx"
2001-03-23 22:59:18 +00:00
SG_USING_STD(string);
2003-08-28 20:53:08 +00:00
SG_USING_STD(map);
SG_USING_STD(set);
2003-11-27 23:37:03 +00:00
SG_USING_STD(vector);
2003-08-28 20:53:08 +00:00
/***************************************************************************************
*
**************************************************************************************/
class FGAirport {
private:
string _id;
David Luff: Attached is a patch to the airport data storage that I would like committed after review if acceptable. Currently the storage of airports mapped by ID is by locally created objects - about 12 Meg or so created on the stack if I am not mistaken. I've changed this to creating the airports on the heap, and storing pointers to them - see FGAirportList.add(...) in src/Airports/simple.cxx. I believe that this is probably better practice, and it's certainly cured some strange problems I was seeing when accessing the airport data with some gps unit code. Changes resulting from this have cascaded through a few files which access the data - 11 files are modified in all. Melchior and Durk - you might want to test this and shout if there are problems since the metar and traffic code are probably the biggest users of the airport data. I've also added a fuzzy search function that returns the next matching airport code in ASCII sequence in order to support gps units that have autocompletion of partially entered codes. More generally, the simple airport class seems to have grown a lot with the fairly recent addition of the parking, runway preference and schedule time code. It is no longer just an encapsulation of the global airport data file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!). My personal opinion is that we should look to just store the basic data in apt.dat for all global airports in a simple airport class, plus globally needed data (metar available?), and then have the traffic, AI and ATC subsystems create more advanced airports for themselves as needed in the area of interest. Once a significant number of airports worldwide have ground networks and parking defined, it will be impractical and unnecessary to store them all in memory. That's just a thought for the future though.
2005-09-20 20:26:57 +00:00
double _longitude; // degrees
double _latitude; // degrees
double _elevation; // ft
string _name;
bool _has_metar;
FGAirportDynamics *dynamics;
public:
FGAirport();
// FGAirport(const FGAirport &other);
FGAirport(const string& id, double lon, double lat, double elev, const string& name, bool has_metar);
~FGAirport();
David Luff: Attached is a patch to the airport data storage that I would like committed after review if acceptable. Currently the storage of airports mapped by ID is by locally created objects - about 12 Meg or so created on the stack if I am not mistaken. I've changed this to creating the airports on the heap, and storing pointers to them - see FGAirportList.add(...) in src/Airports/simple.cxx. I believe that this is probably better practice, and it's certainly cured some strange problems I was seeing when accessing the airport data with some gps unit code. Changes resulting from this have cascaded through a few files which access the data - 11 files are modified in all. Melchior and Durk - you might want to test this and shout if there are problems since the metar and traffic code are probably the biggest users of the airport data. I've also added a fuzzy search function that returns the next matching airport code in ASCII sequence in order to support gps units that have autocompletion of partially entered codes. More generally, the simple airport class seems to have grown a lot with the fairly recent addition of the parking, runway preference and schedule time code. It is no longer just an encapsulation of the global airport data file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!). My personal opinion is that we should look to just store the basic data in apt.dat for all global airports in a simple airport class, plus globally needed data (metar available?), and then have the traffic, AI and ATC subsystems create more advanced airports for themselves as needed in the area of interest. Once a significant number of airports worldwide have ground networks and parking defined, it will be impractical and unnecessary to store them all in memory. That's just a thought for the future though.
2005-09-20 20:26:57 +00:00
string getId() const { return _id;};
const string &getName() const { return _name;};
David Luff: Attached is a patch to the airport data storage that I would like committed after review if acceptable. Currently the storage of airports mapped by ID is by locally created objects - about 12 Meg or so created on the stack if I am not mistaken. I've changed this to creating the airports on the heap, and storing pointers to them - see FGAirportList.add(...) in src/Airports/simple.cxx. I believe that this is probably better practice, and it's certainly cured some strange problems I was seeing when accessing the airport data with some gps unit code. Changes resulting from this have cascaded through a few files which access the data - 11 files are modified in all. Melchior and Durk - you might want to test this and shout if there are problems since the metar and traffic code are probably the biggest users of the airport data. I've also added a fuzzy search function that returns the next matching airport code in ASCII sequence in order to support gps units that have autocompletion of partially entered codes. More generally, the simple airport class seems to have grown a lot with the fairly recent addition of the parking, runway preference and schedule time code. It is no longer just an encapsulation of the global airport data file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!). My personal opinion is that we should look to just store the basic data in apt.dat for all global airports in a simple airport class, plus globally needed data (metar available?), and then have the traffic, AI and ATC subsystems create more advanced airports for themselves as needed in the area of interest. Once a significant number of airports worldwide have ground networks and parking defined, it will be impractical and unnecessary to store them all in memory. That's just a thought for the future though.
2005-09-20 20:26:57 +00:00
double getLongitude() const { return _longitude;};
// Returns degrees
double getLatitude() const { return _latitude; };
// Returns ft
double getElevation() const { return _elevation;};
bool getMetar() const { return _has_metar;};
void setId(const string& id) { _id = id;};
void setMetar(bool value) { _has_metar = value; };
FGAirportDynamics *getDynamics();
private:
FGAirport operator=(FGAirport &other);
FGAirport(const FGAirport&);
Changes contributed by Bernie Bright <bbright@c031.aone.net.au> - The new classes in libmisc.tgz define a stream interface into zlib. I've put these in a new directory, Lib/Misc. Feel free to rename it to something more appropriate. However you'll have to change the include directives in all the other files. Additionally you'll have add the library to Lib/Makefile.am and Simulator/Main/Makefile.am. The StopWatch class in Lib/Misc requires a HAVE_GETRUSAGE autoconf test so I've included the required changes in config.tgz. There are a fair few changes to Simulator/Objects as I've moved things around. Loading tiles is quicker but thats not where the delay is. Tile loading takes a few tenths of a second per file on a P200 but it seems to be the post-processing that leads to a noticeable blip in framerate. I suppose its time to start profiling to see where the delays are. I've included a brief description of each archives contents. Lib/Misc/ zfstream.cxx zfstream.hxx C++ stream interface into zlib. Taken from zlib-1.1.3/contrib/iostream/. Minor mods for STL compatibility. There's no copyright associated with these so I assume they're covered by zlib's. fgstream.cxx fgstream.hxx FlightGear input stream using gz_ifstream. Tries to open the given filename. If that fails then filename is examined and a ".gz" suffix is removed or appended and that file is opened. stopwatch.hxx A simple timer for benchmarking. Not used in production code. Taken from the Blitz++ project. Covered by GPL. strutils.cxx strutils.hxx Some simple string manipulation routines. Simulator/Airports/ Load airports database using fgstream. Changed fgAIRPORTS to use set<> instead of map<>. Added bool fgAIRPORTS::search() as a neater way doing the lookup. Returns true if found. Simulator/Astro/ Modified fgStarsInit() to load stars database using fgstream. Simulator/Objects/ Modified fgObjLoad() to use fgstream. Modified fgMATERIAL_MGR::load_lib() to use fgstream. Many changes to fgMATERIAL. Some changes to fgFRAGMENT but I forget what!
1998-09-01 19:02:53 +00:00
};
1998-08-25 17:19:13 +00:00
David Luff: Attached is a patch to the airport data storage that I would like committed after review if acceptable. Currently the storage of airports mapped by ID is by locally created objects - about 12 Meg or so created on the stack if I am not mistaken. I've changed this to creating the airports on the heap, and storing pointers to them - see FGAirportList.add(...) in src/Airports/simple.cxx. I believe that this is probably better practice, and it's certainly cured some strange problems I was seeing when accessing the airport data with some gps unit code. Changes resulting from this have cascaded through a few files which access the data - 11 files are modified in all. Melchior and Durk - you might want to test this and shout if there are problems since the metar and traffic code are probably the biggest users of the airport data. I've also added a fuzzy search function that returns the next matching airport code in ASCII sequence in order to support gps units that have autocompletion of partially entered codes. More generally, the simple airport class seems to have grown a lot with the fairly recent addition of the parking, runway preference and schedule time code. It is no longer just an encapsulation of the global airport data file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!). My personal opinion is that we should look to just store the basic data in apt.dat for all global airports in a simple airport class, plus globally needed data (metar available?), and then have the traffic, AI and ATC subsystems create more advanced airports for themselves as needed in the area of interest. Once a significant number of airports worldwide have ground networks and parking defined, it will be impractical and unnecessary to store them all in memory. That's just a thought for the future though.
2005-09-20 20:26:57 +00:00
typedef map < string, FGAirport* > airport_map;
2003-08-28 20:53:08 +00:00
typedef airport_map::iterator airport_map_iterator;
typedef airport_map::const_iterator const_airport_map_iterator;
2003-11-27 23:37:03 +00:00
typedef vector < FGAirport * > airport_list;
typedef airport_list::iterator airport_list_iterator;
typedef airport_list::const_iterator const_airport_list_iterator;
2003-11-27 23:37:03 +00:00
2003-08-28 20:53:08 +00:00
class FGAirportList {
private:
airport_map airports_by_id;
airport_list airports_array;
//set < string > ai_dirs;
public:
// Constructor (new)
FGAirportList();
// Destructor
2003-08-28 20:53:08 +00:00
~FGAirportList();
// add an entry to the list
void add( const string& id, const double longitude, const double latitude,
const double elevation, const string& name, const bool has_metar );
// search for the specified id.
// Returns NULL if unsucessfull.
David Luff: Attached is a patch to the airport data storage that I would like committed after review if acceptable. Currently the storage of airports mapped by ID is by locally created objects - about 12 Meg or so created on the stack if I am not mistaken. I've changed this to creating the airports on the heap, and storing pointers to them - see FGAirportList.add(...) in src/Airports/simple.cxx. I believe that this is probably better practice, and it's certainly cured some strange problems I was seeing when accessing the airport data with some gps unit code. Changes resulting from this have cascaded through a few files which access the data - 11 files are modified in all. Melchior and Durk - you might want to test this and shout if there are problems since the metar and traffic code are probably the biggest users of the airport data. I've also added a fuzzy search function that returns the next matching airport code in ASCII sequence in order to support gps units that have autocompletion of partially entered codes. More generally, the simple airport class seems to have grown a lot with the fairly recent addition of the parking, runway preference and schedule time code. It is no longer just an encapsulation of the global airport data file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!). My personal opinion is that we should look to just store the basic data in apt.dat for all global airports in a simple airport class, plus globally needed data (metar available?), and then have the traffic, AI and ATC subsystems create more advanced airports for themselves as needed in the area of interest. Once a significant number of airports worldwide have ground networks and parking defined, it will be impractical and unnecessary to store them all in memory. That's just a thought for the future though.
2005-09-20 20:26:57 +00:00
FGAirport* search( const string& id );
// Search for the next airport in ASCII sequence to the supplied id.
// eg. id = "KDC" or "KDCA" would both return "KDCA".
// If exact = true then only exact matches are returned.
// NOTE: Numbers come prior to A-Z in ASCII sequence so id = "LD" would return "LD57", not "LDDP"
// Implementation assumes airport codes are unique.
// Returns NULL if unsucessfull.
const FGAirport* findFirstById( const string& id, bool exact = false );
2003-11-27 23:37:03 +00:00
// search for the airport closest to the specified position
// (currently a linear inefficient search so it's probably not
// best to use this at runtime.) If with_metar is true, then only
// return station id's marked as having metar data.
David Luff: Attached is a patch to the airport data storage that I would like committed after review if acceptable. Currently the storage of airports mapped by ID is by locally created objects - about 12 Meg or so created on the stack if I am not mistaken. I've changed this to creating the airports on the heap, and storing pointers to them - see FGAirportList.add(...) in src/Airports/simple.cxx. I believe that this is probably better practice, and it's certainly cured some strange problems I was seeing when accessing the airport data with some gps unit code. Changes resulting from this have cascaded through a few files which access the data - 11 files are modified in all. Melchior and Durk - you might want to test this and shout if there are problems since the metar and traffic code are probably the biggest users of the airport data. I've also added a fuzzy search function that returns the next matching airport code in ASCII sequence in order to support gps units that have autocompletion of partially entered codes. More generally, the simple airport class seems to have grown a lot with the fairly recent addition of the parking, runway preference and schedule time code. It is no longer just an encapsulation of the global airport data file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!). My personal opinion is that we should look to just store the basic data in apt.dat for all global airports in a simple airport class, plus globally needed data (metar available?), and then have the traffic, AI and ATC subsystems create more advanced airports for themselves as needed in the area of interest. Once a significant number of airports worldwide have ground networks and parking defined, it will be impractical and unnecessary to store them all in memory. That's just a thought for the future though.
2005-09-20 20:26:57 +00:00
// Returns NULL if fails (unlikely unless none have metar and with_metar spec'd!)
FGAirport* search( double lon_deg, double lat_deg, bool with_metar );
2003-11-27 23:37:03 +00:00
/**
* Return the number of airports in the list.
*/
int size() const;
2003-11-27 23:37:03 +00:00
/**
* Return a specific airport, by position.
*/
David Luff: Attached is a patch to the airport data storage that I would like committed after review if acceptable. Currently the storage of airports mapped by ID is by locally created objects - about 12 Meg or so created on the stack if I am not mistaken. I've changed this to creating the airports on the heap, and storing pointers to them - see FGAirportList.add(...) in src/Airports/simple.cxx. I believe that this is probably better practice, and it's certainly cured some strange problems I was seeing when accessing the airport data with some gps unit code. Changes resulting from this have cascaded through a few files which access the data - 11 files are modified in all. Melchior and Durk - you might want to test this and shout if there are problems since the metar and traffic code are probably the biggest users of the airport data. I've also added a fuzzy search function that returns the next matching airport code in ASCII sequence in order to support gps units that have autocompletion of partially entered codes. More generally, the simple airport class seems to have grown a lot with the fairly recent addition of the parking, runway preference and schedule time code. It is no longer just an encapsulation of the global airport data file, and has grown to 552 bytes in size when unpopulated (about 1/2 a K!). My personal opinion is that we should look to just store the basic data in apt.dat for all global airports in a simple airport class, plus globally needed data (metar available?), and then have the traffic, AI and ATC subsystems create more advanced airports for themselves as needed in the area of interest. Once a significant number of airports worldwide have ground networks and parking defined, it will be impractical and unnecessary to store them all in memory. That's just a thought for the future though.
2005-09-20 20:26:57 +00:00
const FGAirport *getAirport( unsigned int index ) const;
/**
* Return a pointer to the raw airport list
*/
inline const airport_list* getAirportList() { return(&airports_array); }
/**
* Mark the specified airport record as not having metar
*/
void no_metar( const string &id );
2003-11-27 23:37:03 +00:00
/**
* Mark the specified airport record as (yes) having metar
*/
void has_metar( const string &id );
1998-08-25 17:19:13 +00:00
};
// find basic airport location info from airport database
const FGAirport *fgFindAirportID( const string& id);
// get airport elevation
double fgGetAirportElev( const string& id );
// get airport position
Point3D fgGetAirportPos( const string& id );
1998-08-25 17:19:13 +00:00
2003-08-28 20:53:08 +00:00
#endif // _FG_SIMPLE_HXX
1998-08-25 17:19:13 +00:00