-
Hi,
I've managed to increase the number of flights with routing information greatly by mass improrting info by libhomeradar. Now even the majority of Ryanair and Easyjet flights have route info.
Perhaps AirNav could look into a data exchange program with them?
Jon
Follow up: A kind member of the Stansted Airport yahoo group sent me an entire list of Ryanair callsigns and route info. I also use the Heathrow callsigns list given by Knight01 here http://www.airnavsystems.com/forum/index.php?topic=5195.0
I now tend to just lack Thomas Cook (Libhomeradar doesn't have them all) and Flybe (for the flights I pick up in East Anglia)
Here is a pic showing what can be achieved with a little time and effort. It just makes it a bit frustrating and mystifying AirNav's suppliers can't provide this sort of info.
-
It just makes it a bit frustrating and mystifying AirNav's suppliers can't provide this sort of info.
There are industry sources of flight route data, just as there are commercial sources of aircraft data. If AirNav chooses not to use them, that's entirely up to them.
-
Dave, one more time please don't use this forum with hidden commercial objectives.
-
Dave, one more time please don't use this forum with hidden commercial objectives.
On the contrary, simple statement of fact. Feel free to correct me if I'm wrong.
As for commercial objectives, the route data that I provide is free, always has been :-)
-
As for commercial objectives, the route data that I provide is free, always has been :-)
And is as incomplete as many other sources of route data :(
Has anyone found a source of route data for Loganair/Flybe?
(http://farm5.static.flickr.com/4137/4897238514_6dc7589ab5_o_d.jpg)
-
Here we go again.
(http://i454.photobucket.com/albums/qq269/Thebsrman/images.jpg)
-
Blink,
did you have to search one by one or is there a way of getting the data in a useful form for import?
-
Here is a pic showing what can be achieved with a little time and effort. It just makes it a bit frustrating and mystifying AirNav's suppliers can't provide this sort of info.
You might want to update your database - G-TTIA has been G-OZBS of Monarch for a couple of years now, that's why it's operating a MON flight.
-
Thanks - I'll make that change.
My database is hopelessly out of date. I do ocassionally update it with the info you and others posted on here (but don't do it not nearly enough to keep it up to date)
I'm hoping the awaited database update the volunteers are working on will fix a lot of my out of date info
Jon
-
Blink,
did you have to search one by one or is there a way of getting the data in a useful form for import?
No I do it by airline. I use the database search function of libhomeradar to search for all flights by a particular airline (e.g for Easyjet I searched for all callsigns starting with EZY) taking care to take off the just last 24 hours filter. I then cut and paste the results into Excel (I try and get a whole week to cover all flights)
I then manipulate the data in Excel to get it into the correct format to import. I remove duplicates and flights with no route info. I then split the route info into 2 columns for origin and destination and use LOOKUP formulae to convert the IATA digit airport codes e.g STN into ICAO codes e.g EGSS. I save as a CSV and then globally import into NavData. Whole process doesn't take too long (as Excel can be made to do most of the work for you).
Jon
-
I thought perhaps incorrectly that the route data is downloaded from the net by airnav software as planes appeared in network.
Is this correct ?
Since installed software I have not done any updates.
-
It is (if you have that option ticked as I do) but a lot of flights have no routing information populated this way - mainly alpha numeric callsigns. AirNav gets its route info from a company called FlightStats but they tend to not have the alphanumeric route info so nothing is downloaded automatically for these flights. I think it is something AirNav is still investigating ...
http://www.airnavsystems.com/forum/index.php?topic=5190.0
-
Is there any way of alphanumeric callsign origin/destination information that we can use/upload to our central databases? Where?
-
Is there any way of alphanumeric callsign origin/destination information that we can use/upload to our central databases? Where?
I take it that you didn't pursue this, then:
http://www.airnavsystems.com/forum/index.php?topic=5038.msg50476#msg50476
-
Is there any way of alphanumeric callsign origin/destination information that we can use/upload to our central databases? Where?
I can send you what I have (and I'm sure other users would do likewise). However it would be best it you could find a way of using the network to collect the information automatically (mentioned in the thread Dave links to)
Jon
-
So the point is to find out from where a specific flight taking-off/landing and build a callsign database from that information?
-
Yes
-
Doh
-
Left and right hand springs to mind here!!
-
We have good news on this one: we've just finished the implementation of a new server software which will get origin/destination pairs from ADS-B flights (finding the location from where they TO/LND).
Our flight database has now 378K flights.
From these and using the new routine we've just populated 90K flights more which means that we have now information on over 200K flights.
The new server application will run H24 populating our server database which means all client tables (on the RadarBox application) will start to be populated too (if you want to force a re-population simply delete flights from the client table and the software will get them again from the server).
-
How do you force a re-population of flights from my database.
Can you do a multiple delete or do you have to delete each entry.
-
The new server application will run H24 populating our server database which means all client tables (on the RadarBox application) will start to be populated too (if you want to force a re-population simply delete flights from the client table and the software will get them again from the server).
At the risk of showing my total ignorance, what exactly is the "Client Table" please?
-
hello
Good to see progress, however will this not cause an aircraft using its registration as a flight ID cause this problem:
Example - Reg / flight ID GAAAA Flies from EGLL to EGPD and then back to its base at EGKK and then the next day to EHAM and back , then the next day ....
would this not mean that the route of GAAAA = EGKK - EGPD will remain in the database for 6 months although it only did this flight once.
Andrew
-
OMG, AirNav have actually adopted one of my suggestions :-)
-
OMG, AirNav have actually adopted one of my suggestions :-)
Well it seems to be working Dave. Improvement in BAW KLM BMA from first impressions. Still down on Lufthansa and the cheapos.
BTW can you tell me what the "client table" is?
John
-
>"Client Table": flight table of the AirNav RadarBox software (installed on the user's computer).
>Good to see progress, however will this not cause an aircraft using its registration as a flight ID cause this problem
Only airline flights should be updated.
PS: DaveReid you are the best! :-)
-
Hello
I thought there would be something like that in place but wanted to check. Thanks for clarifying.
Andrew
-
if you want to force a re-population simply delete flights from the client table and the software will get them again from the server
Forgive my ignorance - but am I correct in understanding that I use database explorer, select "routes" from the drop down menu and then individually delete each of the records in order to force a re-population ?
Thanks in advance for your advice.
-
Forgive my ignorance - but am I correct in understanding that I use database explorer, select "routes" from the drop down menu and then individually delete each of the records in order to force a re-population ?
I would guess that if and when AirNav finally release an updated NavData.db3 with the updated aircraft database, it will also contain the new routes table, so you may want to wait until then.
-
if you want to force a re-population simply delete flights from the client table and the software will get them again from the server
Forgive my ignorance - but am I correct in understanding that I use database explorer, select "routes" from the drop down menu and then individually delete each of the records in order to force a re-population ?
Thanks in advance for your advice.
Hi Eggplant - I tried the following early this morning:
Stop processing hardware flights/MyLog/Delete old data/Confirm/Empty mylog tables/Exit MyLog/restart processing hardware flights.
Subsequently going into File/Database Explorer/Routes/ I found the Routes re-populated with today's date and time but more importantly including many alph-numerics.
So it looks as if things are on the move.
On the other hand, I could have got things round my neck. Sometimes I fail to understand Airnav-speak.
-
OMG, AirNav have actually adopted one of my suggestions :-)
In fact the idea goes back to a suggestions email to Andre back in July 2008 ;)
Good to see it working at last, now if only we could find an effective solution for non-ADS/B aircraft routes (eg Loganair) - I guess that might need MLAT as a prerequisite.
-
In fact the idea goes back to a suggestions email to Andre back in July 2008 ;)
Just goes to show there's nothing new under the sun ...
Come to that, I've been using the same technique on my EGLL website for the last four and a half years to pick out inbounds and outbounds.
Good to see it working at last, now if only we could find an effective solution for non-ADS/B aircraft routes (eg Loganair) - I guess that might need MLAT as a prerequisite.
Must be due any time now :-)
-
Good to see it working at last, now if only we could find an effective solution for non-ADS/B aircraft routes (eg Loganair) - I guess that might need MLAT as a prerequisite.
Must be due any time now :-)
Well, I dunno about "any time now" but whenever it comes, if it works, it will be well worth the wait.
-
effective solution for non-ADS/B aircraft routes (eg Loganair) - I guess that might need MLAT as a prerequisite.
hello
I wouldn't imagine MLAT would be of much use for Loganair Routes. I would doubt if there will ever be the required number of receivers in close proximity to Kirkwall, Sumburgh , etc for MLAT to work.
Andrew
-
Still getting quite a lot of ADS/B aircraft with no route data. For example, currently got EZY14PW (Aberdeen to Luton) with no route displayed.
To clarify, will the aircraft have to be detected ON THE GROUND at Aberdeen and Luton to create a route record, or just in the near vicinity at a low altitude?
-
I wouldn't imagine MLAT would be of much use for Loganair Routes. I would doubt if there will ever be the required number of receivers in close proximity to Kirkwall, Sumburgh , etc for MLAT to work.
Going off-topic a bit, but you might be suprised. PP users up here can now MLAT some Loganair aircraft quite well. Still only a handfull, but with just 3-4 users in the far north, we would be able to MLAT quite well in Radarbox.
(http://farm5.static.flickr.com/4121/4904091310_70bc0e4fdc_m_d.jpg) (http://www.flickr.com/photos/tarbat/4904091310/sizes/o/in/photostream/)
-
I would imagine that the updating will be after the event and will take a affect after the first flight received using a particular callsign. Will therefore take at least a day until the next flight with that callsign before we notice a lot of difference
-
To clarify, will the aircraft have to be detected ON THE GROUND at Aberdeen and Luton to create a route record, or just in the near vicinity at a low altitude?
I would assume (yes, I know assumptions are dangerous) that the algorithm attempts to identify that an aircraft is on approach based on position, altitude, track and rate of descent, and similarly for one on climbout.
-
I would assume (yes, I know assumptions are dangerous) that the algorithm attempts to identify that an aircraft is on approach based on position, altitude, track and rate of descent, and similarly for one on climbout.
Accepting that assumptions are dangerous, I would suggest that anything based on less than "ground to ground" could lead to an erroneous routing.
This begs the question of how can these new routings can be checked. Presumably this will be by the community themselves spotting that the route to Linate turned out to be Malpensa.
-
Accepting that assumptions are dangerous, I would suggest that anything based on less than "ground to ground" could lead to an erroneous routing.
I disagree.
If properly implemented, such a schema should be extremely reliable. Feel free to visit www.civilaircraftregisters.org/Mode_S_Resources/LogReport/EGLLADSBsearch.asp and let me know if any of the 1.25 million Heathrow movements listed have been erroneously flagged as such. I certainly can't see aircraft on the ground at LHR from here in Reading.
This begs the question of how can these new routings can be checked. Presumably this will be by the community themselves spotting that the route to Linate turned out to be Malpensa.
I would assume (that word again!) that in the same way that new routes can be identified, so the routing for flights already in the database can be validated each time the same callsign is subsequently picked up on approach or climbout.
Perhaps, now that the system is fully operational, AirNav could explain a bit more about how it works to reassure our readers.
-
I stand corrected.
A more detailed explanation would be most interesting and if the new system proves to be the definitive answer to the routing problem, then well done all concerned.
-
if you want to force a re-population simply delete flights from the client table and the software will get them again from the server
Forgive my ignorance - but am I correct in understanding that I use database explorer, select "routes" from the drop down menu and then individually delete each of the records in order to force a re-population ?
Thanks in advance for your advice.
Hi Eggplant - I tried the following early this morning:
Stop processing hardware flights/MyLog/Delete old data/Confirm/Empty mylog tables/Exit MyLog/restart processing hardware flights.
Subsequently going into File/Database Explorer/Routes/ I found the Routes re-populated with today's date and time but more importantly including many alph-numerics.
So it looks as if things are on the move.
On the other hand, I could have got things round my neck. Sometimes I fail to understand Airnav-speak.
Bratters,
Did all the above and just had UPS 1551 flying over the house here near Alicante. Route populating as Bogota to Miami. Going the long way round perhaps ?!
-
EK01 - to quote the Airnav oracle (above in the thread):
"Only airline flights should be updated"
Does that mean that UPS and the other freighters are excluded? In so far as they go up and come down, I can't understand why.
Going back 10-15 years to acars days, it was a pain in the neck to track down some of their routings.
Maybe he's just having a bad day navigationwise.
-
Bratters,
Non ADSB excluded.
Alpha-Numeric excluded (certainly seems to be the case with Ryanair/Easyjet and Air Berlin over here to name but three).
Freighters excluded?
Non airline flights excluded.
Not exactly comprehensive.
As to UPS 1551, maybe he just likes Spain !
-
If the system works as advertised, then there is no earthly reason why alphanumeric flights (and scheduled freight flights) shouldn't be treated exactly the same as any other.
After all, we're simply talking about tieing a callsign to an airport (or pair of airports) based on deducing that a flight is about to land there or has just taken off.
Incidentally, AirNav, how will you handle routes where network coverage only enables you to deduce the origin, but not the destination (or vice versa) ?
-
EK0 1 - I'm not sure you're right about alpha-numerics. They seem to be coming through fairly regularly.
According to my Database Explorer 8 alpha numerics have been added in the past hour so maybe that's 80 a day. As you point out, only a few of those have been Ryanair/Easyjet but as the system has only just been launched I'm holding my breath that we will see a steady build up across the board.
Non ADSB? Flybe numbers are certainly coming through but I haven't checked for others yet.
Overall, I'm quietly encouraged.
-
Dev will have more details to the ins and out of the new addition. Us (support) don't know the techincals behind this fully yet.
Though route data is coming from both FlightStats and this system. This system is based on a similar system we have used for AI flights in Flight Simulator for our Live Traffic flights.
Also be aware the flight needs to be picked up first with that route for it be added to the database (i.e at the start and end airport - more details on how this is worked out from dev) Also before you make a judgement please be aware to check the route in your local database incase its using old data.
-
So far today (20100818time) it would appear that over 80 new alpha-numeric decodes have been added to my Database Explorer, including 9 for BAW.
This covers a period of 8 hours with an average of around 170 flights in MyFlights at any one time.
If this is correct, it's very encouraging.
-
Answering the questions made only General Aviation aircraft flight numbers (their callsign) are excluded. So when we have a callsign without origin/destination information we check if that that is a General Aviation aircraft. If not we get its origin/destination based on ADS-B TO/LNDG Data.
>Incidentally, AirNav, how will you handle routes where network coverage only enables you to deduce the origin, but not the destination (or vice versa) ?
We don't show anything for those flights.
PS DaveReid, you are always so fast reporting that our network is down on other forums it is strange that you forget to report the addition of nice features like this.
-
Answering the questions made only General Aviation aircraft flight numbers (their callsign) are excluded. So when we have a callsign without origin/destination information we check if that that is a General Aviation aircraft. If not we get its origin/destination based on ADS-B TO/LNDG Data.
>Incidentally, AirNav, how will you handle routes where network coverage only enables you to deduce the origin, but not the destination (or vice versa) ?
We don't show anything for those flights.
PS DaveReid, you are always so fast reporting that our network is down on other forums it is strange that you forget to report the addition of nice features like this.
Your only seeing that now, back stabbing is the word your looking for.
from S.F.
-
PS DaveReid, you are always so fast reporting that our network is down on other forums it is strange that you forget to report the addition of nice features like this.
Well there's gratitude for you, that's the last time I suggest any useful enhancements ...
-
Alphanumerics,
Currently on My Flights:
RYR7TB No route
BER66V No route
RYR54MW No route
IBE37LL No route
BER31E No route
But RYR96V showing route as being Rome to East Midlands. Currently flying over Valencia. I don't think so. Route change in database explorer showing the date of 07072010. Not old data as everything was cleared from the system.
-
"07072010" would be old data.
Its not the date from the database online but whens it written to your local database.
-
But RYR96V showing route as being Rome to East Midlands. Currently flying over Valencia. I don't think so. Route change in database explorer showing the date of 07072010. Not old data as everything was cleared from the system.
If it's any help, RYR96V stopped being an EMA flight at the end of March (it's now LEZL-LIRA, which explains why it's overflying Valencia).
-
Over 200 new routes added to my database today, all with dates "20100818hhmmss"
-
But RYR96V showing route as being Rome to East Midlands. Currently flying over Valencia. I don't think so. Route change in database explorer showing the date of 07072010. Not old data as everything was cleared from the system.
If it's any help, RYR96V stopped being an EMA flight at the end of March (it's now LEZL-LIRA, which explains why it's overflying Valencia).
Exactly my point Dave. Route change at the end of March and yet incorrect route details in the 'cleared out' database (using the Bratters method in Post 606).
Airnav
File/Database Explorer/Routes. Is that not the 'local database'. If so that's where the RYR96V information appeared. (Now individually deleted). If that is not the case, what is the best way of deleting all incorrect route details showing with dates before today?
As an aside, still no alpha-numeric flights route details showing.
-
EK01 - as I understand things - and based on something I think Dave said earlier - if the new system works properly, then a wrong entry such as RYR96V will be automatically identified by the fact that it takes off and/or lands in different airport from the expected ones.
Hopefully the error will then be corrected. If however airlines switch routes but use existing numbers, then it will always be a case of catch-up as far as I can see.
I've also got that routing in my explorer but dated but 02/02/2010. apropos of which what exactly does the column title CH mean?
-
EK01 - as I understand things - and based on something I think Dave said earlier - if the new system works properly, then a wrong entry such as RYR96V will be automatically identified by the fact that it takes off and/or lands in different airport from the expected ones.
Well I was describing how it ought to work, only AirNav Development can confirm that's how it does work.
However they did say:
So when we have a callsign without origin/destination information we check if that that is a General Aviation aircraft. If not we get its origin/destination based on ADS-B TO/LNDG Data.
Perhaps they could confirm that existing routes in the database (which could be wrong, as in this case) are being validated as well as new ones ?
-
I would have thought that the routes information is held locally on each users individual computer, same as aircraft data. If you already have information on your computer regarding call sign that will not be over written, same as aircraft data. Unless you delete the existing info on your computer, nothing will change.
It will only be new route data which will be added not existing data over written.
Like the aircraft themselves this will only be corrected by a new data release. Am I correct in this thinking?
Alan
-
Exactly my point Dave. Route change at the end of March and yet incorrect route details in the 'cleared out' database (using the Bratters method in Post 606).
How did you clear out your database? I emptied my routes table (using DELETE and VACUUM SQLite commands), and the 200 routes added today all had date/timestamps of 20100818hhmmss.
-
I would have thought that the routes information is held locally on each users individual computer, same as aircraft data. If you already have information on your computer regarding call sign that will not be over written, same as aircraft data. Unless you delete the existing info on your computer, nothing will change.
It will only be new route data which will be added not existing data over written.
Yes, you are correct in that route data is cached locally (in MyFlights.db3), but that's not the issue here.
The question, as yet unanswered, it whether a user picking up, say, RYR96V for the first time will get the (incorrect) Rome-East Midlands route downloaded from the server, or will routes that are already in the server database be validated so that changes can be picked up and propagated to users.
AirNav ?
-
I don't think we're going to make any further headway here until we get a more comprehensive and detailed explanation of the system from from "Dev".
I would request Airnav that when the detail is published it is couched in terms with which we are all familiar; introducing phrases like "client table" just further complicates an already confusing issue.
We await developments with interest.
-
That would be the "KISS" principle then? :-)
-
That would be the "KISS" principle then? :-)
Same principle and on the same lines as COIK - Clear Only If Known - a caution against the use of technical words and jargon when addressing people outside your own field. Sounds obvious but happens all the time.
-
RYR23UZ showing route EGBE - EGBB
Clearly wrong, the two airports are very close to each other, possible bug with this new system?
-
RYR23UZ showing route EGBE - EGBB
Clearly wrong, the two airports are very close to each other, possible bug with this new system?
I recall in the early days when I was fine-tuning my Heathrow arrivals/departures algorithm that it would occasionally mis-identify flights to/from London City (same runway orientation), so I can sympathise with AirNav's programmers - it's not a trivial exercise by any means.
Having said that, it's common knowledge that EGBE (Coventry) doesn't have any scheduled flights, so I'm rather surprised that the server process attempts to identify departures from there at all.
According to my database RYR23UZ (RYR1085) is EPRZ-EGBB, by the way.
<?xml version="1.0" encoding="utf-8" ?>
- <Flight>
<FlightNumber>RYR23UZ</FlightNumber>
<Callsign>Ryanair 23UZ</Callsign>
- <Leg>
- <Origin>
<ICAOCode>EPRZ</ICAOCode>
<IATACode>RZE</IATACode>
<AirportName>RZESZOW</AirportName>
<Country>POLAND</Country>
</Origin>
- <Destination>
<ICAOCode>EGBB</ICAOCode>
<IATACode>BHX</IATACode>
<AirportName>BIRMINGHAM/ELMDON</AirportName>
<Country>UNITED KINGDOM</Country>
</Destination>
<GCDistanceNM>899</GCDistanceNM>
<DistanceFromOriginNM>845</DistanceFromOriginNM>
<DistanceFromDestinationNM>56</DistanceFromDestinationNM>
</Leg>
</Flight>
-
Routes Error
See attached file.
This Washington to Oregon flight is over Wisconsin as I write this ... definitely taking the LONG way to get there.
Thanks for checking it!
Jim
-
This Washington to Oregon flight is over Wisconsin as I write this ... definitely taking the LONG way to get there.
There shouldn't be any need for complicated algorithms to work out the routings for AWE flights - the entire Star Alliance schedule is freely downloadable from the Net.
<?xml version="1.0" encoding="utf-8" ?>
- <Flight>
<FlightNumber>AWE925</FlightNumber>
<Callsign>Cactus 925</Callsign>
- <Leg>
- <Origin>
<ICAOCode>KPHL</ICAOCode>
<IATACode>PHL</IATACode>
<AirportName>PHILADELPHIA (INTERNATIONAL)</AirportName>
<Country>UNITED STATES</Country>
</Origin>
- <Destination>
<ICAOCode>KPDX</ICAOCode>
<IATACode>PDX</IATACode>
<AirportName>PORTLAND (INTERNATIONAL)</AirportName>
<Country>UNITED STATES</Country>
</Destination>
<GCDistanceNM>2084</GCDistanceNM>
<DistanceFromOriginNM>664</DistanceFromOriginNM>
<DistanceFromDestinationNM>1422</DistanceFromDestinationNM>
</Leg>
</Flight>
-
How do the two differing systems interact with each other? Does the latest idea over-ride Flightstats or is it the other way round? Which is preferential?
Some interesting questions to be answered.
-
Dave: do you have that Star Alliance schedule listing and can you send it to us?
-
Some interesting questions to be answered.
Form an orderly queue, please ! :-)
Actually, I've answered one of my own questions in the meantime.
Perhaps [AirNav Development] could confirm that existing routes in the database (which could be wrong, as in this case) are being validated as well as new ones ?
Routes that are already in the database don't seem to be being checked by the new algorithm. For example the following flights have all landed at or taken off from Heathrow today, and clearly there must be sufficient network coverage of LHR for the algorithm to identify them as such (AirNav routes in brackets):
CPA037 (VIDP-EGCC-LIMC)
CPA038 (EGCC-LIMC-VHHH)
DLH1FW (EDDF-EGBB)
DLH1VV (EDDF-EGCC)
DLH7PH (EIDW-EDDF)
QFA30 (VHHH-YMML)
UAL931 (KSFO-KLAX)
UAL948 (KLAX-KDEN)
IMHO, detecting that a a route arrives or departs from an airport which isn't consistent with the route currently in the database ought to be sufficient to invalidate that route record until it has been investigated.
-
Dave: do you have that Star Alliance schedule listing and can you send it to us?
www.staralliance.com/assets/doc/en/services/tools-and-downloads/pdf/StarAlliance.pdf
-
We need the list in xml format, not in pdf.
-
We need the list in xml format, not in pdf.
What XML tags?
-
These:
<?xml version="1.0" encoding="utf-8" ?>
- <Flight>
<FlightNumber>AWE925</FlightNumber>
<Callsign>Cactus 925</Callsign>
- <Leg>
- <Origin>
<ICAOCode>KPHL</ICAOCode>
<IATACode>PHL</IATACode>
<AirportName>PHILADELPHIA (INTERNATIONAL)</AirportName>
<Country>UNITED STATES</Country>
</Origin>
- <Destination>
<ICAOCode>KPDX</ICAOCode>
<IATACode>PDX</IATACode>
<AirportName>PORTLAND (INTERNATIONAL)</AirportName>
<Country>UNITED STATES</Country>
</Destination>
<GCDistanceNM>2084</GCDistanceNM>
<DistanceFromOriginNM>664</DistanceFromOriginNM>
<DistanceFromDestinationNM>1422</DistanceFromDestinationNM>
</Leg>
</Flight>
-
I recently flew on a on sector (KBUF-KBWI) of a route that possibly has the most daily sectors and winding route.
Southwest Airlines SWA364
http://flightaware.com/live/flight/SWA364
KBUF-KBWI-KMDW-KLIT-KDAL-KMSY-KTPA
Buffalo-Baltimore-Chicago-Little Rock-Dallas-New Orleans-Tampa
I don't think the system can cope with that one!
-
We need the list in xml format, not in pdf.
That wouldn't really help you - the XML comes from a relational database that can handle multiple (i.e. more than two) legs per flight:
<?xml version="1.0" encoding="utf-8" ?>
- <Flight>
<FlightNumber>UAL840</FlightNumber>
<Callsign>United 840</Callsign>
- <Leg>
- <Origin>
<ICAOCode>YMML</ICAOCode>
<IATACode>MEL</IATACode>
<AirportName>MELBOURNE</AirportName>
<Country>AUSTRALIA</Country>
</Origin>
- <Destination>
<ICAOCode>YSSY</ICAOCode>
<IATACode>SYD</IATACode>
<AirportName>SYDNEY (KINGSFORD SMITH)</AirportName>
<Country>AUSTRALIA</Country>
</Destination>
<GCDistanceNM>381</GCDistanceNM>
</Leg>
- <Leg>
- <Origin>
<ICAOCode>YSSY</ICAOCode>
<IATACode>SYD</IATACode>
<AirportName>SYDNEY (KINGSFORD SMITH)</AirportName>
<Country>AUSTRALIA</Country>
</Origin>
- <Destination>
<ICAOCode>KLAX</ICAOCode>
<IATACode>LAX</IATACode>
<AirportName>LOS ANGELES (INTERNATIONAL)</AirportName>
<Country>UNITED STATES</Country>
</Destination>
<GCDistanceNM>6508</GCDistanceNM>
</Leg>
- <Leg>
- <Origin>
<ICAOCode>KLAX</ICAOCode>
<IATACode>LAX</IATACode>
<AirportName>LOS ANGELES (INTERNATIONAL)</AirportName>
<Country>UNITED STATES</Country>
</Origin>
- <Destination>
<ICAOCode>KORD</ICAOCode>
<IATACode>ORD</IATACode>
<AirportName>CHICAGO (O'HARE INTERNATIONAL)</AirportName>
<Country>UNITED STATES</Country>
</Destination>
<GCDistanceNM>1512</GCDistanceNM>
</Leg>
</Flight>
As the previous poster points out, the simplistic From/To/Via structure of the NavData flights table can't handle that - UAL840 never gets as far as Chicago in your database.
-
B772 G-VIIW operating BAW9262 on MyFlights this morning, route showing as London City to Gatwick.
Now that's a departure I'd like to have seen !!
-
B772 G-VIIW operating BAW9262 on MyFlights this morning, route showing as London City to Gatwick.
Now that's a departure I'd like to have seen !!
The route date in my database explorer for BAW9262 is 11 August 2010 so presumably it was a Flightstats jobbie rather than a result of the new Up&Down system.
-
The route date in my database explorer for BAW9262 is 11 August 2010 so presumably it was a Flightstats jobbie rather than a result of the new Up&Down system.
I suspect this came from the new TO/LND system.
An engineering/test flight? - see http://www.kineticavionics.co.uk/phpBB3/viewtopic.php?f=5&t=12706#p97275
I would presume that Airnav ran this new TO/LND routine for a few days before announcing it and activating the feed into the routes database.
-
Bit of a red herring here - that Kinetic posting on June 3rd was DR himself.
Doesn't seem remotely connected with matters in hand.
-
Okay, I thought it was relevant to mention that BAW9262 was thought to be a test flight back in June, so may still be a test flight. And it's not on Flightstats, so may have come from somewhere other than Flightstats.
If it did come from the TO/LND system, then that would suggest some flaws in the TO/LND system.
Or it might be an old, out-of-date positioning FlightID from earlier in the year - see http://www.airnavsystems.com/forum/index.php?topic=4558.msg45828#msg45828
-
The route date in my database explorer for BAW9262 is 11 August 2010 so presumably it was a Flightstats jobbie rather than a result of the new Up&Down system.
Somebody correct me if I'm wrong, but AFAIK the query that RadarBox sends to the server to get a flight routing only returns a bit of pseudo-XML like this:
<ANLVStart>
BAW285,EGLL,,KSFO,
<ANLVEnd>
So there is no way of knowing how old that route data is, or whether it has come from FlightStats or is derived from the new algorithm.
All that the date string in Database Explorer tells you is when it was downloaded, not when the record on the server was created.
-
So can the download to Database Explorer pre-date when the record on the server was created?
I thought it was only recently that TO/LND system was introduced - like three days ago. But if that system provided the routing, how can the Explorer entry be dated June?
Ugh! I'm getting seriously CONFUSED here. Only "Dev" has the definitive answers (?) and he, she or it is keeping decidedly stum.
-
That is correct Dave.
The dates in your local database only show when you downloaded the data from the server.
-
So BAW9262 routing London City to Gatwick has nothing to with TO/LND then.
-
I thought it was only recently that TO/LND system was introduced - like three days ago. But if that system provided the routing, how can the Explorer entry be dated June?
I thought it was 11th August? Anyway, my guess is that this routing came from an old flight earlier this year, possibly during re-positioning flights. I guess that once a route gets into the database, until it's replaced with something more recent, it stays there forever.
-
Correction on my part - my Explorer entry 11th august. Dave's Kinetic entry in June.
Neverthless, reading Airnav's posts I gain the impression that TO/LND is fresh out of the box and I'm sure you're right Tarbut.
-
I guess that once a route gets into the database, until it's replaced with something more recent, it stays there forever.
Yes, see my earlier post re yesterday's (and today's) Heathrow flights which are wrong on the server and are clearly not being validated by the algorithm.
That strikes me as a fairly fundamental shortcoming of the system - if the network detects an aircraft landing at Heathrow, e.g. this morning's UAL948, why persist in pushing out the route as KLAX-KDEN ? Even FlightStats will tell you that the flight continues to LHR.
-
How complicated would it be to enable the database to be instantly over-written by the latest data from the server?
-
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.
(http://farm5.static.flickr.com/4076/4910697984_059fa61123_o_d.jpg)
-
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.
-
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).
-
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/
-
Polar Air Cargo PAC956 should you have turn left at PANC :-)
-
Another bad route.
-
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.
-
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!
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
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
-
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.
Well, as I said above, with alphanumeric Flight IDs there aren't many options, which is why I was initially delighted when AirNav adopted my suggestion of deducing routings from landings and take-offs. The commercial sites are only really of use for timetable flight numbers - for example to find RYR5DP on FlightStats you need to search for FR5152 (Marseilles to Marrakech). I've been using the technique successfully (with permission) on PlanePlotter network data.
Looks like tiresome manual changes are going to have to be made until if/when AN sort this out.
It's disappointing that so far AirNav have made no comment whatsoever about how (or even if) they plan to deal with incorrect routes on the server, which the new routine ought to be picking up but clearly isn't.
-
Cheers Dave,
Ian
-
I'd like to re-open this thread to inform that today I find 3 flights with wrong Route informations.
Theese flights are:
DLH3KY show as EGLL - EDDM instead of the correct LIMC - LIBD
DLH6HV show as EIDW - EDDF instead of the correct LIMC - EDDF
DLH1EP show as EDDL - EGLL instead of the correct EDDF - LIML
all with timestamp 20100912....
No route information about the BEL351.
An other question: What i do to haven't incorrect informations on 31 october when callsigns change?
Lufthansa this year changes all flights numbers
Must I delete all routes?
-
I would suggest there could be major problems with incorrect routes/flight ID's etc come the end of October when airlines change to their winter schedules.
-
Lufthansa this year changes all flights numbers
Must I delete all routes?
Thanks for that post LSZS which explains something I didn't know
I have been one of the main moaners about lack of route information. particularly as it seemed mainly related to UK lo-cost airlines, Ryanair, Easyjet, Thomson etc.. - big users of my local airports.
However I had also noticed that virtually no Lufthansa flights were showing routes and wondered what the problem was. Now I know.
Heaven help us if reverting to winter schedules means further substantial changes to callsigns - I can't see why wholesale changes should be necessary though.
-
Bratters,
Let's hope you're correct with regard to the changeover to the winter schedules routings because currently it's a bit of a shambles. Alphanumeric flight number routings still don't appear !
-
We will refresh the database then to pick up the new winter routes so they can be downloaded then.
Regarding Alphanumeric we are doing the best we can. We have joined forces with a flight schedule & tracking website to gain this data and implemented our own algorithms to identify routes from positions. Considering both those solutions can't provide all the data gives an indication of how hard this task is. Both of the solutions are being worked on to get these more accurately.
-
Thanks AN for the update,
More 'power to your elbow'.
Cheers,
Ian
-
Not much more to say then. I guess we'll have to live with it for a while longer.
-
Thanks to all.
I have an idea about the alphanumeric callsign.
I'm sure that Lufthansa has 2 "packs" of callsign. Winter season and the Sommer
The summer 2010 callsign are the same of the summer 2009, but different (all) from the Winter
I've ANRB since septembrer 2008 and I noticed this about DLH.
Easyjet, here in Northen Italy (but I think all the system) keeps the same callsign, Airfrance, Alitalia, Iberia ecc. too
I think that in the night to 31 October I reset the table of routes.
And here is where i read the systemwide change oh LH flightnumbers:
http://airlineroute.net/2010/06/15/lh-w10-fltnbr-update2/ (http://airlineroute.net/2010/06/15/lh-w10-fltnbr-update2/)
-
LSZS
Although the flight numbers alternate the alphanumeric codes seem to change at randon each timetable change here.
-
Today I founded my entries in the route table corrected with incorrected routing information.
DLH1KC isn't EDDM - EGLC but EGLL - LIMC
-
Today I founded my entries in the route table corrected with incorrected routing information.
DLH1KC isn't EDDM - EGLC but EGLL - LIMC
If the AirNav route algorithm were working as advertised, there wouldn't be any need for you to make your own corrections like this.
DLH1KC pops up on the network 6 times a week taking off from Heathrow, so there's no excuse for the server listing it as a London City flight.
-
I remember that I inserted this callsign in May or June whith routing from EGLL.
Today I founded it incorrected
But isn't the only. Others but now I don't remember what
-
But isn't the only. Others but now I don't remember what
Get used to it.
Over 100 scheduled flights at Heathrow yesterday were showing incorrect or blank route information on RadarBox, for the following carriers:
AFR, AUA, AZA, BAW, BEL, BMA, CPA, DLH, EIN, EVA, FIN, IBE, IRA, MAU, SHT, SMX, SVA, SWR, TAP, UAL
Leaving aside the issue of whether the route algorithm is or isn't working, I really can't understand why a flight like, say, UAL948 - which all the flight tracking websites will tell you operates from LAX to Heathrow via Denver - doesn't come anywhere near Europe according to AirNav.
-
But isn't the only. Others but now I don't remember what
Get used to it.
Over 100 scheduled flights at Heathrow yesterday were showing incorrect or blank route information on RadarBox, for the following carriers:
AFR, AUA, AZA, BAW, BEL, BMA, CPA, DLH, EIN, EVA, FIN, IBE, IRA, MAU, SHT, SMX, SVA, SWR, TAP, UAL
What is "over 100 scheduled flights" percentage-wise Dave? Is it a significant figure?
Bearing in mind that those carriers are not, for the most part, what we might term "the usual suspects", this is not good news.
LSZS's post also emphasises that, unless one has a specific interest in particular flights, many of us blithely accept false information until/unless something blatantly stupid virtually jumps off the screen.
Are we reaching the stage where we need to go back to the drawing board on routing or are we still dealing with relatively small percentages?
-
The figure for missing/incorrect Heathrow flights typically runs at around 10-15%.
Yesterday's total wasn't quite as bad as normal, but still includes lots of flights that operate every day (for example BAW38TP LROP-EGLL).
And bearing in mind that there are literally dozens of sharers in and around Heathrow feeding arriving and departing flights into the network, it's crazy that the server persists in telling us that, for example, CPA007 is a Hong-Kong-Delhi service, or that Shuttle 9J (inbound every afternoon from Edinburgh, for donkey's years) is a mystery flight with unknown origin and destination.
-
I would have thought that UAL948 and CPA007 -as quoted by you- were Flightstats' bread and butter.
Are they perhaps being over-ridden by the new system or just cock-ups?
-
Are they perhaps being over-ridden by the new system or just cock-ups?
We will probably never know - AirNav have had plenty of opportunity to explain to us how this new system is supposed to work, but have declined to do so. I see no reason to expect that they will respond this time either.
Frankly, I see no evidence whatsoever to show that the system is working.
-
The figure for missing/incorrect Heathrow flights typically runs at around 10-15%.
There is absolutely no excuse for long standing flights that have no routing information. I just hope that AirNav are giving this serious consideration and won't be just another example of a company that takes your money and lets you sweat.
I'm sure that's not the case. Would AirNav like to comment about the accuracy and frequency of updates in the master files when this eventually gets sorted?
-
DaveReid: if you have a list of callsigns/origin/destination which is more accurate than that maintained by AirNav and used by all RadarBox users, why don't you share it with all of us?
-
DaveReid: if you have a list of callsigns/origin/destination which is more accurate than that maintained by AirNav and used by all RadarBox users, why don't you share it with all of us?
Are you seriously suggesting that the reason for your routes database being so bad is because I'm not sharing data with you ?
Now I've heard everything ... !
-
DaveReid: if you have a list of callsigns/origin/destination which is more accurate than that maintained by AirNav and used by all RadarBox users, why don't you share it with all of us?
You have a brassneck cheek, I'll give you that.
Just about any other database is more accurate than the one you are pimping out to the masses.
Maybe if you offer him free realtime he might consider it (tongue in cheek).
-
Hello
I know there are problems with the routings from Airnav but if Airnav had 500 thousand flight numbers on their database and one was wrong we could all be sure of having Davereid complaining about it on the forum. Also Dave you don't mention the missing routings on your own lookup that is far from perfect (for example no Loganair routes etc.
Andrew
-
Hello
I know there are problems with the routings from Airnav but if Airnav had 500 thousand flight numbers on their database and one was wrong we could all be sure of having Davereid complaining about it on the forum. Also Dave you don't mention the missing routings on your own lookup that is far from perfect (for example no Loganair routes etc.
Andrew
You can defend AirNav all you like but the fact of the matter is that the database is woeful. It's not just one or two missing or wrong it's a much greater number than that. One hour on the box in my area alone will reveal considerably more than one error just in flight routings, multiply that by many hours of watching and the problem is self evident.
I don't ever recall Dave saying that his database was the best thing since sliced bread either. Don't forget, it's AirNav that are asking him for help, not the other way round.
Andrew, you need to wipe your nose matey, there is a nasty brown residue showing!
-
Southwest we don't like to keep these kind of discussion on our forum but it is important for our forum members to know that at the same time you post these comments here, you are part of an Internet forum created with the support of our competitors to try to daily damage RadarBox reputation, posting similar comments there.
It is really really bad to know that there are users that instead of enjoying this hobby like 99% of us, spend their time in these kind of games. Please respect the RadarBox community.
-
Airnav Development,
Many of us are members of many fora related to our hobby, they are not set up to try and damage either Airnav or Kinetic. As a customer of both companies I still reserve the right to complain if there is a problem with either the equipment or the service provided by either of you.
With regard to the flight routings both Companies have exactly the same problem. Is there the possibility of being able to upload new data to the central database when we update our own database with new routes as the new algorithm being used is obviously having some issues
-
Flybhx: tks for your input. The problem here is not the right to complain but the artificial complaints put but the same users who later play with the posts on another forum who is supported by our competitors. We don't want to ban these users but lack of respect for our forum and our user base is something that we will not allow to happen.
Now back to what matters: 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. We are also waiting for DaveReid's answer.
-
Now back to what matters: 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.
Airnav - if only 1% of Myflights had routing problems I wouldn't have even noticed, let alone complained about it. Nor I suspect would anyone else.
As it is, the figure here in UK is way way higher than that. I'm quite prepared to settle down and produce some accurate figures if you insist but take it from me you're looking at 10 times that at the very least.
Nobody would make a fuss about less than than 1% - let's get real here.
-
Bratters: make your accurate figures. post them here as they will help us to correct the problems.
-
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.
-
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)
-
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.
-
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 ?
-
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.
-
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.
-
...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.
-
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: 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.
-
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
-
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,
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
-
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 ?
-
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.
-
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.
-
If anyone is interested I can supply a complete list of Flybe alpha numeric callsigns as I work as crew for and we get the complete list .If this would help I will work on putting it together over the next couple of days and post .
Cheers,
Mark
-
That would be a major help as Flybe routings seem to be quite a problem
Kev
-
As I live in North Devon Flybe is a major part of my traffic, yes please Spanman.
-
As promised please find attached a comprehensive list of Flybe Alpha numeric callsigns,Any probs opening them please e-mail me and I will send them to anyone who wants them.It was produced using open office. There will still be the odd gaps but I'm sure you will agree it certainly helps
-
Thanks - a great help.
Attached CSV file suitable for import to your routes table. This has added 433 new entries in my routes table, and updated 17 others. Maybe Airnav can add these to the central server routes database - should only take a few minutes to do.
-
Morning All,
Please could some kind soul, advise us computer numpties, how to add the routes to our individual routes database.
Many thanks
Phil
-
Please could some kind soul, advise us computer numpties, how to add the routes to our individual routes database.
Well, I use SQLite Maestro, but I wouldn't recommend this for "computer numpties"!! Best solution is for Airnav to import this into their central routes database, so the data is then available for anyone through Radarbox. It should only take them a few minutes.............
SQLite Maestro instructions for updating routes - http://www.airnavsystems.com/forum/index.php?topic=1356.msg10216#msg10216
-
Results for yesterday (23nd September):
Of 1199 ADS-B-equipped scheduled LHR flights automatically detected by the EGLLADSB website, 119 (9.9%) were listed by RadarBox with either no route at all, or with a route that didn't have EGLL as a From/To/Via.
-
In my view this is a mammoth task and needs to be tackled from a number of directions. Is there any reason we do not have a Database Update Request topic for routes as we have for aircraft?
-
In my view this is a mammoth task and needs to be tackled from a number of directions. Is there any reason we do not have a Database Update Request topic for routes as we have for aircraft?
There is in fact such a thread - Flight route update info - here: http://www.airnavsystems.com/forum/index.php?topic=5386.0
Having said that, AirNav have stated that they don't welcome route update submissions, and my experience is that they won't get actioned, so post at your own risk !
-
Is it possible to find a way to import update files without needing to be an expert in SQL. That will at least allow us to make use of files such as todays Flybee update
-
Please could some kind soul, advise us computer numpties, how to add the routes to our individual routes database.
Well, I use SQLite Maestro, but I wouldn't recommend this for "computer numpties"!! Best solution is for Airnav to import this into their central routes database, so the data is then available for anyone through Radarbox. It should only take them a few minutes.............
SQLite Maestro instructions for updating routes - http://www.airnavsystems.com/forum/index.php?topic=1356.msg10216#msg10216
So as spanman kindly now has provided a useful chunk of data, how long before airnav can upload this into server ?
-
Please could some kind soul, advise us computer numpties, how to add the routes to our individual routes database.
Well, I use SQLite Maestro, but I wouldn't recommend this for "computer numpties"!! Best solution is for Airnav to import this into their central routes database, so the data is then available for anyone through Radarbox. It should only take them a few minutes.............
SQLite Maestro instructions for updating routes - http://www.airnavsystems.com/forum/index.php?topic=1356.msg10216#msg10216
So as spanman kindly now has provided a useful chunk of data, how long before airnav can upload this into server ?
Only AirNav know the answer to that question.
-
Re FlyBe routes, I have BEE8ET on my box just now which is not on the updated listings, where is it going to and from please.
Alan
-
Results for yesterday (24th September):
Of 1239 ADS-B-equipped scheduled LHR flights automatically detected by the EGLLADSB website, 125 (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, AUA, AZA, BAW, BEL, BMA, CPA, DAL, DLH, EIN, IBE, MAU, OMA, QFA, SHT, SMX, SWR, TAP, UAL.
-
Of 1239 ADS-B-equipped scheduled LHR flights automatically detected by the EGLLADSB website, 125 (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.
Seems quite consistent results day-to-day. Radarbox manages around 90% success on route lookup, with a 10% failure rate (for ADS-B aircraft). Dave, can you do a similar test for non-ADS-B aircraft?
In my opinion, getting correct route information for non-ADS-B aircraft is MUCH more important, to help "visualise" where the aircraft is. When you've got 5 Loganair aircraft in the list without route data, it makes it impossible to "guess" where they're flying from/to.
-
Seems quite consistent results day-to-day. Radarbox manages around 90% success on route lookup, with a 10% failure rate (for ADS-B aircraft). Dave, can you do a similar test for non-ADS-B aircraft?
Interesting idea.
I'll give it a go, although it's not a check that's easy to automate since, by definition, the EGLLADSB website doesn't list non-ADS-B movements (although I do have a complete list of Heathrow Flight IDs which I can use to identify the non-plotters).
If we believe what AirNav tell us, then we should be seeing more routes for ADS-B than for non-ADS-B, since obviously their algorithm won't work for the latter.
Having said that, there is no evidence of improvement in the Heathrow stats to suggest that the algorithm is working for any aircraft.
Watch this space.
-
I have BEE8ET as EGFF - EGPH
-
Cheers Bearcat.
Alan
-
Of 1239 ADS-B-equipped scheduled LHR flights automatically detected by the EGLLADSB website, 125 (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.
Seems quite consistent results day-to-day. Radarbox manages around 90% success on route lookup, with a 10% failure rate (for ADS-B aircraft). Dave, can you do a similar test for non-ADS-B aircraft?
In my opinion, getting correct route information for non-ADS-B aircraft is MUCH more important, to help "visualise" where the aircraft is. When you've got 5 Loganair aircraft in the list without route data, it makes it impossible to "guess" where they're flying from/to.
Point of order here, Tarbat. Your statement "Radarbox manages around 90% success on route lookup, with a 10% failure rate (for ADS-B aircraft)" is based on figures obtained solely at EGLL.
I'll bet my bottom dollar that a similar exercise at Stansted, Birmingham, Manchester etc would produce significantly different results because of the incidence of lo-cost carriers. Certainly based on my observations here in the centre of England a 10% failure rate is wishful thinking.
-
Point of order here, Tarbat. Your statement "Radarbox manages around 90% success on route lookup, with a 10% failure rate (for ADS-B aircraft)" is based on figures obtained solely at EGLL.
Agreed. My comment was simply an observation on Dave's results. Success rate at Inverness also feels like a lot less than 90%, and I'm about to analyse the results from yesterday.
Yesterday's log at http://www.tarbat.gofreeserve.com/data.htm
-
I'll bet my bottom dollar that a similar exercise at Stansted, Birmingham, Manchester etc would produce significantly different results because of the incidence of lo-cost carriers. Certainly based on my observations here in the centre of England a 10% failure rate is wishful thinking.
I agree too.
Heathrow is just a handy benchmark, because I know my box picks up 100% of movements and it's easy to run the analysis daily.
That's why I resisted AirNav's recent repeated requests (6 at the last count) for me to add routes to my EGLLADSB website, thereby enabling them to hoover them all up, add them to the database and then claim that all was well in Routeland.
-
Agreed. My comment was simply an observation on Dave's results. Success rate at Inverness also feels like a lot less than 90%, and I'm about to analyse the results from yesterday.
Yesterday's log at http://www.tarbat.gofreeserve.com/data.htm
Out of 501 flights yesterday, 329 have a route listed (65%). I don't know what percentage of these have the correct route, and some of them you would not expect to see a route listed (eg TARTN51). And also note, I have added a lot of routes (eg BEE*) manually to my database, so the results would have been worse than this without the manual updates.
EDIT: To put this in perspective, I ran FD7.5 for some of the day, clicking on each aircraft to force a route lookup in FD7.5, and it found a route for 246 out of 305 flights, which is better at 80%.
-
Watch this space.
OK, results are as follows:
Of the 82 non-ADS-B LHR movements yesterday (identified by callsign), 6 (7.3%) had no route showing.
Based on such a small sample size, I'm not sure it's possible to draw any conclusions, although it may be significant that more than half of the 82 movements were BA or BMI, and three-quarters of those were non-alphanumerics, i.e. timetabled flight numbers.
But there's certainly no evidence to suggest that the algorithm is leading to a higher proportion of routes being identified for plotting flights.
Did someone mention snake oil ?
-
Attached CSV file suitable for import to your routes table.
Hi Mark / Hi Tarbat,
thank you both verry much for all this! I imported the csv-data succesfully into my "NavData.db3" this morning.
-
Results for yesterday (26th September):
Of 1222 ADS-B-equipped scheduled LHR flights automatically detected by the EGLLADSB website, 123 (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.
New carriers added to the list of those operating unknown/incorrect routes: EVA, FIN, SVA.
-
Results for yesterday (26th September):
Of 1222 ADS-B-equipped scheduled LHR flights automatically detected by the EGLLADSB website, 123 (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.
New carriers added to the list of those operating unknown/incorrect routes: EVA, FIN, SVA.
Good morning Dave - I welcome your stats for EGLL and think they would have even more relevance were you to actually split the figures between "no routes" and "no EGLL"s.
We could then say X% were in fact decoded however an absolute minimum of Y% of all decodes are errors. This might give us some indication of the respective proportions of the two different elements of the problem: A/ getting routings decoded and B/ getting routings right.
What do you say?
John
-
We could then say X% were in fact decoded however an absolute minimum of Y% of all decodes are errors. This might give us some indication of the respective proportions of the two different elements of the problem: A/ getting routings decoded and B/ getting routings right.
Happy to oblige.
Of those 123 mis/unidentified flights, 109 had no route at all and 14 showed routes that didn't involve EGLL.
There's no excuse at all for the latter ones (how can UAL948 be KLAX-KDEN when the network sees it landing at Heathrow every day?) and, of the flights with blank routes, many are from/to other airports which also have good network coverage, so they ought to be easily identifiable too.
It's now a month since I ran the first LHR analysis and the failure rate hasn't improved at all since then.
-
Thanks for that Dave.
As mentioned before, the figures for EGLL are not representative of the country as a whole but they might well represent the best performance and results that Airnav can put up in the UK.
In fact from an Airnav perspective, they’re not too bad at all. We seem to have 91.1% of all flights being decoded and, of these, up to 98.8% might be accurate.
Looking at the two figures separately, over 90% decoded would probably satisfy most of us were it a universal figure. However we know that this figure bears no relation to the other UK airports where decode rates will be considerably lower.
Looking at erroneous routings, a 1.15% failure rate is in fact close to Airnav's own claimed accuracy figure, however as this figure measures only the incidence of the "EGLL" route error, the overall percentage of route errors will probably be higher.
Much of EGLL traffic being scheduled, presumably the same errors are being perpetuated. Your "UAL" exemplifies this but one imagines that this and similar instances could be easily and speedily cleared up. Easily & speedily.............
Do we know the answer to the “UAL948” question?
Of course we do - it’s LAX/DEN/LHR.
So let's immediately correct that entry in our databases and all will be well.
Er.......
I guess your 10% error rate at EGLL is going to remain just that.
-
As mentioned before, the figures for EGLL are not representative of the country as a whole but they might well represent the best performance and results that Airnav can put up in the UK.
Yes, in fact I would expect Heathrow to be better than pretty well any other airport covered by the AirNav network, given that it's surrounded by sharers and a lot of the flights are international ones that FlightStats should have.
Or, to put it the other way round, routes to/from other airports are likely to produce results that are even more adrift from AirNav's claims.
I guess your 10% error rate at EGLL is going to remain just that.
Yes and no.
Between now and the end of October I don't expect to see much change.
But if AirNav haven't got their solution working in time for the Winter schedule changeover, I expect that the hit rate at Heathrow will plummet. There will be more flight numbers showing incorrect routes, because the airlines have reassigned them and the algorithm that should pick that up isn't working. Likewise new flight numbers, even if they are between Heathrow and other airports with good network coverage, will stay blank no matter how many times the network logs those Flight IDs taking off and landing.
Little did I suspect, when I innocently suggested using network movements to deduce routes, that the implementation would turn out to be such a dog's breakfast ...
-
I firmly believe that with a bit of effort and organisation we forum members could crack the alpha-numerics between us relatively easily and relatively quickly. Not too difficult an operation in theory.
But that would still leave us with the bloomin' "update the database" question and that really bugs me. Everybody and his dog knows that the UAL948 routing is wrong but seemingly we can't do anything about it so it will remain wrong until further notice. (I shall call this the UAL948 syndrome in future)
If a Working Database is not readily accessible for constant updating it is not a working database - it's an Archive - and the words useful, teapot and chocolate spring to mind.
-
DaveReid: why don't you send us the full contents of your flight number database so we can update our server for, at least, London Heathrow flights, at once?
-
DaveReid: why don't you send us the full contents of your flight number database so we can update our server for, at least, London Heathrow flights, at once?
That's the 7th time you've asked now, the answer is still the same.
That's why I resisted AirNav's recent repeated requests (6 at the last count) for me to add routes to my EGLLADSB website, thereby enabling them to hoover them all up, add them to the database and then claim that all was well in Routeland.
Fix your algorithm, and then you won't need my help.
And then it would work for every airport on your network, not just one.
Trust me, you'll feel much better for it.
-
Airnav,
How does the route alogorithm deal with multi leg flights. As I see it if we have a flight which, for example, routes LFPG-KPHL-KSFO the database will keep updating between LFPG-KPHL and KPHL-KSFO which isn't much help.
-
If you dont want to help Dave, dont complain. You are quite happy helping users of other systems but you will not aid you fellow members on this forum.
Alan
-
Did the flybe data get provided get uploaded to the network ?
-
RobinB: please resend the data to my email address (just Pmed you).
Dave:
- If you have a database with correct and updated flight numbers;
- You constantly criticize us for having inaccurate data;
Why don't you send us the entire database in csv format so we can update our server? We really don't understand your intentions here. Have a correct database or daily complain about everything? I hope you are not trying to sell your company's services one more time.
Send us the data and we will update our database immediately. Simpler is impossible.
-
If you dont want to help Dave, dont complain. You are quite happy helping users of other systems but you will not aid you fellow members on this forum.
On the contrary, I have provided AirNav with a technique which will allow many, many routes from many, many airports to be derived, not just one, which would be of considerably greater assistance to members. It's hardly my fault that AirNav have made such a miserable hash of implementing it, and I'm certainly entitled to complain about that.
Yes, I could spoon-feed AirNav with all the Heathrow routes, but that would both remove any incentive for them to fix their algorithm, and also remove one of the only useful benchmarks that we have to allow us to assess the overall quality of the routes database.
And, before you accuse me of being unhelpful to other members, correct me if I'm wrong but wasn't it AirNav who declined my offer of access to flightroutelookup.com because they insisted on looking a gift horse in the mouth ?
-
The data is going off to you in a minute, though I cant take credit for it, was supplied by user spanman.
Good luck with it.
-
So let's call it quits then?
I thought we were all in this together?
AirNav have publically asked for help,and you've publically declined, which your fully entitled to.
Pretty pointless banging on about it any more?
-
The data is going off to you in a minute, though I cant take credit for it, was supplied by user spanman.
Good luck with it.
Robin
Thanks for helping - very much appreciated
Rich
-
Until Airnav come up with a better solution, anyone can use FD7 to do route lookups. You simply select the flight in Radarbox, and the route appears in the FD7 window. See attached example:
(http://farm5.static.flickr.com/4144/5032066489_caa058b979_o_d.jpg)
In this example, FD7 is displaying the route for EZY484, whilst doing a lookup at libhomeradar on the aircraft I've just selected - ACA844.
-
Turnhouse ? Haven't heard it called that for years.
Dave
erstwhile member of the Turnhouse Junior Spotters Club (I kid you not!) :-)
-
Turnhouse ? Haven't heard it called that for years.
Yes, I must work out how to update the airports table in FD7.
-
Flybe Route callsign tie ups.
Please find attached all todays flybe callsign tieups,There maybe some which were not in my original batch due to routes operating certain days etc. Once again they are produced using Open Office but hopefully Tarbat will convert for us.
Cheers,
Mark
-
Thanks.
hopefully Tarbat will convert for us.
For me, this added 30 new routes, and updated 400 routes.
Airnav, this type of import takes only seconds. When can we expect to see these routes added to the central server routes table?
EDIT: If you look at my log from yesterday (http://www.tarbat.gofreeserve.com/data.htm), you can see how many more routes I'm now seeing, all thanks to Mark (spanman).
-
Flybe Route callsign tie ups.
Please find attached all todays flybe callsign tieups,There maybe some which were not in my original batch due to routes operating certain days etc.
Out of interest, Tarbat's converted listing doesn't have any VIAs - do you guys not fly any multi-leg flights ?
I'm thinking of Sumburgh-Kirkwall-Aberdeen or Aberdeen-Leeds-Exeter, for example.
Just curious, no criticism intended.
-
Anyone can send us updated route information and we will update our central database (send me a PM for instructions).
In the meanwhile and I'm sorry to insist we continue not to understand the purpose of some forum members in this thread: they are in possession of a good flight number listing and refuse to send it to us for the benefit of all while keeping their complaints. In our view this is an unnaceptable attitude as we are here to help each other and improve the system.
-
Thanks.
hopefully Tarbat will convert for us.
For me, this added 30 new routes, and updated 400 routes.
Airnav, this type of import takes only seconds. When can we expect to see these routes added to the central server routes table?
This is rapidly becoming one great big joke and we Radarbox users have been split into two camps, those who seem to have access to up to date data and those who don't - the latter forming the vast majority I would imagine.
These now daily postings on the lines of "I've got this, that or the other" only serve to aggravate those of us who are reduced to sitting on the sidelines waiting for something to happen - and looking up queries on Google for Pete's sake.
Not a swipe at you Tarbat mate or anyone else in particular - just a blast of utter frustration at the current state of play.
-
Airnav
Anyone can send us updated route information and we will update our central database (send me a PM for instructions).
Why is this, the file is there on the forum for you to take.
-
In the meanwhile and I'm sorry to insist we continue not to understand the purpose of some forum members in this thread: they are in possession of a good flight number listing and refuse to send it to us for the benefit of all while keeping their complaints. In our view this is an unnaceptable attitude as we are here to help each other and improve the system.
Hmmm. As the old Chinese proverb goes:
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime."
Simply throwing fish/routes at you might appear to be helpful. It isn't.
It just gives you an excuse for not fixing the system that you told us 6 weeks ago was already in place and working, but clearly isn't.
It might feel like tough love right now, but you'll thank me one day :-)
-
I guess what might help this problem is if someone could write a simple program to allow the import of CSV files to our local databases.
You don't really need a special program to import routes, you can use the standard SQLITE program.
So, to set this up in the first place:
1. Download the SQLITE command line program from http://www.sqlite.org/download.html. The current version is http://www.sqlite.org/sqlite-3_7_2.zip
2. Unzip this file, and put the resulting sqlite3.exe program in your AirNav Systems\AirNav RadarBox folder. This is the folder where the main Radarbox program (ANRB.exe) is located.
3. Download the attached file (import_routes.bat) into the same folder. This is a BAT file for executing the updates.
4. Download the attached file (sql.txt) into the same folder. This is the data file, containing the route updates as SQL statements. The attached example is for the Flybe routes.
Now, to run the update:
1. Close down Radarbox. This is important, to avoid a locked database. Make sure Radarbox has finished all it's processing before proceeding.
2. Run the import_routes.bat file.
3. Re-open Radarbox, and you'll now have the new routes.
-
These now daily postings on the lines of "I've got this, that or the other" only serve to aggravate those of us who are reduced to sitting on the sidelines waiting for something to happen - and looking up queries on Google for Pete's sake.
I guess what might help this problem is if someone could write a simple program to allow the import of CSV files to our local databases. I'm okay writing in VB, although need to find out how to use SQL in VB. It should only take an expert Airnav programmer a few hours to knock something up.
How about an expert non-Airnav programmer?
-
Tarbat: Do you want to update your local tables, our central server or both?
Dave, your knowledge of Mode-s/ADS-B market is something everyone respects.
Your company will never get any kind of business from AirNav Systems so, for the benefit of the community and one more time stop your games and respect the forum.
-
Tarbat: Do you want to update your local tables, our central server or both?
Personally, I want you to update your central server. I'm perfectly capable of updating my local tables myself, but others aren't.
-
Tarbat - this encapsulates my situation:
Right now passing literally overhead is A319 G-EZAY flight ID EZY906V.
It is in MyFlights but where it came from and where it is going is a mystery.
I Google it.
Apparently it is bound for EDI having departed GVA.
It will be back tomorrow maybe, certainly within the next few days and yet when it appears on screen again it will still be a mystery flight.
Why? because I can't put that route in my database - and nor apparently can Airnav.
It's crazy - there's nothing more to say - crazy.
-
Why dont you update the route yourself? Therafter it will not be a mystery to you.
-
Your company will never get any kind of business from AirNav Systems so, for the benefit of the community and one more time stop your games and respect the forum.
With a statement like that do you really expect Dave to give you anything. You guys have a lot to learn about Customer Service and I am disgusted that you go to print with something like this because your constant begging for help hasn't been answered in your favour. Shame on you.
Onto algorithm. Now, I'll admit that I know nothing about this but it sounds to me from other posts that if you (Air Nav and it's developers) get this sorted then things should be a lot better.
Simple question to Air Nav - Why can't you get this algorithm problem sorted?
-
Surely if they knew the answer to that question there would be no thread.
-
Why dont you update the route yourself? Therafter it will not be a mystery to you.
Simple - I haven't got the expertise. It's just not my field and that's why I bought an RB - supposedly self contained and requiring no particular technical knowledge to use.
And it also explains why we are a two tier society here; some can update, some can't but IMO none should be needing to.
-
If it is so important why not give it a go, you may surprise yourself. I am sure if you get stuck you can ask and will be helped out.
-
Thanks for the encouragement Runway and I appreciate how helpful folks can be on this forum but at my age you know your strengths and weaknesses.
To be honest I really don't want to get involved (bogged down!) in programming when there are other things of far greater interest to me. I just want my RB to do what is says on the tin.
On behalf of all those in my position I would thank Tarbut for his blunt and selfless reply to Airnav:
"Personally, I want you to update your central server. I'm perfectly capable of updating my local tables myself, but others aren't."
Exactly.
-
Simple question to Air Nav - Why can't you get this algorithm problem sorted?
AirNav won't answer that question because they would first have to acknowledge that it isn't working - which they haven't so far done, despite the evidence being there for all to see.
Come on Dev, there's no shame in admitting that something has turned out to be more difficult to do than you first anticipated. Bite that bullet.
-
To be honest I really don't want to get involved (bogged down!) in programming when there are other things of far greater interest to me. I just want my RB to do what is says on the tin.
You shouldn't have to get bogged down. Air Nav should get it sorted, or at least PAY someone with a bit of nowse to get it sorted for them.
I hope Boeing aren't reading this thread!
-
On behalf of all those in my position I would thank Tarbut for his blunt and selfless reply to Airnav:
As soon as Airnav send me the instructions for submitting route information, I'll send them the Flybe routes.
-
Why is that Chris
Are they to lazy to get them from your post.
I sent you a e-mail, don't know you are still using that address.
Andy
-
I sent you a e-mail, don't know you are still using that address.
Best to PM me.
-
These:
<?xml version="1.0" encoding="utf-8" ?>
- <Flight>
<FlightNumber>AWE925</FlightNumber>
<Callsign>Cactus 925</Callsign>
- <Leg>
- <Origin>
<ICAOCode>KPHL</ICAOCode>
<IATACode>PHL</IATACode>
<AirportName>PHILADELPHIA (INTERNATIONAL)</AirportName>
<Country>UNITED STATES</Country>
</Origin>
- <Destination>
<ICAOCode>KPDX</ICAOCode>
<IATACode>PDX</IATACode>
<AirportName>PORTLAND (INTERNATIONAL)</AirportName>
<Country>UNITED STATES</Country>
</Destination>
<GCDistanceNM>2084</GCDistanceNM>
<DistanceFromOriginNM>664</DistanceFromOriginNM>
<DistanceFromDestinationNM>1422</DistanceFromDestinationNM>
</Leg>
</Flight>
Okay, a question about these instructions. Are all fields mandatory? If not mandatory, do we just exclude the XML tags for that field, or submit an empty value for those tags?
Note that all we really need for Radarbox is FLightID, FROM, TO, VIA, CH Date, so would this be acceptable:
<?xml version="1.0" encoding="utf-8" ?
<Flight><FlightNumber>BEE1053</FlightNumber><Leg><Origin><ICAOCode>EGCC</ICAOCode></Origin><Destination><ICAOCode>EGMH</ICAOCode></Destination></Leg></Flight>
<Flight><FlightNumber>BEE1054</FlightNumber><Leg><Origin><ICAOCode>EGMH</ICAOCode></Origin><Destination><ICAOCode>EGCC</ICAOCode></Destination></Leg></Flight>
-
Just an update on a few items being discussed here:
As you know the routes in our central database are updated by both Flights Stats and our algorithm.
The algorithm is doing its best to gain some of the missing flight route data but however is no means perfect. It is being worked on and is being fine tuned. It has been taken from our Live Traffic for FS system which has been very popular. Due to the nature of the algorithm relying on many variables to detect routes its not easy and not always perfect (not to mention we need good coverage at each airport for it to work) We are not sitting here and telling you that is will solve all issues with routes but that its the best we can do at the moment. The alogrithm is devloped by Live Traffic Devs who are not on the forum and cannot devote 100% time on this, for that reason we can't give the specifics at the moment.
Those advising us of other addons which look up at other sites, we cannot do this as we need to have relationships with these sites (quite costly) to get this data.
The routes database is designed to be updated by the two methods above and not manually. However we can do bulk adds to the database (though some may get overwritten - this is being looked into). We hope to provide more information soon on how this can be done. Please be patient with us.
-
Okay, Im a numpty sat at my laptop, how do I find accurate route info and then update my data base?
-
Airnav, don't know if this question got missed or something. I've also PM'd you asking for details on how to submit routes.
Okay, a question about these instructions. Are all fields mandatory? If not mandatory, do we just exclude the XML tags for that field, or submit an empty value for those tags?
Note that all we really need for Radarbox is FLightID, FROM, TO, VIA, CH Date, so would this be acceptable:
<?xml version="1.0" encoding="utf-8" ?>
<Flight><FlightNumber>BEE1053</FlightNumber><Leg><Origin><ICAOCode>EGCC</ICAOCode></Origin><Destination><ICAOCode>EGMH</ICAOCode></Destination></Leg></Flight>
<Flight><FlightNumber>BEE1054</FlightNumber><Leg><Origin><ICAOCode>EGMH</ICAOCode></Origin><Destination><ICAOCode>EGCC</ICAOCode></Destination></Leg></Flight>
-
anorak,
Relax and let RB update the routes. Unless you want perfection you should find most of your flights which have routes to be correct. Some of the routes which do not have routes at all are being worked on using techinques from us.
Tarbat,
From the earlier post :)
"The routes database is designed to be updated by the two methods above and not manually. However we can do bulk adds to the database (though some may get overwritten - this is being looked into). We hope to provide more information soon on how this can be done. Please be patient with us."
-
Just an update on a few items being discussed here:
As you know the routes in our central database are updated by both Flights Stats and our algorithm.
Hi Airnav - I hear what you are saying but what I fail understand is that Google seems to have more routes data than the two sources you mention above put together.
Many of my missing lo-cost alpha-numeric routes I can find just through Google and if they are in Google, then presumably they are in the public domain by definition.
It just strikes me that Flight Stats and your algorithm are both working hard searching for something that has already been found by someone else.
It can't be that simple so I suspect I'm missing something.
-
Hi Airnav - I hear what you are saying but what I fail understand is that Google seems to have more routes data than the two sources you mention above put together.
Which sites does Google find that has the data?
Yes, it's quite easy to manually lookup a single FlightID using any of the following sites:
Libhomeradar (http://www.libhomeradar.org/)
FRL (http://www.flightroutelookup.com/FlightRoute/)
FlightStats (http://www.flightstats.co.uk/)
Flytecom (http://www.flytecomm.com/)
FlightAware (http://flightaware.com/)
But to automate that for potentially thousands of FlightIDs each days would probably require a commercial arrangement between Airnav and the site owners. I guess that would cost money, and some sites may not even allow thousands of lookups each day. And even then you won't get the alphanumeric FlightIds for Loganair, for example.
FD7 uses all the sites listed above, and limits you to 250 lookups per day.
-
As already mentioned FD7 is on some uncertain ground with those lookups. Many of the sites are not happy with you using bots to visit there sites and gain route data. A agreement is needed with them, and we cannot do what FD7 has done without any agreements and get away with it.
A quick check of google, it seems to use FlightStats which is what we use :)
-
As already mentioned FD7 is on some uncertain ground with those lookups.
I would guess it's the end user who may have problems. To be fair to Allan, he provides the following WARNING with FD7:
Warning. Monitoring a large area with high levels of traffic, or using the All aircraft option (particularly for the first time) can generate large volumes of internet lookups. To avoid overloading the lookup sites, FD caps the number of lookups to 250 per session, or if FD is running continuously, 250 per day (midnight to midnight) and spreads the internet look ups over a period of time to reduce peak loads.
Despite these steps it is possible that a lookup site will block your IP address due to excessive use. There are no guidelines as to what level the lookup sites consider excessive so please consider restricting the lookup area and initially only using the feature for 1-2 hours at different times over a period of days while your database of flights is built up.
-
Despite these steps it is possible that a lookup site will block your IP address due to excessive use. There are no guidelines as to what level the lookup sites consider excessive so please consider restricting the lookup area and initially only using the feature for 1-2 hours at different times over a period of days while your database of flights is built up.
I guess some flight route lookup sites feel the need to impose usage restrictions and log IP addresses :-)
-
Dave,
Also possibly as a precaution agains DDOS attacks I would think. Having had an account closed because someone in America attacked the site I can sympathise
-
The main reason would be these sites keep alive by adverts or promoting a "Pro" version of there site. Using robots etc.. you get no adverts or promotion hence there is no advantage of them providing a service.
-
You don't really need a special program to import routes, you can use the standard SQLITE program.
So, to set this up in the first place:
1. Download the SQLITE command line program from http://www.sqlite.org/download.html. The current version is http://www.sqlite.org/sqlite-3_7_2.zip
2. Unzip this file, and put the resulting sqlite3.exe program in your AirNav Systems\AirNav RadarBox folder. This is the folder where the main Radarbox program (ANRB.exe) is located.
3. Download the attached file (import_routes.bat) into the same folder. This is a BAT file for executing the updates.
4. Download the attached file (sql.txt) into the same folder. This is the data file, containing the route updates as SQL statements. The attached example is for the Flybe routes.
Now, to run the update:
1. Close down Radarbox. This is important, to avoid a locked database. Make sure Radarbox has finished all it's processing before proceeding.
2. Run the import_routes.bat file.
3. Re-open Radarbox, and you'll now have the new routes.
-
In parallel running of Radarbox and FD7.5 for the last few hours, out of 74 FlightIDs, FD7.5 returned 4 additional routes, and 6 different routes:
FN FD7.NO FD7.ND FD7.CH anrb.NO anrb.ND anrb.CH
BAW9L EGLL YSSY 20100929000000 EGLL CYYZ 20100906122808
COA47 EDDF KLAX 20100929000000 EDDF KIAH 20100904135321
EZY198A EGCC EKCH 20100929000000
KLM44M EGPF EHAM 20100929000000 LROP EHAM 20100831121032
KLM63B EHAM EGPD 20100929000000 EDDM EHAM 20100831132456
NJE7XM LIML EGNH 20100929000000
NSH610 CYYR EGPE 20100929000000 KIXD KSTP 20100922192440
RYR16ZE ESGP EGPK 20100929000000
RYR28ET ENRY EIDW 20100929000000
TCX121K EGKK HELX 20100929000000 EGPF CYYC 20100901111824
-
You don't really need a special program to import routes, you can use the standard SQLITE program.
Thanks tarbat
-
Here is my contribution to the routes. This is a list of all the SAA routes. Please note the following:
All routes from SAA1000 to SAA1999 are operated by SA Express Airline
All routes from SAA7999 to SAA8999 are operated by SA Airlink
Currently SAA7000 is from JHB to LIS and SAA7001 is the return flight. From 2 November they swap around (who knows why)
-
In parallel running of Radarbox and FD7.5 for the last few hours, out of 74 FlightIDs, FD7.5 returned 4 additional routes, and 6 different routes:
FN FD7.NO FD7.ND FD7.CH anrb.NO anrb.ND anrb.CH
BAW9L EGLL YSSY 20100929000000 EGLL CYYZ 20100906122808
COA47 EDDF KLAX 20100929000000 EDDF KIAH 20100904135321
EZY198A EGCC EKCH 20100929000000
KLM44M EGPF EHAM 20100929000000 LROP EHAM 20100831121032
KLM63B EHAM EGPD 20100929000000 EDDM EHAM 20100831132456
NJE7XM LIML EGNH 20100929000000
NSH610 CYYR EGPE 20100929000000 KIXD KSTP 20100922192440
RYR16ZE ESGP EGPK 20100929000000
RYR28ET ENRY EIDW 20100929000000
TCX121K EGKK HELX 20100929000000 EGPF CYYC 20100901111824
BAW9L (BA093) is indeed a daily EGLL-CYYZ flight, It invariably returns as BAW5CA (BA092).
-
BAW9L (BA093) is indeed a daily EGLL-CYYZ flight, It invariably returns as BAW5CA (BA092).
So, in this case, did Radarbox get it right?
-
Here is my contribution to the routes. This is a list of all the SAA routes.
Thanks, very useful. What's the source?
Attached SQL statements to add to routes table using import_routes.bat above.
-
BAW9L (BA093) is indeed a daily EGLL-CYYZ flight, It invariably returns as BAW5CA (BA092).
So, in this case, did Radarbox get it right?
Yes, it does sometimes :-)
I have no idea where FD got London-Sydney from - looking at my log, BAW9L has always headed west on departure, as far back as 2006.
-
Thanks, very useful. What's the source?
Attached SQL statements to add to routes table using import_routes.bat above.
The source is the official route table on the SAA website - unfortunately a pdf document so took some time to convert.
http://www.flysaa.com/Shared/flightSchedules.html
-
I have no idea where FD got London-Sydney from - looking at my log, BAW9L has always headed west on departure, as far back as 2006.
It comes from one of the route lookup sites. The art to using FD is to know which order to use the sites in - I'm beginning to suspect that Libhomeradar may not be the most reliable, so I've put that as no5 in my lookup sequence. FRL is now no1, followed by FlyteCom, FlightAware, FlightStats, then Libhomeradar. That's until FRL bans my IP address!!!
EDIT: Looks like Libhomeradar was the culprit, showing BAW9L as EGLL-VTBD-YSSY
http://www.libhomeradar.org/databasequery/details.php?page=0&qid=6484167&sid=425291380
-
That's until FRL bans my IP address!!!
Now you know perfectly well FRL doesn't do that :-)
-
Many Thanks Chris for the instructions and the SQL statements. Very much appreciated.
Alan
-
Dave
Perhaps the system is confused with the original BA9 which was the flight involved in the Jakarta volcano incident :)
-
In parallel running of Radarbox and FD7.5 for the last few hours, out of 201 FlightIDs, FD7.5 returned 15 additional routes, and 29 different routes:
FN FD7.NO FD7.ND FD7.CH anrb.NO anrb.ND anrb.CH
AAL51 EGKK KDFW 20100930000000 EGLL KDFW 20100929000000
AEU781P EGKK CYHZ 20100930000000
AIC127 EDDF KORD 20100930000000 VOHS EDDF 20100903083411
AIC191 EDDF KEWR 20100930000000 VAAH KEWR 20100924000000
AWE707 EDDM KPHL 20100930000000 KPHL KDCA 20100905121632
CFEMT CYYR BIKF 20100930000000
COA17 EGPF KEWR 20100930000000 EGPF KLAX 20100905081531
COA37 EGPH KEWR 20100930000000 EGPH KMCO 20100924000000
DAL143 EDDF KDTW 20100930000000 EDDF KMSP 20100929000000
DAL79 EDDT KJFK 20100930000000 KJFK KLAX 20100904110749
EZE1041 EGPD EDDH 20100930000000 EIDL EGPD 20100929000000
EZE26Z EGPD EGNX 20100930000000
EZY14PW EGPD EGGW 20100930000000
EZY688Y EGPF LFPG 20100930000000
EZY905G EGPH LSGG 20100930000000
EZY94EG EGPH LEMD 20100930000000 EGPH EGSS 20100831093407
GMA651 EGLF LFPB 20100930000000
IRL251 EIME EINN 20100930000000
KLM663 EHAM KIAH 20100930000000 KIAH EHAM 20100904125343
MON7648 EGPH GCRR 20100930000000 EGPD LEPA 20100909145709
N436QS CYYT LIBR 20100930000000
N604FJ KBGR EBAW 20100930000000
N8220M CYYR BGBW 20100930000000
NAO990 PHNL PGUA 20100930000000 KDFW KJFK 20100930112802
NJE5HW EGSH LFPB 20100930000000
RYN532 EDDP KLSF 20100930000000 KAEX EDDP 20100930075633
RYR2RC EPGD EIDW 20100930000000
RYR69RF EVRA EIDW 20100930000000
TCX86K EGCC TBPB 20100930000000 EGKK CYVR 20100909102411
THT7 LFPG KLAX 20100930000000 LFPG NTAA 20100924000000
UAL917 EDDF KIAD 20100930000000 EDDF KSEA 20100905120042
UAL926 KSFO EDDF 20100930000000 KLAX EDDF 20100924000000
UAL929 EGLL KORD 20100930000000 EBBR KORD 20100909072628
UAL931 EGLL KSFO 20100930000000 EGLL KLAX 20100929000000
UAL935 EGLL KLAX 20100930000000 EGLL PHNL 20100929000000
UAL939 EGLL KDEN 20100930000000 EGLL KSAN 20100929000000
UAL941 EDDF KORD 20100930000000 EDDF KDEN 20100929000000
UAL943 LFPG KORD 20100930000000 LFPG KLAX 20100929000000
UAL945 EDDF KORD 20100930000000 EDDF KLAX 20100905074528
UAL947 EHAM KIAD 20100930000000 EHAM KLAX 20100831111554
UAL953 EDDF KIAD 20100930000000 EDDF KPHX 20100905103943
UAL955 EGLL KSFO 20100930000000 EGLL KSAN 20100929000000
WIF0393 EGPD ENBR 20100930000000
WWI14 KTEB EGGW 20100930000000 KSAT KTCS 20100930071104
Using route lookup sites in the following order:
1. FRL Service
2. FlyteCom
3. FlightAware
4. FlightStats
5. Libhomeradar
-
Several of those United flights are multi-leg, so both routes quoted are technically correct except that one doesn't take the intermediate stop into account (e.g. UAL931 flies EGLL-KSFO-KLAX).
Bear in mind that FRL will only return the leg that is consistent with the aircraft's current position; the AirNav server should return both legs (though it doesn't in this case).
-
In parallel running of Radarbox and FD7.5 for the last few hours, out of 201 FlightIDs, FD7.5 returned 15 additional routes, and 29 different routes:
FN FD7.NO FD7.ND FD7.CH anrb.NO anrb.ND anrb.CH
EZE1041 EGPD EDDH 20100930000000 EIDL EGPD 20100929000000
EZE26Z EGPD EGNX 20100930000000
EZY14PW EGPD EGGW 20100930000000
EZY688Y EGPF LFPG 20100930000000
EZY905G EGPH LSGG 20100930000000
EZY94EG EGPH LEMD 20100930000000 EGPH EGSS 20100831093407
Using route lookup sites in the following order:
1. FRL Service
2. FlyteCom
3. FlightAware
4. FlightStats
5. Libhomeradar
These EZYs are all over the shop. FD7 decodes 6/6 while Airnav decodes just 2 but both of these differ from FD7.
Confusion reigns as unless/until someone can categorically confirm the correct routes, we just don't know who is right - if either of them!!!
-
Confusion reigns as unless/until someone can categorically confirm the correct routes, we just don't know who is right - if either of them!!!
I'd love to help out.
Unfortunately I've been told by AirNav not to post route updates :-)
-
Confusion reigns as unless/until someone can categorically confirm the correct routes, we just don't know who is right - if either of them!!!
Yes. The more I look at routes, the harder it becomes to decide which lookup service is correct. Now, what we really need is a system that looks at where the aircraft departs and lands, are derive routes from real-world events. But of course, that's what I suggested to Airnav two years ago. Let's hope they can refine their solution.
-
The fog and snow season is approaching - diversions will no doubt add to the merriment ;-)
Rod
-
The fog and snow season is approaching - diversions will no doubt add to the merriment
Yes, an injection of common sense is a useful addition to any automated process :-)
-
OK folks, here's my cunning plan to find at least some of the routes Airnav can't supply at present:
Nominate a "Routes" week
during which everyone will concentrate specifically on their local airport(s) traffic
and note the TO/ landing time & FN for each flight that does not show a route in MyFlights.
At the end of the period, divide your records into incoming and outoing flight lists
and present the 2 sets of stats in alphabetic/numeric order FN Airport Date Time
by posting the results to a specially designated forum topic
where one or all of us can look at the data, stick it through a DBase and hopefully come up with some definitive results.
While it wouldn't correct the existing wrong routes, it would pobably fill a lot of the gaps.
Hairbrained it maybe but at least it's a start?
-
I'm up for that . I can help do Manchester traffic and of course I will keep the Flybe alpha numeric route information as up to date as possible.
-
Thanks for coming back spanman. There are many airports to cover of course even if we impose say a Europe Only limit for the first exercise.
It would mean a lot of of flights however if we concentrated on "non-routers" and "ADS-B" only, I think the numbers, while substantial, would be manageable.
The main point is that if all goes to plan we will at last have hard data to work on and hard data is what we currently lack. If it is a vast quantity, well no worries - there's plenty of time to sort it out.
Let's see if anyone else is interested - lots of airports to monitor.
-
Interesting idea. I just had a play with importing my FLIGHTS table into Excel, and then doing some formulae to look for flights where the Start or End Altitude is below a certain level (1200ft in my case). Gave the following results:
STATUS FLIGHTID DATE/TIME
EGPE 8000 1140 LANDING BDI18B 2010/09/30 08:57:09
EGPE 65 20000 TAKEOFF CWL64 2010/09/30 09:12:44
EGPE 90 22000 TAKEOFF CWL73 2010/09/30 09:17:39
EGPE 0 0 TAKEOFF GLAZL 2010/09/30 10:16:47
EGPE 9500 685 LANDING LOG78HL 2010/09/30 11:12:05
EGPE 37975 955 LANDING EZY761 2010/09/30 13:14:14
EGPE 220 7500 TAKEOFF BDI19B 2010/09/30 19:25:27
EGPE 9375 1070 LANDING LOG51HP 2010/09/30 19:53:21
EGPE 1070 5350 TAKEOFF LOG772P 2010/09/30 19:49:50
Its then fairly easy to eliminate those that went into Lossie or Kinloss, where I can see down to ground level. I might develop this idea further tomorrow. Any other suggestions for automating this?
-
Any other suggestions for automating this?
Er, how about an algorithm ? :-)
Joking apart, you're on the right track (no pun intended). If it's any help, the EGLLADSB website works by looking at position, altitude, track, groundspeed and rate of descent, in order to deduce that an aircraft is landing at or taking off from Heathrow. It has also been enhanced recently to identify arrivals while they are still in the holds, but that's probably overkill.
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 ...
-
Shees Dave - you don't miss an opportunity
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. Is is possible to add a sql instruction at the beginning of the file to delete all existing routes for that airline so that obsolete routes could be deleted?
-
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 - 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.
-
Thanks
-
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.
-
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.
-
"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
-
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.
-
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.
-
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 ?
-
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.
-
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.
-
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
-
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)
-
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.
-
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.
-
Need a username?
If you want sophistication like checking for duplicates, etc, etc then it is a bigger project. I was assuming it would be a data collection facility and that the manipulation and purification would be done in excel or something like that
-
Programmers always shudder when they hear the words data and Excel in the same sentence :-)
-
Can I suggest TWO separate tables, one for takeoffs, and one for landings. Each containing three fields:
CREATE TABLE TakeOff (
ICAO varchar(4),
FlightID varchar(8),
DateTime varchar(50)
);
CREATE TABLE Landing (
ICAO varchar(4),
FlightID varchar(8),
DateTime varchar(50)
);
Then, a simple query would allow you to match takeoffs and landings with the same FlightID:
SELECT
TakeOff.FlightID,
TakeOff.ICAO AS TakeOffAirport,
Landing.ICAO AS LandingAirport,
TakeOff.DateTime AS TakeOffTime,
Landing.DateTime AS LandingTime
FROM
TakeOff
INNER JOIN Landing ON (TakeOff.FlightID=Landing.FlightID)
WHERE
(TakeOff.DateTime < Landing.DateTime)
-
Surely that SQL would only return multi-leg flights which have a takeoff and landing at the same airport with the same FlightID ?
-
Surely that SQL would only return multi-leg flights which have a takeoff and landing at the same airport with the same FlightID ?
Corrected and refined to check that take-off date/time is earlier than landing date/time. Now, if someone could host the database, we could test this out. Although it won't cope with multi-leg flights.
If anyone wants me to test this out, FOR TESTING ONLY, post you takeoffs and landings in the following format:
TAKEOFFS
"AAAA","FFFFFFFF","YYYY/MM/DD HH:MM:SS"
eg:
"EGLL","EZY153","2010/10/01 10:22:12"
LANDINGS
"AAAA","FFFFFFFF","YYYY/MM/DD HH:MM:SS"
eg:
"EGPE","EZY153","2010/10/01 11:54:35"
-
Corrected and refined to check that take-off date/time is earlier than landing date/time. Now, if someone could host the database, we could test this out. Although it won't cope with multi-leg flights.
Well my offer re hosting stands.
By the way, you don't need 2 separate tables, you can run a corresponding SQL query on a single table, regardless of whether rows have origin, or destination, or both, populated.
-
By the way, you don't need 2 separate tables, you can run a corresponding SQL query on a single table, regardless of whether rows have origin, or destination, or both, populated.
Okay, I stand corrected. I can't see how to do that in SQLiteMaestro, so I'll give up now and leave it to more expert people.
-
Programmers don't like the number 2 - in fact they only recognise three numbers:
0
1
lots
:-)
-
Breaking in for a moment techies, I've just had 30 mins monitoring EGNX, working also in conjunction with the online EMA departure and arrivals board.
RYR 7VG landed - from Alicante according to board so should be OK to write route.
RYR17ML took off - for Bergamo according to board so should be OK to write route (Airnav has routing EGNX-LEGE - should be LIME)
TCX 91WC took off - for Teneriffe according to board - should be OK to write route.
Nothing sensational but it shows that in 30 minutes one man can crack 3 routes without much effort. So class, how many routes can 20 men working for a few days crack?
But just what do we do with the info?
-
can I suggest holding fire on the project till the end of the month when the timetable change is complete
-
But just what do we do with the info?
Have a play with www.flightroutelookup.com/FlightRoute/FlightRouteUpdate.asp.
Feedback welcomed.
-
By the way, you don't need 2 separate tables, you can run a corresponding SQL query on a single table, regardless of whether rows have origin, or destination, or both, populated.
Dave, can you give some pointers on how to achieve that - I can't see how.
In the meantime, my "2-table" database seems to work well, except for multi-leg flights. I can input a list of departures from several airports into one table, and a list of arrivals from those airports into the other table, and the query automatically matches arrivals to departures and generates routes. Just need some real data from other airports to test.
ALthough it also shows up flights that appear take-off and land at the same airport:
FlightID T/O LND TakeOffTime LandingTime
CWL64 EGPE EGPE 2010/09/29 09:58:29 2010/09/29 15:27:55
CWL73 EGPE EGPE 2010/09/29 10:07:00 2010/09/29 15:44:12
LOG779 EGPE EGPE 2010/09/27 19:53:38 2010/09/29 16:47:40
-
But just what do we do with the info?
Have a play with www.flightroutelookup.com/FlightRoute/FlightRouteUpdate.asp.
Feedback welcomed.
Right Dave - 2 points - is it case sensitive and what is the date format? Looks dead simple for confirmed completed routes as opposed to half routes.
-
DaveReid,
If your promoting your site again to help, then can you please confirm that you will let us hook into it for free as you do for other software?
If not please make that obvious to everyone. The last think we want is RadarBox users involved in something that they think will help there system when actually it won't at all.
-
Right Dave - 2 points - is it case sensitive and what is the date format? Looks dead simple for confirmed completed routes as opposed to half routes.
No, it's not case-sensitive (anything you enter in lower case is automatically uppercased before saving).
Date format is DD/MM/YYYY.
Not sure what you mean about only simple for completed routes - for a half route just leave the origin or destination blank, as appropriate.
-
If your promoting your site again to help, then can you please confirm that you will let us hook into it for free as you do for other software?
This is nothing to do with the existing FRL database, other than the fact that it runs on the same server. Come to that, it's nothing to do with you either.
The data on submitted routes and half routes belongs to the users who contribute it. You will have to ask them if you want to use it.
-
DaveReid,
Considering you have tried to sell your services (Aircraft, Routes) to us at vastly high price and used the forum to try and leverage us on more than once occasion. We would have to question your motive here.
We would just like to make our customers aware what and whom they are dealing with.
-
Not sure what you mean about only simple for completed routes - for a half route just leave the origin or destination blank, as appropriate.
Is there a process that then runs to match entries with the same FlightID and blank origin or destination?
-
Right Dave - 2 points - is it case sensitive and what is the date format? Looks dead simple for confirmed completed routes as opposed to half routes.
No, it's not case-sensitive (anything you enter in lower case is automatically uppercased before saving).
Date format is DD/MM/YYYY.
Not sure what you mean about only simple for completed routes - for a half route just leave the origin or destination blank, as appropriate.
Good stuff Dave - speaking as the ultimate test pilot for anything to do with Computing, I'll give it a whirl.
I'm now going off on a little detour for a while. I want to see how far I can get in cracking as many of the EGNX routes as possible by using RB in combination with the online EMA Arrivals/Departures board (as outlined above somewhere)
This might prove a decent alternative strategy that anyone can employ at an airport that offers accurate on line info.
Certainly worth a go and hopefully not too difficult.
-
Is there a process that then runs to match entries with the same FlightID and blank origin or destination?
There will be - at least when my phone stops ringing !
-
Considering you have tried to sell your services (Aircraft, Routes) to us at vastly high price and used the forum to try and leverage us on more than once occasion. We would have to question your motive here.
We would just like to make our customers aware what and whom they are dealing with.
Read my lips: it isn't my data
Just what part of that don't you understand ?
-
DaveReid,
If your promoting your site again to help, then can you please confirm that you will let us hook into it for free as you do for other software?
If not please make that obvious to everyone. The last think we want is RadarBox users involved in something that they think will help there system when actually it won't at all.
Speachless & Amazed
Come to that, it's nothing to do with you either.
You tell them Dave - I for one will thank you for all the help you are giving to the user's of this forum
-
can I suggest holding fire on the project till the end of the month when the timetable change is complete
Hi flybhx - I think the accent is very much on "project" at the moment! but lots of interesting ideas and avenues opening up. Good thinking though on your part. If we ever get off the ground it will be more likely Spring Schedules to worry about.
-
There is little point to this project if the data does not find its way into the AirNav database or into a csv file that can easily be imported into the local database ala tarbat import
-
There is little point to this project if the data does not find its way into the AirNav database or into a csv file that can easily be imported into the local database ala tarbat import
Rest assured that both CSV import/output and SQL bulk load statements will be supported, so as a last resort everyone will be able to use the data to update their local NavData database and thereby see the routes on their RadarBox screens.
I agree that it would be much better to get AirNav to use the data to update the server, but you'll have to ask them about that.
I'm certainly not about to engage in discussion with an organisation that thinks posts like #286 above are acceptable.
-
In parallel running of Radarbox and FD7.5 today, out of 354 FlightIDs, FD7.5 returned 84 different or additional routes:
FN FD7.NO FD7.ND FD7.CH anrb.NO anrb.ND anrb.CH
AA41 LFPG KORD 20101001000000
AAL51 EGKK KDFW 20100930000000 EGLL KDFW 20100929000000
AAL9420 KLAX EGLL 20101001000000
AEU781P EGKK CYHZ 20100930000000
AIC127 EDDF KORD 20100930000000 VOHS EDDF 20100903083411
AIC191 EDDF KEWR 20100930000000 VAAH KEWR 20100924000000
AWE707 EDDM KPHL 20100930000000 KPHL KDCA 20100905121632
BCY505D EGPH LFPG 20101001000000
BEE643 EGTE EGNM 20100930000000 EGNM EGPD 20100928100000
CFEMT CYYR BIKF 20100930000000
CGRFO CYYR CYUL 20100930000000 CYYR BIKF 20100929000000
CJT1891 CYYT EDLP 20101001000000 CYHM MUHA 20101001172514
COA17 EGPF KEWR 20100930000000 EGPF KLAX 20100905081531
COA37 EGPH KEWR 20100930000000 EGPH KMCO 20100924000000
DAL143 EDDF KDTW 20100930000000 EDDF KMSP 20100929000000
DAL243 VABB EHAM 20101001000000 VABB KDTW 20100929000000
DAL79 EDDT KJFK 20100930000000 KJFK KLAX 20100904110749
DAL8955 KPWM BIKF 20101001000000 KEWR KDFW 20101001100943
EXS6383 ENVA EIDW 20101001000000
EZE1041 EGPD EDDH 20100930000000 EIDL EGPD 20100929000000
EZE1803 EGPD EGPB 20101001000000
EZE26Z EGPD EGNX 20100930000000
EZY14PW EGPD EGGW 20100930000000
EZY238 EGPH EGSS 20101001000000 EGSS EGPH 20100929000000
EZY688Y EGPF LFPG 20100930000000
EZY905G EGPH LSGG 20100930000000
EZY94EG EGPH LEMD 20100930000000 EGPH EGSS 20100831093407
FDX9006 KBGR LFPG 20100930000000 KMEM KHRL 20100930155823
GEC8240 EDDF KDFW 20100930000000 KORD MMMX 20100905152201
GMA651 EGLF LFPB 20100930000000
GMA665 KBGR KBCT 20101001000000
ICE436 BIKF EGCC 20101001000000 BIKF BIKF 20100924000000
IRL251 EIME EINN 20100930000000
KAI80 KSDM EGPE 20101001000000 KOAK KEGE 20101001174736
KLM663 EHAM KIAH 20100930000000 KIAH EHAM 20100904125343
MON7648 EGPH GCRR 20100930000000 EGPD LEPA 20100909145709
N118EA CYYR BGBW 20101001000000
N427SA EGPH KPTK 20101001000000
N436QS CYYT LIBR 20100930000000
N450EE KACK KBED 20101001000000
N454QS KTEB EGPH 20101001000000
N53235 CYYR BGBW 20101001000000
N604FJ KBGR EBAW 20100930000000
N817ME CYYR LFPB 20101001000000
N8220M CYYR BGBW 20100930000000
N874C CYYR EGGW 20101001000000
NAO990 PHNL PGUA 20100930000000 KDFW KJFK 20100930112802
NCR0601 CYQX EETN 20101001000000 TJBQ GVAC 20101001081416
NJE5HW EGSH LFPB 20100930000000
NJE5LE LFSB EGLF 20101001000000
NJE7QC EHAM EGPH 20101001000000
RYN530 KBGR EDDP 20101001000000
RYN532 EDDP KLSF 20100930000000 KAEX EDDP 20100930075633
RYN7120 KSVN EDDP 20100930000000 KVCV KRFD 20100930155750
RYR29YV EGPK EPWR 20101001000000
RYR2RC EPGD EIDW 20100930000000
RYR5WA EGPH LEPA 20101001000000
RYR61KF EIDW EGPD 20100930000000
RYR69RF EVRA EIDW 20100930000000
RYR6DC EGPH LFBD 20101001000000
TCX24K EGCC CYVR 20101001000000 CYYC EGKK 20100910143616
TCX31K EGCC MUHG 20101001000000 EGCC CYYC 20100903114337
TCX84K EGKK CYVR 20101001000000 EGKK EGKK 20100924000000
TCX86K EGCC TBPB 20100930000000 EGKK CYVR 20100909102411
THT7 LFPG KLAX 20100930000000 LFPG NTAA 20100924000000
TSC409 LFPG CYYC 20101001000000 LFPG CYVR 20100924000000
UAL901 EDDF KSFO 20101001000000 EDDF KSAN 20100923000000
UAL909 EHAM KORD 20101001000000 EHAM KDEN 20100903102656
UAL917 EDDF KIAD 20100930000000 EDDF KSEA 20100905120042
UAL926 KSFO EDDF 20100930000000 KLAX EDDF 20100924000000
UAL927 EDDF KSFO 20101001000000 EDDF KLAX 20100831165621
UAL929 EGLL KORD 20100930000000 EBBR KORD 20100909072628
UAL931 EGLL KSFO 20100930000000 EGLL KLAX 20100929000000
UAL933 EDDF KIAD 20100930000000 EDDF KDEN 20100905162804
UAL935 EGLL KLAX 20100930000000 EGLL PHNL 20100929000000
UAL939 EGLL KDEN 20100930000000 EGLL KSAN 20100929000000
UAL941 EDDF KORD 20100930000000 EDDF KDEN 20100929000000
UAL943 LFPG KORD 20100930000000 LFPG KLAX 20100929000000
UAL945 EDDF KORD 20100930000000 EDDF KLAX 20100905074528
UAL947 EHAM KIAD 20100930000000 EHAM KLAX 20100831111554
UAL953 EDDF KIAD 20100930000000 EDDF KPHX 20100905103943
UAL955 EGLL KSFO 20100930000000 EGLL KSAN 20100929000000
WIF0393 EGPD ENBR 20100930000000
WWI14 KTEB EGGW 20100930000000 KSAT KTCS 20100930071104
Using route lookup sites in the following order:
1. FRL Service
2. FlyteCom
3. FlightAware
4. FlightStats
5. Libhomeradar
-
What does the FD7.CH column indicate ?
-
What does the FD7.CH column indicate ?
Its the "Posted" date from the FD7 routes table. And you've also spotted my deliberate error!!! I picked up FD7 routes from yesterday as well.
After a few days of using FD7, I've decided that it gives me most of what I need for routes. Attached are today's new/corrected routes.
-
In parallel running of Radarbox and FD7.5 today, out of 354 FlightIDs, FD7.5 returned 84 different or additional routes:
That's 24% which is high but as we mentioned before it's difficult to draw any conclusions without thorough checking.
On which point the very limited time I spent this afternoon working on EGNX flights was sufficient to convince me that I can crack the majority of lo-cost flights, esp. Ryanair & BMI in and out of EMA.
It's a bit laborious and time consuming but a bit of experience on my part will speed things up. Anyone who can monitor a local airport that offers an accurate flight info service can make a big impact on these missing routes.
An encouraging day one way and another.
-
I'm certainly not about to engage in discussion with an organisation that thinks posts like #286 above are acceptable.
Dave - while you have a lot to add - if I was AirNav I would have banned you for the constant sniping which adds little to to this forum. You must accept that this forum is owned by AirNav - please respect that.
I am an "outsider" but I even feel dubious when you start offering services.
This is an AirNav forum and so all suggestions must be for the benefit of Radarbox users in general or else they do not belong here.
-
Of those 84 you quote around 25 are Bizjets who use the same callsign on many different routes and should be discounted. I think FDX9006 and AEU781P are non revenue positioning routes that can also vary. And NOA990 is a US mil charter over various routes. Takes the numbers right down.
Another one is
THT7 LFPG KLAX 20100930000000 LFPG NTAA 20100924000000
I believe this route to be LFPG-KLAX-NTAA and maybe in Airnav the middle stop is included
The two AIC correctly in Airnav have start and end of route (and no doubt) middle whilst FD only has the Europe to USA sector.
Doesn't make such a big difference now
-
I'm certainly not about to engage in discussion with an organisation that thinks posts like #286 above are acceptable.
Dave - while you have a lot to add - if I was AirNav I would have banned you for the constant sniping which adds little to to this forum. You must accept that this forum is owned by AirNav - please respect that.
I am an "outsider" but I even feel dubious when you start offering services.
This is an AirNav forum and so all suggestions must be for the benefit of Radarbox users in general or else they do not belong here.
Quote.
"I would have banned you for the constant sniping which adds little to to this forum."
Well said Chris11 its about time someone said that, must people on this site would be scared to say it, again well done Chris11.
-
I'm certainly not about to engage in discussion with an organisation that thinks posts like #286 above are acceptable.
Dave - while you have a lot to add - if I was AirNav I would have banned you for the constant sniping which adds little to to this forum. You must accept that this forum is owned by AirNav - please respect that.
I am an "outsider" but I even feel dubious when you start offering services.
This is an AirNav forum and so all suggestions must be for the benefit of Radarbox users in general or else they do not belong here.
Quote.
"I would have banned you for the constant sniping which adds little to to this forum."
Well said Chris11 its about time someone said that, must people on this site would be scared to say it, again well done Chris11.
I think Dave's great!!
-
On which point the very limited time I spent this afternoon working on EGNX flights was sufficient to convince me that I can crack the majority of lo-cost flights, esp. Ryanair & BMI in and out of EMA.
That's very good news. If you don't fancy banging those into the database via the website one at a time, I should have the CSV import working later today, so feel free to post them as a file. Hopefully we will be able to tie up at least some of the far ends of the routes, which will be to everyone's benefit.
-
DaveReid,
Considering you have tried to sell your services (Aircraft, Routes) to us at vastly high price and used the forum to try and leverage us on more than once occasion. We would have to question your motive here.
We would just like to make our customers aware what and whom they are dealing with.
It would appear that the above post by AirNav is confusing at least a couple of members, maybe more. That may or may not be its intended purpose - I don't know.
Either way, allow me to put the record straight.
It's no secret that, several months ago, AirNav and I negotiated re the supply of aircraft data. Equally, it's no secret that we couldn't come to any agreement in the end - that's how business works, you can't win 'em all, and I have no problem with that.
I have no problem either if AirNav now choose to describe the product I was offering as having a "vastly high price" - they are entitled to their opinion. Likewise, if I said that it, and AirNav's subsequent actions, simply demonstrated that they don't understand the value of anything, I would just be expressing mine.
So far, so good.
However for AirNav to assert that I have been trying to sell them a commercial Routes service (which I don't have) is simply a lie.
Sure, I operate www.flightroutelookup.com, and have done for some time now. It's an enthusiast service, with hundreds of users, both direct and via FlightDisplay.
It's open to absolutely any individual or organisation (AirNav included) , it's free to use, and comes with no warranties whatsoever.
How that translates into me trying to sell routes to AirNav, I have no idea.
Ditto for the new, collaborative route update service that I and several forum members are now working on - that's there for anyone to use, on the URL I posted, and the results of matching takeoffs to landings will be freely available to everyone to import into their local databases, should they so desire.
So, AirNav, I would suggest that you either produce some evidence that I have been trying to sell you routes, or acknowledge that you are lying when you say so.
I hope this clarifies things for any members who may have been misled.
-
What an absolute shower.
-
Oh oh the bad boys are back in town. Give it a rest both sides and allow us to get on with our hobby.
P.S. you may not have noticed but the route look up doesnt work as well as intended.
Alan
-
P.S. you may not have noticed but the route look up doesnt work as well as intended.
Meaning ... ?
-
Dave - you have made it very clear you do no want to share with AirNav - remember the "teach a man to fish" comment
Have you changed that?
I have also been into your site and can't see how to download - am I missing something.
So far, in this topic we have the Flight numbers for three airlines and ideas for sorting out more codes. Please do not sidetrack that.
PS - I am also well on my way to produce the file for UAL. I have a pdf file of all their routes and am in the process of converting that to text for an import file
-
Meaning that we all know and have done for some time that the routes detailed are not correct or non-exittant and I feel that this thread is going on and on and covering old ground each time as if the problem has just been discovered.
Yes I would like the correct routes to be shown and Airnav have asked for some patience while they try and sort it out, if they can and I appreciate the efforts being made by users to overcome the problems.
Unfortunately the debate always seem to sink into mudslinging by people who should really know better. Airnav are just as bad as some of the members in this and while I understand their annoyance at some of the more graphic posts by some of the radarspotters elements who frequent the board for their own ends, they should show some moderation in their postings and do not take the bait. While I can understand wanting to reply, the tone set doesnt help matters.
Alan
-
Of those 84 you quote around 25 are Bizjets who use the same callsign on many different routes and should be discounted.
Yes, I suspect these are coming from Libhomeradar, so I've now excluded Libhomeradar from the FD7 lookup sequence.
-
Dave - you have made it very clear you do no want to share with AirNav - remember the "teach a man to fish" comment
Have you changed that?
I have also been into your site and can't see how to download - am I missing something.
So far, in this topic we have the Flight numbers for three airlines and ideas for sorting out more codes. Please do not sidetrack that.
PS - I am also well on my way to produce the file for UAL. I have a pdf file of all their routes and am in the process of converting that to text for an import file
No, I haven't changed my view about AirNav learning to fish :-)
Specifically, delivering what they promised us - a working algorithm that will produce many more routes from network traffic than we could ever hope to populate manually as as individuals.
In the meantime, the matched routes download, in the form of both CSV and SQL statements, should be up on the site later today, although of course it's early days yet and we need a lot more recorded takeoffs and landings before it will start to produce results.
All contributions are welcomed, either via the website or as files.
-
All I get is "server error 403 - Forbidden: Access is denied...You do not have permission to view this directory or page using the credentials that you supplied." when I try n look at http://www.flightroutelookup.com/ ????.................................
-
All I get is "server error 403 - Forbidden: Access is denied...You do not have permission to view this directory or page using the credentials that you supplied." when I try n look at http://www.flightroutelookup.com/ ????.................................
Sorry, I should have made it clear that these are the URLs:
www.flightroutelookup.com/FlightRoute/FlightLookup.wso?op=FlightLookup for the main FRL database to look up routes - that's also the address for the web service interface, and there's a link at the top where you can download the WSDL if you want to build your own automated lookup client
www.flightroutelookup.com/FlightRoute/FlightRouteUpdate.asp for the collaborative database that will match observed landings and takeoffs to derive routes that are currently unknown
-
All contributions are welcomed, either via the website or as files.
What format for the files, and where do we send them? I can produce a file of daily Inverness arrivals/departures. Thanks.
-
What format for the files, and where do we send them? I can produce a file of daily Inverness arrivals/departures. Thanks.
FLIGHT_ID,ORIG,DEST,DATE,TIME
BCS8491,,EGNX,"1/10/2010",2320
Header line is optional, time is assumed to be ATA/ATD at your local airport, in local time.
Either post the CSV file here as an attachment, or email direct to me, I'll PM you with the address.
-
Flightinair - that's not Thick Mick again is it. He's had more nome-de-plumes than I've had hot dinners. :o)
-
Has anyone got a file with the IATA and ICAO codes for airfields
-
Has anyone got a file with the IATA and ICAO codes for airfields
FlightDisplay comes with a CSV file containing over 8000 airfields, with ICAO and IATA codes and also latitudes/longitudes.
You don't need to install the program, simply extract the CSV from the ZIP.
http://sites.google.com/site/0flightdisplay/homepage
-
Flightinair - that's not Thick Mick again is it. He's had more nome-de-plumes than I've had hot dinners. :o)
yes someone told me about you, they call you DADS ARMY.
you got the wrong chap buddy.
-
Flybe weekend routes
Lets get back to what we love the most. Find attached the weekend alpha numeric routes for Flybe this Saturdat.Hopefully Tarbat will convert to a .csv file for us?
Cheers
Mark
-
Lets get back to what we love the most. Find attached the weekend alpha numeric routes for Flybe this Saturdat.Hopefully Tarbat will convert to a .csv file for us?
Thanks Mark. CSV and SQL statements attached.
-
This link is to BHX departure and arrivals board.
http://www.birminghamairport.co.uk/arrivals-and-departures.aspx
Anybody within proximity of BHX fancy putting in some time on the non-route flights coming and goings and tying them up? Takes only a little bit of practice and it's very satisfying as well as adding to our database.
-
Lets get back to what we love the most. Find attached the weekend alpha numeric routes for Flybe this Saturdat.Hopefully Tarbat will convert to a .csv file for us?
Thanks Mark. CSV and SQL statements attached.
Thank you Mark for the origonal data and thank you to Tarbat for
the conversions.
Best regards,
Ian.
-
Thanks for your lists Mark, these have filled a lot of gaps in my route database.
Cheers
Stewart
-
A few Birmingham flights added to the project database tonight
-
I still think there should be an update team as for the aircraft. You eat an elephant one bite at a time.
Dave - is the download functionality in process?
Just one comment on the program - if you update one flight (by clicking Save) and then enter another flight number - same dep and dest but different time and then save again you overwrite the first entry - you have to click clear and then start again. Could that be changed?
-
A few Birmingham flights added to the project database tonight
I decoded 41 new alpha-numerics in & out of EMA over the weekend which, while labourious, shows that the callsign enigma can be cracked piece by piece.
The exercise also threw up some wrongly decoded flights - ie flights erroneously showing EMA as part of the route. Not sure how we can get these removed?
-
I still think there should be an update team as for the aircraft.
There is - it's just that for routes, the team is independent of AirNav.
Dave - is the download functionality in process?
Not yet, I've been a bit preoccupied over the weekend (see below), plus we're only just starting to match the first takeoffs and landings, so there's not much to download yet. If you want to download what's been done so far, it's easy enough for the time being to copy-and-paste from the route listing report into Excel.
Just one comment on the program - if you update one flight (by clicking Save) and then enter another flight number - same dep and dest but different time and then save again you overwrite the first entry - you have to click clear and then start again. Could that be changed?
Fair point - but there's a better way of addressing that. I know from writing commercial web applications that users often like to see the record once it's been saved, so removing the data from the screen as soon as it's saved isn't such a good idea. However to prevent records being overwritten, the database will now disallow changes to the Flight ID of an existing record.
Over the weekend I've captured several thousand takeoffs and landings from the network, a significant proportion (around 1400) showing blank routes, and these are in the process of being added to the database.
The distinction of being the first route to have both origin and destination derived from a captured takeoff and landing goes to Saturday morning's JZR171 (J9171), a Jazeera AW flight from Dubai to Kuwait, now safely stored in the database.
-
Great - that will eliminate the overwrite of the record.
Confirm that to enter more than one route you will have to add the data, click save, click clear and then add again.
-
Confirm that to enter more than one route you will have to add the data, click save, click clear and then add again.
Correct, or if you don't click Clear you can make changes (other than the Flight ID) to the record currently on screen.
-
I decoded 41 new alpha-numerics in & out of EMA over the weekend which, while labourious, shows that the callsign enigma can be cracked piece by piece.
Keep up the good work chaps, much appreciated !
The exercise also threw up some wrongly decoded flights - ie flights erroneously showing EMA as part of the route. Not sure how we can get these removed?
If you mean wrongly decoded by the AirNav server, you will have to ask them, although they have already stated that they aren't interested in feedback on individual routes.
If you see or suspect an erroneous route in the new database, I've added a Notes field so leave a suitable comment and I'll deal with the offending record(s).
-
It looks to me that the datestamp on the route table was introduced mid 2008. It appears to me that route without a datestamp are out of date (based on a small sample)
It almost look to me that all routes with no datestamp should be deleted. I will have to do some more checking on a larger sample to confirm this
-
The lookup for airports shows FAJS as Jan Smuts - it is now the O R Thambo International
-
The lookup for airports shows FAJS as Jan Smuts - it is now the O R Thambo International
Airports index duly updated. I've used Tambo, rather than Thambo, as that seems to be the usage preferred by the airport itself.
-
Oooops Tambo it is
-
All SAA flights between FALE and FACT will cease on 1 November.
These flights will be taken over by Mango (MNO) who will absorb the passengers in its normal flights. No announcement has been made by Mango as to increased flights (yet)
-
Hi Dave,
I have just added a number of routes to my routes db but they are not populating for some reason.
Do you have any idea why not, or what I'm doing wrong.
Thanks
Andrew
-
Were the aircraft displaying while you updated? Normally need to exit and open again to get the data displaying
-
Chris,
I did restart the software but still no route info.
Andrew
-
Hi Andrew
No, I can't see aHi Dave,
I have just added a number of routes to my routes db but they are not populating for some reason.
Do you have any idea why not, or what I'm doing wrong.
Thanks
Andrew
No, I can't see any reason why what you are doing shouldn't work. The screenshot looks like you have updated the database OK.
I don't personally use RadarBox's built-in Database Explorer as the user interface is hopeless - do you have access to any other SQLite utilities that you could try ?
-
I have added an SQL download facility to the Flight Route Update website/database.
This can be used to produce an update file which can be loaded straight into your NavData.db3 using any of the available SQLite utilities.
www.flightroutelookup.com/FlightRoute/FlightRouteUpdate.asp
Feedback welcomed.
Dave
-
Dave,
I used SQLite Maestro (from a Access db file) to import the new routes into the NavData.db3.
Andrew
-
Here's another flight
-
Here's another flight
OK, I think I know what's happening, and why.
I've done some tests, and it would appear that RadarBox can't handle route lookups where a Flight ID is in the format that CCM Airlines uses on its routes, even when the same flight number is already in the Routes table in your NavData.db3.
As far as I can see, there is no workaround for this.
-
Dave,
I suppose you mean a format with 2 letters + 3 numbers + 2 letters.
Looking down the Flight Id list there are also a number of Air France flights in this format without route info.
Are AirNav aware of this problem?
Andrew
-
So these flights will never auto-populate?
-
I found to get the route to display you need to populate the NV column with something like"." and then delete it again if you dont want to display the "." . This will then turn the box from pink to white.
Try one and see if it works by restarting
Another little bug:-)
-
No, those flights will never populate and yes, I believe AirNav are aware of the problem - or if they weren't, they are now :-)
-
Should those flights really be setting there Flight IDs to that method? Is this an pilot/airline error in entering the Flight ID.
-
Air Nav,
CCM Airlines have over 200 flight ID's with this format.
Air France also use this format, see screenshot below. How can it be airline/pilot error?
Andrew
-
As far as I am aware, they should be using the ICAO-Code format (3 letters) - I will get this confirmed.
Andrew please be aware that while they are broadcasting ADS-B, many of the rules regarding Flight IDs etc.. haven't been enforced strictly yet as many countries are not using this for ATC yet.
-
AirNav,
As far as I am aware, they should be using the ICAO-Code format (3 letters) - I will get this confirmed.
Does this mean that the RB will not accomodate for Flight ID's unless they are using the ICAO-Code format (3 letters).
Andrew
-
Does this mean that the RB will not accomodate for Flight ID's unless they are using the ICAO-Code format (3 letters).
It would appear so.
I don't know why that should be, it's only a lookup after all, but I guess we'll have to live with it.
Perhaps AirNav should contact CCM and Air France to advise them of the issue.
-
As mentioned earlier all aircraft should be following the ICAO format for there Flight IDs. There is no issue with our software, it was designed to handled what is specified which in this case is ICAO format flight ids.
As a famous programming saying goes, garbage in -> garbage out.
In the past when we have seen non ICAO codes they usually been mistakes and eventually been rectified. When the next version is released, if there is a significant portion of non ICAO flights appearing we may change the system to allow these routes.
-
The Eurocontrol rules for mode S is that you put into the transponder what is on your flight plan in field 7 of the ICAO flight plan format. That should be your ICAO flight number
-
The Eurocontrol rules for mode S is that you put into the transponder what is on your flight plan in field 7 of the ICAO flight plan format. That should be your ICAO flight number
No argument there.
But the issue is that, if airlines like CCM and Air France have a standard range of non-ICAO Flight IDs, which clearly they do, and if we know the routes for those flight numbers, why shouldn't we be able to put these in our local database and do lookups on them too ?
I don't understand what the difficulty is - could someone explain, please ?
-
Should be no problem - it is a simple sql lookup. Might need to remove some programming that does a check for the standard though
-
The lookup will only occur if there is 3 letters at the start of the Flight ID.
-
The lookup will only occur if there is 3 letters at the start of the Flight ID.
So we can assume that will be changed in the next version ?
-
Explained in
http://www.airnavsystems.com/forum/index.php?topic=5333.msg56192#msg56192
-
Sorry, Andrew - I tried !!
-
Actually speaking to our devs, they say this was actually changed in the past but does not have the exact details.
Andrew can you send us a screenshot of what is in your database, comparing to what you see on the screen.
FYI, Just checking the network, AZ65F is showing with a route, a few AA flights. It may be that the route look up across the network has two and three letter lookup. We will check this.
-
Here are the screen shots I put in previous posts.
-
Dave - if the update database only allows one entry per flight number then we need a via field
-
Some quick stats from MyLog db for 3 major french airlines
The numbers are unique callsigns.
Air France - 529 callsigns
316 / 60% 2 letter codes (AF)
213 / 40% 3 letter codes (AFR)
Air France Regional - 169 callsigns
134 / 79% 2 letter codes (RA)
35 / 21% 3 letter codes (RAE)
CCM Airlines - 184 callsigns
184 / 100% 2 letter codes (CC)
Out of 882 callsigns, only 248 or 28% will have the chance of being populated.
Andrew
-
Dave - if the update database only allows one entry per flight number then we need a via field
The Flight Route Update database does allow multiple entries per flight number.
In fact that will often be how it's used.
For example, one member records flight ABC123 taking off from airport XXX, and another member records ABC123 landing at airport YYY, and maybe even taking off from there again if it's a multi-leg flight.
Once takeoffs and landings are matched, they go into a master routes database, but even that one allows for multiple entries per flight number to cope with IVs, like our old friend AIC188, although obviously you won't be able to import more than one route per flight number, or routes with 2 or more stops, into your RadarBox Navdata.
-
Hi Andrew,
Yes, fingers crossed they realise there mistake and inform the crew when they input the Flight IDs. Obviously that percentage is high but when compared against the rest of flights showing up on the network its very small which have the icao flight id. Infact yesterday when we did the quick check, out of 700 flights on the network we could only find a couple with non icao ids.
-
Tuesday there was a Ryanair flying about with ID RY. 2numbers 2 letters - an error one assumes.
-
Yes, fingers crossed they realise there mistake and inform the crew when they input the Flight IDs. Obviously that percentage is high but when compared against the rest of flights showing up on the network its very small which have the icao flight id. Infact yesterday when we did the quick check, out of 700 flights on the network we could only find a couple with non icao ids.
Does it seem likely that 100% of CCM Airlines crews will "realise there mistake", when clearly they are doing what they have been told to do ?
I don't understand your reference to "only a couple" of flights on the network with non-ICAO IDs - I've just had a quick look at my network log for yesterday and around 25% of Air France flights used IATA callsigns, plus of course all of CCM's. And that's without taking into account all the regionals' non-ADS-B flights that don't appear on the network at all.
But what I don't understand most of all is your seeming reluctance to agree to what must be a trivial change to the program. Why not make it work as the manual says it does - if the received FlightID is in your local Routes table, then you will see the route on the screen ?
-
Can you explain what you mean by your network log? Would you like to go into detail about this?
We do recognise there are flights which are not using the icao conversions incorrectly. However the stats are not that high when compared to the whole network flights stats, infact they are small.
As we have said before and we have to repeat this for the 2nd time to you, we will add this functionality if we deem this problem to be causing major issues. If you want to make a mountain out of a mole hill with this issue Dave then please don't, take the issue up with the airlines as they are the ones causing it.
At the end of the day here, our process is correct and the issue is with the airlines not following correct proceadures. If we were to correct every issue that is caused by ADS-B we would need to correct the drift on some aircraft, the callsign 747 changing issue etc.. We do have the draw the line.
-
In the past when we have seen non ICAO codes they usually been mistakes and eventually been rectified. When the next version is released, if there is a significant portion of non ICAO flights appearing we may change the system to allow these routes.
So is this different from what was said last night ?
-
As we have said before and we have to repeat this for the 2nd time to you, we will add this functionality if we deem this problem to be causing major issues. If you want to make a mountain out of a mole hill with this issue Dave then please don't, take the issue up with the airlines as they are the ones causing it.
Of course it's a major issue, 25 pages of script should be able to tell you that! something
-
RobinB,
We still investigating whether the network only allows non icao look ups. However our view hasn't changed from last night.We just mentioned it again.
Southwest,
Please read the last few posts again. This hasn't got anything to do with the 24 pages of posts. This is an airline/crew issue.
-
Of those 84 you quote around 25 are Bizjets who use the same callsign on many different routes and should be discounted.
Yes, I suspect these are coming from Libhomeradar, so I've now excluded Libhomeradar from the FD7 lookup sequence.
Interestingly, since excluding Libhomeradar from my FD7 lookup sequence, the success rate in FD7 has dropped to 53%. That is, out of 893 autopopulate route lookups, FD7 found routes for 470.
So, it looks like we have a choice when using FD7:
1. Include Libhomeradar in the lookup sequence, but suffer from data that is either incorrect, out-of-date, or irrelevant.
2. Exclude Libhomeradar, and only achieve 53% success.
This is not a criticism of FD7. It just illustrates that none of the established lookup services (Dave's FRL service, FlightStats, Flytecom, & FlightAware) can resolve many of these difficult flight IDs.
For info, these are the Flight IDs where route lookup failed in FD7. I realise that some of these you would not expect to find a route for (eg all the G-FRA* flights).
3AMRG, AAC587, AC15258, AEA282, AEU501F, AEU502F, AEU504F, AEU901F, AEU901N, AFR83U, AFR84U, AUF433, AWC11H, AWC91A, AXIS01, AZTEC01, AZTEC02, BCS2704, BCY172Y, BCY174Z, BCY176Y, BCY505D, BCY505E, BDI18B, BDI19A, BDI19B, BDI20C, BEE13Y, BEE19M, BEE1CN, BEE1EV, BEE1JM, BEE2DY, BEE2RL, BEE3KR, BEE3LT, BEE3MG, BEE3PR, BEE3RW, BEE3VD, BEE51PM, BEE5BQ, BEE5CX, BEE6CD, BEE6CM, BEE6DL, BEE6DW, BEE6GT, BEE6KB, BEE6RN, BEE7WB, BEE7YQ, BEE8BC, BEE8EW, BEE8RV, BEE9EL, BEE9JG, BEE9YD, BGH9003, BHA6EH, BHL49A, BHL69X, BIRD, BKK3C, BMA1EH, BMA1WC, BMA2EH, BMA375Q, BMA376A, BMA3EH, BMA3NL, BMA3WC, BMA4EH, BMA5EH, BMA5WC, BMA67G, BMA6EH, BMA7EH, BMA7NL, BMA9EH, BMA9NL, BMI24N, BMI62L, BMR134V, BMR1369, BMR160Q, BMR375Q, BMR376A, BMR683V, BMR86DM, BMR9131, BMR9132, BMR9151, CFC4011, CFE25D, CFE64D, CFE75D, CFE97D, CLF8, CLU2349, CLUB2, CMB519, CMB521, CWL45, CWL93, CWL94, DCVJN, DLH404U, DLH440U, EICVR, EIN25S, EXS10J, EXS136P, EXS143P, EXS4E, EXS81PH, EXS9G, EZE1040, EZE1041, EZE11W, EZE12W, EZE13W, EZE14W, EZE19Q, EZE26Z, EZE27K, EZE27Z, EZE28Z, EZE32F, EZE36F, EZE36X, EZE40D, EZE41D, EZE51U, EZE52U, EZE55G, EZE57U, EZE58U, EZE59U, EZE61L, EZE65L, EZE66L, EZE67L, EZE81Z, EZE82Z, EZE83B, EZE88B, EZY12GW, EZY14PM, EZY14PW, EZY14WD, EZY198A, EZY1DH, EZY21LH, EZY2DP, EZY56PH, EZY688Y, EZY695U, EZY6LX, EZY905G, EZY94EG, EZY9VE, EZY9YG, FLJ423F, FLJ427F, FPO301, GBLYK, GCGNE, GFFRA, GFRAH, GFRAI, GFRAK, GFRAP, GFRAR, GFRAT, GFRAU, GFRAW, GLAZL, GLCYA, GMA636, GMA664, GMA685B, GMA691B, GMA701, GMA702, GMA713, GRSKR, GTI604W, GUTS64, HBJUS, HFY611P, HFY612, HFY631, ICE1540, IFA450, IWD6202, JKK235, JTG9880, KLM33G, KLM34G, KLM35Z, KLM36Z, KLM40M, KLM44M, KLM63B, KLM64H, KLM65G, LOG12AT, LOG13ML, LOG14LG, LOG16BM, LOG19ED, LOG21EG, LOG23DB, LOG23HE, LOG26LW, LOG27LR, LOG27RD, LOG32MD, LOG32PA, LOG39DN, LOG41JH, LOG41NW, LOG41VM, LOG45SG, LOG46DM, LOG48AL, LOG48DJ, LOG51HP, LOG52YT, LOG56HL, LOG56NG, LOG57JA, LOG58ML, LOG58WG, LOG58YB, LOG61ZW, LOG62CN, LOG64DZ, LOG67CK, LOG69CW, LOG72YZ, LOG74PN, LOG76WB, LOG781, LOG782F, LOG78HL, LOG78TM, LOG79YE, LOG82VE, LOG830F, LOG83HB, LOG83PZ, LOG83ZM, LOG851, LOG852, LOG87AD, LOG89PE, LOG91DT, LOG91GK, LOG92MU, LOG93VC, LOG96DE, LOG96RH, LOG97GZ, LOG97KG, MBWFC, MIFLY, MINOR, MJF705, MMACH, MMD1332, N218WW, N545CC, N551GA, N555TQ, N624BP, N767A, N767FL, N777KK, N944H, NATO09, NATO10, NATO11, NATO32, NATO33, NATO36, NJE129B, NJE213C, NJE241P, NJE305N, NJE3LD, NJE3VN, NJE467D, NJE4DU, NJE558Q, NJE571U, NJE595P, NJE680G, NJE702E, NJE784P, NPT873, OKMYS, OOMAS, P248, PCH251, PIRATE2, PPR93, PRI603, QAF6, QID30, QID96, RAE556, RAE557, RAE558, RAE559, RAE560, RCH189, RCH228, RCH234, RCH329, RCH353, RCH377, RCH379, RCH385, RCH453, RCH566, RCH578, RCH579, RCH621, RCH697, RCH805, RCH8094, RCH822, RCH988, RFR7171, RRR1693, RRR1918, RYR12KL, RYR16ZE, RYR1T, RYR28ET, RYR2PZ, RYR2RC, RYR2ZH, RYR31FV, RYR3HE, RYR3TC, RYR54ME, RYR57WC, RYR58VQ, RYR5BJ, RYR5WA, RYR5YF, RYR69RF, RYR6DC, RYR6MH, RYR6VP, RYR84CL, RYR8F, RYR93LN, SCARS56, SHT12G, SHT17D, SHT17Q, SHT17S, SHT17U, SHT18C, SHT18E, SHT18F, SHT18H, SHT18V, SHT18Y, SHT18Z, SHT19A, SHT19M, SHT19T, SHT19U, SHT19W, SHT19X, SHT7A, SHT7U, SHT8B, SHT9B, SHT9C, SHT9E, SHT9F, SHT9J, SHT9N, SHT9P, SHT9T, SHT9U, SHT9Y, SHT9Z, SJT113, SJT114, SNOOP55, SRR6565, ST18V, STELLA0, SVA037, SVW1LA, SXN41E, T346S, TARTN31, TARTN32, TCX580K, TCX68GR, TEST000, TVS125, UAL901B, UAL901U, VIK821, VIK83P, VIK891A, VJS697, VKG9992, VTSGT, WDG64, WZZ315Z, WZZ316J, WZZ416K,
-
since we can't get official data all of the look ups are subject to error in submission by the people doing it. For example people close to airports are able to tie routes up from sightings to online arrival departure sources but sometimes a couple of flights from the airline being present at the same time can cause the routes to get transposed.
I would hope that airnav should be able to amend the software to display whatever is in the database field to resolve the 2 letter code issue. Does it only apply to French/French dependency airlines?
-
Air Nav - my apologies.
However with over 26 pages of threads all related in some way to Improved Routing Information it is apparent that this topic is a 'hot' issue with Radar Box users and we look forward to you coming up with a solution to it. Please though, sooner than later!
-
For info, these are the Flight IDs where route lookup failed in FD7. I realise that some of these you would not expect to find a route for (eg all the G-FRA* flights).
You will be pleased to hear that, excluding the military, bizjets and reg-as-callsign flights in your list, a number of the flights and carriers featured (BCY, BDI, EZY, LOG, RAE, RYR, WZZ, etc) are starting to appear in the Flight Route Update database.
While we don't necessarily (yet) have both ends of every route, without which they can't go into FRL, we've had considerable success with enthusiastic users monitoring Mode S and their local airport's website simultaneously.
-
You will be pleased to hear that, excluding the military, bizjets and reg-as-callsign flights in your list, a number of the flights and carriers featured (BCY, BDI, EZY, LOG, RAE, RYR, WZZ, etc) are starting to appear in the Flight Route Update database.
That's a good point Dave. Do you have plans to include the results of this exercise into your FRL service? In that way the efforts of the Radarbox community to resolve these difficult routes will become available to users of FD7 across the whole VR community, regardless of which hardware they're using. Even better, maybe you could encourage owners of other VR hardware to also contribute. Or even operators of other flight sharing networks.
I've tried my best with Loganair flights into Inverness (EGPE), but unfortunately getting the other end of these flights seems difficult. I've even tried MLAT'ing them, but they never get near another airport before dissapearing from MLAT.
-
If we were to correct every issue that is caused by ADS-B we would need to correct the drift on some aircraft, the callsign 747 changing issue etc.. We do have the draw the line.
That's a ridiculous analogy. Even professional ATC systems have problems with rotating B744 callsigns, so nobody is expecting you to come up with a solution for that. Likewise ADS-B drift - you can't possibly make corrections for that, so why raise it ?
Can you explain what you mean by your network log? Would you like to go into detail about this?
I'm not going to be drawn into a clumsy attempt to change the subject and divert attention from the issue under discussion, which is Flight IDs and routes.
-
Do you have plans to include the results of this exercise into your FRL service? In that way the efforts of the Radarbox community to resolve these difficult routes will become available to users of FD7 across the whole VR community, regardless of which hardware they're using.
Most certainly I do. Complete routes from FRU will start to be loaded into FRL over the next few days.
I haven't decided yet how to handle partial routes. For them to go into FRL would need some reprogramming, since obviously we can't do sanity checks on an ADS-B position if we have no idea where an aircraft is coming from or going to, as the case may be.
Even better, maybe you could encourage owners of other VR hardware to also contribute. Or even operators of other flight sharing networks.
Yes, in fact I have permission from the PlanePlotter folks to use sharers' traffic to deduce takeoffs and landings at airports covered by the PP network, although that process isn't operating at the moment.
I've tried my best with Loganair flights into Inverness (EGPE), but unfortunately getting the other end of these flights seems difficult. I've even tried MLAT'ing them, but they never get near another airport before dissapearing from MLAT.
Your efforts are much appreciated.
-
Needing some help here importing the sql.text file downloaded from the flight route update site.
I have Tarbets import route batch file, sqlite3 exe, anrb.exe and the text file in the one folder. I close down Airnav, run import route bat and when I start Airnav again and check in database explorer under routes, I cannot see any of the routes detailed on the sql.text document.
Where am I going wrong please?
Alan
-
I've just received an amazing PM from AirNav Support threatening (not for the first time) to ban me from the forum, on this occasion I'm told that I'm suspected of having "hacked" [sic] the RadarBox network, whatever that means.
I suspect that it's more to do with the recent debate on decoding Flight IDs where our views, to say the least, differ widely.
Some may, of course, agree that banning me would be a good thing :-)
Anyway, and just for the record, I have not "hacked" RadarBox or its network, I have no intention of doing so, and indeed would have no idea how to, were I so inclined. In fact , I'd always been under the impression that network traffic was encrypted, and my codebreaking skills are non-existent.
My usage of RB and the network does not involve any functionality other than that provided by the software to any user of the system.
AirNav are still, of course, at liberty to ban me, but any further allegation or imputation on their part that I have been involved in "hacking", or any other illegal activity, will be passed to my legal advisers.
-
As you have decided to publicly post on the forum like this we have no choice but to ban you untill you tell us what you meant by your network log and other posts. You ignored our earlier PM and post on the forum about it and only untill you were sent that PM did you actually think about replying.
You have stated more than once on this forum and others you have found other ways to analyse the network data and log the data ("I've just had a quick look at my network log for yesterday")You have been asked to explain your self and in your last post above you haven't done so at all.
For the sake of the security of RadarBox Network we have asked you to explain what you have meant but you haven't.
Its your choice, you will remain banned untill you explain your comments which identify you as accessing the network data. You know the various ways to get in contact with us if you choose too.
-
AirNav - I think you guys have made a mistake here. I have already said that I would have banned Dave because of the constant sniping which detracts from the from the actual item under debate. I find those comments irritating.
The problem I have is that we are now onto a project/idea that will be for the benefit of all your customers. Routes are an issue and anything that assists in improving that is positive. for you to ban Dave because of some suspicion that he has secret access is ludicrous. If Dave has a mechanism to record all the flights he sees on Radarbox or any other Mode S receiver then that is his prerogative. When he refers to his network log - surely he is referring to his log of flights.
I really think you guys have acted hastily and propose that you unban Dave with immediate effect.
-
Before we get some negative comments from customers regarding this banning let us explain the decision:
While DaveReid provides great assistance on key issues we cannot have network or RadarBox software integrity and security undermined and anyone who is seen to be damaging that will be questioned.
DaveReid last post which alerted us contained the following line.
"I've just had a quick look at my network log "
http://www.airnavsystems.com/forum/index.php?topic=5333.msg56216#msg56216
This is not either the first time he has commented on gaining access to the network data. He has made suggestions to this before and even further on other sites. As you will know the network data cannot be extracted from the RadarBox 2010 software, so we are concerned and hence have questioned him.
We have simply asked Dave to clarify this twice today which has been ignored before we sent him a further PM to gain this information.
If he has done no wrong doing he can easily explain his comments by emailing us otherwise he will remained banned.
-
Chris11,
If that is correct, he can easily be unbanned if he emails us. These PMs was going on behind the scenes and he has brought it to the public himself which has meant we had no choice but to ban him.
-
He has already said that - as I see it the ball is in your court
Anyway, and just for the record, I have not "hacked" RadarBox or its network, I have no intention of doing so, and indeed would have no idea how to, were I so inclined. In fact , I'd always been under the impression that network traffic was encrypted, and my codebreaking skills are non-existent.
My usage of RB and the network does not involve any functionality other than that provided by the software to any user of the system.
-
Chris,
His response does not explain much. How has got he got a log of the network data if it’s not possible via RadarBox?
This was asked to him via PM and post and both were ignored before we PMed him again. If it was nothing to be concerned about why didn't he email back saying so then and why hasn't he explained to us how he managed to log the network data.
If he has done nothing wrong he can explain to us how he has managed to get a network log if it’s not possible through RadarBox.
Otherwise we have a right to remain concerned if things don't add up for the integrity and security of the network.
-
To all concerned: we have been mentioned several times before that our forum is the largest mode-s related community on the internet - the forum is totally free but has rules: we constantly send PMs to users who don't follow those rules and advise them to correct their actions. Some users prefer to continue their actions and simply don't respect the other 4000 forum members who come here to enjoy this hobby and change ideas/know-how between themselves.
We cannot accept that a user constantly posts negative / false comments on our forum, doesn't answer PMs from our moderators and permanently halts any discussion going on.
Unfortunately and because of the huge success RadarBox is having we have users that connected or not with our competitors use our forum to damage RadarBox reputation and image. This is something our company will not accept.
-
Furthermore the link below contains another example:
http://www.airnavsystems.com/forum/index.php?topic=4283.msg43157#msg43157
He will need to explain that as well.
-
Hello
I personally would like to thank Airnav and think they have done the correct thing here. We should maybe now put this subject to rest and get on with our hobby of Radarbox. This forum has been pretty stirred up these last few months and if it means weaning out one or 2 bad apples then it should be done to get back to normal discussions and helpful hints.
Andrew
-
Hello
As he has deleted his account it turns his status into 'Guest'.
Andrew
-
Abrad41 has deleted his own account after sending a message which had to be removed (that's why he was seen as a guest - after removing himself from the forum). This kind of users should respect the 4000 forum members of this forum. There are lots of places on the internet for behind the scenes games.
Now let's turn this discussion into a positive one and focus on what we like RadarBox and the mode-s hobby.
-
Hello
As he has deleted his account it turns his status into 'Guest'.
Andrew
Andrew,
Cheers for that. I just wondered how a 'guest' was able to participate in the forum.
AN
I have also deleted the question I made to yourselves and the forum in general as I had quoted Abrad41's comments in my message and I notice you have quite rightly deleted his message. Oops, silly me !
-
Guys,
Hopefully not a silly question. When you go into File>Database Explorer and then the routes table, under the column headed CH I understand that the first lot of numbers are the date of any changes you have made to the route. My question is what do the following 6 numbers represent and is it something I should be putting in (I see they are different each time) or are these numbers automatically generated ?
-
The lat numbers are the time hh:mm;sec
-
Bearcat,
Thanks for that. Does that mean that if I just put in oooooo for the hours/min/sec it would still work ok and pick up the route change or do I have to be specific or does the RB pick that up itself and insert the hours/min/sec that I have made the change ?
Ian
-
When I manually in put a route I always put the date and time in, I've not tried it with just 000000 you could try it and see. I doubt the missing time will be automatically filled in by Rbox, but the full date and time are populated when the route is pickd up from the network
-
Cheers Mate,
Ian
-
Why does the route sometimes not display - not the non ICAO problem.
I have SAA036 on screen now with no route display. If I right click it shows that I have SAA036 FAJS to FBSK in the local database.
-
To get these to show create a route for the flight required without the leading "0" and the should then populate the next time they are received eg SAA36
-
Thanks - remember reading that somewhere.
Except I have SAA037 displaying its route properly 8-)
-
AS far as I can see the first time it populates from the network the route shows in list but subsequent contacts of the same flight do not show in the list like SAA037.
To see what happens enter a new route for SAA37 but with a wrong route and see which one is in the list
-
Flybe winter alpha numeric callsigns
Find attached the Alpha numeric callsigns for Flybe winter 10/11 .They are currently in PDF file hopefully my good friend Tarbat can convert to csv or text file to manually enter into the routes folder
Cheers,
Mark
-
hello
I have converted this into csv.
The format is callsign, origin (ICAO), destination (ICAO)
Andrew
-
I'd like to contribute to the routing population. Here are the ONLY numerical flights number of LIMC Airport.
Timestamp is the expire date of end March.
Then, day per day I write the alphanumerical callsign with the Tarbat’s Route Mach database of post#272 and DaveReid’s FRL
I can contribute with flights from/to LIMC, LIML and LIME
I remember that Lufthansa changes ALL flight numbers from Sunday.
Saturday night I empty the routes table of navdata to start from the beginning with routes and I turn off for the first week the routing autopopulate option. So, I can't overwrite with old routes.
I forgot to insert the EZY flights. Unfortunately I wrote the airports in IATA format. Tarbat or an other who can use SLQlite can convert these in ICAO format.
The Easy file is attached here now
Happy Iata winter season to all.
-
Is there an easy way of importing the flybee csv file to the local database or is there a way of converting it so that sqlite can import it please
-
Is there an easy way of importing the flybee csv file to the local database or is there a way of converting it so that sqlite can import it please
Try running this SQL
-
thanks Tarbat you're a star
One problem, when I run it in the screen is flashing error messages in the dos window about an error near "."
-
found the problem, now resolved
Kev
-
I noticed that there were no routes showing for Wizz flights. Here is a list that you might want to import.
PS - it took me about an hour to get all the Wizz routes sorted.
-
A useful source of route data is that used by the Planeplotter community and others. There is a database of 32000+ routes on a Yahoo group at
http://groups.yahoo.com/group/PP-logs-and-routes/files/
It even has those elusive Loganair routes :) I can't vouch for it's accuracy, but I believe a lot of work goes into updating it.
It's an SQLite database, so I've created the following SQL to extract the relevant data for import into a Radarbox routes table. I haven't included the vias (NV), since there aren't many in the database anyway.
SELECT DISTINCT
FlightRoute.flight AS FN,
substr(FlightRoute.route,1,4) AS NO,
substr(FlightRoute.route,length(FlightRoute.route)-3,4) AS ND,
"" AS NV,
substr(date('now'),1,4) || substr(date('now'),6,2) || substr(date('now'),9,2) || "090000" AS CH
FROM
FlightRoute
ORDER BY
FN
Airnav, how about adding these to your central database?
-
Hi Tarbat
Thanks for that link. Is there sql for dummies that will enable me to understand your post above.
I agree that Airnav should consider importing these. Anything is better than nothing.
-
I agree that Airnav should consider importing these. Anything is better than nothing.
Not quite Chris - I'd rather have nothing than some of the totally misleading rubbish that continues to plague my screen.
If it isn't accurate, leave it blank.
-
I agree that Airnav should consider importing these. Anything is better than nothing.
Not quite Chris - I'd rather have nothing than some of the totally misleading rubbish that continues to plague my screen.
If it isn't accurate, leave it blank.
Well, the ones I've checked from the Planeplotter routes database have all been spot on. Not sure how anyone can check all 32000 routes for accuracy, but I'm happy to use them in my routes table.
-
Hiya Tarbat - I and a few dozen others are still wating patiently on the sidelines. It would make a nice Christmas present? Or maybe Hogmanay?
Actually when Chris11 writes "anything is better than nothing" I have a horrible feeling he's closer to the truth than perhaps he thinks. Could be wrong though - we live in hope.
-
Hi Tarbat
Thanks for that link. Is there sql for dummies that will enable me to understand your post above.
Unless you understand SQL, I wouldn't recommend attempting an import of 30000+ records. I used SQLite Maestro to import the database, write the SQL query, export the data in XML format, and then import the XML data into the routes table.
Sorry if it sounds complex, but my programming skills don't extend to writing a program to do it automatically.
-
Thanks - got sorted
-
The problem with importing flight routes that you only see on the network is that they will never be updated so your database will continue to grow.
-
You're right Chris. Network flights always get their route information from Airnav's server. The only solution is for Airnav to update their server with these corrected routes.
-
Yep - as I see it the only way to see if there is a new (or different) route in the server is to right click the route ID and manually check if the one displayed is different from the one you have in your local database. then manually delete (assuming your local one is correct) I like to keep databases small so this will require huse effort. Else you can just leave it and let it grow.
-
AirNav,
Going back to an issue with 2 letter flightID’s that are unable to show route information
http://www.airnavsystems.com/forum/index.php?topic=5333.msg56212#msg56212
will this be rectified in the next RB software release?
Andrew