Modelling and Optimization of the Unit Dispatch ...

CONSERVATOIRE NATIONAL DES ARTS ET METIERS PARIS

Thesis submitted for the purpose of obtaining the

CNAM ENGINEER’S DEGREE In computer science, modelling, and optimization

Benjamin BERHAULT

‘Modelling and Optimization of the Unit Dispatch System of an Emergency Service’

Thesis defended on 5 July 2017 JURY President:

Christophe PICOULEAU

Professor, Head of IMO department, CNAM Paris

Members:

Eric SOUTIL

Lecturer, CNAM Paris

Amélie LAMBERT

Lecturer, CNAM Paris

Company Tutors:

Benjamin FOUILLEUL

Geomatician, Paris Fire Brigade

Vianney BŒUF

Doctoral Student in Applied Mathematics, INRIA Saclay and CMAP, Ecole Polytechnique

Abstract The optimal engagement of a rescue team following an emergency call does not necessarily result in the assignment of the one offering the shortest transit delay. It should be used in cases where the urgency is known. However, this selection should be put into perspective for situations that are less critical. For these less critical cases, the service coverage preservation should be taken into account in order to ensure a good quality of service for emergency assistance requests with proven severity. Today, information systems for the allocation of rescue services seem to be dissociated from their geographic information systems. In order to reach an optimal allocation, these two systems must communicate so that the allocation phase takes into account transit delays and coverage factors. Bearing this in mind, the present work defines a logic, identifies challenges, and proposes technologies and architecture for the Paris Fire Brigade. The realization of this information technology project should provide the emergency service with real-time quality of service information and result in an improvement of its allocation system.

Acknowledgements My first thanks go to my tutors, and most of all to my EICNAM academic tutor, Christophe Picouleau, who remained present and attentive even in times of doubt. The conduct of a thesis is not a long, quiet river. Hence, having tutors who are ready to listen and who are easily accessible is helpful for any student in the phase of thesis work. Thanks also to my company tutors, on whom I initially believed that I was imposing myself but who showed from the start a fabulous enthusiasm for the work. My gratitude goes out to Benjamin Fouilleul, who understands perfectly the need for relational and human qualities in a working environment. He is a perfect proof of the need for communication and exchange between professional fields in order to be able to move forward and complete projects. The lack of communication within a military structure too often prevents the maximization of skills, and the emulation of the ideas and forces involved. Thank you to Vianney Bœuf for the time he spent following my work with the attentive look that is his alone. His valuable advice and questions pointing to the weaknesses and imperfections enabled me to increase the quality of the present work. I am thankful to have benefited from these two tutors, each demonstrating a different facet of the role of an engineer—one with more practical skills in software development and the other with a vision more marked by the fields of research and applied mathematics. This has been a luxury that I can only wish for any engineering student. Thanks also to the other members of the jury, Amélie Lambert and Eric Soutil, who agreed to judge the work. It was wonderful to note the interest aroused in the work presented. I also cannot omit Geneviève Obrist and François Faye who were caring supports. They listened and provided great advice, both qualities that we would like to see emerge from all superiors. How could I go without mentioning David Wyatt, Head of Information Management of the London Fire Brigade, who offered me his time and patience to understand how and with what means our neighbours work. Being able to interact with David and discover the structure of the London Fire Brigade has become an unforgettable memory. Thank you! Of course, I cannot forget his great team: Andy Mobbs, Anna Lockwood, and Chris O'Connor. To this was added Graham Holland from ORH Ltd. He is doing an excellent job for the London Fire Brigade. Thanks also to Todd Stout and Mike Thompson from FirstWatch, Zack Bouz from the Los Angeles Fire Department, Suzann Leininger from the California Department of Forestry and Fire Protection of San Diego, and Luca Ruggero from HERE for his responsiveness and unfailing assistance. Finally, I cannot end these acknowledgements without mentioning the framework of the CNAM institution in which it has been extremely pleasant to study for the last few years. The open-mindedness of the teachers and the diversity of students' backgrounds are real assets. The CNAM offers an unbelievable and unusual opportunity that makes this institution a valuable gift—a gift that can only be hoped for and that I hope will continue to grow.

Table of Contents Abstract ............................................................................................................................................................. ii Acknowledgements ............................................................................................................................................ i Abbreviations .................................................................................................................................................... v 1.

Introduction............................................................................................................................................... 1 1.1

1.1.1

Collection of Information .......................................................................................................... 2

1.1.2

Planning ..................................................................................................................................... 2

1.1.3

Assistance of Operational Teams .............................................................................................. 3

1.1.4

Ongoing Management of Operational Teams............................................................................ 3

1.2

2.

Scope of Work ........................................................................................................................... 4

1.2.2

Functional Needs ....................................................................................................................... 5

Definitions ................................................................................................................................................ 6 Business Terms .................................................................................................................................. 6

2.1.1

Response Time .......................................................................................................................... 6

2.1.2

Jurisdiction ................................................................................................................................ 6

2.1.3

Service Availability Measures ................................................................................................... 6

2.1.4

Catchment Area ......................................................................................................................... 7

2.2

Mathematical Terms .......................................................................................................................... 7

2.2.1

Graph ......................................................................................................................................... 7

2.2.2

Adjacency List ........................................................................................................................... 7

2.3

Route Calculation Algorithms ........................................................................................................... 8

2.3.1

Greedy Algorithm ...................................................................................................................... 8

2.3.2

Dijkstra ...................................................................................................................................... 8

2.3.3

Best-First Search........................................................................................................................ 9

2.3.4

A* .............................................................................................................................................. 9

2.3.5

Contraction Hierarchies ........................................................................................................... 10

2.3.6

For More Information .............................................................................................................. 12

Introduction of a Rescue Service; Case Study: the Paris Fire Brigade ................................................... 13 3.1

The Paris Fire Brigade ..................................................................................................................... 13

3.2

Operational Activity ........................................................................................................................ 13

3.2.1

Jurisdiction and Emergency Request ....................................................................................... 14

3.2.2

Daily Solicitation ..................................................................................................................... 15

3.3 4.

Study Framework .............................................................................................................................. 4

1.2.1

2.1

3.

What Could Be the Expectations of an Emergency Service from Its Information System? ............. 1

Operational Objective of the Service ............................................................................................... 15

Analysis of an Emergency Response System ......................................................................................... 16 i

Table of Contents 4.1

Decision-makers Dispatching Rescue Teams .................................................................................. 16

4.2

Emergency Service Triggering Process ........................................................................................... 18

4.2.1 4.3

5.

Intervention Management Information System ....................................................................... 21

4.3.2

Cartographic Information System ........................................................................................... 21

Study of Existing Solutions for Viewing and Analysing Emergency Service Coverage ....................... 24 Coverage Representation Maintained by the Paris Fire Brigade ..................................................... 24

5.2

Commercial Solution Used in France ...................................................................................... 25

5.2.1

OXIO ....................................................................................................................................... 25

5.3

7.

Software Environment ..................................................................................................................... 21

4.3.1

5.1

6.

Qualification of an Emergency Request .................................................................................. 18

Commercial Solutions Used Abroad ............................................................................................... 25

5.3.1

ORH ......................................................................................................................................... 25

5.3.2

DECCAN ................................................................................................................................. 26

5.3.3

FirstWatch ............................................................................................................................... 26

5.3.4

Intermedix................................................................................................................................ 27

Definition of the Target System.............................................................................................................. 28 6.1

Proposed Allocation Logic .............................................................................................................. 29

6.2

Sketch of the Means Management Data Model ............................................................................... 30

6.3

Computation and Representation of Emergency Service Coverage ................................................ 32

6.4

Service ............................................................................................................................................. 33

6.4.1

Data Maintained ...................................................................................................................... 33

6.4.2

Coverage Constant ................................................................................................................... 34

6.4.3

Client-side Query..................................................................................................................... 34

6.4.4

Response of the Service ........................................................................................................... 35

6.4.5

Future Developments ............................................................................................................... 37

Selection of an Open-Source Solution for Exploitation of Geographic Information System Data ........ 38 7.1

Investigation of Route Computation Solutions................................................................................ 38

7.1.1

GraphHopper ........................................................................................................................... 38

7.1.2

OpenTripPlanner ..................................................................................................................... 38

7.1.3

OSRM (Open Source Routing Machine) ................................................................................. 38

7.1.4

pgRouting ................................................................................................................................ 39

7.1.5

RoutingKit ............................................................................................................................... 39

7.1.6

Routino .................................................................................................................................... 39

7.1.7

SpatiaLite ................................................................................................................................. 39

7.1.8

Tempus .................................................................................................................................... 40

7.1.9

Valhalla.................................................................................................................................... 40

7.1.10

Comparative Table .................................................................................................................. 41 ii

Table of Contents 7.2

8.

Choosing a Framework and a Philosophy: Performance versus Flexibility .................................... 42

7.2.1

Expected Functionality ............................................................................................................ 43

7.2.2

What Is a Spatial Database? .................................................................................................... 43

7.2.3

Introduction to PostGIS ........................................................................................................... 43

7.2.4

pgRouting ................................................................................................................................ 45

Final Architecture ................................................................................................................................... 55 8.1

Why C++ for This Service and Not C or C# ................................................................................... 55

8.1.1 8.2

Making the pgRouting Framework Evolve to Better Meet the Needs of the Rescue Service ......... 56

8.2.1 8.3

C++ Strengths .......................................................................................................................... 56

Aside on the Function departure_time() ...................................................................... 59

Appliance Dispatch Application/Service Communication .............................................................. 60

8.3.1

Phases of Reflection Leading to the Selection of a Protocol ................................................... 60

8.3.2

Thrift vs. Avro vs. Protocol Buffers ........................................................................................ 61

8.4

Changes in the Emergency Dispatch Application ........................................................................... 65

8.5

Opportunities for Cartographic Applications .................................................................................. 65

8.5.1

PostgreSQL + Node.js ............................................................................................................. 65

8.5.2

Applications Requiring More Complex Operations ................................................................ 66

8.6

Overall Scheme ............................................................................................................................... 67

8.7

Response Capacity Rendering ......................................................................................................... 67

9.

Traffic Data Services .............................................................................................................................. 69 9.1

Traffic Data from Government Services in France ......................................................................... 69

9.1.1

Data from the Ministry of Ecology, Sustainable Development and Energy............................ 70

9.1.2

Data of the Parisian City Council ............................................................................................ 71

9.2

Commercial Traffic Data Services .................................................................................................. 72

9.2.1

TomTom Traffic Flow—Intermediate Service ........................................................................ 73

9.2.2

HERE—Traffic Flow Data API .............................................................................................. 74

9.3

Assessment of the Appropriateness of the Use of the Traffic Information Data Services .............. 76

10.

Ongoing Project Recommendations .................................................................................................... 77

12.

Academic Purposes ............................................................................................................................. 79

13.

Conclusion ........................................................................................................................................... 80

Bibliography .................................................................................................................................................... 81 Appendix 1: Vocabulary.................................................................................................................................. 86 Appendix 2: Example of Content for the Data Model in § 6.2 ........................................................................ 93 Appendix 3: pgRouting ‘Ways’ Table Columns ............................................................................................. 97 Appendix 4: pgRouting Query to Retrieve the Immediate Response the Service Can Offer .......................... 99 Appendix 5: Performance Test for Multithreaded pgRouting Queries.......................................................... 100 iii

Table of Contents Appendix 6: Introduction to gSOAP ............................................................................................................. 102 Installation from the source code .............................................................................................................. 102 Shared libraries loading............................................................................................................................. 102 Example of Service Looking for the Closest Node Near Defined GPS Coordinates ........................... 102 Appendix 7: Eight Good Behaviors of a Manager ........................................................................................ 106 Appendix 8: Calculation of the Cost of a C++ Developer for the Public Service ......................................... 107 Total cost for a gross salary of €44,000 .............................................................................................. 107 Total cost for a gross salary of €60,000 .............................................................................................. 108 Appendix 9: Open-Source Software Libraries Used in the Development Environment ............................... 109

iv

Abbreviations ACID: Atomicity, Consistency, Isolation, Durability ADAGIO: Application de Diffusion de l’Alerte et de Gestion Informatisée des Opérations ALT: A*, Landmarks, and Triangle inequality ANTARES: Adaptation Nationale des Transmissions Aux Risques Et aux Secours API: Application Programming Interface AR: Ambulance de Réanimation (in English: medical unit) ASCII: American Standard Code for Information Interchange BGL: Boost Graph Library BSPP: Brigade de Sapeurs-Pompiers de Paris CALT: Core-ALT CCH: Customizable Contraction Hierarchies CH: Contraction Hierarchies CHASE: CH + Arc Flags CNAM: Conservatoire National des Arts et Métiers CORBA: Common Object Request Broker Architecture CPCU: Company Parisienne de Chauffage Urbain CPU: Central Processing Unit CRP: Customizable Route Planning DDE: Direction Départementale de l'Equipement DRIEE: Direction Régionale et Interdépartementale de l'Environnement et de l’Energie EDF: Électricité De France EPSG: European Petroleum Survey Group FOSS4G: Free and Open Source Software for Geospatial GDAL: Geospatial Data Abstraction Library GDF: Gaz De France GIS: Geographic Information System GIST: Geographic Information Science and Technology GPS: Global Positioning System GTFS: General Transit Feed Specification HH: Highway Hierarchies HH*: Highway Hierarchies + A* HLC: Hub Label Compression HNR: Highway-Node Routing HPML: High-Performance Multi-Level HTTP: HyperText Transfer Protocol IGN: Institut National de l'Information Géographique et Forestière INC: Incendie (in English: fire) INED: Institut National d’Etudes Démographiques INSEE: Institut National de la Statistique et des Etudes Economiques JSON: JavaScript Object Notation OSM: OpenStreetMap OSRM: Open Source Routing Machine PHAST: PHAST Hardware Accelerated Shortest-path Trees RAM: Random-Access Memory RATP: Régie Autonome des Transports Parisiens v

Abbreviations ReachFlags: Reach + Arc-Flags REAL: REach + ALt REST: REpresentational State Transfer RPC: Remote Procedure Call SAMU: Service d'Aide Médicale Urgente SAV: Secours A Victimes (victim assistance) SDIS: Service Départemental d’Incendie et de Secours SDK: Software Development Kit SHARC: Shortcuts ARC-flag SNCF: Société Nationale des Chemins de Fer français SOAP: Simple Object Access Protocol SQL: Structured Query Language SSD: Solid-State Drive TNR: Transit Node Routing UML: Unified Modeling Language VSAV: Véhicule de Secours et d’Assistance aus Victimes (paramedic ambulance) WGS: World Geodetic System XML: eXtensible Markup Language

vi

1. Introduction Emergency services are commonly split into three families: law enforcement, fire departments, and emergency medical services. In some countries, these missions are carried out by three distinct organizations. In others, as in France, the fire, rescue, and ambulance services are all handled by a single organization. The effectiveness of these services is very much related to the relevance of their responses to the requests for relief that they receive. Contrary to what we might believe, the optimal dispatch of a team to a request for relief does not necessarily result in the assignment of the one offering the shortest transit delay. Instead, it is necessary that the emergency reason be established as well as put into perspective for less critical situations. For these less critical cases, the notion of operational coverage conservation (see § 2.1.3.1) should be taken into account to ensure a good quality of service for future emergency requests whose severity will be proven. This work is intended to be an investigation that provides a set of proposals for improving the quality of service of an emergency service, be it a fire and rescue service, a pre-hospital emergency department, or the police force. Today, it seems that the systems used by emergency services face difficulty in answering the following questions: -

What percentage of the population, at this point in time for the jurisdiction, is served in less than 10 minutes after the emergency call acceptance? Based on what measures does the decision-maker of the operations management centre engage a temporary reallocation of resources to ensure service coverage while maintaining the speed of response? How many means of the service can be used to respond to a catastrophe or a terrorist attack (highpoint solicitation) and maintain a capacity to respond to the current requests at eight, ten, or twelve minutes following the call acceptance for 70%, 80%, or 90% of the population?

The decisions taken so far to deal with these problems, owing to the lack of resources, are closely linked to the perception and judgment of the managers of management centres on the basis of the limited measures they have at their disposal. Following this observation, the present work defines a logic, identifies the challenges, and proposes the technologies and an architecture for the Paris Fire Brigade. The realization of this information technology (IT) project should provide the emergency service with realtime quality of service information and should result in an improvement of its allocation system.

