World Imaging

As perhaps previously mentioned, my interest in digital databases started with a flight simulator application. It was fantastic to 'virtually' move like a bird, and fly over just about any part of the earth. For fun, I did some round the world trips ;-))

FlightGear, my favourite, for many reasons, flight sim has continued to improve. The great thing I like about it, is its view of the land, and airports is derived from mostly public data. Following the README in the TerraGear source, it starts with global DEM data. Try these links -
1. ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/SRTM30/ - 27 folders, like e100s10, e140s10, ...
2. http://www.ngdc.noaa.gov/seg/topo/globe.shtml - a 30-arcsec world wide data, GLOBE project.
3. http://edcwww.cr.usgs.gov/landdaac/gtopo30/gtopo30.html - GTOPO30 data.
4. or others ? ...

To break these data blocks into 1 x 1 degree 'squares', TerraGear has command line tools to convert this 'binary' DEM format, to an 'ascii' DEM format. The tool is -
"Prep/DemRaw2ascii/raw2ascii"

For example, I had ftp transferred the e100s10 folder from above link 1, and unzipped the e100s10/e100s10.DEM (56MB), and the e100s10.HDR, from their respective ZIP file, then running raw2ascii produced some 2,000 1x1 degree 'ascii' DEM files, ready for the next step of building the world scenery.

The next README job was to dissect each of the 2000 1x1 'ascii' DEM files, into 'buckets', 'leafs', 'nodes', using the TerraGear command line tool, demchop. Running this tool iterative over the 2000 DEM files produce about 20,000 .ARR file - WOW! This is fun ;-))

During the running of this demchop tool, I noted that no .ARR files was written, if the 'bucket' was all zeros! So I went back to raw2ascii, and added the code to avoid writing a DEM file, if the entire 1x1 block was all zero. Of course, this will not reduce the .ARR file count, but reduced the iterations in this particular folder to about 250 'ascii' DEM files ...

The next step, to 'convert' these ARR files to FIT files, was a combination of a perl script, to output two intermediate files, PGM and OBJ, and then running an 'array' application. Well since I do not have a 'perl' interpreter on this machine, I did the next best thing - converted the perl to C++ !!!

Some of the perl string manipulation took some time finding the C++ code to be near equivalent. Some particularly simple to write in perl actions cost quite a number of C++ lines, but it all appears to work. Of course I just linked in the objects of the 'array' app, and did an internal call ... and was rewarded with my first FIT output.

The perl also handles command line parameters very well, and at present my FIT incarnation only runs with the default parameters, those in the perl script, and it does not yet iterate through a folder, like the perl did, but this is just some additions, if needed ... but if I pour more effort into here it would be to internally pass values, in structures, classes, rather than using the disk file interface.

It must be remembered, even with just one global block downloaded, and partially processed, there are over 20,000 ARR files to 'massage' into FIT files, so anything that speeds up the process can not be bad ...

So far this process would produce a global surface map. Airports are special places on this map, so they are derived from another dataset, maintained by Robin Peel, - http://www.x-plane.org/users/robinp/ - As the URL implies, this data is also used by the X-Plane product. As usual, the acquisition of the data was easy, but the next steps described in the README caused me to take another breath ...

It says - Robin's apt.dat needs to be run through two scripts -
cat apt.dat | ./xp2simpleapt.pl > basic.dat and cat apt.dat | ./xp2runway.pl > runways.dat
Yeek, some more perl. But I have had some 'experience' loading data, so I again decide to render the perl into C++ ... I make extensive use of one of the SimGear tools - $F = simgear::strutils::split( line ); - to split the file line into a vector<string> array ... works great ...

But not content with just reading the X-Plane (Robin Peel), and out putting FlightGear data files, [$FG_SCENERY/]Airports/basic.dat[.gz] and runways.dat[.gz], I decided I want to COMPARE the new XP data with the old FG data, to see if I could spot the difference ...

Wow, that took a bit. Here is some of the log file output ...
Commencing COMPARE of 17750 XP airports with 22975 FG airports.
Then a display of the first 'difference' -
Changed lat 38.871864 vs 33.185833 diff= 5.686031
Changed lon -102.884747 vs -84.368056 diff= 18.516691
A 96GA 38.871864 -102.884747 890 CNY 3MS
A 96GA 33.185833 -84.368056 890 CNN 3MS

