ECE297 Final Report Googol Maps - Skuleexams.skule.ca/exams/ECE297H1_20161_661553880569Wd2-Final...

/* ECE297 Final Report Googol Maps */

// CI: James McMahon struct Student {

string name; unsigned id; Student (string name, unsigned id)

: name(name), id(id) {} }; Student s1(“Sihan Wu”, 1001258122); Student s2(“Haoran Liang”, 1001357907); Student s3(“David Yang”, 1001409647);

1.0 Introduction

We aim to create a city-mapping software that is useful beyond the scope of the course. The map is designed for navigation, intended for drivers visiting unfamiliar destinations. Consequently, the design shares many similarities with Google Maps™ [1], an extremely popular [2] Geographic Information System. To compete against such an impressive map, our design must not only be easy to learn and simple to use, but also have all the functionality required by the user. This document describes key design choices and important technical innovations. Section 2.0 analyses the motivation behind visualization and user interface designs. Section 3.0 justifies our coding architecture and describes the improvements we made on standard algorithms to improve speed or solution quality.

2.0 Design Overview

Our goal is to create a visually appealing and useful map. In order to be useful, a map must have functionality while remaining simple [3], intuitive [4], and responsive [5]. The following sections describe how we implemented essential functionality using our 3 goals as design principles.

2.1 Map Visualization Our Geographical Information System contains too much information to display all at once (Figure 2.1). Our design must display select land features, streets, and points of interest in a manner that is not cluttered (Figure 2.2). As shown in Table 2.1, smaller features are hidden when zoomed out. Reducing clutter increases visibility for important features, facilitating a more pleasant user experience.

// Page 1 2016 Googol Maps

Figure 2.1: High level screenshot of map visualization with nothing hidden. Note this can never

happen during regular runtime.

Figure 2.2: High level screenshot of the map visualization where residential streets, buildings,

and points of interest are hidden to reduce clutter.


Table 2.1: Visualizations shown at different zoom levels.

Visualization Zoom Level

Items Shown

1 Land Bodies, Islands, Large Parks, Large Water Bodies, Major Highways, City Names/Labels

2 Streams, Primary Roads, Small Rivers

3 Medium-sized parks

4 Small water bodies, Residential Streets, Points of interest, Small Parks

5 Buildings


2.1.1 Land Feature Visualization Many features must be identified to read a map. To ease the burden on the user, our map uses easily distinguishable and intuitively identifiable colours to display different land features (Table 2.2). These colours reflect reality and are inspired by the popular Google Maps™ colour palette [1]. In addition, points of interest are sorted into multiple categories, each with an intuitive icon. These icons serve to facilitate effortless point of interest identification and classification. To avoid distracting the user with irrelevant points of interest, each category can be toggled. Buildings are also colored by category (Table 2.2), but are not a main focus of the map. Thus, building colors are less vibrant and only subtly help users identify the region type. Table 2.1.1.a: Color Palette and Visualization of Land Features

Visualization Item/Type

Parks, Greenspace, and Golf Courses

Beaches

Ponds and Lakes

University Buildings


Schools, Government, and Public Buildings

Retail Buildings

Commercial and Industrial Buildings

Train tracks

Subway tracks

Streetcar/tram tracks

Point of Interest Icons


2.1.2 Street Visualization Just like land features, streets should also be easily distinguishable. We redirect user attention to important streets through colour and thickness (Table 2.3), allowing users to quickly identify well-known streets and providing a sense of driving speed.

Text placement follows our simplicity and anti-clutter design principles in order to be easy to read. Directional arrows warn users of one-way streets, and are intelligently drawn to the left and right of each street name to prevent a randomized look and feel (Figure 2.3). Furthermore, street names never overlap at intersections and are always right-side-up and read left-to-right along the street (Figure 2.4).

Figure 2.3: One-Way Street Direction

Indication.

Figure 2.4: Residential street names. Some building structures are shown as well.


Table 2.3: Color Palette and Visualization of Streets Visualization Item/Type Line Thickness Ratio Compared to

Residential Streets

Motorways and Trunks Motorway Links and Trunk Links

3

Primary Streets Primary Street Links

3

Secondary Streets Secondary Street Links

2

Tertiary Streets 2

Residential/Unknown Streets 1


2.2 User Interface - Output

Textual information must be displayed without overwhelming the user. As seen in Figures 2.5, 2.7, and 2.8, all detailed information is displayed in a scrollable info-pane. Isolating all detailed information to a single pane ensure that users know where to look for information and unifies the overall experience. We also implemented a help menu to guide lost users (Figure 2.5). This help menu covers all aspects of the program’s input and output such as viewing information about a selected intersection (Figure 2.7), and viewing user-saved locations (Figure 2.8). Additionally, error messages are displayed to inform users about invalid commands (Figure 2.6). These messages fade in and out automatically so the user doesn’t have to perform additional actions.

