Example of My Work PDF

Emergency helpdesk
B2-20
S OFTWARE
A ALBORG UNIVERSITY
Institut for datalogi
Skibbrogade
9000 Aalborg
Title: Abstract:
Emergency Operative Plan GIS
This report examines if a software solu-
Project: tion could help organise information for
the emergency services. An interview
P2 - A greater project of high quality
with the chief of emergency management
Project period: was made and the focus of the report was
fixed to help the emergency management.
February 3rd 2020 - May 27th 2020 The emergency management was looked
into and current solutions were examined
Project group:
including IHM and CoordCom.
B2-20 After defining the problem, it was decided
to create software that automatically dis-
Members: plays operative plans for current fires. A
priority list was made focusing on stor-
Frederik Hvidberg Madsen ing and displaying the correct informa-
tion, leading to a sketch of the overall de-
Johan Løhde Thomsen sign of the program, including where and
how information is stored and displayed.
The requirements of the program are de-
Karin Maria Wallsten scribed and the final program is tested.
The limits of the program are discussed
Kristian Dragsbæk Schmidt Thomsen and it is concluded that the program lives
up to most of the requirements. The fu-
Mojeb Hamid ture of the program is reflected upon, in-
cluding better security, database and col-
laboration.
Nanna Kåstrup Müller
Rasmus Borrisholt Schmidt Amount of pages: 74
Completed on: October 10, 2020

—————————————————————————————-
Supervisor:
Ondrej Franek
By signing this document using "Digital eksamen", every member hereby confirms that everyone have participated
evenly in the work, and as such everyone vouches collectively for the contents of this report.
The content of the report is freely available, but publication (with source reference) may only take place in agree-
ment with the authors.
Aalborg Universitet B2-20
Contents
1 Introduction 1
1.1 From Call to Dispatch - a Quick Introduction . . . . . . . . . . . . . . . . . . 1
1.2 Initiating Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Methods 3
2.1 Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Brainstorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Literature Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4 Top Down Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6 Stakeholder Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.7 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I Problem analysis 6
3 Stakeholder Analysis 7
3.1 Identifying Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Stakeholder Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 Justification of Stakeholders . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Danish Emergency System Overview 11

4.1 Flow of OCC systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 Emergency Management 14
5.1 Emergency Fire Management Resources . . . . . . . . . . . . . . . . . . . . . 14
5.2 Priority Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6 Existing Software Solutions 16

6.1 IHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2 Carmenta’s CoordCom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3.1 AML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.4 GIS Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.5 Operational Digital System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.6 Multiple Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7 Problem Delimitation 21
7.1 Defining the Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2 Choosing the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2.1 Necessary Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
CONTENTS iii
II Problem Solution 24
8 Software Design 25
8.1 Program Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2 Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.3 Program Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.3.1 In Depth Program Flow . . . . . . . . . . . . . . . . . . . . . . . . . 30
9 Implementation 33
9.1 JavaScript Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.2 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.2.1 Operator Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.2.2 Commander Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.2.3 Input Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.3 GIS as GeoJSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.4 Node.js HTTP Server Backend . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.5 Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.6 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10 Testing 53
10.1 Unit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1.1 Polygon Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
10.1.2 Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.2 Full Program Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.2.1 Operative Plan Upload . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.2.2 Receiving Fires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
10.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
III Problem Closure 61

11 Discussion 62
11.1 Primary Information Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
11.2 Program Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
11.3 Program Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
11.3.1 Comparison With the Design . . . . . . . . . . . . . . . . . . . . . . . 64
11.3.2 Program Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 66
11.4 Overall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
12 Reflection 68
13 Conclusion 70
Bibliography 72
CONTENTS iv
1 | Introduction
The emergency helpline in the Danish capital region alone receives 1.000 emergency calls every
day, and every year it dispatches a total of 100.000 vehicles to emergency locations[1].
Because these emergencies can create life threatening situations, the efficiency at which the
emergency helpline operates is paramount. An example of such an emergency could be a fire in
an apartment complex, which requires a large organisational effort to be dealt with efficiently
to save lives and property[2].
1.1 From Call to Dispatch - a Quick Introduction

The specific dispatch process differs for each unique emergency call. However, it is possible to
make a general outline of the process from receiving a call to dispatching an emergency vehicle.
When receiving a call, an emergency helpline operator will at the start of the call ask the fol-
lowing questions[3]:
• What happened?
• Where did it happen?
• When did it happen?
• What number are you calling from?
• Where does the help need to be sent?
• How many are hurt?
Getting this basic information across first, ensures that even if something happens to the caller
or the call for some reason is cut off, the operator is still able to dispatch help to the location.
Since 2011, a new system has been active in Denmark where emergency calls that need medical
guidance are redirected to a specialised helpline called AMK (Akut Medicinsk Koordinering).
After redirecting the call, the police can choose to stay on the line if they suspect that any in-
formation relevant to a potential investigation might come up. This can also help the police
identify any potential dangers still at the emergency site, such as fires or gas leaks, that could
be harmful for the emergency helpers arriving at the location[4].
In case of fire emergencies, the emergency information and location is sent to the emergency
management, who then dispatches the required vehicles and personnel to the location.
With criminal offences or other emergencies that require acute police response, the caller is
forwarded to the closest available police operation control centre, from which point the local
police handle the situation[5].
CHAPTER 1. INTRODUCTION 1
Recently, a system to help locate callers, called AML (Advanced Mobile Location), has been
implemented. AML automatically sends the caller’s phone’s location to the emergency helpline,
making it easier to locate callers unable to inform the helpline of their location[6].
Each individual call can vary in complexity and required response time, making the dispatcher’s
process more unpredictable.
1.2 Initiating Problem

From looking at the process of dispatching, it is clear that resolving an emergency call requires
a great amount of collection and coordination of information in order to send the correct help in
a timely manner[2]. Ideally, a well structured piece of software could help organise and share
information among operators. From this, the following initiating problem has been created:
How can a software solution help to organise information to coordinate a dispatch of emer-
gency services?
CHAPTER 1. INTRODUCTION 2
2 | Methods
This section will describe the different methods used in this project.
2.1 Interview
An interview was conducted in a semi structured way, meaning that questions had been formed
beforehand, and that an agenda had been prepared for the interview. The agenda allowed for
more in-depth questions, if these were necessary, for a better understanding of the subject. This
way of having the interview was chosen because only one interview was planned with the given
person, and this method allowed for more fulfilling and relevant questions.
The data from the interview were then processed qualitatively, by rereading the answers and
condensing it down to what is relevant for further working with the topic of this project[7].
2.2 Brainstorm
To get a better understanding of the topic and what should be included in the report a brainstorm
has been done. Brainstorm is a method for ideation, and was used to get to a common agreement
of the direction of the project.
2.3 Literature Sources

For literature sources, relevant articles and websites have been used to get more knowledge
about the subject. The main concern during research is to be critical about literature and ar-
ticles. It has to be certain that the information found is correct and relevant for the subject.
Source criticism is used to avoid outdated-, biased- or misinformation. Therefore, the articles
and literature used in this project are made by relevant sources like FALCK and the Danish
emergency fire management.
2.4 Top Down Programming

The implementation of the program solution is done primarily through a top down program-
ming approach. With a top down approach, the highest level functions are created first, and
then smaller sub-problems are worked through until the smallest sub-problem is solved and the
program is done. This is a best case scenario, and in reality it is often necessary to go back to
higher level functions to rework or modify them with knowledge gained from working with the
implementation.
CHAPTER 2. METHODS 3
2.5 Testing
By using unit tests, it is made sure that the individual parts of the program are working accord-
ingly. The focus in these tests is to ensure that the individual basic functions work as intended.
This makes the code more reliable, and ensures that the higher level functions interact with
validated basic function. The unit tests were performed using Jest.
End-to-end testing is a form of integration testing used to ensure that the functions in the pro-
gram work together as intended. The focus in these tests is not on the individual functions, but
rather how they interact with each other. This means that by combining end-to-end tests with
unit tests, all aspects of the program are tested. The end-to-end tests were performed using
Cypress, which is a testing framework for programs that are run in a browser.
2.6 Stakeholder Analysis

A stakeholder analysis has been conducted to identify important people and their interest in the
project. They have been sorted in groups according to their level of participation, influence and
interest. The stakeholder analysis gives an overview of how the project affects these different
groups of people. By using this method, a clear perspective of who the project should focus on
is made, and it is therefore a good method to use early in the project.
2.7 Glossary
Table 2.1 explains selected words and abbreviations used in the report.
Word Description
AMK Akut Medicinsk Koordinering. A specialised emergency
helpline in the Danish emergency services.
AML Advanced Mobile Location.
OCC Operation Control Centre.
Emergency Services The services sent by the OCC, such as ambulances and
fire engines.
Emergency Management Agency The agency responsible for the Danish national fire and
rescue service[8].
Emergency Management The fire and rescue services.
Operative Plan A document describing emergency rescue information
for a building or location.
Operator The person answering calls at an OCC or 112-central.
Dispatcher An operator that has the ability to dispatch rescue re-
sources.
On-site Commander The person in charge of fire rescues at the incident.
GIS Geographic Information Systems.
ODS Operational Digital System.
DOM Document Object Model.
Table 2.1: Glossary list.
Part I
Problem analysis
6
3 | Stakeholder Analysis
In this chapter, the stakeholders are identified and described to get an understanding of who they
are. The stakeholders will then be placed into the stakeholder matrix, after which explanations
of the placements are provided[9].
3.1 Identifying Stakeholders

Participants and involved parties are analysed, to find out who the stakeholders are in this
project. This is done by looking at who is working with or around an emergency and who
they are dependent on. The focus is primarily on the Danish emergency services, with data
from other countries used only to make general statements.
Callers
The callers are either people who are in need of emergency care or someone who has witnessed
an emergency scene. The callers help the dispatchers by informing them where and what the
emergency is. It is hard to expect much from the callers due to the shock the incident may cause
to the person or simply because the caller could be someone without the necessary capabilities
to help.
112-operators
112-operators are the people receiving the emergency calls. They consist of trained personnel
with prior experience in the emergency help sector, located at one of three emergency call cen-
tres. Operators manage every emergency call and make sure the correct authorities are involved.
Meanwhile, they also gather and report information from the caller and forward the call to the
operation control centre (OCC).
Emergency Services
The emergency services are the services that are sent by their OCC to the location where the
help is needed. What service is needed depends on the emergency. For this stakeholder anal-
ysis, the fire department and ambulance services are considered to be the primary emergency
services.
Operation Control Centre

Each emergency service has an OCC connected to them. The OCC is where the 112-operators
direct the callers after retrieving the necessary information from the caller. The dispatchers at
the OCC then handles the deployment of emergency services to the incident. Operators at the
OCC gives informational aid to the caller, e.g. medical assistance, evacuation plans and more.
CHAPTER 3. STAKEHOLDER ANALYSIS 7

3.2 Stakeholder Matrix

The stakeholders are evaluated on how much participation and influence they have in the project,
this is then displayed in the stakeholder matrix. Participation is determined from how affected
the stakeholders are by the project. Influence is how much the stakeholders can affect the
project.
The stakeholders’ influence and participation are assessed with the initiating problem in mind.
The matrix is dependent on how much such a software solution would affect the stakeholders,
and how big of an influence they have on the solution. The focus of this project is optimising
the emergency process by creating a piece of software to handle emergency situations. This is
therefore also considered when assessing the stakeholders’ positions.
Figure 3.1: The different roles of the stakeholders.

The stakeholders are distributed in the following categories:
• Hostages These are the people who have low influence but they are participants.
• Resource The resources are the people who have a high influence and high participation.
• Grey eminences This category has a high involvement in the project but has no partici-
pation.
• Externals These are neither participating or involved.
3.2.1 Justification of Stakeholders

