IAF to be specified as a transition

[N6722C]

Matt, on the WT Discord, has stated that :-

The Navigraph compatibility is for them to fix. The sim requires, in the sim data, for each IAF to be specified as a transition, which Navigraph does not do

Is this something that Navigraph will address ?

[NAVDataOld]

Hi,
do you have a specific example please? I´m not aware of that …

Thank you,
Richard

[N6722C]

I would suggest you talk directly with MATT at Working Title ( WT Discord).

He is far more familiar with this issue than I am, and since WT is a 1st level dev for MSFS, he should be able to advise you on exactly what the issue is, and how together Navigraph & MSFS/ASOBO/WT can come up with the optimum solution.

Regards
Geoff
wb-sim

[NAVDataOld]

Done, but the answer from Matt was not very helpful - therefore I have asked again for an example to verify it.

Cheers,
Richard

[N6722C]

Welcome to my world of trying to get a straight answer from Matt & WT !!

As far as I can make out, there is an issue with the Current MSFS flight plan software, and its use with the WT Garmins, if the each IAF is NOT defined as a Transition point in the nav Database, and it seems that WT is saying that that is the issue with the Navigarph data.

Ie Not all IAFs are defined as being a Transition point.

Are you able to share what he told you ?

I assume the original MSFS nav database DOES define every IAF to be a Transition point ?

[NAVDataOld]

Yep, no example … but I have made a fast test.

I have checked a few examples and I have found in EVERY of my examples an IAF waypoint in the transition … BUT and thats important I guess, it´s not evertime the first waypoint - the IAF can also be embedded.

According the ARINC specification, a transition must NOT start with a IAF nor that the IAF waypoint is equal a transition.

I have looked into a typical example: KLAX the FIM transition - as an example ILS06L:

The transition is starting with the FILLMORE VOR (FIM) but the IAF is the WAKER waypoint. On the other hand the EXERT transition - this transition starts with the EXERT waypoint which is also the IAF.

In this case, I used the FAA charts (but Jeppesen has the same):

Yellow is the FIM-transition with WAKER as IAF, blue the EXERT-transition with EXERT as IAF.

… and here what I see in the G1000 with the stock-data:

You see a own WAKER-transition in the stock data, which doesn´t exist in real. Also when you look into the FAA data (which will be also used in the stock data) - no WAKER transition:

… and here with our data installed:
FIM-transition (iaf WAKER):

EXERT-transition (iaf EXERT):

So, this transition doesn´t exist in real so we would leave the reality here. I don´t know the Garmins but it is possible that this feature is a unique feature in the Garmins, that every IAF is also a transition … I don´t know. Fact is, that neither the FAA nor Jeppesen has WAKER listed as own transition.

When you look on the TDS GTNXi, you will also see that WAKER is listed but this is done by the GTNXi behind because our data don´t offer a WAKER transition …

Look at the 787, you will also find the WAKER transition and thats wrong (at least for the 787) - so this is a logical issue in the background of the MSFS and not a Navigraph issue.

Cheers,
Richard

[N6722C]

Richard wrote:
so this is a logical issue in the background of the MSFS and not a Navigraph issue.
.
.
.
This stuff is way over my head, as it is not something I deal with every day, or even occasionally.

As far as I am concerned, you (Navigraph) must be the most expert in this area, so from what I can make out from what you are saying, if there is anything wrong, it’s with MSFS, and WT’s implementation of the Garmin, that is causing any issue experienced by the garmins interpreting the nav data.

It si also not clear to me if there is no issue when using the MFSF’s Nav adta, but only when using the Navigraph data.

Its a little Deja-Vue, ref User waypoint, North Pole issue, that was initially blamed on Navigraph, but after a LOT of pushing, Asobo found it was an issue at Asobo’s end , and they finally fixed it.

This one is also probably not going to just “Go away” till there is some meeting of the Minds between Navigraph & Asobo /WT

[NAVDataOld]

Hi Geoff,
I have made a little bit of research:

Also the Garmin data/updates don´t have this transition included but the Garmin devices add all IAF waypoints as seperate transitions too. This is a special feature of Garmin - provider independent.

So, this implementation is correct in the MSFS Garmin devices but the way to this is wrong because WT expect the “additional transitions” in the data. WT hasn´t implement it in the Garmin devices. The result is what I have shown before, you find this “additional transition” also in all FMC/S in the other aircrafts - even when this “additional transitions” don´t exist in real (not in Jeppesen nor in the FAA data).

So, this is 100% a WT issue how they handle the data. It´s simple - they expect data which doesn´t exist in real to build a feature in the Garmin device, but these data can also be used in non Garmin devices and here the data are wrong.

TDS has shown how it works … using real data and implement the features directly in the Garmin device, without changing the real-world data/data structure,

I will mark it as solution now because we may not change our source data and I don´t see any issue on our side.

Cheers,
Richard

[N6722C]

Thanks Richard for looking into this.

So it ends up being a WT issue, that only they can resolve.

Step one, and probably the most difficult, is to convince WT that the issue is theirs to fix.

I don’t suppose in your talks with WT, that they admitted to accepting that ?

[NAVDataOld]

Hi Geoff,
I have opened a “bug-report” in the MSFS dev forum to this issue. I guess, that´s the correct way to report such bugs

Wrong (not existing) approach transitions

Cheers,
Richard

[N6722C]

Thanks Richard

I will watch with great interest to see how Asobo responds…

Geoff

[NAVDataOld]

Geoff, AIRAC 2403 revision 3 is out … We have implement the IAF transition.

Enjoy - hope that helps,
Richard