How to programmatically distinguish European from non European call sign?

Question

Any ham radio log processing app developers?

I am creating web application to manage our club award and I need to programmatically distinguish European from non European stations by call sign.

I cannot find viable solution so any hint is valuable.

I use PHP but I guess any other platform experience could be helpful.

Answer 1

Jim Reisert AD1C regularly publishes various downloadable country files containing an up-to-date list of callsign prefixes with their associated countries, continents, etc. Those files are meant to be used by ham software.

Here's three lines from a 2016 cty.dat file. Notice how the fourth column indicates the continent (SA, EU, AF).

Guyana:  09:  12:  SA:    6.02:    59.45:    4.0:  8R:
        8R;
Croatia: 15:  28:  EU:   45.18:   -15.30:    -1.0:  9A:
        9A;
Ghana:  35:   46:  AF:    7.70:     1.57:     0.0:  9G:
        9G;

You can download the source of TLF and see how tlf reads and processes it. I rely on Jim's cty.dat file when I use TLF, a contest logging and dupe-checking program for Linux.

Here is Jim's latest country file.

Answer 2

The ITU is the international body responsible for the allocation of call sign prefixes to each country. You can consult this table of allocations in order to build the necessary logic in your program to determine if the call sign in question meets your award requirements.

An example of this table of ITU allocations can be found at: http://www.arrl.org/international-call-sign-series

Here is a snip of that table:

As an alternative, you could subscribe to the QRZ.COM call sign lookup service. The data is exchanged via XML so you could resolve the country from the appropriate XML tag. This may not be fool proof, however, if the call sign in question is not in their database or if the entry contains an error.

Answer 3

I did this years ago and I just looked to see if I could find the code and I must have just let it rot (entropy takes over the bits and turns them into ordered chess openings).

However, my method was not fool proof because there are exceptions to the basic rules that everyone knows. For example, I ran across a special event station in Russia or Finland (can't remember which) that failed my call sign test because it was too long at about 10 characters. I had a sanity check on the length of I think around 8 characters. I fixed my sanity check.

My method is straight-forward:

1. US calls were easy even though there are some to watch out for such as KG4 prefix is something other than a southern state (if I remember correctly, this was years ago).
2. I downloaded the ARRL list of official country or DX-Entity call sign prefixes and turn it into a database used by my call sign lookup.
3. My program (since I am US resident) always checked US call sign first but as a cheat I also had the US Call sign database in a fast lookup table (all memory resident).
4. Then, I would do a RE prefix check on the ARRL DX-entity list and usually that creates a match to ID the country or entity name (not all entries are countries).
5. If I miss on the program, I make note of it in a log and go check on it later to see why. Usually it is a weird case that snuck thru or maybe a special event station call sign.

To test my program when I first ran it, I downloaded the entire QRZ.com database (I was a subscriber with permission to download) and I tested my program against every single call sign in the QRZ database to validate that we had the same DX entity name. I actually found a few that were incorrect in the QRZ database.

I wrote the program in C++ and it ran on my Mac computer and I stopped using it back around 2005 when I started using the MacLoggerDX application which had its own call sign handler.