makerwys runway.txt with additional altitude in meters ?

[Quaxman]

Hi,

regarding the P3D 4.5 HF2 altitude processing and the problem with fsAerodata Navigraph FSAD_comms.BGL, I wrote a script to check the airport records in runways.txt to scan airports for BGLs with different altitudes.

The script works, but now, I detected rounding issues from meters (as defined in the BGL) to feet in the chain runways.txt (alt in ft) -> fsAerodata correction tools (alt in ft) -> FSAD_comms.BGL (alt in meters).

My question: would it be possible to enhance the airport lines in runways.txt with the original meters value from the BGLs ?
currently: "Airport EDDF :N50:01:59.8986  E008:34:13.6389  363.99ft"
enhanced: "Airport EDDF :N50:01:59.8986  E008:34:13.6389  363.99ft 110.947m"
(110,947 derived from DWORD 63 B1 01 00)

I asked fsAerodata for a modification of the correction tool AdjustElevation.exe to process the input list with the correction values in meters,
if both wishes would be fulfilled, one could take the exact altitude value in meters for addon airports from runways.txt,
create the input list for AdjustElevation.exe for these airports in meters
and correct the fsAerodata FSAD_comms.BGL with this exact altitude value to remove the elevation issues.

BTW: I had to create such a correction list as the fsAerodata tool doesn't process all my addon airports and some of the processed ones don't have the correct altitude value.

I know, Christmas is nearly over and time for wishes has passed, but maybe you can consider my thoughts in a future update of makerwys.txt ?

[Thomas Richter]

Hi,

which version of MakeRwys are you using?

The runways.txt file is a log file and shouldn't be used as a data source. I.e. the runways.xml file is a source file.

By searching the forum you would have come across the this thread, couple weeks ago:

MakeRwys and airports elevation with decimal precision

First make sure you use latest version, Make Runways utility version 4.891 MakeRwys.zip

Thomas

[Quaxman]

Yes, I know the discussion. And I spend hours in analyzing why the tool of fsAerodata doesn't handle all my addon airports:
It's a rounding problem feet vs. meter (output of makerwys is in feet, BGL definition says meter). I wrote this in their forum with my wish to handle a fixed airport altitude list in meters instead of feet.

My thoughts were to avoid processing of the whole P3D airport list, instead giving the fsAerodata tool a fixed list with <ICAO>,<altitude> (as I know my addon airports and have to modify this list only if I buy a new one).

They made it possible by a parameter "-f <list>" in their AdjustElevation.exe, but the altitudes have to be specified in feet at the moment. Now I found out, that their tool has to convert feet in meters - according to fsdeveloper.com BGL files contain altitudes in meters and aero.sors.fr states "Altitude is given in 1/1000 m as DWORD".

