Improved Routing Information

[bratters]

Bratters: make your accurate figures. post them here as they will help us to correct the problems.

Will do. Might take a day or two.

[bratters]

Airnav - just to give you an example of a spotcheck right now:
I have 48 ADS-B showing in Myflights of which 28 have routes.


Airline        Flights      Routes

BAW             2             2
DLH              3             0
EIN               7             6
EXS              3             3
EZY              7             5
ICE              1             1
OHY             1             1
RYR            15             6
SHT              2            2
TCX              2            0
UAE              1            1
UPS              1            1
WZZ             3            0

(I don't know whether the routes are accurate or not - another gripe from certain members) 

[AirNav Development]

Bratters: what I wrote before is that less than 1% of the routes shown were wrong, not that 99% of the flights ids had route information.

What we are trying to find is why and when routes are wrong.
regarding improving the number of origin/destination routes we are working on it.

[DaveReid]

We are also waiting for DaveReid's answer.

And Dave Reid has made it clear that he is awaiting an answer first to the question he asked a month ago (and a couple of times subsequently) about how does the new system for deriving routes from positions work.

Or are we suggesting that it's perfectly OK for AirNav to ignore reasonable questions from users, but that the same users must be castigated if they don't supply instant answers to AirNav's questions ?

[AirNav Development]

The answer has not been given because it was developed by an external programmer for the the AirNav FS Live Traffic application. Basically it detects when an aircraft meets certain criteria and gives that flight a condition of landing or take-off from a specific airport. For an example if an aircraft is descending at 700 fpm for a certain period of time, is below a certain altitude and the closest airport is London Heathrow then the destination of EGLL is given to that flight number. Depending on meeting the attributes above a variable is added to each flights. The closest it gets to 0.00 the most reliable is the information given.

[Wayne]

I currently have DLH8XV on my map and the routing is showing EGLL-EDDF but it's actually climbiung out of Manchester,as this flight does regularly. This clearly proves your criteria are not working as you hoped.

The thing is, if I correct this manually using database explorer and set it to EGCC-EDDF then you can be sure your algorithm wil uncorrect it at some point in the future. This is happening lots where correct flights are being overwritten by incorrect data because of some process you have implemented.

[Chris11]

...and flights in and out of FALE (IATA DUR) are still being overwritten as being to and from FADN (IATA DUR) which has been closed for at least 2 months. Other than that flights in South Africa are very accurate.

[flybhx]

I would think multi-sector flights are also a problem for this algorithm. I have just picked up DAL170 from KSLC-LFPG but the database has it as KLAX-KSLC

[bratters]

Bratters: what I wrote before is that less than 1% of the routes shown were wrong, not that 99% of the flights ids had route information.

What we are trying to find is why and when routes are wrong.
regarding improving the number of origin/destination routes we are working on it.

Airnav - what you actually wrote was "we are checking with our programmer regarding the flight route lookup problems which, it is important to underline, affect less than 1% of the flights".

Route lookup problems, not "routes shown problems". My misinterpretation perhaps.

Be that as it may, getting less than one percent of them wrong is frankly meaningless if up to half the routes aren't shown at all.

Just booted up and the attached pic speaks for itself.

Anyway, it's pointless arguing - let's hope the collective brains on here can get something done.

[LSZS]

An other example now:
I inserted this one in april:
DLH9YF  LIMC - EDDM (correct)
Now is show as EDDF - EDDN (not correct)
Timestamp few minutes ago

[AirNav Support]

LSZS,

If you add a route you give it a timestamp. Once 6 months have passed this record is then checked again with our online datbase and changed if it doesn't match.

All,

As mentioned aplhanumeric flight number are not easy to lookup and get routes from. The system we have put in place for this is by no means perfect, it is still being worked on and is the best we can do in gaining these routes.

Some of customers keep emailing us saying surely there is a simple lookup table. There isn't, if there was this whole process would be simple.

[LSZS]

LSZS,

If you add a route you give it a timestamp. Once 6 months have passed this record is then checked again with our online datbase and changed if it doesn't match.

Ok, when i write a new callsign i usually write also the timestamp. For example i write 20100921122800 (now)
This callsign is of LIMC - EDDM since 28th march (the beginn of the summer season 2010).
Unitl yesterday was correct (i read in my log flights table). Today this raw changes. The callsign is still of LIMC-EDDM.
I'm sure that my database is correct (I leave near LIMC airport) and i'm sure that DLH9YF is about the route LIMC - EDDM unitl 30th october 2010.
I'm sorry to say, but your online database is not correct (for this callsing)
I know is difficult job to search for all corrected callsign but progressing well as now i'm going to switch off the autopopulate route option.

An OT question: What's the timestamp? the date of begin validity or the date of until? I have not understood

[DaveReid]

The answer has not been given because it was developed by an external programmer for the the AirNav FS Live Traffic application. Basically it detects when an aircraft meets certain criteria and gives that flight a condition of landing or take-off from a specific airport. For an example if an aircraft is descending at 700 fpm for a certain period of time, is below a certain altitude and the closest airport is London Heathrow then the destination of EGLL is given to that flight number. Depending on meeting the attributes above a variable is added to each flights. The closest it gets to 0.00 the most reliable is the information given.

Thank you for finally answering my question, now that wasn't hard, was it ?

In fact you have also partially answered what was going to be my next question ("why isn't it working ?").

If you'll forgive me saying so, that's a very crude and simplistic algorithm you have just described (and trust me, I know just how difficult it is to fine-tune an airport arrivals/departures detection routine).

However that explains not only why you are missing lots of LHR flights, but may also be the reason why some Gatwick and London City flights are being wrongly reported as Heathrow routes.

To illustrate, I've run some stats for yesterday (20th September):

Of 1135 ADS-B-equipped LHR flights automatically detected by the EGLLADSB website, 118 (10.4%) were listed by RadarBox with either no route at all, or with a route that didn't have EGLL as a From/To/Via. 

I know you said you won't publish a route when you have only deduced one of the airports involved, so you have an excuse for some of those blanks, but there are also a worrying number of routes where you must surely by now have detected LHR landings or take-offs for the Flight ID concerned, but continue to list a route between two completely different airports (like those Cathay and United examples yesterday).

I have no reason to believe that the route algorithm is working any better or worse at Heathrow than at any of the hundreds of other airports covered by the worldwide sharer network (Heathrow just happens to be a handy benchmark), so presumably we're looking here at just the tip of the iceberg.

What do you intend to do about it ?

[DaveReid]

I've run the same analysis for yesterday (21st September):

Of 1047 ADS-B-equipped scheduled LHR flights automatically detected by the EGLLADSB website, 110 (10.5%) were listed by RadarBox with either no route at all, or with a route that didn't have EGLL as a From/To/Via. 

[DaveReid]

Results for yesterday (22nd September):

Of 1134 ADS-B-equipped scheduled LHR flights automatically detected by the EGLLADSB website, 114 (10.1%) were listed by RadarBox with either no route at all, or with a route that didn't have EGLL as a From/To/Via.