RNP not RNP AR Being Filtered Out

Navigation Data General MSFS Data
1

Seems like more airports are deploying new approaches formatted in the RNP(GPS/GNSS) that are linked to runways but may only have Circle to Land data.

These approaches are being coded in a way that when WT G3000 or GNS (NXi currently does not have the filter implemented but it is on their list to do…) pull the airport facility data to get the approaches they return in the same way an RNP AR would return with no RNAV Minima…

SBRJ is a really good example as this airport is now serviced by only approaches that contain RNP Circle to Land options that fall out or RNP AR that should be excluded… So nothing shows up.

This seems like it is only growing with the number of legitimate approaches that are caught up.

Might need to look at the raw data compare it to RNP AR, an LPV and a LNAV to see where maybe these effected RNP to a Runway with only Circle minima might be able to work around this by added some data where it “should not be” if only to make it work…

1 Like
2

This is going to be a growing issue. While I anticipate the (correct) argument being made that this is a WT/Asobo problem - there’s more to the issue.

At the end of the day, these are approaches we should be able to select and while I 100% agree we shouldn’t be having this conversation on the Navigraph side, I think we’re going to unfortunately be forced to for quite a while. It’s become clear from some of the posts on the flight simulator forums that the devs have no intention of solving this at this time. So the question that Navigraph has to answer is:

Do they deviate slightly from real-world data to cater to the simulator or do they stand firm on precisely accurate data and punt this to Asobo/WT to fix and put pressure there?

I personally think it should be a bit of both. I think that Asobo/WT needs to figure out a better way to filter AR approaches than “no minima in the LPV/LNAV” because it’s not just RNP approaches being filtered. There’s a VOR/GPS approach I looked at not too long ago that had the same problem - the approach only had circle-to-land minima so it wasn’t selectable. I would like to see Navigraph provide a temporary workaround to Asobo’s problem, but I understand that Navigraph probably won’t - they’re historically resistant to such things with good reason.

I guess this is a long-winded way of saying “Navigraph, please rescue us from Asobo/WT’s misstep here.”

3

Hi gentlemen,
first of all thank you very much for this posting and I will try to clarify something, even when this is not the answer what you want to read …

We have an official contract with Jeppesen, a real-world data provider and we are very happy with this cooperation. We get fully support from Jeppesen, the data quality is perfect and of course worldwide. That’s the starting point.

The side effect of this is (and that´s part of a good cooperation), both sides must be able to rely on the fact that these agreements will be respected. One of these agreement is, not to change the data itself. We trust Jeppesen, Jeppesen trusts us …

We may add data from somewhere else, but we may never ever change their source data. So, back to this topic. Yes, we could change such approaches, that they will not be filtered out but we may not due our agreements. A second point is, we are not in sync with our charts any longer, when we would do this. So, the answer to this is no - we will not change the approach criteria to bypass this filter sorry.

Due the requests from developers what we receive, we are seeing a tendency to move away from the MSFS bgl format. In most cases, the reason is the dependence to any WU, SU, SDK updates, … from MS/ASOBO. It´s not a “open” system, it´s a closed system and the 3rd party developer have no possibility (or easy possibility) to use data from outside as in the past with FS9, FSX, P3D or X-Plane. That´s for both systems, PC and XBox, the same situation.

In other words, it’s part of MS/ASOBO or WT to remove this filter. We have no real influence on it. Thats a design issue and this can only be fixed by them.

Sorry, but I hope it makes something clearer. We help where we can and we try always to find a solution to help our customer but in this case, we must also look into our contracts and what we can do and what we may not do.

Cheers
Richard

4

Understandable, undesirable but understandable.

Unfortunately, this is quickly going to put more and more people in a situation where this simply can’t be used. Of course, this mistake is on WT/Asobo’s side not yours, but it’s going to start to make people (like myself) seriously consider going back to “default” navdata - less than ideal.

Would it be correct to assume that you do receive the information from Jeppesen about whether an approach is Authorization Required? So if sufficient pressure was placed on WT/Asobo to fix this on their end, you could support if they added an additional field to their data?

5

Circle to land procedures/minima are flagged in ARINC 424 with Qualifier 2 = C. Probably that is also the trigger for WT to filter them. Its up to them to implement them properly.

There shouldn’t be a difference in suppression or not between the default Navblue file and Jeppesen.

Not all real world FMS are capable of handling them. That is probably where the suppression originates from.

For MSFS use I think it shouldn‘t go that deep on which avionic is able to handle which approach. Real world is complex enough.

6

I admit I don’t know enough about the underlying data to understand this.

Let me grab two example approaches, one which should be usable in a G3000 and one which shouldn’t and maybe those can be used to better explain what you are talking about?

For should be allowed: SBRJ RNP L RWY 02R. This is specifically a Cat ABC approach (so piston through medium jet roughly). It only has Circle To Land because the final approach is very much not aligned with the runway (and in fact all it really does is get you down to about 1000’ AGL while avoiding terrain).

Same airport and runway RNP X - this is an authorization-required approach. It should not be available to G3000 and G1000 planes (at least not normally - it’s surprising to me that it’s a cat ABC approach also)

So my question is - is there sufficient information in the data set to differentiate these? What does that look like? And is the difference something that can be set by Navigraph (someone from Navigraph would have to answer) or is it a field that Asobo/WT didn’t bother to include - I know they use a stripped-down version of the actual full data set.

7

RNP L RWY 02R would be a circling with circling only minima:

https://aisweb.decea.gov.br/download/?arquivo=f0a18b69-77bd-44c9-bec658da5bfe0eb5&apikey=1587263166

RNP X RWY 02R would be a straight in with RNP minima:

