Patent Description:
Navigation systems that automatically route drivers, bicyclists and pedestrians between geographic locations generally utilize indications of distance, street names, building numbers, etc. to generate navigation instructions based on the route. For example, these systems can provide to a driver such instructions as "proceed for one-fourth of a mile, then turn right onto Maple Street. " To users who are en route to a destination, a portable component of the navigation system can provide relative navigation instructions, i.e., instructions that are based on the direction of the movement. Examples of such navigation instructions include "turn left onto Main Street. " However, at the beginning of navigation, when the user is stationary and there is no direction of movement yet, the navigation systems in general provide absolute directions such as "go North on State Street. " Users can find absolute directions difficult to use, as they do not always know their orientation. However, it is difficult for a portable device to determine its operation or heading while the portable device is at rest.

Generally speaking, the system of this disclosure identifies candidate navigation landmarks at the initial location of a portable device within a <NUM>-degree range of the location. The candidate navigation landmarks can be visible within the <NUM>-degree view, audible within the <NUM>-degree range, or otherwise perceptible in any direction from the initial location. The system then generates initial navigation instructions referencing one or several of these landmarks, without limiting the selection to those landmarks that are disposed in the direction of initial travel. The system can generate such initial navigation instructions when the portable device is at rest, without relying on the sensors of the portable device to determine the current orientation of the portable device or the user. In some cases, the system generates initial navigation instructions that reference landmarks that will be behind the user once he or she commences travel. For example, the initial navigation instruction can be "walk away from the fountain and toward the hill. " Moreover, the landmark(s) the system selects need not be proximate and can include far-away natural objects such as mountains as well as artificial structures such as bridges, towers, tall buildings, etc. Using crowdsourcing or automated techniques, the system according to the invention identifies and references in initial navigation instructions auditory landmarks, e.g., "walk toward the music" if an outdoor concert is reported at a nearby location.

According to an aspect of the invention, there is provided a method for providing initial navigation guidance according to claim <NUM>.

According to another aspect of the invention, there is provided a portable computing device according to claim <NUM>.

Other example embodiments of these techniques are methods and systems that select a navigation landmark disposed in a direction substantially aligned with the direction of the first directed section in a sequence of directed sections. Yet other example methods and systems select a navigation landmark disposed in a direction that is neither aligned with the direction of the first directed section nor opposite to the direction of the first directed section (e.g., the direction in which the navigation landmark lies can be substantially perpendicular to the direction of the first directed section).

To users who are en route to a destination, a navigation system of this disclosure can provide relative navigation instructions, i.e., instructions that based on the direction of the movement. Examples of such navigation instructions include "turn left onto Main Street. " However, at the beginning of navigation, when the user is stationary and there is no direction of movement yet, absolute directions such as "go North on State Street" may be difficult to use. To generate initial navigation instructions, the navigation system identifies candidate navigation landmarks at the initial location of a portable device within a <NUM>-degree degree of the location. The navigation system then generates initial navigation instructions referencing one or several of these navigation landmarks, without limiting the selection to those navigation landmarks that are disposed in the direction of initial travel.

In some cases, the navigation system generates initial navigation instructions that reference navigation landmarks that will be behind the user once he or she commences travel. For example, the initial navigation instruction can be "walk away from the fountain and toward the hill. " Moreover, the one or several navigation landmarks the system selects need not be proximate and can include far-away natural objects such as mountains as well as artificial structures such as bridges, towers, tall buildings, etc. Using crowdsourcing, the navigation system also can identify and reference in initial navigation instructions auditory landmarks, e.g., "walk toward the music" if an outdoor concert is reported at a nearby location.

The navigation landmarks can be permanent or transient. The navigation system can generate various metrics for navigation landmarks, and use the metrics when selecting navigation landmarks for certain location and certain orientation. The metrics can be related to observability, prominence, and uniqueness of navigation landmarks. To assess these factors, the system can utilize machine vision and other automated techniques, crowdsourcing, etc..

