AirNav Systems Forum

AirNav RadarBox and RadarBox24.com => AirNav RadarBox and RadarBox24.com Discussion => Topic started by: AirNav Development on February 26, 2011, 12:09:29 AM

Title: Improving RadarBox Automatic Database Population
Post by: AirNav Development on February 26, 2011, 12:09:29 AM
We are trying to give our best to correct all aircraft database issues even before ShipTrax is released. Unfortunately and due to the 5 projects we've talked about before we can't promise that we will be able to correct all the pending issues on time.

Anyway we kindly ask our users to, at this time, report what needs to be done regarding the database population issues so everyone feels happy and the software fully communicates with the great online database our updaters are constantly working on.

In simple terms we need concise and short descriptions of wrong behavior on the database interaction.

A similar discussion has also started inside our team.
Title: Re: Improving RadarBox Automatic Database Population
Post by: AirNav Support on February 26, 2011, 12:32:21 AM
Just to add, here are the major issues we are aware of:

- Database must be able to handle updates of data so data is not stale.
- Allow users data not to be overwritten by data on our server
- Pictures, use most recent addition rather than most popular
- Corruption bug causing details to incorrectly have "..."
Title: Re: Improving RadarBox Automatic Database Population
Post by: ACW367 on February 26, 2011, 02:46:14 AM
Just to add, here are the major issues we are aware of:

- Database must be able to handle updates of data so data is not stale.
- Allow users data not to be overwritten by data on our server
- Pictures, use most recent addition rather than most popular
- Corruption bug causing details to incorrectly have "..."

I would change third ones to read, - photos only to be derived from NAVDATA link fields as provided by updaters or return photo not available field.  No independent search of ANet for 'most' anything by individual user.  (I will PM you seperately with how this should be working within the updater DB.)

I would change the fourth one to 'When hex not in NAVDATA, Corruption bug that does not pull ICAO data from database and instead guesses ICAO code, sometimes right, mostly wrong, sometimes blank or ...'

The other major data corruptions include:
-Corruption bug messes display of all diacritical marks   à  & ū ö etc

-Corruption bug to NAVDATA of Aircraft long name adding ... to end of name IE Gulfstream Aerospace G200...  OR Cessna 560XL Citation XLS...

- Corruption to Info displayed next to photo.  Reaches into Navdata for Regn rather than Hex

- Confusion in decode of aircraft hex leading to incrrect callsigns/heights/locations being displayed on screen
IE
   400A7C  SHT18C   LOWW-EGLL       G-DBCC  A319  bmi                  2011/02/25 12:38:01  
   400AFC  SHT18C   EGCC-EGLL       G-EUXD  A321  British Airways      2011/02/25 12:31:41

   400B04  BEE7RV                   G-JEDW  DH8D  FlyBe                2011/02/25 15:38:04  
   400B04  SHT2P                    G-JEDW  DH8D  FlyBe                2011/02/25 15:41:28  
   400B00  SHT2P    EGLL-EGCC       G-EUXH  A321  British Airways      2011/02/25 15:39:08

- Corruption bug to route if same aircraft picked up only once on seperate days with same callsign each day, displays as one flight and does not appear on reporter for latest day.
See attachments

-No 3D models or skins for hundreds of ADS-B aircraft. 3D models also set up against corrupted ICAO codes like A380 instead of A388.

- No Silhouettes for over 600 aircraft types

Every single one of the above issues has been around since V2.0 and have been reported to death in myriads of threads, so you should be well aware of every one of them.
Title: Re: Improving RadarBox Automatic Database Population
Post by: AirNav Development on February 26, 2011, 03:07:50 AM
Our comments:

>I would change third ones to read, - photos only to be derived from NAVDATA link fields as provided by updaters or return photo not available field.  No independent search of ANet for 'most' anything by individual user.  (I will PM you seperately with how this should be working within the updater DB.)

Ok. Right now the server returns the two newest airliners.net photos for each aircraft. It saves the links on the main server database which is then passed to the client application. What's wrong with this?

-

>I would change the fourth one to 'When hex not in NAVDATA, Corruption bug that does not pull ICAO data from database and instead guesses ICAO code, sometimes right, mostly wrong, sometimes blank or ...'

