Event alerting - A holistic approach

by Dave Barter on

One of the great modern-day-moans goes along the lines of "Well nobody told me!". People expect to be informed in near real time of events that may affect their daily life. They want to know when their packages are going to arrive, when schools may be closed, when their houses could be flooded and when someone plans to build a huge great extension overlooking their back garden.

Many of these events are well covered and communicated. The delivery companies now have decent infrastructure for keeping us informed of the fact that our valuable package has been left out in the rain even though we were clearly in at the time. And for once the public sector are ahead of the game. Most local authorities have infrastructure for informing residents of new planning applications. Users sign up for email alerts and every day receive a list of planning applications that have been submitted in close proximity to their region of interest.

But I see a failing with many of these services. They're too vertical. By "vertical" I mean that residents can subscribe to planning alerts and not much else. What of they want to know about a pending missed bin collection? What if they're interested in local events? What if they'd like prior warning of a road closure or major building exercise?

These alerts all tend to come from different systems. Which mean a different set of subscriptions and credentials to manage. Consolidating these is hard and so it tends not to happen. As a result it's up to the member of public to go searching for the alerts they want and individually manage their subscriptions to them.

Fortunately, not everyone thinks that way. We've been working with the Royal Borough of Windsor and Maidenhead on an entirely different approach and believe we've reached a point where we can begin to operate alerting services that take a more holistic view of keeping residents informed.

Firstly, we untangled the problem of "verticals" and created a generic alerting service. This has simple principles:-

  • the service has subscribers
  • subscribers have areas and topics of interest
  • the system ingests Geospatial data (topics)
  • topics are matched to subscribers and alerts sent accordingly
  • templates are used to customise alerts

This means we can alert anyone about anything. We don't care if the alert is a planning application or a potential flood warning. We simply match it to the interested subscribers, pick the right template and off it goes.

As a result we're looking to expand the service currently sending planning,enforcement and building control alerts into all of the great things I mentioned above. One subscription gets you missed bins, local events, closed roads and anything else that we can find the subscription data for.

We've also changed the integration model.

Much of this alert data exists in disparate systems. Some is easy to get out and others are mystical engines of proprietary code that only Fred in IT can fathom if pressed. We quickly realised that asking Maidenhead to send us this data in consistent form would be hard. So we took a different approach and built a variety of data interfaces. Now we can retrieve alerts using the following mechanisms:-

  • a pull service, we call a Maidenhead API and retrieve the alerts ourselves
  • a push service, send us data conforming to our API
  • scraping, sounds horrible and it is, but we're able to scrape from website data if this really is the only option

In Maidenhead's case we've moved to the pull model. This works for both of us as they're pretty good at data extraction but don't want to have to run a polling service and some of the complexity that entails. So we do that instead, we manage pulling the data from Maidenhead, checking for new records and turning these into alerts. This removes significant burden from their internal IT and allows us all to focus on the things we're good at.

All of this is done using a set of APIs we constructed around PostgreSQL. We're really pleased with the end result as it's truly generic and integrates with all of our other services.

  • map views and analysis of alerts
  • simple online subscription management
  • custom workflow on alert receipt
  • interfaces with external systems

In the future we'll be able to open up the service to external parties to add their own alerts, for example:-

  • local interest groups publicising their events
  • coffee mornings or gatherings for the elderly/lonely
  • requests for help on a local basis
  • community clear ups

And let's also be clear that alerting can work anywhere. If you've got customers/users and they're interested in locations then you possibly have a need for alerting right now.

So if you have something that needs alerting and a community that you need to alert, you know who to call? Or should I say "alert".

Event alerting - A holistic approach

Contact us