X-Plane 11.10 brings a few changes to how airports, the airport gateway, and navdata interact.
Many pilots who try to fly realistic IFR operations with the X-Plane built-in GPS or FMS will have encountered this dreaded window already:
The reason for this is that coded instrument flight procedures (CIFP) come from very reliable sources – Jeppesen or LIDO (depending on whether you get your data updates from Navigraph or Aerosoft), while the runways on X-Plane’s airports come from a community driven, open database: The X-Plane airport gateway.
Unfortunately, the airport gateway community is not always fast when it comes to runway renames or airport expansions, which happen all the time all over the world. The most common reason for a runway rename is a shift in magnetic variation: Runways are named for their cardinal direction relative to magnetic north. While the runway’s orientation with regard to true north is fixed[citation needed], the orientation measured against magnetic north changes over time, as the magnetic pole moves and local magnetic declination changes. Now when the magnetic course of runway 11L changes from 114 to 115 degrees, airports paint new numbers on their runways. 11L-29R becomes 12L-30R. Jeppesen knows about this and changes the runway name in all their data, which ends up in a data update for X-Plane. Meanwhile, the scenery author community over at the airport gateway of course has more exiting things to develop then a runway rename.
To make things worse, runway renames are super annoying in WED. After you renamed the runway from 11L to 12L, you had to go through ALL your flows, ALL your taxiroutes, and ALL your airport signs to change the name EVERYWHERE.
In the past, we have partially solved this problem by running mass renames of runways in the gateway database rather than through WED. If you see a change on an airport made by a user named “WEDbot” (like at this airport) that is usually such a batch-rename.
With X-Plane 11.10 and WED 1.7 there are some big changes that greatly improve the interaction between X-Plane airport data, navdata, WED, and the airport gateway.
Easy runway rename in WED
WED 1.7 has a function that changes all flows, routes and signs for you when you rename a runway end. This makes bringing an airport up-to-date a nearly foolproof operation even for a WED-dummy like me. You don’t need to be a scenery wizard to simply fix an airport anymore.
Silent runway rename in X-Plane
If you have navdata from Aerosoft or Navigraph, and a runway in the X-Plane airport matches a runway coming from the navdata, but the name has changed, X-Plane 11.10 now silently renames the runway at runtime for you. Which means, even if a 11L is painted on the runway, the FMC can load the procedure for 12L and get you there. This only works if the scenery is properly georeferenced and the runway is actually in the right spot – if the scenery was made incorrectly and the runway is not at the right coordinates, this obviously doesn’t work.
Silent threshold fix in X-Plane
Not all scenery authors correctly place displaced thresholds. A bit of confusion exists over when to use the white arrows or the yellow chevrons – and which counts into the runway length and which doesn’t. I teach my student pilots “the only thing you can do on yellow chevrons is crash – anything but crashing on that area is illegal.” Hence this area doesn’t count for runway length. Again, if you work off a properly georeferenced orthophoto, you won’t have any problems. Unfortunately, if you misplace where the (displaced) threshold is, this coordinate problem can feed back into the instrument procedures of this runway. For example, for many non-precision approaches the MAPt of the procedure coincides with the runway threshold, so if those coordinates are off, so will be your missed approach point. With X-Plane 11.10, if a runway in the airport scenery matches a runway coming from your updated navdata, but the threshold is laterally offset from where it should be according to instrument procedure data, X-Plane silently moves the threshold coordinates the GPS/FMS works off to the correct location. This works if the scenery is “good enough” in that the majority of the runway pavement is where it should be, and the thresholds are only off in the direction of the runway. If the whole scenery is ill-referenced, meaning the runway is off other than along its major axis, this obviously doesn’t work.
Silent and not-so-silent feedback
If you have enabled anonymous data collection in X-Plane, whenever your X-Plane silently applies a runway name or runway threshold location fix in the background, it also sends a packet of data to our analytics server, telling us the airport you were approaching and what was up with the runways. Collecting this data from a wide range of X-Plane 11 users will allow us to generate a heatmap, i.e. the most important airports that need the gateway communities’ love. Note that this data is collected only if you are running navdata that is current – we are not collecting reports based on historical data.
Only if both of the above fail, which means the airport has both a problem with its runway numbering and is ALSO poorly georeferenced (runways are in the wrong location geographically) the situation is beyond fix for the new runway logic. Only in this case you will see the dreaded dialog, because the runway simply does not exist in X-Plane, at least not where it should be. In this case, you will be able to submit an automatic report to the gateway website if the problem exists with current navdata. Note that this dialog will come up whether you have enabled data collection or not – but you can still chose to close it without actually posting the report if you don’t want to.
Only this kind of “all is lost” reports are actually visible on the gateway website and the XSG bug database. This allows artists to see the only airports that are actually so outdated that they cannot be fixed automatically. The automatically fixable scenery errors no longer clutter up the gateway airport bugbase.
Any downsides?
The downside to all these changes is that they all actively work to keep the X-Plane default scenery up to speed with the airport changes in the real world. This means that over time, as our global airports follow the real world in terms of runway renames, airport construction, expansions, etc… it will become less useable without up-to-date navdata. That’s the price we have to pay for “as real as it gets”.
Break ALL the scenery!
Poorly georeferenced scenery has a problem beyond affecting the missed approach points of non-precision approaches. It also affects the ability to use the new SBAS (satellite based augmentation system) approaches that are comparable in accuracy to ILS. I always prefer to fly the LPV approach if given the choice. However, the FAS block (final approach segment) comes from the navdata, which means it guides you precisely to where the runway is in the real world. If the X-Plane scenery is poorly referenced, the approach will dutifully fly you into the grass in X-Plane, if this is where the runway would have been in the real world. This is obviously a problem for serious training scenarios. Therefore, X-Plane 11.10 can be started with the commandline option –accurate_runways which will dynamically rewrite the actual scenery in X-Plane after loading an approach, both moving the runway into the correct geo-location and also changing the numbers written on the runway if needed. This obviously only works on default scenery with the procedurally generated runway textures. It will not change custom scenery that uses draped polygons for photorealistic runway textures. Moving the runway into the correct location will obviously also disconnect it from any incorrectly placed taxiways. Also, using this option increases load times for selecting an instrument procedure significantly, since it has to rebuild the airport scenery. So this option is really only there to help you keep limping along with broken scenery, if your operation absolutely requires accurate runways and you can live with some broken taxiways. It is therefore not available as an “official” setting. Do not come to us to complain about the jarring results – make a proper fix in WED instead! The results can be quite disruptive, but at least the approach won’t guide you into the grass:
So…. if a user does *not* update their navdata, and then they fly to an airport that has been updated in the Gateway due to magvar, they will suddenly find themselves with completely mismatched data, and no procedures since the runways are now all different.
We probably need a log of what gets updated when, Philipp, so that when a user goes and gripes to a third party FMS developer, that the data mismatch between their navdata and the airports in the Gateway can be debugged and the real problem diagnosed.
Obviously, the smart thing is for users to always fly with current navdata, but that’s not always an option for every user due to cost.
Correct. If a user never updates their navdata, and X-Plane 11 carries on for a few more years with constant gateway updates, more and more of the airports will become different from what they were in October 2016.
Every time we dump updated airports into an X-Plane update, you find the full list of airports updated in the release notes. Also, the scenery gateway logs the updates, so if you once in a while see a bunch of airports updated by “WEDbot” you can be sure that those airports had runway name updates.
Thanks!
I couldn’t find a simple log per se, but did check for the updates done by WEDbot, and found a substantial number of runways updated on September 13. I presume this is what you meant.
A more easily accessed document that is easily searched would be appreciated. WEDbot has 42394 entries. 🙂 Right now we can only see 11 airports at a time. Perhaps something that could be downloaded for a specific WED user in Excel format, or even CSV?
Are you saying X-Plane updates will deliver the latest gateway airports but not the latest navdata? That doesn’t seem right!
We cannot deliver navdata that we don’t own the rights to. You’ll have to get those from one of the providers who made deals with the big data suppliers to make the data available to flightsimmers. X-Plane has worked with data from Navigraph (sourced from Jeppesen) and Aerosoft (sourced from LIDO) for a long time!
Have you considered sourcing it from the gateway itself?
I had no idea I had to pay for another product to keep x-plane working!
Which one is the primary source of data? Is the navdata time-stamped so you could choose to which source (gateway bs navdata) is the most up to date? Would be odd if gateway changes were held back if I’ve never updated my navdata.
Navdata is very unlikely to be successfully crowdsourced. Designing coded flight instrument procedures requires both a fairly expensive software, and extensive knowledge of both real world procedures and encoding rules – I doubt more than three or four people in the whole X-Plane community even have the required knowledge and background. And there’s thousands of airports to be cared for. That’s why we rely on data providers that use the same source as real world airlines do.
The navdata is indeed time-stamped. It’s called the AIRAC cycle date, which is a four digit number that consists of two digits for the year, and two digits for the 28-day period. It’s in the first line of each navdata file – 1610 is the one that ships with X-Plane.
Hi Philip,
Some interesting info here. I was wondering, if the default runway system is superior to draped polygons, then is it possible that we can get a referenced file format in X-Plane for artists? (I mean this in a similar sense of trees having a .for file or ground markings having a .lin file.) Right now, the only way I can see to change the texture of the runways is to replace the default bitmaps (which lack variation, custom sizes, or the ability to apply normals to the runway.) Having a runway file which x-plane references per custom scenery would be useful for scenery authors!
regards
The default runways system is not “superior” to draped polygons. The dirty trick of dynamically fixing the runway layout at run-time is just that. A very dirty trick. It’s to help band-aide completely broken scenery temporarily. They really need to be fixed in WED instead! I do not consider the fact that a broken scenery happens to lend itself to that because it doesn’t use draped polygons an advantage of not using draped polygons.
WED 1.7 is not available yet, right?
I had such an airport runway “rename” and would like to see WED 1.7 in action.
Cheers.
Correct. It’s in development now, and can be tested by building from the git repository. You can’t contribute to the gateway with it yet. If you want to contribute to the gateway, you need to use 1.6 or wait until 1.7 is released.
We may have an WED 1.7 early beta shortly. Maybe even before the facade preview is completely done.
On the other hand- 1.7 so far is fully backwards compatible with 1.6. So you could use it just to rename your runways and then go back.
Hi Philipp, thank you for pointing out the upcoming fixes and enhancements. Those of the runway identifiers and thresholds are essential for RW procedures being followed correctly.
Just one question: you wrote “but the threshold is laterally offset from where it should be according to instrument procedure data”. Did you mean longitudinally? As the fix is intended for runways that are NOT “off other than along its major axis”. Might has been a typo or I didn’t understand well. Thanks.
Hmm. Two non-native speakers discussing how to use the english language correctly. Frankly, I don’t know who’s right.
Here’s what I mean though: If the majority of the pavement is in the correct place, but the ends of the pavement are longer or shorter in one direction, that’s what is considered fixable. If the end of the runway is offset sideways, in a direction other than straight down the runway, that’s a problem that cannot be easily fixed without a human author actually working on it in WED.
“Laterally” isn’t this well defined, it’s frequently used for “in any direction but up and down”, so its not wrong …
“Longitudinally” is usually understood as “in direction of the long axis. But in the context of geographic coordinates one might think of it as “in direction of longitude” or East-West direction. So its not a really good word either 🙁
So lets think of it as “in runway” direction. As opposed to “perpendicular to the runway”.
Hello Philipp,
These are good features! But make me want 11.10 to be released right away.
Now. One question. Will user have a log of the data that was shared? Being curious, please don’t think wrong. Just for statics.
If you start X-Plane from the commandline you’ll see various diagnostic outputs in stdout, among them EVERY http connection that X-Plane makes.
In case of the runways, you’ll see something like this when a threshold was auto-fixed and the fix reported back:
stop teasing us GIVE IT TO US lol
I think having consistent data (airports matching procedures and ATC) is more important than having “bleeding edge” data (for the airports).
Another thing that might help is “aliases” or “obsoletes”: If you can tell X-Plane new “RW12L” is an alias of the existing “RW11L” (“RW12L obsoletes RW11L), the procedures for “RW12L” would work, even if the runways is labeled “RW11L”. Confusing for the pilot, I agree.
Maybe a “true Austin hack” would visually “cross out” (X) the old runway number is yellow or red, and put the new one on top. That would be realistic, because the actual runway does not rotate, but just “the compass above”. Maybe the real fix in times of GPS would be a switch to geometrical north instead of sticking to magnetic north.
That’s exactly what “silent runway rename” does – albeit not painting an X on the runway 🙂
seriously eta on 11.10 beta? it’s holding up the works here
Is it not possible to keep the numbers of the runway as a variable which is calculated by the actual runway heading (or historical heading if someone is using old navdata). Using the variable (instead of the value) in all names that use the runwaynumbers makes renaming an automatic trick. All airports have to be renamed once to use the variable, but the x-plane could take care of it for ever.
But… I think I overlook something so that you decide not to use this approach.
Yes. Naming the runway is NOT automatic, but done by the local aviation authority. Also, frequently there are numbers used that do NOT correspond to the magnetic heading at all. See for example LAX with its four parallel runways. They all have the same magnetic heading, but they are named 6L, 6R, 7L and 7R to resolve the ambiguity of four runways in the same direction, but only having L, C and R as letters to distinguish them. Atlanta, Denver, DFW, and others do similar things. And then there’s Canada where some runways are named for true rather than magnetic direction, because far up north, the magnetic direction is so out of whack.
What kind of performance improvement are you offering in xplane 11.10?
When 11.10 will come out? Release date please!
All this is nice and all, and thanks, but I agree with the above, whats the ETA on 11.10 and what improvement will we see ?
Ho, im Riccardo, from Italy, im a newbie developer, im working on a Tecnam aircraft, how can I be part of you to development of my plane?
Thanks.
I’m not sure if I understand the question correctly, but if you are looking for the information and reference needed to build your own plane in X-Plane, you should start reading here: //developer.x-plane.com/docs/aircraft/ Next place to check out would probably be the aircraft designer forums on one of the X-Plane community sites, like X-Plane.org and X-Pilot.com – that’s where all the people are that make planes for X-Plane.