Corrected. ICAO aircraft code returned directly from server and no more "guesses".

-

>-Corruption bug messes display of all diacritical marks   à  & ū ö etc

Send two examples so we can investigate further.

-

-Corruption bug to NAVDATA of Aircraft long name adding ... to end of name IE Gulfstream Aerospace G200...  OR Cessna 560XL Citation XLS...

Corrected.

-

- Corruption to Info displayed next to photo.  Reaches into Navdata for Regn rather than Hex

Explain in detail.

-

Confusion in decode of aircraft hex leading to incrrect callsigns/heights/locations being displayed on screen

Nothing can be done regarding this.

-

- Corruption bug to route if same aircraft picked up only once on seperate days with same callsign each day, displays as one flight and does not appear on reporter for latest day.
See attachments

We will check this one.

-

-No 3D models or skins for hundreds of ADS-B aircraft. 3D models also set up against corrupted ICAO codes like A380 instead of A388.

We need a full list with these errors. It's a matter of changing the sub-folder names inside the GE_Models folder.

-

- No Silhouettes for over 600 aircraft types

Where is the Silhouette team? We can add extra silhouettes for V4.04.

-
Title: Re: Improving RadarBox Automatic Database Population
Post by: AirNav Development on February 26, 2011, 03:09:54 AM
Changes done at this time:
- Preferences form scroll box problems;
- Aircraft ICAO code returned from server and not guessed;
- If aircraft record has been manually changed by user it is not automatically updated (option for this);
- Right mouse click on grid and report problems with aircraft record for updaters team to look at;
- No more aircraft/route ending with ...;
Title: Re: Improving RadarBox Automatic Database Population
Post by: ACW367 on February 26, 2011, 03:18:36 AM
Our comments:

>I would change third ones to read, - photos only to be derived from NAVDATA link fields as provided by updaters or return photo not available field.  No independent search of ANet for 'most' anything by individual user.  (I will PM you seperately with how this should be working within the updater DB.)

Ok. Right now the server returns the two newest airliners.net photos for each aircraft. It saves the links on the main server database which is then passed to the client application. What's wrong with this?



Sorry this is nowhere near fixed.  Yes The links are populated to the updater and passed to user NAVDATA.  They are then completely ignored by the users box in the search for thumbnails for the photos folder.  This thumbnail search is still as for V2.0 and searches most popular from each individual user to populate the photo thumbnail folder.  

The NAVDATA remains the same with the central 'most recent' server link which is completely unrelated to the 'most popular' thumbnail.  Clicking on the 'most popular' thumbnail will take you to the ANET page for the correct NAVDATA derived 'most recent' photo.

See attached screenshot, this thumbnail of a previous B732 uploaded today, ignoring what is in NAVDATA links with the updater team added blocker. 

Double clicking on the bad thumbnail opens IE at the correct blocker link.
http://www.airnavsystems.com/cgi-bin/anlv_sv/photo/photonotavailable.jpg
Title: Re: Improving RadarBox Automatic Database Population
Post by: ACW367 on February 26, 2011, 03:52:25 AM
Our comments:

>I would change the fourth one to 'When hex not in NAVDATA, Corruption bug that does not pull ICAO data from database and instead guesses ICAO code, sometimes right, mostly wrong, sometimes blank or ...'

Corrected. ICAO aircraft code returned directly from server and no more "guesses".

Sorry Airnav wrong again.  Any aircraft not in the released NAVDATA will still guess/corrupt the ICAO code  when pulled from the updater server as will aircraft long names when in the NAVDATA and subsequently picked up on the box.

The last code in yesterdays NAVDATA release was OO-UAR.  The six codes below that were added or changed in the Updater DB today and pulled from the server to my NAVDATA.  For the A320 B774 and B733 the code was not direct from the updater DB but guessed correctly by my local software, exactly as has happened for these easy codes since 2.0.  The other four were not guessed correctly by my software and have corrupted. 

At the second screenshot is the five records that have corrupted in the past day with the dots after the long name.  No record had the dots immediately after I uploaded the new NAVDATA yesterday, I know, I specifically checked.  These five corrupted today as my box picked up the aircraft.

 

Title: Re: Improving RadarBox Automatic Database Population
Post by: ACW367 on February 26, 2011, 04:15:54 AM
Our comments:

