Topics

TX7T Prefix unknown in Spot Collector but DXView is fine

Max NG7M
 

I must be missing an obvious setting?  TX7T's prefix isn't getting resolved in spot collector, but DXView resolves the prefix as FO-M and Marquesas Islands.  Operator error?

Max NG7M

Dave AA6YQ
 

+ AA6QY comments below

I must be missing an obvious setting? TX7T's prefix isn't getting resolved in spot collector, but DXView resolves the prefix as FO-M and Marquesas Islands. Operator error?

+ TX is one of several ambiguous prefixes, meaning that the station's DXCC entity cannot be determined. E5, TM, and TO are other examples. DXView provides an "override" mechanism to deal with stations using ambiguous prefixes. See

<https://www.dxlabsuite.com/dxlabwiki/CreateEntityOverride>

73,

Dave, AA6YQ

Michael Harang
 

Max,

An override should be added to DXView. In DXView, open the Config window and go to the Overrides tab.

Mike
K5MMH

Jim - KR9U
 

Don't forget that you can use the *club Log* button to populate the override list for you.

Jim - KR9U

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: Monday, November 11, 2019 2:08 PM
To: DXLab@groups.io
Subject: Re: [DXLab] TX7T Prefix unknown in Spot Collector but DXView is fine

+ AA6QY comments below

I must be missing an obvious setting? TX7T's prefix isn't getting resolved in spot collector, but DXView resolves the prefix as FO-M and Marquesas Islands. Operator error?

+ TX is one of several ambiguous prefixes, meaning that the station's DXCC entity cannot be determined. E5, TM, and TO are other examples. DXView provides an "override" mechanism to deal with stations using ambiguous prefixes. See

<https://www.dxlabsuite.com/dxlabwiki/CreateEntityOverride>

73,

Dave, AA6YQ

iain macdonnell - N6ML
 

On Mon, Nov 11, 2019 at 11:08 AM Dave AA6YQ <@AA6YQ> wrote:

+ AA6QY comments below

I must be missing an obvious setting? TX7T's prefix isn't getting resolved in spot collector, but DXView resolves the prefix as FO-M and Marquesas Islands. Operator error?

+ TX is one of several ambiguous prefixes, meaning that the station's DXCC entity cannot be determined. E5, TM, and TO are other examples. DXView provides an "override" mechanism to deal with stations using ambiguous prefixes. See

<https://www.dxlabsuite.com/dxlabwiki/CreateEntityOverride>
A good segue to something I had been meaning to look into... When TX7T
showed up, I used the "Club Log" method to update my overrides
database. TX7T appeared as expected. I later noticed that spot
database entries for TX7T have no Azimuth value. I also notice that if
I look up TX7T in DXView, the latitude, longitude and grid fields are
blank. The location columns are populated in the override database. Am
I missing something?

73,

~iain / N6ML

Max NG7M
 

Thanks for the responses... yep, downloading the ClubLog overrides did the trick.  I can confirm that the Azimuth shows up in DXView, but not in Spot Collector.  Thanks again for the quick responses.  Max NG7M

Dave AA6YQ
 

* More AA6YQ comments below

I must be missing an obvious setting? TX7T's prefix isn't getting resolved in spot collector, but DXView resolves the prefix as FO-M and Marquesas Islands. Operator error?

+ TX is one of several ambiguous prefixes, meaning that the station's
+ DXCC entity cannot be determined. E5, TM, and TO are other examples.
+ DXView provides an "override" mechanism to deal with stations using
+ ambiguous prefixes. See

<https://www.dxlabsuite.com/dxlabwiki/CreateEntityOverride>
A good segue to something I had been meaning to look into... When TX7T showed up, I used the "Club Log" method to update my overrides database. TX7T appeared as expected. I later noticed that spot database entries for TX7T have no Azimuth value. I also notice that if I look up TX7T in DXView, the latitude, longitude and grid fields are blank. The location columns are populated in the override database. Am I missing something?

* The Override's Location field contains a text string that appears in the Location box on DXView's Main window.

* Does your TX7T override specify a gridsquare in its Grid1 field?

73,

Dave, AA6YQ

Dave AA6YQ
 

+ AA6YQ comments below

Thanks for the responses... yep, downloading the ClubLog overrides did the trick. I can confirm that the Azimuth shows up in DXView, but not in Spot Collector.

