PMDG and FSLabs have incorrect leg data for certain SID

An interesting problem with the PMDG and FSLabs (and maybe more) aircraft in P3DV5 is that they have incorrect leg data for certain SIDs, with the wrong leg type as compared to real life and other Navigraph data. I did bring this issue up before but with no response or change over several months, so here I will provide more detail and comparison, as the default Navigraph data actually has these legs correct.

I discovered this problem with the Cathedral One (CATH1) departure from Palm Springs KPSP, so that is what I will use for this example, but there may be more like this that I have not discovered.

The real Cathedral One departure from the normal runway 31L requires departing the runway on a heading of 310 until crossing radial 268 of the Palm Springs VOR (PSP), then proceeding direct to said VOR. The leg type would be a VR followed by a DF. The departure from the opposite runway 13R requires a climbing left turn to a heading of 100, proceeding on the 100 heading until crossing the 176 radial of the PSP VOR, then direct to PSP. Another VR to DF.

This is represented 100% correctly most of the Navigraph Navdata, as shown in X-Plane 11. The global data there shows a VR leg followed by DF.

The issue is that the PMDG and FSLabs data do not represent this correctly, instead calling for the aircraft to intercept the 268 and 176 radials respectively. The PMDG data is viewable and clearly a different format from the correct X-Plane data, and clearly shows the command “INTERCEPT” in both cases, which is very much incorrect. In the case of the unique PMDG data it should most likely show “UNTIL” or something similar, as this situation would be very similar to a fly-over waypoint seen on some SIDs, which the PMDG handles just fine.

The FSLabs data is not viewable or editable, but it shows the same intercept command on the FMC and incorrect path on the ND, so I assume the case is very similar if not identical to the PMDG.

I assume this issue is a result of an incorrect manual interpretation of the data, which also makes me wonder if similar issues exist with other SIDs or STARs in the PMDG and FSLabs databases.

Below is the chart for this specific SID, the correct X-Plane data, the incorrect PMDG data, and a comparison between the incorrect result in the FSLabs A320 and the correct result in the Zibo 737.


Cathedral One departure plate


Correct raw X-Plane 11 data


Incorrect PMDG data


Incorrect result in FSLabs A320


Correct result in the Zibo 737

Hi,
to the PMDG issue:
The problem is the limited syntax which makes an “UNITL” or “OVERFLY” not possible. The “intercept” is per se not wrong according the VR leg definition:
image

But what is missing here is the “crossing/overfly” information which can´t be added in the PMDG syntax.

The FSLabs is a own chapter - here please contact the FSLabs devs because the FSLabs interpret our data by his own. We offer the raw data for FSLabs and they interpet it in their addon. Means it´s completely differ to PMDG where we can “define” the logic with the syntax - in FSLabs we offer only the raw data, like for XP11, without any logic behind.

Just an example from the CRJ dataset:

SID,CATH1,31L,1
VR,0,PSP,268.0,310.0,0,0,0,0,0,0,0,0, 
DF,PSP,33.870014,-116.429783,2, ,0.0,0.0,0,0,0,0,0,0,0,0, 
TF,EMRUD,33.794086,-116.251575,0, ,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,1, 
DF,PSP,33.870014,-116.429783,2, ,0.0,0.0,0,0,0,0,0,0,0,0,

You see in the first line the VR-leg, the PSP R268 and the mag course 310 … so all values correct so far, but we have no influence how the CRJ interprets the data and if they use the correct values - the same situation as in the FSLabs addon.

Hope that helps, but in this case we can´t do anything, sorry.

Cheers,
Richard

Thanks for the quick response, much appreciated. I do understand about the FSLabs issues, no worries there, I will probably reach out to them.

For the PMDG though, I was able to achieve desirable results by changing the “INTERCEPT” to an “UNTIL” - this does appear to be a valid input and gave a similar result to the Zibo. It works fine for me, so glad there is a possible ‘fix’ at least on my end.

Thankfully X-Plane seems to have no problem with anything like this for all the default a/c plus the Zibo and Toliss so that is probably where I’ll spend most of my time.

Hi again,
thanks for the input and your effort testing this. I will try to reproduce it and possible I also can build a general fix for that. Thanks again for the hint, I´m honest - I haven´t tested it. I have only looked in the specs and haven´t seen the “until” at the VR leg - therefore my more or less “general” (wrong it seems) answer.

Anyway, I will check, if I can fix this in the PMDG dataset. Please give me a little bit of time - I will not close this thread till I have updated you …

Thanks again,
Richard

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