Improved Routing Information

[Chris11]

Let's see if anyone else is interested - lots of airports to monitor.

I am happy to monitor FAJS, FACT, FALE and come up with the route changes needed

[tarbat]

tarbat - here is the full up to date route list for 1Time Airline - RNX. I would be grateful if you could do the sql.txt file again.

Attached.

Of course none of this should be necessary - if you're feeding traffic to the network, there's a server somewhere that has access to all this data already, and should already be doing what you have just described  ...

I almost agree Dave.  However, AFAIK non-ADS-B aircraft are not shared on the network, and I really want to get routes for non-ADS-B aircraft, such as Loganair.

[Chris11]

Thanks

[DaveReid]

Results for yesterday (30th September):

Of 1183 ADS-B-equipped scheduled LHR flights automatically detected by the EGLLADSB website, 119 (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.

Carriers affected: AFR, AHY, AUA, AZA, BAW, BEL, BMA, CPA, DAL, DLH, EIN, EVA, FIN, IBE, IRA, MAU, OMA, QFA, SHT, SMX, SVA, SWR, TAP, UAL

Routes involved: Amsterdam, Barcelona, Belfast/BFS, Berlin/TXL, Brussels, Bucharest, Budapest, Cologne/Bonn, Delhi, Denver, Dresden, Dublin, Dusseldorf, Edinburgh, Frankfurt, Geneva, Hamburg, Helsinki, Lisbon, Madrid, Malaga, Manchester, Milan/LIN, Milan/MXP, Munich, New York/JFK, Nice, Paris/CDG, Pisa, Prague, Rome/FCO, San Francisco, Singapore, Stuttgart, Vienna, Warsaw, Zurich

Clearly there isn't enough day-on-day variation to make it worth doing the analysis daily, so I'll run it once a week from now on in the hope that, sooner or later, we'll see an improvement in the results.

[bratters]

Thinking out loud and using the forum as a sounding board, the specific object of the route finding exercise I have in mind is to be able to say  "RYR123AB" definitely took off from here and "RYR123AB" definitely landed here.

It seems to me that no further information is necessary therefore on a KISS basis we could adopt the folllowing method:

Open three Topics:

1. "No-route ADS-B only flights" - confirmed take-offs.

2. "No-route ADS-B only flights" - confirmed landings.

3. "No-route ADS-B only flights" - resolved routes.

Format needs to be no more than say "RYR123AB - EGBB" posted in either the take-off or landing topic.  Posts can be made at any time by anybody relating to any flight at any airport either in singles or lists, the idea being simply to accumulate data.

When we have a match, it goes into Resolved Routes.

About as simple as I can make it - Please discuss.



 

[Chris11]

"Via" routes will give a small problem but can be resolved fairly easily.
The problem is that AirNav have indicated they will not be updating the network database with individual corrections. In fact we have not even had confirmation that they have done the bulk updates already supplied.

Just a question - some airlines provide a list of their flights. These lists will include the Code Share flight numbers. I suppose one would have to add all those to the route database as one does not know who is flying the route, ie what will be put into the transponder

[DaveReid]

About as simple as I can make it - Please discuss.

Sounds like a great idea, although of course it's no more than we have already been told is supposedly being done at the server end.

However I would strongly recommend that, as well as simply recording the fact that flight ABC123 has been seen landing (or taking off) at airport X, you also record the time.

For example, suppose an observer at Aberdeen records a Flybe departure, and a user at Exeter records the same flight landing.

Before you can conclude that you're looking at an Aberdeen-Exeter flight, you need to look at the timings - Flybe's ABZ-EXT block time is 2:45, and there's no way that a Dash 8 would take nearly 3 hours to cover 390nm (the explanation in this case is that it stops at Leeds en route).

So you need to sanity-check the departure and arrival times against the route - ideally you would have users monitoring each on the same day, but failing that you can average the timings over several recorded sightings on different days and still get a reasonable result.

I'd be happy to assist with any number-crunching that's involved.

[Chris11]

I don't think the time is necessary - the via flights can be eliminated by sorting.

In your example - assume we have flight ABC123 that is seen to take off at Aberdeen and Leeds and is seen to land at Leeds and Exeter. If you did a sort on flight numbers you would see the duplicate for ABC123 and by simple deduction the city that has a take off and landing must be the via point.

[DaveReid]

I don't think the time is necessary - the via flights can be eliminated by sorting.

In your example - assume we have flight ABC123 that is seen to take off at Aberdeen and Leeds and is seen to land at Leeds and Exeter. If you did a sort on flight numbers you would see the duplicate for ABC123 and by simple deduction the city that has a take off and landing must be the via point.

But your argument is based on there being observers at all "via" points.  

What if there aren't ?

[bratters]

Chris and Dave - reading through your respective posts I suppose logic dictates if we have the time we should also show the date so that we are not trying to tie up Monday's flight which took off on time with Wednesdays which was three hours late.

That leads us to:

RYR123AB EGBB 01/10 0700 as a standard topic posting format.

The time is some cases may be approximate.

In my case the first I know of a non-route take off from EGNX is when RYR123AB suddenly appears on screen outbound climbing through 3000ft - closest to ground I can get.

[DaveReid]

Just realised, if we're talking about ADS-B aircraft, the direction it appears from, or disappears in, would also be very useful as a further sanity-check.

So initial track, for an arrival, or final track, for a departure, would be a great help too.

[Chris11]

What would be better is to be able to add these to a database directly. I am sure this could be done in a very short space of time.
My IT guy could do one very quickly and we could add to any website

[Chris11]

Spoke to my IT guy - if we give him the fields we need he could bash something together in an hour or so - very basic - an input page and the ability to export the database to excel or csv
(I did promise him a bottle of single malt)

[bratters]

Just realised, if we're talking about ADS-B aircraft, the direction it appears from, or disappears in, would also be very useful as a further sanity-check.

So initial track, for an arrival, or final track, for a departure, would be a great help too.

Nice yes but IMO a bit of a frill maybe? We really only need Observer 1 to confirm it took off from X and Observer B to confirm it landed at Y. ("via" flights can cause probs but these are not the majority)

If we do the job thoroughly there will be duplications - esp. if as anticipated we have more than one observer per airport - but far from being a pain in the butt these would confirm the accuracy of the observations.

A direct entry database chris would be brilliant if poss esp. if it could cope with with multi-duplications.

[DaveReid]

If it's any help, you can use the existing facility at www.flightroutelookup.com/FlightRoute/FlightLookup.wso

It would need a couple more fields to be added to the Update form, but that's 5 minutes' work.