Petter Jakobsson 0 Posted January 19, 2015 Share Posted January 19, 2015 Hi The route calculation in PFPX 1.18 has some how changed. Previously when finding the route between ESSA and ENGM you would get the correct one, ARS N623 ESEBA. Now with 1.18 you get, KOGAV Z11 OVDAL P600 INREX or RESNA P609 TOR Z132 ULMUG M609 RIPAM, which is around a 100% increase to the GC-distance. The same happens with other route pairs as ESSA-EKCH, ESSA-EGLL, EKCH-ENGM and so on. It seems like the SID/STAR selection is to blame. It does not select the most logical on, some times even the opposite one. I've noticed that other have the same problem since they file the same strange routes when flying on VATSIM and it is a bit annoying handling this when controlling. It worked perfectly before. Please have a look at this. Best regards Petter Link to comment Share on other sites More sharing options...
Aerosoft Jonas S. 466 Posted January 24, 2015 Aerosoft Share Posted January 24, 2015 Hello Petter, maybe upgrading to 1.19 helps! Jonas Link to comment Share on other sites More sharing options...
Ray Proudfoot 231 Posted January 24, 2015 Share Posted January 24, 2015 Jonas, Just found this topic having updated to 1.19. My plan ESSA-EGLL was calculated by PFPX as follows:- RESN4G RESNA P609 BEDLA N866 RAM N581 EVAKI N866 UPGAS UN866 BUKUT UP7 LOGAN LAM3A Taking off on 19R I then turn right and head north for 50nm before doing a 180 and heading SW. Doesn't seem very efficient use of expensive jet fuel. 1.19 seems to have problems selecting the best SID. Link to comment Share on other sites More sharing options...
Petter Jakobsson 0 Posted January 24, 2015 Author Share Posted January 24, 2015 Hi Thx for the reply. Unfortunately the problem still exists in 1.19. Just want to emphasize that this is a problem that did not exist before. The SID/STAR selection is faulty. Regards Petter Link to comment Share on other sites More sharing options...
Ray Proudfoot 231 Posted January 25, 2015 Share Posted January 25, 2015 Another unrealistic route created with 1.19. EGLL-EGPH using westerly runways has produced this. WOBU1A WOBUN L10 BUZAD UT420 TNT UN57 POL UN601 MARGO LANA1A The problem is BUZAD. That waypoint is south east of WOBUN resulting in a very odd route. Shouldn't WELIN be the next waypoint after WOBUN? What's going on? Never remember having problems like this with earlier versions. Link to comment Share on other sites More sharing options...
FlightSimSoft.com 283 Posted January 25, 2015 Share Posted January 25, 2015 @Ray: PFPX is better than you might think here. The 'strange' routes are related to RAD restrictions for certain waypoint/airways. The route EGLL-EGPH looks indeed strange. Taking a closer look reveals: you can't plan via DTY, as the portion DTY Y250 AKUPA is restricted (see RAD restriction EG2458.1). So the PFPX generated route is the 'shortest' route which validates fine with CFMU. You could also plan a BPK departure and go via L10, which would be slightly longer. The ESSA-EGLL route would indeed be possible via ARS. The problem is that this routing interferes with restriction DS5522.5 and is rejected therefore. The route would be allowed according DS5522.3, but has a 'if via' restrictions, which is not yet support by PFPX. If you don'T want to worry about any CFMU route restrictions, you could just disable the routes restrictions in the advanced route finder. Link to comment Share on other sites More sharing options...
srcooke 422 Posted January 25, 2015 Share Posted January 25, 2015 Hello Ray, Additionally to Christian's reply Serge has been kind enough to share his files from the UK Standard Route Document which when installed will provide six routes between EGLL & EGPH covering various scenarios. His post with the link: SRD Whether the SRD forms part of Christians plans for the future we'll have to wait and see Link to comment Share on other sites More sharing options...
FlightSimSoft.com 283 Posted January 25, 2015 Share Posted January 25, 2015 We can pack the UK standard routes in the next installer, if required. The auto-router would than preferably pick these routes for route generation. Link to comment Share on other sites More sharing options...
srcooke 422 Posted January 25, 2015 Share Posted January 25, 2015 We can pack the UK standard routes in the next installer, if required. The auto-router would than preferably pick these routes for route generation. Personally I reference the SRD for all UK and overflights, combined with the RAD it would be most welcome. Link to comment Share on other sites More sharing options...
Ray Proudfoot 231 Posted January 25, 2015 Share Posted January 25, 2015 Hello gents, I'm very grateful for the explanation for my "strange" routes. Whilst I'm an enthusiastic user of PFPX I admit to having limited knowledge of real-world restrictions such as those you cite. I suppose in my naivety I just expect PFPX to produce plans that don't have these odd deviations. By using that option in the Advanced planner I was able to generate the following route:- WOBU1A WOBUN L10 DTY UY250 AKUPA UT420 TNT UN57 POL UN601 MARGO EDN2A Whilst this does break the rule regarding Daventry it does make for a more logical route. I'd be interested to know how real-world flights get around this issue since the WOBUN SID is a popular departure for most US west coast bound flights. BUZAD is usually included on 09 EGLL departures to the NW. Anyway, if I continue to get these 'odd; routes I'll continue to use the advanced planner option. Having all UK routes in a future version of PFPX is appreciated and my thanks to Serge for going to all that trouble. Thanks. Link to comment Share on other sites More sharing options...
srcooke 422 Posted January 25, 2015 Share Posted January 25, 2015 With Serge's SRD files installed one option: EGLL WOBU3F WOBUN DCT WELIN UT420 TNT UN57 POL UN601 ABEVI N601 ESKDO EDN3A EGPH Link to comment Share on other sites More sharing options...
Petter Jakobsson 0 Posted January 25, 2015 Author Share Posted January 25, 2015 Hi Then the problem is the RAD entered into PFPX. If I check the true definition of DS5522 it states: | ARS Not available DEP ESSA/SB Except 1. Via ARS N623 BEDLA N866 LAPSI DEP ESSA 2. Via ARS N623 BEDLA P609 KSD 3. Via ARS N623 IBGAX Not available via ENOS1 sector Not available via ENOS3 sector except via NIBNO 4. Via ARS - PERAX DEP ESSB 5. ARR Stockholm Group, Stockholm Area DS5522 To facilitate correct DEP traffic flow. In PFPX it says: DS5522 ARS Not available for traffic DEP ESSA/SB except ARR ESCM ESKC ESOW ESSA/SB/SE/SN/SU/SX/SZ ESCF ESGJ ESIA ESKG/KK/KN/KT ESOE/OL ESQO ESSC/SD/SG/SH/SI/SK/SL/SP/SW ESVA/VB/VK/VQ EFMA This is obviously wrong. But this is good, now we know what the problem is: faulty RAD restrictions in PFPX. The problem is not for the hard core PFPX users hwo can fix this but as I said befor more of these strange flight plans is showing up on VATSIM by users who rely on PFPX to provide them with a reasonably accurate route. Best regard Petter Link to comment Share on other sites More sharing options...
FlightSimSoft.com 283 Posted January 26, 2015 Share Posted January 26, 2015 @Petter Jackobson In fact the PFPX RAD restrictions are not 'wrong'. They are just not complete (yet). The problem is the 'except via' part in DS5522.3 which is presently not supported in PFPX. We've entered more than 3600 restrictions so far, continously applying revisions all 28 days at no cost for the users. The CFMU RAD scheme is a very complex system. Even professional real world planners regularily fail to produce a valide route without human intervention. It looks like a few users expect better results than the real world products can produce by a tool tailored for home use flight simulation at a very reasonable price. So far, I haven't seen any comparable product for flight simulation that comes even close to the accuracy and depth of PFPX. Link to comment Share on other sites More sharing options...
Petter Jakobsson 0 Posted January 26, 2015 Author Share Posted January 26, 2015 Hi Christian Indeed PFPX is a powerful tool if you know how to use it. I acknowledge that the RAD-function in PFPX is not complete and I look forward to when it is. The problem arise when you put in "not complete" RAD restrictions that prevents normal logical route calculations that are correct and used for real. I do appreciate your work of trying to get them in to the system but I fail to see how DS5522 in any way resembles the real world one. Most of the DS RAD restrictions is based on the assumption that you will use free routing in DK/SE FAB, which PFPX currently does not support. Without the PFPX DK/SE RAD restrictions your system will with high accuracy generate proper routes via airways. The reason for me badgering you with this is because surprisingly many PFPX-users don't understand that they can't blindly thrust the system as long as they get through CFMU-validation. I base this on the ridicules amount of faulty flight plans to and from ESSA on VATSIM. Can you, please, consider removing (until PFPX supports 'except via') some of the "not complete" RADs in the next update to allow for high accuracy airway routing, especially around ESSA. I would gladly help you reviewing the DK/SE RADs. Best Regards Petter Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.