[Flightgear-devel] FGPositioned refactoring

[James T. <zak...@ma...>]

I'm planning to do a slightly intensive re-factoring - creating a base  
class where one didn't exist before. The (draft) base class is  
attached - it will become a base for the following:
	FGAirport
	FGRunway
	FGFix
	FGNavRecord
	ATCData

The members are pretty uncontroversial, I think. What I'll do is keep  
the 'old' accessors / members on each derived class, to avoid a  
massive diff, and clean them up in separate, boring patches.

Once the base class is in, and nothing is broken, I'll proceed as  
follows:
- make FGFix, FGRunway and ATCdata be 'pointery', so all these things  
are living on the heap and do proper virtual calls. I'll actually make  
them SGReferenced I hope, but I need to see how much more work that  
will be. (FGNavRecord is already an SGReferenced, for example)

- create a centralised, SGBucket-based spatial index of the whole lot,  
with some query methods:

	static FGPositionedList  
FGPositioned::findWithinRangeOfLocation(double lat, double lon, double  
rangeNm);

	static FGPositionedList FGPositioned::findWithIdent(....)
	static FGPositionedList FGPositioned::findClosestWithIdent(....)

(and of course some variants / overloads to filter by type. I need to  
check about overloading statics, but ideally  
FGNavRecord::findWithinRangeOfLocation
would be overloaded to only return navaids, etc, etc).

- gradually simplify  or kill off the various FGblahList classes in  
favour of unified queries on this (i.e clean up the call sites). This  
includes removing the 'poor mans' spatial index in navlist, the total  
*absence* of a spatial DB in airports, the SGBucket-based one in  
commlist.cxx. At the same time I'd let the derived classes keep their  
specialised indices and query methods - eg airport idents are unique,  
navaids and ATCDatas can be indexed by frequency, and so on.

(this last step will take some time :)

The motivation for this is of course being able to build my NAV  
display, but it's also the starting point for working on improving the  
airways code and creating a standard FGFlightPlan class - an airway or  
flightplan is essentially built out of FGPositioned objects, tagged  
with some extra data. And indeed that's what Dave Luff's GPS code  
looks like - just using its own internal waypoint and flightplan  
classes for these jobs, which is one of the many things I hope to  
improve.

Incidentally, the unified 'type' enum will replace several existing  
type fields - the FGAirport type member, the FGRunway taxiway flag,  
the FGNavRecord type, and the ATCData type. There's also scope to add  
more - I've optimistically included an 'OBSTACLE' type, for example,  
on the hope that I can add find an existing obstacle DB to import. In  
any case, adding types is cheap.

Comments on, or objections to, this plan, would be greatly  
appreciated. Note I hate the name 'FGPositioned' but can't think of a  
better name that accurately reflects what the class does. I'll buy a  
beer/beer-substitute for anyone who comes up with a shorter, more  
meaningful class name.

Cheers,
James