Linköping University | Department of Computer and Information Science Bachelor’s thesis | Bachelor’s Programme in Programming

Spring term 2020 | LIU-IDA/LITH-EX-G--20/053—SE

Visualization of Geographic Data in ASP.NET

Anton Sköld

Tutor, Jalal Maleki Examinator, Rita Kovordanyi

Copyright The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Anton Sköld

1

ABSTRACT

This paper explores the development and implementation of an in-browser map with the purpose of visualizing large sets of geographic data. The map is implemented into a pre-existing search engine of geographic data.

Two mapping frameworks are compared in terms of performance, ease-of-use, and functionality. These frameworks are Leaflet and Google Maps. This paper also explores which issues may arise when implementing these mapping frameworks within a pre-existing ASP.NET project.

These aspects were evaluated through performance tests, documentation reading, and compiling experiences gained through implementing the map within the search engine.

The experiments show that both Leaflet and Google Maps are viable frameworks to use when developing in-browser maps, but also that they have their pros and cons. Google Maps sports a generally higher level of performance, and a larger set of paid available services. Leaflet is a free, open-source alternative with a large plugin repository, but relies on third-party services for features such as geocoding.

1 INTRODUCTION

Maps are an integral part of modern life, and the internet has been an important tool for the distribution of our maps [16]. In July 2018, 77% of smartphone owners were active users of navigation services, and of those, 70% used Google Maps, the most popular online mapping app [1].

Many online services use maps as data visualization tools [17]. Maps can display many things, including driving instructions, weather forecasts, and graphical overviews of data.

The purpose of this paper is to explore the development of an in-browser map, within the ASP.NET web framework. The primary contribution of this paper is an evaluation of two popular mapping frameworks, Google Maps and Leaflet, comparing them based on criteria outlined at the end of this section. Leaflet.js will be used as the API for showing OpenStreetMap data. Google Maps provides its own API.

ASP.NET is the web framework solution found within the .NET framework., which is primarily run on Windows platforms. The language used to code an ASP.NET project is C#, and when looking at language usage statistics, you can find that C# represents about 2.2% of the total code used on GitHub. This is quite small compared to the most used web programming language JavaScript, which represents 15% of all code [2].

Seeing as ASP.NET is a less common choice for developing web applications, the available options for mapping services may not be as well supported as in the case of a JavaScript-based project. The secondary contribution of this paper is to find out which issues may arise when using a JavaScript-based map within an ASP.NET / C# based project.

Google Maps and Leaflet are two popular mapping services that can be used to implement such maps. These are evaluated and

compared based on some criteria. Thus, the research questions of this paper are as follows:

RQ1: How do Google Maps and Leaflet compare in terms of:

• Performance

• Ease of use

• Functionality

RQ2: Which issues may arise when implementing JavaScript-based maps in ASP.NET-projects?

The performance criterion measures the time it takes for maps to load, the time it takes to place points / lines / polygons onto the map, and how the maps perform in terms of frame rate while rendering large data sets.

The ease of use criterion is evaluated through factors such as how easy it is to start using each of the mapping frameworks. This criterion compares activities such as how straight-forward it is to register your API-keys, and how easy it is to implement certain features on your map. This criterion can be quite subjective.

The functionality criterion summarizes features of one mapping framework that the other may lack. While implementing this in-browser map, noteworthy features of each mapping framework are recorded. A dedicated documentation reading session will also be held to try to find additional noteworthy features of each framework.

2 BACKGROUND

The web-based map will be implemented as part of an existing project, hence the ASP.NET limitation. This project is a search engine for geographic metadata and is owned by the land surveying unit in Motala municipality.

This search engine allows you to search for different layers. A layer is a set of geographic data, such as all bodies of water, sewage piping, electricity grids, or all forested areas within a region. These layers contain geometric data which determine the coordinates of these regions, and additional metadata concerning the geometry (such as property names, city codes, or how accurate the geometry is).

What the search engine lacks, is a visual preview of the layers on the page for search results. This preview will be implemented through the previously mentioned in-browser map.

3 THEORY

In this section a brief overview of .NET and ASP.NET is given. The section explains how they relate, and how a project built in ASP.NET can be structured. These technologies are used within the search engine project.

The mapping services studied in this paper are also brought up and some background is given on each of them. These mapping services are used to answer RQ1 when evaluating the criteria for each of them.

To wrap up this section, the proprietary geographic layers the pre-existing search engine uses are explained in depth, including how they are used and what types of information a layer can contain.

3.1 .NET

.NET is a software development platform developed by Microsoft. Using .NET, you can build many different types of applications in several different programming languages. The primary languages used are C#, F#, and Visual Basic [3]. When building applications within .NET, your applications can run wherever .NET is installed. It is comparable to Oracle’s Java Virtual Machine (JVM) technology.

.NET has three primary implementations, .NET Core, .NET Framework, and Xamarin / Mono. These implementations target different platforms and have different use cases. .NET Core is cross-platform for Windows, Linux, and macOS. .NET Framework is primarily for Windows. Xamarin/Mono is primarily for the major mobile platforms [4].

3.2 ASP.NET

If you want to develop web applications within the .NET framework, ASP.NET is the natural choice. ASP.NET extends the regular capabilities of .NET with built-in libraries and functions to make developing web applications quicker and easier [5].

