writing

thesis/chapters/02.02-Dataformats.tex

@@ -17,7 +17,7 @@ label=lst:geojson-example
 ]{../data/example-simple.geojson}
 
 
-\todo[inline]{Explain the nested array coordinates of polygons}
+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. All cases in this thesis will only deal with two-dimensional positions. 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. 
 

thesis/chapters/03.01-benchmark.tex

@@ -8,7 +8,7 @@ In this chapter I will explain the approach to improve the performance of a simp
 \label{sec:simplify.js}
 % Simplify.JS + turf
 
-Simplify.js calls itself a "tiny high-performance JavaScript polyline simplification library"\footnote{\path{https://mourner.github.io/simplify-js/}}. It was extracted from Leaflet, the "leading open-source JavaScript library for mobile-friendly interactive maps"\footnote{\path{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 while the Turf.js derivate @turf/simplify has 30,389. Turf.js maintains an unmodified fork of the library in its own repository.  \todo{leaflet downloads}
+Simplify.js calls itself a "tiny high-performance JavaScript polyline simplification library"\footnote{\path{https://mourner.giformthub.io/simplify-js/}}. It was extracted from Leaflet, the "leading open-source JavaScript library for mobile-friendly interactive maps"\footnote{\path{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 while the Turf.js derivate @turf/simplify has 30,389. Turf.js maintains an unmodified fork of the library in its own repository.  \todo{leaflet downloads}
 
 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. 
 
@@ -107,7 +107,6 @@ label=lst:wasm-util-load-result
 ]{../lib/wasm-util/coordinates.js}
 
 
-
 \subsubsection{The implementation of a web framework}
 
 The performance comparison of the two methods will be realized in a web page. It will be a built as a front-end web-application that allows the user to specify the input parameters of the benchmark. These parameters are: The polyline to simplify, a range of tolerances to use for simplification and if the so called high quality mode shall be used. By building this application it will be possible to test a variety of use cases on multiple devices. Also the behavior of the algorithms can be researched under different preconditions. In the scope of this thesis a few cases will be investigated. The application structure will now be introduced.
@@ -117,6 +116,7 @@ The performance comparison of the two methods will be realized in a web page. It
 The dynamic aspects of the web page will be built in JavaScript to make it run in the browser. 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 framework}
+\label{ch:benchmark-framework}
 
 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. 
 
@@ -148,4 +148,21 @@ For running multiple benchmarks the class \texttt{BenchmarkSuite} was created. I
 
 \subsubsection{The user interface}
 
-\todo[inline]{Explain user interface}
+\begin{figure}[htbp]
+	\centering
+	\fbox{\includegraphics[width=.9\linewidth]{images/benchmark-ui.png}}
+	\caption{The user interface for benchmarking application. (not final)}
+	\label{fig:integration-ui}
+\end{figure}
+
+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.
+
+\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-framework}. 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{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.
+
+\paragraph{Chart}
+
+
+\subsubsection{The test data}
+\label{ch:benchmark-data}

thesis/chapters/03.02-integration.tex

@@ -69,7 +69,7 @@ After explaining the state model the User Interface (UI) shall be explained. The
 \begin{figure}[htb]
 	\centering
 	\fbox{\includegraphics[width=\linewidth]{images/integration-ui.jpg}}
-	\caption{The user interface for the algorithm comparison. (Placeholder!)}
+	\caption{The user interface for the algorithm comparison. (not final)}
 	\label{fig:integration-ui}
 \end{figure}
 

thesis/main.lof

@@ -1,3 +1,4 @@
 \contentsline {figure}{\numberline {1}{\ignorespaces UML diagram of the benchmarking application}}{17}{figure.1}% 
-\contentsline {figure}{\numberline {2}{\ignorespaces The state model of the application}}{22}{figure.2}% 
-\contentsline {figure}{\numberline {3}{\ignorespaces The user interface for the algorithm comparison. (Placeholder!)}}{23}{figure.3}% 
+\contentsline {figure}{\numberline {2}{\ignorespaces The user interface for benchmarking application. (not final)}}{19}{figure.2}% 
+\contentsline {figure}{\numberline {3}{\ignorespaces The state model of the application}}{23}{figure.3}% 
+\contentsline {figure}{\numberline {4}{\ignorespaces The user interface for the algorithm comparison. (not final)}}{25}{figure.4}%