NAVData

Members
  • Content count

    30
  • Joined

  • Last visited

Community Reputation

20 Neutral

About NAVData

  • Birthday 09/09/1970

Flight Sim Profile

  • Commercial Member
    Yes
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No

Contact Methods

  • Website URL
    http://www.navigraph.com

Profile Information

  • Gender
    Male
  • Location
    Vienna

Recent Profile Visitors

200 profile views
  1. NAVData

    PMDG 777 Prepar3d v4 and navigraph

    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.
  2. 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.
  3. 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
  4. No Mr. Mwilk, its reality and the result of hard work. Cheers Richard
  5. NAVData

    EGCC departures

    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
  6. NAVData

    EGCC departures

    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
  7. 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 ...
  8. 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
  9. NAVData

    Unable to select SID transition

    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
  10. NAVData

    RJOO SID ASUKA4 errors at PMDG 777

    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
  11. NAVData

    RJOO SID ASUKA4 errors at PMDG 777

    Hi Dan, first of all - yes, we are a kind of "mammoths" here in the community ... aren´t we? B) I have optimized the coding now on my side, and the golden key is really the direction directive - but it´s partly very tricky because you can´t "translate" the ARINC424 source 1:1 into the PMDG syntax ... anyway, I will do some more testings the next days before I release a second revision of this cycle. Thanks again for your time Dan and take care Cheers, Richard
  12. NAVData

    RJOO SID ASUKA4 errors at PMDG 777

    Hi guys, first of all thanks for some hints here, regarding the wrong turns or the missing turn information. But I have still open question, which is completely unclear for me and I guess, for your customer too: Before I start with my testings - following startup parameter: RJOO on RW32L, in every test scenario the FMC was fully configured and ready for take-off Mystery #1: This line (without the turn directive), produce two different result in the 737NGX and the T7: RNW 32L TRK 322 UNTIL 500 HDG 071 INTERCEPT RADIAL 101 TO FIX ASUKA FIX ASUKA AT OR ABOVE 5000 Result on the 737NGX ND - flight path is correct, a/c flies the turn (left) correct and follow the path Result on the 777 ND - flight path is incorrect, a/c flies the turn incorrect (right) too Question: How knows the 737NGX that the a/c should turn left? There is no reference ... ?? Mystery #2: Now the same conditions but with the turn directive, as suggested RNW 32L TRK 322 UNTIL 500 HDG 071 INTERCEPT RADIAL 101 TO FIX ASUKA TURN LEFT FIX ASUKA AT OR ABOVE 5000 Result on the 737NGX ND - flight path looks incorrect, but the a/c flies the turn (left) and follow the path correctly Result on the 777 ND - flight path is correct, a/c flies the turn correct (left) now too Both a/c´s fly the procedure correctly, but the flight paths on the ND are different Question: Why? How can this happened? And more: how can this be fixed? My conclusion is now, that there must be an incompatibility existing between the 737 and the T7. Both addons use the same information, fly the same path but looks different on the ND. I guess that was what Kuzao and some PMDG customer here mean. It´s difficult to say, what happend with the a/c when you see two rings on the ND (in this case, we know what happened - nothing, but that can´t be a general rule). It´s difficult for the data provider too, because we can´t test all such procedures from month to month - and last: I hope you see, that this is NOT a data issue (this issue exists in the default database which is included in the 737NGX/T777 too) Thanks for your time, Richard
  13. Thank you Philipp, I'm sure Aerosoft will fix this issue in his database latest for the final version because I'm sure that the information is in the Lido database too! Thanks for fixing and thanks to Ryan and Scott for the explanation in this case! Had learned a lot again in this posting! Cheers Richard
  14. Hi Ralf, thanks for clarfication - I'm a X-Plane newbie, sorry! May I ask a question? Can you manual enter the flightplan? Does this work? Cheers Richard
  15. Anyway - this discussion doesn't help Ryan and the other guys here! Fact is, that this IAF waypoints (defined or not) are not in the list and when I had understand the result correctly - this is a bug (or missing link) in the GPS and not a data issue! I guess thats the conclusion now ... Cheers Richard