SOTA MT IT Group Priorities for the next year

As mentioned in the minutes of the SOTA MT meeting, each group will be posting our priorities for 2017. As the newly elected leader of the IT Group, it falls upon me to provide our list of priorities for 2017. My aim is not to go into great detail on all of these, but to give a sense of what it is we are working on, approximate timelines, and some of the challenges we face.

For context, the IT group within the SOTA MT consists of three permanent members: myself as leader, Jon GM4ZFZ and Andy MM0FMF. Obviously, Jon is primarily focused on the website, and Andy primarily on the database. We will be assisted as needed by Csaba YO6PIF, and Cristophe ON6ZQ

Business Continuity

Our first primary priority is to ensure we have suitable Business Continuity plans in place to ensure SOTA can continue to run. Unfortunately, we have seen this occur with the sad passing of Eric KU6J, who maintained the RBNGate software; an event that has prompted substantial discussions within the MT about how we keep the lights on in the event of another unfortunate event of that magnitude.

There are two aspects to Business Continuity Planning: the first, obvious, one, is that backups (or more precisely, means of recovery) of critical systems must be kept, but this alone is not enough. These backups need to be tested and deployed by others who are not the primary maintainer of the system, who may be incapacitated and unable to assist with recovery. The latter aspect is the area we currently require further work on, and we have a number of initiatives underway to ensure that the entire IT group can manage any other system, and have experience with bringing up these systems.

We anticipate that we will have a reasonable amount of this in place within the next month or two. It’s easy to describe, but there are many layers of complexity to deal with. This is our number one priority at this point, overriding other large activities that are ongoing.

SOTA Shop Integration

Currently, the SOTA Shop is a separate website, with no real links back into the rest of the SOTA Infrastructure. This leads to a number of challenges for Barry GM4TOE in processing of awards. Jon will be overseeing the integration of the shop into the website, which will allow a better user experience not only for customers, but for Barry as well!

We anticipate this will take between 3 and 6 months to implement. We are currently in the requirements phase, and should be able to move into implementation comparatively soon.

SOTA Maps Integration

Rob DM1CM has expended a tremendous amount of time and effort, as well as his own money, on managing and maintaining the SOTAMaps service. The SOTA MT acknowledges the tremendous value this provides to the SOTA community, and the cost that Rob has borne to keep this service running. I have been working with Rob on bringing the SOTAMaps service onto MT managed-and-paid-for servers, to reduce the financial cost to Rob, and also to ensure the service can continue for the community should anything happen to Rob.

We have one or two action items to go before that transition happens, which are currently stuck behind the higher Business Continuity requirements for all-of-SOTA, but we anticipate doing the cutover within a month or two. Rob will continue to have access to the servers and will continue to maintain SOTAMaps - this is primarily just a change in server arrangements and funding.

SOTAWatch replacement

Jon continues to work on a replacement for SOTAwatch that is integrated into the main SOTA website. There is no timeline at this point for this to be implemented, but we anticipate it will be released before the end of the year.

Database Improvements

A number of improvements are needed for the database environment, primarily in support of other SOTA IT Group initiatives. The first is around the backend work required to enable the SOTA Shop integration and reduce the workload on Barry, the second is decoupling the web interface from the database itself via an API, and the third is providing the infrastructure to enable ARM auto-generation.

Andy will be very busy over the next year, as these are each, in and of itself, a large body of work, as well as the other ongoing database management requirements! Both Jon and I will help out as necessary to alleviate the workload as time permits.

Single Sign On

I will be working as well on providing a Single Sign On solution, to eliminate the tedious need to have separate passwords for SOTAwatch, sotadata,, the reflector, etc. This will also allow external apps, with some extra work, to determine your identity easily, without having to share passwords with the app, allowing, eg, for upload of log data. This one requires a lot of careful thought, as a failure in a single sign on application would prevent logging in to any application. A multi-redundant cluster will be deployed to allow a strong level of resilience.

