• Basic Contact Info

    General Information and PR

    Aaron Ault
    OADA Project Lead
    Senior Research Engineer
    Open Ag Technology Group at Purdue University

    Media Contact
    Joe Dager, ApRecs

  • Let’s Connect

  • We Respect You

    Please let us know a little about yourself and an OADA representative will reach out with information about the organization and how to get involved.

    There are many ways to contribute and benefit from the OADA Community. We look forward to exploring them with you.


Technical Summary & Road Map

Technical Summary of the OADA Approach

The following sections contain technical details and are written for architects and engineers.

To address the farmer’s data interoperability and security concerns, a set of common, extensible REST API specifications will be defined. Precision ag systems that want to take advantage of this data interoperability and want to securely access farmer data will build their systems to match the OADA API specification. While a precision ag system will create an implementation of the open source OADA API specification, the implementation itself is the IP of the entity implementing the OADA API. Building an implementation that adheres to the OADA API specification in no way requires the implementation to be open sourced. The open source OADA API specification is merely a vehicle to facilitate interoperability between both open and closed precision ag systems.

The REST API specification will focus on data exchange that allows data from any precision ag platform in any format to be easily transferred between platforms. The API will not be concerned with the details of the data format of the files being exchanged beyond including information about which kind of format they are. This will allow APIs to easily evolve over time with new features and still remain backwards compatible. Combined with the industry standard OAuth 2.0 authorization protocol and successor versions, the API specification will have common data sharing semantics that ensure only farmer approved trusted agents or vendors can have access to the farmer’s shared data. The API will have operations that allow data to be shared both permanently and temporarily as the farmer sees fit.

A verification suite will be created that can automatically be run against vendor implementations of the OADA API specification. Results of the verification suite will be used to measure a platform’s compliance with the OADA API specification and ensure interoperability across the industry. Development of the above will occur openly in the community for all to see. An open source agile development approach will be used. Code will be placed in publicly available source code repositories released under the MIT License for everyone to freely contribute and use.

The community will drive the ultimate roadmap and specific features of the API specification. Through this open, community-driven effort, farmers will get precision ag platforms that are able to easily integrate despite the diversity of data formats. Support for future, yet to be defined industry data standards will be enabled. An environment that facilitates the creation of innovative services that benefit the farmer will be created by lowering the cost of entry to integrate among precision ag platforms and by having common security mechanics.

OADA will naturally facilitate a discussion in the industry of what proper privacy and security practices are for ag data. Community guidelines will be developed that third party auditors can use to evaluate varying levels of OADA compliance, and the industry as a whole can use as a common language to properly and easily relate the ramifications of complex technical details. For example, OADA “level 1” and “level 2” compliance will have a definite meaning, and the industry can begin with that definition as a means to communicate and compare business practices.

Technical Roadmap

The features described here are a starting point and will eventually be finalized through involvement of the broader OADA technical community. A first draft of the API can be found on GitHub at https://github.com/OADA/oada-api-spec/blob/master/oada-api.raml

Building a common, extensible, interoperable REST API that allows data to be stored and transformed in any format requires defining a standard mechanism from which farmer data can be referenced. To simplify integration the API will expose the data through a file system paradigm. Farmers and external systems will reference farmer data through file paths and unique file identifiers. The underlying implementation of the API does not need to store files and paths: it only needs to provide the interface. A given implementation can use a distributed file system, database, or any other storage mechanism that works best for their needs. No detailed knowledge of the files’ underlying storage format will be required to store or transfer data. The API would initially have the following key capabilities:

  • Sharing that allows farmers to authorize permanent or temporary access to their data to an external precision ag system or trusted advisors through OAuth 2.0.
  • File Create, Read, Update, Delete – operations to read, write, and delete farmer data files
  • File Transformation – transformation operations to convert data between different precision ag data formats. It would be up to each OADA API implementation to report what format transformations it supports. A basic set of transformation drivers for known public data formats (shape, GeoJSON, KML, etc.) will be developed, and contributions from industry participants who want to provide drivers to their own file formats will be accepted.
  • File Metadata – the ability to associate metadata with the data file. Some lightweight OADA-specific metadata about file type and manufacturer will be required if available, but custom metadata will also be supported to enable individual implementations to add features as they see fit.
  • System Features – A set of operations to communicate which data formats and transformations the OADA API implementation supports.

An early draft of the API specification using the API specification language RAML
can be found on Github

Potential future API capabilities will include searching, synchronization, alerting, and streaming:

  • Alerting of events such as the arrival of new data so that a farmer’s prescription can be updated with the most recent data.
  • Synchronization among clouds.
  • Streaming to support capabilities such as writing and retrieving data in chunks as needed.
  • Search functionality would range from basic searches across metadata to spatial queries to identify data layers that fall with in a field boundary. Searching will support use cases that require identifying key data layers that need to be transferred from a pure data management provider to an ag analytics provider that is providing prescription services.

A reference implementation of the API specification in a yet to be identified programming language will be developed and maintained by the OADA technical community and hosted on GitHub.

Accompanying the reference implementation will be a verification suite. The verification suite will contain a set of functional tests to validate each feature of the API. The verification suite will be automated and can be run on a repeated basis to measure the compliance of any implementation with the OADA API specification.

Other potential community driven technical artifacts include transformation libraries that convert data between the different proprietary industry data formats and existing open standard formats such as shape, GeoJSON, etc.

Project Structure

Please refer to the Developer Guidelines for information about contributing to the project and the process by which code will be approved for inclusion in the project.