NAVData

Hi Bryan, first of all, thank your very much for the team-work and the extrem professional cooperation in the last couple of days. We have now fixed this issue and have created a new version of the Navigraph Navdata Center (v1.0.5) - from now on, you don´t need to shutdown the NNC and you SHOULD not close it because as I wrote, the NNC does more then offering AIRAC updates - this little tool needs only a few kB in the background but is very helpful to keep the content-file up2date and what is much more important in the correct ordering. Again, thanks for the whole FS2Crew team for the great work ... Cheers, Richard

Hi Bryan, first of all Happy New Year 2022 ... but your statement is not correct. The NNC makes more and should be run in the background. It checks the content-file and re-order it, when someone install a 3rd party scenery that the navdata has always the highest priority. Therefore, it is HIGHLY!! recommended to let the app running in the background. The other solution would be, that you start the app after you have installed a 3rd party scenery but that´s error-prone because most of the customer forget this step (this is the knowledge of the past couple of months, what we have made). Therefore again - the Navigraph Navdata Center SHOULD be run in the background ... May I ask, why do you recommend to shutdown the Navigraph Navdata Center? When you see any issue here, please contact us directly. The Navigraph Navdata Center works nearly since 1 year without any issue. Now you release your addon and you recommend to shutdown the NNC without contacting us before. Thank you very much, Richard

No Frank, what I mean are these restrictions - therefore the IAFs are always after the first transition waypoints. IAF is not equal to a starting point of an approach transition. In this case, the approach-transition are BULGE, ROC and BUF and when these procedures are not authorized, you can enter the IAFs directly, but WASKI, TRAVA and TOPKE are only a part of the approach-transitions but not a transition per-se. Cheers, Richard

TOPKE is a IAF but isn´t a own approach-transition. Therefore you have two possibilities: add the ROC transition and delete ROC, or select only the approach and add TOPKE. The same when you come from north via BULGE - WASKI is also an IAF and when you come from south via BUF, than TRAVA is the IAF. The reasons are the airway arrival restrictions of all these transitions. When you are not authorized for the arrivials via BUF, BULGE or ROC due these restrictions, you may not use these approach transitions and than you must enter the specific IAFs. Cheers, Richard

Hi, this is not a Navigraph issue, it´s more a MSFS issue in their in-game flightmanagement, which will be used in the WorldMap and in all default aircraft models (Airbus, Boeing, Garmins, ...). We have reported such cases to ASOBO (via the 3rd Party Developer forum - when someone has access) and their are aware of it. They have also confirmed that this is a limitation. The "missing" points are all included and also the approach-transitions are correct. Attention! LNM doesn´t read the terminal procedures from the MSFS, it takes the terminal procedures from our external sqlite database file which we provide monthly. So, to compare it with LNM is not 100% correct because this doesn´t really view the real situation in the sim. Currently, the only way to look, if a procedure is complete is the way over the "WorkingTitle CJ4 mod". WorkingTitle has developed their own flightmanagement and doesn´t use the in-game flightmanagement. So, they take the same files from the sim but build their own logic for their mod. So, here from the WT CJ4: FMC page KBUF RNAV33-Y ... and here on the ND: You see, the waypoints are all included - I have only selected the RNAV 23Y approach, with the ROC transition. The WT CJ4 reads all information correct and build also a correct flight path - that´s what is not working correctly in the default flightmanagement system and that´s what is independent of the data you use (stock or our, Navigraph data). It´s the in-game logic, which truncate waypoints, re-build STARs and approaches, and so on ... Again, we still have reported this for months. We had also describe exactly this issue in our "Known issues" category in our forum: https://forum.navigraph.com/t/star-approach-limitation-truncate-waypoints-odd-flightpaths-pseudo-waypoints/4321?u=navdata Hope that helps, Richard

Hi guys, only for clarification - this "issue" with the rebuild of the ARPT_RWY.DAT file has nothing todo with any navdata-provider, nor with the navdata itself. Means, this can happen with NavDataPro also (see a FAQ posting in the AS forum). It´s a PMDG specificum and happens only in the 777 what I know, what I have seen since years now ... So, whenever you have any issues with missing runways in the PMDG try to rebuild the ARPT_RWY.DAT file first. You can do this with the makerwys.exe from Pete Dawsons webpage.

