SAEZ ILS Z RW35 bug

Hi,
Yesterday some friends and I were flying to SAEZ. We selected ILS Z rw35 approach, with GBE6B arrival and transition in GESTA to find out the approach is wrong. It draws a circle above EZE VOR, instead of going straight to the runway. It forces to fly over the airport in a circle to approach it again from the same direction we were flying from.
Charts do not show it, and we’ve validated it with other simmers and air traffic controllers and looks wrong.

Thanks!

Reported to Toliss as well, they will correct the issue in the future…

For me the solution was deleting CF35 (SADP) from airac; because i only use SAEZ…

If you want to keep both CF35 (SADP and SAEZ) you should delete the fix point when landing rw35 SAEZ so you wont be creating that loop… :slight_smile:

Flight Factor also has the same bug, confirmed. It is strange that all developers have a bug reading AIRACS data…

It is not so easy to find the correct & complete index per waypoint. In 95% its enough when you have the region + the waypoint-ident because the waypoint-ident is in most cases unique in this areas. In this special case there are two equal waypoints in the SA region, so it´s not enough to get a unique key … a unique key for terminal waypoints are “RegionCode + IcaoCode + WaypointIdent” — thats unique and you never come in the situation to get a “wrong” waypoint in any terminal procedures.

So, not so strange - it´s difficult and absolutely understandbale … :wink:
But, fine that this can be fixed for two addons :wink:

Cheers,
Richard

1 Like

Thanks Richard for taking the time to review this. This means that we should expect this scenario with multiple, if not all, developers. I’ll work on the workaround you’ve proposed in the other thread.

Could be yes, I wouldn’t rule it out … but I´m honest, I have make a quick check how often this happened … it´s only on a handful airports/regions worldwide but can expand on every cycle, so this should be fixed yes to avoid this in the future :wink:

arrivederci
Richard

This is very interesting regarding safety…

Toliss took advise and will correct this , but its also true what they say, and i quote “I am a bit surprised, because in real life, the waypoint ID + region code should be unique. I don’t think that it complies with the A424 standard to have to use the airport code to identify the correct waypoint.”

if this happens in real life is a mess … having 2 same named points nearby and in the same region…

but thank you very much for explain it so patiently @NAVData :ok_hand:

Hi,
no, sorry that I must correct this - in real life (ARINC424 standard), you have two record-types for waypoints. One for enroute waypoints (record-type EA) and one for terminal waypoints (record-type PC).
Both have the same structure but why then two tables?

Exactly due this reason:
EA (enroute waypoints) are unique with region + waypoint-ident and will be used by airways
PC (terminal waypoints) need an additional filter to be unique region + airport-identifier + waypoint-ident and will be used for terminal procedures.

The terminal procedures reference in most cases to the PC (terminal waypoints), so you have the airport-identifier. EA (enroute waypoints) will be used for airways, so no real connection to a specific airport.

That´s in real and therefore you need this additional filter for the terminal procedures. In reality it works exactly in this way - so no mess :slight_smile:

Hope that makes something clearer - I want only to clarify that this answer from ToLiss is not correct.

Cheers,
Richard

I was told today that the RNAV procedure for RW35 in SADP is suspended. There’s a NOTAM (A1804/2021) about it. Will probably be decomissioned soon.

1 Like

… but that´s not due the CF35 waypoint :wink: … there are a few other terminal procedures with this “issue”.

I only want to aware you, that multiple waypoints with the same ident are possible and therefore it´s necessary to add the airport-identifier in the search to make all unique. Believe it or not, but that´s the reality … and my recommendation. When it will not be changed in the addons, ok - but that´s not a navdata issue, nor a none ARINC424 standard, nothing. It is simple the reality …

Cheers,
Richard

2 Likes

Excelent! so nice to understand the structure point of this.
Thank you for explaining !!!

1 Like

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