DOI: https://doi.org/10.52939/ijg.v20i4.3157

1. The planting site should be suitable for the chosen garlic variety. This includes considering factors such as soil type, irrigation, altitude, temperature, humidity, and rainfall.
2. Soil preparation should involve loosening the soil, liming if the soil is too acidic, creating drainage ditches, and applying fertilizers.
3. The planting time, or planting season, should be at the beginning of the dry season. This is because garlic struggles to thrive in waterlogged conditions. Garlic cannot be planted at any time; it requires specific timing. Generally, garlic has specific growing conditions as presented in Table 2.

Table 1: List of garlic growth variables

Table 2: Garlic growing condition classification [4]

It outlines temperature ranges conducive to garlic cultivation within each suitability class, along with rainfall patterns and drainage conditions essential for optimal growth. Additionally, the table addresses soil texture, depth, and peat thickness necessary for successful cultivation. Maturity levels of the soil, soil fertility, and nutrient retention are also presented, along with factors such as alkalinity and sodicity. Hazards like sulfic material depth, erosion, and flood risks are evaluated, providing insights into potential challenges. Lastly, the table includes information on land preparation, emphasizing the presence of rocks and their impact on cultivation practices. The information contained in Table 2 will be highly useful in determining the classification of land suitability for garlic. For further details, the classification calculation will be explained in section 3.1.

2.3 System Architecture

