Patent Description:
The described embodiments relate generally to providing navigation route guidance, and more particularly, to dynamically determining a level of detail at which to render a digital map according to a user's position along the route.

Position information and navigation route guidance are typically provided to users of client devices with the assistance of digital maps. Digital maps are rendered at particular zoom levels, with higher zoom levels representing smaller scales. For example, a digital map may be rendered at a zoom level in which one inch on the digital map represents five hundred meters of actual distance. Digital maps are also rendered at particular levels of detail (LODs), with each higher level of detail including additional features. For example, a digital map rendered at a higher level of detail may include secondary roads, more points of interest (POIs), and more labeled features, while a digital map rendered at a lower level of detail may include only primary roads, show fewer or no POIs, and label fewer features.

When using a client device, receiving and rendering a digital map consumes bandwidth and power. Both the bandwidth and power consumption increase with the complexity of the map being rendered. <CIT> proposes techniques for fetching map data as a selected subset of entire map data available by selecting map data tiles corresponding to an area that encompasses a route. An amount of map data accessed may be adjusted based on a priority assigned to areas or points along the route. A sequence of map data may be accessed based on a priority assigned to sets of map data
<CIT> proposes a navigation system for instructing an operator of a vehicle. The navigation system includes a navigation processor configured to obtain a destination location, and to generate a proposed route to the destination location. The navigation system also includes a presentation element coupled to the navigation processor, the presentation element configured to provide navigation instructions to the operator. A selection module is coupled to or incorporated into the navigation processor, and the selection module is configured to select a cartographic resolution from a plurality of different cartographic resolutions, resulting in a selected cartographic resolution. The presentation element provides navigation instructions for at least a portion of the proposed route, using the selected cartographic resolution. <CIT> proposes a system and method for off route processing. The system and method can be used to provide information when an off route condition occurs. The system and method can include provisions to make modifications in the way navigation information is displayed. The system and method can also provide a selectable re-route mode and selectable re-route information.

According to a first aspect of the present invention, there is provided a method as set out in claim <NUM>. According to a second aspect of the present invention, there is provided a non-transitory computer-readable storage medium as set out in claim <NUM>. Described embodiments enable navigation route guidance using less client device power and bandwidth by automatically selecting which portions of a digital map to display on the client device with higher levels of detail and which portions to display with lower levels of detail. For example, in one embodiment an origin location and destination location are displayed at a higher level of detail, while portions of a route between the origin location and destination location are displayed at a lower level of detail. Portions of the route that involve turns or other complex maneuvers may also be rendered at higher levels of detail.

Described embodiments also include displaying digital maps to a client device user who is a user of a transportation service. For example, a user may use an application on her client device to request a ride, specify her pickup location, and specify her destination location. The pickup locations and destination locations may be displayed on her client device using a digital map rendered at a higher level of detail. While waiting for a driver to pick her up, and while en route to the destination location, the user may consult a digital map displayed on her client device that is rendered at a lower level of detail. In one embodiment, multiple users participate as riders in a transportation service, sharing a common driver but each having different pickup and drop off locations. In this embodiment, portions of a map may be rendered at one level of detail for one of the users, but the same region of the map may be rendered at a different level of detail for another user, according to their respective pickup and drop off locations.

The figures and the following description relate to various embodiments by way of illustration only. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily recognized as viable alternatives that may be employed without departing from the principles of what is claimed.

Network systems acting as navigation service providers may be used to facilitate navigation service between client devices operating within an environment. For example, a navigation service provider system may be used to provide routes, digital maps, and navigation route guidance to client devices traversing road networks in the environment. In some configurations, the navigation service provider system may be configured to determine levels of detail for digital maps and navigation route guidance that reduce the amount of power and bandwidth required to facilitate navigation service. For example, the navigation service provider may provide some portions of a navigation route guidance at a high level of detail while providing other portions of the navigation route guidance at a lower level of detail.

