improving usability of land warfare simulator: pathfinding and...

INOM EXAMENSARBETE TEKNIK,GRUNDNIVÅ, 15 HP

, STOCKHOLM SVERIGE 2017

Improving usability of land warfare simulator: pathfinding and adaptive speed based on geographic data

OLOF ENGSTRÖM

GABRIEL LÖRDAL TIGERSTRÖM

KTHSKOLAN FÖR INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK

Improving usability of land warfare simulator:

pathfinding and adaptive speed based on

geographic data

OLOF ENGSTRÖM

GABRIEL LÖRDAL TIGERSTRÖM

Bachelor Degree Project, KTH Information and Communication TechnologySupervisor: Prof. Åke Sivertun

Examiner: Prof. Carl-Mikael Zetterling

Trita-ICT-EX-2017:114

Abstract

SANDIS II is a land warfare simulation and analysis tooldeveloped by the Finnish Defence Research Agency. TheSwedish Defence Research Agency has evaluated SANDIS IIto have potential as a war gaming aid within education, atthe Swedish Defence University. However, operating thetool is considered too difficult to avail that potential. Inthis report we propose a way of using geographical data forpath-finding in terrain and automatically adjusting units’speeds. We construct a cost raster from various types ofgeographic data, with each grid in the cost raster storing avalue, representing a degree of mobility. Models using costrasters are then created for adjusting unit speed and findingleast-cost paths. We implement the models in Python asa stand-alone module, and describe the module’s internalmethods, interface and how it can be used by SANDIS II.

Keywords: warfare simulation, geographic data, educational software, geographicinformation systems, geospatial analysis.

Referat

Förbättring av markstridssimulators

användarvänlighet: pathfinding och adaptiv

hastighet baserad på geografisk data

SANDIS II är ett simulerings- och analysverktyg utveck-lat av Finska Försvarsmaktens Forskningsanstalt. Svens-ka Totalförsvarets forskningsinstitut har utvärderat SAN-DIS II och funnit ett potentiellt användningsområde förverktyget som stöd vid krigsspel, inom utbildning vid För-svarshögskolan. Verktyget anses dock vara för svårhanter-ligt för att uppfylla detta syfte. I denna rapport föreslåsmetoder för att beräkna de snabbaste förflyttningsvägarnai terräng och att automatiskt justera enheters hastighet isimulatorn, baserat på geografisk data. Vi konstruerar ettkostnadsraster av olika typer av terrängdata, där varje rutai rastret tilldelas ett värde som representerar framkomlig-het. Med kostnadsraster som grund skapar vi sedan model-ler för att kunna justera enheters hastigheter och beräknaframryckningsrutter med så låg kostnad som möjligt. Viimplementerar modellerna i en separat Python-modul ochbeskriver modulens interna metoder, gränssnitt och hur detkan användas av SANDIS II.

Contents

List of Figures I

List of Tables I

Acronyms II

Terminology III

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 SANDIS II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Manual assignment of simulator parameters . . . . . . . . . . . . . . 11.4 The problems with manual assignment . . . . . . . . . . . . . . . . . 21.5 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 32.1 Military Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 The SANDIS II tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 Current use of geographic data . . . . . . . . . . . . . . . . . 42.2.2 Unit velocity calculation . . . . . . . . . . . . . . . . . . . . . 42.2.3 Direct fire order . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.4 User experience . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.5 Development environment . . . . . . . . . . . . . . . . . . . . 6

2.3 Geographic information . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.1 Vector data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.2 Raster data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.3 GDAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.4 ArcGIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Method and requirements 83.1 Project structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 The study 114.1 SANDIS II unit speed . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Problem analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3 Geographic data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4 Choosing a tool for processing geographic data . . . . . . . . . . . . 14

5 Modelling solutions 165.1 Cost raster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.2 Rasterizing a line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.3 Terrain resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.4 Least-cost path analysis . . . . . . . . . . . . . . . . . . . . . . . . . 205.5 Splitting a path into way points . . . . . . . . . . . . . . . . . . . . . 21

6 Implementation 236.1 Python implementation . . . . . . . . . . . . . . . . . . . . . . . . . 236.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3 Integrating with SANDIS II . . . . . . . . . . . . . . . . . . . . . . . 25

7 Discussion 277.1 Choice of framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.2 Rasterizing line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.3 Cost rasters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287.4 Least-cost path analysis . . . . . . . . . . . . . . . . . . . . . . . . . 297.5 Calculating speed along path . . . . . . . . . . . . . . . . . . . . . . 307.6 Ethical aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

8 Conclusions and future work 338.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Appendices 34

A Algorithms 35A.1 Ramer-Douglas-Peucker algorithm . . . . . . . . . . . . . . . . . . . 35A.2 Bresenham’s line algorithm . . . . . . . . . . . . . . . . . . . . . . . 36

Bibliography 37

List of Figures

2.1 SANDIS II unit properties . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1 Calculating least-cost path in ArcGIS . . . . . . . . . . . . . . . . . . . 15

5.1 Rasterized line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2 Terrain resistance flowchart . . . . . . . . . . . . . . . . . . . . . . . . . 215.3 Splitting a path into way points . . . . . . . . . . . . . . . . . . . . . . . 22

6.1 Interface to SANDIS II . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7.1 Simulation of a unit advancing on a obstructed path. . . . . . . . . . . . 31

A.1 Visualisation of the Ramer-Douglas-Peucker algorithm . . . . . . . . . . 35

List of Tables

5.1 Least-cost path comparison . . . . . . . . . . . . . . . . . . . . . . . . . 20

I

Acronyms

DDA Digital Differential Analyzer.

DEM Digital Elevation Model.

ESRI Environmental Systems Research Institute.

FDRA Finnish Defence Research Agency.

GDAL Geographic Data Abstraction Library.

GIS Geographic Information System.

GPL GNU General Public License.

GUI Graphical User Interface.

SDRA Swedish Defence Research Agency.

SEDU Swedish Defence University.

II

Terminology

ArcGIS A commercial GIS software-suite developed by Environmental SystemsResearch Institute.

Cost raster Continuous accessibility data—represented as integer values between0––90–––stored as pixel-values in a TIF-file.

costrasterkit The name of the python module presented as a result in this report.

Dijkstra’s algorithm A well-known algorithm for computing shortest paths ingraphs.

Geographic Information System A system for collecting, storing, presentingand analyzing geographical data on a computer.

GeoTIFF A public domain meta-data standard, allowing TIFF files to embedgeoreferencing informaiton.

GO area An area where a unit is able to move at near its maximum speed due tolow underlying terrain resistance.

Maybe-GO area Areas where a unit’s speed depends on a non-binary value ofthe underlying terrain resistance, for example slope, vegetation, soil type andother factors.

NO-GO area An area where a unit would not be able to pass through withoutcoming to a standstill.

Path/Route A path/route is a set of one or more way points in the SANDIS IIsimulator. Units can be assigned to paths and will then move towards thenext way point on the path.

python A high-level programming language for general-purpose programming. SAN-DIS II is written in python code.

III

python environment A python executable together with its accessible modulesand frameworks. Different python environments may use different versions ofpython and different modules and frameworks.

QGIS An open source GIS software.

scikit-image An open source image processing library for python. Used in thisreport to calculate least cost paths.

Simulation scenario Settings for a simulation, including participating troops, lo-cations, equipment, times, paths, pre-defined orders and more.

Simulation time step Data formed by simulation invocations and models duringa timed stimulation is divided into simulation time steps of a predefined length.In this report—time step refers to the fixed length of a time step.

Slope An angle representing the steepness of pixels in a raster, calculated fromdigital elevation maps.

Troop editor A program used to edit troop configurations prior to a simulation.

Unit Troops existing within a SANDIS II simulation.

User experience An aspect of human-computer interaction. The user’s percep-tion of the simulator’s ease-of-use, utility and efficiency.

Way point An intermediate point on a path.

Chapter 1

Introduction

1.1 Motivation