>-Corruption bug messes display of all diacritical marks   à  & ū ö etc

Send two examples so we can investigate further.

In aiports table
Nagoya Chūbu Centrair Int't corrupts as
Nagoya Ch?bu Centrair Int'l

In updater DB and in NAVDATA since version 2.0, ANET photographer names with a diacritical mark have always corrupted in the PT fields
Sergio Mendes.    Becomes corrupted
Sérgio Mendes.

Also any company name with an & symbol, corrupts this to space underscore IE John Smith & Sons in NAVDATA becomes John Smith _Sons when displayed next to photo.

Title: Re: Improving RadarBox Automatic Database Population
Post by: ACW367 on February 26, 2011, 04:17:59 AM
Time for bed - Can someone post a screenshot of a TACTICAL or VARIOUS to illustrate the Airnav quote

- Corruption to Info displayed next to photo.  Reaches into Navdata for Regn rather than Hex

Explain in detail.

Title: Re: Improving RadarBox Automatic Database Population
Post by: ACW367 on February 26, 2011, 04:38:50 AM
Our comments:


-No 3D models or skins for hundreds of ADS-B aircraft. 3D models also set up against corrupted ICAO codes like A380 instead of A388.

We need a full list with these errors. It's a matter of changing the sub-folder names inside the GE_Models folder.

- No Silhouettes for over 600 aircraft types

Where is the Silhouette team? We can add extra silhouettes for V4.04.

-

The second question confuses me.  TARBAT provided in the other thread the full list of 600.  Airnav have always stated they do not require third party resource.  Therefore surely the silhouette team that created the 2.0 silhouettes was within Airnav.  If this task had been regularly reviewed within airnav over the years, it wouldn't have grown to be such a big task.

For the first question.  Can someone monitor the network for a week or so and report to Airnav every single airline code/ICAO Code combination that appears on ADS-B aircraft

Just looked at nework A332 the following airlines appear.
Those with ** are ones not currently showing in the 3D Skins folder and therefore Airnav created skins are required.  This is just a small sample.  As given above it would take me maybe a week to get you the full list of ADS-B regulars.

Network A332 at 0400Z 26 Feb
AFL
AFR
**AIC
ALK
BER
**CRK
**DAL
ETD
EVA
**GIA
**GFA
**GRL
JST
KLM
**KKK
**MEA
QTR
TAM
TCX
THY
**XLF
Title: Re: Improving RadarBox Automatic Database Population
Post by: tarbat on February 26, 2011, 08:34:09 AM
Time for bed - Can someone post a screenshot of a TACTICAL or VARIOUS to illustrate the Airnav quote

- Corruption to Info displayed next to photo.  Reaches into Navdata for Regn rather than Hex

Explain in detail.

Hopefully it's explained with these screenshots I posted a while ago:

