• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Runway beginning and end positions

J

jeehell

Messages
43
Country
france
Hi

I am still struggling with runway position and heading as I did not have any answer in this thread http://www.fsdeveloper.com/forum/threads/runway-position.440966/

I hope I might have better chances here (Jon??)...
I need to find the FSX/P3D exact computation for runway placement. Basically I need two sets of lat/lon, one for each runway end, on the runway centerline.

Using the BGL/XML declared runway center and heading is not giving me consistent results. I am off sometimes by 1m or more.

However, when I manually look up up for these coords, then compute the runway heading (initial heading from one runway end to the other end) I find accurately again the runway center with half the length.

So I do use correct wgs84 functions. I just don't know what exactly is the runway heading in the XML file is. It is TRUE heading alright, but it is not what I expect it to be...

Thanks a lot
Jean Luc
 
Hello Jean Luc,

I fully understand your problem since, AFAIK nobody knows how the sim precisely draws runway limits from the available BGL information that is
- runway center lat/long
- runway true heading
- and runway length
That's the only data it has for drawing runways

I made several tests with different accurate earth representation models and couldn't find a perfect fit for any

Here is an example on a field with quite a high latitude so as to magnify possible differences
ENAT rwy 11/29 and from BGL data
BGL rwy center latitude/longitude: 69.9773560 - 23.3645565
True heading: 121.17°
Rwy length: 2081.17 m (mid length: 1040.585 m)