The stakeholders’ placements will now be justified.
112-operators
The 112-operators are placed as grey eminences.
The 112-operators are handling the callers, and gather and sort the information needed to handle
emergency situations. Therefore, they have a high influence as their information is the base of
the emergency help process. Since the focus of this project is coordinating information in order
to dispatch help, the results of this report is assumed to not affect the 112-operators as they do
not handle the information after they have gathered it.
Callers
The callers are placed as hostages.
The reason why they are hostages is because they are affected by any change made to the emer-
gency process and are interested in having this process optimised. Therefore, they have a high
participation. The callers are not able to set any boundaries for what the result of their call will
be, they are only able to inform about the situation and not decide how to handle it, meaning
they have a low influence.
Emergency services
The emergency services are placed as resources.
Considering the initiating problem statement, the report is focused on the coordination of a dis-
patch. It is assumed that creating a piece of software for the coordination of a dispatch will
affect the emergency services’ process therefore, they have high participation. The emergency
services have to operate within certain guidelines, which have to be taken into consideration
when creating a solution, meaning they have a high influence on the project.
Operation control centre

The operation control centre is placed as resources.
Similar to the emergency services, it is assumed that creating a piece of software for the co-
ordination of a dispatch will affect the OCC, giving them a high participation. Since most of

the dispatch is controlled at the OCC, a program to aid this process needs to be able to work
together with their processes, meaning they have the highest influence.
From the presented arguments, the OCC is the most influential and participating stakeholder.
Because of this, it is important to understand the processes they are involved in regarding dis-
patch as these will provide the basis for the problem statement. Therefore, an interview was
made with Lars Bjørndal, chief of emergency management for North Jutland at the OCC in
Aalborg.
3.3 Interview
The interview was held on 25th February 2020, and consisted of a tour around the OCC, with
short interviews with the different operators, as well as a more in-depth, qualitative interview
with Lars Bjørndal.
The information gathered from the interview and tour is incorporated into the report and lays
the foundation for the problem analysis.
One of Lars Bjørndal’s primary points was the importance of managing resources between
the OCC and the emergency services. Therefore, the next chapter will analyse the current
emergency system in Denmark.

4 | Danish Emergency System Overview

The OCC system in Denmark is not a centralised system, instead it is made up of several sepa-
rate entities that work together to coordinate emergency help. The system consists of:
• AMK
• Municipality helpline
• Emergency management OCC
• Police OCC
• Falck
This can be seen in figure 4.1.
Even though the system is made up of many separate entities, they can in some cases be located
together. In Aalborg municipality, the shared OCC consists of: the AMK, municipality OCC,
emergency management OCC and Falck, which all operate from a shared location.
Figure 4.1: Flow of the OCC system in Denmark, as it was described during a tour of the shared
OCC in Aalborg.
CHAPTER 4. DANISH EMERGENCY SYSTEM OVERVIEW 11

4.1 Flow of OCC systems

Entities from the flowchart 4.1 representing the Danish OCC organisations are briefly explained
in this section.
112
The 112-operators never directly dispatch any emergency vehicles. They simply answer all
emergency calls and decide which organisation the information and/or call should be forwarded
to. This system makes it as simple as possible for the callers, since they never have to consider
what number to call for the specific type of emergency they are in.
Emergency Management
The emergency management OCC handles primarily fire incidents. They handle both fires re-
ported to the 112 and automatic fire alarms. In case of 112-calls, only the information given to
the 112-operator is forwarded, and the caller never talks directly to the emergency management.
With automatic fire alarms, all needed information for a dispatch is automatically sent to the
emergency management OCC and a fire engine is instantly dispatched automatically. An emer-
gency management operator will then call a contact person from the address of the fire alarm to
gather more information, and confirm whether or not there actually is an ongoing fire.
Any information gathered by the emergency management operator is forwarded to an on-site

commander. The on-site commander can view the information from a tablet while in the field.
This makes sure that the newest information is always available to those handling the emer-
gency.
Police
For emergencies that require police action, the 112-operator will in most cases forward the
caller to the local police OCC, where the incident will be handled and, if needed, police will
be dispatched. If the local police is very busy it is possible that the caller gets forwarded to a
different police station nearby.
AMK
112-callers can be forwarded to the AMK for medical guidance. This can happen in cases where
an ambulance is already dispatched, but there is need for guided first aid until the ambulance
arrives. In some cases no ambulance is needed and the emergency can be resolved with only
medical guidance over the phone.

General practitioners can also call the AMK directly if they have patients whose condition
requires an immediate ambulance transfer to a hospital.
Municipality Helpline
The municipality helpline coordinates help for the elderly or disabled citizens. This could for
example be an elderly person living alone who has fallen over, and is not able to get up on
their own. Most cases are handled by sending a home care service worker to the address, but if
necessary an ambulance can be dispatched.
The municipality helpline differentiates itself from the others in the fact that the callers do not
go through the 112-helpline, but instead call the municipality helpline directly as can be seen
on the left side of figure 4.1. They can receive both calls and alarms.
Falck Ambulance Service

Falck is a privately owned company and does not handle any emergencies themselves directly
from their control centre. They only manage and dispatch ambulances requested by the state
owned OCCs. It is also the task of Falck to make sure the entirety of Denmark has ambulance
coverage. This means that if a part of the country does not have emergency medical vehicles
within an acceptable range, one will be redirected to the area, even if there is no immediate
emergency.
This overview was produced through a tour of the shared OCC in Aalborg together with con-
versations with the employees at the municipality helpline, emergency management, Falck and
AMK stations.
During the tour and the interview, the emergency management was set into focus. The interview
revealed some of the difficulties with the systems for emergency management, and potential
solutions to these. Therefore, the focus will from now on be put on the emergency management.

5 | Emergency Management
In case of fire, natural disaster and other emergencies, the emergency helpline contacts the
Danish emergency management agency, and with the specific resources they have available
they will try to resolve the emergency. This chapter explains which resources are available to
the emergency management and how they prioritise emergencies.
5.1 Emergency Fire Management Resources

Emergency management is handled not only by the government and municipality, but also in
part by private companies. In Denmark, this is primarily Falck, which is privately owned, but
the company has a close connection with the public sector in Denmark.
The Emergency management has resources for almost every situation, and can help with ev-
erything from natural disasters to the cleaning of hazardous chemicals. The Danish emergency
management agency consists of firefighters and national servicemen. This means that they have
access to fire equipment, firetrucks and trained personnel, to help in stressful situations[10].
Falck plays a big part in firefighting, and they contribute with fire vehicles like water tenders,
ladder trucks and fire engines. Falck has a close relation to the OCC, and they will electronically
get the announcements of fire and traffic accidents, and thereby dispatch the right vehicles[11].
In all big emergencies that can cause hazardous situations, the Danish emergency management
will contribute with their help and resources. At the helpline for the capital of Denmark, your
call will be directed to personnel at the OCC, who will help in case of fires, by dispatching
emergency vehicles. In most cases with small fires or automatic fire alarms, the municipal
fire department will handle the situation by themselves. However, in bigger fires or big rescue
operations, for example with natural disasters, the dispatcher will organise help from fire de-
partments nearby, and the governmental fire department can help if needed[12].
Normally, the municipal fire department will be the first ones at the emergency site among the
police and ambulances, and if needed, the governmental fire department will come. They have
all the special equipment that might be needed in some cases. Most municipal fire departments
have one or a few small firetrucks, with limited crew. However, they are widespread over the
country and are therefore able to act fast, and be at the site in a matter of minutes, whereas the
governmental fire department can be there in a matter of one to two hours. The governmen-
tal emergency centres are placed in Thisted, Herning, Haderslev, Næstved, Hedehusene and
Allinge[13].
The various dispatch resources respond to different types of emergencies. Depending on the
severity of the situation, different vehicles are sent out, with or without sirens and lights. These
CHAPTER 5. EMERGENCY MANAGEMENT 14

types of emergencies are divided into different classes which will be described in section 5.2.
5.2 Priority Classes

In an emergency situation it is crucial that the help arrives on time, since a delay could mean the
difference between life and death. In case of a fire in a house, it can take less than five minutes
for the fire to completely engulf the building, and after just two minutes, the situation can be
life-threatening[14]. During these five minutes, the situation goes from a situation where it is
safe to evacuate the building to a dangerous situation that could potentially result in lives lost.
There are two classes of fire emergencies; emergency class one and emergency class two. No
matter what the emergency class is, the firetruck has to leave the fire department within 5 min-
utes of getting the alarm[15].
Class 1 Emergency
A class one emergency indicates that there is a fire, and it is important to reach the emergency
site fast. Vehicles going to a class one emergency will therefore use both sirens and lights. A
class one emergency happens whenever there is a fire.
Class 2 Emergency
A class two emergency happens whenever an automatic alarm goes off, and the fire department
has confirmed with a contact person that there is no fire, or it was an alarm failure. In this
situation, a fire vehicle will travel to the site to make sure everything is okay and under control.
Since it is not an emergency, it will use neither sirens nor lights.
Average Response Time

In the North Jutland region, the average response time for the fire department was 9 minutes
and 52 seconds in 2018[16]. The response time is defined as the time from dispatch to when the
first vehicle arrives at the incident.
CHAPTER 5. EMERGENCY MANAGEMENT 15

6 | Existing Software Solutions

This chapter will analyse the existing software solutions in the emergency helpline ecosystem,
and more specifically which software is used in the OCC, and how they work together.
Firstly, two of the biggest all-in-one solutions (IHM and CoordCom) will be described.
6.1 IHM
IHM is an emergency response system used in Denmark. It handles calls, dispatching and
resource management, while also giving recommendations for crew, equipment and vehicles
for each event. Primary features include[17]:
• Handling registration and archiving of incidents
• Automatic call-out of personnel
• Two-way communication with task forces
• 24/7 support
• Visuals of resources and geographic information systems
• Video surveillance
• Support for automatic alarms
6.2 Carmenta’s CoordCom

CoordCom is another emergency response system which is used in Sweden and other parts of
Europe. It is a comprehensive solution that covers elements from call taking, to case creation
and updating, to vehicle coordination[18]. Some of the notable features include:
• Distribution of calls between dispatchers
• Maps that can show nearby resources
• Realtime update of case information for everyone involved
• Support for telephone, radio and data communications
• Applicable to any existing communication infrastructure
• Extensions for advanced maps, API’s and communications servers designed for emer-
gency response
• 24/7 support
CHAPTER 6. EXISTING SOFTWARE SOLUTIONS 16

A variety of similar software solutions exist, with similar features. They show a focus on cre-
ating an overview and making coordination of resources as easy as possible, to lower response
time and possibility for failure.
Generally, a large part of their goal is to provide a simple to use solution that makes the dis-
patcher’s job as easy and quick as possible, while still making sure that they can relay all the
correct information to the people who need them.
A stable program is as much a priority for them, since even a little down-time can cause great
problems for the callers. Downtime can create a backlog of calls, which makes the dispatcher’s
job much harder and more stressful[18].
In order to make the dispatcher’s job easier, a number of tools have been developed to help with
various aspects of their job, which will be explored in the next couple of sections.
6.3 Location
When calling 112 to ask for help, one of the most important factors in getting help fast is being
able to quickly inform the dispatcher of your exact location. This is also why one of the first
things a dispatcher asks the caller about is their location[3]. It is very important for the helpline
to get this information quickly, so they can send the information to the OCC, in order get help as
fast as possible. However, sometimes a caller can have a hard time informing the dispatcher of
their location, either because of shock, being intoxicated or simply not knowing where they are.
This is especially prevalent during forest fires since it can be very difficult for the caller to know
exactly where they are in a forest[19]. In order to help in these situations, a technology known
as AML (Advanced Mobile Location) has been introduced to the Danish helpline software.
6.3.1 AML
AML is a technology developed in the UK by the telecom companies BT, EE and HTC in 2014,
which allows cellphones to find their location up to 4000 times more accurately than the stan-
dard at the time[20]. In July 2016, this technology was then natively implemented by Google on
more than 99% of all Android smartphones. This software, called ELS (Emergency Location
Services), is slightly different than AML, but it is essentially the same as AML just using native
Android location features, so it will be referred to as AML in the report[21].
It was then implemented into the Danish emergency helpline software ecosystem in 2019 on all
compatible android phones[6]. AML is turned on when the user calls an emergency helpline.
When this happens, the phone turns on all needed services in order to find an accurate location.
On Android, this location is found using their Fused Location Provider API, which uses a com-
bination of GPS, cell tower triangulation, wifi hotspot proximity, Bluetooth and potentially a
number of other sensors such as a barometer which will also be used if needed. This location
is on average accurate to a radius of 56 m, and takes an average of 4 seconds to calculate and