<FIG> illustrates an environment <NUM> for providing automatic selection of map detail levels in accordance with one embodiment. Environment <NUM> includes a client device <NUM> and a navigation service provider (NSP) system <NUM> that communicate with each other over a network <NUM>. The road network can be represented as a digital map that can be stored on NSP system <NUM>. The NSP system <NUM> can provide digital maps of the environment <NUM> to client device <NUM> and client device <NUM> can display the digital map. Additionally, NSP system <NUM> can determine a route from a first location to a second location using the digital map. The route also includes any number of locations between the first location and the second location. NSP system <NUM> can determine and provide navigation route guidance for the route to client device <NUM>. Route guidance, in various embodiments, includes a visual depiction (e.g., highlighted road segments) of a route from a first location to a second location shown on a digital map. Route guidance may also include other forms of route guidance for the route, including, for example, textual guidance, audio guidance, visual guidance, etc..

Client device <NUM> is a computing device used by a user to obtain route guidance and view digital maps. In one embodiment, client device <NUM> includes a radio <NUM>, a user interface <NUM>, and a map request module <NUM>. Client device <NUM> may be a smartphone, tablet, portable computer, or other such device. Client device <NUM> may also be a purpose-built device such as a hand-held navigation computer. Client device <NUM> includes software e.g., an application or operating system that implements the various embodiments of the invention in whole or in part. In some embodiments, the capabilities of client device <NUM> may also be provided by a computer system installed within a vehicle, such as, for example, an in-car navigation system.

Client device <NUM> includes a radio <NUM> for communicating with NSP system <NUM> via network <NUM>. Methods of communication between client device <NUM> and network <NUM> may include one or more of cellular, satellite, LAN, WAN, or any suitable protocol that supports the exchange of data described here. In various embodiments, radio <NUM> also includes a GPS receiver that provides positioning information identifying a current position of client device <NUM>.

Client device <NUM> includes a user interface <NUM> for displaying digital maps and route guidance. User interface <NUM> also allows a user to specify information, view and/or manipulate a digital map, and view and/or manipulate route guidance. For example, a user can view her current location, specify an origin location and a destination location, and request route guidance from the origin location to destination location. In various embodiments, locations may be specified by entering address information (e.g., <NUM><NUM>th Avenue, New York, NY), point-of-interest (POI) information (e.g., "Empire State Building"), or by selecting a point on a displayed digital map. Once an origin and destination location have been specified by the user, client device <NUM> requests and obtains route guidance information from NSP system <NUM> via network <NUM>.

NSP system <NUM> receives requests for route guidance and provides route guidance and digital maps in response. NSP system <NUM> includes a routing engine <NUM>, a rendering engine <NUM>, and a map data store <NUM>. NSP system <NUM> may be operated, for example, by an entity that provides mapping, routing, and guidance services, or by some other entity.

Routing engine <NUM> receives a request for route guidance, including the origin location and destination location, from client device <NUM> and in response determines a route along segments of the road network from the origin location to the destination location. Determination of a route may be performed according to any number of conventionally known algorithms. Once routing engine <NUM> determines the route, rendering engine <NUM> renders a digital map to be provided to client device <NUM>.

Note that while for purposes of illustration we describe segments as road segments within a road network, in various other embodiments the road network may include segments that are traversed by foot, motor vehicle, bicycle, or other form of travel.

Rendering engine <NUM> renders (i.e., creates, generates, etc.) a digital map using map data stored in map data store <NUM>. The map data includes information about the road network within the geographic regions described by the map data, and may include other features such as bodies of water, topographical characteristics, and POIs.