Applying different models from rwy center, on rwy heading and 1/2 declared distance provides the following results
Spherical great circle (1'=1nm): 69.972688 - 23.387953
Spherical (GRS 1980): 69.972691 - 23.387937
Ellipsoid WGS84: 69.972707 - 23.387842
Loxodrom (1'=1nm): 69.972689 - 23.387956
Loxodrom (GRS 1980): 69.972693 - 23.387940
Ellipsoid loxodrom: 69.972708 - 23.387845
Equirectangular projection: 69.972689 - 23.387956

Position of sim rwy 29 start on middle runway retrieved from SimConnect (when locating aircraft exactly at this position) is
69.972689 - 23.387911

Unless someone knows the way sim draws runway (and probably other elements), I'm affraid it can only be sorted out by reverse engineering or trial and error processes

Hervé
 
Hi Hervé,

Thanks for the answer, it sort of corroborates what I notice as well.
It seemed to me that runways close to a north-south or to east-west directions were less prone to this weird behavior (so 18/36 or 09/27).
I wonder if there is a sort of " De Givry" correction applied... They did some bad things with the IAS computation, they could have messed up some computations here applying a correction twice...
At least, I believe the 045°/135°/225°/315° are the worst cases.
But I could not find an "hemispheric influence", the direction of the needed correction does NOT seem to be N/S hemisphere dependent.
I also wonder if they do not apply some sort of rounding on the heading. But I find differences of more than 0.05° in some cases. I doubt they round the data that "bad" on such critical navigation items.

I will try to investigate a bit more on my side. I'll report here if I find anything...

Jean Luc
 
This is interesting. I place runways using FAA National Flight Data Center, which provides the physical end and offset thresholds to within 0.0001 seconds. What I have noticed is that the best "fit" given a calculated centerpoint (using WGS84 in Compsys21) is where the end points marked with the red X appear at the near the physical end of the rendered runway in between the sold white line drawn on the end border and the parallel white lines drawn at the runway threshold between the runway end and the runway number. The rendering of endpoint is always aligned with lengthwise centerline, but always inside the rendered runway.
 
Hi Dan,

Thanks for sharing. However I am sorry I don't 100% get your description here, particularly the red X??
Do you really mean you more or less can "predict" how the RWY is rendered in P3D from the BGL LAT/LON/HDG ?

Regards
 
Sorry, I was looking for the right word and didn't get it. The red x as in position markers. Here is my work process for "as-building" a runway: Using FAA NFDC data I place position markers in ADE at the lat/lon for the physical ends of the runway according to the data. There are often differences between rendered runway and the data so I make adjustments to the runway object in ADE to end up with a runway where it should be. When obtaining the best fit to data, I calculate the center point lat/lon (it is not provided by the FAA) and the true bearing with Compsys21 from the end points. What i observe is when placed using the center point, both end points of the rendered runway will fall just beyond the position markers. This observation is only valid where I have FAA data, so basically I've found this to be true in any of the 50 states. Also, of course placement in the sim world is perhaps to within 0.001 min whereas the FAA data is within 0.0001 sec for runways.
 
Hello

The (seemingly few) people who are interested in this topic may be happy to know I believe I finally found out the relation between BGL/XML files runway LAT/LON/HDG values and actual depiction in FSX/P3D.

Forget complex WGS84 computations. The BGL algorithm implemented probably dates back from FS2002 or before, and at that time Earth model in FS was not the WGS84 geoid, not even a spehrical Earth model, but a planar model.

The BGL files place 3D objects in a planar (X,Y) referential which was described already here:
Conversion between geographic and FS XY coordinates

This Wiki page explicitly states this does not apply to FSX (and by extension to P3D). Although I haven't checked for other uses, I can say this is WRONG when it comes to runway depiction in the visual FSX/P3D engine.

So how it works now. Please note that I use BGL file for either the BGL or the XML file which will be compiled into a BGL at a later stage, they contain the same values.
  1. We need the formulas from the link above:
    formula 1:
    x = (lon - lon_ref) * (40075000.0 / (2.0 * PI)) * Cos(lat_ref)
    y = (lat - lat_ref) * (40007000.0 / (2.0 * PI))
    and formula 2
    lat = lat_ref + y / (40007000.0 / (2.0 * PI))
    lon = lon_ref + x / ((40075000.0 / (2.0 * PI)) * Cos(lat_ref))

    Remember in the (X,Y) referential, we'll use meters as distance unit. Regarding angles, we will convert everything to radians (including lat/lon) from start, and convert back to degrees only at the end. Remember to use radians for sine and cosine computations.

  2. In the BGL file for an airport, you can find the ARP (Aerodrome Reference Point) latitude/longitude. This will be lat_ref and lon_ref as described in the formulas.

  3. In the BGL file we then find the runway data:
    middle point LAT_ctr, LON_ctr
    HDG true which will call THETA (remember to use radians!)
    and length (eventually including overrun/blastpad etc... For clarity sake, here we will not consider any overrun or such).
    We'll call DP the semi length : DP=length/2

  4. Using formula 1 we convert the LAT_ctr/LON_ctr to a (X_ctr,Y_ctr) couple.

  5. With planar trigonometry, we can compute the thresholds (X1,Y1) and (X2,Y2):
    X1=X_ctr + DP * sin(THETA)
    Y1=Y_ctr + DP * cos(THETA)


    X2=X_ctr + DP * sin(THETA+PI)
    Y2=Y_ctr + DP * cos(THETA+PI)


  6. Using formula 2 we can convert (X1,Y1) and (X2,Y2) to latitudes and longitudes, which FSX/P3D then uses as runway start/end points to draw the runway in the visual engine (which IS WGS84).

I hope this will help at least a couple other developers...
I have tested this method on many airports so far, with varying latitudes (including the ENAT sample which Hervé gave in this thread). And the accuracy is near perfect.

This method explains why some runways are less impacted if you used the raw data from the BGL : the pure N/S and E/W runways are free from the distortion of the projection used to convert into the (X,Y) system. And the deviation is maximum for runways at heading of 45°/135°/225°/315°. Also the higher the absolute latitude, the higher the error it gave.

One last important thing to note : a runway of length L in the BGL might end up being drawn with a slightly different length!!!
In the ENAT sample, WGS84 computations give around 2087 m instead of BGL's 2081 m!

Cheers,
Jean Luc
 
According to Norwegian AIP, I have runway threshold coordinates as well as runway end coordinates. The THR coordinates is the white line just before rwy big white stripes starts; end is where asphalt stops. ENAT has huge offset thresholds. This is always a headache, but I did ENAT just fine by setting like described. Total length is 2253, with offset thresholds 277 and 215 meters. Fits my photoscenery and AIP drawing like a glove as a glove. I nail those coordinates first thing by using ADE markers.
 
You must log in or register to reply here.
Back
Top