Getting to the Root Cause of Incompatible Ag Data
In my role as Portfolio Manager at AgGateway, I am afforded a unique perspective on the agricultural data landscape. In any given week I help facilitate meetings with a wide range of topics: GNSS accuracy of field boundaries; accurately documenting lab test methods for manure; data standards for irrigation; or how to uniquely identify a grower for contracts and seed deliveries.
This diversity in topics also brings in a variety of companies and individuals that take part, sharing perspectives, knowledge, and struggles within their organizations related to data. I have the privilege of learning about not only the different topics, but also the perspectives, headaches, and solutions all these different people and organizations experience.
One common thread that has been running through discussions for a while now is environmental reporting. Originally perceived by many people in agriculture as a passing fad, it is coming up more frequently and in more places. Whether for documenting carbon offsets, sustainability practices, nutrient management, water use, or verifying climate-smart commodities and sustainable aviation fuel, there is widespread and sustained interest. A lot of people are trying to find and standardize the data needed from farms to document these practices and their effect on the broader environment.
I have seen other topics like blockchain, drones, and telematics hit their peak on the hype curve to settle out into a more rational level of use and adoption. This environmental reporting seems to be a little different animal – different aspects have peaked and drawn venture funding for things like carbon credits and soil amendments. But the overall trajectory for just finding and organizing data for quick, easy, and accurate documentation of what happened on the farm is not a hockey stick on the graph, but a steady line to the upper right corner.
MORE BY BEN CRAKER
Through AgGateway efforts and tools like ADAPT, or In-Field Product ID, as well as other industry standards and projects, the ability to move data accurately and efficiently from system to system, while not perfect by any means, has greatly improved. And with this improvement people are starting to realize there are some other fundamental issues besides interoperability hampering both precision ag tool adoption and participation in environmental programs. This difficulty is the result of several issues, none of which is really the classic interoperability complaint of one system not “talking” to another. Often the issues are with the data itself. Below are five examples that illustrate my point:
- Missing metadata. Many programs require information about what type of operation was performed in a field. However, very few pieces of agricultural equipment log what implement is attached to the tractor or what configuration it is in. Is it a no-till planter or conventional? What type of tillage operation was performed? Was an offset disc used or a vertical till tool? Was the date, year, or season for the operation captured accurately?
- Missing parameters. Not all OEMs log the same data in the files their machines generate. It is great to know what the seeding rate is, but what was the fuel consumption or engine load on the tractor during planting? Reporting something seemingly as simple as how much fuel was used to grow a crop can be nearly impossible to figure out, and guesses have to be made based on assumptions using a percentage of the total fuel purchased in a year.
- Missing product information. For years anyone that has worked with data generated from farm equipment knows “1” is the most planted variety and most common chemical or fertilizer applied. During the heat of the season not every machine operator takes the time to type in the actual seed variety they planted, or the actual mix of crop protection products in the sprayer tank, or how much of each product was actually loaded in the feed mixer. Trying to go back and figure out what was in a machine gets exceedingly difficult, especially if the person looking at the data is a step or two removed from the person that actually loaded it.
- Questionable data quality. When was the last time the machine was calibrated? Was the machine set up with the correct dimension and lead/lag times? Was the right crop even selected? Is this a field of corn that had an issue and only yielded 60 bu/ac or is it a good field of beans? Even just understanding the units of measure can often be difficult. Again, if the person looking at the data was not directly involved in the operation, trying to piece together even these simple bits of information can be time consuming and difficult to track down.
- Data archival and provenance. Is there an actual record of the “raw” files that came off a machine somewhere? A binder of printed yield maps is great but will require manual data entry. Is the data coming out of a system after it was processed? Almost every software tool will “clean” raw data from a machine to remove data points that don’t look quite right, but what thresholds were used to determine if points were bad data, what math was used to aggregate or average out data points, was it post calibrated using other information? These variances are what drive inconsistency and are the reason why no two systems will generate the same number for average yield/product applied, or even area in a field for that matter.
All these issues are not problems with the systems trying to interact with each other. Some are things the farmer, operator, or service provider needs to invest a little in time up front to ensure proper documentation downstream. If farmers want to capture added revenue or market opportunity by having the data needed, they need to put the same focus and effort into ensuring they prepare for the best data possible, just like they do for any other crop.
Other issues are opportunities for equipment manufacturers to put more focus on logging the correct information and make it easily accessible to their customers. Some machines may not log all data together but have separate “machine” and “agronomic” data paths. This results in users needing to track down and export from different systems to get the complete data set from a machine. This distinction between data types a machine generates can limit the utility of data, and make extra work to report on what happened in a field. For example, most people would assume engine load is strictly a machine data parameter, but if it is coming from a machine pulling a tillage tool it could be used to identify areas of a field that had more compaction than others. Similarly, while most would see yield as agronomic data, if one’s goal is to optimize the performance of a combine it would be pretty important to know how much yield is flowing through the machine to see if the ground speed and engine load are within the expected range.
Ultimately, the data needed to report into the various environmental programs provides guidance on what machines need to log and make available, as well as what information farmers and machine operators need to make sure information is entered correctly in the terminal at the start of an operation. To capture the full value of data, we as the industry need to make sure we are doing the right things up front to ensure accurate, understandable data is available to the organizations asking for it downstream.
AgGateway does have several projects going to help address some of these issues and make it easier for the operator to ensure the right data is captured. Some solutions are ready for equipment manufacturers and other companies to implement to make lives easier as more and more people are focusing on environmental reporting. If you’d like to learn more about these ongoing projects and available solutions, feel free to reach out to me at [email protected].
Subscribe Today For