<FIG> illustrates an environment <NUM> in which at least some of the techniques for generating initial navigation instructions can be implemented. The environment <NUM> includes a portable system <NUM> and a server system <NUM> interconnected via a communication network <NUM>. The server system <NUM> in turn can communicate with various databases and, in some implementations, third-party systems such as a live traffic service or a weather service (not shown to avoid clutter). A navigation system <NUM> operating in the environment <NUM> includes components configured to select visual and/or auditory landmarks for inclusion in navigation instructions and, in particular, for generating initial navigation instructions. The navigation system <NUM> can be implemented in the portable system <NUM>, the server system <NUM>, or partially in portable system <NUM> and partially in the server system <NUM>.

The portable system <NUM> can include a portable electronic device such as a smartphone, a wearable device such as a smartwatch or a head-mounted display, or a tablet computer. In some implementations or scenarios, the portable system <NUM> also includes components embedded or mounted in a vehicle. For example, a driver of a vehicle equipped with electronic components such as a head unit with a touchscreen can use her smartphone for navigation. The smartphone can connect to the head unit via a short-range communication link such as Bluetooth® to access the sensors of the vehicle and/or to project the navigation instructions onto the screen of the head unit. In general, modules of a portable or wearable user device, modules of a vehicle, and external devices or modules of devices can operate as components of the portable system <NUM>.

The portable system <NUM> can include a processing module <NUM>, which can include one or more central processing unit (CPUs), one or more graphics processing unit (GPUs) for efficiently rendering graphics content, an application-specific integrated circuit (ASIC), or any other suitable type of processing hardware. Further, the portable system <NUM> can include a memory <NUM> made up of persistent (e.g., a hard disk, a flash drive) and/or non-persistent (e.g., RAM) components. The portable system <NUM> further includes a user interface <NUM> and a network interface <NUM>. Depending on the scenario, the user interface <NUM> can correspond to the user interface of the portable electronic device or the user interface of the vehicle. In either case, the user interface <NUM> can include one or more input components such as a touchscreen, a microphone, a keyboard, etc. as well as one or more output components such as a screen or speaker.

The network interface <NUM> can support short-range and/or long-range communications. For example, the network interface <NUM> can support cellular communications, personal area network protocols such as IEEE <NUM> (e.g., Wi-Fi) or <NUM> (Bluetooth). In some implementations, the portable system <NUM> includes multiple network interface modules to interconnect multiple devices within the portable system <NUM> and to connect the portable system <NUM> to the network <NUM>. For example, the portable system <NUM> can include a smartphone, the head unit of a vehicle, and a camera mounted on the windshield. The smartphone and the head unit can communicate using Bluetooth, the smartphone and the camera can communicate using USB, and the smartphone can communicate with the server <NUM> via the network <NUM> using a <NUM> cellular service, to pass information to and from various components of the portable system <NUM>.

Further, the network interface <NUM> in some cases can support geopositioning. For example, the network interface <NUM> can support Wi-Fi trilateration. In other cases, the portable system <NUM> can include a dedicated positioning module <NUM> such as a Global Positioning Service (GPS) module. In general, the portable system <NUM> can include various additional components, including redundant components such as positioning modules implemented both in the vehicle and in the smartphone.

In the example implementation illustrated in <FIG>, the memory <NUM> stores instructions that implement an initial navigation instruction API <NUM>, a geographic application <NUM>, and a third-party application <NUM>. In another implementation, however, the memory <NUM> stores only the API <NUM> and the third-party application <NUM> such as a web browser or a gaming application, which obtains initial navigation instructions with references to navigation landmarks by invoking the API <NUM> and uses in the initial navigation instructions in the manner specific to the application. In another implementation, the memory <NUM> stores only the geographic application <NUM> which obtains the initial navigation instructions and provides these initial navigation instructions via the user interface <NUM> as part of driving directions, for example. More generally, the memory <NUM> store the API <NUM>, the geographic application <NUM>, or both.