send to the dispatcher[22].
This information is sent using either Data SMS which sends the location data as binary informa-
tion over a subset of standard SMS, or as an HTTPS POST request which sends the information
in key/value pairs over the internet[22]. Of these two, Data SMS is the most reliable since it
does not need an internet connection, however it is more difficult to setup the needed infrastruc-
ture, compared to the HTTPS POST request.
In the event that a location cannot be found, AML will send the last known location of the
device. In the case that the user has had all location tracking technologies turned off, this will
not exist and a NULL location will be sent. However, this very rarely happens as the calling
device needs a cell phone signal to call which requires it to be in contact with a cell tower.
Using this cell tower will almost always be able to give a rough estimate of the caller’s location
(around 3 km radius)[23].
6.4 GIS Software

A large part of the existing software solution is heavily dependant on Geographic Information
Systems (GIS) to give the dispatchers at the OCC an overview of all their resources. GIS
software is a general term for a software that displays information as multiple layers over a
map. One of the most well known examples of this is Google Maps displaying points of interest
when looking at an area, as can be seen in figure 6.1.
Figure 6.1: Example of a GIS showing points of interest in Aalborg centre[24].

GIS works by splitting a map up in several layers. An ex-

ample of this is on Google maps, where one of the layers is
the street map in the background, and on top of that layer
there is a layer displaying points of interest. This layering
principle is visualised in figure 6.2. Here, five layers are
shown with the satellite data on the bottom, going all the
way up to points of interest on the top layer. The advantage
of using layer maps is being able to quickly and efficiently
change which information you want to look at since only
one layer needs to be added instead of having to change the
Figure 6.2: Visualisation of lay- entire map[25]. In the case of the OCC software, this tech-
ers in a GIS software[25]. nology is used in collaboration with AML to display where
incidents occur on the map, producing a dot on one of the
layers giving the dispatcher an easy to process overview of where incidents are occurring. Out-
side of this use case, GIS is used extensively in the OCC for managing resources, like vehicles
and fire hydrants[2].
6.5 Operational Digital System

The emergency management uses a system called the Operational Digital System (ODS). This
is a system of procedures (operative plans) for various kinds of emergencies, for quick access
by anyone both in the operator end and in the field. It contains both quick-read instructions
and much longer write-ups about the details and background for the procedures. This lets the
operator provide details to the units in the field and also helps as a universal guide for what to
dispatch and the general procedures in the OCC. The system is not integrated with their GIS
system, so the dispatcher is forced to remember or figure out which procedures are relevant
for each location or address, and then relay this information. This can cause problems if the
dispatcher does not know or can not remember details of a location or that no information is
available for the specific location. This can result in the task force not getting the resources they
need for a specific situation[2].
6.6 Multiple Calls

When larger incidents and disasters happen, the amount of calls to the emergency helpline can
increase drastically. One example of this is during the act of terror in Stockholm 2017, where a
man stole a truck and drove it into the crowds at a shopping street[26]. The emergency helpline
received 700 calls about the incident within the first two hours, which is twice the amount of
calls of a normal Friday night. This amount of calls requires a high level of coordination in
order to send the right help in time.

The emergency helpline uses the location of the incident to identify what calls belong to the
same incident[2], e.g. if two calls concern a fire in the same building, they are considered to
be the same incident. When the helpline forwards the information to the OCC, they include a
note that indicates that this call concerns an already existing incident, and the location pops up
on the OCC’s GIS software map. The OCC then decides if additional help needs to be sent out.
Because of this, the OCC’s process of handling multiple calls is relatively straightforward and
usually does not cause any major problems, in part due to the GIS map[2].
These software solutions cover a great deal of problems, and are quite efficient at helping the
operators do well. There are, however, still issues in the systems, especially as pointed out in
the interview, that could still be fixed. Chapter 7 will discuss these remaining problems and end
with a problem statement covering the most relevant one for this project.

7 | Problem Delimitation
From the problem analysis it is evident that the Danish emergency system has a good infras-
tructure, but that it is not without flaws. In the interview, Lars Bjørndal mentioned some of the
flaws with the emergency management. He mentioned that it is a problem for the firefighters
and the operators to get statistics about water usage and response time, among others. He also
mentioned that their operative plans, which they use in emergencies, are not always directly
available to the operator, and thereby the on-site commander. This leads to bad judgement of
situations, and Bjørndal even mentioned that it once cost them 8 million DKK, because they
used their equipment on the wrong side of the building.
Because of this information and the interview with Lars Bjørndal, the focus was put on the
emergency management. The problems mentioned in the interview are examined in section 7.1.
7.1 Defining the Problems

There were three main problems mentioned in the interview; prioritising valuables at the emer-
gency site, forwarding important rescue information to the on-site commanders and having an
overview of the rescue vehicles.
Value Priority
In big fires where it is necessary to have an operative plan, the on-site commander needs to
know if the building on fire contains anything they should be worried about or that they should
focus on saving. It could be a big company with a big and expensive inventory, e.g. a medic-
inal firm with valuable medicine, or a farm with animals. Many places like these have rescue
plans for their buildings, telling the rescuers what to save. However, many of these plans are
not accessible to the emergency management, and thereby not something that is available to the
on-site commander on the emergency site. This means that the on-site commander has no way
of knowing what they should focus on.
On-site Commander Plan

In emergencies it is crucial that the situation is judged appropriately, and thereby it is crucial for
the on-site commander to know about any worries of hazards on the emergency site. This could
for example be if there is fire at a retirement home, where there might be oxygen tank users.
This could provide a dangerous situation for the firefighters, and they need to take care of this
early in the firefighting process.
This information needs to be easily accessible to the operator, so they can transmit the infor-
mation to the onsite commander. These operative plans should consist of whether or not there
are hazardous environments, or a need for special equipment that could be useful at the emer-
gency site, among others. As it is right now, the operator has to know that these operative plans
with this crucial information exist, and they have to remember which plan is correct for a given
CHAPTER 7. PROBLEM DELIMITATION 21

emergency situation, because the system is not able to tell them.
Vehicle Overview
In some emergency situations, special equipment and vehicles are needed. As it is now, the
operator can search for vehicles, to see if they are available or not. However, it is not possible
for the operator to directly search for specific vehicle traits. This leads to a time consuming
process. With the current system, the operators have to remember what resources they have
and which they do not, and they have to know what equipment would be helpful in the specific
situation, because the system is not able to tell them.
7.2 Choosing the Problem

Now that the problems are defined, they are evaluated and the focus of the report is chosen anew.
The initiating problem statement says:

How can a software solution help to organise information to coordinate a dispatch of emer-
gency services.
By looking at the problems in section 7.1, it is visible that the emergency management has
several problems that could be solved by software. The value property problem and the on-site
commander plan problem seem like problems that if solved properly could positively affect how
emergency services are organised and dispatched, and how the emergency is handled. These
problems also have a connection with each other, and can thereby effectively be solved with
one piece of software.
Because of this, on-site commander plan and the value priority are chosen to be the most rel-
evant problems in this project. Since it is asserted that they can be combined and solved by
one solution, the focus of this report is therefore the on-site commander plan and value priority
problem.
7.2.1 Necessary Technologies

The requirements of this problem makes a network based approach appropriate. Data will need
to be sent between users and updated live. Creating the program as a web application, using
JavaScript and a Node.js backend, will allow easy communication, and updating of maps and
case information using the extensive libraries and network functionality in the language. This
makes it easy to support the tablets used in the field, with responsive design which can be
implemented using HTML and CSS.

7.3 Problem Statement

As a result of the preceding problem analysis and problem delimitation it is now possible to
formulate a problem statement that will guide the progress of this report.
The problem statement is formulated as:
How can a platform be designed that notifies and presents operators and on-site
commanders with important information relevant to the locations of ongoing emer-
gencies?

Part II
Problem Solution
24
8 | Software Design
The current software used by the emergency management is, as explained in chapter 6, heavily
based on the use of GIS software. Therefore, the solution in this report will also be based on
GIS, to create a piece of software that integrates well into the OCC software ecosystem and is
easily accessible by current employees of the emergency management.
The software, and its information, needs to be easily available to both the operators at the
OCC and the on-site commanders out in the field. The OCC staff use desktop computers and
the on-site commanders use tablets. Because of this discrepancy in hardware usage, a web-
solution would be ideal since it can easily run on both systems without much system specific
modification.
8.1 Program Requirements

The potential features of the program have been divided into three categories, prioritising the
development to make sure at least a basic solution is completed. The three categories are need-
to-have, want-to-have and nice-to-have.
The need-to-have requirements are the features that are necessary for the program to solve the
problem. The want-to-have and nice-to-have requirements are features that make the program
easier to use, as well as adding extra functionality. The difference between these two categories
is the priority level, where the want-to-have requirements have a higher priority than nice-to-
have. This is because the want-to-have requirements have a higher relevance for the problem.
Need
The need-to-have requirements include having a map with GIS where the operators can see
which locations have operative plans. This means that when there is a fire at a location, the
operator will be notified of the operative plan automatically. In order for this to function, the
program needs to be able to receive the emergency location of the incident.
The program will operate in a browser, with necessary data stored in a server-side database. Fur-
thermore, the operator and the on-site commander should have an interface where the relevant
information is displayed.
• Receive emergency locations from an external source
• Server and database to store map, location and emergency information
• Display the received emergencies on a map interface with GIS overlay
• Web based client-side app for on-site commanders and operators
CHAPTER 8. SOFTWARE DESIGN 25

Want
When the need-to-have requirements are met, the next priority is to look at the want-to-have
requirements. This includes features that make the program easier to use, such as having an
aesthetically pleasing layout, being compatible with tablets and having information that is easy
to read in a high-pressure environment. Furthermore, a feature that enables the operators to
decide which information is sent to the on-site commander would mean that the commander
only gets the information that is necessary for them, instead of having to sift through large
amounts of information.
Having a feature where the companies themselves can enter their operative plans would increase
the amount of plans available to the emergency management.
The nearby hazards feature means that the operator can view any potential hazards close to the
incident, such as buildings containing highly flammable materials. Based on the operative plans
for the location of the incident, as well as nearby hazards, having a feature that prioritises the
relevant information to the operator would make their job easier.
• Information should be made easy to read and overview
• Ability for companies to enter operative- and escape plans
• Tablet compatibility for a better experience for on-site commanders
• Software notifies of any potential nearby hazards
• Information shown is prioritised by importance
• Operator/OCC is able to curate what information is mission critical and most important
• Easy to understand interface with responsive CSS
Nice
Lastly, if the want-to-have requirements are met, the nice-to-have requirements can be looked
at. These include being able to search for vehicles using vehicle traits. This would require the
vehicles to have the appropriate metadata.
• Searchable database of available emergency vehicles
• Vehicle metadata according to their specific equipment

8.2 Web Interface

To further specify the look, features and workflow of the program a sketch of the web interface
has been made, illustrating a possible final design for the program.
One part of the program is the client-side used by the operators, shown in figure 8.1.
Figure 8.1: Sketch of client-side web interface for operators.
The left side of the program displays the map, where the ongoing emergency is shown with a
location marker. Here, the operative plan is displayed with a pop-up, and when clicked, it is
shown in a bigger format on the right side of the program. At the bottom of the operative plan
are blue links used for further actions, when necessary.

The other part of the program is the client-side used by the on-site commanders, shown in figure
8.2.
Figure 8.2: Sketch of client-side web interface for on-site commanders.
In the top left, there is a summary of the main points from the operative plan concerning fires
involving dangerous fumes, including the most important things that the on-site commander
should be aware of. There are also call-to-action links for e.g. getting additional resources.
In the top right, the operative plan for the current location is described with short points, marking
the most important part of the plan. This plan is provided by the owner of the address, and is a
plan for this specific address, to further specify the general plan to its right. Focus is especially
on specific hazards and extinguishing priorities.
The bottom part of the program displays the floor plan for the building, escape routes as well as
an overview of where the most notable areas are, e.g. valuable items that should be prioritised.
8.3 Program Structure