+ If you want existing Spot Database Entries to be updated after adding or modifying an override, click the Recompute button on the "Spot Database" tab of SpotCollector's Configuration window.

+ I've appended a new section with this information to

<https://www.dxlabsuite.com/dxlabwiki/CreateEntityOverride>


73,

Dave, AA6YQ

Dave AA6YQ
 

The offender has been placed on "moderated" status.

73,

Dave, AA6YQ

iain macdonnell - N6ML
 

On Mon, Nov 11, 2019 at 1:09 PM Dave AA6YQ <@AA6YQ> wrote:

* More AA6YQ comments below

I must be missing an obvious setting? TX7T's prefix isn't getting resolved in spot collector, but DXView resolves the prefix as FO-M and Marquesas Islands. Operator error?

+ TX is one of several ambiguous prefixes, meaning that the station's
+ DXCC entity cannot be determined. E5, TM, and TO are other examples.
+ DXView provides an "override" mechanism to deal with stations using
+ ambiguous prefixes. See

<https://www.dxlabsuite.com/dxlabwiki/CreateEntityOverride>
A good segue to something I had been meaning to look into... When TX7T showed up, I used the "Club Log" method to update my overrides database. TX7T appeared as expected. I later noticed that spot database entries for TX7T have no Azimuth value. I also notice that if I look up TX7T in DXView, the latitude, longitude and grid fields are blank. The location columns are populated in the override database. Am I missing something?

* The Override's Location field contains a text string that appears in the Location box on DXView's Main window.
By "location columns", I meant those referred to in this statement:

"To populate the Override List from active and non-redundant Club Log
exceptions, and populate each generated Override's CQ, ITU, IOTA,
Continent, and Location columns based on its entity, depress the CTRL
key while clicking the Club Log button."

* Does your TX7T override specify a gridsquare in its Grid1 field?
It does not.

I did try Control-Click on the "Club Log" button, but it seems to have
made no difference.

73,

~iain / N6ML

Dave AA6YQ
 

# More AA6YQ comments below

On Mon, Nov 11, 2019 at 1:09 PM Dave AA6YQ <@AA6YQ> wrote:

* More AA6YQ comments below

I must be missing an obvious setting? TX7T's prefix isn't getting resolved in spot collector, but DXView resolves the prefix as FO-M and Marquesas Islands. Operator error?

+ TX is one of several ambiguous prefixes, meaning that the
+ station's DXCC entity cannot be determined. E5, TM, and TO are other examples.
+ DXView provides an "override" mechanism to deal with stations
+ using ambiguous prefixes. See

<https://www.dxlabsuite.com/dxlabwiki/CreateEntityOverride>
A good segue to something I had been meaning to look into... When TX7T showed up, I used the "Club Log" method to update my overrides database. TX7T appeared as expected. I later noticed that spot database entries for TX7T have no Azimuth value. I also notice that if I look up TX7T in DXView, the latitude, longitude and grid fields are blank. The location columns are populated in the override database. Am I missing something?

* The Override's Location field contains a text string that appears in the Location box on DXView's Main window.
By "location columns", I meant those referred to in this statement:

"To populate the Override List from active and non-redundant Club Log exceptions, and populate each generated Override's CQ, ITU, IOTA, Continent, and Location columns based on its entity, depress the CTRL key while clicking the Club Log button."

* Does your TX7T override specify a gridsquare in its Grid1 field?
It does not.

# That's why there's no latitude, longitude, gridsquare, or azimuth shown in DXView's Main window when you lookup TX7T, and why there's no azimuth in Spot Database Entries created after the TX7T override was defined.

I did try Control-Click on the "Club Log" button, but it seems to have made no difference.

# My TX7T override in DXView was created by clicking the "Club Log" button without depressing the CTRL key. This override specifies the Entity, CQ zone, Continent, Start Date, and End Date for TX7T. When on DXView's Configuration window's Overrides tab I select the TX7T override and click the Update button, the override's IOTA tag, ITU zone, Location, and TimeZone items are populated. Had I depressed the CTRL key while clicking the "Club Log" buttons, the TX7T override would have included the IOTA tag, ITU zone, Location, and TimeZone items without me having to click the Update button.