Double wow, that is a big change, isn't it? But the X-Plane data is derived from DAFIF, so I decide I must load, and check the public DAFIFT database. Ok, that added some information, and should help in the decision tree, but it still presents a lot of reviewing. Here is the header information, and the first few lines of the airport 'compare' from the disk log file - tempprt.txt

Here we can see the first two 'different' airports, 96GA, and EKYT. The first line is from the XP data stream; the second line from the FG data stream, and the third, if present is the airport from the DAF data ...

The XP 96GA appears to be some 1,780 km from the current FG airport. Yow, do I have enough gas, if I head to the wrong place, to get back to the right ;-(( There seems no DAF record, so which is correct, is just a guess ...

The XP EKYT has only moved some 245 km ;-)) But there is a DAF record, that is only 428 m away ... which is correct? XP, FG, DAF? Of course, at this point one should understand that the position of the XP airport is CALCULATED as the average of all the runways. It is assumed that the FG position was calculated in the same way using, perhaps using an earlier database, and not sure how the DAF airport position is derived ... Does anyone know were I could read, find that information?

But it is the final statistics that are also interesting. First there appears some 48 new airports in the XP data, but there are some 6680 that need some checking. These I have output these to -

new=48 chg_lat=6541 chg_lon=6546 chg_elev=107 cd=16044 chg_name=78 dif_tot=6686
Of the 17750 XP AP processed, 11064 are to the same, 48 new
Now to 48 new, and then 6638 changed ... ok, well ...
Writing - C:/FG/FlightGear/data/Airports/aptnew.dat
Writing - C:/FG/FlightGear/data/Airports/aptchg.dat

It should be NOTED that some 11,064 'compare' as the SAME ;-)) I can only hope this VALIDATES the coding. Presently it seems the XP-to-FG translation is via some very slick perl script - see Airport/Utils/xp2runway.pl and xp2simpleapt.pl - and not having, or wanting, to install a perl interpreter I translated this to C/C++ code. There does seem an error in my 'interpretation' of the FG code "C"+"Y|N"+"Y|N", since most XP airports seem to have a changed code (cd=16,044).

How can I -
(a) reduce to difference count? Perhaps accept up to less than 1 km relocation?
(b) decide which record is closer to the physical facts? Maybe accept the closest, XP or DAF, where DAF exist?

Still lots to do, so can not get 'stuck' here. I want to move onto airport generation. This process should produce a polygon representing each airport and runways, so a hole can be cut in the world elevation scenery just generated above ...

Started by adding the source of genairports to this application, but on the first compile attempt saw the need for nurbs++ headers, and library, libraries ... from REDAME.nurbs++, went to -
 http://libnurbs.sourceforge.net/ , download the zip source of 3.0.10, settled it into a folder, and searched for a *.dsw, and *.dsp files ... found some strange ones, that did not function as expected ;-((, so set about 'constructing' my own ... sometimes I follow what is sort of described in the unix makefile.am, which is like an nmake file, with some additional rules ...

But came unstuck when matrix/matrix_global.h could NOT find file 'cmath'. What can be the matter? One of the Visual Studio paths points to where it sits! If I try commenting it out, then the same happens with the iostream file, the next entry, so something more is happening ...

... to be continued ... meantime, back to some flying. Want to install some of the australian scenery I have downloaded, and fly around a bit ... first get the ICAO of Kingsford Smith ...

This lead me back to 'viewing' the airport, and runway databases again. After looking at the DAF data, I noted the id string is either an ICAO sign for the airport, but sometimes it just had the two-letter Airline Code. In each of these cases, it seemed the 'identity' was sorted out by the airport having an FCC_HOST_ID that was not "N" ... This appeared to be the Airline Code plus a number.

Hmmm, what does the FG database do about this? Zeeks! It uses "ZZ". Since the FG airport record is being stored in a map, based on this id, then many records were being over-written during the load. But I wanted a mapped list of all airports, so my first effort was to 'sift' the current FG records, and generate a load, with each airport under a unique id.

