ClubLog CTY.XML

[aa5sh]

Due to its very detailed history of exceptions and invalid operations as well as date ranges to match prefixes I added this dataset to be used for importing of old logs as well as when in manual entry mode. This is partially in response to issue #684

[foldynl]

thanks a lot. I was looking for some list with old DXCC Entities, but I only found something old on ARRL. I didn't know that Clulog has a full list with deleted entities. Thanks

[aa5sh]

[aa5sh]

Awards Before - See numbers

After - Just left with the 0 for the MM stations.

[foldynl]

Just a few notes. I’ve been playing with this for a week already. It’s not in your implementation, but it seems to me that it’s not possible to use Clublog as a source of entities, because either I don’t understand it or they have errors there. Most likely it’s that I don’t understand it, but for example 3Y8XSA — the old algorithm (cty.dat) returns a DXCC, but with the new data I can’t find any entity. 3Y is there, but it’s marked as 3Y/B or 3Y/P. That’s what I don’t understand — which one to choose. There are more such cases.

The problem is much more complicated. I think it needs to be simplified to the extent that we really just go with the approach that the user only wants to see deleted entities during editing. Nothing else. Yes, during import and DXCC update it may happen that entities are incorrect, because in that QSO date the entity list had a different DXCC, but I think that’s a smaller risk than starting to incorrectly assign DXCC to current entities based on Clublog CTY xml file.

[aa5sh]

With the ClubLog list 3Y8XSA is there in the clublog_exceptions list. That callsign was valid for Antartica but only for the time period 2010-11-01 to 2011-12-31.

Where with the current list it is also an exception but it does no date validation so it would return it currently but that is not technically accurate.

The most accurate way would be change anyplace you use lookupCallsign to pass the qso date so in new contact widget if we change setDxccInfo to this:
`void NewContactWidget::setDxccInfo(const QString &callsign)
{
FCT_IDENTIFICATION;

qCDebug(function_parameters) << callsign;
QDateTime qsoDt = QDateTime(ui->dateEdit->date(),ui->timeOnEdit->time());
setDxccInfo(Data::instance()->lookupCallsign(callsign.toUpper(), qsoDt.toUTC()));

}`

and if you enter 3Y8XSA with todays date it doesn't return a valid dxcc. but if you change to manual entry mode and put in say 2-Nov-2010 it returns Antartica because that was when he was there.

If you go to the QRZ page for 3Y8XSA you will also see he was there then.

[foldynl]

I didn't want to focus on the callsign 3Y8XSA but rather on its prefix. What I wanted to say is that from Clublog, if we ignore that exception, there is no clear definition for the prefix 3Y. There are the two I mentioned, but I don't know what /P and /B mean. These /P /B make a partial match of this prefix impossible.

Unlike CTY.CSV, where 3Y is clearly defined.

There are more of these ambiguities for me. This is just an example where I already told myself that I really don't understand it and therefore it is not possible to adopt it yet.

[aa5sh]

I think 3Y is a good test case because just by itself it can't tell which entity it is. In the ARRL DXCC List it is listed for two:

So the /P or /B would indicate which one Bouvet or Peter 1. So all of those operations you wouldn't be able to identify by the prefix but really just in the Exception list:

[aa5sh]

Which the standard CTY for 3Y it shows it's DXCC of 13 which in Antartica/

[foldynl]

I'm quite confused by this. This is really important and could break a lot of things, so we should avoid making any changes until everything is clear. In other words, I'm afraid to make a change to this just because we need "deleted" countries. Yes, there is an argument that we can divide it (old algorithm for new QSO and new algorithm for old QSO), but then there will be chaos for the users, depending on which data source is used.

That's why I think we should focus on where the "Deleted" countries are needed and offer them there. I probably wouldn't consider importing them now. And I think the "Deleted" countries should only be offered in QSO Detail. Am I right?

[aa5sh]

Ok I initially started due to the deleted countries, but I do think this is a better solution for the DXCC recalculation because you could have issues depending on the age of your log. For my log if I chose the option today to let QLog update my DXCC information it changes some of my countries to be wrong. I know part of it is due to Deleted countries being lumped somewhere else - which is inaccurate.

With QLog today if I let QLog determine DXCC on import:

With Clublog version determining:

With my log as is in QLog:

From my DXCC Record at LoTW ( I forgot to uncheck eQSL):

I want you to feel comfortable with the idea of making a change but I think the choice between the two is the CTY.CSV used today is optimized for logging today realtime QSOs, where as the club log cty is designed for today and old QSOs, that's why they have thousands of exceptions and invalid entries.

As much as I hate saying this because I don't like comparisons but a handful of other loggers have made the transition Log4OM, RumLogNG etc. It is just a more robust dataset.

I'm ok with leaving it as is but didn't want you to think it was just about having the deleted countries show. I think this is a better resource to make it more accurate when loading existing logs.

[foldynl]

I agree with you. I also think that using the Clublog source would be better, but I don’t know how to deal with the problem I described to you above. I admit, I tested Wavelog which has clublog cty as a source of entities, and I can confirm that for the above-mentioned callsign it simply does not provide a DXCC entity. Hmm, it’s strange that nobody reported this, because there are more exceptions where cty.csv gives a result and the Clublog cty does not.

Yes, these are special callsigns; I came across this by accident when I was running comparison tests of these two methods. And there are really quite a lot of those differences.