Figure 2.5: Getting directions help

instructions. Other help instructions can be opened from the left menu.

Figure 2.7: Selected intersections provide

information about the nearest enabled point of interests

Figure 2.6: Example error displayed through “Toasts”, semitransparent boxes that fade in

and out.

Figure 2.8: Location saver shows users their

saved location. Saved locations can be deleted by clicking the red X button.


2.3 User Interface - Input

2.3.1 Mouse

Mouse-input is our main form of user input. In addition to panning (dragging) and zooming (scrolling), our design features a right click menu (Figure 2.9). This menu serves to concisely provide useful and essential options, such as finding directions, finding the nearest point of interest, and saving the right-clicked location.

Figure 2.9 Right click menu showing mouse-over.

Items are selectable and contain textual information. Left-clicking on parks and intersections (Figures 2.10 and 2.11) will highlight them and add their respective information to the info-pane.

Info-pane headers are clickable and will animate the map toward the associated item (Figure 2.12). This one-click navigation follows our simplistic design principle by reducing the navigation time. The info-pane also supports buttons used as interface shortcuts (Figure 2.13).

Figure 2.10: Selected/highlighted park.

Figure 2.11: Multiple selected intersections.

Figure 2.12: Clicking on an info-pane

item animates to its location on the map.

Figure 2.13: Get Directions button appears after selecting an intersection and point of interest.


2.3.2 Keyboard

As seen in Figures 2.14 and 2.15, the keyboard input is primarily used for entering search and direction queries. Keyboard input is natural and does not require perfect spelling; reasonable typos can be made and the closest search result will be returned. Furthermore, Figure 2.3.2.b exemplifies autocompletion, which completes words or phrases based on what the mapping database provides. Autocompleted phrases are highlighted such that as the user types, the autocompleted part is overwritten, but pressing enter will accept the entire autocompleted phrase. Therefore, no extra clicks/actions are required. Finally, keyboard input combined with mouse input can also facilitate selection of multiple intersections and points of interest (Figure 2.16). Multiple selections can be made by holding SHIFT or CTRL. This allows the user to find directions between two mouse-selected locations. When exactly two items are selected, the user is automatically be presented with the option to find directions between selected locations (Figure 2.13).

Figure 2.14: Textbox in its directions state

Figure 2.15: Textbox in its search state with an

autocompleted example.

Figure 2.16: Multiple points of

interests selected by holding SHIFT or CTRL on the keyboard while

clicking.


2.4 Travel Directions Visualization Our map is capable of computing optimal paths between desired locations so the user doesn’t have to. The path takes turn penalties and speed limits into account for realistic navigation, but currently ignores traffic. These paths are bolded and highlighted for user clarity, and noteworthy turns are identified with numbered pins that correspond to an entry in a turn list (Figure 2.17). Each item in the turn list can be clicked and will smoothly zoom to the associated turn, so the user doesn’t have to manually find it. This turn list serves to intuitively and naturally guide the user. Therefore, the turn list provides instructions that a person might provide, such as verbosely describing turns or the initial heading. Additional navigation details include the name of the street to turn onto and the distance to drive before the next turn. An estimation for total travel time is also provided to help prepare the user for their trip. This is displayed in the usual minute and second format, following the ISO shorthand notation standards [6].

Figure 2.17: Path visualization showing detailed turn list instructions and bolded path, with pins

at each turn.


2.5 Responsiveness We aim to maintain a fast response time to improve usability [7]. Many methods have been incorporated to achieve this, discussed further in Section 3.0. As a result, we complete all visual draws and point-to-point pathfinding within 0.1 seconds, fast enough to seem instantaneous [8][9]. Furthermore, the way things are drawn can perceptually make the program feel faster. Rather than clearing and redrawing a screen one element at a time, we draw to an off-screen image before drawing the finished image all at once. This removes frames with missing elements, creating a sense of smoothness and responsiveness. Responsiveness can also be produced via animations. Animations show that the interface is responding in a natural and understandable way. For example, we animate opening and closing the pane by sliding it in/out using a smoothed cosine model. A smooth animation such as this prevents an unnatural “teleporting” interface.


3.0 Technical Overview

This section covers the technical decisions made in the design process. It is meant for an audience with prior knowledge of standard data structures and algorithms. As such, this document will explain not how they work, but why they’re used and how we’ve improved upon them. Notably, this document will use Big O Notation [10] for complexity analysis.