1.1 What Could Be the Expectations of an Emergency Service from Its Information System? The services targeted by this work should be part of a larger project designed to meet the expectations that the decision-makers within a rescue service can have from their information system. Outlined below are what these expectations might be. This first reflection also confirms the orientation of the work undertaken since it could be a necessary piece for further evolutions.

1

Introduction

1.1.1 Collection of Information A single electronic device would combine a host of features, thereby making information easy to retrieve and manage, while also reducing costs. These features include: -

-

History of the appliance GPS positions; Navigation assistance; Receptacle of the departure orders (information relating to an emergency request transmitted to the dispatched team); Support for the input of intervention information; Means for transmitting information to the proper emergency service such as other government services and private partners (fire-fighters, SAMU, French Red Cross, civil protection, police, RATP, SNCF, DDE, GDF, EDF, hospital services, services of the city). The capacity for inter-service information exchange could, for example, enable the setting up of preventive actions for the riskiest buildings; Phonic means of communication.

The system would allow the direct input of a proposal to update data of the geographic information system for buildings, traffic lanes, and fire hydrants. This proposal would then be sent back to the competent department for verification and validation.

1.1.2 Planning An ideal emergency management system should estimate the likelihood of an emergency request for different areas of the jurisdiction based on: -

-

The population density; Societal parameters; Environmental parameters (e.g. weather); Other risks (e.g. industrial); The age of the population; Time of day; Day of the week; Period of the year; Presence of demonstration (e.g. national day, strike); Type of venue (e.g. concert hall, stadium); Crime rate; Dilapidated structures; Data from government agencies: • National Institute of Statistics and Economic Studies (INSEE); • National Institute for Demographic Studies (INED); • National Institute for Geographic and Forest Information (IGN). Etc.

The system should be able to: -

-

Predict the quality of response of the service for up to one, two, three, or four hours and so on, and alert managers in sectors where the quality of service in the state will no longer be assured for the next X hours; Assess the impact of the unavailability of an appliance; Assess the impact of the closure of a rescue centre; Make it possible to revise the annual plan for the allocation of resources taking into account: 2

Introduction • • •

Urban development plans; Demographic changes; Population trends in terms of demand for relief.

1.1.3 Assistance of Operational Teams The system could suggest an initial deployment area when the Chief of Relief Operations needs it. During a fire intervention, the system would suggest a fire hydrant to the engaged vehicles equipped with a pump. It would allow the chief of the engine to confirm this proposal or to select another one. The system would transmit this information to other committed units. As is already the case with the London Fire Brigade: -

The teams would directly have the plans of all the buildings on a digital tablet, thus facilitating the management of recognition operations and the guidance of the rescue teams. Housing with risk objects (gun owner, oxygen cylinder, etc.) would be referenced and the information would be systematically notified to the team sent.

1.1.4 Ongoing Management of Operational Teams The system would assist the manager to ensure that the arrival time of a first engine at the place of an emergency request does not exceed 10 minutes (for fire and rescue emergency requests). The system should: -

Propose the appliances by taking into account the transit delay and the resulting post-allocation coverage; Be able to characterize service coverage from acceptable to critical; Be able to identify the coverage holes within the jurisdiction; Propose the switch in the degraded mode (see definition on Page 29) following an important solicitation of the means; Suggest a temporary reallocation of appliances to deal with the cover holes.

The system should be able to estimate the arrival time on intervention of an engine according to: -

-

Traffic data; Position of the engine: • Stationed in the rescue centre; • Team on radio listening on board the engine; • Team on radio listening outside the engine. Driver’s driving style; Impact of the chief of the appliance on the driver; Whether or not the vehicle selected is from the nearby rescue centre (staff from the nearby rescue centre has a better knowledge of the roads); Weather information; Type of engine.

The staff would never be engaged for more than 10 hours of 24-hour shifts. The system would balance the burden of the interventions on different teams when the nature of the emergency requests allows it or when the arrival time is estimated similarly for different teams. 3

Introduction

1.2 Study Framework The set of features suggested previously goes far beyond the scope of an engineering brief. The work has therefore been concentrated on the functionalities that seem the most realistic, the most beneficial for the service; in particular, it aims to make the software bricks seem indispensable for further evolutions.

1.2.1 Scope of Work The work has focused on: -

-

Formalizing an optimal engagement process of relief by taking into account: • The transit times of available teams; • The state of operational coverage; Defining the corresponding data structure; Defining a method for the operational coverage assessment; Justifying technologies to favour.

This work is therefore a preliminary study for the construction of a service feeding an application for the management and the allocation of relief teams. A UML (Unified Modeling Language) representation could be as follows:

Figure 1: A diagram of use cases of the studied system

Legend

The use case of the source implies the execution beforehand of the one shown by the arrow.

The use case of the source can be followed by the case pointed out. Generalization; indicates that the use case of the souce is a specificity of the one pointed out.

4

Introduction

1.2.2 Functional Needs For the defined perimeter, the work has endeavoured to provide solutions to meet the following functional needs: • • • • • • • • • • •

•

Maintaining values in order to assess the service quality of the emergency service: territorial coverage for different missions the service is in charge of; Having a vision for the state of the service in real time; Proposing to the decision-maker for an emergency call the teams that would ensure the optimal engagement associated with the resulting coverage information; Making it possible to distribute the burden of relief requests among the various teams that are part of the service; The system must not undermine the existing core of the current emergency release system; The system will have to offer a service that does not delay the triggering process of the emergency service; The system should use the cartographic information maintained by the institution; The system must be able to use traffic information in order to assess as accurately as possible the transit times of the appliances; The system should offer some flexibility in setting up; The system should allow the manager to be aware of the existence of coverage holes in order to commit reallocations or make a change in the rules of the appliance dispatch system (to preserve a certain service quality following a usual solicitation); The system must be extremely reliable; The system must take into account the load-shedding mode (see definition on Page 28).

5

2. Definitions Several definitions were made available at the end of the thesis. Below are those that seem the most essential to ensure a good understanding of this work for different reader profiles.

2.1 Business Terms 2.1.1 Response Time The most commonly used meaning of response time [1] corresponds to the time between the emergency call acceptance and the arrival of a first team at the place of the rescue request. This delay can be broken down into different phases: -

Off-hook time: This time is not a priori taken into account [1] to qualify the response time for fire and rescue services in France; Time to process the emergency request; Time to transmit the alert to the unit selected; Time to alert the recue team members; Time to mobilize the recue team members; Transit time of the appliance.

2.1.2 Jurisdiction A jurisdiction refers to a territory of first intervention and administrative responsibility for a rescue centre, a company (grouping of rescue centres), or a ‘groupement’ (grouping of companies) or the fire brigade itself.

2.1.3 Service Availability Measures Two types of measurements of the availability of the rescue service and the resulting representations have to be distinguished and relate to: -

Immediate response → Operational coverage Response capacity → Operational capacity

2.1.3.1 Operational Coverage The operational coverage is a measure of the immediate response capacity of the rescue service for its jurisdiction for the missions in charge. This term, which is not clearly defined in the professional jargon, refers to a measure for the time required to send a first team anywhere in the jurisdiction area. The operational coverage should be monitored for at least the two main kinds of service: -

Victim assistance; Fire-fighting.

Each rescue service formulates its own definition of operational coverage (see the work carried out for the benefit of the Departmental Fire and Rescue Service of the Val d’Oise by Frédéric LESIEUX et al. [1]) and, as specified in this document, ‘coverage and operational response are used without real distinction’ by the actors of the rescue services.

6

Definitions

2.1.3.2 Operational Capacity As part of the annual allocation plan for the Paris Fire Brigade, its employment division re-examines each year the allocation of the resources in order to ensure the quality of the service for the coming year. This arrangement, once validated by the general commanding the fire brigade, will make it possible to justify to the elected representatives the financial resources needed to support it. Today, the fire brigade's response capacity tends to ensure the deployment of 10 red alpha1 plans while maintaining continuity of the service for the other requests. The operational capacity corresponds to the capacity to respond quantitatively to potential requests for relief, thus answering the question: ‘How many simultaneous events is the service able to cope with?’

2.1.4 Catchment Area A catchment area is a geographical area representing an area of influence. Catchment areas are mainly used in commerce, where they represent the geographical area from which the majority of commercial customers originate. In our context, it will correspond to sets of road sections served by one or more rescue units within a given time limit.

2.2 Mathematical Terms 2.2.1 Graph In mathematics, and more specifically in graph theory, a graph is a structure designed to represent a set of objects in which certain pairs of objects are connected. These objects correspond to the mathematical abstraction of vertices (or nodes) and the links to edges (or arcs).

𝑉𝑒𝑟𝑡𝑖𝑐𝑒𝑠: {6; 3; 8} 𝐸𝑑𝑔𝑒𝑠: {[6 , 3]; [3 , 6]; [8 , 6]; [3 , 8]}

Figure 2: An example of a graph

2.2.2 Adjacency List An adjacency list of a graph is a representation of the graph where each node is connected to a list of adjacent nodes.

3 → {6; 8} 6 → {3} 8 → {6}

Figure 3: An example of a graph and its corresponding representation in the form of an adjacency list

1

An alpha red plan is a module of a pre-constituted engine intended to bring relief to a site in a multi-attack context. This system was created following the attacks in Madrid in 2004 and London in 2005.

7

Definitions

2.3 Route Calculation Algorithms Two algorithms relating to the exploitation of graphs are specifically mentioned later: Dijkstra and contraction hierarchies. It seems preferable to introduce them here. A third, A*, is also mentioned, but we will not dwell on it at length.

2.3.1 Greedy Algorithm A greedy algorithm is an algorithm that follows choices based on what it considers to be optimal at the moment. The choices made correspond to local optimums that are not necessarily optimums on a larger scale.

2.3.2 Dijkstra The Dijkstra algorithm [2] is a greedy algorithm that is used to find the shortest paths within a graph from a source node. It was designed by Edsger W. Dijkstra in 1956 and published three years later.

Algorithm 1. For a given graph, at initialization, each vertex is assigned a distance value: • The initial vertex (start or source) is set to zero; • All other vertices are defined at infinity (∞). 2. The following lists are updated iteratively over the algorithm: • A list of unprocessed vertices; • A list of the shortest path distances between the vertices of the graph and the source vertex; • A list of predecessors following one shortest path. At initialization, the set of vertices is referenced within the list of untreated vertices. 3. The so-called 'current' vertex is systematically selected from the untreated vertices characterized by one smaller distance2 from the source. For the current vertex, the algorithm assesses the distances relative to the vertices of the direct vicinity with the exception of the nodes already processed: The shortest-known path between the origin and the current vertex

+

Distance between the current vertex and the unprocessed vertices of the immediate vicinity

If the value found is less than the one known, the value is replaced. 4. When the set of neighbouring vertices in the list of untreated vertices has been inspected, the current vertex is removed from the set of unprocessed vertices. 5. If a stop condition has been defined, such as the visit of one or more destination vertices, when processing this or these vertices, the algorithm stops. 6. Otherwise, an unvisited node characterized by a smaller distance is taken as the current node and the algorithm returns to Step 3.

2

by one because there may exist several ‘shortest paths’ of the same length

8

Definitions

Pseudocode function Dijkstra(Graph G, source): Initialization of a set Q of unvisited vertices of G Initialization of a list dist[] intended to receive the distances between the various vertices of G and the source vertex Initialization of a list prev[] intended to receive the predecessors of the vertices following one shortest path starting from the source Initialization of u receiving one by one the vertices of Q characterized by a smaller distance with respect to the source // Initialization for each vertex v of the graph: dist[v] ← INFINITY // Set to ‘infinity’ the distance value of vertex v prev[v] ← UNDEFINED // Set to ‘undefined’ the predecessor of v following a path from the source add v to Q // At initialization, all nodes are within Q dist[source] ← 0

// Set the distance from source to source = 0

while Q is not empty: u ← vertex of Q where Min(dist[u]) distance value remove u from Q

// Vertex of Q characterized by a smaller

for each neighbour v of u always within Q: alt ← dist[u] + length(u, v) if alt < dist[v]: // A shortest path to v was found dist[v] ← alt prev[v] ← u // with stop condition if a stop condition is met: stop the loop

// Stop the « while Q... »

return dist[], prev[]

2.3.3 Best-First Search Best-first Search is a search algorithm that explores a graph by successively selecting the most promising nodes according to a specific rule.

2.3.4 A* A*, pronounced ‘A star’, is a widely used algorithm for the shortest-path problem due to its simplicity and rapidity of execution. However, in practice in a road network, it will not systematically offer the optimal path. A* combines the formal approach of the Dijkstra algorithm and the heuristic approach of a best-first search. For a vertex 𝑛, let 𝑔(𝑛) be the cost of the computed path from the starting point to the vertex 𝑛 and ℎ(𝑛) an estimate of the remaining distance to the destination vertex (such as the Euclidean distance or the squared Euclidean distance). Using these values, A* characterizes each neighbouring node to those visited by a value 𝑓(𝑛) = 𝑔(𝑛) + ℎ(𝑛). Using these 𝑓(𝑛) values, among the neighbouring nodes, A* selects the unvisited vertex of the smallest 𝑓(𝑛) value to be the next vertex (next vertex to be visited) of the algorithm. This process is repeated until the destination vertex is discovered.

9

Definitions

2.3.5 Contraction Hierarchies The method of contraction hierarchies can make it possible to obtain answers to a route calculation request much faster than the Dijkstra algorithm, all thanks to a pre-processing phase of the graph and multilevel search algorithms. This method was proposed in 2008 by Robert Geisberger, Peter Sanders, Dominik Schultes, and Daniel Delling of the Karlsruhe Institute of Technology of Germany [3]. Like Dijkstra, it allows within a road graph, the recovery of a shortest path as well as the catchment area.

2.3.5.1 Contraction Phase The contraction of a vertex within a graph consists in making it disappear in the upper representation layer of the graph while retaining the distance information between the remaining vertices. The decision of which vertex to contract first is guided by the combination of several parameters [4]: -

Nodes whose contraction will generate a greater reduction in the number of edges for the upper layer of representation of the graph; Nodes whose contraction will be the fastest; Nodes whose neighbours have not yet been contracted; Etc. New representation of the graph following the contraction of C

Initial graph

Figure 4: An example of the contraction of a node C in a simple graph [5]

For the example above, A-C-E and A-C-B being the shortest paths, two shortcuts must be inserted: AB and AE. Since B-C-E is not a shortest path, there is no need to insert a shortest path between B and E.

10

Definitions

2.3.5.2 Search Algorithm Once the multilevel structure is built, the search algorithm of a shortest path has to carry out only ascending Dijkstra searches from both the source and the destination until a common node is reached. Graph

Step 1: Start of a bidirectional search

Step 2: 𝑥 is chosen as the next node to be processed from 𝑦

Step 3: Common node found and thus shortest path found

Step 4: Relaxing shortcuts

Legend: Edges of the initial graph Shortcuts computed during the contraction phase

Figure 5: An example of a shortest-path search on a multilevel structure between 𝑢 and 𝑦 [4]

A search for getting the coverage information from a vertex must, however, follow the ascending and descending branches until the stop condition is met.

11

Definitions

2.3.6 For More Information For more information on the different route calculation algorithms, it may be relevant to start with the following publications: -

‘Engineering Route Planning Algorithms’ (2009) [6]; ‘Route Planning in Transportation Networks’ (2015) [7].

From the latter, one will especially appreciate the comparison of different methods opposing the pre-processing time and the average time of execution of the requests for a route calculation:

Figure 6: ‘Preprocessing and average query time performance for algorithms with available experimental data on the road network of Western Europe, using travel times as edge weights. Connecting lines indicate different trade-offs for the same algorithm.’ From ‘Route Planning in Transportation Networks’ [7]

For more information on isochrone computation within a multilevel structure, see Valentin Buchhold's thesis, ‘Fast Computation of Isochrones in Road Networks’ (2015) [8]. For a more responsive implementation of contraction hierarchies named ‘customizable contraction hierarchies’, see the GitHub repository of the C++ RoutingKit library supported by the Karlsruhe Institute of Technology of Germany.

12

3. Introduction of a Rescue Service; Case Study: the Paris Fire Brigade 3.1 The Paris Fire Brigade The Paris Fire Brigade is a military unit under the authority of the Prefect of Police of Paris. It was founded after the tragic ball of the Austrian Embassy of 1 July 1810, in which a fire had broken out and from which the Emperor Napoleon I just barely escaped. The insufficiency of the ‘gardes pompes’ service of the time persuaded the monarch to reorganize and professionalize the fight against fire in Paris. By an imperial decree of 18 September 1811, he entrusted this mission to a military corps of sappers from the Engineer Regiment, which established the battalion of fire-fighters of Paris. The fire brigade, which now consists of about 8,000 firemen, ensures the security of property and people in the departments of Paris, Hauts-de-Seine, Seine-Saint-Denis, and Val-de-Marne, as well as some strategic sites such as the Landes missiles test centre and the Guyanese space centre. The brigade defends a population of about seven million inhabitants across 124 communes on the Parisian plate, to which is added almost three million daily workers, tourists, and people in transit.