The system to be developed implements a client-server architecture. In general, the three main components of the system consist of the backend service, frontend service, and mobile app. These three components are connected through Rest API as mentioned in [22][23][24] and [25. The On-Premises server serves as the location where the backend runs. The backend service runs on the on-premises server using a containerization system provided by Docker. In the backend, there is a relational database connected to PostGIS to store, process, and display spatial data [26]. The front end and mobile app function as applications for clients to interact with the system. The Rest API connects the backend, front end, and mobile app (client applications). Figure 2 illustrates the overall system architecture.

In Figure 2, the yellow-colored section represents the scope of the backend service, which is connected to several external services, including the Visual Crossing API to obtain weather data (temperature, rainfall, and solar radiation), online BMKG data for obtaining weather data (duration of sunlight), OpenTopoData API for obtaining elevation data, and Sendinblue for sending emails to users. All these external services are connected to the backend using a Rest API. The green and blue-colored sections are the web-based and mobile client applications, respectively. All traffic in the system's applications will pass through a reverse proxy owned by IPB University.

2.4 Prototyping Methods

The development of the backend module in this system uses the Prototyping method [27]. In the communication stage, Focus Group Discussions (FGD) are conducted with horticulture experts and stakeholders to define the system's requirements and functions. In this research, garlic growth requirement data is categorized into three groups of factors.

Modeling of the backend module begins with the identification of the most suitable options to meet the requirements of the features to be developed. Next, a conceptual design of the changes to be made is created. This conceptual design is then converted into a relational schema and further normalized. The results of this normalization are then transformed into an entity relationship diagram (ERD).

Figure 2: System architecture

An implementation system is then carried out for the features to be developed. The implementation is based on the designs and models created in the previous subsection. Testing is conducted using the black box testing method [28]. Testing is performed in two environments, namely, the development environment and the production environment [29]. Testing in the development environment is carried out by the backend developer while testing in the production environment is performed by the frontend and mobile developers. First, testing is conducted in the development environment. Afterward, the backend module is uploaded and installed on a new server with full access to the operating system, allowing all features, including file uploading, to be used. Following the upload and installation of the backend module on the server, further testing is carried out by stakeholders. If any errors occur during this stage, iterations are made to the preceding sections according to the identified errors.

3. Result and Discussion

3.1 Land Suitability Assessment

Based on the communication result, Figure 3 shows the activity diagrams illustrating the workflow of conducting land suitability assessment and viewing land suitability assessment results. Inputting location data in the form of coordinates (latitude and longitude) can be done automatically if connected to the internet by pressing the automatic fill button. Conversely, without requiring an internet connection, automatic input can also be performed for date and time observation data.

Figure 3: Activity diagram

Figure 4: Calculation of garlic land suitability classification

Table 3: Limitation Factors

Land suitability assessment is conducted using calculations as illustrated in Figure 4. Each weight, multiplied by the growth factor, is obtained from discussions with horticulture experts. To calculate land suitability classes, first, each class is assigned a weight as follows: class S1 = 4, S2 = 3, S3 = 2, and N = 1. The growth requirements with class N in each category will be used to calculate the suitability class results. The types of limitation factors and categories used in this study can be seen in Table 3.

The calculation of the final class results uses the weighted overlay method, as shown in Equation 1:

Equation 1

Where: S = The overall class value

W_i = The weight of the i-th factor

X_i = The class score on the sub-criteria

The weight for each factor is determined by experts.

The results of the calculation in Equation 1 will be converted into classes based on FAO (1976) [30], namely S1, S2, S3, and N, with intervals for each class as determined by experts, namely S1 (3.6-4), S2 (2.6–3.5), S3 (1.6-2.5), N (1-1.5). This study refers to the guide for land suitability proposed by FAO ( https://www.fao.org/3/x5310e/x5310e00.htm). There are four classes for land suitability: Highly Suitable (S1), Moderately Suitable (S2), Marginally Suitable (S3), and Not Suitable (N). The criteria of each class is presented in Table 4.

Next, the determination of the least suitable class for each factor will be carried out. The result of determining the least suitable factor (or the smallest) is then converted using alternative class values, and then the class values will be calculated using the formula in equation 1 for each factor. The results of the calculation for each factor are then summed up. The outcome of this calculation can be seen in Table 6. The total calculation of all factors is then converted based on the intervals specified by experts. According to Table 5, the result of the total land suitability value is 3.5, which falls into the Suitable class (S2). In general, the assessment process can be seen in Figure 4.

3.2 Modeling the Database

The database design begins with the creation of a conceptual design, followed by logical and physical design [31]. First, entity identification is performed based on the created use case diagram [32]. There are three entities required: user entity, land entity, and growth conditions entity. The user entity is needed to store user data, which is used for user management. The land and growth conditions entities are needed to store data related to land and growth conditions, which will be used to assess land suitability.

After obtaining the three main entities to be used, further analysis is carried out on each entity. Starting with the land entity, based on the existing use case diagram, there are two types of land to be stored in the system: user-entered land (user land) and land obtained from the soil map units obtained from BBSDLP (geometry land).

Table 4: Criteria for land suitability classes [30]

Table 5: Input data for calculating garlic land suitability

Table 6: Results of determining and calculating land suitability classes

For each type of land, a new entity will be created as a specialization of the land entity, where these two new entities are disjoint. Then, because a piece of land can be assessed multiple times, a new entity is needed, named the observation entity. This observation entity will have a many-to-one relationship with the land location entity and a many-to-many relationship with the growth conditions entity. The many-to-many relationship is used between the observation entity and the growth conditions entity because one observation can have many different growth conditions, and vice versa, one growth condition value can be owned by many different observations. Furthermore, since a piece of land requires two types of locations, namely point locations and administrative location divisions (area locations), one entity is needed for each type of location. The relationship between the land entity and the point location entity and area location entity is one-to-one and many-to-many, respectively. The many-to-many relationship is used because one piece of land can have many area locations (provinces, cities, etc.).

In the geometry land entity, two new entities are derived from further analysis, namely the geometry entity and the soil characteristics entity. The geometry entity and soil characteristics entity are each required to store geometry data and soil characteristic data from soil map units. The geometry entity has a one-to-many relationship with the geometry land entity because one geometry can potentially encompass many parcels of land, while the soil characteristics entity has a one-to-one relationship with the geometry entity. This is because the soil characteristic data obtained from BBSDLP is unit data for each piece of land. Furthermore, an additional entity is derived from the development of the soil characteristics entity, namely the proportion entity. The proportion entity has a one-to-many relationship with the soil characteristics entity. This is because the same proportion can have many soil characteristics. Then, from the analysis of the observation entity, a new entity is obtained, namely the land suitability class entity, which has a one-to-one relationship with the observation entity. This entity is created to break down the complexity of the observation entity and to facilitate data retrieval. After that, to store data from automatic weather data collection, a new entity is required, namely the daily weather entity. This entity has a many-to-one relationship with the point location entity because the data required for weather data collection is point data, and one point data can have many daily weather data.

In general, all growth conditions are placed in one entity, which is a “growth variable." An entity named "area location" is created to manage location data from the land, such as province, district/city, sub-district, and village. Within this entity, there is an attribute called "bpsCode" used to store the area code data from the Central Statistics Agency (BPS). Storing the BPS area codes is necessary because the frontend and mobile modules implement a third-party API for location data, and this API relies on data from BPS.

Furthermore, all the data related to land suitability classes is stored in the "land suitability class" entity. This allows the backend module to determine land suitability classes for each combination of growth conditions only once. Additionally, the conceptual design includes an "observation" entity, which serves to link the "land location" entity with the growth conditions and land suitability classes. With the presence of the "observation" entity, users only need to input growth condition data without the need for land location data to conduct land suitability assessments at the same location. After creating the conceptual design, it is then converted into a relational form. The purpose of this conversion is to normalize the database design to eliminate redundancy. The Entity Relationship schema for the database can be seen in Figure 5.

Figure 5: The entity relationship schema

Table 7: API Groups

3.3 Development of Backend Module

In the development of the backend module, the implementation of the previously created database design is carried out. This part begins with preparing the program code structure of the backend module to group related program files. The development of the backend module resulted in 37 APIs and 1 scheduler. The APIs are categorized into four groups: location area, growth conditions, land location, and users. Each group has a different focus in terms of functionality as mentioned in Table 7. Separating these functions simplifies the integration process for frontend and mobile developers because each group has a common prefix.

3.3.1 API group for location

This API group consists of all APIs related to location data within the system. The primary purpose of this API group is to process location data from the land. All APIs in this group can only be accessed by users with the admin role. To add and update location data, users must send a request body. The request body contains several fields, including type, name, and bpsCode. The "type" field represents the type of location to be added, where users can input "province" for provinces, "district" for districts or cities, "sub_district" for sub-districts, and "urban_village" for urban or rural villages. The "name" field is the name of the area to be added, while the "bpsCode" field is the BPS area code for the location to be included.

There are two APIs for retrieving location data. These APIs will return a response in the form of JavaScript Object Notation (JSON) containing location data. In addition to location data, these APIs will also return a "success" field as an indicator of the requested user operation.

3.3.2 API group for growth requirement

This group contains all the APIs related to growth requirement data within the system. The main function of this group of APIs is to process growth requirement data. Furthermore, to add or modify growth requirement data, users need to send a request body. The request body includes several fields, such as type, class, lower_limit_interval, upper_limit_interval, and recommendation. However, users do not need to send all these fields to add a new growth requirement. The fields that must be sent are only variable, type, and class, while other fields should only be sent if the specific growth requirement being added includes those fields. There are two APIs to retrieve growth requirement data. Both APIs will return a JSON response containing growth requirement data.

3.3.3 API group for land location

This API group contains all APIs related to land data within the system. Generally, this API group is divided into two subgroups: the user subgroup and the geometry subgroup. The user subgroup includes APIs that focus on processing user-inputted land data, while the geometry subgroup consists of APIs that focus on processing land data from the SPT.

3.3.4 User subgroup

In the user subgroup, there are all APIs related to land data entered by users. In general, this API subgroup has two main focuses. These primary focuses include processing users' land data and processing observation data of users' land. The processing involves addition, modification, or deletion. Furthermore, for the API that retrieves all user-input land data along with all observations and their suitability classes, no authorization is required. This API does not need authorization because it should be accessible to all users, including those who have not authenticated. The response from this API is a list of users' land data containing location data in the form of points (latitude and longitude) and area names and a list of observations that includes growth conditions and land suitability classes for each observation. To add new users' land location data and observations, authorization is required. This authorization mandates that the user accessing the API must be a registered user with a minimum role as a user. Users are also required to send a request body when using this API. In the request body, users must input location data so that the land data they intend to submit can be displayed on the map. Furthermore, when users make a call to the API to add users' land data, all requests sent by the users will be processed by first undergoing an authorization process, which involves checking the token sent according to the user's role. The data entered by users is not manually verified again by the admin. This is because only verified users can input data. Data entered by verified users is considered accurate, and the user is fully responsible for the accuracy of the data they enter.

To assess land suitability, the user-inputted growth conditions include factors such as weather, relief, uncontrollable and uncorrectable factors, controllable factors, and factors with correctable effects. The overall land suitability class will be determined based on these factors. To modify land location data, users are required to input a request body and the ID of the land they want to modify. Changes that can be made with this API are limited to modifications in the land name and land location data. Additionally, there is authorization in the API to ensure that the land data being modified belongs to the user initiating the change and not to another user. Next, to delete land location data, users are required to input the ID of the land they want to delete. The deletion process also includes removing all observations associated with that land. Consequently, all user-input land suitability calculations will also be deleted. This API also includes authorization, which functions similarly to the API for making changes to land location data. Subsequently, to add a new observation, users must input the ID of the land to which the observation will be added. Users need to provide the observation date and all the growth condition data in the request body. If the user does not input the observation date, it will be filled with the timestamp at the time of the user's call. To make changes to users' land observation data, the same request body as the one used to add observation data is required. Changes that can be made with the API to modify observation data include altering the observation date along with modifying all growth condition data. If there are changes to the growth condition data, the backend module will reevaluate the land suitability for that observation data. This API also includes authorization, functioning similarly to the API for adding observation data.

Furthermore, to delete observation data, users are required to input the ID of the observation they want to delete. Like the API for modifying observation data, this API also includes authorization, functioning similarly to the API for modifying that observation data.

3.3.4.1 Geometry subgroup

This subgroup of APIs contains all APIs related to land data from the SPT (Surat Pemberitahuan Tanah or Land Notification Document). Similar to the user API subgroup, generally, this API subgroup also has two main focuses. These primary focuses include processing land data from the SPT and downloading specific parts of that land data. The API for obtaining all locations (provinces and regencies/cities) that differ in the SPT land data does not require a request body, and this API also does not have authorization, meaning all users, including those who have not authenticated, can use this API.

The API to retrieve all land data from the SPT, along with all observations and their suitability classes, also does not require a request body. However, this API includes queries that users can use to filter the data they want to obtain. These queries include filters for province, regency/city, and land ID. Additionally, this API does not require authorization.

To add land data from the SPT, users need to input several files, namely the shp, shx, dbf, prj, and xlsx files. Additionally, users also need to input location data in the form of province and regency/city codes. In general, the process of adding SPT land data is like adding users' land data, but the source of growth condition data when adding SPT land data comes from the Excel file provided by the user. Another difference is that SPT land data has some parts that are not present in users' land data. These parts include geometry and soil characteristics.

Figure 6: Visualization of geometry in one of the SPT data

When adding SPT land data, the suitability class of the land is not immediately determined. This is because the weather data used to determine the land suitability class is either average data or cumulative data for a month. However, weather data obtainable from APIs such as Visual Crossing or other weather APIs is usually daily data. Therefore, it is necessary to fetch weather data for that land over the next month before the suitability class of the land data can be determined.

In this section, there is a process for separating geometry data that has more than one polygon. The separation is done using the ST_GeometryN function from PostGIS. This separation results in each polygon having one record in the database to facilitate the determination of the centroid of that polygon. Figure 6 displays the visualization of geometry for SPT number three, showing three polygons present in the SPT data. If this data is not separated, the determination of the centroid in the next step will result in incorrect values.

To perform the separation of the geometry data, the ST_GeometryN function from PostGIS is used. This function returns the geometry of the first shape (polygon, point, line, etc.) from the input geometry data. In Image 30, SPT number three has three records because the separation process creates one record for each polygon in SPT number three. Next, to delete SPT land data, users need to input the region code of the SPT land they want to delete in the request body. The intended code is the BPS code entered when the user adds SPT land data. This API includes authorization, allowing only users with admin roles to delete SPT land data.

There are three APIs for downloading data, including an API for downloading daily weather data, soil characteristic data, and a shapefile of SPT land data. The response from these APIs is not JSON but binary files that the user wants to download. This is designed to facilitate frontend developers, so they do not have to handle the response from the backend's file download, as the file will be automatically downloaded by the user.

3.3.5 API group for users

Generally, the APIs in this group serve to register and process user data. Before being recognized as a registered user, individuals must verify their email and wait for their account to be verified by an administrator before it can be used. Once the user's account is verified by the admin, the account will be active for one year. To register, users need to provide personal information and information about their institution. Users can choose to enter the institution's ID or enter the name and address of the institution. Meanwhile, other APIs handle essential user-related tasks, including extending the active period, resetting passwords, and changing passwords. Additionally, there are APIs for processing user data, such as activating users, resending verification emails, and retrieving all user data. APIs for processing user data are accessible only to users with admin roles.

3.3.6 Weather scheduler

The weather scheduler created in this research is used to retrieve daily weather data from two sources: Visual Crossing for temperature, precipitation, and solar radiation, and the BMKG data center for solar radiation data. To retrieve data from the BMKG data center, registration is required beforehand. The process for retrieving daily weather data is illustrated in Figure 7.

Figure 7: Activity Diagram for Daily Weather Scheduler

The flow depicted in Figure 7 will be executed every day at 23:00 WIB (Western Indonesian Time). Before retrieving solar radiation data from the BMKG data center, all available measurement stations are initially collected. The retrieval of BMKG measurement stations is done by requesting the BMKG data center site. Once all available stations are obtained, the data of SPT land is grouped based on the nearest station to that land. Subsequently, the retrieval of solar radiation data is conducted. Following that, weather data is obtained through the Visual Crossing API, and all this data is stored in the database. Then, if the weather data for a particular SPT land exceeds 29 entries, the suitability class for that SPT land is determined.

3.4 Testing and Deployment of Backend Modules

Testing was conducted for all APIs developed in this research, using the black box testing method. The testing occurred three times: first by the backend developer in the development environment and later by the frontend and mobile developers in the production environment. After testing in the production environment, the test data was removed to avoid interference with actual data.

Sixty-eight scenarios were utilized for testing. Within these scenarios, two test flows were examined: the positive flow and the negative flow. The positive flow is conducted to verify if an application performs as expected with valid input data. Conversely, the negative flow tests whether the application behaves appropriately when subjected to negative input, validating its response against invalid data. Among the 68 scenarios, 10 scenarios are designated for each of the area location and growth variable API groups.

Additionally, 26 scenarios are allocated for the land location API group, 24 scenarios for the user API group, and 1 scenario for the scheduler. The results showed that each scenario achieved the expected outcome (success). Deployment was done using containerization with Docker to an on-premises server owned by the research team. The use of Docker aims to avoid mixing various dependencies required by the backend modules. After deployment, domain name configuration was performed, including adjustments to the DNS records of the used domain name.

4. Conclusion and Future Research

This study has successfully developed features in the backend module for the garlic land suitability decision support system, considering uncontrollable and uncorrectable factors, correctable factors, and controllable factors. The research also implemented program code to separate SPT data with more than one polygon, facilitating the determination of the polygon's centroid. A scheduler was created to automatically fetch the latest solar radiation data from the BMKG data center for each SPT land in the backend module. The backend module was redeployed to an on-premises server, enabling the use of all features related to file storage. All features were tested using black box testing with 68 scenarios, and the results were as expected. Pagination has not been implemented for all existing APIs in this research, meaning all APIs for data retrieval return all available data. This could impose a burden and impact the speed of the backend module when handling a large amount of requested data. Pagination should be considered, especially if the database contains a substantial amount of data.

Additionally, not all regions in the BMKG data center have measurement stations, so the obtained historical solar radiation data may not be representative of the land's location. In future research, interpolation will be performed using historical solar radiation data from the nearest measurement stations in the land's region to obtain more accurate data for areas far from BMKG measurement stations./

Furthermore, in SPT data, there is a possibility that the polygon can be very large (across districts or regencies), resulting in centroid points with considerable distances from other locations within the polygon. In the next research, a check and determination of an upper limit for polygon size will be implemented. If a polygon exceeds this limit, it can be divided into smaller polygons or a grid can be created on the large polygon, enabling the determination of centroids in the grid squares. Additionally, alternative options need to be explored to obtain more accurate historical solar radiation data with better data availability than the BMKG data center.

Acknowledgements

This research was funded by the National Competitive Research Grant of the Directorate of Research and Community Service, Directorate General of Research and Development, Ministry of Research, Technology and Higher Education Indonesia, grant number 15846/IT3.D10/PT.01.03/ P/B/2023. The authors would like to thank the Directorate of Vegetables and Medicinal Plants, Director General of Horticulture, Ministry of Agriculture for sharing their knowledge, data, and facilities during the system development.

References

[1] Moulia, M. N., Syarief, R., Iriani, E. S., Kusumaningrum, H. D. and Suyatma, N. E., (2018). Antimikroba Ekstrak Bawang Putih Antimikroba Ekstrak Bawang Putih Antimicrobial of Garlic Extract. J. PANGAN , Vol. 27(1), 55-66.

[2] Statistics Indonesia and Directorate General of Horticulture. Garlic Productivity by Province, (2015–2019). Available: https://www.pertanian.go.id/home/index.php?show=repo&fileNum=339. (In Bahasa). [Accessed August. 28, 2022].

[3] The Ministry of Agriculture of Indonesia. The National Development of Garlic, (2017). Available: https://drive.google.com/file/d/12rmwsl3MsOzTvv2NxONwZFwW0QcIkMG8/view. (In Bahasa). [Accessed August. 28, 2022].

[4] Djaenudin, D., Marwan, H., Subagjo, H. and Hidayat, A., (2011). Petunjuk Teknis Evaluasi Lahan untuk Komoditas Pertanian. 1-166. https://nasih.staff.ugm.ac.id/wp-content/uploads/Petunjuk-teknis-evaluasi-lahan-untuk-komoditas-pertanian-2011.pdf..

[5] Mayanda, D. P., Adi, I. G. P. R. and Kusmiyarti, T. B., (2019). Evaluation of Land Suitability of Horticultural Crops in Sembalun Sub-district, East Lombok Regency, Indonesia. IOP Conference Series: Earth and Environmental Science , Vol. 313(1). https://doi.org/10.1088/1755-1315/313/1/012018.

[6] Diriba-Shiferaw, G., (2016). Review of Management Strategies of Constraints in Garlic (Allium sativum L.) Production. J. Agric. Sci , Vol. 11(3). https://doi.org/10.4038/jas.v11i3.8172.

[7] Al-Otayk, S., (2009). Variation in Productive Characteristics and Diversity Assessment of Garlic Cultivars and Lines Using DNA Markers. J. King Abdulaziz Univ. Environ. Arid L. Agric. Sci, Vol. 20(1), 63-79.

[8] Sebnie, W., Mengesha, M., Girmay, G. and Feyisa, T., (2018). Response of garlic (Allium sativum L.) to Nitrogen and Phosphorus Under Irrigation in Lasta district of Amhara Region, Ethiopia. Cogent Food Agric , Vol. 4(1), 1–8. https://doi.org/10.1080/23311932.2018.1532862.

[9] Muslim, R. Q. and Mulyani, A., (2019). Land Characteristics and Suitability for Development of Garlic in East Lombok Regency, West Nusa Tenggara Province. IOP Conference Series: Earth and Environmental Science , Vol. 393(1), 1-8. https://doi.org/10.1088/1755-1315/393/1/012079.

[10] Mufan, Z., Yong, G., Hengyu, P., Fei, W. and Dong, W., (2021). Ecological and Socio- economic Impacts of Payments for Ecosystem Services – A Chinese Garlic Farm Case. J. Clean. Prod, Vol. 285. https://doi.org/10.1016/j.jclepro.2020.124866.

[11] Song, H. and Dai, X., (2023). Construction and Application of an Applicability Evaluation System for Garlic Planters Based on Fuzzy Comprehensive Evaluation. PLoS One, Vol. 18(7). https://doi.org/10.1371/journal.pone.0288236.

[12] Mahmudah, N., June, T. and Impron, I., (2021). Adaptive Garlic Farming on Climate Change and Variability in Lombok. Agromet, Vol. 35(2), 116–124. https://doi.org/10.29244/j.agromet.35.2.116-124.

[13] Sánchez-Virosta, Á. and Sánchez-Gómez, D., (2020). Thermography as a Tool to Assess Inter-Cultivar Variability in Garlic Performance Along Variations of Soil Water Availability. Remote Sens, Vol. 12(18). https://doi.org/10.3390/RS12182990.

[14] Nurkholis, A., Sitanggang, I. S., Annisa, A. and Sobir, S., (2021). Spatial Decision Tree Model for Garlic Land Suitability Evaluation. IAES Int. J. Artif. Intell, Vol. 10(3), 666-675. https://doi.org/10.11591/ijai.v10.i3.pp666-675.

[15] Hartati, S. and Sitanggang, I. S., (2010). A Fuzzy-Based Decision Support System for Evaluating Land Suitability and Selecting Crops. J. Comput. Sci, Vol. 6(4), 417-424. https://doi.org/10.3844/jcssp.2010.417.424.

[16] Sitanggang, I. S., Rahmani, I. A., Caesarendra, W., Agmalaro, M. A., Annisa, A. and Sobir, S., (2023). Garlic Field Classification Using Machine Learning and Statistic Approaches. AgriEngineering, Vol. 5(1), 631–645. https://doi.org/10.3390/agriengineering5010040.

[17] Cartika, I., Rahayu, S. T., Basuki, R. S. and Soetiarso, T. A., (2022). Pertumbuhan dan Hasil Tanaman Bawang Putih pada Berbagai Penambahan Lama Penyinaran Lampu LED Putih. J. Agron. Indonesia, Vol. 50(1), 57-64. https://doi.org/10.24831/jai.v50i1.39300.

[18] Ghabour, T. K., Ali, R. R., Wahba, M. M., El-Naka, E. A. and Selim, S. A., (2019). Spatial Decision Support System for Land Use Management of Newly Reclaimed Areas in Arid Regions. Egypt. J. Remote Sens. Sp. Sci , Vol. 22(2), 219-225. https://doi.org/10.1016/j.ejrs.2018.04.001.

[19] Sugumaran, R. and DeGroote, J., (2010). Spatial Decision Support Systems: Principles and Practices .1-508, CRC Press. https://doi.org/10.1201/b10322.

[20] Rayes, M. L., (2007). Land Resource Inventory Method.Andi Publisher. Yogyakarta.

[21] Atif, M. J., Amin, B., Ghani, M. I., Ali, M. and Cheng, Z., (2020). Variation in Morphological and Quality Parameters in Garlic (Allium sativum L.) Bulb Influenced by Different Photoperiod, Temperature, Sowing and Harvesting Time. Plants, Vol. 9(2). https://doi.org/10.3390/plants9020155.

[22] Teorey, T. J., Lightstone, S. S., Nadeau, T. and Jagadish, H. V., (2011). Database Modeling and Design: Logical Design. Elsevier.

[23] Pereira C. R., (2016). Building APIs with Node.js. Apress , Apress Berkeley, CA. https://doi.org/10.1007/978-1-4842-2442-7.

[24] RESTful API Modeling Language (RAML). [Online] Available from: https://raml.org/. [Accessed: 05.11.2023]

[25] Doglio, F., (2018). REST API Development with Node.js. Apress, 2018. Apress Berkeley, CA. https://doi.org/10.1007/978-1-4842-3715-1.

[26] Sveen, A. F., (2019). Efficient Storage of Heterogeneous Geospatial Data in Spatial Databases. J Big DataVol. 6. https://doi.org/10.1186/s40537-019-0262-8.

[27] Sabale, R. G., (2012). Comparative Study of Prototype Model for Software Engineering with System Development Life Cycle. IOSR Journal of Engineering (IOSRJEN) , Vol. 2(7), 21-24. http://dx.doi.org/10.9790/3021-02722124.

[28] Khan, M. E. and Khan, F., (2012). A Comparative Study of White Box, Black Box and Grey Box Testing Techniques. International Journal of Advanced Computer Science and Applications (IJACSA), Vol. 3(6). http://dx.doi.org/10.14569/IJACSA.2012.030603.

[29] A Comprehensive Guide to Software Development Environment. [Online] Available from: http://dx.doi.org/10.14569/IJACSA.2012.030603". [Accessed: 30.03.2024].

[30] FAO. (1976). A Framework for Land Evaluation. FAO and Agriculture Organization of the United Nations . Available: https://www.fao.org/3/x5310e/x5310e00.htm. [Accessed Sept. 2, 2022].

[31] Teorey, T. J., Lightstone, S. S., Nadeau, T. and Jagadish, H. V., (2011). Database Modeling and Design: Logical Design. Elsevier.

[32] Kulak, D. and Guiney, E. (2012). Use Cases: Requirements in Context . Addison-Wesley.