US20130321400A1 - 3D Map Views for 3D Maps - Google Patents

Abstract

Some embodiments provide a non-transitory machine-readable medium that stores a program which when executed on a device by at least one processing unit provides different viewing modes for viewing a three-dimensional (3D) map. The program renders a first view of the 3D map for display in a first viewing mode based on a first set of map data. The program receives input to adjust the view of the 3D map. In response to the input, the program renders a second view of the 3D map for display in a second viewing mode based on a second set of map data different from the first set of map data.

Description

CLAIM OF BENEFIT TO PRIOR APPLICATIONS
• This application claims the benefit of U.S. Provisional Application 61/655,997, entitled “Route Navigating Method and Apparatus”, filed Jun. 5, 2012; U.S. Provisional Application 61/656,032, entitled “Camera Animation During Navigation”, filed Jun. 6, 2012. U.S. Provisional Application 61/656,043, entitled “Camera Animation During Navigation”, filed Jun. 6, 2012; U.S. Provisional Application 61/657,864, entitled “Route Navigating Method and Apparatus”, filed Jun. 10, 2012; U.S. Provisional Application 61/657,880, entitled “Generating and Presenting Immersive and Non-Immersive 3D Map Presentations for Browsing and Navigation”, filed Jun. 10, 2012; U.S. Provisional Application 61/699,855, entitled “Rendering Maps”, filed Sep. 11, 2012; U.S. Provisional Application 61/699,851, entitled “Voice Instructions During Navigation”, filed Sep. 11, 2012; and U.S. Provisional Application 61/699,862, entitled “Generating Map Data for Rendering”, filed Sep. 11, 2012. U.S. Applications 61/655,997, 61/656,032, 61/656,043, 61/657,864, 61/657,880, 61/699,855, 61/699,851, and 61/699,862 are incorporated herein by reference.
BACKGROUND
• Many map-based applications are available today are designed for a variety of different devices (e.g., desktops, laptops, tablet devices, smartphones, handheld global positioning system (GPS) receivers, etc.) and for various different purposes (e.g., navigation, browsing, sports, etc.). Most of these applications generate displays of a map based on map data that describes the relative location of streets, highways, points of interest, etc. in the map.
• The maps used in such applications are usually two-dimensional (2D) maps or three-dimensional (3D) maps. However, a large number of the applications use 2D maps due in part to the processing-intensive demands of viewing 3D maps. For the same reason, the applications that use 3D maps are often slow, inefficient, plain, and/or simple, to the point that renders the application useless.
BRIEF SUMMARY
• Some embodiments of the invention provide novel methods for generating and presenting immersive and non-immersive 3D map presentations for browsing and navigation. In some embodiments, the immersive and non-immersive 3D map presentations can be alternatively and/or sequentially displayed on a device (e.g., a mobile device) that has a touch-sensitive screen and a multi-touch interface that allow a user to interact with the presentations through touch and gestural inputs on the screen. In other embodiments, the presentations are provided on a device that does not have a touch-sensitive screen.
• In some embodiments described below, these 3D presentations are provided by an integrated mapping application that provides several useful modalities, such as location browsing, map searching, route identifying, and route navigation operations. However, in other embodiments, the mapping application does not employ all of these modalities. For instance, in some embodiments, the mapping application does not provide route navigation.
• In order to display immersive and non-immersive 3D map presentations, some embodiments have to generate a variety of tiles for client devices to render to generate roads, building, and surrounding scenery. In some embodiments, examples of such tiles include road and building tiles used for non-immersive 3D presentations, and navigation and building tiles used for immersive 3D presentations.
• Before generating these tiles, a set of servers has to generate the description of the road, building, and other geometries that are placed in each of the tiles. This task involves multiple sub-tasks such as (1) receiving map data from a variety of vendors, (2) processing such data to produce one dimensional (1D) roads, (3) smoothing the 1D road graphs, (4) defining data to specify junctions, (5) generating 2D road geometries and land cover, (6) smoothing the 2D road geometries, (7) generating data (e.g., estimated height data) regarding buildings, (8) using such data to define building geometries, (9) constructing road geometries details (such as islands, lane markings, and distances and land cover between road geometries), and (10) identifying geometry edge node characteristics and propagating such characteristics.
• Once generated on the mapping service side, the tiles are used by a mapping application on a client device to present 3D maps to users of the client devices. The mapping application of some embodiments uses a variety of novel techniques to present a 3D presentation of a map while the map is being browsed or while the map is providing a navigation presentation. For instance, the mapping application renders the 3D presentation from the vantage point of a virtual camera, and uses various methods for moving the virtual camera (i.e., moving the perspective rendering position) automatically in certain situations to achieve a desired 3D presentation. One such example occurs when the mapping application of some embodiments moves the position of the virtual camera from a perspective rendering position behind a current position of a moving device to a top-down view of the current position when the device is about to make a turn along a route. Another example is the zoom in/out animations that are provided, which show objects in the scene growing and shrinking with the zoom in operation and the zoom out operation.
• Also, in some embodiments, the mapping application provides two different types of 3D presentations—an immersive 3D presentation and a non-immersive 3D presentation. The immersive presentation in some embodiments not only displays more geometries but also displays more details for the geometries that are displayed in the non-immersive presentation. The mapping application also provides smooth transitions between the non-immersive and immersive presentations.
• To achieve such smooth transitions and generate other novel effects, the mapping application of some embodiments uses a novel image processing pipeline. This pipeline performs a variety of pre-load operations to download, retrieve and/or decompress map tiles that may be needed for a navigation presentation, to prepare its rendering pipeline for its rendering operations, and to prepare a duplicate pipeline to smoothly transition between the immersive and non-immersive 3D presentations.
• The preceding Summary is intended to serve as a brief introduction to some embodiments of the invention. It is not meant to be an introduction or overview of all inventive subject matter disclosed in this document. The Detailed Description that follows and the Drawings that are referred to in the Detailed Description will further describe the embodiments described in the Summary as well as other embodiments. Accordingly, to understand all the embodiments described by this document, a full review of the Summary, Detailed Description and the Drawings is needed. Moreover, the claimed subject matters are not to be limited by the illustrative details in the Summary, Detailed Description and the Drawings, but rather are to be defined by the appended claims, because the claimed subject matters can be embodied in other specific forms without departing from the spirit of the subject matters.
BRIEF DESCRIPTION OF THE FIGURES
• The novel features of the invention are set forth in the appended claims. However, for purposes of explanation, several embodiments of the invention are set forth in the following figures.
• FIG. 1 illustrates an example of a device that executes an integrated mapping application of some embodiments of the invention.
• FIG. 2 illustrates how the navigation application of some embodiments provides a 3D control as a quick mechanism of entering a 3D navigating mode.
• FIG. 3 presents a simplified example to illustrate the concept of a virtual camera.
• FIG. 4 illustrates the adjustment of the distance of a virtual camera by contracting and expanding gestures.
• FIG. 5 illustrates an embodiment of a camera the angle of which can be adjusted by gestures.
• FIG. 6 conceptually illustrates the mapping service processing of some embodiments.
• FIG. 7 conceptually illustrates a process of some embodiments for generating a road graph.
• FIG. 8 illustrates various data structures of some embodiments for the roads within a map region.
• FIG. 9 illustrates an example of a modification for two road segments that meet at a junction.
• FIG. 10 illustrates an example of three road segments that are candidates for aggregation into a road at a junction.
• FIG. 11 illustrates a situation in which a first road segment is intersected (in a plane) by a second road segment and a third road segment.
• FIG. 12 illustrates two road segments that are a distance X apart, run parallel in opposite directions, and have the same name.
• FIGS. 13 and 14 illustrate similarly kinked roads that have speed limits of 25 mph and 60 mph.
• FIG. 15 conceptually illustrates a process of some embodiments for generating the road geometry to be used for generating road polygons on the client mapping application.
• FIG. 16 illustrates an operation performed to smooth a lane expansion junction in which one of the sides of the roads stays straight (i.e., is “justified”).
• FIG. 17 illustrates the result of the smoothed lane expansion fromFIG. 16 as rendered by a client mapping application of some embodiments.
• FIG. 18 illustrates an operation performed to smooth a lane expansion junction in which the road expands at both sides.
• FIG. 19 illustrates the result of the smoothed lane expansion fromFIG. 18 as rendered by a client mapping application of some embodiments.
• FIG. 20 illustrates a tapering operation performed to smooth a corner between road segment geometries when the angle between the segments is greater than a first threshold angle.
• FIG. 21 illustrates the result of the smoothed junction fromFIG. 20 as rendered by a client mapping application of some embodiments.
• FIG. 22 illustrates a projection operation performed to smooth a corner between road segment geometries when the angle between the segments is less than a first threshold angle and greater than a second threshold angle.
• FIG. 23 illustrates the result of the smoothed junction fromFIG. 22 as rendered by a client mapping application of some embodiments.
• FIG. 24 illustrates a clipping operation performed to eliminate excess road for road segment geometries when the angle between the segments is less than a first threshold angle and greater than a second threshold angle.
• FIG. 25 illustrates an intersection operation performed to smooth a corner between two road segment geometries.
• FIG. 26 illustrates the result of the smoothed junction fromFIGS. 24 and 25 as rendered by a client mapping application of some embodiments.
• FIG. 27 illustrates a tapering operation performed to smooth a corner between road segment geometries in situations that fit characteristics of freeway on-ramps in some embodiments.
• FIG. 28 illustrates the result of the smoothed freeway merge junction fromFIG. 27 as rendered by a client mapping application of some embodiments.
• FIG. 29 illustrates the generation of additional geometries at a junction in order to create more realistic, rounded corners at the junction.
• FIG. 30 illustrates the result of the smoothed intersection fromFIG. 29 as rendered by a client mapping application of some embodiments.
• FIG. 31 illustrates pushing two roads apart when they overlap.
• FIG. 32 illustrates reducing the widths of two road segments when the road segments overlap.
• FIGS. 33 and 34 illustrate dual carriageways with two different types of medians.
• FIG. 35 illustrates an example of geometries for a junction of two major arterial roads.
• FIG. 36 illustrates the result of the junction fromFIG. 35 as rendered by a client mapping application of some embodiments.
• FIG. 37 illustrates an example of the use of vertex annotation to specify bridge casing for an overpass, where one road travels over another road and the roads do not form a junction.
• FIG. 38 illustrates the result of the road segments ofFIG. 37 as rendered by a client mapping application of some embodiments.
• FIG. 39 illustrates an example of the use of vertex annotation to specify an edge of a road segment geometry as an interior edge, indicating that no casing should be drawn for the directed edge from the annotated vertex.
• FIG. 40 illustrates the result of the road segments ofFIG. 39 as rendered by a client mapping application of some embodiments.
• FIG. 41 illustrates an example of the use of vertex annotation to specify a tunnel for a road segment, indicating that the tunnel should be drawn over the road segment.
• FIG. 42 illustrates the result of the road segments ofFIG. 41 as rendered by a client mapping application of some embodiments.
• FIG. 43 illustrates an example of the use of vertex annotation to specify a sidewalk for a side of a road segment.
• FIG. 44 illustrates the result of the road segment ofFIG. 43 as rendered by a client mapping application of some embodiments.
• FIG. 45 illustrates an example of the use of several annotations for a single vertex of some embodiments.
• FIG. 46 illustrates the result of the road segments ofFIG. 45 as rendered by a client mapping application of some embodiments.
• FIG. 47 illustrates an example of using vertex annotation data to vary a property of the road casing for a road geometry.
• FIG. 48 illustrates the result of the road segment ofFIG. 47 as rendered by a client mapping application of some embodiments.
• FIG. 49 conceptually illustrates an operation performed by a mapping service of some embodiments to generate a route for a requesting device and provide the route, with navigation instructions, to the requesting device.
• FIG. 50 conceptually illustrates a process performed by the mapping service of some embodiments in order to generate and transmit route and intersection data to a user.
• FIG. 51 conceptually illustrates a process of some embodiments for determining path segments between sets of junctions that should be treated together as single intersections.
• FIG. 52 illustrates an example of a junction of some embodiments and shows that there is no requirement that the path segments meet at right angles or that the paths continue in a straight line through the junction.
• FIG. 53 illustrates an intersection of some embodiments that includes two dual carriageway paths and a one-way road.
• FIG. 54 conceptually illustrates a process of some embodiments for linking together several junctions into a single intersection and identifying the branches of the intersection.
• FIG. 55 illustrates a commonly existing intersection of some embodiments, between a dual carriageway with two paths and a dual carriageway with two paths.
• FIG. 56 illustrates an intersection of some embodiments in which left-turn channels are defined as separate path segments.
• FIG. 57 illustrates a slip road in an intersection of some embodiments.
• FIG. 58 illustrates an intersection of some embodiments with both a slip road and left-turn channels.
• FIG. 59 illustrates an additional two-way path in an intersection in some embodiments.
• FIG. 60 illustrates the reduction of an eight-path intersection into four branches in some embodiments.
• FIG. 61 illustrates the reduction of a different eight-path intersection into five branches in some embodiments.
• FIG. 62 conceptually illustrates an example of a data structure of some embodiments for a point type intersection.
• FIG. 63 conceptually illustrates a data structure of some embodiments for a roundabout intersection.
• FIG. 64 conceptually illustrates the reduction of a roundabout intersection to intersection data in some embodiments.
• FIG. 65 conceptually illustrates a process of some embodiments for modifying intersection data in order to provide navigation information for a route.
• FIG. 66 illustrates a conceptual drawing of a route taken through an intersection, a data structure for the intersection, and the modification of the data structure to create a new data structure for turn-by-turn navigation instructions.
• FIG. 67 conceptually illustrates a process performed by some embodiments of the invention perform for conflating land cover polygons to road polygons.
• FIG. 68 illustrates one example of conflating land covers to road polygons.
• FIG. 69 conceptually illustrates a process that conflates boundaries between adjacent polygons received from two different sources in some embodiments.
• FIG. 70 illustrates two stages of some embodiments of the invention that resolve identified gaps by conflating boundary coordinates between adjacent polygons.
• FIG. 71 illustrates two stages of some embodiments of the invention that conflate the boundary coordinates of polygons around identified overlaps.
• FIG. 72 conceptually illustrates a process performed by some embodiments of the invention for resolving border conflicts between regions.
• FIG. 73 illustrates an example of resolving a border conflict between two adjacent regions.
• FIG. 74 conceptually illustrates an example of a virtual camera automatedly moving around a region of a 3D map based on a route navigation according to some embodiments of the invention.
• FIG. 75 conceptually illustrates a process of some embodiments for animating map views during a route navigation.
• FIG. 76 conceptually illustrates an example of a virtual camera automatedly maneuvering a turn in a 3D map during on a route navigation according to some embodiments of the invention.
• FIG. 77 conceptually illustrates a process of some embodiments for animating a map view during a turn of a route navigation.
• FIG. 78 conceptually illustrates an example of a virtual camera panning around a 3D map during a route navigation according to some embodiments of the invention.
• FIG. 79 conceptually illustrates a process of some embodiments for panning to the side of a map view based on gesture input.
• FIG. 80 conceptually illustrates a perspective adjustment feature provided by a mapping application of some embodiments.
• FIG. 81 conceptually illustrates a process of some embodiments for adjusting the position of a virtual camera that is used for rendering a map view in response to a perspective adjustment.
• FIG. 82 conceptually illustrates a virtual camera that is moveable along different arcs at different zoom levels according to some embodiments of the invention.
• FIG. 83 conceptually illustrates a process of some embodiments for determining an arc along which a virtual camera is movable.
• FIG. 84 conceptually illustrates a feature provided by the mapping application of some embodiments for maintaining the position of a virtual camera within a defined range along an arc.
• FIG. 85 illustrates a zoom adjustment feature provided by the mapping application of some embodiments.
• FIG. 86 conceptually illustrates a process of some embodiments adjusting the position of a virtual camera that is used for rendering a map view in response to a zoom level adjustment.
• FIG. 87 conceptually illustrates a rotation operation of a 3D map view according to some embodiments of the invention.
• FIG. 88 conceptually illustrates a rotation operation of a 3D map view after an activation of a position indicator feature according to some embodiments of the invention.
• FIG. 89 conceptually illustrates a rotation operation of a 3D map view from a 2D perspective view of the 3D map according to some embodiments of the invention.
• FIG. 90 conceptually illustrates a process of some embodiments for rotating a map view based on gesture input.
• FIG. 91 conceptually illustrates an example of a mapping application of some embodiments that renders 3D map views for different zoom levels of different viewing modes.
• FIG. 92 illustrates the movement of the virtual camera around the region of a 3D map defined to be viewed by an immersive viewing mode of some embodiments.
• FIG. 93 illustrates the movement of the virtual camera around the region of a 3D map defined to be viewed by a non-immersive viewing mode of some embodiments.
• FIG. 94 conceptually illustrates an example of a mapping application of some embodiments that renders 3D map views for different zoom levels of different viewing modes.
• FIG. 95 conceptually illustrates a processing pipeline performed by the mapping application of some embodiments forrendering 3D map views based on different 3D map tiles.
• FIG. 96 conceptually illustrates a data structure used by the processing pipeline of some embodiments.
• FIG. 97 conceptually illustrates a state diagram of a mapping application of some embodiments.
• FIG. 98 conceptually illustrates a processing pipeline performed by the mapping application of some embodiments in order to render a map for display at the client device.
• FIG. 99 illustrates the application of different textures to different types of roads for some embodiments.
• FIG. 100 illustrates a map presentation that includes one arterial road and two connector roads.
• FIG. 101 illustrates a non-immersive map presentation illustrating the rendering of roads in a map tile, in map browsing view.
• FIG. 102 conceptually illustrates a controller that instantiates two virtual cameras for two different views of map regions.
• FIG. 103 conceptually illustrates a process of some embodiments for pre-loading navigation tiles to enter navigation.
• FIG. 104 illustrates a device that displays a mapping application as the application transitions from a non-immersive map view for map browsing into an immersive map view for navigation.
• FIGS. 105A-105B conceptually illustrate a state diagram10500 that describes different states and transitions between these states of the integrated mapping, search, and navigation application of some embodiments.
• FIG. 106 is an example of an architecture of a mobile computing device.
• FIG. 107 conceptually illustrates an example of an electronic system with which some embodiments of the invention are implemented.
• FIG. 108 illustrates a map service operating environment, according to some embodiments.
DETAILED DESCRIPTION
• Some embodiments of the invention provide novel methods for generating and presenting immersive and non-immersive 3D map presentations for browsing and navigation. In some embodiments, the immersive and non-immersive 3D map presentations can be alternatively and/or sequentially displayed on a device (e.g., a mobile device) that has a touch-sensitive screen and a multi-touch interface that allow a user to interact with the presentations through touch and gestural inputs on the screen. In other embodiments, the presentations are provided on a device that does not have a touch-sensitive screen.
• In some embodiments described below, these 3D presentations are provided by an integrated mapping application that provides several useful modalities, such as location browsing, map searching, route identifying, and route navigation operations. However, in other embodiments, the mapping application does not employ all of these modalities. For instance, in some embodiments, the mapping application does not provide route navigation.
• In order to display immersive and non-immersive 3D map presentations, some embodiments have to generate a variety of tiles for client devices to render to generate roads, building, and surrounding scenery. In some embodiments, examples of such tiles include road and building tiles used for non-immersive 3D presentations, and navigation and building tiles used for immersive 3D presentations.
• Before generating these tiles, a set of servers has to generate the description of the road, building, and other geometries that are placed in each of the tiles. This task involves multiple sub-tasks such as (1) receiving map data from a variety of vendors, (2) processing such data to produce one dimensional (1D) roads, (3) smoothing the 1D road graphs, (4) defining data to specify junctions, (5) generating 2D road geometries and land cover, (6) smoothing the 2D road geometries, (7) generating data (e.g., estimated height data) regarding buildings, (8) using such data to define building geometries, (9) constructing road geometries details (such as islands, lane markings, and distances and land cover between road geometries), and (10) identifying geometry edge node characteristics and propagating such characteristics.
• Once generated on the mapping service side, the tiles are used by a mapping application on a client device to present 3D maps to users of the client devices. The mapping application of some embodiments uses a variety of novel techniques to present a 3D presentation of a map while the map is being browsed or while the map is providing a navigation presentation. For instance, the mapping application renders the 3D presentation from the vantage point of a virtual camera, and uses various methods for moving the virtual camera (i.e., moving the perspective rendering position) automatically in certain situations to achieve a desired 3D presentation. One such example occurs when the mapping application of some embodiments moves the position of the virtual camera from a perspective rendering position behind a current position of a moving device to a top-down view of the current position when the device is about to make a turn along a route. Another example is the zoom in/out animations that are provided, which show objects in the scene growing and shrinking with the zoom in operation and the zoom out operation.
• Also, in some embodiments, the mapping application provides two different types of 3D presentations—an immersive 3D presentation and a non-immersive 3D presentation. The immersive presentation in some embodiments not only displays more geometries but also displays more details for the geometries that are displayed in the non-immersive presentation. The mapping application also provides smooth transitions between the non-immersive and immersive presentations.
• To achieve such smooth transitions and generate other novel effects, the mapping application of some embodiments uses a novel image processing pipeline. This pipeline performs a variety of pre-load operations to download, retrieve and/or decompress map tiles that may be needed for a navigation presentation, to prepare its rendering pipeline for its rendering operations, and to prepare a duplicate pipeline to smoothly transition between the immersive and non-immersive 3D presentations.
• Section I below describes the mapping application of some embodiments of the invention. Section II then describes server side operations for generating the tiles needed to produce immersive and non-immersive 3D presentations. Section III then describes client side operations for generating immersive and non-immersive 3D presentations. Section IV then describes electronic devices that employ the mapping application of some embodiments. Section V lastly describes location services uses by some embodiments of the invention.
• In the following detailed description of the invention, numerous details, examples, and embodiments of the invention are set forth and described. However, it will be clear and apparent to one skilled in the art that the invention is not limited to the embodiments set forth and that the invention may be practiced without some of the specific details and examples discussed.
I. Navigation User Interface
• A. Start
• The navigation application of some embodiments is part of an integrated mapping application that includes several useful modalities, including location browsing, map searching, route identifying and route navigating operations. This integrated application (referred to below as the mapping application, the navigation application or the integrated application) in some embodiments is defined to be executed by a device that has a touch-sensitive screen that displays the output of the application. In some embodiments, this device has a multi-touch interface for allowing a user to provide touch and gestural inputs through the screen to interact with the application. Examples of such devices are smartphones (e.g., iPhone® sold by Apple Inc., phones operating the Android® operating system, phones operating theWindows 8® operating system, etc.).
• FIG. 1 illustrates an example of adevice100 that executes an integrated mapping application of some embodiments of the invention. This figure also illustrates an example of launching a route navigation in this application. This application has a novel user interface (UI) design that seamlessly and cohesively integrates the controls for each of its different modalities by using a minimum set of on-screen controls that float on top of the content in order to display as much of the content as possible. Additionally, this cluster adapts to the task at hand, adjusting its contents in an animated fashion when a user moves between the different modalities (e.g., between browsing, searching, routing and navigating). This common element with an adaptive nature enables the mapping application to optimize for different tasks while maintaining a consistent look and interaction model while moving between those tasks.
• FIG. 1 shows sixstages105,110,115,117,119,121 of interaction with the mapping application. Thefirst stage105 shows a device'sUI120, which includes several icons of several applications in adock area125 and on a page of the UI. One of the icons on this page is the icon for themapping application130. The first stage shows a user's selection of the mapping application through touch contact with the device's screen at the location of this application on the screen.
• Thesecond stage110 shows the device after the mapping application has opened. As shown in this stage, the mapping application's UI has a starting page that in some embodiments (1) displays a map of the current location of the device, and (2) several UI controls arranged in atop bar140, and as floating controls. As shown inFIG. 1, the floating controls include anindicator145, a3D control150, and apage curl control155, while thetop bar140 includes adirection control160, asearch field165, and abookmark control170.
• In some embodiments, a user can initiate a search by tapping in thesearch field165. This directs the application to present an animation that (1) presents an on-screen keyboard and (2) opens a search table full of invaluable completions. This table has some important subtleties. When the search field is tapped and before the terms are edited, or when the search field is empty, the table contains a list of “recents,” which in some embodiments are recent searches and route directions that the user has requested. This makes it very easy to quickly bring up recently accessed results.
• After any edit in the search field, the table is filled with search completions both from local sources (e.g., bookmarks, contacts, recent searches, recent route directions, etc.) and remote servers. The incorporation of the user's contact card into the search interface adds additional flexibility to the design. When showing recents, a route from the current location to the user's home is always offered in some embodiments, while it is offered in the contexts that are deemed to be “appropriate” in other embodiments. Also, when the search term matches at least part of an address label (e.g. ‘Wo’ or ‘ork’ for ‘Work’), the application presents the user's labeled address as a completion in the search table in some embodiments. Together these behaviors make the search UI a very powerful way to get results onto a map from a variety of sources. In addition to allowing a user to initiate a search, the presence of the text field in the primary map view in some embodiments also allows users to see the query corresponding to search results on the map and to remove those search results by clearing the query.
• The bookmark control170 (e.g., button) allows locations and routes to be bookmarked by the application. Theposition indicator145 allows the current position of the device to be specifically noted on the map. Once this indicator is selected once, the application maintains the current position of the device in the center of the map. In some embodiments, it can also identify the direction to which the device currently points.
• The3D control150 is a control for viewing a map or inspecting a route in three dimensions (3D). The mapping application provides the 3D control as a quick mechanism of getting into and out of 3D. This control also serves as (1) an indicator that the current view is a 3D view, (2) an indicator that a 3D perspective is available for a given map view (e.g., a map view that is zoomed out might not have a 3D view available), (3) an indicator that a 3D perspective is not available (e.g., the 3D data is not available for the map region), and (4) an indicator that a flyover animation is available at the given zoom level. The 3D control may provide a different appearance corresponding to each indication. For instance, the 3D control may be colored grey when the 3D view is unavailable, black when the 3D view is available but the map is in the 2D view, and blue when the map is in the 3D view. In some embodiments, the 3D control changes to an image of a building when the flyover animation is available for the user's given zoom level and location on the map.
• Thepage curl control155 is a control that allows the application to minimize the number of on-screen controls, by placing certain less frequently used actions in a secondary UI screen that is accessible through the “page curl” control that is displayed on the map. In some embodiments, the page curl is permanently displayed on at least some of the map views that the application provides. For instance, in some embodiments, the application displays the page curl permanently on the starting page (illustrated in second stage110) that it provides for allowing a user to browse or search a location or to identify a route.
• Thedirection control160 opens adirection entry page180 through which a user can request a route to be identified between a starting location and an ending location. Thethird stage115 ofFIG. 1 illustrates that the selection of thedirection control160 opens thedirection entry page180, which is shown in thefourth stage117. The direction control is one of three mechanisms through which the mapping application can be directed to identify and display a route between two locations; the two other mechanisms are (1) a control in an information banner that is displayed for a selected item in the map, and (2) recent routes identified by the device that are displayed in thesearch field165. Accordingly, the information banner control and thesearch field165 are two UI tools that the application employs to make the transition between the different modalities seamless.
• Thefourth stage117 shows that thedirection entry page180 includes starting and ending fields for providing starting and ending locations for a route, and a table that lists recent routes that the application has provided to the user. Other controls on this page are controls for starting a route, for reversing the order of the start and end locations, for canceling the direction request, and for picking walking, auto, or public transit routes. These controls and other aspects of the mapping application are described in U.S. Provisional Patent Application 61/656,080, entitled “Integrated Location Browsing, Map Searching, Route Identifying, and Route Navigating Application”, filed Jun. 6, 2012; U.S. Provisional Patent Application 61/699,841, entitled “Problem Reporting”, filed Sep. 11, 2012; and concurrently filed U.S. patent application Ser. No. ______, entitled “Problem Reporting in Maps”, having Attorney Docket No. APLE.P0423. The Provisional Applications 61/656,080 and 61/699,841, as well as the concurrently filed patent application mentioned above, are incorporated herein by reference.
• The fourth stage illustrates the user selecting one of the recent directions that was auto-populated in the table182. Thefifth stage119 then shows three routes on a 2D map view between the specified start and end locations specified through thepage180. It also shows the selection of the second route and some information about this route in a bar at the top of the layout. This bar is shown to include start and end buttons. The start button is shown to be selected in the fifth stage.
• As shown by the sixth stage, the selection of the start button directs the application to enter a turn-by-turn navigation mode. In this example, the application has entered a 2D turn-by-turn navigation mode. In other embodiments, the application will enter by default into a 3D turn-by-turn navigation mode. In this mode, the application displays arealistic sign184 that identifies the distance from the current location of the device to the next maneuver in the navigated route and some other pertinent information. The application also displays a top bar that includes some information about the navigation as well as End and Overview buttons, for respectively ending the navigation and obtaining an overview of the remaining portion of the navigated route or the entire portion of the navigated route in other embodiments.
• The mapping application of some embodiments identifies the location of the device using the coordinates (e.g., longitudinal, latitudinal, and latitudinal coordinates) in the GPS signal that the device receives at the location of the device. Alternatively or conjunctively, the mapping application uses other methods (e.g., cell tower triangulation) to compute the current location. When the user carrying the device deviates from the route, the mapping application of some embodiments tracks the location of the device and re-calculates a new route from the deviated location in order to re-direct the user to the destination location from the deviated location. In other words, the mapping application of some embodiments operating in the navigation mode requires the device to be located along a route at all times.
• The application further displays the floating 3D control and the floating list control, which were described above. It should be noted that the list control was adaptively added to the floating control cluster upon entering the route inspection and route navigation modalities, while the position indicator was removed from the floating control upon entering the route navigation modality. Also, upon transition from the route inspection mode to the route navigation mode, the application performs an animation in some embodiments that involves the page curl uncurling completely before the application transitions into the navigation presentation.
• In some embodiments, the animation transition includes removing the top bar, its associated controls and the floating controls from the navigation presentation, and moving thesign184 to the top edge of the presentation a short time period after starting the navigation presentation. In some embodiments, the application requires the user to tap on the navigated map to bring back the top bar, its controls and the floating controls, and requires another tap to remove these controls again from the map. Other embodiments provide other mechanisms for viewing and removing these controls. The navigation user interface and other aspects of the navigation mode of some embodiments are described in greater detail in U.S. Provisional Patent Application 61/655,997, entitled “Route Navigating Method and Apparatus”, filed Jun. 5, 2012; U.S. Provisional Patent Application 61/657,864, entitled “Route Navigating Method and Apparatus”, filed Jun. 10, 2012; U.S. Provisional Patent Application 61/699,851, entitled “Voice Instructions During Navigation”, filed Sep. 11, 2012; and concurrently filed U.S. patent application Ser. No. ______, entitled “Context-Aware Voice Guidance”, having Attorney Docket No. APLE.P0395. The provisional applications 61/655,997, 61/657,864, and 61/699,851, as well as the above-mentioned concurrently filed patent application, are incorporated herein by reference.
• B. 2D and 3D Navigation
• The navigation application of some embodiments can display a map for navigation in either a 2D mode or a 3D mode. As mentioned above, one of the floating controls is the3D control150 that allows a user to view a navigation presentation in three dimensions (3D).FIG. 2 illustrates how the navigation application of some embodiments provides the3D control150 as a quick mechanism of entering a 3D navigating mode. This figure illustrates this operation in three stages205-215. Thefirst stage205 illustrates the user selecting the3D control150 while viewing a two-dimensional navigation presentation.
• Thesecond stage210 illustrates the navigation presentation in the midst of its transition into a 3D presentation. As shown in this figure, the 3D control appears highlighted at this stage to indicate that the navigation presentation has entered a 3D mode. In some embodiments, the navigation application generates the 3D view of the navigated map by rendering the map view from a particular position in the three dimensional scene that can be conceptually thought of as the position of a virtual camera that is capturing the map view. This rendering will be further described below by reference toFIG. 3.
• Thethird stage215 then illustrates the navigation presentation at the end of its transition into its 3D appearance. As shown by the difference between the heights of the buildings in the second and third stages, the transition from 2D to 3D navigation in some embodiments includes an animation that shows three dimensional objects in the navigated map becoming larger.
• 1. Virtual Camera
• The navigation application of some embodiments is capable of displaying navigation maps from multiple perspectives. The application can show maps in three dimensions (3D) or in two dimensions (2D). The 3D maps are generated simulations of a virtual scene as seen by a virtual camera.FIG. 3 presents a simplified example to illustrate the concept of avirtual camera312. When rendering a 3D navigation map, a virtual camera is a conceptualization of the position in the 3D map scene from which the device renders a 3D view of the scene.FIG. 3 illustrates a location in a 3Dnavigation map scene310 that includes four objects, which are two buildings and two intersecting roads. To illustrate the virtual camera concept, this figure illustrates three scenarios, each of which corresponds to a different virtual camera location (i.e., a different rendering position) and a different resulting view that is displayed on the device.
• Thefirst stage301 shows thevirtual camera312 at a first position pointing downwards at an angle (e.g., a 30° angle) towards the3D scene310. By rendering the 3D scene from the position and angle shown instage301 the application generates the3D map view318. From this position, the camera is pointing at a location that is a moving position in front of the device. Thevirtual camera312 is kept behind the current location of the device. “Behind the current location” in this case means backward along the navigation application's defined path in the opposite direction from the current direction that the device is moving in.
• Thenavigation map view318 looks as though it was shot by a camera from above and behind the device'slocation indicator316. The location and angle of the virtual camera places thelocation indicator316 near the bottom of thenavigation map view318. This also results in the majority of the screen being filled with the streets and buildings ahead of the present location of the device. In contrast, in some embodiments, thelocation indicator316 is in the center of the screen, with half of the screen representing things ahead of the device and the other half representing things behind the device. In order to simplify the figure, no road signs are depicted for theviews318,328, and338.
• Thesecond stage302 shows thevirtual camera312 at a different position, pointing downwards towards thescene310 at a larger second angle (e.g., a 45° angle). The application renders thescene310 from this angle, resulting in the 3Dnavigation map view328. The buildings and the roads are smaller than their illustration in the firstnavigation map view318. Once again thevirtual camera312 is above and behind thelocation indicator326 in thescene310. This again results in the location indicator appearing in the lower part of the3D map view328. The location and orientation of the camera also results again in the majority of the screen displaying things ahead of the car, which is what someone navigating needs to know.
• Thethird stage303 shows thevirtual camera312 at a top-down view that looks downwards on a location on a2D map345 that corresponds to the location in the3D map scene310 that was used to render the 3D views318 and328. The scene that is rendered from this perspective is the2D map view338. Unlike the 3D rendering operations of the first and second stages that in some embodiments areperspective 3D rendering operations, the rendering operation in the third stage is relatively simple as it only needs to crop a portion of the 2D map that is identified by a zoom level specified by the application or the user. Accordingly, the virtual camera characterization in this situation somewhat unnecessarily complicates the description of the operation of the application, as cropping a portion of a 2D map is not a perspective rendering operation.
• At thethird stage303, the mapping application in some embodiments switches from rendering a 3D scene from a particular perspective direction to cropping a 2D scene when the camera switches from the 3D perspective view to a 2D top-down view. This is because in these embodiments, the application is designed to use a simplified rendering operation that is easier and that does not generate unnecessary perspective artifacts. In other embodiments, however, the mapping application uses a perspective rendering operation to render a 3D scene from a top-down virtual camera position. In these embodiments, the 2D map view that is generated is somewhat different than themap view338 illustrated in thethird stage303, because any object that is away from the center of the view is distorted, with the distortions being greater the further the object's distance from the center of the view.
• Thevirtual camera312 moves along different trajectories in different embodiments. Twosuch trajectories350 and355 are illustrated inFIG. 3. In both these trajectories, the camera moves in an arc and rotates more downward as the camera moves upwards on the arc. Thetrajectory355 differs from thetrajectory350 in that in thetrajectory355 the camera moves further away from its point of focus (and the user's current location) as it moves up the arc.
• While moving along one of the arcs, the camera rotates to maintain a point ahead of the location indicator at the focal point of the camera. In some embodiments, the user can turn off the three dimensional view and go with a purely two dimensional view. For example, the applications of some embodiments allow a three dimensional mode to be turned on and off by use of a3D button360. The3D button360 is highly useful to the turn-by-turn navigation feature, where it has a role as an indicator and toggle. When 3D is turned off, the camera will maintain a 2D navigation experience, but when 3D is turned on, there may still be some top-down perspectives when 3D viewing angles don't make sense (e.g., when going around a corner that would be obstructed in 3D mode).
• 2. User Adjustment of Camera Height
• Besides (or instead of) having the navigation application control the camera (e.g., turning from 3D to 2D when going around corners) some embodiments also allow the user to adjust the level of the camera. Some embodiments allow the user to make a command gesture with two fingers to adjust the distance (height) and angle of the camera. Some embodiments even allow multiple types of gestures to control the camera.FIG. 4 illustrates the adjustment of the distance of a virtual camera by contracting and expanding gestures. The figure is shown in three stages. Instage401, the application shows abasic scene410 with avirtual camera412 at the default level for 3D viewing and thescreen view414 rendered from thescene410. The basic scene contains two buildings and a T-junction. Instage401, the buildings are viewed from a 45 degree downward angle and a particular height that makes them seem a particular size. Thelocation indicator416 is also shown at a particular size.
• Instage402, the user makes a gesture by placing two finger tips420 near each other on the screen of the device, on thescreen view424 and moving the fingertips apart while they are on the screen. Moving the fingertips420 apart has the effect of making the map (both the part between the fingers and the rest of the map) larger. In order to make the things in the map appear larger, the application causes thevirtual camera412 to zoom in. In some embodiments, theline450 along which the mapping application moves thevirtual camera412 is a line formed by the front of thevirtual camera412 and thevirtual camera412's point of focus. The mapping application of some embodiments moves thevirtual camera412 along a line formed by the front of thevirtual camera412 and a location in the3D map410 based on the user's input to zoom into (or out of) the view of the3D map410.
• After zooming in forstage402, the user decides to zoom out forstage403. In this stage the user has placed two fingers430 on the screen and brought them closer together. Bringing the fingers closer together has the effect of shrinking the map (both the part between the fingers and the rest of the map). The zoom-out adjustment is accomplished by moving thevirtual camera412 farther away from the3D map410 along theline455. In some embodiments, theline455 along which the mapping application moves thevirtual camera412 is a line formed by the front of thevirtual camera412 and thevirtual camera412's point of focus. The mapping application of some embodiments moves thevirtual camera412 along a line formed by the front of thevirtual camera412 and a location in the3D map410 based on the user's input to zoom into (or out of) the view of the3D map410.
• Rendering a 3D map view using thevirtual camera412 at this position results in a3D map view434 in which the buildings and the roads appear farther than the position illustrated in the3D map view424. As shown by the dashed-line version of thevirtual camera412, thevirtual camera412 moved farther from the3D map410 along theline455.
• In addition to being controllable by zooming in and out, some applications allow a user to change the angle of the virtual camera.FIG. 5 illustrates an embodiment of a camera the angle of which can be adjusted by gestures. The figure is shown in three stages501-503. Instage501, the camera is pointing downward at45 degrees atscene510.Scene510 contains two buildings and a T-junction which are shown inscreen view514. The buildings are shown from a particular angle and a particular size. Thelocation indicator516 is also shown at a particular size.
• Instage502, the user has placed twofingers520 on the screen approximately horizontal to each other and dragged up. This has the apparent effect of dragging the scene up with the fingers. The scene rising is accomplished by thevirtual camera512 lowering and changing its viewing angle from 45 degrees to 30 degrees. In thescreen view524, the buildings and the location indicator look taller than instage501.
• After the user drags the scene up instage502, the user then drags the scene down instage503. To do this, the user again places twofingers530 on the screen and drags downwards. This drags the scene down along with thefingers530. The scene dropping is accomplished by thevirtual camera512 rising and changing its angle with thescene510 to 60 degrees downward. Instage503, thecamera512 has moved farther up and is angled down more than instage501. Accordingly, the buildings and location identifier536 again look even shorter and smaller instage503 than instage501.
• In some embodiments, the mapping application provides an inertia effect for different operations (e.g. panning, rotate, entering from 2D to 3D). When a user provides a particular type of input (e.g., input that terminates at a velocity greater than a threshold velocity) to pan the 3D map, the mapping application generates an inertia effect that causes the 3D map to continue panning and decelerate to a stop. The inertia effect in some embodiments provides the user with a more realistic interaction with the 3D map that mimics behaviors in the real world.
• The application of some embodiments allows the distance and angle of the camera to be independently controlled. For example, it allows the distance to be controlled by the contracting and expanding finger gestures and the angle to be controlled by the dragging of horizontally placed fingers. Other embodiments use whichever gesture is being performed to set either a distance or an angle of the camera, with the other variable being set automatically. WhileFIGS. 4 and 5 show gestures performed in a certain direction leading to certain results, in some embodiments, one or both of these gestures could be reversed. For example, in some embodiments, dragging horizontally placed fingers down may bring the camera down rather than bringing the scene down. That would have the effect of moving the scene down when the fingers move up and moving the scene up when the fingers move down.
II. Server Side Generation of Map Tiles
• In order to display both immersive and non-immersive 3D map presentations, some embodiments have to generate a variety of tiles for client devices to render to generate roads, building, and surrounding scenery. In some embodiments, examples of such tiles include road and building tiles used for non-immersive 3D presentations, and navigation and building tiles used for immersive 3D presentations.
• Before generating these tiles, a set of servers has to generate the description of the road, building, and other geometries that are placed in each of the tiles. This task involves multiple sub-tasks such as (1) receiving map data from a variety of vendors, (2) processing such data to produce one dimensional (1D) roads, (3) smoothing the 1D road graphs, (4) defining data to specify junctions, (5) generating 2D road geometries and land cover, (6) smoothing the 2D road geometries, (7) generating data (e.g., estimated height data) regarding buildings, (8) using such data to define building geometries, (9) constructing road geometries details (such as islands, lane markings, and distances and land cover between road geometries), and (10) identifying geometry edge node characteristics and propagating such characteristics.
• The mapping service of some embodiments generates downloadable map tile data through offline processing of map data (e.g., data received from map vendors). In some embodiments, this offline processing takes map object location input (e.g., latitude/longitude data for roads, administrative boundaries, natural boundaries, etc.) and generates aggregated roads and relationships between the aggregated roads. From the aggregated roads and their relationships, the mapping service processing generates road geometries. The mapping service also generates geometries for land cover (e.g., parks, oceans, states, etc.) using the map object location input. Some embodiments use scalable distributed processing to create downloadable map tiles from the geometric vector data. One of ordinary skill in the art will recognize that the “offline” processing described in this application may be performed by mapping service computing devices that are in fact connected to the network through which the mapping application requests tile data, but is used to represent that the processing is not performed in response to user requests for tiles.
• FIG. 6 conceptually illustrates themapping service processing600 of some embodiments. As mentioned, some embodiments perform this processing offline to generate various map tiles which can then be sent to client devices in response to real-time requests. The processing may be performed on a regular basis (e.g., hourly, daily, weekly) or may be performed any time new data becomes available (e.g., updates received through providers of map data, corrections received from users, etc.).
• Themapping service processing600 includes a 1-D road processor605, aroad geometry generator610, a landcover geometry generator615, abuilding geometry generator617 and atile generator620. One of ordinary skill in the art will recognize that the various modular operations shown inFIG. 6 may all be performed on a single server or may be distributed across several computing devices. In fact, some of the operations (e.g., tile generation) may be performed as distributed processing operations that span multiple computing devices.
• In addition to the processing operations,FIG. 6 illustratesroad segment data625,land cover data630, andbuilding data633.Road segment data625 stores data defining the location and properties of roads. In some embodiments, each road segment is assigned one or more names (e.g. “Lincoln Blvd.”, “CA-1”), location data that indicates the path of the road segment, and attributes of the road segment (e.g., speed limit, width, number of lanes, road type, etc.). In some embodiments, the locations of junctions (also referred to as junctions) is part of the road segment data. Theland cover data630 stores data defining the location and properties of various types of non-road land cover. The land cover may include bodies of water (e.g., rivers, oceans, lakes, swimming pools, etc.), administrative bodies (e.g., boundaries of states, countries, cities, parks, etc.), area designations (e.g., rural/urban/suburban, desert/mountains/forest, etc.), or other data describing the land between roads. Thebuilding data633 of some embodiments stores the location of buildings as well as data about the buildings. For instance, the building data may include ground elevation data and surface elevation from which building height may be calculated.
• Theroad segment data625,land cover data630, andbuilding data635 may be received from a single source (e.g., a single vendor of map data) or several sources (e.g., several different vendors). For instance, a first vendor might provide road data for a first region while a second vendor provides road data for a second region, a third vendor provides land cover data for the first and second regions, and a fourth vendor provides elevation data (or other combinations, such as multiple different vendors of land cover data for different types of information).
• The 1-D road processor605 receivesroad segment data625 and generates one or more road graphs from the data. A road graph, in some embodiments, links together a set of road segments and junctions of road segments. To generate the road graph, the 1-D road processor605 identifies road segments that should be combined into aggregate roads (i.e., based on the names, start and end points, and common attributes of the segments). For example, when the end of a first segment shares a location with the start of a second segment, the segments have at least one name in common and the segments share at least some attributes, then theroad processor605 combines the segments into an aggregate road. The 1-D road processor additionally fills in data required for additional processing (e.g., elevation data, speed limit data, number of lanes) when this is missing from the road segment data.
• In addition to forming the aggregate roads, the 1-D road processor605 identifies and generates angle information for junctions of the roads (e.g., as described below) and identifies other relationships between roads (e.g., merging dual carriageways, establishing overlap relationships). A connected set of junctions and segments forms a road graph.
• Theroad geometry generator610 generates geometries for the roads (i.e., sets of vertices for drawing the roads at the client devices) based on the road graph using various processes. In some embodiments, theroad geometry generator610 grows road geometries out from the road centerlines (e.g., using lane #, width, and offset data), then performs various operations to refine the geometries. As examples, theroad geometry generator610 smoothes transitions between road segments with different numbers of lanes, creates more realistic rounded corners at intersections, smoothes road merges to remove excess road pieces and gaps between roads, and removes overlap between separate roads that do not intersect. In addition, in some embodiments theroad geometry generator610 assigns specific characteristics to the polygon vertices and/or edges, such as marking tunnel entries, marking road interior edges (e.g., between segments), marking sidewalks, and marking bridge casings where shadows should be drawn.
• The landcover geometry generator615 uses both theland cover data630 androad segment data625 in some embodiments to create the geometries (i.e., sets of vertices defining polygons) for the land cover. After growing geometries for the land cover, some embodiments use various operations to resolve boundaries between the geometries. For example, when combining data from different sources, the location data indicating object boundaries may not align perfectly and therefore there may be either gaps between the object geometries or overlap of the geometries. Some embodiments use different operations for resolving boundaries between different geometries, depending on the types of objects. In addition, the landcover geometry generator615 uses the road segment data to fill in the land cover geometry and ensure that gaps are not left between the land cover and the roads. Some embodiments grow the land cover geometries outside of their marked boundaries towards the roads, stopping the geometries at road centerline locations. While this creates an overlap between the land cover geometry and road geometry, in some embodiments the client mapping applications include instructions to render road geometry on top of land cover geometry.
• Thebuilding geometry generator617 of some embodiments generates building geometries using thebuilding data633. In some embodiments, as mentioned, thebuilding data633 includes ground elevation and surface elevation data, in addition to locations of the buildings. To generate building geometry, some embodiments calculate the building height for various points within the location of the building. Thebuilding geometry generator617 retrieves the ground elevation and subtracts this from the surface elevation data to calculate the building height. In other embodiments, the building geometry generator617 (or another module) uses 3D satellite data to calculate the height data. To calculate a height for the building as a whole, thebuilding geometry generator617 calculates an overall height as the mean of the various calculated heights at different points, plus a bias factor constant multiplied by the standard deviation of the point heights. The bias factor, in some embodiments, is a constant determined from ground truth (e.g., data determined at the actual location) and experiments.
• Some embodiments also determine whether the building is flat or non-flat (e.g., with a pointy roof). When the standard deviation of the point heights is above a threshold (which may also be based on ground truth and experiments), thebuilding geometry generator617 designates the roof as non-flat. When the standard deviation of the point heights is below the threshold, thebuilding geometry generator617 designates the roof as flat. When generating the geometry vertices, some embodiments create pointy roofs (e.g., triangular prisms or pyramids) for non-flat buildings.
• The road, land cover, and building geometries are sent to thetile generator620. In some embodiments, thetile generator620 creates several tiles for a map region, at different levels of detail (i.e., zoom levels). Some embodiments define the tile location boundaries for the different zoom levels (e.g., with a tile at a first zoom level containing four tiles at the next zoom level), then use distributed processing techniques to assign the different geometries (both roads and land cover) to the various tiles. After assigning the geometries to tiles (each geometry may be assigned to one or more tiles at each zoom level), thetile generator620 uses additional distributed processing to generate and compress the tiles. In some embodiments, map tiles contain vector data describing the polygons to generate for rendering the data as a 2D or 3D map. To reduce the amount of vector data (and thereby reduce the size of the files for easier transmission), some embodiments use a transient rasterization process that reduces the vector data to raster information, then revectorizes the data with fewer vertices.
• As shown, thetile generator620outputs tile data635 to storage. The storedtile data635 is the data accessed by client mapping applications in order for the applications to generate maps for viewing by a user. As shown, the tile data of some embodiments includesnon-immersive map tiles640,immersive map tiles645, buildingtiles650, andtraffic tiles655. Thenon-immersive map tiles640 andimmersive map tiles645 provide different levels of data. In some embodiments, the mapping application includes an immersive 3D view and a non-immersive 3D view, with the immersive 3D view providing additional detail (e.g., asphalt view of roads, more realistic land cover and buildings, closer simulation of driving view, etc.). Some embodiments use separate tile sets for the different views, with theimmersive map tiles645 including a greater level of detail about the roads and land cover. In addition to the road segment and land cover data, the map tiles may contain additional data. For instance, the tiles may include various sets of label data (e.g., road labels, place labels, land cover labels, etc.). As shown, thetile data635 also includes building tiles that indicate geometry for drawing buildings (based on the height and location information) in some embodiments, as well astraffic tiles655 that are updated regularly with traffic information. Some embodiments use the building tiles for both the immersive and non-immersive 3D views.
• A. Road Data and Road Graph Generation
• As stated above, some embodiments receive road segment data (i.e., from one or more sources) and generate a road graph from the road segments.FIG. 7 conceptually illustrates aprocess700 of some embodiments for generating a road graph. Theprocess700 will be described by reference toFIG. 8, which illustrates various data structures of some embodiments for the roads within a map region. These data structures, which will be described in greater detail below, includeroad segments800, edges805,roads810,junctions815, and aroad graph820.
• As shown, theprocess700 begins by receiving (at710) a set of road segments and junctions for a map region. In some embodiments, the process700 (or a similar road graph generation process) is run separately for different map regions (e.g., for states, rectangular geographic areas, land masses, etc.). The road segments for a map region may be received from a single source or from several different sources. In some embodiments, a road segment is a consistent stretch of road that has a single consistent set of attributes (i.e., same number of lanes, speed limit, etc.). When a road attribute changes (e.g., speed limit changes from 45 mph to 35 mph, or a lane is added), a new road segment is defined.
• The junctions for a map region are generally received from the same source as the roads that meet at the junctions. In some embodiments, a junction defines an intersection of at least two roads—i.e., that two or more road segments not only cross the same location (which can be determined from the road segment data) but also that the road segments actually intersect each other so that a vehicle can transition from one road segment to the other at the junction.
• FIG. 8 illustrates thedata structure800 of some embodiments for a road segment as well as thedata structure815 for a junction. As shown, the road segment includes a segment ID (i.e., a unique identification), one or more names, geometry information, and attribute information. The geometry information (which is different than the road geometries created for defining vector data) defines the path and other geometric information about a road segment. As shown, the geometry information includes centerline path data (e.g., an ordered string of coordinates that define the center of the road), start and end junction information, parameters to indicate the width and offset with respect to the centerline, and functionality enabling evaluation of the sides of the road at any point along the road segment. In some embodiments, this is a function on the road segment class that utilizes the centerline, offset, and width information to calculate the location of the sides of the road. While this diagram shows the road drawing data including start and end junctions, some embodiments do not define one as the start and one as the end, but rather simply indicate two junction IDs as endpoints (or a single junction ID if the road segment dead-ends).
• The attribute information describes metadata about the road segment, such as the road type (or functional road class, which defines the level of importance of a road, from freeway down to pseudopath), the number of lanes, the speed limit, the relative elevation of the road (which may contain references to one or more other road segments and/or junctions, indicating that the present road segment runs below or above the referenced object), the height of the road (relevant for identifying elevation), the form of way (which defines a path as a dual carriageway, single carriageway, walkway, stairs, connector road, slip road, etc.), restrictions (e.g., toll restrictions, vehicle type restrictions, indications that a road is private, etc.).
• In addition, as shown inFIG. 8, some embodiments define anedge805 for each road segment. An edge data structure contains a reference (e.g., a pointer) to a road segment to which the edge corresponds, an orientation flag that indicates whether the edge is oriented in the same direction as the road segment, and a functionality to calculate the right and left sides of the edge using the width and centerline data of the referenced road segment. In some embodiments, this functionality exists as a function on the edge class. The edges, in some embodiments, are data constructs used to create the road graph. For a road segment that has both a start and end junction, some embodiments define two edges (one in each direction), so that each junction can reference an edge leading out from the junction.
• As shown inFIG. 8, thejunction data structure815 includes a unique junction ID, an ordered list of edges with associated angles, a location, and an elevation order. While this data structure shows an edge list, some embodiments additionally include a list of road segments referred to by the segment IDs, from which the edge list is generated. In some embodiments, the junction ID, list of segment IDs, and elevation order are received from the road data source, while the angles and edge list are calculated by the mapping service. As each road segment is associated with one or more edges, the mapping service processing can determine the appropriate directed edges to list for the junction (the edges directed away from the junction). For many surface street junctions, the relative elevation is not especially meaningful, as the junction and all roads at the location will be at the same level. However, at intersections such as interchanges, or when a road segment passes under or over a freeway, the elevation order indicates which junctions are on top of other junctions and/or road segments.
• After receiving the road segments, the process defines (at710) a road graph for the map region from the road segments and junctions. As shown inFIG. 8, the roadgraph data structure820 includes a set of road segments and a set of junctions. In some embodiments, the application traverses the edges and junctions to identify connected sets of edges, then maps these edges to the road segments. Other embodiments use the start and end junctions stored in each of the road segments, and the list of segments stored for each junction to define the connectivity of the segments and junctions. Some embodiments define a single road graph for a map region. However, some embodiments will define multiple road graphs when there are multiple connected sets that do not intersect.
• Next, theprocess700 performs (at715) preprocessing on the road graph to align road segments at junctions. In order to identify angles of roads at junctions properly, and to generate polygon geometries for the roads, the roads intersecting at a junction should all end/start at exactly the same location. However, the road centerline for each of the segments that meet at a particular junction may not end at the exact same location in the received map data. Thus, for each junction, some embodiments calculate an average position of the segment path ends, and assign this position to the junction for its location. In addition, the mapping service processing modifies the road segment path data for each of the segments that meet at the junction so that the centerlines all end at the calculated average position.
• FIG. 9 illustrates an example of such a modification for tworoad segments905 and910 that meet at a junction, over twostages920 and930. As shown, each road segment includes a start junction and an end junction, with the end junction of thefirst road segment905 and the start junction of thesecond road segment910 being the same (both referring to a junction with an ID of 16). However, as shown in thefirst stage920, the centerline paths of thefirst road segment905 and thesecond road segment910 do not start/end at the same place (and, in fact, do not intersect at all). Thus, some embodiments identify the average position of the ends that should meet. For a junction with only two road segments, this location will be halfway along a line between the two path endpoints, as shown bylocation915 in the figure. Each of the ending vertices of the centerlines has a pair of coordinate values (e.g., (x,y) coordinate values, or geolocation coordinates (latitude, longitude)). Some embodiments calculate an average among all of the ending vertices for each coordinate, and use this as the average location for the junction.
• After identifying the junction location, the mapping service processing modifies the road segments so that the centerlines all end at the identified location. Thesecond stage930 shows one example of such a result. In some embodiments, when the road segments are received, the centerline paths may not have vertices at fixed distances. The mapping service processing of some embodiments standardizes the road segment vertices so that each vertex is at a fixed distance (e.g., 10 meters), enabling smoother (less kinked) road polygons. Some embodiments, for a particular road segment, identify a vertex a fixed distance from the end (e.g., 50 meters, 100 meters, etc.) and hold this point fixed, while modifying the other vertices between this point and the end vertex. In some embodiments, the vertices are moved by a lesser amount as they get further away from the endpoint. That is, a vector is calculated for the movement of the end vertex to the identified location, and the other vertices are moved by smaller iterations of this vector.
• With preprocessing complete, the process combines (at720) the road segments into aggregate roads. Some embodiments determine when road segments are in fact different portions of the same road, so that the segments can be treated as a single road for the purposes of defining a map (e.g., for generating labels) and for certain aspects of generating polygons for the roads. In some embodiments, the process uses various attribute and geometry data of the segments to determine whether two segments should be combined.
• Some embodiments traverse the road graph to combine the road segments into aggregate roads. While traversing the graph, entering a junction from a particular road segment, the mapping service processing determines which of the other segments is a best match to be a continuation of the current road segment. Some embodiments score each of the segments and aggregate the roads in a greedy fashion.
• To compute a score for a particular segment, the mapping service processing evaluates the difference in angle between the incoming road segment and the particular segment, the compatibility of the road segment names, and compares the road attributes. For the angle, the closer the segment is to 180° (i.e., a continuation straight through the junction), the higher the segment will generally score; typically, a road will continue straight or approximately straight through a junction, rather than turning. Some embodiments perform a fuzzy comparison between the road names associated with each segment. That is, the processing compares the string for the incoming road segment with the particular road segment using approximate string matching techniques. In some cases, one or more of the road segments may have multiple names, and the processing performs comparisons of each to find the best match or matches, and uses these best matches in computing the score (e.g., using the comparison of “San Diego Freeway South” to “San Diego Freeway South” rather than to “I-405 South”).
• In addition, at least some of the road attributes are compared to compute the comparison score in some embodiments. For instance, the mapping service processing of some embodiments compares the road type (i.e., highway, arterial road, minor road, etc.), number of lanes, speed limit, form of way (i.e., single carriageway, dual carriageway, etc.). Once the scores are computed, some embodiments select the segment with the highest score and determine whether it is above a threshold for continuing the road. In addition, some embodiments identify the selected best road segment, and perform a comparison between the selected road segment and each of the other segments. Only if a first segment is the best match for a second segment and the second segment is the best match for the first segment does the processing aggregate the roads. This prevents an incoming road segment that actually ends at a “T” intersection from being joined with one of the road segments that actually continues through the intersection.
• FIG. 10 illustrates an example of threeroad segments1005,1010, and1015 that are candidates for aggregation into a road at ajunction1020. As shown, thefirst segment1005 has the name “Wilshire Blvd”, a speed limit of 40 mph, and three lanes, and is an arterial road. Thesecond segment1010 also has the name “Wilshire Blvd” and three lanes, and is also an arterial road, but has a speed limit of 35 mph. Thethird segment1015 has the name “Saltair Ave”, a speed limit of 35 mph, and 2 lanes, and is characterized as a minor road. If the initial incoming segment is thethird segment1015, then thesegment1010 would be the higher-scoring road segment of the two possible continuations. However, for thesecond segment1010, thethird segment1015 will not be the optimal road continuation, as thefirst segment1005 will have a much higher continuation score (the angle, road name, road type, and number of lanes are the same, and the only difference is the 5 mph in speed limit). As such, the optimal result at thisjunction1020 is for the road of which thethird segment1015 is a part to terminate, with thefirst segment1005 andsecond segment1010 linked together as a single road. Other embodiments do not perform the reciprocity test, but instead set a high enough threshold that bad matches are unlikely. Furthermore, while traversing the road graph, some embodiments allow a segment to be moved from one aggregate road to another when a better match occurs later in the traversal (e.g., ifroad segment1015 is found to continue on intoroad segment1010, but then thejunction1020 is reached again viaroad segment1005, thesegment1010 may be moved from the first road to a new road that also containsroad segment1005.
• FIG. 8 illustrates aroad data structure810 of some embodiments. As shown, theroad data structure810 includes an ordered list of edges (through which the road object contains references to its constituent segments). In addition, the road structure contains functionality to evaluate the road centerline and the sides of the road at any point along the road. In some embodiments, the centerline functionality exists as a function of the road class that refers to the centerline information of the constituent segments (and may also interpolate between any slightly mismatched centerlines). The side of road functionality also exists as a function of the road class, that uses the side of road function from the road segment objects contained by the road object.
• Returning toFIG. 7, after combining the road segments, theprocess700 derives (at725) additional road description data. In some embodiments, this involves filling in missing data in the road segment information. As some embodiments implement the road segments (and other data) as objects, in some cases the object variables will have null values because the data has not been provided by the map data provider. For instance, speed limit data, road width, number of lanes, or other parameters may be missing. Some embodiments automatically fill in values for at least some of the missing data of a road segment when possible, either using other information from the road segment or information from neighboring road segments. For example, some embodiments might fill in missing speed limit information for a road segment based on the speed limits of the neighboring segments (e.g., if a first segment has a speed limit of 55 mph and a third segment has a speed limit of 35 mph, then the middle segment could be filled in with a 45 mph speed limit).
• Other embodiments only fill in data necessary for generating the road geometry, such as the number of lanes and road width information. For example, some embodiments may use neighboring road segments within an aggregated road to generate the number of lanes (e.g., if segments on either side of a particular segment have a particular number of lanes, that particular number of lanes may be assigned to the particular segment as well). For the road width, some embodiments use the number of lanes (if it exists) to assign a width to the road (e.g., assume that each lane is 4 meters wide). On the other hand, some embodiments assign road widths based on the road type (i.e., freeways have a first width, major arterials have a second width, etc.). In fact, some embodiments derive the number of lanes from the road type (e.g., freeways always assigned three lanes, etc.), then generate the width based on the number of lanes.
• In addition, some embodiments fill in missing data for height, or elevation, information. As described above, in some cases the map data specifically indicates that a particular road segment passes over (or under) another road segment, or over (or under) a junction, or that a particular junction passes over (or under) another junction. However, this relative elevation data may be missing in some cases. When a first segment (or junction) and second segment (or junction) have centerline paths that intersect in a flat plane, but for which no junction is defined, then the paths must be at different elevations. When the absolute elevation data is included from the map data provider, this data can be used to ascertain the relative elevation data (i.e., defining a relationship that a first segment with lower absolute elevation passes under a second segment with a higher absolute elevation.
• When relative elevation data cannot be ascertained for a particular set of road segments that intersect in the plane but do not meet at a junction, some embodiments create a random relative ordering for segments. In other embodiments, a likely relative ordering may be derived from road types of the non-intersecting roads, but may also use attributes of other nearby road segments.FIG. 11 illustrates a situation in which a first road segment1105 (“I-405N”) is intersected (in a plane) by a second road segment1110 (“Wilshire Blvd.”) and a third road segment1115 (“Main St.”). However, in this case the map data does not indicate any junctions between these road segments. The I-405N segment has a height of 1 while the Wilshire segment has a height of 0. However, the Main St. segment has a null height (i.e., this information is not provided). Based on the fact that the I-405N segment travels over the Wilshire Blvd. segment, some embodiments also assume that the I-405N will travel over Main St. As such, the mapping service operations automatically fill in the height of the road segment data structure for Main St. with a value of 0, or will fill in a relative ordering indicating that the segment of Main St. travels under the segment of I-405N.
• Additionally, theprocess700 establishes (at730) relationships between roads and road segments. In some embodiments, establishing relationships includes identifying semantic data, such as opposite sides of dual carriageway, and defining links between the related roads. In some embodiments, the process identifies roads containing road segments with the same or similar names (e.g., “I-5 N” and “I-5 S”), that are marked as dual carriageways (i.e., in a form of way field), and that are within a threshold distance of each other and a threshold angle of being parallel.FIG. 12 illustrates tworoad segments1205 and1210 that are a distance X apart, run parallel in opposite directions, and are both named “Main St.” Assuming that the distance X is less than the threshold distance for roads with the same name, then these roads will be linked as associated dual carriageways, and turns between the roads can be classified as U-turns rather than separate left turns. Additional semantic data that may be propagated includes assigning names to connector/slip roads (e.g., freeway entrances, freeway interchanges, right turn slip roads, etc.).
• Lastly, theprocess700 generates (at735) a smoothed version of the roads. In some embodiments, the centerline data may have noise. For instance, a five mile stretch of freeway may in actuality be straight, but the data may have slight back and forth in places. In addition, as the roads are defined as lines between centerline vertices, kinks might appear where the road has a smooth turn in reality. Furthermore, when road segments are joined at junctions, this may create sharp turns that should be smoother in reality. As this sort of noise is unwanted, some embodiments apply a smoothing operation, controlled by road properties, to the roads (e.g., either one road segment at a time, or to aggregate roads) in the road graph. To perform the smoothing, various different operations may be performed by different embodiments. Some embodiments use smoothing operations that move each vertex in the road a distance based on the locations of its neighbor vertices (e.g., Laplacian smoothing).
• Some embodiments allow more smoothing for faster roads, because of the expectation that these roads (e.g., freeways) will be smoother and less likely to have sharp angles. Some embodiments use the speed limit data to control the smoothing. For example, some embodiments allow different deviations of the centerline from the received vertex data for roads with different speed limits (e.g., allowing up to a 5 meter deviation forspeed limit65 roads, and a 2 meter deviation for 30 mph roads).FIG. 13 illustrates akinked road1310 that has a speed limit of 25 mph. The result of applying the smoothing operation to the road is illustrated as modifiedroad1320.FIG. 14, on the other hand, illustrates a similarly kinkedroad1410 with a speed limit of 60 mph. The result of applying a similar smoothing operation to the road is illustrated as modifiedroad1420. As shown, the modifiedroad1420 illustrates a greater level of curve smoothing because the speed limit of the road is larger. Some embodiments use other properties to modify the level of smoothing allowed, such as road types (which can serve as a proxy for speed limit).
• In addition, some embodiments limit smoothing in special cases. For instance, a road might make a 90° turn (e.g., where two roads both end at a junction in a residential neighborhood, and have been joined together). In such a case, rather than smoothing the road too much, some embodiments fix two points close to the junction (one on either side of the 90° turn) and smooth a small elbow between these two points.
• B. Generating Road Geometry
• After generating the road graph from road segments and junctions, aggregating roads in the road graph, filling in missing data, smoothing the aggregate roads, etc., the offline processing of the mapping service of some embodiments generates geometry for the roads in the road graph. In some embodiments, the geometry comprises a set of vertices that define the edges of polygons to be rendered by the client mapping application. These geometries are included in vector map tiles that are sent to devices running mapping applications in order for the mapping applications to render the resultant polygons. The mapping service processing initially bases the geometry off of the road segment definitions (i.e., the centerline vertices and width data), but also performs various adjustment operations on the geometry, such as smoothing the polygons to create more realistic rendered roads and intersections, eliminating overlaps, and annotating vertices with data that marks features to draw (e.g., shadows, bridge casings, curbs, sidewalks, tunnels, etc.).
• FIG. 15 conceptually illustrates aprocess1500 of some embodiments for generating the road geometry to be used for generating road polygons on the client mapping application. As with theprocess700, various embodiments perform theprocess1500 as an offline process that may be performed on a single computing device or distributed across several computing devices.
• As shown, theprocess1500 begins by receiving (at1505) a road graph for a map region. The road graph, as described above and shown inFIG. 8, is a connected set of road segments and junctions. In some embodiments, the process700 (or a similar road graph generation process) is run separately for different map regions (e.g., for states, rectangular geographic areas, land masses, etc.).
• Thegeometry generation process1500 generates (at1510) an initial polygon representation of the road segments in the road graph. Some embodiments expand the piecewise linear centerline representation (which should be reasonably smooth after inserting vertices at a regular distance and then smoothing these vertices, in a process such asprocess700 described above) into a polygon that follows the path of the road, having the width specified by its road segment data structure. The resulting polygon is, essentially, a structure with parallel sides that may appear to be curved. However, these polygons will need to be adjusted in many situations in order to generate a more realistic road animation.
• The polygon adjustment, in some embodiments, includes smoothing the polygons to create more realistic rendered roads and junctions, eliminating overlaps, and annotating vertices with data that marks features to draw (e.g., shadows, bridge casings, curbs, tunnels, etc.). The next several operations inprocess1500 describe these adjustment operations in a particular order. However, one of ordinary skill in the art will recognize that the once the initial polygons are grown, these operations may be performed in various different orders.
• Theprocess1500 adjusts (at1515) the geometries at junctions. In general, with the exception of overlaps between two or more geometries, the smoothing is primarily required at the junctions of the road graph. Within a road segment, the smoothing of the vertices described above should prevent any sort of obtrusions or irregularities. Some embodiments traverse the road graph and, at each junction, determine whether any modifications to the geometry are necessary to ensure a smooth, appealing rendered road at the client mapping application (and then make those modifications). These junctions may involve nothing more than a road continuing in a straight line where the speed limit changes (which will not involve any smoothing in some embodiments if the road width stays constant), but may also include freeway merges, roads intersecting at various angles, intersections between large and small roads (of which a freeway merge is one example), lane expansions, etc.
• The following will describe various types of these junction smoothing examples, along with figures for some of the examples. When a road expands or contracts its number of lanes, some embodiments perform a particular smoothing operation. In some embodiments, the mapping service processing first determines whether a junction includes only two edges, and then that those two edges are connected within a road. If this is the case, and the number of lanes changes, then some embodiments perform one of the following transition smoothing operations to prevent unnatural-looking sharp angles.
• FIG. 16 illustrates a first operation performed to smooth a lane expansion junction in which one of the sides of the roads stays straight (i.e., is “justified”), over three stages1610-1630. As shown in thefirst stage1610, in this example afirst road segment1605 connects into asecond road segment1615. Thefirst road segment1605 has data indicating that it has two lanes, while thesecond road segment1615 has data indicating that it has three lanes. In some cases, this data is indicated in the road segment data received from the map data provider. When the map data provider includes lane information, in some cases the provider additionally includes lane connectivity data. In some cases, the lanes are numbered (e.g., from left to right), and the connectivity data indicates which lane in a first segment (e.g., segment1605) continues into which lane in a second segment (e.g., segment1615). As shown in thefirst stage1610, in thiscase lane 1 of thefirst segment1605 continues intolane 1 of thesecond segment1615, whilelane 2 of the first segment continues into bothlanes 2 and 3 of the second segment. This indicates that the lane expansion occurs on the right side of the road (“right” based on the travel direction of the road). This lane connectivity data may be stored with the junction, or with one or both of the segments in various embodiments.
• Thesecond stage1620 illustrates the initially-grownsegment geometries1625 and1635 for the first and second road segments. As can be seen, thesecond segment geometry1635 is wider than thefirst segment geometry1625, and all of this additional width is at the right side of the road, with the left side of the road justified. When lane connectivity data is provided, some embodiments generate the geometry with the additional lane appearing in the correct location. However, when rendered using this geometry, the asphalt would appear to have a 90 degree angle, with the lane appearing out of nowhere. While occasionally freeway lanes do start in this manner, typically they expand smoothly out of the existing lane.
• Thus, some embodiments automatically taper the lane expansion, as shown in thethird stage1630. Some embodiments identify a point along the edge of the narrower segment geometry (the geometry with fewer lanes) and taper from this point to the start of the edge of the wider segment. Some embodiments use a fixed distance to identify the point (e.g., 25 meters, 50 meters, etc.). The taper may be a straight line, as shown, or a curve. In addition, some embodiments employ the transition within the wider geometry, or spread the transition across the two geometries.
• FIG. 17 illustrates theresult1700 of the smoothed lane expansion as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). For this figure, as well as a number of figures within this section, the result of specific road segments as rendered on a client mapping application are shown. In these figures, various controls and features that would typically be present in the mapping application display (e.g., a user location indicator (or navigation puck), a route line, additional land cover and building features, UI controls, etc.) are not displayed, so as to highlight the various aspects of the road segments. InFIG. 17, the asphalt makes a smooth transition from two to three lanes, and lane markings begin a bit before the lane is fully formed. As will be described below, some embodiments add road casing (e.g., curbs, guardrails, etc.) and lane markings. In different embodiments, the instructions for drawing the road casing may be communicated to the client mapping applications as additional geometries or as annotations to the geometry, with instructions for rendering based on the annotation stored at the client device.
• FIG. 18 illustrates a second operation performed to smooth a lane expansion junction in which the road expands at both sides, over three stages1810-1830. As shown in thefirst stage1810, in this example afirst road segment1805 connects into asecond road segment1815. In this case, there is no lane connectivity data, but thefirst road segment1805 has two lanes while thesecond road segment1815 has three lanes. The lane count data may be provided directly from the map provider, or derived from either the provided road width or the road type.
• Thesecond stage1820 illustrates the initially-grownsegment geometries1825 and1835 for the first and second road segments. As can be seen, thesecond segment geometry1835 is wider than thefirst segment geometry1825, with the additional width split between the two sides of the road. When no lane connectivity data is available, some embodiments use a default lane expansion that splits the difference between the two sides of the road. However, when rendered using this geometry, the asphalt would appear to have a 90 degree angle on either side. While occasionally freeway lanes might start in this manner, typically they expand smoothly out of the existing lane.
• Thus, some embodiments automatically taper the lane expansion on either side, as shown in thethird stage1830. Some embodiments identify, for each side of the road, a point along the edge of the narrower segment geometry and taper from this point to the start of the edge of the wider segment. Some embodiments use a fixed distance to identify the point (e.g., 25 meters, 50 meters, etc.). The taper may be a straight line, as shown, or a curve. In addition, some embodiments employ the transition within the wider geometry, or spread the transition across the two geometries.
• FIG. 19 illustrates theresult1900 of the smoothed lane expansion as rendered by a client mapping application (e.g., on the display of a portable device). The asphalt makes a smooth transition from two to three lanes. Some embodiments bend two of the lanes in one direction and add the new lane on the other side in order to keep the lane markings continuous in some embodiments (e.g., choosing a random side for the new lane, or using a default.
• The above examples are situations in which the junction in question only has two road segments. For junctions with three or more road segments, some embodiments identify special cases, and for other cases step through the list of road segments in the junction and perform corrections on geometries for subsequent pairs of roads. One such special case occurs when a bi-directional single carriageway road splits into a pair of corresponding dual carriageways. This often occurs when a median is introduced into a two-lane road (one lane in either direction). Some embodiments taper the road outwards (from the single carriageway to the dual carriageway) at the outer edges, and identify a merge point for the internal edges of the two dual carriageways. Some embodiments use lane information to determine the merge point (e.g., if one of the dual carriageways is one lane while the other is two lanes), while other embodiments use a default of a point at the center of the single carriageway, at its end.
• When stepping through the list of road segments at a junction, some embodiments perform different corrections based on the angle between two segments. Some embodiments select a first road segment of the junction, then correct the corner formed by the left side of the segment geometry (as viewed exiting the junction) with the right side of the segment geometry (as viewed exiting the junction) for a second segment directly counterclockwise from the first segment. The second segment is then set as the first segment, and the process repeated for the next corner, until all of the corners have been corrected.
• The following will describe various corrections performed for various junction angles, along with figures for some of the examples. These figures, though illustrating junctions with several road segments, show the geometries for only the two segment that are conformed to each other in the example.
• FIG. 20 illustrates a tapering operation performed to smooth a corner between road segment geometries when the angle between the segments is greater than a first threshold angle (e.g., 170°), over three stages2010-2030. In such a case, some embodiments automatically taper the side of one of the roads to meet the side of the other road. As shown in thefirst stage2010, in this example afirst road segment2005 intersects with asecond road segment2015 at a junction, as well as with twoadditional road segments2025 and2035.
• Thesecond stage2020 illustrates the initially-grownsegment geometries2040 and2045 for the tworoad segments2005 and2015. The geometries for the other two road segments are not illustrated in this figure, as the mapping service processing of some embodiments corrects one corner of the junction at a time, and this example illustrates the correction between thesegments2005 and2015. The mapping service processing of some embodiments would then perform a correction on the corner betweensegment2015 andsegment2025, a correction on the corner betweensegment2025 andsegment2035, and finally a correction on the corner betweensegment2035 andsegment2005. As shown at thissecond stage2020, the initial corner betweengeometry2040 andgeometry2045 involves a visually jarring (and unrealistic) discontinuity, owing in part to the roads having different widths (although some embodiments perform the same process for roads of the same width).
• Thus, some embodiments automatically taper the side of the narrower road segment to the side of the wider road segment, as shown by the modifiedgeometry2040 in thethird stage2030. In this case, because the wider segment is the more counterclockwise of the two road segments, the processing tapers the left side of the narrower segment to the right side of the wider segment (for this and subsequent examples, the “right” and “left” sides of a particular road segment are viewed from the perspective of a vehicle leaving the junction along the particular road segment). When the wider segment is the more clockwise of the two segments, the processing tapers the right side of the narrower segment to the left side of the wider segment. To perform the tapering operation, some embodiments fix a point along the side of the narrower segment geometry and taper from this point to the start of the side of the wider geometry. Some embodiments use a fixed distance to identify the point (e.g., 25 meters, 50 meters, etc.). The taper may be a straight line, as shown, or a curve. This operation is similar to the tapering illustrated inFIG. 16, and may also be performed when only two roads of different widths meet at a junction.
• FIG. 21 illustrates theresult2100 of the smoothed junction as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). The asphalt indicates a smooth right turn from the first road segment (shown at the bottom of the display) to the second, wider segment (shown at the top right of the display). In addition, the display includes asphalt (and lane markings, road casing, etc.) for the other two segments that form the intersection. In different embodiments, the instructions for drawing the road casing may be communicated to the client mapping applications as additional geometries or as annotations to the geometry, with instructions for rendering based on the annotation stored at the client device.
• FIG. 22 illustrates a projection operation performed to smooth a corner between road segment geometries when the angle between the segments is less than a first threshold angle and greater than a second threshold angle (e.g., between 120° and 170°), over three stages2210-2230. In such a case, some embodiments automatically project the side of one of the roads to meet the side of the other road. As shown in thefirst stage2210, in this example afirst road segment2205 intersects with asecond road segment2215 at a junction, as well as with twoadditional road segments2225 and2235.
• Thesecond stage2220 illustrates the initially-grownsegment geometries2240 and2245 for the tworoad segments2205 and2215. The geometries for the other two road segments are not illustrated in this figure, as the mapping service processing of some embodiments corrects one corner of the junction at a time, and this example illustrates the correction between thesegments2205 and2215. The mapping service processing of some embodiments would then perform a correction on the corner betweensegment2215 andsegment2225, a correction on the corner betweensegment2225 andsegment2235, and finally a correction on the corner betweensegment2235 andsegment2205. As shown at thissecond stage2220, the initial corner betweengeometry2240 andgeometry2245 involves a visually jarring (and unrealistic) discontinuity, owing in part to the roads having different widths (although some embodiments perform the same process for roads of the same width).
• Whereas for the angle between the geometries shown inFIG. 20 the mapping service processing of some embodiments tapers the narrower road to the wider road, in this example the mapping service processing projects the side of the wider road onto the narrower road, as shown by the modifiedgeometry2240 in thethird stage2230. In this case, because the wider segment is the more counterclockwise of the two road segments, the processing projects the right side of thegeometry2245 onto the centerline (or the left side, in some embodiments) of thegeometry2240. When the wider segment is the more clockwise of the two road segments, the processing projects the left side of the wider segment onto the centerline (or right side, in some embodiments) of the narrower segment. Whereas the tapering operation involves changing the angle of the side of one of the segments, the projection simply extends the projected side in some embodiments, as shown instage2230.
• FIG. 23 illustrates theresult2300 of the smoothed junction as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). The asphalt indicates a smooth right turn from the first road segment (shown at the bottom of the display) to the second, wider segment (shown at the top right of the display). In addition, the display includes asphalt (and lane markings, road casing, etc.) for the other two segments that form the intersection. In different embodiments, the instructions for drawing the road casing may be communicated to the client mapping applications as additional geometries or as annotations to the geometry, with instructions for rendering based on the annotation stored at the client device.
• FIG. 24 illustrates a clipping operation performed to eliminate excess road for road segment geometries when the angle between the segments is less than a first threshold angle and greater than a second threshold angle (e.g., between 30° and 80°), over three stages2410-2430.
• In such a case, some embodiments automatically clip the side of one or both of the roads to avoid overshooting the other road. As shown in thefirst stage2410, in this example afirst road segment2405 intersects with asecond road segment2415 at a junction, as well as with anadditional road segment2425.
• Thesecond stage2420 illustrates the initially-grownsegment geometries2440 and2445 for the tworoad segments2405 and2415. The geometry for the other road segment is not illustrated in this figure, as the mapping service processing of some embodiments corrects one corner of the junction at a time, and this example illustrates the correction betweensegments2405 and2415.FIG. 25, described below, illustrates the correction betweensegments2415 and2425. As shown at thissecond stage2420, the initial corner betweengeometry2440 and2445 is not problematic, but the right side of thegeometry2445 overshoots the right side ofgeometry2440, owing in part togeometry2440 being narrower thangeometry2445.
• Thus, the mapping service processing of some embodiments clips the left side of the more clockwise segment back to the centerline of the more counterclockwise of the two segments, and correspondingly clips the right side of the more counterclockwise segment back to the centerline of the more clockwise segment, as shown by the modifiedgeometries2440 and2445 in thethird stage2430. In some embodiments, only the side of the wider road segment is clipped, but other embodiments clip both geometries as shown. As illustrated in thethird stage2430, this removes the excess “ear” of road that would otherwise be sticking out of the intersection unrealistically.
• FIG. 25 illustrates an intersection operation performed to smooth a corner between theroad segment geometry2445 and aroad segment geometry2505 for theroad segment2425, over three stages2510-2530. Some embodiments perform the intersection operation for angles greater than 180°, due to the gap left between the road segment geometries at such large angles. In such a case, some embodiments identify an intersection between the tangents of the road sides, and extend or clip the road geometries so that the sides end at this intersection point.
• The second stage2520 illustrates thesegment geometry2445 as modified in the operation shown inFIG. 24, as well as the initially-grownsegment geometry2505 for theroad segment2425. As shown, this (i) leaves a gap between the two geometries and (2) results in thewider segment2445 overshooting thesegment2505. The second stage also illustrates a dashed line that represents the intersection of the projection of the left side of the moreclockwise geometry2445 with the projection of the right side of the morecounterclockwise geometry2505.
• As shown in the third stage2530, some embodiments either clip or project the sides of the geometries to this intersection point. In the case of thenarrower segment2505, the side is extended to fill in the gap, while in the case of thewider segment2445, the side is clipped to prevent an overshoot of thegeometry2505.
• FIG. 26 illustrates theresult2600 of the smoothed junction from the previous two figures as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). The asphalt indicates smooth turns between each of the subsequent roads, with no missing sections or excess bits of asphalt.
• FIG. 27 illustrates a tapering operation performed to smooth a corner between road segment geometries in situations that fit characteristics of freeway on-ramps in some embodiments, over three stages2710-2730. In this example, afirst segment2705 continues straight into athird segment2725 at a junction, with asecond segment2715 entering the junction at a shallow angle relative to thefirst segment2705. This situation fits the profile of a freeway merge in some embodiments: the first and third segments are a connected road, wider than the second segment, and the angle between the first and second segments is less than a threshold angle (e.g., 30°).
• Thesecond stage2720 illustrates the initially-grown segment geometries2735-2745 for the three road segments2705-2725. The twofreeway segment geometries2735 and2745 are significantly wider than the on-ramp segment geometry2740. In addition, thethird segment geometry2745 is wider than thefirst segment geometry2745, in order to accommodate the merge lane. However, as a result, the initial geometries leave a gap between the on-ramp geometry2740 and thethird segment geometry2745.
• Thus, the mapping service processing of some embodiments taper the outside (left side) of thesecond geometry2740 to the right side of thethird geometry2745, as shown in thethird stage2730. In this case, the tapering is shown as a curved roadside, though different embodiments may use other methods (e.g., using a straight line to connect the segments). Some embodiments also use a taper from the left side of thefirst geometry2735 to the right side of thethird geometry2745, as in the rendered result shown below.
• FIG. 28 illustrates theresult2800 of the smoothed freeway merge junction as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). The asphalt indicates a smooth merge, rather than the choppy display that would be rendered as a result of the initial rectangular geometry. Furthermore, this figure illustrates that some embodiments render different roads differently. For example, some embodiments render freeways a different color (or shade) than other roads, including the freeway on-ramps.
• In addition to modifying the geometries with tapering, projection, clipping, etc. operations, some embodiments use techniques to create more rounded corners at certain types of junctions. Rather than employing techniques to modify the already-generated road segment geometries in order to create rounded corners, some embodiments generate new geometries that create these round corners. In some embodiments, modifying the already-generated segment geometries would be extremely processing intensive.
• FIG. 29 illustrates the generation of such additional geometries at a junction in order to create more realistic, rounded corners at the junction over three stages2910-2930. Thefirst stage2910 illustrates a junction with four road segments2905-2935, that intersect at right angles. Thesecond stage2920 illustrates the initial geometries for these road segments. In this case, all of the road segments have same width, so the geometries all have the same shape and size. Because the angles between the segments are all right angles, there is no need for any of the projection, clipping, or tapering described above.
• Thethird stage2930 illustrates the generation of additional geometries that overlap the road segment geometries and generate the rounded corners for the intersection. Specifically, the additional geometries2940 (shown as solid lines, while the road segment geometries are represented by dashed lines at this stage) have edges that radiate out from the junction location towards points a fixed distance from the 90° corners formed by the segment geometries. Theadditional geometries2940 also have curved lines between these points (or straight lines between enough vertices to approximate a curved line so that the intersection will be rendered with a more realistic, curved appearance.
• FIG. 30 illustrates theresult3000 of the smoothed intersection as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). The asphalt does not make jarring 90° turns between the road segments, but instead has a more curved, pleasing appearance. In addition, the intersection includes stop lines and centerline markings, the generation of which is described below.
• Returning toFIG. 15, theprocess1500 also eliminates (at1520) road overlaps. In some cases, two (or more) initially-grown road geometries will overlap incorrectly. Geometries for road segments that intersect at junctions should overlap, and when two road segments that do not form a junction but cross through the same latitude/longitude coordinates (e.g., a stacked-level road, roads going over/under each other, etc.), their geometries will overlap (as projected onto a flat plane representing the surface of the earth). However, when most other geometries overlap, this is most likely due to incorrect data and should be corrected. Without correction, the rendered map would indicate to a user of the mapping application that two roads intersect when in reality the roads do not.
• The most common cases for such an overlap is when two corresponding dual carriageways overlap (e.g., Northbound and Southbound or Eastbound and Westbound freeways, opposite sides of arterial roads divided by a median, etc.). In most cases, the geometries for such corresponding dual carriageways should come very close to each other without actually overlapping. However, as the segment geometry is based on the centerline and width data for the segment, if any of this information is slightly inaccurate, then the geometries may not line up correctly. For example, when neither a lane count nor width is provided for a road, some embodiments derive the width based on the road type. However, if the road is actually narrower than usual for its road type, then the road geometry may end up larger than the actual road in the real world. Other situations that may cause such overlap include a freeway and its frontage road, roads that dead-end at a freeway rather than going over or under the freeway, etc.
• Different embodiments use different techniques to remove these overlaps of road segment geometry. For instance, some embodiments push two roads apart at the location of the overlap, while other embodiments reduce the width of the road at the overlap. In addition, after moving the roads apart, when the roads are corresponding dual carriageways, some embodiments add geometry for a median between the road geometries.
• FIG. 31 illustrates pushing two roads apart when they overlap, over three stages3110-3130. Thefirst stage3110 illustrates afirst road segment3105 and asecond road segment3115, each as a sequence of vertices. As described above, some embodiments use a constant distance between centerline vertices for roads, in order to standardize operations performed using the vertices. When road segment data is received by the mapping service from a data provider, in some cases the vertex data representing the road segment centerlines may be defined at varying distances (e.g., with gaps of 10 meters, 25 meters, 50 meters, etc.). Some embodiments automatically define vertices at a predefined interval (e.g., every 10 meters) upon ingesting road segment data. This ensures that (i) the roads will have a more curved, realistic appearance than if the vertices were spread out, as the mapping service processing of some embodiments defines straight-line edges between the vertices. Furthermore, it makes the smoothing operations described above more successful by providing more points to move in the operation. Furthermore, defining the vertices at regular intervals enables more useful tests for road overlap.
• Thefirst stage3110 additionally illustrates the road sides generated for the road geometries for thesegments3105 and3115. As can be clearly seen, the two generated road geometries overlap for a section. In order to detect such overlaps, some embodiments generate capsules around each of the edges of a road centerline (the lines between subsequent vertices), and test the capsules for overlaps. Thefirst stage3110 illustrates four such capsules:capsules3125 and3135 for thefirst road segment3105 andcapsules3140 and3145 for thesecond road segment3115. The capsules, in some embodiments, are defined to encompass the edge between two subsequent vertices, and extend out to the width of the road (using the centerline and width data for the road segment). While shown as ovals (i.e., ellipses) in this example, different embodiments use different shapes for the capsules, such as rectangles or other parallelograms, other ellipsoids, etc.
• As shown at the first stage, thecapsule3125 for a first edge of thefirst road segment3105 overlaps with thecapsule3140 for a first edge of thesecond road segment3115. Additionally, thecapsule3135 for a second edge of thefirst road segment3105 does not overlap with thecapsule3145 for a second edge of thesecond road segment3115. In addition, though not shown in this figure, capsules for the two edges of each road segment in between those with capsules illustrated would most likely also overlap. For simplicity in illustrating the modification of the road segments, these additional overlaps are not illustrated or accounted for inFIG. 31.
• In some embodiments, when an overlap is detected between capsules of two road segments, the mapping service processing applies a “force” to the vertices encompassed by the capsule, in order to push the road segments apart from each other. Some embodiments use a spring-mass equation to determine this force, with larger overlaps between capsules resulting in a larger force outward. That is, the larger the overlap, the more the mass “compresses” the conceptual spring, resulting in a larger outward force. Some embodiments apply this force to each of the four vertices within the two overlapping capsules, then taper the force off to nearby vertices as well. Thesecond stage3120 illustrates the application of these forces, with the largest force arrows applied to the two vertices inside each ofcapsules3125 and3140, and smaller force arrows applied to the vertices on either side.
• In some embodiments, the mapping service processing identifies each set of overlapping capsules, and identifies a force to apply to each vertex as a result of that individual overlap. After identifying the forces on the different vertices, the mapping service processing integrates the forces on each vertex to arrive at a new centerline path for the road segments. The processing then performs the same capsule test to determine whether any overlap between the road segment remains. If there is still overlap, the mapping service processing applies additional force to the vertices and pushes them apart again. Thethird stage3130 illustrates that the tworoad segments3105 and3115 have been pushed apart, so that capsules around the edges of the first segment do not overlap at all with capsules around the edges of the second segment. As shown, the road sides for the two road segment geometries are now independent and do not overlap at all.
• Other embodiments use different mechanisms to move the vertices apart. For instance, even with multiple overlapping capsules, some embodiments move the vertices as soon as the first overlap is detected, then move on to the next set of vertices once the first identified sets have been pushed far enough apart to avoid any overlap. In addition, while the example illustrates that forces are applied to vertices around those that overlap, some embodiments only move the vertices of the edge that actually causes the overlap (i.e., only the vertices withincapsule3125 and3140). Furthermore, different embodiments may use different equations (i.e., varying from the spring-mass equation) to determine how much to push vertices away from each other, as well as different equations for calculating how far to move the surrounding vertices.
• Moving the centerline vertices of the road segments is one option employed by some embodiments to handle overlapping road geometries. Some embodiments, on the other hand, reduce the width of the road in the vicinity of the overlap rather than moving the centerline (i.e., reduce the size of the road geometry).
• FIG. 32 illustrates reducing the widths of two road segments when the road segments overlap, over three stages3210-3230. Thefirst stage3210 illustrates afirst road segment3205 and asecond road segment3215, each as a sequence of vertices (similar to the road segments shown inFIG. 31). As described above, some embodiments use a constant distance between centerline vertices for roads, in order to standardize operations performed using the vertices. When road segment data is received by the mapping service from a data provider, in some cases the vertex data representing the road segment centerlines may be defined at varying distances (e.g., with gaps of 10 meters, 25 meters, 50 meters, etc.). Some embodiments automatically define vertices at a predefined interval (e.g., every 10 meters) upon ingesting road segment data.
• Thefirst stage3210 additionally illustrates the road sides generated for the road geometries for thesegments3205 and3215. As can be clearly seen, the two generated road geometries overlap for a section. In order to detect such overlaps, some embodiments generate capsules around each of the edges of a road centerline (the lines between subsequent vertices), and test the capsules for overlaps. Thefirst stage3210 illustrates two such capsules:capsules3225 for thefirst road segment3205 andcapsule3235 for thesecond road segment3215. The capsules, in some embodiments, are defined to encompass the edge between two subsequent vertices, and extend out to the width of the road (using the centerline and width data for the road segment). While shown as ovals (i.e., ellipses) in this example, different embodiments use different shapes for the capsules, such as rectangles or other parallelograms, other ellipsoids, etc. Some embodiments may employ both the solution shown inFIG. 31 and that shown inFIG. 32, and use the same capsules for each solution.
• As shown at the first stage, thecapsule3225 for an edge of thefirst road segment3205 overlaps with thecapsule3235 for an edge of thesecond road segment3215. In addition, though not shown in this figure, capsules for the two edges of each road segment below those with the overlapping capsules illustrated would most likely also overlap. For simplicity in illustrating the modification of the road segments, these additional overlaps are not illustrated or accounted for inFIG. 32.
• In some embodiments, when an overlap is detected between capsules of two road segments, the mapping service processing reduces the width of the road segments at the location of the overlapping capsules. As shown in thesecond stage3220, some embodiments move the road sides at the location of the overlap inward towards the centerline by a particular distance. Some embodiments move this portion of the road side for a particular segment a distance proportional to the amount of overlap. The distance may be just enough to reduce the overlap at the location, or this amount plus additional leeway so that there is a gap between the two road segment geometries. In addition, some embodiments only move the road side that causes the overlap inward, while other embodiments symmetrically modify the other side of each road as well (so that the centerline remains in the center of the road).
• To prevent the rendered roads on a client mapping application from appearing to have a sudden chunk removed from the road, some embodiments select a point along the roadside in either direction (e.g., 100 meters, 500 meters, etc. from the affected vertices) and hold these points fixed. The mapping service processing then tapers the width reduction out from the overlapping section to the fixed points.
• Thethird stage3230 illustrates the road geometries for thesegments3205 and3215 after the widths of the roads have been reduced. As shown, the road geometries no longer overlap at all (at least in the sections shown in the figure). Some embodiments, after detecting an overlap between any two capsules, perform the process to reduce the width at that location and taper out the width reduction. The processing then retests that pair of edges and continues on to identify whether any overlapping road sections remain. On the other hand, other embodiments first identify all of the overlapping sections, reduce the widths at each such section, and calculate the different tapers required for each of the width reductions.
• In addition to the geometry corrections performed at1515 and1520 to smooth junctions and eliminate road overlaps, theprocess1500 also generates (at1525) road markings to display on the roads. These road markings, in some embodiments, may include lane markings, medians, stop lines and/or crosswalks at intersections, etc.
• For example, some embodiments automatically add medians between dual carriageways. As described in the previous subsection, some embodiments identify road segments (or aggregate roads) as being corresponding sides of a road (e.g., opposing directions of a freeway or sides of an arterial road separated by a median, etc.) using the road segment data. In some embodiments, this road segment data indicates that a road is a dual carriageway (sometimes referred to as a divided highway, as opposed to a single carriageway that carries traffic in both directions), and other properties (both geometric and attribute data for the road segments) indicate a likelihood that two roads are corresponding dual carriageways.
• Such dual carriageways often have the two sides separated by various different kinds of medians. For instance, different areas may use concrete raised medians, grass medians, drawn medians (e.g., different combinations of yellow lines), dividers, etc. Some embodiments generate geometries that fill in the gaps between corresponding dual carriageway roads, and then assign these geometries properties so that they are rendered as medians. Some embodiments use the locations of the vertices of the road sides to determine locations for the median vertices, so that the median lines up exactly with the side of the road.
• Different embodiments render the medians differently. For example, some embodiments use a single median type for all dual carriageways, while other embodiments have different types. Much like roads, land cover, etc., stylesheets stored at the client can define different median styles that are drawn differently. The median geometries from the mapping service are tagged with different styles (e.g., arterial road median, freeway median, etc.) that correspond to differently rendered graphics by the client mapping application.
• FIGS. 33 and 34 illustrate dual carriageways with two different types of medians.FIG. 33 illustrates two renderedroads3305 and3315, that are corresponding dual carriageways. In addition, the application displays a design of yellow lines representing a median3310 in between the two roads (specifically, a pair of double yellow lines, with diagonal lines connecting them.FIG. 34 illustrates a concrete median3405 drawn between the twodual carriageways3305 and3315.
• In addition to medians, some embodiments generate geometries for various types of road paint (e.g., lane dividers, stop lines, etc.). In some embodiments, this includes the lane markings shown in the rendered results described above. To generate the lane markings for a road segment, some embodiments use the lane count information stored in the road segment data structure (which may be derived from either the width data or the road type data). In addition, special lanes such as carpool lanes may be indicated in the road segment data and can have geometry generated.
• In addition, some embodiments recognize junctions at which a driver would likely have to stop at a stop sign or light. The mapping service of some embodiments receives this data from map providers (e.g., as information stored in the junction data). Thus, a particular junction might indicate a 4-way stop, a 2-way stop (picking out particular road segments as having the stop signs), a traffic light, etc. In some embodiments, the mapping service processing derives this information based on the road types at the junction. For instance, when a connector road intersects a major arterial road, some embodiments assume that the connector road has a stop sign with the major arterial road having the clear right of way. When two major arterial roads intersect, the mapping service processing assumes that the intersection will be controlled by a stoplight, and adds stop line markings to all of the road segments at the junction.
• FIG. 35 illustrates an example of geometries for such ajunction3500. When all of the road segment geometries at the intersection have the same width, and line up at 90° angles, then generating the stop lines is easy (as shown below). However, the four road segments3505-3520 are not so well aligned. Instead, the segments have different widths, and thesegment3510 intersects the junction at a different (non-right) angle. In such a situation, for each particular road segment, the mapping service processing identifies the line perpendicular to the particular road segment's centerline that is closest to the intersection and touches both sides of the particular road segment's geometry without also intersecting the other road segment geometries. While shown for a more complex junction, some embodiments also use this process to identify the stop line locations in the simpler cases as well.
• The dashedlines3525 inFIG. 35 illustrate these lines for thejunction3500. The mapping service processing then generates geometries for the stop lines that end at these identified lines (the dashed lines3525). For single carriageway road segments (that have two-way travel), the processing only generates the stop line to extend halfway across the road segment. In addition, some embodiments push the stop lines back from the edge of the intersection (the edge being represented by the dashed line in this figure) by a particular distance (e.g., two feet, five feet, etc.).
• FIG. 36 illustrates theresult3600 ofjunction3500 as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). As shown, a thick white line is drawn halfway across each of the road segments at the location identified by the dashed lines ofFIG. 35. The interior (to the intersection) edge of the stop line geometry is drawn at the indicated line, with the stop line extending a ways into the road segment (away from the intersection). Some embodiments push the stop line a fixed distance away from the intersection as well. In addition, lane markings are generated such that they stop at the stop line, or shortly before.
• Again returning toFIG. 15, the roadgeometry creation process1500 next specifies (at1530) annotation information on the road geometry, then ends. In some embodiments, this annotation information is stored on the polygon vertices (or edges, as the two are essentially interchangeable) that directs the mesh building modules and/or rendering engine of the client mapping application to apply particular characteristics to the rendered output. For example, some embodiments specify different types of road casing (i.e., the objects located at the sides of the road) through the road geometry vertices, instructing the client application to draw curbs, sidewalks, bridge casings (and corresponding shadows), tunnels, stacked roads, etc. In some embodiments, the instructions for drawing these casings are stored on the client device as part of the mapping application. The client mapping application then reads the information stored on a particular vertex and generates the appropriate road casing for the edge that corresponds to the vertex.
• The following illustrates several examples of different annotations of some embodiments for road vertices to indicate types of casings to be drawn.FIG. 37 illustrates an example of the use of vertex annotation to specify bridge casing for an overpass, where one road travels over another road and the roads do not form a junction. As shown inFIG. 37, the tworoad geometries3705 and3710 intersect in flat space. However, the road segment data specifies that the road segment for which thegeometry3705 is generated has a higher elevation than the road segment for which thegeometry3710 is created (either using absolute elevation data or relative elevation data). In addition, while shown as one segment for each of the two roads, in some embodiments the roads would be defined using several segments (e.g., for theroad3705, a first segment from an elevation of 0 to an elevation of 1, a second segment with an elevation of 1, and a third segment from an elevation of 1 to an elevation of 0.
• FIG. 37 also illustrates several vertices3715-3735 used to define the sides of theroad geometries3705 and3710. Each particular vertex defines a directed edge from the particular vertex to a next vertex in a sequence. Thus, for example, annotation for thevertex3735 defines how the client mapping application will draw the edge from thevertex3735 to thevertex3730, annotation for thevertex3730 defines how the client mapping application will draw the edge from thevertex3730 to thevertex3725, etc. Different vertices along a single road segment may have different annotations, so that portions of a single road segment will be drawn with different features (e.g., different road casings).
• In this case, the vertex3715 (as well as the other vertices for road segment geometry3710) specifies that it is a vertex of a connector road, and to use the default casing. In some embodiments, different types of roads (e.g., connector, arterial, freeway, etc.) may not only be drawn differently (e.g., different color/texture for the asphalt, different widths, etc.) but also may have different casings (e.g., a curb for a connector road). While this shows an actual specification of a default casing, some embodiments have no specific annotation on vertices for the default casing (or any other property for which the vertex provides annotation).
• Three of the illustrated vertices3725-3735 specifically indicate bridge casing for their edges of thegeometry3705, while thevertex3720 indicates a default arterial road casing. Just as different types of roads may have different default casings, different types of roads may also have different bridge casings. That is, the client mapping applications may contain instructions to draw different overpasses for arterial roads, freeways, etc. Thevertex3720, while located at the edge of the overpass area, does not specify bridge casing, but rather, specifies a default road casing for its edge. This is because its edge is directed away from the overpass, towards the next vertex to the left (not shown) for that side of theroad geometry3705.
• FIG. 38 illustrates theresult3800 of theroad segments3705 and3710 as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). In this case, the asphalt for the connector road is rendered using the same color/texture as the asphalt for the arterial road, although some embodiments may render the roads differently. In addition, lighter-colored curbs are drawn along the edges of the two roads for locations for which the vertices specify a default road casing. For the overpass section, however, the client application draws an overpass bridge according to some embodiments. Furthermore, the application renders a shadow onto the asphalt of the connector road to more realistically illustrate the overpass. If a user were to rotate the view of the map for these roads, then a similar bridge casing would be rendered for the other side of the overpass. In addition, while the shadows appear only for the overpass of the connector road, some embodiments also render shadows underneath the arterial road as it moves upwards from the ground to the overpass.
• FIG. 39 illustrates an example of the use of vertex annotation to specify an edge of a road segment geometry as an interior edge, indicating that no casing should be drawn for the directed edge from the annotated vertex. Some embodiments use such an annotation where roads meet at junctions, in order to prevent the client mapping application from drawing a curb in the middle of the road. As shown inFIG. 39, tworoad segment geometries3905 and3910 meet at a junction. In this case, the road segments are connected as subsequent portions of an aggregate road; however, the same road casing annotation may also be used at junctions representing intersections of more than one road in some embodiments.
• FIG. 39 also illustrates several vertices3915-3925 used to define the sides of theroad geometry3905. Theother road geometry3910 is also defined by vertices, including vertices located at the same point as thevertices3915 and3920. As in the previous figure, each particular vertex defines a directed edge from the particular vertex to a next vertex in a sequence. Thus, for example, annotation for thevertex3915 defines how the client mapping application will draw the edge from thevertex3915 to thevertex3920, annotation for thevertex3920 defines how the client mapping application will draw the edge from thevertex3920 to thevertex3925, etc.
• In this case, all of the vertices3915-3925 (as well as the other vertices for road segment geometry3910) specify that they are vertices of a connector road. In addition, thevertices3925 and3920 specify to use default casing. While this shows an actual specification of a default casing, some embodiments have no specific annotation on vertices for the default casing (or any other property for which the vertex provides annotation). In addition, thevertex3915 specifically indicates to use interior casing (i.e., that the directed edge associated with thevertex3915 is an interior edge of the road. In some embodiments, the interior casing annotation directs the client mapping application to not draw any road casing at all for those edges.
• Thevertex3920, while located at the corner of the road geometry next to the interior edge, specifies the default casing rather than interior casing. This is because its edge is directed towards thevertex3925. Furthermore, in some embodiments vertices for theroad geometry3910 would be located at the same points as thevertices3915 and3920, with the vertex co-located withvertex3920 specifying the interior casing (assuming the direction of the edges was the same for thegeometry3910 as for3905.
• FIG. 40 illustrates theresult4000 of theroad segments3905 and3910 as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). In this case, the asphalt for the first road segment blends smoothly into the asphalt for the next road segment, with no visual indication of a transition from one road segment to the next. The application also draws curbs along either side of the road as the default casing. In addition to polygons for the lighter colored curbs, some embodiments also draw details such as the small shadows generated by the curbs, in order to provide a more 3-dimensional feel to the display, at least in some modes of the client mapping application. While the interior (i.e., facing other road segments) edges of roads are specified as such so that curbs and other road casing are not drawn in the middle of a road, some embodiments also use the interior annotation for roads that do not have casing on their exterior edges, such as country roads that lie at the same level as the grass next to the road, with no curb or other casing.
• FIG. 41 illustrates an example of the use of vertex annotation to specify a tunnel for a road segment, indicating that the tunnel should be drawn over the road segment. Some embodiments use such an annotation to indicate the entrance/exit for a tunnel, as well as middle of the tunnel, so that the client mapping application will draw the tunnel when rendering the road segment. As shown inFIG. 41, tworoad segment geometries4105 and4110 meet at a junction. In this case, the road segments are connected as subsequent portions of an aggregate road; however, the same road casing annotation may also be used at junctions representing intersections of more than one road in some embodiments.
• FIG. 41 also illustrates several vertices4115-4130 used to define the sides of theroad geometry4110. Theother road geometry4105 is also defined by vertices, including vertices located at the same point as thevertices4115 and4130. These vertices, in some embodiments would be annotated to specify default casing or interior casing, for the different vertices. As in the previous figures, each particular vertex defines a directed edge from the particular vertex to a next vertex in a sequence. Thus, for example, the annotation for thevertex4115 defines how the client mapping application will draw the edge from thevertex4115 to thevertex4120, annotation for thevertex4125 defines how the client mapping application will draw the edge from thevertex4125 to thevertex4130, etc.
• In this case, all of the vertices4115-4130 (as well as the vertices for the road segment geometry4105) specify that they are part of an arterial road. In addition, thevertex4130 specifies to use tunnel entrance casing, while the vertices4115-4125 specify to use tunnel casing. The tunnel entrance casing annotation, in some embodiments, specifies that the particular edge (the edge ofsegment geometry4110 that crosses the roadway is the entrance to a tunnel and should be drawn as such. The tunnel casing annotation of some embodiments specifies that the edges are the sides of a tunnel, and thus a tunnel should be drawn across the road. at the location of those edges.
• FIG. 42 illustrates theresult4200 of theroad segments4105 and4110 as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). In this case, the first road segment is displayed with asphalt and curb, the default rendering of some embodiments. For the second road segment, however, the application draws the curved tunnel entrance, and then a rounded covering of the road segment. At the other end of the road segment, the application would render a tunnel exit. In addition, the application renders a shadow below the entrance, resulting in the asphalt being darkened at this location.
• FIG. 43 illustrates an example of the use of vertex annotation to specify a sidewalk for a side of a road segment. This figure illustrates asingle road geometry4305 for a road segment that travels in a straight line. As shown, several vertices4310-4325 are used to define the sides of theroad geometry4305. Each particular vertex defines a directed edge from the particular vertex to a next vertex in a sequence. Thus, for example, annotation for thevertex4310 defines how the client mapping application will draw the edge from thevertex4310 to thevertex4315, annotation for thevertex4320 defines how the client mapping application will draw the edge from thevertex4320 to thevertex4325, etc. Different vertices along a single road segment may have different annotations, so that portions of a single road segment will be drawn with different features (e.g., different road casings).
• In this case, thevertices4310 and4315 specify that they are vertices of a connector road, and to use the default casing. As explained above, different types of roads may have different default casings (e.g., curb for a connector road or arterial road, guardrail for certain other types of roads, etc.). While this shows an actual specification of a default casing, some embodiments have no specific annotation on vertices for the default casing (or any other property for which the vertex provides annotation).
• Thevertices4320 and4325 specifically indicate sidewalk road casing for their edges of thegeometry4305. Just as different types of roads may have different default casings, different types of roads may also have different sidewalks. That is, the client mapping applications may contain instructions to draw different sidewalks for connector roads, arterial roads, etc. (e.g., wider sidewalks for arterial roads).
• FIG. 44 illustrates theresult4400 of theroad segment4305 as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). In this case, the asphalt for the arterial road is rendered in the same manner as shown above, and the left side (with the default road casing) simply has a curb drawn. For the right side of the road, however, the application renders a sidewalk in addition to the curb. In addition to polygons for the lighter colored curbs, some embodiments also draw details such as the small shadows generated by the curbs, in order to provide a more 3-dimensional feel to the display, at least in some modes of the client mapping application.
• The above examples illustrated different types of annotations that can be applied to the road segment geometries. In some embodiments, multiple types of road casings may be applied to a single edge by annotating the edge's vertex with several types of annotation. In the above example ofFIG. 43, the sidewalk annotation implied that the client application should render both a curb and a sidewalk.
• FIG. 45 illustrates an example of the use of several annotations for a single vertex of some embodiments. Specifically,FIG. 45 illustrates an example of using vertex annotation to specify an overpass that includes a sidewalk on one side of the bridge. Thegeometries4505 and4510 are similar to thegeometries3705 and3710 ofFIG. 37, with the latter, a connector road, passing underneath the former, an arterial road. In fact, the difference fromFIG. 37 is that the vertices4515-4525 include annotations that specify both a bridge casing and a sidewalk casing.
• FIG. 46 illustrates theresult4600 of theroad segments4505 and4510 as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). LikeFIG. 45, the asphalt for the connector road is rendered using the same color/texture as the asphalt for the arterial road and the application draws the lighter-colored curbs along the edges of the two roads. For the overpass section, the client application renders not only the overpass and its shadow, but a sidewalk atop the overpass on the side of the road annotated with the sidewalk. In this case, the other side of theroad segment3705 is not annotated to specify a sidewalk, so the application does not render one.
• In the previous examples, the mapping service processing simply specified a casing type for the vertices. In some embodiments, the mapping service can also specify various different variables for different types of casings, that modifies how the casings are rendered. For instance, the height for bridge casings may be specified in the annotation data (i.e., based on the road segment elevation information). In addition, the sidewalk width, curb height, guardrail height, tunnel thickness, curb color, etc. may be varied in different embodiments.
• FIG. 47 illustrates an example of using the vertex annotation data to vary a property of the road casing for aroad geometry4705. Specifically, theroad geometry4705 includes twovertices4710 and4715 on one side and twovertices4720 and4725 on the other side. The twovertices4710 and4715 specify for the client application to render a sidewalk casing, and include a width of 1 meter for that sidewalk. On the other side of the road, the twovertices4720 and4725 also specify for the client application to render a sidewalk casing, this time with a width of 1.5 meters.
• FIG. 48 illustrates theresult4800 of theroad segment4705 as rendered by a client mapping application of some embodiments (e.g., on the display of a portable device). The rendering is similar to that shown inFIG. 44. However, the rendered road now has sidewalks on both sides, and the sidewalks are of a different width (as specified in the annotation data).
• The above examples illustrate the use of vertex annotation data to specify road casing data for some embodiments. However, as other map objects (e.g., buildings, land cover polygons, etc.) are described in map tiles using vertices in some embodiments, these other objects may also contain vertex annotations in their descriptions. For instance, building details can be specified using such annotation (e.g., different color faces, different types of moulding, etc.), as can aspects of the land cover (e.g., how to draw different borders of the land cover polygons).
• After specifying the annotation information, the road geometry creation process ends. As mentioned above, in some embodiments the specific order of the operations to create the road geometry may be different. Furthermore, some embodiments may use parallel processing to perform some or all of the road geometry operations to several road segments (or sets of road segments) at once.
• C. Server Side Generation of Intersection Data
• Having described the server operations that lead directly to the road geometries (e.g., defining aggregate roads and the creation of road geometry), the generation of intersection data using the junction data referred to above will now be discussed. When requesting a route, the client mapping application in some embodiments receives data about each of the intersections that the route traverses, that indicates the different branches of the intersection and notes through which branches the route enters and exits the intersection. In some embodiments, this intersection information is stored by a mapping service that the mapping application accesses in order to retrieve map data as well as route and navigation information.
• As mentioned above, the mapping service of some embodiments receives data specifying each junction of road segments. In some embodiments, the mapping service automatically generates additional data for each of these junctions stored in the map data, and in some embodiments converts the junction data into intersection data. This junction information simplifies each received junction (or a set of related junctions that are viewed in the real world as a single intersection) into a set of branches leaving the junction at different angles. When a user requests a route through a mapping application operating on a device, the device sends the request to the mapping service, which generates a route from a starting location to an ending location. The mapping service also generates turn-by-turn navigation instructions for the route in some embodiments, using the intersection data. The mapping service identifies the intersections at which maneuvers are made, and modifies the intersection data to be specific to the maneuver made during the route. This data is then sent to the user device on which the client mapping application runs. The following subsections first introduce the creation of navigation data for a route, then discuss the precalculation of intersection data by the mapping service (so that the data is available for use in generating navigation data), and then finally describe specific types of modifications made to the intersection data for a requested route.
• 1. Navigation Data Creation
• FIG. 49 conceptually illustrates an operation performed by a mapping service of some embodiments to generate a route for a requesting device and provide the route, with navigation instructions, to the requesting device.FIG. 49 illustrates this operation over six stages4910-4960, in which the mapping service receives a request for the route, generates the route, generates intersection data for the route, and provides the route to the device, which uses the information to display navigation instructions.
• As shown, each stage ofFIG. 49 illustrates adevice4905 and amapping service4900. Thedevice4905 may be a handheld device in some embodiments (e.g., a smart phone, tablet device, etc.), or may be a dedicated navigation device (e.g., a navigation system built into an automobile, a portable navigation device, etc.). In addition, in some embodiments, thedevice4905 may be a non-portable device such as a desktop computer or other non-portable computing device.
• Themapping service4900 is a service to which thedevice4905 connects (e.g., via a wired connection, wireless connection such as a cell network, Wi-Fi, etc.) in order to request and receive map data, route data, turn-by-turn navigation data, as well as additional information (e.g., information about places located on the map, etc.). As shown, themapping service4900 stores mapdata4915 andintersection data4925, and includes amap generator4935 androute generator4945, among other modules (not shown).
• Themap data4915 provides data from which viewable map regions and routes can be generated. This map data, in some embodiments, includes latitude and longitude data, name data, as well as descriptive data about roads and other pathways (e.g., walkways, ferry routes, bike paths, etc.), natural features (e.g., rivers, lakes, mountain ranges, etc.), places of interest (e.g., buildings, businesses, parks, etc.), and other map items. In some embodiments, for example, a pathway is defined as a series of latitude/longitude vertices, a name, and descriptive data. This descriptive data may include a form of way (i.e., whether the pathway is a single carriageway or a part of a dual carriageway, whether the pathway is a one-way path), the class of road to which the path belongs (e.g., motorway, local road, private road, bicycle path, etc.), as well as other information). In some embodiments, this map data is compiled by an outside source (i.e., a map provider) and provided to the mapping service, while in other embodiments the mapping service provides its own map data. The map data may also be a hybrid of outsider-provided and internally-generated data. In addition, the map data may include geometry data for various map constructs, such as roads, land cover, etc.
• Theintersection data4925 provides pretabulated data for the intersections of road paths in the map data. In some embodiments, as described below, the mapping service automatedly calculates intersection data for road pathway intersections using the map data. Thisintersection data4925 may be stored by denoting an intersection type (e.g., point, roundabout) and a series of branches coming in and out of the intersection at different angles. While themap data4915 and theintersection data4925 are shown as separate storages, these may both be stored on the same physical storage or on separate physical storages, and theintersection data4925 may in fact be part of themap data4915. In addition, one or both of the map and intersection data might be distributed across several physical storages (e.g., a series of disks for storing the map data).
• Themap generator4935 of some embodiments generates map information (e.g., map tiles) to transmit to the requestor device. The requestor device requests a map for a particular region (e.g., using latitude/longitude information), and themap generator4935 creates (or uses pre-generated) map tiles for the region, then sends data for these tiles (e.g., as encoded vector and/or image data) to the device.
• Theroute generator4945 calculates optimal routes between two or more points in response to user requests. In some embodiments, theroute generator4945 calculates the routes based on the map data, using optimization algorithms. The routes may be defined as a series of intersections, a series of road pathways, or in other manners. In addition, when a user requests a route, theroute generator4945 provides intersection data for use by the device in turn-by-turn navigation. In some embodiments, theintersection analyzer4955 retrievesintersection data4925, and modifies this data for navigation of the route, as described below.
• As shown, atstage4910, thedevice4905 sends a request for a route to themapping service4900. In some embodiments, the user enters a starting address (or place) and an ending address (or place), potentially including additional midpoint locations (e.g., starting at A, going to B, then going to C from B). The device then transmits location information to the mapping service. In some embodiments, the device translates the locations into latitude and longitude data, while in other embodiments this conversion is performed by the mapping service.
• Atstage4920, theroute generator4945 accesses themap data4915 in order to generate one or more routes for the series of locations. In some embodiments, theroute generator4945 uses an optimization algorithm to find the best (and second best, third best, etc.) route that connects the series of locations.
• Atstage4930, theintersection analyzer4955 identifies maneuvers along the route for which navigation directions need to be generated and retrieves intersection information for these maneuvers. Some embodiments generate turn-by-turn navigation directions to provide to the device along with the route. To generate these directions, themapping service4900 identifies each time the route changes pathways, at which point the user following the directions will have to perform a maneuver (e.g., right turn, slight left turn, U-turn, merge, etc.). In some embodiments, each of these pathway changes corresponds to a pretabulated intersection stored in theintersection data4925. Theintersection analyzer4955 retrieves this intersection data. In some embodiments, each intersection is stored as a series of branches coming out of the intersection at various angles (e.g., based off of North=0°). In some embodiments, in addition to the intersection data, the route generator creates routing directions, that generally describe the maneuver to be performed. Examples of such descriptions include “turn left”, “highway off ramp”, “U-turn”, etc. In other embodiments, this description is derived by the client mapping application based on the received intersection data.
• Next, atstage4940, theintersection analyzer4955 generates intersection information designed for the route. In some embodiments, this entails modifying the angles to set the direction of travel into the junction to 0° (i.e., setting the branch on which the route enters the junction to 180°). This effectively rotates the intersection description by the difference between due North and the route's incoming direction of travel. In addition, theintersection analyzer4955 tags one of the branches as the exit branch. Some embodiments tag an entrance branch as well, while other embodiments rely on the device to identify the 180° branch as the entrance branch.
• Stage4950 illustrates that themapping service4900 then transmits (e.g., via the same network that the device used to transmit the route request) the route data (i.e., route data and intersection data for navigation) to thedevice4905. As shown atstage4960, thedevice4905 then uses the intersection and route data generated by the mapping service to display navigation instructions for the user of the device. In some embodiments, the navigation instructions include a display of the intersection along with a stylized arrow showing the maneuver (in this case, a right turn) through the intersection.
• While themapping service4900 is displayed as including a map generator module and a route generator module, one of ordinary skill in the art will recognize that the mapping service may include additional modules, or different breakdowns of modules. The mapping service may consist of a single computing device (e.g., a server) storing all of the functionality and data, or the functionality may be distributed between multiple servers (e.g., one process on a first server and a second process on a second server, numerous servers that perform the same operation in parallel for different users, or other configurations of computing devices that perform the functionality described herein).
• FIG. 50 conceptually illustrates aprocess5000 performed by the mapping service of some embodiments in order to generate and transmit route and intersection data to a user. As shown, theprocess5000 begins by receiving (at5005) a request for a route between two locations on a map. In some embodiments, when the user requests a series of more than two locations, each segment is treated as a separate route (i.e., from point A to point B is a first route, then point B to point C is a second route).
• The process then generates (at5010) at least one route between the locations using map data. In some embodiments, the process uses an optimization algorithm to identify the best (or two best, three best, etc.) routes between the two locations. These routes may be described as a series of vertices along pathways, a series of intersections between pathways, or with another description.
• With the routes generated for the start and end locations,process5000 selects (at5015) one of the generated routes in order to create turn-by-turn instructions for the route. The process then identifies (at5020) maneuvers to make along the route. In some embodiments, the mapping service identifies each time the route changes pathways, at which point the user following the directions will have to perform a maneuver (e.g., right turn, slight left turn, U-turn, merge, etc.).
• Next, the process retrieves (at5025) intersections for each of the maneuvers. In some embodiments, each of these pathway changes corresponds to a pretabulated intersection stored by the mapping service. The generation of these intersections is described in detail below. In some embodiments, each intersection is stored as a series of branches coming out of the intersection at various angles (e.g., based off of North=0°). In addition, the intersection data stores the type of intersection in some embodiments (e.g., point, roundabout, traffic square, etc.).
• The process then modifies (at5030) the intersection information for each of the maneuvers. In some embodiments, this entails modifying the angles to set the direction of travel into the junction to 0° (i.e., setting the branch on which the route enters the junction to 180°). This effectively rotates the intersection description by the difference between due North and the route's incoming direction of travel. In addition, some embodiments tag one of the branches as the exit branch. Some embodiments tag an entrance branch as well, while other embodiments rely on the device to identify the 180° branch as the entrance branch.
• Theprocess5000 next determines (at5035) whether additional routes remain for which to generate maneuver/intersection information. When additional routes remain, the process returns to5015 to select the next route. Different variations of routes from a start location to an end location may overlap in part, in which case some embodiments reuse the already-generated set of intersections for the overlapping portions.
• Once intersections are generated for all of the routes, the process transmits (at5040) the route and intersection information to the requestor (e.g., a requesting device). As mentioned, the requesting device uses this information in some embodiments in order to generate turn-by-turn navigation, including stylized junction/maneuver arrows.
• 2. Precalculation of Intersection Data
• As mentioned above, some embodiments precalculate intersection data from the stored map data (e.g., road segment and junction data). The mapping service then stores this intersection data for use in generating turn-by-turn navigation instructions. The following section describes several processes used to generate this intersection data, in which the mapping service receives vendor-provided junctions, identifies whether any sets of the received junctions should be consolidated into a single intersection, identifies pairs of road segments that should be joined together within an intersection, and generates angles for the intersection. Within this section, the term junction will be generally used to refer to vendor-provided information at which two path segments intersect, while the term intersection will refer to data generated from the junctions that represents where two or more roads meet in the real world. Thus, multiple junctions might be consolidated into one intersection, and junctions between two road segments that are actually just a continuation of a single road might not be considered intersections at all, in some embodiments.
• The following represents pseudocode of some embodiments for generating intersection data for point intersections:
• • Identify all internal segments;
  • Identify all internal turn channels and mark them as internal segments;
  • For each internal segment:
    • Gather all contiguous internal segments;
    • Mark the gathered internal segments as processed;
    • Build an intersection from this collection of internal segments;
• In addition to other data (e.g., locations of parks, waterways, businesses, etc.), the map data stores information about pathways (i.e., roads, walkways, bike paths, etc.). Each pathway, in some embodiments, is received from a map provider as a series of segments (e.g., road segments). For a given segment, in some embodiments the stored data includes start and end junctions for the segment, geometry data that defines the course taken by the path between the start and end junctions, a path characterization (or “form of way”), a direction of travel (which may, in some embodiments, involve a one-way flag), one or more names for the path (e.g., “I-405 S”, “San Diego Freeway”, etc.), a class that indicates the level of importance of the path, and a netclass (a connected graph of paths to which the path belongs). In some embodiments, the geometry information comprises a series of latitude/longitude vertices through which the path travels. The form of way attribute, in some embodiments, includes the following characterizations: single carriageway, dual carriageway, motorway, slip road, connector, walkway, stairs. Some embodiments may include additional characterizations.
• FIG. 51 conceptually illustrates aprocess5100 of some embodiments for determining path segments between sets of junctions that should be treated together as a single intersection. As shown, theprocess5100 begins by receiving (at5105) a junction between at least two path segments (e.g., road segments). In some embodiments, the mapping service receives (e.g., as precalculated data from a map vendor) a set of road segments and a set of junctions. Each road segment follows a path between two such junctions, and each junction references at least two road segments that enter and/or exit the junction. On the other hand, in some embodiments, the junctions are not received from the map data vendors and the mapping service traverses the path data to identify intersections between paths and analyzes these intersections in order to pretabulate the junctions.
• The process then determines (at5110) whether any of the path segments at the received junction are dual carriageways. As mentioned, a dual carriageway is a path characterization used in some forms of map data. Many roads that are divided (e.g., by a median, a double-yellow line, etc.) are received (and drawn) as two separate path segments, one for each direction. Each of the path segments is then marked with a direction of travel and as one-half of a dual carriageway. Because a user will typically think of an intersection of two roads that are both divided by medians as a single intersection (rather than four separate intersections), the junction generation process attempts to unify these four received junctions into a single intersection to present to a user for navigation purposes.
• When none of the path segments are marked as dual carriageways, the process calculates (at5115) the intersection branches using only the path segments specified in the received junction (i.e., the intersection will include only the one received junction). In some embodiments, the calculation of junction branches entails calculating the angle at which each of the segments specified for the junction leaves the junction location. The process then ends.FIG. 52 illustrates an example of such ajunction5200, also illustrating that there is no requirement that the path segments meet at right angles or that the paths continue in a straight line through the junction.
• When at least one path segment specified for the received junction is a dual carriageway, the process determines (at5120) whether there exists a cross-traffic turn off of a dual carriageway at the junction. A cross-traffic turn is a turn off of the dual carriageway in a direction that will cross through the matching half of the dual carriageway (i.e., the other direction of the road), assuming it exists. In the United States, a left turn is a cross-traffic turn. While the examples shown in this document involve right-handed driving (i.e., driving on the right side of the road), one of ordinary skill will recognize that the examples are equally applicable to left-handed driving areas (e.g., England) as well.FIG. 53 illustrates anintersection5300 that includes twodual carriageway paths5305 and5306 and a one-way road5310. At thejunction5315, there is no cross-traffic turn off of a dual carriageway, because the only options are a right turn off of thedual carriageway path5305 or a left turn off of the one-way street5310. When no such turn exists, theprocess5100 stores (at5125) the received junction while recognizing that it may still be part of a larger intersection, in order to determine whether to include the received junction with other received junctions (e.g., thejunction5320 between the one-way road5310 and the dual carriageway path5306) in a larger intersection. For instance, in theintersection5300, the process will want to join the receivedjunction5320 with the receivedjunction5315 into a single larger intersection. The process then ends.
• When a cross-traffic turn off of a dual carriageway exists at the junction (for instance, at junction5320), the process moves (at5130) in the direction of the cross-traffic turn until the next dual carriageway path is reached. In some embodiments, because the path segments start and stop at junctions, the next dual carriageway path will be reached at a different received junction (though not necessarily the next junction, if a road such as a left turn lane is received as a separate path segment). For instance, fromintersection5320, the process would traverse thepath5310 away from thejunction5320 until reaching the next dual carriageway, atjunction5315.
• Theprocess5100 then determines (at5135) whether the dual carriageway path reached at5130 has a direction of travel in the opposite direction of the originating dual carriageway path. This, essentially, is a quick determinant of whether the second dual carriageway could be the matching path for the first dual carriageway (i.e., whether they are likely to be two sides of the same road). In most cases, this next dual carriageway will be the matching path, due to the nature of how roads are typically built.
• In the case when the second dual carriageway is not in the opposite direction of the originating path, the process proceeds to5125 to store the newly reached junction for later use in determining whether to include it with any other received junctions. For example, if the left turn off ofpath5306 reached another dual carriageway with a downward direction of travel, thenpath5306 could be assumed to not have a match in the data (as far as the junctions are concerned, at least), but the newly identified path might itself have a match.
• On the other hand, if the two dual carriageways have opposite directions of travel, the process identifies and stores (at5140) the segment traversed by the cross-traffic turn. In the example ofFIG. 53, the segment fromjunction5320 tojunction5315 would be stored. This segment will be used as part of additional junction consolidation processes in some embodiments. The process then ends.
• Theabove process5100, when applied to all the junctions within a map region, will generate a set of segments between dual carriageways. Some embodiments use these segments to link together received junctions and identify additional received junctions to include in a single intersection definition. The following represents pseudocode of some embodiments for identifying all such “internal” segments for a complex intersection:
• • For each segment that is a dual carriageway;
    • For each connection with cross-traffic turn where a path can be assembled to other side of intersection;
      • Mark all segments on the path to other side as internal segments;
• This pseudocode includes a determination as to whether a path can be assembled to the other side of an intersection from a segment. The following includes pseudocode of some embodiments for such a determination:
• • Add first segment to path;
  • Get connections from last segment on path;
  • Iterate through each connection to either find a connection to other side or find connection that is best continuation;
    • If connection is other side, note success and end;
    • If no connection is other side and no connection is the best continuation, note failure and end;
    • Otherwise:
      • Add segment to end of path;
      • If path is too far, note failure and end;
      • If too many crossings, note failure and end;
      • Otherwise return to get connections for added segment and iterate through connections;
• FIG. 54 conceptually illustrates aprocess5400 for linking together several junctions into a single intersection and identifying the branches of the intersection. Theprocess5400 begins by receiving (at5405) a set of intersecting segments between dual carriageways. These segments may be identified using a process such as that shown inFIG. 51, in some embodiments. The mapping service then groups together sets of such segments that intersect each other (i.e., at received junctions).FIG. 55 illustrates a commonly existingintersection5500, between a dual carriageway withpaths5505 and5506 and a dual carriageway withpaths5510 and5511. The set of intersecting segments are shown in this figure as thicker lines.
• The process then identifies (at5410) all junctions and path segments that connect directly to the set of intersecting segments at junctions. That is, the set of intersecting paths intersect at junctions, but these junctions may contain additional path segments. For instance, in theexample intersection5500, the eight dual carriageway path segments that leave the intersection all intersect with the internal (thicker) path segments at the four junctions. Thus, the four junctions and eight external path segments are all included in the intersection.
• FIG. 56, on the other hand, illustrates anintersection5600 in which left-turn channels are defined as separate path segments. In this case, because the left-turn channels intersect the internal segments at junctions received in the initial map data, these channels are identified by theprocess5400. The left-turn channels may be characterized in the map data as slip roads or single carriageways, in most cases.
• The following represents pseudocode of some embodiments for identifying all turn channels to treat as “internal” to an intersection:
• • For each segment that is a dual carriageway;
    • For each connection with cross-traffic turn where a path can be assembled to internal segments;
      • Mark all segments on the path to the internal segments as internal segments themselves;
• This pseudocode includes a determination as to whether a path can be assembled to the internal segments from a segment (e.g., a turn channel). The following includes pseudocode of some embodiments for such a determination:
• • Add first segment to path;
  • Get connections from last segment on path (i.e., segments connected to last segment at junction);
  • Iterate through each connection to either find either an internal segment or find connection that is best continuation;
    • If connection is an internal segment, note success and end;
    • If no connection is internal segment and no connection is the best continuation, note failure and end;
    • Otherwise:
      • Add segment to end of path;
      • If path is too far, note failure and end;
      • If too many crossings, note failure and end;
      • Otherwise return to get connections for added segment and iterate through connections;
• Next, theprocess5400 defines (at5415) a new intersection as including all of the identified junctions and path segments, including those that directly intersect the initial set of path segments. In some embodiments, in the case illustrated inFIG. 56, the junctions where the left-turn channels leave their originating dual carriageway segments would be included as well as the left-turn channels that intersect the initial segments. In this situation, some embodiments identify the other junction (i.e., the start junction) for the slip road or single carriageway path segment, which will be where the path segment intersects with one of the dual carriageway path segments before entering the intersection. When the single carriageway path segment stays internal to a (presumed) pair of dual carriageway paths for a threshold distance (e.g., 1 km), some embodiments assume the path segment is a part of the road defined by the dual carriageway paths, and eliminate the junction from consideration.
• When processing a slip road or other connector outside of the dual carriageways (e.g., theslip road5705 shown in theintersection5700 ofFIG. 57), some embodiments do not treat the slip road as a path into the dual carriageway intersection. Instead, some embodiments identify the path characterization as a slip road and attempt to form a closed loop including the start and end junctions of the slip road. When this closed loop shares a common junction with the newly defined intersection (as will typically be the case), the slip road may be associated with the intersection but not treated as an internal path of this intersection. On the other hand, when the newly defined dual carriageway intersection has grown due to the presence of, e.g., left-turn channels, such that the slip road junctions are encompassed by the intersection now including the intersecting single carriageways (as for theslip road5805 in theintersection5800 ofFIG. 58), some embodiments treat the slip road as internal to the newly defined intersection. In the description of the intersection, these left turn channels, slip roads, etc., will typically be eliminated, as a user generally will not want complex instructions, but will instead want an instruction of “make a right turn onto San Vicente Blvd” or something similar.
• With the set of segments and junctions that form the intersection defined, the process needs to merge dual carriageways into single junction branches. Theprocess5400 next defines (at5420) the set of all paths entering the intersection, and defines (at5425) the set of all paths exiting the intersection. For a dual carriageway, which is a one-way path (half of a two-way road), the path will typically have an exit side and an entrance side. For purposes of merging, some embodiments treat each segment (the segment exiting the intersection and the segment entering the intersection) as separate paths. Single carriageways that are not internal to dual carriageways (e.g., the additional two-way path5905 in theintersection5900 ofFIG. 59) will typically be treated as separate branches and are not part of the merging analysis in some embodiments.
• Next, the process determines (at5430) whether the set of entrance paths includes any unpaired dual carriageway paths. When no such paths remain in the set (or none existed in the first place), the process stores (at5435) any unpaired dual carriageway left in the set of exit paths as separate branches of the junction. In general, this will happen in the case of mislabeled map data (the road is actually a one-way street) or merging criteria that are too strict (leaving a pair of entrance and exit paths unmerged).
• When an unpaired entrance path exists, the process selects (at5440) one of the entrance paths. The process then determines (at5445) whether a potential match exists in the exit set. A potential match, in some embodiments, is a dual carriageway found by traversing the previously identified segment to the left (to the right, in the case of left-handed driving regions), or traversing the intersection in a clockwise fashion.
• When no potential match exists (e.g., the next identified dual carriageway in the traversal is also an entrance path, or the exit set is empty), the process stores (at5450) the entrance path as a separate branch of the intersection and then returns to5430 to find the next unpaired entrance path. On the other hand, when a potential match exists, some embodiments determine (at5455) whether the potential pair satisfies a set of dual carriageway match criteria. These are criteria, in some embodiments, to determine whether a pair of dual carriageways are actually the two sides of the same road. Some embodiments determine whether the two paths (1) are within a threshold distance (e.g., 25 m, 50 m, etc.) where the paths enter/exit the intersection, and (2) whether the angles at which the paths hit their junctions within the intersection is within a threshold range of each other (e.g., 5°, 10°, etc.). To calculate the angle, some embodiments use the vertex closest to the edge of the intersection (or the location of the junction at which the path segment intersects the other segments within the intersection) and a vertex located a particular predefined distance (e.g., 50 m) away. The process then calculates the angle off of North for the line between the two vertices.
• In some embodiments, the mapping service additionally looks at the names of the paths to determine whether these match. When the names match, such embodiments may relax the geometry criteria for a matching pair (i.e., allow a greater distance between the paths or a greater difference in angles between the paths). Matching names might be, e.g., “CA-1 South” and “CA-1 North”, or if both paths include “Wilshire Blvd.” as one of their names. Some embodiments may also look at the road class data for confidence in matching dual carriageways.
• If the two paths match, the process merges (at5460) the paths into a single branch of the newly defined intersection. As indicated above, intersections are stored as a set of branches at different angles. For a merged path, some embodiments store the angle as the average of the angles of the two paths that make up the branch.FIG. 60 illustrates the reduction of an eight-path intersection6000 into four branches, in which the angle of theright branch6010 is at half the offset from horizontal as theright exit path6005, because the right entrance path is on the horizontal. As shown conceptually, directions (entrance/exit) are not stored for intersection branches in some embodiments. The mapping service generates the routes using map data, which includes the intersections as well as directions of travel for the roads, so a route will not travel the wrong way on a branch of the intersection.
• On the other hand, when the paths do not match, the process stores (at5465) each of the paths as separate branches of the intersection.FIG. 61 illustrates the reduction of a different eight-path intersection6100 into five branches. In this case, thedual carriageway paths6105 and6106 on the right side do not merge and are therefore treated asseparate branches6110 and6111 of the reduced intersection. In this example, the angle at which each of these branches leaves the intersection is the angle that is stored for the branch (with no averaging). Theprocess5400 then returns to5430 to determine whether any entrance paths remain. As stated, once the entrance path set is empty, the process proceeds to5435, and subsequently ends.
• The following represents pseudocode of some embodiments for generating the data for an intersection once the internal segments have been identified for the intersection (e.g., operations performed by some or all of process5400):
• • Gather all external segments that touch internal segments for an intersection;
  • Identify external segments that are surrounded by internal segments in the intersection and mark them as internal;
  • Group together pairs of incoming and outgoing segments that represent same road;
  • Compute an outgoing angle for each pair and for each unpaired road;
  • Construct a template Intersection Pattern with one branch for each angle;
  • If pattern exists for previously generated intersection, use existing pattern to save space (refer intersection to existing pattern);
  • Else if pattern does not exist, create and store new entry for pattern;
• As indicated, some embodiments store each intersection as a data structure. This data structure indicates the branches of the intersection and the angles at which the branches enter and/or exit the junction.FIG. 62 conceptually illustrates an example of such a data structure6200 of some embodiments for a point type intersection. As shown, the intersection includes an intersection ID (which, in some embodiments is a unique identifier), a map data association, and a set of branches with angles and types. The map data association, in some embodiments, associates the intersection data structure with an actual location within the map. In some embodiments, this is simply a latitude/longitude point, but may also consist of other data in other embodiments (e.g., a list of the path segments or aggregate paths that meet at the intersection). Each branch includes a type and an angle. The type, in some embodiments, is an intersection type. Some embodiments define two intersection types: point and roundabout. However, other embodiments may include additional intersection types, such as traffic squares. Some embodiments store the intersection type as a property of the intersection rather than separately for each branch, but other embodiments recognize the possibility of an intersection partially being a roundabout but partially being a point intersection. The data structure6200 includes four branches, at the cardinal directions of 0° (North), 90° (East), 180° (South), and −90° (West). In some embodiments, the intersection data structure also includes references to any junctions (i.e., data received from the map data provider) and path segments that are contained within the defined intersection. For a typical intersection of two dual carriageways, four junctions are referred to by such a data structure.
• FIG. 63 illustrates a data structure6300 of some embodiments for a roundabout intersection. Some embodiments provide specialized processing for roundabout intersection. The following represents pseudocode of some embodiments for generating intersection data for roundabout intersections:
• • Identify all roundabout segments;
  • For each roundabout segment:
    • Gather all contiguous roundabout segments;
    • Mark the gathered roundabout segments as processed;
    • Build a roundabout intersection from this collection of roundabout segments;
• In some cases, the map data identifies a roundabout (e.g., as a form of way or through another indicator). This allows the mapping service intersection calculator to begin its specialized automated roundabout processing. Specifically, when performing roundabout processing, the mapping service attempts to identify pairs of flare connectors (i.e., the portions of a road that flare into and out of a roundabout). In some embodiments, the intersection calculator traverses the roundabout (e.g., in a counterclockwise fashion for right-handed driving) looking for an exit path that is followed, within a particular distance (e.g., angular distance), by an entrance path. The process then determines whether to combine these paths, looking at factors similar to those for merging dual carriageways at point intersections. For instance, the factors used might include whether the names are similar, whether the distance between the exit/entrance paths is small enough, and potentially other factors. As a result of this processing, when a random road intersects the roundabout in between what otherwise appears to be an entrance/exit combination, some embodiments treat this as three separate branches.
• In order to calculate the angles of the branches, some embodiments determine where the branch intersects the roundabout, rather than the angle of approach of the road. For entrance/exit combinations, the process takes the average of the two paths.FIG. 64 conceptually illustrates the reduction of aroundabout intersection6400 to intersection data. The top path, despite approaching at approximately a 30° angle off of North, is designated as a 0° branch—the user is primarily interested in the distance around the traffic circle for the intersections, rather than the angle at which they enter and exit. The other three branches are also designated cardinal directions, because their flares average out to these directions. The data structure6300 shows the data structure for theroundabout junction6400. Other embodiments, however, use the angle at which the paths enter or exit the roundabout, rather than the distance around the roundabout at which the paths intersect it.
• The following represents pseudocode of some embodiments for generating the data for a roundabout intersection once the roundabout segments have been identified for the intersection:
• • For set of roundabout segments that form a simple loop:
    • Gather all non-roundabout segments that touch the loop, ordered by the direction of travel around the loop;
    • Group together pairs of consecutive roundabout exit/entry segments that represent same road;
    • Assign an angle to each pair and each unpaired segment;
    • Subtract the smallest angle from all angles (so smallest angle=0);
    • Construct a template intersection pattern with one branch for each angle;
    • If pattern exists for previously generated intersection, use existing pattern to save space (refer intersection to existing pattern);
    • Else if pattern does not exist, create and store new entry for pattern;
• As indicated in the above examples of pseudocode, some embodiments perform additional compression when storing the intersections. The real world contains millions (or hundreds of millions) of individual intersections, but many of these intersections have the same configuration (especially when very small angular variations are tolerated). Thus, rather than storing separate data for each of the hundreds of millions of intersections, some embodiments utilize compression in storing the intersections. As each intersection is processed, some embodiments store a template pattern for that intersection. When additional intersections with the template pattern are identified, such embodiments store a reference to that pattern (while still creating a separate data structure, as the location information is different for two intersections that follow the same pattern).
• 3. Modification of Junction Data for Navigation
• The above section described the generation of complex intersection data, typically done as an offline process prior to route generation. However, at the time of route generation, some embodiments modify the intersection data for transmission to the user. The mapping service providing the route data modifies the angles to make them relative to the direction of entry and marks one of the branches as an exit branch.
• FIG. 65 conceptually illustrates aprocess6500 of some embodiments for modifying intersection data in order to provide navigation information for a route. As shown, the process begins by receiving (at6505) a route for which to generate intersection information. As mentioned above, some embodiments generate one or more routes for each set of starting and ending locations requested by a user device. Each of these routes consists of a series of maneuvers at various path intersections (i.e., at road intersections).
• As shown, with the route identified, theprocess6500 selects (at6510) the next intersection along the route. Some embodiments begin with the first intersection (i.e., the first maneuver a user following the route will make), starting from the start point of the route. Many routes involve long stretches along a particular road, going straight through numerous intersections (possibly including junctions of two road segments that are part of the same road and at which no other roads intersect). In some embodiments, the navigation instructions do not include information about the intersections at which no turning maneuver is made. Accordingly, the next intersection is actually the next intersection along the route at which a maneuver will be made.
• The process then retrieves (at6515) precalculated intersection data as a set of branches with associated angles. As described above, some embodiments store a data structure for each intersection, which lists the branches of the intersection along with angles for each branch.FIGS. 62 and 63 illustrate examples of such data structures, for both a point intersection and a roundabout intersection.
• After retrieving the data structure for the selected intersection, the mapping service rotates the intersection definition to normalize the definition to the direction at which the route enters the intersection. Accordingly, theprocess6500 identifies (at6520) the entry branch of the intersection and sets the entry branch to a predetermined angle. Some embodiments set the direction of movement into the intersection as 0°, and therefore set the entry branch of the intersection to 180°.
• The process then rotates the other branches of the intersection. As shown, the process selects (at6525) a next branch of the intersection. In some embodiments, the branches and angles are stored in an array, list, or similar data structure, and the process traverses this data structure. The process sets (at6530) the angle of the selected branch based on an angular distance from the entry branch. For example, if the entry branch was stored as 0° (i.e., pointing North), then a branch stored as 95° will be shifted 180° to −85°. In addition, the process determines (at6535) whether the selected branch is the exit branch of the junction (i.e., the branch at which the route exits the intersection). In order for the turn-by-turn navigation instructions at the client mapping/navigation application to properly display the maneuvers, the device needs to know along which branch of the intersection the route exits. Thus, when the selected branch is the exit branch, theprocess6500 marks (at6540) the selected branch as such. The process then determines (at6545) whether any additional branches of the intersection remain to be converted for the route. When additional branches remain, the process returns to6525 to select the next branch of the junction. When all branches have been processed for the current intersection, theprocess6500 determines (at6560) whether additional intersections remain along the route that need to be modified. When additional intersections remain, the process returns to6510 to select the next intersection. When the last intersection is modified, the process ends.
• FIG. 66 illustrates a conceptual drawing of a route taken through anintersection6600, adata structure6605 for the intersection, and the modification of the data structure to create anew data structure6610 for turn-by-turn navigation instructions. As shown, the route enters from the right side (the 90° branch) and exits the intersection at the bottom (the −162° branch). In the modified data structure, the entry branch has been rotated to 180°, causing a 90° rotation of the other branches. The branch at 18° rotates to 108°, the branch at −65° rotates to 25°, and the branch at −162° rotates to −72°. In addition to the rotation angles, thedata structure6610 has the last branch marked as the exit for the navigation. Some embodiments include a binary exit field, with the exit branch marked with a ‘1’ and all other branches marked with a ‘0’.
• D. Generation of Land Cover Geometry
• In addition to generating road geometry for map tiles, some embodiments also generate land cover geometry. Much like road segment data is received from various sources, so may data describing land cover (e.g., as a series of vertices that indicate the boundary of a particular land cover body). The land cover may include bodies of water (e.g., rivers, oceans, lakes, swimming pools, etc.), administrative bodies (e.g., boundaries of states, countries, cities, parks, etc.), area designations (e.g., rural/urban/suburban, desert/mountains/forest, etc.), or other data describing the land between roads. Initially, some embodiments use these coordinates to grow geometries for the land cover items.
• After growing geometries for the land cover, some embodiments use various operations to resolve boundaries between the geometries. For example, when combining data from different sources, the location data indicating object boundaries may not align perfectly and therefore there may be either gaps between the object geometries or overlap of the geometries. Some embodiments use different operations for resolving boundaries between different geometries, depending on the types of objects. In addition, the land cover geometry processing uses the road segment data to fill in the land cover geometry and ensure that gaps are not left between the land cover and the roads. Some embodiments grow the land cover geometries outside of their marked boundaries towards the roads, stopping the geometries at road centerline locations. While this creates an overlap between the land cover geometry and road geometry, in some embodiments the client mapping applications include instructions to render road geometry on top of land cover geometry. The following subsections describe some of these different methods for resolving discrepancies or mismatches between various land cover boundaries.
• 1. Conflating Land Cover to Roads
• FIG. 67 conceptually illustrates aprocess6700 that some embodiments of the invention perform for conflating land cover polygons to road polygons. In some embodiments the process of conflating land cover polygons is performed in order to resolve data mismatches that occur from receiving land cover polygon data and road polygon data from different data sources. The process of conflating land covers will be described with reference toFIG. 68, which illustrates one example for conflating land covers to road polygons in three stages6801-6803.
• As shown inFIG. 67,process6700 receives (at6705) a road polygon. Theprocess6700 then receives (at6710) at least two land cover polygons. In some embodiments the road polygon and the land cover polygons are received from two different data sources, while in other embodiments they are received from the same data source.Stage6801 inFIG. 68 illustrates an example of two suchland cover polygons6810 and6820. In this example, different land cover types are illustrated by each land cover polygon. For instance,land cover6820 can be a lake andland cover6810 can be a park. However, in other embodiments landcover polygons6810 and6820 could be of the same type. Furthermore, the process may receive more than two land cover polygons, which are not illustrated for simplicity.First stage6801 also illustrates an empty space in between the two land cover polygons. Since land covers represent all areas except roads, the empty space is assumed to represent the location of where a road normally runs. However, due to irregularity of the space between the twoland covers6810 and6820, if a road is drawn between the two land cover polygon, there would be irregular empty space between the road and the land covers that are not visually appealing when the map is rendered on a user device.Process6700, therefore, conflates the land covers to the road as described below.
• Process6700 draws (at6715) the road polygon in the empty space between the two land cover polygons as illustrated byroad polygon6830 instage6801 ofFIG. 68. In some embodiments this road polygon represents the road that is located between the two land cover polygons. In some embodiments a road may not fit cleanly in the center of the empty space. Portions of the road, or the entire road may overlap one or both polygons. For simplicity,process6700 is described under the assumption that the road is located in the space between the land cover polygons.
• Next,process6700 grows (at6720) the land cover polygons up to the road polygon. For instance, as shown instage6802 inFIG. 68, the process expands the left side ofland cover polygon6810 until the polygon reaches the right side ofroad polygon6830. The process also expands the right side ofpolygon6820 until it reaches the left side ofroad polygon6830. In some embodiments when the road polygon does not lie entirely in the center space between the land cover polygons, the, process alternatively grows the land cover polygons to the center of the gap. In other embodiments, the land cover polygons grow past the road geometry, covering portions or all of the road geometry.
• In order to perform this expansion ofstep6720, the process, in some embodiments, rasterizes the polygons prior to expansion. By rasterizing the polygons, the process generates pixel data for the pixels within each land cover polygon. The conflation process uses this pixel data to fill in neighboring pixels with similar data. For instance, if an empty pixel is neighboring a pixel of a land cover polygon that is of a type representing a paved area, the empty pixel also becomes of a type representing the same paved area. The process grows the empty pixels in this manner until they reachroad polygon6830, which acts as a barrier to end the polygon expansion process.
• AlthoughFIG. 68 illustrates an example where only one road polygon is drawn, other embodiments include multiple road polygons representing more than one road between the two land cover polygons. In such instances, empty space may remain between two roads because the land cover polygons are not expanded into the space between the two roads (i.e., the roads act as barriers for polygon expansions).
• When empty space remains between the two roads,process6700 marks (at6725) the empty space between the roads as filler. In some embodiments the marked fillers are interpreted and rendered according to different instructions on a client application. For instance, in some embodiments, the user device renders these empty spaces as road dividers. In other embodiments, the user device renders these empty spaces as green space, asphalt, etc.
• After marking any empty space that may exist between two roads, some embodiments convert the newly grown pixels into vectors to reduce the number vertices from the land cover polygons and union of the grown pixels with the original received polygons fromstep6710 ofprocess6700. The process then draws (at6730) the road over the road polygon. The drawn road may also overlap the polygons next to the road polygon, in some embodiments.Third stage6803 ofFIG. 68 illustratesoperation6730 ofprocess6700 where the process draws aroad6840 over the road polygon between the twopolygons6820 and6810. In thisexample road6840 covers the road polygon and overlaps portions ofpolygons6810 and6820.
• Next, the process optionally performs (at6735) polygon optimization on certain land cover polygon types to reduce the number of vertices in the land cover polygon. In some embodiments this process involves removing certain land cover polygons of a particular type and drawing land cover polygons on a separate layer. For instance, this optimization technique could be performed on small bodies of water such as swimming pools (or ponds) that generate a large number of vertices within the polygons corresponding to the pool and the area around it. For instance, four swimming pool surrounded by a paved area are represented as four polygons to represent the pools themselves. In addition, the paved area is represented as a polygon with four holes in it. In some embodiments, the polygons corresponding to the swimming pools and their corresponding holes are removed and placed in a separate layer. The paved area is drawn and the pools are drawn over it. In this way, the number of points related to the pools is reduced.
• 2. Conflating Boundaries Based on Reliability or Quality of Source Data
• FIG. 69 conceptually illustrates aprocess6900 that conflates boundaries between adjacent polygons received from two different sources in some embodiments.Process6900 is performed in some embodiments to resolve mismatched boundary coordinates received from different sources where one data source is considered more reliable than the other. The process of conflating boundary coordinates will be described with reference toFIG. 70 andFIG. 71.
• FIG. 70 illustrates twostages7001 and7002 of some embodiments of the invention that resolve identifiedgaps7010,7040, and7060 by conflating boundary coordinates betweenadjacent polygons7020 and7030.FIG. 71 illustrates twostages7101 and7102 in some embodiments of the invention that conflate the boundary coordinates ofpolygons7120 and7130 around identifiedoverlaps7110 and7140.
• As shown inFIG. 69, theprocess6900 receives (at6905) two polygons for two different land cover types that are adjacent to each other. For instance, the two land cover types may be representative of oceans and parks. The process may also receive several other land cover types representative of other map features. Next, the process identifies (at6910) any gaps and overlaps between the boundaries of the two polygons.
• As shown instage7001 inFIG. 70, there aregaps7010,7040, and7060 betweenpolygons7020 and7030. As shown inFIG. 71, there areoverlap areas7110 and7140 betweenpolygons7120 and7130. Although illustrated as separate figures for simplicity, some embodiments of the invention may conflate the polygon boundary coordinates around both gaps and overlaps occurring between the same two polygon during the conflation process.
• Referring back toFIG. 69, after identifying the gaps and overlaps between the polygon boundaries,process6900 determines (at6915) which polygon has boundary coordinates that came from a more reliable source, thus having more reliable boundary coordinates. For instance ifpolygon7120 represents ocean andpolygon7130 represents a park and the vendor or the source that provides ocean polygons is considered a more reliable or a better quality source, the process resolves the overlaps (at6920) in favor of the more reliable data. In some embodiments, the process resolves the overlaps in favor of data that represents a particular type of polygon. For instance in the above ocean/park example, the process may determine that ocean polygons are more reliable than park polygons and resolve the overlaps in favor of the more reliable ocean polygon data. Other embodiments resolve the overlaps in favor of polygons of a greater or lesser size. For instance, some embodiments resolve the overlaps in favor of the polygon with the greatest perimeter length or the largest surface area, while other embodiments resolve the overlaps in favor of the polygon with the shortest perimeter length or smallest surface area. As shown instage7102 ofFIG. 71, theoverlap areas7110 and7140 are removed by matching the boundaries of the lessreliable polygon7120 to align with the boundaries of the morereliable polygon7130. In other words, the coordinates of the morereliable polygon7130 are used to determine the boundary between the two regions.
• In order to resolve gaps, for the polygon with less reliable boundary coordinates (or lower quality data), the process calculates (at6925) a threshold value based on the shape of the polygon. In some embodiments the shape of the polygon is based on the area of the polygon divided by the perimeter of the polygon, multiplied by a scaled factor. When more than a predetermined number of boundary points on the polygon with less reliable coordinates are closer to the more reliable polygon than the threshold value, the process (at6930) uses the boundary coordinates of the more reliable polygon and extends the less reliable region to join the more reliable region. Once the distance between the two polygon is more than the threshold, the two polygons are left separated. For instance, ifpolygon7030 inFIG. 70 is from a more reliable source (or has better data quality), thegaps7010 and7060 (which in this example are less than the calculated threshold) are closed by extending the lessreliable region7020 boundaries to the boundaries ofregion7030. In other words, the boundary coordinates ofregion7030 is used for both regions in the areas ofgaps7010 and7060. On the other hand, the distance between the two region in a portion ofgap7040 in this example is more than the calculated threshold.Gap7040 is, therefore, only partially closed.
• In these examples, gaps and overlaps are conflated in favor of the more reliable boundary data. However, other embodiments may conflate boundary coordinates around gaps and overlaps in other ways including conflation in favor of the polygons or boundary data with the most detail.
• 3. Conflating Region Boundaries Based on Analysis of Border Data
• FIG. 72 conceptually illustrates aprocess7200 that is performed by some embodiments of the invention for resolving border conflicts between regions. The regions can be any land cover regions such as bodies of water, parks, building, etc. The regions can also be administrative regions such as states, cities, counties, international countries, etc. The process extracts the borders in order to resolve mismatches when two sets of data are given for a common border. Such mismatches may occur, for example, when regional border data for a common boundary is obtained from different sources.Process7200 attempts to resolve the mismatch in favor of a single border.
• As shown inFIG. 72,process7200 receives (at7205) polygons corresponding to different regions. The process then identifies (at7210) an overlap between the regions. The process resolves the overlap by including (at7215) the overlapping area in the region with the border that preserves the most border data points. In some embodiments step7215 involves subtracting a first polygon from a second polygon or vice versa. Some embodiments resolve the overlap based on which of the aforementioned operations has more border data points, to preserve more border details.
• Next,process7200 determines (at7220) if all overlapping areas have been examined. If not, the process returns to step7210 to identify another overlapping area between different regions.
• After all overlapping areas have been examined,process7200 continues to step7225 to identify a gap between adjacent regions. Some embodiments of the invention obtain a list of gaps between adjacent borders by taking the union of all regions and subtracting all regions where overlaps have already been examined.
• Once the process identifies a gap between adjacent regions,process7200 determines (at7230) if the gap is between only two regions. If yes, the process uses (at7235) the border of the region that preserves the most number of points along the boundary. Otherwise, the gap is between three or more regions. In that case the process uses (at7240) the border of the region that has the longest border. However, in some embodiments, if the gap is between 4 or more states, the process may flag the gap for analysis by a human. The process then determines (at7245) if all gaps have been examined. If no, the process returns to step7225 to identify another gap. If yes, then the process ends.
• FIG. 73 illustrates an example of resolving a border conflict between twoadjacent regions7350 and7360 by performingprocess7200. Although only two regions are illustrated byFIG. 73 for simplicity,process7200 could be performed on a mismatched border between several regions. As illustrated,regions7350 and7360 share acommon border7390. However border conflicts exist between the two regions.First stage7301 ofFIG. 73 illustrates a blown outportion7340 of theborder7390 betweenregions7350 and7360. The blown outportion7340 illustrates examples of border conflicts such as anoverlap7310 and agap7330 that could be resolved by performingprocess7200.
• Second stage7302 ofFIG. 73 illustrates a blown out portion of how aborder7370 might look afterprocess7200 is performed onborder7390. Referring back toFIG. 72,process7200 would first identify (at7210) overlap7310 and resolve the conflict by including (at7215) the portion of the region that preserves the most border data points. In the example illustrated byFIG. 73,process7200 determined that theborder7395 aroundregion7360 preserves more border data points and included that border as shown instage7302.Process7200 then identifies (at7225) thatgap7330 has to be resolved. The process attempts to remove thegap7330 betweenregions7350 and7360 also by using (at7235) the border that preserves more border data points. In the example illustrated byFIG. 73,process7200 determined that for this portion of the border, theborder7397 aroundregion7350 preserved more border data points and included that border as shown instage7302. In some embodiments, some or all of the operations defined in processes67,69, and72 are performed by one or more software modules.
• E. Tile Generation
• One of the last operations performed by the set of servers that generate the map tiles is the tile cut operation, which generates the map tiles and encodes the geometric and vector data in these tiles. In some embodiments, the set of servers defines a map in terms of a tile tree with multiple levels that correspond to multiple zoom levels for viewing the map. For instance, the tile tree data structure in some embodiments is a quadtree with twenty one levels that correspond to twenty one zoom levels for viewing the map. In the quadtree, each node is a map tile, and each non-leaf node has four child tile nodes.
• The tile cut operation has several novelties. One novelty is the fast mechanism that it uses to associate each geometry that was generated for a map to one or more tiles in the tile quadtree. This fast mechanism in some embodiments uses distributed computing to quickly associate the large number of geometries in the map with the large number of map tiles. The task of determining whether each geometry should be associated with a tile is treated as a task independent of other similar tasks, each of which can be assigned to different computing resource in a distributed computing environment.
• For instance, one computing resource can determine whether one geometry intersects one tile. If it does, then for each tile's children, a separate intersection operation is performed in order to determine whether the geometry intersects the child tile. A separate computing resource can perform each distinct intersection operation independently of the other computing resources. This process can be viewed as “throwing” a geometry down a tile quad tree, identifying each tile node that the geometry intersects, and then sending an intersected portion of the geometry to each child node of each intersected node to determine whether the child node intersects the geometry. The geometries that are identified for each tile node are then used in the tile cut process to generate the tile.
• Another novelty relates to the fast mechanism that it uses to re-encode road vector data in the map tiles to remove unnecessary data. Again, the tile cut operation uses distributed computing to distribute this task of re-encoding the vector data. Each distributed task involves initially recording the road data (which may be overlapping) of each tile on the same canvas in order to merge overlapping road geometries. The task then involves re-vector encoding this data to generate vector data that is not duplicative.
• This tile cut operation of some embodiments is further described in the U.S. Provisional Patent Application 61/657,872, entitled “Scalable and Efficient Cutting of Map Tiles,” filed Jun. 10, 2012; the concurrently filed U.S. patent application Ser. No. ______, entitled “Scalable Processing for Associating Geometries with Map Tiles”, having Attorney Docket No. APLE.P0414; and the concurrently filed U.S. patent application Ser. No. ______, entitled “Scalable and Efficient Cutting of Map Tiles”, having Attorney Docket No. APLE.P0425. The provisional application61/657,872 and the above-mentioned concurrently filed non-provisional applications are incorporated herein by reference.
III. Client Side Generation of 3D Presentations
• The mapping application of some embodiments use a variety of novel techniques to present a 3D presentation of a map while the map is being browsed or while the map is providing a navigation presentation. For instance, as mentioned above, the mapping application renders the 3D presentation from the vantage point of a virtual camera, and uses various methods for moving the virtual camera (i.e., moving the perspective rendering position) automatically in certain situations to achieve a desired 3D presentation. One such example occurs when the mapping application of some embodiments moves the position of the virtual camera from a perspective rendering position behind a current position of a moving device to a top-down view of the current position when the device is about to make a turn along a route. Another example is the zoom in/out animations that are provided, which show objects in the scene growing and shrinking with the zoom in operation and the zoom out operation.
• Also, in some embodiments, the mapping application provides two different types of 3D presentations—an immersive 3D presentation and a non-immersive 3D presentation. The immersive presentation in some embodiments not only displays more geometries but also displays more details for the geometries that are displayed in the non-immersive presentation. The mapping application also provides smooth transitions between the non-immersive and immersive presentations.
• To achieve such smooth transitions and generate other novel effects, the mapping application of some embodiments uses a novel image processing pipeline. This pipeline performs a variety of pre-load operations to download, retrieve and/or decompress map tiles that may be needed for a navigation presentation, to prepare its rendering pipeline for its rendering operations, and to prepare a duplicate pipeline to smoothly transition between the immersive and non-immersive 3D presentations.
• Subsection A below describes the automatic movement of the virtual camera used to render the 3D presentation. Subsection B then describes further the immersive and non-immersive 3D presentations of the mapping application. Subsection C next describes the image processing pipeline of the mapping application, and its associated meshing building pipeline, virtual camera, and rendering engine.
• A. Automated Virtual Camera Movement
• As described above, the virtual camera is a conceptualization of the position in the 3D map that mapping application renders to generate a 3D map view. The following provides descriptions of several different examples of the automated movement of such a virtual camera.
• 1. Virtual Camera Movement During Route Navigation
• FIG. 74 conceptually illustrates an example of avirtual camera7400 automatedly moving around a region of a3D map7435 based on a route navigation.FIG. 74 illustrates the movement of thevirtual camera7400 around the region of the3D map7435 at three different stages7405-7415. In some embodiments, the mapping application performs theprocess7500 described below by reference toFIG. 75 to render the 3D map views described in this figure. As shown in this figure, the region of the3D map7435 includes a road that runs over a bridge.
• Thefirst stage7405 illustrates thevirtual camera7400 at a particular location and position in the3D map7435. In some embodiments, the point at which thevirtual camera7400 is focusing (i.e., the point at which a line projecting out of the front of the virtual camera intersects the road) in the3D map7435 is referred to as a point of focus. In some embodiments, the mapping application uses a point along the route that is a defined distance (e.g., 5 feet, 10 feet, 25 feet, 50 feet, etc.) ahead of the user's location (represented by a circle with a triangle on top in this example) as thevirtual camera7400's point of focus. The mapping application of some embodiments uses different distances ahead of the user's location along the route based on the user's traveling speed (e.g., longer distances when the user is traveling at faster speeds and shorter distances when the user is traveling at slower speeds).
• In thefirst stage7405, thevirtual camera7400's point of focus is a point along the ramp up the bridge that is a defined distance ahead of the user's location. An example rendered image of the3D map7435 from thevirtual camera7400's point of view at thisstage7405 is illustrated in the3D map view7420. The 3D map views7420,7425, and7430 illustrated in this figure, as well as those shown in other figures within this section, do not include various UI controls and features (e.g., road signs, navigation signs, floating controls, etc.) so as to highlight the rendered map images.
• Thesecond stage7410 shows thevirtual camera7400 at a different location and position in the3D map7435. In this example, thevirtual camera7400 has moved up because thevirtual camera7400's point of focus is elevated due to the height of the bridge. In addition, thevirtual camera7400 has moved towards the right to follow along the route navigation. From thefirst stage7405 to thesecond stage7410, the mapping application automatically moved thevirtual camera7400, rendered images of the 3D map from thevirtual camera7400's point of view along the path, and displayed the images on the device. An example rendered image of the3D map7435 from thevirtual camera7400's point of view at thisstage7410 is illustrated in the3D map view7425.
• Thethird stage7415 illustrates thevirtual camera7400 at another different location and position of the3D map7435. For this example, thevirtual camera7400 has moved down because thevirtual camera7400's point of focus is on the road and no longer on the bridge. In addition, thevirtual camera7400 has moved towards the right to follow along the route navigation. From thesecond stage7410 to thethird stage7415, the mapping application automatically moved thevirtual camera7400, rendered images of the 3D map from thevirtual camera7400's point of view along the path, and displayed the images on the device. An example rendered image of the3D map7435 from thevirtual camera7400's point of view at thisstage7415 is illustrated in the3D map view7430.
• In some embodiments, the mapping application detects a threshold amount of change in elevation, or a threshold rate of change in elevation, of the point of focus along the route. The mapping application of some such embodiments adds a delay to the positioning of the virtual camera's adjustment of the tracking in response to the position of the focus point along the route when the mapping application detects that the user's location along the route has decreased in elevation and one or both of the thresholds have been passed. In some embodiments, the mapping application maintains the height of the virtual camera (e.g., the position of the virtual camera long a z-axis) for a defined amount of time when the mapping application detects the decrease in the elevation of the user's location along the route. Adding a delay and maintaining height for a defined amount of time are techniques that each prevents the virtual camera from approaching the road too closely or, in some cases, colliding into the road. This way, the mapping application provides the user a better view of the map while traversing undulating roads.
• FIG. 75 conceptually illustrates a process of some embodiments for animating map views during a route navigation. The mapping application of some embodiments performs theprocess7500 at defined intervals (e.g., 0.5 seconds, 1 second, 3 seconds, 5 seconds, etc.). In some embodiments, the mapping application repeatedly performs theprocess7500 while the mapping application operates in the route navigation mode.
• Theprocess7500 begins by identifying (at7510) a set of attributes for determining the virtual camera's position at the end of a time period. In some embodiment, the end of the time period is the time at which the mapping application receives the current location of the user and the beginning of the time period is the time at which the mapping application receives the previous location of the user. In some embodiments, the set of attributes includes data that is used to derive the position and orientation of the virtual camera.
• In different embodiments, theprocess7500 uses different sets of attributes. The following describes some or all attributes used by theprocess7500 of some embodiments. For instance, theprocess7500 of some embodiments uses the location of a point of reference (i.e., the user's location). Theprocess7500 of some embodiments uses the location of the point of focus of the virtual camera, which is used to determine which direction the virtual camera should face in some embodiments.
• In instances where the user is off-route from the route navigation, the point of focus is a fixed distance ahead of the user along the user's direction of travel (if that can be determined) or a fixed distance north of the user when the user's direction of travel cannot be determined. In instances where the user is on-route with respect to the route navigation, the point of focus is a fixed distance ahead of the user along the route to allow the virtual camera to subtly peek around turns before the user actually turns.
• Some embodiments limit the angle between (1) a vector defined from the point of reference and the point of focus and (2) a vector pointing towards the user's travel direction, to a defined maximum angle amount. For example, if the route turns a corner shortly ahead, the point of focus will be a point around the corner from the current location of the device. As turning the virtual camera to face that actual point could cause the virtual camera to directly face a building, the amount that the virtual camera turns to peek around the corner is limited so that the view of the direction of travel is partially shown at all times.
• Another virtual camera position indicator that theprocess7500 of some embodiments uses is a location of point of interest (e.g., the location of an upcoming intersection). In some embodiments, theprocess7500 determines the virtual camera view style and uses this indicator to derive the position and orientation of the virtual camera. Examples of virtual camera view styles includes top-down centered, top-down forward, and rooftop. A top-down centered view style in some embodiments is where the virtual camera looks straight down on the user's location such that the user's location is positioned at the center of the screen. In some embodiments, a top-down forward view style is where the virtual camera looks straight down on the user's location such that the user's location is positioned towards the bottom of the display. A rooftop” view style in some embodiments is where the virtual camera is positioned behind the user's location and is pitched so that it is looking forward along the vector from the user's location to the point of focus. If the user is off-route from the route navigation or the user's direction of travel cannot be determined (e.g., when the user is parked), the virtual camera is set to a top-down centered view style. Otherwise, the view style is determined by whether the user has requested a 2D or 3D navigation mode. If the user has requested a 2D navigation mode, the view style is set to a top-down forward view style. If the user has requested a 3D navigation mode, the view style is set to a rooftop view style.
• In some embodiments, theprocess7500 determines the virtual camera's focus style and uses it to determine the position and orientation of the virtual camera. Examples of virtual camera focus styles include a cruise focus style and a hard focus style. In some embodiments, a cruise focus style is where the virtual camera is set to a preset height and pitch angle. A hard focus style in some embodiments is where the virtual camera is set to a height (e.g., in the top-down centered or top-down forward view styles) and/or pitch (e.g., in the rooftop view style) so that a given point-of-interest is displayed on screen (e.g., the virtual camera focuses in on the point-of-interest as the user approaches it).
• Next, theprocess7500 determines (at7520) the position and orientation of the virtual camera based on the identified attributes. After determining the position and orientation of the virtual camera, theprocess7500 identifies (at7530) the locations of a set of reference points at the end of the time period based on the virtual camera's position and orientation. Examples of reference points include the position of the camera, the intersection between the virtual camera's forward vector and the ground, a defined point along the virtual camera's right vector, etc.
• Theprocess7500 then identifies (at7540) the locations of a corresponding set of previous reference points. In some embodiments, the mapping application maintains a history of the locations of the set of reference points, which are determined in the same manner as those identified by theprocess7500 at7520, that theprocess7500 accesses.
• Finally, theprocess7500 renders (at7550) an animated map view for the time period based on the sets of reference points identified at7530 and7540. To render the animated map view, theprocess7500 of some embodiments uses cubic polynomials associated with each reference point. Theprocess7500 animates the map view by (1) traversing each of the virtual camera's reference point along its associated cubic polynomial during the animation while (2) rendering the virtual camera's view of the map.
• Before rendering the animated map view, theprocess7500 of some embodiments updates the cubic polynomial associated with a particular reference point when the reference point has changed with respect to its corresponding previous reference point. In some embodiments, theprocess7500 updates the cubic polynomial with a cubic polynomial determined based on the location of a reference point, the location of the corresponding previous reference point, and two tangents based on the reference point and its corresponding previous reference point. In some embodiments, theprocess7500 uses a scaled version of a vector that ends at the location of the reference point and starts from the location of the corresponding previous reference point, as one of the tangents. For the other tangent, theprocess7500 of some embodiments uses another scaled vector that is determined in a similar manner as the first scaled vector except the vector ends at the location of the previous reference point and the location of its corresponding previous reference point. Theprocess7500 fits a cubic polynomial using these two tangents, the location of the reference point, and the location of the corresponding previous reference point and uses the fitted cubic polynomial as the reference point's current cubic polynomial.
• 2. Virtual Camera Movement Around Intersections
• FIG. 76 conceptually illustrates an example of avirtual camera7600 automatedly maneuvering a turn in a3D map7650 during on a route navigation.FIG. 76 illustrates the movement of thevirtual camera7600 in the3D map7650 at three different stages7605-7615. In some embodiments, the mapping application performs theprocess7700 described below by reference toFIG. 77 to maneuver a turn. As shown, the region of the3D map7650 includes a road that abuts another road and a building on the right side of the T-junction.
• Thefirst stage7605 illustrates thevirtual camera7600 at a particular location and position in the3D map7650. In some embodiments, the point at which thevirtual camera7600 is focusing (i.e., the point at which a line projecting out of the front of the virtual camera intersects the road) in the3D map7650 is referred to as a point of focus. In some embodiments, the mapping application uses a point along the route that is a defined distance (e.g., 5 feet, 10 feet, 25 feet, 50 feet, etc.) ahead of the user's location (represented by a circle with a triangle on top in this example) as thevirtual camera7600's point of focus. The mapping application of some embodiments uses different distances ahead of the user's location along the route based on the user's traveling speed (e.g., longer distances when the user is traveling at faster speeds and shorter distances when the user is traveling at slower speeds). For this example, thevirtual camera7600's point of focus is a point along the route ahead of the user's location.
• In thefirst stage7605 thevirtual camera7600's point of focus is a point ahead of the user's location on the road that the user is traveling along. Thefirst stage7605 also illustrates a corresponding top-down view7620 of thevirtual camera7600 and the3D map7650. As shown, the point of focus in this example is indicated by a black circle located ahead of the user on the road that the user is traveling along. An example rendered image of the3D map7650 from thevirtual camera7600's point of view at thisstage7605 is illustrated in the3D map view7635. The3D map view7635 also shows the virtual camera's point of focus.
• Thesecond stage7610 shows thevirtual camera7600 at a different location and position in the3D map7650. As shown in thesecond stage7610, thevirtual camera7600 has moved to the right towards the intersection along the route navigation. To maintain focus on the point of focus, thevirtual camera7600 has also moved up (e.g., up along the z-axis) in order to provide a better view of the point of focus during the right turn in case it might be obstructed. For instance, when there are buildings near or at the intersection, the point of focus might be occluded by the buildings thereby preventing a view head of the corner of the turn.
• In addition, thevirtual camera7600 at this stage has tilted downwards (e.g., decreased pitch) in order to maintain aim at the point of focus. The top-down view7625 at thesecond stage7610 shows that thevirtual camera7600 has rotated slightly to the right of the intersection (e.g., about the z-axis) because the point of focus is just to the right of the intersection. Thus, from thefirst stage7605 to thesecond stage7610, the mapping application has automatically moved thevirtual camera7600 forward along the route navigation (e.g., along the x-axis, y, axis-, or a combination of both x and y axes, etc.) towards the intersection, moved thevirtual camera7600 higher (e.g., up along the z-axis), and rotated (e.g., about the z-axis) thevirtual camera7600 towards the right of the intersection while maintaining focus on the focus point ahead of the user's location. An example rendered image of the3D map7650 from thevirtual camera7600's point of view at thesecond stage7610 is illustrated in the3D map view7640.
• Thethird stage7615 shows thevirtual camera7600 at another different location and position in the3D map7650. Here, thevirtual camera7600 has moved to the right and is at the intersection along the route navigation. To maintain focus on the point of focus, thevirtual camera7600 has also moved up (e.g., up along the z-axis) and over the intersection in order to provide a better view of the point of focus while the user is making the right turn for the same or similar reasons mentioned above (e.g., obstruction or occlusion of thevirtual camera7600's view of the point of focus).
• In thethird stage7615, thevirtual camera7600 has also tilted farther downwards (e.g., decreased pitch) to maintain the focus on the point of focus. The top-down view7630 in thethird stage7615 shows that thevirtual camera7600 has rotated to the right (e.g., about the z-axis) since the point of focus is now past to the right turn of the intersection. As such, from thesecond stage7610 to thethird stage7615, the mapping application has automatically moved thevirtual camera7600 forward along the route navigation (e.g., along the x-axis, y, axis-, or a combination of both x and y axes, etc.) to the intersection, moved thevirtual camera7600 higher (e.g., up along the z-axis), and rotated (e.g., about the z-axis) thevirtual camera7600 towards the right of the intersection while maintaining focus on the point of focus ahead of the user's location. An example rendered image of the3D map7650 from thevirtual camera7600's point of view at thethird stage7615 is illustrated in the3D map view7645.
• FIG. 76 illustrates a point of focus in the top-down views of a 3D map and the rendered 3D map views of the 3D map for purposes of explanation and clarity. In some embodiments, the mapping application does not actually render the point of focus in the 3D map views and the 3D map does not contain an actual point that represents the focus point.
• FIG. 77 conceptually illustrates aprocess7700 of some embodiments for animating a map view during a turn of a route navigation. In some embodiments, the mapping application iteratively performs theprocess7700 when the mapping application is traversing a route navigation. The mapping application of some embodiments performs theprocess7700 at defined intervals (e.g., 0.5 seconds, 1 second, 3 seconds, etc.) while the mapping application is traversing a route navigation.
• Theprocess7700 begins by identifying (at7710) an upcoming intersection. In some embodiments, theprocess7700 uses map data to identify the upcoming intersection along the route navigation.
• Next, theprocess7700 determines (at7720) whether the navigation route has a turn at the upcoming intersection. Theprocess7700 of some embodiments determines that a navigation route has a turn at the upcoming intersection when theprocess7700 identifies a threshold change in direction near or at the intersection or determines a change in street name on along the route navigation at the intersection. Additional and/or other techniques are possible.
• When theprocess7700 determines that there is not a turn at the next intersection, theprocess7700 ends. Otherwise,process7700 determines (at7730) whether the turn angle is within a threshold angle (e.g. whether the curve deviated from being straight by more than some number of degrees). The threshold angle is defined differently for different embodiments. In some embodiments, the threshold angle is defined as a value under 45 degrees, a value between 45 and 90 degrees, larger than 90 degrees, etc.
• If theprocess7700 determines that the turn angle is within the threshold angle then theprocess7700 ends. Otherwise, theprocess7700 displays (at7740) the map view in a top-down viewing mode. In some embodiments, a top-down mode is a viewing mode in which the virtual camera is above or “on top of” the scene and pointing either mostly or entirely downwards. In some embodiments the top-down viewing mode is referred to as a hard focus mode. The top-down viewing mode in some embodiments is a 2D mode. In some instances, the mapping application was already displaying the map view in the top-down mode. In such instances, theprocess7700 continues in the viewing mode through the turn along the route navigation.
• Next, theprocess7700 determines (at7750) whether the turn has been completed. Theprocess7700 determines that the turn has been completed when the user's location is a defined distance past the intersection. In some embodiments,process7700 determines that the turn has been completed when the virtual camera's position has rotated an angle amount of the turn angle or a threshold angle range within the angle of the turn. When theprocess7700 determines that that turn has not been completed, theprocess7700 returns to7750 to continue checking whether the turn has been completed.
• When theprocess7700 determines that that turn has been completed, theprocess7700 displays (at7760) the map view in the original viewing mode. That is, theprocess7700 displays the map view in the viewing mode that the mapping application was displaying the map view before the turn was approached. Theprocess7700 then ends.
• Although theprocess7700 was described as using a top-down mode, in some embodiments otherwise similar or identical processes use a non-top-down mode that makes the turn at the corner easier to see than whatever mode the map had been displayed in before the approach to the corner.
• 3. Virtual Camera Movement when Panning
• FIG. 78 conceptually illustrates an example of avirtual camera7800 panning around a3D map7835 during a route navigation.FIG. 78 illustrates the movement of thevirtual camera7800 around the region of the3D map7835 at three different stages7805-7815. The mapping application of some embodiments performs theprocess7900 described below by reference toFIG. 79 to pan thevirtual camera7800. As shown in this figure, the region of the3D map7835 includes a road and several building along the side of the road.
• Thefirst stage7805 illustrates a top-down view of thevirtual camera7800 at a particular location and position in the3D map7835. In some embodiments, the point at which thevirtual camera7800 is focusing (i.e., the point at which a line projecting out of the front of the virtual camera intersects the road) in the3D map7835 is referred to as a point of focus. In some embodiments, the mapping application uses a point along the route that is a defined distance (e.g., 5 feet, 10 feet, 25 feet, 50 feet, etc.) ahead of the user's location (represented by a circle with a triangle on top in this example) as thevirtual camera7800's point of focus. The mapping application of some embodiments uses different distances ahead of the user's location along the route based on the user's traveling speed (e.g., longer distances when the user is traveling at faster speeds and shorter distances when the user is traveling at slower speeds).
• In thefirst stage7805, thevirtual camera7800's point of focus is a point along road a defined distance ahead of the user's location, as indicated by a circle in the3D map7835. An example rendered image of the3D map7835 from thevirtual camera7800's point of view at thefirst stage7805 is illustrated in the3D map view7820.
• Thesecond stage7810 shows a top-down view of thevirtual camera7800 at a different location and position in the3D map7835. As shown, thevirtual camera7800 has rotated towards the right (e.g., about the z-axis). In this example, the mapping application of some embodiments automatically rotated thevirtual camera7800 towards the right in response to a gesture input (e.g., a swipe left gesture) received through a touchscreen. An example rendered image of the3D map7835 from thevirtual camera7800's point of view at thisstage7810 is illustrated in the3D map view7825.
• Thethird stage7815 illustrates a top-down view of thevirtual camera7800 at another different location and position of the3D map7835. For this example, the mapping application has automatically rotated thevirtual camera7800 back towards the left after a defined amount of time (e.g., 0.5 seconds, 1 second, 2 seconds, 3 seconds, etc.). In some embodiments, the mapping application rotates thevirtual camera7800 back after a defined amount of distance traveled (e.g., 10 yards, 25 yards, half a mile, etc.) An example rendered image of the3D map7835 from thevirtual camera7800's point of view at thethird stage7815 is illustrated in the3D map view7830.
• FIG. 79 conceptually illustrates aprocess7900 of some embodiments for panning to the side of a map view based on gesture input. In some embodiments, the mapping application performs theprocess7900 when the mapping application is in a route navigation mode and the mapping application receives a gesture through a touchscreen of a device on which the mapping application is executing.
• Theprocess7900 begins by receiving (at7910) a gesture for panning to the side. In some embodiments, a gesture for panning to the side includes a touch gesture received through a touchscreen (e.g., swiping the touchscreen to a side with a finger). Alternatively, or conjunctively, the gesture for panning to the side in some embodiments includes a multi-touch gesture (e.g., swiping the touchscreen to a side with multiple fingers).
• Next, theprocess7900 identifies (at7920) a panning component of the panning gesture. Theprocess7900 of some embodiments identifies the horizontal component of the panning gesture as the panning component. In other embodiments, theprocess7900 identifies a vector defined from a location at the initial touch of the gesture (e.g., the location at which a finger touches the screen) to the location at the end of the gesture (e.g., the location at which the finger no longer touches the touchscreen).
• In some embodiments, theprocess7900 limits the panning component of the panning gesture. For example, if theprocess7900 determines (at7930) that the panning component exceeds a threshold amount (e.g., the magnitude amount of the panning component exceeds the threshold amount), theprocess7900 limits (at7940) the panning component (e.g., reducing the magnitude of the panning component) to within a defined limit.
• Based on the panning component, theprocess7900 then pans (at7950) a virtual camera that is being used to render 3D map views of the route along the route navigation. Theprocess7900 of some embodiments pans the virtual camera in a similar manner of panning the virtual camera described above by reference toFIG. 78. That is, theprocess7900 rotates the virtual camera about the z-axis to pan the virtual camera.
• Next, theprocess7900 determines (at7960) whether a defined amount of time (e.g., 0.5 seconds, 1 second, 2 second, 5 seconds, etc.) has elapsed. When theprocess7900 determines that that the defined amount of time has not elapsed, theprocess7900 returns to7960 to continue checking for the amount of time to elapse. When theprocess7900 determines that that the defined amount of time has elapsed, theprocess7900 proceeds to7970.
• Finally, theprocess7900 pans (at7970) the virtual camera back to its original position. In some embodiments, theprocess7900 pans the virtual camera in a similar manner of panning the virtual camera described above by reference toFIG. 78. In other words, theprocess7900 rotates the virtual camera about the z-axis to pan the virtual camera.
• 4. Virtual Camera Movement During Perspective Adjustments
• Besides (or instead of) having the navigation application control the camera (e.g., turning from 3D to 2D when going around corners) some embodiments also allow the user to adjust the level of the camera. Some embodiments allow the user to make a command gesture with two fingers to adjust the distance (height) and angle of the camera. Some embodiments even allow multiple types of gestures to control the camera.
• FIG. 80 conceptually illustrates a perspective adjustment feature provided by a mapping application of some embodiments. Specifically,FIG. 80 illustrates avirtual camera8000 at three different stages8005-8015 that show the adjustment of thevirtual camera8000's position in response to a perspective adjustment. As shown,FIG. 80 illustrates a location in a3D map8035 that includes four objects, which are two buildings and two intersecting roads.
• Thefirst stage8005 shows thevirtual camera8000 at a first perspective position pointing downwards towards the3D map8035 at a first angle (e.g., 45 degrees) with respect to the horizon. In this position, thecamera8000 is pointing to a location that may be a stationary position of the device or of a location being explored, or a moving position in front of a moving location of the device in a case where the map is used for navigation. In some embodiments, the default position of thecamera8000 is to be at a particular orientation with respect to the current location, but this orientation can be modified when the user rotates the map. Rendering a 3D map view based on thevirtual camera8000's position results in the3D map view8025.
• Thesecond stage8010 shows thevirtual camera8000 at a different second perspective position pointing at a lower perspective towards the3D map8035 at a smaller second angle (e.g., 30 degrees) with respect to the horizon. Thestage8010 also shows that a user has provided input to adjust the perspective of the view of the3D map8035 by touching two fingers on the screen and dragging the two fingers in an upward direction (e.g., a swipe gesture). The scene flattening out is accomplished by thevirtual camera8000 lowering and decreasing the viewing angle with respect to the horizon. Rendering a 3D map view using thevirtual camera8000 positioned at this angle results in a3D map view8030 in which the buildings and the roads are taller than their illustration in thefirst map view8025. As indicated by the dashed-line version of thevirtual camera8000, thevirtual camera8000 moved farther downwards alongarc8050 while tilting (e.g., pitching) farther up.
• Thethird stage8015 shows thevirtual camera8000 at a different third perspective position pointing at a higher perspective towards a location (e.g., thevirtual camera8000's point of focus) on the3D map8035 at larger third angle (e.g., 80°) with respect to the horizon. Thestage8015 also shows that the user has provided input to adjust the perspective of the view of the3D map8035 by touching two fingers on the screen and dragging the two fingers in a downward direction (e.g., a swipe gesture). The scene dropping is accomplished by thevirtual camera8000 rising and increasing its angle with respect to the horizon. As shown at thisstage8015, in some embodiments, the mapping application flattens the buildings (e.g., reduces the z-axis component of the polygons to the ground level) in the3D map8035 when thevirtual camera8000 is positioned in a top-down or near top-down position so that 3D map views rendered using thevirtual camera8000 appear 2D. Rendering a 3D map view using thevirtual camera8000 positioned at the angle in thethird stage8015 results in a3D map view8040 in which the buildings appear smaller, flatter and the roads appear smaller than their illustration in thesecond map view8030. As shown by the dashed-line version of thevirtual camera8000, thevirtual camera8000 moved farther upwards alongarc8050 while tilting (e.g., pitching) farther down.
• In some embodiments, thevirtual camera8000 can be made to move in this manner when the mapping application receives input for adjusting the perspective for viewing the3D map8035. In some of these embodiments, the mapping application switches to a top-down mode (where the rendering position faces straight down) that produces 2D map views when the zoom level reaches a particular zoom out level.
• FIG. 80 shows a virtual camera moving along a particular path along an arc. The mapping application of different embodiments moves the virtual camera along different paths when adjusting the perspective of the virtual camera. For instance, in some embodiments, the mapping application uses a particular arc similar to the arc shown inFIG. 80 except the particular arc is farther away and up (e.g., zooms out) as the virtual camera moves upwards along the arc and closer (e.g., zooms in) and down as the virtual camera moves downwards along the arc. In some embodiments, the mapping application uses a path for the virtual camera that flattens out horizontal as the virtual camera moves upwards along the arc. Other paths on which the virtual camera moves are possible in other embodiments.
• While moving along one of the arcs, the virtual camera rotates to maintain a desired location on the map at the focal point of the camera. The desired location in some cases is a stationary location of the device or a stationary location that the user is browsing on the map. In other cases, the desired location is a moving location in front of the moving location of the device as the user is moving with the device.
• FIG. 81 conceptually illustrates aprocess8100 of some embodiments for adjusting the position of a virtual camera that is used for rendering a map view in response to a perspective adjustment. In some embodiments, the mapping application described above and below by reference toFIGS. 1-108 performs theprocess8100 when the mapping application is in a map viewing mode (e.g., a location browsing mode, a navigation mode, etc.) and the mapping application receives a gesture through a touchscreen of a device on which the mapping application is executing.
• Theprocess8100 begins by receiving (at8110) a gesture for adjusting the perspective of a map view. In some embodiments, a gesture for adjusting the perspective of the map view includes a multi-touch gesture received through a touchscreen (e.g., simultaneously touching the touchscreen with multiple fingers), such as the ones described above by reference toFIG. 80. In this example, theprocess8100 receives a two-touch swipe gesture.
• Next, theprocess8100 determines (at8120) whether an angle based on touch points is within a threshold angle. In some embodiments, the angle is defined by (1) a first vector from the location of one of the touch points towards the location of the other touch point and (2) a second vector from the location of the one touch point towards a horizontal direction. The horizontal direction of some embodiments is based on the orientation of the device, while the horizontal direction of other embodiments is based on the orientation of the device's display.
• When theprocess8100 determines that the angle is within the threshold angle, theprocess8100 ends. Otherwise, theprocess8100 identifies (at8130) a translation component of the received gesture. In some embodiments, theprocess8100 identifies the translation component of the gesture by identifying an amount of vertical translation of the gesture's touch points.
• Theprocess8100 then adjusts (at8140) the perspective of the map view based on the identified translation. As explained above by reference toFIGS. 3-5 and74-80, a virtual camera is used in some embodiments to render a map view. Theprocess8100 of some embodiments adjusts the perspective of the map view by adjusting the position and orientation of the virtual camera. In some embodiment, a downwards vertical translation causes the virtual camera's position to increase in height and decrease in pitch (e.g., point farther down) while maintaining the virtual camera's point of focus (e.g., the point at which the virtual camera's forward vector intersects the ground). Stated differently, the camera moves along an arc and rotates more downward as the camera moves upwards along on the arc.
• Different embodiments use different coordinate spaces for a map. For example, the map of some embodiments uses a Mercator unit coordinate space. In such embodiments, theprocess8100 adjusts the virtual camera's position with respect to the map in order to adjust the perspective of the map view. As another example, in some embodiments, the map uses a World Geodetic System (e.g., WGS 84) as the map's coordinate space. Theprocess8100 in such embodiments adjusts the map with respect to the virtual camera's position in order to adjust the perspective of the map view.
• In some embodiment, an upwards vertical translation causes the virtual camera's position to decrease in height and increase in pitch (e.g., point farther up) while maintaining the virtual camera's point of focus (e.g., the point at which the virtual camera's forward vector intersects the ground). That is, the camera moves along an arc and rotates more upward as the camera moves downwards along on the arc. In different embodiments, the vertical translation causes different adjustments to the virtual camera's position. For instance, a downwards vertical translation may cause the virtual camera's position to decrease in height and to increase in pitch while maintaining the virtual camera's point of focus and an upwards vertical translation may cause the virtual camera's position to increase in height and decrease in pitch while maintaining the virtual camera's point of focus.
• Finally, theprocess8100 renders (at8150) a map view for display based on the adjusted perspective of the map view. Theprocess8100 then ends.
• As described above, the process illustrated inFIG. 81 shows an adjustment to a perspective of a map view based on gesture input. The process of some embodiments limits the range of movement of the virtual camera. When gesture input causes the virtual camera's position to exceed a defined range, the process of some embodiments modifies the virtual camera's position be within the defined range. In some such embodiments, the process renders the map view of virtual camera's position, even if the virtual camera's position exceeds the defined range, during the gesture input (e.g., fingers used for touch points are still touching the touchscreen). The process renders the map view of the virtual camera's position that is modified within the defined range when the gesture input is completed (e.g., fingers used for touch points are no longer touching the touchscreen). In some embodiments, when the gesture input is completed, the process displays an animation that “snaps” from the map view of virtual camera's position that exceeds the defined range to the map view of the virtual camera's position that is modified within the defined range. In some embodiments, such an animation and the limit feature may be referred to as an offset rubberbanding feature or effect.
• As shown inFIG. 80, different virtual camera positions render different perspectives of a map view. Specifically,FIG. 80 shows the map view transitioning from a 3D map view to a 2D map view. At the different stages of the transition, the buildings appear to fall into the ground. Similarly, during a transition of the map view from the 2D view in thethird stage8015 to the 3D map view in thefirst stage8005, the building would appear to rise out from the ground. In some embodiments, the mapping application scales the vertices of the building along the z-axis in order to cause the building to appear to rise and fall when the map view transitions between 2D-like map views and different perspectives of 3D map views. The following is an example of an equation used by the mapping application of some embodiments to scale a vertex along the z-axis:
• 
  new_scaled_vertex.z=scaled_vertex.z*u_scale
• where scaled_vertex.z is the z component of a vertex, u_scale is a scale factor that determines an amount to scale, and new_scaled_vertex.z is the new scaled value of the z component of the vertex. In addition, when zooming in/out of the 3D map or moving around the 3D map, some embodiments interpolate the alpha values used to blend buildings in and out and interpolate scale values used to adjust the height of buildings.
• As explained above,FIG. 80 shows several example perspective adjustment operations and the corresponding movement of a virtual camera in a 3D map that is used to render 3D map views of the 3D map. One of ordinary skill in the art will understand that any number of different perspective adjustments are possible. In addition, the mapping application of some embodiments performs perspective adjustment operations in response to additional and/or different types of input. For example, in some embodiments, dragging the two fingers down may decrease the perspective position of the virtual camera and dragging the two fingers up may increase the perspective position of the virtual camera.
• WhileFIG. 80 illustrates a virtual camera moving along an arc in order to change the perspective position of the virtual camera, the mapping application of some embodiments moves the virtual camera along different arcs at different zoom levels (e.g., distances from a 3D map).FIG. 82 conceptually illustrates avirtual camera8210 that is moveable along three different arcs8215-8225 at three different zoom levels. As shown,FIG. 82 illustrates a location in a3D map8205 that includes two buildings and two roads that form a T-junction.
• Atzoom level 18, the lowest zoom level in this example, thevirtual camera8210 is movable along thearc8215 for different perspective positions of thevirtual camera8210 pointing towards the3D map8205. In other words, the mapping application of some embodiments at this zoom level allows a user to adjust the perspective for viewing the3D map8205 within the range (e.g., an angular range of 20 degrees) that thevirtual camera8210 is moveable along thearc8215.
• When thevirtual camera8210 transitions from zoom level 19 (e.g., zooms out), the mapping application limits the range of perspective positions of the virtual camera8200 to the range along thearc8215. In some embodiments, the mapping application positions thevirtual camera8210 along at a position along thearc8215 that corresponds to the position that thevirtual camera8210 was at along thearc8220 atzoom level 19 before transitioning to zoomlevel 18. If the position of thevirtual camera8210 at thezoom level 19 exceeds the range of the arc8215 (e.g., a position along the lower perspective end of the arc8220) when transitioning fromzoom level 19 to zoomlevel 18, the mapping application in some embodiments positions the virtual camera at the closest position possible. In other embodiments, the mapping application gradually moves thevirtual camera8210 towards the closest corresponding position on thearc8215 while in a transition region betweenzoom levels 18 and 19 when transitioning fromzoom level 19 to zoomlevel 18 to provide a smooth transition of thevirtual camera8210's movement fromzoom level 19 to zoomlevel 18.
• At thenext zoom level 19, thevirtual camera8210 is movable along thearc8220 for different perspective positions of thevirtual camera8210 pointing towards the3D map8205. As shown, in some embodiments, the mapping application at this zoom level allows the user to adjust the perspective for viewing the3D map8205 within the range (e.g., an angular range of 45 degrees) that thevirtual camera8210 is moveable along thearc8220. Thus, the mapping application allows thevirtual camera8210 to move along a greater range atzoom level 19 compared to zoomlevel 18.
• When thevirtual camera8210 transitions fromzoom level 18 or zoom level 20 (e.g., zooms in or out), the mapping application restricts the range of perspective positions of the virtual camera8200 to the range along thearc8220. The mapping application of some embodiments positions thevirtual camera8210 along at a position along thearc8220 that corresponds to the position that thevirtual camera8210 was at along thearc8215 or8225 atzoom level 18 or 20, respectively, before transitioning to zoomlevel 19. If the position of thevirtual camera8210 at thezoom level 20 exceeds the range of the arc8220 (e.g., a position along the lower perspective end of the arc8225) when transitioning fromzoom level 20 to zoomlevel 19, in some embodiments, the mapping application positions the virtual camera at the closest position possible. The mapping application of other embodiments gradually moves thevirtual camera8210 towards the closest corresponding position on thearc8220 while in a transition region betweenzoom levels 19 and 20 when transitioning fromzoom level 20 to zoomlevel 19 to provide a smooth transition of thevirtual camera8210's movement fromzoom level 20 to zoomlevel 19.
• At thezoom level 20, the highest zoom level for this example, thevirtual camera8210 is movable along thearc8225 for different perspective positions of thevirtual camera8210 pointing towards the3D map8205. That is, the mapping application in some embodiments at this zoom level allows the user to adjust the perspective for viewing the3D map8205 within the range (e.g., an angular range of 85 degrees) that thevirtual camera8210 is moveable along thearc8225. Thus, the mapping application allows thevirtual camera8210 to move along a greater range atzoom level 20 thanzoom levels 18 and 19. When thevirtual camera8210 transitions from zoom level 19 (e.g., zooms in), the mapping application limits the range of perspective positions of the virtual camera8200 to the range along thearc8225.
• The above-describedFIG. 82 shows an example of a virtual camera that is moveable along different arcs at different zoom levels that allow different ranges of perspective positions for the virtual camera. One of ordinary skill in the art will realize that the mapping application of different embodiments uses any number of different arcs with number ranges of perspective positions for the virtual camera at different zoom levels.
• FIG. 83 conceptually illustrates aprocess8300 of some embodiments for determining an arc along which a virtual camera is movable. In some embodiments, the mapping application described above and below by reference toFIGS. 1-108 in this application performs theprocess8300 when a zoom level is adjusted (e.g., zoom in or zoom out) in a 3D viewing mode (e.g., a 3D navigation mode, a 3D map browsing mode, etc.).
• Theprocess8300 starts by determining (at8310) whether the current zoom level is adjusted to a new zoom level. In some embodiments, theprocess8300 determines that the current zoom level is adjusted to a new zoom level when theprocess8300 receives input to adjust the zoom level of a view of a 3D map (e.g., the types of input described below by reference toFIG. 85). When theprocess8300 determines that the current zoom level is not adjusted, theprocess8300 returns to8310 to continue checking for an adjustment to a new zoom level.
• When theprocess8300 determines that an adjustment to a new zoom level is received, theprocess8300 identifies (at8320) an arc for the new zoom level. As described above, the mapping application of some embodiments uses different arcs at different zoom levels. As such, theprocess8300 identifies the arc that is defined for the new zoom level.
• Next, theprocess8300 determines (at8330) whether the arc for the new zoom level has a position that corresponds to the position of the virtual camera along the previous arc of the previous zoom level. Theprocess8300 of some embodiments determines that the arc for the new zoom level has a corresponding position when the position of the virtual camera along the previous arc is within the angular range of the arc for the new zoom level. Referring toFIG. 82 as an example, if the zoom level is transitioning fromzoom level 19 to zoomlevel 18, theprocess8300 determines that thearc8215 forzoom level 18 has a corresponding position when the position of the virtual camera along thearc8220 forzoom level 19 is within approximately the top third of thearc8220.
• Upon determining that the arc for the new zoom level has a corresponding position, theprocess8300 identifies (at8340) the corresponding position along the arc for the new zoom level as new position for the virtual camera. Otherwise, theprocess8300 identifies (at8350) the position along the arc for the new zoom level that is closest to the position of the virtual camera along the previous arc of the previous zoom level as the new position for the virtual camera. Referring toFIG. 82 for an example, if the position of the virtual camera is at the lower perspective end of thearc8220, as shown inFIG. 82, when transitioning fromzoom level 19 to zoomlevel 18, theprocess8300 identifies the position of the virtual camera shown inFIG. 82 along thearc8215 forzoom level 18 as the new position for the virtual camera.
• Finally, theprocess8300 positions (at8360) the virtual camera at the identified new position along the arc for the new zoom level. Theprocess8300 then ends.
• WhileFIGS. 82 and 83 describe a virtual camera that is moveable along different arcs at different zoom levels, some embodiments use a particular arc for a range of different zoom levels (e.g., an arc for zoom levels 10-13, an arc for zoom levels 14-16, etc.). In some embodiments, different ranges of zoom levels are defined to include the same or a different number of zoom levels.
• As discussed above, in some embodiments, the mapping application uses a particular arc along which a virtual camera is movable within a particular defined angular range along the arc when the virtual camera is positioned at a particular zoom level. The mapping applications of some embodiments uses the following technique for moving the virtual camera along an arc.
• FIG. 84 conceptually illustrates a feature provided by the mapping application of some embodiments for maintaining the position of a virtual camera within a defined range along an arc. In particular,FIG. 84 illustrates thevirtual camera8400 at three different stages8405-8415 that show thevirtual camera8400's position maintained within a defined range ofarc8450. As shown inFIG. 84, a location in a3D map8435 includes two buildings and two roads forming a T-junction.
• Thefirst stage8405 shows thevirtual camera8400 at a particular position along thearc8450. As shown, thearc8450 represents a defined range (e.g., angular range) within which thevirtual camera8400 is movable. Thefirst stage8405 also shows three positions8455-8465 along the arc8450 (e.g., perspective view angles). In this example, the mapping application moves thevirtual camera8400 along thearc8450 between the high perspective end of the arc8450 (e.g., the position along thearc8450 when thevirtual camera8400 is most tilted downwards) and theposition8455 in a manner similar to that described above by reference toFIG. 80. Rendering a 3D map view of based on thevirtual camera8400's position in thefirst stage8405 results in3D map view8425.
• When thevirtual camera8400 passes theposition8455 while moving towards the low perspective end of thearc8450, the mapping application reduces the speed (e.g., decelerates) that thevirtual camera8400 moves towards the low perspective end of thearc8450 regardless of the input provided by a user. In some embodiments, the mapping application reduces the speed of thevirtual camera8400 at a constant rate while, in some embodiments, the mapping application reduces the speed of thevirtual camera8400 at an exponential rate. Additional and/or different methods for decreasing the speed of thevirtual camera8400 are used in some embodiments.
• Thesecond stage8410 shows that thevirtual camera8400 has moved to a position along thearc8450 at or near the low perspective end of thearc8450. As shown, a user is providing input to adjust the perspective of the view of the3D map8435 by touching two fingers on the screen and dragging the two fingers in an upward direction (e.g., a swipe gesture). In response to the input, the mapping application moved thevirtual camera8400 toward the low perspective end of thearc8450 while tilting thevirtual camera8450 upwards. When the virtual camera reaches the position8465 along thearc8450, the mapping application prevents thevirtual camera8400 from moving lower beyond the position8465 while the user is continues to provide input to decrease the perspective of the view of the 3D map8435 (e.g., the user continues to drag the two fingers upwards on the touchscreen).
• In some embodiments, when the user stops to provide input to decrease the perspective of the view of the 3D map8435 (e.g., the user lifts the two fingers off the touchscreen), the mapping application “bounces” or “snaps” the position of thevirtual camera8400 from the position8465 up to theposition8460 along thearc8450. As the mapping application is generating orrendering 3D map views of the3D map8435 based on the view of thevirtual camera8400 during the bounce or snap motion, the generated 3D map views provide a bounce animation that displays the 3D map view briefly bounce or snap down in order to indicate to the user that the perspective of the map view cannot be decreased any farther. Rendering a 3D map view using thevirtual camera8400 positioned at this angle results in a3D map view8430 in which the buildings and the roads are taller compared to themap view8425.
• Thethird stage8415 shows thevirtual camera8400 after the mapping application bounced or snapped the position of thevirtual camera8400 to theposition8460 in response to the user ceasing to provide input. Different embodiments use different techniques for implementing the bounce or snap of thevirtual camera8400. For instance, the mapping application of some embodiments starts quickly accelerating thevirtual camera8400 along thearc8450 for a defined distance or until thevirtual camera8400 reaches a defined speed. Then the mapping application decelerates thevirtual camera8400 for the remaining distance to theposition8460 along thearc8450. Other ways to implement the bounce or snap effect are used in some embodiments. Rendering a 3D map view using thevirtual camera8400 positioned at theposition8460 along thearc8450 in thethird stage8415 results in a3D map view8440 in which the buildings appear a little smaller and flatter and the roads appear a little smaller compared to themap view8430.
• As described above,FIG. 84 illustrates a technique for preventing a virtual camera from moving beyond the low perspective end of an arc. Alternatively or in conjunction with preventing the virtual camera from moving beyond the low perspective end of the arc, the mapping application of some embodiments utilizes a similar technique for preventing the virtual camera from moving beyond the high perspective end of the arc. In addition,FIG. 84 shows an example of a position along an arc at which to slow down a virtual camera, a position along the arc to prevent the virtual camera from moving past, and a position along the arc to which the virtual camera snaps or bounces back. Different embodiments define the positions any number of different ways. For instance, in some embodiments, the position along the arc at which to slow down the virtual camera is the same or near the position along the arc to which the virtual camera snaps or bounces back.
• 5. Virtual Camera Movement During Zooming
• Alternatively, or in conjunction with the perspective adjustment feature, the mapping application of some embodiments allows the user to zoom in and out of a view of a 3D map (e.g., by providing gesture input with two fingers).FIG. 85 illustrates a zoom adjustment feature provided by the mapping application of some embodiments. In particular,FIG. 85 illustrates avirtual camera8512 at three different stages8501-8503 that show the movement of thevirtual camera8512 in response to zooming adjustments. As shown,FIG. 85 shows a location in a3D map8510 contains two buildings and a two roads forming a T-junction.
• In thefirst stage8501, the shows a3D map8510 with avirtual camera8512 at a particular position pointing towards the3D map8510. In this position, thecamera8512 is pointing to a location that may be a stationary position of the device or of a location being explored, or a moving position in front of a moving location of the device in a case where the map is used for navigation. Rendering a 3D map view of based on thevirtual camera8512's position results in the3D map view8514.
• Thesecond stage8502 shows thevirtual camera8512 at a different zoom level position pointing towards the3D map8510. Thestage8502 shows that a user has provided input to increase the zoom level of the view of the3D map8510 by touching two fingers near each other on the screen of the device and moving the fingertips apart while the fingers are touching the screen (e.g., a spread gesture).
• The zoom-in adjustment is accomplished by thevirtual camera8512 moving closer to the3D map8510 along aline8550. In some embodiments, theline8550 that the mapping application uses to move thevirtual camera8512 along is a line formed by the front of thevirtual camera8512 and thevirtual camera8512's point of focus. The mapping application of some embodiments moves thevirtual camera8512 along a line formed by the front of thevirtual camera8512 and a location in the3D map8510 based on the user's input to zoom into the view of the3D map8510.
• Rendering a 3D map view using thevirtual camera8512 at this position results in a3D map view8524 in which the buildings and the roads appear closer than the position shown in the3D map view8514. As indicated by the dashed-line version of thevirtual camera8512, thevirtual camera8512 moved closer towards the3D map8510 along theline8550.
• Thethird stage8503 shows thevirtual camera8512 at a different zoom level position pointing towards the3D map8510. In thisstage8503, the user has provided input to decrease the zoom level of the3D map8510 by touching two fingers far apart on the screen of the device and moving the fingertips closer together while the fingers are touching the screen (e.g., a pinch gesture).
• The zoom-out adjustment is accomplished by moving thevirtual camera8512 moving farther away from the3D map8510 along aline8555. In some embodiments, theline8555 that the mapping application uses to move thevirtual camera8512 along is a line formed by the front of thevirtual camera8512 and thevirtual camera8512's point of focus. The mapping application of some embodiments moves thevirtual camera8512 along a line formed by the front of thevirtual camera8512 and a location in the3D map8510 based on the user's input to zoom into the view of the3D map8510.
• Rendering a 3D map view using thevirtual camera8512 at this position results in a3D map view8534 in which the buildings and the roads appear farther than the position illustrated in the3D map view8524. As shown by the dashed-line version of thevirtual camera8512, thevirtual camera8512 moved farther from the3D map8510 along theline8555.
• As described above,FIG. 85 illustrates several example zoom adjustment operations and the corresponding movement of a virtual camera in a 3D map that is used to render 3D map views of the 3D map. One of ordinary skill in the art will realize that any number of different zoom adjustments are possible. Additionally, the mapping application of some embodiments performs zoom adjustment operations in response to additional and/or different types of input (e.g., tapping the screen, double-tap the screen, etc.).
• FIG. 86 conceptually illustrates aprocess8600 of some embodiments adjusting the position of a virtual camera that is used for rendering a map view in response to a zoom level adjustment. In some embodiments, the mapping application described above and below by reference toFIGS. 1-108 performs theprocess8600 when the mapping application is in a map viewing mode (e.g., a location browsing mode, a navigation mode, etc.) and the mapping application receives a gesture through a touchscreen of a device on which the mapping application is executing.
• Theprocess8600 starts by receiving (at8610) a gesture for adjusting the zoom level of a map view. In some embodiments, a gesture for adjusting the zoom level of the map view includes a multi-touch gesture received through a touchscreen (e.g., simultaneously touching the touchscreen with multiple fingers), such as the ones described above by reference toFIG. 85. In this example, theprocess8600 receives a two-touch pinch or spread gesture.
• Next, theprocess8600 determines (at8620) a zoom location based on the received gesture. The zoom location in some embodiments is a location in the map to which the zoom level is adjusted towards (e.g., for zoom in adjustments) or from which the zoom level is adjusted away (e.g., for zoom out adjustments). In some embodiments, theprocess8600 determines the zoom location by (1) identifying the locations of the initial two touch points of the gesture and (2) identifying the midpoint along a line formed by the locations of the two touch points as the zoom location. Theprocess8600 of some embodiments uses additional and/or different techniques for determining the zoom location. For instance, theprocess8600 uses the center of the map view as the zoom location in some embodiments.
• Theprocess8600 then determines (at8630) a zoom amount based on the received gesture. Theprocess8600 of some embodiments determines the zoom amount based on a length difference between (1) a first line formed by the locations of the initial two touch points of the gesture (e.g., the locations at which the user touches a touchscreen with two fingers) and (2) a second line formed by the locations of the ending two touch points of the gesture (e.g., the locations at which the user lifts the two fingers off the touchscreen). In some embodiments, theprocess8600 determines a positive zoom amount (e.g., a zoom-in adjustment) when the length of the second line is greater than the length of the first line whereas theprocess8600 determines a negative zoom amount (e.g., a zoom-out adjustment) when the length of the second line is less than the length of the first line. Theprocess8600 of some embodiments determines that the zoom amount is zero (e.g., no zoom adjustment) when the difference between the length of the second line and the length of the first line is equal or within a threshold length amount. In some embodiments, theprocess8600 employs additional and/or different techniques for determining the zoom amount.
• Next, theprocess8600 adjusts (at8640) the zoom level of the map view based on the identified zoom location and zoom amount. As explained above by reference toFIGS. 3-5 and74-80, a virtual camera is used in some embodiments to render a map view. Theprocess8600 of some embodiments adjusts the zoom level of the map view by moving the position of the virtual camera (1) along a line formed by the front of the virtual camera and the zoom location and (2) by an amount based on the zoom amount.
• Finally, theprocess8600 renders (at8650) a map view for display based on the adjusted zoom level of the map view. Theprocess8600 then ends.
• 6. Virtual Camera Movement During Rotation
• FIG. 87 conceptually illustrates a rotation operation of a 3D map view according to some embodiments of the invention. Specifically,FIG. 87 illustrates the rotation operation at twodifferent stages8705 and8710. In some embodiments, the mapping application performs theprocess9000 described below by reference toFIG. 90 to perform the rotation operation.
• Thefirst stage8705 shows a3D map view8715 of a diagonal intersection of two roads and three buildings near the intersection. As shown, the three buildings are located at the top and sides of the diagonal intersection in the3D map view8715. Thefirst stage8705 also shows that a user is performing a gesture to rotate the3D map view8715. As shown, the user has touched two locations near the center of the3D map view8715 on the touchscreen using two fingers and has rotated the two locations in a clockwise direction.
• Thesecond stage8710 illustrates the corresponding movement of avirtual camera8700 around a3D map8725, which is used to render the3D map view8715, in response to the rotation gesture illustrated in thefirst stage8705. In this example, the rotate gesture was received near or at the intersection of the two roads. As shown, the mapping application has moved thevirtual camera8700 from the left side of the3D map8725 towards the bottom of the3D map8725 by rotating thevirtual camera8700 about a z-axis located at or near the center of the rotation gesture. A3D map view8720 shows an example rendering of the3D map8725 after the rotation of thevirtual camera8700. As shown, the 3D map view is now rotated such that the three buildings and the roads are rotated in a clockwise direction in response to the clockwise rotate gesture shown in thefirst stage8705.
• WhileFIG. 87 shows a rotate gesture performed near or at the center of the 3D map view, rotate gestures may be performed at any location in the displayed 3D map view. In some embodiments, the mapping application rotates the 3D map based entirely or in part on the location of the rotate gesture. For instance, if a rotate gesture is performed in the upper right corner of the 3D map view, the mapping application of some embodiments rotates the virtual camera about a z-axis located at or near the location in the 3D map that corresponds to the location of the rotate gesture.
• In some embodiments, the mapping application provides a position indicator feature that when activated repositions the 3D map view at the user's location (e.g., the location of the device in the 3D map). The mapping application of some such embodiments performs a rotation of the 3D map view differently when it is performed subsequent to an activation of the position indicator feature.
• FIG. 88 conceptually illustrates a rotation operation of a 3D map view after an activation of such a position indicator feature according to some embodiments of the invention. In particular,FIG. 88 illustrates the rotation operation at twodifferent stages8805 and8810.
• Thefirst stage8805 shows a3D map view8815 of a diagonal intersection of two roads and three buildings near the intersection. As shown, the three buildings are located at the top and sides of the diagonal intersection in the3D map view8815. Thefirst stage8805 shows the 3D map view after a user has activated the position indicator feature that caused the mapping application to reposition the 3D map view at the user's location, which is represented by a circle in this example. In addition, thefirst stage8805 shows that the user is performing a gesture to rotate the3D map view8815 in the upper portion of the3D map view8815. As shown, the user has touched two locations in the upper portion of the3D map view8815 on the touchscreen using two fingers and has rotated the two locations in a clockwise direction.
• Thesecond stage8810 illustrates the corresponding movement of avirtual camera8800 around a3D map8825, which is used to render the3D map view8815, in response to the rotation gesture illustrated in thefirst stage8805. In this example, the rotate gesture was received in the upper portion of the3D map view8815 behind the middle building after the position indicator feature was activated.
• In some embodiments, the mapping application rotates the 3D map about the user's location when the mapping application receives a rotate gesture after the position indicator feature is activated. The mapping application of some embodiments performs the rotate operation illustrated inFIG. 88 only when the mapping application receives a rotate gesture after the position indicator feature has been activated and the mapping application has not received any intervening non-rotate gestures. In some embodiments, the mapping application performs the rotate operation illustrated inFIG. 88 for a defined amount of a time after the position indicator feature is activated and then reverts to the rotate operation illustrated inFIG. 87.
• As shown in thesecond stage8810, the mapping application has moved thevirtual camera8800 from the left side of the3D map8825 towards the bottom of the3D map8825 by rotating thevirtual camera8800 about a z-axis located at or near the user's location, which is indicated by a black dot, at the intersection of the two roads. A3D map view8820 shows an example rendering of the3D map8825 after the rotation of thevirtual camera8800. As shown, the 3D map view is now rotated such that the three buildings and the roads are rotated in a clockwise direction about the user's location in response to the clockwise rotate gesture shown in thefirst stage8805.
• The above-describedFIGS. 87 and 88 illustrate rotating a 3D map while in viewing a 3D map in a 3D perspective view. In some embodiments, the mapping application also allows a user to rotate the 3D map while viewing the 3D map in a 2D perspective view.FIG. 89 conceptually illustrates a rotation operation of a 3D map view from a 2D perspective view of the 3D map according to some embodiments of the invention. In particular,FIG. 89 illustrates at three different stages8905-8915 the rotation operation along with an inertia effect for the rotation operation. In some embodiments, the mapping application performs theprocess9000 described below by reference toFIG. 90 to perform the rotation operation.
• Thefirst stage8905 shows a3D map view8920 of a 3D map. As shown, the3D map view8920 includes several streets running in a parallel or perpendicular direction. Thefirst stage8905 also shows that a user is providing input to rotate the3D map view8920. Specifically, the user is performing a gesture to rotate the3D map view8920 by touching two fingers at two locations on the touchscreen and rotating the two fingers in a clockwise direction, as indicated by two arrows.
• Thesecond stage8910 shows the 3D map immediately after the user has completed the input to rotate the 3D map. For this example, the user completed the input by lifting the two fingers off the touchscreen of the device. In addition, thesecond stage8910 shows a3D map view8925 of the 3D map rendered by the mapping application. As shown, the mapping application has rotated the 3D map in a clockwise direction from the3D map view8920 to the3D map view8925. The streets shown in thefirst stage8905 have rotated approximately 45 degrees in the clockwise direction.
• The mapping application of different embodiments utilize different methods to implement an inertia effect for a rotation operation. For instance, in some embodiments, the mapping application determines an angular velocity of the user's input at or near the instance at which the user lifts the fingers from the touchscreen based on one of the fingers or an average of both of the fingers. The mapping application uses the angular velocity to determine an angle amount for the inertia effect and determines the manner at which the virtual camera used to view the 3D map decelerates (e.g., constant, exponential, logarithmic, etc.) the angular velocity to rotate the determined angle amount. In some embodiments, the mapping application renders and displays an animation of the inertia effect (e.g., a decelerating rotation of the 3D map from the3D map view8925 that rotates the 3D map the determined angle amount). The mapping application of some embodiments does not implement the inertia effect. Rather, the inertia effect is implemented by a framework of an operating system on which the mapping application operates.
• Thethird stage8915 illustrates the 3D map after the mapping application has rendered and displayed the animation of the inertia effect. As shown, a3D map view8930 of the 3D map rendered by the mapping application is displayed. In thethird stage8915, the mapping application has rotated the 3D map farther clockwise after the user completed the input in thesecond stage8910. As shown, a3D map view8930 in thethird stage8915 shows the streets rotated farther clockwise from the streets shown in the3D map view8925.
• FIG. 90 conceptually illustrates aprocess9000 of some embodiments for rotating a map view based on gesture input. In some embodiments, the mapping application performs theprocess9000 when the mapping application is in a map viewing mode (e.g., a location browsing mode, a navigation mode, a 2D viewing mode, a 3D viewing mode, etc.) and the mapping application receives a gesture through a touchscreen of a device on which the mapping application is executing.
• Theprocess9000 starts by receiving (at9010) a gesture for rotating the map view. In some embodiments, a gesture for rotating the map view includes a multi-touch gesture received through a touchscreen (e.g., simultaneously touching the touchscreen with multiple fingers). In this example, theprocess9000 receives a two-touch rotate gesture.
• Next, theprocess9000 identifies (at9020) a rotation component of the received gesture. Theprocess9000 of some embodiments identifies the rotation component of the gesture by identifying an amount of rotation of the gesture's touch points. For instance, in some such embodiments, theprocess9000 identifies the amount of rotation of the gesture's touch points by (1) determining a first vector from the initial location of one touch point to the initial location of the other touch point, (2) determining a second vector from a second location of the one touch point to a second location of the other touch point, and (3) determining a rotation direction based on the initial locations of the touch points and the second locations of the touch points.
• Theprocess9000 then determines (at9030) whether the amount of rotation is within a threshold amount. When theprocess9000 determines that the amount of rotation is not within the threshold amount, theprocess9000 ends. Otherwise, theprocess9000 determines (at9040) an axis of rotation based on the gesture. In some embodiments, theprocess9000 determines the axis of rotation by (1) identifying a point along a vector from the initial location of one touch point to the initial location of the other touch point and (2) determining a point on map view that corresponds to the point along the vector (e.g., the point on the map that coincides with the point along the vector). Theprocess9000 uses the determined point on the map view as the location of an axis (e.g., a z-axis) about which the map view is rotated.
• Next, theprocess9000 then adjusts (at9050) the map view based on the axis of rotation and the amount of rotation. In some embodiments, theprocess9000 adjusts the map view by rotating the map view about the determined axis of rotation by the determined amount of rotation in the determined rotation direction. Different embodiments use different coordinate spaces for a map. For example, the map of some embodiments uses a Mercator unit coordinate space. In such embodiments, theprocess9000 adjusts the virtual camera's position with respect to the map in order to adjust the map view. As another example, in some embodiments, the map uses a World Geodetic System (e.g., WGS 84) as the map's coordinate space. Theprocess9000 in such embodiments adjusts the map with respect to the virtual camera's position in order to adjust the map view.
• Finally, theprocess9000 renders (at9060) the adjusted map view for display on the device. In some embodiments, the rendered map view is an image that represents the adjusted map view. Then theprocess9000 ends.
• TheFIGS. 87-90 described above show various examples of rotate operations performed on a 3D map. In some embodiments, the 3D map is rotatable at a defined range and/or set of zoom levels. For example, in some embodiments, the mapping application allows the 3D map to be rotated at a defined number of the highest zoom levels (e.g., zoom levels 10-20) and prevents the 3D map from being rotated at the remaining lower zoom levels (e.g., zoom levels 1-10). In some such embodiments, the mapping application does not generate instructions to rotate the 3D map when the mapping application receives input to rotate the 3D map at a zoom level that is defined to not allow rotation operations. In other such embodiments, the mapping application generates instructions to rotate the 3D map when the mapping application receives input to rotate the 3D map at a zoom level that is defined to not allow rotation operations, but the mapping application simply ignores the instructions. One of ordinary skill in the art will realize that the zoom levels at which rotate operations are allowed to be performed on a 3D map may be defined any number of different ways in different embodiments.
• B. Immersive and Non-Immersive Viewing Modes
• Many of the figures described above and below illustrate a mapping application that provides a turn-by-turn navigation feature. In some embodiments, the mapping application provides several viewing modes for such a navigation feature. For instance, the mapping application of some embodiments provides an immersive viewing mode and a non-immersive viewing mode. In some embodiments, these two viewing modes are for viewing different 3D maps of the same geographical region. That is, one 3D map that is viewable using the immersive viewing mode and another 3D map that is viewable using the non-immersive viewing mode are 3D maps of the same geographic region. However, the immersive and non-immersive viewing modes of some embodiments are not limited to the turn-by-turn navigation feature. For instance, both the immersive and non-immersive viewing modes may be available in a map browsing mode (i.e., when not using navigation). Furthermore, some embodiments utilize the immersive viewing mode for the turn-by-turn navigation mode and the non-immersive viewing mode for the map browsing mode.
• In some embodiments, the non-immersive and immersive viewing modes are viewing modes for viewing different 3D maps that have different constructs and/or geometries. For instance, the non-immersive viewing mode of some embodiments is for viewing a 3D map that is described by building tiles and road tiles. In some embodiments, a building tile contains polygon data (e.g., a polygon of the footprint of building and a height value of the building) for each of the buildings located in the region of the 3D map that the building tile represents. A road tile, in some embodiments, stores information about the various roads and land that are located in the region of the 3D map that the road tile represents. In some embodiments, the roads are defined by road vectors that represent the center of roads (e.g., centerlines) and the land is defined by polygon data.
• The immersive viewing mode of some embodiments is for viewing a 3D map that is described by building tiles and navigation tiles. In some embodiments, the same building tiles that are used for the non-immersive viewing mode are used for the immersive viewing mode while, in some embodiments, building tiles used for the immersive viewing mode are different (e.g., the immersive building tiles include higher resolution polygon data for the buildings).
• In some embodiments, a navigation tile includes polygon data for roads and polygon data for the land. By using polygon data to define roads, the navigation tiles can be defined more richly. For example, the roads appear 3D and/or appear as asphalt, curbs may be defined along the sides of streets, shadows can be specified for overpasses and bridges, etc. However, the navigation tiles require more information to describe the roads compared to road tiles, in some embodiments.
• In some embodiments, stylesheet data, which is described in more detail below, is used to specify the appearance of constructs in the 3D map (e.g., buildings, streets, highways, land cover, foliage, labels, shadows, road curbs, etc.). For example, stylesheet data may specify the textures to apply to the different constructs, the color of the textures that are applied to the constructs, etc. In some embodiments, the stylesheet data is used to specify the textures for roads in order for the roads to appear like asphalt.
• As mentioned above, both viewing modes use the same building tiles to render buildings for the viewing mode in some embodiments. The stylesheet data in some embodiments defines different styles (e.g., different textures, colors, levels of details etc.) for the buildings in the different viewing modes. For instance, in some embodiments, buildings in the non-immersive viewing mode are styled as gray and the outlines of city blocks have sharp corners. The same buildings in the immersive viewing mode of some embodiments are styled as light gray or white and the outlines of city blocks have rounded corners. Additional and/or different constructs may be styled differently for the different viewing modes in some embodiments. For instance, some embodiments specify different textures for the same buildings in different viewing modes.
• In addition, style sheet data may specify different styles for the same or similar elements in the 3D map at different zoom levels. For instance, some embodiments specify simple textures for buildings at low zoom levels because the buildings are farther away and details may be difficult to notice or not noticeable at all. For higher zoom levels, some embodiments specify more detailed styling for buildings, such as defined shapes of building rooftops (as opposed to flat rooftops for all buildings).
• In addition, the non-immersive and immersive viewing modes may be defined for viewing 3D maps at different ranges of zoom levels. For example, the non-immersive viewing mode of some embodiments is defined for viewing a 3D map at zoom levels 0-14 while the immersive viewing mode of some embodiments is defined for viewing the 3D map at zoom levels 15-21. The viewing modes may be defined to view any number of different zoom levels in different embodiments. In some instances, the range of zoom levels of the immersive viewing mode are defined as higher zoom levels than, lower zoom levels than, the same zoom levels as, or zoom levels that overlap with the zoom levels defined for the non-immersive viewing mode. For example, in some embodiments, the non-immersive viewing mode is defined for viewing at all zoom levels (e.g., zoom levels 0-21) while the immersive viewing mode is defined for a subset of high zoom levels (e.g., zoom levels 15-21).
• A zoom level, in some embodiments, is a defined range of distances from the 3D map. For instance, a first zoom level may be defined as 6-10 distance units (e.g., feet, yards, meters, etc.) from the 3D map along the z-axis, a second zoom level may be defined as 11-15 distance units from the 3D map along the z-axis, a third zoom level may be defined as 16-20 distance units from the 3D map along the z-axis, etc. One of ordinary skill will recognize that zoom levels may be defined to include any number of different ranges of distances using any number of different distance units. In some embodiments, a zoom level is a defined range of distances from a 2D map, (e.g., a 2D version of the 3D map).
• In some embodiments, a map service provider (e.g., a map server) generates and provides different sets of 3D map tiles of the 3D map for different zoom levels. For instance, the map service provider generates a set of 3D map tiles for azoom level 0, a set of 3D map tiles for azoom level 1, a set of 3D map tiles for azoom level 2, etc. (e.g., for the non-immersive viewing mode). In some embodiments, the map service provider generates only one set of 3D map tiles of the 3D map (e.g., for the immersive viewing mode). The mapping application of some such embodiments renders 3D map views of the 3D map at different zoom levels by modifying (e.g., scaling up and/or down) the data in the 3D map tiles (e.g., vertices, polygons, etc.).
• In some embodiments, the different sets of 3D map tiles that the map service provider generates for the different zoom levels have different levels of detail. For instance, the set of 3D map tiles generated for the highest zoom level includehigh resolution 3D constructs (e.g., the 3D constructs include more vertices) to more accurately represent the constructs. The set of 3D map tiles generated for the lowest zoom levels includelow resolution 3D constructs (e.g., the 3D constructs tiles include fewer vertices) because the 3D will be rendered from a far distance. Any additional detail included inhigher resolution 3D map tiles is not noticeable at such far distances.
• Constructs and/or geometries of non-immersive and immersive viewing modes of some embodiments are separately defined in different sets of 3D map tiles. The different sets of 3D map tiles are generated by a map service provider based on 3D maps that the map service provider generates or imports from a 3D map data provider(s). The different 3D map tiles are used by the mapping application of some embodiments to render 3D map views for the different viewing modes of the 3D map. In some instances, the map service provider generates multiple sets of 3D map tiles for the same viewing mode. For instance, in some embodiments, the map service provider generates a set of 3D building tiles and a set of 3D road tiles for a non-immersive viewing mode. For an immersive viewing mode, the mapping service provider of some embodiments generates a set of 3D building tiles (and/or the same set of 3D building tiles for the non-immersive viewing mode) and a set of 3D navigation tiles.
• FIG. 91 conceptually illustrates an example of amapping application9100 that renders 3D map views for different zoom levels of different viewing modes. As shown in this example, the non-immersive viewing mode is defined for viewing a 3D map atzoom levels 1 to N−1 while the immersive viewing mode is defined for viewing the 3D map at zoom levels N to N+M. In some embodiments, theapplication9100 implements a portion or all of the mapping application described above and below by reference toFIGS. 1-108. As shown,FIG. 91 includes themapping application9100, amap service provider9110, sets of3D map tiles9120, and sets of 3D map views9130.
• As mentioned above, a map service provider (e.g., a map server) generates and provides in some embodiments different sets of 3D map tiles of a 3D map for different zoom levels. As illustrated, themap service provider9110 generates and provides a set of3D map tiles9120 for each of the zoom levels 1-N. In some embodiments, themap service provider9110 is implemented by the map service described below in more detail by reference toFIG. 108. Themapping application9100 generates 3D map views9130 based on 3D map tiles received from themap service provider9110.
• Themapping application9100 of some embodiments generates 3D map views at a particular zoom level based on 3D map tiles defined for the particular zoom level. For instance, as shown inFIG. 91, themapping application9100 uses the set of3D map tiles9120 defined forzoom level 1 to generate for the non-immersive viewing mode the set of 3D map views9130 atzoom level 1. Similarly, themapping application9100 generates for the non-immersive and immersive viewing modes a set of 3D map views9130 at other zoom levels from the set of3D map tiles9130 defined for the corresponding zoom level.
• In some embodiments, themapping application9100 generates 3D map views for several zoom levels based on 3D map tiles defined for a single zoom level. As shown in this example, themapping application9100 uses the set of3D map tiles9120 defined for zoom level N to generate for the immersive viewing mode sets of3D map tiles9120 at zoom levels N to N+M. Themapping application9100 of some embodiments generates 3D map views at N+1 to N+M zoom levels by modifying (e.g., scaling up and/or down) the data of the 3D map tiles (e.g., 3D constructs) defined for zoom level N.
• As illustrated inFIG. 91, themapping application9100 generates 3D map views for a non-immersive viewing mode at a particular zoom level based on 3D map tiles defined for the particular zoom level whereas themapping application9100 generates 3D map views for an immersive viewing mode at a particular zoom level based on 3D map tiles defined for the particular zoom level. WhileFIG. 91 illustrates a mapping application that generates for animmersive viewing mode 3D map views at multiple different zoom levels based on a set of 3D map tiles for a particular zoom level, in some embodiments, the mapping application generates additional zoom levels for a non-immersive viewing mode.
• In addition,FIG. 91 shows sets of3D map tiles9120 stored on a single storage of themap service provider9110. In some embodiments, different sets of3D map tiles9120 are stored in different storages. For example, some3D map tiles9120 for the non-immersive viewing mode (some3D map tiles9120 from each of thezoom levels 1 to N−1 in this example) may be stored in a first storage (e.g., a 3D road tile storage) and some3D map tiles9120 for the immersive viewing mode (e.g., some3D map tiles9120 from zoom level N) are stored in a second storage (e.g., a 3D navigation tile storage). In some embodiments, some 3D map tiles (e.g., some 3D map tiles from each of thezoom levels 1 to N) are stored in yet another storage (e.g., a 3D building tile storage).
• FIG. 92 illustrates the movement of thevirtual camera9200 around the region of a3D map9235 at three different stages9205-9215. In particular, the3D map9235 is an example 3D map defined to be viewed by an immersive viewing mode of some embodiments. As noted above, in some embodiments, the map service provider from which the mapping application retrieves tiles only provides one set of 3D map tiles of the3D map9235 at a particular zoom level (e.g., zoom level 15). To render higher level zoom levels (e.g., zoom levels 16-21) based on these 3D map tiles, the mapping application of some such embodiments renders 3D map views at different zoom levels by modifying (e.g., scaling up and/or down) the data in the 3D map tiles (e.g., vertices, polygons, etc.). As shown, the region of the3D map9235 includes two building and a road that abuts another road.
• Thefirst stage9205 illustrates thevirtual camera9200 at a particular location and position in the3D map9235. In some embodiments, the point at which thevirtual camera9200 is focusing (i.e., the point at which a line projecting out of the front of the virtual camera intersects the road) in the3D map9235 is referred to as a point of focus. In thefirst stage9205, thevirtual camera9200's point of focus is near the intersection formed by the two roads. An example rendered image of the3D map9235 from thevirtual camera9200's point of view at thisstage9205 is illustrated in the3D map view9220. As shown, the3D map view9220 of the3D map9235 includes detailed constructs like trees, lane markers, asphalt (represented by a graying of the roads in this example).
• Thesecond stage9210 shows thevirtual camera9200 at a different location and position in the3D map9235. As shown in thesecond stage9210, the mapping application has moved thevirtual camera9200 down and towards the left of the3D map9235. For this example, the mapping application has moved thevirtual camera9200 in response to input (e.g., a gestural input such as pinch gesture or a double tap gesture) for zooming in on the3D map9235. From thefirst stage9205 to thesecond stage9210, the mapping application automatically moved thevirtual camera9200 in the manner described in order to zoom in on the3D map9235. An example rendered image of the3D map9235 from thevirtual camera9200's point of view at thesecond stage9210 is illustrated in the3D map view9225. The3D map view9225 shows the buildings and trees larger and taller and the roads and lane markers are wider than that shown in thefirst stage9205.
• Thethird stage9215 illustrates thevirtual camera9200 at another different location and position of the3D map9235. At thisstage9215, the mapping application has moved thevirtual camera9200 farther down and towards the left of the3D map9235 from the position of thevirtual camera9200 shown in thesecond stage9210. Continuing with the example above, the mapping application has moved thevirtual camera9200 in response to input (e.g., a gestural input such as pinch gesture or a double tap gesture) for zooming in on the3D map9235. Between thesecond stage9210 to thethird stage9215, the mapping application automatically moved thevirtual camera9200 in the manner described in order to zoom in on the3D map9235. An example rendered image of the3D map9235 from thevirtual camera9200's point of view at thisstage9215 is illustrated in the3D map view9230. As shown in the3D map view9230, the buildings and trees are larger and taller and the roads and lane markers are wider than that shown in thesecond stage9210.
• FIG. 93 illustrates the movement of thevirtual camera9300 around the region of a3D map9335 and a3D map9340 at three different stages9305-9315. Specifically, the3D map9335 is similar to the3D map9235 described above by reference toFIG. 92. The3D map9340 in this example is a 3D map of the same geographical region as the3D map9335, but is defined to be viewed by a non-immersive viewing mode of some embodiments. As such, the region of the3D map9340 similarly includes two building and a road that abuts another road.
• Thefirst stage9305 illustrates thevirtual camera9300 at a particular location and position in the3D map9335. In some embodiments, the point at which thevirtual camera9300 is focusing (i.e., the point at which a line projecting out of the front of the virtual camera intersects the road) in the3D map9335 is referred to as a point of focus. In thefirst stage9305, thevirtual camera9300's point of focus is near the intersection formed by the two roads. An example rendered image of the3D map9335 from thevirtual camera9300's point of view at thisstage9305 is illustrated in the3D map view9320. As shown, the3D map view9320 of the3D map9335 includes detailed constructs like trees, lane markers, asphalt (represented by a graying of the roads in this example).
• Thesecond stage9310 shows thevirtual camera9300 at a different location and position in the3D map9335. As shown in thesecond stage9310, the mapping application has moved thevirtual camera9300 up and towards the right of the3D map9335. For this example, the mapping application has moved thevirtual camera9300 in response to input (e.g., a gestural input such as spread gesture or a two-touch tap gesture) for zooming out from the3D map9335. From thefirst stage9305 to thesecond stage9310, the mapping application automatically moved thevirtual camera9300 in the manner described in order to zoom out from the3D map9335. An example rendered image of the3D map9335 from thevirtual camera9300's point of view at thesecond stage9310 is illustrated in the3D map view9325. The3D map view9325 shows the buildings and trees smaller and shorter and the roads and lane markers are narrower than that shown in thefirst stage9305.
• Thethird stage9315 illustrates thevirtual camera9300 at another different location and position of the3D map9235. At thisstage9215, the mapping application has switched from the immersive viewing mode to the non-immersive viewing mode. In some embodiments, a particular zoom level is defined as the transition point between the immersive viewing mode and the non-immersive viewing mode. For instance, the mapping application of some embodiments uses the immersive viewing mode for viewing the region of the 3D map at zoom levels 15-21 and uses the non-immersive viewing mode for viewing the region of the 3D map at zoom levels 0-14. Thus, when the mapping application receives input to zoom fromzoom level 15 to zoom level 14, the mapping application automatically switches from the immersive viewing mode to the non-immersive viewing mode. Similarly, when the mapping application receives input to zoom from zoom level 14 to zoomlevel 15, the mapping application automatically switches from the non-immersive viewing mode to the immersive viewing mode. Different embodiments may define the zoom level at which to switch between the two zoom levels differently.
• In addition, some embodiments do not switch between immersive and non-immersive viewing modes based on the zoom level. For instance, different embodiments use the immersive viewing mode for turn-by-turn navigation and the non-immersive viewing mode for map browsing, or include a UI control that allows the user to switch between a non-immersive viewing mode and an immersive viewing mode.
• FIG. 94 conceptually illustrates an example of amapping application9400 that renders 3D map views for different zoom levels of different viewing modes. As shown in this example, the non-immersive viewing mode is defined for viewing a 3D map atzoom levels 1 to X, while the immersive viewing mode is defined for viewing the 3D map at zoom levels X-K to X. Thus, the application may display a map at zoom levels X-K to X in either immersive or non-immersive mode. As shown,FIG. 94 includes themapping application9400 andmap service provider9410, the functionality of which is similar to that described above by reference toFIG. 91 (i.e., themap service provider9410 generates and providesmap tiles9420, and the mapping application renders map views9430 by using these tiles).
• In this case, as inFIG. 91, themap service provider9410 generates and provides a different set of3D map tiles9420 for each non-immersive zoom level, while only generating and providing a single set of3D map tiles9420 for the immersive viewing mode. Themapping application9400 generates the map views for zoom levels X-K to X using the zoom level X-K map tiles. In some embodiments, the mapping application generates map views using the non-immersive 3D map tiles when in map browsing, route display, route inspection, and auto-stepping modes, and generates map views using the immersive 3D map tiles when in turn-by-turn navigation mode. These modes are described in greater detail by reference toFIGS. 105A-105B below.
• In the above example ofFIG. 93, the mapping application receives input to zoom out from a zoom level defined for the immersive viewing mode to another zoom level defined for the non-immersive viewing mode. As such, the mapping application performed a preload operation to preparerendering 3D map views of the3D map9340, which is defined for the non-immersive viewing mode. Examples of a preloading operations is described below by reference to theFIGS. 97,95, and102.
• After the preloading operation, the mapping application has moved thevirtual camera9300 from the position shown in thesecond stage9310 to a relative position farther up and towards the right of the3D map9335. Continuing with the example above, the mapping application has moved thevirtual camera9300 in response to input (e.g., a gestural input such as pinch gesture or a double tap gesture) for zooming in on the3D map9335. Between thesecond stage9310 to thethird stage9315, the mapping application automatically preloaded the3D map9340 and moved thevirtual camera9300 in the manner described in order to zoom out from on the3D map9335. An example rendered image of the3D map9335 from thevirtual camera9300's point of view at thisstage9315 is illustrated in the3D map view9330. As shown, the3D map view9330 contains the same buildings and roads, but does not contain any of the constructs and/or details shown in the 3D map views9320 and9325 since the mapping application is now rendering 3D map views from the3D map9340, which is for the less detailed non-immersive viewing mode.
• As shown inFIGS. 92 and 93, the immersive viewing mode and the non-immersive viewing mode provide different levels of detail of a region of a 3D map based on the zoom level at which the region is viewed. In some embodiments, the mapping application renders different textures for buildings at different zoom levels. For instance, the mapping application of some embodiments renders more detailed textures (e.g., colors, patterns, etc.) for buildings in the immersive viewing mode and renders simpler textures (e.g., solid colors, etc.) for the same buildings in the non-immersive viewing mode. In some embodiments, the mapping application renders different textures for the same buildings at different zoom levels in the immersive viewing mode. Additionally, or conjunctively with rendering different textures for buildings based on different zoom levels, the mapping application of some embodiments renders different textures for buildings based on other factors (e.g., time of day, geographical region, season of the year, holidays, etc.) as well.
• FIG. 95 conceptually illustrates aprocessing pipeline9500 of the mapping application of some embodiments forrendering 3D map views9560 based on different 3D map tiles9540-9550. As shown, theprocessing pipeline9500 includes amap rendering engine9510, avirtual camera module9520, amesh builder9530, atile processor9570, three different storages9540-9550 of 3D map tiles, and a stylesheet storage9555. In some embodiments, thenavigation tiles storage9540stores 3D map tiles (also referred to as navigation tiles) for the immersive viewing mode, and the road tiles (also referred to as road tiles)storage9545store 3D map tiles for the non-immersive viewing mode. Thebuilding tiles storage9550 of some embodiments stores 3D map tiles (also referring to as building tiles) for use in both immersive and non-immersive viewing modes. The stylesheets storage9555 stores definitions for rendering textures for 3D map views9560 and other styling information for rendering the 3D map views9560.
• Thevirtual camera9520 identifies a location and orientation (e.g., perspective position, zoom level, etc.) from which to view a 3D map. Thevirtual camera9520 sends the field of view of the 3D map (also referred to as a viewing frustum) to thetile processor9570 for processing.
• Thetile processor9570 receives field of views of 3D maps from thevirtual camera9520. In some embodiments, thetile processor9570 performs any necessary culling (e.g., removing surface area too far away, removing objects that will be entirely behind other objects, etc.) to the 3D map view before sending themesh builder9530 “empty” virtual 3D map tiles, in some embodiments. Thetile processor9570 of some embodiments receives “built” virtual 3D map tiles from themesh builder9530 and sends them to themap rendering engine9510 for rendering. In some embodiments, thetile processor9570 is implemented by the controller and tile provider(s) described below by reference toFIGS. 98 and 102.
• In some embodiments, themesh builder9530 prepares virtual 3D map tiles fortile processor9570. Themesh builder9530 requests 3D map tiles (e.g., decompressed 3D map tiles) from the 3D map tile storages9540-9550 based on the viewing mode that is to be rendered for field of view of the 3D map. For instance, when the viewing mode is an immersive viewing mode, themesh builder9530 of some embodiments requests navigation map tiles from thestorage9540 and building tiles from thestorage9550. In some embodiments, themesh builder9530 requests road tiles from thestorage9545 and building tiles from thestorage9550.
• Once themesh builder9530 receives the map tiles, themesh builder9530 builds a polygon mesh using vector data stored in the tiles. Themesh builder9530 also provides texture information based on the styling information retrieved from the stylesheet storage9555. In some embodiments, themesh builder9530 builds the polygon mesh on a tile-by-tile basis and sends the virtual 3D map tiles, which, in some embodiments, are a polygon mesh version of the virtual 3D map tiles received themesh builder9530 received from by thetile processor9570.
• Themap rendering engine9510 is responsible for generating a drawing (e.g., a 3D map view of a 3D map) to output to a display device based on the field of view received from thevirtual camera9520. Additional details of themesh builder9530, thevirtual camera9520, thetile processor9570, and themap rendering engine9510 are described below in further detail by reference toFIGS. 98 and 102.
• An example operation of theprocessing pipeline9500 will now be described. Thevirtual camera9520 identifies a location and orientation from which thevirtual camera9520 views a 3D map. Thevirtual camera9520 sends to the tile processor9570 a field of view of the 3D map based on the identified location and orientation.
• When thetile processor9570 receives the field of view, thetile processor9570 of some embodiments culls the field of view. Thetile processor9570 then sends virtual map tiles to themesh builder9530 for processing.
• When the mapping application generates 3D map views in an immersive viewing mode, themesh builder9530 retrieves navigation tiles from thenavigation tiles storage9540 and building tiles from thebuilding tiles storage9550. However, when the mapping application generates 3D map views in a non-immersive viewing mode, themesh builder9530 instead retrieves road tiles from theroad tiles storage9545 and building tiles from thebuilding tiles storage9550. That is, different sets of 3D map tiles are used by theprocessing pipeline9500 for rendering 3D map views in these different viewing modes.
• In some embodiments, 3D map tiles are cached for a period of time in thestorage9540. Thus, in some such embodiments, if 3D map tiles are not available in thestorage9540, the desired 3D map tiles are retrieved from a map service.
• Once themesh builder9530 has all the appropriate 3D map tiles, themesh builder9530 builds a polygon mesh based on vector data in the 3D map tiles. Themesh builder9530 then sends virtual map tile versions of the 3D map tiles to thetile processor9570.
• When thetile processor9570 receives the virtual map tiles from themesh builder9530, thetile processor9570 sends them to themap rendering engine9510 for rendering. Themap rendering engine9510 receives the virtual map tiles from thetile processor9570 and renders a3D map view9560 based on the virtual map tiles.
• The description of several figures above and below (e.g.,FIGS. 95,98, and102) discusses processing pipelines forrendering 3D map views of a 3D map. In some embodiments, the processing pipeline generates and stores a data structure for rendering a map view.FIG. 96 conceptually illustrates adata structure9600 used by the processing pipeline of some embodiments.
• As shown, thedata structure9600 includes avirtual camera ID9605, virtualcamera location data9610,viewing mode9615,3D map tiles9620,stylesheet data9625, 3Dmap tile cache9630,virtual map tiles9635, a3D map view9640, andother data9645.
• Thevirtual camera ID9605 is a unique identifier for identifying a virtual camera that is used to render a 3D map view. As mentioned above and below, the processing pipeline of some embodiments instantiates several virtual cameras for identifying views of the 3D map. As shown inFIG. 96, a set ofvirtual cameras9650 are available for the processing pipeline to use. In this example, thevirtual camera ID9605 is identifying thevirtual camera2 for the processing pipeline to use to render the 3D map view.
• The virtualcamera location data9610 stores information about the location of the virtual camera identified by thevirtual camera ID9605. Examples of such information include coordinates of the virtual camera (e.g., x, y, and z coordinates), a pan angle of the virtual camera, a tilt angle of the virtual camera, a roll angle of the virtual camera, a zoom level of the virtual camera, etc.
• Theviewing mode9615 is data that indicates the viewing mode in which to render the 3D map view. For instance, theviewing mode9615 might store data that indicates a non-immersive viewing mode, an immersive viewing mode, a satellite viewing mode, a hybrid viewing mode, etc.
• The3D map tiles9620 is the set of 3D map tiles that represent the portion of the 3D map from which the 3D map is to be rendered. The processing pipeline of some embodiments uses the virtualcamera location data9610 and theviewing mode9615 to identify the portion and retrieve the corresponding 3D map tiles.
• Thestylesheet data9625 contains styling information that the processing pipeline uses to build meshes. In some embodiments, the processing pipeline uses thestylesheet data9625 to determine texture data, shadow data, triangulation data, etc.
• The 3Dmap tile cache9630 is used tocache 3D map tiles. In some embodiments, the processing pipeline caches recently used 3D map tiles, often used 3D map tiles, 3D map tiles that the processing pipeline determines is likely to be used in the near future, etc.
• Thevirtual map tiles9635 stores map tiles that include built map constructs. As shown, a virtual map tile includes building constructs, road/navigation constructs, label constructs, landcover constructs, along with other constructs. In particular, thevirtual map tiles9635 of some embodiments stores map tiles that include road constructs when the 3D map view is to be rendered in the non-immersive viewing mode and stores map tiles that include navigation constructs when the 3D map view is to be rendered in the immersive viewing mode.
• The3D map view9640 contains the 3D map view that the processing pipeline renders based on the various information in thedata structure9600 that the mapping application of some embodiments displays.Other data9645 stores information that the processing pipeline in some embodiments might need to render the 3D map view (e.g., the number of mesh builders to use, the number of tile providers to use, etc.).
• One of ordinary skill in the art will recognize that thedata structure9600 is just one possible data structure that the processing pipeline of some embodiments uses to store the required information to render a 3D map view. For example, different embodiments might store additional or less information, store the information in a different order, use a different structure to store the data, etc.
• FIG. 97 conceptually illustrates a state diagram9700 of a mapping application of some embodiments. As shown, the state diagram9700 includes states9710-9770 of the mapping application when the mapping application switches between a first viewing mode and a second view mode during a route navigation. In some embodiments, the first and second viewing modes are a non-immersive viewing mode and an immersive viewing mode. The first and second viewing modes of some embodiments are for viewing different 3D maps of the same geographical region. That is, a first 3D map that is viewed using the first viewing mode and a second 3D map that is viewed using the second viewing mode are both for viewing the same geographic region.
• Atstate9710, the mapping application renders 3D map views in a first map viewing mode. In some embodiments, the mapping application entersstate9710 when the mapping application enters a navigation mode (e.g., by selecting UI item for initiating a route navigation). For this example, when the mapping application entersstate9710, the mapping application uses a first virtual camera to view a first 3D map and renders 3D map views for the map viewing mode in a non-immersive viewing mode.
• Instate9710, the mapping application of some embodiments receives various commands (e.g., zoom commands, pan commands, rotate commands, tilt commands, etc.) to move the virtual camera around the first 3D map and render 3D map views based on the position of the virtual camera in the first 3D map. As the virtual camera moves around the first 3D map, the mapping application retrieves tiles from a map service when the virtual camera to a region of the first 3D map about which the mapping application does not have data.
• Atstate9710, if the mapping application determines that a transition to a second viewing mode is likely, the mapping application transitions tostate9720 to perform a preloading operation for the second viewing mode in order to provide a smooth transition from the first viewing mode to the second viewing mode (e.g., to prevent any stuttering or delays when transitioning between modes). In this example, the second viewing mode is the immersive viewing mode. The mapping application of some embodiments determines to transition to the second view mode is likely based on any number of different factors. One example of such a factor includes a zoom level at which the virtual camera is viewing the first 3D map. For example, if the identified zoom level of the map view is a zoom level in which roads are displayed as yellow lines (e.g., a non-immersive, or standard viewing mode), and the zoom level is within a threshold amount of zoom levels from a zoom level defined for transitioning between the non-immersive mode and an immersive mode, the mapping application determines that a transition to second viewing mode is likely. Additional and/or other factors that the mapping application considers include a set of heuristics that indicate that a transition to the second viewing mode is likely.
• Atstate9720, the mapping application downloads data for a second loader that the mapping application generates for the second viewing mode. In some embodiments, the data includes 3D map tiles and styling information (e.g., stylesheets.) required for the second viewing mode (e.g., 3D map tiles that include areas around the user's location and along the route navigation). The loader loads data related to the second 3D map. In addition, the mapping application generates a second virtual camera for viewing the second 3D map and generating 3D map views of the second 3D map. After generating the second virtual camera and loader and downloading the data, the mapping application transitions tostate9730.
• When the mapping application transitions tostate9730, the mapping application decodes the 3D map tiles for second 3D map. In some embodiments, decoding the data also includes creating meshes for geometries in the second 3D map, retrieving the styling information, associating the styling information with the generated meshes, and determining the draw order of meshes. The mapping application performs additional and/or other operations in some embodiments when decoding the downloaded data. Once the mapping application decodes the data, the mapping application transitions tostate9740.
• Atstate9740, the mapping application prepares the rendering engine to render 3D map views of the second 3D map using the second virtual camera. To prepare the rendering engine, the mapping application of some embodiments generates texture preprocessors, precompiles the rendering shaders, builds styling information for nearby geometry, generates style resources, generates textures based on the styling information, and creates any resources needed for the geometry. For instance, if there's a park near the user's location, theprocess9700 determines styling information related to the park and then generates any and all resources necessary to style the park. After preparing the rendering engine, the mapping application transitions tostate9750.
• Instate9750, the mapping application continues to render 3D map views of the first 3D map using the first virtual camera. Here, the mapping application also determines whether to begin transitioning from the first viewing mode to the second viewing mode. If the mapping application determines that a transition from the first viewing mode to the second viewing mode is unlikely to be needed (e.g., after a defined amount of time has elapsed, the zoom level of the first viewing mode has changed a threshold amount to indicate that a transition is not likely or will not occur, etc.), the mapping application transitions tostate9710. If the mapping application determines to transition from the first viewing mode to the second viewing mode (e.g., the mapping application enters a zoom level that requires the second viewing mode, the application enters navigation mode, etc.), the mapping application transitions tostate9760.
• When the mapping application transitions tostate9760, the mapping application performs the blending operation by performing a cross blend of the 3D map views of the first 3D map rendered using the first virtual camera with the 3D map views of the second 3D map rendered using the second virtual camera. In some embodiments, the mapping application renders the 3D map views of the first 3D map first and then renders the 3D map views of the second 3D map. The mapping application of some embodiments repeatedly alternates between rendering a 3D map view of the first 3D map and rendering a 3D map view of the second 3D map for the blending operation. Once the blending operation is complete, the mapping application transitions tostate9770.
• Atstate9770, the mapping application sets the second viewing mode as the first viewing mode and then transitions back tostate9710. Since the mapping application can switch between the first and second viewing modes any number of times, the mapping application returns tostate9710 in order to preload the second viewing mode to continue providing seamless transitions between the two viewing modes.
• C. Image Processing Pipeline
• FIG. 98 conceptually illustrates aprocessing pipeline9800 performed by the mapping application of some embodiments in order to render a map for display at the client device (e.g., on the display of the client device). As illustrated, theprocessing pipeline9800 includes a requestor9805, a loader/decompressor9810, atile processor9850, a set ofmesh builders9815, atile provider9820, avirtual camera9880, and amap rendering engine9825.
• Thetile processor9850 of some embodiments receives requests for map tiles from themesh builders9815 and performs a multiplexing operation before forwarding the requests. Themesh builders9815, as will be described below, identify existing map tiles (that are stored on a mapping service server or in a cache on the device performing the processing pipeline9800) needed to build their respective meshes. In some embodiments, the map tiles are referenced as nodes of a quadtree. The tile processor acts as a multiplexer when multiple mesh builders request the same tile. As the mesh builders request tiles, in some embodiments thetile processor9850 stores these tiles in its queue. After either a particular period of time or after a particular number of tiles have been requested, thetile processor9850 flushes the queue and sends the tile list to the loader/decompressor9810.
• The loader/decompressor9810 receives the multiplexedtile list9835 from thetile processor9850 and handles the return of decompressedtiles9845 to thetile processor9850. In some embodiments, the loader/decompressor9810 first checks one or more caches to determine whether it has the requested tiles stored at the device on which the mapping application operates. As shown, some embodiments include both afirst tile cache9853 stored on non-volatile memory (e.g., disk, flash memory, etc.) as well as asecond tile cache9854 stored in volatile memory (e.g., random access memory). When the loader/decompressor9810 finds the tiles in one of thecaches9853 and9854, it sends these tiles back to the tile processor9850 (for return to the requesting mesh builder(s)9815).
• When the loader/decompressor9810 does not have the tiles in its cache, it sends a request to therequestor9805 for the remaining tiles. Upon receiving thesemap tiles9840 in a compressed format, the loader/decompressor decompresses the received tiles to generate decompressedtiles9845. In some embodiments, after generating the map tiles as described above, the mapping service also compresses the tiles using an encoding technique. Different embodiments use different encoding techniques. The loader/decompressor9810 returns these decompressedtiles9845 to thetile processor9850, and in some cases also stores them in one or both of thetile caches9853 and9854.
• The requestor9805, in some embodiments, receives requests for map tiles from the loader/decompressor9810 (which in turn receives the requests from the tile processor9850). These map tiles, in some embodiments, are stored on a server (e.g., a server of the mapping service to which the user's device connects). The requestor sends a tile list9836 (received from the loader/decompressor9810) that identifies the tiles needed from the mapping service (and not available in thetile caches9853 and9854. In some embodiments, the requestor takes advantage of the operating device's network connections (e.g., a Wi-Fi connection, a GSM connection, etc.) to contact the mapping service through the Internet to retrieve the needed map tiles. Upon receiving the tiles (in a compressed form) from the mapping service, the requestor9805 returns thecompressed tiles9840 to the loader/decompressor.
• In some embodiments, the requestor9805 (or thetile processor9850, or a different portion of the pipeline) identifies tiles at additional zoom levels that cover the same geographical area as the initially requested tiles, and adds these tiles to therequest list9836 so that the tiles will be available if needed in the near future. In addition, some embodiments automatically request tiles at the same (or different zoom levels) for nearby geographical regions, in order to have the tiles available in case the user pans the map. In some embodiments, therequestor9805, loader/decompressor9810, andtile processor9850 function as an independent portion of the processing pipeline, with themesh builders9815 as the “clients” of this section.
• The mesh builders9815 (also referred to as tile sources) of some embodiments are instantiated by thetile provider9820 in order to build different layers of virtual map tiles. Depending on the type of map being displayed by the mapping application, thetile provider9820 may instantiate a different number and different types ofmesh builders9815. For instance, for a flyover (or satellite) view map, thetile provider9820 might only instantiate onemesh builder9815, as the flyover map tiles of some embodiments do not contain multiple layers of data. In fact, in some embodiments, the flyover map tiles contain an already-built mesh generated at the mapping service for which the flyover images (taken by a satellite, airplane, helicopter, etc.) are used as textures. However, in some embodiments, additional mesh builders may be instantiated for generating the labels to overlay on the flyover images when the application is in a hybrid mode. The generation of flyover maps of some embodiments are described in PCT Application PCT/EP2011/054155, entitled “3D Streets.” PCT Application PCT/EP2011/054155 is incorporated herein by reference. For a 2D or 3D rendered vector map (i.e., a non-satellite image map), some embodiments instantiateseparate mesh builders9815 to build meshes for landcover polygon data (e.g., parks, bodies of water, etc.), roads, place of interest markers, point labels (e.g., labels for parks, etc.), road labels (e.g., road labels in map browsing mode and road signs in navigation mode), traffic (if displaying traffic), buildings, raster data (for certain objects at certain zoom levels), as well as other layers of data to incorporate into the map.
• Themesh builders9815 of some embodiments, receive “empty”virtual map tiles9860 from thetile provider9820 and return “built”virtual map tiles9865 to thetile provider9820. That is, thetile provider9820 sends to each of themesh builders9815 one or morevirtual map tiles9860. Each of thevirtual map tiles9860 indicates an area of the world for which to draw a mesh. Upon receiving such avirtual map tile9860, amesh builder9815 identifies the map tiles needed from the mapping service, and sends its list to thetile processor9850.
• Upon receiving the tiles back fromtile processor9850, the mesh builder uses vector data stored in the tiles to build a polygon mesh for the area described by the virtual map tile. In some embodiments, themesh builder9815 uses several different functions to build the mesh. These functions include themesh generator9816, thetriangulator9817, theshadow generator9818, and thetexture decoder9819. In some embodiments, these functions (and additional mesh building functions) are available to each mesh builder, withdifferent mesh builders9815 using different functions. For instance, the mesh builder responsible for the buildings layer may use amesh generator9816 and atriangulator9817. In addition, several different types of shadow generators may be available to themesh builder9815, including a first shadow generator for creating dynamic shadows (that change as the map rotates) and a second shadow generator for creating a raster image drop shadow.
• Themesh generator9816 generates a mesh of vertices using the tile vector data, in some embodiments. Thetriangulator9817 generates triangles from the mesh, to simplify the eventual rendering. Theshadow generator9818 adds shadows to the mesh (e.g., by labeling vertices and/or polygons with values indicating to the renderer to draw a shadow, or how dark of a shadow to draw. Thetexture decoder9819 decodes texture information (e.g., from a stylesheet) and applies the texture information to the mesh. In different embodiments, the texture information may indicate colors, patterns, etc. to add to the polygons when rendered, which is encoded into the mesh. After building its mesh, eachmesh builder9815 returns itsvirtual map tiles9865 to thetile provider9820 with its layer of the mesh filled in.
• In some embodiments, the texture information may be determined based onstylesheet data9855. Furthermore, some embodiments also use thisstylesheet data9855 to determine the shadow, triangulation, and or mesh construction data. Using stylesheet-driven rendering enables simple modification to many aspects of the map output, because changes to a texture, color, etc. can be made through a minor modification of a stylesheet. As a result, textures can be dynamically created on the fly. An example benefit of the stylesheet-driven rendering is the facilitation of using different textures for certain types of objects at different zoom levels or geographic regions. For instance, when viewed at a low zoom level (less detail), some embodiments might color a park a simple light green. On the other hand, as the user zooms in to a higher zoom level (more detail), the stylesheets indicate to apply a pattern (e.g., a foliage pattern) to the park region. Similarly, patterns at higher zoom levels could be added to buildings, bodies of water, asphalt, urban land cover, etc. This information can be coded into a stylesheet and then the mesh builder simply adds the appropriate texture information to a tile mesh based on the zoom level of the tile.
• By tagging roads (e.g., as urban, suburban, or rural), the mapping service can induce the client application to use different textures for the land cover regions around those roads. In addition, land cover region tags can be updated by the server based on metrics indicative of the sort of area covered by the land cover region. For instance, some embodiments (on the mapping service end) determine the density of mobile devices within the region (e.g., based on the number of devices accessing the mapping service) and generate tags for the land cover. The stylesheets stored by the client devices (which may be updated from the mapping service, in some embodiments) then indicate how to draw these land cover regions. Similarly, different styles can be used for rendering aspects of different regions (e.g., desert, forest, rocky, etc. for land cover; different colors for labels in different states; different colors, textures, and/or casing for different roads, or other such distinctions).
• FIG. 99 illustrates the application of different textures to different types of roads for some embodiments. Specifically, this figure illustrates amap presentation9900 in the mapping application of some embodiments that shows a freeway entrance ramp. In this case, the application identifies the road marked as a freeway and the road marked as an entrance ramp or slip road, and uses the stylesheet to provide different textures (in this case, asphalt shades) for the different types of roads.
• Some embodiments denote roads as dominant or non-dominant, and render the roads differently accordingly. For instance, arterial roads might be considered dominant as compared to connector (e.g., residential) roads.FIG. 100 illustrates amap presentation10000 that includes one arterial road and two connector roads. In this case, the arterial road is considered the dominant road, and therefore the application draws the arterial road larger and with a different, more prominent casing. In addition, in some embodiments the application colors the arterial road darker so that it stands out more prominently. In some embodiments,FIGS. 99 and 100 illustrate the rendering of roads using immersive navigation tiles, in which the roads are defined as 3D polygons. In some such embodiments, the navigation tiles indicate what road casing should be displayed through annotation of the road polygon vertices.
• Map tiles of some embodiments (for non-immersive map browsing view, rather than immersive navigation view), on the other hand, store the road data as vectors (i.e., one-dimensional constructs). The mapping application nevertheless renders some of the roads differently, including rendering dominant roads (e.g., arterial roads) differently from non-dominant roads.FIG. 101 illustrates anon-immersive map presentation10100 illustrating the rendering of roads in a map tile, in map browsing view. In this case, one of the roads is classified as dominant, and therefore the mesh built for the road is different from the other surrounding roads. The dominant road is displayed as darker and thicker than the other surrounding roads in some embodiments.
• Some embodiments dynamically determine which roads within the map are dominant and display the dominant roads differently from non-dominant roads within the map (e.g., by coloring the roads differently, drawing the dominant roads thicker than the non-dominant roads, using different casing for the dominant roads, etc.). In order to determine which roads are dominant within a map, some embodiments use data provided about the type of roads to be drawn for the map. For example, roads may be classified as highways, arterial roads, and non-arterial roads, with sub-classifications in some embodiments. In general, arterial roads are larger roads and carry more traffic than non-arterial roads, and tend to have the right of way at intersections with non-arterial roads. Thus, when a map display has both arterial roads and non-arterial roads, some embodiments draw the arterial roads as dominant. On the other hand, when a map display has no arterial roads, the mapping application of some embodiments selects some of the non-arterial roads to be drawn as dominant roads. However, rather than only examining the actual portion of the map to display for arterial roads, some embodiments identify roads located within a region of a particular distance around the map as well. If arterial roads are present within that region, then the application does not draw any of the non-arterial roads as dominant, so as to avoid having to change the appearance of the road suddenly when the arterial road enters the map display.
• Thetile provider9820 receives from the controller9875 a particular view (i.e., a volume, or viewing frustum) that represents the map view to be displayed (i.e., the volume visible from the virtual camera9880). The tile provider performs any culling (e.g., identifying the surface area to be displayed in the virtual map tile), then sends thesevirtual map tiles9860 to themesh builders9815.
• Thetile provider9820 then receives the builtvirtual map tiles9865 from the mesh builders and, in some embodiments, performs culling on the built mesh using the particular view from the virtual camera9880 (e.g., removing surface area too far away, removing objects that will be entirely behind other objects, etc.). In some embodiments, thetile provider9820 receives the builtvirtual map tiles9865 from the different mesh builders at different times (e.g., due to different processing times to complete more and less complicated meshes, different time elapsed before receiving the necessary map tiles from thetile processor9850, etc.). Once all of the layers of virtual map tiles have been returned, thetile provider9820 of some embodiments puts the layers together and releases the data to thecontroller9875 for rendering.
• In some embodiments, thetile provider9820 may have already received a new virtual camera volume for which to build a mesh before the mesh builders have returned their data. For instance, when the user quickly pans or zooms a map, the data returned by the mesh builders may be out of date. In some embodiments, the tile provider either drops the built virtual map tile layers or stores them in memory. Whether to drop the built virtual map tiles depends, in different embodiments, on whether it is likely the built tiles will be needed soon (e.g., how much the user has moved the virtual camera, whether a navigation is running that makes it unlikely the application will display the older data) and the amount of memory currently in use.
• Thevirtual camera9880 generates a volume or surface for thepipeline9800 to render, and sends this information to thecontroller9875. Based on a particular location and orientation from which the map will be rendered (i.e., the point in 3D space from which the user “views” the map), the virtual camera identifies a field of view to actually send to thetile provider9820. In some embodiments, when the mapping application is rendering the 3D perspective view for navigation, the field of view of the virtual camera is determined according to an algorithm that generates a new virtual camera location and orientation at regular intervals based on the movement of the user device.
• Thecontroller9875 is responsible for managing thetile provider9820,virtual camera9880, andmap rendering engine9825 in some embodiments. In some embodiments, multiple tile providers may actually be instantiated, and the controller puts together several virtual map tiles (e.g., map tiles and building tiles) to create a scene that is handed off to themap rendering engine9825.
• Themap rendering engine9825 is responsible for generating a drawing to output to a display device based on themesh tiles9865 sent from the virtual camera. As shown, themap rendering engine9825 of some embodiments has several sub-processes. In some embodiments, each different element is rendered by a different sub-process, with therendering engine9825 handling the occlusion of different layers of objects (e.g., placing labels above or behind different buildings, generating roads on top of land cover, etc. This figure illustrates aroad rendering process9826, abuilding rendering process9827, and alabel rendering process9828. Examples of additional processes include a vegetation rendering process, a raster traffic rendering process, a raster road rendering process, a satellite rendering process, a polygon rendering process, a background raster rendering process, etc.
• Each of the rendering processes includes a set of rendering parameters; illustrated areroad parameters9836,building parameters9837, andlabel parameters9838. In some embodiments, this data includes information on how to render the roads (e.g., shader information, textures to use for different types of roads, etc.).
• In some embodiments, these sets of rendering parameters are generated at least in part by a renderingengine preparation operation9870. The renderingengine preparation operation9870 includes ashader compiler9871 and atexture loader9872, among other operations. Theshader compiler9871 compiles shaders that the rendering engine will use, and thetexture loader9872 loads texture information (e.g., into the rendering parameters). This texture information may come from thestylesheet data9855 in some embodiments.
• The operation of therendering pipeline9800 in some embodiments will now be described. Based on user input to view a particular map region at a particular zoom level, thevirtual camera9880 specifies a location and orientation from which to view the map region, and sends this viewing frustum, or volume, to thecontroller9875. Thecontroller9875 instantiates one or more tile providers. While onetile provider9820 is shown in this figure, some embodiments allow the instantiation of multiple tile providers at once (e.g., as shown below inFIG. 102). For instance, some embodiments instantiate separate tile providers for building tiles and for map tiles.
• Thetile provider9820 performs any culling necessary to generate an empty virtual map tile identifying regions of the map region for which a mesh needs to be built, and sends the emptyvirtual map tiles9860 to themesh builders9815, which are instantiated for the different layers of the drawn map (e.g., roads, land cover, POI labels, etc.). Themesh builders9815 use a manifest received from the mapping service that identifies the different tiles available on the mapping service server (i.e., as nodes of a quadtree). Themesh builders9815 request specific map tiles from thetile processor9850, which removes any duplicate requests and sends atile list9835 to the loader/decompressor9810.
• The loader/decompressor9810 determines whether the requested tiles are stored in the tile caches (either thenon-volatile storage cache9853 or the volatile storage cache9854), and returns any such tiles to thetile processor9850 for distribution to the requestingmesh builders9815. For any tiles not already stored locally, the loader/decompressor9810 sends a request to therequestor9805, which sends tile list9836 (a pared-down version of tile list9835) to a remote mapping service server. Therequestor9805 receives from the mapping service, and forwards to the loader/decompressor9810, the requested map tiles incompressed form9840. The loader/decompressor9810 decompresses (e.g., decodes) these tiles, stores them in its cache(s), and sends the decompressedtiles9845 to thetile processor9850 for return to themesh builders9815.
• Once aparticular mesh builder9815 has received its map tiles, it begins using the vector data stored in the map tiles to build the mesh for the virtual map tiles sent from thetile provider9820. After building the mesh for its map layer, themesh builder9815 sends the builtvirtual map tile9865 back to thetile provider9820. Thetile provider9820 waits until it has received all of the virtual map tiles from thevarious mesh builders9815, then layers these together and sends the completed virtual map tile to thecontroller9875. The controller stitches together the returned tiles from all of its tile providers (e.g., a virtual map tile and a virtual building tile) and sends this scene to therendering engine9825. Themap rendering engine9825 uses the information in the map tiles to draw the scene for display.
• The above pipeline is illustrated for a single scene from a single virtual camera. Some embodiments, in fact, instantiate several virtual cameras and several tile providers at once, in able to quickly switch from one scene to another, or from one view of a scene to another (e.g., switching between different zoom levels, or from a non-immersive 3D map view into an immersive 3D map view in order to enter navigation).FIG. 102 conceptually illustrates acontroller10200 that instantiates twovirtual cameras10205 and10210 for two different views of map regions. As shown, the first virtual camera provides a non-immersive 3D view of a first map region, while the second virtual camera provides an immersive 3D view of a second map region. The first and second map regions might be simply different views of the same map region, or views of different regions of a map. In different embodiments, the twovirtual cameras10205 and10210 might be providing views of a map region from different zoom levels, specifying different locations and orientations from which to view the map region.
• Initially, thecontroller10200 is receiving the scene from the firstvirtual camera10205, and instantiates the non-immersive 3Dmap tile provider10215 and thebuildings tile provider10220 in order to display a non-immersive 3D map with buildings. Each of these tile providers instantiates its required set ofmesh builders10225 and10230 in order to build the virtual map tiles for the non-immersive 3D scene. Once the controller has received these virtual tiles from thetile providers10215 and10220, thecontroller10200 pieces them together to form ascene10235. Once the controller receives an indication that the application may be switching from the non-immersive viewing mode to the immersive viewing mode (e.g., when a user enters a route with the option to enter navigation), thecontroller10200 instantiates the secondvirtual camera10210 to provide a view of a map region. Based on this, the controller instantiates the immersive3D tile provider10240, which in turn instantiates its set ofmesh builders10245. While instantiating the immersive 3D pipeline, the controller continues providing thenon-immersive 3D scene10235 to therendering engine10250. Once thecontroller10200 has (i) received the built virtual map tiles from the immersive3D tile provider10240 and (ii) received a command to enter the immersive 3D mode (e.g., because the user has started navigation of a route), the controller begins providing theimmersive 3D scene10255 to therendering engine10250. In some embodiments, the virtual building tiles received from thebuildings tile provider10220 are used for both the immersive and non-immersive 3D scenes.
• FIG. 103 conceptually illustrates aprocess10300 of some embodiments for pre-loading navigation tiles to enter navigation. Theprocess10300 will be described by reference toFIG. 104, which illustrates adevice10400 that displays a mapping application as the application transitions from a non-immersive map view for map browsing into an immersive map view for navigation, over six stages10405-10430.
• As shown, theprocess10300 begins by requesting (at10305) route instructions. In some embodiments, this may occur when a user selects a location on a map and then selects a “route” button (e.g., a button in the shape of a car in the label displayed for the location) for requesting a route from the user's current location to the selected location. A user might also use a search field to search for a route from the user's current location to the selected location. In response to the user input, the mapping application sends out the request for the route instructions to a mapping service. Thefirst stage10405 ofFIG. 104 illustrates a user selecting a quick-route button for a location “Pizza Place” in order to generate a route from the user's current location (near the center of the screen of device10400) to the selected location.
• After transmitting the request, theprocess10310 receives (at10310) route instructions and navigation tiles for at least a portion of the route. The mapping server receives the route request, generates an optimal route from the start point (e.g., the user's location) to the end point, and downloads the route instructions to the user. In some embodiments, the server assumes that the user is likely to enter navigation mode to travel along the route, and therefore also downloads the navigation tiles (i.e., the tiles for rendering the areas along the route from a particular high level of detail zoom level).
• The mapping application of some embodiments includes an adaptive tile loading mechanism. In some embodiments, the adaptive tile loading mechanism downloads map tiles for a defined distance at the beginning of the route navigation. Once the user starts traveling along the route navigation, the mapping application increases the amount of tiles downloaded based on factors that indicate that the user is committed on completing the route. For instance, the mapping application of some embodiments increases the amount of tiles to download when a defined distance interval is passed. For example, after every 10 miles traveled along the route navigation, the mapping application downloads an increasing amount of map tiles for the route ahead (e.g., tiles for the next 10 miles ahead, tiles for the next 20 miles ahead, etc.). Other techniques may be used to adaptively download tiles in order to increase power savings (and, if the user does not complete the route, also save on download time).
• Returning toFIG. 103, theprocess10300 next instantiates (at10315) a rendering pipeline for the navigation tiles while displaying the route information. When a route is downloaded, the mapping application displays a static map (in some embodiments, either 2D or 3D) with the route overlayed. In the background, however, the application prepares to begin animating using the navigation map tiles. Thus, the process instantiates a virtual camera, one or more tile providers, and a series of mesh builders for the navigation rendering, and begins generating virtual tiles based on the downloaded navigation tiles.
• In addition, the process prepares (at10320) the rendering engine for the navigation tiles. As described above, this preparation may include compiling shaders for use by the rendering engine and loading textures, also for use by the rendering engine. Thesecond stage10410 ofFIG. 104 illustrates the mapping application displaying aroute10435 to reach the location “Pizza Place”. At this point, the mapping application would have begun downloading the immersive 3D tiles along the route, and begun instantiating a rendering pipeline for these tiles, in case the user opts to enter navigation for this route.
• Theprocess10300 then determines (at10325) whether to enter navigation. The mapping application of some embodiments, when displaying a route, displays a selectable user interface item with which a user can start navigation over the route. When a user selects the start item, the application then enters navigation (as long as the navigation tiles are downloaded and rendering can begin). When the user has not yet entered navigation, the process determines (at10330) whether the route has been canceled. This may occur if the user makes another search (either for a different location or a different route), closes out the displayed route without entering navigation, closes the mapping application, etc. When the user has not canceled the route, the process returns to10325 to determine whether to enter navigation. These two operations effectively function as a ‘wait’ state, in which the mapping application displays the route and waits for user input to either start the route or cancel the route (while also possibly responding to user input to view route instructions, move the map along the route, etc.).
• When the user selects to enter navigation, theprocess10300 begins (at10335) rendering the animation for the navigation tiles at the start of the route. As the rendering pipeline has already generated the mesh and prepared the rendering engine, the lag time to begin the animation should be minimal. A process for determining the path of the virtual camera based on user location in order to determine the animation is described in detail above. When, on the other hand, the user cancels the route, the process deinstantiates (at10340) the rendering pipeline, on the assumption that the user will not be navigating the route. Some embodiments also remove the virtual navigation tiles from memory, though other embodiments cache the virtual navigation tiles for a period of time when possible.
• At thesecond stage10410 ofFIG. 104, the user selects the “Start”UI control10440. Accordingly, the application begins entering navigation, using the pre-loaded immersive 3D tiles and the pre-instantiated rendering pipeline to begin rendering the scene with minimal delay. As shown at the third through sixth stages10415-10430, some embodiments use a cinematic transition from the 2D (or 3D) non-immersive map view into the 3D immersive map view. The application display begins from its current state (that shown at10410) and transitions smoothly from the first virtual camera view to the new virtual camera view that is more zoomed in and pointing in the direction of the start of the route. In doing so, the virtual camera may perform a combination of translation, zoom, and rotation operations in order to reach the start of the route for navigation. In addition, some embodiments use a crossfade operation between the first virtual camera (rendering the non-immersive map tiles for map browsing) and the second virtual camera (rendering the more immersive navigation tiles for navigation). As shown, at thethird stage10415 the first virtual camera has moved towards the eventual location of the second virtual camera, with the map now rotated and zoomed slightly. The non-immersive map tiles are still rendered for display at this point. In the fourth andfifth stages10420 and10425, the mapping application is now rendering from the perspective of the second virtual camera, with the immersive tiles rendered (as shown by the asphalt polygon roads. Over these stages, the second virtual camera rotates into its eventual location behind the navigation location indicator (i.e., the puck), as shown in thesixth stage10430.
• The mapping and navigation application of some embodiments performs this transition within the single integrated application, without leaving the single application. That is, both the map and route browsing mode (shown instages10405 and10410) and the navigation mode (shown in stages10415-10430) are different modes of the same integrated mapping, search, and navigation application. Were the user to select the “end” button during the navigation mode, some embodiments transition back to the map browsing mode, either with a smooth cinematic transition or by a screen refresh without the virtual camera movement.
• D. Integrated Mapping and Navigation Application
• FIGS. 105A-105B conceptually illustrate a state diagram10500 that describes different states and transitions between these states of the integrated mapping, search, and navigation application of some embodiments (e.g., the client-side application described in the above sections). One of ordinary skill in the art will recognize that the application of some embodiments will have many different states relating to all different types of input events, and that the state diagram10500 is specifically focused on a subset of these events. The state diagram10500 describes and refers to various gestural interactions (e.g., multi-touch gestures) for changing states of the application. One of ordinary skill in the art will recognize that various other interactions, such as cursor controller gestures and button clicks, keyboard input, touchpad/trackpad input, etc. may also be used for similar selection operations.
• When a user initially opens the mapping application, the application is instate10505, the map browsing state. In thisstate10505, the application will have generated and displayed a map view. To generate and display this map view, the application of some embodiments identifies a required set of map tiles for a region, requests the map tiles (e.g., from a mapping service server), generates a view of the map tiles from a particular location, orientation, and perspective of a virtual camera, and renders the map view to a device display. When instate10505, the map view is static. With the application instate10505, the user can perform numerous operations to modify the map view, search for entities (e.g., places of interest, addresses, etc.), retrieve a route for navigation, etc.
• In some embodiments, the integrated application is displayed on a device with an integrated touch-sensitive display. Various gestural interactions over the map may cause the application to perform different modifications to the map view (e.g., panning, rotating, zooming, modifying the map perspective, etc.). When the integrated application receives gestural interaction over the map display (as opposed to touch inputs over various floating or non-floating controls overlaid on the map display), the application transitions tostate10510 to perform gestural input recognition.
• The gesturalinput recognition state10510 differentiates between different types of gestural input and translates these types of input into different map view modification operations. In some embodiments, the mapping application receives the gestural input as translated by the operating system of the device with the integrated touch-sensitive display. The operating system translates the touch input into gesture types and locations (e.g., a “tap” at coordinates (x,y), a “pinch” operation with separate touch inputs at two different locations, etc.). Atstate10510, the integrated mapping application of some embodiments translates these into the different map view modification operations.
• When the application receives a first type of gestural input (e.g., two separate touch inputs moving together in a rotational motion over the map view), the application transitions tostate10515 to rotate the map. To rotate the map view, some embodiments modify the location and/or orientation of the virtual camera that determines which portion of the map is rendered to create the map view. When in 3D mode, for example, the mapping application rotates the virtual camera about a particular position (e.g., the center of the touch inputs, the center of the display, a location indicator identifying the user's location, etc.). As the first type of gestural input continues, the mapping application remains instate10515 to continue rotating the map.
• When the user releases the first type of gestural input, the application of some embodiments transitions tostate10530 to perform an inertia calculation. In some embodiments, after the user releases certain types of touch inputs, the application continues to perform the associated map view modification for a particular amount of time and/or distance. In this case, after the user releases the rotation input, the application transitions to theinertia calculation state10530 to calculate the additional rotation amount and the time over which this rotation should be performed. In some embodiments, the application slows down the rotation from the (angular) velocity at which the map was being rotated, as if a “frictional” force was applied to the map. As such, the inertia calculation of some embodiments is based on the speed of the first type of gestural input. Fromstate10530, the application transitions back to the map modification state that the application was previously in. That is, when the application transitions from state10515 (the rotation state) to theinertia calculation state10530, it then transitions back tostate10515 after performing the inertia calculation. After the rotation of the map is complete, the application transitions back tostate10505.
• When the application receives a second type of gestural input (e.g., a single touch input moving over the map view), the application transitions tostate10520 to pan the map. To pan the map view, some embodiments modify the location of the virtual camera that determines which portion of the map is rendered to create the map view. This causes the map to appear to slide in a direction derived from the direction of the second type of gestural input. In some embodiments, when the map view is in a 3D perspective mode, the panning process involves performing a correlation of the location of the touch input to a location on the flat map, in order to avoid sudden unwanted jumps in the map view. As the second type of gestural input continues, the mapping application remains instate10520 to continue panning the map.
• When the user releases the second type of gestural input, the application of some embodiments transitions tostate10530 to perform an inertia calculation. In some embodiments, after the user releases certain types of touch inputs, the application continues to perform the associated map view modification for a particular amount of time and/or distance. In this case, after the user releases the panning input, the application transitions to theinertia calculation state10530 to calculate the additional amount to move the map view (i.e., move the virtual camera) and the time over which this movement should be performed. In some embodiments, the application slows down the panning movement from the velocity at which the map was being panned, as if a “frictional” force was applied to the map. As such, the inertia calculation of some embodiments is based on the speed of the second type of gestural input. Fromstate10530, the application transitions back to the map modification state that the application was previously in. That is, when the application transitions from state10520 (the panning state) to theinertia calculation state10530, it then transitions back tostate10520 after performing the inertia calculation. After the panning of the map is complete, the application transitions back tostate10505.
• When the application receives a third type of gestural input (e.g., two separate touch inputs moving closer together or further apart), the application transitions tostate10525 to zoom in or out on the map. To change the zoom level of the map view, some embodiments modify the location (i.e., height) of the virtual camera that determines which portion of the map is rendered to create the map view. This causes the map view to include more (if zooming out) or less (if zooming in) of the map. In some embodiments, as the user zooms in or out, the application retrieves different map tiles (for different zoom levels) to generate and render the new map view. As the third type of gestural input continues, the mapping application remains instate10525 to continue panning the map.
• When the user releases the second type of gestural input, the application of some embodiments transitions tostate10530 to perform an inertia calculation. In some embodiments, after the user releases certain types of touch inputs, the application continues to perform the associated map view modification for a particular amount of time and/or distance (i.e., moving the virtual camera higher or lower). In this case, after the user releases the zoom input, the application transitions to theinertia calculation state10530 to calculate the additional amount to zoom the map view (i.e., move the virtual camera) and the time over which this movement should be performed. In some embodiments, the application slows down the zooming movement from the velocity at which the map was being zoomed in or out of (i.e., the speed at which the virtual camera changes height), as if a “frictional” force was applied to the camera. As such, the inertia calculation of some embodiments is based on the speed of the third type of gestural input. Fromstate10530, the application transitions back to the map modification state that the application was previously in. That is, when the application transitions from state10525 (the zooming state) to theinertia calculation state10530, it then transitions back tostate10525 after performing the inertia calculation. After the zooming of the map is complete, the application transitions back tostate10505.
• For simplicity, the state diagram10500 illustrates the map panning, zooming, and rotation processes using the same inertia calculation process (state10530). However, in some embodiments, each of these different map modification processes actually uses a different inertia calculation to identify the slow-down and stop for its particular type of movement. In addition, some embodiments calculate and modify the inertia variables as the input is received rather than when the user removes the gestural input.
• When the application receives a fourth type of gestural input (e.g., two separate touch inputs moving up or down the touch-sensitive display in unison), the application transitions tostate10535 to modify the perspective view of the map. To change the perspective view of the map, some embodiments move the virtual camera along an arc over the map, modifying both the location and orientation of the virtual camera (as the camera keeps the center of its field of view at a particular location on the map). In some embodiments, different zoom levels use different arcs along which the virtual camera moves. Each of these arcs has a top point at which the virtual camera is pointing straight down, giving a 2D perspective view of the map. In addition, each arc has a bottom point, that is the lowest point on the arc to which the virtual camera can be moved. Thus, the fourth type of gestural input can cause the application to change between a 2D map view and a 3D perspective map view in some embodiments. As the fourth type of gestural input continues, the mapping application remains instate10535 to continue modifying the perspective view of the map.
• When the user releases the second type of gestural input, the application of some embodiments transitions tostate10540 to perform an inertia calculation. In some embodiments, after the user releases certain types of touch inputs, the application continues to perform the associated map view modification for a particular amount of time and/or distance (i.e., moving the virtual camera higher or lower). In this case, after the user releases the perspective view change input, the application transitions to theinertia calculation state10540 to calculate the additional amount to modify the perspective of the map view (i.e., move the virtual camera along its arc) and the time over which this movement should be performed. In some embodiments, the application slows down the movement from the velocity at which the map was changing perspective (i.e., the speed at which the virtual camera moves along its arc), as if a “frictional” force was applied to the camera. As such, the inertia calculation of some embodiments is based on the speed with which the fourth type of gestural input was performed.
• In addition, for the perspective change operation, some embodiments transition to arebound calculation state10545. As stated, the perspective change operation has a maximum and minimum perspective shift allowed in some embodiments, which may depend on the zoom level of the current map view. Thus, in addition to an inertia calculation, the application performs a rebound calculation atstate10545. The rebound calculation uses the inertia calculation to determine whether the maximum point along the virtual camera arc will be reached and, if so, the velocity of the virtual camera at this point. Some embodiments allow the virtual camera to move slightly past the maximum point to hit a “rebound” point, at which point the application turns the virtual camera around on its arc, moving it back towards the maximum point. Some embodiments include such a bounce-back functionality only on one end of the virtual camera arc (e.g., the bottom of the arc), while other embodiments include the functionality on both ends of the arc. From therebound calculation state10545, the application transitions back to theinertia calculation state10540, then back to theperspective changing state10535 to display the map view movement. In addition, when the user performs the fourth type of touch input for long enough and the perspective reaches its maximum point, the application transitions directly from thestate10535 tostate10545 to calculate the rebound information and then transitions back tostate10535. After the modification to the perspective view of the map is complete, the application transitions back tostate10505.
• The above states relate to the various multi-touch gestures over the map presentation that the integrated mapping, search, and navigation application translates into different modifications to the map presentation. Various other touch inputs can also cause the application to change states and perform various functions. For instance, some embodiments overlay a 3D selectable item on the map view (e.g., as a floating control), and selecting (e.g., with a tap input) the 3D item causes the application to transition to10535 to modify the perspective of the map view. When the map view starts in a 3D perspective view, the application modifies the perspective into a 2D view; when the map view starts in the 2D view, the application modifies the perspective into a 3D view. After the modification, the application returns tostate10505.
• As the application is a tightly integrated mapping, search, routing, and navigation application, the user can easily access the routing function from the map browsing state. When a particular UI control (e.g., a route entry button) is selected, the application transitions to theroute entry state10570. At the route entry state, some embodiments display a touchscreen keyboard with which the user can enter locations (e.g., addresses, place names, place types, etc.) into both “to” and “from” fields in order to request a route. While the user enters characters, the application remains instate10570 and provides suggestions based on recent routes, recent searches, an autocomplete similar to that described for the search entry, etc. If the user selects a cancellation UI control at this stage, the application transfers back tostate10505 without retrieving a route.
• When the user selects a route (e.g., by entering a “to” location and a “from” location), the application transitions to theroute displaying state10575. At this state, the application displays one or more routes from a first selected location to a second selected location over the map view (e.g., by overlaying route lines on the map view). Some embodiments automatically select a first one of the routes. The user can select any of the other routes (e.g., by tapping over the unselected route), with the application remaining in state10575 (but modifying the display of the route lines to indicate the selection of the other route). In addition, when instate10575, the application of some embodiments displays different UI controls related to routing and navigation, including a direction list control, a navigation start control, and others. In some embodiments, theroute display state10575 is accessible from other states as well. For instance, if a user selects a quick-route UI control on a location banner, the application retrieves one or more routes from the current location of the device to the location with which the banner is associated.
• Also, various gestural interactions over the map on which the routes are displayed may cause the application to perform different modifications to the map view (e.g., panning, rotating, zooming, modifying the map perspective, etc.). When the integrated application receives gestural interaction over the map display while in theroute display state10575, the application transitions tostate10510 to perform gestural input recognition, with all of the gestural map modification operations (e.g., corollaries to states10515-10545) available. That is, the application translates the gestural input into panning, rotation, zoom, and/or perspective change operations similar to those described above for states10515-10545, with similar inertia and rebound features for the virtual camera movement. Whereas the operations10515-10545 return to themap browsing state10505, the corollary operations accessed from theroute display state10575 return to theroute display state10575.
• From theroute display state10575, the application can transition into various different modes depending on different controls selected by the user. When the user selects a UI control to clear the routes, the application transitions back tostate10505 to display the map without any routes. In addition, the integrated application may enter one or more navigation modalities from theroute displaying state10575.
• When the selected route displayed atstate10575 starts at the current location of the device and the user selects a navigation starting control, the application transitions to thenavigation state10580. In some embodiments, the application displays a cinematic transition from the map view into a more immersive 3D view for navigation. Within thenavigation state10580 of some embodiments, a virtual camera follows the location of the user along the selected route in order to present the upcoming portions of the route. When either the route is completed (the device reaches the destination location) or the user selects a control to end navigation, the application transitions tostate10505 to present themap browsing view10505.
• In some embodiments, various gestural interactions over the map on which the routes are displayed may cause the application to perform different modifications to the map view (e.g., panning, rotating, zooming, modifying the map perspective, etc.) while in thenavigation mode10580. In some embodiments, only some of the described map modification operations are available in the navigation mode. For instance, some embodiments allow the user to zoom in or out, but do not allow any other modifications to the map. Thus, when the user provides gestural input, the gesturalinput recognition state10510 filters out types of gestural input not associated with the zoom operation (and subsequently the application returns to state10580). When the type of gestural input associated with the zoom operation is received, the gestural input recognition state recognizes this input and the application transitions to a state similar tostate10525, for changing the zoom level of the map (with the inertia calculation, in some embodiments).
• Other embodiments may enable different map modification operations. For instance, in some embodiments all of the gestural map modification operations (e.g., corollaries to states10515-10545) are available while in the navigation mode. Some embodiments allow a subset of the gestural map modification operations, such as zooming and a limited panning operation. The panning operation of some embodiments, upon receiving the type of gestural input associated with panning, moves the virtual camera (while in the navigation mode) to the side, then returns the virtual camera back to pointing along the route. Whereas the operations10515-10545 return to themap browsing state10505, the corollary operations accessed from thenavigation state10580 return to thenavigation state10580.
• When the selected route displayed atstate10575 starts at a location other than the current location of the device (or the route is a walking route) and the user selects a navigation starting control, the application transitions to the stepping mode, or route inspection mode,state10585.
• In some embodiments, the application displays the maneuvers performed along the route one at a time (e.g., as navigation signs). By providing gestural input (e.g., swipe gestures) to the maneuvers, the user can view the different maneuvers while in the route inspection mode. The maneuvers are overlaid on a map and at least a portion of the route is displayed in the map.
• As in the route display mode, various gestural interactions over the map may cause the application to perform different modifications to the map view (e.g., panning, rotating, zooming, modifying the map perspective, etc.). When the integrated application receives gestural interaction over the map display while in the steppingmode10585, the application transitions tostate10510 to perform gestural input recognition, with all of the gestural map modification operations (e.g., corollaries to states10515-10545) available. That is, the application translates the gestural input into panning, rotation, zoom, and/or perspective change operations similar to those described above for states10515-10545, with similar inertia and rebound features for the virtual camera movement. Whereas the operations10515-10545 return to themap browsing state10505, the corollary operations accessed from the steppingmode10585 return to the steppingmode10585.
• Furthermore, in some embodiments the gestural input recognition recognizes at least one type of gestural input over the displayed maneuvers in order to switch between the maneuvers. When a particular type of gestural input (e.g., a swipe gesture) is received over the displayed maneuver (as opposed to over the map view), the application transitions to a state (not shown) for changing the displayed maneuver, then returns tostate10585.
• When the integrated application receives gestural interaction over the map displayed while in the steppingstate10575, the application transitions tostate10510 to perform gestural input recognition, with all of the gestural map modification operations (e.g., corollaries to states10510-10545) available. When the modification operations are done, the application returns tostate10585. When the user selects a control to end stepping through the maneuvers, the application transitions tostate10505 to present the map browsing view.
• In addition, in some embodiments the application can transition from the steppingmode10585 to an auto-steppingstate10590. When the user selects a location tracking control while the application is instate10585, the application transitions to anautomatic stepping mode10590, which is a different navigation modality. When in the automatic stepping mode of some embodiments, the integrated mapping, search, and navigation application displays the maneuver to which the device's location is closest (e.g., as measured by a juncture at which the maneuver is performed). When the device moves (e.g., along the route) to a location closer to a different maneuver, the auto-stepping mode automatically displays the different maneuver. When the user deselects the location tracking control, the application transitions back to the steppingmode10585. When the user selects a control to end navigation while in the auto-steppingstate10590, the application transitions tostate10505 to present the map browsing view.
• As in the steppingmode10585, various gestural interactions over the map may cause the application to perform different modifications to the map view (e.g., panning, rotating, zooming, modifying the map perspective, etc.). When the integrated application receives gestural interaction over the map display while in the auto-steppingmode10590, the application transitions tostate10510 to perform gestural input recognition, with all of the gestural map modification operations (e.g., corollaries to states10515-10545) available. That is, the application translates the gestural input into panning, rotation, zoom, and/or perspective change operations similar to those described above for states10515-10545, with similar inertia and rebound features for the virtual camera movement. Whereas the operations10515-10545 return to themap browsing state10505, the corollary operations accessed from the auto-steppingmode10585 return to the auto-steppingmode10590. In addition, some embodiments automatically turn the location tracking control off when the user pans the map a particular distance, in which case the application returns to the steppingmode state10585 rather than auto-steppingstate10590.
IV. Electronic System
• Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more computational or processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, random access memory (RAM) chips, hard drives, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.
• In this specification, the term “software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage which can be read into memory for processing by a processor. Also, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while remaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software invention described here is within the scope of the invention. In some embodiments, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.
• A. Mobile Device
• The mapping and navigation applications of some embodiments operate on mobile devices, such as smart phones (e.g., iPhones®) and tablets (e.g., iPads®).FIG. 106 is an example of anarchitecture10600 of such a mobile computing device. Examples of mobile computing devices include smartphones, tablets, laptops, etc. As shown, themobile computing device10600 includes one ormore processing units10605, amemory interface10610 and aperipherals interface10615.
• The peripherals interface10615 is coupled to various sensors and subsystems, including acamera subsystem10620, a wireless communication subsystem(s)10625, anaudio subsystem10630, an I/O subsystem10635, etc. The peripherals interface10615 enables communication between the processingunits10605 and various peripherals. For example, an orientation sensor10645 (e.g., a gyroscope) and an acceleration sensor10650 (e.g., an accelerometer) is coupled to theperipherals interface10615 to facilitate orientation and acceleration functions.
• Thecamera subsystem10620 is coupled to one or more optical sensors10640 (e.g., a charged coupled device (CCD) optical sensor, a complementary metal-oxide-semiconductor (CMOS) optical sensor, etc.). Thecamera subsystem10620 coupled with theoptical sensors10640 facilitates camera functions, such as image and/or video data capturing. Thewireless communication subsystem10625 serves to facilitate communication functions. In some embodiments, thewireless communication subsystem10625 includes radio frequency receivers and transmitters, and optical receivers and transmitters (not shown inFIG. 106). These receivers and transmitters of some embodiments are implemented to operate over one or more communication networks such as a GSM network, a Wi-Fi network, a Bluetooth network, etc. Theaudio subsystem10630 is coupled to a speaker to output audio (e.g., to output voice navigation instructions). Additionally, theaudio subsystem10630 is coupled to a microphone to facilitate voice-enabled functions, such as voice recognition (e.g., for searching), digital recording, etc.
• The I/O subsystem10635 involves the transfer between input/output peripheral devices, such as a display, a touch screen, etc., and the data bus of theprocessing units10605 through theperipherals interface10615. The I/O subsystem10635 includes a touch-screen controller10655 andother input controllers10660 to facilitate the transfer between input/output peripheral devices and the data bus of theprocessing units10605. As shown, the touch-screen controller10655 is coupled to atouch screen10665. The touch-screen controller10655 detects contact and movement on thetouch screen10665 using any of multiple touch sensitivity technologies. Theother input controllers10660 are coupled to other input/control devices, such as one or more buttons. Some embodiments include a near-touch sensitive screen and a corresponding controller that can detect near-touch interactions instead of or in addition to touch interactions.
• Thememory interface10610 is coupled tomemory10670. In some embodiments, thememory10670 includes volatile memory (e.g., high-speed random access memory), non-volatile memory (e.g., flash memory), a combination of volatile and non-volatile memory, and/or any other type of memory. As illustrated inFIG. 106, thememory10670 stores an operating system (OS)10672. TheOS10672 includes instructions for handling basic system services and for performing hardware dependent tasks.
• Thememory10670 also includescommunication instructions10674 to facilitate communicating with one or more additional devices; graphicaluser interface instructions10676 to facilitate graphic user interface processing;image processing instructions10678 to facilitate image-related processing and functions;input processing instructions10680 to facilitate input-related (e.g., touch input) processes and functions;audio processing instructions10682 to facilitate audio-related processes and functions; andcamera instructions10684 to facilitate camera-related processes and functions. The instructions described above are merely exemplary and thememory10670 includes additional and/or other instructions in some embodiments. For instance, the memory for a smartphone may include phone instructions to facilitate phone-related processes and functions. Additionally, the memory may include instructions for a mapping and navigation application as well as other applications. The above-identified instructions need not be implemented as separate software programs or modules. Various functions of the mobile computing device can be implemented in hardware and/or in software, including in one or more signal processing and/or application specific integrated circuits.
• While the components illustrated inFIG. 106 are shown as separate components, one of ordinary skill in the art will recognize that two or more components may be integrated into one or more integrated circuits. In addition, two or more components may be coupled together by one or more communication buses or signal lines. Also, while many of the functions have been described as being performed by one component, one of ordinary skill in the art will realize that the functions described with respect toFIG. 106 may be split into two or more integrated circuits.
• B. Computer System
• FIG. 107 conceptually illustrates another example of anelectronic system10700 with which some embodiments of the invention are implemented. Theelectronic system10700 may be a computer (e.g., a desktop computer, personal computer, tablet computer, etc.), phone, PDA, or any other sort of electronic or computing device. Such an electronic system includes various types of computer readable media and interfaces for various other types of computer readable media.Electronic system10700 includes abus10705, processing unit(s)10710, a graphics processing unit (GPU)10715, asystem memory10720, anetwork10725, a read-only memory10730, apermanent storage device10735,input devices10740, andoutput devices10745.
• Thebus10705 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of theelectronic system10700. For instance, thebus10705 communicatively connects the processing unit(s)10710 with the read-only memory10730, theGPU10715, thesystem memory10720, and thepermanent storage device10735.
• From these various memory units, the processing unit(s)10710 retrieves instructions to execute and data to process in order to execute the processes of the invention. The processing unit(s) may be a single processor or a multi-core processor in different embodiments. Some instructions are passed to and executed by theGPU10715. TheGPU10715 can offload various computations or complement the image processing provided by the processing unit(s)10710. In some embodiments, such functionality can be provided using CoreImage's kernel shading language.
• The read-only-memory (ROM)10730 stores static data and instructions that are needed by the processing unit(s)10710 and other modules of the electronic system. Thepermanent storage device10735, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when theelectronic system10700 is off. Some embodiments of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive, integrated flash memory) as thepermanent storage device10735.
• Other embodiments use a removable storage device (such as a floppy disk, flash memory device, etc., and its corresponding drive) as the permanent storage device Like thepermanent storage device10735, thesystem memory10720 is a read-and-write memory device. However, unlikestorage device10735, thesystem memory10720 is a volatile read-and-write memory, such a random access memory. Thesystem memory10720 stores some of the instructions and data that the processor needs at runtime. In some embodiments, the invention's processes are stored in thesystem memory10720, thepermanent storage device10735, and/or the read-only memory10730. From these various memory units, the processing unit(s)10710 retrieves instructions to execute and data to process in order to execute the processes of some embodiments.
• Thebus10705 also connects to the input andoutput devices10740 and10745. Theinput devices10740 enable the user to communicate information and select commands to the electronic system. Theinput devices10740 include alphanumeric keyboards and pointing devices (also called “cursor control devices”), cameras (e.g., webcams), microphones or similar devices for receiving voice commands, etc. Theoutput devices10745 display images generated by the electronic system or otherwise output data. Theoutput devices10745 include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD), as well as speakers or similar audio output devices. Some embodiments include devices such as a touchscreen that function as both input and output devices.
• Finally, as shown inFIG. 107,bus10705 also coupleselectronic system10700 to anetwork10725 through a network adapter (not shown). In this manner, the computer can be a part of a network of computers (such as a local area network (“LAN”), a wide area network (“WAN”), or an Intranet, or a network of networks, such as the Internet. Any or all components ofelectronic system10700 may be used in conjunction with the invention.
• Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media may store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.
• While the above discussion primarily refers to microprocessor or multi-core processors that execute software, some embodiments are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions that are stored on the circuit itself. In addition, some embodiments execute software stored in programmable logic devices (PLDs), ROM, or RAM devices.
• As used in this specification and any claims of this application, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms “computer readable medium,” “computer readable media,” and “machine readable medium” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.
V. Map Service Environment
• Various embodiments may operate within a map service operating environment.FIG. 108 illustrates a map service operating environment, according to some embodiments. A map service10830 (also referred to as mapping service) may provide map services for one or more client devices10802a-10802cin communication with themap service10830 through various communication methods and protocols. Amap service10830 in some embodiments provides map information and other map-related data, such as two-dimensional map image data (e.g., aerial view of roads utilizing satellite imagery), three-dimensional map image data (e.g., traversable map with three-dimensional features, such as buildings), route and direction calculation (e.g., ferry route calculations or directions between two points for a pedestrian), real-time navigation data (e.g., turn-by-turn visual navigation data in two or three dimensions), location data (e.g., where is the client device currently located), and other geographic data (e.g., wireless network coverage, weather, traffic information, or nearby points-of-interest). In various embodiments, the map service data may include localized labels for different countries or regions; localized labels may be utilized to present map labels (e.g., street names, city names, points of interest) in different languages on client devices. Client devices10802a-10802cmay utilize these map services by obtaining map service data. Client devices10802a-10802cmay implement various techniques to process map service data. Client devices10802a-10802cmay then provide map services to various entities, including, but not limited to, users, internal software or hardware modules, and/or other systems or devices external to the client devices10802a-10802c.
• In some embodiments, a map service is implemented by one or more nodes in a distributed computing system. Each node may be assigned one or more services or components of a map service. Some nodes may be assigned the same map service or component of a map service. A load balancing node in some embodiments distributes access or requests to other nodes within a map service. In some embodiments a map service is implemented as a single system, such as a single server. Different modules or hardware devices within a server may implement one or more of the various services provided by a map service.
• A map service in some embodiments provides map services by generating map service data in various formats. In some embodiments, one format of map service data is map image data. Map image data provides image data to a client device so that the client device may process the image data (e.g., rendering and/or displaying the image data as a two-dimensional or three-dimensional map). Map image data, whether in two or three dimensions, may specify one or more map tiles. A map tile may be a portion of a larger map image. Assembling together the map tiles of a map produces the original map. Tiles may be generated from map image data, routing or navigation data, or any other map service data. In some embodiments map tiles are raster-based map tiles, with tile sizes ranging from any size both larger and smaller than a commonly-used 256 pixel by 256 pixel tile. Raster-based map tiles may be encoded in any number of standard digital image representations including, but not limited to, Bitmap (.bmp), Graphics Interchange Format (.gif), Joint Photographic Experts Group (.jpg, .jpeg, etc.), Portable Networks Graphic (.png), or Tagged Image File Format (.tiff). In some embodiments, map tiles are vector-based map tiles, encoded using vector graphics, including, but not limited to, Scalable Vector Graphics (.svg) or a Drawing File (.drw). Some embodiments also include tiles with a combination of vector and raster data. Metadata or other information pertaining to the map tile may also be included within or along with a map tile, providing further map service data to a client device. In various embodiments, a map tile is encoded for transport utilizing various standards and/or protocols.
• In various embodiments, map tiles may be constructed from image data of different resolutions depending on zoom level. For instance, for low zoom level (e.g., world or globe view), the resolution of map or image data need not be as high relative to the resolution at a high zoom level (e.g., city or street level). For example, when in a globe view, there may be no need to render street level artifacts as such objects would be so small as to be negligible in many cases.
• A map service in some embodiments performs various techniques to analyze a map tile before encoding the tile for transport. This analysis may optimize map service performance for both client devices and a map service. In some embodiments map tiles are analyzed for complexity, according to vector-based graphic techniques, and constructed utilizing complex and non-complex layers. Map tiles may also be analyzed for common image data or patterns that may be rendered as image textures and constructed by relying on image masks. In some embodiments, raster-based image data in a map tile contains certain mask values, which are associated with one or more textures. Some embodiments also analyze map tiles for specified features that may be associated with certain map styles that contain style identifiers.
• Other map services generate map service data relying upon various data formats separate from a map tile in some embodiments. For instance, map services that provide location data may utilize data formats conforming to location service protocols, such as, but not limited to, Radio Resource Location services Protocol (RRLP), TIA 801 for Code Division Multiple Access (CDMA), Radio Resource Control (RRC) position protocol, or LTE Positioning Protocol (LPP). Embodiments may also receive or request data from client devices identifying device capabilities or attributes (e.g., hardware specifications or operating system version) or communication capabilities (e.g., device communication bandwidth as determined by wireless signal strength or wire or wireless network type).
• A map service may obtain map service data from internal or external sources. For example, satellite imagery used in map image data may be obtained from external services, or internal systems, storage devices, or nodes. Other examples may include, but are not limited to, GPS assistance servers, wireless network coverage databases, business or personal directories, weather data, government information (e.g., construction updates or road name changes), or traffic reports. Some embodiments of a map service may update map service data (e.g., wireless network coverage) for analyzing future requests from client devices.
• Various embodiments of a map service may respond to client device requests for map services. These requests may be a request for a specific map or portion of a map. Some embodiments format requests for a map as requests for certain map tiles. In some embodiments, requests also supply the map service with starting locations (or current locations) and destination locations for a route calculation. A client device may also request map service rendering information, such as map textures or style sheets. In at least some embodiments, requests are also one of a series of requests implementing turn-by-turn navigation. Requests for other geographic data may include, but are not limited to, current location, wireless network coverage, weather, traffic information, or nearby points-of-interest.
• A map service, in some embodiments, analyzes client device requests to optimize a device or map service operation. For instance, a map service may recognize that the location of a client device is in an area of poor communications (e.g., weak wireless signal) and send more map service data to supply a client device in the event of loss in communication or send instructions to utilize different client hardware (e.g., orientation sensors) or software (e.g., utilize wireless location services or Wi-Fi positioning instead of GPS-based services). In another example, a map service may analyze a client device request for vector-based map image data and determine that raster-based map data better optimizes the map image data according to the image's complexity. Embodiments of other map services may perform similar analysis on client device requests and as such the above examples are not intended to be limiting.
• Various embodiments of client devices (e.g., client devices10802a-10802c) are implemented on different portable-multifunction device types. Client devices10802a-10802cutilizemap service10830 through various communication methods and protocols. In some embodiments, client devices10802a-10802cobtain map service data frommap service10830. Client devices10802a-10802crequest or receive map service data. Client devices10802a-10802cthen process map service data (e.g., render and/or display the data) and may send the data to another software or hardware module on the device or to an external device or system.
• A client device, according to some embodiments, implements techniques to render and/or display maps. These maps may be requested or received in various formats, such as map tiles described above. A client device may render a map in two-dimensional or three-dimensional views. Some embodiments of a client device display a rendered map and allow a user, system, or device providing input to manipulate a virtual camera in the map, changing the map display according to the virtual camera's position, orientation, and field-of-view. Various forms and input devices are implemented to manipulate a virtual camera. In some embodiments, touch input, through certain single or combination gestures (e.g., touch-and-hold or a swipe) manipulate the virtual camera. Other embodiments allow manipulation of the device's physical location to manipulate a virtual camera. For instance, a client device may be tilted up from its current position to manipulate the virtual camera to rotate up. In another example, a client device may be tilted forward from its current position to move the virtual camera forward. Other input devices to the client device may be implemented including, but not limited to, auditory input (e.g., spoken words), a physical keyboard, mouse, and/or a joystick.
• Some embodiments provide various visual feedback to virtual camera manipulations, such as displaying an animation of possible virtual camera manipulations when transitioning from two-dimensional map views to three-dimensional map views. Some embodiments also allow input to select a map feature or object (e.g., a building) and highlight the object, producing a blur effect that maintains the virtual camera's perception of three-dimensional space.
• In some embodiments, a client device implements a navigation system (e.g., turn-by-turn navigation). A navigation system provides directions or route information, which may be displayed to a user. Some embodiments of a client device request directions or a route calculation from a map service. A client device may receive map image data and route data from a map service. In some embodiments, a client device implements a turn-by-turn navigation system, which provides real-time route and direction information based upon location information and route information received from a map service and/or other location system, such as Global Positioning Satellite (GPS). A client device may display map image data that reflects the current location of the client device and update the map image data in real-time. A navigation system may provide auditory or visual directions to follow a certain route.
• A virtual camera is implemented to manipulate navigation map data according to some embodiments. Some embodiments of client devices allow the device to adjust the virtual camera display orientation to bias toward the route destination. Some embodiments also allow virtual camera to navigation turns simulating the inertial motion of the virtual camera.
• Client devices implement various techniques to utilize map service data from map service. Some embodiments implement some techniques to optimize rendering of two-dimensional and three-dimensional map image data. In some embodiments, a client device locally stores rendering information. For instance, a client stores a style sheet which provides rendering directions for image data containing style identifiers. In another example, common image textures may be stored to decrease the amount of map image data transferred from a map service. Client devices in different embodiments implement various modeling techniques to render two-dimensional and three-dimensional map image data, examples of which include, but are not limited to: generating three-dimensional buildings out of two-dimensional building footprint data; modeling two-dimensional and three-dimensional map objects to determine the client device communication environment; generating models to determine whether map labels are seen from a certain virtual camera position; and generating models to smooth transitions between map image data. Some embodiments of client devices also order or prioritize map service data in certain techniques. For instance, a client device detects the motion or velocity of a virtual camera, which if exceeding certain threshold values, lower-detail image data is loaded and rendered of certain areas. Other examples include: rendering vector-based curves as a series of points, preloading map image data for areas of poor communication with a map service, adapting textures based on display zoom level, or rendering map image data according to complexity.
• In some embodiments, client devices communicate utilizing various data formats separate from a map tile. For instance, some client devices implement Assisted Global Positioning Satellites (A-GPS) and communicate with location services that utilize data formats conforming to location service protocols, such as, but not limited to, Radio Resource Location services Protocol (RRLP), TIA 801 for Code Division Multiple Access (CDMA), Radio Resource Control (RRC) position protocol, or LTE Positioning Protocol (LPP). Client devices may also receive GPS signals directly. Embodiments may also send data, with or without solicitation from a map service, identifying the client device's capabilities or attributes (e.g., hardware specifications or operating system version) or communication capabilities (e.g., device communication bandwidth as determined by wireless signal strength or wire or wireless network type).
• FIG. 108 illustrates one possible embodiment of an operatingenvironment10800 for amap service10830 and client devices10802a-10802c. In some embodiments,devices10802a,10802b, and10802ccommunicate over one or more wire orwireless networks10810. For example,wireless network10810, such as a cellular network, can communicate with a wide area network (WAN)10820, such as the Internet, by use ofgateway10814. Agateway10814 in some embodiments provides a packet oriented mobile data service, such as General Packet Radio Service (GPRS), or other mobile data service allowing wireless networks to transmit data to other networks, such aswide area network10820. Likewise, access device10812 (e.g., IEEE 802.11g wireless access device) provides communication access toWAN10820.Devices10802aand10802bcan be any portable electronic or computing device capable of communicating with a map service.Device10802ccan be any non-portable electronic or computing device capable of communicating with a map service.
• In some embodiments, both voice and data communications are established overwireless network10810 andaccess device10812. For instance,device10802acan place and receive phone calls (e.g., using voice over Internet Protocol (VoIP) protocols), send and receive e-mail messages (e.g., using Simple Mail Transfer Protocol (SMTP) or Post Office Protocol 3 (POP3)), and retrieve electronic documents and/or streams, such as web pages, photographs, and videos, overwireless network10810,gateway10814, and WAN10820 (e.g., using Transmission Control Protocol/Internet Protocol (TCP/IP) or User Datagram Protocol (UDP)). Likewise, in some implementations,devices10802band10802ccan place and receive phone calls, send and receive e-mail messages, and retrieve electronic documents overaccess device10812 andWAN10820. In various embodiments, any of the illustrated client device may communicate withmap service10830 and/or other service(s)10850 using a persistent connection established in accordance with one or more security protocols, such as the Secure Sockets Layer (SSL) protocol or the Transport Layer Security (TLS) protocol.
• Devices10802aand10802bcan also establish communications by other means. For example,wireless device10802acan communicate with other wireless devices (e.g.,other devices10802b, cell phones, etc.) over thewireless network10810. Likewisedevices10802aand10802bcan establish peer-to-peer communications10840 (e.g., a personal area network) by use of one or more communication subsystems, such as Bluetooth® communication from Bluetooth Special Interest Group, Inc. of Kirkland, Wash.Device10802ccan also establish peer to peer communications withdevices10802aor10802b(not shown). Other communication protocols and topologies can also be implemented.Devices10802aand10802bmay also receive Global Positioning Satellite (GPS) signals fromGPS satellites10860.
• Devices10802a,10802b, and10802ccan communicate withmap service10830 over the one or more wire and/or wireless networks,10810 or10812. For instance,map service10830 can provide a map service data torendering devices10802a,10802b, and10802c.Map service10830 may also communicate withother services10850 to obtain data to implement map services.Map service10830 andother services10850 may also receive GPS signals fromGPS satellites10860.
• In various embodiments,map service10830 and/or other service(s)10850 are configured to process search requests from any of client devices. Search requests may include but are not limited to queries for business, address, residential locations, points of interest, or some combination thereof.Map service10830 and/or other service(s)10850 may be configured to return results related to a variety of parameters including but not limited to a location entered into an address bar or other text entry field (including abbreviations and/or other shorthand notation), a current map view (e.g., user may be viewing one location on the multifunction device while residing in another location), current location of the user (e.g., in cases where the current map view did not include search results), and the current route (if any). In various embodiments, these parameters may affect the composition of the search results (and/or the ordering of the search results) based on different priority weightings. In various embodiments, the search results that are returned may be a subset of results selected based on specific criteria include but not limited to a quantity of times the search result (e.g., a particular point of interest) has been requested, a measure of quality associated with the search result (e.g., highest user or editorial review rating), and/or the volume of reviews for the search results (e.g., the number of times the search result has been review or rated).
• In various embodiments,map service10830 and/or other service(s)10850 are configured to provide auto-complete search results that are displayed on the client device, such as within the mapping application. For instance, auto-complete search results may populate a portion of the screen as the user enters one or more search keywords on the multifunction device. In some cases, this feature may save the user time as the desired search result may be displayed before the user enters the full search query. In various embodiments, the auto complete search results may be search results found by the client on the client device (e.g., bookmarks or contacts), search results found elsewhere (e.g., from the Internet) bymap service10830 and/or other service(s)10850, and/or some combination thereof. As is the case with commands, any of the search queries may be entered by the user via voice or through typing. The multifunction device may be configured to display search results graphically within any of the map display described herein. For instance, a pin or other graphical indicator may specify locations of search results as points of interest. In various embodiments, responsive to a user selection of one of these points of interest (e.g., a touch selection, such as a tap), the multifunction device is configured to display additional information about the selected point of interest including but not limited to ratings, reviews or review snippets, hours of operation, store status (e.g., open for business, permanently closed, etc.), and/or images of a storefront for the point of interest. In various embodiments, any of this information may be displayed on a graphical information card that is displayed in response to the user's selection of the point of interest.
• In various embodiments,map service10830 and/or other service(s)10850 provide one or more feedback mechanisms to receive feedback from client devices10802a-10802c. For instance, client devices may provide feedback on search results to mapservice10830 and/or other service(s)10850 (e.g., feedback specifying ratings, reviews, temporary or permanent business closures, errors etc.); this feedback may be used to update information about points of interest in order to provide more accurate or more up-to-date search results in the future. In some embodiments,map service10830 and/or other service(s)10850 may provide testing information to the client device (e.g., an A/B test) to determine which search results are best. For instance, at random intervals, the client device may receive and present two search results to a user and allow the user to indicate the best result. The client device may report the test results to mapservice10830 and/or other service(s)10850 to improve future search results based on the chosen testing technique, such as an A/B test technique in which a baseline control sample is compared to a variety of single-variable test samples in order to improve results.
• While the invention has been described with reference to numerous specific details, one of ordinary skill in the art will recognize that the invention can be embodied in other specific forms without departing from the spirit of the invention. For instance, many of the figures illustrate various touch gestures (e.g., taps, double taps, swipe gestures, press and hold gestures, etc.). However, many of the illustrated operations could be performed via different touch gestures (e.g., a swipe instead of a tap, etc.) or by non-touch input (e.g., using a cursor controller, a keyboard, a touchpad/trackpad, a near-touch sensitive screen, etc.). In addition, a number of the figures conceptually illustrate processes. The specific operations of these processes may not be performed in the exact order shown and described. The specific operations may not be performed in one continuous series of operations, and different specific operations may be performed in different embodiments. Furthermore, the process could be implemented using several sub-processes, or as part of a larger macro process. Thus, one of ordinary skill in the art would understand that the invention is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims.

Claims (24)

We claim:

1. A non-transitory machine-readable medium storing a program which when executed on a device by at least one processing unit provides different viewing modes for viewing a three-dimensional (3D) map, the program comprising sets of instructions for:

rendering a first view of the 3D map for display in a first viewing mode based on a first set of map data;

receiving input to adjust the view of the 3D map; and

in response to the input, rendering a second view of the 3D map for display in a second viewing mode based on a second set of map data different from the first set of map data.

2. The non-transitory machine-readable medium ofclaim 1, wherein the first set of map data defines roads in the 3D map as road vectors.

3. The non-transitory machine-readable medium ofclaim 2, wherein the second set of map data defines roads in the 3D map as polygons.

4. The non-transitory machine-readable medium ofclaim 2, wherein the second set of map data defines land in the 3D map as polygons.

5. The non-transitory machine-readable medium ofclaim 1, wherein the set of instructions for rendering the first view of the 3D map comprises a set of instructions for rendering buildings in the first view of the 3D map based on a third set of map data.

6. The non-transitory machine-readable medium ofclaim 5, wherein the set of instructions for rendering the second view of the 3D map comprises a set of instructions for rendering the buildings in the second view of the 3D map based on the third set of map data.

7. The non-transitory machine-readable medium ofclaim 6, wherein the third set of map data comprises a set of building tiles that defines the buildings in the 3D map as polygons.

8. The non-transitory machine-readable medium ofclaim 1, wherein the first set of map data comprises a first set of map tiles and the second set of map data comprises a second set of map tiles different from the first set of map tiles.

9. The non-transitory machine-readable medium ofclaim 1, wherein the program further comprises sets of instructions for:

displaying the first view of the 3D map on the device in the first viewing mode; and

displaying the second view of the 3D map on the device in the second viewing mode.

10. A method for viewing a three-dimensional (3D) map on a device in different modes, the method comprising:

rendering and displaying the 3D map in a first viewing mode based on a first set of map tiles;

receiving input to adjust the displayed 3D map; and

in response to the input, rendering and displaying the 3D map in a second viewing mode based on a second set of map tiles different from the first set of map tiles.

11. The method ofclaim 10, wherein the device comprises a touchscreen, wherein receiving the input comprises receiving the input through the touchscreen of the device.

12. The method ofclaim 11, wherein the input comprises a multi-touch input.

13. The method ofclaim 12, wherein the multi-touch input comprises a pinch gesture for zooming out from the 3D map.

14. The method ofclaim 12, wherein the multi-touch input comprises a spread gesture for zooming in to the 3D map.

15. The method ofclaim 10 further comprising retrieving the second set of map tiles in response to receiving the input.

16. A non-transitory machine-readable medium storing a program executable on a device by at least one processing unit, the program comprising sets of instructions for:

display a three-dimensional (3D) map in a first viewing mode;

receiving input to apply a zoom operation on the 3D map;

when the zoom operation zooms the 3D map past a defined zoom level, displaying the 3D map in a second viewing mode;

when the zoom operation does not zoom the 3D map past the defined zoom level, continuing to display 3D map in the first viewing mode.

17. The non-transitory machine-readable medium ofclaim 16, wherein the zoom operation is a zoom-in operation.

18. The non-transitory machine-readable medium ofclaim 16, wherein the zoom operation is a zoom-out operation.

19. The non-transitory machine-readable medium ofclaim 16, wherein the set of instructions for displaying the 3D map in the first viewing mode comprises a set of instructions for displaying buildings in the 3D map with a first appearance, wherein the set of instructions for displaying the 3D map in the second viewing mode comprises a set of instructions for displaying the buildings in the 3D map with a second appearance different from the first appearance.

20. The non-transitory machine-readable medium ofclaim 16, wherein the set of instructions for displaying the 3D map in one of the first and second viewing modes comprises a set of instructions for displaying roads in the 3D map with a first appearance, wherein the set of instructions for displaying the 3D map in the other viewing mode comprises a set of instructions for displaying roads in the 3D map with a second appearance.

21. The non-transitory machine-readable medium ofclaim 16, wherein roads in the 3D map with the first appearance are displayed with lane markers and the roads in the 3D map with the second appearance are displayed without lane markers.

22. The non-transitory machine-readable medium ofclaim 16, wherein roads in the 3D map with the first appearance are displayed to appear as asphalt and the roads in the 3D map with the second appearance are displayed to appear without asphalt.

23. The non-transitory machine-readable medium ofclaim 16, wherein the first viewing mode is defined for viewing the 3D map at a range of zoom different zoom levels and the second viewing mode is defined for viewing the 3D map at a subset of the range of different zoom levels.

24. The non-transitory machine-readable medium ofclaim 16, wherein one of the first and second viewing modes is defined for viewing the 3D map when the program is only in a navigation modality.

Images