The Finnish Defence Research Agency (FDRA) has developed a land warfare simu-lation and analysis tool for platoon( to brigade level. The tool is named SANDIS IIand was presented to Sweden in 2008 [10]. Since, SANDIS II has been evaluatedby the Swedish Defence Research Agency (SDRA) who found it potentially usefulwithin officers’ education. Today, SANDIS II is considered too complicated to beused within the Officers’ program. A factor impairing the user experience is thatthe user has to specify parameters every time an order is given. In this report,different ways of automating these parameters by evaluating geographic data areexamined. Solution models and a suggested implementation are presented togetherwith ideas for future work on making the simulator more user-friendly.

Automating these parameters may not immediately make SANDIS II a lot moreuser-friendly, but hopefully solves a part of the problem, and thereby brings the sim-ulator one step closer to the goal of making it suitable for educational use. Anotheraspect is that perhaps this report opens up for new ideas regarding the implemen-tation of geographic data in SANDIS II, not only to improve user experience, butalso to open up the possibility for creating more realistic simulation scenarios.

1.2 SANDIS II

SANDIS II is a land warfare simulation tool developed by the Finnish DefenceResearch Agency [5]. The simulator simulates the effect of weapon systems duringmilitary operations. SEDU has decided to further develop SANDIS II, to simplifyits usage so it can be used for educational purposes in the Officers’ Program.

1.3 Manual assignment of simulator parameters

In its current state, SANDIS II requires the user to manually adjust parameterscontrolling different terrain factors, which in turn affect e.g. movement speed of

1

CHAPTER 1. INTRODUCTION

units and the outcome of direct fire orders.

1.4 The problems with manual assignment

There are three main problems stemming from using manual assignment of simulatorparameters.

• Parameters affecting accessibility and the outcome of direct fire orders requireadjustment by the user when creating a new order. This causes the userexperience to be more difficult than necessary.

• An inconvenient user experience possibly leads to decreased level of realismin simulations, since the user manually has to estimate several parameters.

• The parameters affecting accessibility currently do not take the local terraininto consideration. Not considering terrain properties could impact the usabil-ity since the user would have to estimate terrain accessibility, possibly leadingto additional pre-simulation work. It may also decrease the level of realism insimulations.

1.5 Objective

SEDU announced a bachelor degree project to further develop SANDIS II to makeuse of geographic data, with the purpose of improving usability. The objectiveswere as follows.

• Investigate how geographic data can be used to improve usability by auto-matically adjusting the speed of units, and suggesting advancement routes tothe user based on terrain accessibility.

• Investigate existing solutions and tools that could be used.

• Develop necessary calculation models on geographic data and implement themas a python module that can be used by SANDIS II.

2

Chapter 2

Background

2.1 Military Technology

The Swedish Defence University (SEDU) contributes to both national and inter-national security by conducting education and research. One of their subjects,Military Technology, involves education on various weapon systems and how tech-nology affects and is influenced by military activities. It aims to aid military officersin understanding and analyzing technology and its use in operations [16].

Military Technology also includes researching different areas of use for existingtechnology, as well as possible military use of new technology. At SEDU, the use ofsimulation and analysis tools such as SANDIS II an aid to war gaming is currentlybeing discussed [10].

For a simulation or analysis tool to be useful within education it is importantthat the user interface is intuitive. SANDIS II is currently considered too compli-cated to be used within education at SEDU due to various parameters that need tobe adjusted before and during simulation.

2.2 The SANDIS II tool

SANDIS II is a tool for state machine based operation analytics, developed by theFinnish Defence Research Agency. It targets land warfare with an extent fromplatoon up to brigade level. Simulation scenarios can be created containing troopmovement and combat events. The scenario can then be simulated, producing aresult that can be analyzed later [5].

A scenario has many different properties that can be adjusted prior to a simu-lation. For example, troops can have different configurations including speed andequipment, the simulation can have different time intervals and the simulation areacan be changed. Different scenario parameters such as troop properties can also beadjusted during the simulation, and it is possible to go back in time to change apreviously made decision and calculate the new outcome. This makes SANDIS IIwell suited for comparative analysis and may help in decision making processes.

3

CHAPTER 2. BACKGROUND

At every simulation time step, the outcomes are statistical values producedby probabilistic calculations. Individual soldiers alternate between different states,such as taking cover, helping wounded soldiers and different combat states. Thealternating between states is done using Markov processes.

The simulator requires a lot of user input and is therefore not as well suitedfor full simulation of land warfare as it is for staging and visualizing well defined,specific scenarios. For more information on how SANDIS II and its underlyingmodels work, you may wish to read Esa Lappi’s Sandis military operation analysis

tool [5].

2.2.1 Current use of geographic data

As of today, geo-referenced map images and digital elevation models (see Sec-tion 2.3.2) can be loaded into the simulator. The geo-referenced map images deter-mine the location of a simulation scenario and acts as a backcloth, providing visualfeedback of occurring events in a simulation. The digital elevation models are onlyused for calculating the effects of indirect fire.

2.2.2 Unit velocity calculation

To move a unit, which may be of platoon to brigade size, the user first needs tocreate a path. A path consists of a set of way points marked by the user on thegeo-referenced map. When a path is created, a unit can be assigned to it and willthus start moving in a direction towards the next way point on the path.

Each unit is a state machine with the four following states.

1. Advancing

2. Firing

3. Taking cover

4. Evacuating

For each state, every unit has a base speed which is set prior to the simulationusing a user interface called troop editor. A percentage can be assigned to thefiring/advancing ratio, denoting the proportions of how long the unit will residein the firing or advancing state in each time step. This ratio will then, basedon the assigned base speed for each state, determine the unit’s movement speed.Each state affects the unit’s movement speed differently. For example, if a unit isadvancing and firing at the same time, the movement speed will be slower than thatof only advancing without firing. Terrain traits are not taken into consideration bythe simulator when determining movement speed. The only way to do that is tolet the person who plans the scenario analyze the terrain and set the parametersaccordingly, which requires a lot of work. A unit’s speed can also be adjustedmanually during the simulation by selecting a unit and editing its properties asseen in Figure 2.1.

4


Figure 2.1: SANDIS II unit properties

2.2.3 Direct fire order

When the user issues a direct fire order, these are the relevant parameters that mustbe adjusted.

Forest Density Lower forest density means higher hit probability and vice versa.

Surface Attenuation Currently the user must choose one of four types of surfaceattenuation (flatland, rolling terrain, undulating terrain, and rough terrain).

Target Visibility The user must choose whether the target is in open terrain orin forest.

2.2.4 User experience

SANDIS II currently has a working graphical user interface. However, both whensetting up a new scenario and when issuing new orders during a simulation, thereare many parameters that must be adjusted correctly. For example, after adding apath and ordering a unit to follow it, the parameters can be adjusted as shown inFigure 2.1. Because of this, extensive preparation work calculating parameters forthe scenario must be performed by the user prior to simulating. This takes too longtime and is too complicated to be used efficiently within education at SEDU.

5


2.2.5 Development environment

SANDIS II is written in python 2.7.5. Many python frameworks are used, most ofthem outdated. The outdated frameworks may make it difficult to setup a workingdevelopment environment. The python modules and versions used by SANDIS II’spython environment are listed below.

– Python 2.7.5 64-bit

– NumPy MKL 1.7.1 64-bit

– SciPy 0.13.0 64-bit

– Matplotlib 1.3.1 64-bit

– GDAL 1.10.1 64-bit + python bindings

– NetworkX 1.8.1 64-bit

– Pillow 2.6.1 64-bit

– PySide 1.2.1

– Qt 4.8.6

– PyInstaller 2.1

– jsonpickle

2.3 Geographic information

Geographic information is information used to represent and model the world. Itcan be defined as any data with a geographic reference. Geographic data is oftendivided into two categories—entities and fields. Entities are distinct objects witha geographic reference. Fields hold a value for some property in each geographicpoint [6].

2.3.1 Vector data

Vector data describes geometric objects defined as points, lines or polygons. Vectors,besides containing a geographic reference, can contain additional information aboutthe geometric object. The geographic reference can be either a 2-dimensional or3-dimensional point, depending on the context [6, p. 8][7, pp. 19-21]. Vector datais suited to represent data that does not occur continuously over the geographicmodel, as a whole. Given that vector data can be polygons, it is well suited torepresent uniform areas of different kinds.

6


2.3.2 Raster data

Raster data is used to represent continuous data over gridded surfaces. The griddedsurfaces are in most cases 2-dimensional, but in some cases 3-dimensional structures.Geographic raster data has a resolution, which describes how large a pixel wouldbe in the real world.

A common type of raster data is a Digital Elevation Model (DEM). A DEMdescribes the elevation of each point in a grid [7, pp. 51-60][6, p. 7]. Aerial pho-tographies are also stored as raster data. In cases of images and multidimensionaldata points one can use so called bands. For photography there are 3 to 4 bands:red, green, blue and sometimes alpha.

A common way of managing georeferenced or geocoded data is to embed itwithin TIFF-files. That way, all needed information for establishing an exact spatialreference for a map can be embedded in a TIFF-file’s metadata. The resultinggeoreferenced or geocoded file is called a GeoTIFF-file [13].

2.3.3 GDAL

The Geographic Data Abstraction Library (GDAL) is the most widely used opensource geospatial library currently available. GDAL is used as the back-bone inmany of today’s Geographic Information System (GIS) applications [7, p. 3]. GDALprovides an interface for applications to store, modify and perform computationson geographic data. GDAL is licensed under the very permissive X11/MIT licenseby the Open Source Geospatial Foundation (OSGeo). GDAL has, at the time ofwriting, bindings to several popular programming languages [8].

2.3.4 ArcGIS

ArcGIS desktop is a GIS product line from Environmental Systems Research In-stitute (ESRI). The product line offers many applications serving different aspectsof geographic data management. ArcMap is the application for making maps andanalyzing geographic data. By installing different extensions called “toolboxes” onecan augment the capabilities of the ArcGIS desktop suite [9].

7

Chapter 3

Method and requirements

The project work was organized into three parts in order to structure the workand provide reference for tracking progress. The structure also helped limiting theamount of time spent in each part to assure that the project was finished on time.The three phases are described and motivated in Section 3.1. A set of requirementsfor the project is presented in Section 3.2 followed by limitations in Section 3.3.The limitations helped narrowing the scope of the software development.

3.1 Project structure

Due to the project’s short duration, we reduced overhead work by adapting a simplestructure consisting of three phases. Dividing the work into a study, modelling andimplementation did nonetheless provide enough structure for managing time andtracking progress.

The objective of the first phase was to identify and acquire necessary knowl-edge prior to modelling solutions, as well as assuring the work’s conformity withSEDU’s ambition with the SANDIS II project. This was achieved by browsing thesimulator’s source code with accompanying publications and manuals, assimilatinga holistic understanding of its functionality and intended application. Subsequently,the browsing was narrowed down to focus on code responsible for controlling unitspeed and movement. The requirements were then analysed and decomposed, mak-ing it possible to gather information on tools, frameworks and methods for utilisinggeographic data.

The following list outlines the tasks performed during the study. Relevant resultsnot already covered in Chapter 2 are presented in Chapter 4.

• Study of SANDIS II’s source code, publications and manuals—focusing onhow unit speed is assigned and how it can be altered

• Analysis and decomposition of the initial requirements

• Study on categorising and combining several data sources for constructingcomposite rasters representing terrain accessibility

8

CHAPTER 3. METHOD AND REQUIREMENTS

• Search for suitable tools and frameworks for processing geographic data

With the problems identified during the first phase, the second phase (Chap-ter 5) proceeded by modelling solutions to each individual problem. The goal wasto solve the problems theoretically in order to facilitate the implementation work.Furthermore, the modular approach granted the flexibility of combining the modelsin various ways during the implementation. With that freedom the python mod-ule and its interface to SANDIS II could easily be customized whenever possibleimprovements were discovered.

The third phase (Chapter 6), describes the implementation of the models fromthe second phase. The goal was to combine the models in a module accessiblethrough an intuitive python interface, in a way that would satisfy the initial re-quirements. The software was written as a python module to enable seamless in-tegration from within the simulator’s source code. No integration with SANDIS IIwas developed as it was not an objective of the project. However some integrationideas derived from studying the simulator’s source code are presented in Chapter 6,as well as some ideas for future work in Chapter 7.

3.2 Requirements

A set of suggestions on how to improve the user experience of SANDIS II werepresented by by D.Sc Bernt Åkesson, Lieutenant Senior Grade at FDRA. The au-thors decided to follow Åkesson’s suggestions by treating them as requirements fora solution, ensuring the work’s relevance in the field. Additional tasks were avail-able, e.g. rebuilding the entire GUI in another framework. However, the followingrequirements were selected with regards to the authors’ proficiencies and the timeconstraints of a Bachelor’s thesis.

Determine the unit’s speed based on terrain and accessibility data. The route(way points) should be determined by the user.

a)

