MOBILE MAPPING SOLUTIONS FOR THE UPDATE AND MANAGEMENT OF TRAFFIC SIGNS IN A ROAD CADASTRE FREE OPEN-SOURCE GIS ARCHITECTURE

: The adoption of open-source mobile mapping applications in public administration has risen over the last decade due to their interdisciplinary vocation and flexibility in adapting to existing Geographic Information System (GIS) software architectures. This facilitates complex procedures of data collection and management required for transportation and environmental models, emergency management, and maintenance operations. The Ministry of Infrastructure and Transport in Italy requires road-owning agencies to build and maintain a mapping inventory of their road networks, including georeferenced information about streets and ancillary elements, such as traffic signs. Innovative and integrated street-level approaches for the rapid mapping of road entities using open-source mobile mapping tools represent a valuable low-cost solution for the periodical update of road entities inventory. The adoption of these tools allows public administrators to easily consult the road inventory even outside the office, conducting in situ validation and quality evaluation. This work presents a case study focused on the update and management of traffic sign entities of the Road Cadastre of the Province of Piacenza (Italy) using Qfield and Open Data Kit (ODK) Collect as alternatives to the previous traditional survey method that consisted in the use of field papers. A comparison between the adoption of the two mobile apps is conducted, identifying benefits and limitations in terms of both data accuracy and usability. Validation scripts, project and form structure were developed with the perspective of making the entire workflow as reproducible and transparent as possible, sharing details


