diff --git a/benchmarking/results/ipad_ffox_simplify_vs_false.json b/benchmarking/results/ipad_ffox_simplify_vs_false.json
index 560f01b..1e592e3 100644
--- a/benchmarking/results/ipad_ffox_simplify_vs_false.json
+++ b/benchmarking/results/ipad_ffox_simplify_vs_false.json
@@ -1 +1 @@
-{"type":"line","data":{"datasets":[{"id":"simplifyWASM","label":"Simplify.wasm","yAxisID":"performance","fill":false,"backgroundColor":"red","borderColor":"red","stack":"a","data":[6.54558982683983,4.231210742906646,3.447492163009407,3.081520467836255,2.919761273209547,2.7930010210711966,2.699529380717804,2.6305697278911553,2.587768271252844,2.571609419461808,2.5362573099415195,2.5194134897360714,2.4666666666666677,2.5141705069124423,2.50115207373272,2.4875683833239033,2.4855990783410156,2.466990613352069,2.4528813691626192,2.4678543499511245,2.4261052707373265,2.4481191722378606,2.398026315789473,2.385116015846067,2.380747736276175,2.383684210526315,2.5130005561735262,2.37035000543065,2.362161602584988,2.7755718219624588,2.419682940516275,2.357489669421487,2.3441034771679914,2.329999301773494,2.3262987012987,2.338203463203462,2.3602100550964176,2.344817493112946,2.3528138528138522,2.364080689593885]},{"id":"simplifyJS","label":"Simplify.js","yAxisID":"performance","fill":false,"backgroundColor":"blue","borderColor":"blue","stack":"a","data":[14.1320754716981,7.839880952380949,5.688873626373624,4.672268907563025,4.007259528130674,3.593231011412829,3.344012204424104,3.0469827586206883,2.960686128276153,2.828913900913899,2.6878078817733977,2.560714285714285,2.4758064516129035,2.4589700056593107,2.399122807017544,2.373853490259739,2.2709745188397954,2.2204081632653048,2.1509379509379496,2.23073476702509,2.086162054912055,2.0898757045815852,2.1068036564560906,1.9514288420105594,1.928786651944546,1.9576456876456865,2.1778052943466473,1.9264044744946736,4.451145936798735,2.033332215035293,1.8098831985624437,1.8324962615376665,1.7418650793650803,1.7538845083487955,1.7326601387188911,1.7289682539682543,1.7358209826117408,1.705555555555555,1.6843039086517348,1.6770186335403732]},{"id":"simplifyJSAlt","label":"Simplify.js Alternative","yAxisID":"performance","fill":false,"backgroundColor":"green","borderColor":"green","stack":"a","data":[18.341818181818187,9.482758620689664,7.132034632034633,5.778321678321679,5.056725146198834,4.6271008403361344,4.195215311004786,3.8973214285714275,3.7593537414966023,3.608185753640297,3.46139766933456,3.2822222222222246,3.3155797101449274,3.180555555555558,3.0842105263157893,3.075714285714283,2.9898076923076924,2.93949900553674,2.8348827910231433,2.7942413076341617,2.734962406015038,2.6861173309449167,2.6300731452455595,2.589285714285713,2.5743021346469606,2.7676003734827264,2.661944263717196,2.5424133811230587,4.196695123672814,2.568358798385349,2.3981832210998864,2.401480078563411,2.3779436594685834,2.3443418560606046,2.328947368421052,2.3083778966131914,2.312068048910154,2.3066075190406745,2.2862394957983194,2.281376518218622]},{"id":"numberOfNodes","type":"line","label":"# of positions","yAxisID":"nodes","fill":false,"backgroundColor":"grey","borderColor":"grey","stack":"a","data":[1875,1013,728,564,446,381,327,283,262,241,224,208,188,175,155,154,150,141,132,129,127,114,104,103,100,97,96,96,91,89,90,86,84,79,71,72,71,69,66,64]},{"label":"Dataset: Simplify.js example (73.752 points)","data":[]},{"label":"High quality mode: false","data":[]},{"label":"Platform: Firefox for iOS 18.2β15817 (like Safari 8+) on Apple iPad (iOS 12.4)","data":[]}],"labels":[0.05,0.1,0.15,0.2,0.25,0.3,0.35,0.4,0.45,0.5,0.55,0.6,0.65,0.7,0.75,0.8,0.85,0.9,0.95,1,1.05,1.1,1.15,1.2,1.25,1.3,1.35,1.4,1.45,1.5,1.55,1.6,1.65,1.7,1.75,1.8,1.85,1.9,1.95,2]},"options":{"defaultColor":"rgba(0,0,0,0.1)","defaultFontColor":"#666","defaultFontFamily":"'Helvetica Neue', 'Helvetica', 'Arial', sans-serif","defaultFontSize":12,"defaultFontStyle":"normal","defaultLineHeight":1.2,"showLines":true,"animation":{"duration":0,"easing":"easeOutQuart"},"elements":{"arc":{"backgroundColor":"rgba(0,0,0,0.1)","borderColor":"#fff","borderWidth":2,"borderAlign":"center"},"line":{"tension":0.4,"backgroundColor":"rgba(0,0,0,0.1)","borderWidth":3,"borderColor":"rgba(0,0,0,0.1)","borderCapStyle":"butt","borderDash":[],"borderDashOffset":0,"borderJoinStyle":"miter","capBezierPoints":true,"fill":true},"point":{"radius":3,"pointStyle":"circle","backgroundColor":"rgba(0,0,0,0.1)","borderColor":"rgba(0,0,0,0.1)","borderWidth":1,"hitRadius":1,"hoverRadius":4,"hoverBorderWidth":1},"rectangle":{"backgroundColor":"rgba(0,0,0,0.1)","borderColor":"rgba(0,0,0,0.1)","borderSkipped":"bottom","borderWidth":0}},"layout":{"padding":{"top":0,"right":0,"bottom":0,"left":0}},"plugins":{"filler":{"propagate":true}},"tooltips":{"enabled":true,"custom":null,"mode":"index","position":"average","intersect":false,"backgroundColor":"rgba(0,0,0,0.8)","titleFontStyle":"bold","titleSpacing":2,"titleMarginBottom":6,"titleFontColor":"#fff","titleAlign":"left","bodySpacing":2,"bodyFontColor":"#fff","bodyAlign":"left","footerFontStyle":"bold","footerSpacing":2,"footerMarginTop":6,"footerFontColor":"#fff","footerAlign":"left","yPadding":6,"xPadding":6,"caretPadding":2,"caretSize":5,"cornerRadius":6,"multiKeyBackground":"#fff","displayColors":true,"borderColor":"rgba(0,0,0,0)","borderWidth":0,"callbacks":{}},"events":["mousemove","mouseout","click","touchstart","touchmove"],"hover":{"onHover":null,"mode":"nearest","intersect":false,"animationDuration":400},"onClick":null,"maintainAspectRatio":true,"responsive":true,"responsiveAnimationDuration":0,"legend":{"display":true,"position":"bottom","fullWidth":true,"reverse":false,"weight":1000,"onHover":null,"onLeave":null,"labels":{"boxWidth":40,"padding":10}},"title":{"display":true,"fontStyle":"bold","fullWidth":true,"padding":10,"position":"top","text":"Simplify.wasm vs. Simplify.js","weight":2000},"spanGaps":false,"scales":{"xAxes":[{"display":true,"position":"bottom","offset":false,"gridLines":{"display":true,"color":"rgba(0, 0, 0, 0.1)","lineWidth":1,"drawBorder":true,"drawOnChartArea":true,"drawTicks":true,"tickMarkLength":10,"zeroLineWidth":1,"zeroLineColor":"rgba(0,0,0,0.25)","zeroLineBorderDash":[],"zeroLineBorderDashOffset":0,"offsetGridLines":false,"borderDash":[],"borderDashOffset":0},"scaleLabel":{"display":true,"labelString":"Tolerance (length)","padding":{"top":4,"bottom":4},"fontStyle":"bold"},"ticks":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"minor":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0},"major":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0}},"type":"category","id":"x-axis-0","stacked":false}],"yAxes":[{"display":true,"position":"left","offset":false,"gridLines":{"display":true,"color":"rgba(0, 0, 0, 0.1)","lineWidth":1,"drawBorder":true,"drawOnChartArea":true,"drawTicks":true,"tickMarkLength":10,"zeroLineWidth":1,"zeroLineColor":"rgba(0,0,0,0.25)","zeroLineBorderDash":[],"zeroLineBorderDashOffset":0,"offsetGridLines":false,"borderDash":[],"borderDashOffset":0},"scaleLabel":{"display":true,"labelString":"Performance - Milliseconds per operation (ms)","padding":{"top":4,"bottom":4},"fontStyle":"bold"},"ticks":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"minor":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"min":0},"major":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"min":0},"min":0},"type":"linear","id":"performance","stacked":false},{"display":true,"position":"right","offset":false,"gridLines":{"display":true,"color":"rgba(0, 0, 0, 0.1)","lineWidth":1,"drawBorder":true,"drawOnChartArea":false,"drawTicks":true,"tickMarkLength":10,"zeroLineWidth":1,"zeroLineColor":"rgba(0,0,0,0.25)","zeroLineBorderDash":[],"zeroLineBorderDashOffset":0,"offsetGridLines":false,"borderDash":[],"borderDashOffset":0},"scaleLabel":{"display":true,"labelString":"Number of positions in result (#)","padding":{"top":4,"bottom":4},"fontStyle":"bold"},"ticks":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"minor":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"min":0},"major":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"min":0},"min":0},"id":"nodes","type":"linear"}]}}}
+{"type":"line","data":{"datasets":[{"id":"simplifyWASM","label":"Simplify.wasm","yAxisID":"performance","fill":false,"backgroundColor":"red","borderColor":"red","stack":"a","data":[6.54558982683983,4.231210742906646,3.447492163009407,3.081520467836255,2.919761273209547,2.7930010210711966,2.699529380717804,2.6305697278911553,2.587768271252844,2.571609419461808,2.5362573099415195,2.5194134897360714,2.4666666666666677,2.5141705069124423,2.50115207373272,2.4875683833239033,2.4855990783410156,2.466990613352069,2.4528813691626192,2.4678543499511245,2.4261052707373265,2.4481191722378606,2.398026315789473,2.385116015846067,2.380747736276175,2.383684210526315,2.5130005561735262,2.37035000543065,2.362161602584988,2.7755718219624588,2.419682940516275,2.357489669421487,2.3441034771679914,2.329999301773494,2.3262987012987,2.338203463203462,2.3602100550964176,2.344817493112946,2.3528138528138522,2.364080689593885]},{"id":"simplifyJS","label":"Simplify.js","yAxisID":"performance","fill":false,"backgroundColor":"blue","borderColor":"blue","stack":"a","data":[14.1320754716981,7.839880952380949,5.688873626373624,4.672268907563025,4.007259528130674,3.593231011412829,3.344012204424104,3.0469827586206883,2.960686128276153,2.828913900913899,2.6878078817733977,2.560714285714285,2.4758064516129035,2.4589700056593107,2.399122807017544,2.373853490259739,2.2709745188397954,2.2204081632653048,2.1509379509379496,2.23073476702509,2.086162054912055,2.0898757045815852,2.1068036564560906,1.9514288420105594,1.928786651944546,1.9576456876456865,2.1778052943466473,1.9264044744946736,1.93949900553674,2.033332215035293,1.8098831985624437,1.8324962615376665,1.7418650793650803,1.7538845083487955,1.7326601387188911,1.7289682539682543,1.7358209826117408,1.705555555555555,1.6843039086517348,1.6770186335403732]},{"id":"simplifyJSAlt","label":"Simplify.js Alternative","yAxisID":"performance","fill":false,"backgroundColor":"green","borderColor":"green","stack":"a","data":[18.341818181818187,9.482758620689664,7.132034632034633,5.778321678321679,5.056725146198834,4.6271008403361344,4.195215311004786,3.8973214285714275,3.7593537414966023,3.608185753640297,3.46139766933456,3.2822222222222246,3.3155797101449274,3.180555555555558,3.0842105263157893,3.075714285714283,2.9898076923076924,2.93949900553674,2.8348827910231433,2.7942413076341617,2.734962406015038,2.6861173309449167,2.6300731452455595,2.589285714285713,2.5743021346469606,2.7676003734827264,2.661944263717196,2.5424133811230587,2.5362573099415195,2.568358798385349,2.3981832210998864,2.401480078563411,2.3779436594685834,2.3443418560606046,2.328947368421052,2.3083778966131914,2.312068048910154,2.3066075190406745,2.2862394957983194,2.281376518218622]},{"id":"numberOfNodes","type":"line","label":"# of positions","yAxisID":"nodes","fill":false,"backgroundColor":"grey","borderColor":"grey","stack":"a","data":[1875,1013,728,564,446,381,327,283,262,241,224,208,188,175,155,154,150,141,132,129,127,114,104,103,100,97,96,96,91,89,90,86,84,79,71,72,71,69,66,64]},{"label":"Dataset: Simplify.js example (73.752 points)","data":[]},{"label":"High quality mode: false","data":[]},{"label":"Platform: Firefox for iOS 18.2β15817 (like Safari 8+) on Apple iPad (iOS 12.4)","data":[]}],"labels":[0.05,0.1,0.15,0.2,0.25,0.3,0.35,0.4,0.45,0.5,0.55,0.6,0.65,0.7,0.75,0.8,0.85,0.9,0.95,1,1.05,1.1,1.15,1.2,1.25,1.3,1.35,1.4,1.45,1.5,1.55,1.6,1.65,1.7,1.75,1.8,1.85,1.9,1.95,2]},"options":{"defaultColor":"rgba(0,0,0,0.1)","defaultFontColor":"#666","defaultFontFamily":"'Helvetica Neue', 'Helvetica', 'Arial', sans-serif","defaultFontSize":12,"defaultFontStyle":"normal","defaultLineHeight":1.2,"showLines":true,"animation":{"duration":0,"easing":"easeOutQuart"},"elements":{"arc":{"backgroundColor":"rgba(0,0,0,0.1)","borderColor":"#fff","borderWidth":2,"borderAlign":"center"},"line":{"tension":0.4,"backgroundColor":"rgba(0,0,0,0.1)","borderWidth":3,"borderColor":"rgba(0,0,0,0.1)","borderCapStyle":"butt","borderDash":[],"borderDashOffset":0,"borderJoinStyle":"miter","capBezierPoints":true,"fill":true},"point":{"radius":3,"pointStyle":"circle","backgroundColor":"rgba(0,0,0,0.1)","borderColor":"rgba(0,0,0,0.1)","borderWidth":1,"hitRadius":1,"hoverRadius":4,"hoverBorderWidth":1},"rectangle":{"backgroundColor":"rgba(0,0,0,0.1)","borderColor":"rgba(0,0,0,0.1)","borderSkipped":"bottom","borderWidth":0}},"layout":{"padding":{"top":0,"right":0,"bottom":0,"left":0}},"plugins":{"filler":{"propagate":true}},"tooltips":{"enabled":true,"custom":null,"mode":"index","position":"average","intersect":false,"backgroundColor":"rgba(0,0,0,0.8)","titleFontStyle":"bold","titleSpacing":2,"titleMarginBottom":6,"titleFontColor":"#fff","titleAlign":"left","bodySpacing":2,"bodyFontColor":"#fff","bodyAlign":"left","footerFontStyle":"bold","footerSpacing":2,"footerMarginTop":6,"footerFontColor":"#fff","footerAlign":"left","yPadding":6,"xPadding":6,"caretPadding":2,"caretSize":5,"cornerRadius":6,"multiKeyBackground":"#fff","displayColors":true,"borderColor":"rgba(0,0,0,0)","borderWidth":0,"callbacks":{}},"events":["mousemove","mouseout","click","touchstart","touchmove"],"hover":{"onHover":null,"mode":"nearest","intersect":false,"animationDuration":400},"onClick":null,"maintainAspectRatio":true,"responsive":true,"responsiveAnimationDuration":0,"legend":{"display":true,"position":"bottom","fullWidth":true,"reverse":false,"weight":1000,"onHover":null,"onLeave":null,"labels":{"boxWidth":40,"padding":10}},"title":{"display":true,"fontStyle":"bold","fullWidth":true,"padding":10,"position":"top","text":"Simplify.wasm vs. Simplify.js","weight":2000},"spanGaps":false,"scales":{"xAxes":[{"display":true,"position":"bottom","offset":false,"gridLines":{"display":true,"color":"rgba(0, 0, 0, 0.1)","lineWidth":1,"drawBorder":true,"drawOnChartArea":true,"drawTicks":true,"tickMarkLength":10,"zeroLineWidth":1,"zeroLineColor":"rgba(0,0,0,0.25)","zeroLineBorderDash":[],"zeroLineBorderDashOffset":0,"offsetGridLines":false,"borderDash":[],"borderDashOffset":0},"scaleLabel":{"display":true,"labelString":"Tolerance (length)","padding":{"top":4,"bottom":4},"fontStyle":"bold"},"ticks":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"minor":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0},"major":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0}},"type":"category","id":"x-axis-0","stacked":false}],"yAxes":[{"display":true,"position":"left","offset":false,"gridLines":{"display":true,"color":"rgba(0, 0, 0, 0.1)","lineWidth":1,"drawBorder":true,"drawOnChartArea":true,"drawTicks":true,"tickMarkLength":10,"zeroLineWidth":1,"zeroLineColor":"rgba(0,0,0,0.25)","zeroLineBorderDash":[],"zeroLineBorderDashOffset":0,"offsetGridLines":false,"borderDash":[],"borderDashOffset":0},"scaleLabel":{"display":true,"labelString":"Performance - Milliseconds per operation (ms)","padding":{"top":4,"bottom":4},"fontStyle":"bold"},"ticks":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"minor":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"min":0},"major":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"min":0},"min":0},"type":"linear","id":"performance","stacked":false},{"display":true,"position":"right","offset":false,"gridLines":{"display":true,"color":"rgba(0, 0, 0, 0.1)","lineWidth":1,"drawBorder":true,"drawOnChartArea":false,"drawTicks":true,"tickMarkLength":10,"zeroLineWidth":1,"zeroLineColor":"rgba(0,0,0,0.25)","zeroLineBorderDash":[],"zeroLineBorderDashOffset":0,"offsetGridLines":false,"borderDash":[],"borderDashOffset":0},"scaleLabel":{"display":true,"labelString":"Number of positions in result (#)","padding":{"top":4,"bottom":4},"fontStyle":"bold"},"ticks":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"minor":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"min":0},"major":{"beginAtZero":false,"minRotation":0,"maxRotation":50,"mirror":false,"padding":0,"reverse":false,"display":true,"autoSkip":true,"autoSkipPadding":0,"labelOffset":0,"min":0},"min":0},"id":"nodes","type":"linear"}]}}}
diff --git a/public/index.html b/public/index.html
index d8b5d43..cfb7b21 100644
--- a/public/index.html
+++ b/public/index.html
@@ -10,7 +10,9 @@
     <ul>
       <li><a href="./benchmarking/index.html">Benchmarking</a></li>
       <li>