The user can choose a destination, and the software suggests routes based onaccessibility data.

b)

Automatic loading of terrain type and forest density when the user issues adirect fire order. Note that this requirement is studied by Yngve Österberg[11], and is not an objective of this report.

c)

3.3 Limitations

The system would have to be implemented in such a way that the functionalitiescould be reached from SANDIS II while running. What this essentially means isthat the modules would either have to run in the same environment as SANDIS II,or run in a separate environment, but with a stable interface between the two.

9

CHAPTER 3. METHOD AND REQUIREMENTS

The received version of SANDIS II had several compilation errors. It seemedto be an unfinished update of the Graphical User Interface (GUI). This limitationmeant that the future look and feel of the GUI would have to be reworked, beforebeing able to implementing the models. Correcting the GUI would fall outsidethe project’s scope. Instead efforts were directed on suggesting a solution to theproblems and a suggested way of implementing them.

10

Chapter 4

The study

In this chapter a decomposition of the requirements is presented together with theacquired information necessary prior to modeling solutions. Section 4.1 covers therelevant information found during the study of SANDIS II’s source code, regardinghow unit speed is determined. In Section 4.2 the derived problems and decompo-sition approach are explained. Finally, Section 4.3 presents methods of combiningand categorising geographic data, and Section 4.4 presents the results of finding atool or framework for processing geographic data.

4.1 SANDIS II unit speed

Looking at the first requirement, i.e. how to determine a unit’s speed based onterrain and accessibility data, it is evident that knowledge is required on how SAN-DIS II calculates and stores the speed of units. With that knowledge it is possibleto alter a unit’s speed. Furthermore, it could indicate possible return values andformats for a produced solution. A way of obtaining this knowledge is by exploringthe source code of SANDIS II, combined with reviewing any relevant publicationson the simulator’s implementation and technical details.

In the source code it is shown that when a unit is in the state of moving, thesimulator calculates a speed for the unit and uses it for the remaining duration ofthe current time step. A unit’s speed is determined by a state machine. Dependingon what states a unit resides in, its speed will take different values. A unit canreside in four different states where each state is associated with a predefined speed,as described in Section 2.2.2. A unit can reside in several states during a timestep, where the weight of each state dictates the ratio spent in each state during asimulation time step.

After a unit’s speed is calculated, the unit starts moving towards its next waypoint with the calculated speed. If a way point is reached, the next way point inthe path is read and the unit starts moving towards it. This happens until thesimulation time step ends or the path’s final way point is reached.

When a speed is calculated according to the steps above, it is stored in a variable

11

CHAPTER 4. THE STUDY

for each unit. Thus, a unit’s speed may be altered by manipulating its correspondingspeed variable e.g. by multiplying it with some factor. In that way, the currentprocedure of calculating unit speed is not changed. Only the resulting speed isaltered—the effects of the state machines remain unchanged.

4.2 Problem analysis

Assuming it is known how to alter a unit’s speed, the next question is—what is thebest way of doing so? In Section 4.1 it was discovered that SANDIS II calculates aspeed for each unit based on several parameters. Additionally, the calculated speedcan be seen as a base speed—calculation models leading to the base speed should notbe modified. Therefore, an aforethought solution would preserve the base speed,changing a unit’s speed only by multiplying the base speed with some factor—aterrain-, resistance- or accessibility-factor derived from the underlying geographicdata. SANDIS II simulations are divided into time steps, so a way of calculatingan average speed during a simulation time step is also required.

For both requirements, a way of combining, storing and performing computa-tions on geographic data is needed. A common way of storing geographic data is byusing rasters (see Section 2.3.2), where each pixel can hold a value representing someproperty of the corresponding location in a terrain. In that way, a terrain resistancecan be computed for each point in a raster, combining several data types, such aselevation and forest density. The calculated terrain resistance values could then bestored in a cost raster. However, details on how to process geographic data, readand write to raster files, perform computations on raster files and extract valuesfrom a certain path in a raster must be investigated further.

For the second requirement, a system for suggesting routes through a rasteris needed. A possible approach could be to compute least-cost paths through theraster—assuming the raster data accurately conform with the terrain’s actual char-acteristics.

Finally, when returning a path that is to be plotted in the simulator’s GUI,it is important that not every point on the path is plotted. That would clutterthe GUI’s map, rendering the information useless to the operator. A method ofsplitting a path into way points is needed—without placing the way points in ashape misrepresenting the corresponding full path (noticeably, a split path will inany case misrepresent the full path to some degree).The identified problems can be outlined as follows.

• Derive a model for terrain impact on unit speed and a method for altering it.

• Use several sources of geographic data to create a compound cost raster.

• Understand the process of importing and processing raster files in python.

12