With continued reference to <FIG>, the portable system <NUM> can communicate with the server system <NUM> via the network <NUM>, which can be a wide-area network such as the Internet. The server system <NUM> can be implemented in one more server devices, including devices distributed over multiple geographic locations. The server system <NUM> can implement a routing engine <NUM>, a navigation instructions generator <NUM>, and a landmark selection module <NUM>. The components <NUM>-<NUM> can be implemented using any suitable combination of hardware, firmware, and software. The server system <NUM> can access databases such as a map database <NUM>, a visual landmark database <NUM>, and a user profile database <NUM>, which can be implemented using any suitable data storage and access techniques.

In operation, the routing engine <NUM> can receive a request for navigation instructions from the portable system <NUM>. The request can include a source, a destination, and constraints such as a request to avoid toll roads, for example. The request can come from the geographic application <NUM> or the API <NUM>, for example. The routing engine <NUM> in response can retrieve road geometry data, road and intersection restrictions (e.g., one-way, no left turn), road type data (e.g., highway, local road), speed limit data, etc. from the map database <NUM> to generate a route from the source to the destination. In some implementations, the routing engine <NUM> also obtains live traffic data when selecting the best route. In addition to the best, or "primary," route, the routing engine <NUM> can generate one or several alternate routes.

In addition to road data, the map database <NUM> can store descriptions of geometry and location indications for various natural geographic features such as rivers, mountains, and forests, as well as artificial geographic features such buildings and parks. The map data can include, among other data, vector graphics data, raster image data, and text data. In an example implementation, the map database <NUM> organizes map data into map tiles, which generally correspond to a two-dimensional organization of geospatial data into traversable data structure such as a quadtree.

The navigation instructions generator <NUM> can use the one or more routes generated by the routing engine <NUM> and generate a sequence of navigation instructions. Examples of navigation instructions include "in <NUM> feet, turn right on Elm St. " and "continue straight for four miles. " The navigation instructions generator <NUM> can implement natural language generation techniques to construct these and similar phrases, in the language of the driver associated with the portable system <NUM>. The instructions can include text, audio, or both. As discussed in more detail below, the navigation instructions generator <NUM> and/or software components implemented in the portable system <NUM> generate initial navigation instructions that reference navigation landmarks in a manner that differs from the navigation instructions provided while the portable device is en route.

The landmark selection module <NUM> can operate as part of the navigation system <NUM>, which also can include the navigation application <NUM>. The landmark selection module <NUM> can augment the navigation instructions generated by the navigation instructions generator <NUM> with references to visual landmarks such as prominent buildings, billboards, traffic lights, stop signs, statues and monuments, and symbols representing businesses. To this end, the landmark selection module <NUM> can access the visual landmark database <NUM> to select a set of visual landmarks disposed along the navigation route. The landmark selection module <NUM> selects one or more landmarks for inclusion in the initial navigation directions in view of additional signals, such as the indication that the portable computing device is at rest. When selecting landmarks for the initial navigation directions, the landmark selection module <NUM> can apply different selection criteria (e.g., visibility in the <NUM>-degree range), as discussed below.

The visual landmark database <NUM> can store information regarding prominent geographic entities that can be visible when driving (or bicycling, walking, or otherwise moving along a navigation route) and thus serve as visual landmarks. For each visual landmark, the visual landmark database <NUM> can store one or several photographs, geographic coordinates, a textual description, remarks submitted by users, and numeric metrics indicative of usefulness of the visual landmark and/or of a particular image of the visual landmark. In some implementations, a landmark-specific record in the visual landmark database <NUM> stores multiple views of the visual landmark from the same vantage point, i.e., captured from the same location and with the same orientation of the camera. However, the multiple views of the visual landmark can differ according to the time of day, weather conditions, season, etc. The data record can include metadata that specifies these parameters for each image. For example, the data record may include a photograph of a billboard at night when it is illuminated along with a timestamp indicating when the photograph was captured and another photograph of the billboard at daytime from the same vantage point along with the corresponding timestamp. Further, the data record may include photographs of the billboard captured during snowy weather, during rainy weather, during foggy weather, etc., and corresponding indicators for each photograph. Still further, the data record may include photographs captured during different seasons.