I’ll try to look into it more somehow, but it makes me a bit nervous, because I’ve already spent a lot of time on it, and as a result many other things in QLog are waiting for implementation.

[aa5sh]

That callsign is only valid for back in 2010, so if you put in the manual date it will show it properly. Other than that it is ambiguous since like I showed 3Y points at two DXCC. CTY says Antarctica which is wrong. Best solution would be to add a message box saying that it is an exception during selected time period or something. Or not valid DXCC.

…

On Fri, Sep 26, 2025 at 12:35 AM Ladislav ***@***.***> wrote: *foldynl* left a comment (foldynl/QLog#728) <#728 (comment)> I agree with you. I also think that using the Clublog source would be better, but I don’t know how to deal with the problem I described to you above. I admit, I tested Wavelog which has clublog cty as a source of entities, and I can confirm that for the above-mentioned callsign it simply does not provide a DXCC entity. Hmm, it’s strange that nobody reported this, because there are more exceptions where cty.csv gives a result and the Clublog cty does not. Yes, these are special callsigns; I came across this by accident when I was running comparison tests of these two methods. And there are really quite a lot of those differences. I’ll try to look into it more somehow, but it makes me a bit nervous, because I’ve already spent a lot of time on it, and as a result many other things in QLog are waiting for implementation. — Reply to this email directly, view it on GitHub <#728 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUEEMXSS36RU6WB74EBB6DD3UTGC7AVCNFSM6AAAAACDR26BJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMZWHA2DEOJTHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[foldynl]

The more I dive into this, the more I realize that I don’t understand it, and nothing makes sense to me. Right now, for example, I’m dealing with this problem for K7A, but there are more such callsigns with different results:
K7A

• CTY.dat returns DXCC 291 (United States of America), CQZ 6
• Clublog.xml returns DXCC 6 (Alaska), CQZ 1
• QRZ returns 291 CQZ 6
• QRZCQ returns 291, CQZ 5, ITU 8

It still seems to me that CTY.dat (CTY.csv) is more accurate for American callsigns, while CTY.xml is more accurate for English ones. That makes sense, because CTY.csv comes from the American source and Clublog is English.

But it still seems to me that it’s better to use CTY.csv from AD1C. On the other hand, you’re right that CTY.xml has history, which is needed when importing older QSOs.

Hmmm… I really don’t know if it’s worth dealing with old QSOs and their DXCC entities, potentially breaking the new DXCC entities in the process.

[aa5sh]

If I modify NewContactWidget to use my lookupCallsign (ClubLog's XML) for all lookups and not just the manual ones by this change:

I got USA ITU 8 CQZ 5 for a QSO for today.

The Alaska entries in there are for operations back in 2006, 2008 and 2009. So if those dates are entered it would show Alaska not USA.

[foldynl]

I got USA ITU 8 CQZ 5 for a QSO for today.

but I think the correct one is CQZ 3, ITUZ 6 DXCC 291. That is set on their page on QRZ.com and the page looks updated.

Another problem with clublog.xml is that it doesn't contain ITU Zone information. It's not that big of a problem for "common" callsign, but it is critical for special ones. Some ITU Zones can be obtained from cty.csv, but there are many callsign that I just can't determine the ITU Zone for.

To be honest, I don’t really see a way to make the data more precise and usable from clublog.xml. I have to admit that I looked into Wavelog to see how it handles this, and unfortunately there’s nothing special there. It returns exactly what we’re talking about here. So your implementation and my refinement of the algorithm using cty.csv (adding ITUZ and adding missing callsigns from cty.csv) isn’t wrong, it’s just that the prefixes+zones are "inaccurate" in clublog.xml. And it is inaccurate only for the American callsigns.

[aa5sh]

With US Calls you cannot map callsigns accurately without using a database like QRZ. For install W5IHL shows up in QLog CTY CQZ 4 and ITU7 but he is in California so CQ Zone 3. People can move wherever and not change calls like years ago, or can get vanity callsigns.

…

On Sep 29, 2025, at 3:37 PM, Ladislav ***@***.***> wrote: foldynl left a comment (foldynl/QLog#728) <#728 (comment)> I got USA ITU 8 CQZ 5 for a QSO for today. but I think the correct one is CQZ 3, ITUZ 6 DXCC 291. That is set on their page on QRZ.com <https://www.qrz.com/db/K7A> and the page looks updated. Another problem with clublog.xml is that it doesn't contain ITU Zone information. It's not that big of a problem for "common" callsign, but it is critical for special ones. Some ITU Zones can be obtained from cty.csv, but there are many callsign that I just can't determine the ITU Zone for. To be honest, I don’t really see a way to make the data more precise and usable from clublog.xml. I have to admit that I looked into Wavelog to see how it handles this, and unfortunately there’s nothing special there. It returns exactly what we’re talking about here. So your implementation and my refinement of the algorithm using cty.csv (adding ITUZ and adding missing callsigns from cty.csv) isn’t wrong, it’s just that the prefixes+zones are "inaccurate" in clublog.xml. And it is inaccurate only for the American callsigns. — Reply to this email directly, view it on GitHub <#728 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUEEMXX2N5WCAR4LULD6QNT3VGKCLAVCNFSM6AAAAACDR26BJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNBYHE3DGOBQGM>. You are receiving this because you authored the thread.