Hi gentlemen, the issue in the FMS Data Manager is fixed now ... it wasn´t a real "issue", the MDF file was corrupt and therefore the client couldn´t copied the file. We have made a new installation packages now and have tested the installation procedure via the FMS Data Manager - it´s working now. So, from now on you can use both - manual installer and our better solution the FMS Data Manager. Thanks again for your patience and have fun with the new addon, where we can offer now fully support ... thanks to Dave too ;-) Richard PS: according the virus-warning - as Pete wrote, disable the AV first ... our files will be checked with virus addons plus, all files are digital signed, so it´s not possible that the file (coming directly from us, Navigraph) will changed in any way.

Hi guys, Dave informed me about the FMS Data issue. I will re-check it. Please download the manual installer and use it. Thank you Richard

No Mr. Mwilk, its reality and the result of hard work. Cheers Richard

Hi Dan, yes, the D053A is defined terminal waypoint in the Jeppesen database with lat/lon (53.36235556 / -2.25713889) ... it´s a "unnamed, charted intersection" and therefore the reference to MCT/032/0.4 (that comes from the Jeppesen source too as "recommanded navaid"). Hope that helps! Cheers, Richard

Here the real, objective truth: Real-world values which come from the PMDG dataset (Jeppesen source) - with or without displaced thresholds, that´s not important. The coordinates are from the center-line (begin/end): Rwy 05L = 53.34755556, -2.28776389 Rwy 23R = 53.36131944, -2.25928056 Fix D053A = 53.36235556, -2.25713889 Now, I have calculated the heading (true) between the points 05L -> D053A and 23R -> D053A: 05L to D053A = 50.991° 23R to D053A = 50.968° You see, the values are identically - there is no reciprocal value, which would indicate that the waypoint is behind the DER. Further calculation, the D053A is approx. 600ft AWAY!! from the DER. All this has nothing todo with the procedure-file or the coding, it´s a simple calculation and everyone can check it ... ok, its more complex to do this, but it´s the only VALID!! way to show that the waypoint is correct and therefore the procedure is correct ... I´m curious about the new answer ... Cheers, Richard

Hi gentlemen, I have seen these posting now and the question/unknown situation about an addon/dev support. Therefore this answer: we have an own developer mail address (dev@navigraph.com) or from the homepage https://www.navigraph.com/Developers.aspx Please use this possibility to contact us - we are supporting every addon developer (when we know anything about the project) and we are happy, when we can provide the data for the specific addon. The idea in XP11 is simple - to have one dataset for all and all means for the scenery designer, for the addon developer, and so on ... so, this is the prefered method. The XP11 dataset is a standardized dataset with a good public documentation. But whenever you need some other formats (or you need more, specific data), please contact us via the dev-address and let us speak about it ... I´m sure, we will find a way to support you and your projects. We (Navigraph) only can open our hands ... we will support you wherever we can. Only my2cents ... ;-) Richard PS: BTW, thanks for the hint, that this process isn´t clear enough on our side - we will work on it, to make it more transparent and easier for you ...

Hi gentlemen, please be so kind and open a topic in the Navigraph forum, whenever you mean, that there is an issue with our database. We can´t have our eyes everywhere - in such cases, it makes more sense to go directly to the developer: directly means to Carenado (via ticket) and/or to us (via a posting in our forum). Thank you very much, Richard

Hi guys, Sarun pointed me to this topic in our forum. I have tried to figure out what the issue is, but I´m not sure, if the solution from you Dave is really a solution. The reason is, that in nearly all transitions are "between" altitude restriction - crazy, unlogic, silly, ... whatever you want but there are these restrictions. I have looked on to the current charts too and again, you see these restrictions. The "solution" is now: to supress all "between" restrictions, which means in all procedures but that can´t really be the solution because sometimes it makes sense, sometimes possible not. Further when you look onto the charts, you see, that there is a Military flying area around Don Mueang, possible that this is the reason for this special restrictions ... So, the question is: Should we really remove the "between" constraints ... ??? By the way, in the PMDG 777, there is no "constraint issue" with exactly the same syntax ... the PMDG 777 uses exactly the same procedure-file as the 737NGX - Here are the current chart of VTBD SID Rwy 21L/R Frank2

But honestly, the developer tries to make the a/c so realistic as possible - power-settings, aerodynamic, systems, ... but you can´t rely on that the a/c flies the path correctly which is shown on the ND? We know (an Jan-Paul had explain it excellent - thank you), that this is a "design-issue" in the procedure files and/or a "design-issue" in the navigation part of the PMDG addons - as an example: Aivlasoft use the same file format as PMDG, but the procedures there shown correctly (left turn and without any additional circles): RJOO - 32L / ASUKA4 Cheers, Richard