-        <a href="./polygon-simplification/index.html">Polygon simplification</a>
+        <a href="./polygon-simplification/index.html"
+          >Polygon simplification (deprecated)</a
+        >
       </li>
       <li>
         <a href="./mt-polygon-simplification-2019.pdf">Download thesis</a>
diff --git a/thesis/bibliography/bibliography.bib b/thesis/bibliography/bibliography.bib
index 2d29a67..3249155 100644
--- a/thesis/bibliography/bibliography.bib
+++ b/thesis/bibliography/bibliography.bib
@@ -55,4 +55,12 @@
   date   = {2012-12-11},
   url    = {http://monsur.hossa.in/2012/12/11/benchmarkjs.html},
   urldate= {2019-08-15}
+}
+
+@online{apple2019appstore,
+  author = {{Apple Inc.}},
+  title  = {App Store Review Guidelines},
+  date   = {2019-06-03},
+  url    = {https://developer.apple.com/app-store/review/guidelines/},
+  urldate= {2019-08-15}
 }
\ No newline at end of file
diff --git a/thesis/bibliography/specifications.bib b/thesis/bibliography/specifications.bib
index e45874a..4ba2200 100644
--- a/thesis/bibliography/specifications.bib
+++ b/thesis/bibliography/specifications.bib
@@ -15,7 +15,7 @@
 
 @article{open1999opengis,
 	title={OpenGIS simple features specification for SQL},
-	author={Open GIS Consortium and others},
+	author={{Open GIS Consortium} and others},
 	journal={URL: http://www. opengeospatial. org/docs/99-054. pdf},
 	year={1999},
 	url={https://portal.opengeospatial.org/files/?artifact_id=829}
@@ -27,4 +27,4 @@
 	year={2017},
 	publisher={Online},
 	url={https://github.com/topojson/topojson-specification}
-}
\ No newline at end of file
+}
diff --git a/thesis/chapters/01-introduction.tex b/thesis/chapters/01-introduction.tex
index 06b548f..0a597ca 100644
--- a/thesis/chapters/01-introduction.tex
+++ b/thesis/chapters/01-introduction.tex
@@ -9,20 +9,20 @@
 % Why important, who participants, trends, 
 
 
-Simplification of polygonal data structures is the task of reducing data points while preserving topological characteristics. The simplification often takes the form of removing points that make up the geometry. There are several solutions that tackle the problem in different ways. With the rising trend of moving desktop applications to the web platform also geographic information systems (GIS) have experienced the shift towards web browsers \footnote{\url{https://www.esri.com/about/newsroom/arcnews/implementing-web-gis/}}. Performance is critical in these applications. Since simplification is an important factor to performance the solutions will be tested by constructing a web application using a technology called WebAssembly. 
+Simplification of polygonal data structures is the task of reducing data points while preserving topological characteristics. The simplification often takes the form of removing points that make up the geometry. There are several solutions that tackle the problem in different ways. With the rising trend of moving desktop applications to the web platform geographic information systems (GIS) have experienced the shift towards web browsers, too. \footnote{\url{https://www.esri.com/about/newsroom/arcnews/implementing-web-gis/}}\todo{find a better source}. Performance is critical in these applications. Since simplification is an important factor to performance the solutions will be tested by constructing a web application using a technology called WebAssembly. \todo{bessere formulierung}
 
 
 \subsection{Binary instruction sets on the web platform}
 
-The recent development of WebAssembly allows code written in various programming languages to be run natively in web browsers. So far JavaScript   was the only native programming language on the web. The goals of WebAssembly are to define a binary instruction format as a compilation target to execute code at native speed and taking advantage of common hardware capabilities \parencite{haas2017bringing}. The integration into the web platform brings portability to a wide range of platforms like mobile and internet of things (IoT). The usage of this technology promises performance gains that will be tested by this thesis. The results can give conclusions to whether WebAssembly is worth a consideration for web applications with geographic computational aspects. Web GIS is an example technology that would benefit greatly of such an advancement. Thus far WebAssembly has been shipped to the stable version of the four most used browser engines \parencite{wagner2017support}. The mainly targeted high-level languages for compilation are C and C++. Also a compiler for Rust and a TypeScript subset has been developed.
+The recent development of WebAssembly allows code written in various programming languages to be run natively in web browsers. So far JavaScript was the only native programming language on the web\todo{quelle finden}. The goals of WebAssembly are to define a binary instruction format as a compilation target to execute code at native speed and taking advantage of common hardware capabilities \parencite{haas2017bringing}. The integration into the web platform brings portability to a wide range of platforms like mobile and internet of things (IoT). The usage of this technology promises performance gains that will be tested by this thesis. The results can give conclusions to whether WebAssembly is worth a consideration for web applications with geographic computational aspects. Web GIS is only one technology that would benefit greatly of such an advancement. Thus far WebAssembly has been shipped to the stable version of the four most used browser engines \parencite{wagner2017support}. The mainly targeted high-level languages for compilation are C and C++. Also a compiler for Rust and a TypeScript subset has been developed.
 
 \subsection{Performance as important factor for web applications}
 
-There has been a rapid growth of complex applications running in web-browsers. These so called progressive web apps (PWA) combine the fast reachability of web pages with the feature richness of locally installed applications. Even though these applications can grow quire complex, the requirement for fast page loads and instant user interaction still remains. One way to cope this need is the use of compression algorithms to reduce the amount of data transmitted and processed. In a way simplification is a form of data compression. Web servers use lossless compression algorithms like gzip to deflate data before transmission. Browsers that implement these algorithms can then fully restore the requested ressources resulting in lower bandwidth usage. The algorithms presented here however remove information from the data in a way that cannot be restored. This is called lossy compression. The most common usage for this on the web is the compression of image data. 
+There has been a rapid growth of complex applications running in web-browsers. These so called progressive web apps (PWA) combine the fast reachability of web pages with the feature richness of locally installed applications. Even though these applications can grow quite complex, the requirement for fast page loads and instant user interaction still remains. One way to cope with this need is the use of compression algorithms to reduce the amount of data transmitted and processed. In a way simplification is a form of data compression. Web servers use lossless compression algorithms like gzip to deflate data before transmission. Browsers that implement these algorithms can then fully restore the requested ressources resulting in lower bandwidth usage. The algorithms presented here however remove information from the data in a way that cannot be restored. This is called lossy compression. The most common usage for this on the web is the compression of image data. 
 
 \subsection{Topology simplification for rendering performance}
 
-While compression is often used to minimize bandwidth usage the compression of geospatial data can particulary influence rendering performance. The bottleneck for rendering often is the svg transformation used to display topology on the web. Implementing simplification algorithms for use on the web platform can lead to smoother user experience when working with large geodata sets. 
+While compression is often used to minimize bandwidth usage, the compression of geospatial data can particulary influence rendering performance. The bottleneck for rendering often is the SVG \todo{explain abbrevation} transformation used to display topology on the web. Implementing simplification algorithms for use on the web platform can lead to smoother user experience when working with large geodata sets. 
 
 \subsection{Related work}
 There have been previous attempts to speed up applications with WebAssembly. They all have seen great performance benefits when using this technology. Results show that over several source languages the performance is predictably consistent across browsers \parencite{surma2019replacing}. Reiser and Bläser even propose to cross-compile JavaScript to WebAssembly. Through their developed library Speedy.js one can compile TypeScript, a JavaScript superset, to WebAssembly. The performance gains of critical functions reaches up to a factor of four \parencite{reiser2017accelerate}.
@@ -33,7 +33,7 @@ Shi and Cheung analyzed several different polyline simplification algorithms in
 
 This thesis is structured into a theoretical and a practical component. First the theoretical principles will be reviewed. A number of algorithms will be introduced in this section. Each algorithm will be dissected by complexity and characteristics. Topology of polygonal data will be explained as how to describe geodata on the web. An introduction to WebAssembly will follow.
 
-In the next chapter the practical implementation will be presented. A web application will be developed to measure the performance of three related algorithms used for polyline simplification.
+In chapter 3 the practical implementation will be presented. A web application will be developed to measure the performance of three related algorithms used for polyline simplification.
 
 The results of the above methods will be shown in chapter 4. After discussion of the results a conclusion will finish the thesis.
 
diff --git a/thesis/chapters/02.00-theory.tex b/thesis/chapters/02.00-theory.tex
index 1bf2d91..6fb5b30 100644
--- a/thesis/chapters/02.00-theory.tex
+++ b/thesis/chapters/02.00-theory.tex
@@ -1,4 +1,4 @@
 \section{Theory}
 % Principles
 
-In this chapter the theory behind polygon simplification will be explained. The simplification process is part of generalization in cartography. It will be clarified which goals drive the reducing of data quantity, especially in the context of web applications. Then several different simplification algorithms will be introduced. The leading data formats that represent geodata on the web will be explained. From there a closer look can be taken how the algorithms run on the web platform. For that the technology WebAssembly will be presented.
+In this chapter the theory behind polygon simplification will be explained. The simplification process is part of generalization in cartography. It will be clarified which goals drive the reduction of data quantity, especially in the context of web applications. Then several different simplification algorithms will be introduced. The leading data formats that represent geodata on the web will be explained. From there a closer look can be taken how the algorithms run on the web platform. For that the technology WebAssembly will be presented.
diff --git a/thesis/chapters/02.02-Algorithms.tex b/thesis/chapters/02.02-Algorithms.tex
index 194801e..38a1932 100644
--- a/thesis/chapters/02.02-Algorithms.tex
+++ b/thesis/chapters/02.02-Algorithms.tex
@@ -37,9 +37,9 @@ In this chapter several algorithms for polyline simplification will be explained
 %\end{figure}
 
 
-\paragraph{Reumann-Witkam simplification} As the name implies this algorithm was developed by Reumann and Witkam. In 1974 they described the routine that constructs a "corridor/search area" by placing two parallel lines in the direction of its initial tangent. The distance from this segment is user specified. Then the successive points will be checked until a point outside of this area is found. Its predecessor becomes a key and the two points mark the new tangent for the search area. This procedure is repeated until the last point is reached. \parencite{reumann1974optimizing}
+\paragraph{Reumann-Witkam simplification} As the name implies this algorithm was developed by Reumann and Witkam. In 1974 they described the routine that constructs a "corridor/search area" by placing two parallel lines in the direction of its initial tangent. The width of this corridor is user specified. Then the successive points will be checked until a point outside of this area is found. Its predecessor becomes a key and the two points mark the new tangent for the search area. This procedure is repeated until the last point is reached. \parencite{reumann1974optimizing}
 
-\paragraph{Zhao-Saalfeld simplification} This routine, also called the sleeve-fitting polyline simplification, developed in 1997 is similar to the Reumann-Witkam algorithm. Its goal is to fit as many consecutive points in the search area. The corridor is however not aligned to the initial tangent but rather to the last point in the sequence. From the starting point on successors get added as long as all in-between points fit in the sleeve. If the constraint fails a new sleeve will be started from the last point in the previous section. \parencite{zhao1997linear}
+\paragraph{Zhao-Saalfeld simplification} This routine, also called the sleeve-fitting polyline simplification, developed in 1997 is similar to the Reumann-Witkam algorithm. Its goal is to fit as many consecutive points in the search area. The corridor is however not aligned to the initial tangent but rather to the last point in the sequence. From the starting point on, successors get added as long as all in-between points fit in the sleeve. If the constraint fails a new sleeve will be started from the last point in the previous section. \parencite{zhao1997linear}
 
 %\begin{figure}
 %	\centering
@@ -59,7 +59,7 @@ In this chapter several algorithms for polyline simplification will be explained
 %\end{figure}
 
 
-\paragraph{Lang simplification} Lang described this algorithm in 1969. The search area is defined by a specified number of points too look ahead of the key point. A line is constructed from the key point to the last point in the search area. If the perpendicular distance of all intermediate points to this line is below a tolerance limit, they will be removed and the last point is the new key. Otherwise the search area is shrunk by excluding this last point until the requirement is met or there are no more intermediate points. All the algorithms before operated on the line sequentially and have a linear time complexity. This one also operates sequentially, but one of the critics about the Lang algorithm is that it requires too much computer time (DP). The complexity of this algorithm is $\mathcal{O}(m^n)$ with \textsf{m} being the number of positions to look ahead. \parencite{lang1969rules}
+\paragraph{Lang simplification} Lang described this algorithm in 1969. The search area is defined by a specified number of points to look ahead of the key point. A line is constructed from the key point to the last point in the search area. If the perpendicular distance of all intermediate points to this line is below a tolerance limit, they will be removed and the last point is the new key. Otherwise the search area is shrunk by excluding this last point until the requirement is met or there are no more intermediate points. All the algorithms before operated on the line sequentially and have a linear time complexity. This one also operates sequentially, but one of the critics about the Lang algorithm is that it requires too much computer time \parencite{douglas1973algorithms}. The complexity of this algorithm is $\mathcal{O}(m^n)$ with \textsf{m} being the number of positions to look ahead. \parencite{lang1969rules}
 
 %\begin{figure}
 %	\centering
@@ -81,7 +81,7 @@ In this chapter several algorithms for polyline simplification will be explained
 
 %\paragraph{with reduction parameter} \todo{O(n*m)}
 
-\paragraph{Visvalingam-Whyatt simplification} This is another global point routine. It was developed in 1993 (VW). Visvalingam and Wyatt use a area-based method to rank the points by their significance. To do that the "effective area" of each point has to be calculated. This is the area the point spans up with its adjoining points \parencite{shi2006performance}. Then the points with the least effective area get iteratively eliminated, and its neighbors effective area recalculated, until there are only two points left. At each elimination the point gets stored in a list alongside with its associated area. This is the effective area of that point or the associated area of the previous point in case the latter one is higher. This way the algorithm can be used for scale dependent and scale-independent generalizations. \parencite{visvalingam1993line}
+\paragraph{Visvalingam-Whyatt simplification} This is another global point routine. It was developed in 1993. Visvalingam and Wyatt use a area-based method to rank the points by their significance. To do that the "effective area" of each point has to be calculated. This is the area the point spans up with its adjoining points \parencite{shi2006performance}. Then the points with the least effective area get iteratively eliminated, and its neighbors effective area recalculated, until there are only two points left. At each elimination the point gets stored in a list alongside with its associated area. This is the effective area of that point or the associated area of the previous point in case the latter one is higher. \todo{explain why the others not}This way the algorithm can be used for scale dependent and scale-independent generalizations. \parencite{visvalingam1993line}
 
 
 \subsubsection{Summary}
diff --git a/thesis/chapters/02.03-Dataformats.tex b/thesis/chapters/02.03-Dataformats.tex
index d3d0593..72c63e7 100644
--- a/thesis/chapters/02.03-Dataformats.tex
+++ b/thesis/chapters/02.03-Dataformats.tex
@@ -1,11 +1,11 @@
 
-\subsection{Geodata formats on the Web}
+\subsection{Geodata formats on the web}
 \label{ch:dataformats}
 
 Here the data formats that are used through this theses will be explained. 
 
 
-\paragraph{The JavaScript Object Notation (JSON) Data Interchange Format} was derived from the ECMAScript Programming Language Standard \parencite{bray2014javascript}. It is a text format for the serialization of structured data. As a text format it suites well for the data exchange between server and client. Also it can easily be consumed by JavaScript. These characteristics are ideal for web based applications. It does however only support a limited number of data types. Four primitive ones (string, number, boolean and null) and two structured ones (objects and array). Objects are an unordered collection of name-value pairs, while arrays are simply ordered lists of values. JSON was meant as a replacement for XML as it provides a more human readable format. Through nesting complex data structures can be created.
+\paragraph{The JavaScript Object Notation (JSON) Data Interchange Format} was derived from the ECMAScript Programming Language Standard \parencite{bray2014javascript}. It is a text format for the serialization of structured data. As a text format it is well suited for the data exchange between server and client. Also it can easily be consumed by JavaScript. These characteristics are ideal for web based applications. It does however only support a limited number of data types. Four primitive ones (string, number, boolean and null) and two structured ones (objects and array). Objects are an unordered collection of name-value pairs, while arrays are simply ordered lists of values. JSON was meant as a replacement for XML as it provides a more human readable format. Through nesting, complex data structures can be created.
 
 \paragraph{The GeoJSON Format} is a geospatial data interchange format \parencite{butler2016geojson}. As the name suggests it is based on JSON and deals with data representing geographic features. There are several geometry types defined to be compatible with the types in the OpenGIS Simple Features Implementation Specification for SQL \parencite{open1999opengis}. These are Point, MultiPoint, LineString, MultiLineString, Polygon, Multipolygon and the heterogeneous GeometryCollection. Listing \ref{lst:geojson-example} shows a simple example of a GeoJSON object with one point feature. A more complete example can be viewed in the file \path{data/example-7946.geojson}. 
 
@@ -19,22 +19,22 @@ label=lst:geojson-example
 
 The feature types differ in the format of their coordinates property. A position is an array of at least two elements representing longitude and latitude. An optional third element can be added to specify altitude. While the coordinates member of a \textsl{Point}-feature is simply a single position, a \textsl{LineString}-feature describes its geometry through an Array of at least two positions. More interesting is the specification for Polygons. It introduces the concept of the \textsl{linear ring} as a closed \textsl{LineString} with at least four positions where the first and last positions are equivalent. The \textsl{Polygon's} coordinates member is an array of linear rings with the first one representing the exterior ring and all others interior rings, also named surface and holes respectively. At last the coordinates member of \textsl{MultiLineStrings} and \textsl{MultiPolygons} is defined as a single array of its singular feature type.
 
-GeoJSON is mainly used for web-based mapping. Since it is based on JSON it  inherits its strength. There is for one the enhanced readability through reduced markup overhead compared to XML-based data types like GML. Interoperability with web applications comes for free since the parsing of JSON-objects is integrated in JavaScript. Unlike the Esri Shapefile format  a single file is sufficient to store and transmit all relevant data, including feature properties. 
+GeoJSON is mainly used for web-based mapping. Since it is based on JSON it  inherits its strengths. There is for one the enhanced readability through reduced markup overhead compared to XML-based data types like GML. Interoperability with web applications comes for free since the parsing of JSON-objects is integrated in JavaScript. Unlike the \todo{Introduce shapefiles}Esri Shapefile format a single file is sufficient to store and transmit all relevant data, including feature properties. 
 
-To its downsides count that a text based format cannot store the geometries as efficiently as it would be possible with a binary format. Also only vector-based data types can be represented. Another disadvantage can be the strictly non-topologic approach. Every feature is completely described by one entry. However when there are features that share common components, like boundaries in neighboring polygons, these data points will be encoded twice in the GeoJSON object. On the one hand this further poses concerns about data size. On the other hand it is more difficult to execute topological analysis on the data set. Luckily there is a related data structure to tackle this problem.
+To its downsides count that a text based format cannot store the geometries as efficiently as it would be possible with a binary format. Also only vector-based data types can be represented. Another disadvantage can be the strictly non-topologic approach. Every feature is completely described by one entry. However, when there are features that share common components, like boundaries in neighboring polygons, these data points will be encoded twice in the GeoJSON object. On the one hand this further poses concerns about data size. \todo{other formulation. Two negatives}On the other hand it is more difficult to execute topological analysis on the data set. Luckily there is a related data structure to tackle this problem.
 
-\paragraph{TopoJSON} is an extension of GeoJSON and aims to encode datastructures into a shared topology \parencite{bostock2017topojson}. It supports the same geometry types as GeoJSON. It differs in some additional properties to use and new object types like "Topology" and "GeometryCollection". Its main feature is that LineStrings, Polygons and their multiplicitary equivalents must define line segments in a common property called "arcs". The geometries themselves then reference the arcs from which they are made up. This reduces redundancy of data points. Another feature is the quantization of positions. To use it one can define a "transform" object which specifies a scale and translate point to encode all coordinates. Together with delta-encoding of position arrays one obtains integer values better suited for efficient serialization and reduced file size. 
+\paragraph{TopoJSON} is an extension of GeoJSON and aims to encode datastructures into a shared topology \parencite{bostock2017topojson}. It supports the same geometry types as GeoJSON. It differs in some additional properties to use and new object types like "Topology" and "GeometryCollection". Its main feature is that LineStrings, Polygons and their multiplicitary equivalents must define line segments in a common property called "arcs". The geometries themselves then reference the arcs from which they are made up. This reduces redundancy of data points. Another feature is the quantization of positions. To use it, one can define a "transform" object which specifies a scale and translate point to encode all coordinates. Together with delta-encoding of position arrays one obtains integer values better suited for efficient serialization and reduced file size. 
 
-Other than the reduced data duplication topological formats have the benefit of topological analysis and editing. When modifying adjacent Polygons for example by simplification one would prefer TopoJSON over GeoJSON. Figure \ref{fig:topological-editing} shows what this means. When modifying the boundary of one polygon, one can create gaps or overlaps in non-topological representations. With a topological data structure however the topology will preserve. \parencite{theobald2001understanding}
+Other than the reduced data duplication topological formats have the benefit of topological analysis and editing. When modifying adjacent Polygons for example by simplification one would prefer TopoJSON over GeoJSON. Figure \ref{fig:topological-editing} shows what this means. When modifying the boundary of one polygon, one can create gaps or overlaps in non-topological representations. With a topological data structure however the topology will be preserved. \parencite{theobald2001understanding}
 
 \begin{figure}
 	\centering
 	\includegraphics[width=.3\linewidth]{./images/topological-editing.png}
-	\label{fig:topological-editing}
 	\caption{Topological editing (top) vs. Non-topological editing (bottom) \parencite{theobald2001understanding}}
+	\label{fig:topological-editing}
 \end{figure}
 
-\paragraph{Coordinate representation} Both GeoJSON and TopoJSON represent positions as an array of numbers. The elements depict longitude, latitude and optionally altitude in that order. For simplicity this thesis will deal with two-dimensional positions only. A polyline is described by creating an array of these positions as seen in listing \ref{lst:coordinates-array}. 
+\paragraph{Coordinate representation} Both GeoJSON and TopoJSON represent positions as an array of numbers. The elements depict longitude, latitude and optionally altitude in that order. For simplicity, this thesis will deal with two-dimensional positions only. A polyline is described by creating an array of these positions as seen in listing \ref{lst:coordinates-array}. 
 
 \begin{lstlisting}[
 float=htb,
@@ -44,7 +44,7 @@ caption=Polyline coordinates in nested-array form
 [[102.0, 0.0], [103.0, 1.0], [104.0, 0.0], [105.0, 1.0]]
 \end{lstlisting}
 
-There will be however one library in this thesis which expects coordinates in a different format. Listing \ref{lst:coordinates-object} shows a polyline in the sense of this library. Here one location is represented by an object with x and y properties.
+There is however one library in this thesis which expects coordinates in a different format. Listing \ref{lst:coordinates-object} shows a polyline in the sense of this library. Here one location is represented by an object with x and y properties.
 
 \begin{lstlisting}[
 float=htb,
diff --git a/thesis/chapters/02.04-webruntime.tex b/thesis/chapters/02.04-webruntime.tex
index 3ab3716..3b8d0f0 100644
--- a/thesis/chapters/02.04-webruntime.tex
+++ b/thesis/chapters/02.04-webruntime.tex
@@ -1,28 +1,28 @@
 
 \subsection[Web runtimes]{Running the algorithms on the web platform}
 
-JavaScript has been the only native programming language of web browsers for a long time. With the development of WebAssembly there seems to be an alternative on its way. This technology, its benefits and drawbacks, will be explained in this chapter.
+\todo{neuer satz plus quelle}JavaScript has been the only native programming language of web browsers for a long time. With the development of WebAssembly, there seems to be an alternative on its way. This technology, its benefits and drawbacks, will be explained in this chapter.
 
 
-\subsubsection{Introduction to Webassembly}
+\subsubsection{Introduction to WebAssembly}
 
-WebAssembly\footnote{\url{https://webassembly.org/}} started in April 2015 with an W3C Community Group\footnote{\url{https://www.w3.org/community/webassembly/}} and is designed by engineers from the four major browser vendors (Mozilla, Google, Apple and Microsoft). It is a portable low-level bytecode designed as target for compilation of high-level languages. By being an abstraction over modern hardware it is language-, hardware-, and platform-independent. It is intended to be run in a stack-based virtual machine. This way it is not restrained to the Web platform or a JavaScript environment. Some key concepts are the structuring into modules with exported and imported definitions and the linear memory model. Memory is represented as a large array of bytes that can be dynamically grown. Security is ensured by the linear memory being disjoint from code space, the execution stack and the engine's data structures. Another feature of WebAssembly is the possibility of streaming compilation and the parallelization of compilation processes. \parencite{haas2017bringing}
+WebAssembly\footnote{\url{https://webassembly.org/}} started in April 2015 with an W3C Community Group\footnote{\url{https://www.w3.org/community/webassembly/}} and is designed by engineers from the four major browser vendors (Mozilla, Google, Apple and Microsoft). It is a portable low-level bytecode designed as compilation target of high-level languages. By being an abstraction over modern hardware it is language-, hardware-, and platform-independent. It is intended to be run in a stack-based virtual machine. This way it is not restrained to the Web platform or a JavaScript environment. Some key concepts are the structuring into modules with exported and imported definitions and the linear memory model. Memory is represented as a large array of bytes that can be dynamically grown. Security is ensured by the linear memory being disjoint from code space, the execution stack and the engine's data structures. Another feature of WebAssembly is the possibility of streaming compilation and the parallelization of compilation processes. \parencite{haas2017bringing}
 
-The goals of WebAssembly have been well defined. It's semantics are intended to be safe and fast to execute and bring portability by language-, hardware- and platform-independence. Furthermore it should be deterministic and have simple interoperability with the web platform. For its representation the following goals are declared. It shall be compact and easy to decode, validate and compile. Parallelization and streamable compilation are also mentioned. \parencite{haas2017bringing}
+The goals of WebAssembly have been well defined. Its semantics are intended to be safe and fast to execute and to bring portability by language-, hardware- and platform-independence. Furthermore, it should be deterministic and have simple interoperability with the web platform. For its representation, the following goals are declared. It shall be compact and easy to decode, validate and compile. Parallelization and streamable compilation are also mentioned. \parencite{haas2017bringing}
 
-These goals are not specific to WebAssembly. They can be seen as properties that a low-level compilation target for the web should have. In fact there have been previous attempts to run low-level code on the web. Examples are Microsoft's ActiveX, Native Client (NaCl) and Emscripten each having issues complying with the goals. Java and Flash are examples for managed runtime plugins. Their usage is declining however not at least due to falling short on the goals mentioned above. \parencite{haas2017bringing}
+These goals are not specific to WebAssembly. They can be seen as properties that a low-level compilation target for the web should have. In fact there have been previous attempts to run low-level code on the web. Examples are Microsoft's ActiveX, Native Client (NaCl) and Emscripten, each having issues complying with the goals stated. Java and Flash are examples for managed runtime plugins. Their usage is declining however not at least due to falling short on the goals mentioned above. \parencite{haas2017bringing}
 
-It is often stated that WebAssembly can bring performance benefits. It makes sense that statically typed machine code beats scripting languages performance wise. It has to be observed however if the overhead of switching contexts will neglect this performance gain. JavaScript has made a lot of performance improvements over the past years. Not at least Googles development on the V8 engine has brought JavaScript to an acceptable speed for extensive calculations. Modern engines observe the execution of running JavaScript code and will perform optimizations that can be compared to optimizations of compilers. \parencite{clark2017what}
+It is often stated that WebAssembly can bring performance benefits. It makes sense that statically typed machine code beats scripting languages performance wise. It has to be observed however, if the overhead of switching contexts will neglect this performance gain. JavaScript has made a lot of performance improvements over the past years. Not at least Googles development on the V8 engine has brought JavaScript to an acceptable speed for extensive calculations. Modern engines observe the execution of running JavaScript code and will perform optimizations that can be compared to optimizations of compilers. \parencite{clark2017what}
 
-The JavaScript ecosystem has rapidly evolved the past years. Thanks to package managers like bower, npm and yarn it is simple to pull code from external sources into ones codebase. Initially thought for server sided JavaScript execution the ecosystem has found its way into front-end development via module bundlers like browserify, webpack and rollup. In course of this growth many algorithms and implementations have been ported to JavaScript for use on the web. With WebAssembly this ecosystem can be broadened even further. By lifting the language barrier existing work of many more programmers can be reused on the web. Whole libraries exclusive for native development could be imported by a few simple tweaks. Codecs not supported by browsers can be made available for use in any browser supporting WebAssembly. \parencite{surma2018emscripting}
+The JavaScript ecosystem has rapidly evolved the past years. Thanks to package managers like \todo{format}bower, npm and yarn it is simple to pull code from external sources into ones codebase. Initially thought for server sided JavaScript execution the ecosystem has found its way into front-end development via module bundlers like browserify, webpack and rollup. In course of this growth many algorithms and implementations have been ported to JavaScript for use on the web. With WebAssembly this ecosystem can be broadened even further. By lifting the language barrier, existing work of many more programmers can be reused on the web. Whole libraries exclusive for native development could be imported by a few simple tweaks. Codecs not supported by browsers can be made available for use in any browser supporting WebAssembly. \parencite{surma2018emscripting}
 
 % In this these the C++ library psimpl will be utilized to bring polyline simplification to the web. This library already implements various algorithms for this task. It will be further introduced in chapter \ref{ch:psimpl}.
 
 \paragraph{The Emscripten toolchain}
 
-There are various compilers with WebAssembly as compilation target. In this thesis the Emscripten toolchain is used. Other notable compilers are wasm-pack\footnote{\url{https://rustwasm.github.io/}} for rust projects and AssemblyScript\footnote{\url{https://github.com/AssemblyScript/assemblyscript}} for a TypeScript subset. This latter compiler is particularly interesting as TypeScript, itself a superset of JavaScript, is a popular choice among web developers. This reduces the friction for WebAssembly integration as it is not necessary to learn a new language.
+There are various compilers with WebAssembly as compilation target. In this thesis the Emscripten toolchain is used. Other notable compilers are wasm-pack\footnote{\url{https://rustwasm.github.io/}} for Rust projects and AssemblyScript\footnote{\url{https://github.com/AssemblyScript/assemblyscript}} for a TypeScript subset. This latter compiler is particularly interesting as TypeScript, itself a superset of JavaScript, is a popular choice among web developers. This reduces the friction for WebAssembly integration as it is not necessary to learn a new language.
 
-Emscripten\footnote{\url{https://webassembly.org/}} started with the goal to compile unmodified C and C++ applications to JavaScript. They did this by acting as a compiler backend to LLVM assembly. High level languages compile through a frontend into the LLVM intermediate representation. Well known frontends are Clang and LLVM-GCC. From there it gets passed through a backend to generate the architecture specific machine code. Emscripten hooks in here to generate asm.js, a performant JavaScript subset. In figure \ref{fig:emscripten-chain} one such example chain can be seen. On the left is the original C code which sums up numbers from 1 to 100. The resulting LLVM assembly can be seen in the middle. It is definitely more verbose, but easier to work on for the backend compiler. Notable are the allocation instructions, the labeled code blocks and code flow moves. The JavaScript representation on the right is the nearly one to one translation of the LLVM assembly. The branching is done via a switch-in-for loop, memory is implemented by a JavaScript array named HEAP and LLVM assembly functions calls become normal JavaScript function calls like \textsf{\_printf()}. Through optimizations the code becomes more compact and only then more performant. \parencite{zakai2011emscripten}
+Emscripten\footnote{\url{https://webassembly.org/}} started with the goal to compile unmodified C and C++ applications to JavaScript. This is achieved by acting as a compiler backend to \todo{introduce LLVM}LLVM assembly. High level languages compile through a frontend into the LLVM intermediate representation. Well known frontends are Clang and LLVM-GCC. From there it gets passed through a backend to generate the architecture specific machine code. Emscripten hooks in here to generate asm.js, a performant JavaScript subset. In figure \ref{fig:emscripten-chain} one such example chain can be seen. On the left is the original C code which sums up numbers from 1 to 100. The resulting LLVM assembly can be seen in the middle. It is definitely more verbose, but \todo{explain easiness}easier to work on for the backend compiler. Notable are the allocation instructions, the labeled code blocks and code flow moves. The JavaScript representation on the right is the nearly one to one translation of the LLVM assembly. The branching is done via a switch-in-for loop, memory is implemented by a JavaScript array named HEAP and LLVM assembly functions calls become normal JavaScript function calls like \textsf{\_printf()}. Through optimizations the code becomes more compact and only then more performant. \parencite{zakai2011emscripten}
 
 \begin{figure}
 	\centering
@@ -33,6 +33,8 @@ Emscripten\footnote{\url{https://webassembly.org/}} started with the goal to com
 	\label{fig:emscripten-chain}
 \end{figure}
 
+\todo{bild rekonstruieren und "nach (quelle)"}
+
 It is in fact this project that inspired the creation of WebAssembly. It was even called the "natural evolution of asm.js"\footnote{\url{https://groups.google.com/forum/\#!topic/emscripten-discuss/k-egXO7AkJY/discussion}}. As of May 2018 Emscripten changed its default output to WebAssembly\footnote{\url{https://github.com/emscripten-core/emscripten/pull/6419}} while still supporting asm.js. Currently the default backend named \textsf{fastcomp} generates the WebAssembly bytecode from asm.js. A new backend however is about to take its place that compiles directly from LLVM \parencite{zakai2019llvmbackend}. 
 
-The compiler is only one part of the Emscripten toolchain. Part of that are various APIs, for example for file system emulation or network calls, and tools like the compiler mentioned.
+The compiler is only one part of the Emscripten toolchain. Part of it are various \todo{abbrevation tools latex}APIs, for example for file system emulation or network calls, and tools like the compiler mentioned.
diff --git a/thesis/chapters/03.00-methodology.tex b/thesis/chapters/03.00-methodology.tex
index 8c014dd..0666088 100644
--- a/thesis/chapters/03.00-methodology.tex
+++ b/thesis/chapters/03.00-methodology.tex
@@ -2,17 +2,17 @@
 
 % Performance benchmark
 
-In this chapter I will explain the approach to improve the performance of a simplification algorithm in a web browser via WebAssembly. The go-to library for this kind of operation is Simplify.js. It is the JavaScript implementation of the Douglas-Peucker algorithm with optional radial distance preprocessing. The library will be rebuilt in the C programming language and compiled to WebAssembly with Emscripten. A web page is built to produce benchmarking insights to compare the two approaches performance wise.
+In this chapter the approach to improve the performance of a simplification algorithm in a web browser via WebAssembly will be explained. The go-to library for this kind of operation is Simplify.js. It is the JavaScript implementation of the Douglas-Peucker algorithm with optional radial distance preprocessing. The library will be rebuilt in the C programming language and compiled to WebAssembly with Emscripten. A web page is built to produce benchmarking insights to compare the two approaches performance wise.
 
 \subsection{State of the art: Simplify.js}
 \label{ch:simplify.js}
 % Simplify.JS + turf
 
-Simplify.js calls itself a "tiny high-performance JavaScript polyline simplification library"\footnote{\url{https://mourner.giformthub.io/simplify-js/}}. It was extracted from Leaflet, the "leading open-source JavaScript library for mobile-friendly interactive maps"\footnote{\url{https://leafletjs.com/}}. Due to its usage in leaflet and Turf.js, a geospatial analysis library, it is the most common used library for polyline simplification. The library itself currently has 20,066 weekly downloads on the npm platform while the Turf.js derivate @turf/simplify has 30,389. Turf.js maintains an unmodified fork of the library in its own repository. The mentioned mapping library Leaflet is is downloaded 189.228 times a week.
+Simplify.js calls itself a "tiny high-performance JavaScript polyline simplification library"\footnote{\url{https://mourner.giformthub.io/simplify-js/}}. It was extracted from Leaflet, the "leading open-source JavaScript library for mobile-friendly interactive maps"\footnote{\url{https://leafletjs.com/}}. Due to its usage in leaflet and Turf.js, a geospatial analysis library, it is the most common used library for polyline simplification. The library itself currently has 20,066 weekly downloads on the npm platform while the Turf.js derivate @turf/simplify has 30,389. Turf.js maintains an unmodified fork of the library in its own repository. The mentioned mapping library Leaflet is downloaded 189,228 times a week.
 
 The Douglas-Peucker algorithm is implemented with an optional radial distance preprocessing routine. This preprocessing trades performance for quality. Thus the mode for disabling this routine is called highest quality. 
 
-Interestingly the library expects coordinates to be a list of object with x and y properties. GeoJSON and TopoJSON however store coordinates in nested array form (see chapter \ref{ch:dataformats}). Luckily since the library is small and written in JavaScript any skilled web developer can easily fork and modify the code for his own purpose. This is even pointed out in the library's source code. The fact that Turf.js, which can be seen as a convenience wrapper for processing GeoJSON data, decided to keep the library as is might indicate some benefit to this format. Listing \ref{lst:turf-transformation} shows how Turf.js calls Simplify.js. Instead of altering the source code the data is transformed back and forth between the formats on each call. It is questionable if this practice is advisable at all. 
+Interestingly the library expects coordinates to be a list of objects with x and y properties. GeoJSON and TopoJSON however store coordinates in nested array form (see chapter \ref{ch:dataformats}). Luckily since the library is small and written in JavaScript any skilled web developer can easily fork and modify the code for his own purpose. This is even pointed out in the library's source code. The fact that Turf.js, which can be seen as a convenience wrapper for processing GeoJSON data, decided to keep the library as is might indicate some benefit to this format. Listing \ref{lst:turf-transformation} shows how Turf.js calls Simplify.js. Instead of altering the source code the data is transformed back and forth between the formats on each call. It is questionable if this practice is advisable at all. 
 
 \lstinputlisting[
 	float=htbp,
@@ -33,12 +33,12 @@ Since it is not clear which case is faster, and given how simple the required ch
 	label=lst:diff-simplify.js
 ]{../lib/simplify-js-alternative/simplify.diff}
 
-\subsection{The webassembly solution}
+\subsection{The WebAssembly solution}
 \label{sec:benchmark-webassembly}
 
-In scope of this thesis a library will be created that implements the same procedure as Simplify.js in C code. It will be made available on the web platform through WebAssembly. In the style of the model library it will be called Simplify.wasm. The compiler to use will be Emscripten as it is the standard for porting C code to WebAssembly.
+In scope of this thesis a library will be created that implements the same procedure as Simplify.js in C code. It will be made available on the web platform through WebAssembly. In the style of the model library it will be called Simplify.wasm. The compiler to be used will be Emscripten as it is the standard for porting C code to WebAssembly.
 
-As mentioned the first step is to port Simplify.js to the C programming language. The file \path{lib/simplify-wasm/simplify.c} shows the attempt. It is kept as close to the JavaScript library as possible. This may result in C-untypical coding style but prevents skewed results from unexpected optimizations to the procedure itself. The entry point is not the \texttt{main}-function but a function called simplify. This is specified to the compiler as can be seen in listing \ref{lst:simplify-wasm-compiler-call}.
+As mentioned, the first step is to port Simplify.js to the C programming language. The file \path{lib/simplify-wasm/simplify.c} shows the attempt. It is kept as close to the JavaScript library as possible. This may result in C-untypical coding style but prevents skewed results from unexpected optimizations to the procedure itself. The entry point is not the \texttt{main}-function but a function called \todo{format}simplify. This is specified to the compiler as can be seen in listing \ref{lst:simplify-wasm-compiler-call}.
 
 \lstinputlisting[
 float=htpb,
@@ -47,10 +47,10 @@ language=bash,
 label=lst:simplify-wasm-compiler-call,
 caption={The call to compile the C source code to WebAssembly in a Makefile}
 ]{../lib/simplify-wasm/Makefile}
+\todo{more about compiler call}
+Furthermore, the functions \todo{format}malloc and free from the standard library are made available for the host environment. Compiling the code through Emscripten produces a binary file in wasm format and the glue code as JavaScript. These files are called \texttt{simplify.wasm} and \texttt{simplify.js} respectively. 
 
-Furthermore the functions malloc and free from the standard library are made available for the host environment. Compiling the code through Emscripten produces a binary file in wasm format and the glue code as JavaScript. These files are called \texttt{simplify.wasm} and \texttt{simplify.js} respectively. 
-
-An example usage can be seen in \path{lib/simplify-wasm/example.html}. Even through the memory access is abstracted in this example the process is still unhandy and far from a drop-in replacement of Simplify.js. Thus in \path{lib/simplify-wasm/index.js} a further abstraction to the Emscripten emitted code was written. The exported function \texttt{simplifyWasm} handles module instantiation, memory access and the correct call to the exported wasm function. Finding the correct path to the wasm binary is not always clear however when the code is imported from another location. The proposed solution is to leave the resolving of the code-path to an asset bundler that processes the file in a preprocessing step.
+An example usage can be seen in \path{lib/simplify-wasm/example.html}. Even though the memory access is abstracted in this example the process is still unhandy and far from a drop-in replacement of Simplify.js. Thus in \path{lib/simplify-wasm/index.js} a further abstraction to the Emscripten emitted code was written. The exported function \texttt{simplifyWasm} handles module instantiation, memory access and the correct call to the exported wasm function. Finding the correct path to the wasm binary is not always clear when the code is imported from another location. The proposed solution is to leave the resolving of the code-path to an asset bundler that processes the file in a preprocessing step.
 
 \lstinputlisting[
 float=htpb,
@@ -60,9 +60,9 @@ label=lst:simplify-wasm,
 caption={The top level function to invoke the WebAssembly simplification.}
 ]{../lib/simplify-wasm/index.js}
 
-Listing \ref{lst:simplify-wasm} shows the function \texttt{simplifyWasm}. Further explanaition will follow regarding the abstractions \texttt{getModule}, \texttt{storeCoords} and \texttt{loadResultAndFreeMemory}. 
+Listing \ref{lst:simplify-wasm} shows the function \texttt{simplifyWasm}. Further explanation will follow regarding the abstractions \texttt{getModule}, \texttt{storeCoords} and \texttt{loadResultAndFreeMemory}. 
 
-\paragraph {Module instantiation} will be done on the first call only but requires the function to be asynchronous. For a neater experience in handling Emscripten modules a utility function named \texttt{initEmscripten}\footnote{/lib/wasm-util/initEmscripten.js} was written to turn the module factory into a JavaScript Promise that resolves on finished compilation. The usage of this function can be seen in listing \ref{lst:simplify-wasm-emscripten-module}. The resulting WebAssembly module is cached in the variable \texttt{emscriptenModule}.
+\paragraph {Module instantiation} will be done on the first call only but requires the function to be asynchronous. For a neater experience in handling Emscripten modules, a utility function named \texttt{initEmscripten}\footnote{/lib/wasm-util/initEmscripten.js} was written to turn the module factory into a JavaScript \todo{format}Promise that resolves on finished compilation. The usage of this function can be seen in listing \ref{lst:simplify-wasm-emscripten-module}. The resulting WebAssembly module is cached in the variable \texttt{emscriptenModule}.
 
 \lstinputlisting[
 float=htbp,
@@ -71,8 +71,9 @@ firstline=35, lastline=40,
 caption=My Caption, 
 label=lst:simplify-wasm-emscripten-module
 ]{../lib/simplify-wasm/index.js}
+\todo{find a caption for listing 8}
 
-\paragraph {Storing coordinates} into the module memory is done in the function \texttt{storeCoords}. Emscripten offers multiple views on the module memory. These correspond to the available WebAssembly data types (e.g. HEAP8, HEAPU8, HEAPF32, HEAPF64, ...)\footnote{\url{https://emscripten.org/docs/api_reference/preamble.js.html\#type-accessors-for-the-memory-model}}. As Javascript numbers are always represented as a double-precision 64-bit binary\footnote{\url{https://www.ecma-international.org/ecma-262/6.0/\#sec-4.3.20}} (IEEE 754-2008) the HEAP64-view is the way to go to not lose precision. Accordingly the datatype double is used in C to work with the data. Listing \ref{lst:wasm-util-store-coords} shows the transfer of coordinates into the module memory. In line 3 the memory is allocated using the exported \texttt{malloc}-function. A JavaScript TypedArray is used for accessing the buffer such that the loop for storing the values (lines 5 - 8) is trivial. 
+\paragraph {Storing coordinates} into the module memory is done in the function \texttt{storeCoords}. Emscripten offers multiple views on the module memory. These correspond to the available WebAssembly data types (e.g. HEAP8, HEAPU8, HEAPF32, HEAPF64, ...)\footnote{\url{https://emscripten.org/docs/api_reference/preamble.js.html\#type-accessors-for-the-memory-model}}. As Javascript numbers are always represented as a double-precision 64-bit binary\footnote{\url{https://www.ecma-international.org/ecma-262/6.0/\#sec-4.3.20}} (IEEE 754-2008), the HEAPF64-view is the way to go to not lose precision. Accordingly the datatype double is used in C to work with the data. Listing \ref{lst:wasm-util-store-coords} shows the transfer of coordinates into the module memory. In line 3 the memory is allocated using the exported \texttt{malloc}-function. A JavaScript TypedArray is used for accessing the buffer such that the loop for storing the values (lines 5 - 8) is trivial. 
 
 \lstinputlisting[
 float=tbph,
@@ -82,7 +83,7 @@ caption=The storeCoords function,
 label=lst:wasm-util-store-coords
 ]{../lib/wasm-util/coordinates.js}
 
-\paragraph{To read the result} back from memory we have to look at how the simplification will be returned in the C code. Listing \ref{lst:simplify-wasm-entrypoint} shows the entry point for the C code. This is the function that gets called from JavaScript. As expected arrays are represented as pointers with corresponding length. The first block of code (line 2 - 6) is only meant for declaring needed variables. Lines 8 to 12 mark the radial distance preprocessing. The result of this simplification is stored in an auxiliary array named \texttt{resultRdDistance}. In this case \texttt{points} will have to point to the new array and the length is adjusted. Finally the Douglas-Peucker procedure is invoked after reserving enough memory. The auxiliary array can be freed afterwards. The problem now is to return the result pointer and the array length back to the calling code. The fact that pointers in Emscripten are represented by 32bit will be exploited to return a fixed size array of two integers containing the values. A hacky solution but it works. We can now look back at how the JavaScript code reads the result.
+\paragraph{To read the result} back from memory one has to look at how the simplification is returned in the C code. Listing \ref{lst:simplify-wasm-entrypoint} shows the entry point for the C code. This is the function which gets called from JavaScript. As expected, arrays are represented as pointers with corresponding length. The first block of code (line 2 - 6) is only meant for declaring needed variables. Lines 8 to 12 mark the radial distance preprocessing. The result of this simplification is stored in an auxiliary array named \texttt{resultRdDistance}. In this case, \texttt{points} will have to point to the new array and the length is adjusted. Finally, the Douglas-Peucker procedure is invoked after reserving enough memory. The auxiliary array can be freed afterwards. The problem now is to return the result pointer and the array length back to the calling code. The fact that pointers in Emscripten are represented by 32bit will be exploited to return a fixed size array of two integers containing the values. We can now look back at how the JavaScript code reads the result.
 
 \lstinputlisting[
 float=tbph,
@@ -93,7 +94,7 @@ label=lst:simplify-wasm-entrypoint
 ]{../lib/simplify-wasm/simplify.c}
 
 
-Listing \ref{lst:wasm-util-load-result} shows the code to read the values back from module memory. The result pointer and its length are acquired by dereferencing the \texttt{resultInfo}-array. The buffer to use is the heap for unsigned 32-bit integers. This information can then be used to align the Float64Array-view on the 64-bit heap. Constructing the appropriate coordinate representation by reversing the flattening can be looked up in the same file. It is realised in the \texttt{unflattenCoords} function. At last it is important to actually free the memory reserved for both the result and the result-information. The exported method \texttt{free} is the way to go here. 
+Listing \ref{lst:wasm-util-load-result} shows the code to read the values back from module memory. The result pointer and its length are acquired by dereferencing the \texttt{resultInfo}-array. The buffer to use is the heap for unsigned 32-bit integers. This information can then be used to align the Float64Array-view on the 64-bit heap. Construction of the appropriate coordinate representation, by reversing the flattening, can be looked up in the same file. It is realised in the \texttt{unflattenCoords} function. At last it is important to actually free the memory reserved for both the result and the result-information. The exported method \texttt{free} is the way to go here. 
 
 \lstinputlisting[
 float=!tbph,
@@ -105,17 +106,17 @@ label=lst:wasm-util-load-result
 
 \subsection{File sizes}
 
-For web applications a important measure is the size of libraries. It defines the cost of including the functionality in terms of how much the application size will grow. When it gets too large especially users with low bandwidth are discriminated as it might be impossible to load the app at all in a reasonable time. Even with fast internet loading times are relevant as users expect a fast time to first interaction. Also users with limited data plans are glad when developers keep their bundle size to a minimum.
+For web applications an important measure is the size of libraries. It defines the cost of including the functionality in terms of how much the application size will grow. When it gets too large, especially users with low bandwidth are discriminated as it might be impossible to load the app at all in a reasonable time. Even with fast internet, loading times are relevant as users expect a fast time to first interaction. Also users with limited data plans are glad when developers keep their bundle size to a minimum.
 
 The file sizes in this chapter will be given as the gzipped size. gzip is a file format for compressed files based on the DEFLATE algorithm. It is natively supported by all browsers and the most common web server software. So this is the format that files will be transmitted in on production applications.
 
-For JavaScript applications there is also the possibility of reducing filesize by code minification. This is the process of reformating the source code without changing the functionality. Optimization are brought for example by removing unnecessary parts like spaces and comments or reducing variable names to single letters. Minification is often done in asset bundlers that process the JavaScript source files and produce the bundled application code. 
+For JavaScript applications there is also the possibility of reducing filesize by code minification. This is the process of reformating the source code without changing the functionality. \todo{formulierung}Optimization are brought for example by removing unnecessary parts like spaces and comments or reducing variable names to single letters. Minification is often done in asset bundlers that process the JavaScript source files and produce the bundled application code. 
 
-For the WebAssembly solution there are two files required to work with it. The wasm bytecode and JavaScript gluecode. The glue code is already minified by the Emscripten compiler. The binary has a size of 3.8KB while the JavaScript code has a total of 3.1KB. Simplify.js on the other hand will merely need a size of 1.1KB. With minification the size shrinks to 638 bytes.
+For the WebAssembly solution there are two files required to work with it. The \textsf{.wasm} bytecode and JavaScript gluecode. The glue code is already minified by the Emscripten compiler. The binary has a size of 3.8KB while the JavaScript code has a total of 3.1KB. Simplify.js on the other hand will merely need a size of 1.1KB. With minification the size shrinks to 638 bytes.
 
-File size was not the main priority when producing the WebAssembly solution. There are ways to further shrink the size of the wasm bytecode. As of now it contains the logic of the library but also necessary functionality from the C standard library. These were added by Emscripten automatically. The bloat comes from using the memory management functions malloc and free. If the goal was to reduce the file size, one would have to get along without memory management at all. This would even be possible in this case as the simplification process is a self-contained process and the module has no other usage. The input size is known beforehand so instead of creating reserved memory one could just append the result in memory at the location directly after the input feature. The function would merely need to return the result size. After the call is finished and the result is read by JavaScript the memory is not needed any more. A test build was made that renounced from memory management. The size of the wasm bytecode shrunk to 507 byte and the glue code to 2.8KB. By using vanilla JavaScript API one could even ditch the glue code altogether \parencite{surma2019replacing}.
+File size was not the main priority when producing the WebAssembly solution. There are ways to further shrink the size of the bytecode. As of now it contains the logic of the library but also necessary functionality from the C standard library. These were added by Emscripten automatically. The bloat comes from using the memory management functions \todo{format}malloc and free. If the goal was to reduce the file size, one would have to get along without memory management at all. This would even be possible in this case as the simplification process is a self-contained process and the module has no other usage. The input size is known beforehand so instead of creating reserved memory one could just append the result in memory at the location directly after the input feature. The function would merely need to return the result size. After the call is finished and the result is read by JavaScript the memory is not needed anymore. A test build was made which renounced from memory management. The size of the wasm bytecode shrunk to 507 byte and the glue code to 2.8KB. By using vanilla JavaScript API one could even ditch the glue code altogether \parencite{surma2019replacing}.
 
-For simplicity the memory management was left in as the optimizations would require more careful engineering to ensure correct functionality. The example above shows however that there is enormous potential to cut the size. Even file sizes below the JavaScript original are possible.
+For simplicity the memory management was left in as the optimizations would require more careful engineering to ensure correct functionality. The example above shows however, that there is enormous potential to cut the size. Even file sizes below the JavaScript original are possible.
 
 
 \subsection{The implementation of a web framework}
@@ -125,23 +126,23 @@ The performance comparison of the two methods will be realized in a web page. It
 
 \subsubsection{External libraries}
 
-The dynamic aspects of the web page will be built in JavaScript. Webpack\footnote{https://webpack.js.org/}  will be used to bundle the application code and use compilers like babel\footnote{https://babeljs.io/} on the source code. As mentioned in section \ref{sec:benchmark-webassembly} the bundler is also useful for handling references to the WebAssembly binary as it resolves the filename to the correct download path to use. There will be intentionally no transpiling of the JavaScript code to older versions of the ECMA standard. This is often done to increase compatibility with older browsers. Luckily this is not a requirement in this case and by refraining from this practice there will also be no unintentional impact on the application performance. Libraries in use are Benchmark.js\footnote{https://benchmarkjs.com/} for statistically significant benchmarking results, React\footnote{https://reactjs.org/} for the building the user interface and Chart.js\footnote{https://www.chartjs.org/} for drawing graphs.
+The dynamic aspects of the web page will be built in JavaScript. Webpack\footnote{https://webpack.js.org/}  will be used to bundle the application code and use compilers like babel\footnote{https://babeljs.io/} on the source code. As mentioned in section \ref{sec:benchmark-webassembly}, the bundler is also useful for handling references to the WebAssembly binary as it resolves the filename to the correct download path to use. There will be intentionally no transpiling of the JavaScript code to older versions of the ECMA standard. This is often done to increase compatibility with older browsers. Luckily this is not a requirement in this case and by refraining from this practice there will also be no unintentional impact on the application performance. Libraries in use are Benchmark.js\footnote{https://benchmarkjs.com/} for statistically significant benchmarking results, React\footnote{https://reactjs.org/} for the building the user interface and Chart.js\footnote{https://www.chartjs.org/} for drawing graphs.
 
 \subsubsection{The application logic}
-The web page consist of static and dynamic content. The static parts refer to the header and footer with explanation about the project. Those are written directly into the root HTML document. The dynamic parts are injected by JavaScript. Those will be further discussed in this chapter as they are the main application logic. 
+The web page consists of static and dynamic content. The static parts refer to the header and footer with explanation about the project. Those are written directly into the root HTML document. The dynamic parts are injected by JavaScript. Those will be further discussed in this chapter as they are the main application logic. 
 
 \begin{figure}[htb]
 	\centering
-	\label{fig:benchmarking-uml}
 	\fbox{\includegraphics[width=\linewidth]{images/benchmark-uml.jpg}}
 	\caption{UML diagram of the benchmarking application}
+	\label{fig:benchmarking-uml}
 \end{figure}
 
-The web app is built to test a variety of cases with multiple datapoints. As mentioned Benchmark.js will be used for statistically significant results. It is however rather slow as it needs about 5 to 6 seconds per datapoint. This is why multiple types of benchmarking methods are implemented. Figure \ref{fig:benchmarking-uml} shows the corresponding UML diagram of the application. One can see the UI components in the top-left corner. The root component is \texttt{App}. It gathers all the internal state of its children and passes state down where it is needed. 
+The web app is built to test a variety of cases with multiple datapoints. As mentioned, Benchmark.js will be used for statistically significant results. It is however rather slow as it needs about 5 to 6 seconds per datapoint. This is why multiple types of benchmarking methods are implemented. Figure \ref{fig:benchmarking-uml} shows the corresponding UML diagram of the application. One can see the UI components in the top-left corner. The root component is \texttt{App}. It gathers all the internal state of its children and passes state down where it is needed. 
 
 \subsubsection{Benchmark cases and chart types}
 \label{ch:benchmark-cases}
-In the upper right corner the different Use-Cases are listed. These cases implement a function \texttt{"fn"} to benchmark. Additional methods for setting up the function and clean up afterwards can be implemented as given by the parent class \texttt{BenchmarkCase}. Concrete cases can be created by instantiating one of the BenchmarkCases with a defined set of parameters. There are three charts that will be rendered using a subset of these cases. These are:
+In the upper right corner the different Use-Cases are listed. These cases implement a function \texttt{"fn"} to benchmark. Additional methods for setting up the function and clean up afterwards can be implemented as given by the parent class \texttt{BenchmarkCase}. Concrete cases can be created by instantiating one of the benchmark cases with a defined set of parameters. There are three charts that will be rendered using a subset of these cases. These are:
 
 \begin{itemize}
 	\item \textbf{Simplify.js vs Simplify.wasm} - This Chart shows the performance of the simplification by Simplify.js, the altered version of Simplify.js and the newly developed Simplify.wasm.
@@ -150,12 +151,12 @@ In the upper right corner the different Use-Cases are listed. These cases implem
 \end{itemize}
 
 \subsubsection{The different benchmark types}
-On the bottom the different types of Benchmarks implemented can be seen. They all implement the abstract \texttt{measure} function to return the mean time to run a function specified in the given BenchmarkCase. The \texttt{IterationsBenchmark} runs the function a specified number of times, while the \texttt{OpsPerTimeBenchmark} always runs a certain amount of milliseconds to run as much iterations as possible. Both methods got their benefits and drawbacks. Using the iterations approach one cannot determine the time the benchmark runs beforehand. With fast devices and a small number of iterations one can even fall in the trap of the duration falling under the accuracy of the timer used. Those results would be unusable of course. It is however a very fast way of determining the speed of a function. And it holds valuable for getting a first approximation of how the algorithms perform over the span of datapoints. The second type, the operations per time benchmark, seems to overcome this problem. It is however prune to garbage collection, engine optimizations and other background processes. \parencite{bynens2010bulletproof}
+On the bottom the different types of Benchmarks implemented can be seen. They all implement the abstract \texttt{measure} function to return the mean time to run a function specified in the given \texttt{BenchmarkCase}. The \texttt{IterationsBenchmark} runs the function a specified number of times, while the \texttt{OpsPerTimeBenchmark} always runs a certain amount of milliseconds to run as much iterations as possible. Both methods got their benefits and drawbacks. Using the iterations approach one cannot determine the time the benchmark runs beforehand. With fast devices and a small number of iterations one can even fall in the trap of the duration falling under the accuracy of the timer used. Those results would be unusable of course. It is however a very fast way of determining the speed of a function. And it holds valuable for getting a first approximation of how the algorithms perform over the span of datapoints. The second type, the operations per time benchmark, seems to overcome this problem. It is however prune to garbage collection, engine optimizations and other background processes. \parencite{bynens2010bulletproof}
 
 Benchmark.js combines these approaches. In a first step it approximates the runtime in a few cycles. From this value it calculates the number of iterations to reach an uncertainty of at most 1\%. Then the samples are gathered. \parencite{hossain2012benchmark}
 
 \subsubsection{The benchmark suite}
-For running multiple benchmarks the class \texttt{BenchmarkSuite} was created. It takes a list of BenchmarkCases and runs them through a BenchmarkType. The Suite manages starting, pausing and stopping of going through list. It updates the statistics gathered on each cycle. By injecting an \textsl{onCycle} method, the \texttt{Runner} component can give live feedback about the progress.
+For running multiple benchmarks the class \texttt{BenchmarkSuite} was created. It takes a list of \texttt{BenchmarkCases} and runs them through a \texttt{BenchmarkType}. The suite manages starting, pausing and stopping of going through list. It updates the statistics gathered on each cycle. By injecting an \textsl{onCycle} method, the \texttt{Runner} component can give live feedback about the progress.
 
 \begin{figure}[htb]
 	\centering
@@ -164,11 +165,11 @@ For running multiple benchmarks the class \texttt{BenchmarkSuite} was created. I
 	\caption{The state machine for the benchmark suite}
 \end{figure}
 
-Figure \ref{fig:benchmarking-statemachine} shows the state machine of the suite. Based on this diagram the user interface component shows action buttons so the user can interact with the state. While running the suite checks if a state change was requested and acts accordingly by pausing the benchmarks or resetting all statistics gathered when stopping.
+Figure \ref{fig:benchmarking-statemachine} shows the state machine of the suite. Based on this diagram the user interface component shows action buttons so the user can interact with the state. While running, the suite checks if a state change was requested and acts accordingly by pausing the benchmarks or resetting all statistics gathered when stopping.
 
 \subsubsection{The user interface}
 
-The user interface has three regions. One for configuring input parameters. One for controlling the benchmark process and at last a diagram of the results. Figure \ref{fig:benchmark-ui} shows the user interface.
+The user interface has three sections. One for configuring input parameters. One for controlling the benchmark process and at last a diagram of the results. Figure \ref{fig:benchmark-ui} shows the user interface.
 
 \begin{figure}[!htb]
 	\centering
@@ -177,7 +178,7 @@ The user interface has three regions. One for configuring input parameters. One
 	\label{fig:benchmark-ui}
 \end{figure}
 
-\paragraph{Settings} At first the input parameters of the algorithm have to be specified. For that there are some polylines prepared to choose from. They are introduced in chapter \ref{ch:benchmark-data}. Instead of testing a single tolerance value the user can specify a range. This way the behavior of the algorithms can be observed in one chart. The high quality mode got its name from Simplify.js. If it is enabled there will be no radial-distance preprocessing step before applying the Douglas-Peucker routine. The next option determines which benchmarks will be run. The options are mentioned in chapter \ref{ch:benchmark-cases}. One of the three benchmark methods implemented can be selected. Depending on the method chosen additional options will show to further specify the benchmark parameters. The last option deals with chart rendering. Debouncing limits the rate at which functions fire. In this case the chart will delay rendering when datapoints come in at a fast rate.
+\paragraph{Settings} At first the input parameters of the algorithm have to be specified. For that there are some polylines prepared to choose from. They are introduced in chapter \ref{ch:benchmark-data}. Instead of testing a single tolerance value the user can specify a range. This way the behavior of the algorithms can be observed in one chart. The high quality mode got its name from Simplify.js. If it is enabled there will be no radial-distance preprocessing step before applying the Douglas-Peucker routine. The next option determines which benchmarks will be run. The options are mentioned in chapter \ref{ch:benchmark-cases}. One of the three benchmark methods implemented can be selected. Depending on the method chosen additional options will show to further specify the benchmark parameters. The last option deals with chart rendering. Debouncing limits the rate at which functions are called. In this case the chart will delay rendering when datapoints come in at a fast rate.
 
 \paragraph{Run Benchmark} This is the control that displays the status of the benchmark suite. Here benchmarks can be started, stopped, paused and resumed. It also shows the progress of the benchmarks completed in percentage and absolute numbers.
 
@@ -191,7 +192,7 @@ Here the test data will be shown. There are two data sets chosen to operate on.
 
 \paragraph{Simplify.js example}
 
-This is the polyline used by Simplify.js to demonstrate its capabilities. Figure \ref{fig:dataset-simplify} shows the widget on its homepage. The user can modify the parameters with the interactive elements and view the live result. The data comes from a 10.700 mile car route from Lisboa, Portugal to Singapore and is based on OpenStreetMap data. The line is defined by 73.752 positions. Even with low tolerances this number reduces drastically. This example shows perfectly why it is important to generalize polylines before rendering them.
+This is the polyline used by Simplify.js to demonstrate its capabilities. Figure \ref{fig:dataset-simplify} shows the widget on its homepage. The user can modify the parameters with the interactive elements and view the live result. The data comes from a 10.700 mile car route from Lisboa, Portugal to Singapore and is based on OpenStreetMap data. The line is defined by 73,752 positions. Even with low tolerances this number reduces drastically. This example shows perfectly why it is important to generalize polylines before rendering them.
 
 \begin{figure}[htb]
 	\centering
@@ -202,7 +203,7 @@ This is the polyline used by Simplify.js to demonstrate its capabilities. Figure
 
 \paragraph{Bavaria outline}
 
-The second polyline used for benchmarking contains 116.829 positions. It represents the outline of a german federate state, namely bavaria. It was extracted from the OSM dataset by selecting administrative boundaries. On the contrary to the former polyline this one is a closed line, often used in polygons to represent a surface. The plotted line can be seen in figure \ref{fig:dataset-bavaria}.
+The second polyline used for benchmarking contains 116,829 positions. It represents the outline of a german federate state, namely bavaria. It was extracted from the OSM dataset by selecting administrative boundaries. On the contrary to the former polyline this one is a closed line, often used in polygons to represent a surface. The plotted line can be seen in figure \ref{fig:dataset-bavaria}.
 
 \begin{figure}[htb]
 	\centering
diff --git a/thesis/chapters/04.00-results.tex b/thesis/chapters/04.00-results.tex
index 0223664..8fadc31 100644
--- a/thesis/chapters/04.00-results.tex
+++ b/thesis/chapters/04.00-results.tex
@@ -1,6 +1,6 @@
 \section[Results]{Benchmark results}
 
-In this chapter the results are presented. There were a multitude of tests to make. Multiple devices were used to run several benchmarks on different browsers and under various parameters. To organize which benchmarks had to run, first all the problem dimensions were clarified. Devices will be categorized into desktop and mobile devices. The browsers to test will come from the four major browser vendors which were involved in WebAssembly development. Those are Firefox from Mozilla, Chrome from Google, Edge from Microsoft and Safari from Apple. For either of the two data sets a fixed range of tolerances is set to maintain consistency across the diagrams. The other parameter "high quality" can be either switched on or off. The three chart types are explained in chapter \ref{ch:benchmark-cases}.
+In this chapter the results are presented. There were a multiple tests performed. Multiple devices were used to run several benchmarks on different browsers and under various parameters. To decide which benchmarks had to run, first all the problem dimensions were clarified. Devices will be categorized into desktop and mobile devices. The browsers to test will come from the four major browser vendors which were involved in WebAssembly development. These are Firefox from Mozilla, Chrome from Google, Edge from Microsoft and Safari from Apple. For either of the two data sets a fixed range of tolerances is set to maintain consistency across the diagrams. The other parameter "high quality" can be either switched on or off. The three chart types are explained in chapter \ref{ch:benchmark-cases}.
 
 All benchmark results shown here can be interactively explored at the web page provided together with this thesis. The static files lie in the \path{build} folder. The results can be found when following the "show prepared results"-link on the home page.
 
@@ -36,14 +36,14 @@ In the case of the high quality mode enabled however the original and the WebAss
 \input{./results-benchmark/win_chro_simplify_vs_false.tex}
 \input{./results-benchmark/win_chro_simplify_vs_true.tex}
 
-Figure \ref{fig:win_chro_simplify_vs_false} and \ref{fig:win_chro_simplify_vs_true} show the results under Chrome for the same setting. Here the performance seem to be switched around with the original being the slowest method in both cases. This version has however very inconsistent results. There is no clear curvature which indicates for some outside influence to the results. Either there is a flaw in the implementation or a special case of engine optimization was hit.
+Figure \ref{fig:win_chro_simplify_vs_false} and \ref{fig:win_chro_simplify_vs_true} show the results under Chrome for the same setting. Here the performance seem to be switched around with the original being the slowest method in both cases. This version has however very inconsistent results. There is no clear curvature which indicates some outside influence to the results. Either there is a flaw in the implementation or a special case of engine optimization was hit.
 
 Without high quality mode the Simplify.wasm gets overtaken by the Simplify.js alternative at 0.4 tolerance. From there on the WebAssembly solution stagnates while the JavaScript one continues to get faster. With high quality enabled the performance gain of WebAssembly is more clear than in Firefox. Here the Simplify.js alternative is the second fastest followed by its original. 
 
 \input{./results-benchmark/win_edge_simplify_vs_false.tex}
 \input{./results-benchmark/win_edge_simplify_vs_true.tex}
 
-Interestingly in the Edge browser the two JavaScript algorithms perform more alike when high quality disabled. As can be seen in figure \ref{fig:win_edge_simplify_vs_false} The turning point where WebAssembly is not the fastest is at around 0.45 to 0.6. When turning high quality on the graph in figure \ref{fig:win_edge_simplify_vs_true} resembles the chart from Chrome only with more consistent results for the original implementation.
+Interestingly, in the Edge browser the two JavaScript algorithms perform more alike when high quality disabled. As can be seen in figure \ref{fig:win_edge_simplify_vs_false}, the turning point where WebAssembly is not the fastest is at around 0.45 to 0.6. When turning high quality on, the graph in figure \ref{fig:win_edge_simplify_vs_true} resembles the chart from Chrome only with more consistent results for the original implementation.
 
 \FloatBarrier
 \subsection{Case 2 - Simplify.wasm runtime analysis}
@@ -64,9 +64,9 @@ For this case the same device as in the former case is used. To compare the resu
 
 The bar charts visualize where the time is spent in the Simplify.wasm implementation. Each data point contains a stacked column to represent the proportion of time spent for each task. The blue section represents the time spent to initialize the memory, the red one the execution of the compiled WebAssembly code. At last the green part will show the time spent for getting the coordinates back in the right format. 
 
-Inspecting figures \ref{fig:win_edge_simplify_stack_false} and \ref{fig:win_edge_simplify_stack_true} one immediately notices that the time for spent for the memory preparation does not vary in either of the two cases. Also very little time is needed to load the result back from memory especially as the tolerance gets higher. Further analysis of that will follow in chapter \ref{ch:discussion} as mentioned. 
+Inspecting figures \ref{fig:win_edge_simplify_stack_false} and \ref{fig:win_edge_simplify_stack_true} one immediately notices that the time spent for the memory preparation does not vary in either of the two cases. Also very little time is needed to load the result back from memory especially as the tolerance gets higher. Further analysis of that will follow in chapter \ref{ch:discussion} as mentioned. 
 
-In the case of high quality disabled the results show a very steep curve of the execution time. Quickly the time span for preparing the memory dominates in the process. In the second graph it can be seen that the fraction is significantly lower due to the execution time being consistently higher.
+In the case of high quality disabled, the results show a very steep curve of the execution time. Quickly the time span for preparing the memory dominates the process. In the second graph it can be seen that the fraction is significantly lower due to the execution time being consistently higher.
 
 \FloatBarrier
 \subsection{Case 3 - Benchmarking Safari on MacOS}
@@ -91,7 +91,7 @@ At first figure \ref{fig:mac_ffox_bavaria_vs_false} and \ref{fig:mac_ffox_bavari
 
 The results of the Safari browser with high quality disabled (figure \ref{fig:mac_safa_bavaria_vs_false}) resembles the figure \ref{fig:win_edge_simplify_vs_false} where the Edge browser was tested. Both JavaScript versions with similar performance surpass the WebAssembly version at one point. Unlike the Edge results the original implementation is slightly ahead. 
 
-When turning on high quality mode the JavaScript implementations still perform alike. However Simplify.wasm is clearly faster as seen in figure \ref{fig:mac_safa_bavaria_vs_true}. Simplify.wasm performs here about twice as fast as the algorithms implemented in JavaScript. Those however have a steeper decrease as the tolerance numbers go up.
+When turning on high quality mode the JavaScript implementations still perform alike. However, Simplify.wasm is clearly faster as seen in figure \ref{fig:mac_safa_bavaria_vs_true}. Simplify.wasm performs here about twice as fast as the algorithms implemented in JavaScript. Those however have a steeper decrease as the tolerance numbers go up.
 
 \FloatBarrier
 \subsection{Case 4 - Measuring the Turf.js method}
@@ -104,9 +104,9 @@ When turning on high quality mode the JavaScript implementations still perform a
 	\caption{Problem dimensions of Case 4}
 \end{table}
 
+\todo{Take red line back in. Titel passt sonst nicht.}
 
-
-In this case the system is a \textsf{Lenovo Miix 510} convertible with Ubuntu 19.04 as the operating system. Again the bavarian outline is used for simplification with both quality settings. It will be observed if the Turf.js implementation is reasonable. The third kind of chart is in use here, which is similar to the Simplify.wasm insights. There are also stacked bar charts used to visualize the time spans of subtasks. The results will be compared to the graphs of the Simplify.js vs. Simplify.wasm chart. As the Turf.js method only makes sense when The original Simplify.js is faster than the alternative the benchmarks are performed in the Firefox browser.
+In this case the system is a \textsf{Lenovo Miix 510} convertible with Ubuntu 19.04 as the operating system. Again the bavarian outline is used for simplification with both quality settings. It will be observed if the Turf.js implementation is reasonable. The third kind of chart is in use here, which is similar to the Simplify.wasm insights. There are also stacked bar charts used to visualize the time spans of subtasks. The results will be compared to the graphs of the Simplify.js vs. Simplify.wasm chart. As the Turf.js method only makes sense when the original version is faster than the alternative, the benchmarks are performed in the Firefox browser.
 
 \input{./results-benchmark/ubu_ffox_bavaria_vs_true.tex}
 \input{./results-benchmark/ubu_ffox_bavaria_jsstack_true.tex}
@@ -129,7 +129,7 @@ The next two figures show the case when high quality is disabled. In figure \ref
 	\caption{Problem dimensions of Case 5}
 \end{table}
 
-At last the results from a mobile device will be shown. The device is an iPad Air with iOS version 12.4. The Simplify.js example is being generalized using Safari and the Firefox browser. Again both quality settings are used for the benchmarks. 
+At last the results from a mobile device are shown. The device is an iPad Air with iOS version 12.4. The Simplify.js example is being generalized using Safari and the Firefox browser. Again both quality settings are used for the benchmarks. 
 
 \input{./results-benchmark/ipad_safa_simplify_vs_false.tex}
 \input{./results-benchmark/ipad_safa_simplify_vs_true.tex}
diff --git a/thesis/chapters/05-discussion.tex b/thesis/chapters/05-discussion.tex
index a8f2721..463c14a 100644
--- a/thesis/chapters/05-discussion.tex
+++ b/thesis/chapters/05-discussion.tex
@@ -5,39 +5,50 @@ In this section the results are interpreted. This section is structured in diffe
 
 \subsection{Browser differences for the JavaScript implementations}
 
-The first thing to see from the results of chapter \ref{ch:case1} and \ref{ch:case3} is that there is actually a considerable performance difference in the two versions of Simplify.js. So here we take a closer look at the JavaScript performance of the browsers. Interestingly clear winner between the similar algorithms cannot be determined as the performance is inconsistent across browsers. While the original version is faster in Firefox and Safari, the altered version is superior in Chrome and Edge. This is regardless of whether the high quality mode is switched on or not. The difference is however more significant when the preprocessing step is disabled. 
+The first thing to see from the results of chapter \ref{ch:case1} and \ref{ch:case3} is that there is actually a considerable performance difference in the two versions of Simplify.js. So here we take a closer look at the JavaScript performance of the browsers. Interestingly a clear winner between the similar algorithms cannot be determined as the performance is inconsistent across browsers. While the original version is faster in Firefox and Safari, the altered version is superior in Chrome and Edge. This is regardless of whether the high quality mode is switched on or not. The difference is however more significant when the preprocessing step is disabled. 
 
-In figure \ref{fig:win_chro_simplify_vs_true} and \ref{fig:win_edge_simplify_vs_true} one can see how similar Chrome and Edge perform with high quality mode enabled. When disabled however the algorithms perform similar in Edge (figure \ref{fig:win_edge_simplify_vs_true}) while in Chrome the alternative version still improves upon the original.
+In figure \ref{fig:win_chro_simplify_vs_true} and \ref{fig:win_edge_simplify_vs_true} one can see how similar Chrome and Edge perform with high quality mode enabled. When disabled however, the algorithms perform similar in Edge, while in Chrome the alternative version still improves upon the original.
 
-In Firefox the result is very different. Without the high quality mode the original version performs about 2.5 times better than the alternative. Figure \ref{fig:win_ffox_simplify_vs_false} shows this. When disabling the preprocessing the performance gain is even higher. the original performs constantly 3x faster as seen in figure \ref{fig:win_ffox_simplify_vs_true}.
+In Firefox the result is very different. Without the high quality mode the original version performs about 2.5 times better than the alternative. When disabling the preprocessing the performance gain is even higher. The original performs constantly 3 times faster.
 
-The same results can be reproduced under Firefox on macOS with the "Bavarian outline" dataset (figures \ref{fig:mac_ffox_bavaria_vs_false} and\ref{fig:mac_ffox_bavaria_vs_true}). Interestingly under safari the algorithms perform similarly with a small preference to the original version. This applies to either case tested (figures \ref{fig:mac_safa_bavaria_vs_false} and \ref{fig:mac_safa_bavaria_vs_true}).
+The same results can be reproduced under Firefox on macOS with the "Bavarian outline" dataset. Interestingly under Safari the algorithms perform similarly with a small preference to the original version. This applies to either case tested.
 
 With so much variance it is hard to determine the best performing browser regarding the JavaScript implementation. Under the right circumstances Chrome can produce the fastest results with the alternative implementation. Safari is consistently very fast. Even while it falls short to Firefox's results with the original algorithm when high quality is turned on. The greatest discrepancy was produced by Firefox with high quality requested. There the alternate version produced the slowest results while the results with Simplify.js can compete with Chrome's results with the Simplify.js alternative. Edge lies between these two browsers with not too bad but also not the fastest results.
 
 \subsection{Browser differences for Simplify.wasm}
 
-So diverse the results from last chapter were, so monotonous they will be here. The performance of the Simplify.wasm function is consistent across all browsers tested. This is a major benefit brought by WebAssembly often described as predictable performance.
+So diverse the results from last chapter are, so monotonous they will be here. The performance of the Simplify.wasm function is consistent across all browsers tested. This is a major benefit brought by WebAssembly often described as predictable performance.
 
-The variance it very low when the preprocessing is turned off through the high quality mode. The browsers produce about the same runtimes under the same conditions. When high quality is off the Chrome browser got its nose ahead with a mean runtime of 0.66ms. Edge follows with 1.02ms and Firefox takes an average 1.10ms. The results of chapter \ref{ch:case3} show that Safari is a bit faster at the high quality mode than Firefox but slower without. 
+The variance is very low when the preprocessing is turned off through the high quality mode. The browsers produce about the same runtimes under the same conditions. When high quality is off the Chrome browser got its nose ahead with a mean run time of 0.66ms. Edge follows with 1.02ms and Firefox takes an average 1.10ms. The results of chapter \ref{ch:case3} show that Safari is a bit faster at the high quality mode than Firefox but slower without. 
 
 \subsection{Insights into Simplify.wasm}
+\label{ch:discussion-wasm-insights}
 
-So for when the performance of Simplify.wasm was addressed it meant the time spent for the whole process of preparing memory to running the algorithm in wasm context to loading back the result to JavaScript. This makes sense when comparing it to the JavaScript library with the motive to replace it one for one. It does however not produce meaningful comparisons of WebAssembly performance in contrast to the native JavaScript runtime.
+So far when the performance of Simplify.wasm was addressed, it meant the time spent for the whole process of preparing memory to running the algorithm in wasm context to loading back the result to JavaScript. This makes sense when comparing it to the JavaScript library with the motive to replace it one by one. It does however not produce meaningful comparisons of WebAssembly performance in contrast to the native JavaScript runtime. Further insights to Simplify.wasm call will be provided here.
 
-%This is because until Simplify.wasm actually gets to the WebAssembly computation it will take some time to prepare the data and load it back afterwards. To see how long that is the additional chart type "Simplify.wasm runtime insights" was created. In figures \ref{fig:win_edge_simplify_stack_false} and \ref{fig:win_edge_simplify_stack_true} the results can be seen. Each data point contains a stacked column to represent the proportion of time spent for each task. The blue section represents the time spent to initialize the memory, the red one the execution of the compiled WebAssembly code. At last the green part will show the time spent for getting the coordinates back in the right format.
+First the parts where JavaScript is run will be examined. Chapter \ref{ch:case2} shows that there is as good as no variance in the memory initialization. This is obviously due to the fact that this step is not dependent on any other parameter than the polyline length. Initial versions of the library produced in this thesis were not as efficient in flattening the coordinate array as the final version. By replacing the built-in \texttt{Array.prototype.flat}-method with a simple \texttt{for} loop, a good optimization was achieved on the JavaScript side of the Simplify.wasm process. The \texttt{flat} method is a rather new feature of ECMAScript and its performance might be enhanced in future browser versions. This example shows that when writing JavaScript code one can quickly deviate from the "fast path" even when dealing with simple problems. 
 
-First the parts where JavaScript is run will be examined. There is as good as no variance in the memory initialization. This is obviously due to the fact that this step is not dependent on any other parameter than the polyline length. Initial versions of the library produced in this thesis were not as efficient in flattening the coordinate array as the final version. By replacing the built-in \texttt{Array.prototype.flat}-method with a simple for loop a good amount optimization was achieved on the JavaScript side of the Simplify.wasm process. The flat method is a rather new feature of ECMAScript and its performance might be enhanced in future browser versions. This example shows however that when writing JavaScript code one can quickly deviate from the "fast path" even when dealing with simple problems. 
+On the other side of the process exists the function \texttt{loadResult}. It is dependent on the size of the resulting polyline. Since this is often very low in the examples used the green bar can be rarely seen. Merely at low tolerance values like in figure \ref{fig:win_edge_simplify_stack_false} the influence is visible. The maximum fraction is at tolerance value 0.05 where the operation takes 4.26\% of the total execution time.
 
-On the other side of process lies the function \texttt{loadResult}. It is dependent on the size of the resulting polyline. Since this is often very low in the examples used the green bar can be rarely seen. Merely at low tolerance values like in figure \ref{fig:win_edge_simplify_stack_false} the influence is visible. The maximum fraction there is at tolerance value 0.05 where the operation takes 4.26\% of the total execution time.
-
-Now when comparing the two graphs one can clearly see that the influence of the JavaScript portions is much greater when the high quality mode is turned of. The time taken for preparing the memory in both cases is about 0.67ms. The execution time of the algorithms is so low in the first case, that it comes down to making up only 24,47\% when taking the median values. In case where high quality is enabled the results do not look as drastic. The median value of execution time is 4.31ms and with that much greater than preparation time. If JavaScript is at advantage in the first case and the high execution time justifies the switch of runtimes in the latter will be examined in the next chapter. 
+Now when comparing the two graphs one can clearly see that the influence of the JavaScript portions is much greater when the high quality mode is turned off. The time taken for preparing the memory in both cases is about 0.67ms. The execution time of the algorithms is so low in the first case, that it comes down to making up only 24,47\% when taking the median values. In case where high quality is enabled the results do not look as drastic. The median value of execution time is 4.31ms and with that much greater than preparation time. If JavaScript is at an advantage in the first case and the high execution time justifies the switch of runtimes in the latter will be examined in the next chapter. 
 
 
 \subsection{Comparison Simplify.wasm vs Simplify.js}
-\todo[inline]{when is what faster}
+
+In the results, Simplify.wasm is always faster when the high quality mode is enabled. The Firefox and Chrome browser are able to optimize at least one version of the JavaScript routines in a way that they come close to the performance of the WebAssembly based library. In Edge the original version is three times, the alternative two times slower. In Safari both take about twice the time than Simplify.wasm. On the other hand with preprocessing enabled there is often one JavaScript version that surpasses the Simplify.wasm performance. In Edge and Safari its even both JavaScript versions that perform faster at higher tolerance values.
+
+This shows that it is not always ideal to replace a library with a WebAssembly based approach. The cost of the overhead might exceed the performance gain when the execution time is low. In section \ref{ch:discussion-wasm-insights} it is pointed out, that the pure execution time of the simplification algorithm is fastest with WebAssembly. When preparing the geodata beforehand, for example by serializing it in a binary representation, one could immediately call the bytecode. This poses further effort regarding memory management to the web developer. One has to weigh up the complexity overhead to the performance benefit when considering such approaches.
 
 \subsection{Analysis of Turf.js implementation}
-\todo[inline]{When is turf.js faster}
+
+In this section the method used by Turf.js is evaluated. As seen when using the Chrome or Edge browser, the original library is the slower JavaScript method for simplification. There the data transformation is absolutely unfavorable. In Safari, where the JavaScript versions perform equally, the overhead will still lead to worse run times.  Lastly the Firefox browser will be examined. The results from chapter \ref{ch:case4} show that there are indeed cases where the method prevails. These are the ones where the execution time is large enough to justify the overhead. Namely when high quality is enabled or low tolerance values when high quality is disabled. 
+
+Those conclusions are similar to the Simplify.wasm results, where overhead costs also played a role. Here however one has to bear in mind that it is only one browser that is affected by a performance gain in certain circumstances. In the three other browsers the method is definitely disadvantageous.
 
 \subsection{Mobile device analysis}
+
+Here the results from the mobile device are discussed. It stands out that the two browsers show identical results. This is due to Apple Inc.'s security guidelines concerning the iOS App Store. It is specifically restricted for web browsers to use another engine than WebKit \parencite[see][section 2.5.6]{apple2019appstore}. Because of this, Firefox for iOS cannot use the Gecko engine developed by Mozilla. This explains why the two browsers perform equally. 
+
+The results from the two browsers lead to similar conclusions as the benchmarks of Safari under macOS did. Simplify.wasm is always fastest in high quality mode. With preprocessing, the JavaScript implementations outperform the WebAssembly based approach at higher tolerance ranges. Both JavaScript versions perform equally.
+
+The mobile device has lower hardware capabilities than the MacBook Pro tested in \ref{ch:case3}. That is why it is not surprising, that the runtimes are higher on the iPad. The concrete results are not directly comparable as different data sets were used. So the focus lies on the behavior of the algorithms. In the case of high quality enabled, the algorithms take about twice as long on the mobile device. This affects both, JavaScript and WebAssembly, equally. With high quality disabled, one can see that the JavaScript performance of the desktop device gets gradually better where the at the mobile device the performance stagnates.
\ No newline at end of file
diff --git a/thesis/chapters/06-conclusion.tex b/thesis/chapters/06-conclusion.tex
index 6b17519..ef6a988 100644
--- a/thesis/chapters/06-conclusion.tex
+++ b/thesis/chapters/06-conclusion.tex
@@ -1,6 +1,29 @@
 \section{Conclusion}
 
-\subsection{Enhancements}
-Enhancement: Line Smoothing as preprocessing step
+In this section a conclusion is drawn. First the results will be shortly summarized. The work done will be reflected and possible improvements are suggested. At last there will be an prospect about future work.  
+
+\subsection{Summary of the results}
+
+% Turf.js is not making sense
+
+% Is WebAssembly faster?
+
+% development effort
+
+%When designing wen apps, it has to be evaluated when performance justifies the risen complexity.
+
+\subsection{Improvements}
+
+\subsection{Future work}
+
+% Three dimensional data
+
+% Implement other algorithms
+
+% file size
+
+% swappable memory
+
+% compare with native speed
+
 
-\subsection{Future Work}
diff --git a/thesis/main.pdf b/thesis/main.pdf
index 251fc19..167c5e7 100644
Binary files a/thesis/main.pdf and b/thesis/main.pdf differ
diff --git a/thesis/main.tex b/thesis/main.tex
index 1f1a50d..c1aab5e 100644
--- a/thesis/main.tex
+++ b/thesis/main.tex
@@ -55,7 +55,8 @@
 \input{titlepage.tex}
 
 \section*{Abstract}
-Abstract goes here
+In this thesis the performance of polyline simplification in web browsers is observed. Based on the JavaScript library Simplify.js a WebAssembly solution is built to increase performance. The solutions implement the Douglas-Peucker polyline simplification algorithm with optional radial distance preprocessing. The format for polylines that Simplify.js expects differs from the representation used in major geodata formats. This discrepancy is obvious in another JavaScript library, Turf.js, where it is overcome by format transformations on each call. A slight variant of Simplify.js is proposed in this paper that can operate directly on the format used in GeoJSON and TopoJSON. The three approaches, Simplify.js, Simplify.js variant and Simplify.wasm are compared across different browsers by creating a web page, that gathers various benchmarking metrics. It is concluded that WebAssembly performance alone supersedes JavaScript performance. A drop-in replacement that includes memory management however bears overhead that can outweigh the performance gain. To fully utilize WebAssembly performance more effort regarding memory management is brought to web development. It is shown that the method used by Turf.js is unfavorable in most cases. Merely one browser shows a performance gain under special circumstances. In the other browsers the use of the Simplify.js variant is preferable.
+
 \newpage
 
 \tableofcontents
diff --git a/thesis/results-benchmark/ipad_ffox_simplify_vs_false.png b/thesis/results-benchmark/ipad_ffox_simplify_vs_false.png
index fc880dd..d35e9d2 100644
Binary files a/thesis/results-benchmark/ipad_ffox_simplify_vs_false.png and b/thesis/results-benchmark/ipad_ffox_simplify_vs_false.png differ