System and method for abstracting and visualizing a rout map6952661Abstract A system and method for making computer-generated maps includes a different scale factor for each road in a route. The scale factors are used to optimize the route map against a target function that considers factors such as the number of false intersections in the route and the number of roads falling below a minimum length threshold. A refinement technique such as simulated annealing is used to find a solution to the target function. Each road in the scaled map is rendered to provide a finished product having the appearance of a hand-drawn map. The finished product includes context roads that intersect the main route but are not part of the main route. Furthermore, the hand-drawn map is optimized to the characteristics of the viewport used to visualize the map. Claims 1. A method for optimizing a display of a route map, the method comprising: Description The present invention relates generally to a system and method for generating a route map. More particularly, this invention relates to a system and method for applying a unique scale factor to each road in a route map and for optimizing the positions of labels in the route map. Further, a method for rendering the appearance of roads in the route map is disclosed.
Another embodiment of the present invention provides a method of simplifying a road in a route map. In the method, the road is approximated as a piecewise linear curve that includes a plurality of shape points. Each shape point in the plurality of shape points is connected by a linear segment to a respective shape point in the plurality of shape points. At least one point at which the road intersects another road in the route map is added to the plurality of shape points as an intersection point. Each shape point in the plurality of shape points that is (i) not a first shape point, (ii) a last shape point, or (iii) an intersection point, is marked. A check is made for false intersections between the road and another road in the route map and, when a false intersection is found, a first marked shape point and a last marked shape point in the plurality of shape points are unmarked. The checking step is repeated until no false intersection is found or there is no marked shape point in the plurality of shape points. When a shape point is marked, the piecewise linear curve is modified by replacing the marked shape point and each said linear segment connected to the marked shape point with a new linear segment that originates at a shape point or intersection point immediately proceeding the marked shape point and ends with a shape point or intersection point immediately succeeding the marked shape point. When a shape point is unmarked, the piecewise linear curve is modified by replacing the new linear segment associated with the shape point with (i) a first linear segment that is bounded by the shape point or intersection point immediately proceeding the marked shape point and the shape point and (ii) a second linear segment that is bounded by the shape point or intersection point succeeding the marked shape point and the shape point. In this way, the piecewise linear curve represents a smoothed road that corresponds to the road in said route map. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a prior art route highlight map. FIG. 2 is a prior art TripTik map. FIG. 3 is a prior art Overview/Detail map. FIG. 4 is a prior art hand-drawn map. FIG. 5 is a map that is generated in accordance with one embodiment of the present invention. FIG. 6 illustrates a system for generating a route map in accordance with one embodiment of the present invention. FIG. 7 illustrates the processing steps used to optimize the length of individual roads in a route map using a greedy algorithm, in accordance with one embodiment of the present invention. FIG. 8 illustrates the processing steps used to optimize the length of individual roads in a route map using a simulated annealing schedule, in accordance with one embodiment of the present invention. FIG. 9 illustrates the processing steps used to optimize label positions in a route map using a simulated annealing schedule, in accordance with one embodiment of the present invention. FIG. 10 illustrates a map before and after road extensions are made so that labels are optimally associated with corresponding roads. FIGS. 11A, 11B, and 11C illustrate the conceptual steps used to identify the longest axis of a route and to rotate this axis in a predetermined direction, in accordance with one embodiment of the present invention. FIG. 12 illustrates a generalized problem of placing annotations on a route map. FIG. 13 illustrates the processing steps associated with one solution to the generalized problem of placing annotations in a route map in accordance with one embodiment of the present invention. FIG. 14 illustrates the spatial subdivision of a route map in order to identify regions of the route map that are suitable for the placement of annotations as well as labels. FIG. 15 illustrates a generalized problem, which arises in a spatial subdivision approach to placing a label or annotation in a constrained area, in which no empty grid cell can be found. FIG. 16 illustrates how nonuniform subdivision is used to solve the problem of using spatial subdivision to place a label or annotation in a constrained area. FIGS. 17A and 17B illustrate the use of bounding boxes and FIGS. 17C and 17D illustrate the use of orientation vectors that are present in some constraint definitions in accordance with one embodiment of the present invention. FIGS. 18A, 18B, 18C, 18D, 18E, and 18F illustrate various layout styles that are present in some constraint definitions in accordance with one embodiment of the present invention. FIG. 19 illustrates the processing steps used to optimize label positions in a route map using a simulated annealing schedule that includes usage of constraint definitions, in accordance with one embodiment of the present invention. FIG. 20 provides an overview of an embodiment of layout module 688 that makes use of expanded constraint definitions, in accordance with one embodiment of the present invention. FIG. 21 illustrates exemplary image components and text boxes used to compose forms, in accordance with one embodiment of the present invention. FIGS. 22A, 22B, and 22C illustrate various output forms in accordance with one embodiment of the present invention. FIG. 23 illustrates a scaled route map with cross streets in accordance with one embodiment of the present invention. FIG. 24 illustrates the general problem of determining an amount of visual clutter in a pixel based image of a route map. FIG. 25 illustrates a route map with several point features, such as exit numbers, restaurant locations, and city names included in accordance with one embodiment of the present invention. FIG. 26 illustrates a cluttered route map that would be difficult to use while driving. FIG. 27 illustrates the route map of FIG. 26 split into two segment maps which, taken together, comprise the route map of FIG. 26. FIGS. 28A, 28B, 28C and 28D illustrate various intermediate and segment maps in accordance with one embodiment of the present invention. FIG. 29 illustrates a scaled route map with a corresponding inset in accordance with one embodiment of the present invention. FIG. 30 illustrates how the use of an inset can be used to avoid the circularization of a predominantly North-South or East-West route map in accordance with one embodiment of the present invention. FIG. 31 illustrates how the use of an inset can be used to associate legible labels to roads that do not have legible labels in a corresponding main route map, in accordance with one embodiment of the present invention. FIG. 32A illustrates a route map before curve (road or element) simplification and FIG. 32B illustrates the route map of FIG. 32A after curve simplification, in accordance with one embodiment of the present invention. FIG. 33 illustrates how road simplification can introduce false intersections (33A), missing intersections (33B), and inconsistent turning angles (33C). FIG. 34 illustrates how a road is treated as a set of shape points (s) into which intersection points are introduced, in accordance with one embodiment of the present invention. FIG. 35 illustrates the intersection of roads r1 and r2 at a point 3502. FIGS. 36A and 36B respectively illustrate two different methods for identifying shape points to remove or retain from roads in a road map that are not part of a ramp, in accordance with one embodiment of the present invention. FIG. 37 illustrates aspects of shape points in a ramp that are measured in order to evaluate a relevance of a particular shape point in a ramp in a route map during a simplification process, in accordance with one embodiment of the present invention. FIG. 38 illustrates shape points in a ramp in a route map, in accordance with one embodiment of the present invention. FIG. 39 illustrates how a check for turn angle consistency is made when considering to drop a ramp from a route map, in accordance with one embodiment of the present invention. FIGS. 40A and 40C illustrate portions of an unscaled route map whereas FIGS. 40B and 40D show corresponding scaled route maps that respectively illustrate how scaling can lead to false intersections and missing intersections. FIG. 41A illustrates how a missing intersection is scored and FIG. 41B illustrates how a misplaced intersection is scored in accordance with one embodiment of the present invention. FIGS. 42A, 42B, and 42C illustrate several false intersection scenarios, showing for each false intersection point which direction the closest endpoint must travel to remove the knot formed by that false intersection point. FIG. 43 illustrates a knot that is produced by a false intersection upon scaling a route map. FIGS. 44A and 44B illustrate methods for resolving false intersections, in accordance with various embodiments of the present invention. FIGS. 45A and 45B illustrate two types of missing intersections that arise during route map scaling. FIGS. 46A and 46B illustrate methods for resolving missing intersections, in accordance with various embodiments of the present invention. FIGS. 47A and 47B illustrate the utility of using extended intersections, in accordance with one embodiment of the present invention. FIG. 48 illustrates how an extended intersection may work against the resolution of a false intersection during route map refinement. FIG. 49 illustrates a way to determine which extended intersections to add to a refinement score, in accordance with one embodiment of the present invention. Like reference numerals refer to corresponding parts throughout the several views of the drawings. DETAILED DESCRIPTION OF THE INVENTION The present invention provides a system and method for generating maps that have the benefits and characteristics of a hand-drawn map. Automatically generating route maps in this style is complex. Distorting aspects of the map can accentuate reorientation points, but it can also have detrimental effects such as introducing false intersections. Creating an effective route map generally requires searching a large space of possible map layouts for an optimal layout. An efficient multistage algorithm that couples a road layout refinement module with a label and annotation placement module is disclosed. The resulting map is rendered using subtle perceptual cues, such as a wavy hand-drawn style for drawing the paths, to communicate the distortion of scale and shape. The design goals of the present invention are: (i) Roads should be variably scaled so that all roads and reorientation points are clearly visible and easily labeled. (ii) If road A is longer than road B, then road A should be noticeably longer than road B in the map. (iii) The representation of a road only needs to convey general curvature and the significant changes in orientation. (iv) The precise angle of intersection of two roads is not important; instead it is sufficient to communicate clearly the action to be taken (turn left; turn right) and a generalized orientation. (v) The start and end of the route should be clearly marked. (vi) A "sketchy" style should be used to render a road in order to represent an imprecision of scale and orientation. (vii) The resulting map should fit in the desired viewport, such as a single sheet of paper, a computer display screen and/or a window in a graphical user interface. Generating a computer-based map in accordance with the above identified design goals is more difficult than generating a map in conventional computer-based styles. Variable road scaling provides some flexibility in choosing the length of each road to produce a clear and readable map. However, the relative ordering of roads by length must remain fixed and false intersections should not be introduced into the map. The space of all possible route-map layouts is extremely large, and therefore it is not feasible to blindly search for a layout that satisfies the design goals of the present invention. Rather, a multi-phase heuristic generate-and-test approach is used to obtain a map that satisfies the design principles of the present invention. FIG. 5 illustrates a map generated using the methods of the present invention. General Architecture Attention now turns to FIG. 6, which is a system in accordance with one embodiment of the present invention. FIG. 6 illustrates a network 620 that is operated in accordance with the present invention. Network 620 includes at least one user computer 622 and at least one server computer 624. User computer 622 and server computer 624 are connected by transmission channel 626, which may be any wired or wireless transmission channel. User computer 622 is any device that includes a Central Processing Unit (CPU) 630 connected to a random access memory 650, a network connection 634, and one or more user input/output ("i/o") devices 638 including output means 640. In some embodiments, system memory 650 includes read-only memory (ROM). Output means 640 is any device capable of communicating with a human and includes, for example, a monitor, voice user interfaces, and/or integrated graphic means such as mini-displays present in web-phones. Typically, user computer 622 includes a main non-volatile storage unit 636, preferably a hard disk drive, for storing software and data. Further, user computer 622 includes one or more internal buses 632 for interconnecting the aforementioned elements. In a typical embodiment, memory 650 includes an operating system 652 and an Internet browser 654. In some embodiments of the present invention, user computer 622 is a hand held device such as a Palm Pilot. Accordingly, in such embodiments, it is possible that user computer 622 does not have disk 636 and browser 654 is integrated seamlessly into operating system 652. Server computer 624 includes standard server components, including a network connection device 660, a CPU 662, a main non-volatile storage unit 664, and a random access memory 668. Further, server computer 624 includes one or more internal buses 666 for interconnecting the aforementioned elements. Memory 668 stores a set of computer programs, modules and data to implement the processing associated with the invention. In particular, a preferred embodiment of memory 668 includes an operating system 680 and a HTTP server 682. Memory 668 further includes direction parser 684, road layout module 686, label layout module 688, annotation module 690, and map renderer module 692. In some embodiments of the present invention, memory 668 also includes a direction database 694 and/or context database 696. As will be discussed in further detail below, server computer 624 further includes a shape simplification module 697 for smoothing roads in a route map, a map verticalization module 698 for optimizing the dimensions of a scaled route map to the dimensions of the viewport used to display the scaled route map, and a map division module 699 for breaking a complex scaled route map into a plurality of segment maps. Direction parser 684 reads directions from a source, such as a file, a database external to server 624, or a database resident in server 624. Direction parser 684 translates the directions into a graph. Nodes in the graph represent intersections, and edges represent the roads connecting the intersections. In one embodiment, system 620 does not contain a database of roads. Rather, all the information about the map is obtained from text directions stored offsite. In another embodiment, server 624 contains direction database 694, which is used to identify a suitable route between an origin and a destination. After directions have been parsed by direction parser 684, roads in the route map are scaled with road layout module 686. In one embodiment, road layout module 686 applies a constant scale factor to the entire map so that the map fits in a viewport having predetermined dimensions. As a result of this uniform scaling, the map often contains many roads that are too small to see or label. To remedy this, each road in the map, beginning with the smaller roads, is scaled by road layout module 686 until roads in the map are clearly visible. Since the length of roads is only increased in this step, the map ends up being larger than the size of the viewport. Thus, in subsequent steps, certain aspects of the map are reduced to yield a map that fits the dimensions of the desired viewport. In one embodiment of the present invention, the size of the map is reduced by repeatedly initiating a tracing procedure. In this embodiment, road layout module 686 executes the tracing procedure until the entire route is traced without identifying a road that exceeds the dimensions of the viewport. In the tracing procedure, each successive road in the route is examined, beginning at the route origin, until a road extending outside the viewport, i.e. an offending road, is identified. When an offending road is identified, each road that had been traced is examined to see if it is capable of being shortened. A road candidate is capable of being shortened if it is (i) longer than a specified minimum length, (ii) the relative ordering of the roads by length remains fixed even after the candidate has been shortened, and (iii) false intersections are avoided. In one aspect of this embodiment, road layout module 686 shortens road candidates using a greedy approach so that the candidate is shortened as much as possible, in order from longest to shortest, until the offending road is pulled back inside the viewport. Label layout module 688 is used to place labels on the scaled map produced by road layout module 686. To date, proper labeling of individual roads has been an intractable problem. Label layout module 688 solves this problem by refining a novel target function using a simulated annealing schedule. Simulated annealing has been used to refine label positions in prior art methods. Edmondson et al., Cartographica 33, 1997, 12-23. However, unlike Edmondson, which uses a limited set of discrete label positions, the present invention considers a continuous range of positions for label placement, and label placements are not limited to positions that are directly above or below the road. Furthermore, the present invention uses a more comprehensive target function that considers the number of roads each label intersects, the number of labels each label intersects, the distance the label is from the center of the road associated with the label, and whether the label is above or below the associated road. Finally, the present invention is advantageous because roads are extended when the label corresponding to the road is lengthy Annotation module 690 adds decorations, such as road extensions, to the route map of the present invention. Further, module 690 adds an icon for route start and end points. Road extensions accentuate reorientation points, and allow for a larger range of label positions to be considered. In this phase, all roads are extended by a small fixed amount. Then only those roads that need to be extended for the chosen labeling pattern are further lengthened. FIG. 10 illustrates the advantages of applying road extensions. In FIG. 10, 1002 represents a road map prior to road extension whereas 1004 represents the same road map after road extension. Labels now fit the corresponding roads and the map is easier to read. Geographic and/or commercial context information are added to the route map by annotation module 690 to help guide the user through the desired route. In one embodiment, such context information is obtained from context database 696. Map renderer module 692 renders the scaled route map. In this phase, a "sketchy" pen-and-ink style is applied to each road in the route map. That is, instead of drawing roads as straight lines, variation is introduced in the bend and width of each road to generate a hand-drawn look. In an approach similar to that of Markosian et al., SIGGRAPH 97 Conference Proceedings, 1997, 415-420, each road is broken into small segments and the position of each point is slightly shifted both normal and tangent to the segment direction. These points are then joined with a non-uniform rational b-spline (NURB) to create the final stroke. A NURB is a curve that interpolates data. Thus, given a set of points, a curve is generated passing through all the points. The thickness of the roads is then adjusted to emphasize the route and de-emphasize road extensions generated by annotation module 690. Now that an overview of one embodiment of the invention has been disclosed, a number of advantages of the present inventions are apparent. First, the present invention discloses a method for automatically generating a route map that has the clarity of a hand-drawn map. Such a map is produced by using a novel scaling function in which each road is scaled individually using the design criteria of the present invention. Further, a novel method for positioning labels on the map is disclosed. The refined label positions help provide a route map having improved clarity. Map Scaling Attention now turns to detailed embodiments of road layout module 686. The present invention contemplates several different implementations of road layout module 686. The different road layout module embodiments contemplated by the present invention include but are not limited to uniform scaling, fixed non-uniform scaling, as well as refinement of individual scale factors using a greedy search or simulated annealing schedule. In uniform scaling embodiments, a single scale factor that allows the graph created by direction parser 684 to fit in a desired viewport is computed. For viewports that are defined as an x by y pixel array, a single scale factor, pixelsPerMile, is computed by an assignment such as: in which the function ComputePixelsPerMile( ) determines the maximum number of pixels a mile of the route may have without causing the overall route to exceed the desired pixel-based viewport. One of skill in the art will appreciate that a single scale factor for viewports that are based on metrics other than pixels can be computed using functions analogous to ComputePixelsPerMile( ). Once a uniform scale factor has been identified by a function such as ComputePixelsPerMile( ), the uniform scale factor is applied to the length of each road, and intersection points between consecutive pairs of roads are updated to reflect the change in length of the roads. For pixel-based viewports, the application of the uniform scale factor to each road reduces to a conversion of miles to pixels. Thus, in such embodiments, the application of the constant scale factor to each road takes the form:
In fixed non-uniform scaling embodiments, road layout module 686 includes a rescaleByBucket( ) function that breaks the range of road lengths (0, infinity) found in the route into N consecutive buckets [0, x1), [x1, x2), . . . [xN-1, xN), [xN, infinity). The function then scales the roads differently depending on which bucket they fall in. Small roads, those in the earlier buckets, are scaled to be longer, while longer roads are scaled to be shorter. In one embodiment, roads falling in the final bucket are capped at some maximum length. In another embodiment, roads falling in the first bucket are not allowed to fall below a minimum length. In yet another embodiment, the scale factor that is chosen for each bucket is subject to the constraint that the relative ordering of the roads by length remains fixed. In embodiments in which the route is to be scaled to a pixel-based viewport, each road is scaled by the uniform scale factor computed by the ComputePixelsPerMile( ) function described in the uniform scaling embodiment. Thus, one implementation in accordance with the non-uniform scaling embodiment, has the steps:
Attention now turns to FIG. 7 which illustrates an embodiment of the present invention in which road layout module 686 refines the length of roads in the map using a greedy search algorithm. In processing step 702, road layout module 686 first computes a pixel to mile conversion factor and applies this factor to each road in the map so that the map fits into the desired viewport. Then, in processing step 704, the roads are sorted by length. The relative order of the roads, in terms of length, in the map as determined in processing step 704 is maintained throughout the remainder of the processing steps illustrated in FIG. 7. In some embodiments deviations in this relative ordering is allowed upon payment of a penalty. In processing step 706, all small roads are grown until each road is longer than a set minimum length. Because processing step 706 only lengthens roads, the route map is not likely to fit in the desired viewport after processing step 706 has been executed. To reduce the map so that it fits into the desired viewport, a search for roads that can be shortened is performed. In processing step 708, the route is traversed from the route origin. Each route in the road is examined (710-714) until a road that extends outside the viewport (offending road) is identified. When such a road is identified (710-Yes), a list of candidate roads in the portion of the route that had been traversed prior to identifying the offending road is collected (720). To qualify as a candidate road, a traversed road must be capable of being shortened without changing the relative ordering of the roads by length and without falling below a minimum road length. Further, a candidate road must be capable of being shortened without creating any false intersections between roads. Finally, the candidate road should be oriented within ±90 degrees of the offending road. Once a road candidate set has been generated, it is ordered by length, from longest to shortest (722). Once the candidate roads have been ordered, a shortening process is initiated. The shortening process takes advantage of the computational efficiency of a greedy algorithm to shorten the roads (724). The shortening process cycles through each candidate road in the ordered set of candidate roads and shortens the candidate as much as possible (726) before advancing to the next candidate in the ordered set (732). After the greedy algorithm is applied to a candidate road, a check is made to see if the offending road has been pulled back inside the viewport (728). If the offending road has been pulled back into the viewport (728-No), the shortening process ends and control returns to processing step 708. When the greedy algorithm has been applied to each candidate road in the ordered set without successfully pulling the offending road into the viewport (730-Yes), the shortening process repeats the process of applying the greedy algorithm to each road in the candidate list (724) until the offending road is pulled back into the viewport (728-No). The process in FIG. 7 continues until the complete route can be traversed without identifying a road that exceeds the dimensions of the viewport (714-Yes, 780). If such a traversal fails, the shortening process of steps 720-732 is executed and a new attempt to traverse the route is initiated 708. At times, an identified road that matches the candidate requirements indicated above will not be added to the road candidate set because there is some other road in the route that is the same length. Roads that have the same length as the identified road are termed blocking roads. If there is a blocking road, the identified road cannot be added to the road candidate set because, if it were shortened, the relative ordering of roads by length, as identified in processing step 704, would be destroyed. The occurrence of blocking roads is of interest because, in some circumstances, they prevent the processing steps of 724-732 from pulling the offending road into the viewport (728-No). In some embodiments, when a certain number of iterations of processing steps 724 through 732 fail to effect a solution (728-No) one or more of the blocking roads are shortened using the greedy algorithm discussed previously. Then, if the offending road still exceeds the dimensions of the viewport, a new road candidate set is generated (720) and processing steps 724 through 732 are executed until the offending road no longer exceeds the dimensions of the viewport (728-No). FIG. 8 illustrates another embodiment of road layout module 686 in which the length of roads in the map are refined with a simulated annealing schedule. In processing step 802, a single scale factor is applied to each road in the route map. In one embodiment, which is in accordance with this aspect of the invention, the scale factor is used to size the map produced by direction parser 684 so that it fits within the dimensions of the desired viewport. In another embodiment, the map is sized so that each road in the map is longer than a selected minimum length so that each road in the map is legible in the desired viewport. In the second phase of processing step 802, an initial parameter t is chosen. The use of a parameter t to obtain better heuristic solutions to a combinatorial optimization problem has it roots in the work of Kirkpatrick et al., Science 220, 4598, (1983). Kirkpatrick et al. noted the methods used to find the low-energy state of a material, in which a single crystal of the material is first melted by raising the temperature of the material. Then, the temperature of the material is slowly lowered in the vicinity of the freezing point of the material. In this way, the true low-energy state of the material, rather than some high energy-state such as a glass, is determined. Kirkpatrick et al. noted that the methods for finding the low-energy state of a material can be applied to other combinatorial optimization problems if a proper analogy to temperature as well as an appropriate probablistic function, which is driven by the this analogy to temperature, can be developed. The art has termed the analogy to temperature an effective temperature. Therefore, parameter t will henceforth be termed an effective temperature. It will be appreciated that any effective temperature t may be chosen in processing step 802. One of skill in the art will further appreciate that the refinement of an objective function using simulated annealing is most effective when high effective temperatures are chosen. There is no requirement that the effective temperature adhere to any physical dimension such as degrees Celcius, etc. Indeed, the dimensions of the effective temperature t used in the simulated annealing schedule adopts the same units as the objective function that is the subject of the optimization. In one embodiment, a starting effective temperature that is readily reduced by ten percent on a periodic basis is chosen, such as 1.0/log(3)*3. In another embodiment, the starting value of t is based on a function of one or more of the characteristics of the route to be scaled, such as the number of roads in the route, the number of intersections in the route, and/or the length of the route. In another embodiment, the starting value of t is selected based on the amount of resources available to compute the simulated annealing schedule. For example, the starting value of t is reduced below a pre-specified default value when the annealing schedule is to be run on a server that is currently refining several other routes or on a relatively slower client. In still another embodiment, the starting value of t is related to the form of the probability function used in processing step 814. It has been found, in fact, that the effective temperature does not have to be very large to produce a substantial probability of keeping a worse score. Therefore, in some embodiments, starting effective temperature t is not large. Once a single scale factor has been applied to each road in the route map and an initial starting effective temperature has been assigned, an iterative process begins. A counter is initialized in processing step 804 and, in processing step 806, the quality of the map (E1) is assessed using an objective function. It will be appreciated that the utility of the map produced by the simulated annealing schedule is dependent upon the development of an objective function that accurately balances the various features of the map that need to be optimized. In one embodiment, the objective function is dependent upon the number of false intersections each road in the route makes, the number of roads in the route that no longer have the same relative length that they had before the simulated annealing schedule was initiated, and the number of roads that fall below a minimum length. An objective function in accordance with this embodiment is: ##EQU1## where,
After the quality (E1) of the map has been measured using the objective function, a scale factor is randomly generated and applied to a randomly selected road (808). In one embodiment, the scale factor is randomly chosen from a permissible range, such as zero to two. Thus, in such an embodiment, a random number generator is used to identify a number in the range zero to two, such as "0.6893." The random number is then applied to a randomly selected road in the route as a scale constant. For example, if the number is "0.6893" and the randomly selected road is the jth road in the route map, the jth road is shortened by 31.07 percent. In another embodiment, the permissible range for the random number is -0.1 to 0.1 and therefore, in such embodiments, application of the randomly chosen scale constant is capable of altering the length of the jth road by no more than ten percent. After the length of the jth road has been adjusted by the scale factor, the quality of the map (E2) is calculated using the same objective function used in processing step 806 (810). When the quality of the map has improved (E2<E1) (812-Yes), then the change made to the length of the jth road is accepted (830). When the quality of the map has not improved (E2>E1) (812-No) the change made to the length of the jth road is accepted with the probability: From the form of equation (1), it will be appreciated that the probability that the change is accepted, when (E2>E1), is lower at lower effective temperatures t. Equation (1) is implemented as processing steps 814 through 818 in FIG. 8. In processing step 814, exp-[(ΔE)/k*t)] is computed. In processing step 816, a number Pran in the interval 0 to 1 is generated. If Pran is less than exp-[(ΔE)/k*t)] (818-Yes), the change made to the jth road in processing step 808 is accepted (830). If Pran is more than exp-[(ΔE)/k*t)] (818-No), the change made to the jth road in processing step 808 is rejected (840). It will be appreciated that probability functions other than that disclosed in equation (1) are within the scope of the present invention. Acceptance of conditions (E2>E1) on a limited probabilistic basis is advantageous because it provides the refinement system with the capability of escaping local minima traps that do not represent a global solution to the objective function. One of skill in the art will appreciate, therefore, that probability functions other than that of equation (1) will advance the goals of the present invention. Representative probability functions include, for example, functions that are linearly or logarithmically dependent upon effective temperature, rather than exponentially dependent on effective temperature as described in equation (1). Processing steps 806 through 840 represent one iteration in the refinement process. In processing step 842 an iteration count is advanced. When the iteration count does not exceed the maximum iteration count, the process continues at step 806 (844-No). When the iteration count equals a maximum iteration flag (844-Yes), effective temperature t is reduced (846). One of skill in the art will appreciate that there are many different types of schedules that are used to reduce effective temperature t in various embodiments of processing step 846. All such schedules are within the scope of the present invention. In one embodiment, effective temperature t is reduced by ten percent. In another embodiment, effective temperature t is reduced by a constant value. For example, the starting effective temperature set in processing step 802 could be 20,000 and this effective temperature could be reduced by 300 each time processing step 846 is executed. In another embodiment the percentage decrease in effective temperature in processing step 846 is calculated as a function of the number of roads to be scaled. When the effective temperature has been reduced by an amount in processing step 846, a check is performed to determine whether the simulated annealing schedule should be terminated (848). In the embodiment illustrated in FIG. 8, the process is terminated (848-Yes, 850) when effective temperature t has fallen below a low effective temperature threshold or E2 falls below a predetermined low quality threshold. The low effective temperature threshold is any suitably chosen effective temperature that allows for a sufficient number of iterations of the refinement cycle at relatively low effective temperatures. When it is determined that the annealing schedule should not end (848-No), the process continues at step 804 with the reinitialization of iteration count i. In another embodiment of the present invention, a distinctly different exit condition than the one illustrated in FIG. 8 is used. In this alternative embodiment, a separate counter is maintained. This counter, which could be termed a stage counter, is incremented each time t is reduced in step 846. When the stage counter has exceeded a predetermined value, such as fifty, the simulating annealing process ends (850). In yet another embodiment, a counter tracks a consecutive number of times the arbitrary scale factor is rejected (840). When a set number of arbitrary changes in a row have been rejected, the route map is considered optimized and the process ends (850). Map Annotation In one embodiment, annotation module 690 is used to deterministically place context information on the map after the map has been scaled by road layout module 686. In one aspect of this embodiment, the context information represents points of geographical interest and helps to guide the user through the route to the destination. In another embodiment, the context information represents a form of advertisement that is paid for by subscribers. In one example in accordance with such embodiments, the subscriber is a fast food chain and the landmarks represent the location of each fast food franchise that is associated with the fast food chain. It will be appreciated that an important advantage of the present invention is that the route maps do not contain superfluous content. Thus, the route maps of the present invention are particularly well suited for use in conjunction with geographical landmarks that are paid for by subscribers. In one embodiment of the present invention, memory 668 of server 624 includes a context database 696 that is populated with context information that has been provided by and paid for by advertisers. Label Refinement Identification of an optimal position for each label in the route map improves the quality of the map because clutter and object overlap is reduced. The present invention optimizes label position by minimizing a novel target function that scores the position of a label using a unique set of label parameters. Importantly, rather than considering a small number of discrete positions for label placement, a continuous range of positions within a region around the center of the road being labeled are considered. This region includes positions that are not directly above or below the road being labeled. When a position that is not directly above or below the road is selected, the road is extended to the position of the label. In one embodiment, the target function is optimized using a simulated annealing schedule. FIG. 9 illustrates one embodiment in accordance with the present invention. In processing step 900, each label is placed at the center of the road corresponding to the label and an initial effective temperature t is selected. It will be appreciated that effective temperature it may be set to wide range of possible effective temperatures in processing step 900. In one embodiment, a starting effective temperature that is readily reduced by ten percent on a periodic basis, such as 1.0/log(3)*3, is chosen. In another embodiment, the starting effective temperature is based on a function of one or more of the characteristics of the route to be optimized, such as the number of labels in the route, the amount of context information along the route, and/or the length of the route. In another embodiment, the starting effective temperature is selected based on the amount of resources available to perform the simulated annealing calculations. For example, the initial effective temperature is set to a low value when the annealing schedule is to be run on a server that is currently refining several other routes or a client with a relatively slow central processing unit. In still another embodiment, the starting effective temperature t is determined by the nature of the probability function that is used to accept scores having S2>S1. In processing step 902 the stage counter is set to zero. The stage counter is incremented each time effective temperature t has been reduced. Once the initialization steps of processing step 900 have been performed, counter i is set to one (902) and a label j is randomly selected (904). The quality of the position of the jth label (S1) is measured using a target function, which is designed to measure label position quality, in processing step 906 and in processing step 908 the jth label is repositioned by a random amount. In step 908, the quality of the repositioned jth label (S2) is measured. An important advantage of the present invention is that the jth label is repositioned into any of a continuous range of values rather than a limited number of discrete positions. Further the target function used to compute S1 and S2 provides an improved method for assessing the quality of a label position. In one embodiment the target function includes the following components:
In line 301, all the objects that intersect the jth label are collected. Such objects include, for example, roads, other labels, and annotations such as context information. The target function loops through each of the collected objects (line 302). When the object is a road, a road penalty is added to the score (line 304), when the object is a label, a label penalty is added to the score (line 306) and when the object is an annotation, an annotation penalty is added to the score (line 308). In some embodiments, the target function includes one or more additional components. One such component is an off screen penalty. When the jth label is positioned such that a portion of the label exceeds the boundary of the viewport, an off screen penalty is added to the score. Another component is a "distance from the center of the corresponding road penalty." This penalty is determined by taking the product of a centering penalty and the normalized distance of the jth label from the road center. Additional components in the target function represent various constraints that are imposed on the label position. Constraints are used to bias label positions that are consistent with label position design criteria. For example, in one embodiment, it is preferable to position a label above the road rather than below the road. Thus, a below_the_road constraint penalty is added to the score of a label position that is below the road corresponding to the label. Another constraint penalty asks whether a road should be extended so that the road runs alongside the label. When it is determined that a road extension will provide better label to road correspondence, a road extension penalty is added to the target function score. Yet another constraint penalty is used when the label is positioned far away from the center of the corresponding road. In such cases, an arrow is positioned on the map to indicate the relationship between the label and the corresponding road and an arrow penalty is added to the target function. In one embodiment, the target function has the form:
When the quality of the jth position has improved (S2<S1) (912-Yes), the new label position for the jth label is accepted (930). When the quality of the map has not improved (S2>S1) (912-No) there is a probability that the new label position for the jth label will be accepted. From the form of equation (2), it will be appreciated that, for cases in which (S2>S1), the probability that the change in label position will be accepted diminishes as effective temperature t is reduced. Equation (2) is implemented as processing steps 914 through 918 in FIG. 9. In processing step 914, exp-[(ΔS)/k*t)] is computed. In processing step 916, a number Pran, in the interval 0 to 1, is generated. If Pran is less than exp-[(ΔS)/k*t)] (918-Yes), the change made to the jth label position in processing step 908 is accepted (930). If Pran is more than exp-[(ΔS)/k*t)] (918-No), the change made to the jth label position in processing step 908 is rejected (940). It will be appreciated that probability functions other than the function shown in equation (2) and processing step 914 are within the scope of the present invention. Indeed, any probability function that is dependent upon effective temperature is suitable. Processing steps 904 through 940 represent one iteration in the annealing process. In processing step 942, an iteration count is advanced. When the iteration count does not exceed the maximum iteration count (944-No), the process continues at step 904. When the iteration count equals a maximum iteration flag (944-Yes), effective temperature t is reduced and the stage counter is advanced (946). One of skill in the art will appreciate that there are many possible different types of schedules that are used to reduce effective temperature t in various implementations of processing step 946. All such schedules are within the scope of the present invention. In one embodiment, effective temperature t is reduced by ten percent each time processing step 946 is executed. In another embodiment the percentage decrease in effective temperature t in processing step 946 is calculated as a function of the number of labels to be scaled. After processing step 946, a check is performed to determine whether the simulated annealing schedule should be terminated (948). When it is determined that the annealing schedule should not end (948-No), the process continues at step 902 with the reinitialization of iteration count i. In the embodiment illustrated in FIG. 9, the process is terminated (948-Yes, 950) when a maximum number of stages has been executed. In one embodiment, the maximum number of stages executed is fifty. In embodiments other than that illustrated in FIG. 9, criteria other than the stage count is used in processing step 948 to determine when the simulated annealing process should be terminated. Such criteria include terminating the process when effective temperature t has fallen below a low effective temperature threshold, when E2 or E1 falls below a predetermined low quality threshold, or when the consecutive number of times the new label position has been rejected exceeds a threshold value. Map Rendering The final phase of the process is the rendering of the route by map renderer module 692. In this phase, the route map is humanized. In some embodiments, techniques used to humanize the map include casting the roads in a "sketchy" pen-and-ink style, adding a breakage symbol to long roads that have been significantly scaled down by road layout module 686, providing an indication of road length for long roads in the route, adding an arrow to indicate which way is North, and/or adding insets that show enhanced route detail. Map renderer module 692 produces the "sketchy" style by breaking each road into small segments and slightly shifting the position of each segment both normal to the stroke direction and along the stroke directions. The rotated segments are then joined with a NURB to create the final stroke. Further, the thickness of the roads is adjusted to emphasize the route and de-emphasize route extensions. In a preferred embodiment, a hand-drawn font is used for the labels. Overview of Alternative Embodiments for Abstracting and Visualizing Route Maps Embodiments for producing scaled route maps have now been described in detail. In the following sections, details of alternative embodiments for scaling route maps are provided. Full appreciation of these alternative embodiments is best obtained by first providing an overview of the basic processing steps performed by these alternative embodiments. Obtain route directions. First, directions are obtained by direction parser 684 from a source such as direction database 694 (FIG. 6). Although direction database is depicted as being on the same server 624 as direction parser 684, it will be appreciated that there is no requirement that direction database 694 reside on the same server. Indeed, direction database 694 may take several different forms and reside at any address that is in communication with transmission channel 626. Road simplification. Once road directions are obtained, an initial route map is constructed. Then, as will be described in further detail below, a pass is made by road shape simplification module 697 at simplifying the initial route map. If successful, road shape simplification module 697 removes one or more shape points from some of the roads in the route map, thereby reducing the complexity of the route map without sacrificing map legibility and utility. Furthermore, the reduced complexity of a simplified route map gfacilitates computationally intensive map refinement and scaling that arises in subsequent processing stages. Map page design. In the map page design stage, the dimensions of the viewport that the map will be displayed in or printed onto are considered. A layout template is chosen by road layout module 686 based on the dimensions of the viewport. Furthermore, the route map is optionally rotated by map verticalization module 698 in order to optimize the dimensions of the route map to the dimensions of the viewport. When the route map includes several steps, map division module 699 is invoked in order to break the route map into a plurality of segment maps in a manner that is consistent with the selected layout template. Road layout. At this stage, road layout module 686 scales each road independently (i.e. nonuniformly). The nonuniform scaling is driven by an optimization algorithm such as simulated annealing in order to achieve a suitable scaled map. The target function used by the optimization algorithm utilizes a novel scoring strategy that is designed to quantify map scale quality. Label layout. Once the map has been scaled, the route map is populated with road labels by label layout module 688. Each label is associated with a constraint definition that defines the boundaries in which the label may be placed and the format of the label. Using these constraint definitions, label layout module 688 refines the label locations using an optimization algorithm having a target function that quantifies label position quality. Map Annotation. Cross streets, land marks and an optional North arrow are added to the map during the map annotation stage. Annotation module 690 identifies suitable landmarks that will assist the navigator while using the route map. Such landmarks may be derived from a source such as context database 696. It will be appreciated that annotation module 690 can be used in some embodiments for commercial benefit. For example, licensing schemes are envisioned in which a retailer pays to have the location of each franchise positioned on the map as landmarks. Map rendering. Other stages of the map scaling process considered the route map in an abstract sense. In the map rendering stage, the components of the route map, including the main route, cross streets, landmarks, and the North arrow are reduced from an abstract sense to an actual image. In one embodiment, this image is a pixel based image. The stage of the process is performed by map renderer module 692. Now that an overview of this series of alternative embodiments have been provided, novel aspects of the series of embodiments will be examined in detail. Alternative Scoring Functions Used in Road Layout Refinement As outlined in the overview, an important aspect of the map scaling process is performed by road layout module 686. Road layout module 686 scales each road in a route map in a nonuniform manner. In embodiments in which road layout module 686 includes a simulated annealing schedule the following steps are performed:
It will be appreciated that the simulated annealing protocol outlined above and described in detail in FIG. 8 is not limited to any specific scoring function. Indeed, various embodiments of road layout module 686 use a wide array of scoring functions to determine the initial score E1 (806FIG. 8) as well as new scores E2 (810 FIG. 8). Applicants have described an objective function in accordance with one embodiment of road layout module 686 that is determined by (i) the number of false intersections made be each road i in a route map, (ii) the number of roads that no longer have the same relative length that they had before simulated annealing schedule was initiated, and (iii) the number of roads that are shorter than a minimum length threshold. In another embodiment of road layout module 686, processing steps 806 and 810 in FIG. 8 use a scoring function represented by the following representative code.
Each subscore considers a specific aspect of the road layout, and are prioritized as follows:
Line 502 of the representative code initializes the variable "Score" to zero. The variable "Score" represents E1 (806FIG. 8) or E2 (810). Next, lines 503 through 508 each potentially add to the value of "Score." Higher values of score represent higher values for E1 and E2 and thus represent poor solutions. Each of the functions that contribute to the overall value of "Score" on lines 503 through 508 are discussed with more detail below. IntersectionScore( ). The first function to contribute to the variable "Score" in the representative code is function "IntersectionScore( )" on line 503. Maintaining proper intersections between roads is the highest priority in the disclosed scoring function. In the initialization of the annealing, all of the roads in the route map are grown to their desired minimum lengths. Growing the roads can lead to two problems: intersections may be introduced between roads that should not intersect (false intersections), or two roads that should intersect no longer intersect (missing intersections). FIG. 40 illustrates both of these scenarios. FIGS. 40A and 40C each represent an original map whereas FIGS. 40B and 40D represent perturbed maps. FIG. 40B represents a situation in which a false intersection 4002 arises. FIG. 40D represents a situation where a missing intersection 4004 arises. Both missing and false intersections can be extremely misleading and therefore are severely penalized in any proposed layout that has either of these problems. The role of the scoring function in road layout module 686 is to guide the layout algorithm to the desired layout. One approach to furthering this goal is to add a fixed constant penalty when either of these conditions exists. However, this scoring function does not provide adequate guidance because the same penalty is always added to the score no matter how severe the false or missing intersection. Suppose the route contains a missing intersection as shown by 4004 in FIG. 40D. If the layout is perturbed and the missing intersection points end up closer to one another but do not exactly match, the intersection score for this map will not change. The algorithm will not know that moving the missing intersection points closer together generates a better layout. In other words the annealing algorithm is less likely to converge. Thus, in this embodiment, a score is constructed that reflects the severity of the intersection problems in a manner that suggests how they might be resolved rather than using a constant penalty for each false or missing intersection. What follows is a description of how simple false and missing intersections are resolved independently by the disclosed scoring function. Next, a description is provided for how scoring must change when there are both false and missing intersections in a single map. Missing and Misplaced Intersections. If two roads should intersect but don't (missing intersection), a factor is added to the score that is related to the distance between the proper intersection point on each road. The proper intersection point is computed from the parametric value of the original intersection in the unscaled map. If the roads should intersect and do intersect but at the wrong point (misplaced intersection), a factor is also added that is related to the distance between the proper intersection point on each road. The scoring weight for a misplaced intersection is much less than for a missing intersection. This score is illustrated in FIG. 41. FIG. 41A represents how a missing intersection is scored whereas FIG. 41B represents how a misplaced intersection is scored. The general formulas for computing the intersections are: where d is the Euclidian distance between the two points that should intersect as represented in FIG. 41. Simple False Intersections. False intersections occur when the path incorrectly folds back on itself, forming a loop or knot. To remove false intersections, the knot must be unraveled. To remove any individual knot it is desirable to make the false intersection point move toward the closest endpoint (in pixels along the route) of the path (or similarly, make the closest endpoint move towards the false intersection point). FIG. 42 illustrates several false intersection scenarios, showing for each false intersection point which direction the closest endpoint must travel to remove the knot formed by that false intersection point. FIG. 42A represents the simplest case, one false intersection 4202. End point 4204 simply needs to move to the right to resolve the false intersection. FIGS. 42B and 42C show which direction endpoints should move to resolve each false intersection point independently. FIG. 42B represents a situation in which multiple false intersection points 4208 are near the same endpoint 4206. The two false intersection points 4208 are pulling endpoint 4206 in opposing directions. FIG. 42C represents the case of multiple false intersection points (4214, 4216) that are near different endpoints (4210, 4212). In this case, false intersection points 4214 and 4216 are entirely independent of each other. Computing the score for an individual false intersection point is relatively straightforward. It is desirable to move the false intersection point towards the closer endpoint of the route, or alternatively to move the closer endpoint towards the false intersection point. FIG. 43 illustrates a knot that is produced by false intersection 4302. One way to resolve false intersection 4302, is to push the endpoint that is closer to false intersection 4302 towards the false intersection. To determine which endpoint (4304 or 4306) is closer to false intersection 4302, the distance between each endpoint and the false intersection is computed and compared. Then, the endpoint that is closer to the false intersection is moved towards the false intersection. Viewing each false intersection independently, the score for each false intersection point is computed as the "distance in pixels along the route to the nearest end point" multiplied by a scoring weight. This is equivalent to conceptually building a scoring hill along the route that guides the false intersection point to the closer endpoint, where it can be removed. Therefore, the score for a single false intersection can be computed as: where d is the distance in pixels to the endpoint along the route, as opposed to straight line distance, as shown in FIG. 43. However, as illustrated by the scenario in FIG. 42B, if the score for each false intersection is computed this way, then when there are multiple false intersections the scores will push the endpoint in opposite directions. However, this problem is addressed by always counting only the score for the innermost false intersection (i.e. the one farthest from the endpoint). The difference between counting all false intersections and only the innermost false intersection is shown in FIG. 44. FIG. 44A illustrates the situation in which, if the scores for both false intersections 4404 are counted, endpoint 4402 is pulled equally in both directions, resulting in a plateau in the scoring function since a move of endpoint 4402 in either direction does not change the score. FIG. 44B illustrates the situation in which only the innermost false intersection is counted for each endpoint. In the situation described in FIG. 44B, once the innermost false intersection has been resolved, the remaining false intersection becomes the innermost false intersection and is subsequently resolved. In situations such as FIG. 42C, where there are two false intersections but they are both closer to different endpoints, both scores are counted against these respective endpoints. False Intersections and Missing Intersections In general, when both false and missing intersections occur in the same map they can be scored as previously described, and in most cases the scores will interact properly to resolve both problems. However, there is one exceptional situation. This situation occurs when a missing intersection occurs within the loop formed by a false intersection. Several variations of this situation are illustrated in FIG. 45. In FIG. 45A, one point 4502 of the missing intersection is within the loop formed by a false intersection 4504. In FIG. 45B, both points 4506 are within the loop formed by false intersection 4508. In both of the situations shown in FIG. 45, one score may push in one direction and the other score in the other direction, resulting in a stalemate in which neither problem can be resolved. FIG. 46 shows the same routes as FIG. 45, but with arrows 4610 added to indicate the direction that the two scores would move the endpoints 4602 and 4604. An important point to note about the situations arising in FIG. 45 is that resolving the missing intersection often resolves the false intersection. In FIG. 45, there is supposed to be an intersection, it is just occurring between the wrong roads. It is quite often the case when a missing intersection occurs within the loop of a false intersection that the false intersection is simply the missing intersection misplaced. This situation is resolved with one additional rule: if there is some point of a missing intersection inside the loop formed by a false intersection a constant penalty is added for the false intersection, not a hill-based score. Thus, both of the cases that are shown in FIG. 45 will use a constant penalty for the false intersection, as both contain at least one point of a missing intersection within the false intersection loop. With this introduction an algorithm for scoring missing and false intersections can now be stated with lines 601 through 633 of the illustrative code.
Examining lines 601 through 633 of the illustrative pseudo-code in detail, one will notice that an additional score, "MaxExtendedIntersectionScore" is added to the false intersection scores. This function is described below in conjunction with an explanation of the concept of extended intersections. Extended Intersections. In addition to avoiding actual intersections between roads, it is desirable to avoid having roads pass close enough to each other that they appear to touch. These situations are handled in one embodiment of road layout module 686 by using the concept of an extended intersection. Extended intersections between two roads are calculated by extending both endpoints of each road by a fixed number of pixels and then checking if the resulting roads intersect. This concept is illustrated in FIG. 47. In particular, in FIG. 47A, the roads do not actually intersect but are close to one another. In FIG. 47B, when the roads are extended by a fixed number of pixels, the roads do intersect. If an extended intersection does occur between two roads it is scored in the following manner for each of the two roads: (a) if the intersection occurs in the extended part of the road, as for road 4702 in FIG. 47A, then the number of pixels from the end of the extended road is computed and multiplied by a fixed constant. (b) if the intersection occurs within the unextended portion of the road, as for road 4704 in FIG. 47A, then a fixed constant, which is equal to the largest penalty that can be assigned for an intersection with the extended portion of the road, is added to the score. There is one complication with handling extended intersections. When trying to resolve a false intersection, extended intersections often cause many local minimums in the search space. This is illustrated in FIG. 48, where an extended intersection 4802 works against the resolution of false intersection 4804. To reduce the number of local minimums in the search space explored by the target function as much as possible, only extended intersections are counted towards the score when they are not likely to be counteracting the resolution of a false intersection. Implementation of this criteria requires two things: (a) knowing when to, and when not to, count an extended intersection towards the score, and (b) adding the largest possible extended intersection score to the base false intersection score. Otherwise, when a false intersection is resolved the target function starts counting a number of extended intersections, and their increased score may overwhelm the decrease in score from resolving the false intersection. This may cause a substantial local minimum in the search space that would prevent the resolution of most false intersections. However, in a preferred embodiment road layout module 686, the maximum extended intersection score is added to each false intersection score. This guarantees that the resolution of a false intersection will result in a decrease in score. A way to determine which extended intersections to add to the score is to divide the route into false intersection intervals. All roads between an endpoint of the map and a false intersection, or between a pair of false intersections are considered to be in the same false intersection interval. This concept is illustrated in FIG. 49. In FIG. 49, the same route shown in FIG. 48 is illustrated, but the route is segmented by false intersection intervals. In particular, there are three false intersection intervals in FIG. 49: (A) from start point 4802 up to, but not including, the first road with a false intersection, (BCDE) which is from the road with a false intersection up to the next road with a false intersection, and (FGH) which is from the last false intersection to the endpoint. Extended intersections are only counted between roads in the same false intersection interval. Thus, the extended intersection shown in FIG. 48 would not be counted. If only extended intersections that occur between roads in the same false intersection intervals are added, then the problem depicted in FIG. 48 will not occur. ShuffleScore( ). The second function to contribute to the variable "Score" in the representative code is function "ShuffleScore( )" on line 504. The purpose "ShuffleScore( )" is to maintain the relative lengths of the different roads in the scaled route map the same as they were in the unscaled route map. In function "ShuffleScore( )," for each pair of roads A and B in the route map, the ordering of the roads by length in the scaled map is compared with the ordering of the roads by length in the original unscaled map. If the ordering has changed, roads A and B are considered shuffled and a factor is added to the variable "Score" to reflect this. In one embodiment, however, roads are only considered shuffled when their difference in lengths is greater than some perceptual threshold. Typically, the perceptual threshold used is dependent upon the resolution and size of the viewport that is used to visualize the route map as well as factors such as whether the full scaled route map is being displayed in the viewport as opposed to a scaled up segment of the scaled route map. The purpose of the penalty applied by function "ShuffleScore( )" is to ensure that, whenever possible, the relative ordering of roads by length is maintained in the scaled route map. In one representative target function used by an embodiment of road layout module 686, "ShuffleScore( )" is represented by the following expression:
RoadLengthScore( ). The overall goal of the non-uniform scaling of maps that is implemented by road layout module 686 is to make all of the roads in the route large enough to be legible. This is tracked by the third function ("RoadLengthScore( )"), which contributes to the variable "Score", as found on line 505 of the representative code. In function "RoadLengthScore( )," the current length of each road in the route map is compared to a predetermined minimum desired length. If a road is less than the minimum desired length, then a factor is added to the variable "Score." The magnitude of this factor is a function of the power of the difference between the current length of the offending road and a predetermined minimum acceptable road length. The predetermined minimum acceptable road length is set to ensure that the road is long enough to be identifiable in the scaled route map. In some embodiments of the present invention, the predetermined minimum acceptable road length is designated by considering the dimensions of the viewport 640 (FIG. 6) used to display the scaled route map or the number of pixels in viewport 640. In one example, when viewport 640 is a 1024 by 768 pixel array, the predetermined minimum acceptable road length is 20 pixels. In another example, the predetermined minimum acceptable road length is set to four percent of the length of the shortest dimension of viewport 640. Thus, if viewport 640 has a display that is 5 by 6 centimeters, the predetermined minimum acceptable road length is set to 0.2 centimeters. In one representative target function used by an embodiment of road layout module 686, "RoadLengthScore( )" is represented by the following expression:
RatioScore( ). The fourth function to contribute to the variable "Score" is function "RatioScore( )," which is on line 506 of the representative code. One of the lowest priority contributors to "Score," function "RatioScore( )" is used to maintain the ratios between different road lengths. Function "RatioScore( )" examines each road A in the scaled route map whose length is greater than the predetermined minimum acceptable road length described in the discussion of function "RoadLengthScore( )" above. For each such road A in the scaled route map, the ratio of the length of the road is compared to the next shorter and next longer road in the route map. The ratios obtained from these comparisons is matched with the corresponding ratios obtained from the unscaled route map. When the ratio between road A and the next longer and next shorter road in the route map differs significantly in the scaled and unscaled route maps, a penalty is added to the variable "Score." The purpose of function "RatioScore( )" is to preserve road length ratios in the scaled route map from the unscaled route map that have sufficient space. In one representative target function used by an embodiment of road layout module 686, "RatioScore( )" is represented by the following expression:
EndPointDirectionScore( ). The fifth function to contribute to the variable "Score" in the representative code is function "EndPointDirectionScore( )" (line 507). This function adds a factor to the variable "Score" to reflect the difference in the orientation between the start and end addresses in the unscaled route map and in the scaled route map. The magnitude of the factor added to the variable "Score" by this function is dependent upon the extent of the difference in the orientation between the start and end addresses in the scaled and unscaled route maps. Large differences in the orientation yield a large magnitude while small differences yield a small magnitude. In one embodiment of road layout module 686, "EndPointDirectionScore( )" is represented by the following expression: EndPointDistancescore( ). The sixth function to contribute to the variable "Score" in the representative code is function "EndPointDistanceScore( )" on line 508 of the representative code. This function adds a factor to the variable "Score" that reflects the difference in distance between the start and end point addresses in the original unscaled route map and the current scaled route map. This function is particularly useful for route maps that have an overall U-shape. This function ensures that the start and finish of the route map will not get too close to one another. In one embodiment of road layout module 686, "EndPointDistanceScore( )" is represented by the following expression: It will be appreciated that the scoring function represented by lines 501 through 508 of the representative code merely illustrates one type of scoring function that is used in some embodiments of road layout module 686. In fact, many permutations of the scoring function represented by lines 501 through 508 of the representative code are possible. Such permutations include the use of only a subset of the functions outlined in the representative code to build the value of variable "Score." For instance, in some embodiments, only the functions "IntersectionScore( )" and "RoadLengthScore( )" are used. Other permutations of the scoring function illustrated by the representative code include the relative weighting of component functions so that some of the functions have a greater influence on the value of the variable "Score." Thus, for example, in some embodiments, the contribution of IntersectionScore( ) to the variable "Score" is up weighted relative to the contribution of "RoadLengthScore( )." Such weighting schemes may be dynamically imposed based on factors such as the complexity of the route, the size of the viewport used to display the route, the presence of anomalies such as a road in the route that is much longer than any other road in the route, as well as user specified preferences. Additional Label Refinement Embodiments Another important aspect of the overall process for producing a high quality map is performed by label layout module 688. Label layout module 688 places and optimizes labels that correspond to the various roads in the route map. One novel feature of label layout module 688 is that it will fix the position of the label for certain roads during refinement. FIG. 9 illustrates one embodiment of label layout module 688 (FIG. 6). Many different types of target functions may be used to refine the label position in the process illustrated in FIG. 9. Two such target functions are described by lines 301 through 308 and lines 401 through 417 of the illustrative code. In the previously described embodiments, a simulated annealing schedule was used to place labels within a continuous range of positions in a region around the center of the road corresponding to the label. Such a region is called a constraint. The type of constraint used in previously described embodiments is illustrated in FIG. 17A. In FIG. 17A, element 1802 illustrates the continuous range of positions that may be used to place the label that corresponds to road 1802. Element 1804 serves as a constraint because the center of the label is constrained to lie somewhere within element 1804. FIG. 17B illustrates the placement of label 1806 at one such acceptable location. The layout module 688 described in this section builds upon the constraint definition used in prior embodiments. The expanded constraint definition is used by the target function in the simulated annealing schedule of label layout module 688 to identify a suitable label position, orientation, and style. The constraint components in the expanded constraint definition include (i) a bounding box (e.g. element 1704 in FIG. 17A), (ii) an orientation (e.g. element 1710 in FIG. 17C), (iii) a layout style (e.g. FIG. 18A through 18F), and (iv) a scoring strategy. The bounding box defines where the center of the label layout can be positioned. Thus, in FIG. 17B, a label placed using the constraint defined by box 1704 can be placed in such a manner that the center of the label falls anywhere in box 1704. Orientation vectors define how a label should be rotated. Label 1706 in FIG. 17A is positioned along a vector that is parallel to the long axis of corresponding bounding box 1804. Using the expanded constraint definition, labels can adopt alternative orientations. For example, the label may be oriented so that it is orthogonal to the long axis of the corresponding bounding box. FIG. 17D illustrates the placement of a label in a rotated position. The layout style defines what text and images are created and how they are combined to make up the label when the given constraint is selected during annealing. FIG. 18 provides a number of exemplary layout styles. The layout style illustrated by FIG. 18A is a simple layout style in which the primary name for a street or highway is depicted. The layout style illustrated by FIG. 18B combines an arrow image with the primary name for a | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
