[Dx4win] [Van spam verdacht] Wish list, again -- LOTW Import

[Randy Farmer]

>I find that the start with ¨LoTW:¨ in notes is very usefull in dx4win
>Because with F8 looking up ¨LOTW: STATE¨ will only show up those qso´s where
>
>Both are present, same for other items.

This points out the need for a filter dropdown 
choice of "Not blank" in the State, Grid and Zone 
(and other?) fields, similar to that provided in 
Microsoft Excel. The fact that the record has 
been updated from LOTW is already denoted by the 
setting of the Upl Cnf flag. Use of the F8 
filtering function to filter on a combination of 
Upl Cnf = Y and State = (notblank) would do the 
same job without requiring extra text in the log 
file. Inserting extra text in the log file to 
make up for a deficiency in the program's native 
search function is a less than optimum approach.

Another feature that would be "really nice" for 
troubleshooting LOTW problems would be to provide 
an extra field in the log record for a date stamp 
when the Upl Cnf flag was set. This would require 
altering the structure of the log file, however, 
and is almost certainly not worth the complication.

> >"LOTW: State=GA County=Harris Grid=EM72 CQZone<>5" is written in the notes
>for this call because one of the items was incorrect-- in this case it is
>CQZone 5
>like you explained. When all downloaded data is correct and put in the
>correct
>field there is NO LOTW: in the notes for this call.
>I am sure that Paul is reading this and will probably come up with something
>That for instance only shows the corrupt items like LOTW: CQZone<>5, wrong
>Grid
>This part needs the user his attention because there is a difference between
>the log
>And the import.

Actually, the point of picking this particular 
example was that DX4WIN was wrong in selecting 
zone 4 and didn't correct the error on LOTW 
import. KU8E is actually in Georgia, which is 
zone 5. Of course there is no way for the 
software to know that, but the update after the 
LOTW record import should have picked this up 
when the State field was populated with GA.

I also found plenty of records where there was no 
zone problem, just the updated State and County 
fields. Each of these got the "LOTW:" treatment 
too. So the "LOTW:" notation is not indicative of 
a just a conflict between existing log data and 
imported data. It simply indicates that there was 
information, correct or not, in the imported LOTW 
report record that wasn't in the original log record.

I completely agree that imported data that 
conflicts with data already in the log should 
definitely be flagged so the conflict can be 
resolved. As I see it, the main problem with the 
"LOTW:" text insertion is that it blurs the 
distinction between updated information and 
conflicting information in the import record. In 
the case where imported information disagrees 
with information in the log, I'd prefer to see 
the same "ERROR:..." message that's used for 
flagging zone and country prefix differences. 
This alerts the user that there really is some 
sort of problem that needs to be looked at. In 
the case where the LOTW import simply filled 
previously blank fields, it's up to the user to 
verify the new information if he chooses to. The 
search procedure discussed above seems to be the 
best way to select the records that need to be examined.

>I agree that with massive import this is a big job to correct but I prefer
>To have it in my log then somewhere on a report sheet. This get lost or
>deleted And your log stays bugged.

I prefer to work from an import change list, 
especially one in comma-delimited format that I 
can drop into Excel and manipulate to pop out the 
changes that I care about. Then I can go to the 
log itself and fix only the records I've selected. To each his own.

>...181 where gridlocators because in my log was JO21ba and the upload showed
>JO21 only

Which brings up another point. The program does 
wonders with pattern searches in looking for 
callsigns. Surely figuring out that JO21ba and 
JO21 are the same grid square can't be that 
difficult. The structure of grid square 
nomenclature is well-defined. If the first four 
characters match, it's the same grid. Requiring a 
literal string match in the Grid field seems rather primitive.

>100 others where LOCATORS that didn´t match some of them there shack is in
>the middle
>Of the ocean, fixed it with QRZ.com when states and county were equal.
>Now I am still stucked with 40 problems and these ARE USER FAULTS because in
>my log
>They lived in CO - DENVER county in 1991 and moved to a new qth in NY but
>uploaded
>There FULL log with data from the new qth and not from 18 years ago,
>Never received paper qsl so can´t check it.

I've gotten a few of those myself. Unfortunately, 
we can't expect the software to correct for 
mistakes at the supply end of the LOTW chain. 
When we get information from the guy on the other 
end of the QSO we have to assume he's providing 
good information. With humans involved in this 
operation sometimes that doesn't happen.

And to open up another can of worms, see what 
happens when the same call shows up with two (or 
more) different names. Since DX4WIN assumes 
(wrongly, in my estimation) that each callsign 
will map to a single name, bizarre things happen. 
I imported a lot of contest QSO records from the 
North American QSO Party (NAQP) and the North 
American Sprint, where a name is part of the 
exchange. Jim's software picked up the name and 
inserted it in the Name field. The only problem 
is that sometimes the same station will use 
different names in these contests, so for one QSO 
you will get DWEEB and for another you will get 
VAL, etc. I don't remember exactly how the 
program behaved, but I think it ended up updating 
the name field in all QSOs with that particular 
callsign with the name in the last record 
inserted. This didn't bother me a whole lot, but 
it does point out a flaw in assuming that each 
call must always have the same name -- club stations, any one?

>A multiple QSO operation with cleanup ¨LOTW: comments¨ would be an option
>but will
>This be a good option ? you remain with an incorrect log.

Like any tool, if it's misused it can create more 
problems than it fixes. If it's used only after 
true problems have been identified and fixed I'm 
all for using a tool that will ease the burden of 
rote mechanical find, select, delete for dozens or hundreds of log records.

This is why I am contra the 1 button LOTW upload/download some people may
>wish,
> From time to time you make a small expedition or have a special prefix/call
>etc
>And you want to upload them to lotw, creating a unique name log is not a
>problem
>Having a certificate isn´t a problem also, Lets say that Paul should ad this
>feature
>With a setup in preferences.(TQSL password etc) but
>afterwards..................
>Just wondering how many times this 1 button upload will be incorrect if you
>forgot to change
>to the correct certificate?

I agree totally. The biggest problem with the 
LOTW process is that it's, shall we say, somewhat 
less than user-friendly. For those users who are 
lucky enough to have made QSOs only from one 
location and/or callsign, a one-button function 
might be OK. For those of us who have a more 
complicated situation, the chances of getting 
things wrong are much, much greater. To do the 
entire LOTW upload process right from within 
DX4WIN would basically involve wrapping a shell 
around the TQSL application and it probably 
wouldn't look all that different from TQSL 
anyway. I don't think it's worth the programming effort.

Thanks for the comments. It's always good to 
discuss ideas that can make a fine software product even better.

73...
Randy, W8FN