3.2 Operational Activity In the year 2016, the fire brigade intervened in 477,567 calls for relief. The activities of the fire brigade are not restricted to fire-fighting activities alone. Since 1985, the fire brigade has been in charge of the victim assistance formerly insured by police relief. The institution categorizes its missions into nine different families: 1. 2. 3. 4. 5. 6. 7. 8. 9.

Fire Accidents Victim assistance Assistance to persons Animals Water, gas, electricity Goods protection Pollution Reconnaissance–research

Figure 7: The percentage of interventions in 2015 by category

As the graph shows, the vast majority of interventions involve victim assistance.

13

Introduction of a Rescue Service; Case Study: the Paris Fire Brigade

3.2.1 Jurisdiction and Emergency Request The Paris Fire Brigade has subdivided its jurisdiction area into different operational responsibility areas. The fire brigade is made up of three ‘fire and rescue groupings’ (black borders), each consisting of eight ‘fire and rescue companies’ comprising two to four rescue centres, each one associated with a responsibility administrative area (blue borders).

Figure 8: A representation of 30,000 consecutive interventions in red during October 2015

14

Introduction of a Rescue Service; Case Study: the Paris Fire Brigade

3.2.2 Daily Solicitation For 2015, the daily solicitation of the service is shown below.

Figure 9: Daily solicitation of the service for the year 2015

The highest demand was found on 14 July, the national holiday, between 01:00 and 02:00 in the morning, when relief teams were hired to respond to 195 requests. On the right graph, the box plot represents the 10th percentile, the first quartile, the median, the third quartile, and the 90th percentile.

3.3 Operational Objective of the Service Inter-ministerial Circular No. DGOS/R2/DGSCGC/2015/190 of 5 June 2015 states: …Co-ordination of interventions, complementarity of means and, more generally, cooperation between these actors3 constitute an imperative based on a goal of quality of service provided to users but also covers a requirement of overall efficiency of the device, with a watermark respect of the objective of access to urgent care in less than 30 minutes desired by the President of the Republic. …This roadmap is the expression of the joint desire of administrations and representatives of professionals to optimize the coordination and complementarity of the human and material means, both terrestrial and helicopter, which make it possible to bring National territory the most rapid and appropriate response to a user's request for emergency and emergency care. In practice, emergency services try to respond to requests, with a first team on site, within 10 minutes in agglomeration. For equity purposes, relief services distribute their resources as wisely as possible but are constrained by the structures and resources available to them.

3

Actors of the rescue services under the authority of the Ministry of the Interior and actors of the emergency medical assistance services under the authority of the Ministry of Health.

15

4. Analysis of an Emergency Response System Since Euro 20164, an emergency call platform 17-18-112 brings together on the site of the Paris Fire Brigade staff, the treatment of emergency numbers for the Paris conurbation: -

112: Emergency number valid throughout the European Union; 17: Police call number; 18: Fire and emergency call number.

This organization can be summarized by the following representation:

Figure 10: Emergency call platform 17-18-112 [10]

Level 1 screens the telephone callers and, therefore, does not validate the engagement of a rescue team. This work, centred specifically on the allocation process, will focus on the system in place from Level 2 of a rescue service: the fire and rescue service.

4.1 Decision-makers Dispatching Rescue Teams The team dispatch decision on a request for relief within the Paris Fire Brigade involves the responsibility of different actors, which they concretize via an information system named ADAGIO (Application de Diffusion de l’Alerte et de Gestion Informatisée des Opérations). These actors in the chain of dispatch of the relief are disseminated on different sites and can be grouped into four types of decision-making bodies: -

Call processing centre; Medical coordination centre; Operational monitoring centres; Operational watchdog.

Call Processing Centre The call processing centre receives and processes emergency calls. It consists of two managers and operators.

4

European Football Championship held in France

16

Analysis of an Emergency Response System

Medical Coordination Centre Its mission, in conjunction with the call processing centre, is to coordinate the victim assistance operations and to manage the medical teams. There are permanently three doctors (or two doctors + one nurse) and operators.

Operational Monitoring Centre An operational monitoring centre is a decentralized coordinating body at the level of a grouping (responsible for a third of the Paris conurbation) It consists of two managers and operators.

Operational Watchdog The operational watchdog is a decentralized coordinating body at the level of a rescue centre. The control operator becomes the decision-making body for the engagement of a team: -

when an applicant comes to the rescue centre to make a request for assistance; following a switchover of the system in the load-shedding mode (see Page 28)

In other words, different decision-makers, positioned on different sites, are in charge of the dispatch for relief. Among those, two profiles are distinguished: -

Managers: responsible for the actions of operators and requiring an overview of the service's solicitation and response capacity; Operators: dedicated to the engagement of the rescue teams.

For emergency assistance, an online decision-support tree assists the operators to advise applicants, categorize the requests, and send the appropriate team to the scene of the rescue request via ADAGIO.

Figure 11: A decision-support tree used by the rescue service

17


4.2 Emergency Service Triggering Process The emergency service triggering process can be summarized by the following phases: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Routing the phone call Processing the call Qualification of the alert Decision to send assistance Definition of the rescue team Allocation of the appliance(s) Transmission of the order of departure to the unit(s) concerned Appliance(s) departure Follow-up of the intervention Drafting of the intervention report

The work of this thesis focuses on the modelling and an optimization proposition of the sixth point.

4.2.1 Qualification of an Emergency Request All requests for relief are not characterized by the same level of emergency. The least critical requests can and are sometimes handled by teams that are not qualified by the shortest arrival time that the service can offer. The qualification of an emergency request, when taking an appeal, affects a ‘reason code’ to this request. For example, for the code 301 corresponding to ‘Sick person in public area’, it is dispatch in priority, an ambulance armed with three fire-fighters. There are currently about 180 reason codes categorized into nine families: fire; accidents; victim assistance; assistance to people; animals; water, gas and electricity; goods protection; pollution; and reconnaissance– research. For each reason code, either the sending of one or more means or the flip-flop of the request to another service competent to respond (police for example) is predefined. After a first glance, the emergency requests can be categorized as follows: -

Requests requiring an immediate and optimal response; Requests requiring an immediate dispatch of a rescue team but providing flexibility in terms of arrival time; Requests for reinforcement; Requests processed in the ‘load-shedding’ mode; Requests not handled by the fire brigade.

18

Analysis of an Emergency Response System A glimpse of the emergency response grid may help in understanding the fire and rescue service logic. Tableau 1: An overview of the emergency response grid

Reason Code

111

Label

Detachment

Search if Resource is Missing

Precursor

Fire

1 fire engine 1 fire engine (with 1 head of guard) 1 aerial ladder (with 1 positive-pressure ventilator)

1 head of guard or 1 duty officer 1 aerial ladder 1 positive-pressure ventilator

P15: duty officer

1 non-medical means of transport with ‘semi-automatic defibrillator’

P1: miscellaneous intervention vehicle P2: aerial ladder P3: special engine

300

Vital distress

1 victim assistance appliance

351

Sick person in a private place (e.g. at home)

1 victim assistance appliance

621

Materials threatening to fall

1 miscellaneous intervention vehicle

4.2.1.1 Requests for Immediate and Optimal Response Some requests must be answered as soon as possible for the service. The requests for such service requirements include, for example: -

