Method and apparatus for dynamic navigation adjustment

Abstract

The present disclosure relates to methods and apparatus for dynamic navigation adjustments. A system includes a processor configured to receive an instruction to avoid a user-identified portion of a route. The processor is further configured to send the user-identified portion of the route to a remote server. The processor is further configured to receive an updated recommendation related to a size of the user-identified portion of the route in response to the sending, and to calculate a route that avoids the user-identified portion of the route updated by the updated recommendation.

Description

TECHNICAL FIELD

[0001] Illustrative embodiments relate generally to methods and apparatus for dynamic navigation modification. BACKGROUND

[0002] While vehicle navigation systems have existed for decades, recent improvements in both data collection and communication networks allow for real-time or near real-time identification of slowdowns, construction, and traffic congestion.

[0003] However, even with improved traffic reporting, data is not always completely accurate, and often specific incidents are marked on maps with very little data about how to avoid the incident or how far away the construction or traffic extension is.

[0004] Further, there are a wide variety of reasons why a user can want to avoid a road segment that is not related to traffic or current construction. For example, at a particular location, a road tends to form a poor shape after winter, or can experience severe flooding after a particular amount of rainfall. This type of data is not typically included in route "delay" data, but a local user can know that a particular road segment is highly undesirable to travel on. Or, for example, even for a short road segment, a portion of a road can not be paved, which makes travel along that road undesirable after rain or snow. SUMMARY

[0005] In a first illustrative embodiment, a system includes a processor configured to receive an instruction to avoid a user-identified portion of a route. The processor is further configured to send the user-identified portion of the route to a remote server. The processor is further configured to receive an updated recommendation related to a size of the user-identified portion of the route in response to the sending, and to compute a route that avoids the user-identified portion of the route updated by the updated recommendation.

[0006] In a second illustrative embodiment, a system includes a processor configured to receive a destination. The processor is further configured to retrieve a user-specified specified-avoidance area from local storage. The processor is further configured to compute a route to the destination that treats the avoidance area as an untraversable road segment for purposes of route computation, and to present the computed route.

[0007] In a third illustrative embodiment, a computer-implemented method includes receiving a driver request for route computation. The method also includes accessing a database of user-specified avoidance zones. The method also includes downloading avoidance zones within a predetermined distance from the vehicle and performing route determination, wherein the route determination includes avoiding travel on the downloaded user-specified avoidance zones.

[0008] According to one embodiment of the present application, the method also includes repeating the accessing and the downloading while the vehicle is traveling and repeating the performing such that the route determination adjusts a previously computed route to avoid any newly downloaded avoidance zones downloaded by the repeating the downloading.

[0009] According to one embodiment of the present application, the method also includes downloading avoidance zones having a specified condition associated with the avoidance zones.

[0010] According to one embodiment of the present application, the performing includes performing route determination, wherein the route determination includes avoiding travel only on the downloaded user-specified avoidance zones having a specified condition associated with the downloaded user-specified avoidance zones.

[0011] According to one embodiment of the present application, the specified condition includes at least one of potholes or standing water. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 An illustrative vehicle computing system is shown;

[0013] Figure 2 An illustrative process for route deviation is shown;

[0014] Figure 3 An illustrative process for route recommendation is shown;

[0015] Figure 4 An illustrative process for route computation is shown. DETAILED DESCRIPTION

[0016] Detailed embodiments are disclosed herein; however, it is understood that the disclosed embodiments are merely illustrative of the application and can be practiced in various and alternative forms. The figures are not necessarily to scale take some of the features can be exaggerated or minimized for the purpose of illustration. The specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to utilize the claimed subject matter in a variety of forms.

[0017] Figure 1An example block topology diagram for a vehicle-based computing system (VCS) 1 for a vehicle 31 is shown. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by Ford Motor Company. A vehicle provided with a vehicle-based computing system can include a visual front end interface 4 located in the vehicle. If the interface is provided with, for example, a touch sensitive screen, a user is also able to interact with the interface. In another illustrative embodiment, interaction is through button presses, a spoken dialogue system with automatic speech recognition and speech synthesis.