Map data store <NUM> also stores map properties that describe characteristics of road segments. For example, the map properties may include navigation rules such as speed limits and road segment directionality (e.g., one-way or two way). The navigation rules can also include properties about intersections, such as, for example, turn restrictions, stop-light timing information, and connecting road segments. Other map properties may include traffic history, traffic conditions, addresses on the road segment, length of the road segment, and type of the road segment (e.g., surface street, residential, highway, toll, etc.). In some embodiments, the map properties also include properties describing the geographic region as a whole or portions of the geographic region. For example, the properties may include weather within the geographic region, geopolitical boundaries (e.g., city limits, county borders, state borders, country borders), and topological features. Each of the features or category of features, may have an associated level of detail as described further below.

A digital map includes one or more rendered tiles, each representing a portion of the digital map. In various embodiments, the dimensions of a rendered tile are of a fixed size when displayed in a user interface. Therefore, a digital map may be displayed as an arrangement (e.g., a grid) of rendered tiles. For example, a particular user interface <NUM> might accommodate display of a <NUM>-by-<NUM> tile grid.

The geographical area covered by a tile depends upon the zoom level of the digital map. In one embodiment, for example, rendering engine <NUM> initially selects a zoom level that includes the complete route from the origin location to the destination location, and renders the digital map at that zoom level. Continuing the previous example, rendering engine <NUM> renders a digital map with a <NUM>-by-<NUM> tile grid that displays the route from the origin location to the destination location when displayed on the particular user interface <NUM>.

Rendering engine <NUM> also selects, for each tile, a level of detail (LOD) at which to render the tile. In various embodiments, map data store <NUM> associates an LOD value with each feature of the digital map. For example, major highways and bodies of water may have a low LOD value, while tertiary roads and streams may have a high LOD value. Features of the digital map such as small curves in road segments, the shapes of rivers and streams, etc., are also simplified when included at lower LODs, for example as described in <CIT>.

In one embodiment, rendering engine <NUM> renders the tiles containing the origin location and destination locations at a higher LOD than it does the remainder of the tiles. This accounts for what is typically an increased complexity involved in beginning or ending a route - for example, if a route begins with navigation to a freeway, proceeds along the freeway, and then exits the freeway to arrive at the destination, a higher LOD near the origin and destination locations enables a user to more easily navigate while near those locations, while a lower LOD displayed along the freeway portion of the route is adequate, since little maneuvering or complex navigation is required of the user.

In other embodiments, rendering engine <NUM> computes a complexity score for intervals along the route. A complexity score is a measure of complexity for navigation elements such as, for example, turns onto different streets, changes in the road direction (e.g., switchbacks), changes in road names, and transitions between roads of different priority (e.g., primary, secondary and tertiary roads). For tiles displaying intervals (portions) of the route that have a complexity score higher than a threshold score, rendering engine <NUM> renders the tile at a higher LOD, i.e. an LOD sufficiently high to include the required navigation elements. Rendering engine <NUM> renders the remainder of the tiles at a lower LOD. The threshold score may be selected by the implementer (e.g., an administrator of NSP system <NUM>), or by the user - for example, in one embodiment a user interface element such as a slider allows the user to adjust the level of complexity at which a tile will be rendered at a higher LOD. Alternatively, a user can select certain navigation elements, e.g., change of road name, turns, etc., that will cause a tile containing those navigation elements to be rendered at a higher LOD.

Once rendering engine <NUM> renders the digital map, NSP system <NUM> returns the digital map and route guidance to client device <NUM>. Client device <NUM> then displays the tiles of the digital map and the route guidance to the user in user interface <NUM>.

In various embodiments, the user may request that one or more tiles displayed in user interface <NUM> be replaced by tiles rendered with higher or lower LOD's. For example, in one embodiment if the user taps on a tile that is rendered with a lower LOD, map request module <NUM> requests a high-LOD replacement tile from NSP system <NUM> in response. Rendering engine <NUM> then renders the requested high-LOD replacement tile and returns the replacement tile to client device <NUM>. Similarly, at the discretion of the implementer, user interface <NUM> may include additional user interface elements to control whether individual tiles or groups of tiles (e.g., all displayed tiles, all tiles along the route, tiles within a particular distance of the route, etc.) are displayed at a higher or at a lower LOD.