Fire (reason code: 1##); Road accidents (reason code: 2##); Victim assistance (reason code: 3##), subdivided into different procedures, of which those requiring an immediate and optimal response correspond to: 1. Red Procedure: The call evokes obvious vital distress6. The operator immediately triggers the dispatch of a first-aid device and informs the medical coordination directly. The coordinating physician decides whether or not to also send a medical team. 2. Orange Procedure: The call highlights some elements that indicate a vital distress. It immediately triggers the dispatch of a means and switches the call to the coordinating physician.

4.2.1.2 Requests Requiring an Immediate Team Dispatch but Providing Some Flexibility in Terms of Arrival Time These requests for relief leave a margin of manoeuvre for the preservation of the operational coverage and concretely allow the selection of the means for relief characterized by a longer delay of presentation than the service would be able to offer. The requests that are subject to this flexibility include, for example: -

Victim assistance (reason code: 3##) • White procedure: Request without potential or obvious vital distress suspected during the call.

5

P1: precursor of first level Cardiac arrest, high-rise fall, gun wound, thoraco-abdominal wound, incarcerated patient, road accident with important kinetic event with multiple potential victims, etc. 6

19

Analysis of an Emergency Response System It is foreseeable that the manager of the operational centre would like to be able to define the different margins of manoeuvre in terms of acceptable arrival times for different reason codes. It will also allow the operator to: -

Preserve the operational coverage, thus enlisting a more distant team (pre-selected by default); or Force the sending of the appliance offering the optimal response time for the specific cases.

4.2.1.3 Reinforcement Requests A request for means by a first team at the place of a request for relief may be considered: •

•

Critical—for example, a request for additional means following the discovery of a fire in housing by a first team initially dispatched for suspicious smoke. or Providing a room of manoeuvre in terms of the time required to dispatch the means needed. For example, a request for relief teams for a fire already controlled by the fire and rescue service.

The reinforcement requests are typically managed at the level of a decision-making body called the operational monitoring centre (see Page 17) responsible for a ‘grouping’ (subdivision of a third of the fire brigade jurisdiction) and at the medical coordination centre (see page 17). The decision-making body may wish for a system that offers various unit options to dispatch, each characterized by the resulting level of coverage and ideally its cartographic representation on the road network.

4.2.1.4 Requests Processed in ‘Load-Shedding’ Mode The load-shedding is a decentralization of the responsibility for the management and the triggering of emergency means. It results in a queue of operations to be processed and managed by a team or a rescue centre. This mode of processing requests is characterized by greater flexibility in terms of the arrival time than has been mentioned in Section 4.2.1.2. This management mode is used when there occur societal, meteorological, or technological events where the demand exceeds the immediate response capacity of the service. This operating mode is also commonly followed by the miscellaneous intervention vehicles in charge of the operations characterized by a non-critical emergency level, such as: -

Water leak; Materials threatening to fall; Destruction of hymenoptera nests (bees, wasps); Etc.

4.2.1.5 Requests Not Processed by the Fire Brigade The call processing centre receives many calls on a daily basis which are not the responsibility of the emergency service. These calls are then redirected to the competent service: -

Appeal for medical or health reasons: • Green procedure: a call that does not immediately reveal any distress detectable by the operator but requires a medical evaluation. This type of call is switched to Centre 15 (emergency medical services).

20


4.3 Software Environment 4.3.1 Intervention Management Information System The fire brigade dispatches its rescue teams via the C# application named ADAGIO, developed by its own technicians. The data generated is stored within a Microsoft SQL Server database management system.

4.3.1.1 Intervention Data Maintained by the Rescue Service (Non-exhaustive list)

Intervention -

Address Reason code Code of the action taken by the rescue team

Victim -

Identity Address Transport or not and, if so, place of destination Physiological constants (pulse, ventilation, tension, etc.) Other paramedical observations (pupils, etc.) Medical history

Appliance -

Type of appliance Duty station of the appliance Affected staff Selection time Time of the different states that form an intervention: o Departed o On site o Left the scene of the intervention o Hospital transport o Hospital arrival o Available o Unavailable o Returned to the rescue centre

-

GPS position of the appliance with a refresh time of more or less 50 seconds (so far, untapped by the service)

4.3.2 Cartographic Information System The fire brigade has built and maintains its own mapping database.

4.3.2.1 Technologies Used The server-side operating system for cartographic information is a Linux CentOS distribution. This is a free distribution derived from the Red Hat Enterprise Linux (RHEL) distribution. The cartographic data is stored in a PostgreSQL database management system. This information is exploited and managed through ESRI and GeoConcept products. 21

Analysis of an Emergency Response System ESRI7 ESRI is currently the world leader in commercial geographic information systems solutions. The fire brigade uses ESRI products for: -

Fire hydrant management Forecasting studies Edition of a ‘tactical situation’ on rescue operations to define: • Location of an event • Type of event • Surface zone • Delineation of areas of responsibility • Location of water lances • Etc.

GeoConcept8 GeoConcept products are used for: -

Cartographic data entry, except for fire hydrants; The impressions of: o Operational maps o Wall maps o Any other kind of cartographic representation the service may need

For various operational management centres, rescue centres, and certain support services, the access and manipulation of the fire brigade's cartographic information is possible via an integrated Flex application within a Joomla web portal.

4.3.2.2 Sector Map Data The cartographic data have been enriched over the years with data from different sources: -

7 8

NAVTEK (points of interest) Regional and Interdepartmental Directorate for Environment and Energy (DRIEE) concerning flood information National Institute of Statistics and Economic Studies (INSEE) Water services Parisian Heating Company (CPCU)

http://www.esri.com http://www.geoconcept.com

22


Data Each road section of the jurisdiction is characterized by (non-exhaustive list): • • • • • •

• •

GPS coordinates of the start and end of the section Length of the section Value from 1 to 10 categorizing a road axis: motorway, national, departmental, etc. Four addresses delimiting the section Territorially competent rescue centre Flow direction: o two directions o one-way o prohibited to traffic Bus lane (category code) Speed limit

Data missing: • •

Passage eight Road width

Some map data properties (December 2016): • • • • •

138,000 registered road sections 766 sections of more than 500 metres 76 sections of more than one kilometre The longest section is 3.7 kilometres long The 10th-longest one is two kilometres long.

Use of Cartographic Information in Emergency Relief The dispatch of a team to a rescue request depends on a pre-calculation evaluating the transit times to each address of the fire brigade jurisdiction. In the database, this information has been recorded for the 10 rescue centres that should offer the shortest arrival delays. The geomatic department for computing these delays has considered: -

Peak hours: 8:00 AM to 10:00 AM and 5:00 PM to 8:00 PM Off-peak hours: remaining intervals

and applied a factor over the road speed limits as follows: - Peak hours: o Outside Paris: 𝑠𝑝𝑒𝑒𝑑 𝑙𝑖𝑚𝑖𝑡 × 0.4 o In Paris: 𝑠𝑝𝑒𝑒𝑑 𝑙𝑖𝑚𝑖𝑡 × 0.3 - Off-peak hours: o Outside Paris: 𝑠𝑝𝑒𝑒𝑑 𝑙𝑖𝑚𝑖𝑡 × 0.7 o In Paris: 𝑠𝑝𝑒𝑒𝑑 𝑙𝑖𝑚𝑖𝑡 × 0.6

23

5. Study of Existing Solutions for Viewing and Analysing Emergency Service Coverage Before presenting the proposed architecture, here is an overview of the products used by rescue services in France and abroad to measure and visualize their operational coverage.

5.1 Coverage Representation Maintained by the Paris Fire Brigade The coverage representation available to the decision-makers of the Paris Fire Brigade is limited to some predefined types of means (e.g. paramedic ambulance) or skills (e.g. victim assistance): Victim assistance

Paramedic ambulance

Fire engine

Medical unit

Figure 12: A current representation of the operational coverage used by the Paris Fire Brigade (Projection RGF93 / Lambert-93)

24

Study of Existing Solutions for Viewing and Analysing Emergency Service Coverage

5.2 Commercial Solution Used in France 5.2.1 OXIO9 5.2.1.1 AnalyseSDIS In France, to date, Oxio is the leader in software solutions for viewing and analysing operational coverage for fire and rescue services with their AnalyseSDIS product [1]. This is used by more than 40 fire and rescue departments. The solution was born in 2005 on the occasion of a pilot project for the benefit of the Saône-etLoire Fire and Rescue Department [11].

Figure 13: The OXIO AnalySDIS solution

GeoQlik10 AnalyseSDIS uses the GeoQlik mapping tool for its cartographic representations. GeoQlick relies on the Aigle cartographic engine of Business Geografic 11. Business Geografic is a provider of analytical solutions and geographic information systems.

5.3 Commercial Solutions Used Abroad 5.3.1 ORH12 ORH's software and services include: -

Expertise to answer the issues of annual resource allocation planning. Decision-support software solutions for real-time reallocation of resources. The ability to replay an event with different means in order to assess the impact on operational coverage and quantify the resulting response quality. Figure 14: A representation of the coverage by ORH

ORH has worked with 24 UK emergency services (fire departments and paramedical services), including the London Fire Brigade, but also with some rescue services in the United States of America, Canada, Sweden (Stockholm and Gothenburg), Qatar, and Australia.

9

http://www.oxio.fr https://www.geoqlik.com 11 https://www.business-geografic.com 12 http://www.orhltd.com 10

25


5.3.2 DECCAN13 DECCAN offers several software solutions for the management of the real-time operations of fire and rescue services as well as for their planning needs. Several major rescue services in USA and Canada have subscribed to their offer. To name but a few, these include the New York City Fire Department, the Los Angeles Fire Department, the San Francisco Fire Department, the Toronto Fire Services, and the Fire Department of Montreal.

5.3.2.1 ADAM ADAM (Apparatus Deployment Analysis Module) is a modelling tool used to answer the question ‘What if?’. Based on intervention historical data and cartographic data, it allows estimating the impact of resource allocation changes on the service response times, the level of availability of the service, the visualization of deployment plans by heat maps, and the comparison of alternative deployment scenarios.

Figure 15: The ADAM modelling tool

5.3.2.2 LiveMUM LiveMUM (Live Move-Up Module) is a real-time operational module that provides emergency dispatchers with instant, optimal move-up recommendations.

Figure 16: LiveMUM Module 14

5.3.3 FirstWatch

FirstWatch offers a panel of web services to turn near real-time raw data into meaningful information to help public service personnel in charge of emergency relief, fire, and law enforcement, as well as improve situational awareness and operational performance. Their services range from call centre activity monitoring to the follow-up and measurement of staff, rescue units, and rescue centres’ burden. FirstWatch services are currently being used by public services in 35 states and provinces of the US.

13 14

Figure 17: An example of a FirstWatch dashboard

http://www.deccanintl.com/ https://www.firstwatch.net/

26


5.3.4 Intermedix15 Intermedix offers several software products for emergency services, including a suite called Optima Product Suite, which comprises two products: Optima Predict and Optima Live. Optima Predict is intended for the analysis, modelling, and simulation of emergency scenarios.

Figure 18: The product Optima Predict

Optima Live is a dynamic tool for monitoring real-time resources and recommending reallocation in order to maintain the service coverage.

Figure 19: The product Optima Live

It should be noted that the majority of the services mentioned above are consumers of ESRI products. This overview of the operational response measurement systems highlights that the resource allocation information systems seem to be dissociated from the measurement and visualization systems of coverage. When looking for optimal resource allocation, these two systems must be linked so that the allocation phase can take into account the coverage information and so that the selection will not only be the result of static engagement patterns or the operator’s understanding of the measurements available. The reason the choice of open-source technologies has been made, beyond the technical interest of such work, is that it follows the institution's desire to retain some independence and control of its information system, specifically when it comes to the emergency service core activity.

15

https://www.intermedix.com/

27

6. Definition of the Target System From the ‘qualification of an emergency request’ described in § 4.2.1, we end up with three types of allocations: -

Critical allocation—demand requiring an immediate and optimal response. Allocation on request for relief with a margin of manoeuvre in terms of arrival time. Allocation in load-shedding mode, decentralization of the allocation decision (see the definition below).

Sont des interventions From the emergency engagement process discussed in § 4.2, Points 5, 6, and 7 can be defined as follows: 5. Definition of the rescue team: a phase defining the means required to process the rescue request. For example, in the case of a ‘kitchen fire’, two ‘fire engines’ and one ‘aerial ladder’ must be engaged. 6. Allocation of the appliance(s): a phase defining which team(s) will be engaged. For example, for a ‘kitchen fire’ in the city of Vitry-sur-Seine (94) near Villejuif (94), it could allocate one ‘fire engine’ and one ‘aerial ladder’ from the Vitry-sur-Seine rescue centre, and one ‘fire engine’ from the Villejuif rescue centre. 7. Transmission of the order of departure to the unit(s) concerned: the phase where the departure order is sent via the telecommunication network to the team concerned. The degraded mode is an appropriate reduction of some detachments for some targeted reason codes. It ensures minimal operational coverage during occasional phenomena. The degraded mode remains centralized and is managed at the operational centre. The load-shedding mode is a decentralization of the dispatch decision of means to face a massive influx of the requests for relief consecutive to unusual events (societal, meteorological, technological, etc.). The loadshedding mode is associated with one or more defined alert patterns. It may concern all or part of the sector of the fire brigade. The load-shedding is handled at the level of the rescue centre, which creates a list of the interventions for its appliances that relate to the load-shedding mode. The following diagram proposes an improvement of the logic in place. However, this is not currently applicable mainly because of the inability of the current system: -

to assess the transit time of the appliances to assess the coverage of the service

The following work will therefore endeavour to formulate solutions for this.

28

Definition of the Target System

6.1 Proposed Allocation Logic

Figure 20: Proposed decision tree for means allocation

29


6.2 Sketch of the Means Management Data Model We propose below a data model to support the logic that will allow the implementation of an optimal selection of means by taking into account the business rules and the evaluation of transit times. Entities and attributes are restricted to a minimum to understand the logic. The data scheme describing an emergency service structure is of course more consistent.

Figure 21: A proposal for a data model for the management of resources

Conventions of the previous entity–association diagram: - REF: reference - FK: foreign key

30

Definition of the Target System An example of the table contents can be found in Appendix 2: An example of the data content of the data model in § 6.2

Adaptation of the Composite Design Pattern for an Appliance Allocation System From the structure previously defined, the use of the composite design pattern for the allocation process of means could be considered since an allocation can be composed as follows: -

-

an allocation consisting of: o one or more module(s) consisting of: • several appliances o one or more appliance(s) or one or more module(s) consisting of: o several appliances or one or more appliance(s)

The composite pattern [12] is used when we want to represent a tree or to hide the differences between a composite object and a singular object of a similar nature. The composite pattern proposes the definition of a unified interface for singular and composite objects.

Figure 22: Composite pattern design

Figure 23: Adaptation to the allocation of resources

Strengths: • • •

Having a structured tree of objects. Encapsulation of the heterogeneity of simple and composite objects. Facilitates the integration of new classes of simple or composite objects.

Weaknesses: • •

Requires dynamic control for specific constraints when inserting objects within a composite. The generalization of the interface component can lead to the declaration of the methods that do not make sense for simple objects.

31


6.3 Computation and Representation of Emergency Service Coverage For an appliance allocation optimization, more accurate measures should be used than the underlying ones of the coverage representation presented in Section 5.1. A more complex but fairer representation must be intimately linked to the road network because they are linked to the postal addresses representing: -

Buildings (building = population) Outdoor areas (idem) Roads are as well populated by pedestrians and motorists.

This representation could be translated visually as follows:

Figure 24: An example of a better representation of the service coverage around the Eiffel Tower (Projection EPSG 4326 - WGS84)

Among the tasks to be undertaken, one of them will consist in recovering and measuring the roads covered within a defined period of time. To assign a population to road segments, government data such as census data could be used. But to obtain more relevant measures, the exploitation of anonymous data from mobile operators should be considered (see [13]). The work that follows will not go so far but these practices should be known for further work.

32


6.4 Service The service to design will have to communicate with an appliance dispatch application. However, it will also have to be thought of in a way that will facilitate the future evolutions and services to be consumed by various web applications, such as a coverage visualization application of the emergency service. As mentioned in § 2.1.3, two types of information have to be distinguished to measure the quality of service: -

immediate response response capacity

The data structure below is intended to maintain information corresponding to the response capacity that must be distinguished from the immediate response, of which an example is given in § 7.2.4.1.

6.4.1 Data Maintained The systematic calculation of coverage information when selecting a rescue team would result in a waste of resources. In order to have this information without needing to systematically recalculate it, it would be more pertinent to create a table with the coverage information for each operational appliance.

6.4.1.1 Table with Coverage Information on the Geographic Information System Side

-

unique identifier of the record identifier of the appliance identifier specifying the driving behaviour of this type of appliance; identifier of the edge from the cartographic database corresponding to where the appliance is located list of road segment identifiers covered by this appliance within the defined period of time during system initialization availability of the appliance true if qualified for victim assistance true if qualified for fire true if it is a medical unit.

Adding to the road segments table, there must be a column accounting for the number of engines covering each segment within a defined period of time for the concerned services.

33


6.4.1.2 Table of Road Segments Columns to add to the ways table (see Appendix 3: pgRouting ‘Ways’ Table Columns) of pgRouting that will be introduced later: -

-

-

native columns of the pgRouting ways table number of available appliances capable of responding to a victim assistance request within the time limit defined for this road segment number of available appliances capable of responding to a fire emergency request within the time limit defined for this road segment number of available medical teams capable of responding within the time limit defined for this road segment etc.

As soon as a rescue team becomes available or unavailable, it will suffice to increment or decrement these counters (SAV, INC, AR) related to the road segments covered by the team to keep the coverage information up to date.

6.4.2 Coverage Constant The proposed architecture requires the declaration of a time limit constant for the coverage measures to be taken into account when the system is initialized. Since this delay is used for the service coverage calculations, it cannot be dynamically defined when the queries are processed.

6.4.3 Client-side Query The client-side query must be issued from the appliance dispatch application. It could consist of the following parameters: -

id: unique identifier of the query latitude: latitude of the emergency request longitude: longitude of the emergency request FK_Appliance_ID: unique identifier of the appliance for which to evaluate an arrival time distance_search_area: search radius in kilometres (in order to limit the loading time of the road

graph and thus reduce the response time of the query; see § 7.2.4.1) alternatives: number of alternatives to be returned based on means or competency image: return or not an image of the resulting cover bounding_box_x: east–west distance in metres of the bounding box defining the geometries to be returned bounding_box_y: north–south distance in metres of the bounding box defining the geometries to be returned services: categories of the coverage measures to be returned (e.g. victim assistance, medical unit, etc.)

34

Definition of the Target System An example of a query (issued from the appliance dispatch application) in the JSON format: { "id":1, "latitude": 48.860974, "longitude": 2.367221, "FK_Appliance_ID": [[1,4,6,...], [120,121,123,...]], "distance_search_area": [3,6,12], "alternatives": [3,3], "image": true, "bounding_box_x": 1000, "bounding_box_y": 1000, "services": ["SAV", "INC"] }

The ‘...’ corresponds to a voluntary omission of redundant parts of the message without great interest for the reader.

6.4.4 Response of the Service Following the query reception, the service will return information related to the most relevant appliances with the operational coverage measures: -

id: unique identifier of the initial query medium: container of options relating to a type of appliance or competence sequence: sequence number of the desired means options: container of different options option: container of an option FK_Appliance_ID: unique identifier of the appliance delay: estimated arrival time of the appliance in seconds image: image representing the resulting coverage following the dispatch of the appliance SAV: resulting coverage index for the victim assistance response INC: resulting coverage index for the fire response AR: resulting coverage index for medical units, specified only if affected (it does not appear in the

following example since it is not affected) An example of a service response in the JSON format: { "id": 1, "medium": { "sequence": 1, "options": { "option": { "FK_Appliance_ID": 24, "delay": 92, "image": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBwYI...", "SAV": 93, "INC": 78 }, "option": { "FK_Appliance_ID": 26, "delay": 132, "SAV": 95, "INC": 78 }, ...

35

Definition of the Target System } }, "medium": { "sequence": 2, "options": { "option": { "FK_Appliance_ID": 132, "delay": 102, "image": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBwYI...", "SAV": 93, "INC": 72 }, "option": { "FK_Appliance_ID": 133, "delay": 145, "SAV": 95, "INC": 74 }, ... } } }

The omission of the image parameter beyond the appliance offering the shortest delay is voluntary for reasons of bandwidth savings. This information, although not transmitted to the appliance dispatch application, could remain temporarily in memory and would only be transmitted following the operator's consultation of another option. The data to be temporarily stored on the geographic information system side could consist of: -

-

id: unique identifier of the initial query time: time of the initial request to rule on data expiration type: type of appliance or competence name: wording of the appliance or competence geom: geometries of the bounding box set to be returned quantity: resulting coverage of the road segments within the bounding box set following the

dispatch of the appliance for each service affected

36


6.4.5 Future Developments The fact that the GPS information relating to emergency vehicles is currently unavailable simplifies matters considerably. All that remains to be considered is that as soon as a team changes its status to ‘available’, the team is considered to be located at its rescue centre. The fact that the speeds of road sections at this time only correspond to simple ratios calculated from the speed limit by time slots—peak and off-peak hours—further simplifies the task.

6.4.5.1 Traffic Information When it is possible to assign weights on the road graph corresponding to the traffic congestion, a re-evaluation of coverage information every five minutes should a priori remain relevant enough. The computation time of the coverage has to be assessed in order to revise the coverage measures if necessary. Different services capable of providing traffic information are introduced in Chapter 9.

6.4.5.2 GPS Information When the GPS information of the emergency appliances becomes accessible and a willingness to take it into account is clearly expressed by the decision-makers, the system can be expected to have a high reactivity for its coverage representation, taking into account the changes in appliance location resulting in a continuous process and dissemination of information. The reliance on a relational database management system in such a context may not be the best option. To overcome some difficulties, a PostgreSQL/Redis architecture (or PostgreSQL/Memcached) could be considered. Here, PostgreSQL will continue to maintain and distribute its cartographic information and Redis will be responsible for counting operations. A publish/subscribe model will then be responsible for broadcasting information to various client applications. Publish/Subscribe Pattern The publish/subscribe model is a message exchange model for decoupling application broadcasting information from applications that consume this information. Redis Redis differs from more traditional database management systems by relying on the system's RAM as its primary storage medium and reserves the disk for data requiring persistence. To take advantage of the Redis benefits, there is no need to migrate all your data under the Redis system. It can simply be used to meet certain needs to which the database system is unable to respond or for which it would charge an unacceptable system load.

37

7. Selection of an Open-Source Solution for Exploitation of Geographic Information System Data For the intended purpose, a question regarding the choice of a route calculation system arises.

7.1 Investigation of Route Computation Solutions The route computation issue is far from new and different open-source software solutions are actively maintained. After a period of investigation through search engines and forums, questioning domain specialists, and the unavoidable OpenStreetMap Wiki, one might end up identifying the following frameworks and libraries:

7.1.1 GraphHopper GraphHopper [14] supports several routing algorithms such as Dijkstra and A* as well as their bidirectional variants. It also offers the implementation of a contraction hierarchies method. The mode using it is called the speed mode and the one not using it is called the flexible mode. The speed mode offers considerably reduced response times. The disadvantage of the speed mode is that it allows only the use of predefined profiles and requires a preliminary treatment that is not negligible in terms of time and resources. It also makes the use of some functions very complex or even impossible. GraphHopper also has a hybrid mode that uses the search algorithm A* and some landmarks for its operation. It also requires pre-processing but offers more flexibility for the weighting changes of the segments of the graph. It therefore makes it possible to account for the evolution of traffic data. This hybrid mode remains slower than the speed mode but is still much faster and accounts for less RAM consumption than the flexible mode when running a query. Listed below are some features of GraphHopper: • • • • • •

It works on OpenStreetMap data (.osm, .xml, and .pbf) but can be adapted to our own dataset It provides a web API for Java and JavaScript clients Several profiles are pre-defined: car, bike, racing bike, mountain bike, foot, motorcycle, etc. It has the ability to define custom profiles when running queries (flexible mode and hybrid mode only) It can adjust the costs and restrictions (flexible mode and hybrid mode only) It offers proposals for the alternative routes (flexible mode and hybrid mode only)

7.1.2 OpenTripPlanner OpenTripPlanner [15] is a multi-modal16 trip planner. It depends on data in the OpenStreetMap and GTFS formats. It offers a REST API for journey planning as well as a JavaScript web-mapping service based on the Leaflet library.

7.1.3 OSRM (Open Source Routing Machine) OSRM [16] is a high-performance route engine designed to run on OpenStreetMap data. The services it provides are available via an HTTP API, a C++ library interface, or a NodeJs wrapper:

16

Multimodal: pour différents modes de transports

38

Selection of an Open-Source Solution for Exploitation of Geographic Information System Data • • • • • •

Nearest: snaps the coordinates to the street network and returns the nearest matches Route: finds the fastest route between different GPS coordinates Table: computes the duration of the fastest route between all pairs of the supplied coordinates Match: snaps noisy GPS traces to the road network in the most plausible way Trip: solves the travelling salesman problem using a greedy heuristic Tile: generates Mapbox Vector Tiles with internal routing metadata

7.1.4 pgRouting pgRouting [17] extends a PostGIS/PostgreSQL geospatial database to provide geospatial routing functionality. pgRouting will be introduced in detail in Section 7.2.4.

7.1.5 RoutingKit RoutingKit [9] is a C++ library developed at the Karlsruhe Institute of Technology in Germany that provides advanced route planning functionality. The most prominent component is an index-based data structure called (customizable) contraction hierarchy, which facilitates answering shortest-path queries within milliseconds or even less on datasets of continental size while ensuring flexibility of the weighting edges. One of the main design goals of the RoutingKit is to make recent research results easily accessible to people developing route-planning applications.

7.1.6 Routino Routino [18] is an application for finding the shortest path between two positions in time or distance on OpenStreetMap data. It relies on the Qt framework. In order to reduce its query-execution time, Routino requires a pre-processing of the graph. It offers the possibility taking into account the different modes of transport and speed limits, turn restrictions, tonnages, heights, widths, and obstacles. The processing of the input file is controlled by a configuration file that determines the information to use.

7.1.7 SpatiaLite SpatiaLite [19] is a library intended to extend the SQLite core to support full-fledged Spatial SQL capabilities. SQLite is intrinsically simple and lightweight: • • •

A single lightweight library implementing the full SQL engine Standard SQL implementation: almost complete SQL-92 A whole database simply corresponds to a single monolithic file (no size limits)

The combination of SQLite + SpatiaLite may be considered an alternative to a PostgreSQL + PostGIS system.

39

Selection of an Open-Source Solution for Exploitation of Geographic Information System Data

7.1.8 Tempus Tempus [20] is a framework for the development, implementation, and testing of diverse route-planning algorithms. It offers a tool for data integration into the PostgreSQL/PostGIS database. It allows the evaluation of different modes of transport (car, public transport, car pooling, bike, etc.). Some features of Tempus are listed below: • • • • •

Builds on the C++ Boost Graph Library Exposes an API through FastCGI communication protocol Provides a QGIS client for connection with a Tempus Web Processing Service (WPS) server Allows the loading of OpenStreetMap data from shapefiles, .osm files, and GTFS files, and points of interest from shapefiles and CSV files Provides an API for Python queries

7.1.9 Valhalla Valhalla [21] comprises a routing engine and libraries for use with OpenStreetMap data. Here are some of its features: • • • • •

A tiled hierarchical data structure to limit memory footprint and speed up query response Dynamic, runtime costing of edges and vertices within the graph via plug-in architecture. Should allow for customization and alternate route generation Multi-modal and time-based routes Isochrones computation Resolution of the travelling salesman problem

40


7.1.10 Comparative Table It may be interesting to make a first comparison of these technologies according to the following criteria: the language used, the use or not of a PostgreSQL system (technology storing the cartographic information of the fire brigade), the existence of documentation, the license, and some popularity indices via Google searches: GraphHopper

OpenTripPlanner

OSRM

Language(s) Relies on PostgreSQL and PostGIS

Java No

Java No

C++ No

Documentation Open Source

Yes Yes

Yes Yes

Yes Yes

Licence

Apache License 2.0 GNU LGPL Google popularity ratings: ‘name’ +

BSD 2-clause Simplified

‘OpenStreetMap’ ‘OpenStreetMap’ ‘workshop’

33,200 6,060

12,500 1,270

38,900 15,700

‘OpenStreetMap’ ‘tutorial’ ‘OpenStreetMap’ ‘catchment area’

4,690 44

1,520 43

7,180 43

pgRouting

RoutingKit

Routino

C/C++ Yes

C++ No

C No

Yes Yes

Yes Yes

Yes Yes

Language(s) Relies on PostgreSQL and PostGIS Documentation Open Source Licence

GNU GPLv2, Boost, MIT BSD 2-clause simplified Google popularity ratings: ‘name’ +

GNU Affero GPLv3

‘OpenStreetMap’ ‘OpenStreetMap’ ‘workshop’

12,700 2,100

9 0

112,000 228


11,300 677

0 0

781 25

SpatiaLite

Tempus

Valhalla

Language(s) Relies on PostgreSQL and PostGIS

C No

C++ Yes

C++ No

Documentation Open Source

Yes Yes

Yes Yes

Yes Yes

MPL tri-license MIT Google popularity ratings: ‘name’ +

MIT

Licence ‘OpenStreetMap’ ‘OpenStreetMap’ ‘workshop’

16,800 5,110

Result not relevant Result not relevant

23,700 6,770


17,500 682

Result not relevant Result not relevant

4,560 151

The previous investigation enabled us to accumulate a lot of information and to develop a certain culture of the field. In particular, this allowed identifying some differences and needs to which they try to respond with various technologies and philosophies.

41


7.2 Choosing a Framework and a Philosophy: Performance versus Flexibility With the route computation from the database, the system computes the pathway by taking into account the traffic restrictions (speed limits, traffic direction, vehicle height, tonnage limit) as and when required. The advantage of a system based on a database is that the system response will systematically use the most recent data maintained by the system, whether the traffic conditions are foreseen (e.g. pavement work, traffic restriction during peak hours) or not (roadblock following a traffic accident leading to traffic congestion). The disadvantage of this model is that the continuous modification of data excludes any query optimization possibilities that enjoy the benefits of a pre-processing phase. Historically, the first route calculations were carried out in a linear manner, segment by segment, from the departure address to the destination. In order to improve this performance, algorithms were implemented for bidirectional execution (execution from both the starting point and the end point) and parallelizing the tasks (using multi-core architectures). More recently, solutions have been proposed that allow drastic gains on the execution time of queries. The latter rely on a pre-processing of the network reducing the number of segments that the search algorithm will have to consider in order to reach an optimal response. Most of the proprietary open-source solutions now rely on a contraction hierarchies approach to improve their performance. Depending on the size of the network, the pre-processing required for these architectures may take several hours. Therefore, there is a choice between data flexibility and performance. The studies conducted by Boundless Spatial [22] and [23], review five of the most commonly used opensource solutions for route computation: • • • • •

Open-Source Routing Machine Mapzen Valhalla OpenTripPlanner GraphHopper pgRouting

They find that with the exception of pgRouting, all these solutions use a contraction hierarchies method to increase their performance, and offer REST or SOAP programming interfaces to facilitate their integration. They also point out that for these solutions using a contraction hierarchies method, there is little, if any, difference in terms of performance and integrability: ‘The focus on performance resulted in these projects supporting fixed data models with little or no tools for adding custom data’ [22]. From this point of view, pgRouting stands as an outsider. PgRouting is the only tool that favours data flexibility over performance since it currently does not have a pre-treatment process. Therefore, for a structure willing to get the results, and taking into account the latest updates, pgRouting seems to be the preferred solution; otherwise, for operations restricted to route calculation, other solutions seem preferable to benefit from a high response speed and a system load reduction.

42

Figure 25: The gap dividing the two philosophies supported by these frameworks [23]

Selection of an Open-Source Solution for Exploitation of Geographic Information System Data It should be also noted that pgRouting, as it works on a database management system, inherits the databases’ ACID properties: atomicity, consistency, isolation, and durability.

7.2.1 Expected Functionality This project is much more than a simple route computation service. Hence, it requires operations such as: • • • •

A search for the optimal routes from one place to several other locations (from various rescue teams to one emergency request location); The calculation and recovery of the road segments covered by the service under a given time limit; Customization of the speeds related to the road segments; Customization of the speeds according to the emergency vehicles.

These operations can all result from pgRouting functions relatively easily. Its extensive documentation and the fact that mapping data of the organization is already maintained under a PostgreSQL database management system make the choice obvious (pgRouting is a PostgreSQL extension using the spatial functionalities of the PostGIS extension). There are other open-source geospatial database management systems such as MongoDB or Neo4j. However, PostgreSQL with PostGIS is a well-maintained database management system suitable for a multitude of scenarios [24], and it is the one offering the most spatial features. MongoDB is almost as fast as PostgreSQL in some cases, with good performances in k-Nearest Neighbour scenarios, and it is well suited to horizontal scalability (system scalability capacity facing the increase of the number of connections). But many spatial functionalities relating to networks are lacking. Neo4j would offer low performance in comparison but would nevertheless have a very good implementation of the shortest-path computation.

7.2.2 What Is a Spatial Database? PostGIS transforms PostgreSQL into a spatial database system by adding: •

•

•

Spatial types: The basic spatial types defined by the Open Geospatial Consortium (OGC) are GEOMETRY, POINT, LINESTRING, LINEARRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON, and GEOMETRYCOLLECTION. Spatial indexes: Spatial databases use different indexes from traditional B-trees because they are unsuitable for cartographic data. Indexing within a spatial database follows the logic answering the question ‘What objects are located within such a bounding box?’. Spatial functions: A spatial database provides functions allowing the analysis of geometrical components, determining the relations between geometries and the manipulation of geometries.

7.2.3 Introduction to PostGIS This project requires some operations on the geometric or geographical object. PostGIS, with its battery of functionalities [25], largely meets these needs. It is also interesting to note that PostGIS draws the attention of the cartographic section of the fire brigade. Below are some functionalities offered by PostGIS: • • •

Conversion of geometries into different formats (ST_Transform); Merging of geometries (ST_Union, ST_Collect, ST_linemerge); Recovery of geometries’ nearby GPS coordinates (see § 7.2.4.4); 43

Selection of an Open-Source Solution for Exploitation of Geographic Information System Data • •

Selection of geometries within a given area (ST_dwithin); Retrieving geometries directly in the GeoJSON17 format (ST_AsGeoJSON).

7.2.3.1 Initial Motivations of PostGIS In the year 2000, PostgreSQL already offered some geometric types that were the fruit of academic research. However, these were still too limited to meet the real needs of a geographic information system. At the time, Refraction Research conducted the geographic data management operations for the state of British Columbia in Canada [26], [27]. Their work, realized from flat files, became very laborious when the data began to evolve regularly. In such a situation, a database would have made things much simpler. In 2001, the Refraction Research team took advantage of a post-budget inactivity period to build a spatial database to address this issue. An inherent ability of PostgreSQL is its simplicity for adding custom types and its generic indexing structure allowing the construction of indexes on more or less anything. In addition, PostgreSQL has extensive documentation and some explicit examples within its ‘contrib’ directory. All of these is why the team chose this database management system. Under proprietary technology, only Illustra (acquired by Informix in 1997) allowed such ease of extension. This is far from a coincidence since Illustra is the result of the evolution of a fork of the 1992 Postgres, University of California Berkeley, which supported the SQL language (Postgres only supported the SQL language since 1994, following replacement of the POSTQUEL query language) [28]. In the end, the performances observed during the implementation of geometric types under the first version of PostGIS exceeded the expectations of the team. When Version 4.1 of MySQL natively supported geometric types, the PostGIS team was interested in its implementation. However, its structural logic only reinforced their initial decision about PostgreSQL. The achievement of PostGIS 0.1 took less than a month. Achieving ‘MyGIS’ 0.1 would have taken a lot longer; in fact, it may never have seen the light of day.

17

The GeoJSON is a geospatial dataset encoding format in the JSON format

44


7.2.4 pgRouting pgRouting is a PostGIS/PostgreSQL geospatial database extension that adds routing and other networkspecific analysis capabilities. pgRouting is the successor of pgDijkstra designed by Sylvain Pasche 18 whose features were extended by the Japanese company Orkney and renamed pgRouting. The project is currently supported and maintained by Georepublic19, iMaptools20, and a broad user community. pgRouting as a PostgreSQL extension must deal with these database-specific rules and constraints.

7.2.4.1 First Contact with pgRouting In order to better understand the value of pgRouting, it may be interesting to highlight an example of using its pgr_drivingDistance() function to evaluate the immediate response of the service. For this example (see Appendix 4: pgRouting Query to Retrieve the Immediate Response the Service Can Offer), we consider the following: -

A delay of 45 seconds between the call acceptance and the departure of a rescue team; The emergency vehicles follow the direction of the traffic lanes; The speed of the emergency vehicles is equivalent to 50% of the speed limit of the traffic lanes; Each rescue centre has an available appliance able to meet this type of request.

With these constraints and the pgr_drivingDistance() function, we get a result of the following form: gid

source

source_agg_cost

target

target_agg_cost

1

92029

103736

168.968404786

121499

170.817493188

169.892948987

0102000020E6100000020…

2

206909

179304

73.0418248621

197414

71.6981474708

72.3699861664

0102000020E6100000020…

3

199041

147211

84.6918933698

188931

86.3971606329

85.5445270014

0102000020E6100000020…

…

…

…

…

…

…

…

…

18

https://www.linkedin.com/in/sylvainpasche https://georepublic.info/en/ 20 http://imaptools.com/ 19

45

edge_average_transit_time

geom

Selection of an Open-Source Solution for Exploitation of Geographic Information System Data This result, once exploited by a JavaScript library within a web browser or by software such as QGIS (using a graded colour palette), will offer a representation of the road graph of the jurisdiction that might look like this:

Figure 26: A pgRouting request result of the immediate response information over Paris (Projection EPSG 4326 WGS84)

The execution time of this request for our architecture and the Ile-de-France OpenStreetMap data was 7.2 seconds. Notice that the gain in precision for the coverage information in comparison to the current representation (see § 5.1) is obvious.

46


7.2.4.2 Functioning of pgRouting For its operation, this framework exploits the data from a table typically called ‘ways’ 21 , which stores information describing a road graph.

source

target

cost

reverse_cost

3

6

40

38

3

8

25

-25

6

8

-1

32

Figure 17: An overview of data held within a ‘ways’ table required by pgRouting algorithms

Upon calling a pgRouting function, the road graph is loaded into an adjacency list structure via an adjacency_list object of the Boost Graph Library. An adjacency_list is one of the three containers available within this library for defining a graph. The pgRouting framework works as follows [29]: 1. The client connects to the database; 2. The client sends a query; 3. The graph is built and loaded into the database system (the higher the number of segments, the longer the load will be); 4. Once loaded, the query is executed on this representation of the graph; 5. The result is returned to the client; 6. The client disconnects from the database.

Figure 27: The logic of pgRouting presented by C. V. Vergara Castillo at the FOSS4G 2015 conference in Seoul (South Korea)

Unfortunately, if we want to re-execute the same query in the next second, under the current version of pgRouting, the same process will be repeated. This loading time must therefore be assessed.

21

For a complete list of the attributes of the pgRouting ‘ways’ table, see Appendix 3: pgRouting ‘Ways’ Table Columns.

47


7.2.4.3 Graph Loading Time Assessment The assessment of the loading time of the graph can be carried out by starting a shortest path search to traverse a single segment of the graph in order to restrict the execution of the search algorithm to a single cycle. Search request for the shortest path from one end to the other of the ‘Cité de la roquette Paris 11th’ road segment: SELECT q.seq, q.node, q.edge, q.cost, q.agg_cost, w.length_m, w.the_geom As geom FROM pgr_dijkstra( -- Returns the shortest path using the Dijkstra algorithm 'SELECT gid As id, source, target, cost_s As cost, reverse_cost FROM ways', -- Retrieving the necessary information from the 'ways' table 2156, -- Input node of the impasse 'City of the Roquette Paris 11th' 313321, -- Dead end node of impasse 'City of the Roquette Paris 11th' true) As q LEFT JOIN ways AS w ON q.edge = w.gid; -- Join to retrieve the geometric elements

For our architecture22 and road data (Ile-de-France OpenStreetMap data), we get a completion time of two seconds for such a query.

Figure 28: The running time and query result with QGIS

7.2.4.4 Retrieving Source and Destination Nodes for Queries The nodes of the road graph stored in the database will not match each address of the jurisdiction area. However, pgRouting relies on these nodes for its route calculations. Thus, for a calculation of the shortest path or a road network coverage calculation, the nodes near the GPS coordinates to be taken into account must be searched. This can be done by using the ST_Distance function of PostGIS applied to the ways_vertices_pgr table of pgRouting referencing all the nodes of the graph. SELECT * FROM ways_vertices_pgr ORDER BY ST_Distance( ST_GeomFromText( 'POINT(2.3745372 48.8659052)', 4326 ), the_geom ) ASC LIMIT 1;

Figure 29: An example of a search query for the nearest node (blue dot) of an address (red dot) near the street corner ‘avenue Parmentier, avenue de la République Paris 11e’

In the previous representation, the red dot corresponds to the GPS coordinates of an address. The blue dot is the nearest node found by the PostGIS function within the ways_vertices_pgr table.

22

Development environment: • Hardware: Intel i3 2.10GHz processor, 16GB RAM, 240GB SSD, 27GB of swap space. (To modify the swap space see [30]) • Software: Linux CentOS 7 operating system, XFCE 4 desktop environment, pgAdmin3, QGIS 2.14 + DB Manager, PostgreSQL 9.6, PostGIS 2.3.2, pgRouting 2.3.2

48


7.2.4.5 Improving pgRouting Performance What does not work: • •

The indexes do not come into play in the execution of pgRouting algorithms. So, they cannot be used to speed up the query execution. The increase in the size of the shared buffers as well as of the cache does not bring any improvement since, for each request, pgRouting reloads (at this time) the graph in memory.

Shared buffers: PostgreSQL uses the operating system cache as well as its own cache. Both can be useful depending on our use of the database. The cache of the operating system is very fast but very basic: Old data is overwritten by more recent data. This is useful for very versatile query results. The PostgreSQL cache is slower (but remains faster than the hard drive) and maintains counters for the most commonly used data. This is useful in case of recurring results. •

A greater number of processor units will not improve performance either since the pgRouting algorithms currently do not exploit the multithreading processor capabilities. In other words, current algorithms use only one core (that is, one logical unit).

Figure 30: Processor monitoring when executing a pgr_drivingDistance() query

Sustainable Axes of Performance Improvement: • • • •

Pay attention to the writing of SQL queries: Follow the general best practices of query construction. Use a solid-state drive (SSD) for the map data tables. Reuse the results of previous queries when possible. Limit the number of road segments to be taken into account by pgRouting filtering them as with a ST_Buffer() PostGIS function.

For example, if we are looking for the appliance arrival times (in full hours) from the Paris 11th and Paris 4th rescue centres for a request for relief ‘rue de la Roquette, Paris 11’, by applying a filter over the road segments located at an Euclidian distance of 3 km from the request, the query should be as follows: SELECT start_vid As demande_de_secours, end_vid As centre_de_secours, CAST((agg_cost * (1/0.3) / 60) As INT) As delai_minutes, CAST((agg_cost * (1/0.3)) As INT) % 60 As delai_secondes FROM pgr_dijkstraCost( 'SELECT gid As id, source, target, cost_s As cost, reverse_cost_s As reverse_cost, the_geom FROM ways WHERE ST_Within( the_geom, ST_Transform( ST_Buffer( ST_Transform( ST_SetSRID( ST_MakePoint(2.373764, 48.855033), -- GPS coordinates of the node at the intersection rue de la Roquette, city of rocket 4326 -- GPS coordinate system ),

49

Selection of an Open-Source Solution for Exploitation of Geographic Information System Data 3857 -- Spatial coordinate system popular on the web: Google, OpenStreetMap ), 3000 -- Restriction of recovery of segments of the graph at 3 km around the place of the emergency request ), 4326 -- GPS coordinate system ) )', array[193760,10085], -- Nodes near the Paris 11 and Paris 4 rescue centres 2156, -- Node at the corner rue de la Roquette, cite de la Roquette TRUE) ORDER BY agg_cost ASC

With ST_SetRID, we set a spatial reference identifier in the EPSG:4326 format of a point defined previously with ST_MakePoint. The EPSG:4326 format from the International Association of Oil and Gas Producers is equivalent to the WGS84 reference system known as the GPS coordinate system. This coordinate system is then adapted to the standard used by OpenStreetMap: EPSG:3857 using ST_Transform. It is then used to define the radius of the desired search area using ST_Buffer (here set to 3 km). It is then possible to return to the GPS standard using ST_Transform to finally offer this information to ST_Within, which can then restrict the dataset to the geometries within the defined zone (radius of 3 km around the corner rue de la Roquette, cité de la Roquette Paris 11). With such a query, we eliminate the loading of many irrelevant road segments and get a response for our query in less than 100 milliseconds as opposed to two seconds if the entire Ile-de-France road network had to be loaded.

Figure 31: The execution time by filtering the elements within a 3-km radius

•

where possible, execute several queries in parallel:

We can turn to our advantage that pgRouting uses only one logical unit when we are looking at the same time to retrieve the results of several independent queries—for example, to obtain the coverage information of different categories of appliances: victim assistance, pumping machine, medical assistance, aerial ladder, etc.

50

Selection of an Open-Source Solution for Exploitation of Geographic Information System Data Let us reuse the query in Figure 26: A pgRouting request result of the immediate response information over Paris (Projection EPSG 4326 - WGS84), but this time with: -

Time in seconds

-

76 randomly selected source vertices for each sub-query; one to eight parallel queries executed through a C++ script (see Appendix 5: Minimalist PgRouting Query Performance Tests) using the POSIX thread library providing an API for thread manipulation and creation. To consolidate the result, the script was executed 30 times for the different numbers of threads and only the median times are represented below: 30 20 10 0 0

1

2

3

4 5 6 Number of threads/queries

7

8

9

Figure 32: The execution time to retrieve the immediate response information for one to eight categories of appliances

In comparison with Figure 30: Processor monitoring when executing a pgr_drivingDistance(), we observe here four logical units being consumed:

Figure 33: Processor usage when running in parallel 4 pgr_drivingDistance() queries

51


7.2.4.6 Outlook for the Future Version 3.0 of pgRouting pgRouting is currently in Version 2.4 and below is discussed the further improvements on which the developers of pgRouting are working on: • • • •

Review of the code to make it more understandable; Creation of internal libraries; Ability to keep the graph in memory in order to reuse it without having to load it again and again, and speed up the query execution times; Implementation of a graph contraction system.

The implementation of a multi-level architecture within pgRouting arouses a lot of interest among the developer community of this framework [31], [32], [33]. We can see (January 2017) within the osm2pgrouting source code (OpenStreetMap data integration tool to PostgreSQL database under a structure adapted to pgRouting), in the file .\src\prog_options.cpp [34], the existence of a multilevel option that is currently inactive: // Not used currently not_used_od_desc.add_options() ("threads,t", po::value()->default_value(false), "threads.") ("multimodal,m", po::value()->default_value(false), "multimodal.") ("multilevel,l", po::value()->default_value(false), "multilevel.") ;

It should also be noted that a first development aimed at a graph contraction has already been carried out within pgRouting. This implementation is intended for the moment to be a ‘flexible framework’ restricting itself to two operations: dead-end contraction and linear contraction. Dead-end contraction

Linear contraction

Figure 34: The first graph contraction in pgRouting

52

Selection of an Open-Source Solution for Exploitation of Geographic Information System Data For the initial graph on the left, the current function will construct the structure represented by the graph on the right. Initial graph

Representation obtained via pgr_contractGraph()

Figure 35: An example of the representation of an initial graph and its contracted form via pgr_contractGraph()

The syntax of the contraction function currently implemented and its result in the database are as follows: SELECT * FROM pgr_contractGraph( 'SELECT id, source, target, cost, reverse_cost FROM edge_table', ARRAY[1, 2]);

Figure 36: An example of a pgr_contractGraph() query and its result

7.2.4.7 Preparing Data in pgRouting Format To use the pgRouting algorithms, the data in the database has to follow a specific structure. Several tools can be used to reach such a format. For OpenStreetMap data, the most trivial way is probably by osm2pgrouting, developed and maintained by the pgRouting developers. This tool requires some preliminary precautions. The March 2017 version of osm2pgrouting requires the loading of all the data in memory. For the Ile-de-France area, the .osm file is currently 5.48 GB in size. For integration purposes, the swap space extension of the operating system was required. Data loading consumed almost all of its 42.5 GB memory resources (RAM + swap space). •

osm2pgrouting is dedicated to importing OpenStreetMap data. A typical query for loading data via this tool will be as follows:

osm2pgrouting –f ile-de-france-latest.osm –c mapconfig_for_cars.xml –d ile_de_france –U postgres –clean

53

Selection of an Open-Source Solution for Exploitation of Geographic Information System Data Other solutions can be used to import map data into a PostgreSQL database. However, with these, it is necessary to build the topology (see the documentation of pgRouting [35]). Among these tools are the following: •

The PostGIS data loader shp2pgsql [36] allows the conversion of ESRI shapefiles (.dbf, .shp, .shx) into tables for the PostGIS/PostgreSQL database.

shp2pgsql /home/mydata/roads.shp newtable > /home/mydata/roads.sql

•

ogr2ogr [37] from the Geospatial Data Abstraction Library (GDAL) allows the data structures to be converted from and to different formats.

ogr2ogr -f "PostgreSQL" PG:"host=myhost user=myloginname dbname=mydbname password=mypassword" mytabfile.tab

7.2.4.8 Licenses Most software parts of pgRouting are under a GPLv2 license. The Boost bricks are available under a Boost license. The contributions of iMaptools.com are under an MIT-X license. GNU General Public License The GNU GPL license is intended to guarantee the users of a computer program the following rights: • • • •

Freedom of use for any purpose; Freedom of source code analysis and modification for its own needs; Freedom to redistribute it; Obligation to make benefit-modified versions to the community.

Boost License This is a permissive license as are the BSD license and the MIT license. However, it does not require paternity recognition for redistribution in a binary form. MIT-X License The MIT-X license, applied to software, gives to any person the unlimited right to use, copy, modify, merge, publish, distribute, sell, and modify its license. The only restriction is the duty to insert the names of the authors within the copyright notice.

54

8. Final Architecture The architecture chosen can be summarized by a sequence diagram as follows:

Figure 37: Final architecture

8.1 Why C++ for This Service and Not C or C# Within a .NET environment, C# would be great. It allows the realization of many things for a minimum of effort, time, and therefore development cost. Under the Microsoft platform, it is the standard. But since the mapping database system is under the Linux CentOS system and most of the complex operations have to be handled on this side, much of the development is expected to be realized under the Linux system. The system will have to interact with: • • • •

A C# appliance dispatch application under a Windows Server environment; One or more web applications (monitoring or measuring the service coverage); A PostgreSQL database system (mapping data); Data from a SQL Server database (operational data of the rescue service).

55

Final Architecture For the CentOS part, due to the Linux environment, as well as the needs for speed and system load reduction, the C and C++ languages already seem to be good options. Also, it will be interesting to develop the skills in order to evolve the pgRouting framework so that it responds more effectively to the institution needs. Here, C++ has an advantage over C. The pgRouting extension is coded in Procedural Language/PostgreSQL, C, and C++. But for its graph representations, pgRouting relies on C++ and the C++ Boost Graph Library. PostgreSQL extensions [38] can be directly written in C. For other languages, these must be compatible with the C language, which will act as the intermediary.

8.1.1 C++ Strengths Often, the reason given for the use of C++ versus other languages is performance. But beyond the speed, they also must be understood in terms of the gain in development time. The reason for this is that C++ offers a possibility of abstraction, which, unlike other languages, does not have an impact on the runtime performance [39]. When used correctly, C++ actually allows you to enter much less code than C, with no additional cost at runtime and greater safety (better error detection when compiling).

8.2 Making the pgRouting Framework Evolve to Better Meet the Needs of the Rescue Service In terms of coverage metrics, it may be helpful to use the pgr_drivingDistance() function. For an initial node, this function will return all the nodes characterized by a cost (e.g. distance, time) less than or equal to a given value using the Dijkstra algorithm. pgr_drivingDistance() therefore attempts to retrieve the nodes and their predecessor road segment following the shortest paths, node to node, under a determined distance constraint. This logic unfortunately dismisses the segments for which a shortest path has already been found for the two ends. For example, consider a simple query pgr_drivingDistance() starting from the Paris 11 rescue centre during rush hour with a transit delay restricted to five minutes: -- Simple query pgr_drivingDistance SELECT q.seq, q.node, q.edge, q.cost, q.agg_cost, w.length_m, w.the_geom As geom FROM pgr_drivingDistance( 'SELECT gid As id, source, target, cost_s As cost, reverse_cost_s As reverse_cost FROM ways', 193760, -- Node near the Paris 11 rescue centre (300 * 0.3) - departure_time(), -- Coverage at five minutes from the rescue centre at rush hour true) As q LEFT JOIN ways AS w ON q.edge = w.gid -- Join to retrieve geometries WHERE q.edge -1;

This query will return the green-coloured segments of Figure 38: The results of two pgr_drivingDistance queriesErreur ! Source du renvoi introuvable.. If one also wants to retrieve each segment located between two nodes where the shortest path has already been found (shown in red in Figure 38), some additional operations are needed.

56

Final Architecture The query must then be as follows: -- Coverage at five minutes from the rescue centre at rush hour WITH results As (SELECT * FROM pgr_drivingDistance( 'SELECT gid As id, source, target, cost_s As cost, reverse_cost_s As reverse_cost FROM ways', 193760, -- Node near the Paris 11 rescue centre (300 * 0.3) - departure_time(), -- Coverage at five minutes from the rescue centre at rush hour true) ), edges As ( SELECT edge FROM results WHERE edge -1 ), nodes As ( SELECT DISTINCT node FROM results ) SELECT * FROM ways WHERE (source IN (SELECT node FROM nodes) AND target IN (SELECT node FROM nodes)) OR gid IN (SELECT edge FROM edges);

This type of query, beyond adding extra processing, can potentially take into account some segments that should not be considered. Nevertheless, although the result is not perfect, it is a far better measure of the coverage than the previous one.

57

Final Architecture

Figure 38: The results of two pgr_drivingDistance queries

The problem outlined would not arise if the algorithm, instead of trying to cover all the nodes, tried to cover all the edges. To ensure an optimal solution, the algorithm would also return parts of the edges characterized by a node below and a node above the defined time limit constraint. One can observe that some edges, which should be taken into account by the algorithm, are not considered. This is due to an approximation of some OpenStreetMap data. These inaccuracies give rise to an inability of osm2pgrouting to perform certain joins during its network construction. The problem will not arise within a corporate road network database that is well maintained.

58

Final Architecture

8.2.1 Aside on the Function departure_time() The departure of a team is not immediate when an operator picks up the phone for an emergency request. But for the previous query, departure_time() was defined as follows: departure_time.control23 comment = "Team lead-in time after an operator's call acceptance" default_version = '0.0.1' relocatable = true

departure_time.sql \echo Use "CREATE EXTENSION departure_time" to load this file. \quit CREATE FUNCTION departure_time() RETURNS int LANGUAGE plpgsql IMMUTABLE STRICT AS $$ DECLARE -- TODO BEGIN RETURN(0); END; $$;

The departure_time()function returns the value zero. For its future development, this function should a priori take into account: -

-

The median time to transmit a request for relief from the call processing centre to a rescue centre. The position of the appliance: o Parked at the rescue centre; o Crew available on board; o Crew available outside the appliance. The rescue centre. Since the layouts of different rescue centres are not identical, the departure times will differ substantially from one centre to the other; The rest periods of the teams (the wake-up and dressing time lengthens the dispatch period).

So far, almost all the technologies have been defined. Only the inter-language and inter-system communication protocol and language remain to be defined: • •

23

Between the intended service and the C# appliance dispatch application; Between the intended service and the mapping applications.

To define a PostgreSQL system extension, we need at least: A control file specifying the basic properties of the extension itself (.control) and A file containing the SQL commands of the extension (.sql).

59

Final Architecture

8.3 Appliance Dispatch Application/Service Communication For a communication between a C++ application under Linux and a C# application under Windows, the choice of a communication protocol arises.

8.3.1 Phases of Reflection Leading to the Selection of a Protocol In looking for the right protocol, you may find yourself successively moving through different phases of reflection, which Martin Kleppmann has described in a pertinent way in his article of 2012 [40]. Below, you will find an adaptation and some additional information for our context: Phase 1: You will start by looking for the serialization methods specific to the programming languages you have to deal with. Your attention may be focused on C# classes of the System.Runtime.Serialization namespace and the C++ Boost.Serialization library. You may even be tempted to invent your own format. Phase 2: You will understand that the need not to be restricted to a single programming language and environment makes things more complex. You will then turn to protocols and architectures that have been created to answer these types of problems, such as CORBA, SOAP, or REST. There is a good chance that you will opt for REST + JSON (or SOAP + XML, if you like to party like it’s 1999). For our architectural context, you may want to consider the C++ REST SDK 24 , which is also known as Casablanca or Restbed25. For my part at this stage, I was tempted by gSOAP because it is very mature, offers extensive documentation, and does not require a web environment (for an introduction to gSOAP, refer to Appendix 6: Introduction to gSOAP). Despite its name and the example in the Appendix, it can be used to implement a JSON REST service [41] from Version 2.8.28 onwards. Phase 3: You end up understanding that REST + JSON is neither the most effective solution nor the best option in your case. The REST technology combined with a JSON data format is actually popular and for excellent reasons. But it is not the ultimate inter-system data exchange solution. It is a good option when you are in one of the following contexts: • • • • •

24 25

You want the data to be directly readable by an individual; The data of the service will be directly consumed by a web browser; Your server-side application is written in JavaScript; The speed of data exchange under protocol REST + JSON is rapid enough; The cumbersome implementation of another data exchange format would be too expensive.

https://github.com/Microsoft/cpprestsdk https://github.com/Corvusoft/restbed

60

Final Architecture Phase 4: You will understand that you need to change your message format using various types of objects and this will become a problem. You would like to be able to link a schema and documentation to your data that would also avoid the systematic repetition of data field names. At this point, you will probably be interested in Thrift, Protocol Buffers, or Avro. These emphasize an increased concern for optimizing bandwidth, speed of data exchange, and backwards and forwards compatibility: • • •

Thrift, initially developed at Facebook, is now supported by Apache; Protocol Buffers, currently in Version 3, has been developed and is widely used at Google. Designed in 2001, it was only released in Version 2.0 in 2008; Avro joined the Apache Software Foundation as a sub-project of Apache Hadoop and was released in 2009 in Version 1.0.

Supported programming languages: • • •

Protocol Buffers supports [42] Java, Python, and C++. Since Version 3, it also supports Go, JavaNano, Ruby, and C#; Thrift supports [43] C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml, and Delphi; Avro supports [44] C, C++, C#, Java, Perl, Python, Ruby, and PHP.

8.3.2 Thrift vs. Avro vs. Protocol Buffers Choosing between these three technologies is less obvious than the previous technological choices. By browsing various articles and forums, we find a divided community of users. Such a technological choice should be made following a joint reflection within the institution and, even better, with its partners, such as the French Defence Ministry's Inter-Forces Infrastructure, Networks and Information Systems Department and the competent services of the Prefecture of Police, in order to promote the development and consolidation of common technical skills. However, some persistent arguments differentiate these technologies.

8.3.2.1 Apache Thrift Thrift is sometimes pointed to as the slowest protocol in practice. The main advantage of Thrift is that it offers an ‘all-in-one’ framework for both information serialization and RPC communication protocol. The data types and service interface are to be defined within a single file. Using this file, the compiler directly generates the code to be used for the RPC client and server for the targeted programming languages.

61

Final Architecture

8.3.2.2 Apache Avro The real advantage of Avro compared to the other two frameworks is that it offers a dynamic typing approach. It is true, however, that a static approach is sufficient in most cases in practice. In the case of a C# implementation, the .NET 4.5 framework will offer a better compression algorithm [45] thanks to the zlib compression library.

8.3.2.3 Protocol Buffers (also Known as Protobuf) ⟶ gRPC Protocol Buffers is a method for serializing structured data. Unlike Thrift, Protocol Buffers does not directly include any associated RPC system, but is nevertheless affiliated with one—namely gRPC26. gRPC is the open-source version of the Stubby protocol used internally by Google for its microservices [46]. Concerning this dissociation, the authors advance a concern of modularity [47]. When Protobuf was made open source in 2008, the team in charge—in which Kenton Varda was a part—by default of time, could not also publish this RPC implementation and it was only published in 2015 [48]. gRPC is based on the HTTP/2 standard (published in 2015 by the IETF). The HTTP/2 offers a reduction in latency and an acceleration of the content downloads compared to its predecessor: HTTP/1.1. gRPC is intended to be a framework in order to facilitate the creation of high-performance APIs and micro-services for many programming languages and platforms [49]. This RPC protocol is distributed under the BSD license. Like Protobuf, gRPC has very good documentation and better quality at the moment than the other two protocols mentioned. Other organizations outside of Google also use Protobuf. For example, it is used for the OpenStreetMap collaborative project for the distribution of map data in the .pbf format [50] and by TomTom for its TomTom Traffic Flow—Intermediate Service [51]. gRPC is used by Netflix and some network hardware manufacturers including Cisco, Juniper, and Arista [52]. An Example of a Message Encoded in the Protobuf Format Let us take an example close to the JSON message introduced in § 6.4.3 while being a little more explicit than the latter: { "id":1, "latitude": 48.860974, "longitude": 2.367221, "type": ["engine","engine"], "name": ["VSAV","PSE"], "distance_search_area": [3,6,12], "alternatives": [3,3], "geoms": true, "bounding_box_x": 1000, "bounding_box_y": 1000, "services": ["SAV", "INC"] }

By removing the chariot spaces and returns from this JSON object, the message size is 235 bytes.

26

http://www.grpc.io

62

Final Architecture In order to be able to transmit such a message in the Protobuf format, it will first be necessary to create a schema with a .proto file as follows: syntax = "proto3"; package adagio; // [START csharp_declaration] option csharp_namespace = "Google.Protobuf.ADAGIO.RequetesOptionsAllocation"; // [END csharp_declaration] message RequeteOptionsAllocation { int32 id = 1; float latitude = 2; float longitude = 3; enum MediumType { engine = 0; competency = 1; } repeated MediumType type = 4 [packed=true]; repeated string name = 5; repeated int32 distance_search_area = 6 [packed=true]; repeated int32 alternatives = 7 [packed=true]; bool geoms = 8; int32 bounding_box_x = 9; int32 bounding_box_y = 10; enum ServiceType { SAV = 0; INC = 1; AR = 2; } repeated ServiceType services = 11 [packed=true]; } // Envelope to concatenate multiple queries message RequetesOptionsAllocation { repeated RequeteOptionsAllocation requete = 1; }

The message, once encoded in the Protobuf format (Version 3.1 in our case), will consume only 50 bytes with the following hexadecimal27 transcript: 300a 0108 a315 4371 1d42 808d 4017 0222 0000 042a 5356 5641 032a 5350 3245 0303 0c06 023a 0303 0140 e848 5007 07e8 025a 0100

27

Command to read the hexadecimal code of a file from the command prompt: xxd filename_

63

Final Architecture Given the way computers read data, the first thing we need to understand this message is to invert the byte pairs (ABCD should become CDAB): 0a30 0801 15a3 7143 421d 8d80 1740 2202 0000 2a04 5653 4156 2a03 5053 4532 0303 060c 3a02 0303 4001 48e8 0750 e807 5a02 0001

Within this hexadecimal string, we find the information from our initial message as shown in the following figure: ASCII Coding A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 5a

a b c d e f g h i j k l m n o p q r s t u v w x y z

61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 80

Figure 39: A Protobuf message corresponding to the JSON message on Page 62

The character encoding28 follows the ASCII standard. For more information about message encoding in the Protobuf format, see Protocol Buffers language guide [53]. There is a slight inaccuracy regarding the floating-point number encoding: The hexadecimal transcription 424371a3 corresponds in fact to 48.860973 instead of the value 48.860974 provided. For GPS coordinates, a unit to the sixth decimal point corresponds to a difference of 11.13 cm at the equator.

28

For an explanation of the 32-bit floating-point numbers encoding with the IEEE 754 standard, see the explanation of Thomas Finley [54].

64

Final Architecture

8.4 Changes in the Emergency Dispatch Application For the proposed system, some modification to the appliance dispatch application is required. These modifications concern: • •

Sending, to the cartographic information system, a query to evaluate the transit times of the teams available for a place of request for relief; Transmission of the team’s availability changes to the cartographic information system.

The changes to be undertaken relate to the server-side part of the appliance dispatch application. For that purpose, the developer will face the choice between method extension and method overriding. An extension is preferred when: • • •

We have no control over the class to be expanded; We need to add functionality without having to modify a large piece of existing code; We want to provide some features that can be enabled or disabled by adding or removing the references to the project.

In all other cases, method overriding will be preferable.

8.5 Opportunities for Cartographic Applications The mapping application opportunities arising from the proposed structure may be diverse. Depending on the objectives, different architectures have to be considered.

8.5.1 PostgreSQL + Node.js For a coverage-monitoring application that follows database updates (see § 6.4), a PostgreSQL NOTIFY/LISTEN Node.js architecture may respond perfectly to the need. The choice of this language is not innocent since the institution's Geomatics department already has Node.js skills. Of course, other server-side languages could also be used, such as PHP, Python, and so on.

8.5.1.1 PostgreSQL NOTIFY/LISTEN Node.js NOTIFY/LISTEN is a publish/subscribe built-in PostgreSQL mechanism. We consider a ways table for which the columns SAV, INC, and AR have been added to maintain the number of appliances covering the road segments for different services. With this table, we would like to update a graphic representation of the response capacity as updates occur. To meet this need, one possibility would be to create a TRIGGER calling a pg_notify() function [55]:

65

Final Architecture -- Notify when data has been changed within the SAV, INC, AR columns of the 'ways' table CREATE OR REPLACE FUNCTION notify_trigger() RETURNS trigger AS $$ DECLARE BEGIN PERFORM pg_notify( CAST('couverage_watchers' AS text), row_to_json(NEW)::text); RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE TRIGGER notify_trigger AFTER UPDATE OF SAV, INC, AR ON ways FOR EACH ROW EXECUTE PROCEDURE notify_trigger();

PERFORM allows you to execute a query regardless of the result. Its syntax is identical to a SELECT command.

Then, to interact with PostgreSQL from Node.js, Brian Carlson's node-postgres module [56] could be used. The code below corresponds to the client configuration listening to a channel labelled as coverage_watchers. This will allow the call of a function coverage_update() in charge of the coverage representation updates. var pg = require ('pg'); var pgConString = "postgres://localhost/xxxxx" pg.connect(pgConString, function(err, client) { if(err) { console.log(err); } client.on('notification', function() { coverage_update(); }); var query = client.query("LISTEN coverage_watchers"); });

8.5.2 Applications Requiring More Complex Operations For more complex operations requiring the pre-processing of data in C/C++, we can implement a Node.js addon in C/C++ [57]. Node.js extensions: Node.js extensions/add-ons are dynamically linked shared objects, written in C or C++, that can be loaded by Node.js using the require() function and used in the same way as any ordinary Node.js module.

66

Final Architecture

8.6 Overall Scheme In the end, to meet the expressed need, we arrive at the following architecture:

Figure 40: The overall schema of the proposed architecture

8.7 Response Capacity Rendering With such an architecture, the recovery time of the response capacity information associated with each road segment is limited to a simple SELECT query: SELECT gid As id, sav As vsav, the_geom As geom FROM ways WHERE sav 0

For example, we have added to our ways table (built on the OpenStreetMap Ile-de-France data), a column named sav that counts the number of paramedic ambulances reaching the different road segments within 10 minutes. We considered the following: -

All the paramedic ambulances of the fire brigade were available at their rescue centre; A delay of two minutes between the emergency call acceptance and the departure of an appliance; Emergency appliances follow the direction of the traffic lanes; 67

Final Architecture -

The speed of the emergency appliances is equivalent to 50% of the speed limit of the road axles.

The running time of the SELECT statement on our ways table for our architecture provides a 0.5-second execution time. This statement returns a result composed of 158,348 road segments among the 597,053 road segments that are already in our database: id

vsav

geom

1

286177

2

0102000020E6100000020…

2

470595

20

0102000020E6100000020…

3

275661

9

0102000020E6100000020…

…

…

…

…

This result, when transposed on a map, makes it possible to obtain the following representation:

Figure 41: A visualization of the rescue response capacity in Paris for paramedic ambulances (RGF93 / Lambert-93 projection)29

The calibration of this representation must be discussed with different actors within the fire brigade.

‘In less than 10 minutes’ refers to the time between the emergency call acceptance to the arrival of the rescue team in front of the request-for-relief address. 29

68

9. Traffic Data Services 9.1 Traffic Data from Government Services in France In France, traffic and event data from the road management services is freely available. The traffic data is the result of agglomeration and processing carried out within an information system called SIRIUS (Intelligent Road User Information System). This system relies on: - Sensors (electromagnetic loops) for measuring traffic that are installed in the roadway (6,000 counting loops); - Information from community applications; - The network of traffic surveillance cameras.

Figure 42: The Ile-de-France roads control centre. (LP/Jean-Gabriel Bontinck.). 8 December 2016. [58]

We can directly appreciate the coverage of the road network that this service maintains through the representation produced by its application: www.sytadin.fr

Figure 43: Traffic overview based on data collected, which is available on the website www.sytadin.fr

Those wishing to use this traffic data for the Ile-de-France region will turn to two collection points: -

Data from the information system of the Ministry of Ecology, Sustainable Development and Energy [59]; Data from the road management service of the Parisian City Council [60].

69

Traffic Data Services

9.1.1 Data from the Ministry of Ecology, Sustainable Development and Energy Traffic and event data for France may be obtained free of charge, subject to compliance with the ‘bison futé’ state charter [61] (bison futé is a service attached to the Ministry of Ecology, Sustainable Development and Energy). After approval and signature of the latter, for the Ile-de-France region, the DIRIF (Direction des routes Ile-de-France) will transmit the identifiers allowing access to this data. This state service uses the Datex II XML format for the distribution of its data (see [62] and [63]). It offers (at the end of April 2017) data dating back to 4 July 2013. Today, it offers a total of 8,962 observations (8,383 from 23 December 2016 to 26 April 2017, the period for which the data flow seems to be continuous). Reading the XML data structure is not really instinctive. However, it can easily be transposed in tabular form via a tool such as the Power Query add-in of Microsoft Excel. The recovery of the GPS coordinates of the events, with the parameter pointCoordinates, will allow us to appreciate the coverage of the system:

Figure 44: A representation of the record positions with the application of Darrin J. Ward [64]

Other parameters of this service include the following: -

-

situationRecordObservationTime: The date and time the information was observed; overallSeverity: Evaluation of the impact (in terms of severity) the event has on the traffic flow

according to three states: o High; o Medium; o Low. Attribute ‘type’ of situationRecord characterizes the event as AbnormalTraffic, Accident, AnimalPresenceObstruction, ConstructionWorks, GeneralInstructionOrMessageToRoadUsers, GeneralNetworkManagement, GeneralObstruction, MaintenanceWorks, NonWeatherRelatedRoadConditions, PoorEnvironmentConditions, ReroutingManagement, RoadOrCarriagewayOrLaneManagement, SpeedManagement, VehicleObstruction, or WeatherRelatedRoadConditions.

This event information is therefore too succinct to be exploitable.

70

Traffic Data Services For more relevant information at the Ile-de-France region level, you will have to go through the SYTADINPRO service, which requires registration on the Cerbère portal of the same ministry: https://authentification.din.developpement-durable.gouv.fr.

9.1.2 Data of the Parisian City Council Traffic data from the permanent sensors in Paris is released under the Open Database License (ODbL). It is aggregated by the time band providing the following information [65]: -

Road segment identifier according to the repository [66]; Time-stamping; Throughput: number of vehicles counted during the hour; Occupancy rate: vehicle occupancy time of the measurement station over one hour in percent.

It is possible to evaluate the coverage of the system directly from the Open Data Paris platform [66]:

Figure 45: The roads where sensors have been installed to measure the traffic activity

For the period from 1 January 2017 to 28 February 2017, the API offers 386,133 measurements from 2,878 different sensors among the 3,316 sensors referenced.

71


9.2 Commercial Traffic Data Services30 Two major companies offer real-time traffic data: -

TomTom; HERE, acquired in 2015 by the German consortium Audi-BMW-Daimler, was initially a company called NAVTEK. It became HERE a few years after its acquisition by Nokia in 2007.

By way of example, ESRI, thanks to data coming from HERE, is able to broadcast a representation of the traffic information as follows:

Figure 46: Traffic data for the 11th arrondissement of Paris, edited by ESRI [67]

In this sector of activity, we must also note the presence of Google. Its cartographic application services publish traffic information of a level of granularity a priori similar to ESRI. Google's traffic information is based, among other things, on data from the government road management services, taxi service data, cellular data from Google application users (for which GPS position transmission has been licensed by the user), and since 2013, data from the Waze app acquired by Google that year. However, unlike HERE and TomTom, Google does not currently offer any direct access to its traffic information but provides a range of services. HERE and TomTom are getting data from a multitude of sources similar to those used by Google. However, these two companies seem to stand out from the rest of the world thanks to significant feedback from different brands’ in-car navigation devices. HERE's built-in device can be found in the brand-name vehicles of the German Audi–BMW–Daimler consortium, as well as Volvo, Hyundai, Mazda, Mitsubishi, and Jaguar models. Meanwhile, TomTom technology is used by car manufacturers such as Fiat, Renault, Lexus, Alfa Romeo, Lancia, and Ford.

30

The term ‘traffic data’ is understood to mean data characterizing the road traffic flow.

72


9.2.1 TomTom Traffic Flow—Intermediate Service The TomTom Traffic Flow—Intermediate Service [51] provides travel times and the speeds for road segments in real-time. It is a service designed to integrate this information within an enterprise architecture such as traffic control centres, navigation service providers, route planning, and other mapping applications. The service supports two data exchange formats: -

Datex II format; Protobuf format.

With the Protobuf format, TomTom offers finer and broader traffic information than with the Datex format. The query of this service through HTTP should be of the following form: https:///tsq/hdf///content.proto[?flowType=]

The following sample query: https://traffic.tomtom.com/tsq/hdf/DEU-HDF-OPENLR//content.proto?flowType=nff

will provide a response of the form: trafficFlowGroup{ metaInformation { createTimeUTCSeconds: 1452092910 supplierAndClientInfo { clientID: "db14af1d-3827-4d61-8525-8f70bc1c5b3f15e87601" supplierID: "TomTom Traffic Service" } formatVersion: 1 } [...] trafficFlow { location { openlr: "CwmT2iVVRhtgCwEpAiQbU34=" } speed { averageSpeedKmph: 5 travelTimeSeconds: 334 confidence: 97 relativeSpeed: 0.106 trafficCondition: STATIONARY_TRAFFIC } } [...] }

Actually, this service distributes three types of traffic information: • • •

TrafficFlow: current speed information for a position; TrafficFlowWithPrediction: traffic flow prediction of a position, present and future; TrafficFlowWithPredictionPerSection: traffic flow prediction per section, present and future.

73


9.2.2 HERE—Traffic Flow Data API HERE provides a traffic information API [68] that provides speed and congestion information for a defined area. The possible response formats are XML and JSON. It is possible to test this service online at: https://developer.here.com/api-explorer/rest/traffic/traffic-flowbounding-box

Example of Use By using an application code and a user code you will be able to send a GET query in the cURL format: curl \ -X GET \ -H 'Content-Type: *' \ --get 'https://traffic.cit.api.here.com/traffic/6.1/flow.json' \ --data-urlencode 'bbox=48.8709,2.3529;48.8602,2.3992' \ --data-urlencode 'app_id={YOUR_APP_ID}' \ --data-urlencode 'app_code={YOUR_APP_CODE}'

The previous request corresponds to a traffic information query within the following bounding box:

Figure 47: A limit box corresponding to the previous query

The API will return a response such as: { "VERSION": "3.1", "UNITS": "metric", "RWS": [ { "RW": [ { "FIS": [ { "FI": [ { "TMC": { "PC": 51625, "DE": "Place de la République", "QD": "+", "LE": 0.01792 }, "CF": [ { "JF": 1.62962, "CN": 0.7, "SP": 13, "TY": "TR", "FF": 18,

74

Traffic Data Services "SU": 13 } ] }, ...

The meanings of those parameters are as follows [69]: • • • • • • • • • • • • • • • •

RWS: A list of roadway (RW) items RW: This is the composite item for flow across an entire roadway. A roadway item will be present for

each roadway with traffic flow information available FIS: A list of flow item (FI) elements FI: A single flow item TMC: An ordered collection of TMC locations PC: Point TMC Location Code DE: Text description of the road QD: Queuing direction. '+' or '-'. This is the opposite of the travel direction in the fully qualified ID. For example, for location 107+03021, the QD would be '-' LE: The length of the stretch of road. The units are defined in the file header CF: Current flow. This element contains details about speed and jam factor information for the given flow item. CN: Confidence, an indication of how the speed was determined. -1.0 means road closed. 1.0=100% 0.7=100%. Historically usually a value between 0.7 and 1 FF: The free flow speed on this stretch of road JF: The number between 0.0 and 10.0 indicating the expected quality of travel. When there is a road closure, the jam factor will be 10. As the number approaches 10.0, the quality of travel becomes worse. -1.0 indicates that a jam factor could not be calculated SP: Speed (based on UNITS) capped by a speed limit SU: Speed (based on UNITS) not capped by a speed limit TY: Type information for the given location referencing container. This may be a freely defined string

One can appreciate the coverage of the network directly via the traffic application: https://wego.here.com/traffic

Figure 48: The corresponding representation of traffic information from HERE

75


9.3 Assessment of the Appropriateness of the Use of the Traffic Information Data Services In order to improve the team transit time and the service coverage assessments, the design of a statistical model is necessary. For the design of this statistical model, we would like to have: -

An assessment of the traffic fluidity for the various road segments of the jurisdiction; Retrieve as accurately as possible the history of the GPS positions of appliances dispatched to the scene of request for relief matching the road graph in the database.

Unfortunately, these two elements are not available today. Even the paid traffic information services do not currently offer full network coverage due to data quality concerns. The ability to retrieve (≠ continuous transmission to the management centre) the GPS positions of the appliances should nonetheless be an imperative for the institution to improve further models. This approach should also focus on being able to detect and record the arrival times by simply detecting the presence of the allocated team near the place of the emergency request. Currently, a team leader is responsible for the arrival time of his team and may consider being on the scene related to the request for relief: -

On arrival in front of the address; On arrival in front of the appellant on the 15th floor of a residential building, crossing several inner courtyards and climbing 15 floors on foot.

Based on what criteria should we build a model? One could hope to improve the control of the rescue team arrival times, compared to the current model: full hours/off hours and intramuros/extramuros, taking into account: -

-

Transit time pgRouting computation; Taking into account only data from the operation where the arrival time of the team is most likely to be very close to the arrival in front of the address (request for relief on public roads, for example); Characteristics of the appliance (length, width, weight, power, category); Time data: time slots, weekend/week, public holiday, holiday period, etc. (categorical values); Bad weather in the area; Known traffic flow information: o Near the emergency centre; o Near the area from which the request originates. Index of urbanization of the area, such as population density.

76

10. Ongoing Project Recommendations From this study, we arrive at the following work breakdown structure:

Figure 49: The work breakdown structure for the proposed system

The work intended to provide a good estimate of the transit times of the rescue teams, appears to be of prime importance for the rest of the proposed system to be able to achieve the intended objectives. The model to be built for this purpose will not be perfect. Hence, its construction should be concluded with a study establishing the level of imprecision and the limitations of this model. The results of this study should mark a stage in the project, in order to validate the results and confirm or reconsider the objectives. In the present state, it would be a little illusory to draw up a Gantt chart, planning the burden attached to the various actors. Planning and project management is based on well-known and mastered actions, taking into account the constraints and logic of the management of the company. 77

Ongoing Project Recommendations What is certain is that this project requires the joint work of different actors. These include the following31: -

Project manager Senior developer (C++ skills) Cartographic section leader Developer of the geomatics department (skills in web programming) Database administrator Network systems administrator Developer of the emergency response application (C# skills) Actor in charge of statistical studies Business referent

The IT project manager is an indispensable actor who sometimes seems to be discredited within the institution. However, a project manager with a proactive personality is really the linking agent dedicated to bringing together the different actors of a project. Not everyone can be an IT project manager just because of his rank within the company. A project manager requires strong technical skills (relating to the project area), managerial skills (to be distinguished from command action), and qualities now identified as emotional intelligence32. A synthesis of the qualities of a project manager was formulated consecutively to a study carried out by Google in 2009 defining the ‘Eight Habits of Highly Effective Google Managers’ [70]. • •

For these eight qualities, see Appendix 7: Eight Good Behaviors of a Manager. For the genesis of this study, see the article ‘Google's Quest to Build a Better Boss’ [71], published in The New York Times.

In terms of resources, the institution currently has all but one, because of the technological choices previously justified. For this project, the institution will need the skills of a C++ developer. The ChooseYourBoss website [72], which presents itself as a barometer of the IT market in France, advanced in March 2017 a gross annual salary of between €44,000 and €60,000 for a C++ Senior Developer. By targeting the same net salary for the civil service, the total cost [73] (= net salary + wage share + employer's share) will be between €65,556 and €89,394 for recruitment under the civil status, and between €42,994 and €58,629 for recruitment under the contractual status of the public sector (see Appendix 8: Calculation of the Cost of a C++ Developer for the Public Service). The fire brigade now recognizes a lack of resources in terms of developer profiles and is attempting to remedy it. Owing to its desire for independence concerning its emergency response information system, this recruitment option is in line with the policy that has been followed for several decades with the arrival of IT systems within the service.

31

An employee can combine more than one quality. Emotional quotient is a concept and indicator that is well integrated today in many companies as a major decision factor for the recruitment of a future employee. It is very distinct from the conventional IQ (intelligence quotient). 32

78

12. Academic Purposes This project allowed the implementation of the skills developed during certain teaching units followed over the last four years at the Conservatoire National des Arts et Métiers (CNAM). -

Analyse, understand, and transcribe a need (NFE114); Model a data structure to meet this need (NFE113 and NFP107); Understand the stakes of inter-system communication processes and choose the appropriate technology for the existing architecture (NY014 and RX112); Be familiar with the graph traversal methods and the algorithmic complexity (RCP105); Test various programming issues and detect data structures that are conducive to the use of design patterns (NFP121); Understand the possibilities offered by the statistical domain and the necessary prerequisites (RCP208, RCP209, and STA102).

There is also ENG221, which is probably one of the most important exercises. It encourages us to better understand the approach and skills that must emerge from an engineering dissertation. This, in my opinion, remains valid only considering the level of exigency maintained by the juries of this unit. It invites us to venture into unfamiliar areas where we must decipher the logic, as well as understand the stakes and future prospects of an area hitherto unknown. Finally, it is necessary to transcribe the study conducted and its findings to an audience of specialists and non-specialists in the field. A CNAM course, like any other university course, offers a context conducive to the development of skills in order to facilitate working in an area that we are passionate about. It seems to the one experiencing a CNAM curriculum that passion is the fundamental ingredient. Perseverance and self-reassessment are also very good allies. The time and energy burden, as well as the personal life compromises for individuals working full-time, are far from negligible. The CNAM is perfectly described by its professors as ‘the school of perseverance’, for they have lived it. For many, the CNAM precedes a phase of seeking new career opportunities. This phase then becomes a new challenge that, once again, will require time, research, preparation, questioning, and understanding of the expectations and needs of new interlocutors. University training is certainly meant to allow the development of new knowledge but not only that. It tries to help you evolve and mature your approaches, your way of thinking, your capacity to adapt, and your way of organizing yourself. It puts you to the test with the workload and problem-solving opportunities to prepare you to evolve towards a professional environment.

79

13. Conclusion A few years ago, the appliances of the Paris Fire Brigade were dispatched following the areas of competence. Today, the system has been improved and rescue teams are selected based on pre-estimated transit times. This is already a progress. However, the system still offers some margins for improvement with regard to an optimal selection of means. Selecting a team affects the service coverage. Each team engaged on a request for relief reduces the response capacity of the service and can lengthen the arrival time for other potentially critical requests. A better allocation of the rescue teams must result in a shorter presentation time for people in need. Of course, for the majority of common interventions, this additional time has only a slight impact on the fate of the victim. But in some cases, a few seconds may be enough to save a life, or at least reduce the severity of the lesions. For other trades, the benefit will be monetary; for this one, the benefit is counted in human lives. As a result of this observation, the work carried out a preliminary study for the construction of a system designed to optimize the allocation of the resources of a rescue service. However, it also seeks to provide managers with a clearer picture of the current state of the service. It was concretized successively by: -

Analysing the emergency response system Identifying the need Searching for the systems and logics used by other rescue services Defining an optimal logic for the allocation of the rescue teams Defining the architecture allowing the implementation of this logic (data structure, languages, frameworks, protocols) Deepening the opportunities offered by this architecture Exploring the relevance of the traffic information services Recommending a first approach for the evaluation of the transit times of the emergency means Defining the necessary actors for the implementation of this system Defining a work breakdown structure

This work has been guided by the certainty of being necessary before venturing into some other application developments in vogue. Before attempting to make a prediction for a rescue service, you must already have a good command of its current state. This does not seem to be the case today for the Paris Fire Brigade, as is the case for many other rescue services too. This is not inevitable, however. It is therefore what this work has attempted to provide answers to. The work carried out has certainly focused on a rescue service but it can be transposed to others. It can even provide elements of response to the problems of other sectors of activity that seek to visualize, measure, and optimize the response of their fleet of agents.

80

Bibliography [1]

F. Lesieux, F. Lion, P. Marilleau and J. P. Thomas. Quels Indicateurs Pour évaluer La Couverture Opérationnelle D'un SDIS? pp. 84–85. ENSOSP Paris, 2014. .

[2]

E. W. Dijkstra. A Note on Two Problems in Connexion with Graphs. Numerische Mathematik 1, pp. 269–271. Mathematisch Centrum, Amsterdam, 1959. .

[3]

R. Geisberger, P. Sanders, D. Schultes and D. Delling. Contraction Hierarchies: Faster and Simpler Hierarchical Routing in Road Networks. Karlsruhe Institute of Technology, Germany, 2008. .

[4]

R. Geisberger. Contraction Hierarchies: Faster and Simpler Hierarchical Routing in Road Networks. Karlsruhe Institute of Technology, Germany, 2008. .

[5]

M. Tandy. Contraction Hierarchies Path Finding Algorithm, Illustrated Using three.js. Michael Tandy’s Blog. June 2015. .

[6]

D. Delling, P. Sanders, D. Schultes and D. Wagner. Engineering Route Planning Algorithms. Karlsruhe Institute of Technology, Germany, 2009. .

[7]

H. Bast, D. Delling, A. Goldberg, M. Müller-Hannemann, T. Pajor, P. Sanders, D. Wagner and R. F. Werneck. Route Planning in Transportation Networks. 2015.

[8]

V. Buchhold. Fast Computation of Isochrones in Road Networks. Karlsruhe Institute of Technology, Germany, 2015. .

[9]

RoutingKit C++ Library’s GitHub .

Repository.

Accessed

March

2017.

[10] Presentation of the Emergency Call Platform 17-112-18. Portal of the Prefecture of Police. January 2016. . [11] GeoQlik chez les SDIS. GeoQlik’s website. 2013. . [12] B. Trousse. Design Patterns: Composite. CBR*Tools Documentation. INRIA Research Center— Sophia Antipolis, 2001. . [13] P. Deville, C. Linard, S. Martin, M. Gilbert, F. R. Stevens, A. E. Gaughan, V. D. Blondel, and A. J. Tatem. Dynamic Population Mapping Using Mobile Phone Data. 2014. . [14] GraphHopper GitHub Repository. . [15] OpenTripPlanner GitHub Repository. . 81

Accessed Accessed

March

2017.

March

2017.

Bibliography [16] OSRM GitHub Repository. Accessed March 2017. . [17] pgRouting Framework’s Official Website. Accessed March 2017. . [18] A. M. Bishop. Routino .

Application’s

[19] SpatiaLite’s Official Website. gis.it/fossil/libspatialite/home>.

Official

Accessed

Website. March

Accessed 2017.

March

2017.

Modelling and Optimization of the Unit Dispatch ...

Modelling and Optimization of the Unit Dispatch ...

Suggest Documents

Unit Commitment and Economical Dispatch of

optimal unit commitment and economic dispatch of

Thermal Generation Dispatch and Unit Commitment

Hybrid Optimization of the Emission and Economic Dispatch by the ...

decentralized unit commitment and dispatch in the micro-grids ... - PSCC

Unit Commitment with Economic Dispatch

Mathematical Modelling and Optimization of the ...

Unit Commitment with Economic Dispatch - International Electrical

Modelling Network Constrained Economic Dispatch Problems

Optimization of Fuel Cost and Transmission Loss in Power Dispatch ...

Optimization of Fuel Cost and Transmission Loss in Power Dispatch

Unit Commitment and Economic Load Dispatch using Self ... - WSEAS

Unit Commitment and economic dispatch in micro grids

Simulation and Optimization of LNG Production Unit

Dispa-SET 2.0: unit commitment and power dispatch model

modelling human factors and evacuation lift dispatch ...

Modelling Simulation and Optimization of Innovative ...

Electrothermal Modelling and Numerical Optimization of Induction ...

Modelling, Optimization and Control of Yeast ...

modelling and optimization of flexible manufacturing systems

Modelling and multi-objective optimization of process

MODELLING AND OPTIMIZATION OF TRANSMISSION SYSTEMS ...

Modelling and optimization of a continuous stirred

Modelling and optimization of Candida rugosa ...