Flight Number / Call sign Database significantly increased

[AirNav Development]

We have today deleted all records without origin/destination from our database forcing it to be totally refreshe during the next 24 hours which should significantly increase the number of org/dest data shown.

[EK01]

AN,

Does that  'all' include origin/destination details for alphanumeric flight numbers ?

[AirNav Development]

Yes, for most of them.

[EK01]

Thanks AN. That will be a great improvement.

Ian

[tarbat]

So, is now an appropriate time to delete all records from our local navdata routes table?

[DaveReid]

So, is now an appropriate time to delete all records from our local navdata routes table?

Don't be too hasty in deleting your local routes database, I'd hang on for a few days at least.

I don't know if the routes currently being returned by the server are the same as those in AirNav's master routes database (since I don't understand what this "24 hour refresh" process is all about). 

Having said that, I've just run a random sample of Heathrow flights against the server.

Of those, 10% are returning routes which are either wrong/out of date (e.g. BAW21P/BA603 LIRP-EGLL) or simply blank (e.g. BAW29CE/BA341 LFMN-EGLL).

Of the incorrect/blank routes, 75% are alphanumeric flight numbers.

As I said, I don't fully understand the update architecture, so it's possible that over the next few days the refresh process will populate all those alphanumerics.

I'll run another test in a few days time.

[knight01]

I'm still getting incorrect routes from the server.  If I delete or modify the incorrect route, the server just updates it again with the incorrect version.

example: I just noticed VIR22F is EGLL > KIAD in database, so I change it to the correct routing KIAD > EGLL.  But as soon as I restart the application, its back to the incorrect route.

Another example: Air Transat TSC134 CYQB > MMUN in database. 
Correct routing CYYZ > EGKK and its on approach to Gatwick.

This has happened multiple times with multiple airlines/routes and its getting really frustrating.  The server keeps modifying routes I've added manually with the incorrect versions.  
Now I'm wondering how many routes in the database are actually correct.

[DaveReid]

This has happened multiple times with multiple airlines/routes and its getting really frustrating.  The server keeps modifying routes I've added manually with the incorrect versions.

Have you tried populating the CH field for the record in question with a current date/timestamp ?  My understanding (though I could be wrong) is that doing this will prevent newly-edited routes from being overwritten by data from the server that's out-of-date or, as in this case, simply incorrect (I do a lot of work for Virgin in my day job and I know for a fact that eastbound flight numbers are even and westbounds are odd).

Now I'm wondering how many routes in the database are actually correct.

I'm amazed that the whizzy new takeoff/landing algorithm hasn't picked up the fact that VIR22F lands at Heathrow every morning - surely there must be enough network sharers to pick up that one ?

[DaveReid]

As I said, I don't fully understand the update architecture, so it's possible that over the next few days the refresh process will populate all those alphanumerics.

I'll run another test in a few days time.

Today's test shows much the same results, in fact slightly worse than Monday's with 78% of the blank/incorrect LHR routings being alphanumerics.

Has anyone actually seen any signs of the "significant increase" in populated alphanumeric routes ?  Clearly it's not evident at one of the world's busiest international airports, surrounded by dozens of network sharers !

Could AirNav explain how a flight like DLH1VV, which has landed at Heathrow at least 15 times since the new algorithm was supposedly rolled out, has apparently completely escaped detection and is still being reported as Frankfurt-Manchester ?

[neroon79]

To be honest: I can only detect a marginal increase of shown routing Infos here in northern Germany. Further I don't know how many of the "new" routings are correct or still incorrect. I'm checking the EDDV traffic from time to time and for these routings I can say: At least the direction in which the departing Aircraft is flying seems to match with the new routing Information...

As for DLH1VV: Has definitely not shown up on my "space". So the origin seems to be more south of my position/reception area.

[DaveReid]

As for DLH1VV: Has definitely not shown up on my "space". So the origin seems to be more south of my position/reception area.

  <?xml version="1.0" encoding="utf-8" ?>
- <Flight>
  <FlightNumber>DLH1VV</FlightNumber>
  <Callsign>Lufthansa 1VV</Callsign>
- <Leg>
- <Origin>
  <ICAOCode>EDDF</ICAOCode>
  <IATACode>FRA</IATACode>
  <AirportName>FRANKFURT (INTERNATIONAL)</AirportName>
  <Country>GERMANY</Country>
  </Origin>
- <Destination>
  <ICAOCode>EGLL</ICAOCode>
  <IATACode>LHR</IATACode>
  <AirportName>LONDON/HEATHROW</AirportName>
  <Country>UNITED KINGDOM</Country>
  </Destination>
  <GCDistanceNM>353</GCDistanceNM>
  </Leg>
  </Flight>

[tarbat]

Could AirNav explain how a flight like DLH1VV, which has landed at Heathrow at least 15 times since the new algorithm was supposedly rolled out, has apparently completely escaped detection and is still being reported as Frankfurt-Manchester ?

I guess that if there's not adequate, low-level coverage at Frankfurt (EDDF) as well, then the new algorithm won't operate.  Having said that, coverage at Frankfurt looks pretty good at the moment, but is there adequate low-level coverage when DLH1VV is taking off from Frankfurt?

I also see that Airnav said the they have "deleted all records without origin/destination from our database", so if DLH1VV already had an entry in the database of EDDF-EGCC, how long do we have to wait for this to be replaced with the correct information, and what will trigger this?

[DaveReid]

I guess that if there's not adequate, low-level coverage at Frankfurt (EDDF) as well, then the new algorithm won't operate.  Having said that, coverage at Frankfurt looks pretty good at the moment, but is there adequate low-level coverage when DLH1VV is taking off from Frankfurt?

No argument there. 

I think everyone appreciates that if you don't have good coverage at both the origin and destination then it's not going to be possible to work out a route.  AirNav have said that they won't populate routes with an origin but no destination, or vice versa, which is fair enough.

I also see that Airnav said the they have "deleted all records without origin/destination from our database", so if DLH1VV already had an entry in the database of EDDF-EGCC, how long do we have to wait for this to be replaced with the correct information, and what will trigger this?

Who knows, indeed ?  Only AirNav, and so far they aren't saying.

IMHO, as soon as the network detects a flight with a "known" routing arriving or departing from a different airport on two separate occasions (once could simply be a diversion) then the route should be flagged as potentially invalid in the database until an unambiguous origin and destination are detected.

Of course all the above is only relevant if we're talking about something that has actually been developed and deployed and isn't simply snake oil/smoke-and-mirrors/vapourware ...

[AirNav Support]

DaveReid,

Dev knows the in and outs of the system and will explain the details in due time.

It is NOT "snake oil/smoke-and-mirrors/vapourware" as noted when it was released a increase of alphanumeric flights were noticed. As usual you like to cause a bit of controversy in your posts :)

[DaveReid]

Dev knows the in and outs of the system and will explain the details in due time.

I always have trouble understanding Development's explanations of how things work.

Maybe they could explain it to you, and then you could tell us :-)