Design of a pollution ontology-based event generation framework for the dynamic application of traffic restrictions

Introduction

Related work

This section provides a summary of the existing work on traffic forecasting. The majority of the work uses the long short-term memory (LSTM) recurrent neural network (RNN). For example, Kang, Lv & Chen (2018) employ various input settings in LSTM-RNN predictions, which include traffic flow, speed and occupancy. In their work, Bogaerts et al. (2020) use graph convolution to provide the spatial features of traffic and its temporal features by means of long short term memory (LSTM). In addition, some authors include weather conditions as an important feature, such as Awan, Minerva & Crespi (2020a), who propose an LSTM-RNN with which to improve road traffic forecasting using air pollution and atmospheric data in Madrid. In Tehran (Iran), Sadeghi-Niaraki et al. (2020) made a classification of weather conditions, weekdays, and hour days and presented a short-term flow traffic prediction model based on the modified Elman recurrent neural network model (GA-MENN). Some authors have used other approaches. For example, Zhou et al. (2021) combined RNNs and convolutional neural networks (CNNs) by sliding windows over a map, while Vélez-Serrano et al. (2021) proposed CNNs for the spatio-temporal structure of a set of sensors. In their work, Zhang & Kabuka (2018) used RNN to predict traffic flow on the basis of weather conditions such as temperature, smoke or wind speed. In Hou, Deng & Cui (2021), the temporal correlation and periodicity of traffic flow data were integrated with the disturbance of weather factors in order to compare different deep learning algorithms, while Essien et al. (2021) proposed a new approach in which social networks such as Twitter were used to predict the traffic flow in Greater Manchester, United Kingdom. The work of Brunello et al. (2019) shows how weather and air quality conditions were correlated in order to predict traffic flow in Wroclaw, Poland, and Lee, Jeon & Sohn (2021) used spatial-temporal correlations to develop a traffic-speed predictive methodology in Gangnam, Seoul, Korea. According to Ma, Song & Li (2021), some of the factors in inter- and intra-day traffic patterns can be critical. In Guiyang, Guizhou province, China, Wang et al. (2020) implemented a traffic flow prediction method by combining the Group method of data handling (GMDH) with the seasonal autoregressive integrated moving average (SARIMA). In their work, Bie et al. (2017) used loop detectors to collect data on Whitemud Drive, Edmonton, Canada, and introduced weather factors in order to free flow speed, capacity, and critical density in the METANET model, while Shahid et al. (2021) proposed a framework in which regression models were used to forecast air pollution caused by road traffic. However, most works have not considered pollution as key feature for their predictions. To address this issue, few works have applied ontologies to improve smart cities environments (Espinoza-Arias, Poveda-Villalón & Corcho, 2020; Mulero Martínez et al., 2018). For instance, Gonzalez-Mendoza, Velasco-Bermeo & López Orozco (2018) represented a pollution and traffic knowledge within a domain through ontologies. These ontologies classify things, actions, features based on traffic status and pollution status. This approach is very useful to implement control traffic systems in smart cities to reduce pollution levels. Accordingly, many cities have recently published public protocols with which to combat traffic pollution levels. We believe that pollution levels affect traffic patterns because these protocols activate restrictions related to speed, access to districts and parking. The pollution protocol model has, to the best of our knowledge, not yet been studied in literature. We believe that it is necessary to understand the importance of protocols in order to improve traffic forecasting.

Methods

The objective of this article is to design a methodology for the dynamic adoption of traffic restrictions. As shown in Fig. 1, our framework consists of three layers: Data Layer, Prediction Layer, and Event Generation Layer. A more detailed explanation of our framework is provided as follows. The Data Layer extracts all the data from the Madrid City Open Data portal in csv format, and these files are consumed by the Prediction Layer. This layer ingests this data and its output is a forecast. This forecast, which is generated by a time series ML algorithm, returns future pollution values. These predictions are inferred by the ontology in the Event Generation Layer. This ontology internally normalises the official pollution protocol published by the Madrid City Council in 2020. This protocol establishes different alarm levels depending on the air quality values: In the range of [180–200) mg/ $m^3$ are Early Warning level, in the range of [200–400) mg/ $m^3$ are Warning level, and values greater than 400 mg/ $m^3$ are Alert level. Therefore, the output of this ontology is an alarm pollution level (Inactive, Early Warning, Warning, and Alert) according to this pollution protocol.

