Topics

DXView's ""Populate override content from entity"

Björn Ekelund, SM7IUN
 

I love the possibility to keep an up-to-date database for exceptions to the "standard" callsign rules 
in DXView but recently I have found a limitation that I find a bit frustrating.

If I, for instance, enter VP8PJ in the callsign box and hit ENTER, the grid box ends up empty.
The distance (13931km) shows, however. Since the grid and geographical coordinates are 
undefined, clicking the Sun button yields an empty array. 

When I open the Config's Override List panel and right-click the VP8PJ entry and chose 
"Populate override content from entity" I get the message "all override components are already populated".
No grid. 

Is there a reason to not populate the grid with the entity's default locator?
If I simply select VP8-O from the drop down menu, the grid box is populated.

Björn SM7IUN


Joe Subich, W4TV
 

Is there a reason to not populate the grid with the entity's default
locator?
There is no "default locator" for any entity other than HC1, 1A, 3A
which are smaller than a four character grid.

If I simply select VP8-O from the drop down menu, the grid box is
populated.
The grid that is populated when selecting any entity is the one that
either Dave or I selected as a reference (typically geographical center
with some modifications to "center of largest city") when creating or
updating the DXCC database.

73,

... Joe, W4TV


On 2020-02-26 11:35 AM, Björn Ekelund, SM7IUN wrote:
I love the possibility to keep an up-to-date database for exceptions to the
"standard" callsign rules
in DXView but recently I have found a limitation that I find a bit
frustrating.
If I, for instance, enter VP8PJ in the callsign box and hit ENTER, the grid
box ends up empty.
The distance (13931km) shows, however. Since the grid and geographical
coordinates are
undefined, clicking the Sun button yields an empty array.
When I open the Config's Override List panel and right-click the VP8PJ
entry and chose
"Populate override content from entity" I get the message "all override
components are already populated".
No grid.
Is there a reason to not populate the grid with the entity's default
locator?
If I simply select VP8-O from the drop down menu, the grid box is populated.
Björn SM7IUN

Dave AA6YQ
 

+ AA6YQ comments below

I love the possibility to keep an up-to-date database for exceptions to the "standard" callsign rules in DXView but recently I have found a limitation that I find a bit frustrating.

If I, for instance, enter VP8PJ in the callsign box and hit ENTER, the grid box ends up empty.
The distance (13931km) shows, however. Since the grid and geographical coordinates are undefined, clicking the Sun button yields an empty array.

When I open the Config's Override List panel and right-click the VP8PJ entry and chose "Populate override content from entity" I get the message "all override components are already populated".
No grid.

Is there a reason to not populate the grid with the entity's default locator?

+ Yes: DXLab treats the grid square specified in an override as accurate enough to count for awards that involve pursuing grid squares, like VUCC. As Joe W4TV explained, the grid square produced by a DXCC Database lookup does not meet that accuracy criterion.

If I simply select VP8-O from the drop down menu, the grid box is populated.

+ I assume that you're referring to the DXCC prefix selector on DXView's Main window. Using the grid square produced by a DXCC Database lookup is accurate enough for the purpose of displaying a great circle path and computing a beam heading.

73,

Dave, AA6YQ

Björn Ekelund, SM7IUN
 

Although I understand what you are saying I struggle with the logic.

If I enter a random Swedish call in DXView, I get the grid locator of central Stockholm which of course is 
very wrong for e.g. my call. But close enough for all practical purposes (beam heading, sun info, spot plot) 
except of course VUCC. I believe everyone prefers this before getting an empty grid.

If I enter a callsign which is in the override list and the override lacks a grid. I get an empty grid.
What is wrong with using the DXCC database lookup grid when the override lacks a grid, just as 
with random calls? Why is this a bad idea? 

If random calls actually generate the default grid for its DXCC entity, I assume SpotCollector can tell the 
difference between reliable and unreliable grids?

Björn SM7IUN

Den ons 26 feb. 2020 kl 21:17 skrev Dave AA6YQ <aa6yq@...>:

+ AA6YQ comments below

I love the possibility to keep an up-to-date database for exceptions to the "standard" callsign rules in DXView but recently I have found a limitation that I find a bit frustrating.