3.1 Information Look-Up With so much information stored in a map, retrieval speed is critical to responsiveness and usability. Fast and accurate retrieval of information about items such as intersections and street segments is necessary because it is used extensively in pathfinding.

3.1.1 Internal Identification The map stores information about intersections, streets, street segments, and points of interest in arrays, using an identification number (ID) as the index to allow fast O(1) lookup (See Appendix A). These arrays are all contained in a single class [11] that handles initialization and cleanup and can be accessed statically [12] by the rest of the program. We use C++ Standard Template Library [13] vectors [14] instead of conventional arrays for convenience in development, but vector overhead slightly slows the program. Vectors that are never resized can be easily replaced with arrays to improve speed.

3.1.2 String Query Using IDs allows fast lookup from ID to information, such as name or location, but do not allow fast lookup from information to ID. Since IDs are hidden from the user, the map must somehow convert user input into IDs. One common form of input is string [15] input from the keyboard. Since string queries occur once per user input, lookup speed is much more lenient. We decided trading speed for autocorrection would improve user experience, as long as response time never exceeds the “instantaneous” 0.1s constraint [8][9].


Fuzzy matching (approximate string matching) [16] is handled by a static class [12] and calculates the Damerau-Levenshtein distance [17] between strings. To find the closest match, the user input is fuzzy matched against all strings in the database to find closest match. Though this takes much longer than a conventional hash table, the average response time never exceeds the instantaneous response constraint [8][9] while correcting most errors made by our test groups.

3.1.3 Spatial Query

The user can select items by clicking on them, meaning the map must perform spatial queries [18], or find items based on spatial coordinates. We store map items in a two-dimensional grid (See Appendix B) to support spatial queries and also accelerate map drawing. This structure was selected because it provided a significant speed boost in spatial queries and did not noticeably increase setup time. Voronoi diagrams [19] and kd-trees [20] were tested and abandoned after offering no support for map drawing and noticeably increasing setup time.

3.2 Map Visuals Organization Our code is organized for ease of development. All structures support quick addition or deletion of features so we can quickly test and dismiss ideas based on user feedback.

3.2.1 Map Drawing Architecture Our architecture is motivated by a need to batch-process visualized elements. For instance, we need to turn entire groups of items on and off depending on the zoom level, and we need an elegant way to draw all the visuals. To accomplish these tasks, we organized our “MapItems” into “MapLayers”. The power of organizing items into layers/categories is that when we want to turn off an entire category, we only need to flip a single flag located on the layer, rather than flip flags for thousands of MapItems individually. These layers are what allow us to efficiently display different details at different zoom levels. A visual summary of this architecture is provided by Figure 3.1. On a high level, each layer doesn’t know what kind of item it’s holding. By inheriting from MapItem, any item can control how it’s drawn through polymorphism. This allows us to easily add additional MapItem categories without modifying the overall architecture. Every map item inherits from either BlobItem (2D), LineItem (1D), or IconItem (point), for further organization.


Figure 3.1: High level software architecture of the visualization organization

Each layer performs spatial queries (Section 3.1.3) to efficiently search for on-screen MapItems. Thus, we do not waste processor time looping through MapItems that do not need to be drawn.

3.2.2 Map Interface Management Many of our features share the same interface with the user. For example, almost every single feature interacts with the info-pane. Therefore, the info-pane is handled by its own static class [12], and other functions simply add or remove items through a static function [12]. Another example is the drop-down menu, used as both a right-click menu (Figure 2.9) and a textbox description (Figure 3.2), handled by a single class.

Figure 3.2: Dropdown menu used to describe textbox use.


3.3 Point to Point Pathfinding The standard algorithm for point-to-point(s) pathfinding is Dijkstra’s Algorithm [21], sometimes accelerated using A* [22] heuristics. Dijkstra’s Algorithm is usually guaranteed to find the fastest path in O(n) time.

However, we include a turn penalty of 15 seconds every time the path changes in street name. This penalty prevents normal Dijkstra’s from guaranteeing the fastest path (See Appendix B). To rectify this, we modified Dijkstra’s to remember the fastest path to reach each intersection from each street (compare Figure 3.3 with 3.4).

Once satisfied with the accuracy of Dijkstra’s we implemented an A* heuristic [22] to reduce algorithmic runtime. To preserve Dijkstra’s accuracy, the A* heuristic must underestimate the time required to reach the destination [23]. Thus, we used the straight-line distance divided by the speed limit of the fastest highway. The turn penalty only serves to increase actual time, so this heuristic is guaranteed to be an underestimate.

Figure 3.3 Dijkstra’s Path before correction

(55 seconds to traverse).