A flowchart has been made in order to give an overview of the flow of the program.
When the server receives an emergency from either the 112-operator or an automatic fire alarm,
the GPS-coordinates for the location is retrieved. The server has to find any building attached to
those coordinates and search the database for the building to find any available operative plans

or nearby hazards for the address. All this information is then sent to the two clients.
On the operator client the coordinates are then displayed on the map as a marker. If the marker
is pressed, the program retrieves the operative plans from the server, and displays them in a text
box together with the nearby hazards if there are any.
The on-site commander client displays the same overview of the operative plans. But instead
of a map displaying the current fires, the floor plans of the building are displayed, together with
the area plans to give an easy overview of the building.
Figure 8.3: Flowchart of program structure

8.3.1 In Depth Program Flow

The information about the incident is received from the emergency helpline by the backend.
The coordinates then gets linked to a building, from which the operative plans for that specific
building and nearby buildings are fetched from the database. This process can be seen in figure
8.4.
Figure 8.4: Flowchart over the whole program.

Data management and frontend flowcharts can be seen in figure 8.5 and 8.6 respectively.

The coordinates are then sent to data management, where it checks for nearby hazards (see
figure 8.5). If any hazards are found, they are sent back to the backend where it is forwarded to
the frontend along with the operative plan. Figure 8.5 also shows the process of the input client,
where new operative plans are uploaded. The operative plan is input in the JSON database at
the right location using binary search.
Figure 8.5: Flowchart over the the data management portion of the program.

The fetched operative plans are sent to the frontend, where the map data from the coordinates
are read, and an interactive marker points to the specific location, and highlights the affected
building. When the marker is clicked, an info box containing the necessary information about
the site of the incident and nearby locations are shown to the operator. The operator can assign
a fire to a specific commander, who can then see it on their tablet. On this tablet there is also a
resolve fire button which will delete the fire, and refresh the frontend (see figure 8.6).
Figure 8.6: Flowchart over the frontend portion of the program.

9 | Implementation
This section will introduce how the code is implemented. This includes how the different user
interfaces have been designed in the frontend part, and how the backend handles building poly-
gons, the operative plan database and the Node.js server, including the implementation of the
map layout and the GIS layer. This section also contains the performance of the frontend and
backend parts.
9.1 JavaScript Introduction

JavaScript is a highlevel object-oriented programming language that compiles at runtime. It is
widely used for web development to make websites dynamic and interactive using the built-in
DOM (Document Object Model) browser API[27].
Node.js enables JavaScript to run outside of the browser, making it possible to have both the
browser client and the backend server running on JavaScript. It is, however, important to note
that there are some differences between JavaScript in the browser and Node.js. This distinction
is important for a couple of reasons. One is the fact that Node.js has a module import system,
whereas JavaScript in the browser relies on the HTML file to load all the needed JavaScript
documents. Another reason is that the browser JavaScript is run in a sandbox mode for security
reasons. This limits the language’s functionality to web based actions, meaning that the browser
JavaScript for example cannot easily access the computer’s file system[28].
The files in the program are structured according to functionality in a way that makes them easy
to find. The JavaScript files used by the server are placed in the root folder since this is neces-
sary for the server to access them. The PublicResources folder, and its categorised subfolders,
is the default case for the GET requests, which makes all its files accessible by the browser.
Furthermore, the database files are grouped into the folder called Data, for organisational pur-
poses.
9.2 Frontend
The frontend is comprised of three interfaces, each with their own use. There is an interface
for the operator, the commander and an input interface for use by the building owner to upload
operative plans. These interfaces and their use will be described more in-depth in this chapter.
9.2.1 Operator Interface

Making decisions based on the data from the operative plan requires the operator to be able
to see this data. The frontend of the site therefore has to display all the relevant information
CHAPTER 9. IMPLEMENTATION 33
in an easily digestible way. This is done through a GIS map, created using the Leaflet [29]
framework, overlaid with markers for currently active fires. The position of these markers is
based on data fetched from the backend, which keeps track of current fires and provides all
relevant information to the frontend. When clicking a marker, the relevant information will be
displayed in a box on the right, divided into collapsible sections with information about the
location, and an option to download the full operative plan. This also causes the building’s
outline to be drawn on the map, in order to make it easier to see the building. The operator can
assign a fire to a commander by selecting one in the drop-down list.
The initial sketches for this interface can be seen in figure 8.2 and 8.1. Figure 9.1 shows the
implemented operator interface.
Figure 9.1: Operator frontend
Leaflet
Leaflet is a map framework for JavaScript, enabling easily customisable and interactive maps,
with just a few lines of code as seen in figure 9.2. While leaflet does not provide its own map
data or image tiles, many other services like the API based tiles from Mapbox do[30].
Figure 9.2: Code necessary for interactive map
Leaflet has support for adding markers and polygons to the map using data in the GeoJSON
format, which is simply fetched from the backend as necessary.
Layers
Leaflet has a feature called layers, which allows the developer to gather multiple elements of
the same type, and output them all in a specific format, like creating markers from GeoJSON
elements. This whole layer can then be applied to the map at once, so all the features and settings
of each element can be done as it is created. Layers are also used in displaying polygons when
outlining a building on the map.
Displaying Properties
Using Leaflet’s "OnEachFeature" function on the marker GeoJSON layer, a mousedown event
is added to each marker, as they are created on the current fires. When clicking a marker, the
data related to the fire is displayed. Since the data is stored in the marker itself, it can easily
be displayed as Fire Info. Then the information related to the building and its operative plan is
fetched from the server. All of this data is stored in GeoJSON format, which is essentially just
JSON, so JavaScript can easily parse it and work on it like an object. Data from the operative
plan is written to the site in a box with collapsible sections. Next, a polygon is created on the
map using Leaflet’s "polygon" function, using the building’s corner coordinates. This adds the
coordinates to the polygon layer, which is then added to the map.
Fetching Data
Fetching data from the server is done through simple Fetch requests. Requesting "/fires" pro-
vides a full GeoJSON file, containing information for every single active fire, for easy addition
to a GeoJSON Leaflet layer, which can be iterated on and applied to the map. Requesting "op-
erativePlan = coordinates" provides the specific operative plan for the location in JSON format,
so that each relevant data point can be displayed to the operator easily.
Live Updating the Map
The map automatically updates with new fire markers as soon as the backend server receives a
new fire, or a fire is resolved by a commander. To allow for this, the server notifies the frontend
client every time there is an update to the database of current fires. This is done by establishing
a websocket connection between the backend server and any frontend clients. The server then
broadcasts to all connected clients every time an update is available, at which point the client
will make a request for a new version of the file containing active fires.
When live updating, only the leaflet layer containing the markers are updated to make the up-
dates as seamless and responsive as possible.
Assigning Commanders
Assigning commanders is done through a dropdown menu on the operator frontend. The drop-
down list updates and shows only currently active commanders by making a GET request to
the server for the list of active commanders. By clicking a commander from this dropdown the
operator selects that person as one of the active commanders of that fire. While it is possible
for several commanders to be assigned to a single fire, the program will not allow a single com-
mander to be assigned to multiple fires. Once a commander has been assigned a fire, a POST
request is sent to the server updating that commander’s current fire. This current fire is then
what will be presented to the commander as described in section 9.2.2.
9.2.2 Commander Interface

The interface for the on-site commander is designed to give the most valuable information
about the emergency. When the commander logs into the site, the forwarded information from
the operator contains the operative plans for the building and the floor plans, which will be
displayed as images (see figure 9.3).
The info box on the commander interface is implemented using the same code base as the
operator interface. The only difference is that the operative plan is fetched according to the
commander’s assigned fire and not a clicked marker.
Figure 9.3: Commander frontend
Commander Login
The commanders are able to log in to their specific site, to see the fires they need to attend. The
login system works by entering a specific ID number which is connected to each commander.
By entering this ID number, the page will load fires that have been forwarded from the operator.
This works by using a JSON database, where all the ID numbers are stored along side names
for the commanders. When an operator forwards fire information to a specific commander from
the menu, the coordinates from that fire will be stored alongside the ID of the commander,
so that when the ID is logged into, the operative plan connected to the coordinates will be
fetched from the operative plan database and shown on the commander interface. Once logged
in, the commander then has the option to resolve the fire which will remove it from the active
fire database, and unassign all commanders assigned to that fire, making them available for
reassignment.
9.2.3 Input Client

In order to get as many operative plans as possible in the system, a client has been developed
that will allow institutions and companies to input their own operative plan into the database.
The client is a web page, as can be seen in figure 9.4, where the institution will input their
geographical coordinates, their address, some short information about their building, which
fire fighting equipment they have, some special considerations and finally a PDF document
containing their entire operative plan.
This form is then sent to the server where it is stored in the database using the binary input
algorithm described in section 9.5.
Figure 9.4: Client for uploading operative plans
Coordinates by Map
To make it easier for the user to upload operative plans, a clickable map was implemented.
When a building on the map is clicked, it is highlighted and its coordinates are inputted into the
coordinate fields. Likewise if coordinates are typed into the coordinate fields manually by the
user, the map also highlights the building registered on those coordinates to lessen the risk of
mistyped coordinates.
The map is a Leaflet map initialised and controlled the same way as the main map described for
the operator frontend in section 9.2.1. The highlighted building is also achieved by calling the
inside building function as is done on the operator frontend in section 9.2.1.
9.3 GIS as GeoJSON

When implementing the map user interface with Leaflet.js, the fetched map tiles are only PNG
images, meaning they contain no information about what is actually on the map. For the pur-
pose of this program, we need to know exactly where each building is on the map. In order to
make this possible, a GIS layer for the map containing all buildings is needed.
OpenStreetMap does not provide this directly. However, services such as GeoFabrik.de extracts
GIS layers from OpenStreetMap daily. These can then be downloaded as shape-files and loaded
into a GIS application to overlay the map with information as can be seen in figure 9.5.
(b) OpenStreetMap with buildings shape-

(a) OpenStreetMap map tiles only
file GIS
Figure 9.5: Illustration of the use of GIS shapes for map information
However, neither JavaScript nor Leaflet.js has support for shape-files. Instead, existing GIS
software allows for loading shape-files and exporting them as the GeoJSON file format. Geo-
JSON is essentially GIS shapes stored as JSON (listing 9.1) making it fully supported by both
JavaScript and Leaflet.js.
1 { " type " : " F e a t u r e C o l l e c t i o n " ,

2 " name " : " G E O J S O N _ E x a m p l e " ,
3 " crs " : { " type " : " name " , " p r o p e r t i e s " : { " name " : " urn : ogc : def : crs : OGC :1.3: CRS84 " } } ,
4 " features ": [
5 { " type " : " F e a t u r e " ,
6 " properties ": { " osm_id ": " 461446516 " ,
7 " code " : 1500 ,
8 " fclass ": " building " ,
9 " name " : null ,
10 " type " : null } ,
11 " g e o m e t r y " : { " type " : " M u l t i P o l y g o n " ,
12 " coordinates ": [ [ [
13 [ 10.1317328 , 56.9933169 ],
14 [ 10.1317674 , 56.9934513 ],
15 [ 10.1319206 , 56.9934396 ],
16 [ 10.131886 , 5 6 . 9 9 3 3 0 5 1 ] ,
17 [ 10.1318194 , 56.9933102 ],
18 [ 10.1318096 , 56.9932724 ],
19 [ 10.1317348 , 56.9932781 ],
20 [ 10.1317446 , 56.993316 ],
21 [ 1 0 . 1 3 1 7 3 2 8 , 5 6 . 9 9 3 3 1 6 9 ]]]]}} ,]}
Listing 9.1: GeoJSON Example
9.4 Node.js HTTP Server Backend

