Best approach for adding band QSO filter to map view

[kwesthaus]

For a given frequency band, some summits are much more difficult to activate than other summits. For example, a low-lying peak surrounded in all directions by higher peaks would be much trickier to make VHF contacts on than a summit with high prominence (and better line-of-sight to population areas). I think that adding a filter which allows potential activators to e.g. only look at peaks with a large number of QSOs on the 2 meter band would be helpful for people trying to scout out peaks they can activate with the radios they have. I'm willing to implement the code for this, but as I'm not familiar with the architecture of this repository, I'm hoping for some guidance on how to practically implement this feature.

Rough UI draft:

What I know from skimming the code:

• Map view is at src/views/Map.vue
• Current filter implementations are at src/components/MapFilterControl.vue
  • updateFilter() creates an array of all the activated filters, then applies them using setSummitFilter()
  • setSummitFilter() uses the setFilter() function from mapbox (link) on each of the 5 layers of UI elements for summits: 'summits_circles', 'summits_names', 'summits_activations', 'summits_inactive_circles', and 'summits_inactive_names'
• Each of the layers is specified in an asset file for the map type (e.g. src/assets/openmaptiles.json), which in turn uses data from the "summits" source layer
  • The summit source layer comes from a map server (e.g. for my region https://1.us.map.sotl.as/data/summits.json) which has tiles (e.g. https://1.us.map.sotl.as/data/summits/0/0/0.pbf) which come in PBF format (can be opened with the OSM plugin for QGIS)
  • Viewing the pbf files confirms that data source stores the summit attributes that the current filters are using (e.g. act, points, alt) but not QSO counts
  • I'm assuming the PBF files are generated from the summit csv list (link), which has all the summits but no QSO data. Please correct me if this assumption is wrong
• Looking at src/components/SummitActivations.vue, I see the https://api2.sota.org.uk/api/bandstats/ endpoint has the data we want but is queryable 1 summit at a time. It's infeasible to call out to SOTA for every summit on the page while panning around.
• I poked around the api2 and api-db2 SOTA APIs and didn't find any other endpoints that provide the QSO data for every summit

So, what do you think? Should I reach out to the SOTA folks and convince them to include some QSO data in the summitlist csv, then get that into the map tiles to query just like the other filters? Or is there a better way? If the SOTA admins are worried about increased bandwidth, I think it would still be helpful if the QSO data was combined into 2 groups (HF- and VHF+) as opposed to each individual band.

[manuelkasper]

Hello Kyle,

Apologies for the late reply; I've been busy moving house. Thanks for considering to contribute to the SOTLAS codebase!

Your observations on the inner workings of the map filter are correct. The code that generates the map tiles would need to obtain the per-band QSO counts from the SOTA database (without making a separate request for each and every summit), and include them as properties in the tiles, so that they can be filtered via MapBox GL. So the first step would be to convince the people who maintain the SOTA database and APIs to make the required information available in a bulk format.

For the UI, instead of a long list of checkboxes for selecting bands, perhaps a Buefy Dropdown with multiple selection could be used.

73,

Manuel HB9DQM

[kwesthaus]

No worries Manuel, hope the move goes well! I've filed a request to the SOTA management team on the reflector (link). And thanks for the UI idea too, that sounds a lot cleaner.