Introducing the Forerunner Academy, a learning platform for floodplain managers
Explore now

Engineers' Corner: Breaking Down How Forerunner's Features Are Built

June 8, 2022
Susanna Pho, CFM

We typically post about Forerunner happenings and floodplain management resources on our blog page, but we have yet to highlight a key aspect of our daily work at Forerunner: software development. Like floodplain management, software engineering is not easy for the lay person to understand, but the crucial work of our engineering team is what enables Forerunner to support the work of our partner communities!

This blog post comes from a few members of our engineering team, working seamlessly from different states to create and maintain the software platform that you know as Forerunner. Read on to hear from Brian Zable, Elliot Young, Austin Ross, and Sam Lopes about their favorite Forerunner features and why they love them!

Brian Zable- Elevation Certificate Error Detection

Forerunner’s Elevation Certificate Error Detection Feature is a tool that highlights errors in user-uploaded ECs to verify information. It has been highly useful for many of our users, particularly those who deal with a high volume of floodplain development and those who participate in the Community Rating System program.

One of my favorite projects is our EC Error Detection feature. In short, we extract data from Elevation Certificates, then run it through a series of checks to spot common problems with the way the document was filled out. For many of our users, this feature catches common issues within Elevation Certificates and streamlines the CRS recertification process. This feature was a difficult undertaking that took many of us months to get out the door. It touched every part of our product and made us all better engineers for it. We shipped it over a year ago and I am still amazed at all the errors it finds and how much it improves our customer's day-to-day workflow by addressing EC errors in real time.

In terms of the engineering, we approached the error detection problem from a functional perspective. Having come from a purely object oriented background, I always needed a bit more experience with functional programming. With functional programming, we put more emphasis on transforming data rather than organizing data in structures that mirror real world concepts. Working on this project with our team helped improve my skills a lot in this regard.

I also love that this project touched a little bit of everything in our codebase. We had opportunities to refactor and improve a lot of our codebase, including converting a large amount of it over to TypeScript and increasing test coverage. Overall I felt this project set very good patterns for how we do work here and left a better codebase for our team to work in alongside many improvements to the product for our customers.

Click here to read more about EC Error Detection from the Forerunner Knowledge Base.

Austin Ross- Labeling Document Types

The interactive map is one of the most prominent features of the Forerunner dashboard, as it immediately displays important visual data when the user logs into their account. We recently added the ability for users to upload floodplain-pertinent documents to their dashboard and view them geospatially.

Until recently, the only document type supported and displayed on the map was the Elevation Certificate. However, our users spend time working with a wide variety of documents (like V Zone Design Certificates or LOMAs) that differ by community – being able to store them flexibly in Forerunner helps to streamline their work. Now, each account can have custom document types supported in their Forerunner dashboard and these documents appear on related properties.

While this change seems trivial only looking at the user interface, there were many steps involved to achieve this feature. A lot of the work focused on updating the existing document upload process to handle more than a default list of document types and, after this refactor, users were able to upload their documents under any personalized type. This was an important milestone since users could begin uploading different documents and forms based on their individual needs.

The next implementation was displaying all of an account’s document types on the map and this involved interfacing with Mapbox, our third party map provider. We use Mapbox for all our map features because, as developers, we seek out well implemented and maintained existing solutions to complex problems so that we don’t need to “reinvent the wheel” for. There are many other very important features that exist on the map such as FIRMs, parcels, and now, account specific document types. I feel accomplished listing these document types alongside everything else our map has to offer.

Elliot Young - Document Transcription Form Styling

On our application, users can view all of the data we extract for certain documents they upload. This extraction is essential because it means we can run checks on the data to make sure the document was filled out correctly, warning our users about errors or mistakes.

One of the projects I loved working on is one we haven’t released yet! We’re working on making our Elevation Certificate data transcription editable for users. Forerunner extracts data from Elevation Certificates in order to verify that documents are completed correctly (through the EC Error Detection feature that Brian describes) and so that our users can use the resulting data for GIS analysis. While the data transcription is very accurate, we can sometimes make a mistake (especially if the scan quality is poor or a surveyor’s handwriting is hard to read). Currently, users can only report an issue from the Elevation Certificate detail page if they find an incorrect transcription, but they have no way of overriding the extracted values themselves. Our work to bring certificate edits to users will save our users time because, if they find an incorrect extracted value on their processed certificates, they can manually adjust the value to the same value on the document. Essentially we are converting the extracted data section of the certificate detail page into a form!

As an engineer, I lean towards visual work. Styling different parts of the new edit form excited me because there were several new visual elements that had not been implemented before in our app. Some of the small details that I enjoyed styling were the subtle backgrounds and outline of the inputs that appear on hover and expand on click.

