AirNav Systems Forum
AirNav RadarBox and RadarBox24.com => AirNav RadarBox and RadarBox24.com Discussion => Topic started by: Aerotower on September 24, 2011, 12:22:24 PM
-
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
-
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
-
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.
-
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.
-
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
-
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.
-
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.
-
Airnav???!!!!
Any idea?
-
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.
-
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.
-
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.
-
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 .....
-
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.
-
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 !
-
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.
-
flight id-DT650 and DTA650?
-
The source is the same, if you look more closely at the map shows "DTA650."
-
Another
-
Thanks we will investigate further and get back to you.
-
Thanks!
Another one...
-
another
-
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 !
Major breakthrough !!!!
Tonight, at last, EZY4GL is now showing the correct route of Gatwick to Alicante and NOT Gatwick to Madrid.
-
Hi....
I´ll try to ask this as "polite" as I can... some time ago a friend of mine "Aerotower" came here to ask about an issue related to my Database reporting a few times per day some flights, either coming or going from FNLU with a RPLI designation.
After all this time and also after manually changing it back within the database and after replacing my database for the one provided by ANRB, and also after taken some advise from some members, I still have the same issue.
Now, I do have a solution for my problem and I will make sure that it never cames back to hunt me again, but I will like to ask "here" once more for some help. If anyone is willing to help me out, fine, otherwise I´m shothing down my station.
It´s incridible the lack of help we get from the same people that're selling us this equipment. Please.....
Regards
Paulp Santos
As you can see FNLU as changed to RPLI and also...the picture/logo is not corresponding to the TAAG's fleet.
(http://img411.imageshack.us/img411/2372/rpliissue.jpg)
-
Hi Zpress
I can't comment about the airport designator, but I can tell you that your "Logo" - the TAAG symbol, seems to be ok. It's the "Silhouette" to the left of it that is showing an aircraft of a different airline. This is a problem that you can get if you use my "photo-silhouettes" as they are linked to the aircraft type, not to the airline. If you don't like that, you can go back to the standard silhouettes as provided with the software.
The larger photo at the bottom of the screen comes from looking up the registration on Airliners.net - we get whatever they've got for that registration.
Hope that helps
Rod
-
Hi Zpress,
Go into your photo folder and delete the offending photograph(s) oF D2-TED. Next time you pick it up it should download the server held photo which is different from the one you have on your system.
I would also suggest that you go into database explorer and add the ICAO code E120 to your AT record for D2-FDT. Have you downloaded the latest Navdata update as the being missing in your screenshot may indicate that you are using an older version.
Hope this helps
Alan
-
I turned my route look up off to stop this problem. I don't use the new route database so not sure what CH field date and time shows. I think if the date is older than 3 months then it looks for a new route which could cause your routes being overwritten. Change your route to what is required and then change the CH date to today's date/time and give that a try.
Bearcat
-
Although the database updater team have no control of these due to one of the longstanding bugs. The Airnav automatically generated server photos for D2-TED can be seen at these links. As Runway said, if you delete the offending photos from your photos folder, you will get these photos to replace them.
http://www.airnavsystems.com/cgi-bin/ANLV_SV/Photo/D2-TED.jpg
http://www.airnavsystems.com/cgi-bin/ANLV_SV/Photo/D2-TED,2.jpg
Xpress, I hope you do not leave, but your unhappiness with data quality is shared by many. Again this is a result of Airnav's longstanding policy of trying to resolve all the database and data presentation features through automated processes. For those areas where this has not worked (logos, silhouettes, tie-ups, outlines etc) volunteers have stepped in, to try and assist airnav to gain some quality in the data they present users. However, for the other areas, these issues will never be cured until Airnav have proper human scrutiny of all their automated data feeds. And that can only happen if they employ a data administrater. We know their position is that the amount of resource required cannot be yet undertaken within the company structure, because of the overall small scale of the operation/hobby.
Therefore the automated processes like routes/photo selection will continue to remain of poor quality/value because there is no human scrutiny of what the computer spews out.