If the difference of an addon airport is small compared to their default altitude (which is P3D default altitude), the AdjustElevation.exe simply ignores the airport and its specified altitude in the list. This seems to be related to rounding issues in their conversion from feet to meters (only my assumption, but that's what I see as result).

Now why do I process runways.txt ? To get the correct altitude value for the list file as input to their tool, I have to find out the altitude of the addon BGL in an ascending order in the same way the simulator does it. This lead me to runways.txt.
To do this search and display on a convenient way, I wrote the appended script.
This works for most addon airports except for airports where the addon BGL altitude is small compared to the base BGLs altitude (the mentioned rounding errors).

The script writes on the Powershell console and in a logfile the sorted altitudes of the specified ICAO Ids, e.g.:

ICAO linenumber   altitude      BGL
EDDF 000001187422 363.99ft    Scenery\0601\scenery\APX50140.bgl
EDDF 000002172425 363.99ft    ORBX\FTX_EU\FTX_EU_GES_05_SCENERY\scenery\ADE_FTX_GES_EDDF.bgl
EDDF 000002353326 364.01ft    C:\Games\Aerosoft\Mega Airport Frankfurt Professional\.\scenery\EDDF_AFX-OP07.BGL
EDDF 000002377139 363.99ft    C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC_SIDs\scenery\EDDF_SIDS.BGL
EDDF 000002377151 363.99ft    C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC_SIDs\scenery\EDDF_STARS.BGL
EDDF 000002414647 363.99ft    C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC\scenery\EDDF.BGL
EDDF 000002666905 364.20ft    C:\GAMES\fsAerodata Files\Navigation Data\Comms\scenery\FSAD_comms.BGL

***** EDDF *** ATTENTION *** BGL with different altitude found *****

Here, I see: EDDF addon airport altitude from the Aerosoft BGL is 364.01ft, so fsAerodata BGL has to be corrected from 364.20ft to 364.01ft - but that doesn't work at the moment.

I thought, as a solution, if their AdjustElevation.exe would accept meters instead of feet in the correction list ("-f") and runways.txt could deliver the value in meters, the elevation correction would work even with small differences.

p3d45hf2_fsad_altitude_list.zip

[Thomas Richter]

Hi,

but the additional elevation in meter wouldn't change the outcome in Runways.txt file. Pete changed already the precision to 2 digits right of decimal for fsAerodata for their data problem.

In case ft is ish a third of a meter, that means you are already down to 3 thousands of a meter (0.01 ft = 0.003048 m = 3 mm). A value of 3 mm difference will not make a difference.

 

Quote

Here, I see: EDDF addon airport altitude from the Aerosoft BGL is 364.01ft, so fsAerodata BGL has to be corrected from 364.20ft to 364.01ft - but that doesn't work at the moment.

Also with your given example, which Elevation is wrong.?

Thomas

[Quaxman]

The leading problem lies in the fsAerodata correction tool. In the "automatic mode" (the tool processes all airports in runways.xml), some of my addon airports are skipped, therefore elevated. In the "manual mode" with a user specified altitude list, some of my altitude values are skipped and it seems, the tool skipped them as the difference between their altitude and my altitude is lower than 1 ft (but not in every case). I wrote them the issue...

OK, I see that I could use the values of runways.txt for my script and either the tool of fsAerodata has to be corrected or I have to write my own tool...

Regarding EDDF, I made a little mistake: the last line was already corrected by me. With a virgin FSAD_comms.BGL, it would look this way as FSAD_comms.BGL is delivered with the original altitudes of P3D

ICAO linenumber   altitude      BGL
EDDF 000001187422 363.99ft    Scenery\0601\scenery\APX50140.bgl
EDDF 000002172425 363.99ft    ORBX\FTX_EU\FTX_EU_GES_05_SCENERY\scenery\ADE_FTX_GES_EDDF.bgl
EDDF 000002353326 364.01ft    C:\Games\Aerosoft\Mega Airport Frankfurt Professional\.\scenery\EDDF_AFX-OP07.BGL
EDDF 000002377139 363.99ft    C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC_SIDs\scenery\EDDF_SIDS.BGL
EDDF 000002377151 363.99ft    C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC_SIDs\scenery\EDDF_STARS.BGL
EDDF 000002414647 363.99ft    C:\GAMES\fsAerodata Files\Navigation Data\P3D\PROC\scenery\EDDF.BGL
EDDF 000002666905 363.99ft    C:\GAMES\fsAerodata Files\Navigation Data\Comms\scenery\FSAD_comms.BGL

In this case, the correct value that has to be placed in FSAD_comms.BGL is normally the last entry before the fsAerodata files themselves, here 364.01ft from AeroSofts EDDF_AFX-OP07.BGL

I want my script as a general tool to check altitude values of P3D's BGLs in the sim's search order (now as with HF2 the method to retrieve the lasting altitude was changed). Regarding P3D, I trust no one 🤭 (not even myself).

I hope, fsAerodata could correct the behaviour of its tool...

[Thomas Richter]

I guess they use then for the conversation in one direction the simplified 3.281 instead of 3.28084.

Thomas