[0018] In Figure 1 In the illustrative embodiment 1 shown, a processor 3 controls at least a portion of the operation of the vehicle-based computing system. The processor, which is provided within the vehicle, allows for on-board processing of commands and routines. In addition, the processor is connected to both a non-persistent memory 5 and a persistent memory 7. In this illustrative embodiment, the non-persistent memory is a random access memory (RAM) and the persistent memory is a hard disk drive (HDD) or flash memory. In general, persistent (non-transitory) memory can include all forms of memory that save data when a computer or other device is powered down. These include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, solid state drives, portable USB drives, and any other appropriate form of persistent memory.

[0019] The processor is also provided with several different inputs that allow a user to interact with the processor. In this illustrative embodiment, a microphone 29, auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4 (which can be a touch screen display), and a Bluetooth input 15 are all provided. An input selector 51 is also provided to allow a user to switch between the various inputs. The inputs to both the microphone and the auxiliary connector are analog to digital converted by a converter 27 before being passed to the processor. Although not shown, numerous vehicle components and auxiliary components that communicate with the VCS can use a vehicle network (such as, but not limited to, a CAN bus) to pass data to and from the VCS (or components thereof).

[0020] Outputs of the system can include, but are not limited to, the visual display 4 as well as a speaker 13 or stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 through a digital to analog converter 9. Output to a remote Bluetooth device (such as a personal navigation device (PND) 54) or a USB device (such as a vehicle navigation device 60) can also be produced along the bidirectional data streams shown at 19 and 21, respectively.

[0021] In one illustrative embodiment, the system 1 uses the Bluetooth transceiver 15 to communicate (17) with a user's mobile device 53 (e.g., a cell phone, smart phone, PDA, or any other device having a wireless remote network connection). The mobile device can then be used to communicate (59) with a network 61 outside the vehicle 31 through, for example, a communication (55) with a cell tower 57. In some embodiments, the cell tower 57 can be a Wi-Fi access point.

[0022] Exemplary communication between the mobile device and the Bluetooth transceiver is represented by signal 14.

[0023] Pairing the mobile device 53 with the Bluetooth transceiver 15 can be indicated by a button 52 or similar input. Accordingly, the CPU is instructed that the on-board Bluetooth transceiver is to be paired with the Bluetooth transceiver in the mobile device.

[0024] Data can be transferred between the CPU 3 and the network 61 using, for example, a data plan associated with the mobile device 53, on-the-air data, or DTMF tones. Alternatively, it can be desirable to include an on-board modem 63 having an antenna 18 to transfer data (16) between the CPU 3 and the network 61 over the voice band. The mobile device 53 can then be used to communicate (59) with a network 61 outside the vehicle 31 through, for example, a communication (55) with a cell tower 57. In some embodiments, the modem 63 can establish a communication (20) with the cell tower 57 to communicate with the network 61. As a non-limiting example, the modem 63 can be a USB cellular modem and the communication 20 can be a cellular communication.

[0025] In one illustrative embodiment, the processor is provided with an operating system that includes an API (application program interface) for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to accomplish wireless communication with a remote Bluetooth transceiver (such as found in a mobile device). Bluetooth is a subset of the IEEE 802 PAN (personal area network) protocol. The IEEE 802 LAN (local area network) protocol includes Wi-Fi and has considerable overlap with the IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Another means of communication that can be used in this field is free space optical communication (such as IrDA) and non-standardized consumer IR protocols.

[0026] In another embodiment, the mobile device 53 includes a modem for voice band or broadband data communications. In a voice over data embodiment, a technique known as frequency division multiplexing can be implemented when the owner of the mobile device can speak through the device while data is being transmitted. At other times, when the owner is not using the device, the data transmission can use the entire bandwidth (in one example, 300 Hz to 3.4 kHz). Although frequency division multiplexing would be common and still in use for analog cellular communications between a vehicle and the Internet, it has been largely replaced by a mixture of code division multiple access (CDMA), time division multiple access (TDMA), and space division multiple access (SDMA) for digital cellular communications. If the user has a data plan associated with the mobile device that allows broadband transmission and it is feasible for the system to use a much wider bandwidth (speed up data transmission), then in another embodiment, the mobile device 53 is replaced by a cellular communication device (not shown) installed to the vehicle 31. In another embodiment, the mobile device (ND) 53 can be a wireless local area network (LAN) device capable of communicating over, for example, but not limited to, an 802.11g network (i.e., Wi-Fi) or a WiMax network.

[0027] In one embodiment, incoming data can be transmitted through the mobile device, through the on-board Bluetooth transceiver, and into the vehicle's internal processor 3 via voice over data or a data plan. In the case of certain temporary data, for example, the data can be stored on the HDD or other storage medium 7 until the data is no longer needed.