Figure 3.4 Dijkstra’s Path after correction (36

seconds to traverse).


3.4 Vehicle Routing Problem with Pickup and Delivery (VRPPD)

The VRPPD is a variant of the Travelling Salesman Problem (TSP). More specifically, we worked on the pickup-first, delivery-second, multiple commodity, multiple depot, single vehicle routing problem [24]. The key difference to classical TSP is that the solution is not necessarily cyclic [25] (departure and arrival may be at any depot), and visitation order is constrained (pickups must come before deliveries). These differences make standard TSP solutions less effective, and since we have an execution cap of 30 seconds, we created a customized algorithm to perform 2-opts [26] and simulated annealing [27].

3.4.1 Solution Quality Evaluation In order to generate a good solution, the computer must know what a good solution is. Solution quality is defined by the amount of time it takes to traverse the path (solution). Lower travel times are higher quality. The computer must be able to quickly compute the travel times of multiple solutions and compare them to optimize solutions. Therefore, we precompute a matrix of travel times between all pickups/deliveries/depots to allow fast O(1) lookup (See Appendix D). Since the IDs in section 3.1.1 are large, we gave each pickup/delivery a separate ID for indexing. These IDs also serve to easily differentiate pickup/delivery and supports legality assertions [28] during implementation (See Appendix D).

3.4.2 Solution Legality Assertion Due to the constraint of visiting deliveries after pickups, a legality check is required anytime the path (visitation order) is modified. We decide to forego the legality checks and instead perform modifications that are guaranteed legal (covered in Section 3.4.3). To do this in O(1) time, we store an array that tells us where a pickup’s associated delivery or delivery’s associated pickup is in the visit order (Figure 3.5). For example, at index 1 in the first array, the associated node is at index 5. Therefore, the value at index 1 of the second array will be 5. The disadvantage of storing this second array is that it needs to be fixed upon any change to the visitation order. However, this fix is only O(1) and is negligible compared to alternatively doing an O(n) legality check upon changing the visitation order, discarding the change should it fail.


Figure 3.5: Color-coded visualization of the visitation order of nodes and their associated item’s

index.

3.4.3 Iterative Improvement The crux of our algorithm is to start at a greedy solution (See Appendix E), then iteratively improve it. To improve iteratively, we make random perturbations to the path, accepting the change only if the quality improved. An effective “random change” to make is the 2-Opt, where the path is cut in 2 places and reattached differently [27]. However, due to path-legality limitations, blindly performing 2-Opts most likely result in invalid paths. Instead, we analyze the possible outcomes of a 2-Opt (Figure 3.6), then implement each outcome as an individual operation. The operations are selected randomly to avoid deterministic results. The benefit to implementing 2-Opts this way is that each individual operation is designed to produce a legal result. By performing only legal operations, computation-time is not wasted checking for legality and fixing illegal moves. Further analysis shows that some of our 2-Opt outcome operations (Figure 3.6) are capable of performing more powerful 3-Opt outcome operations (Figure 3.7). Although they do not perform all 3-Opt outcomes, they are powerful enough to yield improved results (Table 3.1).


Figure 3.6: A 2-Opt Broken down into its individual operations, each of which simple to

implement.

Figure 3.7: Partial outcomes of a 3-Opt that can result from Swap and Shift 2-Opt

implementations.


3.4.4 Overall Algorithm In addition to the swap, shift, and reversal operations, our overall algorithm implements multithreading and Simulated Annealing to improve our score (Table 3.1). Multithreading was implemented to run the algorithm 4 times simultaneously, allowing us to choose the best of the 4 at the end. Because of our algorithm’s random nature, multithreading improves the chances of randomly arriving at better answers. Finally, we implemented Simulated Annealing [28], which allows slightly worse modifications to be accepted in the early stages of optimization. This metaheuristic prevents the algorithm from converging to a worse local minima due to its greedy decisions. Table 3.1: Algorithm progress and the score improvements

Features Geometric Average Score (Minutes)

None ~5000

+Swap ~2200

+Shift ~1380

+Reversal ~1340

+Multithreading ~1280

+Simulated Annealing ~1240

+Turn Cost Correction (Section 3.3) after iterative improvements

1226.8


4.0 Lessons Learned The primary formula to our success is the time spent on this project. We found that the larger the program got, the more debugging time we needed. Thus, for a project of this size, finishing the basic requirements well before deadlines allowed us to meticulously tweak, improve, and debug our code. As a result, we were able to find subtle problems such as the issue with the original Dijkstra's algorithm (See Appendix C). In addition, we learned the importance of receiving and implementing user feedback from people with different backgrounds. By viewing our design from another standpoint, our friends identified poorly implemented features and gave constructive feedback. For example, the second textbox (Figure 4.1) was implemented due to user feedback stating that finding directions with a single textbox is non-intuitive (Figure 4.2). Effectively, we gathered ideas from other successful designs to enhance our own.

