{'fraction_non_alphanumeric': 0.024930802688809806, 'fraction_numerical': 0.0073349149861605374, 'mean_word_length': 5.017965496728138, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
An operational framework to integrate traffic message channel (TMC)in emergency mapping services (EMS)

ABSTRACT Traffic Message Channel (TMC) is a technology for delivering traffic information to vehicle drivers. Sources of traffic information typically include police departments, Traffic Information Centers (TICs), camera systems, traffic speed detectors, floating car data, so on. Both public and commercial TMC services are operational in many countries. TMC messages can be also exchanged among TICs formally using standard protocols. The term emergency mapping (EM) encloses all activities finalized to produce geographic data on the consequences of a natural or man-made events. Emergency mapping services (EMS) normally exploit satellite or aerial imagery in order to extract the extent of the area affected and the impact on local infrastructures. In this paper, the authors verify the impact of the integration of TMC information in routinary EMS, exploiting the flood event occurred in November 2016 in north-west Italy as a case study. After an introduction to the problem and a description of TMC technology and of EMS, all technical aspects related to the integration of the two services are deeply described. Extracted traffic events have then been integrated and compared with EM products generated for the event previously mentioned. Finally, opportunities, limits, future enhancement and refining are summarized in the conclusions.


Introduction
Nowadays, thanks to the development of Web 2.0, there is a general increase in need of interactive maps and realtime information. Periodically the Copernicus Emergency Management Service -Mapping module (EMS-Mapping) revises the activity done and decides which will be the directions for the future. In the last periodical User Workshop of the Copernicus EMS-Mapping (2016) some suggestions and improvements for the service have been provided: in particular, many users request the publications of interactive maps that allow real-time situation monitoring. In addition, managers and producers underline the need to improve the accessibility of EMS-produced data-enabling Web Map Services (WMS) and Web Feature Services (WFS) (Wania et al., 2016).
Another known limitation of satellite EMS is related to the timely availability of satellite imagery: services like Copernicus EMS-Mapping are based on the availability of remote sensing imagery and in emergency situations timing is critical. A recent research (Voigt et al., 2016) highlights that from the triggering process to the delivery of the imagery it passes 2 days on average, and this is critical time compared to the 6-8 h required for the map production. On this perspective, solutions for speeding up imagery triggering and delivery phases are needed (Ajmar et al., 2015a;2015b).
The spread of traffic event localizations, managed and made available by Traffic Information Centers (TICs), is an activity widespread in most parts of Europe and North America. These centers offer well-established services with underlying certification process, which guarantee the reliability of information. The availability of this information in an integrated way to emergency response services, such as Copernicus EMS-Mapping, could have high benefits (Boccardo et al., 2014). In fact, traffic information could be used during the production activity, for example, by helping in spotting and reporting damages to infrastructures and in reporting road blocks. Additionally, in the pre-activation phase and in case of a large amount of traffic events (likes roads and bridge closures) located over a specific territory area, an automatic triggered alert can be delivered to EMS-Mapping managers, who can therefore decide to pretask satellite platforms and consequently reduce imagery delivery times. Furthermore, the position of traffic events can be used as ancillary information to better define the areas of interest that could be most affected.
If during the production activity traffic event usage can provide auxiliary information that can support in damages search and in the delineation of the emergency events, an information flow in the other direction may also be relevant: map producers can highlight new damages not still acquired by TICs and so directly share the information with them and, through traffic message channels (TMCs), with the general public.
The integration of the two services goes in the direction of the development of interactive web service with a real-time communication, completely in line with the future direction for the Copernicus EMS-Mapping. This paper investigates integration modalities between these two services: firstly main components and data models of the provided data are analyzed, deepening the problem of location referencing when there is a sharing of information between multiple sources. The flood event occurred in November 2016 in the northwestern part of Italy is used as case study, in order to evaluate the possible matching between the information provided by Copernicus EMS-Mapping and the traffic events gather and distributed by Piedmont Region Traffic Operation Centre, managed by 5T Company. To our knowledge, this is the first demonstration of integration between traffic information and emergency management information: the potential mutual enrichment among sources, limitations of the procedures and possible further developments are highlighted and described.

Description of TMC technology
TMC is the acronym that stands for Traffic Message Channel and indicates, globally, a standard service for traffic information distribution. It is a technology for spreading digital traffic information either to final users using the FM-RDS (Radio Data System) on FM radio transmissions or among TIC using DATEX (DATa EXchange) or DATEX II protocols, via dedicated operational nodes.
Moreover, using the TMC, all traffic information services can also be transmitted on other transmission channels including digital radio (Digital Audio Broadcasting -DAB), satellite radio, Internet or GSM (Global System for Mobile communications)/GPRS (General Packet Radio Service) mobile network.
TMC is defined and maintained by the TMC Forum, a non-profit organization that maintains the TMC standard (EN ISO 14819), while the RDS system is defined by the IEC 62106 standard and DATEX by CEN/TS 16157 Standard. In 2007, the TMC Forum joined Transport Protocol Experts Group with the current Traveller Information Services Association.
All the TMC-based traffic events contain information about the localization referred to the TMC locations database, called Location Code. Basically it consist in a set of tables that represent the main road network implementing a sort of raw graph, with a set of points associated to a specific geographical point on the real road (e.g. main intersection, ramps, etc.) and arcs that connect couple of points, coded for machine-to-machine communication. In this perspective, a TMC Location Code (LCD), since is associated to a specific geographical location on the road network, it is used as reference for TMC events codification and localization.
In order to guarantee the interoperability, the TMC database must be unique for each country, because in all European Union countries, all TICs and Traffic Control Centers must use the same TMC database to communicate. The TMC database for Italy is hosted by the "Centro di Coordinamento Informazioni sulla Sicurezza Stradale" (CCISS), National TIC for Italy, which regularly update it and make it available on the Ministry of Infrastructures and Transport web site. 1 All traffic information is sent via a TMC message consisting of an event code, a localization code and some additional information such as the expiration time.
A TMC message is encoded and may be encrypted, according to the specifications defined by the TMC protocol. It contains a list of events that can be translated by a TMC receiver in the user's language. The receiving system decodes messages and can display alerts on the map, via the TMC protocol and the localization tables already integrated in the maps of the major vendors. It can also present the message in text form, translating it into the user's language; all TMC receivers use the same list of event codes as the location database contains a set of country-specific location codes.
This technology, consolidated, reliable and economical, nowadays allows for the "silent" spread of information not only to FM radio receivers but also to connected satellite navigators enabled to receive TMC signals, which thanks to the geo-referencing in the RDS-TMC information, visualize TMC events on map in real time as it occurs on the journey path, allowing the navigator's computer to calculate and propose new travel path to drivers, according to the real-time traffic conditions.
To guarantee interoperability among different TMC receiver devices and countries, the adoption of international standards is a must; Table 1 summarize the main standards related to the TMC and its usage.
The current TMC standard for localization allows to identify points known as Location Code, with indication of the exact point where the traffic event problem occurred, using an offset indication from the position of LC, as shown in Figure 1.
TMC message encoding is mainly divided into two parts: (1) Location description: encoding the data that identifies the place to which the message relates and (2) Event description: consists of an event code plus duration time and other information details.
The location description can be further subdivided into three parts: (1) primary location: where the event is located; (2) extent: indicates which other points are involved; and (3) direction bit: indicates the direction of the event-affected traffic flow. Localization of TMC event is particularly important; the Table 2 reports an example of several fields: Let us briefly outline the table just shown below: • Location code: identifier between 0 and 65536 describing segment of road, intersection or region. • Type: defines the type of location in three main categories and a defined number of sub-categories: Area (A), Linear Location (L) and Points (P). In the above example, L3 identifies a link road, A6.2 describes a metropolitan area, P3.2 a bridge, P1.3 an intersection and P3.3 a service area. • Road number: the street reference number. • Name 1: the name of the primary location that must be displayed by the receiver. • Name 2: the name of a secondary location required to describe a road segment. • Ref A: a pointer to an area where the segment belongs. • Ref L: a pointer to the road section to which the location belongs. • Negative offset: a pointer to the previous area or location (e.g. on the same road segment).   • Positive offset: a pointer to the next area or location (e.g. on the same road segment).

RDS technology
TMC is often associated with the most well-known RDS, the so-called RDS-TMC, since TMC traffic information messages are generally transmitted by an FM radio station. A formal description of traffic events is so coded and broadcasted to RDS-enabled radio receivers as shown in Figure 2. The RDS data transmission system was developed by the European Broadcasting Union (EBU); the first specifications have been published in 1984. Further clarifications, minor corrections and extensions were introduced by CENELEC and published in 1992.
The system has been developed to allow digital data to be transmitted to commercial broadcasters operating in VHF in frequency modulation without interfering with normal audio band modulation.
The RDS signal has been adopted as a European system for the transmission of program identification, control data and messages, as well as radio texts, which can be sent simultaneously to the radio program.
The TMC is sent using a "virtual language" in which the transmitted codes refer to information stored in the databases in the receiver terminals. These databases contain lists of possible road traffic situations, including traffic issues and weather conditions, suggestions, duration and other drivers' useful information, along with the list of locations, including intersections, street numbers and street names.
Information about an event is mapped before transmission in the TMC virtual language, by selecting the location codes and event codes. Coded messages are then transmitted via RDS to TMC receiver terminals, from the received codes, manage to extrapolate from the database the information to be provided to the end user; locations are predefined and their codes are stored in location tables.

DATEX technology
The DATEX technology uses the TMC database. It has been developed in the 1990s under projects funded by the European Union and consists of a standard exchange protocol and communicating mechanisms. Currently data exchange between the various national TICs of the EU member states is done in DATEX, enabling users to obtain traffic information across Europe via RDS-TMC.
A subsequent evolution is the DATEX II, which has been developed to enhance a standardized way of communicating and exchanging traffic information between TICs, service providers, traffic operators and media partners.
It is a CEN/TS 16157 standard organized in the following separated parts:  DATEX II improves and enhances the localization mechanisms of previous DATEX, supporting different localization modalities like OpenLR and WGS84 coordinates. Moreover, DATEX II is of relevance for all applications where dynamic information on the transport systems and notably the road system is concerned. The main usage areas are (DATEX II, 2017): • Rerouting, network management and traffic management planning. Motorway networks and urban networks are regarded as closely connected here. • Lane or line control systems and related applications like ramp metering, dynamic speed limits and overtaking control. • Linking traffic management and traffic information systems. • Applications where information exchange between individual vehicles and traffic management is crucial, like for car-to-infrastructure systems.
For the purpose of facilitating the provision of compatible, interoperable and continuous real-time traffic information services across the Union, road authorities and road operators shall provide the dynamic road status data and traffic data they collect and update in DATEX II format or any machine-readable format fully compatible and interoperable with DATEX II. This does not apply to static road data for which INSPIRE Directive and its implementing acts are relevant here.

TMC message distribution process
The whole TMC message distribution process involves several actors, which are briefly described below: • Data service provider: an organization that manages any data service through collecting such data, processing and selling services. The data service provider then deals with the broadcaster and/or transmission operator to obtain a necessary data bandwidth. They are responsible for the quality of the data provided to customers, and they must provide the necessary support. • Program service provider: organization that manages and organizes the data to be disseminated. • Broadcaster: an organization that is committed to ensuring the continuous dissemination of programs, their quality and data. • Transmission operator: the organization responsible for the complete signal transmission, including audio programs, data associated with programs and services. It is usually entrusted by the broadcaster for data transmission.
Data on traffic flow, accidents, weather conditions and so on are collected by traffic monitoring systems, emergency services, real-time drivers notifications and are compared by TICs. They are therefore passed on to service providers that generate TMC messages.
The service providers then send the TMC messages to the FM radio station for transmission within an RDS signal, through the normal FM radio broadcast.
TMC data are received through the vehicle's radio antenna and decoded by the TMC decoder, which is responsible for rebuilding the original messages using the event database and location codes and presenting them to the car driver via a video or audio message.

5T TIC: user experience
One of the principal implementation of TMC usage in Italy is that of Piedmont Regional Traffic Operation Centre, managed by 5T Company, in the north west part of Italy.
Regional Traffic Operation Centre (CSR-TOC) is based on regional traffic supervisor system (SVR), a software traffic forecast model-based platform, and is mainly aimed at: • Real-time traffic monitoring: traffic measurement acquisition, treatment and fusion. • Real-time data completion: estimate traffic state also on areas without measurements. • Automatic real-time anomalous traffic situations identification (e.g. traffic jams). • Traffic control, by informing drivers/travelers with and also by providing target or forecast traffic states to the Urban Traffic Control (UTC) subsystems. • Off-line determination and real-time actuation of traffic strategies for special events. • Integration and management of data coming from all physical devices on CSR-TOC road network: sensors, VMS, parking, UTC traffic lights. Among the several subsystems it is important to note also the CSR-TOC internal exchange of traffic messages through the usage of DATEX nodes and TMC as reference location database.

Description of EMS
Emergency management is defined as "The organization and management of resources and responsibilities for addressing all aspects of emergencies, in particular preparedness, response and initial recovery steps" (UNISDR, 2009).
Emergency mapping (EM) is defined as "creation of maps, geo-information products and spatial analyses dedicated to providing situational awareness and immediate crisis information for response" (International Working Group on Satellite-based EM (IWG-SEM), 2014). The specific EM activities carried out to support the response phase in the first hours/days after the disaster are generally referred to as rapid mapping. Satellite or aerial imagery is the most exploited source for extracting reference (pre-event) and crisis (post-event) geographic data. This is the reason why Satellite-based Emergency Mapping (SEM) is the solution adopted by most international initiatives to perform emergency-related analysis (Ajmar et al., 2017;Ajmar et al., 2015b;Boccardo, 2013).
Copernicus is the European program for the establishment of a European capacity for Earth observation. The Copernicus Emergency Management Service -Mapping module (EMS-Mapping) is an on-demand service that provides support to all actors involved in the fields of crisis management, humanitarian aid as well as disaster risk reduction, preparedness and prevention. Copernicus EMS-Mapping covers the entire process from the satellite tasking, image acquisition, processing and analysis of satellite imagery and other geo-spatial raster and vector data sources until the production and delivery of maps and vectors, in standard formats, to the user who requested the service and delivery to the public. There are three map types, one pre-event map and two post-event maps, each of which performs specific functions relevant to crisis management. The preevent or reference maps provide comprehensive knowledge of the territory and exposed assets and population. They are based on satellite imagery and other geo-spatial data acquired prior to the disaster event and are often used for comparative purpose, as a baseline for generating the post-event maps. The two post-event map types, known as delineation and grading maps, are produced from post-disaster images. Delineation maps outline the extent of the area affected by an event and its evolution. Grading maps provide an assessment of the impact caused by the disaster in terms of damage grade and of its spatial distribution. They may also provide relevant and up-to-date information on affected population and assets, for example, settlements, transport networks, industry and utilities. In the fastest map production mode, the service provides both post-event maps within 12 h after image data reception and quality acceptance (Ajmar et al., 2017). Figure 4 shows the proposed general workflow for the integration of the traffic events, usually spread by TICs, within the operating procedures of the Copernicus EMS-Mapping.

Integrating TMC data into EMS services
The European TICs through their DATEX II or I node send information to the Copernicus real-time platform. In order to be able to use these data, firstly the DATEX format is decoded and data are filtered according to the traffic event category (excluding, e.g. accidents, limitations due to social events), and therefore, the TMC location is decoded to allow a precise localization on the portal's base map. Following this pre-processing steps, the traffic events are displayed on the portal and can be used by Copernicus service production sites to improve damage assessment and delineation. The delineation and grading data produced by Copernicus are therefore appropriately filtered (e.g. considering only impact on roads and bridges) and converted into a DATEX format in order to be properly received by the European TICs DATEX node affected by the Copernicus activation.

The TMC database
In the classical workflow of system for traffic event management, the TMC database represents the main data source for locating events. It represents the core of the location referencing: the process to encode a location in a form suitable to transfer and subsequently decode location information.
The simplest way for georeferencing traffic events would be using coordinates, but this implies the strong assumption to use identical geographical entities (e.g. roads) at both sides of the system chain. However, typically, those entities are different, so matching (decoding) the location to the map of the receiving system may be inaccurate, ambiguous or impossible.
It has to be underlined that the TMC is a logical network, without a physical representation as a geographic object. In fact, TMC points are logical points and their geographical position can be not so accurate: for example, in Figure 5 the TMC point 1434 (location code or LCD) indicates a service area (highlighted in green in figure), and the distance with the  real geographic entity is about 500 m. In order to provide a spatial representation of the TMC network a reference between the logical network and a physical representation must be implemented (a pre-coding of the TMC over the physical network).

The NAVSTREETS Street Data
5T Company, in its operational activities, uses the NAVSTREETS Street Data provided by HERE, a commercial data set designed for routing and mapping applications.
HERE cartography contains a table (Traffic.dbf) that enables the representation of TMC over the road network. The information is stored at LINK level (the minimum mapping element of NAVSTREETS Street Data) and for each LINK a code is defined (e.g. -501-37825). It consists of several parts coded as shown in Table 3.
Thanks to this reference table it is possible to locate traffic events along the HERE network, having for each LINK the location code of the road and the location code of the point in positive and negative directions. In Figure 6 it is possible to see the extent of the TMC referenced to NAVSTREETS, the original network and the TMC point location.

OpenStreetMap road network
The Copernicus EMS-Mapping operates using mainly open data sources: in particular, OpenStreetMap (OSM) represents the main source for road network. OSM is a collaborative and voluntary project that aims to create and distribute free geographic data for the world. Not all areas of the world reach the same detail level, and the accuracy degree depends on the existent data. The data are continuously updated, but it is not possible to obtain information about the quality of the data provided, both at the level of accuracy and precision, as it varies depending on the techniques used for the digitization. As is highlighted in OSM wiki "Mapping completeness has always been a slightly awkward aspect of OpenStreetMap, both in terms of achieving good completeness, and in measuring how good it is". 2 Establishing metrics for measuring completeness is very important in order to evaluate the suitability of OSM data for analysis.  (2015) is to compare OSM data with established references like the CIA World Factbook, which contains measurements of paved road lengths in every country in the world. From his work it is evident that OSM data in Italy have reached a good level of completeness, as shown in Table 4. A comparison of OSM roads with the NAVSTREETS Streets Data has been performed in the Piedmont area. Results are shown in Table 5.

An approach proposed by Maron
From Table 5 it is clear that in the OSM road network there are more pedestrian streets and unpaved paths with respect to NAVSTREETS Street Data. In the area of Piedmont, the overall completeness can be considered adequate for many applications.
The two road network data sources, OSM and HERE NAVSTREETS, have some differences, in particular for geometric accuracy and coverage. As far as coverage is concerned, OSM network data also include lot of minor paths, as service roads, industrial roads, agricultural roads, pedestrian path and trails, that are not included in HERE cartography, as they are not relevant for classical car-routing applications.
In this first tentative of integration of TMC traffic information in EMS-Mapping workflow, only the already implemented relationship with NAVSTREETS has been used to spatial represent traffic events. There are ongoing experiences for integrating TMC in OSM (WikiOSM, 2009), but a similar activity in the sample geographic area, even if very relevant, is time demanding and out of the scope of current paper.

Sources of traffic events in 5T
The next step involves the representation of the traffic events over the road network, for which an analysis of different sources of traffic events is important. In 5T Company traffic events are mainly managed by two databases: (1) MISTIC database (DATEX I node component) (2) TCM_sistema database (SVR component).
MISTIC database is part of the component DATEX I Node, which acquires information about traffic from automated and manual channels and inserts it into the MISTIC database. The location system is based on TMC standard. The component currently implements the DATEX Data Dictionary 3.1a and the version 3.3 of the TMC location table.
The other source considered for the analysis is the TCM_sistema database (Traffic Count Manager) belonging to the SVR component, where real-time information (traffic data measured and forecasted and traffic event information) are daily aggregated and stored. The component manages and elaborates events formalized following the DATEX II standard and implements the version 3.3 of the TMC location table. In this source, events are already materialized over the NAVSTREETS road network, thanks to internal algorithm of the SVR component (Arneodo, Botta and Gagliardi, 2012;Arneodo, Foti and Cocozza 2009).
The MISTIC database contains two tables useful for this analysis: • the STORY_ELE table that contains relevant timestamp and other information related to the event and • the STORY_LOC table that contains the location reference of the event through the TMC.
In Table 6, the relevant fields of the two tables are descripted. The fields version (VER) and situation define the primary key of the table and represent the fields on which the element table is joined with the location table.   Table 6. Relevant fields and description for tables "STORY_LOC" and "STORY_ELE" in MISTIC database. The event description is given by the combination of the two codes PHR and DOB, derived by DATEX Data Dictionary. PHR has 509 entries and DOB 23. The dictionary derived from the combination of these two codes generates a total of 564 types of traffic events.
The TCM_sistema database indeed contains historical data, aggregated by month. The main table "events_yyyy_Mmm", can be related to "events_descriptions_yyyy_Mmm", which integrates a verbose description of the event. The relevant field used for the analysis is shown in Table 7.
In case of particular emergency situation to be managed in 5T, when information about temporary road closures from authorities comes rapidly and has several updates, some events are not managed through internal operating procedures through MISTIC, but in order to offer to the citizens a complete and updated information, an ad hoc page on the "MuoversiInPiemonte" portal, 3 the informative portal about traffic condition over the Piedmont Region, has been developed.

Data processing and integration
Starting from 22 November 2016, north west of Italy was affected by heavy rainfalls, in particular Piedmont and Liguria Regions. The bad weather conditions and the persistence of precipitations have caused the increasing of hydrometric levels of all the rivers. Hundreds of people had to be evacuated from their homes, and many roads, schools and businesses were closed across affected regions as the River Po and its tributaries burst their banks in numerous places. In Piedmont region only, the estimated economical impact of the event has been calculated as more than 800 Million Euro, considering support to the population affected, functional retrieval of public infrastructures and risk reduction actions. 4 This event has been chosen as case study for this first tentative of integration of traffic events in EMS-Mapping procedures.
The first set of traffic events comes from the MISTIC database: records occurred in the period interested by the flood event case study have been extracted from "STORY_ELE" and "STORY_LOC" tables.
The traffic events from MISTIC needed to be geocoded over the road network, exploiting source points (first and second location codes) and offset information: for this a function has been designed in order to locate a traffic event over the TMC network referenced to the NAVSTREETS Streets Data, using PostgreSQL and its spatial extension PostGIS.
The function iterates over the table of the selected events from MISTIC database and looks for first and second location codes. If only primary location code is present, the event is processed as punctual event (as for car accidents), in order to obtain a point geometry attribute for the situation analyzed, otherwise the event is processed as linear event. The function searches for the edge of the NAVSTREETS associated with the TMC road LCD, locates the primary LCD point and snaps it to the edge, in case there is topological consistency. Then it evaluates the offset distance, if present: the two distances (pri_distance, sec_distance) are measured along the selected edge (with linear referencing functions toolset), using always the snapped primary LCD point as start point, as explained by Figure 7.
Between the materialized events, a second filtering operation has been performed in order to select only those events that can be related to a flood emergency. Using a filter over the PHR and DOB fields, only the categories visible in Table 8 has been considered useful for the analysis. • a preventive selection between point event and linear event (line and multiline types); • a selection on "fdat" field (start time) in order to consider the events that start from the 22 November 2016 to the end of the month and • a filter over the category type ("etyp") in order to select only the events that can be related to a flood emergency. In this table, there are only seven categories: abnormal traffic, roadworks, condition, obstruction, accident, road_management, activity. Only condition and obstruction events have been chosen to perform the analysis.
The third source of traffic events considered is the "muoversiinpiemonte" web site. An extraction of the versions of the WordPress web page created to inform about road closure has been requested: between the 22 November 2016 and the 02 December 2016, there were 276 different versions of the page. The table structure contains the version id, the date time creation and a field that contains the complete HTML page. For each version the field containing HTML page was parsed, creating a new table where each row contains version id of the page, date and time of the version created, area of reference for the event, road interested by the event and descriptions, when available. Then an algorithm has been developed in order to compare which roads in a version of the page are contained or not in the following version, assigning a start and stop time using the date time field of the page version when a new road comes into the web page and when the road is not more present in the page.
As only the road name was available as information, firstly a join on road name has been performed over the set of events extracted, in order to select only relevant roads.
A second selection has been performed on the set of over 160 roads affected previously extracted, in order to reduce significantly the number of traffic events to be manually located through the verbose description. A spatial intersection between the roads affected and the areas of interest defined by the EMS activation, has decreased the number of relevant events to 40.
After those selections, looking at the descriptions, events have been manually located over the NAVSTREETS data set. Nineteen linear events and twenty-one point events have been added to the event layer.
From 200 traffic events extracted from the three sources, 152 spatially intersect the Area Of Interests (AOIs). A split operation of traffic events over the AOIs has been performed in order to work on each AOI: after this operation, events that spatially intersect the AOIs rise up to 274 (events crossing multiples AOIs were duplicated).
The final phase of the analysis in order to validate the information provided by Copernicus EMS-Mapping has been performed with the use of ArcGIS software and the Time Slide Tool.
In particular, the idea was to simulate what can happen if the EMS operators can access the TMC event information during the map production. Two scenarios have been evaluated: the first one assumes that traffic events are available only in real time; the second one implies also a storage system that enables the capacity of retrieving historical data. In fact, a traffic event, even if resolved at the time of AOI production, could still be useful for identifying possible damages.
Firstly, for each AOI defined by Copernicus EMS, a time window has been defined: the Copernicus protocol requires a maximum of 12 h to deliver a delineation or grading maps, so the date time of the delivery has been considered the stop time, and "stop time -12 h" has been chosen as start time.
For the first scenario, the time enablement on the traffic event layers uses two dates: the timestamp of the start of the event and the timestamp of the end of the event. For the second scenario, only the timestamp of the start of the event has been considered in time enablement.
In this way, using the Time Slider, it is possible to slide over a time window and analyze which AOIs and traffic events occur during time. The resulting maps have been manually evaluated.

The case study of November 2016 flood event in northwestern Italy
Copernicus EMS-Mapping was activated on 24 November 2016 and produced a total of 16 delineation maps and 18 grading maps (Figure 8). In this section traffic events and Copernicus EMS-Mapping products are compared in order to make consideration on if the integration of the two services may have  improved the quality and accuracy of the information transferred to the respective users.
In the chart (Figure 9), it is possible to see for each AOI the count of traffic events is analyzed in the two scenarios (only real time or considering historical data). It is frequent that traffic events were present in AOI but did not overlap with the time extent of the map production. Considering the second scenario, the number of traffic events that can be used for EMS-Mapping analysis increases.
From the analysis of traffic events, it has become necessary to categorize the utility for the mapped traffic events.
In particular, there are traffic events validated by the Copernicus image analysis ("Validated"). For instance, in the case of a road closure it is verified that there are  no cars crossing the road. In such cases, the road affected by the traffic events was often not inserted in the damaged roads detected by Copernicus, but in a perspective of integration, the road section could be classified as potentially affected.
The second category defined is traffic events potentially useful to deepen the analysis ("Potentially Validated"): particularly in delineation cases, the location of closed roads and bridges could help in concentrate the analysis around those traffic events.
The third and last categories are those traffic events that do not seem to be validated by the Copernicus image analysis ("Not Validated"), like traffic events far from the most affected areas or involving several kilometers of road crossing multiple AOIs.
In the chart ( Figure 10) for each source of traffic events and for each scenario, there is the count of traffic for category of utility.
In the first scenario, from over 274 total events, only 88 are spatially and temporally overlaid with AOIs (32%). Of these, however, those that actually contribute to improve the damage detection activity of Copernicus ("Validated" and "Potentially Validated" events) are 38, about 13% of total events.
In the second scenario instead, from over 274 total events, 194 events are spatially and temporally overlaid with AOIs (71%) and those that contribute to improve the damage detection activity of Copernicus are 96, about 35% of total events.
In the first scenario, TCM_sistema is the richest source of located events (34), but only 35% of these were information that enriched the analysis (12 events). WordPress is the source that has proven to be the most useful, with 14 of the 24 events actually used to enrich the analysis. This is probably because, unlike the other two sources, these events are also located outside the TMC network.
In the second scenario, again WordPress is the most useful source, with 64% of the events used to enrich the analysis. MISTIC database, even if it is the source with the highest number of located events (82), has several events "Not Validated" (53%).
During the analysis, a series of duplications between events has to be handled. In particular, among the traffic events from MISTIC database, there are duplicated points with the same identification code and same information about the event, except for the direction of travel concerned. In case of linear events, duplications (on the same time extent) concern road section of several kilometers, with a long temporal extension (about 3 days) along which there are other traffic events that affect limited portions of the affected section, with different types of events or temporal extension (usually 1 day).
On TCM_sistema events, duplicate identification code appears to be more numerous. In this case, many of the duplicated events vary by the date and time of update, but there is no change in the version number of the identification code (as should be done following the procedures).
Finally, between sources, MISTIC and TCM_sistema share many events (same identification code) that sometimes differ slightly in geometry, probably due to differences in the algorithm that calculates the geometry. Rarely, the event is duplicated in all three sources.
In general, during the manual assessment of traffic events, those duplications have not affected the analysis, as duplications do not increase the time needed to perform the visual interpretation.
Delineation maps produced are built on SAR imagery, which allow a semi-automatic extraction of the flooded areas. For those maps, in general, the presence of traffic events like temporary bridge or roads closure could have brought to a more accurate In some cases, the presence of traffic events could have led to improved reference data: for example, in the Chivasso AOI, there was a road closure in an area not affected by flood according to EMS-Mapping analysis, but close to a seasonal stream, not detected in reference data produced by Copernicus EMS-Mapping, that presumably overflowed (see Figure 11). In this particular case, as the traffic event comes from the WordPress source, the point is located outside the TMC network data, unlike for MISTIC and TCM_sistema sources, thanks to the verbose description of the location. Knowing the traffic event, a more accurate investigation could be done, identifying the stream affected by the event, which was not easily identifiable from the imagery on which reference data are based.
Another particular case is the traffic event that reports the closure of the underpass near the Po River in San Mauro (North of Torino). This event had a big impact on traffic as the road is particularly important for the general traffic flow from Torino north, but such kind of event cannot be detected by any imagery.
In case of grading maps, TMC location referencing shows limits related to the TMC coverage: most of the roads flagged as damaged by Copernicus EMS-Mapping are local and rural roads that are not monitored by the TMC system ( Figure 12).
Similarly, in the area near to Bagnasco, a small village along the Tanaro river, several damages to the road infrastructure were identified according to Copernicus EMS-Mapping analysis: a bridge and portion of the road network were destroyed ( Figure 13). The event was not reported by TMC because the affected roads were in a low-functional class, currently not covered by the service.  As a criterion to determine if TMC-based traffic event can be used as source for EMS-Mapping damage detection, the presence of cars on a road reported as closed by TMC-based traffic event has been evaluated. There are several cases where there was the evidence of road closure but not damages where visible from the imagery: this can be considered as a new special case where the EMS-Mapping operator can declare the road as possibly affected, specifying the TMC-based traffic event as source.
For instance, on Ceva South area a road closure traffic event (SP353) is supported by the evidence that no cars are crossing the road in the imagery and other similar cases regard the SP300 to Valdinferno in Garessio South area, the SP143 from Vinovo to Carignano (La Loggia area) and the SP143 near Carignano. In those cases, the road does not seem to be particularly affected by flood or mudflow and damages are not visible, so probably the closure was decided for security reason.
In several areas, relevant erosion phenomena associated with the flood event (i.e. not present in the preevent imagery) affected areas in proximity to road segments where TMC reported blockages, floodings and road closures. Figure 14 displays an area where Tanaro river left bank was clearly eroded: TMC reported an obstruction of the road network, and EMS-Mapping reported a complete destruction of a portion of the rail network next to the obstructed road. The availability of TMC event during Copernicus mapping activity may have led to report some degree of damages to the road network too.
In other areas, flood traces can be detected using satellite imagery on portion of the road network mentioned as disrupted by TMC. During the EMS-Mapping production phase, those traces were not noticed and therefore no damage reported on the road network. As in the previous case, the availability of the TMC event could have led to report  some damages to the road network in the EMS-Mapping products (Figure 15).
Turin Municipality, with a couple of decrees issued on the 12 and 19 December 2016, 5 closed several portions of the cycle tracks along the Po River for lack of security requirements: damages were so relevant that most of those limitations were still active in June 2017 (Città Metropolitana di Torino, 2016). Damages on these infrastructures were detected by Copernicus EMS-Mapping and reported in products released on 28 November 2016 ( Figure 16). The availability of a communication channel from Copernicus service to TMC would have allowed to timely disseminate this information to the population.

Conclusion and further development
The analysis conducted and documented in this paper confirms the benefit of integrated TMC traffic events with emergency mapping services.
In particular, traffic events sent using TMC are certified and are a kind information that can also have a high level of detail, allowing for instance, improving the reference data, and above all, guiding the analysis of post-event imagery, in order to find damages otherwise not easily interpretable. It would be therefore an additional help to photo interpretation, which also benefits the fact of being certified and therefore highly reliable.
Finally, looking at the distribution of AOIs and traffic events, it is evident that by integrating the two services, it was possible to agree on a better definition of the AOIs with the authorized user, justifying them also due to the presence of significant traffic events.
With the aim of developing real-time services and interactive maps for the Copernicus services, information generated by TICs becomes important during both activation and pre-activation phases.
The availability of traffic information in real time for rapid mapping also includes the TIC in Europe, as they are the ones that can share a "certified" information. This is different from EMS-Mapping procedures, where damages are only interpreted and validated only afterwards. Therefore, one of the main efforts is to unify and standardize the TIC operational workflow and data. At the same time,  the flow of the information can be reverted. As Copernicus EMS-Mapping usually maps detailed area and spot damages, it may be useful to provide that information, even if related to local or rural roads, to TIC, which can also eventually validate the event in a reasonable time.
However, there are still some issues that can be addressed by future studies. In particular, the difference between managing traffic events for public information and their use for emergency management has been highlighted.
As far as the function of the TIC is concerned, the aim is to inform the public and especially drivers: this type of information is structured so that it can be transmitted via radio and GPS to enabled vehicles, allowing to update routing based on traffic status. For this type of objective, managing the event as a linear element, involving an even larger portion of the road segment actually affected, allows the information to be potentially transmitted to a greater number of users, even if to the detriment of information detail. Conversely, in the rapping mapping emergency service, the aim is to provide detailed information about damage and in order to use traffic event information, it is better if it is provided by point location, which are less used in TIC.
The resolution of the TMC network is poor compared to the operational scale of RM services: from this study, it has emerged that some of the local roads involved with floods are not reported in TMC-based traffic events. This is one of the main limitations of TMC location referencing system: a limited number of locations related to high cost of update and maintenance, both in terms of money and time.
In addition, during the analysis some duplicated traffic events were found. This issue is mainly due to the internal workflow management for traffic events in 5T company and is related to the different aim of the application: for 5T the main purpose is to inform, lower attention is paid to the consistency of the information and redundancy is preferable.
The progressive implementation of the DATEX II standard can refine the localization methods: in fact, the standard provides three different possibilities for locating an event: WGS84 coordinates, TMC location codes and Open LR, a new protocol map-agnostic with a higher level of detail compared to TMC location system.
As previously stated the location referencing is the main problem in those kinds of applications, in particular if automation of encoding and decoding location of traffic events is expected. In Germany, a tentative to integrate TMC location code in OSM has started: the research institute BAST has been contacted in order to provided TMC location codes and authorize the process (WikiOSM, 2009;WikiOSM, 2016). Unfortunately, the project has been stopped since 2010. If all European TMC location will be pre-coded on OSM data, the automatic processing of traffic event data will be possible and will ease the process of creation of real-time services. With the spread of the OpenLR methods, a similar initiative can be conducted on OSM data.
Apart from increasing the automation for managing and disseminating traffic alerts, the adoption of a common and open road network data set, such as OSM, would be important for integrating crowdsourced information acquired by volunteers by means of mobile applications: that would support the completeness of the traffic events collected, including smaller ones but capable to cause, or participate in causing, congestions and disruptions of the road network. Social media intelligence can also be applied in order to capture events from textual information and geocode them on OSM. The main drawback of volunteer-acquired data is their accuracy and reliability, requiring the setup of validation processes.
Finally, during the simulation presented in this paper some doubts have emerged about the category assigned to the traffic events. In particular, there seems to be an overlap between categories and it is unclear, probably also for the operators, in which cases use one or other category (e.g. "Weather informationroad closure due to bad weather" and "Traffic restrictionsroad closure due to bad weather"). This issue will be probably solved by the adoption of the new Dictionary of DATEX II that among other things tries to eliminate the problem of overlap between categories.

Disclosure statement
No potential conflict of interest was reported by the authors.