Housser.is

John Housser, Digital Architect

Southern Straits Race Tracker

Screenshot
Visit Website

Background

In November of 2023 the organizers of the Southern Straits Race reached out to me to get involved in managing the technology for tracking the race. I’ve been a member of the club for a number of years, but only a spectator of the race. For the last number of years they had been leasing a satellite-communicator based system that provided location data from all of the boats racing for safety as well as spectating. That system was nearing end-of-life, so they needed to source a replacement.

The prime candidate was a smartphone-based system that required each competitor to download and operate an app that they would log in to and would return their location data to a central server. That platform then provided a publicly available map interface for race organizers and spectators to view the event with. The costs for this system would be substantially cheaper than the previous system, but placed a significant burden on participants for connectivity and reliability.

Other existing solutions also used satellite communicators, which don’t rely on cellular connectivity, but are dramatically more expensive and also burden competitors during the race with operations.

The majority, and increasing, of boats participating in events like this are also equipped with AIS automated tracking systems, which periodically broadcast the boat’s position over traditional VHF radio frequencies. This is generally used by vessels to see traffic in their area, but can be aggregated by ground- and satellite-based receiving stations. This race, and others like it, are now requiring all boats participating in the more exposed courses to be equipped with AIS transponders, and many others are already investing in this equipment for safety and navigation. Adoption will only increase as the costs of this technology continue to decrease.

Question

We needed a system that could collect location data from the entire fleet as accurately and timely as possible, that we could then deliver to race organizers in case of emergency and also display to spectators.

An ideal system would require minimal investment or operations by participants.

Solutions

While the entirely smartphone-based system would provide a fallback option, I wanted to explore whether we could leverage AIS infrastructure to collect information from those boats equipped. We would still have to implement a smartphone-based system for those boats without AIS.

First I had to determine whether there was a suitable AIS provider that would have adequate coverage of the racing area and type of vessels, prove reliable, and affordable. After exploring a number of providers, I selected one that appeared tomeet our needs, and would allow us to license their data per-day as required.

Product Design

Working with the event organizers, as well as a number of participants, we determined the essential functionality.

  • Central database to track participants, collect and retain location data from all boats
  • AIS data collector to retrieve periodic location updates
  • Smartphone app for data collection from non-AIS equipped boats (including offline-data capture for deferred reporting)
  • Web interface for organizing teams for emergency use cases
  • Web interface for spectating

Technology Design

AIS Collection & Aggregation

In an attempt to begin with the areas that had the greatest sense of unknown for me, I began with a focus on the AIS data collection. After testing various providers, we decided to proceed with leveraging the data from VesselFinder. It seemed to have adequate coverage of our racing area, an established API platform, and reasonable licensing options.

Developing a polling system to retrieve data from VesselFinder and store it in our own managed SQLite database with Turso using Cloudflare Workers and the Hono application framework was a fairly straightforward task.

Web Interface

Next up was to validate the usefulness of the data we were receiving. I created a web application with Astro that would retrieve the position data from the database and display it in a convenient map using the MapLibre GL JS library. During initial development the web application pulled data in real time from the database, but to reduce load on the database in production I generated static files of the latest data every minute. These files were then published to a global Content Delivery Network (CDN) for fast and reliable access.

Mobile Smartphone App

Race Track Architecture.Race Track Architecture.

We still needed to collect location data from boats that were not equipped with AIS transponders. So, I began design of a mobile smartphone solution. I evaluated several technical approaches.

First I had to immediately discard a Progressive Web Application (PWA) approach, though the distribution and operations would be incredibly simple, as unfortuantely there is no way to retrieve location updates when the PWA is not active (discussion).

I avoided pure native (Swift/Kotlin) as I have very little experience with those platforms, and didn’t want to be maintaining two totally separate products.

After building hybrid prototypes with NativeScript and Cordova (hoping to leverage my strong web platfrom experience), I had to discard those as there were too many issues and hangups with bundling/deployment/distribution.

Moving a bit closer to native I build prototypes with Flutter and React Native, eventually settling on React Native for its developer ergonomics and reliability.

Final Architecture

Race Track Architecture.

Technology of Note