If I, for instance, enter VP8PJ in the callsign box and hit ENTER, the grid box ends up empty.
The distance (13931km) shows, however. Since the grid and geographical coordinates are undefined, clicking the Sun button yields an empty array.

When I open the Config's Override List panel and right-click the VP8PJ entry and chose "Populate override content from entity" I get the message "all override components are already populated".
No grid.

Is there a reason to not populate the grid with the entity's default locator?

+ Yes: DXLab treats the grid square specified in an override as accurate enough to count for awards that involve pursuing grid squares, like VUCC. As Joe W4TV explained, the grid square produced by a DXCC Database lookup does not meet that accuracy criterion.

If I simply select VP8-O from the drop down menu, the grid box is populated.

+ I assume that you're referring to the DXCC prefix selector on DXView's Main window. Using the grid square produced by a DXCC Database lookup is accurate enough for the purpose of displaying a great circle path and computing a beam heading.

        73,

               Dave, AA6YQ





Björn Ekelund, SM7IUN
 

Joe,

I'm not so well versed in the CTY terminology. With the "default grid" I mean the reference 
grid that pops up when you enter a random call in DXView. All DXCC entities seem to have at least one. 

Björn SM7IUN

Den ons 26 feb. 2020 kl 20:06 skrev Joe Subich, W4TV <lists@...>:


 > Is there a reason to not populate the grid with the entity's default
 > locator?

There is no "default locator" for any entity other than HC1, 1A, 3A
which are smaller than a four character grid.

> If I simply select VP8-O from the drop down menu, the grid box is
> populated.

The grid that is populated when selecting any entity is the one that
either Dave or I selected as a reference (typically geographical center
with some modifications to "center of largest city") when creating or
updating the DXCC database.

73,

    ... Joe, W4TV


On 2020-02-26 11:35 AM, Björn Ekelund, SM7IUN wrote:
> I love the possibility to keep an up-to-date database for exceptions to the
> "standard" callsign rules
> in DXView but recently I have found a limitation that I find a bit
> frustrating.
>
> If I, for instance, enter VP8PJ in the callsign box and hit ENTER, the grid
> box ends up empty.
> The distance (13931km) shows, however. Since the grid and geographical
> coordinates are
> undefined, clicking the Sun button yields an empty array.
>
> When I open the Config's Override List panel and right-click the VP8PJ
> entry and chose
> "Populate override content from entity" I get the message "all override
> components are already populated".
> No grid.
>
> Is there a reason to not populate the grid with the entity's default
> locator?
> If I simply select VP8-O from the drop down menu, the grid box is populated.
>
> Björn SM7IUN
>





Joe Subich, W4TV
 

On 2020-02-26 6:52 PM, Björn Ekelund, SM7IUN wrote:

I'm not so well versed in the CTY terminology.
There are no grids in AD1C's CTY files and DXKeeper does not use
them unless one chooses to import the Big CTY file to populate the
override list.

With the "default grid" I mean the reference grid that pops up when
you enter a random call in DXView.
AA6YQ and/or I supplied a reference grid for each list entry (DXCC
entity, state, oblast, certain call areas, etc,.) specifically for
DXView to use in calculating *BEAM HEADINGS* and nothing else.

If one is entering an override, the "reference" in the DXCC database
is obviously invalid. It logically follows that anyone who creates
an override is expected to provide their own grid square information
along with any other information (e.g., IOTA reference) that is
important to them.

73,

... Joe, W4TV


On 2020-02-26 6:52 PM, Björn Ekelund, SM7IUN wrote:
Joe,
I'm not so well versed in the CTY terminology. With the "default grid" I
mean the reference
grid that pops up when you enter a random call in DXView. All DXCC entities
seem to have at least one.
Björn SM7IUN
Den ons 26 feb. 2020 kl 20:06 skrev Joe Subich, W4TV <lists@...>:


> Is there a reason to not populate the grid with the entity's default
> locator?

There is no "default locator" for any entity other than HC1, 1A, 3A
which are smaller than a four character grid.

If I simply select VP8-O from the drop down menu, the grid box is
populated.
The grid that is populated when selecting any entity is the one that
either Dave or I selected as a reference (typically geographical center
with some modifications to "center of largest city") when creating or
updating the DXCC database.

73,

... Joe, W4TV