• Given a start point and an end point on a map, extract all cost values fromthe corresponding cost raster, from all pixels belonging to the line betweenthe given points (line rasterization).

• Given two points, a cost raster, the length of a simulation time step and aunit’s maximum speed—calculate the average cost for the distance covered bythe unit in one time step.

• Given two points and a cost raster, calculate the least-cost path between thepoints.

• Divide a path into a set of way points. The way points should not be too closenor too far away from each other—to not clutter the GUI’s map.

4.3 Geographic data

Most of the problems stated in Section 4.2 are based on the fact that geographicdata can be used. More precisely, data describing the difficulty associated withmoving in a certain terrain.

As described in Section 2.3.2, a raster is well suited for representing continu-ous data over a surface. Therefore, an intuitive approach is to represent terrainresistance with a cost raster.

The difficulty associated with moving in a terrain depends on what unit it con-cerns. It would be impossible for a big vehicle to move through a dense forest, whileit would only slightly impair the mobility of infantry. Therefore, each unit couldhave its own cost raster representing its mobility.

For all different unit classes, the geographic data can be divided into threeaccessibility categories [15].

• GO areasConsist of areas with little to no resistance, such as roads, where a unit willbe able to move at its maximum speed.

• NO-GO areasAre areas that a unit cannot move through without coming to a standstill.For example houses, boulders, bodies of water and ditches.

• Maybe-GO areasThese areas are non-binary representations of terrain resistance. The resis-tance in Maybe-GO areas could depend on slope (calculated from a DEMas shown in Figure 4.1b), vegetation, soil type, surface roughness and otherfactors.

With these three categories it is possible to construct a cost raster—as later donein this report for the area shown by the ortophotograph in Figure 4.1a. All the GO

13


areas are assigned values of zero, and the NO-GO areas values of one. The Maybe-GO areas are assigned values ranging between 0 and 1, where 0 is no resistance and1 is full resistance. The resulting cost raster can be seen in Figure 4.1c.

4.4 Choosing a tool for processing geographic data

A tool or framework capable of reading and modifying raster files is needed inorder to perform calculations on rasters within the source code of SANDIS II. Thesimulator’s source code is written in python. Using a tool with python bindings ora python framework would therefore allow for easy integration with the simulator.A software capable of doing that is ArcGIS 10.5, with its python module ArcPy.ArcGIS is mainly considered because it is currently being used in many placeswithin the Swedish Armed Forces. While ArcGIS is a commercial product by ESRI,another GIS-software called QGIS is available open source under the GNU GeneralPublic License (GPL) Version 2 or above. Both of these applications have built-infunctions for common geospatial computations, and they both rely on GDAL (seeSection 2.3.3) for processing geographic data. Another option is to use the pythonbindings of GDAL directly, without any GIS working on top of it.

The requirements on the framework are identified as follows.

• It must run in SANDIS II’s python 2.7.5 environment.

• It must be able to read and write raster files (GeoTIFF format).

• (Optional) It should have built in functions for geospatial calculations. Thefunctions have to be implemented time-efficiently since computations may beperformed at every simulation time step.

Examining ArcGIS with its tool ArcMap, the possibility of extracting a rasterunder a certain path is shown (see Figure 4.1f). However, ArcGIS stores the path asa raster containing no applicable information about the cells’ ordering in the path.To calculate when the duration of a given time step is expired, the ability to iteratethrough cells as presented in the path is needed. To solve the problem, it is possibleto keep an external data structure keeping track of the path’s x and y values.

As for the shortest path calculation, there is an ArcGIS module doing exactlythat. However, the module needs two auxiliary rasters, seen in Figure 4.1d andFigure 4.1e, to be able to calculate the shortest path. Calculating a value for eachcell takes a time in an order of the raster’s size. If the raster is large, the modulehas to calculate two new large rasters—just to determine one path. Creating thesetwo auxiliary rasters takes up to several minutes for a map with an extent of a fewkilometers, on a laptop with 4GB of memory and a 2,6GHz Intel CPU.

ArcPy—the python bindings of ArcGIS—requires a python version (python2.7.12) not compatible with the python environment of SANDIS II (python 2.7.5),and is therefore not investigated further. Integrating ArcPy with SANDIS II would

14


")

#*

(a) Orthophotograph

")

#*

(b) DEM

")

#*

(c) Cost raster

")

#*

(d) Cost distance raster

")

#*

(e) Backlink raster

")

#*

(f) Least-cost path

©Lantmäteriet

Figure 4.1: Calculating least-cost path in ArcGIS

either require porting SANDIS II to a recent python version, or establishing estab-lishing a form of communication between the environments.

Using ArcMap’s functionality regarding least-cost paths and cost rasters maycause unexplained errors and crashes. These errors might make the software unsuit-able for developing a solution to the problems investigated in this report. However,it is possible to use the underlying library GDAL—used by ArcGIS for many of itsfunctions—directly as a python module. A benefit of using GDAL directly is thatno additional dependency would be added to SANDIS II, since GDAL already isused for map-related functionality. However, GDAL provides no functionality forcalculating least-cost paths. SANDIS II already utilizes the scikit-image pythonframework. scikit-image includes a module for least-cost path analysis. There-fore, GDAL can be used for handling geographic data together with scikit-image

for calculating least-cost paths.Generating least-cost paths using GDAL and scikit-image is significantly

faster than in ArcMap. Furthermore, it provides the flexibility of developing so-lutions in python code, and is therefore chosen for the implementation work inChapter 6.

15

Chapter 5

Modelling solutions

Solutions to the problems listed in Section 4.2 are modelled individually in order tovalidate and facilitate the implementation work in Chapter 6. In this chapter, themodels are presented and the approach to creating them from the problems. Bothmodels and implementation can be regarded as results of this report. However, thereasoning leading up to the models are also explained in this chapter, as they insome cases are required to understand the models.

The models use and depend on cost rasters. Details on constructing cost rastersare presented in Section 5.1. A method for rasterizing a line, necessary for extractingdata under a line in a raster, is presented in Section 5.2. By using line rasterization,a model for the terrain’s impact on unit speed is derived in Section 5.3 followed bya model for generating least-cost paths in Section 5.4. To solve the last problem ofrepresenting paths in the simulator’s GUI, Section 5.5 presents a model for splittingpaths into way points using the Ramer-Douglas-Peucker algorithm.

5.1 Cost raster

A cost raster is required to implement the models, as a standardised way of storingand processing geographic data. A raster representing the mobility of a generic unitin a terrain is created, i.e. an imaginary unit with mobility not made to representany specific troop type. Evaluating mobility of specific troop types, e.g. infantry,main battle tanks and trucks, would fall outside the scope of this project.

As found in Section 4.3, three categories of data need to be populated: GO,NO-GO and Maybe-GO areas.

The generic unit will not be capable of crossing bodies of water nor passingthrough buildings. Therefore, the NO-GO areas consist of vector representations ofhouses, lakes and wetlands. These areas are given a maximum resistance value of90 in the cost raster.

The GO areas consist of vector representations of roads, which are cost-freeregardless of size and shape. Even if the road’s underlying terrain is steep, the roadis given a resistance value of 0.

16

CHAPTER 5. MODELLING SOLUTIONS

All ground forces regardless of type will experience an impact on mobility dueto curvature in the terrain. For example, some vehicles may lose maneuverabilityor become inoperable on steep surfaces. A slope function ranging from 0 to 90degrees is used to represent the terrain’s curvature, further populating the costraster according to elevation data. The slope describes a cell’s inclination relativeto its surrounding cells.

The area used, a village outside the Swedish city of Sundsvall, is mostly coveredby forest. Forest density data for the area is obtainable from the Swedish ForestAgency (Skogsstyrelsen) in raster format. The forest density raster is added to thecost raster with a factor of 1

3—where the forest is at its densest, another 30 degreesare added to the slope.

To convert the cost raster’s values ranging between 0–90, into values between 0–1 as mentioned in Section 4.3, the values are normalized, i.e. the value of each cell isdivided by the maximum slope of 90. Normalization is useful when the cost raster’svalues along a path is to be combined, and interpreted as a factor representing theterrain’s impact on mobility. Normalization can be done either when creating thecost raster or at run-time. However, rasters with float type raster bands quicklygrow in file size as their extents increase. The file size is therefore reduced by usingbyte values instead of float values, hence requiring run-time normalization.

5.2 Rasterizing a line

A straight line, only represented by a beginning and an end, holds no informationabout what cells that lie in-between. In order to extract data under a line in araster, a set of cells needs to be selected. The method of converting a straight lineinto a set of cells is called rasterization.

