FARMs: A Geospatial Crop Modeling and Agricultural Water Management System

: To ensure agricultural sustainability and desirable environmental outcomes, stakeholders need systems-based model-driven decision support tools. The objective of this study was to develop a global scale web-based geospatial crop modeling application called F ood, A griculture, and R esource M anagement s ystem (FARMs), to simplify the application of the crop simulation model —Decision Support System for Agrotechnology Transfer (DSSAT) without requiring users to create input weather, climate, and soil ﬁles. FARMs was built based on open source Geographic Information System (GIS) technologies and DSSAT to allow for adaptive management through its ability to perform in-season yield predictions for alfalfa and maize, currently. Validation of FARMs against variety trial data in California was acceptable between measured and simulated yields for alfalfa. The work done in this study showed how a complex model like DSSAT can be translated into a useable web-based decision support tool for near-real-time simulation with the help of open-source GIS technologies.


Introduction
There are many crop management and related computer software developed for various purposes. Scientists have developed powerful biophysical or crop simulation model (CSM)s such as DSSAT [1][2][3], APSIM [4,5], AQUACROP [6], RZWQM [7], CropSyst [8], and SWAP [9] that are capable of predicting crop yield as affected by genetics, environment, management, and socioeconomics (G × E × M × S) [10] interactions. However, a recent USDA Irrigation and Management Survey [11] showed that less than 1% of growers in the US use CSMs to decide when to irrigate.
Lack of wide-scale adoption of CSM in agricultural operations and among the wider scientific community can be attributed to their complexity. For example, CSM usually runs in a desktop environment, which requires users to pre-and postprocess input and output data. In many cases, users must prepare weather and soil input data for the field of interest before running a CSM in a desktop environment. However, it is hard to get the weather and soil data for the specific time and location on many occasions. Even if those data are available, it is time-consuming and labor-intensive to organize the input data into the correct format for each CSM. In addition, the display of simulation results is not always sufficient for output visualization. For example, it is hard to find a CSM with geospatial capabilities to compare output results for multiple fields and crop management scenarios intuitively. Furthermore, running CSM itself can be complicated for some users, especially without science or engineering background. Additionally, most CSMs are designed to be operated in a forward mode, i.e., cannot be easily updated or interrupted during the simulation which limits the ability to update the model with new information gathered during the season. There has been many software or model development researches for decision support system with crop management. For example, there are web-based irrigation scheduling applications with GIS capabilities [12][13][14][15][16][17]. Furthermore, there are geospatial crop production applications or models, which has been recently developed [18][19][20][21][22]. However, it is hard to find a global scale web-based geospatial agricultural water management tool that considers the G × E × M × S dynamic interactions as well as environmental impacts such as nitrate leaching in a specific field. In comparison with the applications in the reviewed literature, FARMs can perform adaptive irrigation and fertility management at a global scale with the ability to perform in-season yield prediction as a function of management decisions and environmental conditions. An easily accessible web-based geospatial application-Food, Agriculture and Resources Management System (FARMs)-was developed to run CSM without requiring users to input weather, climate, or soil data, and to compare simulation output results intuitively using cutting edge data visualization tools for decision making for any field on the globe. Compared to traditional water management decision support tools that are either rule-based or empirical, FARMs allows the users to define unique problems more realistically in their fields using interactive GIS. This is accomplished by specifying each field's soil physical properties by automatically retrieving them from gridded soil databases or field measurements, specifying initial soil water content, nitrogen/phosphorus amounts, cultivar, and other seasonal inputs coupled with in-season and historical weather data pulled from gridded weather data products. FARMs will also provide the users with the ability of virtual monitoring of the crop growth throughout the season. This is particularly important for in-season decision support for frequent reviewing the effects of previous management decisions and past weather events on yield. For example, farmers, their consultants, or researchers will be able to evaluate the effect of making or delaying a management decision on crop development and future yield prospects based on seasonal weather from planting to the approximate date when a decision needs to be made, and historical weather data. This could have a significant impact on total inputs applied (e.g., water and nitrogen) and environmental impact (e.g., nitrate leaching). We currently lack geospatial decision support systems that can allow growers or scientists to make decisions that optimize inputs while minimizing production risks and environmental degradation.
DSSAT is one of the most widely used CSM, which supports the modeling over 42 crops [2]. The number of users, including researchers, educators, consultants, extension agents, students, growers, and policy-makers, is greater than 14,000 from over 150 countries [23]. Considering the size of the user group, FARMs is expected to have a large impact on agricultural communities. The coverage of National Aeronautics and Space Administration (NASA)'s Prediction of Worldwide Energy Resources (POWER) (these data were obtained from the NASA Langley Research Center (LaRC) POWER Project funded through the NASA Earth Science/Applied Science Program) [24] weather data and the Global High-Resolution Soil Profile Database for Crop Modeling Application [25,26] enabled the global coverage of the application.
The objective of this research was to solve the problems associated with difficulty in input data preparation for near-real-time weather and soil data, the inflexibility of output data visualization, the limited accessibility of CSM to a large number of users (e.g., researchers, extension specialists, growers, consultants, and other practitioners), and the limited ability of updating in-season parameters, using Open-Source GIS and software technologies. The geographical scope of the FARMs availability is any field on the earth. Currently FARMs only simulates Alfalfa and Maize, but more crops can be added. The simulations were conducted for Alfalfa for two fields in California. The results of the simulation for Davis, California, which gave better water productivity and forage quality than the simulation for Tulare County, California, was validated by comparison with observation data from variety trials. The user interface and software of FARMs described in this article is based on the time of simulation (June 2020) because they are updated peri-odically. Figure 1 shows the overall architecture of FARMs with major software components. Liu et al. [27] addressed the scientific use of Django, PostgreSQL, PostGIS, and OpenLayers well. In Figure 1, Django python framework [28], DSSAT, PostgreSQL Database [29], PostGIS spatial extension [30], and Geospatial Data Abstraction Library (GDAL) geospatial data toolkits [31] are the main software components used on the server-side of the FARMs application. FARMs has been built using the Django framework because Django supports fast development, security, scalability, and versatility [32]. Furthermore, Django is easy to integrate with multiple python geoprocessing modules including GDAL, shapely [33] and scipy.spatial [34]. Several components of themes and/or templates of D3noob [35], Miller [36], and Traversy [37] were modified and used partly for the design of crop management GUI templates. ISPRS Int. J. Geo-Inf. 2021, 10, x FOR PEER REVIEW 3 of 17 observation data from variety trials. The user interface and software of FARMs described in this article is based on the time of simulation (June 2020) because they are updated periodically. Figure 1 shows the overall architecture of FARMs with major software components. Liu et al. [27] addressed the scientific use of Django, PostgreSQL, PostGIS, and OpenLayers well. In Figure 1, Django python framework [28], DSSAT, PostgreSQL Database [29], PostGIS spatial extension [30], and Geospatial Data Abstraction Library (GDAL) geospatial data toolkits [31] are the main software components used on the server-side of the FARMs application. FARMs has been built using the Django framework because Django supports fast development, security, scalability, and versatility [32]. Furthermore, Django is easy to integrate with multiple python geoprocessing modules including GDAL, shapely [33] and scipy.spatial [34]. Several components of themes and/or templates of D3noob [35], Miller [36], and Traversy [37] were modified and used partly for the design of crop management GUI templates. OpenGIS Simple Features Reference Implementation (OGR) of GDAL was used as a main geoprocessing toolkit on the server-side to process vector data. In FARMs, OGR was used as both an independent executable file (ogr2ogr) or was imported as a module in a python program depending on the usage of the functions. The OGR was used for the creation and re-projection of shapefiles, the creation of field geometries, and the calculation of fields' centroids. PostgreSQL was chosen as a database as it is a free and open-source database, which can be easily connected to Django while supporting PostGIS, which is a powerful spatial extension. When a user creates a field in FARMs, the geometry information of a field is stored into the format of Javascript Object Notation (JSON) [38]. After the field information is sent to the server side, a table is created to upload the field's geometry data using shp2pgsql, which is the data loader of PostGIS. For this task, field OpenGIS Simple Features Reference Implementation (OGR) of GDAL was used as a main geoprocessing toolkit on the server-side to process vector data. In FARMs, OGR was used as both an independent executable file (ogr2ogr) or was imported as a module in a python program depending on the usage of the functions. The OGR was used for the creation and re-projection of shapefiles, the creation of field geometries, and the calculation of fields' centroids. PostgreSQL was chosen as a database as it is a free and open-source database, which can be easily connected to Django while supporting PostGIS, which is a powerful spatial extension. When a user creates a field in FARMs, the geometry information of a field is stored into the format of Javascript Object Notation (JSON) [38]. After the field information is sent to the server side, a table is created to upload the field's geometry data using shp2pgsql, which is the data loader of PostGIS. For this task, field shapefiles are created using ogr2ogr for polygon geometry, or using ogr and shapely libraries for circle geometry. In addition, soil and weather data for the field are stored in the database. When a user creates management practices, the management practices information are saved in the database as well.