So, how is an ASP.NET project structured? There are two primary types of files which create the project. These are .aspx-files and .aspx.cs-files.

.aspx-files are somewhat like regular HTML-files. They structure the website using tags which represent the website elements used. These files can also execute server-side code, similarly to how the <script>-tag works in a JavaScript-based project. In addition to the regular HTML-tags, ASP.NET adds a set of controls that you can use on your website. These include forms, buttons, labels, timers, and more. These controls are all implemented as C# classes, and thus you can act on them like you could any other C# object.

.aspx.cs-files are the so-called “code-behind” files. These files contain all functionality of your website and are written in pure C#. Variables and functions which you create in these files are available to the structural .aspx-file.

3.3 Google Maps

In 2005, Google released Google Maps. During the following months they added multiple features to the service and made it available for a multitude of different platforms. In June that year they released the Google Maps API, a way for developers to implement their own web-based maps [6]. In 2016, the Google Maps API was used by 1 million websites and services, reaching a total of 1 billion active users.

The API can be implemented in several ways depending on your platform and needs [7]. The most relevant one for this paper is the JavaScript API. To use this implementation, you need a Google Maps API key to be allowed access. You import the API

within an HTML <script>-tag or a JavaScript file, and then you can initialize your google.maps.Map object [8].

3.4 OpenStreetMap and Leaflet

OpenStreetMap is an open collaborative world-wide effort of creating and maintaining a reliable source of geographic information [9, 14]. All information is free to use granted you credit OpenStreetMap as being the source of the data.

Contrary to the Google Maps API, OpenStreetMap does not have a single must-use framework implementation. It can be used with whichever framework supports OpenStreetMap as a source of geographic information. For this paper, Leaflet is the chosen implementation.

3.5 Geographic layers and their structure

Within our database of geographic data, each geographic layer is represented as a regular SQL table. A row within these tables represents a shape within the layer.

The primary information stored within these shapes is the geometric information which describes how the shape looks and where it is. This geometric information is stored as an SQL geometry datatype.

The three primary shapes used in our database are points, lines, and polygons. In the geometry datatype, these shapes are called “POINT”, “LINESTRING”, and “POLYGON” respectively [15]. When reading these shapes from the database in text form, these are examples of what shapes can look like.

• POINT(58 15)

• LINESTRING(58 15, 58 15.4, 56 12.3)

• POLYGON((10 1, 10 9, 4 9, 10 1),(9 4, 9 8, 6 8, 9 4))

A point is simple, it contains a single coordinate (latitude / longitude) that defines where the point is placed.

A linestring contains two or more coordinates, representing multiple points connected by a line.

A polygon looks much like a linestring, but the line connects back into itself to form a 2D area. Contrary to lines and linestrings, polygons can contain more than one set of coordinates. The first set of coordinates represents the outer bounds of the polygon, and any following sets define holes in the outer shape.

3.6 Method theory

In RQ1 three different metrics are proposed which will be used to evaluate how good each mapping service is. These are performance, ease of use, and functionality.

Performance will be measured by the time it takes to perform a certain task on the map. These tasks include loading the map, placing geometry onto the map, and how the maps perform while rendering large datasets.

3

Lee et al. measured the performance of Android applications using the built-in Java method nanoTime() [10]. This method is precise to the nanosecond assuming the underlying hardware supports it and can be a suitable candidate for measuring time in Java-projects. The equivalent time-measuring tool in C# is the Stopwatch class, part of the System.Diagnostics namespace. This class has a read-only field called Frequency, which tells us how precise the time measurements are. This field is constant and depends on the hardware used. Thus, the frequency of time samples is somewhat uncontrollable and will be assumed to be negligible throughout this paper.

To measure time in JavaScript, the performance.now() function exists as part of the standard library. This function returns the system time elapsed since the webpage was loaded. If we subtract two points in time from each other, we can easily find the time required for a certain code block to execute.

The ease-of-use criterion will be evaluated based on how straight-forward it is to implement each mapping framework into the search engine, and how easy it is to perform certain actions on the maps. One factor that can help tell how easy a framework is to use, is how many lines of code are needed to perform the tasks.

One might think that the formatting of the code matters when measuring the amount of lines (i.e. spacing, braces on new lines, etc.). However, J. Rosenberg showed in his paper that it is a misconception and that SLOC (source lines of code) is an acceptable metric no matter the formatting [11]. Even if code formatting mattered, the experiments conducted in this paper are written by a single developer and the formatting should thus be self-consistent.

To be able to answer RQ2, the day-to-day experiences of development need to be recorded. This will be done through a diary, consisting of a set of questions which will be answered daily.

J Rowley wrote an article which brings up important aspects of designing questionnaires for scientific purposes [12]. The obvious first step is that questions should be designed to provide data related to the objective, we will thus design the questions to focus on issues encountered during development. The questions will be open questions, as opposed to closed, because the opinions and experiences of the developer should be brought forward rather than numeric or yes / no answers. The questions should be phrased clearly and concisely, without being leading.

4 METHOD

This section describes the methods used and the experiments that were ran to evaluate the two different mapping services, and how the results of those experiments can be used to answer both proposed research questions.

4.1 The testing setup used