[0028] Other sources that can interact with the vehicle include a personal navigation device 54 with, for example, a USB connection 56 and / or an antenna 58, a vehicle navigation device 60 with a USB 62 or other connection, an on-board GPS device 24, or a remote navigation system (not shown) with a connection to a network 61. USB is one of a class of serial networking protocols. IEEE 1394 (Firewire TM (Apple), i.LINK TM (Sony), and Lynx TM (Texas Instruments)), EIA (Electronic Industries Association) serial protocols, IEEE 1284 (Centronics port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Developer Forum) form the backbone of device-to-device serial standards. Most protocols can be implemented for electrical or optical communications.

[0029] In addition, the CPU can communicate with various other auxiliary devices 65. These devices can be connected by a wireless connection 67 or a wired connection 69. Auxiliary devices 65 can include, but are not limited to, a personal media player, a wireless health device, a portable computer, etc.

[0030] Additionally or alternatively, the CPU can be connected to a vehicle-based wireless router 73 using, for example, a Wi-Fi (IEEE 802.11) transceiver 71. This can allow the CPU to connect to remote networks within range of the local router 73.

[0031] In addition to the exemplary processes being performed by a vehicle computing system located in a vehicle, in particular embodiments, the exemplary processes can also be performed by a computing system in communication with the vehicle computing system. Such systems can include, but are not limited to, a wireless device (such as, but not limited to, a mobile phone) or a remote computing system (such as, but not limited to, a server) connected through the wireless device. Such systems can be collectively referred to as a vehicle-associated computing system (VACS). In particular embodiments, particular components of the VACS can perform particular portions of the processes depending on the particular implementation of the system. By way of example and not limitation, if a process has a step of transmitting or receiving information with a paired wireless device, it is likely that the wireless device does not perform that portion of the process since a wireless device does not "transmit and receive" information with itself. One of ordinary skill in the art will understand when a particular computing system is not appropriate for a given solution.

[0032] In each of the illustrative embodiments discussed herein, an exemplary, non-limiting example of a process that can be performed by a computing system is shown. For each process, it is possible that the computing system performing the process becomes configured as a special purpose processor for the limited purpose of performing the process. All processes need not be performed, and should be understood to be examples of the many types of processes that can be performed to implement elements of the present invention. Additional steps can be added to, or removed from, the exemplary processes as desired.

[0033] For the illustrative embodiments described in the figures showing illustrative process flows, it should be noted that a general purpose processor can be temporarily used as a special purpose processor for the purpose of performing some or all of the exemplary methods shown by these figures. When code providing instructions for performing some or all of the steps of the methods is executed, the processor can be temporarily repurposed as a special purpose processor until the method is complete. In another example, to the extent appropriate, firmware running on a preconfigured processor can cause the processor to act as a special purpose processor provided for the purpose of performing the methods or some reasonable variation of the methods.

[0034] While modern navigation systems include a number of options for identifying construction and traffic accidents in progress, this data is not always updated in real-time and often does not include data regarding the time of delay or length of congestion. Furthermore, this data almost never includes "road in bad condition" data indicating roads that are generally not suitable or appropriate for travel.

[0035] Users can know about such local road conditions (especially, persistent conditions such as common puddles, large potholes, and unpaved sections). Users will simply choose to avoid these sections of local roads, but a navigation system that does not know about the condition can not always consciously avoid these roads. Furthermore, while a user can know about the condition of a road, the user does not always know good options for avoiding, and can drive into a nearby area of a congested road or other inappropriate alternative while trying to avoid an area of interest.

[0036] When a user is not from an area where a condition exists, the user can be even more difficult to avoid the condition. Even before deciding to avoid the condition, the user can encounter the condition at least once, and at this point, it can no longer be possible to avoid initially (e.g., there is no fork for avoiding the condition). In such cases, even if the condition itself does not appear on any map data, routes taken by other local drivers can help indicate that there is a road condition in bad condition.

[0037] By combining crowd-sourcing with observed local driving instructions and actions, illustrative embodiments can delineate areas to avoid with reasonably good accuracy. By observing typical areas to avoid and the size of these areas, a profile of "road in bad condition" road conditions can be built, and while this is essentially a hypothesis about road conditions, in fact, the threshold percentage of a driver's choices to avoid an area (even if it is otherwise the fastest route) often indicates that there is a problem with the area.

