[Dxspider-support] 3B7 St Brandon?

Dirk Koopman djk at tobit.co.uk
Fri Jul 28 09:03:32 BST 2000


On Fri, 28 Jul 2000, you wrote:
> I don't know which database file SPIDER uses for the country info.
> Perhaps it's a good idea to use the one of the logging program CT: cty.dat
> It's an ascii file that holds a listing of each DXCC entity and its
> allocated prefix blocks. The file is updated constantly and freely available to
> my knowledge.
> Other cluster programs like AK1A,DXNET and CLX also use cty.dat.

Actually AK1A uses wpxloc.raw, which isn't updated very frequently.

> From: Andrew B. White <k9cw at prairienet.org>
> > 3B6 and 3B7 count for the same country.  The ARRL list shows it as:
> >
> >   3B6,7  Agalega & St. Brandon
> >
> > It is interesting to note that 3B6 and 3B7 have different DXCC numbers,
> > however.  AK1A PacketCluster also returns "Agalega - 3B6" for "sh/pre 3b7"
> >

I actually use a combination of wpxloc.raw (with all the (many) mistakes in it
that I know about removed) and something which used to be distributed with
the CT stuff called RGSB.CTY. 

The reason this is done is because I store 'country' numbers (for speed of
search) in the dx spots files for spotter and spotted (amongst other things).

These numbers are roughly equiv to a dxcc country, but are actually used
to uniquely identify entities (almost always dxcc countries) that people 
might want to search for. 

The main purpose is to cope with the plethora of prefixes an 'entity' might 
have. To take an extreme example:-

sh/dx ve 
and 
sh/dxcc ve

will give different results because sh/dx works on the prefix as a string
and so will only give callsigns starting with VE, but sh/dxcc will give
all the VA, VO and the rest of the Canadian prefixes that they are now
using. 

Similarly:

sh/dxcc G 

will show all the G, 2E and M prefixes (but not 2M, GM, MM etc).

Now I will be converting from RSGB.cty to the CTY.dat file RSN, but it
doesn't really solve my problem which is I would really like some help
from an expert to cast their eyes on the issued wpxloc.raw and check that
the basic country information is correct.  You can ignore the actual
'dxcc' number 'cos dxcc don't seem to have an actual 'official' dxcc number
for each country.

For all that it doesn't use the absolutely latest CT data, I don't believe
that it is currently very far out.

Dirk G1TLH
--
Dirk-Jan Koopman, Tobit Computer Co Ltd 
At the source of every error which is blamed on the computer you will find
at least two human errors, including the error of blaming it on the computer.







More information about the Dxspider-support mailing list