(http://farm6.static.flickr.com/5001/5268003353_3c82021d52_t_d.jpg) (http://www.flickr.com/photos/tarbat/5268003353/sizes/o/in/photostream/)  (http://farm6.static.flickr.com/5129/5268579084_3ceaa23a04_t_d.jpg) (http://www.flickr.com/photos/tarbat/5268579084/sizes/o/in/photostream/)

The information displayed next to the aircraft photos is wrongly derived using a REGISTRATION lookup on the aircraft table, whereas it really needs to use the ModeS hex code (the primary key) to lookup the information.

Some more explanations at
http://radarspotters.eu/forum/index.php/topic,4169.msg29969.html#msg29969
http://radarspotters.eu/forum/index.php/topic,3932.msg27958.html#msg27958
Title: Re: Improving RadarBox Automatic Database Population
Post by: tarbat on February 26, 2011, 09:11:50 AM
-No 3D models or skins for hundreds of ADS-B aircraft. 3D models also set up against corrupted ICAO codes like A380 instead of A388.

We need a full list with these errors. It's a matter of changing the sub-folder names inside the GE_Models folder.

The first place to start is the missing models (not skins).  A quick analysis of MyLog indicates these are the most numerous ADS/B aircraft (flying over Scotland) without GE models:

B77W   65
RJ85   19
GLF5   13
ATP   8
A388   7
CL60   5
EC25   3
C25B   2
E55P   2
F900   2

Created using this SQL:
SELECT DISTINCT 
  Aircraft.AircraftTypeSmall,
  COUNT(Aircraft.ModeS) AS Counter
FROM
 Aircraft
 LEFT OUTER JOIN GE_Models ON (Aircraft.AircraftTypeSmall=GE_Models."AT")
WHERE
  (GE_Models."AT" IS NULL) AND
  (Aircraft.ADSB = "Y")
GROUP BY
  Aircraft.AircraftTypeSmall
ORDER BY
  Counter DESC
Title: Re: Improving RadarBox Automatic Database Population
Post by: bearcat on February 26, 2011, 10:10:40 AM
"Confusion in decode of aircraft hex leading to incrrect callsigns/heights/locations being displayed on screen

Nothing can be done regarding this."

Why not? Other boxes don't seem to have a problem. See the attached from Thursday evening, which was the correct aircraft/flight?.
Title: Re: Improving RadarBox Automatic Database Population
Post by: AirNav Support on February 26, 2011, 10:24:15 AM
Bearcat,

We were asking about database changes at the moment. Any other issues will be worked on later on.

Also some of the changes taking place mentioned above are taking place both server side and the software side. So do not expect a difference to everything mentioned until a new software is released.
Title: Re: Improving RadarBox Automatic Database Population
Post by: bearcat on February 26, 2011, 11:22:50 AM
This was raised in this thread, but look forward to this being sorted out in the next software release
Title: Re: Improving RadarBox Automatic Database Population
Post by: tarbat on February 26, 2011, 02:27:00 PM
Just a heads-up for the next version, but 42 aircraft in this new database still have invalid ICAO Type codes (field AT), and there are around 611 aircraft types without silhouettes available.

Note that if end-users make use of IanK's silhouettes, then there are only 281 silhouettes missing for this new database:

E45X, CRES, LAE1, GLF6, S108, GOLF, R722, C188, CP23, JCOM, PP2, DR1, DR22, FLIZ, GA20, GY20, SA30, YK55, DG60, G103, PNR2, RV3, UF13, XA85, CT4, DC3T, PK15, SF28, CASS, FB1A, HB23, MC10, MXS, NIPR, P8, PAT4, R721, SE5A, SRAI, UHEL, V322, BE77, C162, CH30, D31, IFUR, MG21, PK20, PKAN, SF2, SKYR, SONX, SU95, VTOR, WACC, B207, CORS, CP13, CRER, DC3S, DFLY, E230, EAGX, FA01, FA62, L181, M22, PITA, PT80, RF3, RV12, S1, SBOY, SU29, TAYA, VALI, VP2, XA42, , BE80, BE88, BL11, C06T, CA25, CB1, CH20, CJ1, CP32, DH2T, DWD2, EVIC, F156, F60, FINC, FLSS, G73, GP3, HDJT, HUML, IS28, J2, JT2, KZ7, L11, L18, LK19, LYSA, M28, MS31, MS73, N120, P2, PK21, PK23, QIC2, RC3, RENE, RJ03, RLU1, RS12, RYST, SA02, SAKO, SIDE, SKIM, SNS7, SPST, STOR, TAYD, VJ22, WA41, WFOC, -, A019, A22L, AA5B, AS31, AUJ4, B25B, B422, B757, BIPL, BLKS, BN2, BU81, C153, C190, C365, C430, C526, CA61, CA65, CA7T, CH65, CH75, CHR4, CL4T, CLA, COOT, CORO, CP20, CP21, DA50, DC83, DC92, DIMP, DSA1, E2CB, EC47, ECH0, ELST, EP9, FALC, FL55, FLE2, FNKB, FW44, G140, G202, G2GL, G46, GAUN, GM17, GP4, GSIS, H40, HI27, HM38, ISPT, JAJ5, JD2, KIS2, KL35, KNTW, KR1, KRAG, KZ2, L11E, L159, L37, LAK4, LC42, LNK4, M2HK, M2OT, MAGN, MC45, MD3, MG29, MIMU, MJ5, MJ7, MONA, MR35, MUS2, MY13, N3, N3N, NDIC, NORS, P36, P68T, P80, PA26, PEGZ, PETR, PK11, PK18, PNR4, PO2, PO60, PT22, PT70, PTMS, QR01, QUIC, RA14, RAF2, RAV5, RC70, S200, S210, S51D, S78, SA10, SAH1, SASY, SAVG, SCAM, SE5R, SEAW, SF23, SF27, SHEK, SKYC, SPHA, SRAS, ST30, TA20, TAIL, TBEE, TBM, TCAT, TEXA, TF19, TF21, TFK2, TMUS, TNAV, TRF1, TRIM, UL10, UT75, VIPJ, VIX, VTUR, WA42, WACO, WAIX, WOPU, YK53
Title: Re: Improving RadarBox Automatic Database Population
Post by: ACW367 on February 27, 2011, 12:46:36 PM
Airnav

Can you now confirm what your plans are for ensuring all required silhouettes and models, which are not included in the current 3.13 and 4.03 releases (as they also were not for the 2.0 release), are to be added and included over the coming '5 amazing releases'.

Regards
ACW367
Title: Re: Improving RadarBox Automatic Database Population
Post by: AirNav Development on February 28, 2011, 01:13:56 AM
Any volunteers to develop the missing silhouettes? ACW367/Tarbat: are you able to help us with this task?

Regarding missing models: documentation is available for such development so, just like FS users do, why not developing such models too? It would bring a lot more value to the community.
Title: Re: Improving RadarBox Automatic Database Population
Post by: ACW367 on February 28, 2011, 02:16:05 AM
Any volunteers to develop the missing silhouettes? ACW367/Tarbat: are you able to help us with this task?

Regarding missing models: documentation is available for such development so, just like FS users do, why not developing such models too? It would bring a lot more value to the community.

No doing quite enough already!!
Title: Re: Improving RadarBox Automatic Database Population
Post by: Marpleman on February 28, 2011, 11:51:44 AM
Any volunteers to develop the missing silhouettes? ACW367/Tarbat: are you able to help us with this task?

Regarding missing models: documentation is available for such development so, just like FS users do, why not developing such models too? It would bring a lot more value to the community.

Unbelievable!!!

Maybe the forum members could look at fixing bugs, re-writing software as well whilst they are keeping the database going?

Surely there's a minimum standard that needs to remain "in house" here?

In a desparate way, I can understand the aircraft database, although it still remains highly controversial as we've all witnessed, but silhouettes and 3D models is pushing the boundary way too far in my opinion.
Title: Re: Improving RadarBox Automatic Database Population
Post by: AirNav Support on February 28, 2011, 12:13:30 PM
Marpleman,

The silhouettes itself were never created by us and something that users requested for which other members and people in the community had made them and allowed them to be included in the last release.

AirNav never created any of them this is why we are asking as last time they were provided by kind individuals who were creating them for the benefit of the community.
Title: Re: Improving RadarBox Automatic Database Population
Post by: AirNav Development on February 28, 2011, 12:52:02 PM
Marpleman, silhouettes, airline logos, outlines have always been developed by our users and we helped them adding these features to the main software improving, as an example the airline logo identification routine several times as per our users request. There are things that are much better done by end users taking in account that we will do anything possible to accommodate users requests for these features.

There are hundreds of examples of this on the tech community: 99.9% of browser addons are developed by end users. Themes are usually developed by end users, etc, etc.

This has nothing to with software development, database integration, server optimization: those are things that are and will ever be done by us.
Title: Re: Improving RadarBox Automatic Database Population
Post by: Marpleman on February 28, 2011, 02:29:30 PM
Dev/Support

I totally understand where you're coming from with those comments, but as the database/logo's/silhouettes/flags, and whilst I'm at it, routes, come out of the "tin" so to speak, it reflects badly on the product, if there are holes in the standing data available as part of version downloads, or on the software cd.

The aircraft database and routes could be treated as an exception to this, due to the frequency in which they change,  however everything else is pretty static?

One of the reasons I chose RadarBox was the fact that the user could simply load the cd and not have to go trawling off to find other add ons - this being a highly attractive marketing point at the time.

Unfortunately, in my opinion, this is no longer the case guys!

We have to lump it, in as far as new aircraft being picked up without a silhouette, and if Rod ever hangs up his hat, god forbid where we'd be with  airline/operator logos?

Does the current download off the website incorporate the new navdata file yet?

If not, then surely it should, as it reflects the current situation available to users.

These ase just my opinions obviously!




Title: Re: Improving RadarBox Automatic Database Population
Post by: DaveG on February 28, 2011, 03:03:33 PM
Airnav, correct me if I'm wrong.  But do you not sell the product with silhouettes and 3D models, and the program was designed to display them.  If the answer to both of these is yes then it should be Airnav providing the goods to the paying customer. 

I'm all for third parties helping improve and enhance products but you (Airnav) are very quick to put-down or distance yourself from third party products.

When you try to put everything into a product and exclude third parties your never going to keep everything up to date, and if you can't do not even try as that is what people will expect.


Title: Re: Improving RadarBox Automatic Database Population
Post by: bratters on February 28, 2011, 03:18:18 PM

One of the reasons I chose RadarBox was the fact that the user could simply load the cd and not have to go trawling off to find other add ons - this being a highly attractive marketing point at the time.

Me too. Being a computer numpty, I wanted "plug 'n play" simplicity.
 
I can still mess around with aerials and bits of wiring thanks to earlier radio experience, but when it comes to PCs - forget it. Nor do I particularly want to learn PC use beyond my immediate needs.

For several months now I have not clearly understood the work being undertaken by others beyond the fact that several forum members (and FDL) have been trying to update and supply data - data that I genuinely thought would come directly from Airnav as part of the original deal.

The pity of it is that my box still works very well and reliably, the display and information presentation is good and very much to my liking but the original high quality data stream has not been sustained.

Let's hope all these current discussions and exchanges of views will soon put things back on an even keel.





Title: Re: Improving RadarBox Automatic Database Population
Post by: LSZS on February 28, 2011, 03:45:26 PM


Created using this SQL:
SELECT DISTINCT 
  Aircraft.AircraftTypeSmall,
  COUNT(Aircraft.ModeS) AS Counter
FROM
 Aircraft
 LEFT OUTER JOIN GE_Models ON (Aircraft.AircraftTypeSmall=GE_Models."AT")
WHERE
  (GE_Models."AT" IS NULL) AND
  (Aircraft.ADSB = "Y")
GROUP BY
  Aircraft.AircraftTypeSmall
ORDER BY
  Counter DESC

OT: SQL Error: near "(": syntax error
I'm using sqllite maestro 9.10.0.4
Title: Re: Improving RadarBox Automatic Database Population
Post by: tarbat on February 28, 2011, 04:14:59 PM
Any volunteers to develop the missing silhouettes? ACW367/Tarbat: are you able to help us with this task?

Sorry, I don't have the talent to make silhouettes (I've tried!).