Figure 4.1: Current textbox layout designed for finding directions.

Figure 4.2: Old textbox layout which used a single textbox for everything. Users noted this was more like a command line, and was non-intuitive for users that did not commonly use command

lines. Finally, we learned that having brainstorming and planning sessions before writing code was very helpful. This was especially effective in creating our inheritance structure in Section 3.2, which laid out the framework for the entire visualization. Our strategy gave us a clear goal and allowed us to write clean, concise, and easily expandable code.


4.1 Future Plans Although time did not permit us to fully explore POI categories, future plans include replacing miscellaneous POIs (Figure 4.3) with actual icons (Figure 4.4 and Figure 4.5). Furthermore, our pathfinding algorithm only implements a turn-cost constraint without considering traffic data. To further reflect reality, we also plan on considering U-turns, crossings between major/minor streets, and traffic (Figure 4.6).

Figure 4.3: Current visualization of miscellaneous point of interests.

Figure 4.4: An example of point of interest icons that can be added in the future to replace the

miscellaneous dots.

Figure 4.5: Subway (metro) station, bus stop, and streetcar stop icons


Figure 4.6: A path depicting two stretches where the user will experience traffic.

5.0 Conclusion By carefully tweaking the visualization and reconstructing the user interface based on user feedback, we made the map visually appealing and easy to use. We did not slack on the technical side either, and meticulously fixed errors in standard algorithms to suit our purposes. Combined, we achieved our initial design goals and created a useful mapping application that is comparable to Google Maps™.


References [1] "Google Maps", Google Maps, 2016. [Online]. Available: http://maps.google.ca/. [Accessed: 08- Apr- 2016]. [2] Z. Fox, "The 10 Most Frequently Used Smartphone Apps", Mashable, 2013. [Online]. Available: http://mashable.com/2013/08/05/most-used-smartphone-apps/#mrV7SfUUBqqG. [Accessed: 08- Apr- 2016]. [3] H. Loranger, "Simplicity Wins over Abundance of Choice", Nngroup.com, 2016. [Online]. Available: https://www.nngroup.com/articles/simplicity-vs-choice/. [Accessed: 08- Apr- 2016]. [4] J. Spool, "What Makes a Design Seem 'Intuitive'?", UX Articles by UIE, 2005. [Online]. Available: https://articles.uie.com/design_intuitive/. [Accessed: 08- Apr- 2016]. [5] J. Nielsen, "Website Response Times", Nngroup.com, 2010. [Online]. Available: https://www.nngroup.com/articles/website-response-times/. [Accessed: 08- Apr- 2016]. [6] "ISO 8601 - Time and date format", Iso.org, 2016. [Online]. Available: http://www.iso.org/iso/home/standards/iso8601.htm. [Accessed: 08- Apr- 2016]. [7] J. Hoxmeier and C. DiCesare, System Response Time and User Satisfaction: An Experimental Study of Browser-based Applications. AMCIS 2000 Proceedings. 2000. [8] Nngroup.com, "Response Time Limits: Article by Jakob Nielsen", 2016. [Online]. Accessed: 11- Feb- 2016. Available: https://www.nngroup.com/articles/response-times-3-important-limits/ [9] "Acceptable Response Times", Developer.gnome.org, 2016. [Online]. Available: https://developer.gnome.org/hig-book/3.12/feedback-response-times.html.en. [Accessed: 08- Apr- 2016]. [10] "Big O notation", Massachusetts Institute of Technology, 2003. [Online]. Available: http://web.mit.edu/16.070/www/lecture/big_o.pdf. [Accessed: 08- Apr- 2016]. [11]"Classes", Cplusplus.com, 2016. [Online]. Available: http://www.cplusplus.com/doc/tutorial/classes/. [Accessed: 08- Apr- 2016].


https://www.nngroup.com/articles/response-times-3-important-limits/