On 2020-02-26 11:35 AM, Björn Ekelund, SM7IUN wrote:
I love the possibility to keep an up-to-date database for exceptions to
the
"standard" callsign rules
in DXView but recently I have found a limitation that I find a bit
frustrating.

If I, for instance, enter VP8PJ in the callsign box and hit ENTER, the
grid
box ends up empty.
The distance (13931km) shows, however. Since the grid and geographical
coordinates are
undefined, clicking the Sun button yields an empty array.

When I open the Config's Override List panel and right-click the VP8PJ
entry and chose
"Populate override content from entity" I get the message "all override
components are already populated".
No grid.

Is there a reason to not populate the grid with the entity's default
locator?
If I simply select VP8-O from the drop down menu, the grid box is
populated.

Björn SM7IUN

Dave AA6YQ
 

+ AA6YQ comments below

Although I understand what you are saying I struggle with the logic.

If I enter a random Swedish call in DXView, I get the grid locator of central Stockholm which of course is very wrong for e.g. my call. But close enough for all practical purposes (beam heading, sun info, spot plot) except of course VUCC. I believe everyone prefers this before getting an empty grid.

+ Correct.

If I enter a callsign which is in the override list and the override lacks a grid. I get an empty grid.
What is wrong with using the DXCC database lookup grid when the override lacks a grid, just as with random calls? Why is this a bad idea?

+ The long-standing description of an override's Grid field, dating back to the days of 16 fixed overrides, is

"the Maidenhead Grid Square from which the station is operating"

<https://www.dxlabsuite.com/dxview/Help/Configuration.htm#Entity%20Overides>


+ Each Spot Database Entry contains a DXGridSource field that contains one of the following values

L - the gridsquare associated with the Latitude and Longitude specified in the Operator location panel
O - the gridsquare specified by an Override
S - a gridsquare extracted from a spot note or information appended to the spot by a Spot Source
U - the gridsquare determined by a USAP Database lookup
D - the gridsquare determined by a DXCC Database lookup

<https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm#DXGridSource>

+ Originally, a Spot Database Entry's "Grid Square" field was only considered valid for VUCC if the Entry's DXGridSource contained the letters L, O, or S.

+ At some point in the past, discussion here led me provide user control of this by adding the "Grid Sources for VUCC" panel to the General tab of SpotCollector's Configuration window. This panel provides you with the ability to determine whether Spot Database Entries whose DXGridSource fields contain O, S, or U should be considered reliable enough for VUCC need determination.

+ Note that these options are "all or nothing": if you uncheck the L box in the "Grid Sources for VUCC" panel because some of your overrides specify inaccurate grid squares, then all grid squares specified in Overrides will be ignored for VUCC need determination.

+ If you're pursuing VUCC, then each override of a station QRV on VHF or UHF should specify an accurate grid square so you can keep the "Grid Sources for VUCC" panel's Override box checked.

+ If you're not pursuing VUCC then you can uncheck the "Grid Sources for VUCC" panel's Override box; in this case, there's no reason to not populate an Override's grid square with an approximate location.

73,

Dave, AA6YQ

Björn Ekelund, SM7IUN
 

Thanks Dave,

very clear. Now I understand the background of the current mechanics. 
I have honestly never noticed the grid source panel in SpotCollector's config 
and not at all realized its all-or-nothing effect.

I also realize it is SpotCollector and not DXView that determines the reliability of a grid locator. 
Thank you.

All this also makes me realize I was barking up the wrong tree. (Not the first time.)

What I found inconvenient was really the lack of sunset/sunrise data, not the lack of a grid locator.

So, starting over: 

Since DView generously provides approximated geographical distance and beam headings 
for callsigns having an override but lacking a grid locator, would it be possible to also provide equally 
approximate sunset/sunrise information when an override lacks exact geographical data?

Björn SM7IUN


Den tors 27 feb. 2020 kl 02:59 skrev Dave AA6YQ <aa6yq@...>:

+ AA6YQ comments below

Although I understand what you are saying I struggle with the logic.

If I enter a random Swedish call in DXView, I get the grid locator of central Stockholm which of course is very wrong for e.g. my call. But close enough for all practical purposes (beam heading, sun info, spot plot) except of course VUCC. I believe everyone prefers this before getting an empty grid.

