ACW367,
I understand all the arguments against using T-xxxxxx for these so-called tactical registrations. But:
The vast majority of SBS users get their registration details from GAS, which does NOT use the words TACTICAL in any registrations. So, where did this use of TACTICAL in the Yahoo group come from - not SBS users. It's a flawed solution. We should be looking for a solution that works for all Radarbox users, not just the few that contribute to a SBS Yahoo group.
Tarbat - don't know which it comes from for other systems and it is kind of not important in the points I am making. All I know is TACTICAL, <GND> do not trigger the parser. Individually tailored registration IDs would. The opinions that have been expressed in this thread do show that the use of TACTICAL does work for the majority of users and are happy with how it is presented in their Mylogs and reporters. However, they are campaigning alongside us updaters to get the bug fixed so they can then also become happy with how the photo and data next to it gets presented.
Sure, the 449 <GND> registrations, 9 "VARIOUS", and other duplicates are a problem that can be fixed by appending a unique differentiator or sequence number. For example, 01(GLF5) and 01(C17), 02(CL60) and 02(C17), etc. I've fixed my own database in this way, and it works.
I'm just trying to get a pragmatic solution in place that fixes the problem for everyone, without having to wait for Airnav to make a software fix sometime in the future. Simple changes to the database could FIX this problem within a matter of days, rather than the days/months/years (select your own guess) it will take waiting for a software change. Ultimately it doesn't bother me, I'm able to change my own database to make it work correctly with Radarbox.
You are not suggesting a fix, you are suggesting a workround. That was my point, doing a workaround to bypass a bug, and then having to redo that work back to the old way when the bug gets (eventually) fixed, is completely the wrong way to do things.
The only thing that is required is an Airnav bug patch. Whether it is in a new version or a standalone patch doesn't matter, but it is very long overdue.
At the moment the myflights and reporter produce exactly what is in our Navdata. The data next to the picture (and the picture itself) ignores what is in the navdata for the hex due to bugs. If airnav fix those longstanding bugs, problem is solved.
For example, 01(GLF5) and 01(C17), 02(CL60) and 02(C17), etc. I've fixed my own database in this way, and it works.
You have not fixed your database, you have amended your database to work around a bug. When the bug is fixed you will need to un-amend all those records. Again this method would foul the parser, so are you suggesting that those users that do then upload logs to the Yahoo group users then use another seperate work around for their reporter logs as they upload them to the mode S group.
I understand all the arguments against using T-xxxxxx for these so-called tactical registrations.
You say "so-called" tactical registrations. The ICAO docs on 24-bit codes enshrines that while civil aircraft must have a unique hex, to aid national security States can allocate serial batches for tactical allocation to military and government aircraft - hence the widespread usage of the phrase tactical. It comes from ICAO descriptions. I know quite alot about this as I work for the military and have access to the CAA docs that detail the tactical usage policy. I have also in the past seen copies of the US 3rd AF database that allocates this type of code on a rotational basis to USAF Squadrons in Europe. The CAA has allocated the entire 43D*** serial batch to the MOD for exactly this purpose, thankfully apart from occasional exercises the UK military have not started making extensive usage of them yet.
--
Hope this all helps explain and soon?? Airnav will produce the overdue bug fix (as you say insert your own day/month/year). They are working to whatever timescales they are working to, and we are not privy to them. All we can do is keep asserting how important their implementation is to our user experience and how these frustrations make their product less attractive to use (or recommend to others).
Collectively that is still being done, lets keep up the pressure.
