AirNav Systems Forum
AirNav RadarBox and RadarBox24.com => AirNav RadarBox and RadarBox24.com Discussion => Topic started by: hofs on October 21, 2009, 02:56:13 PM
-
i have been reading a lot of topics about changing aircraft data in the database explorer.
But what ever i try some aircraft data are going back to the old data after starting up radarbox.
I also have been reading the topic from airnav about database and how it works and if i understood well after finding a mode s first of all it is checking in the data base if its already been written down and if not it wil go to other data base like Gas to see if they have the data.
But i already put the data in the database explorer so why does it go to Gas or airliner to get the wrong data .
The data that is changing is most of the time german military aircraft.
Please tell me how to stop this.
Fred
-
You can stop it by unticking the "Auto-Populate Aircraft Data" in Preferences. However, you will then have to make any and all updates manually.
The problem itself is well understood, so hopefully will be addressed in a future version.
-
thanks for your quick reply .
Then we have to wait and see what happens in the future and until then i will stop changing data .
Fred
-
Can someone explain how ANRB auto-populates? When does it pull information from the database?
Here is the problem. If data is pulled down even if the fields are completed (ie corrected locally) then I do not want that as information that I have corrected (or local anomalies) will be overwritten. That means I must switch auto-populate off.
If I turn auto-populate off then my data will not be updated with new information so when I find information on flights in my area and submit them to the database updaters I could be wasting their time as the database could be updated already.
So - do I keep it on and constantly check my info for unwanted changes or do I waste the updaters time?
-
So - do I keep it on and constantly check my info for unwanted changes or do I waste the updaters time?
Hopefully you won't need to do either soon.
We're promised a new release of the RadarBox software which will:
a) include a much more intelligent updating architecture so that changes you make locally aren't overwritten by older data from the AirNav server, and
b) feature a much more up-to-date database incorporating all the work being done by the updaters, so that there should be less need for you to make manual updates anyway
No sign of it yet, though ...
-
So - what you are saying is that I should do the latter.... waste the updaters time :) :)
-
I think the trick to stop it overwritting your data is to have a photo in your Photo file for the A/c required. Either a copy of a similar A/c or one off the web. Failing that I use a dummy image " Sorry no Photo" and give it the A/c registration, leaving the LK, PT, LK2 ,PT2 fields blank
-
So - what you are saying is that I should do the latter.... waste the updaters time :) :)
Well hopefully the updaters won't consider it a waste of their time(!), but technically yes, you're right, there is no way of knowing whether submitted updates are already in the updaters' master database because those don't find their way into our local RadarBox databases.
-
So - do I keep it on and constantly check my info for unwanted changes or do I waste the updaters time?
Hopefully you won't need to do either soon.
We're promised a new release of the RadarBox software which will:
a) include a much more intelligent updating architecture so that changes you make locally aren't overwritten by older data from the AirNav server, and
b) feature a much more up-to-date database incorporating all the work being done by the updaters, so that there should be less need for you to make manual updates anyway
No sign of it yet, though ...
Totally back you on this one Dave!
It's frustrating to find a lot of info we're asked to check, is actually now (or indeed has been for a few weeks at least) on the central db, prior to the request coming in!
Equally frustrating to continually see threads crop up of this ilk, where there's still a lot of uncertainty and confusion surrounding the way records are maintained/updated
We've discussed this within the Updater team regularly,as we try to get to grips with the mechanics.
The comment made by Bearcat above is one possibility, but it really shouldn't have to get to this fiddly level, as I'm the first to admit to not being over confident in resorting to playing about with the records like this, and I'm sure countless other users aren't also!
Either a re-working of the architecture as you've mentioned above, or a facility to release a new db (as we've been working on) with continual updates at regular intervals (as is the norm with most of the major spotting db's out there) seems to us to be one possible way forward, otherwise it's going to be an ongoing problem, only resolved by completely flushing out one's db ever so often and let the updated info start to re-populate the users db as codes are picked up - not the best I'm sure you'll agree?
We have put our collective suggestions to AirNav, and they are currently being worked on.
Unfortunately we are not in a position to determine what solution will be forthcoming!
In the meantime, keep forwarding your observations and requests, and we'll keep adding/amending accordingly - after all, now the World Cup's finished, we've nothing better to do :-)
Regards
Rich
-
It's frustrating to find a lot of info we're asked to check, is actually now (or indeed has been for a few weeks at least) on the central db, prior to the request coming in!
Why can't Airnav generate a CSV file from the central database with all the required fields (MS, AR, AT, AN, AC, CN, PT, LK, PT2, LK2), and anyone could then use the SQLite command line (http://www.sqlite.org/download.html) to import the updates into their local database.
It would involve the end-user entering just four commands:
sqlite3 data/navdata.db3
.separator ","
.import aircraft.csv aircraft
.exit
-
Hi Tarbat
Forgive my lack of technical knowledge (which I'm sure you've already gathered!), but could this be used just to deal with db additions/changes that could be identified by "date stamp", or would it entail a complete re-load of the db every time such a file was produced?
If so we could easily obtain a file of records only updated after a certain date/time.
I presume we would still have the dilema of this continuing to over-write any isolated changes people make themselves independant to the central db?
In my view, this would still be a suitable improvement over the current scenario
Rgds
Rich
-
Why can't Airnav generate a CSV file from the central database with all the required fields (MS, AR, AT, AN, AC, CN, PT, LK, PT2, LK2), and anyone could then use the SQLite command line (http://www.sqlite.org/download.html) to import the updates into their local database.
I am sure I am not alone when I say I don't want to get involved with SQLite or any other, seemingly "complex" PC centred work. That's was not the idea when buying Radarbox which is simplicity itself and I'm sure sells on that basis.
The final answer to DB updating must not present any sort of challenge for the absolute PC beginner and must be simple and clearly accessible to each and every user.
-
I can still not find the answer to my question - under what circumstances does the local database get updated. Does it only update if you left click the aircraft (as indicated in the help file)? Does it update in any filed is empty or does it check for a local photograph (as indicated above). I really do not want to waste Marpleman or Runway 31's time by sending them info they have but on the other hand I do not want my local updates overwritten. I have a number of "local" entries, mainly aircraft that have been imported into my country and still have the Mode S code of the country of origin.
-
Chris
Totally understand your frustrations!
I really think AirNav need to re-visit this urgently by offering/ posting a difinitive concise overview of how this all works.
I'm afraid I personally can't offer any clarification, and to be honest , with the upmost respect to the guys offering suggestions, don't think it's upto others to suggest their understanding, however reliable or helpful it is!
It's blatantly obvious that there is enough ambiguity with the whole process to confuse the majority of us!
Ref your point in sending us info that we already have - it's actually of benefit to receive this in some ways, as it continues to give us some feedback as to the validity of what we presume is actually happening!
Rgds
Rich
-
I am sure I am not alone when I say I don't want to get involved with SQLite or any other, seemingly "complex" PC centred work.
Understood. But some of us are very happy to use a few commands to correct our local database. I just wish Airnav would give us the choice. They could issue a CSV file containing all updates after a certain date, for example.
Give me access to the central database, and I'll have a go at creating a CSV file myself!!!
-
http://www.airnavsystems.com/download/anrb/databaseupdates/NavData.db3
It shouldn't really be any more complicated than that ...
-
http://www.airnavsystems.com/download/anrb/databaseupdates/NavData.db3
It shouldn't really be any more complicated than that ...
I'm getting a "dead" link on that page Dave???
-
Is the central Airnav database now up-to-date with all these updates. If so, think I'll have a go at writing a VB program that:
1. Goes through each aircraft record in navdata.
2. Takes the ModeS hex code (HHHHHH).
2. Calls http://www.airnavsystems.com/cgi-bin/ANLV_SV/ANLV_SV_user.exe?usgetphoto=0&usverify_name=PGANRB111111&usversion=ANRB301&modes=HHHHHH
3. Takes the returned CSV data, and updates the aircraft record.
-
http://www.airnavsystems.com/download/anrb/databaseupdates/NavData.db3
It shouldn't really be any more complicated than that ...
I'm getting a "dead" link on that page Dave???
My point exactly !
-
Just for your info. (also posted this in the other place)
The main database has currently 69637 records, and we have manually checked 31,025 to todays date, which leaves 38,612 still to check.
Majority of main production models within DB have been completed in this first push but still lots to keep us busy.
Dave
-
Is the central Airnav database now up-to-date with all these updates. If so, think I'll have a go at writing a VB program that:
1. Goes through each aircraft record in navdata.
2. Takes the ModeS hex code (HHHHHH).
2. Calls http://www.airnavsystems.com/cgi-bin/ANLV_SV/ANLV_SV_user.exe?usgetphoto=0&usverify_name=PGANRB111111&usversion=ANRB301&modes=HHHHHH
3. Takes the returned CSV data, and updates the aircraft record.
Yes, but (correct me if I'm wrong) that won't populate the AT (ICAO type code) column in the Aircraft table.
By the way, you're cheating - that's 4 steps, not 3 :-)
-
I am sure I am not alone when I say I don't want to get involved with SQLite or any other, seemingly "complex" PC centred work.
Understood. But some of us are very happy to use a few commands to correct our local database. I just wish Airnav would give us the choice. They could issue a CSV file containing all updates after a certain date, for example.
With your knowledge and ability Tarbat so would I!
However my fear is that we could run the danger of establishing a two-tier community. Those (the few) who have up to date DBs in their RBs and those (the majority) who haven't.
As I see it, we are not discussing an optional add-on application here - this is about an integral and important part of RB operation and it has to be available to one and all.
-
All,
We have amended the post below in our FAQ to answer some of the common questions about the database.
http://www.airnavsystems.com/forum/index.php?topic=2688.0
Work is ongoing on a update to the software so it can update records in the local database. We hope to have more news on this soon.
Please do not use method Tarbat has mentioned as that will overload the server with requests.
We apologise for the delay and we are doing our best that the software is rolled out as soon as possible and works 100%.
We want to keep everyone on the same page so we don't want to roll out csv's just yet. Though we may provide a navdata database with the latest entries from the AirNav database, we will look into that.
We also like to thank the database updates for there efforts so far.
-
Thanks - That's the info I needed
-
We have amended the post below in our FAQ to answer some of the common questions about the database.
http://www.airnavsystems.com/forum/index.php?topic=2688.0
You could usefully update your description on the above page of how and why Mode S codes change:
Mode-S IDs can also change there [sic] link to registrations. Example G-EUUT could go out of service and then 401240 is assigned to G-ELLB (In rare cases, usually the Mode-S link to registration stays the same).
That's not a "rare case", it's an example that can't ever happen - Mode S codes never get reassigned to a different aircraft in the UK, and indeed Mode S-to-registration tieups rarely change in any part of the world.
-
Its been changed, thanks, anything else you think will explain the process better please say.
-
That's not a "rare case", it's an example that can't ever happen - Mode S codes never get reassigned to a different aircraft in the UK, and indeed Mode S-to-registration tieups rarely change in any part of the world.
Maybe in the first world - try 3rd world CAA government officials. :)