# It is not possible for DXView to accurately populate an override's Grid1 field from its callsign and CQ or ITU zone information; if the override downloaded from ClubLog or BigCity does not specify a gridsquare (or a latitude and longitude), you must manually specify the override's grid1 field and then click the Save button. Then direct SpotCollector to "Recompute" so that the Azimuth field of existing TX7T Spot Database Entries will be updated.

73,

Dave, AA6YQ

iain macdonnell - N6ML
 

On Mon, Nov 11, 2019 at 2:19 PM Dave AA6YQ <@AA6YQ> wrote:

# More AA6YQ comments below

On Mon, Nov 11, 2019 at 1:09 PM Dave AA6YQ <@AA6YQ> wrote:

* More AA6YQ comments below

I must be missing an obvious setting? TX7T's prefix isn't getting resolved in spot collector, but DXView resolves the prefix as FO-M and Marquesas Islands. Operator error?

+ TX is one of several ambiguous prefixes, meaning that the
+ station's DXCC entity cannot be determined. E5, TM, and TO are other examples.
+ DXView provides an "override" mechanism to deal with stations
+ using ambiguous prefixes. See

<https://www.dxlabsuite.com/dxlabwiki/CreateEntityOverride>
A good segue to something I had been meaning to look into... When TX7T showed up, I used the "Club Log" method to update my overrides database. TX7T appeared as expected. I later noticed that spot database entries for TX7T have no Azimuth value. I also notice that if I look up TX7T in DXView, the latitude, longitude and grid fields are blank. The location columns are populated in the override database. Am I missing something?

* The Override's Location field contains a text string that appears in the Location box on DXView's Main window.
By "location columns", I meant those referred to in this statement:

"To populate the Override List from active and non-redundant Club Log exceptions, and populate each generated Override's CQ, ITU, IOTA, Continent, and Location columns based on its entity, depress the CTRL key while clicking the Club Log button."

* Does your TX7T override specify a gridsquare in its Grid1 field?
It does not.

# That's why there's no latitude, longitude, gridsquare, or azimuth shown in DXView's Main window when you lookup TX7T, and why there's no azimuth in Spot Database Entries created after the TX7T override was defined.

I did try Control-Click on the "Club Log" button, but it seems to have made no difference.

# My TX7T override in DXView was created by clicking the "Club Log" button without depressing the CTRL key. This override specifies the Entity, CQ zone, Continent, Start Date, and End Date for TX7T. When on DXView's Configuration window's Overrides tab I select the TX7T override and click the Update button, the override's IOTA tag, ITU zone, Location, and TimeZone items are populated. Had I depressed the CTRL key while clicking the "Club Log" buttons, the TX7T override would have included the IOTA tag, ITU zone, Location, and TimeZone items without me having to click the Update button.

# It is not possible for DXView to accurately populate an override's Grid1 field from its callsign and CQ or ITU zone information; if the override downloaded from ClubLog or BigCity does not specify a gridsquare (or a latitude and longitude), you must manually specify the override's grid1 field and then click the Save button. Then direct SpotCollector to "Recompute" so that the Azimuth field of existing TX7T Spot Database Entries will be updated.
Shouldn't it ("it" being SpotCollector. I suppose) derive the azimuth
from the entity when there is no grid in the override? DXView is able
to come up with short and long path headings for TX7T - why can't the
method used to determine those be used when creating spot database
entries?

73,

~iain / N6ML

Dave AA6YQ
 

@ even more AA6YQ comments below

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of iain macdonnell - N6ML
Sent: Monday, November 11, 2019 6:11 PM
To: DXLab@groups.io
Subject: Re: [DXLab] TX7T Prefix unknown in Spot Collector but DXView is fine

On Mon, Nov 11, 2019 at 2:19 PM Dave AA6YQ <@AA6YQ> wrote:

# More AA6YQ comments below

On Mon, Nov 11, 2019 at 1:09 PM Dave AA6YQ <@AA6YQ> wrote:

* More AA6YQ comments below

I must be missing an obvious setting? TX7T's prefix isn't getting resolved in spot collector, but DXView resolves the prefix as FO-M and Marquesas Islands. Operator error?

+ TX is one of several ambiguous prefixes, meaning that the
+ station's DXCC entity cannot be determined. E5, TM, and TO are other examples.
+ DXView provides an "override" mechanism to deal with stations
+ using ambiguous prefixes. See