In short, the visual landmark database <NUM> can store a large set of visual landmarks that in some cases is redundant both in terms of the number of landmarks available for the same maneuver (e.g., a billboard on the right and a church on the left near the same intersection) and in terms of imagery available for the same landmark. The navigation system <NUM> can determine which of the redundant landmarks are useful for particular lighting conditions, weather conditions, traffic conditions (as drivers may find it difficult to recognize certain visual landmarks when driving fast), and how well the corresponding scene is visible from the driver's vantage point (as inferred from real-time imagery).

In addition to multiple images of a same visual landmark, the visual landmark database <NUM> can store multiple descriptions of the same landmark, such as "the large glass building," "the building with a large 'M' in front of it," "the building with international flags ," etc. Operators of the server system <NUM> and/or users submitting landmark information as part of a crowd-sourcing effort can submit these descriptions, and the server system <NUM> can determine which description drivers find more helpful using the feedback processing techniques discussed in more detail below. To keep track of drivers' feedback, the visual landmark database <NUM> in one example implementation stores an overall numeric metric for a visual landmark that can be used to assess whether the visual landmark should be referenced in navigation instructions at all, separate numeric metrics for different times of day, different weather conditions, etc. and/or separate numeric metrics for different images.

To populate the visual landmark database <NUM>, the server system <NUM> can receive satellite imagery, photographs and videos submitted by various users, street-level imagery collected by cars equipped with specialized panoramic cameras, street and sidewalk imagery collected by pedestrians and bicyclists, crowd-sourced information from users (e.g., "street fair at State & Main"), etc. Similarly, the visual landmark database <NUM> can receive descriptions of landmarks from various sources such as operators of the server system <NUM> and people submitting user-generated content. Additionally or alternatively to using crowdsourcing techniques, the server system <NUM> can utilize 3D reconstruction, computer vision, and other automated techniques to generate numeric metrics of observability, prominence, and uniqueness for potential visual landmarks, and various audio processing techniques to determine similar metrics (e.g., volume, frequency range, distinctiveness) for auditory landmarks. The server system <NUM> in some implementations uses metrics derived from user-generated content to supplement or correct the automatically generated metrics, for example.

As illustrated in <FIG>, the visual landmark database <NUM> can store images <NUM> of highly distinctive, famous buildings visible at relatively few locations, images <NUM> of large structures visible from numerous locations, and images <NUM> of generally inconspicuous buildings that nevertheless may be sufficiently observable, prominent, and unique in a certain setting (e.g., next to multiple smaller buildings).

In another implementation, the visual landmark database <NUM> stores only references to images in other databases. For example, one or several database can store the images <NUM>, <NUM> and <NUM>, and various electronic services can use these images for a variety of purposes (such as providing user albums, online photo galleries, virtual tours or supplementing business data). Because these images often are updated, the visual landmark database <NUM> in this implementation can store only references to the images to avoid redundancy in storage and the delays associated with synchronizing databases. In a similar manner, the visual landmark database <NUM> can store, for a certain landmark, a reference to the corresponding map data in the map database <NUM> rather than a copy of the map data.

With continued reference to <FIG>, the user profile database <NUM> can store user preferences regarding the types of visual landmarks they prefer to see. For example, the profile of a certain user can indicate that she prefers billboards as landmarks. The landmark selection module <NUM> can use user preferences as at least one of the factors when selecting visual landmarks from among redundant visual landmarks. In some implementations, the user provides an indication that he or she allows the navigation system <NUM> to utilize this data. Other factors for selecting visual landmarks from among redundant visual landmarks can include objective metrics, such as the numeric metrics of prominence, observability and uniqueness. In an example implementation, the objective metrics take precedence over user preferences.