Data layer

This layer collects historical data in order to feed our framework. First, a large set of data regarding traffic intensities and pollution levels was stored, after which we collected data from the Madrid City Council’s Open Data website (Madrid City Council, 2022) in CSV format. Moreover, we extracted data related to weather conditions and local calendar from the same source. This raw data is provided by more than 4,000 traffic intensity sensors, 26 weather stations and 24 air quality stations. For our prediction case, we focused on Madrid Central. This area constitutes the urban core, which consists of around 50 traffic intensity sensors together with one station for weather and air quality (Fig. 2).

Traffic status data in Madrid covers the entire metropolitan area of the city. As shown in Table 1, we filtered the data of those stations that are inside the target area. From an initial number of 4,000 traffic sensors, around 50 have been chosen that are located within Central Madrid. We extracted the main values that are related to traffic from these stations: intensity and occupancy. Intensity is the number of vehicles that pass through a fixed section in a given time, while occupancy is the ratio between vehicles and the distance between vehicles on the road per lane, represented as a percentage. Accordingly, we reduced the number of columns compared to the original. In this case, we reduced the ones that we considered important from 13 columns to six. The selected columns are the following:

Table 1:

Dataset analysis of rows and columns.

Dataset	No. rows	No. rows	No. columns	No. columns
name	(Original)	(Filtered)	(Original)	(Filtered)
Traffic status	28,247,866	8,760	13	6
Weather	33,852	8,760	12	3
Air quality	1,332,889	8,760	13	3
Local calendar	28,567	365	19	3
Merged dataset (prediction input)	8,760	8,760	9	10*

Note:

* These columns are explained in the Prediction Layer section (see Table 2).

Table 2:

Features considered in order to train the model.

Feature	Label	Value/unit
Hour	hour_of_day	0–23
Time of day	Day sin & Day cos	[−1,1]a
Time of year	Year sin & Year cos	[−1,1]b
Weekday	day_of_week	1–7
Holiday	is_holiday	0–1
$N{O}_2$	no2_level	mg/ $m^3$
Temperature	Temperature	°C
Humidity	Humidity	%
Traffic occupancy	Occupancy	0–100
Traffic intensity	Intensity	Veh/h

DOI: 10.7717/peerj-cs.1534/table-2

Notes:

a Day (seconds) = 24 (h/day) * 60 (min/h) * 60 (sec/min).

b Year (seconds) = 365.25 (days/year) * day (sec).

• id: Sensor identification code (integer)

• date_timestamp: Date timestamp (timestamp)

• date_id: Date time (integer)

• hour_of_day: Hour time (integer)

• intensity: Traffic intensity value (double)

• occupancy: Traffic occupancy value (double)

Currently, there are 26 weather stations in Madrid, but we filtered all the data to collect the data referring to the Madrid Central district. Afterwards, we merged temperature and humidity values due to their importance in our study. The final dataset have been reduced from initial 12 columns to three.

• date_id: Date time (integer)

• humidity: Weather humidity value (double)

• temperature: Weather temperature value (double)

Air quality data represents the urban levels detected by 24 stations. In the same way as with the weather data, we used the data related to the Madrid Central district. The original data comes with several magnitudes related to air quality, but we focused on the magnitude that is established in the pollution protocol. The Madrid pollution protocol uses only the $N{O}_2$ magnitude to apply different restrictions and this motivates the use of this magnitude in our study. As in the previous cases, we decreased the number of columns from 13 to three:

• date_id: Date time (integer)

• hour: Hour time (integer)

• value: $N{O}_2$ value (Double)

Local calendar data includes all public holidays and working days throughout the year in Madrid. This distinction is important to be able to distinguish how labor mobility influences traffic. We selected three columns out of 19 possible columns:

• date_id: Date time (integer)

• day_of_week: Day of the week (integer)

• is_holiday: Working/Holiday (integer)

Merged dataset combines the information needed by our architecture. This match is based on date and time. We used date_id to make this combination possible and build this dataset. The columns are as follows:

• date_timestamp: Date timestamp (timestamp)

• hour_of_day: Hour time (integer)

• day_of_week: Day of the week (integer)

• is_holiday: Working/Holiday (integer)

• no₂_level: $N{O}_2$ value (Double)

• humidity: Weather humidity value (double)

• temperature: Weather temperature value (double)