Rasterization is a method to approximate a straight line as a set of cells, withan error as small as possible. Each pair of consecutive cells are either diagonal oradjacent to each other, making it an unbroken line.

The pixel value from a (x, y) pair can easily be obtained by rounding the twovalues, either up or down. To simplify the process all values are floored. Using thisapproach, all points in the square where 0 ≤ x < 1 and 0 ≤ y < 1 has the pixelindex (0, 0). A set of cells are selected by traversing the line and for each piece ofthe line, selecting cells resulting with smallest possible error.

The model presented here is essentially a Digital Differential Analyzer (DDA),with some borrowed elements from Bresenham’s line algorithm, see Appendix A.2.

A DDA works by adding the slope to the y value while incrementing the x value.For each incrementation, the x and y values are recorded. If the slope is less than1, the following equation is used.

yi+1 =yi + m

xi+1 =xi + 1

17


0 1 2 3 4 50

1

2

3

4

5

(0,0)

(0,1)

(0,2)

(0,3)

(0,4)

(1,0)

(1,1)

(1,2)

(1,3)

(1,4)

(2,0)

(2,1)

(2,2)

(2,3)

(2,4)

(3,0)

(3,1)

(3,2)

(3,3)

(3,4)

(4,0)

(4,1)

(4,2)

(4,3)

(4,4)

(a) Steep vector

0 1 2 3 4 50

1

2

3

4

5

(0,0)

(1,0)

(2,0)

(3,0)

(4,0)

(0,1)

(1,1)

(2,1)

(3,1)

(4,1)

(0,2)

(1,2)

(2,2)

(3,2)

(4,2)

(0,3)

(1,3)

(2,3)

(3,3)

(4,3)

(0,4)

(1,4)

(2,4)

(3,4)

(4,4)

(b) Transposed vector and raster

Figure 5.1: The same data is extracted when transposing the line and the raster

If however, the slope is greater than 1, the line needs to be transposed and thevalues are instead given by the following equation.

xi+1 =xi +1m

yi+1 =yi + 1

All these pairs of x and y values are then floored to obtain the pixels that thecoordinates reside in. This approach however, only works in the first quadrant. Tomake it work regardless of direction of the line, the line’s direction relative to itsstaring point has to be taken into consideration.

In Figure 5.1a a steep line (or vector) can be seen. If the vector and the coordi-nate system is transposed (see Figure 5.1b) and given to the DDA, it would selectthe very same pixel values as if the vector was non-steep.

A similar approach to this can be found in cucovic2016’s QGIS module “Ad-vanced viewshed analysis for QGIS”. In the module there is a function to calculateintervisibility between two points. The function in the module needs to see if thereare any obstacles hindering intervisibility. To achieve that, a line is rasterized forextraction of obstacles from a raster [2]. The function is based on Bresenham’s linealgorithm [1].

5.3 Terrain resistance

As discovered in Section 4.1, a unit’s speed is an average of different speeds dividedby the unit’s strength. As of today the terrain is not being taken into consideration

18


when calculating the speed.There are two major drawbacks from not using geographic data to calculate

speed. It demands more work from the scenario creator, who will have to take theterrain into consideration when assigning speeds to units. Also, it creates a lack ofrealism; a unit would have the same speed traversing a lake and traveling on a road.

A unit moving through terrain will be subject to some resistance, which mayvary depending on the unit’s capabilities. The resistance can be described by a costraster, specific for that unit’s capabilities, see Section 5.1. Calculating the terrain’simpact on a unit is done by analyzing the resistance experienced by traveling alonga path in the terrain. To calculate the resistance, a cost raster, a unit’s maximumspeed and a path is needed.

A path in SANDIS II is represented by a straight line between two points. Inorder to extract any information from the cost raster a rasterized path is needed. Arasterized path is represented by a list of (x, y) pairs, each being a cell in the raster.

There are two ways of turning the unit’s source and destination points into apath. Either by creating and rasterizing a straight line between the two points, seeSection 5.2. Or by calculating the least-cost path between the points and use that,see Section 5.4.

As described in Section 4.3 and Section 5.1 the cost is a number between 0 and1, and describes as a percentage of how much resistance the terrain imposes.

The speed of a unit in a cell i can be defined as vi = vmax ∗ (1−ri). Where vmax

denotes the speed of the unit as calculated by SANDIS II and ri is the resistance(cost) in cell i. So if the resistance is 0.2, the unit would move at 80% of itsmaximum speed.

Since vmax is an average speed over a time step it would make sense to calculatethe terrain’s average impact on that unit during the time step as well. The averagespeed, with the terrain taken into consideration, can be defined as the following.

v̄ = vmaxr̄

The average speed v̄ is obtaines by calculating how far the terrain allows the unitto move in one time step. Evidently, average speed is given by displacement overtime.

Displacement, is given by how far the cost raster allows the unit to move in onetime step. And the time is given by how long it takes to travel that distance. Inmost cases the time will be equal to the alloted time step, if however, the end of apath is reached, the time is shorter.

The time is obtained by iterating over each pair of cells and summing the tran-sition time with the terrain’s impact taken into consideration. When the sum isgreater or equal to the allotted timeslot, the reached cell is recorded.

The path’s length is given by the sum of all distances between the midpointsof all pairs of cells in the rasterized path. If two cells are adjacent to each other,the distance between the cells are equal to the resolution of the raster. If, however,the cells are diagonal to each other, the distance is greater by a factor of

√2. A

19


Table 5.1: Least-cost path comparison

Tool Cells CostArcGIS 1149 1199scikit-image 950 1177

function to describe the “diagonal factor” can be defined as:

k(x0, y0, x1, y1) =

{√2, if ¬(x0 = x1) ∧ ¬(y0 = y1)

1, else

The distance between two cells’ centers can be described as follows, where resis the resolution of the raster.

s(i(x0, y0)), j(x1, y1)) = res ∗ k(x0, y0, x1, y1)

The time it takes to make the transition between two cells’ centers is given bythe time it takes to traverse half the distance with one resistance, plus the time ittakes to traverse the other half with the other cell’s resistance. The transition timecan be defined as follows, where ri denotes the resistance of the cell i.

t(i, j) =

∞ if (ri = 1 ∨ rj = 1)s(i,j)2vmax

(

11−ri

+ 11−rj

)

else

These transition times are successively subtracted from the time step until ithas been consumed or the end of the path has been reached as seen in Figure 5.2.The average speed is the sum of transition lengths until the stopping point, dividedby the time it took to get there.

With the average speed known it is then possible to solve for the average resis-tance of the segment. The average resistance is given by: r̄ =

v̄vmax

. This resistancecan then be multiplied with the unit’s maximum speed within the simulation, toaccount for the terrain’s impact on the unit’s mobility.

5.4 Least-cost path analysis

An interesting feature when simulating movement in terrain, is finding the easiestpath through the terrain. An easy path, is a path that inflicts as little decelerationto a unit as possible, without impacting the traveled distance. Such a path is usuallycalled a least-cost path. There are well known algorithms for pathfinding, one beingthe A* algorithm—a modified version of Dijkstra’s algorithm.

The python framework scikit-image has a graph module, containing a functioncalled route_through_array, which calculates least-cost paths through arrays. Bycomparing the least-cost path calculations, both using ArcGIS and scikit-image, itis seen that scikit-image finds a shorter path with a slightly smaller cost, as seen

20


terrain_resistance(Raster,Path,

Time Slice)

Initializevalues

Calculatetransitiondistance

Calculatetransition time

Subtract timefrom timesliceAdd distance tototal distance

Time Slice> 0and

Distance left

Get next cell

return v̄

vmax

yes

no

Figure 5.2: Terrain resistance flowchart

in Table 5.1. Also, the execution time was shown to be faster using scikit-image,making it more suitable to be used for solving the problem.

5.5 Splitting a path into way points

In SANDIS II, paths are stored as sequences of way points. Drawing all the returnedpoints from the least-cost path model (described in Section 5.4) as way points, wouldquickly clutter the GUI’s map. A solution is to split the path into a smaller setof way points that is returned to SANDIS II (see Figure 5.3b). Those way pointsonly serve the purpose of visual feedback to the user, while the underlying speedcomputations for each time step would still be done using the full shortest path.

To split a path into way points, the Ramer-Douglas-Peucker algorithm (seeAppendix A.1) can be used. When the user adds a way point using the SANDIS IIuser interface, either a new path is created with the new way point, or the new waypoint is added to an already existing path. In the case of creating a new path, onepossible way of integrating with SANDIS II is to add an option in the user interface,letting the user choose whether the least-cost path module should be enabled or not.