In example operation, the portable system <NUM> generates a request for navigation instructions and transmits the request to the server system <NUM>. The request can include an indication of the current location of the portable system <NUM> as well as an indication, which can be explicit or implicit, that the portable system <NUM> currently is at rest. The navigation system <NUM> determines which navigation landmarks are visible or otherwise perceptible at the current location of the portable system <NUM>, without limiting the selection of navigation landmark to any single direction relative to the current location of the portable system <NUM>.

As indicated above, functionality of the navigation system <NUM> can be distributed between the portable system <NUM> and the server system <NUM> in any suitable manner. In some implementations, for example, the server system <NUM> can provide indications of multiple landmarks surrounding the current location of the portable system <NUM>, along with the navigation instructions for traveling to the destination, and the geographic application <NUM> and/or the API <NUM> can locally format the initial navigation instructions.

Next, example methods for generating initial navigation instructions with navigation landmarks and populating a database with suitable navigation landmark data are discussed with reference to <FIG> and <FIG>, respectively, followed by a discussion of an example interface which the portable system <NUM> can provide. Additional examples and methods for selecting and providing navigation landmarks in initial navigation are further discussed with reference to <FIG>.

<FIG> is a flow diagram of an example method <NUM> for generating initial navigation instructions for drivers. The navigation system <NUM> discussed can implement the method <NUM> as a set of instructions executable on one or more processors, in one or several devices. For example, some or all of the acts that make up the method <NUM> can be implemented in the modules <NUM>, <NUM> and <NUM>.

The method <NUM> begins at block <NUM>, where a route to a destination is determined. For example, a request can be received from a portable device, such as the portable system <NUM> of <FIG>, for navigating a user to a certain location from the current location of the portable device. The route can be determined in accordance with any suitable technique in view of road geometry, various road properties such as speed limits and toll requirements, current road conditions, weather, etc. The route can include a sequence of directed sections between waypoints. An example sequence can include the following directed sections: (i) North from the current location at Fifth Ave. and Main to the corner of Ninth and Main, along Main, (ii) West from the corner of Ninth Ave. and Main to the corner of Ninth Ave. and Maple, along Ninth Ave. , (iii) South from the corner of Ninth Ave. and Maple for <NUM> yards along Maple.

At block <NUM>, candidate navigation landmarks perceptible within a <NUM>-degree range of the current location of the portable device are identified. As discussed in more detail with reference to <FIG>, the database <NUM> of <FIG> or a similar database can store data related to various navigation landmarks that are prominently and uniquely observable from various geographic locations. For example, the database can indicate that for the corner of Fifth Ave. and Main, the prominently and uniquely observable navigation landmarks include City Hall <NUM> yards North, a railroad bridge one quarter of a mile West, a mountain range far South (e.g., > <NUM> miles) , and a fountain <NUM> yards East.

Next, at block <NUM>, one or several navigation landmarks are selected for inclusion in the initial navigation instructions, and a corresponding initial navigation instruction is generated at block <NUM>. To continue with the example above, the initial directed section in the sequence corresponding to a certain route defines travel North from Fifth Ave. The initial navigation instructions for this segment can include a reference to the mountain range disposed far South of this starting location. As a more specific example, the initial navigation instructions can include the text "Begin travel away from the mountain range. " Further, the initial navigation instructions can reference City Hall, disposed in the opposite direction, and the text can be "Begin travel away from the mountain range and toward City Hall.

The initial navigation instructions can be provided via the user interface visually or in the form of an announcement, at block <NUM>. As illustrated in more detail <FIG>, the initial navigation instructions also can be provided in an interactive manner to allow the user to view additional details related to the referenced navigation landmarks. Once the initial navigation instructions are provided to the user in the manner described above, subsequent navigation directions can refer to relative maneuvers, such as "turn left in two blocks at Broadway.

Now referring to <FIG>, an example method <NUM> for selecting landmarks for initial navigation directions based on several metrics can be implemented in the module <NUM>, for example, as a set of instructions executable on one or more processors. More generally, the method <NUM> can be implemented in one or several modules, which in some embodiments are distributed among multiple devices or systems. According to some implementations, the method <NUM> is executed in an offline or batch mode to generate metrics for various candidate navigation landmarks and update the respective database records, for subsequent selection. In other implementations, the method <NUM> is executed in real time as part of block <NUM> discussed above with reference to <FIG>, for example.

