Gundi supports Rules, which are conditions that govern how data moves from a source to a specific destination. With Rules, you can filter or transform observations before they arrive, ensuring each destination receives only the data relevant to it.
What kinds of Rules are available?
Currently, Gundi supports:
Field Mapping Rules: These Rules let you reshape incoming observation data before it reaches its destination. Optionally, you can apply conditional logic: when a condition is met, a transformation is applied. For example, you might rename a source field to match what the destination expects, or assign a fixed value to a field when a specific condition is true.
In the future, Gundi will also support:
Device Whitelisting: Only forward data from specific devices to a destination.
Geographic Filtering: Only forward observations that fall within a defined geographic area.
and more.
Considerations
- For this first release, you can add one rule at a time, and the only supported type is "Field Mapping." More rule types are coming in future releases.
- To get the most out of field mapping, you'll need some familiarity with our API schema. We're improving the UX/UI in upcoming releases to make it more accessible to everyone.
How to create a Rule
- Navigate to your Connection from the Connections list.
- Open the Destinations tab.
- Find the destination you want to configure, and click the menu icon (⋮) next to it.
- Select Rules.
- Select “Field Mapping”
- Follow the on-screen steps to create your rule.
Example: Mapping Event Types to destination-specific values
In this example, the rule updates the event_type field on Events before they reach the destination.
The source system uses generic Event Type values like fire and deforestation. The destination, however, expects its own specific values (gfwfire_rep and gfwglad_rep). The rule handles this translation automatically:
| When source “type” value is… | Send this Event Type value instead |
|---|---|
| fire | gfwfire_rep |
| deforestation | gfwglad_rep |
If an Event arrives with a type that doesn't match any of these mappings, send a default value instead ( gfw_rep in the example below, see image)
This means the destination always receives Event Types in the format it expects, without any changes needed on the source side.
Continue Learning