In various embodiments, a user may manipulate the displayed digital map by, for example panning the digital map across user interface <NUM>. Panning the map may cause client device <NUM> to request additional tiles from NSP system <NUM> for displaying on user interface <NUM>. The request for the new tiles may specify that newly rendered tiles should be rendered at a higher LOD.

In various embodiments, if a user changes the zoom level of the map displayed in user interface <NUM>, client device <NUM> requests new map tiles from NSP system <NUM>. Rendering engine <NUM> renders the requested map tiles at the requested zoom level, and selects a LOD for each tile according to the methods described above. In one embodiment, if a user requests a higher zoom level than the initial zoom level, rendering engine <NUM> automatically selects a higher LOD for all tiles rendered in response to the request for a higher zoom level.

In one embodiment, client device <NUM> caches map tiles that have been received from NSP system<NUM>, and map request module <NUM> substitutes the highest-LOD tile available in the cache for a particular tile, instead of requesting the tile from NSP system <NUM>. Cached tiles may have a particular time to live, and once a cached tile has expired, it is removed from cache and a new tile is requested as described above. In another example, cached tiles may only be stored if client device <NUM> remains within a threshold distance of the geographical area represented by the tile.

<FIG> is a flowchart illustrating a method for automatically selecting levels of detail for displaying route guidance to a user, in accordance with one embodiment. The illustrated method may be implemented using client device <NUM> and NSP system <NUM> described in regards to <FIG>.

A user requests route guidance using user interface <NUM> of client device <NUM> and map request module <NUM> receives <NUM> the request. The user may specify an origin location and destination location for the route guidance either by reference to an address, a POI name, or by selecting a location using a digital map. In embodiments where the user selects a location using a digital map displayed on a user interface <NUM>, client device <NUM> may display a cached version of a digital map stored locally on client device <NUM> as noted above. Alternatively a user may request a high-LOD set of map tiles from NSP system <NUM> for areas surrounding the user's present position or, if the user pans the displayed digital map, tiles that cover the region panned to.

Once the user has specified at least an origin location and destination location, map request module <NUM> requests <NUM> a digital map including route guidance information from NSP system <NUM> via network <NUM>. The request may include the origin location and destination location specified by the user. In some examples, the request may also include any other parameters specified by the user or requesting map request module <NUM> indicating a preferred LOD or zoom level.

Routing engine <NUM> of NSP system <NUM> receives <NUM> the route guidance request and determines <NUM> a route from the origin location to destination location. Rendering engine <NUM> renders <NUM> one or more sets of map tiles for a digital map using map data from map data store <NUM>. Rendering engine <NUM> may render the one or more sets of tiles according to the specified LOD received from the client device, a complexity score calculated for portions of the route, or a predetermined LOD implemented by NSP system <NUM>. NSP system <NUM> returns <NUM> the rendered digital map including the route guidance to client device <NUM> via the network <NUM>.

The route guidance in various embodiments includes a visual depiction of the route shown on the map, and may also include text-based or other forms of instructions. Map request module <NUM> of client device <NUM> receives <NUM> the rendered digital map and route guidance, and displays <NUM> the digital map and route guidance in user interface <NUM>. As the user progresses through the route, client device <NUM> may show the user's position (e.g., as determined by an on-board radio <NUM> such as a GPS receiver) overlaid on the digital map. As described above, the user may request that all or portions of the digital map be displayed at a higher LOD, in which case map request module <NUM> requests replacement tiles from rendering engine <NUM>, specifying the higher LOD desired.

In one embodiment, map request module <NUM> automatically requests a higher LOD tile containing the current position of the client device <NUM>. This prevents power and bandwidth consumption required to render and obtain high-LOD map tiles for portions of a route the user has not traversed, and may not traverse if the user chooses to depart from the route, end her journey early, etc. In some embodiments, portions of the map that are within a threshold distance (e.g., <NUM>) of the route are rendered at a higher LOD, while the remainder of the map is rendered at a lower LOD.