At block <NUM>, an indication of a candidate navigation landmark for a certain geographic location is received. For example, for a certain urban location, any identifiable structure in close proximity to the location, any natural geographic feature known to be visible at the location, a source of noise known to be perceptible at the location, etc. Next, at blocks <NUM>-<NUM>, various numeric metrics for the candidate navigation landmark can be determined.

At block <NUM>, a metric of observability is determined. As used herein, observability refers to the probability a traveler can locate the navigation landmark without altering his or her position. For example, a fountain that may be concealed from one side of the street may not be consistently observable, and the metric accordingly can be relatively low. Similarly, seasonal or otherwise transient features may not be consistently observable. Accordingly, the observability metric also can be relatively low (or, in some implementation, the observability metric for the appropriate season can be relatively high, and the observability metric for the remaining seasons can be relatively low). In contrast, the observability metric for a large monument in the middle of city square can be assigned a relatively high value for locations in the square.

The numeric value for the metric of observability can be calculated using one or several signals. For example, photographs of a certain landmark can be tagged with the name of the landmark and with pose data (indications of the location or orientation of the camera). A certain number of photographs of the same landmark captured from the same location, as reflected in the pose data, in general are a strong indicator that the navigation landmark should have a high observability metric. Further, three-dimensional (3D) models constructed using scanning, 3D reconstruction from user photographs, panoramic imagery, aerial imagery, etc. can be used to determine line-of-sight for longer distances.

Still further, transient features can serve as navigation landmarks and assigned high metrics of observability for the appropriate periods of time. For example, farmer's markets can be open some days of the week seasonally, and public art installations can be exhibited for a limited time. Referring back to <FIG>, the map database <NUM> or a similar database can include a business data for the farmer's market at a certain location. This business data and/or crowd-sourced information related to the farmer's market can be used when generating the metric observability.

At block <NUM>, the module that implements the method <NUM> determines a metric of prominence for the candidate navigation landmark. To this end, the module can use such signals as an indication of how widely the candidate navigation landmark is photographed or mentioned in various documents. The numeric value for the metric of prominence can be calculated for example by counting the number of indexed photographs of the candidate navigation landmark and/or the number of search hits, reviews, and queries related to the candidate navigation landmark.

Another signal the module can use is indicative of whether the candidate navigation landmark can be easily picked out from among the surrounding elements. As one example, a computer vision feature detector/classifier can attempt to identify the candidate navigation landmark within a photograph of a scene including the candidate navigation landmark, where the photograph is captured at the given geographic location. If the candidate navigation landmark can be identified with high confidence, this can be used as a signal indicative of prominence.

With continued reference to <FIG>, a metric of uniqueness can be calculated at block <NUM>. To this end, proximity of the candidate navigation landmark to other landmarks can be assessed to determine, for example, whether nearby candidate navigation landmark or points of interest are of the same type (e.g., fountain, traffic signal). Some of the types of points of interest can inherently have expected noteworthiness (e.g., monuments). Other types of points of interest can be expected to be generally similar to each other (e.g., traffic signs).

The metrics determined at blocks <NUM>, <NUM> and <NUM> can be weighed in any suitable manner to generate an overall score. At block <NUM>, one or several landmarks can be selected for use with initial navigation instructions in view of the overall score or, if desired, only or two of the metrics determined at blocks <NUM>, <NUM> and <NUM>.

Referring back to <FIG>, geographic application <NUM> or the third-party application <NUM> can provide initial navigation instructions via an interactive user interface. One example implementation of this interface is discussed with reference to <FIG>. Each of the screenshots <NUM>, <NUM> and <NUM> illustrates example output of a software application displayed on a touchscreen of a portable device <NUM>. Although these examples depict a rectangular layout typical for a smartphone or tablet computer, square, circular, oval, and other types of layout can be implemented in generally similar manner for other types of devices such as smart watches or dedicated navigation devices, for example.