4.1.1 Hardware Processor: Intel Core i7 7700 RAM: 16GB Corsair Vengeance LPX DDR4 3000MHz Graphics: NVIDIA GeForce GTX 1070 Storage: Kingston V300 120GB SSD

Monitor: 144 Hz ASUS VG248QE Network: 100 / 100 Mbit fiber connection located in Sweden.

4.1.2 Software Web browser: Google Chrome 81.0.4004.129 Operating system: Windows 10, version 1909 Google Maps JavaScript API version 3.40 Leaflet v1.6.0

4.2 The workloads

To be able to compare the mapping services, and thus to answer RQ1, we need to define a set of tasks to be performed by the mapping services.

These tasks should be common operations one would expect a mapping service to perform. Some of these tasks are performed only on the client-side, and thus are not dependent on any network requests.

The tasks were implemented with as few lines of code as possible, and official documentation and tutorials were followed to implement them. Of course, the mapping API used may influence how many lines of code are needed to perform a certain task. The number of lines of code required are also considered to evaluate the ease-of-use criterion of RQ1.

Each task was performed five times, and the average time to perform the tasks along with the lines of code required is recorded.

4.2.1 Loading the map

In order to use a map, the geographic information of the map needs to load into the web browser. For this workload, official documentation and tutorials are followed to get a bare-minimum map implementation running in our browser. The code execution time required for the map to load was then measured.

Two additional tests were run which instead of measuring code execution time, recorded video of the loading of each map, and measured the video frames it took for the maps to load. The motivation for these additional tests were that perhaps code execution time is irrelevant to how quickly the maps load, as the loading primarily consists of downloading map tiles (images) to the client.

The first of these tests loaded the map at a fixed position, which made the background tiles cached, speeding up the load times of each framework. The second test randomized the initial position of the map, which makes caching a non-factor.

The tutorial used for Google Maps is available here (Accessed 2020-05-25): https://developers.google.com/maps/documentation/javascript/tutorial?hl=sv

For the OpenStreetMap / Leaflet implementation, this tutorial was followed (Accessed 2020-05-25): https://leafletjs.com/examples/quick-start/.

Both tutorials describe how to import the mapping frameworks, and how to create a basic map object. Leaflets tutorial also describes how to draw simple geometry.

4.2.2 Placing simple geometry

The most important feature for our search engine implementation is the placement of geometric shapes onto the map. These shapes include points, lines, and polygons.

A sample shape is created for each type of shape, which can be input into the mapping framework, and the time it takes for the framework to render the shape is recorded.

4.2.3 Placing bulk geometry

To properly evaluate the real-life performance of the mapping services, this test implements both mapping services into our pre-existing search engine. The proprietary geographic database of is used to populate the map with geographic data. Only the time it takes to populate the map is tracked, and not the time it takes to retrieve items from the database.

The test case placing bulk points places 3683 points, the test case placing lines places 2226 lines, and the polygon test places 3683 polygons.

4.2.4 Evaluating performance under heavy load

For the search engine, it is important that the maps perform and handle well while rendering large amounts of geographic data. This is measured by loading some of the largest layers in our dataset and measuring the frames per second (FPS) of the maps while having these layers rendered. A monitor with 144 Hz refresh rate is used for this test, and thus the best possible framerate in-browser for this setup is 144 frames per second.

The largest layer of points in our dataset contains 33000 points, the largest layer of lines contains 2226 lines, and the largest layer of polygons contain 33337 polygons.

When rendering 33000 points within Leaflet, it froze and did not give proper results. To gain more insightful data of how performance degrades with marker count, the scale of this test was reduced. Initially, no points are rendered, and gradually the marker count increases to 3000. At 3000 markers Leaflet became near-unusable, so it was chosen as a stopping point. For each of these steps, the framerate was recorded, and the results were plotted in a graph.

Two types of user actions were performed on the maps while having the layers rendered. These are panning the map and zooming in and out repeatedly. The framerate was recorded for each of these actions.

Google Chrome’s FPS meter was used to measure the framerate. However, the tool does not provide an average framerate value over time. This makes it necessary to manually observe the framerate and approximate the point it fluctuates around, which could incur some bias.

4.2.5 Evaluating ease of use

This criterion was evaluated by recording noteworthy aspects related to how easy each framework was to use. The process of registration and initializing of the map frameworks, the out-of-the-box usability, and different code quirks became the determining factors of how easy each framework was to use.

4.2.6 Evaluating functionality

This task is explored simultaneously as the other tasks by reading the documentation of both mapping services while implementing the other tasks, trying to find features of one mapping service that the other may lack. The results of this task are difficult to predict as it was intentionally specified as a bit of a wildcard.

After the other tasks are fully implemented and some documentation indirectly has been explored, some time was allotted specifically to reading documentation for the purposes of this criterion. One uninterrupted hour was spent on reading each of the documentations, noting interesting features along the way in a spreadsheet.

This criterion could be subject to a little bit of bias, as the documentation was only scoured by a single person, a single time. Also, how the documentation was presented and structured may have been a factor in how much information was found.

4.3 Evaluation of the project

To answer RQ2, a discussion of the search engine project was held after the work was done. In this qualitative discussion interesting experiences and learnings from implementing the project are brought up. To collect opinions and experiences for this discussion, a developer diary containing a set of questions was answered each day of work.

The characteristics of the questions posed in the developer diary are discussed in Section 3.6. The questions that were answered each day are as follows:

• What have you been working on for the day?

• Which issues have you encountered?

• What can be done to solve the issues?

• What other noteworthy things have you experienced?

5 RESULTS

5.1 RQ1 – Evaluating performance

5.1.1 Loading the map

For this test, a bare-minimum implementation of each mapping framework was built, and then the time to load the maps within each framework was measured.

The first measurement was simply how long it took the code responsible for loading the map to execute. These lines of code are displayed below.

5

myMap = L.map("mapid", {preferCanvas: false}) .setView([58, 14], 14); L.tileLayer('https://api.mapbox.com/styles/v1/{id}/tiles/{z}/{x}/{y}?ac-cess_token={accessToken}', { maxZoom: 18, id: 'mapbox/streets-v11', tileSize: 512, zoomOffset: -1, accessToken: 'Hidden' }).addTo(myMap);

Listing 1 – Leaflet map loading

googleMap = new google.maps.Map(document.getElementById('googlemap'), { center: { lat: 58, lng: 14}, zoom: 14 });

Listing 2 – Google Maps map loading

These lines of code were executed five times, and the average result was computed. Table 1 contains the results of these tests.

Leaflet Google Maps Avg. time (ms) 4.86 4.00 Std. deviation 1.017 0.613

Table 1 – Loading the maps, code execution time.

Below in Table 2 and 3 are the results of the tests which recorded video of the maps loading and measured how many frames it took for each map to load. The results in Table 2 are affected by caching as the maps loaded in fixed positions, and Table 3 are not affected by caching, as the position was randomized.

Leaflet Google Maps Avg. frames 3.2 9.2 Avg. time (ms) 53.33 153.33 Std. dev (frames) 0.4 0.748

Table 2 – Loading the maps with caching.

Leaflet Google Maps Avg. frames 30 17.4 Avg. time (ms) 500 290 Std. dev (frames) 5.72 2.42

Table 3 – Loading the maps without caching.

5.1.2 Placing simple geometry

For these tests, three simple shapes were constructed. A point (marker), a line, and a polygon. See below for an example of how a marker can be created. Lines and polygons are created similarly, except that the mapping services accept multiple coordinates instead of one. The created polyline included 25 coordinates, and the polygon included 5 coordinates.

var marker = L.marker([58, 15]).addTo(myMap);

Listing 3 – Creating Leaflet marker

var marker = new google.maps.Marker({ position: { lat: 58, lng: 15 }, map: googleMap, });

Listing 4 – Creating Google Maps marker

These shapes were then rendered with each of the mapping frameworks, and the time it took for the code to execute was recorded. The average times are in Table 4.

Leaflet Google Maps Point 1.29 1.00 Line 1.46 2.00 Polygon 0.50 0.38 Std. dev (Point) 0.40 0.32 Std. dev (Line) 0.57 0.43 Std. dev (Polygon) 0.21 0.12

Table 4 – Placing single shapes (ms)

5.1.3 Placing bulk geometry

This test is like the simple geometry test, but on a larger scale. Geographic layers, as described in Section 3.5, are loaded from our geographic database into the browser’s memory, and then the layers are rendered onto each mapping framework. Only the time it takes for rendering is recorded, and not the database interactions. See below for how Leaflet iterates through and renders each shape, Google Maps iterates similarly.