21


0 100 200 300 400 500 600

0

100

200

300

400

500

(a) Least-cost path before split intoway points

0 100 200 300 400 500 600

0

100

200

300

400

500

(b) Least-cost path split into waypoints using the Ramer-Douglas-Peucker algorithm. The blue crossesindicate way points that will be re-turned to SANDIS II, where they willbe used to construct a path.

Figure 5.3: Splitting a path into way points

If the least-cost path module is enabled, the least-cost path is calculated. The least-cost path is then split into way points which are returned to the simulator and addedas a path. The tolerance of the Ramer-Douglas-Peucker algorithm can be set as anargument to the function, where the argument is multiplied with the resolution ofthe cost raster. When a unit is ordered to follow that path, the average terrainresistance is calculated over the least-cost path of the current line in the path.

22

Chapter 6

Implementation

This chapter suggests an implementation of the models created in Chapter 5. Theimplementation is written in python code as a module—a stand-alone python filewith an interface. The module’s interface can be accessed from within the sourcecode of SANDIS II by an import statement, granted that the module’s source fileis located in the same directory as the simulator’s source code. In Section 6.1,the python module is described in more detail. In Section 6.2 an overview of theimplementation and its interface is illustrated with a flow chart. Finally, Section 6.3presents ideas on how to integrate the module with SANDIS II.

6.1 Python implementation

The python module is implemented as a class, in a stand-alone python file. The fileis named costrasterkit.py and the class is named costRaster. Internally, thepython module relies on several methods implementing the models from Chapter 5.The models are combined in a procedural way and are accessed by interface methods.Below is a list of each internal method used by the interface in the costrasterkit

module, excluding the interface methods themselves, that are later described inSection 6.2.

pointLineDistance(point, lineStart, lineEnd)

Returns the euclidean distance between point and the line segment betweenlineStart and lineEnd. This function is used by the Ramer-Douglas-Peuckeralgorithm when splitting a path into way points, when calculating whether apoint is within the tolerated deviation or not.

rdp(path, epsilon)

Takes a path (a list of tuples holding x and y coordinates) and a deviationtolerance epsilon. Returns a list of way points using the Ramer-Douglas-Peucker algorithm.

23

CHAPTER 6. IMPLEMENTATION

shortestPath(startPoint, destPoint, coordinates=True)

Returns a triple containing a list of all points in the computed least-cost path,an array where all points on the path have their value set to 1, and the totalcost of the path.To calculate the least-cost path, the skimage.graph.route_through_array

method from the scikit-image python framework is used.

extract_line_from_raster(line)

Takes a path (a list of tuples holding x and y coordinates) and returns a listof all cost values, corresponding to each point on the path. This method isused to extract data from a raster.

line2array(startPoint, endPoint)

This method is used for rasterizing a line. Given two points, the indices of allcells crossing the line are returned as a list.

getAvgTerrainResistance(costsPath, timeSlice, unitRawSpeed)

Used by timesliceResistance. Given a list of costs, which can be extractedeither from a least-cost path or from a straight line using line2array andextract_line_from_raster, calculates the average resistance (where resis-tance is a function of costs from the cost raster) for the distance covered by theunit in one simulation time step. The returned value is a mobility resistancerepresented as a value between zero and one.

raster2array()

This method is only used by the constructor. It loads a raster as an array,as an instance variable using the raster file’s path specified when calling theconstructor. To read raster data, the GDAL python bindings are used.

directionK(startPoint, endPoint)

Takes two neighboring points and returns√

2 if the points are positioneddiagonally to each other, or 1 if they are side by side in any direction. Thismethod is used by getAvgTerrainResistance in order to calculate the realdistance traveled by moving from one point to another neighboring point.

coord2pixelOffset(x, y)

A method used to convert coordinates to array indices. Uses meta-data fromthe cost raster to determine its resolution, and can thereby convert coordinatesto pixel offsets.

6.2 Interface

The interface methods may be used to access the module from the simulator’s sourcecode. Using the interface is optional but promotes using the module as a solution tothe requirements in Chapter 3. The internal methods can be customized or invokedexplicitly to achieve different ways of integrating with SANDIS II.

24


Listing 6.1: Instanciating a costRaster object in python

1 from costrasterkit import costRaster