The log file output, showing which records were discarded, some because they were true duplicates, some were used as an update of the currently mapped version. A few were given a generated id, so they would be 'unique', and this file shows the output information ... These 2 lines sum up the operation -
Loaded 22788 FG Airports from [C:/FG/FlightGear/data/Airports/basic.dat.gz]
Add=22975, disc=187, dupe=44, uped=143, res=22788, maps=22788

So now I had 22,788 airports loaded, each mapped to a unique id. The problem is that the output contains lines like -
A SB100 -23.923789 -55.301856 686 CNN Fazenda Jatoba
A SB101 -15.000000 -55.825000 1020 CNN Fazenda Jopejo
That's right. There are more than 100 airports with the airline code of "SB" ;-((

This quickly proved unmanageable. The search using the id, which should just be -
   return *map_by_id[id];
now gets much more complicated. If in one database loaded, this "SB" record was loaded, as say the 5 th found, and added, then its id would be "SB05", but in a second database, there is no guarantee that this "SB" record will exactly appear in that order ... yuck! Abandon this track ...

Maybe a map-by-id is not really required. Or, once a database is loaded, the decodes done, a map of what is 'available' by map is created. Maybe what is returned from the search(id) algorithm is always a vector of airports, its size() being zero if no finds? Thus if the search is for "SB", then all -
A SB252 -10.834056 -42.683369 1384 CNN Xique Xique
252 unique ids 'created' using the Airline Code ... No, that doesn't sound good ...

The "Kingsford Smith" ICAO id is "YSSY", so now I can load, and run FG, setting the start-up airport, I think ...

Keeping the 'exact' input id, re-worked the load logic to generate a 'unique' id for each airport, and mapping them by this 'unique' id, uid, produced the following summery-
Loaded 22834 FG Airports from [C:/FG/FlightGear/data/Airports/basic.dat.gz]
Add=22975, disc=141, dupe=30, uped=111, res=22834, maps=22834
Written to C:/FG/TerraGear/tempfg/basic2.dat file.

Compare that result to the previous -
Add=22975, disc=187, dupe=44, uped=143, res=22788, maps=22788
shows the new code loads, maps 22,834, discarded less, seems better ... ;-))

But in trying to do a load of the new, found that one-too-many lines were being 'added', so after another small adjustment of the code, got -
Loaded 22833 FG Airports from [C:/FG/FlightGear/data/Airports/basic.dat.gz]
Add=22975, disc=141, dupe=30, uped=111, res=22834, maps=22833 (i=1)
Written to C:/FG/TerraGear/tempfg/basic2.dat file

But this produced an Airline code list that included things like -
E4 6
1T 7
which are NOT Airline codes! So another code adjustment to reject any current FG id, which contained a number in position 1 or 2 ... This produced the changed summary -
Add=22975, disc=185, dupe=44, uped=139, res=22790, maps=22789 (i=1)
which increased the exact duplicates and later, assumed updated records to 44 and 139 respectively, which reduced the map total, correctly, I hope, but 2 records were DISCARDED.

As it turns out, these are both 3 digit/letter ids. -

N CD10  37.675003 -106.556152  8100 CNN Chapman Field *NEAREST*
? C24   37.820833 -106.931110  8680 CNN Mineral County Memorial *CHECK ME DISCARDED*
A C24   41.733364  -88.000061   755 CNN Brookeridge Air Park  latd=3.912531 lond=18.931049 km=1675.14 alt=7925 CHANGED NAME?

and

N MLL   61.865923 -162.069046    90 CNN Marshall *NEAREST*
? 3A5   61.864178 -162.026110   103 CNN Marshall Don Hunter Sr *CHECK ME DISCARDED*
A 3A5   34.274023  -81.773444   570 CNN Connelly Fld  latd=27.590155 lond=80.252666 km=6214.29 alt=467 CHANGED NAME?

I decide to convert the second of each of these, adding an "_", thus inserting it at 'unique', thus not discarding these two records ... see all ... or just the summary :-

Loaded 22791 FG Airports from [C:/FG/FlightGear/data/Airports/basic.dat.gz] in 2:12.52 m:s
Add=22975, disc=184, dupe=44, uped=139, res=22791, maps=22791
Written to C:/FG/TerraGear/tempfg/basic4.dat file.

I though of posting a query on the board, but it gets so complex to explain what you have done, found, need ...

Wednesday, 17 November 2004. Hi All,