<https://www.dxlabsuite.com/dxlabwiki/CreateEntityOverride>
A good segue to something I had been meaning to look into... When TX7T showed up, I used the "Club Log" method to update my overrides database. TX7T appeared as expected. I later noticed that spot database entries for TX7T have no Azimuth value. I also notice that if I look up TX7T in DXView, the latitude, longitude and grid fields are blank. The location columns are populated in the override database. Am I missing something?

* The Override's Location field contains a text string that appears in the Location box on DXView's Main window.
By "location columns", I meant those referred to in this statement:

"To populate the Override List from active and non-redundant Club Log exceptions, and populate each generated Override's CQ, ITU, IOTA, Continent, and Location columns based on its entity, depress the CTRL key while clicking the Club Log button."

* Does your TX7T override specify a gridsquare in its Grid1 field?
It does not.

# That's why there's no latitude, longitude, gridsquare, or azimuth shown in DXView's Main window when you lookup TX7T, and why there's no azimuth in Spot Database Entries created after the TX7T override was defined.

I did try Control-Click on the "Club Log" button, but it seems to have made no difference.

# My TX7T override in DXView was created by clicking the "Club Log" button without depressing the CTRL key. This override specifies the Entity, CQ zone, Continent, Start Date, and End Date for TX7T. When on DXView's Configuration window's Overrides tab I select the TX7T override and click the Update button, the override's IOTA tag, ITU zone, Location, and TimeZone items are populated. Had I depressed the CTRL key while clicking the "Club Log" buttons, the TX7T override would have included the IOTA tag, ITU zone, Location, and TimeZone items without me having to click the Update button.

# It is not possible for DXView to accurately populate an override's Grid1 field from its callsign and CQ or ITU zone information; if the override downloaded from ClubLog or BigCity does not specify a gridsquare (or a latitude and longitude), you must manually specify the override's grid1 field and then click the Save button. Then direct SpotCollector to "Recompute" so that the Azimuth field of existing TX7T Spot Database Entries will be updated.
Shouldn't it ("it" being SpotCollector. I suppose) derive the azimuth from the entity when there is no grid in the override? DXView is able to come up with short and long path headings for TX7T - why can't the method used to determine those be used when creating spot database entries?

@ The existence of an override for a callsign means that the "normal" means of determining location information for that callsign are unusable. If you define or download an override for a station, only the information specified in that override is considered accurate.

73,

Dave, AA6YQ

iain macdonnell - N6ML
 

On Mon, Nov 11, 2019 at 4:12 PM Dave AA6YQ <@AA6YQ> wrote:

@ even more AA6YQ comments below

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of iain macdonnell - N6ML
Sent: Monday, November 11, 2019 6:11 PM
To: DXLab@groups.io
Subject: Re: [DXLab] TX7T Prefix unknown in Spot Collector but DXView is fine

On Mon, Nov 11, 2019 at 2:19 PM Dave AA6YQ <@AA6YQ> wrote:

# More AA6YQ comments below

On Mon, Nov 11, 2019 at 1:09 PM Dave AA6YQ <@AA6YQ> wrote:

* More AA6YQ comments below

I must be missing an obvious setting? TX7T's prefix isn't getting resolved in spot collector, but DXView resolves the prefix as FO-M and Marquesas Islands. Operator error?

+ TX is one of several ambiguous prefixes, meaning that the
+ station's DXCC entity cannot be determined. E5, TM, and TO are other examples.
+ DXView provides an "override" mechanism to deal with stations
+ using ambiguous prefixes. See

<https://www.dxlabsuite.com/dxlabwiki/CreateEntityOverride>
A good segue to something I had been meaning to look into... When TX7T showed up, I used the "Club Log" method to update my overrides database. TX7T appeared as expected. I later noticed that spot database entries for TX7T have no Azimuth value. I also notice that if I look up TX7T in DXView, the latitude, longitude and grid fields are blank. The location columns are populated in the override database. Am I missing something?

* The Override's Location field contains a text string that appears in the Location box on DXView's Main window.
By "location columns", I meant those referred to in this statement:

"To populate the Override List from active and non-redundant Club Log exceptions, and populate each generated Override's CQ, ITU, IOTA, Continent, and Location columns based on its entity, depress the CTRL key while clicking the Club Log button."