[0038] In an illustrative example, a user can mark areas to avoid (e.g., when the user encounters a pothole, the area to avoid can be marked) and a local navigation system can treat these areas to avoid as "non-roads" or otherwise refrain from using the marked areas in any route calculation. This can continue until the user unmarks the road (the road is repaired). In a less user-interactive manner, a vehicle can detect particular bad road conditions and mark these areas on a local map, and recommend avoiding these areas in future navigation. If a user is observed to consistently travel on a marked or recommended area to avoid, the system can "unmark" the area (assuming the problem is determined or the user simply does not care). A navigation system can also use "non-road" marked areas for route navigation if there is no route that does not use the area.

[0039] Figure 2 An illustrative process for route deviation is shown. In this illustrative example, at 201, the process receives instructions to navigate a route around a particular area. Such instructions can be in the form of a selection of an avoid area on a map, can be in the form of a positive response to a detour route recommendation, or can even be in the form of repeated user deviations based on a particular segment of the route being bypassed (even a few consistent deviation instances would likely indicate a problem on a portion of the route). Another example of receiving instructions to deviate around an area would simply be whether the user leaves the route or deviates from the route for more than a particular distance or a particular time.

[0040] At 203, the process receives a distance for the detour route. If the user specified to avoid a particular portion of the map, the distance would be any route that allows reentry as long as the marked area is avoided. In other examples, the distance can be discrete (e.g., avoid the next two miles of the road). In another example, the distance can be based on typical avoidance maneuvers observed from consistent behavior of the user avoiding a portion of the route (e.g., when and where the user typically reenters the initial route).

[0041] The process then, at 205, locally stores a marked version of the map indicating that the area is to be avoided in future navigation. This allows the user to at least avoid the specified area in future route navigation recommendations without the user having to alert the system to avoid the portion or selectively avoid the portion as the route still passes through the portion.

[0042] Further, in this example, at 207, the process uploads the marked portion to a cloud server. This can serve at least two functional purposes. First, this allows the marked data to be provided to a large number of users as part of a crowdsourcing analysis of local road data. This can help other users who can not be familiar with the area to know which roads are avoided by locals.

[0043] Another useful aspect of uploading the data is that the server can compare the marked portion with portions received from other vehicles to determine whether the detour route is inadequate or overly aggressive. That is, if a 2-mile road segment contains a significant number of potholes, and the user only avoids 1.5 miles of the road, the system can use the crowdsourced data to inform the individual user that the need for a detour route is greater (if the potholes are to be avoided). On the other hand, if the user avoids 4 miles of the road and thus takes a slower route, the process can inform the user that only 2 miles of the road needs to be avoided based on observed and indicated behavior from other drivers in the area.

[0044] At 209, the process receives any adjustments or recommendations, and provides the adjustments to the driver. If the driver accepts the suggested adjustment to the detour route at 211, at 213, the process changes the local markers of the map to reflect the improved data. Then at 215, the process can recalculate the route that avoids the particular area. The adjustment capability is especially useful for non-local drivers, who can encounter pothole sections, and can seek a large avoidance area to address a problem that is actually very localized. If the vehicle can detect a pothole or other undesirable road feature, the vehicle can detect one or two potholes in close succession, and based on that evidence, dynamically request a detour route from the cloud without any explicit indication from the driver. The cloud can then collect user observations and indicated behavior from other local drivers to determine whether the portion of the road is frequently avoided and how far it is avoided.

[0045] Notably, the avoidance processing can be done in a completely local manner without reference to crowd-sourced data, if desired. For example, a user can request to avoid a dirt road or construction area, and the local navigation system can treat that portion as impassable (at least for navigation calculation purposes) for a particular amount of time or until the user otherwise indicates.

[0046] Figure 3 An illustrative process for route recommendations is shown. In this example, at 301, the process can receive one or more user-specified areas of marked regions to avoid for a route. These regions can be aggregated as received from vehicles in order to establish a custom model of avoidance regions for any location.

[0047] The process, in addition to modeling the received requested avoidance regions, can also receive data indicating when users stop avoiding (re-enter the road or route). This can help define the "end" of a region, and a sufficiently large data set can be used to define preferred regions for re-entry for users who can not be familiar enough with the avoidance region to accurately specify when to end the avoidance.