[12] "Static Specifier", cppreference.com, 2016. [Online]. Available: http://en.cppreference.com/w/cpp/language/static. [Accessed: 08- Apr- 2016]. [13] "Containers", Cplusplus.com, 2016. [Online]. Available: http://www.cplusplus.com/reference/stl/. [Accessed: 08- Apr- 2016]. [14] "Vector", Cplusplus.com, 2016. [Online]. Available: http://www.cplusplus.com/reference/vector/vector/. [Accessed: 08- Apr- 2016]. [15] "What is a string?", The Linux Information Project, 2007. [Online]. Available: http://www.linfo.org/string.html. [Accessed: 08- Apr- 2016]. [16] “What is Fuzzy Matching? - Definition from Techopedia", Techopedia Inc, 2016. [Online]. Available: https://www.techopedia.com/definition/24183/fuzzy-matching. [Accessed: 08- Apr- 2016]. [17] "Mailcheck", GitHub, 2012. [Online]. Available: https://github.com/mailcheck/mailcheck/wiki/String-Distance-Algorithms. [Accessed: 08- Apr- 2016]. [18] "Spatial Query", esri Support, 2016. [Online]. Available: http://support.esri.com/en/knowledgebase/GISDictionary/term/spatial%20query. [Accessed: 08- Apr- 2016]. [19] D. Reem, "An Algorithm for Computing Voronoi Diagrams of General Generators in General Normed Spaces", IEEE, p. 9, 2009. [20] A. Moore, "An introductory tutorial on kd-trees", Carnegie Mellon University, 1991. [Online]. Available: https://www.ri.cmu.edu/pub_files/pub1/moore_andrew_1991_1/moore_andrew_1991_1.pdf. [Accessed: 08- Apr- 2016]. [21] M. Yan, "Dijkstra's Algorithm", Massachusetts Institute of Technology. [Online]. Available: http://math.mit.edu/~rothvoss/18.304.3PM/Presentations/1-Melissa.pdf. [Accessed: 08- Apr- 2016]. [22] R. Eranki, "Searching using A* (A-Star)", Massachusetts Institute of Technology, 2002. [Online]. Available: http://web.mit.edu/eranki/www/tutorials/search/. [Accessed: 08- Apr- 2016].


[23] A. Patel, "Heuristics", Stanford University, 2010. [Online]. Available: http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html. [Accessed: 08- Apr- 2016]. [24] "VRPPD", Wiki4City, 2013. [Online]. Available: http://wiki4city.ieis.tue.nl/index.php?title=VRPPD. [Accessed: 08- Apr- 2016]. [25] "Graph Cycle", Wolfram Mathworld, 2016. [Online]. Available: http://mathworld.wolfram.com/GraphCycle.html. [Accessed: 08- Apr- 2016]. [26] G. Croes, "A Method for Solving Traveling-Salesman Problems", Operations Research, vol. 6, no. 6, pp. 791-812, 1958. [27] S. Kirkpatrick, C. Gelatt and M. Vecchi, "Optimization by Simulated Annealing", Science, vol. 220, no. 4598, pp. 671-680, 1983. [28] "Assert", Cplusplus.com, 2016. [Online]. Available: http://www.cplusplus.com/reference/cassert/assert/. [Accessed: 08- Apr- 2016].


Appendix

Appendix A This appendix entry explains the use of IDs to look up information (Section 3.1.1). Intersections, streets, and street segments are stored in their respective arrays. Each intersection has a unique ID from 0 to the number of intersections, and likewise for streets and street segments. The ID acts as the index of the array, so accessing the information given the ID is done by simply indexing into the appropriate array (Figure A1).

Figure A1: Visualization of Street Info lookup using Street ID. N = total number of streets.

Intersections are used heavily in pathfinding because they act as the nodes of a graph. Every time a node is visited in Dijkstra’s (Section 3.3), it requires information about its street segments (travel time), their streets (turn penalty), and all adjacent nodes (future visits). Having fast lookups for these operations is crucial because nodes are visited hundreds of thousands of times in extreme cases. If the lookup were one millisecond slower, the program would essentially freeze.


Appendix B This appendix entry explains the advantages of using a grid structure to store map items (Section 3.1.3). Each grid cell corresponds to a geographical square in the world and contains items that fall in that square. These squares can be indexed by geographical coordinates in O(1) time (See Figure 3.1.b) and therefore provide fast responses from spatial queries or draw requests. Items are placed into the grid based on the location of its centroid. This way, no item is duplicated in multiple cells. A spatial query is performed by indexing into the corresponding cell and calculating the distance to all the items inside. If no item is guaranteed to be closest to the query, neighbouring cells are also searched until the closest item is found. Grid and cell sizes depend on the map, sized to hold an average of 10 items per cell. This heavily reduces the amount of items searched, bringing average search time to O(1), reducing response time from 2ms (full search) to 7µs.

Figure 3.1.3.a: Visualization of the map being split into grid cells.


Figure 3.1.3.b. Visualization of Spatial Query returning a small list of items to search.

To draw the map, only items in cells in the visible window are drawn. By indexing into only visible cells, all other map items are ignored, removing inefficiencies and decreasing draw time.


