Re[2]: [Tlf-devel] Re: TLF country resolution

[Martin Kratoska]

>>you are right, tlf does not know about prefixes at the moment, it just looks
>>at the length, assuming the shorter part before or after the slash is the
>>prefix. Of course this fails when both parts are the same length. I can even
>>think about P3A/CE0Y coming on the band and tlf thinks it is Cyprus.

of course, there are many weird calls which are not properly resolved
by most contesting software including CT, TR, NA to name the most
known ones.

JS> I have had some experience with xlog with weird prefixes. Just as you
JS> think you have solved one prefix bug, a station shows up with the call
JS> K1B. No, it's not USA, but Baker Island. What about K8O and K8T: they
JS> are American Samoa. Another nice one is the CE9 prefix/suffix. I wish
JS> hamradio agencies would stick with the rules and not issue callsigns
JS> which give me the creeps. Sigh!

JS> Joop PG4I

This is another problem. A station log used over very long time should
use very extensive and precise country resolution algorithm AND a
quite complex set of country tables which should be maintained over
the time. I offer this, my tables originated in 1991 and updated twice
a month are currently used in YPLOG and numerous private projects.

A contest log should properly resolve the ACTUAL calls only, no
feedback to the long history is needed. It seems that a standard .cty
file is appropriate but I suggest another "last minute" table with
exceptions TO BE EXPECTED in the upcoming contest. Of course, this
file should be simple as possible, ASCII formatted and very user
friendly, any user should be able to update this. However i offer also
to maintain this table for TLF. For TLF, we don't need tears anymore!

The country resolution system is not a big problem, I think. The more
serious problem is the cwdaemon. Sigh!

-- 
73,
 Martin OK1RR
 address@hidden