23 RasterObject = costRaster ("/home/olof/ geodata /

cost_raster .tif", 90, 12.5)

4 resistance = costRaster . timesliceResistance ((0 ,0) ,

(47 ,11) , 60, 4)

5 print resistance

The costrasterkit class must first be instantiated using its constructor, takingas arguments a cost raster filename, a maximum cost value and a deviation toleranceused by the Ramer-Douglas-Peucker algorithm. The constructor then loads the costraster into memory and initializes its instance variables, so that they are accessiblefor all class members. Instance variables that are used often, for example the costraster array, do not need to be provided as arguments to the interface methods. Anoverview of the interface can be seen in Figure 6.1. Following is a list of the interfacemembers visible to SANDIS II after importing the costrasterkit module.

costRaster(filename, maxCost, epsilon)

Constructor

timesliceResistance(start, dest, time, unitRawSpeed, shpath=True)

Returns average resistance as a floating point value between 0 and 1. If theboolean variable shpath is set to True, the least-cost path algorithm will beused. Otherwise, the resistance will be calculated along a straight line betweenthe given points.

shortest_path_waypoints(start, dest)

Returns a list of way points. This method may be used to split a path intoway points, to make a simplified graphical presentation of a path possible inthe SANDIS II user interface.

In Listing 6.1 the costRaster object is initialized with a file path to a costraster, a maximum raster value of 90 and a deviation tolerance of 12,5 meters.After the initialization, the average resistance between two points is calculated,using a simulation time step length of 60 seconds and a unit base speed of 4 m/s.Finally the resistance is printed to the standard output stream.

6.3 Integrating with SANDIS II

The timesliceResistance method returns a value between zero and one, repre-senting an average terrain resistance for a traversed path. One way of adjusting

25


AverageResistance

ifshortest

path

Rasterizeline

scikit-image

Resistancecalculator

no

P ath,

T ime slice,

Raster

yes

P ath,

T ime slice,

Raster

r̄

Raster

T ime slice

Source

Destination

vmax

r̄

Way points

scikit-image

RDP

Raster,Source,

Destination

P ath

ε

W ay points

Raster

Source

Destination

ε

W ay points

SANDIS II interface Our implementation

Figure 6.1: Interface to SANDIS II

a unit’s speed is to multiply the unit’s speed-variable in SANDIS II by a factorof one minus the return value of timesliceResistance. Thus, speed is reducedif a terrain resistance is present, and remains unchanged otherwise. To make thefeature available to the user, the SANDIS II GUI must be updated. For example,the GUI could let the user choose whether the module should be enabled or not,and should provide a context for easy importing of cost rasters to the scenario.

The shortest_path_waypoints method returns a list of way points. To inte-grate this method with SANDIS II, there are two further problems to be solved.

1. Define a way of adding way points returned by the shortest_path_waypoints

method to the data structure for paths in SANDIS II

2. Define a way of updating the SANDIS II GUI to let the user choose whetherthe least-cost path module should be used or not when adding a new path

26

Chapter 7

Discussion

This chapter discusses limitations of the solutions as well as interesting ideas and as-pects that arose during the project. A discussion regarding the choice of frameworkrelated to other valid candidates is presented in Section 7.1. Section 7.2 discussesthe line rasterization model and how the authors modeled a DDA without knowing.Creating accurate cost rasters was not an objective of the project, but in Section 7.3some improvements on constructing cost rasters and extracting cost values are dis-cussed. In Section 7.4 some weak points with the used path-finding algorithm andthe implementation is covered, followed by suggestions for future improvement. InSection 7.5 an issue regarding intersecting paths and NO-GO areas is discussed,together with some smaller issues with the model for calculating terrain resistancefactors over a time step. Concluding the chapter, the many ethical aspects of warfaresimulation are discussed in Section 7.6

7.1 Choice of framework

When developing the python methods, GDAL was used to serve the geographicinformation. GDAL is already used by SANDIS II, making it an easy choice fordeveloping the models, as no additional dependency would be added.

In the first phase of our project, ArcMap was used to experiment with geographicdata. However, to make ArcGIS interact with SANDIS II, some sort of interfacethat could handle connections to ArcGIS would have to be implemented, since itwould not run in the same python environment. It was concluded to be outsidethe project’s scope, considering the given requirements. A considerable approachcould also be to rewrite the simulator’s source code in the same python versionas the newest ArgGIS software use (ArcGIS Pro 1.2 at the time of writing). Thebenefit would be ease of integration with existing systems used by the SwedishArmed Forces already using the ArcGIS suite, for example centralized geographicdata servers. Unfortunately, this would not have been possible within the project’stime frame.

If the demand for handling, classifying and serving data to SANDIS II increases,

27

CHAPTER 7. DISCUSSION

there might be a need for a full-fledged GIS. ArcGIS contains a lot of geospatialfunctions but in order to use those functions, ArcGIS would have to either run inthe same environment as SANDIS II, or provide an interface for each function.

If the SANDIS II resource manager was to be updated, it would be valuable tosee if it could make connections to GIS servers. That way there could be a centralGIS server managing all data, and each SANDIS II instance would not have tohandle huge datasets by itself. By running a centralized GIS server it would also beeasier to keep all simulator instances provided with the most recent data available.

7.2 Rasterizing line

The model presented in Section 5.2 was designed by the authors with no priorknowledge about Bresenham’s line algorithm or DDAs. It was in a later stage ofthe work that the model’s similarities to Bresenham’s line algorithm were discovered.

The developed model turned out to be a DDA. When later discovering DDAs,it verified the correctness of the model. However the error in the developed modelmight be greater than that of Bresenham’s line algorithm. Before implementinga straight line rasterization algorithm into SANDIS II, it might be interesting toevaluate the different algorithms.

It would also be valuable to look into the effects of using an anti-aliased line al-gorithm, such as Xiaolin Wu’s line algorithm [17]. An anti-aliased line is a smootherline, that could create an interesting effect when extracting values from the raster.

7.3 Cost rasters

In this report the focus was not to create a realistic cost raster, but rather on theoperations on the rasters. There are quite a few things to consider if geographicinformation were to be integrated into SANDIS II.

In our solution a cost varies between 0 and 1, where 0 is no resistance and 1 isfull resistance. It would be beneficial to do the inverse. If we let the raster representthe mobility where 0 is full resistance, we would have some benefits. As proposedby Rybanský the compound cost raster C could be described as:

C =n

∏

i=1

Ci

Where Ci is a cost raster and n is the amount of cost rasters. [14, p. 66] Rybanský’sway of modeling the compound cost raster differs from ours. Our approach adds adifficulty while Rybanský’s has “percentage coefficients”. If an automatic generationof cost rasters was to be implemented in SANDIS II, Rybanský’s approach wouldhave to be the preferred way.

Something that could further improve an automatic construction of cost rastersis the use of a function mask. The mask, which would be unique for each unit,would contain one function for each raster. The function would describe how to

28


transform data in the cost raster before creating the composite raster. In such ascenario, a function would be able to describe an exponential relation. For someunit types it might be exponentially harder to move as the slope increases.

A similar approach could be used at run-time when extracting data from a costraster. Each unit’s cost raster is different, but the geographic data that the rastersare built from are the same for all units. Instead of having prepare one cost rasterfor each unit for each scenario, the effects of the cost rasters could be calculated byselecting specific properties from different rasters at run-time. In that way, using onecost raster per data type, the data sets required would be smaller and constructedwith better time efficiency.

When merging geographic data, it would also be valuable to look at the relation-ship between different data sets. Instead of deeming all bodies of water impassable,one could allow units to cross bodies of water where the underlying elevation mapmakes the water shallow enough. One could also imagine the case where it wouldbe fatal to drive in certain angles depending on what soil the ground consists of.A more advanced system would allow for the possibility to define relations betweendifferent datasets, and also allow to define a unit’s relation to such relations.

7.4 Least-cost path analysis

According to the source code of scikit-image’s method route_through_array, thealgorithm used for finding least cost paths is Dijkstra’s minimum cost path algo-rithm [12]. This algorithm solves the problem, but for large graphs it is not veryefficient. There exists modifications of Dijkstra’s algorithm with better time com-plexity. For example, the A* algorithm may be used. It is also possible to reducetime complexity at runtime even further by pre-processing a graph. For improvingpathfinding performance within large cost rasters it might be worth looking intocontraction hierarchies [3].

Another point worth discussing is how a route is presented to the user. In ourproposed implementation, when a user wants to add a path using the shortest pathmethod, the user is only presented with one path—the shortest path. A way ofincreasing the versatility of the shortest path method could be to generate severalgood paths (paths with low total resistance), plot them on the map, and let theuser choose which one to use.

To improve the shortest path method even further, we suggest questioning whichproperties of a path are most important within the scope of SANDIS II. In ourproposed implementation, the only variable being minimized while finding the least-cost path is the time it would take for a unit to reach its destination. However,since the scope of the simulator is land warfare, other properties of a path could beconsidered equally, or even more important than the time to reach a destination. Forexample, when planning a route through enemy territory, the surrounding terrain’sability to protect the advancing unit from being spotted by the enemy might be apriority. Subsequently, the user could be given the option to choose what variables

29


to optimize for, enabling more realistic route planning.

7.5 Calculating speed along path

There are many variables that goes into modeling the terrain’s impact on a unit,because it does not solely depend on the terrain. The impact is a function of boththe terrain and the unit itself. Depending on the unit’s capabilities to handle theterrain, the outcome of the impact varies. In our model, the only variable of unitsthat we took into consideration was maximum speed. One might get more preciseand realistic models if size, weight, traction and other properties are considered.

Our model is an approximation of the path’s impact, and therefore containsa substantial error. Instead of reporting back to SANDIS II for each cell passed,our model returns an average resistance. The unit will move along a straight linebetween two way points, while the data that decides the impact is an approximationof that line.

With SANDIS II’s current implementation we are faced with a problem if theunit reaches its way point and still has time left of its allotted time step. As of nowSANDIS II will keep the same terrain resistance over the remaining time step, evenif the direction has changed. It is therefore important if the module is implemented,that SANDIS II queries for a new path resistance each time the time step is overor a way point has been reached.

One thing that we did not consider when calculating the transition length be-tween two cells is the vertical difference between them. However, the real distancecan be calculated as follows, where l is the original distance, l′ the final distanceand α is the slope between the two cells [14, p. 68].

l′ =l

cos(α)

The vertical climb also affects the deceleration of the unit. The deceleration canbe described as l

l′. This coefficient can then be multiplied with the maximum speed

to obtain the slope’s direct impact on the speed [14, p. 68].For a future implementation it could be good to review what happens when the

terrain impose such a big impact on a unit that it cannot continue. It would be ablow to the usability if the user of the simulator would not get any feedback if theroutes are invalid. One could imagine either an error message or modify the waypoint placing so that it would not allow placing paths that cross NO-GO areas. Ourimplementation can detect when a unit hits a NO-go area, and could therefore beused to test a path when a unit is assigned to it. An image generated while testingthe terrain resistance function can be seen in Figure 7.1.

30


0 100 200 300 400 500 600

0

100

200

300

400

500

Figure 7.1: Simulation of a unit advancing on a obstructed path.

7.6 Ethical aspects

The ethical aspects of warfare are many and complicated. It would fall outsidethe scope of this report to try to discuss whether or not war itself is ethical. Herehowever the ethical problems concerning warfare simulation will be discussed. Theethical problems can be divided into three categories:

• The design of warfare simulation.

• The purpose of warfare simulations.

• The actual usage of warfare simulation.

The ethical problems impact different parties. Apart from the obvious militaryand civilian individuals there are parties such as historical and cultural buildings,ecological systems and endangered species.

Nations following international law aim to minimize the impact on all the abovementioned parties. Warfare simulation can assist in developing strategies doingexactly that. With the flip of a switch however, a simulator could be used tooptimize for the exact opposite: maximal inflicted damage on all parties. Even ifthe intended usage of the simulator is to minimize, if it falls into the wrong handsit can have the dreadful capability of planning atrocities.

When designing a warfare simulator it is important that the underlying modelsare tested and verified. No simulator can perfectly represent the world as it is,but it is important that the simulator does what it’s purposed to do. If a warfaresimulator was based on faulty models it could have fatal consequences for all above

31


mentioned parties. It is extremely important that the shortcomings of a simulator’scapabilities are clearly communicated. It would put lives at risk to try to hide flawsor falsify the capabilities of a warfare simulator.

The purpose of a warfare simulator seems quite clear, it simulates warfare. How-ever there are underlying and more specific purposes. It is important that the sim-ulator’s purpose is to simulate warfare in a, to the extent possible, ethical way. Itwould be an unethical purpose to simulate in order to maximize the effect of chemi-cal weapons. It would however be ethical to simulate chemical weapons to calculatethe optimal defence against it.

There are ethical aspects depending on how a warfare simulator is used, and whouses it. An ethical purpose and a correct design does not matter if the simulatorwill be misused. The user of a warfare simulator has as much responsibility asthe designer. It is crucial that the user understands that a simulation never canrepresent the world as it is, and that the results from simulations could put allparties at harm if acted on. It is also important that a warfare simulator doesnot fall into wrong hands, since that would allow planning of strategies breakinginternational law.

The SANDIS II simulator is not intended for decision support. It is purposedto be used in the education of officers. If officers’ education gets impacted byflawed models, it might impact their future ability to make decisions. That waySANDIS II could indirectly impact decisions. Officers in training should be madevery clear about the capabilities and flaws of the SANDIS II simulator.

32

Chapter 8

Conclusions and future work

The work showed that it is possible to import and use geographic data to auto-mate tasks that would otherwise have to be performed manually, in the SANDIS IIsimulator.

The report presents two methods aided by geographic data: least cost pathanalysis and the terrain’s impact on units’ speeds. These models show that it ispossible to adjust a unit’s speed as well as quickly finding fast routes through terrainusing geographic data. Furthermore, the python implementation showed that themodels could be implemented using a few available python modules such as GDALand scikit-image, without needing to use a fully equipped GIS.

Usability and user-friendliness as concepts stretch far beyond the audiovisualaspect. Our suggested solutions would assist the user by taking away cumbersomework, but would not necessarily have to be shown visually. Ideas for future workand improving our implementation are presented in Section 8.1.

8.1 Future work

In Chapter 7 we have discussed what can be improved with the implementation.Some ideas for future work have been mentioned throughout the report, and willbe summarized below.

For future development it is suggested that SANDIS II’s resource manager willbe given extended capabilities to handle geographic data. The updated resourcemanager would enable further development of geographic aided computations. Itwould be important for the resource manager to support classification of rasters.By supporting classifications, a software function could request all rasters with acertain feature for a certain unit class.

In order to improve versatility and utility of the least-cost path module, it wouldbe interesting to implement the following two functionalities.

• When a new path is added using the least-cost path module, provide theuser with several different paths and let the user choose which one to use.

33

CHAPTER 8. CONCLUSIONS AND FUTURE WORK

Implementing this functionality may raise some problems. For example, howto ensure that the algorithm does not return too similar paths? Letting theuser choose from a set of paths that differ from each other only on some pixelswould hardly be useful.

• In this report’s solution, the least-cost path is determined by minimizing costsin a cost raster, and thus consequently maximizing the speed of a unit. How-ever, in a land warfare simulation, there might other more important factorsto consider than travel time. It would be interesting to investigate whichare the most important factors when planning an advancement route, anddevelop an algorithm that can find good routes based on those factors usinggeographic data. For example, if the resource manager is extended to sup-port classifications of different rasters, an approach could be to introduce afunction, taking as arguments a unit class and one or multiple factors to beoptimized. The function could then use the resource manager to obtain acomposite cost raster, consisting of a combination of all rasters for the givenunit and optimization factors. The least-cost path method could then find aleast-cost path in the customized composite raster.

34

Appendix A

Algorithms

A.1 Ramer-Douglas-Peucker algorithm

Given a polyline and a predefined distance ε, the Ramer-Douglas-Peucker algorithmis a way of approximating the polyline with less points. Points of the approximatedline are selected by following a recursive procedure. At first, the first and the lastpoint of the polyline are selected, as shown by line a in Figure A.1.

Then for each point between the end points, the distance between each pointand the line segment formed by drawing a line between the two end points is cal-culated (see line b in Figure A.1). The point with the largest distance to the linesegment (which is the current best approximation of the original polyline) is found.If the distance of that point is greater than the deviation tolerance ε, it is selectedfor the approximation. The polyline is then split into two polylines at the selected

Image by the original uploader Leupold at German Wikipedia [CC BY-SA 2.0], via Wikimedia Commons [4].

Figure A.1: Visualisation of the Ramer-Douglas-Peucker algorithm, where 0 is theinput polyline and 4 is the constructed approximation with deviation tolerance ε.

35

APPENDIX A. ALGORITHMS

point, and the algorithm calls itself recursively with those polylines. When the re-cursion is finished, the approximated polyline is constructed from all selected points.

A.2 Bresenham’s line algorithm

Bresenham’s algorithm is a algorithm to make an approximation of a straight linewith pixels. Bresenham developed the algorithm for digital plotters, at IBM in theearly 1960’s. The algorithm is essentially a Digital Differential Analyzer (DDA).The algorithm works by recursively choosing the plotter move which yields the leasterror, until it reaches its goal point [1].

36

Bibliography

[1] J. E. Bresenham, “Algorithm for computer control of a digital plotter”, IBM

Systems journal, vol. 4, no. 1, pp. 25–30, 1965.

[2] Z. Čučković, “Advanced viewshed analysis: A quantum GIS plug-in for theanalysis of visual landscapes”, The Journal of Open Source Software, vol. 1,no. 4, Aug. 2016.

[3] R. Geisberger, P. Sanders, D. Schultes, et al., “Contraction hierarchies: Fasterand simpler hierarchical routing in road networks”, in International Workshop

on Experimental and Efficient Algorithms, Springer, vol. 5038, 2008, pp. 319–333.

[4] L. at German Wikipedia. (Feb. 2007). Line simplification using the ramer-douglas-peucker algorithm, [Online]. Available: https://upload.wikimedia.

org/wikipedia/commons/9/91/Douglas_Peucker.png (visited on 04/24/2017).

[5] E. Lappi, “Sandis military operation analysis tool”, 2nd Nordic OA Sympo-

sium, 2008.

[6] C. Lloyd, Spatial data analysis: an introduction for GIS users. Oxford, UnitedKingdom: Oxford university press, 2010.

[7] D. McInerney and P. Kempeneers, Open Source Geospatial Tools: Applications

in Earth Observation. Cham, Switzerland: Springer International Publishing,2015.

[8] Open Source Geospatial Foundation. (Feb. 2017). GDAL homepage, [Online].Available: http://www.gdal.org/ (visited on 04/24/2017).

[9] T. Ormsby, E. J. Napoleon, R. Burke, et al., Getting to Know ArcGIS Desktop,M. Karman, Ed. ESRI Press, 2010.

[10] D. Oskarsson and P. Rindstål, “Evaluation of sandis”, Dec. 2009.

[11] Y. Österberg, “Determining line of sight obstructions using geospatial analy-sis; modeling solutions for combat simulators”, 2017.

[12] Z. Pincus and A. Klein. (2009). Cython implementation of dijkstra’s minimumcost path algorithm, for use with data on a n-dimensional lattice, [Online].Available: https : / / github . com / scikit - image / scikit - image / blob /

master/skimage/graph/_mcp.pyx (visited on 04/24/2017).

37

https://upload.wikimedia.org/wikipedia/commons/9/91/Douglas_Peucker.png

https://upload.wikimedia.org/wikipedia/commons/9/91/Douglas_Peucker.png

http://www.gdal.org/

https://github.com/scikit-image/scikit-image/blob/master/skimage/graph/_mcp.pyx

https://github.com/scikit-image/scikit-image/blob/master/skimage/graph/_mcp.pyx

BIBLIOGRAPHY

[13] N. Ritter, M. Ruth, B. B. Grissom, et al., “Geotiff format specification geotiffrevision 1.0”, SPOT Image Corp, 2000.

[14] M. Rybanský, Cross-Country movement: Modeling, 1st ed. Brno, Czech Re-public: Akademické Nakladatelství CERM®, s.r.o, 2010.

[15] Å. Sivertun and A. Gumos, “Analysis of cross country trafficability”, in Progress

in Spatial Data Handling: 12th International Symposium on Spatial Data Han-

dling, A. Riedl, W. Kainz, and G. A. Elmes, Eds. Berlin, Heidelberg: Springer,2006, pp. 921–941.

[16] Swedish Defence University. (Sep. 2015). Military technology, [Online]. Avail-able: http://www.fhs.se/en/research/research- areas/military-

technology (visited on 04/24/2017).

[17] X. Wu, “An efficient antialiasing technique”, in Proceedings of the 18th An-

nual Conference on Computer Graphics and Interactive Techniques, ser. SIG-GRAPH ’91, 1991, pp. 143–152.

38

http://www.fhs.se/en/research/research-areas/military-technology

http://www.fhs.se/en/research/research-areas/military-technology

TRITA Trita-ICT-EX-2017:114

www.kth.se

improving usability of land warfare simulator: pathfinding and...

Documents