A few of us talked this morning about how great this feature would be. Some activate POTA CA-1234, and a pop-up says, “You are also a WWFF reference VEFF-1234. Would you like to activate this location as well?” That would be a great feature.
1 Like
Hi Stuart,
This might sound nice but there are a few impediments to providing this and also a near solution there already.
Firstly, PoLo does not maintain a park pairing list. There is no such “official” list of pairings. But as you may well know, N3KAE/Al uses my mParks software to create pairs and publishes the output on CQParks.net.
But the task of pairing parks and maintaining the list is not trivial and PoLo provides the next best solution for pairing since it puts the actual job of pairing in the hands of the activator.
PoLo allows you to bring forward (with the latest release) a template operation of having both WWFF AND POTA activities. The activator is also provided with an initial list for both program parks based on proximity. This makes dual activations even easier for the OPs who wish to do it like me and you.
But a popup like this would probably be interpreted as a “nag” and would not go down well with OPs who do only one program.
Bottom line IMO is that this sort of “promotion” should be handled outside the logging software.
Alan
Thanks Alan, Al and I talk frequently…we were chatting today and that is where the idea came from 
If you enable the WWFF feature, then it’s very easy to just find the nearest park.
If the WWFF data file were easier to download and parse, I’d even consider having that feature enabled by default, but as it is right now, it would make the “first time experience” a lot more cumbersome than it already is.
So at this point, users have to decide to “opt in” into using WWFF features in the app.
1 Like
I think that is a great idea! There could be a list view that shows nearby refs for all programs selected / distance. Of course it would be activators responsibility to check that they are actually inside the boundaries.
Please describe how the file would be easier download & parse and we can consider implementing it to WWFF. The CSV is old format but it is actually very compact compared to any other format (JSON, XML). We could gzip the CSV…
(wwff.co dev here)
Whatever works best, I just had the idea…I know N3KAE updates the CSV monthly on CQPARKS
I’m currently using https://wwff.co/wwff-data/wwff_directory.csv
It’s a 22MB file, compared with 6MB for POTA’s https://pota.app/all_parks_ext.csv
Is there a more compact file available?
I’ve been thinking of caching these data files in a ham2k server, pre-processing them to make them optimal for PoLo’s use, and even creating some kind of “delta files” to minimize download times. But this is not our highest priority right now.
Yup, that’s the only file available. I haven’t got any idea how to compress it really, as the longest fields are the ones that are actually needed every time.
Of course we could make another file of refs that have been modified during the year, that would compress it quite a bit.
Just let me know what would be more optimal and we can discuss about it with the WWFF dev team.
Actually looking at it now, there are some fields that could be removed for PoLo use (the PP link, history information).
Jouni,
If you are going to make a PoLo specific export, there are a few fields which could be removed without causing issue and making the file considerably smaller.
The bold ones could be removed and not cause issues with processing.
reference,status,name,program,dxcc,state,county,continent,iota,iaruLocator,latitude,longitude,IUCNcat,validFrom,validTo,notes,lastMod,changeLog,reviewFlag,specialFlags,website,country,region,dxccEnum,qsoCount,lastAct
Even in the extended POTA download these are the fields present and used by PoLo
“reference”,“name”,“active”,“entityId”,“locationDesc”,“latitude”,“longitude”,“grid”
So that would make the process a lot lighter.
Alan
I’ve added this idea on our issue listings, but I cannot say if/when we are going to implement this. I will keep you updated.
We do currently use the dxccEnum rather than dxcc. We also use the iaruLocator, but fallback to calculating that from lat/long anyway. But obviously open to changing anything
Code pulling out fields here for some background: app-polo/src/extensions/activities/wwff/WWFFDataFile.js at 5b6a832b5949f8f9937e68c13808f57878065943 · ham2k/app-polo · GitHub