There is a list at:
http://www.arrl.org/awards/dxcc/dxcclist.txt
Is this what you want? If so, I'll talk to Bill Moore, who maintains the
list, to see if there is some mechanism by which we can generate a more
machine-friendly format. It's unlikely that we'll be able to supply data
with the granularity you'd like, but at least the data used for DXCC is
available.
Jon
--
Jon Bloom, KE3Z
[EMAIL PROTECTED]
Electronic Publications Manager
(Software, CD-ROMs and Web site)
> -----Original Message-----
> From: Hamish Moffatt [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 08, 2000 9:54 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [log project] schema
>
>
> On Mon, May 08, 2000 at 09:33:16AM +0000, Richard Adams wrote:
> > On Mon, 08 May 2000, Hamish Moffatt wrote about, Re: [log
> project] schema:
> > > On Mon, May 08, 2000 at 03:59:55PM +0000, Wilbert Knol wrote:
> > > > The CTY.DAT list of DX entities is available and
> regularly updated:
> > > > http://www.contesting.com/ct/files/
> > >
> > > All the links under /ct are broken?! :-(
> >
> > Not quite all.
> >
> > http://www.contesting.com/ct/files.kr6x
>
> I'm sure I checked there earlier and it was empty -- but I
> see the files
> now! There is a newer version of CTY.DAT on the www.k1ea.com web site.
> However, they have gone to some trouble to compile this data
> so I think
> there would be copyright problems with pinching it.
>
> It IS very comprehensive, although not as comprehensive as it
> might be --
> for example, for each entity it allows additional prefixes.
> Additional
> prefixes may optionally override the zone numbers. However,
> this facility
> isn't used to correctly determine the zones for Australia.
> (We are spread
> between CQ zones 28, 29 and 30.)
>
> So the question is: do we want that facility in our schema? ie having
> the ability to subdivide an entity, with overridden zone numbers.
> I think it could be useful. Possible modified schema:
>
> create table country (
> name text PRIMARY KEY,
> deleted bool,
> timezone int2,
> latitude float4,
> longitude float4,
> adifnum int2,
> subentity bool,
> parent text
> );
>
> In this case, if the user enters a callsign 'VK3SB', we cut this
> down to VK3, and find a record in the prefix table with the country
> name "Australia - Victoria". We look up "Australia - Victoria"
> and find that it is a subentity, so we look up it's parent.
>
> There are a few advantages to dividing an entity -- mostly, for big
> countries the data is not accurate for the whole entity. Australia
> covers many CQ zones, and many time zones, and several degrees of
> latitude and longitude. We might even be able to calculated the
> US 'Worked All States' award if we divide the US into 50.
>
> They even allow particular callsigns to be exceptions. Like U8MIR
> is a space station, as was R0MIR, as was VK5MIR (not in South
> Australia!)
> 4U1UN is in New York, but 4U1?? is in Switzerland (from
> memory). We could
> put whole callsigns in with parent pointing to the parent entity.
>
> However, I don't think we should pinch this data. If we can find
> a free source, terrific; if not, develop it ourselves over time.
>
>
> Hamish
> --
> Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
>