• intensity: Traffic intensity value (double)

• occupancy: Traffic occupancy value (double)

Prediction layer

This layer represents our pollution level forecasting. Our analysis is divided into two categories: (1) statistical-based feature selection analysis and (2) predictive analysis. We first correlated weather, local calendar and air quality conditions with traffic intensity status. This approach makes it possible to explain the choice of features and their influence on traffic. We then collected and analysed metrics in order to attain a highly accurate pollution level using LSTM-RNN.

Statistical-based feature selection analysis

As illustrated in Fig. 3, we randomly selected two traffic intensity sensors (4301 and 4306) in a 250–m perimeter of the weather and air quality station (35) in order to explain the correlation of the different features. This selection depended on the analysis of the aggregated data in order to understand any possible correlations among weather, air quality and the local calendar, and the hourly traffic status obtained from nearby traffic sensors. These correlations were then accordingly plotted in order to visualise patterns.

Our first analysis consisted of examining the most frequent traffic intensities. As illustrated in Fig. 4, the most frequent traffic intensity at Sensor 4301 is between 0 and 250, which appears more than 2,000 times. The least frequent is between 1,250 and 1,500, less than 100 times, while the mean is slightly higher than 400 vehicles/hour. This sensor, therefore steadily decreases from 250 to 1,000, but there are some low values above 1,000 that appear infrequently. In the case of sensor 4306, the most frequent is between 750 and 1,000, which occurs more than 2,000 times. The least frequent is between 1,500 and 1,750, less than 100 times, while the mean is slightly lower than 600 vehicles/hour. This sensor does not behave in a regular manner and consequently has a significant effect on the results. This signifies that some other variables are influencing traffic intensity.

Our second analysis focused on weather conditions. Figure 5 shows the correlation between temperature and traffic intensity. These values are the mean values obtained for both sensors. At first glance, the lower the temperature, the higher the number of vehicles passing by sensor 4301. Even if in the case of the 4306 sensor, the ranges (25–30] and (30–35) also present higher values. These optimal values are located roughly between the ranges (5–10] and (10–15]. With regard to sensor 4301, the highest value is located within the range (10–15], while the lowest values are influenced by temperatures of over 20 degrees. Sensor 4306 behaves in a similar manner to sensor 4301, but the lowest values are within the range (15–20]. The temperature consequently affects urban traffic intensity, thus it is necessary to study other variables that, together with temperature, can better explain certain differences in other results between the two sensors.

The third analysis was based on humidity in order to estimate rainfall days. As shown in Fig. 6, the humidity affects the traffic intensity at sensors 4301 and 4306. The higher the humidity, the higher the number of vehicles detected by the sensor. On the one hand, the highest values are located in the range [80–100) for both sensors, while on the other, the lowest values are in the range [20–40]. These results evidence the importance of humidity and temperatures as regards predicting future traffic intensities.

In our fourth analysis, we analysed the importance of local calendar traffic intensities. The bank holidays in Spain can fall on any day of the week and there may also be different values depending on the local calendar. As illustrated in Fig. 7, holidays affect the number of vehicles passing by both sensors. On the one hand, bank holidays that fall on Mondays have higher values than those for working Mondays at sensors 4301 and 4306. On the other, working Fridays are significantly higher than holiday Fridays. Both sensors provide similar behavior for the other weekdays. Sensors 4301 and 4306 have higher values for working Tuesdays, Thursdays, Fridays and Saturdays, but the absolute values on weekdays at sensor 4306 are higher. This shows the importance of this feature as regards traffic intensity distribution.

The last analysis is related to the importance of traffic intensity in the case of air quality levels. As shown in Fig. 8, traffic intensity affects air quality conditions. We focused on NO₂, since this is the parameter that is taken into account when implementing traffic restrictions in the city of Madrid (station 35). NO₂ behaves similarly to traffic intensity. The peak of vehicles/hour and gas levels detected by sensors 4301 and 4306 takes place between 10 am and 3 pm. Moreover, a valley is observed for both of them between 5 pm and 10 pm. From 3 pm onwards, another significant increase appears that affects both the traffic intensity and the air quality. The max values are very similar for traffic intensity and air quality, with the exception of sensor 4301 for which there is a significant decrease in the last part of the day.