This was a fun problem to solve because of the background needed to ‘overflow’ beyond the boundaries of the row. When styling things in code, all of the elements on the page have an invisible ‘box’ around them so creating styles that appear dynamically and extend beyond the ‘box’ boundaries is a little tricky. Having a background color and a thin outline appear beyond the ‘box’ is even more complicated. I love solving little style problems like this and hope that those little interactions make our app just a little more intuitive and friendly for our users! I can’t wait for this project to become public so our users can start editing their extracted data on the new certificate edit form.

Sam Lopes- Coastal A Zone Determinations

A common, recurring challenge Forerunner engineers face is writing software to replace analog, physical operations done by local floodplain managers - such as computing inclusion or exclusion from a special flood hazard zone - with digital equivalents. These problems are complex by their very nature: human minds are capable of nuanced decision making which rarely, if ever, translates directly in to a straight-forward algorithm.

One such analog-to-digital conversion we’ve built here at Forerunner is the determination of Coastal A zone inclusion for a given community. The definition of a Coastal A zone is treacherously simple - FEMA designates it as the “area landward of a V Zone or landward of an open coast without mapped V Zones”. To further assist us, FEMA also provides us with LiMWAs (limits of moderate wave action) which can be used, among other things, to more clearly draw the boundaries around coastal A zones. The image below demonstrates this:

A human being can look at the above map and easily point out where the coastal A zone begins and ends - after all, it’s just the bit of dry land between the LiMWA and the V zone. Differently, a computer has an incredibly hard time determining this - the terms “coast”, “landward”, “V Zone”, “LiMWA”, and “area” are all things the computer needs to be taught. Fortunately, though, our engineers are a clever bunch and, armed with tools like PostGIS, computing Coastal A is but one stored procedure away*.

A very handy tool in every engineers toolkit is the ability to solve a problem by decomposing it in to a smaller problem, solving that problem, and then using the solution from this simpler problem as the input to a larger problem. This process is repeated until you produce the final result. We can tackle computing coastal A zones with this “divide-and-conquer” approach**, breaking the algorithm (i.e. the “recipe” the code will walk through to make coastal A zones) in to the following steps:

  1. Determine what could be part of a coastal A zone. This is simple enough: we know that coastal A zones are not V zones; rather, as the name implies, they are A zones, and so we can first aggregate all A zones from the community in question in to one massive A zone. This amalgam zone will be the only place within the FIRM that could possibly house coastal A zones, so we’ve massively reduced our geospatial search space.
  2. Cut up the large coastal A zone with the available LiMWAs. If you imagine the amalgam zone we created in step 1 as a flat piece of sheet dough on a counter-top, you can create this cut by carefully dragging a knife along the dough, from edge to edge, in exactly the spot where the LiMWA would be. At this point, all we have is two or more smaller A zones - we don’t know which one is landward and which one is seaward from the LiMWA, but we do know that one has to be the coastal A zone.
  3. Pick the segmented coastal A zone that is on the “right-hand side” of the LiMWA. In geospatial computations, a line is defined as a set of points between a starting point and an ending point. If you were to walk along the line from its starting point to its ending point by traversing every midpoint with your right hand outstretched, everything your right hand pointed to would be the “right-hand side” of the line. LiMWAs depend heavily on this line property - they are purposefully built so that the right-hand side of the LiMWA will be the seaward side, so we pick the A zone chunks that fell out of step 2 and touch this right-hand side.

And there you have it! We’ve successfully computed coastal A zones by breaking apart a large problem in to smaller subproblems that built upon each other to arrive at the answer. This is but one of the many complex algorithms we’ve built during my time at Forerunner - our problem domain is rife with these kinds of fun challenges and our engineers are always happy to tackle them.

  • A stored procedure is a code that is saved in a database so that it can be reused multiple times
  • This isn’t a perfect example of “divide-and-conquer” from a purely theoretical computer science perspective, for those of you looking up the Wikipedia definition. “Divide-and-conquer” algorithms usually have an element of recursion, where the software calls back in to itself with a smaller piece of the problem pie until the pie is gone. Our coastal A algorithm has no such recursion. For more information about recursion, consider reading “Gödel, Escher, Bach: an Eternal Golden Braid” by Douglas Hofstadter. Perhaps also read about the myth of the ouroboros, although that one is less practical for computing purposes.

Our engineers are constantly working to improve our product and create features that allows our partner communities to utilize it to its full capacity.

Sign up for our newsletter!

Receive a monthly update from us with news, product updates, and resources from our team.

You can unsubscribe at any time. View our Privacy Policy.

Oops! Something went wrong while submitting the form.
Download the Whitepaper
Oops! Something went wrong while submitting the form.
Register for the Webinar
Oops! Something went wrong while submitting the form.

Ready to increase your community’s resilience?

Request demo
Sign up for our newsletter!

You can unsubscribe at any time. View our Privacy Policy.

Oops! Something went wrong while submitting the form.