Issue with SID GAXUN1B at SPZO – Missing RF Leg

Navigation Data SID/STAR/APPR
1

Hi Navigraph Team,

I have noticed an issue with the GAXUN1B departure from Runway 10 at SPZO (Cusco) when using AIRAC data in X-Plane. I am currently using AIRAC 2503.

The leg between ZO802 and ZO804, which should be an RF (Radius to Fix) turn, is missing. Instead, the aircraft flies directly from ZO802 to ZO806, completely skipping ZO804 and the necessary curved path.

This is a critical issue because the RF segment is required for terrain clearance, and the current data results in an incorrect and unsafe departure path.

I am attaching screenshots from the Toliss A320 in X-Plane, showing how the RF leg is missing, and also from the FSLabs A320, where the procedure is correctly displayed. This confirms that the issue is present in X-Plane but not in other platforms.

Could you please check if this is a limitation in how X-Plane processes the data or if the RF leg is missing from the AIRAC itself? If the latter, is there a way to ensure it is correctly included in future updates?

Looking forward to your response.

Best regards,
[Grabriel Cevallos]

SPZO2
SPZO2651×568 162 KB

SPZO1
SPZO1841×684 287 KB

FSLABS:

SPZO10
SPZO10598×540 119 KB

2

Hi,
Please report this to ToLiss. It looks like an implementation issue because the leg segment is defined as an RF leg in our source and the X-Plane dataset (which will be used by ToLiss). You see the correct implementation in your FSLaba screenshot.

This is not a navdata issue, it’s an addon issue.

Cheers
Richard

3

Hi Richard,

Apologies for insisting on this, I really appreciate your time and patience. I just wanted to clarify that I have tested this issue in multiple aircraft that use the Custom Data folder in X-Plane, not just ToLiss, and the problem persists across all of them.

If the RF leg is correctly defined in your source, but no aircraft in X-Plane can interpret it correctly, could it be an issue with how the data is formatted for X-Plane rather than a specific addon?

Please let me know if there is any way to verify this or if additional modifications are needed on the Navigraph side to ensure proper RF leg execution in X-Plane.

Thanks again for your help, and sorry for the persistence!

Best regards

4

Hi,
Here, is our XP12 data (what we offer) part for the GAXUN1B departure at SPZO:

SID:010,5,GAXU1B,RW10,RW10,SP,P,G,G   , ,302,IF, , , , , ,      ,    ,    ,    ,    , ,     ,     ,18000, ,   ,    ,   ,SPZO,SP,P,A, , , , ;
SID:020,5,GAXU1B,RW10,ZO536,SP,P,C,E   , ,302,TF, , , , , ,      ,    ,    ,    ,    ,+,12000,     ,     , ,   ,    ,   , , , , , , , , ;
SID:030,5,GAXU1B,RW10,ZO540,SP,P,C,E   ,R,302,RF, , , , , ,004000,    ,    ,    ,0014,+,13000,     ,     , ,   ,    ,   ,RZO18,SP,P,C, , , , ;
SID:040,5,GAXU1B,RW10,ZO544,SP,P,C,E   , ,302,TF, , , , , ,      ,    ,    ,    ,    ,+,13500,     ,     , ,   ,    ,   , , , , , , , , ;
SID:050,5,GAXU1B,RW10,ZO548,SP,P,C,E   ,L,302,RF, , , , , ,006000,    ,    ,    ,0007,+,14000,     ,     , ,   ,    ,   ,RZO62,SP,P,C, , , , ;
SID:060,5,GAXU1B,RW10,ZO552,SP,P,C,E   , ,302,TF, , , , , ,      ,    ,    ,    ,    ,+,14700,     ,     , ,   ,    ,   , , , , , , , , ;
SID:070,5,GAXU1B,RW10,ZO802,SP,P,C,E   , ,302,TF, , , , , ,      ,    ,    ,    ,    ,+,15000,     ,     , ,   ,    ,   , , , , , , , , ;
SID:080,5,GAXU1B,RW10,ZO804,SP,P,C,E   ,L,302,RF, , , , , ,002600,    ,    ,    ,0084,+,17500,     ,     , ,   ,    ,   ,RZO81,SP,P,C, , , , ;
SID:090,5,GAXU1B,RW10,ZO806,SP,P,C,E   , ,302,TF, , , , , ,      ,    ,    ,    ,    ,+,18000,     ,     , ,   ,    ,   , , , , , , , , ;
SID:100,5,GAXU1B,RW10,ZO808,SP,P,C,E   , ,302,TF, , , , , ,      ,    ,    ,    ,    ,+,FL220,     ,     , ,   ,    ,   , , , , , , , , ;
SID:110,5,GAXU1B,RW10,GAXUN,SP,E,A,EE  , ,302,TF, , , , , ,      ,    ,    ,    ,    ,+,FL250,     ,     , ,   ,    ,   , , , , , , , , ;

In segment 080, you see the RF leg to ZO804, which means from the previous waypoint ZO802 → ZO804. When you compare it with the charts, it´s coded correctly. So, it must be another issue, is not a navdata issue, as I have written before.

Cheers,
Richard