D3.4.2 Development of the Urban Traffic Knowledge Basemovesmartfp7.iti.gr/.../uploads/2018/...D3.4.2_v11.pdf · 10. 09.03.2016 Incorporation of suggested minor changes in the consolidated

FP7-SMARTCITIES-2013 609026 - MOVESMART

D3.4.2: Page 1 of 47

Renewable Mobility Services in Smart Cities

FP7 - Information and Communication Technologies

Grant Agreement No: 609026 Collaborative Project

Project start: 1 November 2013, Duration: 36 months

D3.4.2 Development of the Urban Traffic Knowledge Base

Work package: WP3 – Crowd Sourcing for Urban Mobility Knowledge Base Building Due date of deliverable: 31 October 2015 Actual submission date: 31 October 2015 (revision submitted on 26 April 2016) Responsible Partner: CTI (according to the DoW) Contributing Partners: CTI, KIT (according to the DoW)

Nature: Report Prototype Demonstrator Other Dissemination Level: PU : Public PP : Restricted to other programme participants (including the Commission Services) RE : Restricted to a group specified by the consortium (including the Commission Services) CO : Confidential, only for members of the consortium (including the Commission Services) Keyword List: Open List of comma separeted Keywords

The MOVESMART project (http://www.movesmartfp7.eu) has received funding from the European Union’s Seventh

Framework Programme for research, technological development and demonstration under grant agreement no 609026.

http://www.movesmartfp7.eu/


D3.4.2: Page 2 of 47

The MOVESMART Consortium

Ayuntamiento de Vitoria-Gasteiz (coordinator), Spain

Business Innovation Brokers S. Coop., Spain

Centre for Research and Technology Hellas / Information Technologies Institute, Greece

Computer Technology Institute & Press “Diophantus”, Greece

Karlsruhe Institute of Technology, Institute of Theoretical Informatics, Germany

Universidad de la Iglesia De Deusto, Energy Unit, Spain

South West College, UK

Grad Pula - Pola, Croatia

Going Green SL, Spain

MLS Multimedia SA, Greece

Flexiant Limited, UK


D3.4.2: Page 3 of 47

Document history

Version Date Status Modifications made by

1. 15.09.2015 Dissemination of Deliverable’s template, with skeleton and allocation of tasks to involved partners

Spyros Kontogiannis, CTI

2. 22.09.2015 Finalization of deliverable skeleton and allocation of tasks to involved partners


3. 09.10.2015 Partners’ contribution (cf. list of contributors)

4. 19.10.2015 Final draft sent to peer reviewers

Spyros Kontogiannis

5. 22.10.2015 Comments of peer reviewers sent to DM

Dionisis Kehagias, CERTH Konstantinos Genikomsakis, UD

6. 29.10.2015 Revised version of final draft, with comments of peer reviewers incorporated, sent to PQB for approval


7. 30.10.2015 PQB provides feedback and approval of deliverable

8. 30.10.2015 Comments of PQB incorporated to the deliverable


9. 31.10.2015 Submission of deliverable to EC

10. 09.03.2016 Incorporation of suggested minor changes in the consolidated report of REVIEW-2


11. 15.03.2015 Comments of internal reviewers incorporated, sent to PQB for approval


Deliverable manager

Spyros Kontogiannis, CTI List of Contributors

Julian Dibbelt, KIT Moritz Baum, KIT Christos Zaroliagis, CTI Georgia Papastavrou, CTI Andreas Paraskevopoulos, CTI George Michalopoulos, CTI Dionisis Kehagias, CERTH Athanasios Salamanis, CERTH Dimitrios Michalopoulos, CERTH Konstantinos Genikomsakis, UD Diego Lz. de Ipiña Glz. de Artaza, UD

List of Evaluators


D3.4.2: Page 4 of 47

Konstantinos Genikomsakis, UD Dionisis Kehagias, CERTH

Executive Summary The present deliverable summarizes the efforts undertaken within WP3 in order to develop the Urban Traffic Knowledge Base (UTKB) in the context of task T3.4, responsible for the creation and maintenance of all the traffic-related data, which are necessary for the provision of live-traffic aware, core route planning services by the MOVESMART system. The document provides in sufficient detail the description and implementation details of the UTKB management module, whose role was specified in tasks T2.3 and T2.4 and has been clearly described in the corresponding deliverables D2.3 and D2.4. The goal of this deliverable is to provide all the details for the required hardware infrastructure (UTKB server) residing at the UT-Cloud, the procedures for creating and maintaining historic traffic data, service-related traffic metadata, and traffic-data snapshots that are asynchronously disseminated to the travelers’ devices, the methodology and techniques for digesting live-traffic updates as recorded by emergency reports and traffic prediction alerts, as well as the details for the interaction with the Traffic Prediction and Energy Efficiency Assessment modules.


D3.4.2: Page 5 of 47

Table of Contents

1 Introduction ............................................................................................................. 8 1.1 Purpose and Scope ............................................................................................................. 8 1.2 Deliverable Structure .......................................................................................................... 9

2 Supported Traffic Data Types .................................................................................. 10 2.1 Data Types for Private Vehicles ........................................................................................ 10 2.2 Data Types for Public Transport ....................................................................................... 12 2.3 Output Data of Core Routing Services .............................................................................. 13 2.4 Data Types for the Energy Efficiency Assessment Module ............................................... 14

3 Hardware ............................................................................................................... 15 3.1 Description and specifications of the UTKB Server .......................................................... 15 3.2 Assurance of Uninterruptible UTKB Operation ................................................................ 15

4 Services .................................................................................................................. 16 4.1 Time-Dependent Routing Service ..................................................................................... 16

4.1.1 Specification of Raw Traffic Data ......................................................................... 16 4.1.2 Creation and Maintenance of Traffic Metadata .................................................. 18 4.1.3 Periodic creation of Snapshots, and Synchronization with Connected Clients ... 23 4.1.4 TDR Query Algorithms ......................................................................................... 24 4.1.5 Adaptation to Emergency Reports and Traffic Prediction Alerts ......................... 27

4.2 Electric Vehicle Routing Service ........................................................................................ 28 4.2.1 Static Data ............................................................................................................ 29 4.2.2 Dynamic Data ....................................................................................................... 31

4.3 Multimodal Routing Service ............................................................................................. 31

5 Interaction with the Traffic Prediction Module ....................................................... 33 5.1 Integration of Historic Traffic Data ................................................................................... 33

5.1.1 Historic Data from Loop Detectors ...................................................................... 33 5.1.2 Data Extraction and Exploitation from the Crowd Sourcing Database ................ 33

5.2 TP module interface implementation ............................................................................... 35 5.3 Provision of Stream of Emergency Reports and Traffic Prediction Alerts ........................ 35

6 Interaction with the Energy Efficiency Assessment Module ..................................... 37 6.1 Energy Efficiency Assessment of Unimodal Routes as a Web Service .............................. 37

6.1.1 Conventional Vehicles .......................................................................................... 38 6.1.2 Electric Vehicles ................................................................................................... 41 6.1.3 Public Transport ................................................................................................... 43

6.2 Energy Efficiency Assessment of Multimodal Routes as a Web Service........................... 44 6.3 Estimation of Per-Route / Per-Traveler Emissions............................................................ 45

7 Experimental Validation of UTKB Functionalities..................................................... 46

8 Conclusions ............................................................................................................ 46


D3.4.2: Page 6 of 47

References ...................................................................................................................... 47


D3.4.2: Page 7 of 47

List of Figures Figure 1: Overview of the UTKB architecture and its interaction with other MOVESMART modules. ... 9 Figure 2: Overall architecture of the Time-Dependent Routing (TDR) service. .................................... 16 Figure 3: The upper-approximating function 𝜟𝒍, 𝒗 (the orange, upper pwl line), and lower-approximating function 𝜟𝒍, 𝒗 (the yellow, lower pwl line), of the unknown distance function 𝑫[𝒍, 𝒗] within the interval [ts, tf). ...................................................................................................................... 20 Figure 4: Architecture of the Electric Vehicle Routing Service and its integration within the UTKB. ... 29 Figure 5: Overall architecture of the Multimodal Routing Service. ...................................................... 32 Figure 6: WTT impact of main transport fuels in EU. ............................................................................ 38 Figure 7: Impact of “upstream” stages for the Spanish electricity mix. ................................................ 38 Figure 8: Sequence diagram of the web-service for the energy efficiency assessment of PC routes. . 41 Figure 9: Sequence diagram of the web-service for the energy efficiency assessment of EV routes. . 43 Figure 10: WTT and TTW impact per passenger-km by means of public transport. ............................. 44 Figure 11: Internal structure of the Energy Efficiency Assessment Module (EEAM). ........................... 45 Figure 12: Parallel processing of route legs in multi-modal routes. ..................................................... 45

List of Tables Table 1: Input files for RTD from the 5-minute predictions TPM daemon. .......................................... 10 Table 2: Format of temporal_RTD. ........................................................................................................ 12 Table 3: Representation of piecewise linear approximations. .............................................................. 22 Table 4: Piecewise composition or constant approximate function. .................................................... 23 Table 5: Explanation of Emergency Alerts. ............................................................................................ 27 Table 6: Road types and their characteristics. ...................................................................................... 30 Table 7: Alternative set of road types and their characteristics (fewer parameters). .......................... 30 Table 8: Specification of traffic-congestion classifications. .................................................................. 31


D3.4.2: Page 8 of 47

1 Introduction

1.1 Purpose and Scope

The Urban Traffic Knowledge Base (UTKB) acts as the pivotal point of all the traffic-related information (raw-traffic data) aggregated by the MOVESMART system from external sources (e.g., from loop detectors, travelers, etc.), or service-oriented traffic metadata (e.g., travel-time functions between distant points, traffic-sensitive energy-consumption factors, etc.) created and continuously updated within it. All these raw-traffic data and metadata are then at the disposal of the core routing services of MOVESMART –– the core Time-Dependent Routing (TDR) service, the Multi-Modal Routing (MMR) service, and the Electric Vehicle Routing (EVR) service –– which run on a dedicated virtual machine (the UTKB server) of MOVESMART’s UT-Cloud. These services are in turn to be exploited by the more sophisticated personalized mobility and mobility-on-demand services of WP4. The necessity for developing a cloud-based architecture on which traffic-related raw data and metadata is created and maintained, was already addressed since an earlier EU-funded project (eCOMPASS). The following crucial obstacles had been realized within eCOMPASS, and particularly during the deployment of the pilot-phase of the project:

The computational effort to create and continuously update raw-traffic data and either historic-metadata and live-traffic temporal data is actually impossible for isolated portable computing devices (PNDs, smartphones and tablets).

The exploitation and re-use of all the traffic-related information by multiple route planning and traveler-assisting services is not feasible when there is no single point of reference to act as the pivotal point of the travelers' "social network".

Extensive experimental evaluation on real instances of urban transport networks has been conducted, to showcase the validity of the developed techniques supporting the functionalities of the UTKB, which acts exactly as the pivotal point of traffic-related data and metadata within MOVESMART. More details on these experimental evaluations are provided in Section 7. A stream of temporal traffic-related information, which is produced by the crowd sourcing application Live Traffic Reporter (LTR), is also digested by the UTKB. This stream of temporal data provides real-time information about the actual status of the network and is aggregated at the UTKB either as traveler-initiated emergency reports (e.g., blockages of road segments due to car accidents), or automatically generated traffic-prediction alerts (because of prediction of some significant deviation from the nominal behavior of a road segment). Appropriate temporal metadata are also maintained within the UTKB in real-time, and are interpolated with the previously mentioned raw-traffic data and metadata, in order to support the sophisticated time-dependent, live-traffic aware routing services of the MOVESMART system. Finally, periodically updated snapshots of the traffic-related data are disseminated to the travelers’ smartphone devices, in support of elementary routing services, as a contingency plan in case of connectivity loss with the MOVESMART system. Figure 1 provides an overview of the entire architecture of the UTKB functionalities, whose details are clarified in the present document.


D3.4.2: Page 9 of 47

UTKB Server PARK & RIDE

RENEWABLE

MOBILITY ON

DEMAND

TRAFFIC

PREDICTION

MODULE

CROWD

SOURCING

MODULE RTD

daemon

Historic

Traffic Metadata

(TMD)5-min TPM

daemon

Cached Snapshots

(local_SNAP)

LTR daemon

30-min TPM

daemon

TMD daemon

TDR Query

Algorithm(s)

Temporal_TMD

daemon

SNAP

daemon

Snapshots of

Traffic Data

(SNAP)

MOBILE

DEVICE API

EV ROUTES

CAR

ROUTES

VEHICLE

POOLING

Energy

Consumption

daemon

ENERGY

EFFICIENCY

ASSESSMENT

MODULEConsumption

Factors daemon

Emergency Reports

and TP Alerts

(temporal_RTD)

New Sampling of

Raw Traffic Data

(new_RTD)

Current

Raw Traffic Data

(RTD)

Temporal

Traffic Metadata

(temporal_TMD)

Current

Consumption Metadata

(CMD)

Temporal

Consumption Metadata

(temporal_CMD)

Public transit

schedule source (e.g.,

GTFS files)

Public transit live

source (e.g., GTFS-

RT)

Temporal Public Transit

Timetable Metadata

(temporal_PTD)

Temporal_PTD

daemon

MM ROUTES

Figure 1: Overview of the UTKB architecture and its interaction with other MOVESMART modules.

1.2 Deliverable Structure

The following sections analyze the UTKB architecture, as well as the developed services and functionalities dedicated to support the creation and maintenance of traffic-related raw-data and metadata (e.g., travel-time functions between distant nodes in the network) and the operation of the sophisticated personalized and renewable mobility services currently being developed within WP4. In particular, we describe in detail: (i) the produced traffic-related raw-data and (service-dependent) metadata (cf. Section 2); (ii) the supporting hardware residing at the UT-Cloud, which hosts these traffic-related data (cf. Section 3); (iii) the main techniques for maintaining the service-related metadata, as well as for auditing live-traffic reporting of the actual status in the network and the core UT-Cloud based routing services (unimodal TD-routing, multimodal routing, and EV routing) residing at the UTKB server (cf. Section 4); and (iv) the interoperability of the UTKB infrastructure with other modules, in particular with the Traffic Prediction module (cf. Section 5) and the Energy Efficiency Assessment module (cf. Section 6). Finally, the document concludes with an epilogue (cf. Section 7) and relevant references.


D3.4.2: Page 10 of 47

2 Supported Traffic Data Types

2.1 Data Types for Private Vehicles

The data types that are handled within the UTKB, concerning mainly the travel-times of private vehicles (be it either conventional, or electric vehicles), are the following:

Raw Traffic Data (RTD). This type of data is produced periodically by the training algorithm of the Traffic Prediction Module (TPM), exploiting the stream of periodic travel-time reports from both fixed loop-detectors and the connected users’ smartphones, as they are gathered and aggregated by the Crowdsourcing Module (CSM). A Traffic Prediction (TP) Training daemon continuously runs at the UTKB server, and keeps creating very-short-term (say, 5-minute) predictions periodically (e.g., every 5 minutes), so that by the end of each day there is a complete picture of the travel-time value estimations for all 5-min slots in the road network. The TP-Training daemon also takes into account, apart from this image for the travel-times in the entire network, the aggregated raw traffic data for the same day of the all the weeks so far, in order to eventually converge to the typical time-dependent behavior of travel times for the particular day. More details are provided in Section 5. The picture of entire network is maintained on a weekly basis (i.e., the road graph and the travel-time values per arc and 5-min slot) and it is represented in Table 1.

Table 1: Input files for RTD from the 5-minute predictions TPM daemon.

nodes.csv

This file starts with a single number indicating the number of vertices in the graph, (e.g., 473253). Every new line gives the coordinates (longitude, latitude) of a new vertex (e.g., 12.3952 52.2722). The ID of each vertex is exactly the cardinal number of the line containing its own coordinates.

edges_MON.csv, edges_TUE.csv, edges_WED.csv, edges_THU.csv, edges_FRI.csv, edges_SAT.csv, edges_SUN.csv

Each of these files starts with a single number indicating the number of arcs in the graph (e.g., 1126468). Every new line represents the travel-time function of another arc, characterized by the unique pair of tail-vertex ID and head-vertex ID, with the following arc attributes:

// the origin-vertex, destination-vertex, and road-type of the particular road segment

TAIL_VERTEX_ID HEAD_VERTEX_ID ROAD_CATEGORY // number K of travel-time samples for the particular road segment

NUMBER_OF_BREAKPOINTS // sequence of (departure-time, travel-time) samples for the given road segment

DEPARTURE_TIME_1 TRAVEL_TIME_VALUE_1 …

DEPARTURE_TIME_K TRAVEL_TIME_VALUE_K

The TRAVEL_TIME_VALUE is a time duration estimation (in seconds) for traversing the road segment at a given DEPARTURE_TIME (again in seconds) from the interval [0 , 86400) corresponding to the duration of an entire day. For the i-th breakpoint of the travel-time function, the TRAVEL_TIME_VALUE_{i} is valid for the time interval :


D3.4.2: Page 11 of 47

[ DEPARTURE_TIME_{i} , DEPARTURE_TIME _{i+1} )

For the last (K-th) breakpoint, having departure time DEPARTURE_TIME_K, the corresponding time interval is implied as [ DEPARTURE_TIME_K , 86400 ). A single file with arc-travel-times is created at the beginning of a day, and then is updated incrementally by the TP-Training module by creating new travel-time samples, till the end of the day. All missing travel-time values are completed by the corresponding nominal values deduced by the reported speed limits. The arcs in these files are sorted lexicographically according to the (TAIL_VERTEX_ID, HEAD_VERTEX_ID) pairs, i.e., the first two columns of each line. Within each arc, the breakpoints are ordered in increasing values of DEPARTURE_TIME values. All these files are stored and periodically maintained directly in the UTKB Server. Towards this direction, the TPM uses the TP training phase’s outcome (e.g., 5-min predictions, for each of the 288 5-min slots of the day) in order to produce at the end of every day the updated version of the travel-time estimations of the entire network for the particular day. The purpose of each file is, as time evolves, to converge in the limit to the historic travel-time-functions depicting the typical behavior of each and every road segment in the network, assuming that no emergency situation occurs.

Snapshots (SNAP). This data type has three categories (MORNING, NOON, FREE_FLOW) and two types of daily operations (WEEKDAY, WEEKEND). They are periodically updated (at the end of every week), based on the current version of the RTD that has been updated during the entire week, and are communicated to the connected smartphones to the MOVESMART System, upon users’ requests. The purpose of these data is to support elementary routing services that are executed locally on the users’ devices, as a contingency plan for the MOVESMART routing services in case of temporal loss of connectivity with the UT-Cloud.

Traffic Metadata (TMD). This data type is dependent on the particular core routing services (TDR/MMR/EVR, cf. Section 4) which are to use them. TMD are created in an offline fashion at the UTKB Server (e.g., every evening). Their mission is to support in real-time rapid responses (e.g., in a few milliseconds, excluding the network latency) to arbitrary route planning queries.

o A complete toolset of preprocessing techniques for TMD related to the (unimodal) Time-Dependent Routing (TDR) service has been implemented and experimentally evaluated on the UTKB Server, for benchmark data that we have at our disposal from similar EU projects (e.g., project eCOMPASS). During the ongoing pilot phase of MOVESMART, an experimental evaluation will also be conducted for the city of Vitoria and Pula-Pola. A detailed description of these techniques is provided in Section 4.1.2.

o A toolset of preprocessing techniques for TMD related to the Electric Vehicles Routing (EVR) service has been implemented and experimented on benchmark data. A detailed description of these techniques is provided in Section 4.2.

o A toolset of preprocessing techniques for TMD related to the Multimodal Routing (MMR) service has been implemented and experimentally evaluated for benchmark data. A detailed description of these techniques is provided in Section 4.3.


D3.4.2: Page 12 of 47

Emergency Alerts (EMA). The purpose of these reports is to feed the MOVESMART system with an indication of the network’s current status with respect to live traffic conditions. In particular, these alerts are produced by: 1. The CSM, after assessing and statistically processing (e.g., depending on the significance

of the incident and the credibility of the reporting user) several emergency reports for

the same road segment at the same point in time.

2. The TPM, for predictions of forthcoming unusual temporal traffic conditions compared to

the travel-time functions kept by the RTD. This kind of EMAs should be based on periodic

traffic predictions for, say, a 30-minutes time-window. For each arc, if the predicted

travel-time value is significantly different (say, by more than 20%) from the reported

(current) values in the RTD, then an EMA is created for the specific arc and the given 30-

minutes time-window, to highlight the abnormal behavior of this arc within the particular

time-window.

All the EMAs are reported in an ad-hoc fashion (e.g., as interruption signals) by the CSM and the TPM daemons running on the UTKB server, and are stored on the UTKB server, in separate files as temporal Raw-Traffic Data (temporal_RTD). The format of each temporal_RTD is as shown in Table 2.

Table 2: Format of temporal_RTD. // the origin-vertex, destination-vertex, and road-type of the particular road segment TAIL_VERTEX_ID HEAD_VERTEX_ID ROAD_TYPE // NEW travel-time estimation (in seconds), when traversing the road segment at a departure time (in seconds) in the interval [ EMA_START , EMA_START + EMA_DURATION ) EMA_START EMA_TRAVEL_TIME_VALUE EMA_DURATION

An update procedure takes place, also in real-time, which produces temporal Traffic Metadata (temporal_MTD), which are valid for a precomputed time-window of validity. Upon expiration, both temporal_RTD and temporal_MTD are removed from the UTKB. All the temporal traffic-related data are meant to be used by the core routing services of MOVESMART, along with the nominal traffic data (RTD and the TMD) currently residing in the UTKB, in order to provide more accurate route plans in real-time.

2.2 Data Types for Public Transport

The General Transit Feed Specification (GTFS) is an open document format that stores static timetable information. The timetables of many operators are available. The format is specified using a set of text files in Comma Separated Value (CSV) format. GTFS feeds come with detailed descriptions of stops, connections, and timetable information. The format is widely used, making it a reasonable choice for our purposes.1 Moreover, there is an extension to handle real-time updates (e.g., due to delays).2

1 More details can be found in the url https://developers.google.com/transit/gtfs/

2 For more information and a formal GTFS-real-time feed specification, the reader is deferred to the url

https://developers.google.com/transit/gtfs-real-time/

https://developers.google.com/transit/gtfs/

https://developers.google.com/transit/gtfs-realtime/


D3.4.2: Page 13 of 47

2.3 Output Data of Core Routing Services

Every core routing service of MOVESMART, be it TDR, MMR, or EVR, produces as output a route plan in either KML or JSON format, as a sequence of arcs along with traversal-times per arc and other accompanying information (e.g., mode-of-transport per arc). In particular, we consider the following two data types: UNIMODAL ROUTE FORMAT (UMRF): Every UM-route is reported as a sequence of triples: [ UMROUTE = < ( LATITUDE,

LONGITUDE,

TIME_OF_PRESENCE // what time am I at the OSM point?

) > ,

MODE_OF_TRANSPORT , // how shall I travel?

VEHICLE_TYPE ]

MULTIMODAL ROUTE FORMAT (MMRF): Every MM-route is reported as a sequence of tuples: MMROUTE = < ( LATITUDE,

LONGITUDE,

TIME_OF_PRESENCE, // what time am I at the OSM point?

NEXT_MODE_OF_TRANSPORT, // how shall I continue travelling?

VEHICLE_TYPE ) >

Additional information may also be determined, based on the user’s preferences. REMARKS:

1. Given the provided information of a recommended UM/MM-route (basically, coordinates of consecutive OSM/SHAPE points, and TIME_OF_PRESENCE values at each of them), one could also calculate directly other relevant attributes. E.g., for a road segment along the route, connecting two consecutive points

P = ( LATITUDE_1 , LONGITUDE_1 , TIME_OF_PRESENCE_1 )

Q = ( LATITUDE_2 , LONGITUDE_2 , TIME_OF_PRESENCE_2 )

we have:

PREDICTED_TRAVEL_TIME

= TIME_OF_PRESENCE_2 – TIME_OF_PRESENCE_1

APPROX_LENGTH = Math.sqrt(x*x + y*y) * R // a simple approximation (good for small distances), in meters

where:

x = (longitude_2 – longitude_1)

* Math.cos( (latitude_1 + latidute_2) / 2 )

y = (latitude_2 – latitude_1)

R = 6371000 // earth’s radius, in meters…

// A more accurate calculation can be found in:

http://stackoverflow.com/questions/27928/how-do-i-calculate-distance-between-two-latitude-

longitude-points

PREDICTED_SPEED = PREDICTED_TRAVEL_TIME / LENGTH

Math.cos() computes the cosine of a nonnegative real number

Math.sqrt() computes the square-root of a nonnegative real number

http://stackoverflow.com/questions/27928/how-do-i-calculate-distance-between-two-latitude-longitude-points

http://stackoverflow.com/questions/27928/how-do-i-calculate-distance-between-two-latitude-longitude-points


D3.4.2: Page 14 of 47

2. Other static information concerning road segments and OSM/SHAPE points along a route (e.g., speed-limits to fill in missing travel-times, elevation, etc.) have also been aggregated for the entire network once and for all and are exploited locally per core service (e.g., by the EEAM per energy-efficiency-assessment request, or by the preprocessing techniques for the maintenance of TMD), without having to send multiple queries to several resources of information in real-time.

2.4 Data Types for the Energy Efficiency Assessment Module

The EEAM receives as input a route plan (in the format described in subsection 2.3) from the MOVESMART routing services and returns as output the energy consumption (by energy source and total) as well as the impact of emissions for the entire route. The results are reported in JSON format following the schema below:

{

"energyConsumption": {

"petrol_lt": numeric value,

"diesel_lt": numeric value,

"cng_lt": numeric value,

"lpg_lt": numeric value,

"e85_lt": numeric value,

"electricity_wh": numeric value,

"total": numeric value

},

"co2equiv": numeric value

}

The schema above consists of two main fields, namely energyConsumption and co2equiv. The former describes the energy sources and the corresponding consumption for a unimodal or multimodal route, as follows:

petrol_lt is a numeric value for the consumption of petrol (gasoline) in liters.

diesel_lt is a numeric value for the consumption of diesel in liters.

cng_lt is a numeric value for the consumption of compressed natural gas in liters.

lpg_lt is a numeric value for the consumption of liquefied petroleum gas in liters.

e85_lt is a numeric value for the consumption of E85 (ethanol fuel blend of 85% denatured ethanol fuel and 15% gasoline or other hydrocarbon by volume) in liters.

electricity_wh is a numeric value for the electricity consumption in watt-hours.

total is a numeric value for the total energy consumption of the route, i.e. the total energy content of the fuels and electricity based on the estimated consumption by energy source.

The second main field of the schema, i.e. the co2equiv, contains the impact of emissions for the entire route in terms of global warming potential (GWP), expressed in CO2 equivalents.


D3.4.2: Page 15 of 47

3 Hardware

3.1 Description and specifications of the UTKB Server

The machine that runs the UTKB on the UT-Cloud, called the UTKB server, is a virtual machine that has been created within the FLEXIANT testbed which runs Flexiant Cloud Orchestrator (FCO). The hardware specifications of this vertical machine are the following:

RAM: 16384 MB.

CPU: 2000 MHz, 6 cores.

OS: Ubuntu 14.04 LTS.

3.2 Assurance of Uninterruptible UTKB Operation

In order to assure uninterruptible operation of the UTKB, two identical mirrors (independent virtual machines) of the UTKB server are maintained on the UT-Cloud. The preprocessing for the creation of TMD, which is the most computationally-demanding operation, is load-balanced between these two servers. The live-traffic updating (i.e., the creation of temporal_TMD) is also load-balanced between the two servers. All the traffic-related data and metadata are stored as simple text files in CSV format. Irrespectively of which server creates the data, the traffic data and metadata residing on both servers are completely synchronized: Each VM immediately creates copies of the data and metadata it computes to its mirror VM. Simple hashing techniques are adopted for balancing the workload between the two servers of the UTKB, in order to assure the mutually-exclusive write-operations of the computed data and metadata. In order to respond to route-planning queries, each of the core routing services (TDR/MMR/EVR) acts as follows: When both UTKB servers are operational, the route planning requests are also load-balanced between them according to a simple hashing scheme (e.g., based on odd/even IDs of users). If only one of them is operational, then all route planning requests are directed to the operational server. If there is no connectivity with the MOVESMART system, or both the UTKB servers are temporally unavailable, then elementary routing services hosted at the traveler’s smartphone respond to the query, based on the SNAP data kept in it.


D3.4.2: Page 16 of 47

4 Services

4.1 Time-Dependent Routing Service

The Time-Dependent Routing (TDR) service aims at supporting the time-dependent route-planning functionality for vehicles (be it conventional cars or electric vehicles), the optimization being the minimization of the total travel-time. In the following subsections we describe the mechanisms for creating and maintaining the raw-traffic data (RTD), the traffic snapshots (SNAP), and the relevant traffic metadata (TMD). We also describe the main procedures to digest live-traffic reporting, i.e., for creating and maintaining temporal_RTD and temporal_TMD. Finally, we describe the implemented core routing services which exploit all this data. All these tasks, be it data-maintenance procedures or route-planning query algorithms, run on the UTKB servers. An overview of the overall architecture of the TDR service, along with its interaction with other services of the MOVESMART system, is depicted in Figure 2.

Figure 2: Overall architecture of the Time-Dependent Routing (TDR) service.

It is mentioned that all the implemented services described in this section for maintaining historic and live-traffic (meta) data, as well the time-dependent query services, have already been published in quite antagonistic and internationally recognized conferences and journals [Kontogiannis et al. (2015), Kontogiannis et al. (2016), Kontogiannis & Zaroliagis (2015)].

4.1.1 Specification of Raw Traffic Data

A daemon was implemented to run on the UTKB server, which generates travel-time samples during the entire day, exploiting the TPM. In particular, the TPM daemon runs as a system service in the background and its main functionality is to generate short-term traffic predictions for all the road segments of a traffic network for all the time intervals of a day. The traffic descriptor used is travel-time and the time interval resolution is set to 5 minutes (i.e. 288 travel-time predictions per road segment per day). As input TPM takes two type of files: 1. The traffic network map in SHAPE format (.shp file). 2. Live traffic data (i.e. speed probes) from the users of the Live Traffic Reporter (LTR) application

which are stored in the database handled by the CSM. By the end of the day, the TPM daemon generates incrementally a file named <nameOfDay>_predictions.csv which contains the travel-time predictions for all the road segments of the network. This file is updated at the end of each TPM session (i.e. every 5 minutes). At the end of


D3.4.2: Page 17 of 47

each day it contains all the travel-time samples for all the road segments of the network and all the time intervals for the specific day. Every new line of the files represents the travel-time function of another arc, characterized by the unique pair of tail-vertex ID and head-vertex ID, with the following arc attributes:

{

TAIL_VERTEX_ID

HEAD_VERTEX_ID

ROAD_CATEGORY

NUMBER_OF_ DEPARTURE_TIMES (288)

DEPARTURE_TIME_1 TRAVEL_TIME_VALUE_1

…

DEPARTURE_TIME_K TRAVEL_TIME_VALUE_K

}

The TRAVEL_TIME_VALUE is a time duration estimation (in seconds) for traversing the road segment at a given DEPARTURE_TIME (again in seconds) from the interval [0 , 86400) corresponding to the duration of an entire day. For the i-th departure time of the travel-time function, the TRAVEL_TIME_VALUE_{i} is valid for the time interval :

[ DEPARTURE_TIME_{i} , DEPARTURE_TIME _{i+1} )

For the last departure time, having departure time DEPARTURE_TIME_K, the corresponding time interval is implied as [ DEPARTURE_TIME_K , 86400 ). The arcs in these files are sorted lexicographically according to the (TAIL_VERTEX_ID, HEAD_VERTEX_ID) pairs, i.e., the first two columns of each line. The TPM was implemented using the C++ programming language on the Netbeans 8.0.2 integration development environment. It uses the following libraries:

1. Boost. 2. Geospatial Data Abstraction Library (GDAL): Translator library for raster and vector geospatial

data formats. 3. rapidJSON: Fast JSON (JavaScript Object Notation) parser. 4. cURL: Library for transferring data with URL syntax.

It was implemented on a personal computer and runs on a 64-bit Ubuntu 14.04 LTS server. By the end of the week, we shall have created 5-min predictions (treated as periodic travel-time samples) for all the road segments and all the days of the week. These predictions are then combined with the analogous traffic-related information that is already kept in the UTKB, in order to create a new version of the traffic-related historic data. For this purpose, we have created a C++ program using the boost library that takes two arguments:

-d, which is the date taking values from 0-6 (0 for Sunday and 6 for Saturday)

-p, which is the value of the delta that we will use for the weighted averaging It reads the two files containing the historic traffic-related data and the new samples of raw-traffic information for a particular day, and it creates a new file that has the weighted averaging, according

to a weighting parameter delta (0,1):


D3.4.2: Page 18 of 47

(1-delta) * <nameOfDay>_old.csv

+ delta * <nameOfDay>_Predictions.csv

In this way we assure that long-term deviations of travel-times from the anticipated values (which are already kept in the current version of the historic traffic data) are reported by the new travel-time samples and are gradually incorporated in the new versions of the historic traffic data. We created 7 scripts, one for every day. These scripts run the C++ program for a particular day. Then Crontab is used to call the scripts the following day at 2:00 am (i.e., the script Sunday.sh is called at 2:00 on Monday). The crontab command, found in Unix and Unix-like operating systems, is used to schedule commands to be executed periodically. For our purposes we use crontab to call the scripts daily and therefore we are sure that the csv files are up to date. More specifically, the program takes two files

<nameOfDay>_predictions.csv, which contains the travel-time predictions, and

<nameOfDay>_old.csv, which contains the old travel-times for all the road segments of the network and the entire day. For every road segment it averages the

values that correspond to the specific time according to some parameter delta (0,1) and it creates a new value as follows:

new_value = (1-delta) * value_old.csv

+ delta * value_Predictions.csv

Finally the program generates one file named <nameOfDay>.csv that saves the previous values for every segment of each arc.

4.1.2 Creation and Maintenance of Traffic Metadata

This section describes in detail the algorithmic technique used for the actual creation of the traffic metadata (TMD), as well as the methodology adopted for the efficient maintenance of all the traffic-related information kept in UTKB, so that it can be continuously available and exploited by the TDR service residing at the UTKB server. The TDR service (as described in Subsection 4.1.4) is able to respond significantly fast to arbitrary shortest-path queries, by computing an optimal origin-destination path providing the earliest-arrival time at a destination when departing at a given time from the origin. In order for the route-plans given by TDR to be fast and accurate, the service exploits the appropriately selected shortest-path information, precomputed off-line. In particular, a carefully selected subset of vertices (landmarks) is equipped with succinct representations of shortest-travel time functions to all other vertices in the network. Since providing the exact shortest-travel time functions turns out to be hard regarding computational time and space, we compute (1+ε)-approximations of these functions (distance summaries) from the selected landmarks towards all other vertices. The main challenges of this major task are (i) to ensure that the preprocessing time and space complexity is actually small, (ii) to provide fast query-responses in practice and (iii) to obtain provably good approximation guarantees. In the following, the approximation technique used for the computation of all landmark-to-vertex approximate distance summaries is described. First, the set of landmark-nodes L has to be determined. Then our goal is to construct, for each

landmark l L, the (1+ε)-upper-approximation shortest travel-time functions towards all reachable destinations in the network for a time period of a day, i.e. in the interval [0, T = 86400 sec). Since all arcs α of a time-dependent network are associated with a continuous, piecewise linear (pwl) and usually periodic travel-time function 𝐷[𝛼], which denotes the travel-time needed to traverse the arc


D3.4.2: Page 19 of 47

when departing from its tail at a given time, we need to compute the time-dependent shortest path function 𝐷[𝑙, 𝑣] for every l-v-path in the network, for every possible departure time from l, which also is continuous and pwl, thus can be represented succinctly by a number K of breakpoints. Instead

of computing the exact minimum-travel-time functions from each l L towards each reachable v

V, we seek for (1+ε)-upper-approximations 𝛥[𝑙, 𝑣] of every 𝐷[𝑙, 𝑣] function.

More precisely, given a landmark-node l and a destination v, a (1+ε)-upper-approximation 𝛥[𝑙, 𝑣] and a (1+ε)-lower-approximation 𝛥[𝑙, 𝑣] of 𝐷[𝑙, 𝑣] are continuous, pwl, periodic functions, with a small (in particular, independent of the size of the network) number of breakpoints in [0,T), such that the following inequalities hold:

∀𝑡𝑙 ≥ 0,𝐷[𝑙, 𝑣](𝑡𝑙)

1 + 𝜀≤ 𝛥[𝑙, 𝑣](𝑡𝑙) ≤ 𝐷[𝑙, 𝑣](𝑡𝑙) ≤ 𝛥[𝑙, 𝑣](𝑡𝑙) ≤ (1 + 𝜀) ⋅ 𝐷[𝑙, 𝑣](𝑡𝑙)

We now describe the efficient approximation method, which we call the Trapezoidal method (TRAP),

for computing one-to-all approximations 𝛥[𝑙, 𝑣] of min-cost functions 𝐷[𝑙, 𝑣] from every landmark l

towards all reachable destinations v V. TRAP is designed so as to provide good approximations of the actual minimum-travel-time function in small subintervals of possible departure times [ts, tf = ts +

τ) [0, T), for some (small) positive real 0 < τ < T. The algorithm exploits the fact that τ is indeed small, along with the following assumption on the travel-time slopes of all minimum-travel-time functions in the network, which has also been verified by real-world data that we have. Bounded Travel-Time Slopes: All the minimum-travel-time slopes are bounded in a given interval [-

Λmin, Λmax], for Λmin [0,1) and Λmax ≥ 0. The basic idea of TRAP is to split the entire period [0,T) into small, consecutive subintervals of length τ > 0 each and provide a crude approximation of the unknown distance function within [ts, tf), concerning the minimum slope -Λmin and maximum slope Λmax of the actual shortest-travel-time functions in the instance. For every subinterval [ts, tf), TRAP works as follows.

We sample the travel-time values of each destination v V both for departing from l at the times ts, tf. We then consider the semi-lines with slope Λmax from ts and -Λmin from tf. The considered upper-

approximating function 𝛥[𝑙, 𝑣] within [ts, tf) is then the lower-envelop of these two lines. Analogously, the lower-approximating function 𝛥[𝑙, 𝑣] is the upper-envelop of the semi-lines that pass through ts with slope -Λmin, and from tf with slope Λmax. In particular, TRAP considers the following two (upper- and lower-) approximating functions of 𝐷[𝑙, 𝑣] for every possible departure

time t [ts, tf):

𝛥[𝑙, 𝑣](𝑡) = 𝑚𝑖𝑛{𝐷[𝑙, 𝑣](𝑡𝑓) + 𝛬𝑚𝑖𝑛 ⋅ 𝑡𝑓 − 𝛬𝑚𝑖𝑛 ⋅ 𝑡, 𝐷[𝑙, 𝑣](𝑡𝑠) − 𝛬𝑚𝑎𝑥 ⋅ 𝑡𝑠 + 𝛬𝑚𝑎𝑥 ⋅ 𝑡}

𝛥[𝑙, 𝑣](𝑡) = 𝑚𝑎𝑥{𝐷[𝑙, 𝑣](𝑡𝑓) − 𝛬𝑚𝑎𝑥 ⋅ 𝑡𝑓 + 𝛬𝑚𝑎𝑥 ⋅ 𝑡, 𝐷[𝑙, 𝑣](𝑡𝑠) + 𝛬𝑚𝑖𝑛 ⋅ 𝑡𝑠 − 𝛬𝑚𝑖𝑛 ⋅ 𝑡}

Considering the above definition of 𝛥[𝑙, 𝑣], the algorithm has to decide whether this is actually a (1+ε)-upper-approximation of 𝐷[𝑙, 𝑣] within [ts, tf). We compute in each subinterval the maximum additive error MAE(ts, tf), as follows. Let (tm, Dm) be the intersection of the two legs involved in the definition of 𝛥[𝑙, 𝑣]. Similarly, (tm, D̅m)

is the intersection of the two legs involved in the definition of 𝛥[𝑙, 𝑣]. The worst-case MAE(ts, tf),

guaranteed for 𝛥[𝑙, 𝑣] in [ts, tf), is:


D3.4.2: Page 20 of 47

𝑀𝐴𝐸(𝑡𝑠, 𝑡𝑓) = 𝑚𝑎𝑥𝑡∈[𝑡𝑠,𝑡𝑓]{𝛥[𝑙, 𝑣](𝑡) − 𝛥[𝑙, 𝑣](𝑡)} = 𝛥[𝑙, 𝑣] (𝑡𝑚) − 𝛥[𝑙, 𝑣] (𝑡𝑚)

= 𝛥[𝑙, 𝑣](𝑡𝑚) − 𝛥[𝑙, 𝑣](𝑡𝑚)

Figure 3 provides a visualization of all the above mentioned quantities, as well as the upper- and lower-approximating functions returned by TRAP within [ts, tf). For each subinterval [ts, tf), the algorithm checks whether the constructed upper-approximating

function 𝛥[𝑙, 𝑣], valid for every possible departure time t [ts, tf) from the origin l, is actually a (1+ε)-upper-approximation of the exact shortest-path function in the same interval, and if this is the case,

𝛥[𝑙, 𝑣][ts, tf) is accepted. Otherwise, the length of the sampling interval τ needs to be even smaller. TRAP handles all possible sampling intervals as follows. Rather than splitting the entire period [0,T) in a flat manner, i.e. into equal-size intervals, we start with a coarse partitioning based on a large length τ and then in each interval and for each destination vertex we check for the provided approximation guarantee by TRAP. All the vertices which are already satisfied by this guarantee with respect to the current interval, become inactive for this and all its subsequent subintervals. If there is at least one active destination vertex, for which the

function 𝛥[𝑙, 𝑣] constructed in the current interval violates the maximum absolute error, we proceed by splitting in the middle the current subinterval, and repeat the check within the new subintervals created. The algorithm terminates when all reachable destinations become inactive for every subinterval of [0,T), which means that every one of them has a (1+ε)-upper-approximation function for the entire period.

sho

rtes

t tr

ave

l ti

me

at

v

sho

rtes

t tr

ave

l ti

me

at

v

departure time from landmark

ts tf

Slope: ΛmaxSlope: -Λmin

Slope: Λmax

Slope: -Λmin

Max Abs Error

tm tm

Dm[l,v](ts,tf)

Dm[l,v](ts,tf)

D[l,v](tf)

D[l,v](ts)

Figure 3: The upper-approximating function 𝜟[𝒍, 𝒗] (the orange, upper pwl line), and lower-approximating

function 𝜟[𝒍, 𝒗] (the yellow, lower pwl line), of the unknown distance function 𝑫[𝒍, 𝒗] within the interval [ts, tf).

We keep every constructed 𝛥[𝑙, 𝑣] function as a sequence of samples, which are of the form (departure_time, travel_time, approximate_path_predecessor). Each predecessor of v results from the sampling that the algorithm performs at each subinterval [ts, tf). To reduce the required space in


D3.4.2: Page 21 of 47

memory, we do not store the node-id of each predecessor. Instead, we only need to keep a small integer indicating the index of the corresponding incoming edge of v in the adjacency list. We now describe some heuristic algorithmic improvements, as well as some implementation details that we apply in order to obtain even better results, both regarding the required preprocessing space and the efficiency of the query phase. Approximately constant functions: The TRAP approximation method introduces one intermediate breakpoint per interval that satisfies the required approximation guarantee. To keep our algorithm space-efficient, the first thing that we do dealing with every subinterval of the time period is that we check for approximately constant functions. More precisely, we perform an additional sampling at

the middle point tm of each [ts, tf) and we consider the upper-approximation 𝛥[𝑙, 𝑣][ts, tf) to be “almost constant”, if the following condition holds: D[l,v](ts) = D[l,v](tf) = D[l,v](tm). For those approximately constant functions, the insertion of the additional breakpoint at tm is unnecessary. Piecewise composition: Many shortest paths are likely to contain at least one arc with piecewise travel time, making the shortest-path function also piecewise. In our case, keeping the predecessor

vertex of v in every sample of 𝛥[𝑙, 𝑣] (t), allows us to analyze any l-v approximate shortest path into two sub-paths l-p-v. Starting from the destination v, we travel back to a predecessor p, as long as all

vertices u up to p have constantly the same predecessor kept in the corresponding samples of 𝛥[𝑙, 𝑢] (t), and all arcs involved in p-v sub-path have a constant travel-time function. Therefore, there is no

need to keep any samples for the approximate function 𝛥[𝑙, 𝑣] (t), instead we store the necessary information in the form: (constant_travel_time, predecessor_p, approximate_path_predecessor). In

this way, the approximate travel-time function 𝛥[𝑙, 𝑣](t) is given by taking into account 𝛥[𝑙, 𝑝](t) and

the (approximately) constant travel-time from v to p, i.e. 𝛥[𝑙, 𝑣](t) = 𝛥[𝑙, 𝑝](t) + 𝛥[𝑝, 𝑣](t). In our experiments, this method leads to around 40-50% reduction of the space requirements. Delay shifts: In cases that such a predecessor p does not exist, we have to store the approximate

travel-time function as a sequence of breakpoints. However, the samples collected for 𝛥[𝑙, 𝑣] (t) may have small delay variation. Based on this fact, the required space can be further reduced. We store the minimum travel-time value and for each leg we only need to store the small shift from this value. This conversion leads to around 5–10% reduction of the required preprocessing space. Fixed range: For a one-day time period, departure-times have a bounded value range. The same holds for travel-times which are at most one-day for any query within a country or city area, such as Vitoria-Gasteiz. When the considered precision of the traffic data is within seconds, we handle time-values as integers in the range [0, 86,399], rather than real values, sacrificing precision for space reduction. In particular, we convert all floating-point time-values tf to integers ti with fewer bytes and a given unit of measure. For a unit of measure s, the resulting integer is 𝑡𝑖 = ⌈𝑡𝑓 𝑠⁄ ⌉ and needs size

⌈𝑙𝑜𝑔2 (𝑡𝑓 𝑠⁄ ) 8⁄ ⌉ bytes. Converting tf to ti results to an absolute error of at most 2 seconds. Therefore,

for storing the time-values of approximate distance summaries, we can consider different resolutions, depending on the scale factor s, to achieve further reduction of the preprocessing space. Compression: Since there is no need for all landmarks to be concurrently active, we can compress their data blocks. This method leads to significant reduction of the space requirements, especially for large-scale networks. For the city of Vitoria-Gasteiz, we rather choose not to perform this compression. Contraction: The space of the preprocessed distance summaries can be further reduced if we consider a subset of vertices in the network as inactive. More precisely, we can conduct a


D3.4.2: Page 22 of 47

preprocessing of the instance that contracts all vertices which are not junctions, i.e. they form paths with no intersections. Each such path can be represented by a single shortcut arc, which is added at the endpoints of the chain and equipped with an arc-travel-time function equal to the corresponding (exact) path-travel-time function. The edges involved in the contracted paths are also considered as inactive. All contracted nodes are ignored and therefore the number of possible destinations from a landmark is smaller. At the query phase, these paths can be easily retrieved, by exploiting the appropriate information kept on all inserted shortcuts and all contracted nodes for this purpose. It is mentioned that for the city of Vitoria-Gasteiz we choose not to contract any vertices, due to the relatively small size of the corresponding instance. Parallelism: We can speed up the preprocessing time for computing the one-to-all approximate travel-time functions, from properly selected landmarks towards all reachable destinations, as well as the real-time responsiveness to live-traffic reports, i.e. the re-computation of the travel-time summaries for the subset of affected landmarks, by exploiting the inherent parallelism of the entire process. The traffic metadata produced by TRAP are efficiently maintained in the UTKB server, according to the following methodology. In order to access the data blocks of each landmark in O(1) time, we use a mapping. For retrieving efficiently each approximate travel-time function from a landmark to any destination vertex, we need to store an index. In particular, for each landmark l we maintain a vector of pointers, the size of which equals to the number of destinations. The order of the pointers is in ascending order of node id and each one of them corresponds to a destination v. Thus, the address

of the 𝛥[𝑙, 𝑣](t) data is provided in O(1) time, while the required space for this indexing is O(n|L|). We adopt the representation shown in Table 1 for the produced distance summaries, depending on the form of the function.

Table 3: Representation of piecewise linear approximations. // number K of travel-time samples

NUMBER_OF_BREAKPOINTS // the minimum travel-time found in samples and the maximum shift from this value

MINIMUM_TRAVEL_TIME_VALUE MAXIMUM_TRAVEL_TIME_SHIFT // sequence of (departure-time, travel-time_shift, approximate_predecessor) samples

DEPARTURE_TIME_1 TRAVEL_TIME_SHIFT_1 APPROXIMATE_PRED_1 … DEPARTURE_TIME_K TRAVEL_TIME_SHIFT_K APPROXIMATE_PRED_K

For the i-th breakpoint of the travel-time function, the TRAVEL_TIME_VALUE_{i}, computed as MINIMUM_TRAVEL_TIME_VALUE + TRAVEL_TIME_SHIFT_{i}, is valid for the time interval [DEPARTURE_TIME_{i} , DEPARTURE_TIME _{i+1} ). For the last (K-th) breakpoint, having departure time DEPARTURE_TIME_K, the corresponding time interval is implied as [ DEPARTURE_TIME_K , 86400 ). In this case, we consider the interval [ DEPARTURE_TIME_K , DEPARTURE_TIME_1 ), since the function is piecewise linear and periodic. For an arbitrary DEPARTURE_TIME from a landmark node, we first identify the appropriate time interval [ DEPARTURE_TIME_{i} , DEPARTURE_TIME _{i+1} ) and then evaluate the function in this interval for the particular DEPARTURE_TIME.


D3.4.2: Page 23 of 47

If the improvement of the piecewise composition has been applied or the approximate function resulted to be constant, we need to store only one sample, as shown in Table 4.

Table 4: Piecewise composition or constant approximate function.

NUMBER_OF_BREAKPOINTS = 1 // number K of travel-time samples

TRAVEL_TIME_VALUE PRED_OF_PWL_ARC CONST_APPROXIMATE_PRED

// the constant delay towards the first arc of pwl travel-time function, the head-node of this arc and the constant approximate predecessor of the destination for any departure from landmark

To keep the preprocessing space small, we store the information about both predecessors using the same unit of memory. In the case that the approximate function from a landmark l to a destination v is constant, we expect the approximate predecessor of v to be the vertex l and the predecessor corresponding to the piecewise composition (not performed in this case) to be the destination vertex v itself. Finally, we describe how the appropriate traffic metadata related to every day of the week are uploaded in the UTKB-server, so that they are available to the TDR service. A continuously running daemon is responsible for this task. In particular, at the beginning of each day the corresponding traffic-data should be uploaded, while the data related to the previous day should be automatically removed. Also, the daemon undertakes the creation of new updated TMD for any day in an off-line fashion (e.g. at the end of each day), as it was already described in Section 4.1.1. All the responsibilities of this daemon related to other functionalities are further described in the corresponding sections of this deliverable.

4.1.3 Periodic creation of Snapshots, and Synchronization with Connected Clients

The role of the snapshots (SNAP) is to support the contingency plan of MOVESMART with respect to the TD-routing service, in case of network loss. In particular, we create static travel-time metrics which are actually averages of the time-dependent travel-time metric over certain time-windows during the day. These snapshots are then stored in the UTKB and are available for download to the traveler’s smartphone, upon his/her own request. Specifically we divide the entire day in three main zones of departure-times (morning/noon/free) and we consider two types of days (weekday/weekend). For each zone we create a static travel-times metric, which is the average of the time-dependent travel-times metric in this zone. We then create two different files for this particular zone, at the end of each week (e.g., every Sunday evening), one for the typical weekday and one for the weekend. The six different files of SNAP traffic-data are stored in the UTKB so that they are always at the disposal of the travelers, upon their own request for downloading to their own smartphones, in an analogous way that maps are updated in almost all navigation services. We implemented a C++ program on the 64-bit Ubuntu 14.04 LTS operating system, for computing these average travel-time values per road segment and for the three periods for every day (the first and the last interval together comprise the free-traffic zone):

0-21600sec (0h00-06h00 : first part of free-flow zone)

21600-43200sec (06h00 – 12h00 : morning zone)

43200-61200sec (12:00 – 17:00 : rush-hour zone)

61200-86400 (17h00 – 24h00 : second part of free-flow zone ) Afterwards, it averages the previously created data over all weekdays, in order to create the snapshot for a typical workday, and over the two days of the weekend for the corresponding snapshot of a


D3.4.2: Page 24 of 47

weekend-day. Crontab is used to call the scripts to create the new versions of SNAP traffic data, each Sunday at 18:00. The program begins by opening seven files named <nameOfDay>_predictions.csv, which contain the travel time predictions for all the road segments of the network for the entire day, one for each day. For every road segment, the program saves the specific value and creates the average travel-time for every day. Finally, the program generates two files:

weekdays_current_timestamp.csv

weekend_current_timestamp.csv These files contain travel time predictions for all road segments. For every road segment we have four samples: the (early) free value, the morning value, the rush value and, again, the (late) free value. The two free-zone values are also merged into a single value. File names include the creation date and the timestamp of the file, so that the clients of the travelers are able to check the consistency of their own snapshots with the ones kept in the UTKB.

4.1.4 TDR Query Algorithms

The Time-Dependent Routing (TDR) service is developed to provide significantly fast and accurate min-cost route plan responses to arbitrary shortest-path queries, exploiting (i) a carefully selected landmark-set of vertices, (ii) the historical and temporal traffic-related information kept in the UTKB-server and (iii) an efficient approximate query algorithm, designed to provide the required routes. In this section, we describe how the query algorithms supported by the routing service work, as well as how the exploitation of the historical traffic-data and those provided by the TPM and the CSM is achieved. The daemon residing at the UTKB-server continuously runs and accepts incoming origin / destination / departure-time shortest-path queries (o, d, to). For each one of them, the query algorithm provided by the routing service is called and returns either the exact travel-time value, along with the corresponding exact o-d path or an approximate travel-time value via an appropriate landmark-node l and the corresponding approximate o-l-d path. Three approximate query algorithms have been implemented and extensively tested. We describe them below. The first one, which is called FCA, grows a Time-Dependent-Dijkstra (TDD) ball from (o, to) until either d or the closest landmark lo is settled. It then returns either the exact travel-time value, or an (1+ε+ψ)-approximate value via lo, where ψ is a constant, that depends on characteristics related with travel-times, but not on the size of the network. The second algorithm, called FCA+(N), is a variant of FCA which keeps growing a TDD ball from (o, to) until either d or a given number N of landmarks is settled. FCA+ then returns the exact travel-time value or the smallest via-landmark approximate travel-time value, among all these settled landmarks. Theoretically, the approximation guarantee is the same as that of FCA, but the practical performance of FCA+ is impressive. The third algorithm, called RQA, improves the approximation guarantee provided by FCA, by exploiting carefully a number r (called the recursion budget) of recursive accesses to the preprocessed information, each of which produces (via calls to FCA) additional candidate o-d paths. RQA works as follows. As long as the destination vertex within the explored area around the origin has not yet been discovered, and there is still some remaining recursion budget, it “guesses” (by exhaustively searching for it) the next wk of the boundary set of touched vertices (i.e., still in the priority queue) along the unknown shortest o-d path. Then, it grows an outgoing TDD ball from every


D3.4.2: Page 25 of 47

new center (wk, tk = to + D[o,wk](to)), until it reaches the closest landmark lk to it, at travel-time Rk = D[wk,lk](tk). Every new landmark offers an alternative o-d path by a new application of FCA for every boundary center wk. RQA finally responds with a (1+σ)-approximate travel-time to the query, for any constant σ > ε. The response-times as well as the approximation guarantees provided by all three query algorithms have a strong dependence on the selected landmark-set. Our experimental study has shown that FCA has the fastest performance (as expected), and provides quite small approximation guarantees. Both RQA and FCA+ are fast, i.e. they run in time less than 1 msec, but also significantly accurate, since they produce solutions with relative errors less than 1% in the average case. FCA+ is in some cases better than RQA regarding accuracy, while it is almost as fast as RQA. In fact, we can control the trade-off between time and accuracy, by selecting a smaller or larger number of landmarks to be discovered by the algorithm. For those reasons, FCA+ is the algorithm that runs by default in the TDR service. Next, we describe in detail the way in which the query algorithm manages to exploit the historical traffic-data as well as the temporal data corresponding to live-traffic updates, and finally provides the resulting route as output, after the application of a path reconstruction method, for retrieving the unknown approximate paths. The output is in the form described in Section 2.3. For any incoming shortest-path query, the algorithm considers the flags associated with all edges and landmarks in the network, to indicate whether there exists active temporal data for them or not. Any temporal traffic-updates have to be adopted. As described in Section 4.1.5, if there are any road segments or landmark-nodes affected by an emergency disruption or a traffic prediction, a flag corresponding to those edges and landmarks in the network is raised, to indicate that for a specific time-window the temporal RTD and TMD have to be considered, respectively. The algorithm absorbs the online traffic changes, by taking into account these flags on the affected edges and landmarks. More precisely, we consider the two basic phases of any query algorithm, i.e. the first step, which is a Dijkstra-based search, and the second one, which retrieves the approximate distance from a settled landmark-vertex to the destination, by searching into the appropriate preprocessed distance function. For the first step, we perform the following modification on the relaxation of edges. Each time that we need to compute the travel-time needed to traverse an edge, given a departure-time from its tail, the algorithm checks the flag corresponding to the edge, so as to search for its travel-time function either in the current or the temporal RTD. We need to take the temporal raw traffic-data into account, in the case that a specific edge was recently affected by a change in the road network, for a particular time-window around the departure time from its tail. The update-daemon running on the UTKB server is responsible to modify the temporal RTD for all affected edges and raise the bit flag on them so long as an update has been adopted and is still active. Both the current and the temporal travel-time functions are stored per edge. The second phase of the algorithm adopts a similar modification for landmarks. If the destination was not discovered by the first step, the algorithm collects one or more landmark-nodes, which provide one or more candidate approximate solutions towards the destination. If a landmark-node is affected by an update, we have to store the time window of corresponding departure times from it for which the update will still be active, as well as a pointer to the address of the corresponding temporal TMD for this landmark. For each landmark the algorithm checks whether its update-flag bit is 0 or not, so as to decide if the specific landmark has active temporal traffic-data for a particular time window, and therefore there exists an updated approximate distance function from it, kept at the appropriate memory block. The temporal TMD are considered for a landmark when its update-flag bit is 1, meaning that there is a pointer to a memory address which is not NULL, and the departure time from the landmark is within an affected time window. By adopting these simple modifications, we are able


D3.4.2: Page 26 of 47

to exploit the real-time traffic conditions of the network and provide fast and accurate responses to route-planning requests. Finally, we describe the Path Reconstruction method followed for the generation of the calculated o-d path, as a sequence of arcs. In the case that the shortest path returned by the query algorithm is exact, i.e. the destination was discovered during the TDD-search (which is actually quite possible to occur), the path is constructed by simply following the predecessors from the destination to the origin, which the TDD ball provided. However, if the algorithm decides that the destination is to be reached via an appropriate landmark l, we need a method to retrieve the unknown sequence of predecessors from the destination up to the landmark, corresponding to the approximate l-d path. For this purpose, we exploit the information kept in all TMD. For every possible destination d and for any departure time from l, the travel-time function contains the immediate predecessor of d, valid for a specific time interval, where TRAP performed its sampling. Based on this information and some heuristic ideas the path reconstruction method works as follows. Let v denote every node that belongs on the path we want to construct. We start with v = d. We then obtain the immediate (approximate) predecessor, approxPred(v), given by the approximate travel-time function D[l,d](t), when departing from l at time tl = Arr[o,l](to), which denotes the arrival time set by the Dijkstra-ball. We then mark node v as visited, we set v = approxPred(v) and repeat. The procedure terminates when we reach the landmark-node l, i.e. v = l. The retrieval of all predecessors is done by searching either the historical or the temporal TMD, depending on the flag that the algorithm previously considered for landmark l. In practice we observed the following phenomena which we tackled accordingly. Firstly, as we reversely approach the landmark l, the sequence of nodes v at some point enters the area explored by the query algorithm. We decided to collect all those explored nodes v and calculate the total travel-time D[v,d](tv), exploiting the reverse arc-travel-time functions on all arcs connecting all nodes v up to that point. When the main loop of our method terminates, we check which explored node on the path we constructed (including the landmark l) gives the minimum D[o,v](to) + D[v,d](tv). This means that there can be some cases where we construct the approximate path via an appropriate explored node v of the Dijkstra-ball and not the proposed landmark l. Next, we observed that a predecessor given by the distance-summaries stored in UTKB can in fact be already visited, which means that a cycle is created. This can be expected since we search different

approximate functions 𝛥[𝑙, 𝑣](t) for each vertex v, departing from l. The TRAP method samples the exact travel-time-function in different subintervals for each destination. We choose to face this case as follows. The path reconstruction method returns to its initial step, where v = d. Instead departing from the landmark l at the exact departure time tl, we seek for the closest departure time to tl, contained as a breakpoint in all approximate distance functions of the predecessors involved to an approximate path up to l. This safely means that this departure time is a sampling time for all those destinations and thus, they all belong to the very same shortest-path tree, created by the TRAP method during the preprocessing. To avoid the cycle (which in practice is a rare case), we consider the sequence of vertices created, considering the above departure-time from l, which is usually very close to the actual. After the sequence of predecessors has been constructed, the method simply walks on the edges connecting them and the l-v path-travel-time value is provided by the (actual) path-travel-time function, when departing from l at its actual arrival-time, set by the algorithm. The path-travel-time function can be provided by current or temporal raw traffic-data, depending on the flags kept on each edge. The resulting value is at most the approximate one. In practice, we obtain a much better travel-time. The last step is to connect the constructed l-v path with the exact o-l path, given by the query algorithm, leading to a total o-d route-response, which is usually very close to the exact one.


D3.4.2: Page 27 of 47

4.1.5 Adaptation to Emergency Reports and Traffic Prediction Alerts

The TDR service is responsible for computing shortest paths with respect to the current status of network. In such a service that responds to several queries in real-time, various disruptions may occur “on the fly” (e.g., unforeseen congestion, or even blockage of a road segment). In this matter, the new traffic conditions have to be absorbed online and they have to be taken into account by the TDR.

Table 5: Explanation of Emergency Alerts.

Input Emergency Alerts (EMA)

Goal Shortest path queries on updated arc travel time functions and landmark data

The update of the arc travel time functions and the landmark travel-time summaries which are used by the query algorithms is assigned to an online update-daemon worker within TDR. The daemon’s tasks are:

Periodic inspection of EMA. The arc travel time changes in the network are supplied by reports. These are produced by the TPM and they are stored in alerts.csv file, within UTKB. The file format of alerts.csv is described in Section 2.1. The daemon periodically reads the file (every 15 minutes), in intervals in which the TPM-daemon does not write. For preventing the infrequent case of reading the file when is still being written by TPM-daemon, its last modification time in file system is probed. If it is different before and after the reading phase, then the reading phase is repeated after 1 min. If alerts.csv is not empty, then the update-daemon loads in TDR the affected arcs which have to be updated.

Network data update.

The TDR must work continuously in order to answer to any user or service query. On this requirement, the update steps have to be performed independently without interrupting the TDR. Under normal conditions, the arcs which need to be updated are few. Therefore the chance for an update not be absorbed in the shortest path computation is small. Also, in the worst case, since the update can be completed in few milliseconds, running shortly a new query will eventually output the updated shortest paths. During the reading phase of the disrupted arcs from alerts.csv, the daemon inserts them in a queue. Then, it runs the update process for each such arc, 𝑎 = (𝑢, 𝑣). Let the new travel time along arc 𝑎 be 𝛥 at the time interval 𝑇 = (𝑡𝑠, 𝑡𝑒], and the original arc travel time function be

𝑡𝑟𝑎𝑣𝑒𝑙𝑇𝑖𝑚𝑒𝑎(𝑡) =

{

𝑡 ∙ 𝑠𝑙𝑜𝑝𝑒1 + 𝑜𝑓𝑓𝑠𝑒𝑡1, [𝑡0, 𝑡1)𝑡 ∙ 𝑠𝑙𝑜𝑝𝑒2 + 𝑜𝑓𝑓𝑠𝑒𝑡2, [𝑡1, 𝑡2)

… 𝑡 ∙ 𝑠𝑙𝑜𝑝𝑒𝑘 + 𝑜𝑓𝑓𝑠𝑒𝑡𝑘, [𝑡𝑘−1, 𝑡𝑘)

…

The update steps are: STEP 1: Initially, the daemon inserts the affection expiration time 𝑡𝑒 of the new travel time on 𝛼 in a priority queue 𝑃𝑄. This is because the emergency alerts may concern short-term changes. Consequently, after the expiration of the time-window of affection, the original travel time function of 𝑎 will be restored.


D3.4.2: Page 28 of 47

STEP 2: The daemon generates the updated travel time function of arc 𝑎. Initially, it detects the affected legs of 𝑡𝑟𝑎𝑣𝑒𝑙𝑇𝑖𝑚𝑒(𝑡) which have to be updated, within the time interval [𝑡𝑠, 𝑡𝑒]. For example, if the new travel time 𝛥 is occurred in [𝑡𝑘−1, 𝑡𝑘), then the candidate legs to be modified are (𝑠𝑙𝑜𝑝𝑒𝑖, 𝑜𝑓𝑓𝑠𝑒𝑡𝑖), 𝑖 = 𝑘 − 1, 𝑘, 𝑘 + 1. In such a case, the linear interpolation is applied on the new travel time values throughout the interval [𝑡𝑠, 𝑡𝑒]. The updated travel time function is stored in a different memory address. In order TDR to be informed about the new travel time function of 𝑎, an update-flag bit is associated to 𝑎 and it is set to 1 only if the creation of the function is finished. In consequence, during a shortest path computation, the update-flag bit of 𝑎 indicates that its travel time function has changed. In addition, if 𝑎 belongs to a shortest path a pointer to the address of the updated travel time function is accessed by the routing service. STEP 3: The daemon re-computes the travel-time summaries for a subset of landmarks 𝐿 in the vicinity of the disrupted arc 𝑎. In more detail, it runs a Backward-Dijkstra from 𝑢 (tail-node of a) under the free-flow metric, with travel time radius of 𝑡𝑒 − 𝑡𝑐𝑢𝑟, where 𝑡𝑐𝑢𝑟 is the current time (based on the corresponding network’s UTC). The travel time radius is used to trace only the nearest landmarks that may actually be affected by the disruption, leaving unaffected all the “faraway” landmarks. This means that the update has to be performed only for the involved drivers who are close to the area of disruption. For each affected landmark 𝑙, we consider a disruption-times window 𝑇𝑙 = [𝑑𝑠, 𝑑𝑒], containing the latest departure times from 𝑙 for arriving at the tail 𝑢 at any time in the interval [𝑡𝑠, 𝑡𝑒] in which the disruption occurs. The 𝑇𝑙 windows, for all landmarks 𝑙 ∈ 𝐿, are computed by running two Backward-Dijkstra queries from 𝑢 under the time-dependent-flow metric, the first with arrival time equal to 𝑡𝑠 and the second with arrival time equal to 𝑡𝑒. We then compute the temporal travel time summaries for each affected landmark 𝑙 at its disruption-times window 𝑇𝑙. The produced travel time summaries are stored in a different memory address. In order TDR to be informed about the new travel time summaries of landmark 𝑙, an update-flag bit is associated to 𝑙 and it is set to 1 only if the creation of the travel time summaries is finished. In consequence, during a shortest path computation, if 𝑙 is required at the specific disruption-times window 𝑇𝑙, then the update-flag bit indicates that the travel time summaries of 𝑙 have changed on 𝑇𝑙. In this case, a pointer with the address of the updated travel time summaries is accessed by the routing service.

Expiration monitoring The daemon wakes up from idle state when the affection expiration time 𝑡𝑒 of a disrupted arc is reached based on the network’s UTC. In such a case, it extracts the arc 𝑎 having the earliest 𝑡𝑒 from the priority queue 𝑃𝑄. Then it sets the update-flag bit to 0 on arc 𝑎 and any corresponding landmark 𝑙 ∈ 𝐿 which were updated due to 𝑎. In consequence, during a shortest path computation, when it is required, the routing service will use the original travel time function of arc 𝑎. Similarly, if a landmark 𝑙 ∈ 𝐿 is used on a shortest path computation, then the routing service will use the original travel time summaries of 𝑙. In the end, the daemon removes the outdated temporal travel time functions and summaries.

4.2 Electric Vehicle Routing Service

Figure 4 shows the overall architecture of the Electric Vehicle Routing (EVR) service. In particular, the routing service requires consumption data, both dynamic (i.e., live consumption data) and static (long-term consumption). In this section we specify input data that is used for the Electric Vehicle Routing (EVR) service. Section 4.2.1 describes static data (that needs to be gathered once and


D3.4.2: Page 29 of 47

updated only rarely), while Section 4.2.2 focuses on input data that is subject to frequent updates (e.g., due to real-time traffic information). Note that the EVR service is based on algorithms that were published in international conferences on algorithm engineering [Baum et al. (2014), Baum et al. (2015)].

Figure 4: Architecture of the Electric Vehicle Routing Service and its integration within the UTKB.

4.2.1 Static Data

This section describes static data that is required for the EVR service. Road data is extracted from Open Street Map (OSM)3. From each way in the source data, we collect the attributes "osm_id", "nodes", "highway", "area", "max_speed", "direction", "forward", "backward", "name". We also collect coordinates of vertices. To obtain arc lengths, we compute the Euclidean distance between its endpoints from these coordinates. To allow accurate energy consumption prediction, we also require height information (since consumption depends on the slope of a road). We obtain height information for the vertices of the extracted graphs from the freely available by NASA Shuttle Radar Topography Mission data (SRTM)4. It covers large parts of the world with a horizontal resolution of approximately 90 meters. We assign a height value (in meters) to every vertex of the road graph extracted from OSM. To do so, we retrieve the coordinates of each vertex, and interpolate its height by linear interpolation between the four closest samples in the SRTM dataset (the four corresponding endpoints of the tile containing the vertex). We fill (rarely) missing data points in SRTM tiles by interpolating from neighbors in the resulting graph. In more detail, if samples of all four tile points are missing for some vertex, we set its height to a special value UNDEFINED. After assigning height values to all vertices of the graph, we perform a second run for all vertices with undefined height. For these, we perform a Breadth First Search in the graph to obtain their closest neighbors that have a valid height assigned. The height of the current vertex is then interpolated from these neighbors.

3 http://www.openstreetmap.org/

4 http://www2.jpl.nasa.gov/srtm/

http://www.openstreetmap.org/

http://www2.jpl.nasa.gov/srtm/


D3.4.2: Page 30 of 47

Given static and dynamic input parameters, we are now able to assign an energy consumption value to each road segment of the road network (and update it periodically). To this end, we need to map a road segment (identified by several parameters, see below) to the average energy consumption on this segment. Therefore, we create a table that maps road type, typical (free flow) speed, current speed (according to the traffic situation), and slope to average consumption. We use intervals of reasonable size for continuous parameters (e.g., speed). Below, we show two alternative formats. The first uses average (free flow) speed and current speed (according to real-time traffic) in order to obtain consumption predictions. The second uses the speed limit on a road, as well as a more generic description of the traffic pattern (one category in FREE_FLOW, HEAVY_TRAFFIC, CONGESTED, STOP_AND_GO, in increasing level of congestion). Consumption values are obtained from driving cycles that resemble the situation specified by the parameter set. Table 6: Road types and their characteristics.

roadType avgSpeed [km/h] curSpeed [km/h] slope [%] cons [kWh/km]

MOTORWAY 120 120 0 0.212

MOTORWAY 120 110 0 0.204

… … … … …

OTHER 10 10 -6 -0.123

Table 7: Alternative set of road types and their characteristics (fewer parameters).

roadType speedLimit [km/h] trafficSituation slope [%] cons [kWh/km]

MOTORWAY 120 FREE_FLOW 0 0.212

MOTORWAY 120 HEAVY_TRAFFIC 0 0.204

OTHER 10 STOP_AND_GO -6 -0.123

Road types are given in the following list:

CONTROLLED_ACCESS_HIGHWAY,

TRUNK_HIGHWAY,

RURAL_TRUNK_ROAD,

URBAN_TRUNK_ROAD,

RURAL_COLLECTOR_ROAD,

URBAN_COLLECTOR_ROAD,

LOCAL_ROAD,

OTHER Speed limits are given in intervals of 10 km/h, ranging from 10 up to 120. We distinguish average (free flow) and actual speed to account for different traffic situations in the first approach, while the traffic situation is named explicitly in the second. Finally, we consider different slopes (in percent, ranging from 6 to -6) to measure the impact on energy consumption. The table sketched above provides an energy consumption value for each combination of parameters. We then assign energy consumption to road segments following this table, taking the parameters of the corresponding arc to obtain its (up to 12) distinct average consumption values (that may vary due to real-time traffic). We obtain the actual consumption by picking the value corresponding to the current traffic situation, and multiplying it by the length of the arc.


D3.4.2: Page 31 of 47

4.2.2 Dynamic Data

While the datasets mentioned in the previous section are sufficient to generate static consumption data for our road networks, we have to periodically update them to incorporate real-time traffic. Note that the tables listed above are static, that is, we do not update the consumption entries within the tables (except for updates due to, e.g., more accurate simulations). Instead, we retrieve the current traffic situation from the UTKB (in accordance with the unimodal Time-Dependent Core Routing Engine described in Section 5.1), to update travel times on the underlying network model. The difference between uncongested free-flow travel time (which is known from static data) and the current travel time is taken into account on each road segment, to estimate the current traffic situation. Following the example shown in Table 6, this difference immediately resolves to the current traffic situation. If we follow the approach shown in Table 7, we consider the ratio between free-flow (FF) and current (CR) travel time to estimate the current situation as shown in Table 8. Table 8: Specification of traffic-congestion classifications.

FF/CR Traffic Situation

> 0.8 FREE_FLOW

> 0.6 HEAVY_TRAFFIC

> 0.4 CONGESTED

otherwise STOP_AND_GO

We obtain the current energy consumption from the table, using the according parameters. By periodically performing this update procedure (e.g., every 10 minutes), we guarantee that route planning applications respect energy consumption accurately.

4.3 Multimodal Routing Service

In multimodal route planning, we combine the different modes of transport mentioned throughout this document. As a result, a holistic route planner is obtained, taking into account different modes of transportation. On a higher level, we distinguish schedule-based public transport (for example, busses and trams) and private transport (by car, bicycle, or foot). The overall architecture of the Multimodal Routing (MMR) Service is depicted in Figure 4. The MMR further advances a previous algorithm [Delling et al. (2013)], of which a detailed description will be disclosed in the upcoming Deliverable D4.2.2.


D3.4.2: Page 32 of 47

Figure 5: Overall architecture of the Multimodal Routing Service.

As mentioned in Section 2.2, we use the General Transit Feed Specification (GTFS) for public transit. It is an open document, in which the timetables of many operators are available. The format is specified using a set of text files, again in CSV format. Unfortunately, the basic GTFS specification does not contain support of real-time timetable adjustments. Such adjustments can become necessary because of delays in the schedule. For example a train might be delayed because of a broken signal or a bug might be stuck in traffic congestion. For this reason a real-time extension of GTFS called GTFS-RT was introduced. GTFS-RT does in contrast to GTFS not contain a full timetable but only the parts that were changed with respect to the original planned schedule. GTFS-RT is not a text file but it is a binary format built using the Google Protocol Buffer infrastructure. To be able to adjust to real-time information, we designed a program that reads in a GTFS timetable and the changes from a binary GTFS-RT file and outputs an adjusted GTFS timetable. The Multimodal Routing (MMR) service is then restarted with the adjusted GTFS file. Incorporating GFTS-RT within a GTFS specification can become complex. GTFS supports storing repetitions in the timetable. For example one can specify that a bus drive on every Monday at a certain time. With GTFS-RT this compression is no longer possible. The bus on the first Monday, i.e., the one that was adjusted using real-time information, no longer departs at the same time as the buses on the other Mondays. To support real-time information we there first duplicate the generic Monday from the input GTFS. One copy remains the generic Monday whereas the other copy is adapted. Additionally we must specify that the adapted copy is only valid on the Monday for which we have real-time information, whereas the generic copy should be valid on all Monday except the one for which we have real-time information. Regarding private transportation, we incorporate traffic updates as described in Section 4.1, and consumption updates for electric vehicles that were described in Section 4.2.


D3.4.2: Page 33 of 47

5 Interaction with the Traffic Prediction Module

This section describes the synthesis of historical data with en-route (speeds and positions) and port-route (emergency) reports as means to create traffic predictions.

5.1 Integration of Historic Traffic Data

We start by providing an overview of the methodology according to which the input stream (from loop detectors and periodic speed reports by travelers’ devices) is aggregated by the training engine of the TPM, which then feeds the UTKB with the appropriate periodic updates (travel-time samples) of the underlying road network. More details on the mechanisms of UTKB for actually maintaining traffic-related raw-traffic data and service-dependent metadata, are provided in Sections 4.1.1, 4.1.2, 4.1.3, 4.2.1, and 4.2.2 of this document. The interpolation of all the related raw-traffic data and metadata with the real-time picture of the network that is provided by live-traffic reports (emergency reports and traffic prediction alerts) is described in Section 4.1.5.

5.1.1 Historic Data from Loop Detectors

The historic traffic data from the city of Vitoria – Gasteiz contain traffic volume and occupancy values from the loop detectors installed at the roads of the city. There are 277 loop-detectors in total which can have one of the following operation statuses:

Currently operating

Canceled (but with historical data)

Currently not operating Each one of the operating loop detectors provide traffic counts and occupancy values aggregated into 15-min time intervals. The total time period covered by the data is one year (2013) and eight months (January – August 2014). Considering the fact that the data refer to loop detectors and not roads of the network, a pre-processing step was implemented to match the data to the corresponding roads.

5.1.2 Data Extraction and Exploitation from the Crowd Sourcing Database

The crowd sourcing database collects the data which are sent by the crowd sourcing application (Live Traffic Reporter) as has been described in details in deliverable D3.2.4. From a technical perspective, the database module in MongoDB is a document oriented model which uses objects as data structure. For data communication, a particular RESTful API has been developed and released, based on PHP slim framework. Using an authentication token based on OAuth2 authentication protocol, each device accessing particular calls can send, retrieve and (more rarely) modify data. Traffic data in the crowd sourcing database are mainly in two collections: positions and reports. Positions, consists of users’ position and speed for particular time period (en-route scenario). In fact, as declared in project’s ethics, all collected information is anonymous and is achieved using the hashed value of username. An example such an object is presented below:

{

"_id" : ObjectId("5595b46348177ed460a5bec0"),

"userLatitude" : "40.0474",

"userLongitude" : "-74.7972",

"accuracy" : "5.0000",

"heading" : "53.0859375",

"speed" : "35.7300",

"time" : "1435874399",


D3.4.2: Page 34 of 47

"userId" : "29435281c32958c4aab2f1d7f68dd62d94cc706f"

}

In particular the fields are:

_id: the unique object identity, created by mongo.

userLatiture, userLongitude: the coordinates of the user at the particular time.

accuracy: GPS accuracy value (depends on the device).

heading: user heading at the particular time in degrees.

speed: user speed at the particular time in m/s.

time: the UNIX timestamp of the position (in seconds).

userId: the hashed value of user's username. The collection of Reports consists of report incidents (accident, traffic, works and weather) that users send through the crowd sourcing application. Each report is evaluated by nearby users and at the back-end passes through the report evaluation algorithm and is formed as below:

{

"ProbabilityRealTF" : 1.0000000000000000,

"ProbabilityTF" : 1.0000000000000000,

"RealTF" : "false",

"TF" : "false",

"_id" : ObjectId("5603a8b448177ed8793d38a2"),

"accuracy" : "5.0000",

"address" : "214 Tallebudgera Dr, Palm Beach, QLD 4221",

"comments" : "",

"heading" : "241.05996704102",

"judgements" : [],

"mode" : "walk",

"reportLatitude" : "-28.114155475209",

"reportLongitude" : "153.44589471817",

"severity" : "medium",

"speed" : "20.0400",

"time" : "1443080363",

"type" : "traffic",

"userId" : "a82f8cad0b2d396710d41409d6d0c1fa259a5821",

"userLatitude" : "-28.1156",

"userLongitude" : "153.4315"

}

In particular the fields are:

ProbabilityRealTF: the probability that the report is false after user evaluation, based on the report evaluation algorithm.

ProbabilityTF: the probability that the report is false before user evaluation based on the report evaluation algorithm.

RealTF: the final decision of the report evaluation algorithm after user evaluation.

TF: the decision of the report evaluation algorithm before user evaluation.

_id: the unique object identity, created by mongo.

accuracy: GPS accuracy value.

address: the postal address (if available) of the report point.

comments: potential comments about the report by the user.

heading: user heading at the particular time in degrees.


D3.4.2: Page 35 of 47

judgements: an array that contains judgments for this report by nearby users. It is used in report evaluation algorithm.

mode: the operation mode of the application when the report is submitted (walk/drive/cycle/transportation).

reportLatitude, reportLongitude: the coordinates of the report (strings).

severity: the severity of the report, as specified by the user.

speed: user speed at the particular time in m/s.

time: the UNIX timestamp of the position (in seconds).

type: the type of the report (Accident, traffic, works, weather).

userId: the hashed value of user's username.

userLatitude, userLongitude: the coordinates of the user at the particular time (strings). Data in the database are always enriched with new ones, so long as the crowd sourcing application is being used by users. In terms of extracting necessary data this can be done by multiple ways:

1. Directly from the database. MongoDB is supported by a variety of corresponding drivers for many operating systems and languages. Particular credentials have been created and given to connected modules.

2. Using a particular web service that has been created for the necessity of data extraction. This web service takes as input the start and stop points in UNIX timestamp format using the GET method. It then extracts the retrieved information in JSON format. Needless to say that there is a limit of 10000 objects as it is important not to overload the server. An example of accessing this web service is given by the url sending as start and stop parameters the particular time stamps with GET method:

http://ltrserver.movesmartfp7.eu/slim/API/v1/getData?start=1436772544&stop=1436872544

5.2 TP module interface implementation

The Traffic Prediction Module (TPM) in its current state has been implemented as a system service (daemon) on Linux environment and specifically on 64-bit Ubuntu 14.04 LTS server. The whole functionality was implemented, using C++ programming language on the Netbeans 8.0.2 integration development environment. The building/compiling process was performed by the gcc GNU C++ compiler. In fact, the following libraries have been used:

Boost

Geospatial Data Abstraction Library (GDAL): translator library for raster and vector geospatial data formats

rapidJSON: fast JSON parser

cURL: library for transferring data with URL syntax

5.3 Provision of Stream of Emergency Reports and Traffic Prediction Alerts

We describe in this section the procedure for assessing emergency reports posed by travelers, as well as assessing the significance (say, when there is an indication of more than 20% deviation from the stored travel-time value of a road segment in the raw traffic data stored by the UTKB) of traffic prediction alerts by the long-term (say, 30-minute) TPM. More details are provided in the corresponding deliverable (MOVESMART’s D3.3.4) for TPM.

http://ltrserver.movesmartfp7.eu/slim/API/v1/getData?start=1436772544&stop=1436872544


D3.4.2: Page 36 of 47

The main functionality of TPM is to predict the upcoming traffic state of the roads of the network periodically in an accurate way. The goal is to know beforehand a probable differentiation from a typical traffic trend for the current time of day and day of the week. This information is provided by travel time values stored on the edges_*.csv files. These values are updated at the end of each TPM session by the generated prediction values. By comparing these values with certain traffic thresholds (e.g. 50km/h for weekdays from 07:00 AM to 11:00 AM), a deviation from the “typical” traffic pattern can be identified. The complete description on the UTKB exploiting this stream of emergency reports and traffic prediction alerts is provided in Section 4.1.5 of the present document.


D3.4.2: Page 37 of 47

6 Interaction with the Energy Efficiency Assessment Module

This section presents an overview of the development of the Energy Efficiency Assessment module (EEAM) as a web service, to support the unimodal and multimodal route planning of individuals by performing the assessment of the route suggestions (provided to the user) from an energy-efficiency perspective. In this context, the interoperability with the MOVESMART routing services and UTKB is discussed, providing useful insight on how EEAM receives a route plan and returns relevant information about fuel/energy consumption and emissions. The EEAM was implemented in Java and employs the latest features of Java 8, such as streams and lambda expressions that simplify the execution of database queries and loops in parallel, reducing thus the execution time of a service. On the other hand, the EEAM web-services are currently built with Jersey5 and run on Grizzly6, while other frameworks, such as Vert.x7 or Akka8 are also under consideration as means of potentially improving the performance of the EEAM. Regarding the database technologies to store and access the data required for assessing the energy / fuel consumption and impact of emissions (e.g. output data of energy models), MongoDB9 was selected due to its high performance and cross-platform capability. The energy efficiency assessment of multi-modal routes is typically based on the distance covered by each transport mode. Thus, essential parameters to take into consideration include the length of each leg of a given route along with the energy consumption (EC) and emission factors (EFs) by mode and vehicle type, as well as energy carriers and conversion processes involved. The “EN 16258:2012 Methodology for calculation and declaration of energy consumption and GHG emissions of transport services (freight and passengers)", published by the European Committee for Standardization (CEN, French: Comité Européen de Normalisation), is the first European standard to provide a common approach and framework on this field. Specifically, it states that “the assessment of energy consumption and GHG emissions of a transport service shall include both vehicle operational processes and energy operational processes that occur during the operational phase of the lifecycle” [CEN 2012]. Among others, it further suggests the exclusion of processes related to: (i) manufacturing, maintenance, and disposal of vehicles, and (ii) construction and maintenance of transport infrastructure. In this direction, the EEAM considers the necessary “well-to-wheels” (WTW) stages, i.e. the “well-to-tank” (WTT) part of the life cycle that refers to the energy operational processes for the production and supply of fuels and electricity for the transport sector as well as the “tank-to-wheels” (TTW) part of the life cycle that refers to the vehicle operation, in order to assess the energy efficiency of multi-modal routes in the context of life cycle analysis.

6.1 Energy Efficiency Assessment of Unimodal Routes as a Web Service

This subsection discusses the development of web-services for the energy efficiency assessment of unimodal routes, based on the on-going developments within the frame of the MOVESMART task “T4.4- Energy-efficient multimodal route planning”. Specifically, the WTT analysis employs the life cycle assessment (LCA) software package SimaPro [Pré Sustainability 2015] to model the pathways of fuels and electricity for the transport sector, considering the production chain and distribution to refueling/charging stations. The global warming

5 https://jersey.java.net/

6 https://grizzly.java.net/

7 http://vertx.io/

8 http://akka.io/

9 https://www.mongodb.org/

https://jersey.java.net/

https://grizzly.java.net/

http://vertx.io/

http://akka.io/

https://www.mongodb.org/


D3.4.2: Page 38 of 47

potential (GWP) impact category from the IPCC 2013 method (developed by the International Panel on Climate Change) is chosen for evaluating the impact of fuel and electricity pathways with a time horizon of 100 years.

Figure 6: WTT impact of main transport fuels in EU.

Figure 7: Impact of “upstream” stages for the Spanish electricity mix.

Figure 6 presents the GWP of the WTT part of the life cycle for main transport fuels (i.e., diesel, gasoline, biodiesel, ethanol 85 and LPG) in EU, expressed in kg of CO2 equivalents per MJ of fuel. Similarly, Figure 7 shows the GWP of 1 kWh in Spain (ES) for the years 2011-13, including the impact of “upstream” stages for electricity generation, transmission, transformation and distribution to end users. The following paragraphs describe the development of the individual web-services for assessing the energy efficiency of unimodal routes for conventional passenger cars (PCs), public transport (PT) and electric vehicles (EVs), taking into account both WTT and TTW stages.

6.1.1 Conventional Vehicles

The TTW analysis of conventional vehicles is based on the Handbook Emission Factors for Road Transport (HBEFA) [Hausberger et al. (2010), Hausberger et al. (2014)], which is a traffic-situation


D3.4.2: Page 39 of 47

tool covering the European emission standards for passenger cars (PCs) up to Euro 6. More specifically, HBEFA provides fuel consumption (FC) and EFs expressed in gr/vehicle-km for a total of 276 traffic situations, defined in terms of area type (e.g. urban or rural), road type (e.g. motorway, trunk road, distributor, local, access-residential), speed limit and level of service (e.g. free flow, heavy, saturated and stop & go). Moreover, it supports different road gradient classes, i.e. 0%, ±2%, ±4%, and ±6%. For each segment k of the route, the FC and EFs for CO2, CH4 and N2O, i.e. EFCO2, EFCH4, and EFN2O respectively, are retrieved from a locally stored database, which has been populated with EFs from HBEFA, given that the latter supports all regulated and the most important non-regulated pollutants. These factors depend on the vehicle type, road gradient and traffic situation. The GWP for a route with respect to the TTW part of the life cycle is then calculated using the IPCC 2013 method for a time horizon of 100 years, as given in Equation (1), where dk denotes the length of route segment k.

𝐺𝑊𝑃𝑇𝑇𝑊(𝑃𝐶) = ∑ 𝑑𝑘 ∗ [

𝐸𝐹𝐶𝑂2(𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑡𝑦𝑝𝑒, 𝑟𝑜𝑎𝑑 𝑔𝑟𝑎𝑑𝑖𝑒𝑛𝑡, 𝑡𝑟𝑎𝑓𝑓𝑖𝑐 𝑠𝑖𝑡𝑢𝑎𝑡𝑖𝑜𝑛) +

25 ∗ 𝐸𝐹𝐶𝐻4(𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑡𝑦𝑝𝑒, 𝑟𝑜𝑎𝑑 𝑔𝑟𝑎𝑑𝑖𝑒𝑛𝑡, 𝑡𝑟𝑎𝑓𝑓𝑖𝑐 𝑠𝑖𝑡𝑢𝑎𝑡𝑖𝑜𝑛) +

298 ∗ 𝐸𝐹𝑁2𝑂(𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑡𝑦𝑝𝑒, 𝑟𝑜𝑎𝑑 𝑔𝑟𝑎𝑑𝑖𝑒𝑛𝑡, 𝑡𝑟𝑎𝑓𝑓𝑖𝑐 𝑠𝑖𝑡𝑢𝑎𝑡𝑖𝑜𝑛)

]𝑘𝑖=1 (1)

As already pointed out, the GWP for the WTT part of the life cycle represents the impact for producing the transport fuel consumed by the vehicle, and it is expressed by Equation (2), where GWPfuel denotes the GWP of each fuel type per unit of mass, as calculated with the SimaPro tool.

𝐺𝑊𝑃𝑊𝑇𝑇(𝑃𝐶) = ∑ [𝑑𝑘 ∗ 𝐺𝑊𝑃𝑓𝑢𝑒𝑙(𝑓𝑢𝑒𝑙 𝑡𝑦𝑝𝑒) ∗

𝐹𝐶(𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑡𝑦𝑝𝑒, 𝑟𝑜𝑎𝑑 𝑔𝑟𝑎𝑑𝑖𝑒𝑛𝑡, 𝑡𝑟𝑎𝑓𝑓𝑖𝑐 𝑠𝑖𝑡𝑢𝑎𝑡𝑖𝑜𝑛)]𝑘

𝑖=1 (2)

It derives that the total impact is the sum of the GWP of the WTT and TTW stages, as given in Equation (3).

𝐺𝑊𝑃𝑊𝑇𝑊(𝑃𝐶) = 𝐺𝑊𝑃𝑊𝑇𝑇(𝑃𝐶) + 𝐺𝑊𝑃𝑇𝑇𝑊(𝑃𝐶) (3) Regarding the implementation of the web service for the energy efficiency assessment of car routes, EFs from HBEFA have been employed to populate a database in MongoDB, following a revised classification of the HBEFA’s sub-segments (in terms of technology, size class and emission concept) in order to reduce the total number of categories. The relevant FC and EFs are stored in JSON with the following format:

{

"_id" : ObjectId("553753bbccf22485ce03c721"),

"EmConcept" : "emission concept",

"Gradient" : "road gradient",

"SizeClass" : "size of the engine",

"Technology" : "technology",

"TrafficSit" : "the traffic situation of a road",

"ComponentsByFuelType" : {

"Normal" : [

{

"ComponentName" : "CH4",

"Properties" : {

"EFA" : numeric value,

"Speed" : numeric value

}

},

{


D3.4.2: Page 40 of 47

"ComponentName" : "CO2(rep.)",

"Properties" : {



}

},

{

"ComponentName" : "FC",

"Properties" : {



}

},

{

"ComponentName" : "CO2(total)",

"Properties" : {



}

},

{

"ComponentName" : "N2O",

"Properties" : {

"EFA" : numeric value


}

}

]

}

}

More specifically:

EmConcept represents the emission concept of the car engine,

Gradient is a numeric value that represents the gradient of a road in percentage,

SizeClass describes the class of the engine size,

Technology defines the technology of the car engine,

TrafficSit denotes the traffic situation in terms of area type, road type, speed limit, and level of service.

ComponentsByFuelType is a list of different types of fuel that the car engine supports, for instance in the case of a bifuel vehicles. The “Normal” value is used to identify the default fuel as defined in the Technology field. For each fuel type, the FC and EFs for N2O, CO2 and CH4 emissions are stored in grams per vehicle-km.

To calculate the FC and impact of emissions for a car route, the properties for each route segment are extracted from a locally stored database with the road network characteristics. The average traversal speed Vavg,k for each route segment k is calculated by Equation (4), where “∆Time of presence” denotes the difference between the time of presence in the current and the next point of the route plan (as provided by the MOVESMART routing services). Then, the value of average traversal speed is used to determine the level of service for the route segment k, according to the area type, the road type and the speed limit.

𝑉𝑎𝑣𝑔,𝑘 =𝑑𝑘

∆𝑇𝑖𝑚𝑒 𝑜𝑓 𝑝𝑟𝑒𝑠𝑒𝑛𝑐𝑒 (4)


D3.4.2: Page 41 of 47

Next, the road segments are grouped by their properties and the total distance of each group is calculated and multiplied by the per distance FC and EFs corresponding to the identified level of service, in order to obtain the total FC and impact of emissions for the segments that share the same properties. Last, the impact of emissions and FC of each group are added to form the final result for the whole route. Figure 8 shows the sequence diagram of the relevant calculations (impact of emissions and FC) for a PC route.

Figure 8: Sequence diagram of the web-service for the energy efficiency assessment of PC routes.

6.1.2 Electric Vehicles

EVs are known to produce no tailpipe emissions. Hence, their environmental impact is traced back to the upstream stages of the life cycle, where electricity is generated for charging the EV battery in order to move the vehicle. This implies that the GWP of an EV route depends not only on the energy consumption of the EV over the route, but also on the country-specific electricity mix used to charge the EV battery. In this case, the impact over the whole life cycle is expressed by Equation (5):

𝐺𝑊𝑃𝑊𝑇𝑊(𝐸𝑉) =𝐺𝑊𝑃𝑒𝑙𝑒𝑐𝑡𝑟𝑖𝑐𝑖𝑡𝑦(𝑐𝑜𝑢𝑛𝑡𝑟𝑦) ∗ ∑ 𝑑𝑘 ∗ 𝐸𝐶𝑘(𝐸𝑉 𝑡𝑦𝑝𝑒, 𝑟𝑜𝑎𝑑 𝑔𝑟𝑎𝑑𝑖𝑒𝑛𝑡, 𝑙𝑒𝑣𝑒𝑙 𝑜𝑓 𝑠𝑒𝑟𝑣𝑖𝑐𝑒)

𝑘𝑖=1 (5)

where GWPelectricity denotes the GWP of 1 unit of electricity (e.g. 1 kWh) produced and delivered to end uses according to the country-specific electricity mix, while ECk is the EV energy consumption per unit of distance for route segment k. The relevant GWPelectricity factors have been obtained for Spain (ES) and Croatia (HR) with the SimaPro LCA tool, taking into account the electricity generation technologies in each country. Additionally, EV models for electric cars, electric scooters and electric bikes, have been developed in the frame of the MOVESMART project in order to extract EC factors for various types of EVs and road gradients, based on specific driving cycles (speed profiles over time) representing different levels of service in terms of traffic flow conditions. The approach followed combines a generic physics-based vehicle model with the operational characteristics of the main EV components in order to transform the traction power requirements (at wheels) into EV battery


D3.4.2: Page 42 of 47

power requirements. Thus, the theoretical foundation for the extraction of the relevant EC factors is the estimation of the tractive effort Fte required to overcome the forces opposing to the movement of the vehicle and drive it at speed u. The traction power Pte is given in Equation (6).

𝑃𝑡𝑒 = 𝐹𝑡𝑒 ∗ 𝑢 = (𝐹𝑎𝑑 + 𝐹𝑟𝑟 + 𝐹ℎ𝑐 + 𝐹𝑙𝑎 + 𝐹𝜔𝛼) ∗ 𝑢 (6) where Fad is the aerodynamic drag, Frr is the rolling resistance force, Fhc is the hill climbing force, Fla is the linear acceleration force of the vehicle, and Fωα is the inertia force of the rotating parts of the vehicle [Travesset-Baro et al. (2015)]. Taking into account the characteristics of EVs available in the market with respect to technical specifications and manufacturer data, the aforementioned EV models were employed to populate a database of EC factors for different EV types, according to their operational characteristics, such as motor type (e.g. synchronous and induction), motor power, and battery type (e.g. Lead acid, NiCad, NiMH, and LiIon). The implementation of the web service for the energy efficiency assessment of EV routes is based on three similar processes to account for the three different types of EVs, namely electric cars, electric scooters and electric bikes. In each case, the relevant EC factors are stored in a MongoDB database (in JSON format), following the schema below:

{

"_id" : ObjectId("55a63b0bccf2e075acba7923"),

"MotorPower" : motor power,

"MotorType" : "motor type",

"BatteryType" : "Battery type",

"AreaType" : "Area type",

"LevelOfService" : "level of service",

"Gradient" : gradient,

"Consumption" : energy consumption

}

More specifically:

MotorPower is a numeric value to denote the power of the EV motor in kW,

MotorType is the motor type (e.g. “synchronous”),

BatteryType is the battery type (e.g. “LiIon”),

AreaType is the type of the area (e.g. “urban”),

LevelOfService is the level of service (e.g. “saturated”),

Gradient is a numeric value that represents the gradient of a road as percentage (e.g. +2%),

Consumption is a numeric value to denote the energy consumption of the EV in Wh/km. The sequence diagram in Figure 9 shows that the process to obtain the EC and impact of emissions for a route with an EV is similar to the case of PCs, with the difference being that the CO2 equivalent emissions depend also on the country-specific electricity mix.


D3.4.2: Page 43 of 47

Figure 9: Sequence diagram of the web-service for the energy efficiency assessment of EV routes.

6.1.3 Public Transport

The evaluation of the GWP of a route with public transport (PT) is based on average fuel/energy consumption and EFs extracted from SimaPro, which includes processes related to passenger transport activities from the Ecoinvent database. Figure 10 presents the relevant WTT and TTW impact factors expressed in grams of CO2 equivalents per passenger-km. Given that passenger transport by tram produces no direct emissions, it is interesting to note that the WTT impact, and consequently the WTW impact, in Spain (ES) and Croatia (HR) differs as a result of the different electricity mix in these countries. The calculation of the WTW impact is straightforward and depends on the distance (route length) and the vehicle type, as shown in Equation (7).

𝐺𝑊𝑃𝑊𝑇𝑊(𝑃𝑇) = 𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒 ∗ (𝐺𝑊𝑃𝑊𝑇𝑇(𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑡𝑦𝑝𝑒) + 𝐺𝑊𝑃𝑇𝑇𝑊(𝑣𝑒ℎ𝑖𝑐𝑙𝑒 𝑡𝑦𝑝𝑒)) (7)


D3.4.2: Page 44 of 47

Figure 10: WTT and TTW impact per passenger-km by means of public transport.

Consequently, the energy efficiency assessment of PT routes is implemented as a simple web-service, taking into account the average (static) factors of energy/fuel consumption for buses and trams, as well as the CO2 equivalent emissions of transport fuels and the country specific electricity mix.

6.2 Energy Efficiency Assessment of Multimodal Routes as a Web Service

This subsection describes the integration of the individual web-services into the EEAM for the energy efficiency assessment of multi-modal routes. Figure 11 depicts a high-level representation of the EEAM structure, as well as the main data flows between the EEAM components. Upon the receipt of a request from the MOVESMART routing services to assess a route plan, the “Energy efficiency assessment of multi-modal routes” process disaggregates it into unimodal route legs. Next, each unimodal service involved, depending on the case, retrieves relevant information from the locally stored database of road network characteristics (e.g. road type, speed limits and elevation) as well as from the database of vehicle profiles, and performs the energy efficiency assessment by retrieving the required EFs, FCs or ECs from the corresponding database. For instance, emission/consumption factors according to vehicle type, road gradient, and traffic situation are retrieved for the case of PCs, while emission/consumption factors according to EV type, road gradient, and level of service are retrieved for the case of EVs. Each route leg is processed on an individual basis (separately from the others), in order to send the required queries to the relevant databases in parallel, and thus increase the performance of the service in terms of execution time, as shown in Figure 12. Then, the output from the individual unimodal services in terms of partial emissions (in CO2 equivalents) and fuel/energy consumption are combined together in order to provide the aggregated results for the total impact of the route plan in terms of GWP, total energy consumption, as well as consumption by energy source. At this point, it is noted that zero energy consumption and impact of emissions are assumed for the case of walking and cycling.


D3.4.2: Page 45 of 47

Figure 11: Internal structure of the Energy Efficiency Assessment Module (EEAM).

Figure 12: Parallel processing of route legs in multi-modal routes.

6.3 Estimation of Per-Route / Per-Traveler Emissions

As already pointed out, the emission/consumption factors for PT are available (and stored in MongoDB) on a per passenger-km basis, whereas for the other means of transport these are available in terms of vehicle-km. For the sake of consistency, the processes of the EEAM that assess the routes of PCs and EVs take into account the average vehicle occupancy in EU (as a reasonable approximation due to the absence of relevant data characterizing the locality of the project pilots), according to the mode of transport involved, in order to report the output results to the routing services in terms of fuel/energy consumption and impact of emissions per passenger.


D3.4.2: Page 46 of 47

7 Experimental Validation of UTKB Functionalities

The techniques that have been implemented for supporting the functionalities of the UTKB have already been published in significant scientific fora (cf. [1,2,4,7,8,9]), and experimentally evaluated thoroughly on real-instances of urban-transport networks, such as the metropolitan areas of Berlin and London. Moreover, preliminary experimental evaluation of all the functionalities of UTKB has also been conducted for the city of Vitoria, which is one of the two pilot sites of the project. More thorough experimental evaluation on both the pilot sites will be conducted during the last year of the project.

8 Conclusions

In this deliverable we have provided a comprehensive description of the development of the Urban Traffic Knowledge Base (UTKB) within MOVESMART’s WP3. In particular, we provided extensive descriptions of (i) the produced traffic-related historic raw-traffic data and (service-dependent) metadata and live-traffic temporal (meta)data; (ii) the supporting hardware residing at the UT-Cloud, which hosts these traffic-related data; (iii) the main techniques for maintaining the service-related metadata, as well as for auditing live-traffic reporting of the actual status in the network; (iv) the core UT-Cloud based routing services (unimodal TD-routing, multimodal routing, and EV routing) residing at the UTKB server; and (v) the interoperability of the UTKB infrastructure with other modules, in particular with the Traffic Prediction module and the Energy Efficiency Assessment module All the historic raw-traffic data and (service-dependent) metadata are continuously updated by our services, and are also complemented with the live-traffic reporting data that are also maintained within the UTKB. Both historic traffic and live-traffic data and metadata are already exploited by the core routing services (TDR, MMR, and EVR) which have been implemented within the UTKB and are provided as ever-running services in the UTKB server. For the provision of these traffic data, the UTKB services have to interact with other modules of MOVESMART, in particular, with the modules TPM, CSM, and EEAM. Moreover, the core routing services have already been used as building blocks of the more sophisticated personalized mobility services of MOVESMART’s WP4, such as CAR-ROUTES, EV-ROUTES, MM-ROUTES, and CAR POOLING services. More services of WP4 will also exploit the UTKB infrastructure in the future.


D3.4.2: Page 47 of 47

References

[1] M. Baum, J. Dibbelt, L. Hübschle-Schneider, T. Pajor, D. Wagner: Speed-Consumption Tradeoff for Electric Vehicle Route Planning. In Algorithmic Approaches for Transportation Modeling, Optimization, and Systems (ATMOS), 2014. [2] M. Baum, J. Dibbelt, A. Gemsa, D. Wagner, T. Zündorf: Shortest Feasible Paths with Charging Stops for Battery Electric Vehicles. In ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems, 2015. [3] CEN 2012, “EN 16258:2012 Methodology for calculation and declaration of energy consumption and GHG emissions of transport services (freight and passengers),” European Committee for Standardization (CEN, French: Comité Européen de Normalisation), 2012. [4] D. Delling, J. Dibbelt, T. Pajor, D. Wagner, R.F. Werneck: Computing Multimodal Journeys in Practice. In International Symposium on Experimental Algorithms (SEA), 2013. [5] Hausberger S., Rexeis M., Kühlwein J., Luz R., 2014. “Update of Emission Factors for EURO 5 and EURO 6 vehicles for the HBEFA Version 3.2,” available at: http://www.hbefa.net/e/documents/HBEFA32_EF_Euro_5_6_TUG.pdf [6] Hausberger S., Rexeis M., Zallinger M., Luz R., 2010. “Emission Factors from the Model PHEM for the HBEFA Version 3,” available at: http://www.hbefa.net/e/documents/HBEFA_31_Docu_hot_emissionfactors_PC_LCV_HDV.pdf [7] S. Kontogiannis, G. Michalopoulos, G. Papastavrou, A. Paraskevopoulos, D. Wagner, C. Zaroliagis: Analysis and Experimental Evaluation of Time-Dependent Distance Oracles. In SIAM Algorithm Engineering and Experiments (ALENEX 2015), pp. 147-158, 2015. [8] S. Kontogiannis, G. Michalopoulos, G. Papastavrou, A. Paraskevopoulos, D. Wagner, C. Zaroliagis: Engineering Oracles for Time-Dependent Road Networks. In SIAM Algorithm Engineering and Experiments (ALENEX 2016), pp. 1-14, 2016. [9] S. Kontogiannis,C. Zaroliagis. Distance Oracles for Time-Dependent Networks. In Algorithmica, to appear, 2015. [10] Pré Sustainability, 2015. “SimaPro, the world´s leading LCA software,” available at: http://simapro.com/ [11] Travesset-Baro O., Rosas-Casals M., Jover E., 2015. Transport energy consumption in mountainous roads. A comparative case study for internal combustion engines and electric vehicles in Andorra, Transportation Research Part D: Transport and Environment, 34, pp. 16-26.

http://www.hbefa.net/e/documents/HBEFA32_EF_Euro_5_6_TUG.pdf

http://www.hbefa.net/e/documents/HBEFA_31_Docu_hot_emissionfactors_PC_LCV_HDV.pdf

http://simapro.com/

Documents

D3.4.2 Development of the Urban Traffic Knowledge Basemovesmartfp7.iti.gr/.../uploads/2018/...D3.4.2_v11.pdf · 10. 09.03.2016 Incorporation of suggested minor changes in the consolidated