As stated, this is exploration 'work-in-progress' ... stay tuned, but DO NOT hold your breath :-))

Back to Page 1.

The image is getting 'busy'. I have added a colour key, so I know what is what, but the multiple overlaying of the text just creates a blur - non-readable. For the precise clear number one must view the LOG output text.

And nearer home, Orley, it becomes a 'mess' more than blurred!

Here the FG data set has not yet been synched up to the DAFIFT/Peel/X-Plane data set.

With this particularly simple Red, Green, Blue (RGB) I had the 'wild' idea that if I could really simplify the painting on a source basis, and animate the display cycling through showing the background grid with first just DAFIFT information, then FG, then Peel, and cycle fast enough, then where they fully agreed I should get WHITE, or at least GRAYISH.

Some of this 'combination' of colours can already be seen in both the above. Because of the close proximity of the DAFIFT and Peel/X-Plane data the edges on the runways look 'purple' - i.e. DAF R 'blue' plus Peel R 'red'. But you might ask, if the data represents a solid, almost immovable objects, plate tectonics aside, why are they 'different' at all.

For me some, or all of the answer lies in the 'maths'. On runways specifically, DAFIF gives the world coordinate of both center ends of the runway, while both Peel, and FG give the center - center, or geographic center of the runway. At certain scales on particular runways it is possible to see the DAFIFT 'blue' runways does not exactly surround the center line drawn. That is to say the final calculation of the two center ends to pixel locations, and the calculation using the heading and length to build a rectangle, and converting that set of coordinates to pixel locations do not agree.

There is some very interesting math involved in say converting two positions (lat/lon/alt) to a distance and heading, even ignoring any altitude difference, or conversely getting a destination position from a given position, on a particular heading (true), for a specific distance.

When I first started my FS File Viewer, I grubbed it. I assumed a 'flat' world, stretching out from the equator, and made everything relative to a desired 'scale' number. Naturally as the latitude increased, or decreased, the 'distortion' became pronounced, but since I 'painted' everything with the same 'grey' math, some of the comparisons were valid.

When I eventually came across FlightGear, its source contained two 'beautiful' math babies, named geo_inverse_wgs_84 and geo_direct_wgs_84, and in their own words -

// given alt, lat1, lon1, lat2, lon2, calculate starting and ending

// az1, az2 and distance (s). Lat, lon, and azimuth are in degrees.

// distance in meters, and

// given, alt, lat1, lon1, az1 and distance (s), calculate lat2, lon2

// and az2. Lat, lon, and azimuth are in degrees. distance in meters

These allowed me to at least initially 'check' my 'grubby' FS File Viewer's math, and in the new fgsd, are the basis for ALL such calculations. Through Robin's site, I found another 'fascinating' set of equations, at URL Williams DOT best DOT vwh DOT net SLASH avform DOT htm, or Aviation Formulary, but I have not used these yet. Of course these, and other 'simple' formula mainly calculate the rhumb line, since mostly a true heading changes as you fly a great circle on our oblate spheroid, as you can read lots about in the above, all of which adds to the 'problem' of rendering our real world in a pixel world.

To read more on the precursor to fgsd, go Flight Simulator File Viewer