For the client-side software to be able to communicate meaningfully with a server, a method for
handling requests is needed. For the implementation of this project, the server was created using
Node.js and therefore the Node.js HTTP package was used to handle requests. The server is
initialised with the createServer() function built into the HTTP package, which takes a function
as a parameter. The parameter function contains all the request routing for the server.
This program only handles GET and POST request methods. Each request method is handled
by its own switch case which switches on the request url, with a case for each expected request
path and a default case for any requests to unexpected paths. Requests are being sent to the
correct switch case that corresponds to their method through two if-statements. Once the server
is initialised, it is set to listen to the desired port and host name using the listen function from
the HTTP package.
GET Requests
GET requests are all the requests trying to retrieve information from the server, which means
that the request does not contain any data for the server in the body. The response from the
server to a GET request should always contain some amount of data in the body if the request
is successful. A diagram of the POST request routing can be seen in figure 9.6.
Figure 9.6: Diagram of HTTP GET request routes.
’/’
Serves the frontpage (index.html) for when the website is accessed with no extra path. This is
done via the function call fileResponse(index.html, response).
’/uploadOP’ & ’/commanders’

Similarly to the frontpage case, these two cases just serve their corresponding pages for upload-
ing operative plans and the commander overview page respectively.
fileResponse() works by taking in a file name and a response object. The function tries to read
the given file using the File System module and returns a response with the file’s content. Should
the file read fail, the response will instead contain the error encountered by the file read attempt.
’/fires’
Returns a response with the JSON data contained in the file, keeping track of all current ongoing
fires by again calling the fileResponse() as before, but this time instead with the GeoJSON file
of current fires.
’/operativePlans=n;n_n;n’
This case is used to find the operative plan for a set of coordinates. The request looks as follows:
(request.url.match(/^\/operativePlans=
\d{1,};\d{1,}_\d{1,};\d{1,}$/) || {}).input
This case is quite different from the other cases in the switch statement, since it needs to accept
requests for all coordinates as long as the request is in the correct format. If the url passes the
regular expression test, the case is set to the input string of the regular expression test, meaning
the original request url. This means that the case is now equal to the request url and so the case
is run. If the regular expression does not find a match, the case is instead set to be empty, which
is of course not equal to the request url and so the default case will run instead.
The regular expression will accept any string of the following form:
’/operativePlans=n;n_n;n’
where n is an integer with a length of one digit or more.
An example of an accepted request url could be ’/operativePlans=51;34_7;5’, which would re-

trieve any operative plans for the coordinates (51.34, 7.5).
The case returns the operative plans for the coordinates in JSON, if the operative plan exists, as
well as the building’s metadata and any warnings of nearby hazards. This is done by calling the
function sendOperativePlan(), which in turn calls a number of different functions (see figure
9.7).
Figure 9.7: Order and dependency of function calls in sendOperativePlan function.
The first function that is called inside sendOperativePlan() is insideBuilding(), where the pro-
gram finds the metadata for the building in question in the GeoJSON-file. This is done by
checking if the given coordinates lie within a building’s area on the map, which is described
in section 9.4. The GeoJSON-file contains the metadata for every building on the map, and is
therefore very long. In order to prevent the program from searching through all of the thousands
of buildings, an if-statement has been implemented with the condition that the building’s X and
Y coordinates must lie within a 500 meter range from the coordinates we want to find. This
distance has been chosen since a building typically is smaller than 500 meters.
This is done by calculating the difference between the X and Y coordinates of the two sets of
coordinates. If the difference is less than 0.005 (i.e. 500 meters), the functions described in
section 9.4 are called.
Using the forEach-method on the array containing the data from the GeoJSON-file, the program
goes through every element in the array. If it finds a building that matches the given coordinates,
the function returns the building’s name and type, the index of where the building is located in
the GeoJSON-file, the coordinates that are associated with the operative plan as well as the co-
ordinates needed to draw the building’s outline on the map. This data is returned as an object,
to make it easily accessible to the sendOperativePlan() function.
Next, the function binarySearch() is called, which is described in section 9.5. This function is
used to find the index of the coordinates in the sorted array of operative plans.
If the binarySearch() function could find an operative plan for the coordinates, the function
NearbyLocation() is called. This checks if there are any buildings within a range of 500 me-
ters that have an operative plan. Since the array containing the operative plans is sorted by
coordinates, the program first calls a function that checks the operative plans that have an in-
dex greater than the index returned by binarySearch() and where the X and Y coordinates are
±0.005 from the starting coordinates. The function is then called recursively, until it reaches an
operative plan that does not fit these conditions. Each operative plan that matches the conditions
is concatenated into an array, which is returned to NearbyLocation(). A similar function is then
called, which does the exact same thing, only with operative plans that have a smaller index.
NearbyLocation() then concatenates the results from these two functions, and returns it as an
array to sendOperativePlan().
Once all of the information has been found, sendOperativePlan() returns an object that contains
the operative plan, metadata and any nearby operative plans.
’/commanderList’
commanderList returns a list of currently active commanders that can be assigned by the oper-
ators. This list is then used to create a dropdown menu on the operator site.
POST requests
Contrary to the GET request, a POST request contains the data that it intends to send to the
server. In this case, it is often enough for the server to simply respond with a confirmation that
the request has been received and handled. A diagram of the POST request routing can be seen
in figure 9.8.
Figure 9.8: Diagram of HTTP POST request routes.
’/fireAlert’
This case has the task of receiving new fires which are afterwards added to the list of active fires.
The request contains the information of the fire in binary form and therefore has to be parsed
before the data can be processed. To avoid errors due to the rest of the function continuing
asynchronously before the parsing is done, the parsing is done as a Promise and the rest of the
function is called in the Promise’s .then(), which is only run after the Promise is resolved.
To avoid duplicate fires and to enable the ability to update already existing fires with new infor-
mation, the function needs to know if a fire is already on the list of fires. This is checked using
the function entryExist().
In order for entryExist() to search the list of fires, which is contained within a JSON-file, it has
to be parsed to an array. The JSON is read to a string using the File System Module and then
parsed to an array using the Node.js JSON.parse function.
entryExist() searches each element in an array for the existence of a specified entry using a forE-
ach call. The function returns an object with a Boolean of whether or not the entry was found
and the index of the entry. If the entry was not found, the index returned will be undefined.
The function uses two if-statements to check if it should add a new entry, delete an entry or do
nothing. If the received fire is active and not on the list, the list should be updated with the new
fire. However, if it already exists in the list, the list is up to date, and no action needs to be
taken. If the received fire is not active, but exists in the list, it should be deleted from the list.
Entries are deleted using the array prototype function .splice() and entries are added to the list
using the array prototype function .push(). In both cases the JSON-file is updated afterwards
using the File System function writeFile().
’/addOpPlan’
This case receives a form sent via the input client described in section 9.2.3. This case calls a
function handleOpPlan(), which uses the Formidable library to catch the form and load it into
a JavaScript object. This object is then inputted into the database via the binary input function
described in section 9.5. Lastly, the coordinates related to the operative plan are inserted in the
building’s array in the GeoJSON file. This means that the operative plan is connected to the
actual building, rather than the specific coordinates entered when uploading the operative plan.
Because of this, the building’s operative plan will be displayed regardless of which coordinates
are used for registering a fire, as long as they are inside the building.
’/assignCommander’
When the operator assigns a commander to a fire, that assignment is sent to the server using
’/assignCommander’. On the server end, the request is handled by updating the commander’s
entry in the JSON file containing all commanders, with the new active task in form of a fire ID
for the fire.
’/RemoveFireFromCommander’
Like /assignCommander the server updates the commander’s entry in the JSON file containing
all commanders. But instead of assigning a new active task, the current active task is unassigned.
’/validateInside’
A request containing a set of coordinates. The server then checks if the coordinates are inside
a building using the insideBuilding() function. If the coordinates are inside a building the re-
sponse body is set to return a true result and an array of the building polygon’s points, otherwise
the response body is set to a false result.
Inside Building Algorithm

Each building is represented by a polygon on the map, where each corner has a pair of coordi-
nates. In general terms, to check if a point lies within a polygon, you first draw an infinite line
from the point in an arbitrary direction and then count how many edges of the polygon that the
line crosses (see figure 9.9). If this number is uneven, the point lies within the polygon, and if
it is even, the point lies outside of the polygon[31].
Figure 9.9: The amount of edges crossed is even when inside the polygon, and uneven when
outside.
This is done using three main functions in the program. The first function checks the orientation
of three points in relation to each other, using the formula in figure 9.10. The formula calculates
and compares the size of the areas underneath and above the centre point. If these areas are
equally large, all three points are collinear. If the areas have different sizes, the points are
oriented either clockwise or counter clockwise.
Figure 9.10: Finding the orientation of point q relative to points p and r, using their X and Y
values.
The second function checks if two line segments (A and B) intersect, using the formula de-
scribed in figure 9.10. Since each line segment consists of two points, the formula is called
four times in order to compare the orientation of all point combinations. This function has three
types of result cases. The first case is that the orientations of the points in A in relation to B (or
vice versa) are different. This means that A and B intersect, as shown in figure 9.11.
Figure 9.11: The orientation of point q lies counter clockwise to line segment A, and the orien-
tation of point r lies clockwise.
The second case is that the result of one of the orientation function calls returns 0, i.e. three of
the points are collinear. This means that A and B might intersect. To check if they do, a third
function is used, which looks at the maximum and minimum values of the coordinates of the
three collinear points, in order to find out if one of the points lie between the other two points.
If so, the lines A and B intersect.
The third case is that neither of the above two cases are true, i.e. the orientations of the two
points in A or B are the same and no points are collinear. This means that A and B do not
intersect.
The program uses a for-loop that calls these three functions using the coordinates from a build-
ing on the map as well as the coordinates for the point we are trying to locate and an ’infinite’
point. The infinite point is created by using the Y-coordinates from the point that we want
to locate and an X-coordinate of 1. This has been chosen to represent infinity, since one X-
coordinate on a map represents ~110 km and all buildings on the map are highly likely to be
shorter than 110 km.
The for-loop counts how many of the lines intersect. If the number of intersects is uneven, the
point lies within the polygon, and the building has been found.
9.5 Database Management

Because the program potentially has to handle large amounts of data if a large amount of oper-
ative plans are uploaded, it is important to handle the data efficiently to ensure good scalability.
Binary Search
This part of the program runs through the database containing the operative plans for certain
buildings and locations. When the input of a fire comes from the emergency helpline to the
OCC, it will have the coordinates of the location of the fire. With these coordinates, the pro-
gram can make a binary search through the sorted database, and collect the matching operative
plan. The binary search works by dividing the database by a startIndex and an endIndex. These
two are divided by a middleIndex, which divides them in the middle using the floor method if it
is an uneven number. This division can be seen in figure 9.12. The program will then compare
the target coordinates with the middleIndex. When compared, it will look at the value of the
coordinates in the middleIndex. If the value is less than the middleIndex, the endIndex will
be set to middleIndex-1 and a new middleIndex is calculated. Similarly, if the target coordi-
nates are bigger than the middleIndex, the new endIndex is middleIndex+1. Thereby the binary
search function continues with slicing the chosen index into middle-, start- and end- indexes
and comparing the values, until it finds one that is equal to the target.
Figure 9.13 and 9.14 shows how the division occurs. In figure 9.13 the number 5 is now being
searched in the startIndex. Again, the middleIndex using floor is found and compared with the
number 5. It has not been found yet, and another division occurs. Figure 9.14 shows that the
number 5 now has been found. If the binary search never finds the target coordinate, it returns
a false value.
Figure 9.12: The number 5 is being searched for.

