1. Field of the Invention
The present invention relates generally to display of maps in a user interface of a navigation system. In particular, the present invention is directed to providing varying perspective views of displayed maps according to the scale of the displayed map.
2. Description of the Related Art
Navigation systems are popularly used to guide travelers to destinations. Such systems are available built into vehicles or free-standing, to be moved from vehicle to vehicle; for use by drivers and/or pedestrians; as purpose-built devices or as applications on general-purpose devices such as personal digital assistants or mobile telephones; and as systems that are entirely self-contained or as systems that utilize a remote server to perform some or all of their calculations. We refer generally to these systems as “navigation systems.”
The designer of the user interface of a navigation system has a choice of many styles for map displays. For example, there is great variation in the choice of colors and line styles. Maps can be more or less detailed; that is, there may be a large number of features drawn in a map, or only the most important features. Separately, maps can be rendered at a variety of scales, from very large (very zoomed-in) scales, showing a map only a few tens or hundreds of meters across, to very small (very zoomed-out) scales, showing a whole country or continent on a single screen. On a given device, the user can typically select from a number of map scales. A map may be shown with north at the top of the display, so that the map looks similar to a map printed in an atlas, or it may be oriented with the traveler's current heading toward the top of the display, so that objects ahead of the traveler are above the traveler's location on the map, and so that objects to the left and right of the traveler are on the left and right sides of the map. The latter type of display is described in U.S. Pat. No. 4,914,605, incorporated by reference herein in its entirety.
Another choice the designer of a user interface makes is between a two-dimensional display and a perspective view. By a two-dimensional display we mean the type of map typically seen in an atlas or in a paper map of roads, namely, a representation presented as though the viewer of the map were directly over the area depicted and were looking straight down at the earth. A perspective view, by comparison, represents the view as seen by an imaginary viewer some distance above the earth and looking, not straight down, but rather at the horizon or else toward some other point not directly below the viewer. This type of display is described in U.S. Pat. No. 5,161,886, incorporated by reference herein in its entirety. The perspective view may be derived from truly three-dimensional data, so that the vertical dimension is represented accurately in the view. More often, the perspective view is effectively a perspective view of a flat map. That is, the perspective view is not a view that would be seen by a hypothetical viewer above actual terrain with varying elevations, but rather the view seen by a hypothetical viewer above a map which has been rendered as a straight-down view. (The latter is sometimes called a “2½-dimensional view”.) Navigation systems that offer a perspective view typically offer the same perspective at different scales. That is, the map is in effect rendered by rendering the map in various scales and orientations as a flat map, then producing a perspective view of that map, always from the same perspective.
It should be noted that in a perspective view, the scale varies from the foreground (the bottom of the image) to the background (the top of the image). The foreground of the map is necessarily more large-scale (zoomed in) than the background. As a result, if one is comparing a two-dimensional (straight-down) map at a given scale with a perspective view that has the same scale in the foreground, the perspective map will show features from a larger area of the earth because of the smaller scale in the background part of the view.
In navigation systems that offer perspective views, the user is often given a choice between a perspective view and a two-dimensional (straight-down) display. In some systems, display of very small-scale (zoomed-out) views requires more computation time or more input/output time than display of larger-scale (more zoomed-in) views. For this reason, in combination with the fact that perspective views inherently require retrieving data from a larger area of the map, some navigation systems offer perspective views only at the more large-scale (zoomed-in) view levels, and allow only two-dimensional (straight-down) displays at the smallest-scale (most zoomed-out) levels.
The present invention enables display of a digital map with gradually changing perspective. Digital map data is stored in a database of a navigation system, which may be a self-contained device, or a networked client-server system. In one embodiment the navigation system includes an optional radio for determining its current position. A perspective engine determines a perspective with which a requested map should be rendered, and then renders the map in that perspective. The rendered map is then displayed in a user interface.
Perspective engine selects from among possible foreshortening ratios depending on the selected map scale. In one embodiment, the perspective engine uses a fixed perspective view corresponding to each of a fixed set of scales. In alternative embodiments, there is a continuum of scales, and parameters are specified as functions of the scale, rather than as fixed values. In general, at smaller scales—that is, more zoomed-out—the displayed perspective appears to be more flat, as though looking straight down at the map. At larger scales—more zoomed-in—the map is displayed with increasing perspective. In some embodiments, once a threshold scale is reached, continuing to zoom in does not additionally increase the perspective; similarly, once a threshold zoomed-out scale is reached, the map continues to be displayed in a two-dimensional flat appearance.
The figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.
The present invention comprises a system and method for displaying maps that transition gradually between a perspective view and a two-dimensional view. This avoids the jarring user experience that otherwise occurs in systems where the display changes abruptly from perspective to two-dimensional, or vice versa.
There is a correspondence between display scales (zoom levels) and the perspective view. Accordingly, we begin with a description of the mathematics of a perspective projection.
As noted, the goal in this portion of our description is to draw so-called “2½-dimensional” maps, i.e., perspective views of flat maps in a valid, aesthetically pleasing way.
We assume the initial existence of the map as a two-dimensional map, scaled appropriately, on a “virtual screen”. We define a “reference point” on the virtual screen. All coordinates in the virtual screen will be measured relative to this reference point. That is, we consider the reference point to have coordinates (0, 0) in the virtual screen.
We also define a reference point in the screen to be drawn, which we call the “actual screen”, or, when there is no confusion, just the “screen”. We also measure coordinates in the actual screen relative to the reference point. That is, we consider the reference point to have coordinates (0, 0) in the actual screen, with x increasing to the right and y increasing in the upward direction.
Note that the coordinate system for the actual screen is likely not the coordinate system that the graphics package will be using for the actual screen in implementing the described invention. Our reference point will usually be at or near the center of the screen, for reasons described below. At the implementation level, the origin in the graphics package's model of the screen is usually in either the upper left or the lower left corner. Also, a graphics package often considers y to increase in the downward direction. It remains up to the implementer to convert between these two coordinate systems, which is a very easy task.
We construct the projection as follows: place the virtual screen, the actual screen, and the viewer's eye in a three-dimensional coordinate system, as illustrated in
The projection is then constructed as follows: For any point P in the virtual screen, we construct a line from P to E. We then project P to the point P′ at which this line intersects the actual screen (the xz plane).
Parameterization
Referring to
This places E at (0, −b, a), R at (0, c, 0), and R′ at (0, 0, z), for some unknown z, in the three-dimensional coordinate system. For brevity, henceforth we consider any set of three coordinates to be in the three-dimensional coordinate system, and any set of two coordinates to be in the coordinate system of the appropriate screen. Next we find the location of the reference point in the actual screen.
A basic observation in working out this and almost everything else about the perspective projection is that, for collinear points, the differences between the coordinates of pairs of the points are proportional. That is, if P0=(x0, y0, z0), P1=(x1, y1, z1), and P2=(x2, y2, z2) are collinear, we know that
Since E=(0, −b, a), R=(0, c, 0), and R′=(0, 0, z) are collinear, we can use the y and z terms of this identity to see that
Solving for z:
So that
Or
Now that we have located the reference point, the problem becomes one of mapping between an arbitrary point P=(x, y) in the virtual screen and its corresponding point P′=(x′, y′) in the actual screen. Because the reference points are offset with respect to the origin of the three-dimensional coordinate system, P is located at (x, y+c, 0) and P′ is located at
Because E, P, and P′ are collinear, we can use identity 1 above to determine that
Simplifying the rightmost term:
So equation 2 simplifies to
This is the equation that we use to derive everything else about the projection.
Projecting from the Virtual Screen to the Actual Screen
To find the point P′=(x′, y′) in the actual screen that corresponds to a point P=(x, y) in the virtual screen, we have to determine x′ and y′ in terms of x and y.
From equation 3, we know that
Solving for x′, we find that
Similarly, from equation 3, we know that
Solving for y:
Or
Projecting from the Actual Screen to the Virtual Screen
Conversely, to find the point P=(x, y) in the virtual screen that corresponds to a point P′=(x′, y′) in the actual screen, we have to determine x and y in terms of x′ and y′.
From equation 3, we know that
Solving for x, we find that
There are other ways to express the right-hand side of equation 6, but it's not clear that any of them are simpler.
To find y in terms of y′, we observe from equation 3 that
Solving for y:
Or
Now that the conversions above are known, we can set a, b, and c in order make the projection on the actual screen look as desired. The person requesting the map does not care about a, b, and c—she cares about things like the scale, the amount of foreshortening, and the location of the horizon. So, we proceed to specify a, b, and c in terms of those quantities.
The scale for the projected map can be specified by specifying the horizontal scale at the reference point R′. In order to know the scale at which to draw the map on the virtual screen, we have to know the relationship between the scale on the actual screen and the scale on the virtual screen at R′. In other words, we need to know the relative scale r0=∂x′/∂x at R′.
This value can be derived. From equation 3, we know that
That is,
Differentiate with respect to x:
But at R′, y=0, so
Once we have this relative scale r0, we determine the scale at which to draw the map on the virtual screen by taking the horizontal scale desired at the reference point and dividing it by r0. For example, to obtain a horizontal scale of 100 pixels/km at the reference point, we render the map on the virtual screen at a scale of 100/r0 pixels/km.
Specifying the scale is not enough to specify the appearance of the map. Even once the horizontal scale is fixed at the reference point, we can make the map look more or less foreshortened by moving the viewer's eye more or less far behind the screen, i.e. by making b larger or smaller.
Of course, specifying the location of the viewer's eye is not at all intuitive to someone requesting a map. What is likely to be much more intuitive is specifying a “foreshortening ratio”. We define the “foreshortening ratio” at a point—for example, at the reference point—to be the ratio of the vertical scale to the horizontal scale at that point. For example, a small circle on the virtual screen centered at the reference point will be projected to an ellipse on the actual screen (almost) centered at the reference point, with its axes parallel to the x′ and y′ axes. The foreshortening ratio is the ratio of the length of the vertical axis of the ellipse to the length of its horizontal axis. Mathematically, the foreshortening ratio at any point is
Let the foreshortening ratio at the reference point be called f0.
To apply a specified foreshortening ratio, we need to be able to find ∂y′/∂y at a specified point. From equation 3, we know that
Differentiating both sides with respect to y, we find that
That is,
But at the reference point, y=0, so that at the reference point
Combining this with equation 10, we find that
Some implementers may want to think in terms of an “angle of depression” α, the angle between the line from the viewer's eye E to the horizon and the line from E to the reference point R in the virtual screen, as illustrated in
Because this is also the angle between the line from E to R and the negative direction of y axis, it's easy to see that tan α=a/(b+c)=f0, the foreshortening ratio. So α=arctan f0. Because the implementer can easily use these conversions, henceforth we will discuss only the foreshortening ratio.
Given a, b, and c, the location of the horizon on the actual screen can be determined. The horizon is at the level of the viewer's eye. Its height above the reference point is therefore
Doing Away with Relative Scale
So far we have determined the relative scale r0, foreshortening ratio f0, and height h of the horizon in terms of a, b, and c:
But one of these things is not like the others. The person requesting the map really cares about the actual scale (pixels per unit distance), not the relative scale (pixels on the actual screen per pixel on the virtual screen). After all, we can always rescale the map drawn on the virtual screen appropriately. So far, therefore, we have two values f0 and h to set in order to specify a, b, and c.
This means that either (1) there is another degree of freedom in the appearance of the map that the user can specify, or else (2) there is redundancy in the values of a, b, and c, and we can specify one of them at our whim and still produce a map with the same appearance. In the latter case, then we can specify a value of, for example, c and a different scale in the virtual screen, and obtain exactly the same projection on the actual screen.
To illustrate, fix values for â, {circumflex over (b)}, and ĉ, then specify a, b, and c in such a way that the relative scale {circumflex over (r)}0=1 but such that the foreshortening ratio and the height of the horizon remain unchanged. We then rescale x and y appropriately, and see whether the projection comes out the same. If it does, that will indicate that we can set relative scale any way we like.
If
that forces ĉ=0. To keep the height of the horizon the same, we have to set ĥ=h, i.e.,
That determines the value of â.
To keep the foreshortening ratio {circumflex over (f)}0=f0, we must set
Solving for b,
To summarize: We define a new mapping with the parameters
We rescale the coordinates in the virtual screen by the original relative scale:
Then we apply the mapping to get a new {circumflex over (x)}′ and ŷ′. If they are the same as the original x′ and y′, then the mappings really are the same.
From equation 5, we know that
So the mapping of x to x′ matches. Now check the mapping of y. From equation 5, we know that
So the mapping of y to y′ matches as well.
If we use this reparameterization, with c=0, the picture actually ends up looking like that illustrated in
We have seen that the only degrees of freedom that we have in formulating the final mapping are the height of the horizon h and the foreshortening ratio f0, and that we can safely set c=0. That turns the relations in equations 12 into
r0=1
f
0
=a/b
h=a
Or, stating a and b in terms of f0 and h instead:
a=h
b=h/f
0 (13)
c=0
We can now express x′ and y′ in terms of x, y, h, and f0. From equations 4 and 5:
We can determine the inverse relations by solving directly, or by plugging into equations 6 and 8, as shown here:
Although parameterizing the projection in terms of the height h of the horizon above the reference point is useful and intuitive if the horizon is on the screen, it is sometimes desirable to use a different parameter when the screen layout is designed in such a way that the horizon is off the screen. We describe two alternatives to h.
The location of the horizon determines how quickly the foreshortening ratio changes with respect to the screen coordinate y′. Even when the horizon is not visible, the rate of change q of the foreshortening ratio with respect to y′ at the reference point is visible on the screen.
Determine the relationship between that rate of change q and f0 and h. From equation 15, we know that
Partially differentiating with respect to y,
From equation 14, we know that
Partially differentiating with respect to x,
As a result, in terms of f0, h, and y, at any point the foreshortening ratio is
However, to determine q=df/dy′, we need to express f in terms of y′. Using equation 17 to substitute for y,
As a result, it's easy to differentiate f with respect to y′:
It is therefore possible to parameterize the projection in terms of f0 and q instead of in terms of f0 and h, by setting h=−f0/q.
Another parameter that is useful in specifying a perspective view when the horizon is off the screen is the “vanishing point angle”. Imagine a straight line in the virtual screen (for example, a straight street) pointing directly from the reference point to the horizon. This line will have constant x=0 in the virtual screen, and x′=0 in the actual screen. Now consider another straight line, parallel to the first, which is projected onto the screen so that it hits the left edge of the screen at y′=0, i.e., on a level with the reference point. This projected line will make an angle with the edge of the screen that becomes smaller and smaller as the horizon moves farther and farther up (i.e., as h becomes greater and greater). We can specify the projection using this “vanishing point angle” φ.
It is possible to determine the relation between φ and h. Let the width of the screen be w. Consider the triangle formed by the left edge of the screen, the horizon, and the projected line. The top edge of the triangle—the part of the horizon between the extension of the left edge of the screen and the extension of the projected line—has length w/2. The left edge of the triangle—the extension of the left edge of the screen from the level of the reference point to the horizon—has length h. The angle between the left edge and the hypotenuse is φ. As a result,
So that
Projecting from Three Dimensions
Sometimes we want to project from a three-dimensional space, rather than a plane, onto the screen. From the projection from the plane, the extension to three dimensions is straightforward.
As noted, we can, without loss of generality, set c=1 and thereby set the relative scale r0=1. That will make the algebra of the projection from three dimensions much simpler.
Refer now to
Setting c=0 and using (x, y, z) instead of (x, y+c, 0) as the coordinates of P, equation 2 turns into
Simplifying, this becomes
Solving for x′ and y′, we find that
—which is unchanged from before—and that
so that
If we want to express the projection equations in terms of h and f0 instead of in terms of a and b, we can use equations 13, which turns equations 19 and 20 into
Unfortunately, when it comes to performing the reverse projection from (x′, y′) in the actual screen to (x, y, z) relative to the virtual screen, there is insufficient information to determine x, y, and z. Solving equation 19 for x, y, and z amounts to solving two equations in three unknowns. We can do it if we know one of x, y, and z, but not otherwise.
It is possible to define a, b, and c (or alternatively r0, h, and f0), so that the foreshortening ratio at the bottom of the screen becomes greater than 1, that is, so that a tiny circle on the virtual screen is elongated into an ellipse with the long axis vertical. Many viewers find this unattractive and puzzling. It is therefore advisable to set the projection parameters so that the foreshortening ratio remains less than 1 even at the bottom of the screen.
From equations 9 and 11, the partial derivatives
at a general point are
This means that the foreshortening ratio f at a general point is
But we need this in terms of y′. Fortunately, we know from equation 7 that
So at a general point
We would like to find the values of y′ for which f<1. Solving the inequality for y′ yields
We also need to express this condition in terms of h and f0 for the projection parameterized by those values. Using equations 13, the inequality above becomes
For aesthetic purposes, a, b, and c, or alternatively h and f0, should be set so that the coordinate y′ at the bottom of the actual screen satisfies the appropriate inequality above.
To summarize the discussion above, and with reference to
First, set 902 the mapping parameters. Specify the foreshortening ratio f0 at the reference point and the height h of the horizon above the reference point on the screen.
Next, project 904 the map onto the virtual screen. Use the scale, in pixels/km or whatever units are desired, to be applied at the reference point on the screen. Orient the map with the positive y axis pointing in whatever compass direction to be at the top of the screen. Place the longitude and latitude meant to be at the reference point at the origin (0, 0) of the virtual screen.
Next, project 906 the virtual screen onto the actual screen. For each point (x, y) on the virtual screen, find the corresponding point (x′, y′) on the actual screen using equations 14 and 15, repeated here:
If necessary, project 908 the actual screen back to the virtual screen. It may be necessary to map coordinates (x′, y′) on the actual screen—for example, points selected with mouse clicks—back into coordinates (x, y) on the virtual screen using equations 16 and 17, repeated below:
In one embodiment, the navigation system 100 displays maps using only a fixed set of scales, and there is a fixed perspective view corresponding to each scale. That is, there is a table of the following form:
Note that a foreshortening of 1 and a rate of change of foreshortening of 0 denotes a two-dimensional, i.e., straight-down view. The usual formulas for a perspective projection break down at these values, but the view is simply the standard straight-down view known to practitioners of the art.
There is no special preference for the values shown above. Rather, the above table is meant to exemplify the properties that the progression of values might have. For example, in one embodiment perspective engine 104 uses a scale such that at all scales less than that scale the perspective parameters are the same. Similarly, in one embodiment there is a scale such that at all scales greater than that scale the perspective parameters remain the same. In one embodiment, between those scales the foreshortening and the rate of change of foreshortening change in a regular manner. It is often aesthetically pleasing to have both parameters change linearly as a function of the logarithm of the scale.
In various embodiments, the navigation system 100 does not have a fixed set of scales at which it displays maps, but rather a continuum of scales. In some such embodiments, the parameters are specified as functions of the scale rather than as values in a table. For example, the parameters might be specified as follows:
In some embodiments, the progression of the projection values for the various map scales, whether a discrete set or a continuum, is fixed and not alterable as part of the user interface 102. In other embodiments, the user interface 102 allows the user to change the way in which the gradual change of projection values is accomplished.
While the present invention has been described above in particular detail with respect to a limited number of embodiments, other embodiments are possible as well. The particular naming of the components and their programming or structural aspect is not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, formats, or protocols. Further, the system may be implemented via a combination of hardware and software, as described, or entirely in hardware elements. Also, the particular division of functionality between the various system components described herein is merely exemplary, and not mandatory; functions performed by a single system component may instead be performed by multiple components. For example, the particular functions of the perspective engine 104 may be provided in many or one module.
The operations described above, although described functionally or logically, may be implemented by computer programs stored on one or more computer readable media and executed by a processor. Computer readable storage media include, for example, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.
Throughout the description, discussions using terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a particular computer system, or similar electronic computing device, that manipulates and transforms data representing or modeling physical characteristics, and which is represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The algorithms and displays presented above are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be modified by using the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the described method steps. The required structure for a variety of these systems will appear from the description above. In addition, the present invention is not described with reference to any particular programming language, any suitable one of which may be selected by the implementer.
Finally, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention.
This application claims the benefit of U.S. Provisional Application 61/041,594, filed on Apr. 1, 2008, incorporated by reference herein in its entirety.
Number | Date | Country | |
---|---|---|---|
61041594 | Apr 2008 | US |