Best approach would be to provide a new menu function in Radarbox v4.04 called "Import Silhouettes".  End users could then download IanK's full set of silhouettes, and the "Import Silhouettes" function would resize these to 68x16 and save them in the silhouettes folder.  Simple.

End users would then end up with around 1270 silhouettes covering the vast majority of ICAO types without having to distribute resized versions of IanK's silhouettes (which would breach his copyright).

On a similar note, a new menu function called "Import Routes" would also be a useful way of creating up-to-date route data, based on that freely available at http://groups.yahoo.com/group/PP-logs-and-routes/files/ (48000+ routes).
Title: Re: Improving RadarBox Automatic Database Population
Post by: bratters on February 28, 2011, 04:34:27 PM
Tarbat, you make things sound so simple and straightforward, but if that's the case why oh why doesn't it happen?
Title: Re: Improving RadarBox Automatic Database Population
Post by: AirNav Support on February 28, 2011, 04:49:45 PM
Marpleman/ DaveG/ bratters

We have to be careful where we draw the line otherwise we will end in a position where we constantly updating everything and this cost will have to be past back to customers. Some of you will read this and get annoyed but you have to be realistic.

If we were to now decide we will create the Silhouettes in house this would be a cost to us especially since we never created them in the first place and the community etc.. provided them. If we do this then in the same area we should then be providing detailed views of all major airports that the community has helpfully provided. Again this would be a large cost to us. Furthermore customers would demand all the 3D models of all aircraft should be provided with all the liveries. Again that would be an enormous task and have a significant cost.

