# The Development of a Prototype Solution for Detecting Wear and Tear in Pedestrian Crossings
## 3 Prototype
### Software Components
#### 3.3.2 Application Programming Interface and Database (Back-End)  
The API was meticulously developed using the NodeJS language [34] in conjunction with the Fastify framework [35]. The selection of NodeJS offers considerable advantages, including its capacity to process a substantial volume of requests in an efficient manner and its scalability. For information storage, we opted to utilize Firestore, a NoSQL database provided by Firebase [36]. This database offers a flexible and scalable structure for storing and querying data in real time. Initially, a Structured Query Language (SQL) database was employed, specifically PostgreSQL via PrismaDB [37]. This offered Object Relational Mapping (ORM), facilitating the creation of tables using Typescript for various types of databases. However, as the project progressed, it was replaced by Firebase due to its straightforward integration and the fact that this solution is relatively simple and does not necessitate complex configurations. All the endpoints were implemented based on [38; 39]. The Postman platform [40] was used to test all the endpoints locally. Figure 21 illustrates the document structure required to register a new crosswalk detection. These documents contain a state field, which indicates the level of degradation of the crosswalk, along with the location field, which includes the longitude and latitude of the captured GPS coordinates. Figure 20: Flowchart of how the Raspberry Pi works. The endpoints configured in this API are shown in Figure 22, which illustrates that only three HTTP methods are utilized: GET, POST, and DELETE. The /crosswalks endpoint is employed to both retrieve all crosswalk detections and to register a new one. The /crosswalks/:id endpoint enables the removal of specific detection. During the development of the API, it was discovered that the location field, which contains the coordinates of the location where a crosswalk was detected, could be utilized to obtain the name of the city. This information facilitated the user's ability to identify the location of the crosswalk. To achieve this, the Geoapify API [41] was employed through its reverse geocode endpoint, which returned the name of the city using the coordinates. Figure 23 illustrates an exemplary response from this API. Figure 23: Example of a response from the Geoapify API. Figure 22: Endpoints on the API. Figure 24 illustrates the sequence diagram between the various components of this application, from detection by the IoT device to registration in the Firebase non-relational database. An IoT device, such as a Raspberry PI, detects and classifies a crosswalk, collecting the GPS coordinates. These data are then sent to the API via the /crosswalks endpoint. The API then processes the received data and uses a reverse geocode API to transform the GPS coordinates into location information, such as the name of the city, the name of the street, and so forth. Subsequently, the API determines whether this detection is new or whether there is already a similar one in the database. To do this, it compares the new detection with the existing ones, calculating the distance between the coordinates. If the distance between the new detection and one already registered is less than a specified threshold value, the existing database entry is updated with the new information. Conversely, if the distance is greater than this threshold, the new detection is added as a separate entry in the database. This mechanism is illustrated in Figure 25, in which the threshold value set was 5 m.  
The prototype thus serves to guarantee the accuracy and up-to-date status of information regarding crosswalks, thereby precluding the necessity for unnecessary repetition and maintaining the database in a state of optimal organization. Figure 24: Sequence diagram between API and Raspberry PI. Figure 25: Illustration of the mechanism for identifying the distance between coordinates. Once the API had been developed, it was necessary to deploy it. The Render platform [18] was employed for this purpose.