## 3 Results
### Mobile User GNSS Data  
The developed application works in the local Polish CS92 system (EPSG: 2180), based on the GRS80 ellipsoid. The source data extracted from the National Geoportal [35] are compiled and made available in this system. One of the objectives of the multimodal system was to automatically acquire or manually assign the location of the mobile user's device. The geographical coordinates extracted from the mobile device are in the global WGS1984 system (EPSG:4326). The coordinates are transformed into the cartographic coordinate system in which the application is operating. This is achieved through the use of the Proj4 js library [52], which employs a mathematical transformation utilizing Gauss-Kruger projection (a variation of Merkator transverse projection). This transformation enables the conversion of geographic coordinates into flat orthogonal coordinates, taking into account the parameters of the destination system, such as the central meridian or offset and scale. The library automatically implements this method using defined EPSG standards, thereby ensuring compliance with accepted geodetic specifications. The final coordinates are used to determine the centroid of the location of the extracted orthophoto section for visualization using the WCS service. The coordinate range of the extracted area is set by the user, using the dimensions of the raster (width and height).  
System Architecture and Data Flow  
Figure 10 illustrates the general concept of data flow between the principal components of the system. The mobile user utilizes a browser-based mobile application, which enables the device's location coordinates Global Navigation Satellite System (GNSS) to be obtained and transmitted to another component of the system (the Django application server) via HTTPS (HyperText Transfer Protocol Secure). Additionally, the browser receives results from the system, including building perimeters and data for visualization in geoyon format. In this context, Django is the primary data processing component. The application server acquires the coordinates from the browser and then communicates with the database, geospatial services (downloading orthophotos from the National Geoportal), and the classification module.  
The Django framework is responsible for the following processes:  
* In order to ascertain the veracity of the data in question, Django verifies the local spatial data resources. In the event that the user's location is known, the information is not obtained from external services, but rather from the cache of the aforementioned resources.
* The processed results are stored in a PostgreSQL database for potential future use in subsequent location-recursive requests.
* The system generates building boundaries based on data collected or downloaded from external services.
* Django stores information about the roof types detected in the analysis for a given user query area.
* Django sends queries to external WFS and WCS services to retrieve geospatial data for a given area.
* Download from an external source of building boundaries and orthophoto data.
* The YOLO model is used to initiate roof detection and classification tasks on selected areas of the orthophotos, in order to assign appropriate building models to the visualized space in AR.  
PostGIS (PostgreSQL): Acts as a geospatial database, storing local information about buildings, roof types, and analysis results. Django communicates with PostGIS to read and write spatial data.  
National Geoportal[35]: An external source of geospatial data from which Django extracts building boundaries and orthophotos. WFS and WCS services are used to extract current data.  
YOLO v10 XE: A classification module that analyzes images to detect and classify roof types based on orthophotos.