for (var i = 0; i < shapes.length; i++) { var type = shapes[i].type; // For each subshape (in case of polygons) for (var j = 0; j < shapes[i].shapes.length; j++) { if (type == "POINT") { var marker = L.marker(shapes[i].shapes[j][0]).addTo(myMap); } else if (type == "LINESTRING") { var polyline = L.polyline(shapes[i].shapes[j]).addTo(myMap); } else if (type == "POLYGON") { var polygon = L.polygon(shapes[i].shapes[j]).addTo(myMap); } } }

Listing 5 – Leaflet renders a layer

Each layer can consist of either points, lines, or polygons. The rendered layer of points consisted of 3683 points, the line layer had 2226 lines, and the polygon layer had 3683 polygons. Table 5 contains the average render times for each layer type and mapping framework.

Leaflet Google Maps 3683 points 546.68 71.84 2226 lines 91.00 97.75 3683 polygons 185.14 139.57 Std. dev (points) 7.26 6.70 Std. dev (lines) 2.43 21.93 Std. dev (polygons) 7.16 17.92

Table 5 – Placing bulk shapes (ms)

5.1.4 Performance under heavy load

For these tests, the largest geographic datasets we had available were used. These datasets contain 33000 points, 2226 lines, and 33337 polygons, respectively.

First, the dataset containing points was rendered. As seen in the table below, Leaflet could not handle the pressure and thus did not give any proper framerate values, as seen in Table 6.

Leaflet Google Maps Avg. FPS (panning) NaN 20 Avg. FPS (zooming) NaN 7

Table 6 – Placing 33000 markers

As described in section 4.2.4, the scope of the marker rendering test was reduced to gain more insightful data. These results are presented below in Graph 1.

Graph 1 – Framerate by marker count

Next, a large set of lines and polygons were rendered, and the average FPS was recorded. These results are presented below in Table 7.

Leaflet Google Maps 2226 lines (pan) 144 144 2226 lines (zoom) 80 110 33337 polygons (pan) 60 140 33337 polygons (zoom) 1 4

Table 7 – Placing bulk shapes (Avg. FPS)

5.2 RQ1 – Evaluating ease of use

5.2.1 Process of initializing the map & Pricing

Leaflet does not require any direct registration to be able to use the framework. You import the framework like you would any other framework, within a <script> HTML tag. A stylesheet is also needed, which you import through a <link> tag. It is also possible to locally download Leaflet which removes the need for an internet connection when loading the API.

However, Leaflet does not provide its own tile layer i.e. the map background. The tile provider used in this paper is MapBox. MapBox required a simple free registration to gain an access token. This token is then used with the tile providers’ URL to make Leaflet have access to the data.

Leaflet is completely free of charge if you credit OpenStreetMap as the providers of map data. Your tile provider may require crediting as well.

Google Maps requires registration on the Google Cloud Platform before being able to be used, which includes registering a payment method if any monetary charges are to occur. After registration you import the Google Maps JavaScript API within a <script> tag, which includes your API token. As Google Maps

provides its own map data and is entirely self-contained, this is the only registration necessary.

The Google Maps JavaScript API does have a cost associated with using it, however at the time of writing you get 200$ worth of free use per month. This credit can support loading the map 28000 times in one month.

5.2.2 Out-of-the-box usability

Google Maps is very self-contained and provides its own map data and map tiles. Leaflet requires you to register at a tile provider for access to map tiles but therefore does give you the option of which tile provider to use. You can even host map tiles locally if you are in possession of such data.

Both mapping frameworks were straight-forward to implement within the search engine, and due to the syntax being alike, the frameworks became quite hot-swappable.

The main difference between the frameworks for the purposes of this project was the performance factor. As shown in Section 5.1.4 Leaflet does not like rendering thousands of markers at once. To make Leaflet viable for this project, this issue needed to be fixed. In Leaflet, each marker is rendered within the HTML DOM tree. This is likely what caused the performance loss when thousands of markers were placed.

One solution to Leaflets marker issue is to force Leaflet into rendering on an HTML canvas instead, by setting the preferCanvas attribute to True when creating the Leaflet map. When rendering to a canvas, you also need to use the CircleMarker type instead of a regular Marker. This CircleMarker type does by default look slightly different to a regular Marker, being a circle instead of a pin.

5.2.3 Code quirks

Leaflet and Google Maps differ slightly in which formats they accept coordinates. Leaflet has four different ways of expressing a coordinate. These four formats are equivalent and shown in Listing 6.

[58, 15] {lon: 15, lat: 58} {lat: 58, lng: 15} L.latLng(58, 15)

Listing 6 – Leaflet coordinate formats

Google maps has three ways of expressing coordinates. These are shown in Listing 7 and are both equivalent.

new google.maps.LatLng(58, 15) {lat: 58, lng: 15} new google.maps.LatLng({lat: 58, lng: 15})

Listing 7 – Google Maps coordinate formats

Within the search engine project described in this paper, shapes were read from our geographic database. After reading, the coordinates were in array format similarly to the first format shown in Listing 6. Before being able to implement Google Maps, the coordinates had to be iterated through and translated into the dictionary format described on the second line of Listing 7. In

7

this regard, Leaflet is more flexible with how coordinates are expressed.

Another code quirk found while implementing the maps, is how both frameworks handle popups. Popups are boxes of information shown when you hover over or click shapes and markers on the map.

Within Leaflet, each created shape inherits a bindPopup function. This function accepts a string of text to be displayed, as well as a dictionary of style options for the textbox. When called, the function adds the popup you defined to the shape. An example of creating a Leaflet popup is displayed in Listing 8.

var marker = L.circleMarker([58, 15], { color: "#FF0000" }).addTo(myMap); marker.bindPopup("This is popup content", { maxHeight: 100 });

Listing 8 – Leaflet popup creation.

For Google maps to achieve a similar result to the code in Listing 8, the equivalent code is shown below in Listing 9.

var infowindow = new google.maps.InfoWindow({ content: "Info window content" }); var marker = new google.maps.Marker({ position: {lat: 58, lng: 15}, map: map }); marker.addListener('click', function () { infowindow.open(map, marker); });

Listing 9 – Google Maps popup creation.

However, the code shown in Listing 9 has one major issue if you are executing it within a loop. Every marker gets an on-click event listener attached. This listener, when triggered, opens the infowindow variable. If executed in a loop, for every marker you place, the infowindow variable gets overwritten and only the content of the latest marker popup is stored within it. Because of this, every marker you create in a loop using this code all get a popup, but the content of the popup is shared between all markers.

To solve this within Google Maps, you need to change the content of the infowindow dynamically, depending on which marker it is displayed on. One solution to this is displayed below in Listing 10.

var infowindow = new google.maps.InfoWindow(); var marker = new google.maps.Marker({ position: {lat: 58, lng: 15}, map: map }); marker.content = "Info window content" marker.addListener('click', function () { infowindow.setContent(this.content); infowindow.open(map, marker); });

Listing 10 – Google Maps proper popup creation.

The solution shown in Listing 10 stores the content of the infowindow within the marker object instead of the infowindow object. When the click event listener triggers, the content of the infowindow is dynamically set to the content stored in the marker object.

For popup behavior within this project, where shapes were created within a loop, Leaflet had a more straight-forward way of implementing them. However, because Google Maps uses an event system, it has greater variety in which types of events can open the infowindow, and what code you want to execute within each event.

5.3 RQ1 – Evaluating functionality

This evaluation criterion was explored by taking note of interesting features of each mapping framework during development of the maps, and by a dedicated documentation reading session. The most interesting differences between the frameworks are presented here.

5.3.1 Leaflet

Leaflet does not provide its own map tiles. This means you have a choice of which tile provider you want to use. It is also possible to host tiles locally and be your own provider.

This framework is also completely free and open source. Leaflet also has a large library of third-party plugins that you can use to customize how Leaflet acts.

5.3.2 Google Maps

Google Maps as a service is self-contained and closed source. This leads to not have as much customizability compared to the open source Leaflet.

However, the (paid) functionality is quite vast in range. To start, the framework provides its own tile data, which means you do not need to involve third-party tile providers to paint your map background.

For the purposes of drawing shapes onto the maps, Leaflet and Google Maps mostly have the same features. Google Maps does support drawing heatmaps onto your map, which Leaflet does not support without the help of a plugin.

When registering for a Google Maps JavaScript API access token, you also get access to a heap of other services apart from the dynamic maps. These services have different pricing compared to simply loading a map.

These optional services include functionality such as geocoding – to translate a physical address into a latitude / longitude coordinate, street view, an overlay of bicycling / commuting routes, live traffic information, directions, and displaying map elevation.

5.4 RQ2 – Issues encountered using JavaScript within ASP.NET

This section describes some of the issues that were encountered during development of the search engine, what causes the issues, and how one can work around them.

5.4.1 Accessing public variables from JavaScript

When adding JavaScript code in the .aspx-file within an ASP.NET project, it is possible for the JavaScript side of the code to access server-side (C#) variables. An example of this is shown

below in Listing 11, where the public string “helloWorld” is fetched from the server-side class MyClass.

var helloWorld = '<%=MyClass.helloWorld%>'; alert(helloWorld);

Listing 11 – JavaScript accesses a C# variable.

Early on in development, the idea was for the server to read the geographic layers from the database, parse them into a server-side list of shapes, and let the JavaScript code iterate through this list to render the layers onto the map.

When fetching primitive datatypes such as strings, integers, and booleans, the syntax used in Listing 11 is very convenient and simple to use. When trying to do more complex things such as iterating through a public list, it is not as straight-forward.

If you were to have some loop in JavaScript, and within the loop you try to index the public server-side list, this would not immediately work. In this scenario, the iterator variable is a JavaScript integer, and the syntax in Listing 11 does not support using this variable for indexing the public list. Thus, instead of working directly on the server-side list, we need to transfer the data structure to the JavaScript side.

To transfer a complex data structure using the syntax in Listing 11, one needs to translate the complex structure into some primitive variable. The solution chosen was to serialize the data structure before transferring it. When serializing a data structure, it gets converted into a string. This string can then be deserialized back into the original data structure with no data loss. The serialization method used was JSON (JavaScript Object Notation), as it is a format which JavaScript can handle natively.

5.4.2 ASP.NET refresh / postback behavior

Another problem encountered during development is ASP.NETs tendency to refresh the webpage after nearly every button click / website interaction. For instance, when typing something into a search bar on an ASP.NET website and hitting the search button, the search form is submitted to the server, and then a search result page is built and sent back to the client. This leads to a postback refresh happening.

On most websites, this postback behavior is expected and completely normal. Within the search engine, this behavior caused a somewhat major issue: If the website refreshed, everything previously drawn onto the map is reset. This made the map only able to preview a single geographic layer at once, because when clicking the preview button for the other layers, the website would refresh, and the previous layer would be erased from the map.

A few solutions to this were considered, but unfortunately within the scope of this paper none were considered viable.

The first solution involved saving the previously displayed layers to the browsers localstorage or sessionstorage, and then all saved layers are presented when the website refreshes. This proved unviable as localstorage and sessionstorage have quite restrictive size limits (~5 MB each). Geographic layers can be many megabytes in size, and this size limit would make the feature at best able to render 2-3 layers at a time, depending on which layers you are rendering.

Another solution would be for the server to keep track of which layers are rendered for each session, storing the rendered layers in memory, and sending them back over each page refresh. This solution would incur substantial load times when the page refreshes, and the server could become a massive memory hog if each session is handled improperly.

Like the previous solution, the server could keep track of the names of each layer being rendered to a session, and upon refresh fetching all those layers from the database and sending them to the client. This would alleviate the memory-hogging of the previous solution but increase load times even further due to the extra database requests and the overhead associated with them.

The extreme load times of the two previous solutions are due to needing to send all previous layers when rendering a new one. Imagine previewing five layers, which means at least five button clicks and five page refreshes. On the first refresh a single layer is sent, on the second refresh two layers are sent, on the third refresh three layers are sent, et cetera. In total, 1+2+3+4+5 = 15 layers would need to be transferred when rendering 5 layers, and it scales even worse the more layers you preview.

The most viable solution to rendering multiple layers would be to dynamically update the website data without needing a postback refresh. AJAX (Asynchronous JavaScript and XML) is a perfect solution for this. If this solution were implemented, the client could dynamically receive additional layers to be rendered, without the need for a page refresh.

Implementing this dynamic AJAX loading of layers, in the case of this search engine, would involve essentially rebuilding the project from the ground up. For the scope of this paper, this solution was considered unviable.

6 DISCUSSION

This section discusses the research questions while considering the found results. Critiques of the chosen methods and potential points of improvements are also discussed.

While running all the tests described in this paper, only the Google Chrome browser was used, and all tests were executed on a single machine. It is very possible that choice of browser and differences in computing hardware can have impacts on the test results.

6.1 RQ1 – Performance

6.1.1 Map loading

The first test that was ran was loading the maps and measuring the time it took for them to load. The initial measurement was how long it took for the line of code that was responsible for loading the map to execute. The results were in the range of a few milliseconds, which sounded unreasonable as multiple network requests and picture downloads would have had to happen within that time. It was thus concluded that the primary factor that caused a map to take longer to load was how fast the map tiles loaded in, and that this loading of tiles did not reflect in code execution time.

9

Two more tests were then performed regarding loading the maps, where video was recorded of the maps loading, and the time it took for the maps to load were measured in amount of video frames. It was observed that caching had a major impact on the load times, and thus one of the tests loaded the maps in fixed locations, and the other test randomized the initial locations to make sure caching did not occur.

One interesting observation was that with caching, Google Maps took longer to render the map. This is likely due to Google Maps having a fade-in animation which hides most of the tile loading “pop”. In the no-caching test, even with Google Maps’ fade-in animation, Google Maps still achieved nearly half the load time of Leaflet. Thus, it seems that the primary factor which determines map loading times, is the choice of tile provider. Within this paper, the only tested Leaflet tile provider was MapBox. Other tile providers could see faster load times.

6.1.1.1 Map loading – Method discussion

Instead of measuring time through recording a video, a more suitable way of measuring could be to detect when all map tiles have finished downloading and recording that time more precisely. Network monitoring tools such as Wireshark, or some callback function within the frameworks could be used for this purpose. Doing it this way would eliminate the overhead caused by the fade-in animation of each framework. Even with recording video, one could see that Google Maps serves tiles faster to the client than MapBox.

6.1.2 Placing geometry

Two types of geometry-placing tests were conducted. The first test placed a single shape of each shape type, and the second test placed many of those shapes. The code execution time for placing the shapes were recorded.

When placing individual shapes, the code execution time fluctuated quite heavily between test cases, as seen by the standard deviation. To somewhat mitigate this, each test was executed five times and the results were averaged. Even with this averaging, these results may very well be unreliable, the individual test cases seemed mostly determined by luck-of-the-draw.

The test where many shapes were rendered can be a much better indicator of the performance of each framework, as with a much larger sample size the differences between the frameworks become more apparent. Again, the test was executed five times with averaged results. Google Maps was quite a lot faster than Leaflet when placing markers and polygons, but mysteriously a little slower when placing lines. When placing markers, Google Maps achieved almost eight times faster execution speed.

6.1.2.1 Placing geometry – Method discussion

There exists a chance that when rendering a large set of geometry, the browser gradually slows down while rendering, as a single shape was drawn at a time. If Leaflet needed to render 1500 markers while already having 1500 markers rendered, it could be possible that the final 1500 markers get slower code execution rates. If this were the case, this test may not have perfectly captured how optimized the code for each framework

is. A band-aid fix for this could be to clear the map after each additional rendered shape.

6.1.3 Performance under heavy load

Leaflet did not handle rendering many markers very well. The scope of this test was reduced to give a better picture of how Leaflets performance degrades with marker count. After this test, additional research was performed as to how one can optimize Leaflet for improved marker performance, this research is presented in Section 5.2.2 regarding out-of-the-box usability. When rendering lines and polygons, the frameworks performed more comparably. Google Maps did tend to maintain a higher framerate count.

6.1.3.1 Performance under heavy load – Method discussion

Google Chrome’s FPS meter was used to measure the frames per second within this test. The tool does not provide an average FPS metric, so measurement had to be done by looking at the current FPS and approximating which value it gravitated around. Thus, this measurement can have a touch of human error within it and using a more accurate measurement tool is a point of improvement.

During the FPS measuring test, the map was manually panned and zoomed. Using an automated method of moving and panning the map would be preferable as then the movement is consistent between tests. Selenium is a tool which can automate most web browser actions and would be suitable for this. [13]

6.2 RQ1 – Ease of use

For this criterion, an attempt was made to find the major differences between the mapping frameworks. The aspects that were primarily focused on were the processes of registration and implementation, how usable the frameworks were out-of-the-box, and which code quirks each mapping framework had.

6.2.1 Ease of use – Method discussion

The aspects that were evaluated, were so because they had a direct impact on the developed project because they drew the most attention. Due to this, there could be additional aspects regarding ease-of-use that were overlooked. A point of improvement would be to increase the sample size of developed projects and developer opinions.

If this paper were redone, research would have been conducted to find out what makes a framework easy to use, scientifically. The current method has the downside of being quite subjective regarding the aspects that were considered most important.

6.3 RQ1 – Functionality

For the purposes of drawing geometry onto a map, both frameworks had enough functionality to do so in a satisfactory way for the search engine. Google Maps does inherently support rendering heatmaps, whereas Leaflet requires a plugin to do so.

The primary differences in functionality were all the additional paid services included with the Google Maps access token. If your project requires geocoding, live traffic information, or a

directions service, Google Maps is a one-stop shop for all these features.

6.3.1 Functionality – Method discussion

This criterion was evaluated partly by experiences gained through development, and partly by a one-hour documentation reading session. The results of this criterion could have been influenced by how the documentation was structured, and due to only being read by a single person, a single time, some notable features could have been missed.

This criterion was quite well-defined from the start of this paper. The method used has seemed suitable throughout the work and has yielded the expected data set.

6.4 RQ2 – Issues encountered

The most important issue that was found was ASP.NETs postback behavior, as refreshing the webpage when the map is purely client-side is quite destructive. Future work could delve deeper into this behavior and try to find simple ways of working around it. It seems that some form of dynamic updating (i.e. AJAX) would be necessary and trying to find a simple way of combining it with ASP.NET could be very helpful for future projects.

Another interesting idea for future work could be a comparison between server-side web frameworks, to see how they compare regarding postback behavior. Perhaps some are more suitable to use than others when dealing with client-side maps?

6.4.1 Issues encountered – Method discussion

This research question was explored by writing a developer diary after each day of development and taking note of noteworthy issues that were encountered.

The diary served its purpose quite well, and adequately summarized the experiences gained during development.

7 CONCLUSIONS

For the purposes of implementing in-browser maps, Leaflet and Google Maps are both adequate at doing so. The frameworks do however have different pros and cons.

When rendering large sets of geographic data, both frameworks have enough functionality to draw the needed geometry. Google Maps generally maintains a higher level of performance when doing so, especially when it comes to placing large sets of markers.

Both frameworks are easy to use and quite straight-forward to implement. The code and syntax of the frameworks are very alike, to the point of being nearly hot-swappable.

Google Maps is a paid service whereas Leaflet is free to use. Google Maps includes many additional services that Leaflet users would need to obtain through third-party providers. These services include (but are not limited to) geocoding, live traffic information, map elevation, and directions. If your project requires any of these services, Google Maps is your one-stop shop for them.

When implementing in-browser maps (through JavaScript) in an ASP.NET project, two issues were found that one may need to keep in mind: Client-server variable sharing, and ASP.NET refreshing the webpage on postback requests, wiping the maps.

REFERENCES [1] Robert Williams, “MobileMarketer”, 11 July 2018. [Online]. Available:

https://www.mobilemarketer.com/news/google-maps-rated-as-no-1-navigation-app-survey-says/527525/. [Accessed 28 May 2020]

[2] Carlo Zapponi, “GitHut.info”. [Online]. Available: https://githut.info/. [Accessed 27 January 2020].

[3] Microsoft, “.NET | Free. Cross-platform. Open Source”. [Online]. Available: https://dotnet.microsoft.com/ [Accessed 10 February 2020]

[4] Microsoft, “What is .NET? An open-source developer platform”. [Online]. Available: https://dotnet.microsoft.com/learn/dotnet/what-is-dotnet [Accessed 10 February 2020].

[5] Microsoft, “ASP.NET | Open-source web framework for .NET”. [Online]. Available: https://dotnet.microsoft.com/apps/aspnet [Accessed 10 February 2020].

[6] Google, “Our history in depth – Company - Google”, 6 April 2016. [Online]. Available: https://web.archive.org/web/20160406123606/http://www.google.co.uk/about/company/history/#2005 [Accessed 10 February 2020].

[7] Google, “Google Maps Platform | Google Developers”. [Online]. Available: https://developers.google.com/maps/documentation/ [Accessed 10 February 2020].

[8] Google, “Overview | Maps JavaScript API | Google Developers ”. [Online]. Available: https://developers.google.com/maps/documentation/javascript/tutorial [Accessed 10 February 2020].

[9] OpenStreetMap, “OpenStreetMap”. [Online]. Available: https://www.openstreetmap.org/about [Accessed 10 February 2020].

[10] Lee, J. K., & Lee, J. Y. (2011, September). Android programming techniques for improving performance. In 2011 3rd International Conference on Awareness Science and Technology (iCAST) (pp. 386-389). IEEE.

[11] Rosenberg, J. (1997, November). Some misconceptions about lines of code. In Proceedings fourth international software metrics symposium (pp. 137-142). IEEE.

[12] Rowley, J. (2014). Designing and using research questionnaires. Management Research Review.

[13] A. Holmes & M. Kellogg (2006, July). Automating functional tests using Selenium. In AGILE 2006 (6 pp. -275).

[14] M. Haklay & P. Weber (2008). OpenStreetMap: User-Generated Street Maps. In IEEE Pervasive Computing (vol. 7, no. 4, pp. 12-18)

[15] Yi Fang et al. (2008). Spatial indexing in microsoft SQL server 2008. In Proceedings of the 2008 ACM SIGMOD international conference on Management of data (SIGMOD ’08) (pp. 1207–1216)

[16] Peterson, M. P. (1997, June). Trends in Internet map use. In Proceedings of the 19th ICA Conference, Ottawa (Vol. 1, No. 10, pp. 571-580).

[17] Gibin, M. et al. (2008). An exploratory cartographic visualisation of London through the Google Maps API. Applied Spatial Analysis and Policy, 1 (pp. 85-97).