[Dxspider-support] DXSpider Enhancements

[Bob Nielsen]

On Tue, Dec 21, 2004 at 01:28:07PM +0000, Dirk Koopman wrote:
> 
> On Tue, 2004-12-21 at 03:30 -0800, Bob Nielsen wrote:
> > On Tue, Dec 21, 2004 at 10:39:55AM +0000, Dirk Koopman wrote:
> > > 
> > > Now would be a good time to make your suggestions for improvements and
> > > to tell me about those annoying problems that I haven't fixed yet.
> > 
> > The old problem about distinguishing between V6 and T8 is still there 
> > (it works correctly for sh/dx):
> > 
> > sh/dxcc v6
> > Prefix: V6 Dxcc: 104 (Fed-Micronesia-V6)
> >            Dxcc: 104 (Fed-Mic-V6-East)
> >   7000.3  T8DU        27-Nov-2004 2318Z                               <N3GNW>
> >  21230.0  V63ME       27-Nov-2004 2130Z                               <VY0PW>
> >  28046.5  T8VA        27-Nov-2004 1938Z  TOO QUICK FOR MY EARS        <PY2XC>
> >  28037.7  V6DDT       27-Nov-2004 1909Z                                <W2FU>
> >  21240.0  V63ME       26-Nov-2004 2148Z  Beaming  NA via 7N1RTO      <JH7RTQ>
> >  21224.9  V63ME       26-Nov-2004 0606Z  qsl via 7N1RTO              <JF1IXE>
> >  21225.0  V63ME       24-Nov-2004 2145Z  IOTA OC-010                   <N6KZ>
> >  21225.0  V63ME       24-Nov-2004 2141Z  endo san via 7N1RTO         <JA1FBD>
> >  21225.0  V63ME       24-Nov-2004 2142Z  QSL VIA 7N1RTO                <W6VA>
> >  21225.0  V63ME       24-Nov-2004 2141Z  Endo san qsl via 7n1rto     <JA1BOQ>
> > 
> > sh/dxcc t8
> > Prefix: T8 Dxcc: 104 (Palau-Is-T8)
> >   7000.3  T8DU        27-Nov-2004 2318Z                               <N3GNW>
> >  21230.0  V63ME       27-Nov-2004 2130Z                               <VY0PW>
> >  28046.5  T8VA        27-Nov-2004 1938Z  TOO QUICK FOR MY EARS        <PY2XC>
> >  28037.7  V6DDT       27-Nov-2004 1909Z                                <W2FU>
> >  21240.0  V63ME       26-Nov-2004 2148Z  Beaming  NA via 7N1RTO      <JH7RTQ>
> >  21224.9  V63ME       26-Nov-2004 0606Z  qsl via 7N1RTO              <JF1IXE>
> >  21225.0  V63ME       24-Nov-2004 2145Z  IOTA OC-010                   <N6KZ>
> >  21225.0  V63ME       24-Nov-2004 2141Z  endo san via 7N1RTO         <JA1FBD>
> >  21225.0  V63ME       24-Nov-2004 2142Z  QSL VIA 7N1RTO                <W6VA>
> >  21225.0  V63ME       24-Nov-2004 2141Z  Endo san qsl via 7n1rto     <JA1BOQ>
> > 
> > 
> > I think this is because they both show up as 104 in wpxloc.raw.  Is this 
> > an error?
> 
> It certainly looks that way to me. It is easily fixed for the future by
> giving one or the other a new country number; this does not fix
> historical data. That would need a program to go through and renumber
> everything. Oh for the "speed" and flexibility of a fully normalised
> relation database :-)!
> 
> I notice that T88 in wpxloc.raw is also called "West-Carolines-T88" with
> a dxcc of 104. This, together with T8 being "Palau-Is-T8" with a
> different timezone althoigh not being that far away is confusing to
> someone as ignorant about DXing as me.
> 
> The more I stare at wpxloc.raw, the less I like it. However, there is
> useful information gathered there that doesn't exist in cty.dat. 
> 
> I think what I need is a master list of DXCC entities with canonical
> prefix and then add stuff to that. But I am still consulting experts and
> thinking about it.

In looking a bit further into this, I found the adif spec (used by
contest logging programs), which assigns a different set of numbers than
does wpxloc.raw.  This is based on what ARRL uses for LOTW numbers,
although there are a few differences, which hopefully will be
reconciled.  This spec (which shows entity names but not prefixes, can
be found at <http://www.hosenose.com/adif/>.  There is probably also
some good information in the LOTW code (which is in C++).

What is the origin of the wpxloc.raw data?  It would be nice to have a
consistent list between LOTW, dx cluster and logging programs (which the
ADIF spec talks about).  ADIF looks like a good start.

Bob, N7XY