I have mismatching databases lately on several airports. Especially regarding the approaches. Install of latest AIRAC worked fine. My MCDU (A32NX) shows the correct cycle. I also use LittleNavMap for flightplanning (latest AIRAC installed). I don’t know if it is a problem with Navigraph or maybe addon airports.
ILS 19L, LittleNavMap shows there’s an approach with BETSO transition (the only trans here, according to LNM). But in the sim (A32NX MCDU) there are two different transitions for this approach (BN and WISPA). BETSO isn’t in there.
Same problems with airports like
I normaly fly in Europe. Havn’t had this problem so far.
What I’ve done so far (with no luck)
- uninstalled latest AIRAC via Navigraph Navdata Center
- removed Content.xml and all files in …\SceneryIndexes\ folder
- launched MSFS to let it build Content.xml and SceneryIndexes again
- exit MSFS
- installed latest AIRAC again
Hope somebody can help.
a very good question - I can confirm (at least your given example with YBBN). I have checked our data and we have ONLY the BETSO transition in our data. I haven´t found any transition (nowhere in the world) called WISPA. There are a transtion called BN somewhere in Africa but not in Australia. So, I have no idea, from where these transitions are … I can only say: not from us because we don´t have it in our source data, nor in the MSFS data.
But I have “played” a little bit now - when I remove the Orbx YBBN scenery, without any other changes of the AIRAC! … I get the correct transition and the only one BETSO. Here a screenshot, AIRAC 2201 rev. 1 installed, Orbx YBBN un-installed:
So, I´m not sure, what the issue here is and I can´t look deeper into the Orbx scenery file. You wrote, that you see the same on the two other airports. Please can you give me example procedures for these two 3rd party sceneries, at least for the BinerSim WIII because I have also this scenery.
Last, please can you try to deinstall the Orbx YBBN and can you look, if you can confirm what I have found out? When the Orbx scenery is not installed, you should see only the BETSO transition. I assume a scenery issue somewhere but again, I can´t really say why and under what conditions this happened. Therefore, possible you have an example for WIII also …
some further investigation:
When you have installed the Orbx YBBN scenery and you scroll thru the approach-pages of the Airbus FMS you will see all approaches twice, in the example two ILS19L.
When you select the first one you get tbe approach with the two wrong transitions.
When you select the second one you get the correct BETSO transition only.
I assume, the scenery has included approaches with these two wrong transitions. As I wrote, I can’t refactoring this scenery file and therefore, its only an assumption but it looks like so. As I have tested before, when you remove the scenery, you have only the BETSO transition and also only one aporoach-type per runway and not multiple. So, it looks really, that this comes from the scenery.
Thanks for your reply, Richard.
It seems I wasn’t patient enough and grabbed the first 19L I found.
I wondered already, why the navdata - some airport developer integrated - should be prioritised over the Navigraph data.
Having at least the Navigraph data also as an option is good enough, I think (since you’re not able to do anything with DRM protected scenery files). I wonder why some airport devs even put in navdata. I would rather rely on Navigraph (or even MSFS default data) then on any data, a dev inserted some years ago.
I’ll check for other mismatches regarding WIII. I will fly there soon. You gonna have the same problem there, since the BinerSim software is also DRM protected (marketplace).
ILS 25R: only transition is PRIOK (according to LMN). MCDU has ESALA and NOKTA. (no PROIK)
But I found the ‘second’ ILS 25R and there is PRIOK as you already checked with YBBN. So we have to live with the wrong airport injected navdata for the time beeing, I guess.
Thanks for the second example, will also look on it … It looks ASOBO/MS/WT has again changed the scenery logic in the content file without any announcement.
Normally, till SU7, the first line in the file has the lowest priority and the last line the highest. Therefore our AIRAC package was always on the last line, to overwrite all information of the installed 3rd party packages before.
For testing, I have moved the ORBX YBBN package now BELOW/AFTER our
navigraph-navdata package and now, you will see only our data, means only the BETSO transition, no multiple equal approach-types … So, it seems they have made any logic change again with SU7.
Will try to find out what they have made … sorry, but thats all very unprofessional and we are always two steps behind.
PS: it could also a big, because the same happens with the stock data, when you don’t have installed the navigraph package
I have looked deeper in the Orbx YBBN issue and when you look in LNM, you see the wrong transitions, which comes definitively from the Orbx scenery.
You see the yellow marker (ie. ILS19L) is the wrong approach, comming from the Orbx scenery. The red-underlining is the correct one from us. So it´s now 100% clear, that this procedures come from the scenery and not from the stock data or our data. As I have written, when you remove our data, you see the same effect with the stock data. Only when you remove the Orbx YBBN scenery, you will see the correct data.
So, they have changed something with SU7 but we currently don´t know what and why …
Following testing your additional example at WIII …
Yes, I own the marketplace version of YBBN (Orbx) which is encrypted. My LNM can’t read / find the Orbx airport and only reads the default and Navigraph data. So I don’t have the ‘fake approaches’ in LNM.
If you’re interested (don’t know if it helps) I can report more mismatches, when I find them. But I think the general issue is found. Very weird by the way - if MS / Asobo changes such a fundamental logic without even saying a word. But we at FBW have to deal with these kind of decisions too.
I can confirm that the errant approach procedures are contained in the scenery afcad, at least in P3D. It maybe these procedures were correct at the time the scenery was published.
Thanks @srcooke … It´s ok so far, the main question here for me is now:
Had ASOBO/MS/WT changed the logic in the content-file or not with SU7 because it looks so … as I have explained, till SU7 the package in the last line of the content.xml file has “overwritten” all information of the packages above. That doesn´t seem to work anymore …
When you put this Orbx YBBN package (which includes terminal procedures and which is ok so far) now at the end (last line), all is good and you see only our data.
In other words -
navigraph-navdata package on last line, doesn´t work:
navigraph-navdata package NOT on the last line (Orbx YBBN on it) works:
So, it´s clear that something is changed since SU7.
It could be interesting to ‘turn the whole content.xml around’ and see what happens.
any news on the issue? I can live with the situation. So no hurry. I’m just interested in what’s going on.
I have reported this to Orbx and yesterday my ticket was updated - here the whole ticket:
I have opened the ticket short after our conversation here, so for approx. a week - we will see what the devs say but for me, it´s clear that the scenery includes the wrong transitions because you see exactly the same, when you use the stock data.
Will come back, when I have an update to this
Have a nice start into the week