Before I switched to PF3 I used two different ATC-addons that both could handle AIRAC data (in theory at least...). So when I first looked at PF3 my first thougt was "What a pity this otherwise so promising software does not work with AIRAC data."
Fortunately that did not hold me back and now after two months and dozens of great flights with PF3 I don't miss it at all.
I plan my flight with a flightplanning software that uses AIRAC data. Then I look at the specifications of the relevant SIDs/STARs and decide wether to include the SID/STAR waypoints in the PF3-flightplan or not. I set up the PF3 options accordingly. If I do that properly, PF3 will simulate the real world procedures realistically, thanks to the great flexibility it offers.
Having said that there is no doubt it would be the optimum if PF3 could properly handle AIRAC data. But I consider it a massive task to implement this.
There are so many different characteristics of SIDs/STARs to be dealt with. Some are runway specific, others are not. Some have transitions at the start, some have transitions at the end. Some are only a few miles short, others are more than 100nm long. And while the AIRAC data are up to date, the scenery in the sim ist not. Runway numbers change, runways (and whole airports) are closed, new runways are built. So the AIRAC data won't mtach the scenery in the sim.
All that would have to be considered and may be the source of all kinds of problems. As far as my experience goes, the other ATC-addons are also struggling with it.
So I rather have Dave March spend his resources on other nice little things to further enhance PF3 than on this massive task.
Regards
Ralf
As Peter said above it would screw the approach into Kai Tak. A lot of us fly aircraft without FMCs and they require a different approach to navigation. From what I have seen also, the ATC programmes that "give" you a SID and STAR often give the wrong ones. In practice the fpl filed with ATC by the the airline will also include preferred SIDs if there is a choice that direct the a/c to the same outbound waypoint. If there are different SIDs to the same wypt from the same rwy there are reasons. For example time of day or night, noise abatement, traffic density and so-on. To give an example at Venezia LIPZ. The correct departure for a/c wishing to climb the Alps is ROKIB 6J not ROKIB 6S. ROKIB 6S is the one chosen exclusively by other ATC programmes. It is used only at night and only when Treviso airport is closed as the flight path encroaches on Treviso airspace. The exception is for flights wishing to go via RESIA. That's the sort of thing a flightplanning programme cannot determine and would require human intervention. This is why if any alteration to the present PF3 function is made I would prefer a drop down list box that I could personally populate and choose from.
I know a lot of people already have subscriptions for Navigraph data but a lot don't and it would mean having to have a navigraph subscription just to use PF3. An option that might be workable is for PF3 to have an optional bolt on module. The module specifically handles navigraph data and feeds PF3. So you would have to pay extra for the module and it would ask if you are already subscribed or not. If not then you would have to additionally subscribe. Perhaps it could then direct you to the correct page for that purpose.
Bear in mind that this exact topic has already been raised in this forum and has been discussed. What PF3 does now is not far from the truth in reality. It's just not "random".