A double IEEE float is (from memory) a 48 bit mantissa and a 16 bit exponent
It's even 52bit mantissa, 1bit sign, 11bit exponent.
Back to using haversine, haversine gives me 202 NM too for EHLE-EDHK, compared to 205 NM for the supposedly mathematically equivalent formula
For EGKA-LGST, the difference is about 100NM!
Jepp Flitestar reckons 1475.7nm for EGKA DCT LGST.
Looking at the above URL, I can't see how it could be correcting for the non-spherical shape of the earth.
Jepp Flitestar reckons 1475.7nm for EGKA DCT LGST.
That's close to what haversine gives
Looking at the above URL, I can't see how it could be correcting for the non-spherical shape of the earth.
It doesn't
Given the complexity of doing so, the frequency of use of the great circle computation and the rather small error you commit when assuming a spherical earth, I doubt many compute for the non-spherical earth
For IFR join flightplans, set the flight type in the app to Z. In many cases it will find a route; in some cases it finds none. I just tried departing VFR from LSGL with no results. I tried EKAE (grass strip on the Aeroe Island I recently visited) to EHRD (my home base) and it gave me ALS IFR P999 EEL N872 PAM L980 EKROS DCT at FL180.
I can't say yet why it doesn't work some of the times. By the way, we insert the IFR after the first waypoint in the route for Z flightplans and VFR after the last waypoint for Y flightplans. You can move them around and revalidate them against the CFMU/IFPS system, I get the impression that once you have a Z or Y flightplan with either VFR or IFR in there, the route validates about all the time. I use this method for fixing some strange routes that just won't validate. It seems that the Eurocontrol system doesn't know how to validate composite flightplans very well.
So: (1) We have to check the GC distance and offset (2) Fix some problematic routes (I would love to collect them, so keep posting them) (3) See how we can get a better score on composite flightplan route searches (Z/Y flightplans).
Question: who is flying from the UK VFR a lot and has to address the VFR flightplan themselves? We have embedded a VFR addressing engine in our app for these pilots that automates it almost to perfection (ask me for some samples or watch the video tutorial on our website), but since we don't have to do this here in Holland (ARO Schiphol takes this responsibility from us) I have no clue how British pilots do this and figure this out.
UK pilots were "pushed" to the AFPEX tool (basically an AFTN terminal, with some customised forms) and this now implements automatic VFR address generation.
I don't know what % of UK pilots file with AFPEX.
I have a description of AFPEX here. You need to provide a UK address to get access to it, but obviously it works for filing stuff worldwide.
Thanks Peter. I have heard about the AFPEX system, but understood that it doesn't do the VFR addressing for you. You have to manually fill in the addresses. Is that correct? The complaint we get from many ARO offices is that many of the apps and tools used do not address well. That is why ARO Schiphol wants to receive VFR flightplans by fax, so they can address them manually themselves.
Thanks for looking into the Z/Y flight plan issues. And just to be clear, it's not the fpl validation function but the route finder function that needs a slight improvement. If it helps in your config, nearly all Z plns from LSGL that get validated OK from CFMU use SPR VOR for joining.
All the best, GF
GF: we will improve the route-search part. Thanks to all the great feedback. That helps a lot.
In the meantime, what sometimes helps is to find a route from a nearby airport (Geneva), then rebuild in in the route editor to an IFR join from LSGL. But that doesn't work for everybody and every situation. I would have to look on the IFR charts or in SkyDemon to check for nearby routes and waypoints.
I have heard about the AFPEX system, but understood that it doesn't do the VFR addressing for you. You have to manually fill in the addresses. Is that correct?
It didn't used to, for the first 2 years or so. This (and the stupid Java use and Java version dependency of the client app, not working on an Ipad, etc) created a lot of hate of the system among UK pilots.
Also UK airfields lost the ability to just fax a flight plan to the filing office (usually one at Heathrow) so when you turned up with one, they had to stop what they were doing and type it in manually into AFPEX, which they disliked (and still do).
But I found, when filing a VFR flight plan for someone about a month ago, that it now does the VFR addressing automatically. Just enter the dep and dest airports and it fills in the other addresses. They must have added the code into their Java app. It's obviously not complicated - a big lookup table and some conditionals. I had not read about this anywhere but I guess people don't spread good news 
The complaint we get from many ARO offices is that many of the apps and tools used do not address well. That is why ARO Schiphol wants to receive VFR flightplans by fax, so they can address them manually themselves.
The UK used to do this, but closed the centres that used to do it, to save money. They used to process approx. 3000 flight plans a month, nearly all VFR and obviously nearly all light GA. A lot of them were training ones for flying schools. Commercial users, and advanced private pilots, had moved to electronic filing years ago. So for the accountants it was an obvious one to chop...
But the UK has to honour its ICAO obligations / ARO duties, for foreign pilots at least, and you can still fax a flight plan to the AFPEX office. They don't like to talk about it too much though.
I go IFR on nearly all foreign trips so have not filed a VFR flight plan for myself for a long time.
GF: all departures from Lausanne essentially need to go through St. Prex (SPR), Passeiry (PAS) or MOLUS, "thanks" to LS2539F and LS2547B.
So it doesn't always have to be SPR. MOLUS/N0133F110 IFR N871 SOSAL N871 TELNO N871 KORED N871 KONOL N871 BERSU N871 SUREP N871 DITON VFR LSZK works too.
Interestingly, this route validates starting from F110, even though BERSU N871 SUREP only exists starting from F135, and there's AFAIK no other airway between BERSU and SUREP, and LS1A does not exempt BERSU DCT SUREP from the DCT ban. Looks like (another) bug in the Eurocontrol stuff.
The Geneva region has hellishly complex RAD rules. My router took a fairly long time to sort this out.
If you need some specific routes, I can try to compute them for you...