In our statistical-based feature selection analysis was used as the basis on which to consider the following features in our model: Date timestamp, Hour, Weekday, Holiday, NO₂, Temperature, Humidity, Traffic Occupancy, and Traffic Intensity. The only temporal features that do not have a regular periodicity are the months (28–31 days) and years (365–366 days) that can vary over time their values in contrast to hours (24). The management of periodic features demands to control the management of the inputs of the algorithm. Therefore, for objects that exhibit periodic behavior, a sinusoidal function can be used as a modeller since these functions are periodic. These functions solve the curse of dimensionality and longer computational time for machine learning algorithms (Peng et al., 2021).

As illustrated in Fig. 9, we applied this function for time day/year signal due to their periodicity. We calculated the sine as { $sin((x)\ast (2\ast \mathrm{\Pi }/(day\vee year)))$} and the cosine as { $cos((x)\ast (2\ast \mathrm{\Pi }/(day\vee year)))$}, both for every ‘date_timestamp’ in our merged dataset (Data Layer) since 1st January of 2022. Therefore, these new features have been included in our model, instead of the original ‘date_timestamp’ field (Table 2).

As can be observed in Fig. 10, the relationship between the features varies. A heatmap shows the correlation between features, where the clearer the value between two features, the more correlated they are with values closer to 1. Using pollution levels as the basis for our study, intensity and occupancy are the most highly correlated. This validates the previous analysis where changes in pollution levels were reflected depending on traffic. Furthermore, hours have a significant effect for both days and years. By contrast, temperature has a low correlation with pollution levels.

Predictive analysis

Multi-step algorithm benchmarking (1): Before running an algorithm (Fig. 11), it is common to split a dataset into training and testing sets before fitting a statistical or machine learning model (Joseph, 2022). We applied a (80%, 10%, 10%) split for the training, validation, and test sets. Therefore, we split in such a way as to respect the temporal ordering and the model is never trained on data from the future and only tested on data from the future. Secondly, it is necessary to normalise the data in order to guarantee their quality and the accuracy of the machine/deep learning model (Awan, Minerva & Crespi, 2020b). We used one of the most common normalisation technique: Subtract the mean and divide by the standard deviation of each feature. In this technique, the mean and standard deviation should only be computed using the training data so that the models have no access to the values in the validation and test sets (Aksu, Güzeller & Eser, 2019). These features might have had disparate impacts on the quality of our model and we, therefore, studied the importance of each feature considered in order to estimate these possible impacts. Thirdly, the implementation of sliding window time series (SWTS) analysis enables to use the resulting predictor, but the driving data should be presented in the state-space format (Mozaffari, Mozaffari & Azad, 2014).

We used multi-step algorithms in order to work with dynamic and continuous data (Belgasmia, 2021). This approach is applied to discover the best algorithm for our prediction case, we compared the multi-step algorithms most frequently used in the state of the art: Multi-step Dense, LSTM-RNN and CNNs. Some approaches apply Multi-step Dense to classification problems by training them in a supervised manner; LSTM-RNN in time series problems; and CNNs in order to learn multiple layers of feature hierarchies automatically (Ordóñez & Roggen, 2016). The selection was determined by the lowest Mean Absolute Error (MAE) (Šter, 2013). We initialized the algorithms with two different strategies based on split sizes (Table 3).

Table 3:

Multi-step algorithm benchmarking configuration.

Metric	Description	Strategy-1	Strategy-2
lag	Number of lags (hours back) to use for models	168	168
n_ahead	Steps ahead to forecast	24	24
split_size	Split share in testing	80/10/10	70/20/10
epochs	Epochs for training	15	15
batch_size	Batch size	512	512
lr	Learning rate	0.001	0.001
n_layer	Number of neurons in layer	3	3

DOI: 10.7717/peerj-cs.1534/table-3

LSTM-RNN tuning (2): As illustrated in Fig. 11, the best option as regards dealing with temporal patterns is the Long Short-Term Memory Recurrent Neural Network (LSTM-RNN) (Guo et al., 2016). In accordance with our model, the input will be expressed as { $x=(x_1,x_2,...,x_T)$} and the output as { $y=(y_1,y_2,...,y_T)$} with {T} as time in our traffic intensity predictions, following the algebraic expressions shown in Ma et al. (2015). The LSTM-RNN framework works with memory blocks, unlike traditional neural networks, which work with neurons. A memory block has an input gate, an output gate, and a forget gate. The output of the input gate is represented as { $i_t$}, the output gate as { $o_t$}, and the forget gate as { $f_t$}. Moreover, the cell and memory activation vectors are symbolized as { $c_t$} and { $m_t$}, with { $b$} and {W} representing the bias and the weight. The centered logistic sigmoid functions are { $h$} and { $g$}. Nevertheless, the lack of connection among neurons within the same layer has some limitations and increases the failure ratio in terms of spatio-temporal reasoning (Zhao et al., 2017).