<FIG> illustrates in more detail the rendering of map tiles performed by rendering engine <NUM> of NSP system <NUM> at step <NUM>.

Rendering engine <NUM> receives <NUM> the route from the origin location to the destination location from routing engine <NUM> and selects <NUM> a zoom level. As described above, the zoom level in one embodiment is chosen such that the origin location and destination locations will be visible together on the route map provided to the client device <NUM> and displayed in user interface <NUM>. In alternative embodiments, other zoom levels may be chosen, or a zoom level may be specified in the request received from client device <NUM>.

Rendering engine <NUM> identifies <NUM> the tile including the origin location and identifies <NUM> the tile including the destination location. Rendering engine <NUM> renders <NUM> the origin tile and destination tile at a high LOD. Rendering engine <NUM> identifies <NUM> the remainder of the tiles to be sent to client device <NUM>, and renders <NUM> those tiles at a lower LOD. NSP system <NUM> returns <NUM> route guidance and a digital map including the rendered tiles to client device <NUM>.

In some embodiments, tiles near (e.g., adjacent, or within a threshold number of tiles) to the origin location and/or destination location may also be rendered at a higher LOD. This may be helpful, for example, where an origin location and/or destination location is near the edge of a tile, and rendering the neighboring tile at a low LOD may not provide sufficient guidance to the user. As noted above, a complexity score can be determined for intervals (e.g., an interval of distance, or an interval of time) of the route, and tiles exceeding a threshold complexity score can be rendered at a higher LOD.

In various embodiments, map data store <NUM> includes POIs that can be displayed on a rendered digital map. POIs include major landmarks, buildings, topographic features, and other distinctive features and locations of interest. As with other map data stored by map data store <NUM>, POIs may have associated LODs, and thus are ordinarily only included in map tiles that have a level of at least the requisite detail. In some embodiments, rendering engine <NUM> includes certain POIs in rendered tiles even where the POI would not normally be included for the given level of detail. In a particular example, rendering engine <NUM> determines whether a change in route (e.g., a turn, a change in street name, etc.) occurs near a POI and, if so, includes the POI in the rendered tile regardless of the POI's associated LOD value.

In some embodiments, the user has an account on NSP system <NUM>, and NSP system <NUM> maintains a record of previous route guidance provided to client device <NUM> associated with the user. In some such embodiments, rendering engine <NUM> includes a POI in a rendered map provided to the user if the POI was previously provided to the user as part of a previous route. This assists the user by providing her with a POI she may recognize, having previously passed by it.

<FIG> illustrates an environment <NUM> in which embodiments of the invention operate in connection with a service facilitator. The service facilitator, for example, may be a transport service facilitator (TSF) system <NUM> that facilitates matching of drivers who provide transport service to riders who request transportation. Other service facilitation applications are also possible (e.g., delivery service, etc.). A TSF system <NUM> includes the elements previously described with respect to NSP system <NUM>, additionally including user data store <NUM> and matching engine <NUM>. <FIG> also illustrates a driver client device <NUM>, rider client device <NUM> (which is an example of client device <NUM> of <FIG>), and network <NUM>. Driver client device <NUM> may be similarly configured to, and provide similar functionality to, client device <NUM> of <FIG>. In some embodiments, driver client device <NUM> may be an autonomous vehicle.

In some embodiments, users such as drivers and riders use their client devices <NUM> and <NUM>, respectively, to register with the TSF system <NUM>. For example, users may register by creating accounts and providing user information (e.g., contact information, a home or office address, or billing information) to TSF system <NUM>. TSF system <NUM> can store the user information and transport service records in the user data store <NUM>. For instance, information including transport service records describing transport service that a rider received from drivers, or transport service that a driver provided to riders may be stored in user data store <NUM>. TSF system <NUM> can associate feedback received from a user or data from transport service taken with the user's registered account.