Materials and Methods
For soil data, the Global High-Resolution Soil Profile Database for Crop Modeling Application [26] was used as the default. This soil data were developed by Han et al. [26] based on soil grids of 1 km [39] and ISRIC-AfSIS [40] to be compatible with DSSAT with a 5-arc minute resolution on a global scale [26]. FARMs extracts NASA POWER weather data from external web services using parameters shown in Table 1 when a user defines a new field or runs simulations on a new date. For the case of running FARMs on a new date, weather data are extracted only once for the first simulation. A complete list of parameters for using NASA POWER Application Programming Interface (API) for extracting weather data can be referred from NASA [41]. NASA Power API returns weather data for a centroid (longitude, latitude) of a field between start and end dates as predefined in the output format. Currently, the end date is configured as the current date in Pacific Standard Time (UTC-8) for daily weather data. The PostGIS functions shown in Table 2 were used to define the centroid. In addition, FARMs extracts 36 years of historical data and uses the most recent 30 years of data as future weather data beyond the end date for annual crops. An additional six years of weather data are extracted because perennial crops can require future weather data for longer than one year. The annual and perennial crops configured currently in FARMs are each maize and alfalfa, respectively. If any missing daily weather data are found (e.g., the data between the last available date and the very current date), they were replaced with long-term monthly averages. The portion of the growing season simulated using historical climatic data decreases as simulation time approaches the end of the season. When a user simulates the predefined field at a later date, FARMs updates weather data of the field automatically. In FARMs, JSON was chosen as an output format for weather data because Python JSON library [42] supports serialization and deserialization with convenient and reliable functions.
In addition to server-side programs, various javascript libraries were used in the client-side as shown in Figure 1. Table 3 describes major javascript libraries used in FARMs. Especially for geospatial capabilities, OpenLayers API was used as a mapping toolkit in the client-side programs. Ganesan [43] (2009) documented the integration of Django, Post-greSQL Database, PostGIS spatial extension, GDAL, and OpenLayers. OpenLayers API can visualize vector or raster formats of geospatial data by layering them in an orderly manner and can process those layers using various geospatial functions. For example, a polygon field is stored as GeoJSON format using the function writeGeometry() of OpenLayers' format.GeoJSON object when a user creates a field in FARMs. However, circular geometry was not found in GeoJSON's standard [44]. Therefore, a customized JSON [45] was used for a circular field as shown in Table 4. Those JSON variables are passed to the server-side to store field geometries in the database. Circular field geometries are common in many parts of the world where center pivot irrigation is widely used. Table 3. Major Javascript Libraries.

