Linköping University | Department of Computer And Information Science Bachelor thesis, 16 ECTS | Innovativ Programmering Spring term 2020 | LIU-IDA/LITH-EX-G--20/039--SE
Pathfinding in the forest
Anton Karlsson
Eric Östholm
Supervisor: Anders Fröberg Examiner: Erik Berglund
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25
years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to download, or to
print out single copies for his/hers own use and to use it unchanged for non-commercial research and
educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the
document are conditional upon the consent of the copyright owner. The publisher has taken technical and
administrative measures to assure authenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned when his/her work is
accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedure s for publication
and for assurance of document integrity, please refer to its www home page:
http://www.ep.liu.se/.
Pathfinding in the forest
Eric Östholm
Linköping, Sweden
erios853@student.liu.se
Anton Karlsson
Linköping, Sweden
antka586@student.liu.se
ABSTRACTDijkstra’s algorithm used for pathfinding in a grid type setting consisting of forest geoda ta with multiple a ttributes. A cost a na lysis wa s performed rega rding the memory required to run the a pplica tion. This cost a na lysis yielded in a spa ce complexity of O(n), a nd a cla ss structure with focu s on low memory usa ge while still ma inta ining desired functiona lity. The test shows a reduction of a bout 17,9% in memory usa ge compa red to without memory sa ving mea sures. The a lgorithm a nd cla ss structure a re used in a web-ba sed a pplica tion implemented with Ja va Script. Author Keywords
Pa thfinding, memory ma na gement, geoda ta , web-ba sed a pplica tion a nd Dijkstra ’s a lgorithm.
INTRODUCTION
Exporting timber a nd other timber-ba sed products ma ke up a significa nt portion of the Swedish Gross Domestic Product (GDP). Felling forest is consequently a huge industry in Sweden, with close to 100 million cubic meters of timber being cut down ea ch yea r a ccording to Skogsstyrelsen1.
If a compa ny is pla nning to clea r a new a rea of the forest they must find a nd clea r a pa th through the forest to the a rea . This pa th is then used, for exa mple, to a ccess the a rea with ma chines a nd to extra ct timber. To find this pa th ca n be quite a cha llenge, a s the pa th ought not to go through wetla nds or be too steep for their ma chines etc. The ta sk of finding this pa th is usua lly done ma nua lly, by going to the loca tion a nd pla nning the pa th by foot. It is in the interest of the person pla nning pa ths to a lso inflict the lea st a mount of da ma ge to the surrounding forest when working there. The product of this work hopefully will help users a chieve this goa l while sa ving time a nd effort.
Compa nies ha ve expressed a need for a softwa re tool tha t ca n find the chea pest pa th possible from a n inputted sta rting position to a ny public or priva te roa d using terra in da ta . Wha t roa d does not ma tter in most ca ses a s the compa ny felling wood usua lly ha s a ccess to a ll roa ds surrounding the forest. This mea ns tha t the tool will ha ve to consider a ny nea rby roa d to be a va lid goa l.
The cha llenge for this a pplica tion is ha ndling the la rge a mount of da ta tha t is a va ila ble when working with
1 Skogsstyrelsen.se, ”Bruttoa vverkning”:
https://www.skogsstyrelsen.se/sta tistik/sta tistik-efter-a mne/bruttotistik-efter-avverkning/
geogra phica l da ta . Ha ndling la rge a mounts of da ta is usua lly a problem to consider with a ny a pplica tion. Wha t increa ses the difficulty with this a pplica tion is tha t it is implemented in a web browser, which ha s more restricted memory a lloca tion tha n usua l a pplica tions. The focus of this project is to reduce memory usa ge to a ba re minimum to ena ble the la rgest sea rch a rea s possible.
Purpose
The purpose of this work is to design a nd crea te a web a pplica tion ca pa ble of ha ndling a n a s la rge geogra phica l a rea a s possible. The a pplica tion must consider limita tions specified by the user, a s use ca ses ca n va ry between personnel inspecting forest to wider pa ths being felled for ma chine a ccess.
Research question
How should a porta ble web a pplica tion used for pa thfinding in geoda ta be designed to cope with a s la rge geogra phica l a rea a s possible?
Delimitations
The focus of this work is on a llowing users to sea rch la rge a rea s of forest to find their optima l pa ths. Mea ning tha t t h is project disca rds time optimiza tions a nd will not include a ny time mea surements.
Users of this a pplica tion a re expected to provide their own forest geoda ta a nd roa d da ta , a nd often ha ve it loca lly on their computers. Users will then be a ble to use this in the field without a ny need for internet a ccess. Th e a pplica tion will be developed to work in computer browsers with no cellphone a ccessibility in mind.
This work a ssumes tha t there a re APIs (a pplica tion progra mming interfa ce) in pla ce tha t the a pplica tion ca n query to get terra in da ta a nd roa d da ta for a given a rea . Th e terra in API wa s supplied by Fora n, but due to CORS issues, a proxy wa s required to a ccess the API. We built a sta nda lone API for querying roa d da ta .
Motivation
The client, Fora n, is interested in offering their customers a web-ba sed a pplica tion tha t uses forest geoda ta a nd pa thfinding a lgorithm s to find pa ths through forests to roa ds. Such a web-ba sed a pplica tion ha s been requested by Foran’s clients to allow them to more easily find paths through forests a nd reduce their ha rm on the na ture. THEORY
The theory behind this project is to be divided into two pa rts, memory ma nagement a nd pa thfinding.
Memory management
For a process on a computer to work, it requires memory to store its da ta . Ordina rily, a pplica tions ca n use some pa rt of the a va ila ble RAM, but there is only so much memory a va ila ble in a system, tha t processes need to pra ctice memory ma na gement to fit a ll its da ta in the a va ila ble memory. Web browsers ca n ha ve severa l a ctive ta bs tha t ha ve to sha re the RAM a va ila ble to the browser, limiting a va ila ble memory even further. Chromium -ba sed browse rs, a mong others, sta rts a new OS process for ea ch ta b2 which
ma kes more memory a va ila ble for ea ch ta b , but the point still sta nds tha t memory ma na gement is required. As our a pplica tion will be running in web browsers, ma na ging memory is going to be the most importa nt fa ctor to ma ke sure the a pplica tion ca n be used to its fullest extent. The two things in the a pplica tion tha t requires the most memory a re storing a ll Nodes a nd running the pa thfinding a lgorithm. Ea ch Node object ha s to sa ve a ll da ta required for the pa thfinding a lgorithm a nd recrea ting the pa th . The pa thfinding a lgorithm ha s to keep tra ck of a ll Nodes tha t it ha s visited a nd a ll run-time ca lcula ted va lues.
As the pa thfinding is a pplied to a n a rea , doubling the ra dius of the sea rch a rea equa tes to qua drupling the a mount of data a nd memory required. To a dd to this, one requirement for the a pplica tion is to be a ble to ha ndle multiple la yers of geogra phica l da ta while sea rching. The required da ta , a nd memory, rise a t exponentia l ra tes a s the user increa ses sea rch a rea a nd da ta la yers. To ena ble users to sea rch the la rgest a rea possible, this mea ns keeping the memory usa ge for the sea rch a rea a nd la yer da ta a s low a s possible.
Figure 1: Basic pathfinding example.
2 Chromium.org, “Process Models”:
https://www.chromium.org/developers/design-documents/process-models
Pathfinding
This project involves pa thfinding in a gra ph of nodes, i.e. a grid of squa res, with obsta cles a nd weighted nodes. This is visua lized in figure 1, where ea ch white node is a possible position, green is the sta rting position, red is the goa l position a nd a ll-bla ck nodes a re obsta cles. While finding the shortest pa th between green a nd red is quite ea sy in this exa mple, the complexity of finding pa ths increa ses a s a rea a nd obsta cles do.
Note how node is spelled with a lower case “n” when it refers to a node in a gra ph. Node with upperca se “N” will refer to the cla ss Node tha t is used to progra mma tica lly represent a node.
To a dd a nother la yer of complexity to the problem, the a pplica tion must find the chea pest pa th, where the chea pe st could mea n the most time-efficient one, the shortest one or some other mea sure. This mea ns tha t pa thfinding would a dd a cost, or weight, of moving between nodes. In this ba sic ca se, the time cost of moving between nodes is a sha red consta nt for a ll nodes, since they a re a ll equa l sizes, a nd the chea pest pa th would, in this ca se, be the shortest pa th.
Figure 2 shows how the finished pa thfinding is supposed to work. Avoiding a rea s with va lues over the set threshold a nd finding a pa th to a nea rby roa d. Figure 2 uses da ta form one la yer (wetness). A hypothetica l use ca se for the a pplica tion is for someone trying to find a pa th in the forest with the lea st a mount of wetness in the ground to not da ma ge the vegeta tion. Then the cost of moving to a node is set to the
Figure 2: An example of the finished pathfinding. Red areas on the map indicate no go zones. The computer-generated path is marked red and physical roads are marked blue. Underlying data was generated using measurements from laserdata skog.
mea sured wetness in tha t node. When the pa thfinding a lgorithm then tra verses the gra ph, it ca n a void wettest nodes a nd, while it might not be the shortest pa th to the goa l, it will be the driest one.
Dijkstra’s algorithm, which is used in this application, finds the shortest pa th between two nodes in a gra ph by la beling one of the nodes a s the sta rt node a nd the other a s the end node. It will then ca lcula te the cost of going to a ll of the sta rt node’s neighboring nodes, a dding those nodes to a list, and then “visiting” the node in the list with the lowest cost, and calculating the cost of moving to that node’s neighbo rs. The a lgorithm will continue to visit the node in the list with the lowest cost a nd ca lcula ting neighbor costs until it find the end node, a t which point it will ha ve found the chea pest pa th between the sta rt a nd end nodes. In the ca se of this a pplica tion, there ca n be multiple end nodes since there a re roa ds a t ma ny pla ces in the forest. This works well with Dijkstra s, a s we just check if the current node is a roa d, a nd if so a solution ha s been found.
The pa thfinding ca n be extended with multiple la yers, where it, for exa mple, ca n simulta neously sea rch for the driest pa th, a nd the lea st steep pa th. Then the cost of moving to a node would be the sum of the mea sured va lu e s for wetness a nd inclina tion. This ca n be extended to a ny number of la yers, if the da ta exists.
One importa nt thing to note when using multiple la yers is tha t different la yers use different nota tions a nd types of va lues. For exa mple, there is one la yer conta ining mea surements for ground wetness a nd a nother la yer mea suring the inclina tion of the ground. These two mea surements works on two completely different sca les. This becomes a problem for the pa thfinding a lgorithm sinc e it requires these va lues to be summed ma king the pa thfinding very bia sed. Therefore, the da ta must be norma lized so tha t a ll la yers a re on a n equa l sca le. In this a pplica tion, the user will supply a norma liza tion function for ea ch la yer, which a lso gives them control over which la yer should ma tter the most. For exa mple, when wa lking, the inclina tion is not a s importa nt a s ground wetness is. This would be specified by ma king sure tha t the norma lized wetness a ttribute gets a higher va lue tha n the inclina tion va lues. It is still importa nt to include the inclina tion a ttribute in the pa thfinding since over a certa in degree the inclina tion becomes a n obsta cle, in this ca se, this should be specified a s a da ta la yer threshold in the a pplica tion. BACKGROUND
The terra in da ta set tha t the a pplica tion will rely on is provided by Fora n. The da ta set conta ins mea surements for ea ch one-by-one-meter squa res over a la rge a rea in the northern pa rt of Sweden. The API is queried with a bounding box a nd a width a nd height a nd will respond with da ta for the bounding box divided into the inputted width a nd height. A query for a bounding box tha t is 10 by 12 units a nd a width of 5 a nd a height of 4 would result in da ta for the bounding box divided into recta ngles of 2 by 3 units.
A roa d is defined by a n a rra y of coordina tes, which defines the position a nd the curves of the roa d. The roa d da ta tha t the a pplica tion will be using is the one supplied by La ntmä teriet3, provided to the a pplica tion from a
PostgreSQL4 da ta base hosted on a loca l server.
The roa d da ta is a ssumed to be correct for this project, but a ccording to La ntmä teriet ha s a n a vera ge error of 20 meters, with recorded errors of up to 150 meters5.
The user will be a ble to customize most of how the a pplica tion fetches a nd rea ds da ta . There is the pixel size,
padding va lues, a nd ea ch data layer tha t the user ha s a ccess
to ha s its va lues which the user ca n set. These a ttributes a re mea nt to increa se the functiona lity of the a pplica tion a nd ma ke it highly flexible.
Pixel Size
The a pplica tion represents the da ta it receives a s a squa re grid, a s seen in Figure 1. The pixel size va lue will tell the a pplica tion the side length, in meters, of the squa res in the grid. This is a releva nt a ttribute for the a pplica tion in two wa ys.
Firstly, you ca n decrea se memory usa ge by increa sing pixel size, since ha ving la rger squa res for the sa me a rea mea ns tha t the a pplica tion requires fewer squa res to store the sea rch a rea . A la rger pixel size will mea n tha t squa res a re less a ccura te a s they a re a n a vera ge of the 1 by 1 squa res tha t they a re representing.
Secondly, it gives the user more customiza bility while using the a pplica tion. This is importa nt since ha ving a sta tic pixel size would not a pply to a ll use ca ses. Some users might be pla nning a na rrow pa th to wa lk, while others might wa nt to pla n a pa th tha t ca n be used by felling ma chines tha t require quite wider pa ths.
Padding
When the user enters their goa l position in the forest, the a pplica tion must find a ll nea rby roa ds. The a pplica tion use s the pa dding va lue to query a roa d server for a ll roa ds with in the pa dding dista nce of the user inputted goa l position . Data layer
A da ta la yer is some specific kind of da ta tha t the a pplica tion ca n use. Three da ta types were a va ila ble during development, a ltitude over sea level, hydra tion in the ground a nd inclina tion.
3 La ntmä teriet, ”Vä gka rta n”:
https://www.la ntma teriet.se/sv/Ka rtor-och-geogra fisk-informa tion/geoda taprodukter/produktlista /vagkartan/
4 PostgreSQL: https://www.postgresql.org/
5 La ntmä teriet, ”Produktbeskrivning GSD-Vä gka rta n”:
https://www.la ntma teriet.se/globa la ssets/kartor-och-geogra fisk-informa tion/ka rtor/vagshmi.pdf
The a pplica tion ca n consider a ny number of, but a t lea st one, da ta la yers when running. The user will provide these da ta la yers either from a loca l or remote da ta ba se. The a pplica tion ca n ha ndle a ny type of da ta , a s it only sa ves t h e ra w da ta tha t it receives from its’ queries. The user ca n select a threshold method a nd va lue. The two sta nda rd threshold methods a re ma ximum a nd minimum, but the threshold method is not required. Any node with va lues exceeding the threshold will be set a s not a ccessible, the mea ning of this is expla ined in the result cha pter.
There is a lso a norma liza tion method for ea ch da ta la yer, which the user ca n customize, tha t is a pplied to ea ch da ta va lue for the la yer. One of the da ta la yers could represent height a bove sea level, which could conta in mea sured va lues between -1 000 a nd 10 000 meters, a nd a nother la yer conta ining mea surements of inclina tion with va lues between 0 a nd 90 degrees. Through norma liza tion functions, the user is a ble ma ke these two da ta la yers be on equa l sca les.
The user ca n a lso, using the norma liza tion, tell the a pplica tion wha t la yers should ma tter the most a nd lea st. This is a n importa nt fea ture since some la yers might be required for the use ca se, but not a ll should ha ve the sa me weight in the pa thfinding a lgorithm.
An exa mple of this is if you a re pla nning a pa th with one da ta la yer mea suring ground wetness, a nd on e mea suring inclina tion, a nd less ground wetness is more importa nt tha n less inclina tion, you could first norma lize the la yers to va lues between 0 a nd 1, then you could, in this ba sic exa mple, multiply the wetness va lues by two. This would result in the a lgorithm va luing less wetness higher tha n less inclina tion.
RELATED WORK
Previous work in this field ha s mostly focused on either pa thfinding or memory ma na gement. In this work, we will focus on a combina tion of these two fields.
Memory management in JavaScript
When it comes to memory ma na gement in Ja va Script, previous studies ha ve focused on memory lea ks. Ja va Scrip t ha s a ga rba ge collector, tha t works by freeing up memory tha t is not used [17]. Despite the ga rba ge collector, it is still possible to lea k memory in Ja va Script. To detect memory lea ks [9-10] suggests using Google Chrome’s a bility to ta ke a sna pshot of the a lloca ted memory. This method is not perfect, it relies on la bor-intensive investiga tion of the code. The a ctua l lea ks follow some distinct pa tterns discussed in [7-10].
The study by [11] ha s a very simila r structure of the underlying da ta compa red to this project. Where every point in their da ta ha s multiple a ttributes, but their a ttributes differ a lot from the ones used in this project.
Pathfinding
Pa thfinding is a well-resea rched a rea a nd ca n be a pplied to severa l rea l-life situa tions such a s pa th-pla nning for robotics [14], video ga mes [12-13] a nd tra ffic pa th-pla nning [15]. The most nota ble pa thfinding a lgorithm ought to be Dijkstra’s algorithm [6] which laid the groundwork for most other modern pa thfinding a nd will be used in this project. Ha rt et a l. [1] la ter relea sed their improved version of Dijkstra’s algorithm, the A* algorithm which uses a heuristic function to ga in grea ter performa nce. Since then, the A* a lgorithm ha s ha d new grea t versions developed upon itself, such a s the HPA* a nd IDA* [3-4]. It ha s been shown tha t A* uses less memory tha n tha t of Dijkstra ’s [16]. A*’s heuristic function does ca lcula tions on the current node a nd the end node to get a va lue, but our a pplica tion ha s multiple end nodes, a ll in different directions a s roa ds surround the forest, which mea ns the heuristic fuction would not work in the a pplica tion . This is why this a pplica tion will be using Dijkstra ’s.
METHOD THEORY
There a re severa l pa rts included in finding a solution to our problem which will be discussed here. The user inputs a position, a pla ce in the forest tha t they wa nt to a ccess. This is rega rded a s one of the points for the a lgorithm. The second point needed will be a ny point on a nea rby roa d, public or priva te does not ma tter in this ca se. We will be using La ntmä teriet for roa d network da ta .
The user will a lso ha ve to tell the a lgorithm wha t da ta a ttributes a nd ra nges a re considered obsta cles. The user will input this into a ba sic front-end website which consists of a n intera cta ble ma p where they ca n choose a goa l a nd a sideba r with support for customizing da ta a ttributes a nd ra nges. Na h [5] mentions displa ying feedba ck to the user will help them tolera te long wa iting times, i.e. when the a pplica tion is fetching da ta a nd processing. The a pplica tions will show its progress for these while running. METHOD
This section will be used to expla in our process, the implementa tion of the different pa rts of the a pplica tion , why we chose how to implement them tha t wa y a nd how we mea sure the a pplica tion's memory cost.
We will first crea te the front-end site for the a pplica tion. On this site, the user will be a ble to enter their goa l position a nd their pa ra meters. The site will tra nsla te their position into coordina tes rela ta ble to the da ta ba se, which is then used for the next steps in the process of producing results. There will be a need for a roa d-da ta server, which the a pplica tion ca n query with coordina tes a nd a pa dding va ria ble, which the server will respond to with a ll roa ds meeting the requirements. The requirements for wha t roa ds to return will be tha t a ny pa rt of the roa d is within the pa dding-dista nce from the coordina tes, but this could be done in a more thoughtful wa y, which will be discussed in a
la ter cha pter. The roa d-da ta will be the one provided by La ntmä teriet a nd hosted on a PostgreSQL server.
The a rea which the a pplica tion queries la yer da ta for is equa l to the bounding box including a ll given roa ds. The query will result in da ta for a ll the specified a ttributes. The a pplica tion then proceeds to ca lcula te wha t nodes a re ina ccessible a s they a re outside the a ccepta ble va lues a ccording to wha t the user ha s inputted. All da ta la yer va lues a re norma lized using the la yer norma liza tion function inputted by the user. Then once the releva nt nodes ha ve been a cquired a nd their va lues ca lcula ted it is time to sta rt the a lgorithm to find a pa th.
For the a pplica tions pa thfinding a lgorithm we chose to implement Dijkstra’s algorithm [6] as it is a well-regarded a lgorithm tha t will be more tha n enough for our purpose. While Dijkstra ’s a lgorithm uses more run time memory tha n A* [16], the A* heuristic function requires a n end-node for its ca lcula tion, we ha ve multiple end-nodes in different directions, which does not work for A*. Dijkstra ’s does not ca re for direction a nd it ca n run through a ll nodes until it finds a n end-node. If there a re multiple end-nodes other tha n tha t of the solution end-node they a re disca rded a s a n y pa th to those nodes would be longer tha n tha t of to the first found end-node.
It is a t this point tha t we ca n sta rt to cut down on memory usa ge in the a pplica tion. Both Node cla ss a nd the pa thfinding a lgorithm will be disected repetitively to find a ny unnecessa ry va ria bles tha t ca n be set a t a la ter point , a s Ja va Script a llows for setting object a ttributes a t a ny time ra ther tha n only a t insta ntia tion. Some va ria bles might be fully removed. By removing or setting va ria bles when needed the a pplica tion ca n sa ve on memory usa ge.
At the end of the project, we will perform a cost a na lysis of the a pplica tion’s memory usa ge to eva lua te how well it ha ndles the geologica l da ta a nd pa thfinding a lgorithm compa red to without our memory sa ving mea sures.
Cost analysis
When using the a pplica tion, two mea surements ca n be use d for evaluating its’ efficiency. These measurements are time, i.e. how long it ta kes for the a pplica tion to produce results, a nd memory usa ge, i.e. how much working memory is used to produce results. This is mea nt to be a mobile a pplica tion tha t users ca n ta ke with them into the field, with a ll the required da ta pre-loa ded onto their system. There a re no time constra ints, but instea d the focus is on keeping memory usa ge a s low a s possible a nd ena bling low-end ma chines to run the la rgest possible sea rch a rea s with sma ll pixel size a nd multiple da ta la yers.
Memory usage
The Area object, which stores a ll nodes a nd their va lues, a nd the pa thfinding a lgorithm a re the most memory requiring pa rts of the a pplica tion. As the Area object is sha red with the pa thfinding a lgorithm, the a lgorithm ha s references to the nodes which reduces its required memory. Therefore, most of the work a nd focus ha ve been put into keeping the node, a nd indirectly the a rea object, to a minima l size.
For mea suring memory a lloca tion ma de by the progra m we will be using Google Chromes integra ted hea p sna pshot a s seen in figure 3. This will a llows us to mea sure how much memory our progra m ha s a lloca ted a nd see when the memory limit is rea ched. How much memory a progra m ca n a lloca te is different for every system. The ma x size of the hea p in Google Chrome ca n be seen by typing
console.memory in the developer console. The system
used in our testing ha s a ma x hea p size of a bout 4GB. The settings combina tions of pixel sizes 2, 4 a nd 8, with one, two a nd three da ta la yers would be sta nda rd use ca se s , which a re the ones used when the a pplica tion is tested. There is a lso the pa dding va ria ble, which sets the ra dius, in meters, for where the a pplica tion will query for roa ds. The sea rch a rea will be equa l to the bounding box for a ll roa ds returned by the roa d server query.
The memory mea suring will use the following settings, a pixel size of 2, 4 or 8. The pa dding for querying nea rby roa ds will be set to 1000 a nd we only used one la yer (wetness). The sta rting point will be chosen ra ndomly. The results will be recorded to get a n a vera ge for the settings a nd to find some curve for how much memory is used depending on the settings. This curve will be used to derive the spa ce complexity of the a pplica tion.
RESULT
When a dding la yers, the only difference is one more entry in the va lues dictiona ry for every Node. The number of different la yers used ended up not impa cting the memory usa ge nota bly. Therefore, the results only include gra phs with one la yer (wetness).
Figure 3: Example snapshot after running a search in the application.
Figure 4: This graph shows memory measurements for three different pixel sizes with the same layers and corresponding trend lines. This shows that memory usage is linear and scales with the area.
The trendlines in figure 4 indica te tha t a s the a rea grows the memory needed by the a pplica tion grows linea rly. This gives the a pplica tion a spa ce complexity6 of O(n) where n is
equa l to the a rea . This is one of the most importa nt mea sures of the a pplica tion since it ensures tha t the a pplica tion ca n ha ndle a s la rge of a n a rea a s possible. Sin c e the memory spa ce complexity ha s linea r growth, memory usa ge increa ses a t the sa me ra te a s the a rea does.
The la rgest a rea the a pplica tion could ha ndle before running out of memory is 5 6250 000 squa re meters (56,25 km2).
This wa s done using only one la yer (wetness) a nd a pixel size of 4 meters times 4 meters. To put this figure into context, this is roughly the sa me size a s Sollentuna Municipa lity (57,97 km²)7. This ma ximum wa s a chieved by
using the cla ss structure visua lized in figure 5.
The Node cla ss a s seen in Figure 4 uses the minima l a mount of stora ge required for the pa thfinding to work. A Node only needs to know its da ta va lues, a s other a ttributes ca n be ca lcula ted or set a s the a pplica tion runs. The following list will expla in wha t the different a ttributes a re a nd when they a re ca lcula ted a nd used. Any Node a ttribute with a n a sterisk (*) a re a ttributes tha t no Node insta nce ha s a t insta ntia tion but might be a ppended to the object a s the a pplica tion runs.
6 Wikipedia .org, “Spa ce complexity”:
https://en.wikipedia .org/wiki/Spa ce_complexity
7 Wikipedia .org, “Lista över Sveriges kommuner”:
https://sv.wikipedia .org/wiki/Lista _%C3%B6ver_Sveriges_ kommuner/
Values
When the user ha s chosen a goa l position a nd wha t la yers to use, the a pplica tion will query the da ta API for ea ch la yers’ da ta for the sea rch a rea . When the query returns da ta , the da ta will be a dded to the corresponding Nodes va lue dictiona ry.
Figure 5: Application class diagram. Node attributes with an asterisk (*) are attributes that not all node has. The classes illustrated in the figure stand for most of the memory allocation in our tests.
0 100 200 300 400 500 600 700 0 5 000 000 10 000 000 15 000 000 20 000 000 25 000 000 M e m o ry ( M B ) Area (m2)
The va lues ca n then be used for ca lcula ting the cost of moving to a Node or to displa y a hea tma p over the ma p on the front-end website.
Cost*
The cost a ttribute is a representa tion of how much it costs to move from the current Node to a neighboring node, plus the cost of getting to the current Node, a s Dijkstra pa thfinding a lgorithm specifies [6]. When the pa thfinding a lgorithm is running, this a ttribute is required for them to know when deciding which neighboring Node is the chea pest one to move to. Therefore, the cost of a Node on ly needs to be ca lcula ted a nd stored when a neighboring Node is being eva lua ted, which decrea ses memory usa ge since not a ll Nodes will ha ve this a ttribute sa ved.
Coordinates*
The coordina tes a re the physica l world coordina tes for a Node. The coordina tes a re stored indirectly by the Area object tha t stores a ll the Nodes, a s they a re used a s the k e y s in the Area Nodes dictiona ry, which mea ns tha t ea ch Node does not need to know its coordina tes. A Node only needs to know its coordina tes for when it is eva lua ted since then it might be pa rt of the solution pa th a nd to recrea te the pa th the coordina tes a re required. Therefor only Nodes tha t ha ve been eva lua ted know their coordina tes. This is done to sa ve on memory usa ge.
Not Accessible*
When Dijkstra’s algorithm is evaluating the Nodes, it skips a dding neighboring Nodes to the open set, which is the list of Nodes tha t a re to be eva lua ted, if they a re not a ccessib le . The a pplica tion gives users the option to set thresholds for da ta la yers a nd when some da ta la yer in a Node exceeds th e threshold the not a ccessible a ttribute is set to true. The threshold eva lua tion is done a s the da ta is returned from t h e query before the pa thfinding a lgorithm sta rts. Setting this a ttribute only when the Node is not a ccessible lessens the memory usa ge for the a pplica tion.
Figure 6: Visualization of how the line between two nodes overlaps multiple nodes in a grid.
Came From*
When the pa thfinding a lgorithm eva lua tes the current Node, it will set the previous node a s the current Nodes ca me from a ttribute. This a ttribute is la ter used when recrea ting the solution pa th, a s the a lgorithm returns the fina l Node, a nd then using the ca me from a ttribute the a pplica tion ca n recursively ba cktra ck the solution pa th a nd sa ve the releva nt Nodes a nd their coordina tes.
Road*
Nodes tha t conta in a ny pa rt of a roa d get this a ttribute set. This a ttribute ma kes the a lgorithm consider a Node with it set a s a goa l position, a nd when the a lgorithm eva lua tes a Node tha t ha s this a ttribute set, it knows tha t it ha s found a solution a nd returns the Node a s its result.
There is a bit of work tha t goes into ca lcula ting which Nodes a re to be set a s roa d nodes. Any roa d close to the sta rting point is served to the a pplica tion when it queries the ba ck-end roa d-da ta server. The query returns roa d da ta in the form of a n a rra y of coordina tes tha t define the position a nd figure of the roa ds a s seen in figure 6.
In figure 6, the two points in the grid a re coordina tes for a pa rt of a roa d, a nd the red line is where the roa d is implied to be. Only Nodes tha t directly conta ins the coordina tes returned in the query ca n insta ntly be set a s roa d Nodes, bu t there a re ma ny Nodes between the roa d coordina tes tha t a lso implicitly conta ins roa ds, i.e. the gra y Nodes.
Since the line between coordina tes in a roa d is a stra ight line the solution to finding the Nodes in between the coordina tes, wa s to consider the line between coordina tes a s a linea r equa tion8, with a stepping size equa l to the pixel
size. This resulted in the red line seen in figure 6. All nodes intersecting with the red line ha d their Roa d a ttribute set to true.
Memory saving measures in JavaScript
Since a ll Nodes do not ha ve to sa ve a ll a ttributes, the a pplica tion ca n sa ve memory. This is beca use of how Objects a nd their properties work in Ja va Script. A grea t exa mple of where this is used in the a pplica tion is when it comes to roa d Nodes. When the a lgorithm checks if a Node ha s its roa d a ttribute set it looks like the following:
if(Node.Road) {
* Exit algorithm and return end-Node * }
As mentioned ea rlier, Nodes tha t conta in pa rts of a roa d gets the roa d a ttribute set. If the Node tha t the a lgorithm eva lua tes is a roa d Node, the a lgorithm ha s found a solutio n a nd exits a nd returns the Node. If the Node does not ha ve
8 Wikipedia .org, “Linea r Equa tion”:
With improvements (MB) Without improvements (MB) Area (m2) Improvement 48,2 59,4 25621120 18,9% 44,1 53,2 22916480 17,1% 54,1 65,7 27536320 17,7% 83,1 103 41420160 19,3% 61,5 73,4 28920064 16,2% 86,8 106 45103360 18,1%
Table 1: This table shows the improvements when only saving necessary attributes in the Node class, this yielded an average improvement of 17,9%.
the roa d a ttribute set, the if-sta tement, by Ja va Script sta nda rds, will eva lua te to fa lse.
Wha t this mea ns is tha t not setting a n a ttribute for a n Object, a nd eva lua ting the a ttribute will return undefined, which is eva lua ted a s fa lse. Then, since not setting a n a ttribute is equa l to setting it to fa lse, a ll a ttributes tha t a re fa lse on most Nodes, such a s the roa d a nd not a ccessible a ttributes, does not need to be set unless they a re true, a nd thus the a pplica tion ca n sa ve on run-time memory.
Since Ja va Script a llows for setting object a ttributes a t a ny time, a nd not only a t insta ntia tion, a ttributes such a s cost a nd ca me from ca n be set when they a re needed a nd furth e r sa ve memory a s only a few a mount of Nodes will ha ve those a ttributes set.
Ta ble 1 shows a n a vera ge of 17,9% improvement in the different test ca ses. With one ca se yielding a s much a s a n 19,3% improvement when a voiding setting a ll the a ttributes when insta ntia ting a new Node.
DISCUSSION
We a re very sa tisfied with the result, the a pplica tion ca n ha ndle la rge sea rch a rea s with quite ea se. The a pplica tion runs quite fa st while still ma king the a pplica tion a s memory effective a s possible. We ha ve noted tha t we could further remove some a ttributes a nd unneeded memory a lloca tions if required, but tha t ha s been left in for the sa ke of functiona lity or time constra ints on our pa rt.
We rea lized tha t Ja va Script wa s a grea t la ngua ge for this project, seeing a s we ta lked a bout in the result cha pter, tha t object a ttributes ca n both be set a t a ny time, not only a t insta ntia tion, a nd tha t a ttributes tha t ha ve not been set, when checked, will eva lua te to fa lse. This ma de it so tha t most Nodes only conta ins the va lues a ttribute while other a ttributes will be set a s the a pplica tion a nd a lgorithm a re running.
There is a limit for how la rge a sea rch a rea ca n be ha ndled by a browser, depending on the a va ila ble RAM of the computer it is running on. This limit is set by how much
memory is required by the a pplica tion for storing the Node da ta a nd running the sea rch.
The tests showed tha t the a pplica tion ha s a spa ce complexity of O(n), which mea ns tha t memory usa ge increa ses a t the sa me ra te a s the sea rch a rea does. This is a good result for the a pplica tion since a ny kind of exponential spa ce complexity, O(n2) etc., would mea n tha t the required
memory for the Nodes a nd the sea rch would increa se fa ster tha n the size of the sea rch a rea . This would in turn decrea se the la rgest potentia l sea rch a rea for a ll users.
A grea t exa mple of where we could sa ve some memory is rega rding the a ttributes Va lues a nd Cost. When we receive the la yer da ta , we store it in the Va lues dictiona ry for ea ch Node, a nd when the pa thfinding a lgorithm runs, it ca lcula tes the Cost for ea ch Node using its Va lues dictiona ry. Storing it in Va lues is not required, a s we could ca lcula te the cost for ea ch Node a s we receive the da ta a nd a dd it to the Nodes’ Cost a ttribute. Doing this we would not need the Va lues a ttribute a nd would sa ve memory. But the consequence of this would be tha t the hea tma p functionality would be lost, a s the hea tma p displa ys a single da ta la yer over the front-end ma p, a nd if no la yer da ta is sa ved the hea tma p has nothing to displa y.
During testing of the a pplica tion, some rea l-world terra in seemed to give non-a ccura te da ta . An exa mple of this would be la kes or other bodies of wa ter for the ground hydra tion da ta la yer. As expected ground hydra tion surrounding bodies of wa ter is higher tha n a vera ge, but mea surements from inside the wa ter gives very va ried results, sometimes in the nega tive. This is specula ted to origina te from the optic a nd la ser mea suring tools used to ga ther the da ta giving ina ccura te mea surements when used on the reflective surfa ce of the wa ter.
We figured tha t if the a pplica tion fa ils to find a solution to the pa thfinding problem , increa sing the sea rch a rea would in some ca ses ena ble the pa thfinding a lgorithm to find a solution. The user ca n increa se the sea rch a rea ma nua lly, but this could be done a utoma tica lly by the a pplica tion. This improvement wa s not implemented due to time constra ints.
How the a pplica tion chooses releva nt roa ds could be done in a more thought-through wa y. Currently the a pplica tion considers a ll nea rby roa ds a s endpoints, which in some ca ses it should not. An exa mple of this occurring ca n be seen in figure 7, where the red circle is the users inputted goa l position a nd the a pplica tion ha s retrieved a ll nea rby roa ds, seen a s blue a nd red lines. The red roa d should not be used by the a pplica tion, which it currently is, a s there a re no possible wa ys, a ccording to the figure, tha t a pa th ca n be found between the red circle a nd the red roa d without crossing a blue roa d. This mea ns tha t such roa ds a s the red roa d ta kes unnecessa ry memory, a nd removing such roa ds could improve the mem ory usa ge of the a pplica tion. A possible solution to remove unnecessa ry roa ds could be a
combina tion of the current dista nce-ba sed a pproach a nd ray
casting9, a nd only sa ving the closest roa d for ea ch ra y. Due
to a la ck of time, this a pproa ch ha s yet to be implemented a nd tested.
To further improve the memory usa ge of the a pplica tion, we could increa se the number of API-ca lls, a nd query for sma ller sections of the sea rch a rea . So instea d of ma king one la rge query for the whole a rea the a pplica tion could ma ke ma ny sma ller requests. This would ensure tha t only the nodes visited by the pa thfinding a lgorithm would be queried. One downside of this a pproa ch is tha t the time ta ken to complete a sea rch would increa se substa ntia lly, a s fetching the da ta from the API is wha t ta kes the longest time when running the a pplica tion. If users do not require speedy results, this cha nge could dra stica lly reduce the memory required for the a pplica tion to find a solution. It would be logica l to a dd this a s a sta nda rd option to the a pplica tion for extra memory sensitive ta sks.
An exa mple of when this cha nge would be effective ca n be seen in figure 7, a s a solution pa th would likely be found between the red circle a nd the nea rby blue roa d. Currently, the a pplica tion would query the whole a rea seen in the figure, requiring much more memory tha n if it would just loa d the few Nodes between the red circle a nd the roa d. This cha nge could potentia lly sa ve more memory tha n a ny other suggested cha nge. The a lgorithm would then keep running until either it finds a solution or ha s a ll Nodes a nd not found a solution, a t which point there is no solution to the current input. The worst-ca se scena rio for this cha nge is tha t it loa ds a s much da ta , i.e. the whole sea rch a rea , a s the current solution does, but best-ca se only a few number of Nodes would be queried a nd stored, dra stica lly reducing required memory.
The client, Fora n, ha s mentioned tha t a use ca se could be tha t a user ha s the da ta on a loca l server on their computer a long with them a s they a re using the a pplica tion in the forest. This would mea n tha t a ccessing the da ta from the server would ta ke less time a nd it would be fea sible to ma ke more but sma ller da ta queries. This could be controlled by a va ria ble in the user's front-end controls, a nd could go a s low a s only requesting da ta for the pixels tha t the pa thfinding a lgorithm is currently looking a t.
Fora n a lso requested tha t in future versions of the a pplica tion users could uploa d files conta ining coordina tes for forbidden a rea s, be it na ture reserva tions or priva tely -owned la nd etc. This would be ea sily a chieved with the cla ss structure, a s a ll Nodes in the forbidden a rea would ha ve their not accessible a ttribute set, telling the pa thfinding a lgorithm to ignore those Nodes.
9 Wikipedia , “Ra y ca sting”:
https://en.wikipedia .org/wiki/Ra y_ca sting
Figure 7: The red road is an example of an unnecessary road that should not be included in this use case.
CONCLUSION
The initia l question Fora n a sked us wa s to eva lua te if it wa s possible to crea te this kind of a pplica tion in the client-side of a browser, where the doubt of the ta sk la id in if a browser ha s enough memory to ha ndle the a mount of geologica l da ta tha t is required for the a pplica tion to work. While the required memory for the da ta va ries between use ca ses a nd the a va ila ble browser memory va ries between users, we ha ve run tests tha t requires more memory tha n expected use ca ses a nd found tha t it could be ha ndled on our testing computer.
Fora n ha s told us tha t they a re sa tisfied with the a rea tha t the a pplica tion ca n ha ndle, a s the results we ha ve presen t e d to them a nd the a rea a chieved by the a pplica tion is fa r more tha n the expected use ca ses.
Wha t ended up impa cting the memory usa ge the most were the Node objects a nd the pixel size, a nd not so much the numbers of a ttributes for every given Node. This is beca use when reducing the pixel size, the number of pixels grows exponentia lly. In the end, the pa thfinding a lgorithm did not use enough memory for it to be considered a problem . The a lgorithm sa ved a reference to the Area object which ha d a ccess to a ll Nodes, a nd the memory usa ge for other run-time va ria bles were negligible.
As pixel size is a consta nt va lue set by the user, there is not much to cha nge a bout how the a pplica tion ha ndles tha t va lue. Instea d, most of the focus wa s put on reducing the size of the individua l Node objects.
When pla nning roa ds, the goa l is a lwa ys to da ma ge the surrounding forest a s little a s possible. With this a pplica tion, we hope tha t pla nning ca n be done in a better a nd more efficient wa y, sa ving users time a nd spa ring the forest from unnecessa ry da mage.
Future work
In the discussion cha pter severa l cha nges ha ve been suggested tha t could potentia lly improve upon the memory usa ge of the a pplica tion. Some cha nges potentia lly could dra stica lly increa se the run time but should not be considered a s a downside a s this project a nd a pplica tion is not focused on time performa nce but instea d on memory. We believe tha t it would be interesting for someone to resea rch a nd test these cha nges to see to wha t extent they would improve the a pplica tion a nd other uses.
One of the suggested cha nges includes improving upon the wa y the a pplica tion chooses wha t roa ds to include in the sea rch, a s the tota l sea rch a rea is dependent on wha t roa ds a re being used a nd removing unnecessa ry roa ds will reduce memory usa ge. We specula ted tha t there could be a whole report written a bout finding the closest releva nt roa ds to a point a nd could ha ve its a pplica tion in other subjects simila r to pa thfinding a nd geologica l da ta a pplica tions.
Another cha nge tha t we suggest is to only query la yer da ta for extra releva nt Nodes. Currently, the la yer da ta being queried is tha t of the entire sea rch a rea , i.e. the bounding box for a ll returned roa ds. As no focus is put on speed, the a pplica tion could ma ke severa l sma ller queries for la yer da ta for only the currently required Nodes. Sta nda rd use ca se queries rea ch pixel a mounts in the thousa nds, in a best-ca se scena rio for this cha nge, only the da ta required for the solution pa th would ha ve to be queried.
ACKNOWLEDGMENTS
Tha nks to everyone a t Fora n a nd especia lly Ma rtin Sa muelsson for ena bling this work a nd for guiding us a long the wa y. Also, a big tha nks to Erik Berglund a nd Anders Fröberg for supervising this work a nd providing feedba ck. REFERENCES
[1] P. Hart, N. Nilsson, and B. Raphael, “A Formal Basis for the Heuristic Determina tion of Minimum Cost Paths,” IEEE Transactions on Systems Science and Cybernetics, vol. 4, no. 2, pp. 100–107, 1968.
[2] C. Yin a nd H. Wa ng, “Developed Dijkstra shortest path search algorithm and simulation,” 2010 International Conference On Computer Design a nd Applica tions, 2010.
[3] A. Botea , M. Müller, a nd J. Scha effer, “Nea r optima l hiera rchica l pa th-finding,” Journa l of ga me
development, vol. 1, no. 1, pp. 7–28, 2004. [4] R. E. Korf, “Depth-first iterative-deepening: An
optima l a dmissible tree sea rch,” Artificia l intelligence, vol. 27, no. 1, pp. 97–109, 1985.
[5] F. F.-H. Na h, “A study on tolera ble wa iting time: how long are web users willing to wait?,” Behaviour & Informa tion Technology, vol. 23, no. 3, pp. 153 –163, 2004.
[6] E. W. Dijkstra a nd others, “A note on two problems in connexion with graphs,” Numerische mathematik, vol. 1, no. 1, pp. 269–271, 1959.
[7] G. Wa gner, A. Ga l, C. Wimmer, B. Eich, a nd M. Franz, “Compartmental memory management in a modern web browser,” ACM SIGPLAN Notices, vol. 46, no. 11, pp. 119–128, 2011.
[8] A. Bhattacharya and K. S. Sundar, “Memory leak pa tterns in Ja va Script,” IBM webpa ge. h ttp://www128. ibm. com/developerworks/web/libra ry/wa -memlea k/(a ccessed 24 April 2007), 2007.
[9] J. A. Pienaar and R. Hundt, “JSWhiz: Static analysis for JavaScript memory leaks,” in Proceedings of the 2013 IEEE/ACM Interna tiona l Symposium on Code Genera tion a nd Optimiza tion (CGO), 2013, pp. 1 –11. [10] S. H. Jensen, M. Sridha ra n, K. Sen, a nd S. Cha ndra ,
“MemInsight: platform-independent memory
debugging for JavaScript,” in Proceedings of the 2015 10th Joint Meeting on Founda tions of Softwa re Engineering, 2015, pp. 345–356.
[11] G. P. Siknun and I. S. Sitanggang, “Web-based cla ssifica tion a pplica tion for forest fire da ta using the shiny fra mework a nd the C5. 0 a lgorithm,” Procedia Environmenta l Sciences, vol. 33, pp. 332–339, 2016. [12] X. Cui and H. Shi, “A*-based pathfinding in modern
computer games,” International Journal of Computer Science a nd Network Security, vol. 11, no. 1, pp. 125 – 130, 2011.
[13] A. Botea , B. Bouzy, M. Buro, C. Ba uckhage, a nd D. Nau, “Pathfinding in games,” 2013.
[14] J. R. Del Millá n a nd C. Torra s, “A reinforcement connectionist a pproa ch to robot pa th finding in non -ma ze-like environments,” in Reinforcement Lea rning, Springer, 1992, pp. 139–171.
[15] Q. Li, Z. Zeng, T. Zhang, J. Li, and Z. Wu, “Path-finding through flexible hiera rchica l roa d networks: An experiential approach using taxi trajectory data,” Interna tional Journa l of Applied Ea rth Observa tion a nd Geoinforma tion, vol. 13, no. 1, pp. 110–119, 2011. [16] S. H. Perma na , K. Y. Bintoro, B. Arifita ma , a nd A.
Syahputra, “Comparative analysis of pathfinding algorithms a*, dijkstra, and bfs on maze runner game,” IJISTECH (Interna tiona l J. Inf. Syst. Technol., vol. 1, no. 2, p. 1, 2018.¨
[17] Mozilla . 2020. Memory Ma na gement. (2020).
https://developer.mozilla
