Keywords

1 Introduction

As our population increases, so to does our production of food crops. This increase in demand for agriculture coincides with an increased demand for water resources. This has resulted in a continuous decline of aquifers, especially in Northern Texas and Oklahoma. Given the fact that our water resources are limited, it is in our best interest to allocate resources appropriately. Agriculture researchers have developed methods for more accurately determining irrigation needs, but these methods have previously been unavailable to the general public [4].

We report on an interactive web-application that is designed to put advanced irrigation tools into the hands of everyday farmers and crop scientists. We interviewed both types of users and found that they desired an application that was easy to use, quick in reporting results, and compatible with both computers and mobile devices. We also found that farmers generally don’t want to input precise location data such as their address or map coordinates. On the other hand, crop scientists and plant breeders require the ability to input exact location data. We used this field study data to determine our design goals and process. The web-application was designed to be easily accessible to inexperienced web users and offers both basic, and advanced irrigation recommendations. The basic recommendations utilize location data limited to the user’s zip code, whereas the advanced recommendation uses the exact latitude and longitude values for the user’s field. To test and further develop our application, we implemented a user study that incorporated heuristic evaluation, application guidelines, cognitive walkthroughs, and usability testing. From this we were able to isolate and fix several issues, which ultimately lead to a streamlined, easy to use, widely accessible web-application.

This paper is organized as follows: Sect. 2 introduces the system design, Sect. 3 describes the experimental setup, Sect. 4 is a discussion, and Sect. 5 examines the conclusions drawn from this work.

2 System Design

2.1 System Framework

To implement the system described above, we utilized Ruby on RailsTM (RoR). RoR is a web framework written in Ruby. It utilizes the model-view-controller (MVC) framework shown in Fig. 1. MVC offers Active Record database functionality, customizable web pages, and user interaction. RoR is exceptionally good for designing database-backed web applications due to its built in support the major database types. In our case, we chose to utilize PostgreSQL [1]. RoR is also open source software, which has resulted in community wide development of libraries. These libraries are collections of modules written in Ruby that can be easily incorporated into new or existing RoR applications. For example, our application utilizes geocoding and user authentication libraries to relieve some of the coding required while developing the application.

Fig. 1.
figure 1

Model-view-controller framework.

Full size image

2.2 Application Architecture

To describe the application architecture, we will begin with the database schema shown below in Fig. 2. There are four base models: crops, stations, Landsat, and users. Crops simply have a type (sorghum, cotton, or corn). However, each crop has a sub model associated with it called a KC coefficient. A KC coefficient is the ratio of evapotranspiration observed for a reference crop under similar conditions. There is a KC coefficient for each day of the crops growth. This is used in the irrigation recommendation calculations later down the line. There exists a station entry for each known station in Northern Texas. Every day these stations report on agriculture conditions for their area, which we have represented as the reading model. Daily readings can be found at the mesonet website for reference [2]. The Landsat model contains Landsat coverage metrics and their corresponding latitude and longitude values for Northern Texas. Last is the user model. This directly owns the farm and irrigation recommendation models, and indirectly owns the field model through the farm model. The user model contains standard user information such as username, email address, and an encrypted password. The farm model contains a farm name (to be easily recognizable), a zip code, the user ID of its owner, IDs of any associated fields, and the ID of the closest station. The closest station is found by performing a reverse geocode lookup using the provided zip code. Once a user has created a farm, they can begin creating fields. The field model contains a field name, the corresponding farm ID, a crop ID, the planting date, and an entry titled geometry, which is an instance of GeoJSON data. The final model is the irrigation recommendation. This model utilizes the reading, KC coefficient, and field (optional) models during its creation.

Fig. 2.
figure 2

Database schema

Full size image

2.3 Application Flow

When utilizing the irrigation platform, users begin by creating an account. With an account, users can either generate a basic irrigation calculation, or create a farm and therein field for more accurate irrigation recommendations. Basic irrigation calculations take into account crop type, planting date, and the nearest station. The planting date and crop type can be selected through the use of a simple drop down menu, and the nearest station is found by performing a reverse geocode lookup using a user-entered zip code (this is the same way the farm model associates a station with itself). When the user has input the necessary parameters, they can generate an irrigation recommendation. This is done in the following manner: for every day since the planting date, grab the corresponding station reading and access its potential evapotranspiration value (in both mm and inches). Then grab the crop’s KC value for the given day and multiply these two values. This gives irrigation recommendations in both mm and inches for every day since planting. These recommendations are presented to the user in an interactive graphical format as seen below in Fig. 3a. The recommendations can also be viewed in a table format below the graph as seen in Fig. 3b.

Fig. 3.
figure 3figure 3

(a) Irrigation recommendation graph, (b) Irrigation recommendation table

Full size image

If users choose the more advanced route, the program flow is slightly different. Users create a farm simply by entering a title for the farm and their zip code. This finds the closest station and automatically associates it with any fields added to the farm. With the farm created, users can create fields. When creating fields, users specify a name, the crop type, the planting date, and specify the boundaries of the field using a Google Maps interface as shown in Fig. 4. The map interface utilizes Google Maps JavaScript API and its Data Layer class. This class provides a container for geospatial data, which can be used to store and display GeoJSON data on a Google map [3]. The GeoJSON data generated by the boundaries shown in Fig. 4 can be seen in Fig. 5. The user can now generate irrigation recommendations for the generated field. This process differs from the basic irrigation calculations in the fact that it utilizes recent Landsat data. The GeoJSON data generated during the field’s creation is parsed and latitude and longitude values are assigned to each pixel in a manner similar to the scan line algorithm used in graphics. These latitude and longitude values are cross-referenced with the values stored in the Landsat model and the corresponding coverage values are pulled. These values, how they are determined, and how they are used to determine accurate KC values for the specified field, are outlined here [4]. Irrigation recommendations for every day since planting are generated and displayed for the user. These recommendations are displayed in the same manner as the basic irrigation calculations and can be seen in Fig. 3. Aside from the described pipeline, users can edit any farm or field, regenerate recommendations if necessary, view past recommendations, or delete old data.

