# The Architecture of an Agricultural Data Aggregation and Conversion Model for Smart Farming
## 3 Data Aggregation and Conversion Model
The created map elements are saved or updated in the database, and the geometric shape is drawn on the map (with different layer options). This information is used to calculate and output a temporal field analysis report depending on which field the user selects. All the reports and maps generated by the platform are available to users via a web-based user interface (Figure 1) and API (Application Programming Interface) access. The API allows to access the system's functions externally by sending certain requests to the server that services the system. The _PostgreSQL_ database management system extension _PostGIS_, which is designed to work with _GIS_ data, is used for storing the geographic data and for interfacing with additional information sources. The geographic database comprises interconnected parts (Figure 3). The user section holds the user's basic login information and status, as well as the API key used by the user to access the system information externally. The user section also contains a unique desktop code that is used to connect the _PostgreSQL_ part of the database and the _PostGIS_ part of the geographic database. The code for this part of the program is generated from the information in the uploaded file and the date of the upload using a cryptographic hash function, a cryptographic method widely used in programming to encrypt data. This function is used to obtain a fixed-length result (character string) from which it is not possible to recover the original data. The system encrypts the entered data with the same hash function and compares the resulting hash value with the value stored in the database. If the values match, the data are good, if they do not match, the entered data are different from the protected data [38]. The user section is connected to the user's password section, which allows for password validity checks. Figure 3: General scheme of geographical data management model. The layer section contains information about the fields uploaded by the user but does not hold the field geometry and other geographic information itself. The stored filename is used to associate the field data with geographic data that are accessible via the user's desktop information. The layer is also linked to the harvest, the type of work carried out, and the dates. For each platform user, a _PostgreSQL_ desktop is created which separates the data of the different users according to their unique identification numbers. Each user also has their section of uploaded files which are not related to each other. The uploaded files section contains GIS-type data stored in an optimised \"geometry\" format. The _PostGIS_ extension allows for the use of geometric functions and query databases using GIS data. At the same time, the section holds the information obtained when users upload a file, for example, the amount of fuel, the type of work completed, the unit of measurement used, the product used, and how much of this product was used in that polygon (area of land). When uploading data to the platform, the geometry of the perimeter of the uploaded field (file) is automatically generated. The user-uploaded field, which comprises individual polygons, is merged into a solid polygon by applying a small distance buffer around each polygon, thus covering any gaps between them. The merged field is converted into its perimeter and the _MultiPolygon_ type so that the field can be read even if there is an area inside the field that is outside the field. The resulting perimeter is used for GIS operations and is saved. This saves computational resources by eliminating the need to calculate the perimeter each time. The perimeter is saved as a _MultiPolygon_ geometry type, which allows you to save non-contiguous geometries in a single line, i.e., if there is a space in the middle of the field, the polygon is still saved without errors. Combining the data aggregation and geographic database models results in a common platform that formats different data types and adapts them to farm management (Figure 4).