+ Correct.

If I enter a callsign which is in the override list and the override lacks a grid. I get an empty grid.
What is wrong with using the DXCC database lookup grid when the override lacks a grid, just as with random calls? Why is this a bad idea?

+ The long-standing description of an override's Grid field, dating back to the days of 16 fixed overrides, is

"the Maidenhead Grid Square from which the station is operating"

<https://www.dxlabsuite.com/dxview/Help/Configuration.htm#Entity%20Overides>


+ Each Spot Database Entry contains a DXGridSource field that contains one of the following values

L - the gridsquare associated with the Latitude and Longitude specified in the Operator location panel
O - the gridsquare specified by an Override
S - a gridsquare extracted from a spot note or information appended to the spot by a Spot Source
U - the gridsquare determined by a USAP Database lookup
D - the gridsquare determined by a DXCC Database lookup

<https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm#DXGridSource>

+ Originally, a Spot Database Entry's "Grid Square" field was only considered valid for VUCC if the Entry's DXGridSource contained the letters L, O, or S.

+ At some point in the past, discussion here led me provide user control of this by adding the "Grid Sources for VUCC" panel to the General tab of SpotCollector's Configuration window. This panel provides you with the ability to determine whether Spot Database Entries whose DXGridSource fields contain O, S, or U should be considered reliable enough for VUCC need determination.

+ Note that these options are "all or nothing": if you uncheck the L box in the "Grid Sources for VUCC" panel because some of your overrides specify inaccurate grid squares, then all grid squares specified in Overrides will be ignored for VUCC need determination.

+ If you're pursuing VUCC, then each override of a station QRV on VHF or UHF should specify an accurate grid square so you can keep the "Grid Sources for VUCC" panel's Override box checked.

+ If you're not pursuing VUCC then you can uncheck the "Grid Sources for VUCC" panel's Override box; in this case, there's no reason to not populate an Override's grid square with an approximate location.

       73,

               Dave, AA6YQ







Joe Subich, W4TV
 

Since DView generously provides approximated geographical distance
and beam headings for callsigns having an override but lacking a grid
locator, would it be possible to also provide equally approximate
sunset/sunrise information when an override lacks exact geographical
data?
Again, DXView provides an approximate location which is used for
beam headings, sunrise/sunset, Lat/Lon for each entry in the DXCC
Database. By creating an override, you are explicitly telling
DXView that the information in the DXCC Database is not accurate
for the callsign being overridden.

Once you tell DXView that the DXCC Database information is not to be
used, it is up to you to provide the information you want to use.
Make your decision ... if beam heading and SR/SS are important to
you, provide an approximate grid square when you create the override.
VP8PJ has the information on their home page: IOTA AN-008, Grid:
GC79eh. It takes a minute to find that on the web and less time than
that to enter into (update) the override.

73,

... Joe, W4TV


On 2020-02-27 12:52 PM, Björn Ekelund, SM7IUN wrote:
Thanks Dave,
very clear. Now I understand the background of the current mechanics.
I have honestly never noticed the grid source panel in SpotCollector's
config
and not at all realized its all-or-nothing effect.
I also realize it is SpotCollector and not DXView that determines the
reliability of a grid locator.
Thank you.
All this also makes me realize I was barking up the wrong tree. (Not the
first time.)
What I found inconvenient was really the lack of sunset/sunrise data, not
the lack of a grid locator.
So, starting over:
Since DView generously provides approximated geographical distance and beam
headings
for callsigns having an override but lacking a grid locator, would it be
possible to also provide equally
approximate sunset/sunrise information when an override lacks exact
geographical data?
Björn SM7IUN
Den tors 27 feb. 2020 kl 02:59 skrev Dave AA6YQ <@AA6YQ>:

+ AA6YQ comments below

Although I understand what you are saying I struggle with the logic.

If I enter a random Swedish call in DXView, I get the grid locator of
central Stockholm which of course is very wrong for e.g. my call. But close
enough for all practical purposes (beam heading, sun info, spot plot)
except of course VUCC. I believe everyone prefers this before getting an
empty grid.

+ Correct.