Referring first to an example screenshot <NUM> depicted in <FIG>, an instruction window <NUM> partially overlaps a digital map <NUM>, where the initial navigation instruction is illustrated using markers illustrating the current location of the user, the first waypoint, and the direction in which the user should move. As discussed above, it is difficult for the sensors of a portable device to reliably determine the user's orientation when the user is at rest, and accordingly it is difficult to assist the user with aligning the digital map <NUM> with the user's surroundings. The screenshot <NUM> can be generated directly in response to the user requesting navigation instructions or, in some implementations, after presenting an overview of the route to the user and in response to the user command to start presenting the sequence of navigation instructions.

The instruction window <NUM> in this example includes text that references both a navigation landmark (bank) disposed in the direction of travel along the first directed section of the route, and a navigation landmark (fountain) disposed in the opposite direction. Accordingly, the text instructs the user to walk toward the bank and away from the fountain. In some implementations, the digital map <NUM> is interactive and accessible via a direct contact such as a tap. In response to a tap event detected within the digital map <NUM>, the instruction window <NUM> can be dismissed.

As illustrated in <FIG>, the instruction window <NUM> can include icons depicting the type of the navigation landmark referenced in the initial navigation instruction. The landmark selection module <NUM> or another module operating in the system of <FIG> can select these icons from a list of available landmark types. The icons can be individually selectable to access additional information regarding the corresponding navigational landmark. Alternatively, the user can choose to dismiss the instruction window <NUM> to cause the digital map <NUM> to occupy the entire screen, or in any case a larger portion of the screen.

Referring to <FIG>, the user can select the icon corresponding to the bank to access an informational screen <NUM>, which can partially overlap the digital map <NUM> similar to the instruction window <NUM>. The selection of the icon can correspond to a tap event, a double event, or any suitable type of interaction. The informational screen <NUM> can include a conventional (flat) photograph of the navigation landmark, a panoramic photograph of the navigation landmark, an interactive 3D view of the landmark, or any other available imagery. If desired, the informational screen <NUM> can also include business data for the navigation landmark.

Next, a block diagram <NUM> of <FIG> schematically illustrates the use of distant and proximate navigation landmarks in generating initial navigation instructions. In this example scenario, the current location of the portable device is represented by marker <NUM> and the destination for the navigation instructions is represented by marker <NUM>. A route <NUM> between the current location and the destination is made up of a sequence of directed sections, including the first directed section <NUM>.

Referring to <FIG> and <FIG>, when the user of the portable system <NUM> begins navigation along the route <NUM>, the navigation system <NUM> can generate initial navigation directions that reference a mountain <NUM>, disposed far away from the location <NUM> (e.g., <NUM> miles) as well as a gas station <NUM> is disposed at the same intersection as the location represented by marker <NUM>. More particularly, the navigation system <NUM> can generate text <NUM> to instruct the user of the portable system <NUM> to start driving or walking away from the mountain <NUM> and toward the gas station <NUM>.

For further clarity, <FIG> illustrates an example method <NUM> for generating an initial navigation instruction that references two navigation landmarks disposed in different directions relative to the current location of the portable device. The method <NUM> can be implemented in the navigation system <NUM> discussed above. As a more specific example, the method <NUM> can be implemented in the navigation instructions generator <NUM> as a set of instructions stored on a computer-readable medium and executable by one or more processors.

At block <NUM>, a first navigation landmark is selected within the <NUM>-degree range in view of the metrics of observability, prominence and uniqueness discussed above. User preferences (e.g., "use billboards when available," "do not use auditory landmarks") also can be used to select from among multiple candidates. In general, the first navigation landmark can be selected in any direction relative to the direction of the first one of the sequence of directed sections. For example, the first navigation landmark can lie on the left-hand side relative to the direction of travel. In the example scenario discussed above with reference to <FIG>, the bank disposed in the general direction serves as the first navigation landmark. In the example scenario discussed above with reference to <FIG>, the mountain serves as the first navigation landmark.