SSL Everywhere

An easier one to round out the year, we intend to have SSL enabled on all systems that we run as part of SOTA.

Other work in the work queue, but not prioritised

New association uploads - The number of associations continues to grow, as does the number of summits in existing associations.

Uploader hardening - Increasing the existing number of checks that ensure when uploads do occur, they are correct.

SOTA API - The SOTA API requires ongoing work to deliver all of the API endpoints discussed.

HTML handling - There is inconsistent handling of UTF-8 and other non-UTF character sets that have found their way into things like summits pages.

Summit surveying workflow tools - As part of some of the bigger associations we’ve brought online recently, we have been experimenting with a few tools to help facilitate the process. It would be ideal if we can rewrite the current duct-tape-and-wire version with something more extensible.

It is important to note that several of these projects, if implemented in ‘the real world’, would take several weeks or months of full-time work. For giggles, I handed a rough outline to one of my colleagues, who is a Service Delivery Manager used to quoting these out for consulting projects. She reckoned about 6 months full time to do it all properly, priced in the low six figures. We are not full-time workers for SOTA, nor do we have that amount of funding available, so we won’t get it all done in 6 months, but we’ll make a fair whack of an impact on these over the next year.

SOTA MT IT Group Leader


Thanks Andrew and to all the other members of the IT group. You make an interesting point at the end about the time, effort (and cost) involved if this was done “professionally” (and that’s certainly not intended as a slur on your competency), rather than voluntarily.
Could I just add one comment about the business continuity that I did ask about a year ago, but didn’t get an answer. It’s important that the systems you discuss are able to withstand the loss of any individual (or group of individuals) for whatever reason, not just a tragic death. That includes the intellectual property rights as well as physical hosting etc. SOTA has reached the scale where it would be sad to lose features just because of internal rifts. I raise that concern from personal experience outside SOTA (yes there is a parallel universe out there populated by families, friends, work, sport and others that merely tolerate our madness).
Thanks again!

The IP one is an interesting question. There’s not a lot of IP that isn’t already controlled by the SOTA organisation, either through funding of the development work that was involved, or through donation of code, de facto or otherwise. RBNHole is GPL’d so that should be OK too.

The only outlier to that is the SOTA Mapping Project, which is entirely Rob’s work, and it is not my place to, nor would I want to, require him transfer copyright of that to us or release it under a non-restrictive license. That’s something for Rob to weigh in on, I guess @DM1CM?

That’s why I used the term ‘real world’ rather than ‘professionally’ :smiley: Arks and Titanics, as it were.

That answers my original question, thanks Andrew. I wasn’t intending to fan the heat of any other threads but it seems to me that there are a few “peripheral” systems - SMP, SMS spotting, RBNHole/gate …?

A perceptive statement if ever there was one.

Andrew and others,

Re SOTA API, can someone point me to this please, I cannot find it? I am interested in a web service/API that takes GPS or lat/long coordinates and maps them to the nearest SOTA summit, to enable a hand held GPS enabled locator project. It would be nice if it was able to determine activation zone boundaries. Just toying with an idea.

73 Paul VK3HN.

Hi Paul,
I’ll have to ask Andy @MM0FMF or Jon @G4ZFZ to enable API access on your account. As for that particular API service, nothing like that exists as yet. Nearest summit shouldn’t be too hard, but Activation Zone boundaries would require import of terrain data in order to determine the AZ boundaries and, while technically possible, is probably not going to be remotely accurate enough at the scale you’re hoping for.


Tnx Andrew. Neatest summit and mrtres to the summit would be good. Tnx vk3hn.

This post highlights once again all the work that goes on behind the curtain. A very well laid-out plan Andrew.

The single login will be much appreciated, I was talking about this with other members recently who were confused by the multiple logins required.

Eventually SOTA will become a failsafe “sum of its parts” in the meantime all I can do is wish you luck in the integration process. Thanks for the hard work gentlemen!