[0048] Further, in this example, at 303, the process receives vehicle travel data, which in this example indicates at least where the vehicle intends to re-enter the route. The currently received re-entry points can be based on, for example, the size of the user-specified avoidance region, or can be based on any other reasonable factors adjusted by the user's on-board navigation system.

[0049] At 305, the process compares the current avoidance plan and re-entry point to a known existing profile for the avoidance region. For example, the known existing profile is based on crowd-sourced data collected as discussed above. Other data sources, such as municipal data sources or traffic feeds, can also be used to define the size of a particular avoidance region with some degree of accuracy.

[0050] If at 307 there is a faster option for the avoidance (one that re-enters the route as soon as possible and possibly faster), then at 309 the process can send a recommended change to the vehicle that originally sent the detour route data. This can be an ongoing and dynamic process such that as long as a detour route exists, the received travel data includes the location and speed of the current vehicle. If at 311 the vehicle re-enters the route or resumes speed (depending on what is tracked), or when the vehicle re-enters the route or resumes speed at 311, then at 313 the process can mark the end of the detour. Otherwise, the process continues to receive travel data that can indicate both when the vehicle re-enters the route and whether the re-entry point is actually a suitable re-entry point (based on observed driver behavior after the re-entry).

[0051] The following is an illustrative example using the aforementioned drivers / vehicles A, B, and C. For one or more reasons (such as traffic conditions, road conditions, etc.), all three vehicles attempt to avoid a 2-mile road trip that is currently recorded in the cloud server as a 2-mile trip. The drivers of the three vehicles all witness the traffic and request a detour route, with driver A specifying 1.5 miles, driver B specifying 2.5 miles, and driver C specifying 2 miles.

[0052] Since the cloud has an avoidance region currently set to two miles, the cloud recommends a detour route of only 2 miles for driver A, and the same for driver B. Both drivers accept the recommendation. Driver A arrives at the region first and begins to avoid the region. As driver A is driving, the remote process is receiving travel data of driver A and can update the recommendation (as well as for drivers B and C).

[0053] Driver A re-enters the initial route after 2 miles and encounters another 0.2 miles of other traffic. Thus (and possibly based on more than one simple data instance), the remote process can update the size of the avoidance region to 2.2 miles. Since communication with drivers B and C is still ongoing, the process can dynamically recommend a change to route B and route C such that 2.2 miles are currently avoided. Driver B does not accept the change, while driver C accepts the change.

[0054] Driver B (next to take the detour) actually re-enters the original route at 1.7 miles, choosing to use the locally displayed map to calculate how to re-enter the route as quickly as possible. After re-entering, Driver B does not encounter traffic at this time, or at any other time along the route. The remote processing now updates the size of the avoidance zone and sends another recommendation to Driver C.

[0055] This example shows how the zone is dynamically adjusted as the vehicles travel and how the communication generally improves the driving experience. If the same three vehicles travel the same route the next day, with the expectation of continuing to avoid (and where the previous avoidance reason was related to a continuing condition such as road status), the three vehicles will have local data sets corresponding to the size of the zone last received (2 miles for Driver A, 1.7 miles for Driver B, and 1.7 miles for Driver C). While the size of the traffic delay can not coincide with the daily obstacle, a similar concept can be used for poor driving conditions on a road trip that can last for some time.

[0056] In some cases, it can not be possible to determine a particularly precise end point based on the re-entry of the route, as conditions such as potholes can not be consistently detected in some vehicles, or even at all. Thus, in some cases, with sufficient data, it can be possible to determine the size of a stretch of road with consistently poor conditions based on the range of points at which people request re-routing. In these examples, the processing "assumes" that when a significant portion of the damaged or poor road still exists, people request re-routing, so the trailing data point (the farthest point along the stretch of road where re-routing was requested) tends to indicate an "end point" beyond which the road is no longer poor enough to warrant re-routing. By using this data analysis, a reasonably accurate model of at least the worst portion of the stretch of road with poor road conditions can be determined and constructed.

[0057] For example, it is also possible to receive or determine certain conditions associated with a road trip based on various data. A clear identification of the condition will provide the most accurate data, but, for example, if all vehicles except SUVs (Sport Utility Vehicles) avoid a portion of a road, the condition can be related to a condition that is not suitable for standard vehicles (but is suitable for SUVs). In another example, low-hanging tree branches on a route can cause drivers of all SUVs and trucks (but not regular vehicles) to avoid the route. While it can not be possible to pinpoint the problem without additional data, even data such as this can be used to tailor recommendations for vehicle categories. Additional data (additional data from cameras, radar, lidar, etc.) can be used to more accurately model the actual conditions experienced.