https://aisweb.decea.gov.br/download/?arquivo=97c528a3-0b06-4c87-95b9383ccbb89015&apikey=1587263166

What WT is probaly looking for is an approach with LNAV or LNAV/VNAV minima:

SBSP RNP T RWY 17L for example:

https://aisweb.decea.gov.br/download/?arquivo=699ce2da-c986-42ac-8f93f9362ae793cf&apikey=1587263166

Circling and straight in would be able to be differentiated via the qualifiers.

8

Hi,
to make it short - yes, there are several ways to filter this in and out from our data but as you wrote, WT must offer the logic behind.

Cheers
Richard

1 Like
9

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.

10

Hi…

This Topic was closed. Which is why I must post another to continue this discussion.

1 - Not allowed to Alter the data… Okay … totally understand agreements and having to stick to them.

2 - WT says they cant in anyway not filter it out and they have looked at all the data… There is something here then in the way it is responded that the base sim needs this addressed. Sometimes it seems like they have the ability to changes these things in the base and sometimes they do not.

So the other part to this topic then is not about Navigraph “supplying” a work around but maybe having to do some lobbying on their own directly to MS/Asobo since WT is saying it needs to be fixed in the base sim.

3 - I guess for Richard? There was an example of two approaches put in that other thread. Would it be possible to get those two examples in the “raw” data as they show in the BGL files when the avionics request the facility data?

Maybe it is possible knowing what each field represents for use to have a look at his.

There are other places as well with some issues so maybe even better would be LFMN

At LFMN there are runway 4L approaches where we have ILS RNP with LPV and an RNP A which is erroneously filtered out as it is not an RNP-AR.

Maybe if possible that those approaches be exposed to the raw data that the sim BGL file is used then some of us could see where the missing holes are.

Again Not asking you to manipulate the data based on that last report… just supply it. If we have to raise a wish list item I would like to have the data and examples to throw up on the board to point to where something is missing.

Yes I could go off and make a JS/HTML instrument that will pull the Airport Facility data and I could one by one extract that data but I would rather just get it straight from you so I don’t make a mistake on that.

And this very well could all be a useless endeavor because they already fixed this in MS2024 and none of the party involved can just say that to us currently.

12

Again, the procedures are still in your AIRAC cycles … you can check it by yourself with as an example the stock A320 NEO, which is currently not using the WT framework (or at least has it not the same limitiation/filter set).

Here both example - SBRJ RNP 02R L:

image
image721×628 20.7 KB

… and SBRJ RNP 02R X:

image
image725×632 21.3 KB

You see, both are included in the data and you can also select it. This filter is set by WT not by us - so please report this to WT. In other words WT is still using the logic to filter such approaches out, so I don´t see any reason, what we can offer more. Sorry.

Cheers,
Richard

13

That is not what I asked Richard. I am asking for the “RAW DATA” that would be in the BGL file formatted as would be pulled out by doing the Facility Request.

What you are displaying is how the avionics “AFTER” parsing it will display it… I understand that non working title avionics see it (guess what I also know how to FORCE WT avionics to see them using the panel.xml tags).

I am not asking you to make it unfiltered… I am asking you to provide the raw data that is in the BGL for the listed 3 approaches at LFMN. From those (and with the Data Filed type) maybe we can find some way or not to suggest WT consider modifying their filter to use a combination of fields.

The fact that your response does not even reference LFMN and you go back to using the example of SBRJ makes it pretty clear that you did not read the entire post and hence your reply is out of context and does not address the request.

If you don’t want to do it just type NO … if you are going to not even give the courtesy to actually read the request in it’s entirety then just don’t respond. Starting the reply with AGAIN is pretty condescending since every word after that is out of context with regards to the post I made.

14

No, we don´t offer any raw data - the SDK is available for all and available for public. What I want to show you was, that the data are existing and are selectable without the WT interface. So, it´s not a navdata issue or what we can fix or we can help. WT filter these approaches, so they know how they can remove the filter or what is needed to identify such procedures. We will follow the SDK, possible that WT set a flag or similar else, what we can set too then.

We are following the SDK schemas and thats all what we can do …

And last, when you read YOUR request exactly, you wrote under #3 that you have also spoken from the procedures at SBRJ and AFTER that from LFMN. I have picked out one example to show you that these procedures are included. Again, please contact WT that they remove the filter in there framwork.

Thank you,
Richard

15

I did not ASK you to show me that they are in non WT avionics. I asked you for the RAW data.

I then elaborated further that LFMN would be a better solution as 3 types of RNAV are there and would give the best data set.

Your response was a condescending AGAIN which is a passive aggressive way to tell someone that they did not read what you already wrote and now you have to write it again.

I never said they were not available … I never said I can’t find them and can you show me the exist.

You want to double down that your response was correct and that it was not condescending only provides examples where you have zero respect for those that pay money which in turn pays you.

WT should not be removing the Filter – those Aircraft NOT capable of RNP-AR should not see RNP-AR.

Your response should be… “We will not provide you the data but we will contact WT and see what we can do offer ideas on how to exclude RNP-AR but retain all of these other newer RNP procedures” …

People like me are offering up our free time to try an help look for a resolution.

I will go now and write some JS myself to pull it out and when I am done I will just have wasted an extra day of my time trying to help YOUR customers… that keep complaining that more and more approaches are not available to them…

IF more and more of them are phased out why will they continue to buy your data?? They will just get frustrated . remove it and find that they don’t have this problem if they use the Stock Nav Data… Then decide they don’t want to pay a subscription anymore if where they fly in the sim is not served by you.

But yeah you do you and and keep telling us to go away.

16

This topic was automatically closed after 13 hours. New replies are no longer allowed.