RE: updated airport, runways, components listing - scenery generation

I have been working through the TerraGear libraries and tools, per the README, using MS VC6 - like Lib_Dem, raw2ascii, demchop, terrafit, ... which included writing some C++ code to 'duplicate' the perl scripts ... to genapts - and reached two road blocks, and hope someone can help ...

(a) can not get nurbs++ to compile in VC6, so blocked in compiling the 'array' tool used in genapts ... have read some things about this here recently ... maybe someone has a VC6 compile ... perhaps just need time to push on this ... but the more important road block is ... (b) can not generate an updated basic.dat and runways.dat ... of course, for fun, have written C++ code to do what xp2simpleapt.pl and xp2runway.pl do ... but there comes a problem of deciding which data is correct!

Some of my log output show what I found in the downloaded XP data - Loading file [C:/DTEMP/FG/Resources/Earth Nav Data/apt.dat], 9981866 bytes, 24/12/2003 13:28 Found 154451 lines. Got AP=17750 (A=17750) Rwys=22370 Txw=95199 B=0 W=0 From X-Plane file [C:/DTEMP/FG/Resources/Earth Nav Data/apt.dat] Loaded 17750 XP2FG Airports ... Loaded 118216 XP2FG Runways and components ...

As per xp2simpleapt, each airport is positioned as the average of all the runway centres. In my code I retain the apt.dat load, in memory, as FGAirport and FGRunway blocks, so I can load, and compare the XP data to the current FG data ($FG_ROOT/Airports/basic.dat.gz, and later the runways ...

As an extra comparison, have downloaded, and also load ... Loading file [C:/FG/Dafift/ARPT/ARPT.TXT], 1240317 bytes, 08/10/2004 16:52 ARPT_IDENT NAME STATE_PROV ICAO FAA_HOST_ID LOC_HDATUM WGS_DATUM ... CYCLE_DATE WARNING: U ZSHC 30.228333 120.431667 23 CYY XIAOSHAN : updated existing! Processed 9992 DAFIFT APT lines. Found 4 DAFIF types [ADCB]. Counts: Total=9992 A=2981 D=5760 C=771 B=480

So now I am ready to do - Commencing COMPARE of 17750 XP airports with 22791 FG airports. Database LOAD after Running for 7:27.11 m:s

Bah, how can anyone help with this ??? I have done so much behind the scene that it would take ages to explain, what has been tried, what does not work, what appears ok, etc, etc ... The log output lists only help explain ...

Work it out!

This first new entry 'looks' bad ;-(( ICAO=CA01 Adin X CA01 21.983846 -48.578502 4229 CNY Adin - *New XP2FG record* A CA54 37.670485 -121.327719 81 CNN 33 Strip - FG nearest at KM=7070.69 *CHK* D TAPA 17.136750 -61.792667 62 CYY V C BIRD INTL - DAF nearest at KM=1485.97 *CHK*

Yup, I used the id CA01 to find in my mangled uid's ;-(( Fixed code - first looks better, no? Nothing is found 'nearby', so can only accept the NEW record, with great thanks. ICAO=CA01 Adin X CA01 21.983846 -48.578502 4229 CNY Adin - *New XP2FG record* A COCO 17.551661 -61.768333 13 CYN Cocoa Point - FG nearest at KM=1466.01 *CHK* D TAPA 17.136750 -61.792667 62 CYY V C BIRD INTL - DAF nearest at KM=1485.97 *CHK*

The stats show it all again - new=635 chg_lat=6101 chg_lon=6105 chg_elev=381 cd=15458 chg_name=363 dif_tot=432 Of the 17750 XP AP processed, 17318 are to the same, 635 new Now to 635 new, 432 changed, and 5776 to check ... ok, well ... Writing 635 - C:/FG/FlightGear/data/Airports/aptnew.dat Writing 432 - C:/FG/FlightGear/data/Airports/aptchg.dat Writing 5776 - C:/FG/TerraGear/tempfg/checkme.dat Writing 10907 - C:/FG/TerraGear/tempfg/skipped.dat Done ... Note: 864 of 10691 icao listing NOT touched!

That is a FANTASTIC set of 635 airports. Some are in the icao liat I have, some are in DAF data, as a comparison. Great additions ... like - ICAO=IL06 Amboy-Albrecht X IL06 42.018862 -101.475190 794 CNY Albrecht - *New XP2FG record* A 1V2 42.010582 -101.769388 3710 CNN Grant Co - FG nearest at KM=24.39 *CHK* D K1V2 42.009431 -101.769344 3710 CYY GRANT CO - DAF nearest at KM=24.39 *CHK*

X FAZZ 7.945168 -46.874181 2600 CNY Alldays - *New XP2FG record* A SOCA 4.819807 -52.360446 26 CYN Rochambeau - FG nearest at KM=698.41 *CHK* D SOCA 4.819808 -52.360447 26 CYY ROCHAMBEAU - DAF nearest at KM=698.41 *CHK*

X NC74 43.547714 -47.900145 400 CNY Allens - *New XP2FG record* A CYYT 47.620309 -52.745855 461 CYN St Johns Intl - FG nearest at KM=589.58 *CHK* D CYYT 47.618611 -52.751944 461 CYY ST JOHNS INTL - DAF nearest at KM=589.74 *CHK*

X UOOO 67.478457 54.195149 574 CYY Alykel - *New XP2FG record* A UUYY 61.647049 50.845050 324 CYN Syktyvkar - FG nearest at KM=669.42 *CHK* D UUYY 61.647050 50.845050 324 CYY SYKTYVKAR - DAF nearest at KM=669.42 *CHK*

X SCZZ -34.295206 51.837667 1420 CNY Auco - *New XP2FG record* A FMSD -25.039277 46.956382 29 CNN Tolagnaro - FG nearest at KM=1129.15 *CHK* D FMSD -25.038056 46.956111 29 CYY TOLAGNARO - DAF nearest at KM=1129.29 *CHK* ICAO=CA69 Avenal X CA69 7.618179 -56.714362 790 CNY Avenal - *New XP2FG record* A SYCJ 6.498875 -58.254551 95 CYN Cheddi Jagan Intl - FG nearest at KM=210.42 *CHK* D SYCJ 6.498553 -58.254119 95 CYY CHEDDI JAGAN INTL - DAF nearest at KM=210.40 *CHK*

X TN51 35.452192 -55.922900 545 CNY Aydelotte - *New XP2FG record* A LFVP 46.762663 -56.175529 27 CYN St Pierre - FG nearest at KM=1256.28 *CHK* D LFVP 46.762664 -56.175531 27 CYY ST PIERRE - DAF nearest at KM=1256.28 *CHK* ICAO=MN84 Oklee-Bachand X MN84 -9.217330 64.317305 1100 CNY Bachand - *New XP2FG record* A FJDG -7.313268 72.411090 9 CYN Diego Garcia Nsf - FG nearest at KM=916.17 *CHK* D FJDG -7.313267 72.411089 9 CYY DIEGO GARCIA NSF - DAF nearest at KM=916.17 *CHK*

X WIZZ -1.025996 48.464381 1200 CNY Bandingagung - *New XP2FG record* A HCMK -0.377351 42.459232 49 CNN Kisimayu - FG nearest at KM=672.27 *CHK* D HCMK -0.377353 42.459233 49 CYY KISIMAYU - DAF nearest at KM=672.27 *CHK*

X VAZZ 28.756743 -21.269444 700 CNY Banswara - *New XP2FG record* A GCLA 28.626477 -17.755613 107 CYY La Palma - FG nearest at KM=343.69 *CHK* D GCLA 28.626478 -17.755611 107 CYY LA PALMA - DAF nearest at KM=343.69 *CHK* ICAO=SD98 Enning-Barber X SD98 36.356075 -40.724046 2655 CNY Barber - *New XP2FG record* A LPFL 39.455336 -31.131396 112 CYN Flores - FG nearest at KM=910.45 *CHK* D LPFL 39.455272 -31.131361 112 CYY FLORES - DAF nearest at KM=910.45 *CHK* ICAO=PS69 Flinton-Barnhart X PS69 41.382129 -83.966176 1640 CNY Barnhart - *New XP2FG record* A OH02 41.294495 -83.954665 694 CNN Eickmeier - FG nearest at KM=9.78 D K7W5 41.374278 -84.067917 683 CYY HENRY CO - DAF nearest at KM=8.56

I love new airports ;-))

Then turn to the CHANGED, noting that some 10,000 of the original XP 17,000 are un-moved. I have discarded some of the 15,000 changed codes, like an XP "CNY" replacing a FG "CNN", etc, for the moment ... until I get to grips with the next bunch ... the CHANGED records!

Here, the XP record is going to be used to update the current FG record, but we should look at some of the comparative changes first ... the first few look great - ICAO=KLIT Little Rock-Adams Field X KLIT 34.729415 -92.225482 262 CYN Adams Fld - *USE XP UPDATE?* A KLIT 34.729415 -92.225482 262 CYN Little Rock Adams Field - CHANGED NAME? upd D KLIT 34.729444 -92.224306 262 CYY ADAMS FLD - latd=0.000029 lond=0.001176 m=107.75 *code* ICAO=79TX Brownsville-Ag-Air Inc X 79TX 26.073056 -97.537500 30 CNY Ag Air Inc - *USE XP UPDATE?* A 79TX 26.073134 -97.537486 30 CNN Ag Air Inc - latd=0.000078 lond=0.000014 m=8.75 *code* upd D 79TX 26.073133 -97.537486 30 CYY AG AIR INC - latd=0.000077 lond=0.000014 m=8.65 *code*

Just quickly scanning down the list - X KAYX 35.392577 -86.085818 1067 CNY Arnold AFB - *USE XP UPDATE?* A KZZZ 35.392577 -86.085818 1065 CNN Arnold AFB - *id* KAYX vs KZZZ alt=2 *code* upd D KAYX 35.392578 -86.085822 1065 CYY ARNOLD AFB - lond=0.000004 m=0.38 alt=2 *code* look interesting. A FG "KZZZ" id is being updated to "KAYX". which is 'confirmed' by DAF data ...

But if XP data is based on DAF, then sets of compares like the following make you wonder ... X SDRR -23.092790 -48.985768 2654 CYY Avare-Arandu - *USE XP UPDATE?* A SDRR -23.093056 -48.984165 2654 CYN Avare-Arandu - latd=0.000266 lond=0.001603 m=166.86 *code* upd D SDRR -23.092522 -48.987378 2657 CYY AVARE ARANDU - CHANGED NAME? latd=0.000268 lond=0.001610 m=167.59 alt=3

X ORBD 33.943958 44.366139 161 CYY Balad Southeast - *USE XP UPDATE?* A ORBD 33.943958 44.366150 161 CYN Balad Southeast - lond=0.000011 m=1.02 *code* upd D ORBD 33.940194 44.361583 161 CYY BALAD SOUTHEAST - latd=0.003764 lond=0.004556 m=593.06

X WRBB -3.442048 114.760789 66 CYN Banjarmasin Syamsudin Noor - *USE XP UPDATE?* A WRBB -3.442354 114.762553 66 CYN Banjarmasin Syamsudin Noor - latd=0.000306 lond=0.001764 m=198.91 upd D WAOO -3.442356 114.762553 66 CYY SYAMSUDIN NOOR - CHANGED NAME? *id* WRBB vs WAOO latd=0.000308 lond=0.001764 m=198.95 *code*

X EGYE 52.960999 -0.561667 367 CYY Barkston Heath - *USE XP UPDATE?* A EGYE 52.961189 -0.559746 367 CYN Barkston Heath - latd=0.000190 lond=0.001922 m=130.85 *code* upd D EGYE 52.962225 -0.561625 367 CYY BARKSTON HEATH - latd=0.001226 lond=0.000042 m=136.52

X SBTA -23.040134 -45.516010 1923 CYY Base De Aviacao De Taubate - *USE XP UPDATE?* A SBTA -23.040134 -45.516010 1908 CYN Base De Aviacao De Taubate - alt=15 *code* upd D SBTA -23.040133 -45.516011 1908 CYY BASE DE AVIACAO DE TAUBATE - alt=15 ICAO=1U7 Paris-Bear Lake County X 1U7 42.243334 -111.327361 5928 CNY Bear Lake Co - *USE XP UPDATE?* A 1U7 42.245569 -111.336696 5928 CNN Bear Lake Co - latd=0.002235 lond=0.009335 m=809.46 *code* upd D K1U7 42.247150 -111.338261 5928 CYY BEAR LAKE CO - *id* 1U7 vs K1U7 latd=0.003816 lond=0.010900 m=994.46 *code*

Of, course, I have no real idea how the DAF airport location is 'derived', 'calculated' or 'stated', thus must accepts each of these updates on a good faith basis. You can see in each of these the FG location 'agrees' with the DAF location, while the new XP data moves everything a few hundred meters ...

EOF - end of posting attempt ...

But then a new light shone ;=)) Try -
http://www.nottingham.ac.uk/~eazdluf/taxidraw.html
This is at least part of my World View ... and airport taxiway view ...

