|
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
|
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
|
+ 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
|
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
|
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
>
|
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
|
+ 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"
<>
+ 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
<>
+ 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
|
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"
<>
+ 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
<>
+ 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
|
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"
<
+ 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
<
+ 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,?
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"
>>
>> <
>>
>>>
>>
>>
>> + 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
>>
>> <
>>
>>>
>>
>> + 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
>>
|
+ 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
|
Thank you Dave.?
This was all I really wanted. My apologies for taking the?discussion on a detour via the grid locator.
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
|
Bj?rn SM7IUN