That's not to say we will just ignore them but we are trying to get the most used models etc.. and provide them but we cannot be expected to provide everything. In the example of Silhouettes and Airport views, this can be a community effort and has been in the past.

With respect to the Aircraft Database work is being done via the updater's who are doing a fantastic job and the server/client issues are being worked on and a more permanent link for updates  and we hope to have this resolved with the new software.

The routes use FlightStats to determine routes currently and we are using other means to gain better results. Again in this case we have done a good deal to get routes but the server/client issues need to be resolved but we cannot be expected to provide routes for all the world without some of the cost being past back.

Some of you mention add-ons but as shown recently many of these have now gone or now have charges. What we are doing is providing a lot of these services for free and absorbing the cost.
Title: Re: Improving RadarBox Automatic Database Population
Post by: Runway 31 on February 28, 2011, 05:01:41 PM
Tarbat,

When you mention 1270 silhouettes on Ian K's site, I take it this figure included the 100's of ones not yet available?

I dont see anything wrong with users themselves going to the site as has been done for years and getting them ourselves and re-sizing., do we really need a nanny state to do everything for us?

The ones not available are hardly going to reduce the pleasure of using the box as they are not very frequently seen, especially here in Scotland.

Alan
Title: Re: Improving RadarBox Automatic Database Population
Post by: tarbat on February 28, 2011, 05:16:39 PM
When you mention 1270 silhouettes on Ian K's site, I take it this figure included the 100's of ones not yet available?

