Two naviads, a VORDME and an NBD, near Maurice Bishop International Airport (TGPY) share the name GND. When selecting the VORDME and clicking Add to Route the NDB is always selected. I asked about this on Discord and was requested to post it here so the team could investigate. Thanks!
G’day, I’m not trying to hijack your post here but was just about to post a similar issue. Hoping to kill two birds with one stone here. Let me know if I’m out of order.
I’m trying to use the following flight plan from Simbrief. YCFS/21 DCT CFS W214 RIC V11 BK DCT YSBK/11C. It is a user submitted preferred route into YSBK Bankstown airport, Australia (which I confirmed to be correct). My issue is that when I import it into Navigragh Charts 8 the waypoint RIC comes up as an error on the route. The reason for this appears to be that Richmond AFB (YSRI) has both a TACAN (TACAN, not VORTAC) and an NDB with the identifier RIC. Charts recognises RIC (NDB) as a fix on both the W214 and V11 airways yet it comes up with a route error, presumably because it tries to plot the route using the RIC TACAN which is a fix on neither airway. Is there a way to resolve this? (possibly by way of a drop down box to select the correct one) I can get around it by creating a user waypoint for the RIC NDB and manually inputting the waypoints as the user waypoint is obviously not recognised as a waypoint on any airway, but given that the RIC NDB is the official fix on these and a number of other airways, is there any way that this can be resolved? To make things just a little more complicated, although nearly all the airways that use RIC as a fix are using the NDB as the fix, there is one airway, W144 that uses the RIC TACAN as a fix (W144 is a route from NWA TACAN to RIC TACAN). Thanks.
1 Like
In real world flight planning systems a box pops up allowing me to select which Ambiguous waypoint I want, or in other systems I can enter it - XXX,K6 - I want the XXX VOR in Arinc 424 area K6.
1 Like
Hi everyone! Thanks for the feedback.
@roughapproach that particular issue is a bit easier for us to fix, and it should now work as expected. The issue was indeed that there is both an NDB and a TACAN with the same identifier, and we were previously unable to identify which one was the most appropriate. Since the RIC NDB is the last waypoint on the airway W214, we should assume that this is the waypoint you intended to reach, and with the just-released update, that should be the case!
However, the original question by @myockey is not as easy to solve. The proposed box with a list of alternatives works for one session, but the route string format does not allow the choice to be persisted. That means that one would have to manually select the correct navaid every time that the flight is loaded, at least at the moment. We’ll look into possible solutions when the holidays are over!
In the meantime, we’ll see if we can optimize the route validator so that it prefers the VORDME over the NDB. It makes sense in this case since the VORDME actually has airway connections while the NDB does not, making the VORDME the more likely option! We’re looking into this as well.
Kind Regards,
Malte
1 Like
Nice! Just checked it now and it works perfectly, thanks Malte. I just wish I had told you about it earlier. It’s been bugging me for ages but I’ve just been working around it.
2 Likes
Having same issue as OP. VOR/TACAN/DMEs are being confused with a nearby NDB even when the VOR is selected. In South America NDBs and VORs use the same 3-letter identifiers and near the same airport. Generally, a database uses an entry ID that is unique to all entries. For example, just a 0 - N value determined by when the entry was appended to the DB. Instead of having the DB select a navaid identifier directly, it should really be selecting its row ID to prevent this issue.
A printed and selectable list of duplicates is fairly easy to set up. Loop through navaid names, store appropriate associations in arrays, print navaid ident and assocs, select correct one by DB ID.
i.e.
SELECT ident, type, country, id FROM charts_navaid GROUP BY ident, type, country HAVING count(ident) > 1
If a unique ID does not exist, then a combination of ‘ident’ and ‘type’ can work as well to SELECT. There could be an issue of the same names within the world. Of course, we’d have to provide a distance by plugging it into whatever function Navigraph is using for that such as an X, Y (LAT, LONG) float into some trig expression.
This is super easy to do if you have enough information. However, in this case, we don’t! Our “source of truth” in the Charts app specifically is the route string, which does not contain enough information to uniquely identify any navaid. We only have the identifier, and we try our best to find the best match based on lots of parameters.
Real-world tools have this same issue, which is often handled by showing an error with a list of possible options to make sure that the correct one is identified. This is currently not possible for us, but we have noted this as a potential future improvement in a future rewrite of the routing system.
I hope that this makes sense!
Kind Regards,
Malte