5 is being compared to the middle index containing the value 9.
Figure 9.13: Since 5 is smaller than 9, the left side of the middle index is being searched. Now
the number 4 is the middleIndex.
Figure 9.14: Since 5 is greater than 4, the right side of the middle index is being compared.
5 is equal to 5, and the searched number has been found.
Binary Input
As it is important to have operative plans for all buildings and properties, companies and prop-
erty owners are able to input their own operative plans, so that they are available to the fire
department. The new, entered operative plans will be input into an already sorted data array.
Therefore, it has to be inputted correctly so it fits into the sorted array. The program uses binary
search to search for the right placement of the new operative plan. This works the same way as
normal binary search, which is shown with figures 9.12, 9.13 and 9.14. A small difference be-
tween the binary search and the input function, is that it is not looking for a specific coordinate.
The binary input will keep searching through the array by dividing it into smaller pieces and
comparing the values, until it is as close to the input value as possible. This is shown in figures
9.15, 9.16, 9.17 and 9.18. It will then compare the coordinate next to the placement it has found
as shown in figure 9.19. The program will go one step to the right, and see if it is bigger than
the new value inputted. When the value to the right is bigger than the new value, the program
will input the new operative plan to the left of the value that is higher, and move all elements to
the right of the new operative plan one index to the right as shown in figure 9.20. If the value
found is smaller, the same will happen just to the left instead.
Figure 9.15: The value 9 is being inputted into the sorted array.
First a binary search through out the array is done, giving a good idea of the placement.
9 is found to be smaller than 10.
Figure 9.16: Since 9 is smaller than 10, it checks the middle index to the left. 9 is greater than
5.
Figure 9.17: Since 9 is greater than 5, it checks the middle index to the right. 9 is greater than
7.
Figure 9.18: Since 9 is greater than 7, it checks the middle index to right. Here the startindex
is the same as the endIndex which means the binary search is over and the placement of 8 is
found.
Figure 9.19: Since 9 is greater than 8, it checks to the right of the array until it finds a number
greater than 9, which it finds when 10 is greater than 9.
Figure 9.20: To make room for number 9, all elements to the right have to be moved over by
one index.
Figure 9.21: Finally, the number 9 is input in the array, resulting in a new sorted array with the
new element inputted.
JSON Database
The JSON database is built to give easy to read operative plans for the on-site commander in
case of a fire. The operative plans are based on coordinates for a given address, and they contain
all the crucial information needed to save a building and people from a fire. The different oper-
ative plans are accessed through the coordinates. When a pair of coordinates matches another
pair in the database, it will show the given address and some information about the building.
This is information such as usage, height, and what the building is called. The database also
contains information about what kind of fire equipment is accessible on the address. This is
equipment like risers, sprinklers, escape stairs among others. All the equipment is visible in
figure 9.22. Besides the fire equipment and building information, considerations and special
considerations will also be visible in the operative plan. This is information that can be crucial
for the onsite commander to know. Considerations is information that can help the evacuation
of people or make the work for the fire department easier, whereas special considerations are
potential hazards that the on-site commander needs to know.
Figure 9.22: Graph showing structure and content of an operative plan.
9.6 Performance
In this section the time complexity of the front- and backend will be described. Here, it is
explained how certain functions run and also what consequences can occur in worst case sce-
narios.
Frontend
The performance of the frontend is greatly impacted by the size of the operative plans gathered
by the server, as it loops through quite a lot of the properties of each plan. Even so, the size of
the plan is unlikely to ever grow too big, as the number of data fields is predetermined by the
input form, and as such the number of iterations has an upper limit. Furthermore, even if the
plans were to grow large, the slowest run time has a worst case scenario of O(n*m), where n is
the number of features in the object and m is the amount of properties the features have.
Figure 9.23: A single nested for-loop on different lists creates O(n*m).
Both the number of properties in opPlan is limited as operative plans are written by people and
as such the problem size is limited to a size most likely manageable by a computer. The same is
true for nearby warnings, as the amount of nearby buildings are gated by the size of buildings
in the real world, and is unlikely to be too large.
While displaying the polygon might initially seem like something that would take time, since
the polygon corresponding to the operative plan is calculated and assigned server side, creating
the polygon on the client is as simple as creating a layer of the polygon coordinates and adding
it to the map.
Otherwise, the slowest part of the program is the loading and displaying of map tiles, and
animation frames upon zooming onto a marker. The tiles are loaded asynchronously from the
server, and the animation frames use RequestAnimationFrame, which is also asynchronous,
causing no slowdown to the general use of the site.
Backend
In the backend, the slowest function deals with the data management, the polygons and the
check for nearby locations. The data management uses BinarySearch. This is a fast function
with O(log n) runtime[32], and is well known so it will not be further discussed here.
The number of polygons being checked is limited by a maximum distance to the point being
checked, as to not check every single polygon in the GeoJSON, and for each of those checks
the edges of the polygon, limiting it to at most O(n*m) again. This is reasonably fast, and only
needs to be done when a new operative plan is inputted, and so is unlikely to ever have an impact
on the use of the software.
The check for nearby locations uses two recursive functions, each of which is limited by the
amount of buildings in close proximity, based on the current operative plans. This means the
worst case scenario for each is O(n), in the case that every operative plan is close enough to
warrant another call. This is quite fast, so it should not cause problems.
10 | Testing
In order to catch potential errors in the code, several tests were performed, including unit tests
and end-to-end tests. The tests also ensure that the program does what it is intended to do, and
helps to verify its validity.
10.1 Unit Test

The unit tests were done by checking if each part of the program works separately, these parts
being the backend and the data management. This is done to minimise errors when all parts are
running together and help to verify individual functions. The tests were done using Jest, which
is a widely used testing framework[33]. In this section, some snippets of code will be shown
including how the unit tests have been done.
10.1.1 Polygon Test

This unit test suite checks whether the functions in insideBuilding calculates the relative posi-
tion between the given points correctly. In the test, some coordinates are chosen, and from these
expectations are made. If the results from the tests meet the expectations, the test passes.
The onSegment function checks whether a point in two dimensions (test point) is within the
coordinate interval of two other points in two dimensions (base points). To test this function,
the following three test cases where made:
• Test point is collinear with base points.
• Test point is above the line segment created by the base points.
• Test point is not within the bounds of the base points.
Test one and two are expected to return a truthy result and test three is expected to return a falsy
result. If all three tests return the expected result, the function passes the unit test and is working
as expected. These tests can be seen in figure 10.1.
CHAPTER 10. TESTING 53

Figure 10.1: Code from the unit test done for the polygons. This code tests whether the points
are on, above or away from the segment
The second unit test in this suite is for the orientation function, which checks whether a point
in two dimensions (test point) is collinear with, rotated clockwise, or rotated counterclockwise
relative to two other points in two dimensions (base points). Once again, three cases where
made to verify the function:
• Test point is rotated clockwise relative to the base point line.
• Test point is rotated counterclockwise relative to the base point line.
• Test point is collinear with the base points.
Here, the first test is expected to return 2, meaning a clockwise rotation. For the second test, a
return of 1 is expected, meaning a counterclockwise rotation. Lastly, the third test is expected
to return 0, meaning the points are all collinear. If all three tests return the expected result, the
function passes the unit test and is working as expected.
10.1.2 Data Management

The second unit test suite is for the data management.
The first data sorting test checks if the binary search works. It does this by calling the binary-
Search function with a sorted array and a set of coordinates that exist in the given array. It then
expects the function to return the index of that set of coordinates in the array, and if it returns
the index the test is successful.
The second and final data sorting test checks the binary input function. It does this by calling
the binaryInput function with a sorted array and a new set of coordinates. It then expects this
function to return a new array with the new set of coordinates inputted in the correct sorted
order. If the new array returns in order, the test is successful. Both tests are shown in figure
10.2.

Figure 10.2: The test code for the data management tests, which assert that the insert and search
functions work.
10.2 Full Program Test

A usability test of the full program was made in order to ensure that the requirements for the
program were met and that the full work flow functions as intended. This was done using the
Cypress testing framework. Cypress allows end-to-end testing on programs that are run via a
browser[34].
10.2.1 Operative Plan Upload

The interface connected to uploading operative plans is tested in two ways. The first way is to
use the correct values and file formats to check that it gets input correctly, and that the right
information is shown when the new operative plan is fetched from the operator frontend. This
was done using Cypress. The second way is to use the incorrect values and file formats, essen-
tially in an attempt to break the program. If the program handles the correct values correctly,
and rejects the incorrect values accordingly, the test passes. This was done manually, since the
file limitations are made via the file browser, which do not work with Cypress.
An example of an incorrect value is trying to upload an operative plan in a file format that is not
PDF. This should not be possible, since if the program is functioning correctly the user should
only see the allowed file formats in the file browser (see figure 10.3). Another incorrect value is
to leave the mandatory text fields empty.

(a) File browser when accessed from the Windows (b) File browser when uploading operative plan
pathfinder. PDF.
Figure 10.3: Only the allowed file type is shown in the file browser when uploading files to the
server.
10.2.2 Receiving Fires

When receiving a fire from the emergency central, it should be displayed on the map with a
marker at the location of the incident. This is tested by sending a POST request to ’/fireAlert’
with a set of coordinates as well as other necessary information. If the marker is displayed at
the correct location, the test passes. Similarly, by simulating a "completion" of the fire using
the POST request, the marker should disappear from the map.
For this test sequence, coordinates (9.932112, 57.046611) were used, which should place the
fire inside the Nordkraft building in Aalborg. The marker showed up at the correct place on the
map as shown in figure 10.4.
Figure 10.4: Fire marker placed with coordinates (9.932112, 57.046611).
Fetching Operative Plans

By clicking on a map marker, two things happen; the outlining of the building is shown on the
map and the building’s operative plan is displayed on the right-hand side of the screen.

The operative plan is checked by creating several fire markers, some of which are inside the
same building and some are outside the building. The test then clicks a marker inside a building
and saves the address displayed in the operative plan in a variable. It then compares the address
with the address displayed on the other markers. If it matches the markers inside the building,
and does not match the markers outside the building, the test passes.
Since the map itself is just an image, on top of which the building’s polygon is drawn, it is
difficult to test if the correct polygon has been drawn using Cypress. Therefore, this part of the
test was done by a user clicking a marker and visually checking that the correct polygon was
displayed. Furthermore, this test also involves trying to break the program to make sure that
these types of errors are found. This includes inputting a fire that is not inside a building as well
as using a building that does not have an operative plan, to check that no outline is drawn and
no operative plan is shown respectively. An important feature here is that the operative plan and
the building’s outlining is found regardless of which coordinates are used, as long as they are
inside the building in question. As shown in figure 10.5, the same building and operative plan
is displayed for all three sets of coordinates used.
(a) Marker bottom right (b) Marker top right (c) Marker middle left
Figure 10.5: A marker anywhere inside a building returns that building’s operative plan.
Notifying of Nearby Warnings

There are three test cases that need to be checked in order to see if the nearby warnings are
displayed correctly.
• There is a building within 500 meters that has a hazard.
• There is a building within 500 meters that does not have a hazard.
• There is a building further than 500 meters away that has a hazard.
Only the first case should cause the nearby warnings to show up, whereas the two other cases
should leave this field empty.
Using four uploaded operative plans, each case is tested. As shown in figure 10.6, the only
nearby warning that is displayed is for House of Music (Musikkens Pl. 1), which is a building

within 500 meters with a hazard. The other two buildings fit into case two and three, and are
therefore not displayed.
Figure 10.6: Test of nearby warnings.
Assigning Commanders
The dropdown menu for assigning fires to commanders has two simple tests. One is to check
that all commanders in the database are displayed in the menu when clicking the button. This is
done by checking that the amount of commanders displayed matches the amount of comman-
ders in the commander database (see figure 10.7). The other is to select a fire and assign it to a
commander. Checking that the correct information is sent to the commander is described in the
next test.
Figure 10.7: Cypress test case for cheking if all commanders are on the dropdown menu of
commanders.
Commander View
The test used for the commander view involves checking if the correct data is displayed after
logging in with a commander ID, and that a fire can be resolved correctly. This is done by
assigning a commander to a fire with an operative plan, and then logging in to the commander
page with the same commander and verifying that the operative plan is correctly assigned and

displayed.
Figure 10.8 shows the data displayed after logging in with the commander ID.
Figure 10.8: Commander view with assigned fire.
After resolving the fire, the information should disappear.

Here it is also important to check that no information is displayed when logging in with either
an incorrect ID or an ID that does not have an assigned fire.
10.3 Results
The unit tests were used continuously to test all the basic functions in each part to control cor-
rectness. When all the tests return the expected result and pass, it means that all the base core
functions run as desired from the program design. By testing the unit functions it is assumed
that if they pass, the functions comprised of the units will also run as expected.