* Does your TX7T override specify a gridsquare in its Grid1 field?
It does not.

# That's why there's no latitude, longitude, gridsquare, or azimuth shown in DXView's Main window when you lookup TX7T, and why there's no azimuth in Spot Database Entries created after the TX7T override was defined.

I did try Control-Click on the "Club Log" button, but it seems to have made no difference.

# My TX7T override in DXView was created by clicking the "Club Log" button without depressing the CTRL key. This override specifies the Entity, CQ zone, Continent, Start Date, and End Date for TX7T. When on DXView's Configuration window's Overrides tab I select the TX7T override and click the Update button, the override's IOTA tag, ITU zone, Location, and TimeZone items are populated. Had I depressed the CTRL key while clicking the "Club Log" buttons, the TX7T override would have included the IOTA tag, ITU zone, Location, and TimeZone items without me having to click the Update button.

# It is not possible for DXView to accurately populate an override's Grid1 field from its callsign and CQ or ITU zone information; if the override downloaded from ClubLog or BigCity does not specify a gridsquare (or a latitude and longitude), you must manually specify the override's grid1 field and then click the Save button. Then direct SpotCollector to "Recompute" so that the Azimuth field of existing TX7T Spot Database Entries will be updated.
Shouldn't it ("it" being SpotCollector. I suppose) derive the azimuth from the entity when there is no grid in the override? DXView is able to come up with short and long path headings for TX7T - why can't the method used to determine those be used when creating spot database entries?

@ The existence of an override for a callsign means that the "normal" means of determining location information for that callsign are unusable. If you define or download an override for a station, only the information specified in that override is considered accurate.
So if we don't know the grid square for a DXpedition that requires an
override, in order to get reasonable Azimuth in spot database entries,
we're forced to guess what the grid square might be, and manually
enter our guess? This could result in incorrect progress for the grid
square that we guessed.

I don't understand why it's reasonable to derive the location from the
DXCC database when there's no override, but not reasonable to do what
when there's an override that specifies a different entity but does
not specify a grid square.

Also, why is it reasonable to DXView to derive the headings that way,
but not reasonable for SpotCollector to do it?

73,

~iain / N6ML

Chad Kurszewski
 

On Mon, Nov 11, 2019 at 04:40 PM, iain macdonnell - N6ML wrote:
I don't understand why it's reasonable to derive the location from the
DXCC database when there's no override, but not reasonable to do what
when there's an override that specifies a different entity but does
not specify a grid square.