If I enter a callsign which is in the override list and the override lacks
a grid. I get an empty grid.
What is wrong with using the DXCC database lookup grid when the override
lacks a grid, just as with random calls? Why is this a bad idea?

+ The long-standing description of an override's Grid field, dating back
to the days of 16 fixed overrides, is

"the Maidenhead Grid Square from which the station is operating"

<
https://www.dxlabsuite.com/dxview/Help/Configuration.htm#Entity%20Overides

+ Each Spot Database Entry contains a DXGridSource field that contains one
of the following values

L - the gridsquare associated with the Latitude and Longitude specified in
the Operator location panel
O - the gridsquare specified by an Override
S - a gridsquare extracted from a spot note or information appended to the
spot by a Spot Source
U - the gridsquare determined by a USAP Database lookup
D - the gridsquare determined by a DXCC Database lookup

<
https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm#DXGridSource
+ Originally, a Spot Database Entry's "Grid Square" field was only
considered valid for VUCC if the Entry's DXGridSource contained the letters
L, O, or S.

+ At some point in the past, discussion here led me provide user control
of this by adding the "Grid Sources for VUCC" panel to the General tab of
SpotCollector's Configuration window. This panel provides you with the
ability to determine whether Spot Database Entries whose DXGridSource
fields contain O, S, or U should be considered reliable enough for VUCC
need determination.

+ Note that these options are "all or nothing": if you uncheck the L box
in the "Grid Sources for VUCC" panel because some of your overrides specify
inaccurate grid squares, then all grid squares specified in Overrides will
be ignored for VUCC need determination.

+ If you're pursuing VUCC, then each override of a station QRV on VHF or
UHF should specify an accurate grid square so you can keep the "Grid
Sources for VUCC" panel's Override box checked.

+ If you're not pursuing VUCC then you can uncheck the "Grid Sources for
VUCC" panel's Override box; in this case, there's no reason to not populate
an Override's grid square with an approximate location.

73,

Dave, AA6YQ

Björn Ekelund, SM7IUN
 

Joe, 

I'll try to be even more clear.

My point is that DXView is providing beam heading and distance for 
callsigns with an override but no grid specified. Obviously using an 
approximate location. 

I don't see the harm in using the same exact mechanics also for 
sunset/sunrise information.

Currently the Sun information panel is blank if a grid is not 
explicitly specified. 

Björn SM7IUN


Den tors 27 feb. 2020 kl 19:14 skrev Joe Subich, W4TV <lists@...>:


> Since DView generously provides approximated geographical distance
> and beam headings for callsigns having an override but lacking a grid
> locator, would it be possible to also provide equally approximate
> sunset/sunrise information when an override lacks exact geographical
> data?
Again, DXView provides an approximate location which is used for
beam headings, sunrise/sunset, Lat/Lon for each entry in the DXCC
Database.  By creating an override, you are explicitly telling
DXView that the information in the DXCC Database is not accurate
for the callsign being overridden.

Once you tell DXView that the DXCC Database information is not to be
used, it is up to you to provide the information you want to use.
Make your decision ... if beam heading and SR/SS are important to
you, provide an approximate grid square when you create the override.
VP8PJ has the information on their home page:  IOTA AN-008, Grid:
GC79eh.  It takes a minute to find that on the web and less time than
that to enter into (update) the override.

73,

    ... Joe, W4TV


