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!
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.
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.
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.
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:
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.
Our engineers are constantly working to improve our product and create features that allows our partner communities to utilize it to its full capacity.
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.