To carry out this analysis, we defined five types of algorithm optimizations: Regression, Windowing regression, Timesteps regression, Batch memory, and Stacked batch memory. Accordingly, it is necessary to do a deeper study on the optimization of the algorithm: LSTM-RNN tuning. In a more detailed explanation of each optimization, Regression is the base calculation methodology for predictions. Windowing regression is intended to emulate the problem so that multiple recent steps can be used to make the prediction for the next time step. Timesteps regression takes previous time steps in our time series as inputs to predict the output at the next time step. Batch memory builds states throughout the entire training sequence and even maintains them if necessary to make predictions and lastly, Stacked batch memory which is the addition to the configuration that is required is that an LSTM layer before each subsequent LSTM layer must return the sequence for the predictions. To each of them we applied a series of strategies that are detailed below (Table 4).

Table 4:

LSTM-RNN tuning configuration.

Metric	Strategy-1	Strategy-2	Strategy-3	Strategy-4	Strategy-5	Strategy-6	Strategy-7	Strategy-8
lag	168	168	168	168	168	168	168	168
n_ahead	24	24	24	24	24	24	24	24
split_size	70/20/10	70/20/10	70/20/10	70/20/10	80/10/10	80/20/10	80/10/10	80/10/10
epochs	15	30	15	30	15	30	15	30
batch_size	512	512	512	512	512	512	512	512
lr	0.001	0.001	0.001	0.001	0.001	0.001	0.001	0.001
n_layer	4	4	8	8	4	4	8	8

DOI: 10.7717/peerj-cs.1534/table-4

Event generation layer

The objective of this layer is to translate the Madrid City Pollution Protocol (Madrid City Council, 2022) into our own intelligence in order to generate events according to NO₂ levels. As shown in Fig. 12, we have designed an event-based ontology in order to express this logic semantically. We analysed other works that established ways to adapt the logic of smart cities within decision making. For this reason, we based the design of our ontology on the semantic expression works analysed in the ‘Related Works’.

We first studied different protocols and activation plans. This process is helpful as regards defining the ‘Core Ontology’ hat contains the main class Protocol with sub-classes such as Pollution, Health or Security. All cities have different protocols for specific areas, and this level is where they relate to each other. We then defined the Protocol ‘Domain Ontology’, which shows the different NO₂ activation levels as Early Warning, Warning, and Alert. Early Warning activates when values exceed 180 mg/ $m^3$, Warning 200 mg/ $m^3$, and Alert 400 mg/ $m^3$. In addition, pollution has different scenarios depending on air quality levels and number of times that any alarm has been activated. Finally, we connected our logic with the lowest level of the ontology. This level is denominated as ‘Instance Data’, where our ontology infers the predictive data. The relationship between the concepts is through the alarms that are generated based on pollution levels and the stations. The station has a category associated with it and belongs to a specific district within the city of Madrid. An external file (csv) contains all the fields required in order to activate any level (datetime, url, itemId, itemName, brandName, itemStation, itemCategory and itemLevel). We run a python script that imports this file in our graph database. Our Domain Ontology was created in OWL format (World Wide Web Consortium (W3C), 2022) and stored in an NEO4J graph database (Neo4j, 2022) to carry out this approach. This approach has already been used in Gong et al. (2018).

Results

Multi-step algorithm benchmarking (Predictive analysis): In Table 5, we collected the results of algorithms benchmarking. LSTM-RNN (‘LSTM’) has the best performance when compared to CNN (‘Conv’) and Multi-Step Dense in both strategies. These two strategies provided different results depending on the dataset split strategy. This indicates that there is a better performance of any metric (MAE, MSE, and RMSE) increasing 10% the train data. From this analysis it can be deduced that the LSTM-RNN algorithm together with a strategy of 80%/10%/10% allows to obtain the best performance. Therefore, this is the base configuration of our model before its optimization.