Appendix C This appendix entry illustrates the problem with conventional Dijkstra’s (Section 3.3). On the graph displayed in Figure C1, Dijkstra’s will perform the following operations in chronological order:

1. Push A into priority queue with zero cost (sets up the initial visit) (Figure C1).

2. Visit A since A is the only node in the queue (Figure C2). a. Push B into priority queue with cost 1 (edge cost).

3. Visit B since B is the only node in the queue (Figure C3).

a. Push C into queue with cost 2 = 1 (B cost) + 1 (edge cost). b. Push D into queue with cost 3.05 = 1 (B cost) + 1.8 (edge cost) + 0.25 (turn cost).

4. Visit C since C is the least cost node in the queue (Figure C4).

a. Consider D again with cost 3.25 = 2 (C cost) + 1 (edge cost) + 0.25 (turn cost). ■ Note: By inspection, continuing along this path would result in a traversal

time of 4.25, since it turns once and traverses 4 edges that cost 1 each. However, since it costs 3.25 to visit D, this is worse than the previously considered path, which only cost 3.05 to visit. Thus, this path is ignored.

5. Visit D since D is the only node in the queue (Figure C5).

a. Push E into queue with cost 4.30 = 3.05 (C cost) + 1 (edge cost) + 0.25 (turn cost).

6. Visit E. This is the end of the algorithm since E (the endpoint) was visited.

Notice that the path in Figure C5 cost 4.30, while a path traversing A->B->C->D->E would cost only 4.25. Any time this configuration occurs on the map, conventional Dijkstra’s finds a suboptimal path by 0-0.25 minutes. Compounded, this may add to a lot, so we were pressured to fix this error.


Figure C1: An example graph with nodes labeled and edge costs (traversal times in minutes)

labeled. Also displayed is the current priority queue of nodes to visit.

Figure C2: Node A is popped (visited) and node B is pushed.


Figure C3: Node B is popped and nodes C and D are pushed.

Figure C4: Node C is popped and node D is considered, but not pushed due to having a higher

cost than a previously considered path.


Figure C5: Node D is popped and node E is pushed.

Once this discrepancy was fixed, we ran a test to confirm that our new algorithm would find the expected optimum path. We generate two random points, then run Dijkstra’s forwards (from point A to B following one-way streets) and backwards (from point B to A violating one-way streets). These paths would always be equal if the algorithm found the fastest path. With conventional Dijkstra’s the paths would sometimes be different due to the nature of the above described error. We repeated the test tens of thousands of times without fail, statistically confirming that we fixed the error.


Appendix D This appendix entry illustrates all advantages of having a separate ID system for the VRPPD (section 3.4). Consider a case of two arbitrary pickups and two arbitrary deliveries, with intersection ID: Pickup 1, 152; Delivery 1, 15365; Pickup 2, 56446; Delivery 2, 6565. These intersection IDs are converted into new IDs as shown in Figure D1.

Figure D1: Arbitrary intersection IDs being converted into new IDs for the VRPPD. A new array

is created to store the old IDs. The new array is used at the end of VRPPD optimization to turn the new IDs (which hold no meaning to the rest of the program) back into intersection IDs for path reconstruction. Otherwise, intersection IDs are irrelevant during VRPPD optimization. These new IDs hold interesting bitwise properties. The remainder when divided by 2 (bitwise AND with 1) explains the type of location. Pickups are always 0, and deliveries are always 1. This makes it easy to check if a modification will be legal (Section 3.4.2), since pickups can always shift left, and deliveries can always shift right.


When divided by 2 (right-shift by 1), only associated pickups and deliveries have the same result. Pickup and delivery 1 are both 0, while pickup 2 and delivery 2 are both 1. This makes it easy to check if a pickup and delivery are associated during development (Section 3.4.2). The other motivation for this new ID system is the path cost matrix (Section 3.4.1). Using intersection IDs to index into this matrix is a huge waste of memory space, since most intersections are not used. Hashing the intersection IDs would reduce the size of the matrix, but wastes some time to perform necessary hashing operations. Instead, the “hash” shown in Figure D1 is performed once on startup, and the new “hashed” IDs are used instead (Figure D2). This serves to increase access speed to this matrix, accessed often in VRPPD optimization.

Figure D2: Example path cost matrix with 2 pickups and 2 deliveries. Index [i][j] represents the cost to travel from pickup/delivery i to pickup/delivery j. The two extra columns (4 and 5 in this case) represent the numerous depots. Index [i][4] represents the cost to travel from the nearest depot to pickup/delivery i. Index [i][5] represents the cost to travel from i to the nearest depot.

