Skip to content

The story of CoronaFriend

From idea to launch in two weeks

Gary Gale, CTO, Kamma

By Gary Gale

CTO, Kamma

 

Like so many projects, the starting point for what would become CoronaFriend was the innocuous question “can you put that on a map?”. Unlike so many projects, the answer was “actually, yes, we can”.

The real starting point for CoronaFriend was a discussion between two CEOs who were stuck in departures, trying to catch a flight back to the UK just as the coronavirus lockdown was starting. Orla Shields from Kamma and Phil Hewinson from Would You Rather Be were discussing the idea of dropping leaflets through people’s front doors, to reach people who needed help with food shopping, medical supplies or were lonely.

The idea was, could a map be built that allowed people to say they had leafletted a road in their neighbourhood and also to see which roads hadn’t been covered, either partially or at all. And so, I was asked … “can you put that on a map?

As the adage goes; given enough time and enough resources, pretty much anything is technically possible. But we had very little of either and so the team from Kamma and then other volunteers from the geospatial community cut as many corners as we could to get CoronaFriend up and running.

We decided quickly to use as many free services as we could to collaborate; Slack for conversations, Google Hangouts for video conferencing and GitHub for storing the code.

We also made the key decision to use the tools and the technologies we already know to build out the project at pace. For the front end we used vanilla HTML and Javascript with jQuery, based on Bootstrap for out of the box responsive capabilities and we planned to use Leaflet as our Javascript mapping toolkit. We needed an API, so we quickly built one with PHP, based on the Slim API framework. We needed a data store with geospatial capabilities, so we used PostgreSQL with PostGIS. We needed SSL certificates, so we used Certbot and the LetsEncrypt project.

Then we needed data, both for a base map and to enable us to visualise the UK road network. We’d made a decision early on that we’d use a vector base map, if at all possible, to take advantage of smaller size and so the faster download and rendering of vectors over raster map tiles.

I’d been a massive fan of the OS Open Zoomstack vector tile set since I’d played with it during beta preview back in 2018. Amongst the many and varied decisions that we’d made early on, we decided to support the UK initially and then, if uptake took off, expand wider. Thankfully there’s already a well-documented vector tile server for Open Zoomstack, plus a handy guide to using Mapbox GL with Leaflet, albeit with an experimental Leaflet plugin. But this allowed up to get a base map up and running in minutes.

Early on in the life of the company, Kamma were part of the Geovation programme and as graduates from Geovation, we still keep in close touch with the team there. We were granted early preview access to the new OS Data Hub, which made searching for, downloading and experimenting with open data significantly much quicker and easier than the previous ways of getting hold of OS Open Data. After a quick trial, we decided on using OS Open Roads as our UK road network data set. It was the most current data set we could find that was also the easiest for us to use (of course, we know there are other open data sets we could have used speed was of the essence). The supported download formats, both Shapefile and GeoPackage, allowed us to download and then quickly and easily push the data into our PostGIS instance, with a single GDAL command line invocation and we were almost ready to be up and running.

After some experimenting with getting the road network onto the base map, via Leaflet’s built in GeoJSON layer, we adjusted the API to firstly only render the road network below a certain zoom level and also to only return the roads which were fully or partially contained inside the map viewport to speed things up. We also made heavy use of PostgreSQL’s inbuilt JSON functions, to offload the creation of our GeoJSON response payloads to the database server, rather than the API code base.

Screenshot of CoronaFriend

After just over a week and a half’s worth of work, we’d moved from an initial idea through to something that was working, albeit on our own machines. Thankfully everyone involved from the technical side of the project was either using a Mac or a Linux machine which meant that repositories for all the tools we were using were easily available and installable. The final technical hurdle was where to host the project.

Many of the big names in tech have donated time, resources and money to helping projects that are trying to do their bit in the response to the Covid-19 crisis. Thanks to the generosity of Amazon’s AWS COVID-19 Disaster Response Support Program, we were able to take the AWS knowledge we already have in house and easily spin up a scalable cloud hosting solution with automatic build and deployment straight from our GitHub repositories.

Looking back over two weeks of full on and frantic geospatial endeavours, several things have been very much apparent.

Firstly, the adage mentioned at the start of this post deserves a corollary, in the form of “given enough time, resources and availability of data, pretty much anything is technically possible”.

Secondly, without the support of individuals and their companies, without the organisations who provide open data, in a usable form, and keep it current and updated and without the generosity of companies and their staff to make services such as vector APIs and cloud hosting available in extraordinary times, none of what makes up CoronaFriend would have been possible.

The observant among you may have noticed that we’ve talked about the UK throughout this piece, right now CoronaFriend only really works for England, Scotland and Wales, which most definitely isn’t the whole of the UK. For many reasons, Northern Ireland’s roads aren’t in the OS Open Roads data set as Ordnance Survey of Northern Ireland covers that part of the United Kingdom. But there’s open data there too, in the form of the OSNI Open Data 50K Transport Line data set, which will be coming on stream into CoronaFriend just as soon as we’re able to convert and normalise the data, so it was be easily incorporated.

Finally, massive thanks and appreciation is due to everyone who helped turn a conversation into an idea and an idea into something that’s online, publicly available and which works. It’s not perfect and should still be very much considered a minimum viable product, but that’s OK for just two weeks. You all may not be mentioned by name, but your contributions have made all the difference.

Gary Gale is CTO at Kamma. He leads on engineering and products in industries where data and software combine to create exciting and next generation products and where devices connect with SAAS and PAAS environments.