Fire Brigade Asset Coverage Map

Live menu + incidents
Ward risk levelsWard boundary coverageRoad coverage

Technologies used:

  • C#, WCF, ASP.NET, JavaScript, HTML, CSS
  • OpenLayers
  • Microsoft Team Foundation Server
  • Microsoft Test Manager 2010

Project status: Shipped

In September 2012 I began working at Seed, a software development company owned by Hull University that lets MEng students benefit from real commercial experience in the software industry. At Seed, I worked in a team of four to develop an asset coverage map for UK fire brigade services, so that they can see where their fire appliances can reach within a specified period of time.

The project started in September and was shipped to Cleveland Fire Brigade in May, where it has been set up in the control room to inform staff when there is a gap in coverage. In the future the system will be taken on by another development team and adapted to suit other fire brigades.

The coverage map has two primary purposes. For staff in the control room it serves as a birds-eye-view map of the whole county, and also informs them when no tenders are available at a particular station, so they can quickly send an available tender to that area. For the risk and performance team the coverage map includes a snapshot mode, where the user can freeze frame the current coverage map and manipulate the on-screen assets, so that they can simulate hypothetical situations.

The browser-based map has been built using OpenLayers, a free JavaScript library for rendering maps in a web browser. The server fetches road network and asset data from several databases, runs a modified implementation of Dijkstra’s algorithm to calculate where each asset can get to, and passes that data to the browser when requested.

We managed the project with the Scrum development methodology, which is a process designed to minimize management overhead and give more control over the project to the development team, rather than Waterfall’s trickle-down approach. This has given the team a lot of creative freedom in how we designed and implemented the system; the only decision made about the project before the development team was brought on board was a single paragraph stating what the final release should be able to do, and the requirements changed significantly over the course of the project. The team held regular meetings with our customers to keep them informed about the progress we’d made, and also to bring them in on the project and prioritize our next steps.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s