Results Carbon Hack

On the 21st and 22nd of March, two teams deepdived data for carbon sequestration on the experimental farm De Rusthoeve in Zeeland for 32 hours. The hackathon was part of the search for a user-friendly tool that is easy to use and provides farmers insight into the carbon sequestration on their farm. The Carbon Hack, part of the Ploutos project, was organized by Farmhack and ZLTO.

At the Carbon Hack we explored the use of machine and satellite data for affordable monitoring of C-storage by farmers. There are two ways in which these data might be useful:

• Defining parameters to feed the Roth-C model for carbon storage modeling.
• Recording of on-field measures that promote C-storage (an automated log or record of farming activities). 

During the hackathon we explored how you can use raw machine data to make automated farming records, and whether is was possible to fill data gaps by including satellite data in further analysis and decision making.

Although still very preliminary, the shared result of the hackathon is that teams felt the combination of these two data sources is potentially very powerful. In this blogpost you’ll read about the results of the two teams. 

Team one: Track the tractor 

(Teammembers: Henk, Stephan, Teun, Akshay, Sven)

Part of the team inventorized parameters to feed the roth-C carbon monitoring model. For each parameter they indicated how effective they could be sourced from machine or satellite data. The green parameters were deemed most important to focus on. They made a similar overview for a list of possible measures that farmers can take to promote carbon storage. 

Although the combination of machine and satellite data is promising, not all relevant data can be easily sourced. Eg. the event that the tractor ran over the field applying manure can be detected, but does not tell us the quantity or type / quality of the manure. The same goes for crop protection activities and also for yield.

The other part of the team worked on translating machine data into a log of farming activities. They designed a data pipeline that could feed into the BBWP (or other carbon tools). They processed the machine data to derive events on the field level, to identify when there was an activity on a particular plot. Based on available context data the type of machine and therefore activity could be identified. Knowing what machine was present during the activity, the available CAN data could be used to verify that the machine was actually used, instead of just attached to the tractor.

It became clear that the basic context is easily detectable using tractor data, but that there are some other important values such as yields, or amount of applied compost or manure are not easily derived. Mainly because of missing sensors, although it is expected that in time tractors and implements will get smarter and provide such additional data.

Satellite Data

(Teammembers: Sebastian, Niels, Nikolaj ,Soufyan, Nick, Kees)

Can we identify farming activities just from looking at satellite data? That is what the second challenge was about. Looking at NDVI data, a proxy for biomass, which in turn is a factor (together with others) for carbon produced and possibly stored. If we can identify events like sowing, applying compost, harvesting, we could validate the same events as identified from machine data (in challenge 1). 

The aim was to create an automated record of significant crop activities. Such a record would be useful for all kinds of applications, one of them detection of carbon storage measures that farmers take. In the present rewarding scheme, such measures in itself are a basis for being rewarded. 

Now why would you want to do the same thing -identifying farming activities- twice? Basically to combine the two to be more robust. Both machine data and satellite data suffer from gaps, because of a loose plug or a different machine coming into the field, or from clouds in the case of satellites. If you combine the two data sources you can validate and complement. Gaps in machine data can be filled in by satellite data, and vice versa. 

The team first made an inventory of data sources. To limit size, some filters were applied: 

• clipping the data for the 1 field that was indicated, an arable field in the Hoekse Waard. 
• Applying the time slot from October 2018 to 2021. 
• A cloud filter to use only if  less than 10% clouds.

Potential sources were: 

• Trekkerdata.nl for a record of dates of farming activities from machine data

For satellite data:

1. AgroDataCube, for which Boerenbunder.nl can be used a viewer. Here other useful data is stored as well, such as crop history, soil characteristics, etc. 
2. Satellietdataportaal
3. Google Earth engine

In the end the Google Earth engine was considered the most useful. Ease of extraction was an important factor and prior experience using it helped with that. After the data was successfully gathered, pattern finding started. The initial plan was to find and identify anomalies, but the plan changed and instead three methods for clearing up the data were applied to the time series: smoothing, windowing and clustering. 

This yielded a graph that when paired with the provided farm activity data for sowing and  harvesting actually made good sense. The next step would be to train an algorithm to automatically read the data and to combine it with machine data to provide a robust automated farming record. 

Conclusion

The results were judged by Auke Sytsma (Founder of Trekkerdata.nl), Luuk Wezel (Climate Program Leader ZLTO) and Christoper Brewster (TNO).  It was however a collaborative event, so it was hard to appoint a winner. It was the second team however that was judged to have the better pitch, explaining the computational steps they had taken.  

Thanks to the enthusiasm of the teams and ZLTO’s hospitality it turned out to be a fruitful two days. The machine & implement combination is very promising. It does still need a lot of work to make the data applicable for use cases such as carbon farming and offer a robust, scalable and affordable system to automatically record farming activities.

I would like to sign off with the recommendation to all carbon hackers out there, to take the following consideration of Teun Biemond (aESTI) to heart: “the reliability of credits is essential for the revenue model of farmers. Less will be paid for credits of questionable quality (no guarantee that that amount of CO2 eq has actually been removed from the atmosphere). Worse still, they erode potential buyers’ confidence in agriculture as a climate partner. As a result, we are not only shooting ourselves in the foot in the short term, but certainly also in the longer term.

It is important to realize those extremely reliable credits with the lowest possible cost level (and therefore also administrative burden). That is why it is so important to make optimal use of available data (especially if it is already available or can be expected). It is important that we are not going to make the data models exclusively for the Netherlands or NW-EU; the voluntary carbon market in a global market that until now has certainly not been determined by the Netherlands.

And if we can reduce costs with machine data (eg sampling less frequently or less intensively) and whether we can increase reliability with on balance a higher quality/cost ratio of the carbon credits, then this is very worthwhile.”