Fig. 4.
figure 4

Google maps data layer interface

Full size image
Fig. 5.
figure 5

GeoJSON data stored in geometry field of the field model

Full size image

3 User Study

Our irrigation tool was evaluated using heuristic evaluation, application guidelines, cognitive walkthroughs, and usability testing. In a heuristic evaluation, UI specialists study the interface in depth and look for properties that they know, from experience, will lead to usability problems. Our heuristic evaluators were skilled UI professionals, with advanced degrees and years of experience in evaluating digital interfaces. It was through their evaluation that we were able to simplify the UI design as much as possible before putting it into the hands of inexperienced testers. We went through several UI design mock-ups before we were able to streamline the interface. We eventually settled upon a simple panel based UI and reduced necessary user input as much as possible. This went hand in hand with meeting our application’s guidelines, which are listed below:

  • The application must be compatible with both mobile and computer devices.

  • The application must be easily accessible to inexperienced web users.

  • The application must incorporate basic irrigation tools that limit the need for user input.

  • The application must offer the option to use advanced irrigation calculation tools for users willing to input precise location data.

These guidelines were originally developed during our field study, where we met with crop scientists and farmers in order to determine what they would like to see in an online irrigation tool. We ensured that the application guidelines were met through the use of the cognitive walkthrough method and usability testing. The cognitive walkthrough method combines software walkthroughs with a cognitive model of learning through exploration [5, 6]. In this methodology, the developers of an interface walk through the application in the context of core tasks a typical user would need to accomplish. The respective actions and feedback from the interface are compared to the user goals and knowledge, and any discrepancies between the user’s expectations and the steps required by the interface are documented.

For this evaluation we utilized professors of crop ecophysiology and precision agriculture from the agriculture departments at both Texas Tech University and Texas A&M University. Through this methodology we were able to identify a few issues early in development. The original map interface did not allow users to easily create a circular region. This is necessary as many crop fields are designed in a circular manner. We noted this and added in the functionality to lasso a section of the map by simply clicking a center point, and dragging to expand the radius of the circle. We also added the ability to pass in more parameters when creating a field. Crop scientists desired the ability to make notes pertaining to their field, which are unused in the irrigation calculations, but can help them with other analysis down the line.

Following the cognitive walkthrough testing, we moved on to usability testing. For this testing we used graduate agriculture students from Texas A&M. The usability testing was exceptional at finding recurring and general problems, and at avoiding low-priority problems. We found that occasionally, the map interface and other JavaScript elements would fail to load. This was actually two-pronged issue. The map interface was failing to load due to a new instantiation of the Turbolinks gem. This gem is a package for rails. “When you follow a link, Turbolinks automatically fetches the page, swaps in its <body>, and merges its <head>, all without incurring the cost of a full page load.” [7] The gem’s update included changes to function calls and had to be updated within our code. The other JavaScript elements that were failing were due to the use of an old build’s navigation bar. To correct this, we removed the old Superfish navigation bar and replaced it with a custom designed bootstrap navigation bar. We also found that users desired an easy way to remove any drawing they had made on the map due to mistakes. To correct this, we simply added in a button that allowed for the removal of any overlay that had previously been drawn on.

4 Discussion

Dr. Rajan’s previous work has shown that utilizing a KC value drawn from Landsat imagery is effective in estimating crop water usage [4]. She worked with the Texas Alliance for Water Conservation (TAWC) and its affiliates to test this. The team monitored three separate fields in three different conditions (fully irrigated, under irrigated, and dryland). Like our tool, they evaluated crop water usage from “standard weather observations from operational weather observing networks and readily available medium-resolution multispectral satellite imagery” (Landsat data). This is what allows the estimated crop water usage to be specific to an individual field, as opposed to the standard KC value approach which estimates crop evapotranspiration for a field in “standard conditions.” These conditions are never met and certainly invariant from field to field. As Dr. Rajan noted in her paper, “The Ksp (KC value derived from using Landsat imagery and weather observations) is well-suited for operational applications such as irrigation scheduling, where its use could contribute to water conservation by minimizing over-irrigation” [4]. This is exactly what we aimed to do in creating this application. We think that one of the most important findings of our work is that software developers and agricultural specialists can easily work hand in hand to develop new-age tools for the agricultural work force. This is an ingenious way to incorporate emerging technologies with an older industry.

5 Conclusion

The irrigation scheduling application discussed throughout this paper has succeeded in placing new age irrigation science into the hands of everyday farmers. We were able to meet our design goals in both ease of access and efficiency. This resulted in a tool that is helpful to both inexperienced and power users. Farmers can utilize the basic irrigation tool while inputting minimal personal data whereas crop scientists and specialists can utilize the advanced tool for more accurate irrigation recommendations. As we continue to improve our tool and move it past the beta stage, it is our hope that this work will serve as a foundation for the development of interactive irrigation software in other agricultural heavy areas. This would result in decreased water usage and directly contribute to our ecological sustainability. We believe the development of this tool can also serve as a guideline for the implementation of additional agricultural research tools. There is a great deal of research that has been done, but has yet to make it into the hands of the public. Creating online tools to allow public access to such research would do wonders for the agricultural world.