* Return to HOME * Later tools
*
I wanted to database the airport and navigation aids given in MS Flight Simulator scenery files, circa 95, and what an adventure it turned out to be...
As I flew around in the simulator, I got very interested in navigation aids, airports and runways. My section on virtual travel has some snapshots of flying into various airports, sometimes exactly on the ILS glide slope and line. I love flying. I began a database of these objects, using the extension, * .DFS, to sort of = data flight simulation.
Each record represented an airport, runway or navigation aid 'object' found in a MS bgl scenery files, and much of the 'record' structure 'emulated' the multiple bgl forms, because I was always weary of just keeping the calculated values, and wanted to try to store the exactly 'information' per the source. So I could 'convert' it later ...
Over the top of this database I built a quite rough display engine, that 'displayed' the records from my database. By using some freely available tools at the time, you could build a bgl file just giving some command line parameters, so my database began to contain multiple 'types' of records, from 'any' source.
Some initial 'views' of the data yielded a quite minimal object set -
// Record types - First not really
// Also OFFSETS into some GDI Paint items
// ======================================
#define fsd_Unk 0 // not a 'type', really!
#define fsd_Air 1 // Airport
#define fsd_Rwy 2 // Runway
#define fsd_Vor 3 // VOR
#define fsd_Ils 4 // ILS
#define fsd_Ndb 5 // NDB
// Added Dec 1997
#define fsd_Atis 6 // ATIS
// FIX980407 - Add Land-Me and Markers
#define fsd_LMe 7 // LandMe (ie an Airport!)
#define fsd_IMO 8 // Markers (Inner,Middle,Outer)
#define fsd_Building 9 // building from BGL file - 20020714
#define fsd_Poly 10 // polygon
#define fsd_Line 11 // lines
#define fsd_Max 16 // MAXIMUM (for now)
That is still the list of interest. :-)
I found FlightGear, which also has some databases, copyright © 2001, Robin A. Peel (email), and I read in these and converted each to my own DFS (ugly) record type, and displayed them alongside the records from bgl file(s), or additional sources, from my own, now developing, database, in this case Europe.dfs.. It makes for quite a busy, unreadble!, display - eg
I am not particularly 'proud' of the rustic display, and its orientation EW/NS may be wrong, and the user interface really sucks, but it allowed me to compare, say an ILS of MSFS with that of FlightGear. This comparison proved very difficult some times, not with standing the possible incorrect orientation shown.
Was the runway heading wrong? Or incorrectly converted from MSFS co-ordinates? Or an error calculating the exact pixel location, first on a quasi world map, and then offset onto the current screen, according to the current scroll position? What x-y scew/distortion used? No adjustment of 'degrees=length' at elevated latitudes? All I can say, all the errors were consistently applied to records in my database ...
In the above display, an ILS: comes from one dataset, while an ils: comes from the other. Of course these text stream overlaying each other on the screen were all 'printed' to a file, thus I could more carefully compare the 'calculated', in all its senses, position (lat/lon) of an item. fsfilvw1.htm is the output matching the above display.
This is a load of my Europe.dfs database, quite dated, containing - and some of the debug text output is -
Auto: Attempt to LOAD [D:\GTools\Tools\BglView2\DFS\Europe.dfs] DFS
DFSCnt: Air = 262, Nav = 2489, Visible = 0. Total = 2751. (0?)
Then, after loading and searching the Robin A. Peel data that comes with the FlightGear base data set -
List of FGFS Nav objects within 0.2 degs of COS(48.7300002222,2.3866724722).
6, ILS, 48.741879,2.389964, 18,LFPO,110.30,OLN
and so, on, on, and on. But I am 'fascinated' by such reams of 'factual' information that should 'exactly' agree. Each these is a man made object, and its exact position could be determined, and checked.
This is just about exactly the database I was trying to create all those years back. :-)) Yowee, it arrives (ils arriver?). It comes in several forms, and is updated regularly. It is a vast store of information and I wanted to 'see' what it contained. Some how to 'visually' paint the object contained ...
At first I thought of using "FS File Viewer (BglView2)", but it has 'my' record form, and I did not want to 'convert' the DAFIFT to my 'form'.
So I started another 'viewer', just called it fgsd, standing for "FlightGear Show Data". While working earlier with the FlightGear default files I had developed my own set of 'structure' to handle 'object', so I imported big chunks from "FS File Viewer", and thus had a head start on my new viewer, fgsd.
Since working in WIN32 environment, I chose that the DAFIFT data files would be memory mapped, and when a search was required, that raw data would again be the base of the search. But I had also created other linked listed of allocated structure to hold some of the info. converted on a line by line basis.
Contrast the above "FS File Viewer" 'image' with that of fgsd, showing approximately the same information -
Due to normal JPEG pixelation, colour becomes hard to read, so here is the larger PNG file -
Now I am getting to 'like' my 'mappy' type view :-))
It has a command line to enter the root directory of the un-zip of DAFIFT.zip, and the de-tar of the FlightGear 'default' apt,ils,nav files, and the first ICAO to search for first. Here is my command line that produced the above. The scale is simply pixel per nautical mile, applied in both directions, thus with some errors -
<runtime>\fgsd -daf="D:\FG\dafift" -fg=d:\fg\sd -ICAO=LFPO -scale=150.0, and then changing the scale to 50.0 pixels per nm, then [ Re-Display ].
Like the earlier FS viewer, it output some text as it runs to a file - TEMPFGSD.TXT, and fgsd-01.htm is a link to that. First it shows the size of the data files loaded, well in this case memory mapped. WIN32 has returned a pointer to the data -
DBG:Got Map of [D:\FG\dafift\ARPT/ARPT.TXT] file, 1221169 bytes.
DBG:Got Map of [D:\FG\dafift\ARPT/RWY.TXT] file, 3110447 bytes.
DBG:Got Map of [D:\FG\dafift\NAV/NAV.TXT] file, 1574327 bytes.
DBG:Got Map of [d:\fg\sd\default.nav] file, 692808 bytes.
DBG:Got Map of [d:\fg\sd\default.ils] file, 420873 bytes.
DBG:Got Map of [d:\fg\sd\default.apt] file, 3872349 bytes.
Then some 'counting' of the 'loaded' file -
DBG:File D:\FG\dafift\ARPT/ARPT.TXT has 22 cols (38 mx.), 9896 lines/items.
DBG:File D:\FG\dafift\ARPT/RWY.TXT has 50 cols (12 mx.), 13782 lines/items.
DBG:File D:\FG\dafift\NAV/NAV.TXT has 31 cols (30 mx.), 11193 lines/items.
WARNING: Discarded OOW record
N 175.330833 -037.860556 0 390.00 50 N HN XXX Hamilton NDB
DBG:WARNING: Got 9974 FGFS Navs, D=101, N=6677, V=3196 (0?) *** 1 FAILED! ***
DBG:Collected 2238 FGFS Ils objects. (823584 memory!)
DBG:Summary: Of 2238 FGFS Ils objects, L=237, I=1949, M=3, S=26, D=23 (0)
DBG:FGFS: Airports 17455, Runways 21424, Sea 368, Helo 14.
Here you can see a decent load of items. 9,896 DAFIFT Airports, 17,455 FG/Peel Airports, 13,782 DAFIFT runways, 21,424 FG/Peel runways and taxiways, 11,193 DAFIFT navaids, 9,974 FG/Peel navaids. There has been some checking done during this database 'counting', and oodles more memory consumed to create double linked lists of certain items.
One interesting item shown is the rejection of a FG/Peel NDB because it is OOW - Out of World - range. You can see it is placed at 175 degrees North - a little north of the north pole :-)
But if you want to 'compare' the two, then here is a better view, at 150 ppnm., with the debug text also shown.
DAFIFT data shows 3 runways, FG/Peel shows 5 - But how do they really compare. The view shows the DAFIFT in green and FG/Peel in blue. You can see most have the same orientation, and approximate length, so, in fact, they compare well - just some small adjustments.
It further shows FG/Peel has a 'duplicate' of LFPO ILS OLN 110.30 on O2 in one case, and on 02L in the other. Luckily, when flying into this area, such signals would have an exact source, and this type of database 'differences' only effect simulated views, like the above is. But what fun I had doing it.
I could now use it to review each successive update of either database. In fact I understand that the FG/Peel data is in fact 'extracted' from DAFIF data, so eventually these two data sets should come together, and completely agree over time.
To follow the fgsd trail - - A 'night' view of San Francisco Intl. (KSFO) - as this page peters out soon.
More on fgsd -
There are many 'systems' to hold a 'view' of the world, but tied into the above 'view-of-data-set-items' is trying to 'paint' a realistic view of the earth in the view rectangle. I worked hard with my DibView viewer to be able to load and display some very large GEOTIFF tiled image files.
One contained a patched together 'satellite' of a large part of Europe, and I tried to be able to load this data, reach in an extract the appropriate portion, and paint that as the background to either of the above displays.
I had some very good success, but found the PC I was using just did not have the horse power to run massive pixel moves, many times per second to give smooth scrolling ... so it was shelved until we have to oomph :-))
* Back to Previous * Back to Projects * Back to Home * Later tools
Another image -