Makerunway R5.bin Runway Number and Runway Designation Issues

[pshkong]

Hi Pete,

 

I hope I had posted on the correct forum.  Recently, I have been playing with Makerunway's binary file.  I found that there are some errors in the wRwyNum and chDesig field of the R5.bin file.

For instance:

In R5.bin
chICAO, wRwyNum, chDesig
CYLT,50,\0
ENKR,240,\0 
UENN,2602,C
ESMS,1705,L

In R5.csv
CYLT,0050
ENKR,0240
UENN,0260
ESMS,0170

So I found that the wRwyNum sometimes is showing an extra trailing zero and/or with an unspecified number attached to it, and the chDesig field sometimes have \0 as the content.

I tried to programmatically filter out these spooky entries, but rRwyNum = 40 and rRwyNum = 50 will overlap with SW-NE, and E respectively.

Do you have an idea how what's going on?

Thanks!

 

 

[Pete Dowson]

2 hours ago, pshkong said:

Do you have an idea how what's going on?

No, sorry. I'll have a look, but it will be next week now. First, though, please tell me the version number and what simulator you are using it with. And are they default or add-on airports?

Pete

 

[pshkong]

Sorry for the late reply.

I am using P3D v5.3 and MakeRunway 5.128.  I dump a list of problematic airports in the attach file.  I think most of them are default airports.  The CSV file is OK, so I guess its the problem of BIN file generation.

Thanks!

 

patch_log.zip

[Pete Dowson]

I had a look at the code and I think I've fixed the problem. It looks like it's been there since the very first version which was released in 1999, so it's over 22 years old! Surprising no one has reported before!  I assume the binary format is very rarely used.

BTW your version 5.128 is out of date, 5.129 is current. However, it would have made no difference.

Please try the attached and let me know. If okay I'll make it a proper release -- it is version 5.13 now.

Pete

 

MakeRwys.exe

[pshkong]

The new version works like magic!  Thanks!

Ha... nice, I've unearthed an ancient bug.  I am using C++ so the binary file is way more efficient way to work with, at least in my case.  🙂

 

 

 

 

patch_log.txt

[Pete Dowson]

13 minutes ago, pshkong said:

The new version works like magic! 

Good. I'll make it the current version, then. Thanks for the quick feedback.

Pete

 

[pshkong]

Just a small question about make runway, how is the threshold offset being dealt with?  Does the threshold include the offset or not?  Many thanks!

[Pete Dowson]

35 minutes ago, pshkong said:

Just a small question about make runway, how is the threshold offset being dealt with?  Does the threshold include the offset or not?  Many thanks!

The threshold lat/lon is just what is provided in the BGLs, usually from a "Start" record (the data used by the sim when you opt to start on a runway). No computation involving any threshold offset is performed. Makerunways' job is simply to extract and file the data. How it is used and what it all means is up to the user.

Possibly, if you actually want the coordinates of the very ends of the runway you would need to compute this from the runway length, the centre coordinates and the direction of the runway -- i.e. a bit of trig.

Pete

 

[pshkong]

Thanks! Very clear.

With best regards,
Phil

[Pete Dowson]

30 minutes ago, pshkong said:

Thanks! Very clear.

STOP PRESS!

I suddenly remembered: there are lines in the Log (Runways.txt) showing a computed threshold/start. This is actually computed with trig the way I said, thus:

                    // Compute better thresholds and get other stuff
                    rwy1.r.fLat = (float) ((double) rwy1.fLat - (((double) rwy1.r.uLen * cos((double) fHeading * PI / 180.0)) / 729132.0));
                    rwy1.r.fLong =  (float) ((double) rwy1.fLong - (((double) rwy1.r.uLen * sin((double) fHeading * PI / 180.0)) /
                                        (729132.0 * cos((double) rwy1.fLat * PI / 180.0))));
                    fprintf(fpAFDS, "              Computed start %s: Lat %.6f Long %.6f\n",
                                chWork2, (double) rwy1.r.fLat, (double) rwy1.r.fLong); 

So the positions given ARE the centres of the end lines of the runway!

I seem to remember I did this because so many runway "start" records were actually set at the hold point off the runway. This is especially the case for many add-on airports.

Sorry about my first answer. Most of this code is so old I don't remember it well (and old age isn't helping).

Pete

 

[pshkong]

I see, good to know MakeRunway has better numbers than in the BGL file!

I tried to compared with the Google map, some of the airports are quite accurate.  

I think it is highly dependent on the developers of the airports.

If they have done it right (according to the proper definition of runway threshold), the threshold should be where the runway pavement start (i.e. including the threshold offset), and the runway end line point should exclude the offset.  The runway length should include the offset too.

I guess that's not strictly defined in the sim so there are different ways of doing it...

Regards,
Phil

[Pete Dowson]

6 hours ago, forstmeier said:

Years ago I wrote the program
"RwyLength"

Your post is very interesting. Are you wishing to allow others to make use of your work? If so, would you like to re-post this data to the "User Contributions" subforum, above? I can do this for you if you prefer, with just a small edit needed to divorce it from this thread.

Pete

 

[forstmeier]

Pete said:

"would you like to re-post this data to the "User Contributions"

-------------------------

Yes i will copy it there.

By the way. Tomorrow i will upload to my website the corrected ATIasHold Software.

Before doing the last 1.8.3 upload I saw a point in the program that seemed easy to change.

Mea culpa. (maybe the age)

I made a glamorous mistake as this small change affected at least 4 procedures and functions. In detail, the radar view of Adf + Vor in relation to the Flight Plan which can be divided and precisely, the Flight Plan can be interrupted for a free flight Adf, Vor Instrument flight.
Tomorrow i will upload the corrected program.

Raimund

 

Nota regarding Runway Identities.

There are several differences between the various simulators.
If FSX + MSFS indicates Rwy 33 at LJMB, xplane is indicating 32.

With RwyLength and AddAirports the user manages it.

 

 

This program is reading any text database cvs ecc... dividing Headers single or multiple, SubRecords with different initial digits, extracting in any sequence.

The user must have a very good knowledge of the various structures of a dBase text. It's amazing how many variations there are. I wrote it several years ago to create my personal dbase. In fact the program name is: AiracStructure

Only 1 user, a german company is using it for extracting and translating Frequency dBases for the Radio Amateur world in different forms. To help i just need 1 complete Record and what should be the result for creating a configuration file. The program is Freeware. I'm a Radio Amateur.

An expert like you notes the presence of R-Set and R-Align which are 2 different things.

In this example we have a Header Record with all SubRecords in 1 Line only.
A delimiter "_" is used only for the Header in order to read the Apt names without the "_" digit.
While the following Runway subfields are read "by position". The space digit divides the SubRec Runways. This is a simple example.

.

 

 

 

[Pete Dowson]

10 hours ago, forstmeier said:

Yes i will copy it there

Thank you!

10 hours ago, forstmeier said:

There are several differences between the various simulators.
If FSX + MSFS indicates Rwy 33 at LJMB, xplane is indicating 32

Perhaps they are using data from different dates. The magnetic runway headings can change due to changes in the Earth's magnetic field.  Of course, the True heading should be the same.

Pete

 

[forstmeier]

On 3/24/2022 at 7:55 PM, Pete Dowson said:

an do this for you if you prefer, with just a small edit needed to divorce it from this thread

Yes please. copy the part you think is useful.

Thanks

Raimund

.