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.
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 …
But, fine that this can be fixed for two addons
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
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
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
Hope that makes something clearer - I want only to clarify that this answer from ToLiss is not correct.
… but that´s not due the CF35 waypoint … 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 …