Matching engine <NUM> selects drivers to provide transport service using transport service requests received from riders. For example, matching engine <NUM> receives a transport service request from a rider client device <NUM> and determines a set of candidate drivers that are online, available to provide transport service, and near the requested pickup location (i.e., origin location) for the rider. Matching engine <NUM> selects a driver from the set of candidate drivers to which it transmits an assignment request. The driver can be selected based on the driver's location, the pickup and/or destination location, the type of the driver, the amount of time the driver has been waiting for an assignment request and/or the destination of the trip, among other factors.

In some embodiments, the matching engine <NUM> selects the driver who is closest to the pickup location or who will take the least amount of time to travel to the pickup location (e.g., having the shortest estimated travel time to the pickup location based on routing and map information from a data source). The matching engine <NUM> sends an assignment request to the selected driver. If the driver accepts the assignment request, then the matching engine <NUM> assigns the driver to the rider. If the driver rejects the assignment request, then the matching engine <NUM> selects another driver and sends a subsequent assignment request to the client device <NUM> for that driver.

In various embodiments, when a user uses rider client device <NUM> to request a ride, she is presented with a map in user interface <NUM>, through which she can specify her pickup (origin) location, and may in some embodiments also specify a drop-off (destination) location. Map request module <NUM> displays a digital map showing the user's current location (e.g., based on a GPS signal from radio <NUM>). To display the digital map, map request module <NUM> obtains the digital map from its cache, if available, and otherwise requests any needed tiles from system <NUM> at a high LOD to enable the user to accurately identify her pickup location.

In various embodiments, once the user has submitted her transport service request and been matched by matching engine <NUM> with a driver who is willing to provide the transportation service to the user, rider client device <NUM> displays a digital map to the user showing a current location of the driver's client device <NUM>. The user interface <NUM> of the rider client device <NUM> enables the user to track the driver's progress to the pickup location. In various embodiments, map request module <NUM> requests tiles for this digital map in a lower LOD, since the user does not require a high level of detail to understand the driver's progress towards her.

Once the rider has been picked up by the driver and the trip is underway, the driver can obtain route guidance on his driver client device <NUM> in the manner described above, e.g., with respect to <FIG> and <FIG>. The rider can also view her progress on her rider client device <NUM>. In one embodiment, while the trip is underway map request module <NUM> obtains map tiles that are rendered at a low LOD, which provides the rider with context as to the progress of her journey, without requiring the power and bandwidth consumption involved in downloading high-LOD maps. In some embodiments, the area of the map including the rider's drop-off location is rendered at a higher LOD, while the remainder of the route is rendered at a low LOD. In some embodiments, the rider can obtain higher-LOD maps while on her trip by invoking user interface elements provided for that purpose.

In some embodiments, a different color scheme or theme is associated with low versus high LOD maps, which provides an immediate visual cue to the user as to which display mode is being used.

In some embodiments, TSF system <NUM> facilitates rides for multiple riders matched with a single driver, such that riders may share parts of their routes with each other. Consequently, each rider may have a different pickup and/or drop-off location. In various embodiments, each rider's client device <NUM> requests maps with an LOD appropriate for their individual phase of their journey. For example, two riders may be in a driver's car simultaneously, with the first rider having a drop-off location at <NUM> Dulany Street and a second rider having a drop-off location at <NUM> King Street. The map request module <NUM> of the first rider's device <NUM> includes a high-LOD rendering of the area surrounding <NUM> Dulany Street, while the remainder of the map is rendered at lower LOD-including, if shown at all, the area surrounding <NUM> King Street. Conversely, the map request module <NUM> of the second rider's device <NUM> includes a high-LOD rendering of the area surrounding <NUM> King Street, but not <NUM> Dulany Street. Similarly, a third rider awaiting pickup by the same driver may consult his rider client device <NUM> while awaiting pickup, and the region surrounding that rider's pickup location is rendered at a high-LOD, but that same region is displayed at low LOD for his two co-riders, who are already on board and en route.

