This is a feature request to the SOTA management team, filed publicly in case others have helpful ideas and comments.
I, as a user of SOTLAS, wish to have the ability to filter summits based on the number of QSOs in a frequency band; specifically for my use case, I want an easy way to find summits that are easy with VHF (as opposed to requiring an HF kit). Since the code for SOTLAS is open source, I was able to peruse it and figure out what would be necessary to make that happen; see discussion here.
So, SOTLAS needs a way to grab the per-band per-summit QSO counts from SOTA in bulk. From an external point of view, the easiest way to do this would be to add some additional fields to the summitlist.csv. If adding a field for each individual band is too bandwidth-intensive, the bands could also be grouped into HF-and-below and VHF-and-above. If it makes sense to expose the data another way instead (a new API endpoint?), Iâm all ears.
Since the code for SOTA is not open source, I donât have an idea of how extensive the changes to make this happen would be. I am willing to (attempt to) make the initial code contributions to make this happen (and test them, of course), but there would still be an ongoing burden for the management team to maintain this code which I imagine you would like to discuss.
So, management team - how can we make this happen?
You are correct. SOTLAS is the work of Manuel @HB9DQM. The request should be sent to Manuel.
Here is a way to use our SOTAData site to find summits:
*Go to the âHonor Rollsâ for your home association and look at the Activator Honor Roll
*Filter by band = 144MHz and Mode=FM
*Now you will see the top 2m FM activators in your area. Drill down into their logs (right-most column âview logâ) to see how many 2m FM QSOs they made on each summit.
In general, look for summits that are close to populated areas. You may also consider contacting some of these folks and asking them for recommendations. SOTA ops are generally friendly and very happy to talk about summits, kit, etc. with other SOTA ops.
SOTL.as operates on data that is automatically published by SOTA. I am requesting that SOTA publish additional data, so that I may implement a new feature for SOTL.as on top of it.
Iâll think a bit about this, but one thing is certain, it wonât be done via summitslist.csv. I once typoâed a word in the header - not even the data - and broken a dozen tools that people had written that parsed that file and never heard the end of it, so no changes going to happen there. I donât need that kind of grief
Itâs also used by a gazillion different clients - it seems every new logging app decides it needs to download it whether the person is logging SOTA or not - and itâs also already a very large file thatâs often downloaded via mobile data and adding the counts would almost certainly double that size at least.
So, if it happens, itâll be an API endpoint. The second thing I want to check before committing it is the fact that if you want that data in bulk, itâll almost certainly require a table scan of several very large tables. Thatâs the sort of thing we desperately try to avoid because it ties up resources while the query runs and invariably causes other issues.
Andy, would it save resources to have the info on the summit page, calculated annually to show the figures to Dec. 31st of the previous year? I canât imagine that any more than that would be needed.
From my point of view (as just a SOTA activator not an MT member) I get quite some satisfaction from digging out info like this by viewing all the resources. The info on how often a summit is activated and the QSO counts per band is already available per summit. Itâs not made available as a list of summits in a region and the counts so you have to view it per summit.
As Andrew says such a query will involve a lot of table scans and thus be expensive. It can be done for a single summit as thereâll be only one scan and there is also Ă lot of index data. One summit will have an expense but hundreds, thousand or tens of thousands will cost. The problem with queries that run for a few seconds is some users have little patience and if they donât get results as soon as they click then they start clicking and refreshing and clicking making the situation worse.
It can be done but it will need some proper engineering and measuring doing so the impact is not problematic.
This is indeed true: within a single regionâs summits listing in the SOTA DB, it necessitates clicking forwards through an intermediate page to get to a listing of QSO counts per band for a particular summit (but no breakdown on modes), and then clicking backwards two web-pages again to get back to the regionâs summits listing, just in order to choose the next summit. To view several summits in a region, thatâs a lot of clicking back and forth through many web-pages - think of it as good exercise for the mouse-click finger.
There is at the moment an easier and more comfortable alternative, however, using the main page in sotamaps. Just choose a region to list all of itsâ summits in the LH part of the window, and one can choose âMappingâ (the standard option), âSummit Historyâ or âRegion Summariesâ from the tabs above the summits listing. These tabs will show in the main part of the window either
the full activations history for a particular summit, including a full breakdown of bands and modes used on the summit in both tabular and chart presentations, or
summaries of bands and modes used in the region, again table and charts.
Itâs simplicity itself to choose another summit from the LH list, and watch the display update in a fraction of a second.
The best part of all this is that, in the very near future, these tables, charts, etc. in sotamaps will all be closed down and deleted when sotamaps is finally buried, and your only chance to see such details (minus the modes, of course ⌠and the regions summaries) will be the click-fest described above. But donât worry too much about that - the colors and fonts used there are really nice and easy on the eye.
I have arrived here from the SOTLAS GitHub repo/issues list.
Would a suitable compromise be to generate the expensive results periodically, for whatever periodicity makes sense (5mins? 30mins? 2hrs? 24hrs? 7days?), and/or to cache results and statistics rather than regenerating them for every API query/request, perhaps?
My understanding (and personal view) is the request for this data is to get a general indicative/approximate overview of summit activation trends, so lags and delays in data updates are perfectly acceptable. I could possibly even make an argument that a degree of stability in the responses may even be preferable.
Possibly worth noting too that simple counts of QSO by band for each summit (for this use case) do not necessarily even need to be consistent between summits. For example, if background tasks are updating summit stats on a rolling basis such as n summits every 5-15mins to spread the load/updates throughout the day, I suggest it is perfectly okay (for this use case) to have summit Xâs count be 25mins old and summit Yâs count be three hours old.
That said, I fully realise that further requests (or internal requirements/policy/convention) might expect/demand more granular updates or for all entries to all reflect the same point in time (etc.), but for this specific use case/request I suggest it is not required.