[0058] Figure 4 An illustrative process for route calculation is shown. In this example, at 401, the process receives a destination input or a calculated route. Here, it is considered that a route already exists, but if the process receives a destination, a similar process can be performed during route formation by using a "preferred" route without detours as a base route.

[0059] At 403, the process checks the route to see if it includes any marked avoidance areas (e.g., user marked or crowd-sourced avoidance areas) at 405. If there are marked areas, at 409, the process can treat these areas as "non-road" or impassable road, and at 411, the process re-calculates the route. At 407, the process can then present the route to the user.

[0060] In an alternative approach, a navigation route calculator determining an initial route can treat any marked areas as simply roadless areas or impassable areas, so the initial route can reflect the desired, persistent avoidance areas.

[0061] Since there can be a case where a route becomes impassable without including at least one avoidance area, or a route becomes too convoluted (such as deviating from a preferred avoidance-free route by more than a threshold time or threshold distance), the process can always "turn off" some or all of the avoidance portions in order to determine at least one passable route to the destination that falls within acceptable parameters or specified parameters (time / distance / fuel / etc.).

[0062] In other examples, the driver can specify what type of persistent conditions (pits, puddles, low-hanging trees, etc.) should be avoided, and then the vehicle can request data identifying these conditions in the local area to use in formulating directions within the local area. This data is also updated as the vehicle travels, so that it can be presented in an updated and on-demand fashion when the driver needs it.

[0063] Illustrative embodiments allow users to specify and continuously avoid particular roads with data that is improved by crowdsourcing for these users and provided in a similar fashion to less experienced users.

[0064] While the foregoing describes exemplary embodiments, these embodiments are not intended to describe all possible forms of the application. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes can be made without departing from the spirit and scope of the application. Additionally, the features of various implementing embodiments can be combined in logical combinations to produce variations suitable for the intended context of the embodiments described herein.

Claims

1. A system for navigation adjustments, comprising: a processor configured to: receive an instruction to avoid a road segment marked by a user on a local map and selected to be avoided; send the user-selected road segment to a remote server; in response to the sending, receive an updated recommendation from the remote server related to the distance of the user-selected road segment, the updated recommendation comprising adjusting the distance of the user-selected road segment based on crowd-sourced data indicating distances other drivers avoid for the user-selected road segment to create an updated road segment to be avoided; compute a route that avoids the updated road segment to be avoided.

2. The system of claim 1, wherein, the instruction comprises an explicit selection of a map portion displayed in a vehicle for avoidance.

3. The system of claim 1, wherein, the instruction is received automatically in response to detecting a predefined adverse driving condition based on driving conditions sensed by the vehicle.

4. The system of claim 1, wherein, the processor is further configured to receive a reason for the avoidance and include the reason in the sending.

5. The system of claim 4, wherein, the processor is further configured to receive the reason as a user input.

6. The system of claim 4, wherein, the processor is further configured to determine a candidate reason as the reason based on vehicle sensor data.

7. The system of claim 1, wherein, the processor is further configured to save the user-selected road segment and avoidance reason in local memory for future route computation use.

8. The system of claim 1, wherein, the processor is further configured to save the updated road segment to be avoided based on the updated recommendation in local memory for future route computation use.

9. A system for navigation adjustments, comprising: a processor configured to: receive a destination; retrieve a user-specified avoidance area from local memory, the avoidance area defining a road segment marked by a user on a local map and specified to be avoided; send the avoidance area to a remote system; receive an updated version of the avoidance area from the remote system, the updated version comprising adjusting a size of the avoidance area based on crowd-sourced data indicating sizes specified by other drivers for the avoidance area to create an updated avoidance area; compute a route to the destination, the route to the destination treating the updated avoidance area as an impassable road segment for route computation purposes; present the computed route.

10. The system of claim 9, wherein, the processor is further configured to save the updated version of the avoidance area.

11. The system of claim 9, wherein, the processor is further configured to determine that no route exists to the destination and in response treat at least one avoidance area as drivable for route computation purposes.

12. The system of claim 9, wherein, the processor is further configured to determine that no route exists to the destination within a specified time or a specified distance from a route that does not include an avoidance area and in response treat at least one avoidance area as drivable for route computation purposes.

Images