No.  In the download that IanK provides, there are 1339 silhouettes.  70 of these are copies with "Airbus", "Boeing", "Antonov" on them, leaving 1269 actual unique silhouettes.  Alright, some of these are for ground vehicles, etc.

I dont see anything wrong with users themselves going to the site as has been done for years and getting them ourselves and re-sizing., do we really need a nanny state to do everything for us?

Unfortunately I think we do, since end-users complain about missing silhouettes when all they have to do is download IanK's silhouettes, resize them to 68x16, and save them all in the data/silhouettes folder.

After all, it was IanK that provided the Radabox silhouettes in the first place.
Title: Re: Improving RadarBox Automatic Database Population
Post by: Runway 31 on February 28, 2011, 05:56:18 PM
Yes I was aware who provided then and I am greatful for his work.  I hadnt realised there were that many actual silhouettes.

I hear what you say but still think that nanny state thinking is a bit much to expect.  Point people in the right direction and let them have a go themselves.

Alan
Title: Re: Improving RadarBox Automatic Database Population
Post by: Bob SEN on February 28, 2011, 07:51:23 PM
Dont see what all the fuss is about really.......... you go buy a car & then put in the stereo/seatcovers/nodding dog or whatever you want to personalise it..... the Radarbox suits me fine, yes granted there are things I would like to see added & also options on there that I am not interested in, but on the whole what we have is people in the community that are putting themselves out to make this product better....... which works for me !!!

but that said, I think as already mentioned it would be a good idea to "automate" things like silhouettes for those that arent too up on pc's .... but thats just my opinion
Title: Re: Improving RadarBox Automatic Database Population
Post by: tarbat on February 28, 2011, 09:02:27 PM
Point people in the right direction and let them have a go themselves.

http://www.airnavsystems.com/forum/index.php?topic=4648.msg46529#msg46529
Title: Re: Improving RadarBox Automatic Database Population
Post by: ACW367 on February 28, 2011, 10:46:43 PM
When you mention 1270 silhouettes on Ian K's site, I take it this figure included the 100's of ones not yet available?

