AirNav RadarBox
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
 


Author Topic: Question to RadarBox Users on Database Editing  (Read 7871 times)

0 Members and 1 Guest are viewing this topic.

AirNav Development

  • AirNav Systems
  • Hero Member
  • *****
  • Posts: 2545
    • AirNav Systems
Question to RadarBox Users on Database Editing
« on: October 21, 2012, 11:28:01 PM »
Quick question to our users: how often do you use local database editing? Do you find this feature useful?
Wouldn't you prefer to have, each time the application starts, all the databases synchronized with our server databases which are daily maintained by our database updaters team?

Waiting for your feedback.

mikek

  • Sr. Member
  • ****
  • Posts: 331
Re: Question to RadarBox Users on Database Editing
« Reply #1 on: October 22, 2012, 12:11:45 AM »
I used to do bit of manual editing until the database update volunteers started and are doing an awesome job. I'm personally not terribly fussed abouts routes so don't worry about that.

I would like the sync option, however it needs to be optional so those on limited or slow connections aren't forced to download too much. It would be even better if it knew its last update date and only added/changed/deleted those records which were more recent and didn't download the entire database file.

RodBearden

  • Hero Member
  • *****
  • Posts: 9128
    • Rod's RadarBox Downloads
Re: Question to RadarBox Users on Database Editing
« Reply #2 on: October 22, 2012, 12:26:53 AM »
I edit the Airlines table to cater for local variations. This is especially important for aircraft using IATA codes, which are not unique - in some parts of the world an IATA code will relate to one airline, in another part of the world it will relate to a different one.

Also some organisations use "wrong" codes - for example the Australian Royal Flying Doctor Service (RFDS) often uses FD codes, which officially belong to Thai Air Asia, who consistently use AIQ, so I've created a dummy ICAO code for the RFDS so that FD codes show the RFDS logo.

Users need to be able to edit the table to choose the logo they think is more important to them.

Other than that, I only edit the Aircraft table to correct aircraft ICAO type codes which the server gets wrong - usually with ... replacing the proper code - today I corrected just one, a PA31. Assuming that the server routine is corrected someday, I won't need to do that.

HTH

Rod
Rod

Northern Watch

  • Hero Member
  • *****
  • Posts: 523
Re: Question to RadarBox Users on Database Editing
« Reply #3 on: October 22, 2012, 03:02:31 AM »
Not for me.  I would prefer to do the update when it is relatively quiet ie. in the evening.  I run AN on a netbook and I would be concerned that it could slow down the initial start up even further especially when I use a dongle for my internet connection when using AN on the move.  I used to do a lot of manual editing until the database update volunteers started and like mikek, I am not that worried about routes.

Regards

Keith

Bell 407

  • Full Member
  • ***
  • Posts: 124
Question to RadarBox Users on Database Editing
« Reply #4 on: October 22, 2012, 05:47:40 AM »
Not for me. My database is correct for my own individual use so a sync is not for me.

Also bandwidth and cost is an issue for me.

If implimented however, This feature would need to be unticked by default with the user selecting it on for themselves.

Kenny

  • Hero Member
  • *****
  • Posts: 509
Question to RadarBox Users on Database Editing
« Reply #5 on: October 22, 2012, 07:01:26 AM »
That feature would be useful for me.  However, since I normally adjust several incorrect routes, I need to approve the sync entry.
ANRB 3km north of VTBD

bratters

  • Hero Member
  • *****
  • Posts: 935
Re: Question to RadarBox Users on Database Editing
« Reply #6 on: October 22, 2012, 07:02:38 AM »
I'm one of the people who is concerned about Routes.

With all due respect to your "database updaters team" I prefer to get my route details from FliteDisplayLite who seem to be marginally "less innacurate" than you.  Yes, I know it's a minefield!!

I do not undertake database edting and would therefore like to download monthly selectable updates, categorised by field.

EK01

  • Hero Member
  • *****
  • Posts: 4847
Re: Question to RadarBox Users on Database Editing
« Reply #7 on: October 22, 2012, 08:45:53 AM »
I'm with Bratters in that my main concern is that route details are correct. I am continually on Flighradar24 getting the correct route details updated. For this reason, all the hard work that the updaters team put into the aircraft table is not downloaded by me when the information comes through as I have found it causes a problem with my correct routes information. If the databases on start up synchronisation could be guaranteed not to have an effect on the routes table then it would be useful because at least my aircraft table would be up to date which at present it isn't.

GreekSpy2001

  • Hero Member
  • *****
  • Posts: 692
    • Graham's Aircraft Photos
Re: Question to RadarBox Users on Database Editing
« Reply #8 on: October 22, 2012, 09:27:11 AM »
Happy with the Updaters work.  The db supply is more than "good enough" for my needs.  Although maybe a more regular update.  !st of every month. If you got for full sync need to be able to switch to local mode when mobile with no or limited internet access.

Also need access to a local db as I extract mil hex codes for use with JSTARS for mill only alerting.  This point is by far my greatest need as I use this to alert upon and see mil overflights.

So for it works for me as it is.

Graham

Runway 31

  • Moderator
  • Hero Member
  • *****
  • Posts: 33577
Re: Question to RadarBox Users on Database Editing
« Reply #9 on: October 22, 2012, 09:29:53 AM »
I am sure an acceptable compromise to your original idea would be to sync the aircraft table only and leave the others well alone. 

I also consider a munual sync via a button would be more preferable than an auto sync, that way those that dont want to sync are not forced to make a decision one way or the other

Alan
« Last Edit: October 22, 2012, 09:41:37 AM by Runway 31 »

anorak

  • Hero Member
  • *****
  • Posts: 977
  • support The Devon Air Ambulance Trust
Re: Question to RadarBox Users on Database Editing
« Reply #10 on: October 22, 2012, 09:31:33 AM »
Auto-sync on start-up works for me, but an opt out would be good.
Dave.
Dave. Exmoor, North Devon.

bratters

  • Hero Member
  • *****
  • Posts: 935
Re: Question to RadarBox Users on Database Editing
« Reply #11 on: October 22, 2012, 10:10:38 AM »
I am sure an acceptable compromise to your original idea would be to sync the aircraft table only and leave the others well alone. 

I also consider a munual sync via a button would be more preferable than an auto sync, that way those that dont want to sync are not forced to make a decision one way or the other

Alan

Sounds like a practical & down-to-earth solution.

nortonbeak

  • Sr. Member
  • ****
  • Posts: 318
  • RadarBox MVT7100 PCR1000 M0NBK
Re: Question to RadarBox Users on Database Editing
« Reply #12 on: October 22, 2012, 01:41:30 PM »
Personally, I would like the convenience of an automatic synchronisation on startup, but with the opportunity to deselect individual fields.

bratters

  • Hero Member
  • *****
  • Posts: 935
Re: Question to RadarBox Users on Database Editing
« Reply #13 on: October 22, 2012, 03:10:42 PM »
Personally, I would like the convenience of an automatic synchronisation on startup, but with the opportunity to deselect individual fields.

I'm sure that the opportunity to select/deselect individual fields is key in this matter.

AirNav Development

  • AirNav Systems
  • Hero Member
  • *****
  • Posts: 2545
    • AirNav Systems
Re: Question to RadarBox Users on Database Editing
« Reply #14 on: October 22, 2012, 03:36:29 PM »
Thanks for all your replies. We believe the best way to do this is by having an additional field in the database that would state if the user wants that record to be automatically updated on not. All other records will be synchronized from the central database but the records with this setting will not (manually changed records).

Let us know if you agree with this approach.
Any other ideas are welcome.