Page 1 of 1

Problem with entity Minami Torishima

Posted: 23 Oct 2016, 05:18
by w6trh
I have noticed that when I double click on this call, JD1YAA, in the spots, the map indicator will correctly draw a line between my QTH in California, and Minami Torishima. THen, one or two seconds later the line is redrawn from CA to what looks to be a Latitude of 0 degrees, and a longitude of 0 degrees. I am using version 1.26, and have update the country list as of 10-22-2016.

I have noticed this before with other calls, but pretty infrequent. JD1YAA is the latest one that does this.

Any ideas ?

Tom
W6TRH

Re: Problem with entity Minami Torishima

Posted: 23 Oct 2016, 07:44
by K7PT
I also am running 1.26.0 and do not see this behavior for JD1YAA. All is well here. 8-)

Re: Problem with entity Minami Torishima

Posted: 23 Oct 2016, 11:02
by G4POP
w6trh wrote:I have noticed that when I double click on this call, JD1YAA, in the spots, the map indicator will correctly draw a line between my QTH in California, and Minami Torishima. THen, one or two seconds later the line is redrawn from CA to what looks to be a Latitude of 0 degrees, and a longitude of 0 degrees. I am using version 1.26, and have update the country list as of 10-22-2016.

I have noticed this before with other calls, but pretty infrequent. JD1YAA is the latest one that does this.

Any ideas ?

Tom
W6TRH
Yes I have found the reason!

The initial locator information is taken from our own resources when the spot appears in the cluster - This is the centre of the country - This is the initial line drawn on the map

When you click the spot and the call is entered into the callsign field, Log4OM then goes to verify that Grid reference (Locator) from the external sources like whatever on line lookup facility your use QRZ, HamQTH or QRZCQ and finally Clublog.

Because Clublog is not listing a Locator for this entity the locator field is being emptied so the line defaults to the centre of the earth (JJ00SF)

Try turning off the Clublog lookup in the Options/Settings 1 tab and then do the lookup again you will find it used the correct information from QRZ which is QL64XG

PS: HamQTH has no information about this call and QRZCQ appears to have a log in issue at this time