|
The Prefix Database - Prefixes Explained
The prefix database has two sections; the prefix definition list; the callsign exception list.
The prefix defenition list.
The standard allocations made by the ITU who allocate the prefix range for member countries.
Over a period of time prefix allocations can change, so many of these have date range limitations.
ITU member countries scope is often spread across several DXCC entities.
An example of this is the "GAA-GZZ" series allocated to the UK, the UK has several entities covered by the GAA-GZZ series.
Sub-definitions are created my member states themselves, e.g. UK uses GM for Scotland; GW for Wales etc.,
however some member allocations do not adhere to any particular convention, or have changed theirs over time.
Relying on the standard definition list would cause many ambiguities and requires further expansion.
Not only expansion of the standard prefix range e.g. UK "GAA-GZZ", e.g. GJ, GM, GW ,etc., but many callsign
or prefixes can not be determined by any en-bloc system, example "GB" prefix which have been issued
to any of the UK entities over a great number of years.
This problem is not limited to the UK callsigns, major problems exist in USA, USSR (that was) and many other countries.
For this reason, most prefix look-up systems rely on a list of callsign 'exceptions'; those callsigns that fall outside of convention.
Winlog32 combines both the standard definitions and a dedicated list of callsign exceptions to parse the Country entity from a callsign.
Callsign exception list.
Most callsign exceptions have a date range limitation to further improve accuracy.
Winlog32 has a massive callsign exception list, each individual callsign entry carries a date range limitation.
The callsign exceptions often are the result of modern relaxed call area licensing as in the case of W/K/N and
the US territories; the UK GB, GQ, GR and GO prefix; old USSR states, and minor hindrances like VP8, ZK1, JD1.
No system is infallible as new exceptions are continually appearing,
however the extensive prefix look-up system employed in Winlog32 ensures we have 99.9% accuracy or better.
Prefixes often encompass 'call areas'. These are usually defined by the number after the initial prefix.
These numbers may represent specific geographical 'call' areas of a country, or even the country entity itself.
They may indicate a licence class or have no meaning at all.
Example: Sweden with SM1, SM2, SM3 etc., each representing a geographical area where the licence was issued for,
or a geogaphical area which defines a different DXCC entity, as does SV1(Greece), SV5(Crete) SV9(Dodecanese Is).
Often licence requirements stipulate that the call area must be added as a suffix when operating outside the licencees call area, e.g. SM3xxx/1 is still Sweden but SV1xxx/5 is Crete.
Hams operating from a different country adds complexity, a temporary licence would usually require a suffix
or prefix to be added to the operators callsign to indicate the country.
In recent times there have been an increasing number of often unofficial suffixes, added to callsigns that are used merely for special events, the whole retrieval system must be aware of this.
The prefix database not only provides country entities, but includes other data for user interest like capital or regional cities' QRB and QTF, CQ and ITU zones and data for internal functions like map reference.
To encompass every conceivable variation and circumstance is a headache for any look-up system,
and to arrive at a 100% reliable system is impossible, to get a system better that 99% requires continual updating and revising.
Winlog32 has such a system, which is based algorithms and a prefix database which has evolved considerably since it was first developed in 1995 and expanded on an almost daily basis ever since.
How does it work?
A prefix search initially generates several possible strings that look for a match in the prefix database
Winlog32 uses a multi-tier system, looking for descending possible matches.
Each in turn only being processed if the preceding fails to find a match.
1. The look-up will try to match the complete callsign with any from the exceptions list,
this will usually check that the logged date matches the date range for the exception too.
2. An initial cleanse of the full callsign, stripping off any unnecessary or meaningless suffix regarding country designation.
Examples: G0CUZ/P, G0CUZ/M, G0CUZ/100, G0CUZ/LH are stripped to G0CUZ.
3. Callsign/call area suffix will be corrected for the lookup, example: RA3ZZZ/0,
for matching purposes the callsign will be changed to RA0ZZZ, then the correct call area and in this case country will be returned.
4. The parsing operation, which splits the callsign into several possible matches.
Most callsigns have a number following a letter combination, but in some cases callsigns start with a number so the prefix is parsed at the second number instance.
Example#1. Callsign: VP5/G0CUZ. As VP5 has fewer characters than G0CUZ, it is surmised that the prefix must be 'VP5' and this will be used.
Example#2. Callsign: CE0ZAA. This is parsed into three components: CE0Z, CE0 and CE. The length of the prefix has priority - 'CE0Z'.
If no match then the second part 'CE0' is used. If still no match then 'CE' is used.
A match will only be found if the logged date falls between the date range limitations that the prefix or callsign exception has.
Some callsigns may be matched correctly but still return a non-valid result.
Examples:
Callsigns with suffix /MM or /AM as they are not operating from a land mass.
Unofficial prefix, callsign or countries not-valid for DXCC.
Invalid, bogus or unlicensed operations as determined by ARRL/DXCC.
Callsigns beginning with "Q" as this has never been allocated by the ITU
The 'Search Prefix' mini-window has limitations as only the current date is provided in the search criteria.
Unless a year range is provided, prefix or callsigns exceptions with date ranges of less than a year may not be found by this method
The greatest DXCC entity accuracy will be found when logging QSOs, using the Log Check Robot, using right-click "Look-up DXCC" methods and for DXCluster spot alarms.
There is a possibility that no match will be found in the prefix database, if this is not the result of an incorrectly entered callsign or prefix, then this should be reported to Winlog32 for investigation.
Other inaccuracies can be reported too.
Winlog32 prefix database is periodically cross-referenced with that of 'Club Log' which probably has the most accurate and up-to-date information available for prefix definition.
|