I ran into some 'interesting' things in compiling the wxWidgets
libraries, and linking them with TaxiDraw ... I came across a
LINK error - namely -

Build ERROR:

Linking...
shell32.lib(shguid.obj) : fatal error LNK1103: debugging information corrupt; recompile module
Error executing link.exe.

Work around: Use the make file, TaxiDraw.mak to perform the last, link, process ???
Beats me why the console use of the linker should be different to that run
within the Microsoft Studio 6 (+SP) environment ... very strange ... anyway ...

What a beautiful tool David Luff has made ... Thank you David. I have some idea of the effort, time, dedication, to get this far into graphically viewing our world, all from digital databases ... Yabba, dabba, doo, someone once said ;=))

This pushed me to go back to another FlightGear related tool, fgsd - http://fgsd.sourceforge.net - and try another compile ... I had tried over a year ago, but failed that time ... There you can find the list to download ... but if you have compiled FlightGear then you will already have OpenGL , (or Mesa - not tried), PLIB , SimGear , zlib .

Now fgsd adds FLTK 1.1.x , FLU , GTS 0.7.2 and some of the glib suite, glib, libiconv, libjpeg, etc. ...

This last glib, and related, was the most difficult. Well, perhaps only because I chose to try against the grain, as it were. I wanted a static WIN32 library, but the only port available for WIN32 is via a DLL. While the DLL technology is ok, great even, in some circumstances, it make binary distribution a NIGHTMARE. You have to not only ship a WIN32 executable, but must include all the runtime DLL's as well, and most WIN32 users expect you to 'install' these DLL's, because they do not know how ...