<FIG> is a diagram illustrating a computer system upon which embodiments described herein may be implemented. For example, in the context of <FIG>, NSP system <NUM> may be implemented using a computing system <NUM> such as described by <FIG>. Similarly, in the context of <FIG>, TSF system <NUM> may be implemented using a computing system <NUM> such as described by <FIG>. Systems <NUM> and/or <NUM> may also be implemented using a combination of multiple computer systems <NUM> as described by <FIG>, with each computer system implementing one or more of the components of systems <NUM> and/or <NUM>. Multiple-computer-system implementations include networked systems, such as a networked client-server system.

In one implementation, computing system <NUM> includes processing resources such as one or more processors <NUM>, as well as main memory <NUM>, read only memory (ROM) <NUM>, a storage device <NUM>, and a communication interface <NUM>. Computing system <NUM> includes the processor(s) <NUM> for processing information and main memory <NUM>, such as a random access memory (RAM) or other dynamic storage device, for storing information and instructions to be executed by the processor(s) <NUM>. Main memory <NUM> also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor(s) <NUM>. Computing system <NUM> may also include ROM <NUM> or other static storage device for storing static information and instructions for processor(s) <NUM>.

The storage device <NUM>, such as a magnetic disk or optical disk, is provided for storing information and instructions. The communication interface <NUM> can enable computing system <NUM> to communicate with one or more networks (e.g., cellular network, network <NUM>, etc.), through use of the network link (wireless or wireline). Using the network link, computing system <NUM> can communicate with one or more computing devices, and one or more servers.

In some variations, computing system <NUM> can be configured to receive sensor data (e.g., such as GPS data) from one or more location tracking devices via the network link. The sensor data can be processed by the processor <NUM> and can be stored in, for example, the storage device <NUM>. The processor <NUM> can process the sensor data of a location tracking device in order to determine the path of travel of a transportation vehicle corresponding to the location tracking device. Extrapolated position information can be transmitted to one or more service requestor devices over the network to enable the service applications running on the service requestor devices to use the position information to present a visualization of the actual movement of the transportation vehicles.

Computing system <NUM> can also include a display device <NUM>, such as a cathode ray tube (CRT), an LCD monitor, or a television set, for example, for displaying graphics and information to a user. An input mechanism, such as a keyboard that includes alphanumeric keys and other keys, can be coupled to systems <NUM> and/or <NUM> for communicating information and command selections to processor(s) <NUM>. Other non-limiting, illustrative examples of input mechanisms <NUM> include a mouse, a trackball, touch-sensitive screen, or cursor direction keys for communicating direction information and command selections to processor(s) <NUM> and for controlling cursor movement on display device <NUM>.

In various embodiments, storage device <NUM> stores any of user data store <NUM>, map data store <NUM>, rendering engine <NUM>, routing engine <NUM>, and matching engine <NUM> components described herein as computer executable instructions. During operation, the processor(s) <NUM> executes the instructions and loads the components into main memory <NUM>. The instructions cause the processor(s) <NUM> to perform the method of <FIG> and <FIG>. In this way, the processor(s) <NUM> coupled to main memory <NUM>, read only memory (ROM) <NUM>, storage device <NUM>, and communication interface <NUM> (as described below in greater detail) is a special-purpose processor.

Examples described herein are related to the use of computing system <NUM> for implementing the techniques described herein. According to one embodiment, those techniques are performed by computing system <NUM> in response to processor(s) <NUM> executing one or more sequences of one or more instructions contained in main memory <NUM>. Such instructions may be read into main memory <NUM> from another machine-readable medium, such as storage device <NUM>. Execution of the sequences of instructions contained in main memory <NUM> causes processor(s) <NUM> to perform the process steps described herein. In alternative implementations, hard-wired circuitry may be used in place of or in combination with software instructions to implement examples described herein. Thus, the examples described are not limited to any specific combination of hardware circuitry and software.

