Improved Routing Information

[tarbat]

Similar flight by the same aircraft.  BAW9263, Gatwick to Heathrow via Scotland!!    Looks like a test or training flight to me.  Datestamp in database explorer is 20100820153506, so just downloaded this afternoon.

[DaveReid]

Similar flight by the same aircraft.  BAW9263, Gatwick to Heathrow via Scotland!!    Looks like a test or training flight to me.  Datestamp in database explorer is 20100820153506, so just downloaded this afternoon.

I've had about a dozen instances this year of BAW9262 departing from Heathrow, usually late morning, and the aircraft in question landing back there late afternoon as BAW9263.

I haven't worked out yet where it has been in the meantime - presumably it has landed and taken off again from somewhere, as changing Flight IDs in mid-air is a big no-no.

[tarbat]

I've had about a dozen instances this year of BAW9262 departing from Heathrow, usually late morning, and the aircraft in question landing back there late afternoon as BAW9263.

Got it as BAW9262 and BAW9263 today, first at 11:50-12:25, and then 16:19-16:41 (BST).

[ACW367]

BAW9*** are charters/training or positioning flights and therefore do not operate a set route, therefore any routing info should be disregarded and deleted.  Could be crew training where they often use Prestwick for circuits.  Other uses could be positioning for maintenance (often into Cardiff) or following an unserviceability.  They also undertake fear of flying flights from various airports around the UK.

http://www.aviatours.co.uk/

[anorak]

Polar Air Cargo PAC956 should you have turn left at PANC :-)

[54901 - Jim]

Another bad route.

[DaveReid]

Another bad route.

There needs to be some intelligence built into the route algorithm such that routes for fractional operators like NetJets, indeed corporate operators as a whole, are  excluded since clearly they don't, as a rule, operate scheduled services.

Only airline flights should be updated.

That doesn't seem to be what's happening, which is daft.

[bratters]

My knowledge of computing begins and ends with switching the things on and off.
However my knowledge of the applications and uses of computers in a variety of businesses is more comprehensive.

Briefly I collect data, collate data, analyse data then act on the findings. In a very fluid and fast moving world it's no use whatsoever having a database that is not only 2 years out of date but seemingly incapable of being brought up to date and kept up to date.

This is one aspect of RB that I fail to grasp - not on the technical side but on the application side.  If I have access to a server in the outside world which itself has access to the latest information, why isn't that data downloaded into my databases automatically?

Currrently we're looking at "routing" and we find two things - firstly, information on changes/new routes is difficult to obtain (we have a "collection" problem) and secondly, where such data is obtainable it does not check - and over-write where necessary - material already in the Database(we have a "collation" problem). One assumes that this applies to every aspect of the field so we may conclude that a percentage of the signals we receive perpetually, and increasingly, show false and out of date information.

This couldn't happen in a large scale commercial operation where  continued existence is dependent on information being bang up to date. I can sympathise with the difficulties in obtaining fresh and current information - never easy -  but I simply do not understand why the latest data from the server does not automatically revise and update the Database on the PC. We seem to be dependent therefore on a "periodic" downloadable upgrade which, while useful, will always be too little, too late.

Have I got the wrong end of the stick? Not for the first time :) - "experts" were always telling me I don't appreciate their problems!

[tarbat]

Currrently we're looking at "routing" and we find two things - firstly, information on changes/new routes is difficult to obtain (we have a "collection" problem) and secondly, where such data is obtainable it does not check - and over-write where necessary - material already in the Database(we have a "collation" problem). One assumes that this applies to every aspect of the field so we may conclude that a percentage of the signals we receive perpetually, and increasingly, show false and out of date information.

I think Airnav have previously explained that route information held on your local database (in the routes table) is deemed to have a shelf-life of 3 months.  If the data in your local routes table is less than 3 months old, then it is NOT refreshed from the central server.  It's a valid data model I guess, although not perfect.

I presume this is to reduce traffic load on the central servers, and to reduce bandwidth usage.

[DaveReid]

If the data in your local routes table is less than 3 months old, then it is NOT refreshed from the central server.  It's a valid data model I guess, although not perfect.

I agree - it isn't perfect, but it's a reasonable compromise.

What isn't reasonable, though, is where the server knows that flight ABC123 lands daily at Airport A, but tells us instead that it's a flight from X to Y.  That's the part that needs fixing, urgently.

[neroon79]

What isn't reasonable, though, is where the server knows that flight ABC123 lands daily at Airport A, but tells us instead that it's a flight from X to Y.  That's the part that needs fixing, urgently.

Exactly, and that's the why I would prefer, that the mechanism should (In my humble opinion) work as following:

Tracking new Flight ID and having Information of TO und LND: Add Info to Database. Well, I guess it may be a good idea to wait until the TO LND paring will be tracked for about three to five times. This will make the information more reliable, but will cause problems with charter flights.

Tracking known Flight ID and TO and LND matches with Data in Database: Do nothing (of course).

Tracking known Flight ID and TO and LND do not match Database Info: Monitor this flight. After three or five Times with same TO and LND Airports update the Database with new Info.

Tracking known or unknown ID with no route Info in the Database and only one of the two (Landing and Take-Off ) known: After seeing an AirCraft with Callsign XYZ123 Landing or Taking Off at a particular Airport for about three to five times add this Info to the Database. This is especially referring to the  local Database.

Why? Because I guess that the information of the destination or the origin is of interest especially if I can't get both Information at the moment. Doing it that way I am able to get at least 1/2 (1/3...) of the route information.

If the last time a particular flight ID was tracked lies more than two or three month in the past: generate an request for updated information and download this information and add it to local Database.

And finally there could be added a plausibility check. Means: If a flight with EGGL as origin and LFPG as destination is tracked several times flying over north/east Germany or south/west of Spain the route information can't be true any more. In this case the route information should be terminated from the Database. "Show no info instead of false info" is -in my opinion- the better way.
A List of these dump-list routes should be downloaded and integrated in the local Database every month.

[EK01]

Well guys we've come full circle on this one. On screen now at 17.53 (Spanish time), RYR96V heading for Valencia, still showing routing as Rome to East Midlands. Therefore old route information (very old according to an earlier post from Dave) is not being overwritten.

I don't think I'll trust any of this routing information for the time being.

[HH]

I'm just playing with PlanePlotter and Findflight. Any opinions if this is less/ equal or more accurate than RB? Until now I can't find any striking differences but I'm using it for only 2 days now.

Markus

[DaveReid]

I'm just playing with PlanePlotter and Findflight. Any opinions if this is less/ equal or more accurate than RB? Until now I can't find any striking differences but I'm using it for only 2 days now.

The two should complement each other (but don't).

FindFlight makes use of various commercial flight lookup websites and is pretty good for regular flights in many parts of the world, but useless for alphanumeric flight IDs when they are used in lieu of flight numbers.

The AirNav system should cope with the latter, assuming that they serve airports that have network coverage, but as we have seen above, once a wrong or out-of-date routing gets into the server database, it stays wrong.

[EK01]

Dave,

Which is the best site you are using to obtain you're routing information. I have now had RYR5DP showing it's route as being from Dublin to Katowice but obviously the flight crew want some overtime as they are flying over Valencia.
Looks like tiresome manual changes are going to have to be made until if/when AN sort this out.

Ian