INTRODUCTION
Over the past decade, scientific literature highlighted the rising interest in open-source mobile mapping applications (Duarte and Teodoro, 2021), thanks to their interdisciplinary vocation and flexibility of adaptation to existing Geographic Information System (GIS) software architectures, facilitating complex procedures of data collection and management (Nakagawa et al., 2015). In this context, road administrators and public agencies started considering the adoption of GIS-based desktop and onfield solutions for the definition of a comprehensive management system in support of decision making (Christou et al., 2021). Indeed, the increase of road traffic and the complexity of street environments demanded for location-based solutions able to support simulation modelling, emergency management and maintenance operations (Droj et al., 2022, Gonzalez Alba et al., 2019, Vavassori et al., 2022. In order to develop accurate transportation and environmental models, however it is necessary to document the current state of the territory. For this reason, digitization and update of road network databases represents a crucial topic for a good management of critical infrastructures by public administrations (Moscovici et al., 2022). Since 2001, Italian road-owning agencies have been required by the Ministry of Infrastructure and Transport to build and maintain a road cadastre, i.e., a mapping inventory of their road networks. Such architecture should include georeferenced information about streets as well as all ancillary elements regulated by road regulations, ranging from safety and protection assets to traffic signs (Barrile et al., 2020a). In particular, due to the high frequency of new signals installation and substitution, traffic signs require a well-structured, flexible and efficient workflow for collecting and manipulating georeferenced data. In this * Corresponding author context, investigating innovative and integrated street-level approaches for rapid mapping of road entities represents an important challenge for public administration. Studies on this field tested the adoption of mobile mapping laser scanning systems for automatic road sign detection (Soilán et al., 2016, Barrile et al., 2020b but such approaches usually imply the use of specialized and expensive machinery, usually handled by expert operators. On the other hand, recent progresses in computer vision and deep learning techniques support the automatic detection and the rapid mapping of traffic signs and billboards (Campbell et al., 2019) but their reproducibility and geolocation accuracy are still strongly site-specific, requiring training data that may be challenging and time-consuming to be collected (Zaibi et al., 2021). In this context, open-source mobile mapping tools represents valuable practical low-cost solutions for periodical update of road entities inventory, engaging, thanks to their simplified and customizable interfaces, also users without a technical background in GIS or geomatics (Filocamo et al., 2020). Moreover, such applications also help surveyors and public administrators to easily consult the road inventory even out of the office, conducting in situ validation and quality evaluation (Gharbi and Haddadi, 2020). This work aims at presenting a case study for the adoption of lowcost open-source mobile mapping applications in the field of public administration, understanding potentials and limitations of these possible approaches, also in terms of introducing new users to FOSS4G applications. In particular, the pilot study is focused on the update and management of traffic sign entities of the Road Cadastre of the Province of Piacenza (Italy) using Qfield and Open Data Kit (ODK) Collect as alternatives to the previous traditional survey method that consisted in the use of field papers. A comparison between the adoption of the two mobile apps is conducted, identifying benefits and limitations in terms of both data accuracy and usability. Validation scripts, project and form structure were developed with the perspective of making the entire workflow as reproducible and transparent as possible, sharing details in a dedicated GitHub repository.

METHODOLOGY
The proposed methodology of mobile mapping solutions is built based on the existing software architecture for the management of the Road Cadastre inventory of Piacenza ( Figure 1). Indeed, in agreement with the official national requirements, in 2019 the Province of Piacenza adopted and implemented a digital cadastre with GIS and WebGIS functionalities built on top of free and open-source software. In particular, on the server side, PostgreSQL is used as database management system together with the PostGIS extension for enabling the manipulation of geographical data. and QGIS for the manipulation of geodata. QGIS Server is used for the publication of web geographic services, while Liz Map PHP application is used for the dynamic generation of a web map application ( Figure 2), with its user interface configuration. Public administrators can access the geodatabase through QGIS Desktop, manipulating, updating, and styling vector and raster data.  Such software infrastructure ensures flexibility of usage as well as the possibility to expand its functionalities with other easy-touse open-source custom web and mobile applications. In this framework, this methodology introduces mobile open-source applications to substitute the old procedure that consisted in the documentation of element installation on paper support, implying the risk of transcript errors as well of loss or deterioration of the original survey document. Before defining the required steps of mobile mapping, a preliminary phase was dedicated to understanding of how traffic signs are modelled inside the adopted DB model. Such elements are indeed implemented through a one-to-many relationship between an entity representing the sign holder (parent table with a point geometry) and another one for the signs themselves (child  table). In this way, it is possible to collect and manage individually information about each sign (main ones and supplementary ones as well) always linked to their support pole ( Figure 3). Then, together with the road cadastre responsible, a requirement analysis was conducted to understand the specific needs for the application. The designated tools should be installable on smartphones or tablet devices and should have the ability to collect and edit data with attributes in different formats, ranging from simple text and numbers to datetime and geometry. In particular, they should be able to implement widgets (e.g. drop down menus, check boxes, calendar selection) that simplify and speed up the procedure of data form filling. Also, the form structure has to be easily customizable and updatable to any future road cadastre changes. Lastly, the output file resulting from in-situ operations should be in an open format compatible with the QGIS-PostgreSQL architecture. An important consideration that emerged in this phase consisted in the geolocation data quality assessment of the surveyed traffic signs according to the national guidelines that required a maximum uncertainty of 5 meters. However, a sub-metrical accuracy is strongly suggested for optimal positioning. In order to reach the required accuracy, the adoption of external Global Navigation Satellite System (GNSS) receivers that are able to connect with mobile devices represented a good and practical solution for optimising field surveys. However, in absence of strict accuracy requirements, the mobile applications could easily be used without any additional equipment. Additionally, an evaluation on the type of users involved in the in-situ survey process was conducted, identifying two distinct groups, labelled as: internal and external users. The first group of operators is composed of people that are part of the road management organisation and usually consists of technical users with experience on accurate positioning and survey of the existing road entities. The external users group is composed of employeesusually without any background in the field of geomatics -of companies that have been commissioned by the province of Piacenza to install new traffic signs. This phase resulted in the choice of two open-source solutions to be tested and compared in terms of compatibility and usability by users with different technical background, integration with the actual infrastructure and possibility of customisation: Qfield because of its native compatibility with QGIS libraries and ODK Collect thanks to its simplified graphic user interface (GUI) that resembles commonly used data collection forms without a visible GIS GUI. Once the form design was finalised for both the applications, a guided field survey was conducted in order to train new users and to test the usability of the mobile mapping solutions. For this purpose, a series of test sites was chosen, identifying roads to be surveyed with different features or conditions. A diverse sample of test users was involved in the data collection activity, ranging from people with no previous experience in geospatial technologies to GIS technicians. Finally, the data collected with both applications were reviewed in QGIS environment in a validation phase aimed at identifying differences between the dataset, their completeness, their position accuracy and their coherence with a ground truth represented by photos of corresponding traffic signs taken on field with mobile devices. First, the validation consisted in checking if the mapped elements were located within buffers calculated along the surveyed streets and then evaluating the coherence between the street code inserted in the element field and the one of the roads in whose buffer such sign is included. Hence, a similar approach was adopted for comparing the value of municipality associated to the single traffic sign to the administrative boundaries within which it falls. A semantic validation on the traffic sign type documented with the mobile mapping was conducted by comparing values with what was depicted in photos taken on field. The entire validation routine process was automatized as much as possible with Python scripts using the PyQGIS library. All the validation scripts together with sample dataset are included in a GitHub repository in order to make them openly reusable and adaptable to other specific project needs. An analysis on the synchronization process of the collected data on the original main database was evaluated too, marking different approaches involving plugins or automatic scripts.

THE CASE STUDY
A pilot test on the use of the two chosen mobile applications was conducted on a subset of streets of the road network of Piacenza.
The initial phase required the definition of custom user interface settings and form implementations. In the case of Qfield, the configuration is simply driven by the definition of a QGIS project and its export through the Qfield Sync plugin. Main manual modifications were required only for the choice of widgets to simplify the form filling with the aim of speeding up the process of collecting pictures and implement relationships. ODK Collect, instead, required the definition of an XLSForm template in which for each form attribute it was needed to define constraints and pre-defined answers for inserted values, filters for the visibility of certain questions based on previous choices and entityrelationship settings. The configuration files served as starting point for the definition of the graphical aspect of the graphic user interfaces of two applications. Then, first a training with the operators on the field was conducted, highlighting in details the differences of procedures in Qfield and ODK Collect: the first one takes advantage of a map-based view for the project, simply resizing in a small portion of the screen the data form to be filled (Figure 4), while the other one is built entirely on the form architecture, showing the map object when it is required to associate a position to the point that will represent the traffic sign holder ( Figure 5). Both applications were adopted in an offline data collection approach, meaning that features or errors collected with the form are not directly synchronized with the main Road Cadastre database, but they are temporarily stored in the mobile device local memory and later processed with a validation procedure in order to filter out of the dataset gross errors and inconsistencies. The asynchronous procedure was required as the internet connection may not be always available on the field, especially along mountain roads or in remote areas.  Once the form design was finalised for both the applications, a guided field survey was conducted in order to train new users and to test the usability of the mobile mapping solutions. The chosen equipment consisted in the use of a set of tablets having Android as operating system. For an optimal testing of the procedure, an external single frequency GNSS receiver (Stonex S500) was used, providing the opportunity to improve the positioning of the native receiver of the tablet while respecting the sub metrical accuracy requirements of the Italian Guidelines. For testing the methodology, a series of sites was chosen, identifying roads to be surveyed with different features or conditions such as morphology, accessibility to the roadside and internet coverage that could affect the accuracy of GNSS signal ( Figure 6). The surveyed roads consisted in a total length of 14 kilometres. After the data collection phase, the operators were supported in the data transfer from the mobile device to the desktop station, facing the different approaches for the two applications. While Qfield enables the possibility to directly query and visualise collected data (stored as geopackage) in a QGIS project, ODK Collect requires a pre-processing step in which the instances of the original form are interpreted and transformed with ODK Briefcase into tabular data (comma separated values format) readable in a GIS environment. Once pre-processed, both the collected dataset is prepared for the validation phase for data quality assessment through predefined Python scripts. Eventually, operators previously engaged in the data collection are then engaged again in the synchronization of the data that satisfied the validation requirements with the traffic signs layers stored in the PostgreSQL database on the server, updating the existent documentation of this entities.

RESULTS
The data collected on field with the chosen mobile applications were subjected to a validation process and compared with a subset of data previously collected with the traditional methods of field papers and reports. Hence, this step of the study is devoted to the data quality analysis aimed at quantifying spatial and thematic accuracy, as suggested by ISO 19157, through significant indexes and statistics to be compared within the different approaches of data collection. A first data analysis was conducted on the position associated to each traffic sign holder. Each entity is checked to ensure that its location is within the buffer defined around the road geometry stored in the Road Cadastre and modelled as lines corresponding to the street axis. To this end, a Python script that makes use of PyQGIS and Pandas libraries and loops through all the features contained in the sign holder dataset was developed. The choice of values for the buffer computation is based on the fact that the average value of holder distances from the roadside, calculated on values recorded in the associated field, is equal to 1,2 meters. Based on that and on the assumption of a roadway width of 5 meters, three values for buffer around road axis and consequent accuracy classes were defined as illustrate in Table 1.
Traffic holders outside the three given buffers are considered as gross errors and are not validated by the procedure. The results of this procedure are depicted in Figure 7, showing the percentages of entities validated for each accuracy class and categorised for methodology (traditional method, Qfield, ODK Collect). The graph underlines how the position tracking for traffic holders was improved by the adoption of mobile mapping solutions, bringing the percentage of data validated with optimal accuracy from 39 to 99 %. Investigating the previous methodology in detail, it was found that the location was detected from EXIF files of photos taken by phone at a certain distance from the sign. This issue combined with transcription mistakes and the capturing of coordinates information in sexagesimal degrees truncated to the integer value of seconds highlighted that the old process was strongly affected by errors, giving in some case a minimum position accuracy of 20-30 meters. With predefined forms provided with embedded coordinates capture functionalities and integrated with external GNSS receiver, the transcription errors are avoided, and positioning is improved. Following such observations, the commission error for the road code associated to the traffic holder is computed, based on the comparison between the value inserted in the related attribute and the position along the network. In this case, an error of 8% linked to data collected with the old methods was reduced to 3% in the case of ODK Collect and cleared with Qfield. The same evaluation methodology was applied to the case of the municipality within which the signs are located, compared with the information contained in the "location" attribute of the data. Similar results were obtained: from 19% of the old method to 11% of ODK Collect and 0% with Qfield. This latter evidence can be associated to the use of base map in the main interface view, supporting the users with a direct reference when inserting the correct road code. Hence, a data completeness analysis has been conducted on two typologies of attributes: mandatory and null ones. The fields considered for the evaluation are "image" (not null), containing the photo of the signal, and "roadside_distance" (null), referring to the distance in centimetres of the sign holder from the roadside. Results of this step can be found on As expected, given the inclusion of the mandatory constraint in the definition of forms in Qfield and ODK Collect, the "image" not null condition is always satisfied. Instead, the old method is highly affected by missing picture documentations. This could be due to the loss of unique strong connection between the picture taken on field with mobile devices and the related field paper. Loss of digital file due to the absence of an organised data management structure for the survey is another possible cause. The values for the "roadside_distance" modelled as a null attribute, instead, could represent a proxy of ease of the formfilling procedure on the user side, suggesting possible preferences of operators. However, such consideration needs to be supported by direct user feedback. The validation analysis workflow was automatised through the procedural execution of scripts in QGIS, also supporting the validator user with cartographical output able to make more evident positioning accuracies and highlighting as well through selection on the attribute table commission errors and data incompleteness (Figures 8 and 9).  Finally, an important consideration on the data post-processing and validation needs to be done when analysing the data synchronising in the QGIS project environment. While Qfield take advantage of the functionalities of an official plugin, ODK Collect data need to be converted from tabular format to a vector one, taking care of unicity of features identifiers (IDs). Moreover, when aligning IDs of collected data with the one already existing in the Road Cadastre DB, it is important to preserve the correspondence between primary and secondary keys of parent and children features of the holder-traffic sign(s) relationship. In order to facilitate such approach, an automated PyQGIS script was developed, supporting the users in the routine operation of loading ODK tabular data, recalculating their IDs, reconstructing their relationship and finally concatenating them to the main layers of the DB.

USERS FEEDBACK
Showing important improvements with respect to the previous traditional data collection method, the results of the validation process highlighted significant differences in the data management process. Indeed, each application underlined the need to consider peculiarities on user experience and technical background, implying different approaches in the form configuration, data post-processing and application adoption. In order to evaluate such characteristics, a LimeSurvey feedback form was provided to users who tested the tools on field. It was designed to collect insights on different steps of the workflowform design, data collection and post-processing -, tracking and evaluating possible differences between users with different background and no previous knowledge of geospatial concepts. This resulted in highlighting potentials and issues linked to the adoption of Qfield or ODK Collect for traffic signs mapping ( Figure 10). A sample of test operators were involved in the process. The comparison in term of differences in the configuration processes resulted in a general preference for Qfield. The key factors that drove this prevalence were mainly linked to the possibility of easily exporting a whole QGIS project and its related settings with simple steps with the Qfield sync plugin. In the case of ODK Collect, instead, even a slight modification of the DB structure in the QGIS project implies relevant manual interventions in the XLSForm configuration, making the form definition an even more time-consuming step. Regarding the simplicity of installation, both applications can be easily and freely installed, and the local form project imported through cable connection of the mobile device to the desktop station. An important distinction needs to be highlighted when evaluating the user interfaces. Indeed, the feedback survey highlighted strong preferences between experienced users in GIS-related fields and operators without any technical background in the field of geomatics or insitu survey. When asked, the first group of users manifested a strong preference for Qfield, operating in a cartographic-driven multi-layered environment like QGIS. The possibility to activate satellite imagery or OpenStreetMap as base maps was particularly appreciated. On the contrary, users without previous experiences in data-collection operations showed a preference for ODK Collect, thanks to its essential and clean interface that illustrate in sequence questions and predefined answers, guiding the operator step by step along the entire process without distractions of any additional advanced GIS-related feature.
Regarding the facility of adding new data, ODK Collect was slightly preferred to Qfield. However, the choice is completely different when users are asked to choose the favourite app for editing existing features. In Qfield, the possibility to directly click on traffic signs already present on the map and access their data form has been appreciated by both groups.

Figure 10. Test users' preferences between Qfield and ODK
Collect for in-situ survey of traffic signs.

CONCLUSIONS
The insights resulting from the validation step and the user feedback suggested that FOSS solutions for mobile mapping could play a relevant role in public administration routine process. Procedural guided geo-referenced forms like the ones implemented in Qfield and ODK Collect reduce the presence of gross error in the data and involve actively even non-expert users in the digital documentation process. Moreover, the possibility of adopting low-cost and less time-consuming approaches for adding new elements or updating existing information represents a critical benefit for public administrations that, having an up to date accurate documentation of their assets, could better manage their interventions of maintenance. Following the pilot testing, the Province of Piacenza decided to officially adopt both Qfield and ODK Collect for mobile data collected at different level, integrating them in an already FOSS4G architecture based on PostgreSQL, QGIS and LizMap. The first application was chosen for routine operations, used by internal field surveyors that frequently monitor the state of roads and its assets, updating information on existing features. ODK Collect, instead, was adopted for collaborations with external company responsible for new traffic sign installation, usually not familiar with traditional surveying techniques and GIS applications. In this way, the entire lifecycle of the entities is documented, ranging from their installation by external agents to renewal or removal events managed by operators of the Provincia di Piacenza. The adopted approach, thanks to simplicity of use of both the mobile applications, is easily transferable to other territory management and urban planning contexts. Because of this, the transparency of the entire workflow is being documented on a dedicated GitHub repository with informative guides, a QGIS demo project for Qfield export, ODK format definition files and all codes adopted for validation and synchronization purposes. An example of traffic sign data is also shared in order to understand the layers data structure. In this way, interested users could easily adapt the code and the methodology to their own data collection needs. The repository is available at: https://github.com/labmgf-polimi/road-cadastre-traffic-signs. Last, in order to better support the routine operations for the monitoring of the Road Cadastre entities, a plugin based on the validation scripts is currently under analysis for the automatic data quality assessment of collected data. Indeed, a user-friendly graphic interface that implement code in Python language could become another valuable tool to be embedded directly in QGIS, helping public administration agent to easily calculate statistics and store them in a printable operation report, representing quantitative e qualitative metadata of the entire procedure.