I eventually managed to get most things required into a single g32.DLL which exported all the function given in the glib.def file, except the gthread / spawn / fork set. Thus I created a  glib32.def file for this. It was just that I was 'exhausted' getting 'something' working, that I baulked at further conversion of gspawn.c to my environment. I think it would work better in say a cygwin environment, which more closely replicates the linux/unix 'standard' distribution.

Even so, look at the linked library list, from fgsd.mak file ...
 LINK32_FLAGS=kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib winmm.lib fltkd.lib wsock32.lib opengl32.lib glu32.lib fltkjpegd.lib SimGear.lib ssg_d.lib sg_d.lib ul_d.lib zlib.lib fltkgld.lib flulibd.lib gts.lib rpcrt4.lib g32.lib /nologo /subsystem:windows /incremental:yes /pdb:"$(OUTDIR)\fgsd.pdb" /debug /machine:I386 /nodefaultlib:"MSVCRTD.lib" /out:"$(OUTDIR)\fgsd.exe" /pdbtype:sept /libpath:"..\..\fltk-1.1.6\lib" /libpath:"..\..\SimGear\source\Debug" /libpath:"..\..\PLIB" /libpath:"..\..\SimGear\source\src-libs\zlib-1.1.4\Debug" /libpath:"..\..\FLU\lib" /libpath:"..\..\GTS\src\gts\Debug" /libpath:"..\..\glib-2.4.7\g32\Debug" .. wow, what a list ;=))

And what you don't see is that I add an additional library / DLL path to the PATH environment variable where I put my 'conglomerate' g32.DLL, and the only component not compile from source, ICONV.DLL. I tried hard, but always found some stumbling block.

But was eventually successful to compile, link, and run my fgsd.exe ... What excitement ... ;=))

I had ideas of how the terrain, the scenery tiles, were but, with the aid of fgsd you can 'see' them, as part of the image ...

To those who know, this is a unique 'view' of Sydney harbour, with the tile boundaries showing. You may need to load it into a separate window to see it in FULL DETAIL. 

To be continued some time ...

End of view chain - return to Home