# Semantic Traffic Sensor Data:
## 5 Experimental Evaluation
Currently, traffic data are not published by the city of Modena; therefore, these tests are executed on real data, while the data that are shared through the SPARQL endpoint are example data (random data). As reported in Table 3, in a generic day, in Modena, about 17,500 1-h observations (first row, forth column in the table), 70,000 15-min observations (second row, forth column in the table) and 430,000 1-min observations (forth row, forth column in the table) are collected. A procedure for transforming and loading data has been deployed. This procedure divides the data in windows of 1-day length so that 365 iterations (loading stages) are needed to load the data of the whole year. In this context, hourly data were successfully handled and the time needed to upload the observations of the whole year was about 1 h (\(\sim\)10 s \(\times\) 365 iterations), as shown in the table. Due to scalability issues with the tool used, 15-min data and 1-min data cannot be loaded by following this approach. In Table 3, a loading process is denoted by \"failure\" in case one iteration does no end successfully within 3 h.  
The table also shows that, if we reduce the length of the temporal window to 12 h, 15-min aggregated data of the whole year can be loaded in approximately 6 h (\(\sim\)30 s \(\times\) 730 iterations); every iteration loaded approximately 35,000 observations. Due to scalability issues, 1-min aggregated data cannot be handled when a 12-h interval is adopted; nevertheless, by considering a window length \begin{table}
\begin{tabular}{l c c c c c} \hline \hline
**City** & **\#Sensors** & **Period** & **\#Observations** & **\#Triples** & **Loading Time** \\ \hline Zaragoza & 46 & 1 January 2019–31 December 2019 & 383 K & 2.5 M & 1.5 min \\ Modena & 400 & 1 January 2019–31 December 2019 & 6.5 M & 46 M & 1 h \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Observation data performance evaluation: loading time of hourly observations from January to December 2019 of 3 h, every iteration has to handle approximately 54,000 observations and 1-min data can be loaded in about 36 h (\(\sim\)45 s \(\times\) 2920 iterations). For more details, please see Table 3, which summarises the loading time of each option. After these tests, it can be noticed that the loading process was not able to manage more than \(54,000\) observations in a single step due to scalability issues. However, this fact should not be considered a big issue. In fact, in case a city council decides to publish fine-grained data (1-min or 15-min data), it is likely that this data will be shared in semi-real time, therefore with a window length even less than 3 h, so loading problems will not occur. Regarding the publication of historical data (e.g., data of the last year, or last month, every year or every month), carrying out the process with a time window of 3 h is not a limitation. In the end, it could also be interesting to analyse the response time of the queries. Different SPARQL queries have been performed during the test phase and very fast responses have been obtained, even given the high number of observations stored in the endpoint. In particular, Table 4 contains some statistics related to the queries presented in Section 4.3 and the queries reported in Appendix B. This approach has proven to be very effective in publishing Linked Data. The robustness provided by OpenLink Virtuoso (open source edition) allows efficiently managing large quantities of triples. Furthermore, its ability to manage geospatial data makes it a valuable tool for our purposes. To the best of our knowledge, Virtuoso open source edition does not support the creation of RDF views over external databases, so the Karma tool has been used in our pipeline to convert relational data into RDF triples. Moreover, an instance of LodView has been adopted to obtain graphical representations of the data hosted in the Virtuoso endpoint. In the end, this completely open-source approach is well suited for handling a large amount of geospatial data and will be the base for further improvements.