While everyone looks at the new UI in awe, X-Plane 11 also had a few important changes under the hood. With Aerosoft Navdata Pro now also supporting X-Plane 11 beta, let’s talk about one of the most boring technical features of X-Plane 11: The completely redesigned database for navigational data, which makes it much easier for data providers like Aerosoft and Navigraph to supply data updates for the X-Plane navigational facilities, while preserving scenery compatibility.
The most important goal when designing the new database was to eliminate the duplication between data in X-Plane’s world and X-Plane’s navigation systems to leave less room for subtle inconsistencies. I also wanted to address compatibility of navdata updates and global scenery (mostly concerning localizers at airports). Other improvements were the integration of SBAS path points (needed for LPV approaches) and RNP service volumes. Last but not least I wanted the ability to work with ARINC424 data directly, and eliminate most of the subtle encoding differences that result from different providers generating files with slightly different converters.
Work on the new database started in April 2016, when I got in touch with FAA representatives at the FAA Aviation Safety Center at SUN ‘n FUN where the External Data Initiative (EDAi) was launched. Preliminary work was completed by end of April, and feedback was provided to the FAA at the EDAi stakeholder meeting in Washington (the whole trip was quite a memorable experience). I cannot emphasize enough how valuable the open data initiative of the FAA is – this is an example of your taxpayer money at work.
The specification of the database was finalized in September, and both Navigraph and Aerosoft were provided the tools they needed to create navdata for X-Plane 11 in the new format. Actually, we are not limited to those “big two” – as the tool is available for everyone, open-data purists can actually generate their own navdata for the US and Canada using the FAA’s file.
With the great power of the unified database comes great responsibility: The navigational data can only be as good as the world scenery it is placed in, especially the airports. Some of X-Plane’s airports in the default scenery have not kept up with the pace the real world is evolving at: runways are renamed (due to magnetic shift), extended, built or closed and X-Plane’s airport scenery is only as good as the community who cares for it. To make their life easier, we are currently working on a big automated scenery update on the server side. We will rename several thousand runways all over the world on the scenery gateway soon, and this will solve the most annoying issue people are currently facing with the new database: runways not being found because they have been renumbered.
This automatic scenery update is however only part of the solution – because we can only rename runways we have! If an airport is extended in the real world because new runways are built, we rely on the scenery gateway and its incredible community for updated airports.
I took the time to write an even more boring technical article on how everything works together in X-Plane 11: Navdata in X-Plane 11. If you are an end-user, you don’t need to bother, because here’s the TL;DR: It’s awesome. It gives you RNP approaches for airliners, and LPV approaches for GA aircraft.
Writing this article though, when I compare it to the new UI, I can’t help but feel like the poor guy in this webcomic because this is exactly how the end-user will experience the change: Most won’t even notice.
Hi Phillip. Great post. However, I am a bit confused on how we update the sim? Everyone is stated copy the navdata folder from XP10 to XP11 custom data folder? Moving forward do we just use Navigraph and let it update the XP11 folder automatically?
Navigraph and Aerosoft update X-Plane 11 automatically. Copying old navdata is not necessary if you have your FMS Data Manager (Navigraph) or Aerosoft Navdata Pro (Aerosoft) program configured correctly to supply both X-Plane and add-on aircraft with data.
Phillip, will it be possible in future to drop in your own images for use in the map viewer? At it’s most simple, being able to drop in a folder of GeoTiffs would be very helpful, and we could use real world VFR charts (or more useful maps) directly inside the simulator. The current VFR map viewer is really not very useful and rather a step back from that of XP10.
Hopefully you’ll consider doing this in a future update 🙂
I’m not really qualified to answer this, because the new map is made by Tyler. However, I think that having large amounts of pixel data, like GoeTIFFs would not be very efficient. The current map is so blazingly fast (compare it to X-Plane 10’s textured maps to see what I mean) because it uses a highly efficient shader to display the topography, instead of loading pixel images for that.
Great post Philipp, very informative.
Ehm, I just don’t get the point – maybe I missed something here. But I use the Flight Factor Boeing 767-300ER Pro every day in XP 11. The current version still uses the GNS430 folder.
All user action required to make the 767 work fine again is to create the now missing folder manually: “X-Plane 11\Custom Data\GNS430”
Then just edit the AIRAC data update tool to the new path and you are all set to go flying. It is even possible to simply copy that folder of XP10 to that path and all add-on birds depending on the GNS430 folder should run fine.
So what is it that LR should do to XP11?
Creating a folder is a 5 seconds job only and can easily be done by the user.
Just my 2 cents.
Regards,
Marc
I’ll try this one more time… 😉
I appreciate the elegance and the technical improvements, Philipp, and the reasons for them. I agree – moving forward and being innovative is cool and highly desirable.
However, I think many users will indeed notice this change when they go to fly their 3rd party add-ons in X-Plane 11 that were developed during X-Plane 10 – mainly when they can’t program their FMS, or worse, the aircraft won’t load due to missing files and the sim crashes and burns. The number of inquiries regarding this sort of thing on the .Org over the past two months has been large.
Since the format of the files contained in the /Resources/GNS430 folder has *not* been deprecated, as you’ve explained to me, would it not be intelligent to support 3rd party developers in X-Plane 11 that do not have the immediate time and resources to convert their aircraft plugins to the new format? So that they will be immediately flyable in X-Plane 11 without modification? If Aerosoft is willing to provide free X-Plane 10 compatible data for release, as long as it’s at least six months old, then the data footprint of the /resources/GNS430 folder is trivial to redistribute. Then there would be at least some level of compatibility, even if the data is never updated. So easy for LR to do. And if users wanted to update the data, the partial use of an Aerosoft/Navigraph X-Plane 10 data set in the form of only the GNS430 folder in the X-Plane 11 Custom Data folder would resolve consistency issues. That already works well enough. Just.
What it comes down to, aside from the forgoing discussion, is why is it necessary to preclude backwards compatibility when the effort and expense to LR is virtually nil?
There are solutions for the 3rd party developers. Yes, indeed. But why force these people to got to the expense and time of releasing plugin updates when such can be reasonably avoided with a little prudent forethought and kindness? There are also workarounds, but these have to be explained ad nauseum in the web fora – if the users even bother going looking for such information.
The bottom line is still “why?” Why not support the X-Plane 10 way for just one more whole number iteration of the sim, at least? Not every user is as concerned as you or I might be about the perfection of their navdata. They are certainly going to be more worried about whether or not the product that they’ve paid good money for remains viable in the overall X-Plane scheme of things.
Providing at least the GNS430 folder with one viable dataset to X-Plane 11 users that own a hanger full of X-Plane 10 aircraft is both a kindness and a nod to the same backwards compatibility that X-Plane has always had. Anything less is hard to accept. Looking forward is good, but being stubborn about legacy compatibility – not so much. Even Microsoft still supports the ancient .xls format in Excel. And my most recent AutoCAD program will open files that are 10 years old. Why should X-Plane and Laminar Research behave any differently?
I’m not trying to be a pest, even though I persist in the opinion that the GNS430 folder data that was only introduced in X-Plane 10.30, not really all that long ago, should never have been summarily dropped.
Congrats on the accomplishment of such high end fidelity, Philipp. I do have a great appreciation of the insanely complex data set that you’re working with, and the equally insane level of detail that one must implement in their code. I have enormous respect for this sort of effort as well as the many, many years of experience it took to be able to write that code. My concerns are more pragmatic, and customer based, and it is for my customers and clients that I persist. Sorry if I’ve been in any way an irritant.
All add-ons made for the X-Plane 10 data set continue to work just fine. Aerosoft and Navigraph still supply the old data set, and will do so for the indefinite future. So no one has to “convert” to be compatible with X-Plane 11. If Laminar shipped the outdated XP10 data by default, we would not only be shipping two different versions of data formats, but also two different cycles as default (the XP10 data being considerably older), which would create even more confusion. For users who do not want to sign up for data updates, the add-on providers can ship default data sets which they get from Navigraph or Aerosoft for free, so we are not forcing end-users to buy data either.
Philipp, you’re ignoring the obvious. If add-ons depend on the /Resources/GNS430 folder, they have to be altered – at least to the point of seeking the data in a different location. That inconvenience to users and developers alike can be easily solved by Laminar Research waking up to the fact that maintaining legacy support for add-ons means *not* removing a data folder that had only been added only one whole number release previously. It’s such an easy thing to do, and why it’s sooooooo important to delete the GNS430 folder from X-Plane is undeniably absurd. Delete it for X-Plane 12 or 13? Sure. But not 11.
I fully agree with you, putting back the GNS430 folder into XP11 is zero annoyance for Laminar. Even if we could distribute the data ourselves (which I don’t have the right), many customers would fail putting it at the right place. We’re only left telling people who don’t have XP10 to download the demo version for copying one folder from it: ridiculous!
Not going to happen. The correct fix for you is to ship the default dataset from Navigraph or Aerosoft that you got as part of establishing the update process for your addon, with the initial install of your add-on. No user interaction necessary. As for Steve Wilson’s comment about removing it in XP12 or 13: As if that ever worked. Does anyone know why MS Excel has a bug in calulcating leap years? It’s to be compatible with Lotus-1-2-3. Because that’s what happens if you keep compatiblity kludges: They stay forever. That’s why in 2017 using Office 365 you still have the same leap year bug as in 1983’s Lotus software.
Philipp – You’re just being inexplicably stubborn. Adding the GNS430 folder back to X-Plane 11 has zero impact on LR, and on the rest of your brilliant new navigation efforts.
The fact is that if you don’t add the GNS430 folder back, you are basically showing that you do not care about the add-on developers that have to work around this deletion, and the hundreds, if not thousands of users that will now need to either deploy a questionable work-around themselves or seek an update to their product, which may or may not be available. I’ve already had to spend significant time with a client this morning, solving his installation issues that are a result of this very situation. If the human cost in time and aggravation are unimportant to you, then continue to resist. You’ve presented no good reason not to include the GNS430 folder, only a determination to not yield to simple logic and a zero cost correction.
Skewering my analogies is also not constructive. You know what I mean. Is the GNS430 navdata solution perfect? No! But it’s been out there for the better part of the X-Plane 10 run, and you have an ethical obligation to maintain it for a reasonable period of time. Give developers a chance to migrate away from using the GNS430 folder over a period of years, not months. What you’re basically doing is to suggest that it’s okay to pull the rug out from devs and customers. X-Plane 11 will be great, but it doesn’t need to be a significant hassle to developers and customers at the same time. Right now, it is just that.
Since you have now opened the parallel email discussion, I will not comment on this in public.
Thank you guys!
Well. I move the GNS430 folder out of xplane. I use the FMS NAVIGRAPH MANAGER to update to the newest cycle. All of the planes have Navdata from 2012? When I put the GNS430 folder back into Xplane 11 Custom Data it works fine?
That means you have no add-on mapping in the Navigraph FMS data manager for the add-on aircraft. Please use the Navigraph forum if you need help configuring their manager program.
Any fix to the useless ATC ? Thx
How about the magvar? It will be the same as X-Plane 10 or will be editable? In some airports are now more than 1 degree of difference.
The current magvar is from June 2015, so 1.5 years old. I think we will update it once more before X-Plane 11 goes final. Making it editable however is a bad idea, if every installation could have their own mag var, it would cause all legs based on magnetic tracks to be essentially not reproducible. That would be an invitation for all kinds of stupid bugs with scenery and IFR procedures and it would be a nightmare to debug.
I made the magvar table for Laminar Research in 2015 – but I used predicted data for 2019, if I remember correctly. So the data will only get more accurate over the next few years (as the real world drifts towards X-Plane´s data) and then get inaccurate again after 2019.
The data points for the magvar are every 10 degrees, so there is bound to be some inaccuracy in between or in spaces where the real variation has some unusual anomalies.
1 degree of difference is not unheard of in the real world, either – especially with on-board IRS equipment that has a stored magvar database. Changing it on the fly is impossible for some units, so the owner would have to replace the whole unit to get a new database.
Jan
Sorry but I’ma bit lost.
I need to add Visual Reporting Points for Italy area according to the official AIP italian publication…where so I need to add this data and in which format?
Custom waypoints live in user_fix.dat. Specs are available in the article I linked.
Thanks a lot for feedback Philipp. So user_fix.dat is created when a fix is edited using the map GUI in X-plane…to add other VRP I just have to use the ArincDocoder v4.4 then convert in X-Plane format using the convert 424toxp11 tool? I’m asking because in previous X-Plane version I worte a PHP parser to read data from official ENAV AIP to add the 417 VRP to the X-Plane dataset….adding those VRP manually one by one into the ArincDecoder should be a pain. Thanks again for feedback
The ARINCDecoder program is just a suggestion, there exist other tools in the industry to work with ARINC424 files for sure. Generating a user waypoint through the map is currently not implemented in XP11. You can however use the XP11 default FMC to generate user waypoints, that also causes a valid user_fix.dat to be generated that you can then work with.
Hi Philipp,
I have a plugin which currently uses the GNS430 folder & earth_*.dat files (XPLMNavigation).
I would like to switch over to using CIFP & earth_*.dat files (XPLMNavigation).
It occurs to me that the current SDK calls like
XPLMFindNavAid
XPLMGetNavAidInfo
need changing or replacing to pick up new fields like “ICAO region code”.
Any idea when we will get access to SDK changes / documentation for XP11 ?
Expanding the XPLMNavigation API is certainly on the roadmap, but not high priority right now. If you absolutely need this information NOW, you’re going to have to parse the files yourself.
Documentation for all the new files is in the linked article.
Thank-you for the explanations. Although I am not an X-Plane developer I am always interested in how things work and the reasoning behind them. I appreciated this as well as the more technical article. They both answered a lot of questions for me.
X-Plane 11 is a major leap forward. Keep up the great work!
Hi Philipp,
Since legacy FMS is going to go out of scope for XP11 (already is according to Ben), will there be any interaction through the SDK for the the new CDUs?
I am asking that to know if anything has been changed in XP11 code to display new curved routes, DME arcs, etc… on planes ND?
Really glad to see X-Plane leveling up on top of all other sims!
Cheers
You can interact with the new CDUs via the command system.
All X-Plane default NDs do display arc segments in the flight plan now (try loading for example KPSP into the default 737).
As for new XPLM functions, see above comment about XPLM.
All great stuff and I have no problem getting updates from Navigraph for GNS430 and UFMC to stay compatible with V10 for the time being.
What I noticed is that there is no mention about airspaces. There is a airspaces folder under Default Data with USA airspaces, and I added an airspaces folder to Custom Data with airspaces data for Canada, etc..
Can you comment about what the correct way is to maintain airspaces, and what LR has in mind for that in the long run?
Custom airspaces in openair format can be installed into Custom Data/airspaces/ You can get them for example from soaringweb.org
We have no plans to introduce a different file format for airspaces.
Yes, I get my airspaces from soaringweb. Just a correction, their URL is soaringweb.org.
Thanks. Fixed.
Thanks for the explanation Phillipp, it looks like you’re positioning the sim Nav wise to be better off in the long run and that, is a good thing. Watching the discourse between folks over this has been interesting for a non dev, however, the writing was on the wall all the way back in December, when Ben posted
“One of my concerns about the public beta has been the number of aircraft I have seen that were developed or updated in the last year or two and yet use authoring techniques that were in the “obsolete but supported” bucket for X-Plane 10. The window of compatibility where we provide support for old and new features doesn’t help if people don’t migrate.”
Thats a pretty good reason why not budging on the change, may be a good thing, past practice shows it to be detrimental.