Using this approach, the program can easily be tested for correctness after changes are made to
the code.
The full program test using Cypress was done after all of the functionality had been developed.
However, smaller portions of the program were continuously tested without Cypress to ensure
that the user interface utilised the core functions as intended.
The full program test was performed in an iterative way, so that the test was run again after any
error correction.

Part III
Problem Closure
61
11 | Discussion
In this section the choice of primary source, limitations of the program implementation and the
structure of the program is discussed, including a comparison between the initial design of the
program and the final implementation. Lastly, the program requirements that have not been
fulfilled are discussed.
11.1 Primary Information Sources

Since there are limited sources online concerning how the Danish emergency management deals
with fires and how they have optimised their OCC, it was decided as a group to conduct an in-
terview.
The interview ended up being the primary source of information, and it was the main reason for
the decision of the problem formulation. The interview was with the chief emergency manage-
ment officer, and is therefore considered a knowledgeable and reliable source.
The problem however, is that the information is very one sided by only having one main source
of information. This means that the information and the solution produced by this information
are only relevant to the one OCC that the information is from. It is not certain whether the
problems and difficulties mentioned in the interview are relevant for other OCCs throughout
Denmark. But as it was not possible to get other interviews, it was necessary to base the analysis
of the problems on the information from the one interview that was held. If more time and
resources had been put into the project, more interviews with different OCCs would have been
a great addition to this report, so a better perspective of the problems could have been formed.
11.2 Program Limitations

Given the time restraints on this project some limitations had to be made regarding the size and
scope of the program. These will be listed in this section.
Nearby Hazards
The first of these limitations can be seen when looking for nearby hazards during a fire. When it
does this, the program needs a limit for how far away from the fire it should search for hazards.
An arbitrary number of 500 meters was chosen. If the program is to be integrated in an OCC,
some research could be done to find a more accurate limit for how far to search for nearby
hazards. Furthermore, an option for the operator or commander to change this limit depending
on the situation could be implemented. If the fire spreads very rapidly, in e.g. a forest area, the
limit might need to be higher than for a house fire in a city.
CHAPTER 11. DISCUSSION 62

JSON Database
The program is based on a database containing the operative plans as well as a database with
building metadata and polygons. The databases are made using JSON files because it was within
the scope of the project. JSON databases are easy to set up, but they quickly get unmanageable.
A JSON file is read and written every time an entry is edited. This is a slow process, with
wasted resources used for reading data that has not been altered. This problem increases with
the amount of entries in the file. Therefore, it is not the best solution for big databases, but it
works well for the size of the current program. Considering the time and knowledge limit in
this project, a JSON based database is the best option.
Because of the limitations of using JSON, only a subset of buildings are available for opera-
tive plans and displaying polygons. The entire world is visible on the map, but the building
polygons are only available in Aalborg. This specific city has been chosen, because the report
focuses around this city, and because the main source of information is based on Aalborg city,
as mentioned in section 11.1.
Better Login
This version of the program does not have any login security. When a commander wishes to log
in, the program only asks for a user ID number, but no password. This could allow other users
than the commanders to log in. The same insecurity applies for the operator. Currently, when
an operator starts the program the operative overview is being displayed without any required
security of login. Therefore, a future expansion of the program could be to insert a more secure
log in system that includes passwords. Passwords would ensure more safety for the comman-
ders, as opposed to just using a simple ID number.
However there are two main reasons why a more advanced and secure login was not included in
the final program. The first is that the program is intended as an extension to an existing OCC
software solution. In that case, it would not be necessary to have a more advanced identification
system than the current one, since this program would already be behind a heavy security layer,
that the big OCC software solution would have.
The second reason for not having a more advanced and secure login was technical limitations,
since the program is not using an SQL database but instead a JSON database, for the reasons
mentioned above. Because of this, it would be very tricky to develop a secure and encrypted
login system, and that combined with the first reason resulted in it not having a high priority
and it was therefore not done.
11.3 Program Completion

During the development of the program, a variety of choices were made, impacting the final
look and functionality of the program. Even if the program does not look like the original
sketches, or perfectly fulfil all requirements, it is important to discuss whether it still completes

its task and is fully functional. This will be done through comparison to the original design
section and the program requirements.
11.3.1 Comparison With the Design

At the start of the development of the program, two sketches were laid out for the OCC operator
client and the on-site commander client. When comparing these to the final versions of these
clients, seen in figure 11.1 and figure 11.2, it is apparent that a few alterations have been made.
Operator Client
When it comes to aesthetics, this version looks similar to the original sketch version (see figure
11.1). However, there are some subtle differences, one of which being that instead of having
a red circle show up on the map when a new fire arrives, a marker shows up clearly indicating
that it is a fire. This decision was made to give the program a little more visual clarity, as a red
dot has a tendency of being hard to see on some backgrounds.
The biggest change on this client has been the information from the operative plan database, as
the only overlap between the information on the sketch and the final client is the address, spe-
cial considerations and download of the full operative plan. However, during the development,
the focus turned away from resource management of vehicles over to more raw information
and display of the operative plan. Another difference is that instead of the program automat-
ically assigning a commander to the fire, the operator does that by choosing the name of the
commander via the blue dropdown menu of available commanders.
(a) Initial sketch for the operator client. (b) Final version of the operator client.
Figure 11.1: Final version of the operator client compared to the initial sketch.
Commander Client
The commander client has changed quite a bit more, most notably by completely foregoing the
"General" box, which turned out to be cluttering up the screen (see figure 11.2). All information
is now gathered in one information box, which draws info from the operative plan database. A
new feature added to this that was not in the sketch is the ability for a commander to sign in via
a unique ID number, which lets them view the fire that has been assigned to them. A couple of
options for how to login were considered, for instance, using the commander’s email to login,
as that would be unique to each commander. However, the program uses unique ID numbers

because on a tablet it can be time consuming to write in an entire email, as opposed to a short
unique ID, and as such that is the method used. There is also now a Resolve Fire button which
deletes the fire and unassigns all assigned commanders. The floor plans are now a carousel
where it is possible for the commander to scroll through all available floor plans, and therefore
the link to download all floor plans no longer exists. In addition to this, the final version of the
client was designed with portrait mode in mind.
(a) Initial sketch of the on-site commander client
(b) Final version of the on-site commander client
Figure 11.2: Final version of the on-site commander client compared to the initial sketch.
Input Client
An entirely new site was also created, the input client. This site was developed because a need
was found for organisations to be able to input their own operative plans. One shortfall of
this client is however that it is not possible to upload an operative plan for a place that does
not have a building, for example a forest that could have a plan for dealing with a forest fire.
This is because the operative plans need to be linked to a building polygon in order for the
program to function. This could be solved by letting the user input their own polygons on
the map, however this would create the challenge of making sure that it does not overlap with
any existing polygons. Given the time constraints this challenge was not solved and therefore
operative plans are limited to preexisting buildings.

11.3.2 Program Requirements

The program requirements provided a prioritised list of features that were either required for
the program to fulfil its purpose or would increase the usability of the program. However, some
requirements were not developed, and will be discussed below.
Want-to-have requirements
There were two requirements from this category that were not fulfilled.
Information shown is prioritised by importance

The information is not ordered, for a few reasons. The information is very hard to prioritise in
a general way, beyond the categorisation that is inherent to the operative plans. Each specific
case might have some things that are far more important than others, and it is up to the operator
and commander to decide this. The program instead focuses on displaying the information in
as clear a way as possible. Since the amount of information outside the operative plans does not
fluctuate much between cases, it should still be easy for the user to get an overview and decide
for themselves what is most important in the present situation.
Operator/OCC is able to curate what information is mission critical and most important
As stated in the previous paragraph, there is not really enough information to warrant prioritis-
ing specific parts of it on the site. Since the commander already has only the most important
information, letting the operator further limit it is unnecessary. Furthermore, since the informa-
tion on the commander site is clearly divided into sections, the commander should be able to
figure out what information is most important to the individual situation.
If it was deemed necessary, a possible implementation could be allowing the operator to mark
each piece of information with a priority, which would then show up on the commander site in
this order, allowing for information acquisition at a glance. This would also cover the previous
requirement for the commander site, which is more relevant, as the operator is more likely to
actually require all the information, and has the knowledge and ability to prioritise on a case-
to-case basis, better than could be realistically implemented in the program.
Nice-to-have requirements
Neither of the requirements from this category were developed.
Searchable database of available emergency vehicles

This database was thought to be a nice add on to the program, to give the operator a better
overview of what emergency vehicles were available for each emergency. This feature, how-
ever, was never implemented because it was irrelevant to the functionality of the program. The
program is intended to be used as an add-in to an already existing, full-scale solution for the op-
erator at the OCC. The problem that the program is solving is displaying operative plans clearly
and making them easy to use. Adding a database of vehicles would also require the program to

deal with selecting and dispatching vehicles, which is a completely different set of problems to
be solved. In order to focus on the primary goal of the program, it was therefore decided to not
implement this feature.
However, if this requirement was chosen to be included it would require a database including all
the emergency vehicles with specific identification numbers, so they could be identified, which
could make it easier for the operator to have an overview of the vehicles. The vehicles could
then be displayed on the map, in a way that resembles their current GIS system.
Vehicle metadata according to their specific equipment

This feature would work along with the searchable database as mentioned above. This fea-
ture would allow the operator to search for specific vehicles according to what equipment was
needed for the emergency. Because the vehicle database was not implemented, it was decided
to not implement this feature either.
A possible implementation of this requirement would be dependant on a working vehicle database.
In this case, another field could be added to the database showing the vehicle’s equipment.
11.4 Overall
The limitations of the program are not vital to its functionality, and are easy to change to fit the
circumstances. Furthermore, the program requirements that were not implemented do not affect
the program negatively. Should these requirements be needed in the future, it is just a matter of
adding them to the existing program.
The project is mainly based around a single information source, which means that the solution
program is developed with this specific OCC in mind. However, if the program was to be
developed further, changes could be made to warrant the needs of users in other OCCs.
Some potential improvements to the program are discussed in section 12.

12 | Reflection
In this section, further improvements of the program are considered. This includes how to
achieve a higher level of security, creating a proper database, using shapefiles as well as how to
make collaborations easier.
Better Database
As previously mentioned in section 9.5, all of the program’s data is stored in JSON files. While
this works for now because the amount of data used in the program is very small, if the program
has to scale and contain every operative plan for the entirety of Aalborg municipality or even
the entirety of Denmark, it quickly becomes very slow to parse the entire file just to change one
thing or read one operative plan. In order to change this, the program could be reconfigured to
use an SQL database. Doing this would allow for much more efficient data extraction and input,
especially when the database gets bigger. However, due to time and knowledge constraints this
has not been done in the current state of the program.
GeoJSON and Shapefiles

There are several ways to store geographical data to be used with GIS. The method chosen for
this project is GeoJSON, which is a method that is easy to use and is well-suited for smaller
data sets. It is natively supported by JavaScript, making it simple to implement in this project
solution. However, if the program is to be used for larger regions (e.g. Denmark as a whole), it
might be better to use shapefiles. Shapefiles take up less than half of the memory space as Geo-
JSON, and it is faster for the program to process. In Aalborg alone, the GeoJSON file contains
over 37.000 lines of data. Expanding this to all of Denmark will drastically increase the amount
of memory needed.
Greater and Better Collaboration Opportunities Between Users

Giving tools for collaboration and teamwork could be useful for big emergencies, where several
commanders and operators might have to work together. Examples of this could be allowing
commanders to communicate directly in the interface, sharing important information, or images
taken with the device. It could also be to let the operator have direct control over transferred
information or even directly communicate with the commanders in the field, relaying important
information. Additionally the program could gather logs and data around the case for review to
further improve the individuals on the case, and find failures in procedures or programs used.
A Testable Program
Only a subset of functions and possibilities in the program are included in the tests. This is
because a test review was not prioritised at the start of the project. The function output was
instead written only with the function use in mind. Therefore, the functions are less testable, as
they often only give a single output. This was because each part was written without a specific
CHAPTER 12. REFLECTION 68