<FIG> is a diagram illustrating a mobile computing device <NUM> upon which embodiments described herein may be implemented as described above. For example, rider client device <NUM> and/or driver client device <NUM> may be implemented as an embodiment of mobile computing device <NUM>. In one embodiment, mobile computing device <NUM> may correspond a cellular device that is capable of telephony, messaging, and data services. Examples of such devices include smartphones, handsets or tablet devices for cellular carriers. Mobile computing device <NUM> includes a processor <NUM>, memory resources <NUM>, a display device <NUM> (e.g., such as a touch-sensitive display device), one or more communication sub-systems <NUM> (including wireless communication sub-systems), input mechanisms <NUM> (e.g., an input mechanism can include or be part of the touch-sensitive display device), and one or more location detection mechanisms (e.g., GPS module) <NUM>. In one example, at least one of the communication sub-systems <NUM> sends and receives cellular data over data channels and voice channels.

The processor <NUM> is configured with software and/or other logic to perform one or more processes, steps and other functions described with implementations, such as those described herein. Processor <NUM> is configured, with instructions and data stored in the memory resources <NUM>, to operate a service application as described herein. For example, instructions for operating the service application in order to display user interfaces can be stored in the memory resources <NUM> of the computing device <NUM>.

The processor <NUM> can provide content to the display <NUM> by executing instructions and/or applications that are stored in the memory resources <NUM>. In some examples, one or more user interfaces can be provided by the processor <NUM>, such as a user interface for the service application, based at least in part on the received position information of the one or more transportation vehicles. While <FIG> is illustrated for a mobile computing device, one or more embodiments may be implemented on other types of devices, including fully-functional computers, such as laptops and desktops (e.g., PC).

In addition to the embodiments specifically described above, those of skill in the art will appreciate that the invention may additionally be practiced in other embodiments.

Within this written description, the particular naming of the components, capitalization of terms, the attributes, data structures, or any other programming or structural aspect is not mandatory or significant unless otherwise noted, and the mechanisms that implement the described invention or its features may have different names, formats, or protocols. Further, the system may be implemented via a combination of hardware and software, as described, or entirely in hardware elements. Also, the particular division of functionality between the various system components described here is not mandatory; functions performed by a single module or system component may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component. Likewise, the order in which method steps are performed is not mandatory unless otherwise noted or logically required. It should be noted that the process steps and instructions of the present invention could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by real time network operating systems.

Algorithmic descriptions and representations included in this description are understood to be implemented by computer programs. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules or code devices, without loss of generality.

Unless otherwise indicated, discussions utilizing terms such as "selecting" or "computing" or "determining" or the like refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.

An example not falling under the claimed invention relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, DVDs, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

The algorithms and displays presented are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings above, or it may prove convenient to construct more specialized apparatus to perform the required method steps. In addition, a variety of programming languages may be used to implement the teachings above.

Claim 1:
A method for providing route guidance on a client device, the method comprising:
receiving, by at least one processor of a client device, a route, the route including an origin location, a destination location, and a plurality of locations in between the origin location and the destination location;
requesting, by the processor of the client device, a first set of digital map tiles, each tile in the first set including a first portion of the route rendered at a first level of detail;
requesting, by the processor of the client device, a second set of digital map tiles, each tile in the second set including a second portion of the route rendered at a second level of detail, the second level of detail having a lower level of detail than the first level of detail; and
determining a complexity score for a third portion of the route based on the complexity for navigation elements of the route along the third portion;
responsive to the complexity score being above a threshold, requesting, by the processor of the client device, a third set of digital map tiles, each tile in the third set including the third portion of the route rendered at the first level of detail;
simultaneously displaying, on the display of the client device and using the computer processor, the route and at least some of the requested digital map tiles of the first set, at least some of the requested digital map tiles of the second set and at least some of the digital map tiles of the third set.