As illustrated in Fig. 13, the more we increase the number of training data instances, the better results are obtained. Aligned with what was explained in Table 6, the experiment 6 is the one with the best performance.

In Fig. 14, we compared the top three experiments through its metrics (MAE, MSE and RMSE).

Experiments 5 and 3 have very similar values close to 27 in the RMSE, while experiment 6 improves both performances in this metric. This indicates the absolute fit of the model to the data, how close the observed data points are to the predicted values of the model. In the case of MAE, the experiment is the only one that approaches 20, which represents the mean absolute error between the predictions of the training and the test.

LSTM-RNN Forecast (Predictive analysis): As evidenced in Fig. 15, most of the experiments are between the range of 6 and 8 of MAE. It can be ensured that the experiments that have a higher training MAE have worse performance at the test level. In addition, the models are better in those where the MAE of train improves that of test. In the other cases, there is surely underfitting and the model does not generalize well.

We collected experiments results in Table 6. A total of forty experiments have been carried out combining the eight strategies defined based on splits, epochs and layers.

As shown in Fig. 16, the best algorithms have been selected based on the strategy. It can be seen how the optimizations through regression, windowing regression and timesteps regression have values less than 8 of MAE for both the training and the test. On the other hand, the optimizations through batch memory and stacked batch memory exceed in at least one of them at the threshold of 8, and even 10 of MAE in some cases. In general, it can be concluded that strategies 5 and 6 are the ones that have obtained the best results for all the experiments. This is because the data has been increased by 10% and that significantly influences performance.

In Fig. 17, we compared the top five experiments through its metrics (MAE, MSE and RMSE). Experiments 27 and 31 have very similar values close to 10 in the RMSE, while experiment 28 improves both performances in this metric. This means the squared difference between the predictions and the target and then averages those values. In the case of MAE, five experiments are around seven, which illustrates the mean absolute error between the predictions of the training and the test.

Ontology inference (Event Generation Layer)

As shown in Fig. 18, the quarterly forecast does not trigger any alarms originating from pollution protocol levels. This implies that no traffic restrictions will be activated because the NO₂ levels are not reaching the minimum of any of the pollution protocol levels (Early Warning, Warning and Alert).

As shown in Fig. 19, our ontology was used to infer NO₂ level data in order to discover the location and the active pollution level. This figure illustrates how our instance data is linked to our domain ontology.

As explained in the definition of the Pollution Protocol Domain Ontology (see Event Generation Layer), the ‘Domain Ontology’ is represented with its alarm levels and established scenarios (orange color). These alarm levels have a defined range of NO₂ pollution in accordance with those established in the official protocol. On the other hand, in the ‘Instance Data’ we have the stations (light purple color) and their different attributes: category (green), air quality (brown), and district (red). The ‘Instance Data’ will be connected through the ‘triggers’ relationship in the event that one of its values at a given time is within the range established within an alarm level. This happens because each station provides a range of pollution levels according to the predictions. For instance, in this figure the relationship ‘triggers’ connects ‘Station 35’ to the alarm level ‘Inactive’ based on some datetimes in Q1 2023. In this case, no level remained active for these datetimes.

Discussion

Designing a dynamic application of traffic restrictions is based on connecting Pollution Level Alarms with different scenarios. Madrid City Council provides five scenarios depending on the alarm level and duration (Madrid City Council, 2022). Certain restrictions are applied in these scenarios, such as speed limits and access to districts:

• ‘Scenario 1’ restricts the speed limit to 70 km/h.

• ‘Scenario 2’ restricts the speed limit to 70 km/h, and access is authorised for ‘Zero emission’ ehicles (excluding taxis).

• ‘Scenario 3’ restricts the speed limit to 70 km/h and access is authorised for ‘Zero emission’ ehicles (highly recommended for taxis).

• ‘Scenario 4’ restricts the speed limit to 70 km/h and access is authorised for ‘Zero emission’ ehicles (recommended for taxis).

• ‘Scenario Alert’ restricts the speed limit to 70 km/h and access is authorised for ‘Zero emission’ (including taxis).

As shown in Table 7, the alarm level and duration establish the requirements needed in order to activate any of the pollution protocol scenarios.

