FI in Barcelona

One of the Barcelona’s northern accesses is a tunnel that has a reversible lane which changes depending on traffic demand and direction. The Flexible Infrastructure service informs the users about the reversible lane status in advance, to anticipate their manoeuvres.

Sample Data Description

For the evaluation of the Flexible Infrastructure service deployment in Barcelona, the relevant log items are the iviaction, ivievent and CAM log files. All of these log files are automatically recorded by the PID of the user. The ivievent logs contain the basic information for each event (e.g. timestamp, log_stationid, iviidentificationnumber etc.). The iviaction logs contain the status of the HMI and thus record the information that was presented to the driver at each moment in time with a frequency of approximately 1Hz. The following fields are particularly relevant for the Flexible Infrastructure data:

• servicecategorycode (=13), pictogramcategorycode (=659, ‘tidal lane closed’ or 660, ‘tidal lane opened’) to filter the relevant FI events
• Lanenumber: indicating the lane for which the message applies
• Lanestatus: indicating whether the lane is open or closed
• Warningdistance: indicating the distance to the event location

The CAM logging is mainly used to derive the vehicle position, speed and acceleration for the entire duration of the event, also at a frequency of approximately 1Hz. For a more in-depth description of the logging format and the data fields in each log type please visit Open Common Log Data Format.

The example data set provided here consists of all Flexible Infrastructure events logged in Barcelona between 01/10/2020 and 01/04/2021. The data set includes both baseline and treatment events. ‘Baseline’ indicates that the service was not active (no information was presented to the driver) and is used as a point of reference, whereas ‘treatment’ events are logged when the service is fully functional. Separating events by baseline/treatment is possible by analyzing the content of the tlmaction log files and, more specifically, by checking for the existence of rows where eventmodelid==6 (indicating that certain information was displayed on the screen). The App by IDIADA deployed in Barcelona randomly switches between baseline/treatment with pre-defined probabilities (percentage of baseline events is 25%). Therefore, the example data set provided here consists of roughly 280 treatment events and 70 baseline events.

To simplify the provision and processing of data, all iviaction logs are grouped into one iviaction.csv file, all ivievent logs into one ivievent.csv file and all CAM logs into one CAM.csv file. Individual events can be identified through unique combinations of the (log_stationid, eventid) fields. As defined in the log format specification, each event should begin with eventmodelid=5 and eventactionid=1 and end with eventmodelid=5 and eventactionid=3. In case there are multiple instances of these combination for one event, the first (5,1) and (5,3) are used to define the start and end of the event.

You can download the log data here.

Sample Data Description (BOR)

For the evaluation of the Flexible Infrastructure service deployment in Bordeaux, the relevant log items are the iviaction, ivievent and CAM log files. All of these log files are automatically recorded by the PID of the user. The ivievent logs contain the basic information for each event (e.g. timestamp, log_stationid, iviidentificationnumber etc.). The iviaction logs contain the status of the HMI and thus record the information that was presented to the driver at each moment in time with a frequency of approximately 1Hz. The following fields are particularly relevant for the Flexible Infrastructure data: 

• servicecategorycode (=12),  
• pictogramcategorycode (=134, ‘car pooling’ or 129, ‘bus allowed on hard shoulder’) to filter the relevant FI events 
• Warningdistance: indicating the distance to the event location 

The CAM logging is mainly used to derive the vehicle position, speed and acceleration for the entire duration of the event, also at a frequency of approximately 1Hz. For a more in-depth description of the logging format and the data fields in each log type please visit Open Common Log Data Format.

The example data set provided here consists of all Flexible Infrastructure events logged in Bordeaux between 01/10/2020 and 01/04/2021. The data set includes both baseline and treatment events. ‘Baseline’ indicates that the service was not active (no information was presented to the driver) and is used as a point of reference, whereas ‘treatment’ events are logged when the service is fully functional. Separating events by baseline/treatment is possible by analyzing the content of the tlmaction log files and, more specifically, by checking for the existence of rows where eventmodelid==6 (indicating that certain information was displayed on the screen). The NeoGLS app deployed in Bordeaux randomly switches between baseline/treatment with pre-defined probabilities (percentage of baseline events is 25%). Therefore, the example data set provided here consists of roughly 280 treatment events and 70 baseline events. 

To simplify the provision and processing of data, all iviaction logs are grouped into one iviaction.csv file, all ivievent logs into one ivievent.csv file and all CAM logs into one CAM.csv file. Individual events can be identified through unique combinations of the (log_stationid, eventid) fields. As defined in the log format specification, each event should begin with eventmodelid=5 and eventactionid=1 and end with eventmodelid=5 and eventactionid=3. In case there are multiple instances of these combination for one event, the first (5,1) and (5,3) are used to define the start and end of the event. 

Since the main aim of the service is simply to inform users about the current road configuration and no major impacts on the traffic flow are expected, evaluation data and results are not presented for the FI service. 

You can download the log data here.