An example use of this matrix is for a path that visits in order 1 -> 0 -> 3 -> 2 (Figure D3). The cost of traversing from the start depot to pickup/delivery 1 is added to the cost of traversing from pickup/delivery 2 to the end depot. Then, the cost of traversing from 1 to 0, 0 to 3, and 3 to 2 is added to the depot costs. This is an O(n) algorithm with minimum overhead to compute path costs.

Figure D3: Illustration of path cost calculation for 1 -> 0 -> 3 -> 2


Appendix E This appendix entry explains how and why the greedy algorithm is applied to the VRPPD solution (Section 3.4.3). The name greedy comes from the fact that at any given point, only the most optimal step at that point (hence, greedy) is selected, even if it may result in suboptimal steps later on. No consideration is made towards future moves and therefore often results in a worse solution. However, this solution is generally way better than random solutions. For comparison, traversing arbitrarily selected points in Toronto, New York, and London require over 5000 minutes for a random path, around 1500 minutes for a greedy path, and around 1200 minutes for our optimized path. The greedy algorithm maintains a set of legal nodes to visit, and an array of visited nodes (Figure E1). The set of legal nodes is initialized to all the pickups. A random pickup is selected to visit first.

Figure E1: Visualization of nodes turned into an array (Visited Nodes) and a set (Legal Nodes).

Anytime a pickup is visited, it is removed from the set of legal nodes to visit, and its associated delivery is inserted into the set (Figure E2). If a delivery is visited, it is simply removed from the set (Figure E3).

Figure E2: Node 2 (pickup) is randomly selected to visit. It is removed from the set of legal

nodes and node 3 (the associated delivery) is inserted.


Figure E3: Node 3 (delivery) is selected to visit (node 3 is the closest node to node 2. This is not true for the general case, but is used here for demonstration purposes). Node 3 is removed from

the set of legal nodes and nothing is inserted. Aside from the first visit, the next node to visit is the nearest node to the current visit that is in the set of legal nodes (a greedy visit). Nodes are visited in this order until the set of legal nodes is exhausted, which is the also the point at which every pickup and delivery is visited. The greedy solution is used as the starting point of our VRPPD optimization since it’s faster to generate a greedy path of 1500 minutes than it is to iteratively perturb a random path (starting at 5000 minutes) until it takes 1500 minutes. Since we have a CPU execution cap of 30 seconds, this leaves more time to iteratively perturb paths beyond 1500 minutes, giving us a faster path on average.


Attribution Table Table A: Attribution table of team members who drafted, edited, and researched each section.

Section Writing Editing/Revision Research

1.0 Introduction Haoran Liang David Yang Haoran Liang

2.1 Map Visualization Haoran Liang Sihan Wu Haoran Liang

2.1.1 Land Feature Visualization

Sihan Wu All Sihan Wu

2.1.2 Street Visualization Sihan Wu All Sihan Wu

2.2 User Interface - Output Sihan Wu Haoran Liang Haoran Liang Sihan Wu

2.3.1 User Interface - Mouse Input

Sihan Wu Haoran Liang Haoran Liang Sihan Wu

2.3.2 User Interface - Keyboard Input

Sihan Wu Haoran Liang Haoran Liang Sihan Wu

2.4 Travel Directions Visualization

Sihan Wu Haoran Liang Sihan Wu

2.5 Responsiveness Sihan Wu David Yang All

3.1.1 Internal Identification Haoran Liang Haoran Liang Haoran Liang

3.1.2 String Query Haoran Liang Haoran Liang Haoran Liang

3.1.3 Spatial Query Haoran Liang Haoran Liang Haoran Liang

3.2 Map Visuals Organization

Sihan Wu Haoran Liang Sihan Wu

3.3 Point to Point Pathfinding

Haoran Liang Haoran Liang All

3.4.1 Solution Quality Evaluation

Haoran Liang Haoran Liang Haoran Liang

3.4.2 Solution Legality Assertion

Sihan Wu Sihan Wu David Yang

N/A


3.4.3 Iterative Improvement Sihan Wu Sihan Wu Sihan Wu

3.4.4 Overall Algorithm Sihan Wu Sihan Wu Sihan Wu

4.0 Lessons Learned David Yang Sihan Wu Haoran Liang

N/A

4.1 Future Plans David Yang Haoran Liang David Yang

5.0 Conclusion Haoran Liang David Yang N/A


ECE297 Final Report Googol Maps - Skuleexams.skule.ca/exams/ECE297H1_20161_661553880569Wd2-Final...

Documents

Transcript of ECE297 Final Report Googol Maps - Skuleexams.skule.ca/exams/ECE297H1_20161_661553880569Wd2-Final...