As illustrated in Fig. 18, neither the quarterly forecast data (Year 2023) nor the data in 2022 exceeded pollution alarm thresholds. In order to validate our approach, we carried out the same methodology in case the contamination protocols were expanded to other districts. For this, we used the Salamanca district as the basis for our validation. We compared this district with Madrid Central to analyse the possible differences in results at the same datetime.

As seen in Fig. 20, the datetime ‘2022-02-21 22:00:00’ exceeded ‘Early Warning’ level, and the datetime ‘2022-09-09 11:00:00’ a ‘Warning’ level. Other datetimes remained at the ‘Inactive’ level. The dates ‘2022-02-21’ and ‘2022-09-09’ would activate ‘Scenario 2’ of the Pollution Protocol. We then inferred this data to verify this scenario. We applied our validation with the datetime ‘2022-02-21 22:00:00’ because it refers the first quarter.

As evidenced in Fig. 21, ‘Station 35’ (Madrid Central district) triggers an ‘Inactive’ level, while ‘Station 8’ (Salamanca district) triggers an ‘Early Warning’ level. We see how the output of the inference is displayed both in the Neo4J dashboard and within a Kafka topic.

Scenario 2 applies some restrictions related to speed limits and access to districts. The speed cannot exceed 70 km/h at district access points during the activation of this protocol scenario. Moreover, driving without an environmental ‘Zero emissions’ label is prohibited. These restrictions are applied the day after the activation of the scenario.

It is consequently possible to confirm that our contamination protocol ontology works correctly as regards triggering a pollution level alarm. On the one hand, it has been able to transfer the pollution predictions to the first quarter of 2023, and on the other hand, it has allowed us to see how it would work with several stations at the same datetime.

As a final part of the discussion, we wanted to explain the validity of our approach through a flowchart (Fig. 22). Flowcharts serve as a pictorial means of communicating from one person to another the temporal order of events or actions through American National Standard Institute (ANSI) (Chapin, 2003).

Based on these standards, our validation process begins with the definition of the research question: Predict traffic restrictions. For this, we established Central Madrid as the validation scenario. On the one hand, we investigated if there is any public that limits the restrictions in this district: the protocol of political contamination. This protocol determines a series of scenarios based on thresholds based on air quality pollution levels. At this point we considered the need to generate a system that could launch alarms when the contamination levels established in the protocol were exceeded. This led us to create an ontology based on the contamination protocol and store it in a graph database (NEO4J) as the basis of the approach. On the other hand, in order to validate this approach, we needed to have historical data in order to work: Madrid City Open Data. We focused on generating a first dataset to merge the levels of traffic, weather, air quality and local calendar as a basis for our study. We then filtered by stations that were within the Madrid Central district boundaries to create a dataset. On this dataset, we defined the objective of working on predictions, but using historical data as part of the validation test. In order to make the predictions, we analysed the time series algorithms that could give the best results to select the one with the best metrics. At this point, we needed to join the ontology stored in our graph database (NEO4J) with the output data of the predictions and we established a streaming data management tool (Kafka). This tool had a connector with the database to launch queries that returned the alarm levels of the stations based on those predictions: Inactive, Early Warning, Warning and Alert.

Conclusion

This work shows the impact of traffic on pollution levels. We used real data in order to estimate and predict future pollution level values. Moreover, we integrated the Madrid City Council pollution protocol scenarios into our ontology in order to automatically trigger alarms based on pollution threshold levels. This system provides advantages by which to include local pollution policies based on traffic predictions. This has been accomplished by proposing a framework with an additional layer of events that takes into account the variability of the specific prediction case for air pollution forecasting with local policies. Our approach employs this framework in order to overcome certain limitations indicated in literature. Authors stated the need for dynamic systems with which to manage real time traffic status based on pollution protocols (Rodriguez Rey et al., 2021). The approach presented in this work, therefore, triggers events/alarms on the basis of Madrid city council’s pollution protocol. Moreover, we included local calendar holidays or traffic occupancy, which have not been considered in previous research (Borge et al., 2018). We showed the effect of holidays and weekdays on traffic and pollution levels. We also justified the use of deep learning techniques in forecasting systems (Pappalardo et al., 1998), in addition to validating our ontology and the entire framework. This framework, therefore, has the potential to be dynamic and to adapt to what is happening in real time scenarios. This might be useful as regards extending traffic restriction policies and testing the effects in different pollution scenarios in the city, thus enabling local governments to comply with EU air quality standards in order to improve the quality of citizens’ lives.