Although the initial navigation instructions can include a reference to only one landmark, the method <NUM> can include selecting a second navigation landmark within the <NUM>-degree range at block <NUM>. The first and second navigation landmarks can be disposed in different directions relative to the initial direction of travel. At block <NUM>, the text of an initial navigation instruction referencing movement relative to the first navigation landmark and the second navigation landmark is generated. The movement can be away from the first navigation landmark and toward the second navigation landmark, for example. In some implementations, the text is generated according to the template "travel <direction> from <the first navigation landmark> to <the second navigation landmark>.

At block <NUM>, icons corresponding to the type of the first navigation landmark and the second navigation landmark are selected. As illustrated in <FIG>, the icons can operate as selectable controls for retrieving additional information regarding the navigation landmarks. An initial navigation instruction using the text generated at block <NUM> and the icons obtained at block <NUM> is generated (block <NUM>). The initial navigation instruction then can be provided to the portable system for display or otherwise for output via the user interface.

<FIG> is a flow diagram of an example method <NUM> for identifying locations that can serve as navigation landmarks for an initial navigation instruction, using photographs captured from certain locations. Referring back to <FIG>, the method <NUM> can be implemented in the landmark selection module <NUM>, for example, as one of the techniques for populating the visual database <NUM>. The method <NUM> can be implemented as a set of instructions stored on a computer-readable medium and executed by one or more processors.

Referring to <FIG>, a set of photographs of a landmark is identified at block <NUM>. For example, a large number of people may share their photographs of the National Gallery of Art building in Washington, D. , and many label ("tag") their photographs with the title "National Gallery of Art. " Moreover, many of these users share indications of the locations from which their photographs were captured.

At block <NUM>, a location from which multiple photographs of the landmark were captured is determined. For example, the photographs of the National Gallery of Art building can be clustered at certain locations from which people tend to capture photographs. As a more specific example, of <NUM>,<NUM> example photographs <NUM>% may be captured at a first intersection, another <NUM>% may be captured at a second intersection, and the remaining photographs may be spread around multiple other locations. Accordingly, at block <NUM>, the first and second intersections may be selected as locations from which this landmark is visible.

At block <NUM>, the respective directions from the first and second intersections to the National Gallery of Art building are determined using map data. At block <NUM>, a database (such as the database <NUM> of <FIG>) is updated to indicate that at the first intersection, the National Gallery of Art building is a candidate navigation landmark, disposed in a certain direction from the first intersection. Similarly, the database cam be updated to indicate that this building also is a candidate navigation landmark at the second intersection, disposed in the corresponding direction. The navigation system <NUM> of <FIG> subsequently can use these stored indications when selecting candidate navigation landmarks.

More generally, the navigation system <NUM> also employ a variety of techniques for populating the database <NUM>. Examples of such techniques include receiving indications from organizers regarding temporary exhibitions, street fairs, music festivals, etc. occurring at certain locations, or receiving similar indications from users in accordance with crowd-sourcing techniques to obtain indications of temporary events. For auditory landmarks, users can report sources of sound above a certain noise level, so that the navigation system <NUM> can generate initial navigation instructions of the type "walk away from the subway stop toward the music.

Similarly, the methods or routines described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented hardware modules. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.

The one or more processors may also operate to support performance of the relevant operations in a cloud computing environment or as a software as a service (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).

Claim 1:
A method for providing initial navigation guidance, the method comprising:
determining, by one or more processors, a route from a current location of a portable device to a destination, the route including a sequence of directed sections;
generating, by the one or more processors, navigation instructions to guide a user of the portable device along the route to the destination, including:
identifying an auditory navigation landmark corresponding to a source of sound proximate the current location of the portable device,
generating an initial instruction in the navigation instructions prior to determining a direction of movement of the user, the initial instruction referencing the identified auditory navigation landmark; and
causing the initial navigation instruction to be provided via a user interface of the portable device;
wherein generating the initial instruction includes directing the user to walk toward the source of sound.