Also, why is it reasonable to DXView to derive the headings that way,
but not reasonable for SpotCollector to do it?
Could we suggest that it is reasonable for DXView, and propose that SpotCollector work similarly?  (I'd really prefer not to have DXView work like SC in this case.)

Respectfully,
Chad WE9V

Dave AA6YQ
 

% more AA6YQ comments below

snip<
# It is not possible for DXView to accurately populate an override's Grid1 field from its callsign and CQ or ITU zone information; if the override downloaded from ClubLog or BigCity does not specify a gridsquare (or a latitude and longitude), you must manually specify the override's grid1 field and then click the Save button. Then direct SpotCollector to "Recompute" so that the Azimuth field of existing TX7T Spot Database Entries will be updated.
Shouldn't it ("it" being SpotCollector. I suppose) derive the azimuth from the entity when there is no grid in the override? DXView is able to come up with short and long path headings for TX7T - why can't the method used to determine those be used when creating spot database entries?

@ The existence of an override for a callsign means that the "normal" means of determining location information for that callsign are unusable. If you define or download an override for a station, only the information specified in that override is considered accurate.
So if we don't know the grid square for a DXpedition that requires an override, in order to get reasonable Azimuth in spot database entries, we're forced to guess what the grid square might be, and manually enter our guess? This could result in incorrect progress for the grid square that we guessed.

% Most DXPeditions publish location information beforehand.

I don't understand why it's reasonable to derive the location from the DXCC database when there's no override, but not reasonable to do what when there's an override that specifies a different entity but does not specify a grid square.

% The existence of an override means "callsign does not play by the usual rules". The callsign's call area and suffix cannot be relied upon to determine the location within a medium-size or large-size entity.

Also, why is it reasonable to DXView to derive the headings that way, but not reasonable for SpotCollector to do it?

% DXView's and SpotCollector's behavior is identical: if no override is defined for a callsign, they determine the location by analyzing that callsign - its prefix, its call area, and its suffix - and by consulting the DXCC and USAP databases. If an override is defined, DXView and SpotCollector use the location information specified in that override; if the override doesn't specify a grid square, neither application attempts to guess the location within the specified entity.

% There aren't that many DXPeditions using ambiguous callsigns that expecting users to specify a grid square when defining (or after downloading) an override should be problematic.

73,

Dave, AA6YQ

Dave AA6YQ
 

+ AA6YQ comments below

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Chad Kurszewski
Sent: Monday, November 11, 2019 7:54 PM
To: DXLab@groups.io
Subject: Re: [DXLab] TX7T Prefix unknown in Spot Collector but DXView is fine

On Mon, Nov 11, 2019 at 04:40 PM, iain macdonnell - N6ML wrote:


I don't understand why it's reasonable to derive the location from the
DXCC database when there's no override, but not reasonable to do what
when there's an override that specifies a different entity but does
not specify a grid square.

Also, why is it reasonable to DXView to derive the headings that way,
but not reasonable for SpotCollector to do it?

Could we suggest that it is reasonable for DXView, and propose that SpotCollector work similarly? (I'd really prefer not to have DXView work like SC in this case.)

+ Based on a test run earlier today, I thought that DXView does not display an azimuth for a callsign with an override that does not specify a grid square, but checking it again just now leads to a different conclusion. That's a defect in DXView that I will correct.

73,

Dave, AA6YQ

iain macdonnell - N6ML
 

On Mon, Nov 11, 2019 at 5:06 PM Dave AA6YQ <@AA6YQ> wrote:

% more AA6YQ comments below

snip<
# It is not possible for DXView to accurately populate an override's Grid1 field from its callsign and CQ or ITU zone information; if the override downloaded from ClubLog or BigCity does not specify a gridsquare (or a latitude and longitude), you must manually specify the override's grid1 field and then click the Save button. Then direct SpotCollector to "Recompute" so that the Azimuth field of existing TX7T Spot Database Entries will be updated.
Shouldn't it ("it" being SpotCollector. I suppose) derive the azimuth from the entity when there is no grid in the override? DXView is able to come up with short and long path headings for TX7T - why can't the method used to determine those be used when creating spot database entries?

@ The existence of an override for a callsign means that the "normal" means of determining location information for that callsign are unusable. If you define or download an override for a station, only the information specified in that override is considered accurate.
So if we don't know the grid square for a DXpedition that requires an override, in order to get reasonable Azimuth in spot database entries, we're forced to guess what the grid square might be, and manually enter our guess? This could result in incorrect progress for the grid square that we guessed.

% Most DXPeditions publish location information beforehand.

I don't understand why it's reasonable to derive the location from the DXCC database when there's no override, but not reasonable to do what when there's an override that specifies a different entity but does not specify a grid square.

% The existence of an override means "callsign does not play by the usual rules". The callsign's call area and suffix cannot be relied upon to determine the location within a medium-size or large-size entity.
I see it a bit differently. To me, an override means "the DXCC
database gets this callsign wrong - here's the corrected information
that we have available". Deriving the azimuth from the DXCC entity is
not a datum that is being overridden - rather it's a rule/mechanism
that seems to me to be applicable whether or not an override is in
play (assuming that the override does not specify a location, of
course). It's not like you're inappropriately using data from the DXCC
database for the entity that the callsign would have been associated
with in the absence of an override, rather it's using the new
information (which DXCC entity the callsign is really in) when
executing the usual rules to determine azimuth.

This is just my opinion, of course... but I think it dilutes the value
of getting overrides from Club Log if we have to go in and manually
edit them to make them fully functional.

Could you describe a scenario where it would be bad to derive the
azimuth from the entity specified in an override (without specific
location information) ?


Also, why is it reasonable to DXView to derive the headings that way, but not reasonable for SpotCollector to do it?

% DXView's and SpotCollector's behavior is identical: if no override is defined for a callsign, they determine the location by analyzing that callsign - its prefix, its call area, and its suffix - and by consulting the DXCC and USAP databases. If an override is defined, DXView and SpotCollector use the location information specified in that override; if the override doesn't specify a grid square, neither application attempts to guess the location within the specified entity.

% There aren't that many DXPeditions using ambiguous callsigns that expecting users to specify a grid square when defining (or after downloading) an override should be problematic.
There are 1216 entries in my overrides database. That seems more than
"not that many". Very few of them have grid squares.

73,

~iain / N6ML

Dave AA6YQ
 

+ AA6YQ comments below

This is just my opinion, of course... but I think it dilutes the value of getting overrides from Club Log if we have to go in and manually edit them to make them fully functional.

+ Yes, it would be nice if the information provided by Club Log and BigCTY include grid squares or latitudes and longitudes.


Could you describe a scenario where it would be bad to derive the azimuth from the entity specified in an override (without specific location information) ?

+ Consider the station BY0DX, whose home QTH location is indicated by the 0D portion of the callsign to be in XinJiang Uyghur province in western China, CQ zone 23.

+ An override for BY0DX downloaded from Club Log indicates operation from CQ Zone 24 in eastern or southern China for the next 30 days. How should DXView determine the location of BY0DX within CQ zone 24 so that an azimuth from my QTH can be computed?

+ From my QTH, the short-path azimuth to the western-most section of CQ zone 24 is 7; to the eastern-most section of CQ zone 24, the short-path azimuth is 343. That's a range of 24 degrees.


Also, why is it reasonable to DXView to derive the headings that way, but not reasonable for SpotCollector to do it?

% DXView's and SpotCollector's behavior is identical: if no override is defined for a callsign, they determine the location by analyzing that callsign - its prefix, its call area, and its suffix - and by consulting the DXCC and USAP databases. If an override is defined, DXView and SpotCollector use the location information specified in that override; if the override doesn't specify a grid square, neither application attempts to guess the location within the specified entity.

% There aren't that many DXPeditions using ambiguous callsigns that expecting users to specify a grid square when defining (or after downloading) an override should be problematic.
There are 1216 entries in my overrides database. That seems more than "not that many". Very few of them have grid squares.

+ There are not overrides for 1216 DXPeditions in your override database.

73,

Dave, AA6YQ

iain macdonnell - N6ML
 

On Mon, Nov 11, 2019 at 11:06 PM Dave AA6YQ <@AA6YQ> wrote:

+ AA6YQ comments below

This is just my opinion, of course... but I think it dilutes the value of getting overrides from Club Log if we have to go in and manually edit them to make them fully functional.

+ Yes, it would be nice if the information provided by Club Log and BigCTY include grid squares or latitudes and longitudes.


Could you describe a scenario where it would be bad to derive the azimuth from the entity specified in an override (without specific location information) ?

+ Consider the station BY0DX, whose home QTH location is indicated by the 0D portion of the callsign to be in XinJiang Uyghur province in western China, CQ zone 23.

+ An override for BY0DX downloaded from Club Log indicates operation from CQ Zone 24 in eastern or southern China for the next 30 days. How should DXView determine the location of BY0DX within CQ zone 24 so that an azimuth from my QTH can be computed?

+ From my QTH, the short-path azimuth to the western-most section of CQ zone 24 is 7; to the eastern-most section of CQ zone 24, the short-path azimuth is 343. That's a range of 24 degrees.
I would have thought that it would use the center of the DXCC entity
(BY). That would generally be "good enough" for (initial) antenna
pointing purposes. It's not like you're going to log inaccurate award
progress as a result of any inaccuracy ... unless there's a "worked
all azimuths" award that I've not heard of? :)


Also, why is it reasonable to DXView to derive the headings that way, but not reasonable for SpotCollector to do it?

% DXView's and SpotCollector's behavior is identical: if no override is defined for a callsign, they determine the location by analyzing that callsign - its prefix, its call area, and its suffix - and by consulting the DXCC and USAP databases. If an override is defined, DXView and SpotCollector use the location information specified in that override; if the override doesn't specify a grid square, neither application attempts to guess the location within the specified entity.

% There aren't that many DXPeditions using ambiguous callsigns that expecting users to specify a grid square when defining (or after downloading) an override should be problematic.
There are 1216 entries in my overrides database. That seems more than "not that many". Very few of them have grid squares.

+ There are not overrides for 1216 DXPeditions in your override database.
There are 1216 callsigns that could potentially be spotted. Doesn't
the problem pertain to all of them (that don't have grids) ?

73,

~iain / N6ML