format in mind, a format that could easily be tested. The tests which are present cover the
functions with easily testable outputs, or core functions to the function of the program, with the
vast majority of the untested code being helper functions or functions which directly impact the
interface.
CHAPTER 12. REFLECTION 69

13 | Conclusion
During emergencies time is of the essence, and to be able to act fast and make decisions can be
life saving. Therefore, this project has focused on making a program to help on-site comman-
ders and operators to act fast during emergencies.
In researching the topic of emergency dispatching, a need was found for a software solution
which could help coordinate and share information, and thereby positively affect the efficiency
of emergency operators’ work. From this the initiating problem was created:
How can a software solution help to organise information to coordinate a dispatch

of emergency services?
The stakeholder analysis lead to more focus being put on the Operation Control Centre (OCC).
An interview with the chief of the OCC in Aalborg was scheduled. Through this interview and
further research into the Danish emergency management, it was decided to focus the project
on the emergency management. The interview made it clear that the OCC for the emergency
management had issues concerning identifying operative plans, as this is currently a manual
process for the operator. From this the following problem statement was created:
How can a platform be designed that notifies and presents operators and on-site
commanders with important information relevant to the locations of ongoing emer-
gencies?
From this problem definition, the program requirements were stated through need-, want- and
nice-to-have categories. These requirements consisted of a database containing the operative
plans, an easy accessible interface for both the operator and on-site commander, and a way to
show the important information for a specific emergency. These requirements were made to
ensure the functionality and usability of the program.
The need-to-have requirements consist of requirements necessary for the functionality of the
program and to fulfil the problem statement. The need-to-have requirements, seen in section
8.1, were met. All of the want-to-have features were implemented, except the prioritised in-
formation and the curation of most mission critical information as mentioned in section 11.3.2.
None of the nice-to-have requirements were implemented, since the focus of the program was
changed to only organise and display operative plans. All the program requirements that were
not implemented have been discussed more thoroughly in section 11.
The program solution consists of three separate interfaces. Two of them are made for the oper-
ator and commander respectively, which automate the process of finding the correct operative
plans. The third interface is to aid in the process of getting operative plans into the system.
CHAPTER 13. CONCLUSION 70

The functionality of the requirements were tested through unit and end-to-end tests to make
sure they worked correctly. The implementation and testing is discussed in section 9. Through
the implementation and testing of the program requirements, it is clear that the requirements for
the program have been reached, and the problem statement has been met.
The report and program solution have some weaknesses, which are described in section 11.
These include e.g. relying on one primary source of information as well as operative plans not
working for areas without a building. However, the program still solves the intended problem,
and the flaws are thus not critical.
To consider potential improvements, a reflection has been made for this project, where the focus
was to look at what features in the program can be improved for a better implementation of the
project in the future.
Therefore, the reflection includes suggestions for better security, a proper database and the use
of shapefiles. Similarly for bigger emergencies, a greater and better collaboration opportunity
between the users have been reflected upon.
CHAPTER 13. CONCLUSION 71

Bibliography
[1] Beredskab H. Alarm- og vagtcentralen; 2017. Accessed: 23-02-2020. Avail-
able from: https://hbr.dk/beredskabet/hvornaar-ringer-du-1-1-2/
alarm-og-vagtcentralen/.
[2] Interview with Lars Bjørndal; 2020.
[3] Nordjylland R. Når du ringer 112; 2020. Accessed: 25-02-2020. Avail-

able from: https://rn.dk/Sundhed/Patient-i-Region-Nordjylland/
Akut-sygdom/Naar-du-ringer-112.
[4] Pre-Hospital NJ. AMK-vagtcentral; 2019. Accessed: 26-02-2020. Available from:

https://dpv.rn.dk/praehospitale-omraader/amk-vagtcentral.
[5] Police D. Alarm 112 info; 2020. Accessed: 26-02-2020. Available from: https://
politi.dk/kontakt-politiet/alarm-112.
[6] Hovgaard L. 112: Nu får alarmcentralen automatisk din position på sms; 2019. Ac-
cessed: 25-02-2020. Available from: https://ing.dk/artikel/112-nu-faar-
alarmcentralen-automatisk-din-position-paa-sms-228509.
[7] universitet A. metodeguiden Interviews; 2019. Accessed 20-05-2020. Available from:

https://metodeguiden.au.dk/interviews/.
[8] Beredskabsstyrelsen. About us; 2020. Accessed: 20-05-2020. Available from: https:
//brs.dk/eng/aboutus/Pages/aboutus.aspx.
[9] Buskbjerg M. Interessentanalyse; 2019. Available from: https://

altomledelse.dk/interessentanalyse/.
[10] Brandstationer i Danmark; 2019. Accessed: 23-02-2020. Available from:

https://brs.dk/viden/statistik/brandstationer/Pages/
brandstationer.aspx.
[11] Brandslukning;. Accessed: 25-02-2020. Available from: https://www.falck.dk/

offentlig/brand-og-redning/ydelser/brandslukning/.
[12] Redningsberedskabet i Danmark; 2020. Accessed: 25-02-2020. Available from:

https://brs.dk/beredskab/idk/redningsberedskabet_i_danmark/
Pages/RedningsberedskabetiDanmark.aspx.
[13] Beredskabscentre; 2020. Accessed: 23-02-2020. Available from: https:

//brs.dk/beredskab/idk/statsligt_beredskab/beredskabscentre/
Pages/beredskabscentre.aspx.
[14] of homeland security D. Home Fires; 2019. Accessed: 26-02-2020. Available from:
https://www.ready.gov/home-fires.
[15] problemer med afgangstiderne; 2012. Accessed: 25-02-2020. Available from: https:
//www.beredskabsinfo.dk/brandvaesen/afgangstider/.
BIBLIOGRAPHY 72
[16] Beredskabsstyrelsen. Redningsberedskabets statistikbank; not given. Accessed:

26-02-2020. Available from: https://statistikbank.brs.dk/sb#page=
77fb3232-1de9-4c7b-baa2-1907d09b972c.
[17] IHM Vagtcentralløsning; 2020. Available from: https://www.ihm.dk/da/

branchelosninger/beredskab-og-kommuner/kontrolrumslosning.
[18] Carmenta Coordcom; 2020. Accessed: 26-02-2020. Available from: https://

carmenta.com/en/public-safety/carmenta-coordcom-2/.
[19] Sjøgren K. Kæmpe kortlægning afslører: Derfor ringer vi 112; 2017. Accessed: 23-02-
2020. Available from: https://videnskab.dk/krop-sundhed/danskere-
ringer-oftest-112-paa-grund-af-skader-og-druk.
[20] EENA. UK SHOWS THE WAY TOWARDS ACCURATE CALLER LOCATION –

AN EXAMPLE FOR OTHERS TO REPLICATE!; 2014. Accessed: 25-02-2020.
Available from: http://eena.org/press-releases/uk-shows-the-way-
towards-accurate-caller-location-an-example-for-others-to-
replicate/.
[21] EENA. ADVANCED MOBILE LOCATION IS NOW AVAILABLE IN ALL ANDROID

PHONES!; 2016. Accessed: 25-02-2020. Available from: https://eena.org/aml-
in-android/.
[22] Google. How it works; 2015. Accessed: 25-02-2020. Available from:

https://crisisresponse.google/emergencylocationservice/how-
it-works/.
[23] Google. ELS FAQ; 2015. Accessed: 25-02-2020. Available from: https://
crisisresponse.google/emergencylocationservice/faqs/.
[24] Google; 2017. Accessed: 26-02-2020. Available from: https://www.google.com/

maps/search/maps/@57.0488966,9.9192101,17.35z.
[25] Maptitude. GIS Software; not given. Accessed: 26-02-2020. Available from: https:
//www.caliper.com/maptitude/gis_software/default.htm.
[26] Carlsson C. När det verkligen gällde ställde alla upp så att vi kunde klara situationen;
not given. Accessed: 19-02-2020. Available from: https://www.sosalarm.se/
trygghet--sakerhet/artikel1-7-april/.
[27] What is JavScript;. Accessed: 14-05-2020. Available from: https:

//developer.mozilla.org/en-US/docs/Learn/JavaScript/
First_steps/What_is_JavaScript.
[28] Arcademind. Frontend vs Backend vs Fullstack Web Development - What should you
learn?; 2018. Accessed: 14-05-2020. Available from: https://youtu.be/
pkdgVYehiTE.
[29] Leaflet. Leaflet; 2020. Available from: https://leafletjs.com/.
[30] Mapbox. Mapbox; 2020. Available from: https://www.mapbox.com/.
BIBLIOGRAPHY 73
[31] geeksforgeeks. How to check if a given point lies inside or outside a polygon; 2020. Ac-
cessed: 06-04-2020. Available from: https://www.geeksforgeeks.org/how-
to-check-if-a-given-point-lies-inside-a-polygon/.
[32] Thomas H Cormen RLRCS Charles E Leiserson. Introduction to Algorithms; 2009.
[33] Jest. JavaScript Unit Test Framework; 2020. Available from: https://jestjs.io/.
[34] io C. JavaScript End to End Testing Framework; 2020. Accessed: 18-05-2020. Available
from: https://www.cypress.io/.
BIBLIOGRAPHY 74

Example of My Work PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Example of My Work PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Emergency helpdesk

Rasmus Borrisholt Schmidt Amount of pages: 74

Completed on: October 10, 2020

4 Danish Emergency System Overview 11

6 Existing Software Solutions 16

III Problem Closure 61

1.1 From Call to Dispatch - a Quick Introduction

• Where did it happen?

• When did it happen?

• What number are you calling from?

• Where does the help need to be sent?

• How many are hurt?

1.2 Initiating Problem

2.3 Literature Sources

2.4 Top Down Programming

2.6 Stakeholder Analysis

Table 2.1: Glossary list.

3.1 Identifying Stakeholders

Operation Control Centre

CHAPTER 3. STAKEHOLDER ANALYSIS 7

3.2 Stakeholder Matrix

Figure 3.1: The different roles of the stakeholders.

CHAPTER 3. STAKEHOLDER ANALYSIS 8

The stakeholders are distributed in the following categories:

• Externals These are neither participating or involved.

3.2.1 Justification of Stakeholders

Operation control centre

CHAPTER 3. STAKEHOLDER ANALYSIS 9

CHAPTER 3. STAKEHOLDER ANALYSIS 10

4 | Danish Emergency System Overview

• Emergency management OCC

This can be seen in figure 4.1.

CHAPTER 4. DANISH EMERGENCY SYSTEM OVERVIEW 11

4.1 Flow of OCC systems

Any information gathered by the emergency management operator is forwarded to an on-site

CHAPTER 4. DANISH EMERGENCY SYSTEM OVERVIEW 12

Falck Ambulance Service

CHAPTER 4. DANISH EMERGENCY SYSTEM OVERVIEW 13

5.1 Emergency Fire Management Resources

CHAPTER 5. EMERGENCY MANAGEMENT 14

5.2 Priority Classes

Average Response Time

CHAPTER 5. EMERGENCY MANAGEMENT 15

6 | Existing Software Solutions

• Handling registration and archiving of incidents

• Automatic call-out of personnel

• Two-way communication with task forces

• Visuals of resources and geographic information systems

• Support for automatic alarms

6.2 Carmenta’s CoordCom

• Distribution of calls between dispatchers

• Maps that can show nearby resources

• Realtime update of case information for everyone involved

• Support for telephone, radio and data communications

• Applicable to any existing communication infrastructure

CHAPTER 6. EXISTING SOFTWARE SOLUTIONS 16

CHAPTER 6. EXISTING SOFTWARE SOLUTIONS 17

send to the dispatcher[22].

6.4 GIS Software

Figure 6.1: Example of a GIS showing points of interest in Aalborg centre[24].

CHAPTER 6. EXISTING SOFTWARE SOLUTIONS 18

GIS works by splitting a map up in several layers. An ex-

6.5 Operational Digital System