is a cloud-hosted platform that gathers data on activities within a protected area in an integrated platform and provides near real-time visualization of that data on a map layer. Much of the data is location information for tracked animals, vehicles and aircraft, and for the rangers charged with protecting the ecosystem. More critically the system collects data about important events that occur, ranging from animal sightings and human wildlife conflict, to carcass discoveries or criminal activity in the park.
The point of it all is to collect activity data in one place, in real-time so that the protected area’s management team can quickly detect activities and identify trends that warrant intervention and make informed decisions on how to do so.
As we build EarthRanger, among our guiding principles is to keep the system simple and approachable. This is for two reasons. First, this is a system not meant to be a commercial money maker, but rather a purpose-built system for increasing effectiveness of teams that have limited capacities and razor thin IT budgets. Second, we hope that the longevity of the software is not reliant on Vulcan’s engineering investment.
These principles guide us to make thoughtful decisions about the tools and technologies we use in our solutions. Namely, to minimize the costs involved in developing and running the software.
Avoiding undue reinvention
Our engineering team is small, and we have lots of features in our backlog. It’s really important for us to concentrate our efforts in the right areas to make EarthRanger the most effective product possible.
Many of the things we build are seemingly conventional, with the occasional twist. Often, we find open source software that meets our needs, and we write glue code. Occasionally we need to invent something from whole cloth.
But then there are the circumstances when we find some open source software that comes close to meeting our needs – and that’s where we can decide to bootstrap a new feature, allowing our engineers to focus on the details that particularly suit our customers.
Put another way, we can move quickly to writing the feature-code our customers need
without having to first build all the plumbing and foundational components ourselves.
An Example: Report Types and Alerts
EarthRanger already does a good job of cleanly gathering information about the activities in a protected area. Have a look at the form below (Figure 1). An EarthRanger user will fill in this form with data reported from the field.
In this case it’s a Carcass Report
and you can see it collects some very carcass-related bits of information.
Figure 1: A Carcass Report Form. EarthRanger administrators can design their own forms, to collect whatever they like.
Other types of reports collect wholly different sets of data. An Accident Report
will collect information about vehicles and injuries while a Spoor Report
will collect information about found footprints, tools, waste or other anthropogenic disturbances.
This is a fundamental feature of what we refer to as EarthRanger’s flexible data model
. While we ship EarthRanger with a standard data model, a management team may choose to modify existing report types or add new ones.
This is key to advancing teams from using handwritten logbooks and Excel spreadsheets
to collecting data in a structured way that facilitates analysis and reporting.
Semi-automatic Report Alerts
Now that teams are regularly entering field reports into EarthRanger, we want to deliver valuable insights quickly into the hands of the people who make critical decisions on when to intervene and with what resources.
An upcoming release of EarthRanger will include a user-configurable alerting feature. With it a user will configure automatic alerts for reports that match some arbitrary conditions. These conditions that a user chooses are saved as Alert Rules
in EarthRanger, and they’re applied whenever reports are added or updated. When an event matches an Alert Rule, EarthRanger will send a notice to an email or SMS text according to how the user configured the rule.
With a term like Alert Rule
It sounds like we need a rules engine, right? That seems like a reasonable approach and the last thing we want to do is build a rules engine from scratch when surely there exists one that does exactly what we need.
Here are some key factors to consider as we determine what we need:
- EarthRanger administrators can define report data-models that capture precisely what they want in each type of report. These models drive much of the logic to allow users to create and edit reports. (I’ll spare you the details, but these models are ultimately represented as JSON Schemas.)
- When an EarthRanger user configures an Alert Rule, it allows selecting conditions that are based on the flexible data models.
- Since report type data models are flexible, we can’t know all the report attributes and values when we write the rule logic.
- We’ve built EarthRanger in Python and would prefer our alerting component to be as well.
After some brief research we landed on using a popular open-source library called business-rules
(originally produced by engineers at Venmo, it’s been around for several years and has been forked 130 times on Github).
As it turns out there isn’t a perfect rules engine that does everything we need and is viable right out of the box. While business-rules meets most of our needs, it does not support building rules to apply to our flexible data models. But it does fit nicely within our technology stack. And with a bit of glue code wrapped around it, we can support Alert Rules with fine-grained conditions over our flexible data models.
Take a look at the Alert Rule form shown below (Figure 2). It’s a form where a user can define the criteria for sending alert messages based on the contents of a report. In this case we’re configuring an Alert Rule for Carcass Reports and the user has elected to receive notices for found elephant carcasses, within one of two section areas and having an age greater than two days. This is a contrived example, of course, but you can see that the condition variables directly identify with Carcass Reports.
Again, just as we saw earlier in EarthRanger’s report entry form, the details (or in this case “conditions”) are driven by the flexible
data model tuned to management’s wishes.
Figure 2: Alert Rule Form. Now a user can define conditions for alerts where the variables are tied to the custom data model.
Nuts and Bolts
I won’t give you the code level details here, but instead just the essence of how EarthRanger benefits from having built it’s alerting engine on business-rules.
EarthRanger relies on business-rules to evaluate encoded rules against new or updated Reports. That’s the generic application of rules. And it frees us to focus on our very specific code for the care and handling of our flexible data models.
Lastly, some of those lines of code that we write may in fact be generic enough to contribute back to the business-rules library to be shared with others in the development community.
As you can probably guess, I’m really passionate about the inner workings of EarthRanger and how it gets built. The point of this post is to briefly educate you about a single EarthRanger feature and illustrate at least one approach we take to making the whole system viable.
In the end we’ve achieved our goals of delivering customer value at minimal time and costs. And we’re confident that as EarthRanger evolves, this new feature will be simple to understand and modify by engineers within or outside our team.
Thanks to the open source community, to Venmo for sharing business-rules
, and to the Vulcan family for funding and supporting the development of EarthRanger.