Problems with database FlightID

[Aerotower]

Hi guys and AirNav,

Me and a friend who is in Angola have seen something strange, all flights departing from Angola has always left as the source RPLI.

You can see what is happening in your database and give an explanation for what is happening?!

Thanks

[Runway 31]

Aerotower

I dont know the answer to your query but I notice a lot of blanks in the Angolan aircraft information.  Is you friend able to provide any hex code/registration tie-ups?

Alan

[Aerotower]

It's a little hard to know.

To find out what the planes in question have to go to the airport and take the radar and security in Angola is no big deal, and can be robbed or arrested.

[BadWolf]

Wondering if the airline in question chaged its route numbering and the database is out of date. It would be a never ending task to keep up with all that.

[Runway 31]

Thanks Aerotower.

Had a look at the airports and FNLU is in the d/b with what looks like the correct co-ordinates to me.  The other airport is in the Philipinnes with what looks like the correct co-ordinates for it.  Maybe someone who knows about these things will be able to answer.  DTA650 doesnt appear to be in the database either,maybe that has something to do with the problem.

Alan

[Aerotower]

Wondering if the airline in question chaged its route numbering and the database is out of date. It would be a never ending task to keep up with all that.

There was never even a TAAG flight to the Philippines and vice versa, and there was never a TAP flight from here to there.

[Aerotower]

Thanks Aerotower.

DTA650 doesnt appear to be in the database either,maybe that has something to do with the problem.

Alan

So this is a problem with the update of the database by the Airnav server.

[Aerotower]

Airnav???!!!!
Any idea?

[AirNav Support]

Sorry we missed your earlier post.

Whats happened here is that routing we have for DTA650 has route data in IATA (LAD) however if you look up LAD in your airport database you will get two entries one of which is Laoug Intl which is what it finds when it does the lookup. If you delete that one in your airports database it should then work fine.

Unfortunately some of the route data we get is only IATA based where there duplication problems can arise. With ICOA its less so.

[Aerotower]

Already deleted from the database.

But now I noticed that not until the 24th of August, the flight DTA650 from FNLU to LPPT that this started happening.

[Aerotower]

Sorry we missed your earlier post.

Whats happened here is that routing we have for DTA650 has route data in IATA (LAD) however if you look up LAD in your airport database you will get two entries one of which is Laoug Intl which is what it finds when it does the lookup. If you delete that one in your airports database it should then work fine.

Unfortunately some of the route data we get is only IATA based where there duplication problems can arise. With ICOA its less so.

The IATA code for RPLI is LOA, please change that on database.

[Aerotower]

Hi AirNav support!

The problem continues!! It placed the new database, and was erased everything that had RPLI from the database of flights.

But apparently nothing has changed ....... Any suggestions?
It also changed the IATA code of LAD for LAO.

Thanks

P.S- He is getting tired of the problem and sell a box any day .....

[AirNav Support]

The data unfortunately comes from our external sources such as FlightStats etc.. who provide the data and then it goes through processing to match up the details before adding to our database. We have changed IATA in your server database but still seeing it feed through which suggests the data is being sent us to incorrectly. We will try and chase this back and get this corrected however it depends on third party data suppliers so this may take some time.

In the meanwhile you can change the details of the Routes manually in your route table to show FNLU.

[EK01]

And it will probably revert back to the incorrect information. Every night EZY4GL flies into Alicante. Every night the route incorrectly shows as LGW to MAD and every night I manually change in Database Explorer sometimes by deleting the whole route information and sometimes by just changing to the correct destination but the following night it has reverted back to showing LGW to MAD. The solution - I now just leave it alone !

[Aerotower]

And it will probably revert back to the incorrect information. Every night EZY4GL flies into Alicante. Every night the route incorrectly shows as LGW to MAD and every night I manually change in Database Explorer sometimes by deleting the whole route information and sometimes by just changing to the correct destination but the following night it has reverted back to showing LGW to MAD. The solution - I now just leave it alone !

The data unfortunately comes from our external sources such as FlightStats etc.. who provide the data and then it goes through processing to match up the details before adding to our database. We have changed IATA in your server database but still seeing it feed through which suggests the data is being sent us to incorrectly. We will try and chase this back and get this corrected however it depends on third party data suppliers so this may take some time.

In the meanwhile you can change the details of the Routes manually in your route table to show FNLU.

The data has been changed several times in the database but still always appear the same.

Even today he sent two screenshots, one of radarbox and another of flightradar24, and as can be seen only in radarbox is appearing incorrectly.


But I catch the same flight here in Portugal and after I have cleaned the database never appeared as RPLI. And with my friend in Angola remains the problem, even after he have cleaned the database.