October 20, 2004
Eric L. Goldstein
Rob Tobkes
Lawrence Wang
|
|
|
The concept of a shortest-path map is easy to understand. Its purpose is to effectively display transportation routes such that the user
can easily find the shortest route in terms of time between his or her source and desired destination. Making the map interface intuitive helps the user
do so more easily. However, an objective definition of intuition must be applied in this case otherwise the map may be designed in the
map-maker's best interests rather than those of a more general populace.
Combining effective engineering into a logical and intuitive map is the most demanding part of this project. As was observed during the numerous discussions on the topic, engineering-driven decisions can sometimes lead to effective yet highly user-unfriendly implementations. For example, using very thick lines to display the most important links on the map can help ease the user's finding of those important links; however, in an area of high city density, the thicher links can appear to pass through many cities that are not located along them. Thus, tradeoffs are required between powerful and intuitive implementations. After much experimentation, we chose four main algorithms to display our cities and links. First, a brightness-based scale for travel time was used wherein the brighter colors represented shorter travel times. Human vision tends to focus on brighter objects first, so making the "more important" (i.e. faster) links correspondingly brighter will decrease the time for a user to find the fastest links. Second, an all-pairs-shortest-path algorithm was utilized to remove any links that were never a shortest path. In other words, any travel routes that would never result in a minimal travel time between source and destination for the user are not drawn on the map. Thirdly, a city clutter-removal technique was implemented where, if two pieces of cities are very nearby in screen space, they are bumped apart in small increments until they no longer near enough to each other to clutter the map. Building a method that accomplishes this last task with minimal geographical distortion is difficult but our algorithm does so nicely. Lastly, a technique to insure that city names do not overlap was also implemented to help remove the clutter and to furthur increase map readability. |
|
|
|
Although map drawing cannot be considered a game with discrete situational steps to take, fundamental problems must be addressed in
order to obtain a clear, intuitive map. The following four points explain in detail the importance of analyzing and solving those
fundamental problems.
The Four Fundamentals
|
|
|
Output image based on gamefile "secret-map.txt". Image shows our player's flexibility because it can successfully draw arbitrary maps. Our initial motivation was to create a player that was as flexible as possible. In other words, we wanted to build a player that could draw any arbitrarily supplied map while simultaneously solving the four aforementioned fundamental problems. The main focus was placed on spacing out any cluttered points without overly distorting the map. We implemented many methods of image manipulation such as city label relocation and point distortion in order to more clearly display the points and city labels, successfully eliminating the problems of ambiguous city labels and geographic distortion. We approached the problem of clearly displaying shortest paths with the intent to use an all-pairs-shortest-path algorithm. Our other intent when approaching this problem was to display the links intuitively in order for the user to easily find his or her desired shortest path. Because most maps use color-coded systems, we chose a similar system implementing color-coded links wherein brighter links meant faster links and dimmer links meant slower links. Finally, for displaying a clear and concise legend, we set aside a very small portion on the very bottom of the map to display a low-profile legend. The specifics of our algorithms' implementations are outlined below. |
|
|
|
Link Coloring & Links on Shortest Pathes
Our initial decision was to categorize links based on their time-distance instead of their physical distance. Additionally, we decided to assign each link a color; this would easily allow the user to discern the shortest time-path by simply following the paths with the "fastest" color. So each link will be assigned a color based on the value of the time between its two endpoints. Offline training could have been done to hardcode boundary values, but this would be very ineffective because the speeds in each map would vary too much. For example, with offline training, it still would be possible for all the links to have the same color if all the speeds are very similar. Instead, our link colors are assigned online so that each color will be assigned an (almost) equal number of links, no matter what the speeds are for the map. In order to do this, we generate a sorted array of the N link-times. The boundary values then become the values at array position ((N-1) * 1) /(number of colors), ((N-1)*2)/(number of colors), . , ((N-1)*number of colors)/(number of colors). Thus, the array is dynamically partitioned into N equal size buckets (well, as close equal size possible), and each speed is assigned a color based on the bucket in which it falls. We initially decided upon eight colors, but later reduced it to six colors. In our opinion, it was too difficult to find eight very distinct colors. Having similar colors reduces the overall value of color-coating the links. Our goal is to have the user easily distinguish speeds based on link color. Additionally, with more colors, the user is forced to remember more if he/she does not wish to constantly check with the key. For example, instead of forcing the user to remember if dark gray is "faster" than light-gray, we simply removed this discrepancy by only having six colors. Now, the fastest color is the brightest color and the slowest is the dimmest, and there is very little overlap in colors. The colors, from fastest to slowest are as follows: orange, green, cyan, magenta, blue, light gray. Additionally the fastest three colored links are drawn with twice the width as the slower three colored links. This insures that the user's eyes will be drawn to faster links. Our group also used an all-pairs shortest path approach to eliminate links not on a fastest path between cities. No user in search of the fastest path would ever take one of these slower links, so nothing is lost by eliminating them. We would like to thank Group 5 for the implementation of this algorithm. In northeast.game, 27 of 152 links (4%) were removed. In subways2.game, 8 of 114 links (7%) were removed, and in uscapitals.game 7 of 97 links (7%) were removed. This effectively helped to remove some of the "clutter" on the map. Scaling the Map We decided to scale the map X and Y coordinates independently in order to maximize the screen space taken up by the map. We were willing to accept the possible distortion created in order to spread out the points on the map as much as possible. It was very clear that removal of clutter was more important than a totally geographically accurate portrayal of the data set. 
Output image based on gamefile "uscapitals.game". Image shows our that X and Y are scaled independently and that link colors are distributed evenly Unclustering Cities Even with coloring links and scaling the map to fit the maximum space allotted, we still observed issues with readability. The main issue was that some maps had closely-grouped clusters of cities, which would display very near each other on the map, making their links and names very difficult to distinguish. 
Map plotted from unmodified dataset. Note the difficulty of distinguishing links and city names in the cluster in the east. To address this situation, we developed an algorithm that spreads out the cities that are too close, increasing the readability of links and names. The algorithm is fairly simple. Cities that are too close "bump" each other apart: for each city N1:
for each other city N2 (that has not already been compared):
if distance(N1, N2) in screen pixels < threshold:
move N1, N2 apart from each other a small amount.
This entire procedure is repeated until no pair of cities is closer than the threshold distance. However, since the scale we use to fit the map to the screen is based on the original set of points, there is a possibility that some points will now display off the screen, so we rescale the new set of points. This rescaling may change the screen distance between some points to be below the threshold, so we actually uncluster and rescale again several times.
Map after cities have been unclustered. Note the improvement in the visiblity of links and the drastic unclustering in the east. This method trades readability for fidelity to the map's original geometry; the higher we set the threshold for minimum distance between cities, the more distorted the map becomes. Based on the size of the label font we used, we picked a value of 40 pixels; this drstically distorts the vertical lines of the subways map, for example, at a low screen resolution, but distorts to a more tolerable degree at 1600 by 1200, our resolution for printing. Label Placement We also implemented a refinement to the way city labels are printed on the map. Note in the figure above that even after unclustering the cities, some labels overlap. This overlap must be avoided at all cost, since it renders text largely unreadable. Fortunately, it is preventable for all but the longest names, since each city has a guaranteed minimum distance from its neighbors after unclustering. We therefore specified several locations around a given city at which its label can be placed, and when each label is to be printed, we check if it would collide with any labels that have already been printed, and if so, choose another location. 
Map with unclustering of cities and flexible name placement. This method is quite successful at resolving the few instances of information overlap remaining after our previous optimizations. It is also "inexpensive," because it doesn't increase the amount of distortion in the map. For a specific exmaple, note the Atlantic City-NJ/Dover-DE conflict in southern part of the map without flexible label placement and then note the successful, non-overlapping label placement for these cities in the map above. |
|
|
|
We set out to design a clear, visually pleasing map that was easy to read, but at the same time was very true to reality. The problem was interesting because it set a fairly strict set of constraints on what we could do: we were limited to what we could display on a single static 8.5x11" sheet of paper.
Despite these limitations, we believe that we have quite successfully accomplished these goals through evenly distributed link-coloring, "bumping" city locations, a "smart" display of city names to prevent overlap, and use of an all-pairs shortest-path algorithm. One bug that snuck in is that the different categories in our legend sometimes overlap each other at small resolutions, but this is not an issue at our printing resolution. According to Judge 2, Abhinav Kamra, our maps are "quite clear". Furthermore, Abhinav was able to successfully find a shortest-path 4 out of 4 times, and only once found the incorrect path. In addition to our maps, only on the maps for Groups 1 and 6 was Abhinav able to find a shortest path all 4 times. But, on Groups 1 and 6, he was incorrect twice for each group and commented that one map looked cluttered for each group. On the other hand, the comments for our maps, very "clear", "clear", and "very clear". Our best review however came from Judge Grinspun who commented that our US Capitals map is "Beautiful from a design esthetic point of view." His comments prove that we were successfully able to remove the clutter to make our map readable. As an added perk, distributing the link colors evenly makes a map that is pleasing to the eye. |
|
|
| We would like to acknowledge the contributions of Group 5 for providing us with an all-pairs-shortest-path implementation that was used on top of our code. Their algorithm reduced the time it took to progress our player to its final state, and we are thankful. More specifically, we used their Path.java file. |
|
|
|
Rob Tobkes helped in the design of much of the mapping algorithms and it was his idea to categorize the links by time instead of distance. Lawrence Wang designed the unclustering algorithm and did much of the implementation and testing of the program. Eric Goldstein implemented an all-pairs-shortest-path algorithm, although it went unused in this project. He also performed various other misc. tasks such as helping to layout and organize this report. |