No.  In the download that IanK provides (http://www.gamefront.com/files/17918616/SBS_1_85x20_size_Aircraft_Silhouettes_zip), there are 1339 silhouettes.  70 of these are copies with "Airbus", "Boeing", "Antonov" on them, leaving 1269 actual unique silhouettes.  Alright, some of these are for ground vehicles, etc.

I dont see anything wrong with users themselves going to the site as has been done for years and getting them ourselves and re-sizing., do we really need a nanny state to do everything for us?

Unfortunately I think we do, since end-users complain about missing silhouettes when all they have to do is download IanK's silhouettes, resize them to 68x16, and save them all in the data/silhouettes folder.

After all, it was IanK that provided the Radabox silhouettes in the first place.

Whoa guys. Ian K very publically on this forum stated that his Intellectual Property would not be available to Airnav users.  To advocate resizing them breaks his IPR and leaves any found doing so, up for legal action from Ian K - if he should so chose.  I am not a legal expert, but was privy to extensive guidance on the nuances of IP law from a top legal team, when the RAF changed its entire corporate identity because it could not guarantee that it could assert IPR over the roundel, which was being used extensively by fashion houses and moped manufacturers. 

Airnav I believe still has rights, granted from Ian K to the 623 silhouettes that come with the Version 4.03 CD.  Anymore than that from Ian K resizes, I would be urgently seeking urgent legal advice on. 

The only solution now either appears to be that either a volunteer stands up to assist airnav out again and produces silhouettes in a similar style but which can be shown not to be direct copys of Ian K's IP work, or Airnav abandon all silhouettes and develop another way that AC Types can be differentiated visually, that can be maintained from within Airnav development resource at no cost long term.

Struggling to see where the resource cost implications in silhouettes, flags, logos, etc lie.  These could be knocked up by any developer while they are waiting for programmes to run/test.  Rod knocks up outlines and logos in a matter of minutes.  Tarbat takes slightly longer when doing a flags update every 6 months or so.  Yes Airnav are way behind the dragcurve having neglected it all for 3 years, but once throw a tiny amount (2-3 days dedicated) of development resource at the task, and they get up to date.  The frequency of the tasks means it could easily be achieved using spare capacity within the tech development team. 
 
I they do not do this I hope that they change their advertising. The current page:
http://www.airnavsystems.com/RadarBox/index.html

One of the main highlighted quotes is:
Accurate Extensive Data Included
The Aircraft Database is powered by the Gatwick Aviation Society. Navigation information information comes from Navigraph.

And from http://www.airnavsystems.com/download/anrb/Why%20RadarBox%20-%20Leaflet.pdf
No add-on programmes required
• Detailed worldwide map coverage
• Extensive internal database containing
thousands of aircraft, airfields,
routes, navigational beacons and fixes.
• Company logos
• Aircraft silhouettes
• Country flags

I hope that these page will be urgently changed to reflect that defacto all Airnav aftersales product support is now provided by small volunteer teams that provide Airnav 100s and 100s of hours of support services free of charge and don't get any credit. 

Airnav of course have had 10 months in which to make small changes to thier advertising to reflect the reality of the product support.  Airnav really know how to stretch the genouroristy of volunteers and then still advertise that it is all Airnav internal work.

Title: Re: Improving RadarBox Automatic Database Population
Post by: tarbat on February 28, 2011, 11:14:29 PM
To advocate resizing them breaks his IPR and leaves any found doing so, up for legal action from Ian K - if he should so chose.

So does the Windows Vista O/S break Ian's IPR when it displays resized thumbnails of his silhouettes and saves those in the thumbs.db?  That's all I'm advocating that Radarbox could do - resize, display, store locally.  I'm not suggesting anyone should then distribute those resized silhouettes.
Title: Re: Improving RadarBox Automatic Database Population
Post by: AirNav Support on February 28, 2011, 11:42:32 PM
ACW367,

Our case was that the logos, silhouettes was something that the community had created and happily allowed us to add to the software. Permission was granted and in some cases compensation was given. For us to now pick up this task we should do exactly the same for Outlines and that's where we would dragged into updating/adding something new nearly every day which will add up to be a considerable resource. This is why we have to cut the line somewhere.

Regarding the advertising, if you felt that way you could have easily contacted us via other means and made this known and this would have been changed. The work of the updaters has been mentioned many times on the forum by us and praised highly.

Also Airnav after sales product support isn't provided by a small team of volunteers unless you want us to pass you the current support inbox :)
Title: Re: Improving RadarBox Automatic Database Population
Post by: Marpleman on March 01, 2011, 11:12:11 AM
Spot on ACW - very well put

ACW367,

Regarding the advertising, if you felt that way you could have easily contacted us via other means and made this known and this would have been changed. The work of the updaters has been mentioned many times on the forum by us and praised highly.


Why oh why is it that a forum member has to highlight something so obviously wrong?