1) Ok, well I have the WGS96 fortran source code. I'll write a C++ class to access it because I can't find anything in the current GMAT source code that would accomodate it. For more info go
here.
2) I just downloaded and installed Doxygen. I'll try and get a class diagram posted.
3) The only thing we would need to possibly include are ship based and airplane based observers (all of which STK has). So, I think it might be better to shift the nomenclature of the observer class that I'm creating to have either static stations fixed to the surface of a planet or attached to a mobile object. That mobile object could be a ship, an airplane, or a spacecraft. In essence, the station would inherit the position and velocity of the parent object (be it planet or craft). I'm thinking the classes will derive as follows with base classes on the left and derived classes on the right. Each derived observer will have a measurement model that is defined with it. The measurement models I think should be friend classes so that they can be associated with any of the parent objects
Observer -> MobileObserver -> Ship -> Radar,Optical,ElectroOptical
Observer -> MobileObserver -> Airplane -> Radar,Optical,ElectroOptical
Observer -> MobileObserver -> Spacecraft -> Radar,Optical,ElectroOptical
Observer -> GroundStation -> SLR, Radar,Optical,ElectroOptical
4) I think this goes back to a question previously about keeping track of whether data is real or simulated. I think that the observer class will merely define the location and capabilities of an observer. If you want GMAT to simulate observations, then you will need to define a tasker (which is yet to be created). In the absence of a tasker, observation data supplied to an estimator via an external data file or database is just data. In the end, the user should know if that external data is real or simulated. That being said, it think that an AEOS object would be defined very similar to what was said above. In this case EOGroundStation is a derived class of GroundStation and would have measurement model parameters that can be defined that are specific to EO systems.
Create EOGoundStation AEOS;
AEOS.Latitude = 20.706486; % degrees
AEOS.Longitude = 203.743084; % degrees
AEOS.Height = 3.056277; % km
AEOS.LatType = "Geodetic"; % Geodetic, Geocentric, Reduced
AEOS.HeigtRef = "Ellipsoid"; % Geoid, Ellipsoid, MeanSeaLevel
AEOS.Name = "Advanced Electro-Optical System";
.... etc ....
Now say the Shuttle has been created as a space object.
Create Spacecraft Shuttle
Shuttle.X = 1234.5;
Shuttle.Y = blah;
Shuttle.Z = foo;
.... etc ...
If one wanted to compute various items of interest such as whether or not the Shuttle was currently in view of AEOS and if so what is the RA and Dec of the Shuttle, then I would imagine something like this:
AEOS.RADEC(Shuttle,DesiredTime);
which would output a single RADEC angle pair or
AEOS.RADEC(Shuttle,ArrayOfTimes);
which would output an array of RADEC angle pairs that could be plotted.
The RADEC capability would be a measurment model asssociated with the EO Ground Station class as would AZEL or whatever other output parameters one might desire. Now, for example, if one were to create an SLRGroundStation and try to call the RADEC measurement model, I would expect to get an error since SLR stations provide Two-way Time-of-Flight and Range.
Create SLRGroundStation Greenbelt
Greenbelt.Latitude = 39.0056; %deg
Greenbelt.Longitude =-76.6610; % deg
Greenbelt.Elevation = 0.019195; % km
Greenbelt.Range(Shuttle,ObTime); % Ok
Greenbelt.AZEL(Shuttle,Obtime); % Error!