Routes

[testmonkey]

Sorry to ask this again - I've asked it in another thread but got no reply and this thread is probably more appropriate.

Could either Support or Dev confirm / deny the following:

My belief is that network route data should be added by AirNav at the server before the network data is propogated to the client machines that are requesting it i.e. downloads with all the other network data and no need for client machines to request it (thank goodness). Currently I only seem to be getting route data for network flights if it already exists in my local route table but I believe the servers are being updated over the next two weeks so the scenario as described previously will ultimately apply.

Are those 2 statements correct?

If so could I be so bold as to repeat my feature request (apologies if Dev have already added it to their wish list).

What I'd like to see is a local process whereby the (already) downloaded network route data is checked against and added to the local route table if it needs updating or is missing when that flight is highlighted (similar to the server request for aircraft data / pictures but a local process only). Obviously it may be wise to make this a switchable user option so that those with low end machines aren't hammering their processors.

TIA

[testmonkey]

Support / Dev - any info on the above?

Also whilst here I thought of another feature request regarding the routes.

Would it be possible in a future version to add the airport country to the information listed for the From, To and Via lines when viewing information for a specific flight (next to the aircraft picture). Most of the time the airport is probably known to the user but now that we'll all be getting more network route information it might be useful for those unfamiliar airports to understand where they are.

Cheers

[Storm]

I have the same problem. It doesn't seem to happen every single time I would say that 60-70% of the flights that transition from Network to my flights do not show the route hen it comes into my view. I have to disable both network and my RB then start my RB once all the routes show up I can start network again.

Not really a workaround though.

[AirNav Support]

Looks like I missed a post above so will explain:

1.) Flights are picked up and data is sent to the network
2.) Network Data is checked is route are added from a local database on the server
3.) Data is sent back to your RBs

What is going to happen is that at stage 2 it will also look up on the online database hence should have more route data on the network flights. (This should happen in the next few weeks)

However we agree that its good but when they go from network to local flights they should then recheck your local file.

This unlike stage 2 will need a code change to your RB software and hence this will be done in the next software update we hope.

[Storm]

OK. Standing by and thanks for the explanation.

[testmonkey]

Thanks for the explanation Support, that's how I thought it would be.

Does this mean that 'missing' routes from the network will get added to the local routes table (via a local process of course) as per my suggestion or is that down as a 'possible' for a future version only at present.

[Wayne]

Hi

I'm still not sure what is happening with routes - they seem to be in a bit of a mess.

I am using RB and purely picking up local traffic. Network is not connected but I have wireless internet at home so I do have an active internet connection.

I have just seen flight AAL949 and the route displaying with the aircraft was KORD-KSEA.

I checked the routes table in Database Explorer and the attribute NO shows KBNA, the attribute ND shows MHZM, the attribute NV shows KMIA and the attribute CH is blank.

The BAA website confirms this flight is really EGLL-KORD. So where is RB getting the information from because none of it seems to be correct in this case ?

Wayne

[AirNav Support]

If the attrubite CH is blank it did not download anything for that flight. That route detail was already in the database.

We have a RB in London which is using then online database and its uploading screenshots and nearly 98% of ADS-B flights have the routes and are correct:

http://www.akzah.com/blog/static.php?page=radarboxLondon

[Wayne]

Yes, I understand what you are saying and I'm not being at all critical - I'm just a bit bemused by it.

So, the attribute CH, if populated, shows it's route info recently downloaded and stored on the local table and this is up to date information from some server or other. I get that.

If a route already exists in the local table and has no entry in CH then how exactly does RB handle it

Should it look to a server and write the up to date route and populate CH ?
Should it ignore the route as it's already known to the local table

The most confusing thing is it was displaying a route neither fom a server nor what was actually in the local table.

I don't dispute that your London based box is doing things correctly but here is evidence that mine, and maybe others, aren't.

When you say 'using the online database' is this what we all access when we are internet connected and is it consulted for both local and networked traffic ?

Wayne

[John Racars]

If a route already exists in the local table and has no entry in CH then how exactly does RB handle it

Hi Wayne,

Last week I did the following:

in my localdatabase I changed the INCOMPLETE (AirNav) data of flight ANZ38; I changed VHHH-NZAA into EGLL-VHHH-NZAA and wrote in the CH field 20080904000000. The next day, September 5th, (when this flight must have been in my area of reception again) the route information was overwritten with.......... the INCOMPLETE information so it is now VHHH-NZAA again. Since I saw this I have given up all my further endeavours to try to make corrections in the route database.

You understand that I am also not happy with this. All that bustle with the routes when a new version comes out has taken verry much time from me in the past. And since version 1.5 (where I have all under control) it looks again, with the release of version 2.0, that all the work was for nothing again.

Verry frustrating but there is hope: AirNav Support told me yesterday that they are working on a solution which is to be expected in the next coming weeks.

[AirNav Support]

John,

Think you have confused a few issues and made them into one. The issue you mention was only affecting routes which had 2 Legs otherwise it should work fine.

The other issue was that the network does not use the online routes yet hence a lot of them appear blank and then once they transition into local flights they do not check the database. This is going be rectified soon.

I assume most of your updates were on single leg flights and hence they should not be affected.

Wayne,

The version running in London is exactly the same you have. No changes it to it except its not using the network so it does not fall into the issue mentioned above.

"The most confusing thing is it was displaying a route neither from a server nor what was actually in the local table."

We haven't seen this before so we would be interested to know if anyone else has had this.

If the CH values are not there it should try and check against the database on our server for new updated route.

[DaveReid]

I checked the routes table in Database Explorer and the attribute NO shows KBNA, the attribute ND shows MHZM, the attribute NV shows KMIA and the attribute CH is blank.

The BAA website confirms this flight is really EGLL-KORD. So where is RB getting the information from because none of it seems to be correct in this case ?

I  suspect the flight database schema was designed by someone who has never worked in the airline industry and who doesn't understand the difference between a leg and a segment.

Presumably NO, ND and NV stand for Origin, Destination and Via - which is a daft way to implement a flight route database as it's not unknown for some flight numbers (particularly cargo ones) to have as many as 8 or more legs (i.e. an origin, destination and 7 intermediate "via" points.

Every programmer knows that there are only 3 numbers you have to worry about:  zero, one and lots. 

The number two (as in a flight consisting of two legs, A to C via B) doesn't get a mention in my copy of Database 101  :-)

http://en.wikipedia.org/wiki/Database_normalization

HTH
Dave

[Wayne]

Hi Support

Here is another example. I have just seen EXS375 which is displaying on screen and in the My Flights list as LEIB-EGNM when in fact it is EGNM-LEMH.

Database Explorer confirms this this time with EGNM in NO, LEMH in ND and the CH field holds the value 20080823151229.

The confusing issue here is where are the displayed values coming from ?

Wayne

[John Racars]

I  suspect the flight database schema was designed by someone who has never worked in the airline industry and who doesn't understand the difference between a leg and a segment.

Hi David,

As I mentioned before this simple exemple:

They give as route for BAW7 EGLL-CYUL. How is this possible? It's EGLL-RJAA as far I know for many years! And this is only one example.

I am verry sorry to say so.

[DaveReid]

They give as route for BAW7 EGLL-CYUL. How is this possible? It's EGLL-RJAA as far I know for many years! And this is only one example.

Yes, that's a different kind of confusion, caused by the mistaken assumption that you can take an alphanumeric callsign (i.e. in this case BAW7MY, the callsign used by EGLL-CYUL flight  BAW95), knock off the letters and then use the resulting flight number as the lookup value.

BAW7 is a completely different flight from BAW7MY.

HTH
Dave