POTA file export

[kyleboyle]

This enhancement completes our pota user experience. I've explained the pota experience and common workflow as a wiki entry here:
https://github.com/kyleboyle/QLog/wiki/POTA-Activations

This PR is the missing functionality of the file export. There are various legacy and pota.app requirements which differentiates it from a generic adif export which I won't outline here but I describe briefly in the wiki and the full documentation is here:

https://docs.pota.app/docs/activator_reference/ADIF_for_POTA_reference.html

[foldynl]

Please, could you rebase it and send me only diff for you change ?

[kyleboyle]

Not sure why qt5 is failing on that enum

[foldynl]

it is because of Ubuntu 20.04. It contains qt 5.12. I already solved it in QLog. Try this:

#if (QT_VERSION >= QT_VERSION_CHECK(5, 15, 0))
    const QStringList &commands = message.split(";", Qt::SkipEmptyParts);
#else /* Due to ubuntu 20.04 where qt5.12 is present */
    const QStringList &commands = message.split(";", QString::SkipEmptyParts);
#endif

[kyleboyle]

Ah, that makes sense. I was trying to replicate locally on 5.15 (the version of qt5 installed by homebrew on macos) and didn't see any difference :D

[foldynl]

Sorry, but this time I have to be strict and cannot fully accept this PR. The idea seems to be OK, but I believe PotaADIFormat is written in a rather risky way (allocation/deallocation etc.). It also has some side effects for those who haven’t read your wiki properly. For example, it informed me that the export was successful even though nothing matched, simply because I hadn’t set POTA_REF records.

A major issue for me is that you specify a file in the export dialog, but it only takes the path instead. Unfortunately, the biggest red flag for me is the manipulation of POTA_REF copying it into SIG_INFO. I’ve read POTA.APP, and unfortunately, the authors haven’t adapted to the new ADI yet, so SIG_INFO is still required. I will try to improve the duplicateField method.

I’ll try to change it in a way that doesn’t break your idea. It might even end with me not coming up with better code, which is also possible.

[kyleboyle]

Thanks for the feedback. My goals were to keep changes to existing code base minimal and reusing the functionality of the adiformat code as much as possible. The major problem I had to work around was keeping the IO based Qt objects for the park files in scope / prevent deconstruction so that the file streams didn't close.

export was successful even though nothing matched, simply because I hadn’t set POTA_REF records.

This was my intention but maybe it's confusing. I wanted the user to be able to export a range of logs and the pota export feature would only concern itself with records that have been logged with pota refs.

specify a file in the export dialog, but it only takes the path instead

It will export all the pota logs to the file specified, and will also write each log to separate park files.

[foldynl]

Can you please advise me? I'm looking at the POTA rules now and how it should actually work. As I can see, the authors of the POTA app transferred all the logic to the operators (external applications).

How do you export logs to the POTA App now? Is there an application that does this?

[kyleboyle]

You have to log into the website and upload your log files using their website. this video shows it:
https://docs.pota.app/docs/activator_reference/submitting_logs.html#submitting-logs-to-parks-on-the-air

[aa5sh]

The couple I did I would export a ADIF file then upload at the pota.app website. In the instance where there are multiple parks for the same location you would need to manually duplicate the files and update the my_sig_info field for each park. Then files upload the files accordingly.

…

On Tue, Dec 17, 2024 at 10:15 AM Kyle Boyle ***@***.***> wrote: You have to log into the website and upload your log files using their website. this video shows it: https://docs.pota.app/docs/activator_reference/submitting_logs.html#submitting-logs-to-parks-on-the-air — Reply to this email directly, view it on GitHub <#514 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUEEMXU2H6ZUYVQ4Y3QFWE32GBEZ7AVCNFSM6AAAAABSLSBF36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBYHEYTINZXHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[foldynl]

In the instance where there are multiple parks for the same
location you would need to manually duplicate the files and update the
my_sig_info field for each park.

That's exactly what I want to ask. Do all POTA hunters/activators manually do this duplication? From what I read in the POTA rules, the QSO duplication is required even for Multi-park-to-Multi-park QSOs. But with hundreds of QSOs, this simply can't be done manually! Sorry, I don't have experience with POTA, but surely this can't be done manually !!! There must be some utility for this. If there is nothing like that here, I think we should do something external rather than implementing this in QLog.

I’d rather not ask why the authors of the POTA.app don't handle this internally when file is uploaded.

[aa5sh]

From what I understand you only need to account for the park(s) you are activating from, not for the other guy. I think they match that up on the back end. So if you are here at a park that falls under several POTA parks then me as an activator needs to submit logs with appropriate MY_SIG_INFO for each park individually. The files would be identical except having to change that one field. Correct me if I am wrong Kyle. I believe that is what Kyle was trying to implement they want it separately and named it a certain way.

…

On Tue, Dec 17, 2024 at 10:41 AM Ladislav ***@***.***> wrote: In the instance where there are multiple parks for the same location you would need to manually duplicate the files and update the my_sig_info field for each park. That's exactly what I want to ask. Do all POTA hunters/activators manually do this duplication? From what I read in the POTA rules, the QSO duplication is required even for Multi-park-to-Multi-park QSOs. But with hundreds of QSOs, this simply can't be done manually! Sorry, I don't have experience with POTA, but surely this can't be done manually !!! There must be some utility for this. If there is nothing like that here, I think we should do something external rather than implementing this in QLog. I’d rather not ask why the authors of the POTA.app don't handle this internally when file is uploaded. — Reply to this email directly, view it on GitHub <#514 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUEEMXWX5QDZVO4ROAEAJH32GBH4RAVCNFSM6AAAAABSLSBF36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBYHE4DQMZQGA> . You are receiving this because you commented.Message ID: ***@***.***>

[kyleboyle]

Some logging apps that are pota aware will generate multiple logs for you if you are activating multiple parks at once, example:

https://youtu.be/bdZGptd-3JI?si=MtCorj6HeO0LKuzo&t=305

For a park2park multi park you need to log the remote park IDs as well, which is also handled by this feature - it generates multiple qsos for each remote park. For software which is not pota aware, stations will usually just manually enter multiple logs for the single contact. Pota aware apps will handle using a comma separated list of parks, seen here:

https://youtu.be/bdZGptd-3JI?si=W7G_U03sZVSNUAaR&t=484

From what I understand you only need to account for the park(s) you are
activating from, not for the other guy.

This is not correct. To get credit for a park 2 park (multi) you need to log the remote park IDs, a firm requirement when the remote station is a multi park, and a suggested best practice for single parks:

An activator can work another activator to earn a park-to-park (P2P) credit. Both activators are strongly recommended (although not required) to record the park number of the other activator in the ADIF log file’s SIG_INFO ADIF field (see ADIF for POTA Reference) in all park-to-park contacts.

Proper use of SIG_INFO is necessary to receive all eligible P2P credits when one or both activators are activating multiple parks. For example, if you work a three-fer activator, you are eligible for three P2P credits. In that case, list the same QSO three times in the ADIF log file, each with one of the three park references in SIG_INFO, with the rest unchanged. Failure to do so will give you only one P2P credit and two hunter credits.

[kyleboyle]

Another logging app which does this file creation & qso splitting is
app.worldradioleague.com

[foldynl]

I've made the code a little clearer. Even though there are a lot of changes, the idea of ​​the original code is still noticeable in it. I didn't invent anything new.

Please, could you test it? The modified code is in branch POTAExport.

[kyleboyle]

Tested and confirmed working. Thank you for cleaning it up!