Name Main Usage
OpenLayers [46] Mapping and visualization by layering geospatial data Vue.js [47] Javascript framework for user interface application D3.js [48] Dynamic visualization of simulation results jQuery [49] Simple, versatile, and extensive event handling Bootstrap [50] Prebuilt templates for user interface components DataTables [51] User interactive table design and manipulation Feather [52] Dynamic design of collection from predesigned icons Popper.js [53] Elements positioning. Required for Bootstrap. Table 4. Creation of Field Geometry as JSON format.

Field Type Java Script Note
Polygon (GeoJSON) format = new ol.format.GeoJSON(); fieldJson = JSON.parse(format.writeGeometry(geometry); ol is OpenLayers object from ol.js Circle (JSON) fieldJson = {"type":"Circle","coordinates":[center longitude, center latitude], "radius":radius, "properties": {"radius_units": "m"}} Virtualandy [45] In FARMs main portal ( Figure 2) described in this article, Sentinel-2 cloudless [54] or USGS Imagery Topo Web Map Service [55] layer was used as a base layer depending on the location and zoom level, and a location search box was developed using Nominatim [56] for users to search the field of interest based on geographic names. Figure 3 shows the overall workflow of FARMs. Users create two basic input data, which are field boundary and crop schedule.
After a user delineates the field on the zoomed in base map, the user can define management practices ( Figure 4). The input parameters for this user interface are described in Table 5. The input parameters noted with an asterisk mark (*) can be selected from the Table A1, Appendix A. Currently, five maize cultivar groupings based on growing degree days (GDD) (2500-2600 GDD, 2600-2650 GDD, 2650-2700 GDD, 2700-2750 GDD, 2750-2800 GDD) and six alfalfa cultivars, based on Fall Dormancy rating (FD-3, FD-4, FD-6, FD-7, and FD-9) and CFIA, are supported in FARMs.
In FARMs, the purpose of specifying an expected harvest date is to determine if the simulation will include future event or not. Presently, the harvest date in the DSSAT input file is defined as 365 days from the planting date if the number of days from planting to the user-defined harvest date is less than 365 days. The purpose of this setting is to calculate the cumulative nitrate leaching for 365 days from planting to prevent FARMs from missing nitrate leached after harvesting during an annual (365 days in current setting) growth period particularly in regions with Mediterranean climates such as California where rains occur after the growing season and can leach residual nitrogen in the soil. This setting is not applied to alfalfa if the number of days between planting and the last harvesting date defined by the user is greater than or equal to 365 days. After a user delineates the field on the zoomed in base map, the user can define management practices (Figure 4). The input parameters for this user interface are described in Table 5. The input parameters noted with an asterisk mark (*) can be selected from the appendix Table A1, Appendix A. Currently, five maize cultivar groupings based on growing degree days (GDD) (2500-2600 GDD, 2600-2650 GDD, 2650-2700 GDD, 2700-2750  After a user delineates the field on the zoomed in base map, the user can define management practices (Figure 4). The input parameters for this user interface are described in Table 5. The input parameters noted with an asterisk mark (*) can be selected from the appendix Table A1, Appendix A. Currently, five maize cultivar groupings based on growing degree days (GDD) (2500-2600 GDD, 2600-2650 GDD, 2650-2700 GDD, 2700-2750   In FARMs, the purpose of specifying an expected harvest date is to determine if the simulation will include future event or not. Presently, the harvest date in the DSSAT input file is defined as 365 days from the planting date if the number of days from planting to the user-defined harvest date is less than 365 days. The purpose of this setting is to calculate the cumulative nitrate leaching for 365 days from planting to prevent FARMs from missing nitrate leached after harvesting during an annual (365 days in current setting) growth period particularly in regions with Mediterranean climates such as California where rains occur after the growing season and can leach residual nitrogen in the soil. This setting is not applied to alfalfa if the number of days between planting and the last harvesting date defined by the user is greater than or equal to 365 days.
Once the field boundary and management practices inputs are defined, the user can run simulations by selecting a field and management practices. Presently, the users can choose a maximum of either two fields or management practices. Although the resolution (10 km) of the default soil data is high for global scale, it is coarse for field-scale assessments. Therefore, field-scale simulation accuracy is expected to increase if users customize soil data to more accurate values. This can be achieved by updating soil parameter values [57] in the user interface table, which should be updated by only advanced users. Furthermore, users can update major soil parameters for Conterminous US (CONUS) using Gridded Soil Survey Geographic (gSSURGO) [58]. As shown in Figure 1, CONUS gSSURGO was uploaded to PostgreSQL database. For a selected point on gSSURGO polygon layer ( Figure 5), users can find the soil profile data in addition to the characteristics of soil compositions. Users can update the most significant parameters in global soil database soil input parameters (DSSAT column) for each input depth (5 cm, 15 cm, 30 cm, 60 cm, 100 cm, 200 cm) in Table 6 using the area-weighted average of relevant soil profile data (sSSURGO column) with available gSSURGO soil profile data, which includes each input depth. If any soil profile data (sSSURGO columns) in Table 6 is not available from gSSURGO, they are excluded when calculating the area-weighted average.  Once the field boundary and management practices inputs are defined, the user can run simulations by selecting a field and management practices. Presently, the users can choose a maximum of either two fields or management practices. Although the resolution (10 km) of the default soil data is high for global scale, it is coarse for field-scale assessments. Therefore, field-scale simulation accuracy is expected to increase if users customize soil data to more accurate values. This can be achieved by updating soil parameter values [57] in the user interface table, which should be updated by only advanced users. Furthermore, users can update major soil parameters for Conterminous US (CONUS) using Gridded Soil Survey Geographic (gSSURGO) [58]. As shown in Figure 1, CONUS gSSURGO was uploaded to PostgreSQL database. For a selected point on gSSURGO polygon layer ( Figure 5), users can find the soil profile data in addition to the characteristics of soil compositions. Users can update the most significant parameters in global soil database soil input parameters (DSSAT column) for each input depth (5 cm, 15 cm, 30 cm, 60 cm, 100 cm, 200 cm) in Table 6 using the area-weighted average of relevant soil profile data (sSSURGO column) with available gSSURGO soil profile data, which includes each input depth. If any soil profile data (sSSURGO columns) in Table 6 is not available from gSSURGO, they are excluded when calculating the area-weighted average. Therefore, FARMs addressed coarseness problem of default soil data for a field level by enabling customization of default soil data and updating default soil data using CONUS gSSURGO. Especially, integration with gSSURGO makes FARMs a precision agriculture system for CONUS because it addresses soil variability inside a field. Once a user starts a simulation, the management practices inputs, weather data, and soil data are written to DSSAT management, weather, and soil input files. Furthermore, the drained upper limit (SDUL) was used as the initial condition for soil water in the management file. If the expected harvest date is in the future, FARMs requires future daily weather data. In this case, FARMs assumes n (currently configured as 30) years of historical record as future weather data. As sequential processing of n instances takes a long time, the simulations are implemented in parallel computing using Python's Thread object in the threading module [59] to increase computation speed. The ability to automatically combine in-season weather data and historical climate data to predict the end of season yield makes FARMs a powerful tool for adaptive in-season management.  Therefore, FARMs addressed coarseness problem of default soil data for a field level by enabling customization of default soil data and updating default soil data using CO-NUS gSSURGO. Especially, integration with gSSURGO makes FARMs a precision agriculture system for CONUS because it addresses soil variability inside a field. Once a user starts a simulation, the management practices inputs, weather data, and soil data are written to DSSAT management, weather, and soil input files. Furthermore, the drained upper limit (SDUL) was used as the initial condition for soil water in the management file. If the expected harvest date is in the future, FARMs requires future daily weather data. In this case, FARMs assumes n (currently configured as 30) years of historical record as future weather data. As sequential processing of n instances takes a long time, the simulations are implemented in parallel computing using Python's Thread object in the threading module [59] to increase computation speed. The ability to automatically combine in-season weather data and historical climate data to predict the end of season yield makes FARMs a powerful tool for adaptive in-season management.
Two simulations for alfalfa were implemented to demonstrate the current capabilities of FARMs for Field 1 and Field 2. Field 1 (Figure 6a) was defined in Tulare County in California. The centroid of the field was located at approximately 36.359 N, 119.061 W. Field 2 (Figure 6b) was defined in Davis CA. The centroid of the field was located at approximately 38.543 N, 121.784 W. The management practice parameters were defined as shown in Table 7. For simulation, the month and date of the first year's cutting events were configured to be consistent with cutting dates from past records (2017 University of California Agriculture and Natural Resources (UCANR) Alfalfa Cultivar Trial [60]) as it included future events.  Two simulations for alfalfa were implemented to demonstrate the current capabili-ties of FARMs for Field 1 and Field 2. Field 1 (Figure 6a) was defined in Tulare County in California. The centroid of the field was located at approximately 36.359 N, 119.061 W. Field 2 (Figure 6b) was defined in Davis CA. The centroid of the field was located at approximately 38.543 N, 121.784 W. The management practice parameters were defined as shown in Table 7. For simulation, the month and date of the first year's cutting events were configured to be consistent with cutting dates from past records (2017 University of California Agriculture and Natural Resources (UCANR) Alfalfa Cultivar Trial [60]) as it included future events.

Results
In Figure 7, seven cutting events for 2020 and eight cutting events for 2021 are shown clearly. The styling of alfalfa forage yield timeseries was inspired by Jing et al. [61]. Time series of alfalfa forage yield can be used as a prediction of forage yield for each cutting. As seen in Figure 7 and Table 8, Field 1 produced a higher maximum forage yield on 1 March 2021 compared to Field 2.

Results
In Figure 7, seven cutting events for 2020 and eight cutting events for 2021 are shown clearly. The styling of alfalfa forage yield timeseries was inspired by Jing et al. [61]. Time series of alfalfa forage yield can be used as a prediction of forage yield for each cutting. As seen in Figure 7 and Table 8, Field 1 produced a higher maximum forage yield on 1 March 2021 compared to Field 2.
However, the water productivity of Field 2 was significantly higher than that of Field 1 based on the CPFs in Figure 8. In Table 8, the maximum water stress in Field 1 was higher than Field 2. This is expected because Field 2 is located in Sacramento Valley, which receives more rainfall compared to Tulare County in the San Joaquin Valley. For alfalfa, DSSAT outputs crude protein values, which is one of the many criteria used for assessing forage quality. When comparing crude protein of Field 1 and 2 in Table 8 and Figure 9, Field 2 showed higher crude protein values. Therefore, Field 2 is a better place for growing alfalfa in terms of water productivity and forage quality although field 1 in Tulare is better in terms of total yield production.  However, the water productivity of Field 2 was significantly higher than that of Field 1 based on the CPFs in Figure 8. In Table 8, the maximum water stress in Field 1 was higher than Field 2. This is expected because Field 2 is located in Sacramento Valley, which receives more rainfall compared to Tulare County in the San Joaquin Valley. For alfalfa, DSSAT outputs crude protein values, which is one of the many criteria used for assessing forage quality. When comparing crude protein of Field 1 and 2 in Table 8 and Figure 9, Field 2 showed higher crude protein values. Therefore, Field 2 is a better place for growing alfalfa in terms of water productivity and forage quality although field 1 in Tulare is better in terms of total yield production.

Discussion
This simulation results of field 2, which has better water productivity and forage quality, were validated using 2020 observation data (UC ANR Alfalfa cultivar trial [62]). Table 9 shows the mean yield (dry, tons/acre) values of 28 varieties for each cutting date from the 2020 yield data of UC ANR Alfalfa cultivar trial. The mean yield was calculated as 3641.16 (kg/ha) from seven cutting events. The total yield was 11.34 (tons/acre) (25,420.88 (kg/ha)). The total yield in the report (11.34 (tons/acre)) [62] is slightly different from the value (11.37 (tons/acre)) calculated using cutting values in Table 9 due to round off errors. The maximum total yield was found to be 12.59 (tons/acre) (28,223.00 (kg/ha))

Discussion
This simulation results of field 2, which has better water productivity and forage quality, were validated using 2020 observation data (UC ANR Alfalfa cultivar trial [62]). Table 9 shows the mean yield (dry, tons/acre) values of 28 varieties for each cutting date from the 2020 yield data of UC ANR Alfalfa cultivar trial. The mean yield was calculated as 3641.16 (kg/ha) from seven cutting events. The total yield was 11.34 (tons/acre) (25,420.88 (kg/ha)). The total yield in the report (11.34 (tons/acre)) [62] is slightly different from the value (11.37 (tons/acre)) calculated using cutting values in Table 9 due to round off errors. The maximum total yield was found to be 12.59 (tons/acre) (28,223.00 (kg/ha)) for CUF101 and the minimum total yield was 9.57 (tons/acre) (21,453.07 (kg/ha)) for CW 704 from this trial. The mean cutting yield was 1.62 (tons/acre) (3631.55(kg/ha)).  Table 10 shows the simulated forage yield of 2020 from Field 2 using 2014 weather data as future weather data, which resulted in the maximum forage yield. Although cutting events were occurred in the same months, cutting dates were different (minimum 2 days for Cut4 and maximum 9 days for Cut7). Especially, the last cutting date affects total and mean yield significantly. As the last cutting date was different between the simulated (19 October 2020) and observed data (28 October 2020), the yield on 28 October 2020 for simulated data was estimated by adding tops dry weight increase (∆Tops Wt., 329(kg/ha)) between 19 October 2020 and 28 October 2020 to the simulated yield (2305 (kg/ha)) on 19 October 2020 for the fair comparison as shown in Table 11. The differences of mean and total values between observations (Table 9) and simulations with the estimated 28 October 2020 value (Table 11) were both 10.25% taking observed values as criteria. Furthermore, the total value (22,814 (kg/ha)) calculated from Table 11 was between the minimum (21,434 (kg/ha), CW704) and maximum (28,223 (kg/ha), CUF 1010) of the observed yields. Although there were differences in simulation and trial environment (e.g., different planting date, different cutting dates, different varieties, and unknown irrigation schedules of UCANR trials), the simulated results from FARMs were satisfactory when compared to the observed value.
The first objective of this research was to solve the problems associated with input data preparation for near-real-time weather and soil data. This was solved by integration of NASA Power weather data and the Global High-Resolution Soil Profile Database for Crop Modeling Application soil data into FARMs using open-source GIS technologies. Especially, important DSSAT soil parameters can be updated using gSSURGO data to address the soil variabilities of a field for CONUS. The second objective of this research was to solve the problem of the inflexibility of output data visualization. This was solved by visualization of essential output information in a web environment. As FARMs is a web application, it is much more flexible to update output visualization compared to a desktop application, which requires update or reinstallation of the program on the user side. The third objective was to solve the problem of limited accessibility of CSM. As FARMs can be used in a web browser, users do not need an installation software package or powerful computer to run DSSAT. In this manner, FARMs increases the accessibility of DSSAT, which is one of the most popular CSMs. Most importantly, the last objective was to solve the problem of limited ability of updating in-season parameters when using CSMs. This was solved by using near-real-time weather data appended by thirty years' historical weather data as future data. Furthermore, users can compare the results from either different scenarios or fields using this weather data. From this feedback, users can adjust the amount and schedule of irrigation and fertilizer application. This in-season parameter update cannot be easily achieved by desktop version of CSMs. Moreover, there are hardly any global scale web-based GIS agricultural applications, which can guide irrigation automatically using near-real-time weather data to update dynamic crop simulations. In addition to the user-defined irrigation scheduling shown in the simulations, FARMs supports DSSAT's automatic irrigation functions for guiding irrigation scheduling based on the dynamic interactions between G × E × M × S in a given season. FARMs' automatic irrigation is very effective and powerful option for scheduling irrigation under erratic weather that varies from season to season.
Prior studies in the literature reviewed included web-based irrigation with GIS [12][13][14][15][16][17] and geospatial crop production application and modeling [18][19][20][21][22]. Compared to those studies, the new contribution of FARMs is enabling crop simulation (1) with DSSAT, (2) for global-scale application, (3) in a web-based GIS environment, (4) with automatic weather, climate and soil support, and (5) with in-season decision-making support at the same time. The previous studies addressed some of those merits but not all of them. The advantage of the methodology proposed here is that the user can perform complex crop model simulations using DSSAT, which is one of the most popular CSMs, for any field on the earth within an easily accessible web environment with GIS capabilities. For CONUS, users can update soil parameters using gSSURGO to address soil variability inside a field. However, this function does not support the rest of the world because gSSURGO used in FARMs is limited to CONUS. However, a user can still update soil parameters using FARMs' user interface if they have their own field measurements. The development done until now has several limitations. First, only two crops have been supported until now. However, more crops simulated by DSSAT can be added in the future. Next, the spatial resolution of FARMs weather data depends on the resolution of NASA POWER data. Currently, NASA POWER data have native 1 degree resolution with 0.5 degree interpolation/ replication [63]. Next, the resolution of the default global soil data is somewhat sparse (5 arc minutes) for the field level. The user will have to update soil data using the user in-terface or gSSURGO (for CONUS) if more precise soil data is needed. Global-scale soil da-ta, which has similar precision with gSSURGO, would be required to address within field soil variability.
The science behind decision support systems for crop management tends not to focus on easy accessibility and limits the practice to certain expert user groups. The easy accessibility of FARMs helps bridge the science and practice using web-based GIS technologies. In addition, the successful application of open-source technologies behind FARMs shows that agricultural decision-making systems can be built without commercial software components, which often interrupts bridging the science and practice because of financial burden. In this study, we filled the knowledge gap of how to integrate global scale weather and soil data automatically with DSSAT in a web GIS environment for users to make in-season decision for crop and water management.

Conclusions
FARMs runs DSSAT globally with near-real-time weather data. This was feasible by using NASA POWER API and Global High-Resolution Soil Profile Database for Crop Modeling Application with web GIS technologies. Currently, FARMs supports maize and alfalfa, but is capable of expansion to more crops supported in DSSAT-CSM. In addition, FARMs is periodically updated to include the latest version of the DSSAT-CSM model with new crop(s) as well as other models and capabilities. Users can compare the results from two scenarios in one field or two fields with one scenario intuitively with enhanced visualization. In addition, it is possible to expand the number of supported scenarios and fields. Depending on the crop types, the current output includes only essential but sufficient features including time series of biomass, grain yield, forage yield, water stress, nitrate stress, cumulative irrigation, crude protein, and cumulative probability function of yield, water productivity and cumulative nitrate leaching. More output visualization can be flexibly added in developer's side. As FARMs is a web-based application, it is easily accessible to users worldwide. Especially, the GIS capabilities of FARMs allows users to prepare weather and soil data for any specific field automatically. Finally, FARMs was developed using open-source GIS and other software technologies. The International Consortium for Agricultural Systems Application (ICASA), which was responsible for the distribution of DSSAT, considered DSSAT to be an open platform and supported open code policy [3], already. Clearly, the open-source strategy is far more flexible and costeffective in development compared to using commercial software. Our future studies in relation to FARMs include the addition of more crops, the integration of other CSMs, and enabling remote sensing capabilities for field monitoring. The beta version of Food, Agriculture, and Resource Management system (FARMs) can be freely accessed from https://ciswma.lawr.ucdavis.edu/ (accessed on 16 August 2021) after registration.

Data Availability Statement:
The data presented in this study are available in this article itself.

Conflicts of Interest:
The authors declare no conflict of interest.