On 2020-02-27 12:52 PM, Björn Ekelund, SM7IUN wrote:
> Thanks Dave,
>
> very clear. Now I understand the background of the current mechanics.
> I have honestly never noticed the grid source panel in SpotCollector's
> config
> and not at all realized its all-or-nothing effect.
>
> I also realize it is SpotCollector and not DXView that determines the
> reliability of a grid locator.
> Thank you.
>
> All this also makes me realize I was barking up the wrong tree. (Not the
> first time.)
>
> What I found inconvenient was really the lack of sunset/sunrise data, not
> the lack of a grid locator.
>
> So, starting over:
>
> Since DView generously provides approximated geographical distance and beam
> headings
> for callsigns having an override but lacking a grid locator, would it be
> possible to also provide equally
> approximate sunset/sunrise information when an override lacks exact
> geographical data?
>
> Björn SM7IUN
>
>
> Den tors 27 feb. 2020 kl 02:59 skrev Dave AA6YQ <aa6yq@...>:
>
>> + AA6YQ comments below
>>
>> Although I understand what you are saying I struggle with the logic.
>>
>> If I enter a random Swedish call in DXView, I get the grid locator of
>> central Stockholm which of course is very wrong for e.g. my call. But close
>> enough for all practical purposes (beam heading, sun info, spot plot)
>> except of course VUCC. I believe everyone prefers this before getting an
>> empty grid.
>>
>> + Correct.
>>
>> If I enter a callsign which is in the override list and the override lacks
>> a grid. I get an empty grid.
>> What is wrong with using the DXCC database lookup grid when the override
>> lacks a grid, just as with random calls? Why is this a bad idea?
>>
>> + The long-standing description of an override's Grid field, dating back
>> to the days of 16 fixed overrides, is
>>
>> "the Maidenhead Grid Square from which the station is operating"
>>
>> <
>> https://www.dxlabsuite.com/dxview/Help/Configuration.htm#Entity%20Overides
>>>
>>
>>
>> + Each Spot Database Entry contains a DXGridSource field that contains one
>> of the following values
>>
>> L - the gridsquare associated with the Latitude and Longitude specified in
>> the Operator location panel
>> O - the gridsquare specified by an Override
>> S - a gridsquare extracted from a spot note or information appended to the
>> spot by a Spot Source
>> U - the gridsquare determined by a USAP Database lookup
>> D - the gridsquare determined by a DXCC Database lookup
>>
>> <
>> https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm#DXGridSource
>>>
>>
>> + Originally, a Spot Database Entry's "Grid Square" field was only
>> considered valid for VUCC if the Entry's DXGridSource contained the letters
>> L, O, or S.
>>
>> + At some point in the past, discussion here led me provide user control
>> of this by adding the "Grid Sources for VUCC" panel to the General tab of
>> SpotCollector's Configuration window. This panel provides you with the
>> ability to determine whether Spot Database Entries whose DXGridSource
>> fields contain O, S, or U should be considered reliable enough for VUCC
>> need determination.
>>
>> + Note that these options are "all or nothing": if you uncheck the L box
>> in the "Grid Sources for VUCC" panel because some of your overrides specify
>> inaccurate grid squares, then all grid squares specified in Overrides will
>> be ignored for VUCC need determination.
>>
>> + If you're pursuing VUCC, then each override of a station QRV on VHF or
>> UHF should specify an accurate grid square so you can keep the "Grid
>> Sources for VUCC" panel's Override box checked.
>>
>> + If you're not pursuing VUCC then you can uncheck the "Grid Sources for
>> VUCC" panel's Override box; in this case, there's no reason to not populate
>> an Override's grid square with an approximate location.
>>
>>         73,
>>
>>                 Dave, AA6YQ
>>





Dave AA6YQ
 

+ AA6YQ comments below

My point is that DXView is providing beam heading and distance for callsigns with an override but no grid specified. Obviously using an approximate location.

I don't see the harm in using the same exact mechanics also for sunset/sunrise information.

Currently the Sun information panel is blank if a grid is not explicitly specified.

+ Björn, I've sent you a new version of DXView that determines the location of a callsign whose override doesn't specify a grid square by using the DXCC entity specified in the override to query the USAP and DXCC databases. This change does not alter the way SpotCollector determines an active station's grid square.

+ Please let me know how it goes.

73,

Dave, AA6YQ

Björn Ekelund, SM7IUN
 

Thank you Dave. 

This was all I really wanted. My apologies for taking the discussion on a detour via the grid locator.

Björn

Den fre 28 feb. 2020 kl 03:25 skrev Dave AA6YQ <aa6yq@...>:

+ AA6YQ comments below

My point is that DXView is providing beam heading and distance for callsigns with an override but no grid specified. Obviously using an approximate location.

I don't see the harm in using the same exact mechanics also for sunset/sunrise information.

Currently the Sun information panel is blank if a grid is not explicitly specified.

+ Björn, I've sent you a new version of DXView that determines the location of a callsign whose override doesn't specify a grid square by using the DXCC entity specified in the override to query the USAP and DXCC databases. This change does not alter the way SpotCollector determines an active station's grid square.

+ Please let me know how it goes.

        73,

              Dave, AA6YQ