Align nav data to 3rd scenary

Hello :wave:
I’m still new to msfs, and I want to understand how the priority of nav dates works here🤔

As I understood from this recommendation:

Developers shouldn’t use manually added nav data in their scenary, because sooner or later it will expire.
only in rare cases should add the manual nav date, for example: when you need to restore the historical situation.

But as we know, many developers still manually added nav data to their scenes for some reason…

Accordingly, I have a question, how does logic work regarding using nav dates in MSFS if the scene already has a manually added nav date (from the scene developer, which is likely to be obsolete or soon to be obsolete), but at the same time we already have we navigraph nav date which has priority high?

My navigraph nav date Install according to these guidelines:
Continuing the discussion from FAQ - Recommendation/using Addon-Linker - content.xml file:

when you use the Navigraph Navdata Center, this app does all for you. You shouldn’t change anything manually. With the upcoming SU10, there is a different way for the priorization but here again, when SU10 is out, you can expect a new Navigraph Navdata Center too which will support the new logic from day one on.

Hope that helps


Of course, I understood this (because I read your recommendations before that), my question was a bit different:

in this case 3rd nav data will it exclude completely and MSFS use only navigraph nav data for all or?

Hi again,
it’s a combination between the data and the a special feature in the Navigraph Navdata Center. Again, with a valid subscription you can use the Navigraph Navdata Center and all will be done in the background.

There are a few other aspects which are only important for developer but when we see this, we get in contact with these developer.

One additional question:
How have you downloaded the navdata without a subscription? Or do you use another account - when yes, which one?


1 Like

I still haven’t received an answer to my question above🥲
I’ll ask a question even simpler: let’s say we already have ILS added by the developer to a third-party scene (which may already be outdated (frequency, course or ILS ID) or will soon become obsolete) we also have a navgraph nav data which has a higher priority, then how can I use the bullet sim logic?:thinking:

at the moment I’m just wondering what is the logic of working with nav date (whether it’s nav date from asobo (nav blue) or yours, it doesn’t matter at case) so as not to get conflicts…

As I wrote before, the logic is in the data and in the Navigraph Navdata Center. You can be sure, that when you use the app, all will be in place correctly and also all will be used correctly.

We have investigated several hundrets of hours for this solution and it works as expected. So trust the Navigraph Navdata Center and you’re on the safe side. It’s your own risk, when you change something.

It’s our own logic that we have developed in the last two years.


PS: conflict of/for what? The navdata are working with in-game addons, also with external ones. So what conflict do you mean here? Can you give as an example?

we seem to be going in circles🥲

Conflict nav data added by the developer to a third-party scenary and navgraph( or asobo nav blue)
nav data which has a higher priority:

that is, for example suppose i have latest navgraph, I will expect the frequency and course ILS a third-party scenario such as in the latest navgraph nav data but in the end, the course will be left or right of rwy or the frequency/iD of the ILS will be outdated(since it was manually added by the developer with an oversight or simply outdated)…
is it possible or not?
or will the navigraph (course in case of correct installation) always have higher priority and we will not get any nav date problems?

Again, please give us an example where this happen? Which 3rd party addon scenery do you refer here which results in a conflict?

Which addon scenery please? That we can try it and after that I can provide a solution, when its necessary but we have no report at the moment about any conflict with any 3rd party scenery.

By the way, the ILS coordinates, runway coordinates, … should always be the same (navdata and/or 3rd party designer) because such information comes from the AIP of the country and are standarized.


1 Like

i can’t name an exact example, but it could probably happen with any third party scenario where incorrect nav date it was manually added by the developer with an oversight or simply because outdated with time…

that’s why you don’t advise third party developers to manually add the nav date to the scenary because either they will have to update it every time there are changes… it’s a useless job since there is a monthly updated nav date from asobo or from you, right?

Thats exactly the reason, why you should use the Navigraph Navdata Center, when you use our data. I can’t speak for the stock data, but with our combination (data + Navigraph Navdata Center) you can be 100% sure, that such information like ILS idents, frequencies, … will be used from our navdata and not the 3rd party scenery addons.


1 Like

but now I have a new question:
as we know (since FSX/P3D) almost all airports(third-party and stock) are to some extent different from true location or runway characteristics (such as length and sometimes width) are different from true.

accordingly, when a developer of a third-party scenary manually adds an ILS to his project, then it is most likely aligned under the runway.

but then, when we start using the navigraph nav data and it has a higher priority, it turns out that it replaces the ILS( and other nav data too) in the third-party scene with one that is based on the true coordinates and characteristics of the runway, respectively, we get not what we expect, namely, the displacement of the ILS relative to the third-party scenario …
What are your thoughts on this?

We don´t offer any sim-updates for FSX nor for P3D so I can´t say anything to it …

But I can´t follow you - when the 3rd party scenery developer uses the same source for the scenery, it should be the same as our data, so it´s irrelevant if we “overwrite” such navigation facilities or not … because the coordinates should be the same, when not, we can check it and normally we inform the addon-devs than (we have made this on an X-Plane scenery dev for two weeks).

There are two much “when - if - then´s” here, to much in the conjunctive. Try our data (one month subscription) and do some tests, you will see that all is on the correct place and works like expected. When not, please come back and report what is not working and we will find out, why it is not working …

Have a nice sunday & a good start in the following week,

that is why this was a big fsx / p3d problem, the new date just quickly became outdated and was also often added manually (scenary developer) to the scenary initially with incorrect characteristics…

in most cases (as I said above) this is not so … often both the width of the ILS of the beam and course / magnetic declination, range differ and sometimes even the GS pitch…

this happens either due to obsolescence of data over time or initially from an oversight of the developer…

the big problem is if initially the coordinates or runway length are slightly different from the truth and if the navigraph package is not aligned to a third-party scenario…

… when we receive such reports, we will contact the 3rd party scenery devs to correct this. Made for a few weeks for an X-Plane scenery …

I can’t say more and I stop this useless “if-when-then” discussion now, sorry … currently, there is no known report existing - so, it looks like it’s not so often as you mentioned.


1 Like