Patent Application
20180216952
Vehicle crashes continue to occur throughout the world. The present discussion offers solutions to reduce the number of vehicle crashes.
The accompanying drawings illustrate implementations of the concepts conveyed in the present patent. Features of the illustrated implementations can be more readily understood by reference to the following description taken in conjunction with the accompanying drawings. Like reference numbers in the various drawings are used wherever feasible to indicate like elements. In some cases parentheticals are utilized after a reference number to distinguish like elements. Use of the reference number without the associated parenthetical is generic to the element. Further, the left-most numeral of each reference number conveys the figure and associated discussion where the reference number is first introduced.
Vehicle crashes account for over one million fatalities and many more million injuries annually worldwide. Some roads are safer than others, so a driving route (e.g., road route or route) that is optimized for safety may reduce the number of crashes. Further, a route that considers safety in combination with other parameters can reduce the number of crashes. The present concepts can estimate the probability of a crash on any road segment as a function of various parameters, such as traffic volume, road characteristics, and/or environmental conditions, among others. Possible routes between a starting point and a destination point can be identified. The safety of the routes can be determined and compared to select a relatively safe route. In some cases, route selection can include other parameters, such as time. The concepts can smoothly trade off safety for time, giving several different route options with different crash probabilities and durations (e.g., travel times) between the two points.
Introductory
The present implementations can identify the safety of individual routes. For instance, route 112(1) (dotted line) can be the safest route between the starting point 106 and the destination point 108. The present implementations can also identify routes based upon other parameters. For instance, route 112(2) (dashed line) can be the fastest route. The present implementations can also identify routes that consider safety as a parameter in combination with other parameters. For instance, route 112(3) (alternating dots and dashes) can balance safety and time parameters. Qualitatively, route 112(3) is almost as fast as route 112(2) and almost as safe as route 112(1). Quantitative calculations relating to route safety are described below relative to the heading “Crash Probability on Route.” Note that while routes are distinguished in the illustrated example via line pattern, other implementations can use other indicia. For instance, the fastest route could be shown in green, the safest route in red and the compromise route in amber/yellow, among other configurations.
In light of the above discussion, in some implementations, map 100 can be an example graphical user interface (GUI) 114 that can be presented to a user to convey route safety information. Other types of GUIs can be generated for, and/or presented to, the user. For instance, a GUI can be presented that allows the user to assign relative weights to different parameters (e.g., rank safety higher than time or rank time higher than safety). These ranking can then be utilized to generate the routes presented on the map 100.
At block 204 the method can calculate crash probabilities for road segments in the geographic region. In one case, the crash information relating to locations within the geographic location can be correlated to a map of roads in the geographic region to identify crashes along specific road segments. Crash probabilities for the road segments can be calculated for the present time (e.g., the time at which the travel from the starting point to the destination point is expected to occur) from the obtained crash information relating to the road segments. A specific example of calculating crash probabilities for road segments is described in more detail below relative to the heading “Individual Crash Probability on Road Segment.”
At 206 the method can generate route information between a starting point and a destination point in the geographic region that reflects the crash probabilities of at least some of the road segments. The route information can pertain to routes solely on the basis of safety (e.g., which routes are safer (and potentially safest)). An example is described above relative to
As mentioned above, data on crashes and vehicle counts for a geographic region can be used to assess the probability of a crash along a route. An example geographic region for which data is available is Minneapolis, Minn. A convenient source of both crash and vehicle count data is the Traffic Data Management System of the City of Minneapolis, Minn., USA (Minneapolis). The source provided data on 15,401 vehicle crashes spanning from Jan. 1, 2013 to Jun. 30, 2015 (30 months). Since the reporting entity is the city of Minneapolis, the data does not include crashes on federal highways passing through the city, and thus federal highways are not considered in the computed routes relating to this example data.
The data available from the Minneapolis source includes hourly vehicle count data from 939 different roads over years 2012-2015. Significantly, the data does not come with an absolute date for the counts. The counts are reported as the number of vehicles traversing the road over the given hour on a given day of the week.
The final piece of input data for the geographic region can be a routable road network from a mapping database, such as the Bing® Maps database (Microsoft Corp.), Google Maps (Alphabet Inc.), etc. Connectivity can be represented as a directed graph, with intersections as vertices and road segments as edges between the vertices. In this example, each crash and traffic count can be matched to the geographically nearest road from the mapping database.
The crash probability of a road segment can be estimated by first interpolating to infer the hourly vehicle count and then classifying to infer the crash probability.
For a given date/time on a road segment, the hourly vehicle count can be estimated. This estimated hourly vehicle count can first be used as a parameter to estimate crash risk, where it has proven to be an important feature (and potentially most important) among the various parameters considered. This estimated hourly vehicle count can also be used as part of the arithmetic to compute a crash probability: if a road segment will host one crash and N vehicles in an hour, then each vehicle on that road segment has a 1/N chance of crashing over that hour.
Due to the spatial sparsity of vehicle count sources, the road segment in question may not have a vehicle count measurement. However, if a traffic count estimate is desired for a date/time on a road segment that has been measured, the count from the traffic count data can be queried. The query can first look for a count taken in the year nearest the given date/time. Given this, the process can then look for a count in that year taken on the nearest day of week. (Recall that the traffic count data in this example does not come with absolute dates, just a year and a day of week). With this nearest year and day of week, the process can then look up the traffic count for the desired hour.
Often the road segment in question does not have a vehicle count measurement, and the hourly traffic count can be estimated on a road where the traffic count has not been measured. This can be treated as an interpolation problem, because the estimate can be made using traffic counts from roads that are nearby in space and time. Mathematically it is a regression problem, where the dependent variable/parameter is the desired traffic count, and the independent variables are features including nearby traffic counts. In this example, there are 65 independent variables in the regression function. Five of the independent variables characterize the date/time and the road segment in question: hour of day, day of week, road type from {major road, arterial, street}, number of lanes, and speed limit. Other and/or additional variables/parameters can be considered in other implementations.
Independent variables from nearby roads that have measured vehicle counts can also be considered. Specifically, the nearest five measured roads for each road type in {major road, arterial, street} can be considered, giving data on 15 total nearby roads. In this example, for each of these 15 roads, the independent variables are:
Thus, the total number of independent variables for the regression function is 65, in this example. The dependent variable to estimate is the hourly traffic count on the road segment in question for the specified date/time.
In this example, the regression function can be a boosted forest of decision trees. In some cases, parameters can be examined and/or ranked for predictive value. For instance, parameters for the learning rate and forest parameters can be examined to find the most accurate function in terms of I1 error. In this case the optimal forest consisted of 500 trees with 74 leaves per tree and a minimum of 10 instances in each leaf. The estimates can be tested by using the learned regression function to estimate traffic counts on roads that have actual traffic count measurements. Specifically, for each measured road segment, the actual vehicle count can be extracted for each hour from our data. Using ten-fold cross validation, regression estimates can be recorded for each measured instance. The results are shown in
With this regression function in place, a vehicle count estimate can be computed for any road segment in the region for any given date/time.
A crash occurrence classifier can be created that identifies the risk of a crash based on the crash data. The crash occurrence classifier can be trained with positive examples from the crash data and negative examples generated randomly and uniformly in space and time. Each example can be an hour-long instance on a road segment that either did or did not host a crash. The positive examples are simply the 15,401 crashes in the data, with the date/time truncated to the previous integer hour and the location represented as the nearest road segment. In this case, it was rare to have more than one crash on the same road segment during the same hour, so all the crash examples implicitly represent a single reported crash incident. An equal number of negative crash examples can be generated in hour-long intervals and road segments that were not reported as crash occurrences. Some crashes go unreported, so there may have been some false negatives in the training data.
In this implementation, the crash occurrence classifier is based on a set of 29 features from each example, outlined below.
Vehicle Count: Vehicle count estimate from interpolation;
Date/Time: Day of week, hour of day;
Road Segment Layout: Road type from {major road, arterial, street}, number of lanes, speed limit, divider (binary), length of road segment, mean slope of road segment, minimum, maximum & mean radii of curvature;
Sun Angle: Sun above or below horizon (binary), elevation, azimuth, subtended angles between azimuth and road heading (sum to 180 degrees);
Weather: Temperature, wind speed, snow depth, visibility (miles), cloud ceiling (feet), precipitation in last hour, last 6 hours, and last 24 hours;
Nearby Structures: Number and density of residences along road segment, number and density of businesses along road segment.
Most of these features are self-explanatory. In this example, the road segment layout features, residences, and businesses came from a mapping database, such as Bing Maps road database. The features involving the sun's azimuth angle indicate the propensity for sun glare in the driver's eyes. Weather features for the Minneapolis, Minn. area were obtained from the National Oceanic and Atmospheric Administration which gives recorded weather conditions in approximately one-hour increments.
Given the features, an instance can be classified as either a crash or not. As with the regression function above, a boosted forest of decision trees can be employed, but for classification instead of regression. Different parameters can be swept with 10-fold cross validation. One example utilized a forest of 500 trees, 296 leaves per tree, and a minimum of 1 instance in each leaf.
Ten-fold cross validation gave an overall classification accuracy of 78.4%. Positive precision and recall were 79% and 77.5%, respectively, and negative precision and recall were 77.9% and 79.4%. The results are shown in
The crash occurrence classifier can estimate the relative risk of a crash occurring on each road segment for a given hour. This section describes how the crash probability can first be computed for an individual traversing a road segment and then how the probability of a crash can be computed over a trip traversing multiple road segments.
The probability pi of a single vehicle crashing on a road segment i over a given hour can be computed. From the crash occurrence classifier above, a class probability ci can be obtained that predicts crash risk given environmental features over the hour in question. This class probability pertains to the occurrence of a crash among all the vehicles on the road segment over the hour. In that hour, there are vi vehicles traversing the road segment, where vi comes from the interpolation estimate described previously. With pi and vi for the relevant hour, the class probability for any individual vehicle crash in that hour is ci′=ci,/vi.
Neither the class probability ci, nor the individual class probability ci′, are calibrated to consider the overall expected number of crashes in the entire region, i.e. the city of Minneapolis in this case. Both can have an unrealistically inflated view of crash occurrences, because the crash occurrence classifier was trained on an equal number of positive and negative crash examples. In actuality, there are far fewer positive instances of crashes than negative instances. Thus, these class probabilities can be calibrated by scaling, such that the expected number of crashes over all the region's road segments is the same as the historical number of crashes over the given hour. The scale factor is ρ, and the calibrated probability of a single vehicle crashing is pi=ρi′. If A is the random variable representing the total number of hourly crashes in the region over an hour-long period, and E[A]=a, then
Here S is the total number of road segments in the region. Equation (1) provides ρ=a/Σi=1Sci′. This scaling by ρ can ensure that the total number of predicted crashes matches the historical number of crashes, a, in the given hour. In this formulation, “a” is the mean number of crashes observed on the day of week and hour of day corresponding to the hour in question.
In numerical terms, the crash occurrence classifier can produce class probabilities ci in the range [0,1]. Hourly road counts vi are typically O(100), giving ci′=ci,/vi a typical range of [0,O(0.01)]. Calibrating with pi=ρci′ gives individual crash probabilities of roughly [0,O(10−6)].
As mentioned above relative to
The crash probability pR of a route can be modeled as a set of independent Bernoulli trials, with one trial for each road segment. The probability of traversing a single road segment i without crashing is 1−pi. The probability of traversing the entire route R without crashing is then Πi∈R(1−pi). Finally, the probability of crashing anywhere along the route is then
An alternative expression for the probability of not crashing on road segment i comes from the Poisson distribution. pi can be interpreted as the average number of crashes per the length of road segment i. The Poisson distribution says the probability of having k crashes on the road segment is then
Given this, the probability of experiencing no crash along the road segment is
P(0)=e−p
This is an alternative to the above formulation which says the probability of not crashing on a road segment is 1−p1. For small values of pi, the following equation can be employed: 1−pi≅e−p
Route Length Vs. Safety Tradeoff
Intuitively, a safe route could be one that tediously weaves a long path around unsafe road segments. However, even with smaller crash probabilities, a longer route with more road segments can lead to potentially more crash exposure. The Bernoulli probabilities make it easy to analyze this tradeoff. As a simple example, suppose that a shorter route consists of nshort road segments, each with an equal crash probability of pshort. From Equation (2), the probability of experiencing a crash on this route is ps=1−(1−pshort)n
Setting ps=pl gives the equivalence point where the two routes are equally safe:
1−(1−pshort)n
For a given value of pshort, values of γ and s can be computed that satisfy this equation. Plotted as ordered pairs (γ, s), points on the lower left side of this curve indicate the longer route is safer. Values on the other side indicate the shorter route is safer. This is illustrated for several values of pshort in
For purposes of explanation, the case with pshort=10−6, which pertains to the left-most curve in
Driving routes are often computed by minimizing a sum of costs. For computing safe routes, the probability of a crash can be used as the cost to minimize. From the Bernoulli trials formulation, the probability of a crash along a route is given by Equation (2). Even though this is not a sum, even in log space, a simple Dijkstra algorithm can still be used to compute safer (and potentially the safest) routes. An alternative algorithm could employ an A* search.
More specifically, Dijkstra's algorithm maintains a list that gives the minimum cost for traveling to each “visited” node. Normally these costs are simply the sum of individual edge costs leading to that node. In present implementations, these costs are instead the partial route crash probabilities computed from Equation (2). For computational efficiency and numerical stability, a parallel list can be maintained that gives Σ log(1−pi) for the partial route to each visited node.
For purposes of explanation, 100 arbitrary start and end pair locations were picked in the study geographic region (e.g., Minneapolis) for testing. The fastest and safest routes can be computed for these start and end pair locations. The fastest (e.g., shortest time) route used only the lengths and speed limits of the road segments to estimate traversal time. Note that in this example the fastest route computation did not account for turns, traffic lights, traffic congestion, or other delays. Thus, they are independent of the time of day.
The hours of 4 a.m., 8 a.m., and 6 p.m. on Tuesday, Jan. 20, 2015, were examined to demonstrate the results. For each time of day, Table 1 shows the mean driving times and mean crash probabilities for the 100 test routes. Table 1 also shows the relative multiples between the driving times and crash probabilities between the fastest and safest routes. On average, the safest route takes 1.69 times as long to drive and has 0.53 times the crash probability, illustrating the tradeoff between driving time and safety. The mean crash probability of the fastest routes is 8.9×10−6, and the mean crash probability of the safest routes is 4.6×10−6.
It is possible to find routes that are between the safest and fastest, incurring a certain driving time penalty for a certain safety benefit. These multi-parameter or ‘balanced’ routes can be computed by using a cost function that includes both driving time and crash probability. Specifically, the cost function can be represented as
Here pR is the crash probability along a route whose edge indices are in set R, as given by Equation (2). The Ti are the costs of the route's edges in terms of driving time, and they sum in the usual way. The variable 0≤α≤1 is a blending parameter that controls the tradeoff between crash probability and driving time. Note also that the driving time part of the cost function could be any available cost function, including those that take into account delays due to traffic, turns, and other factors.
Alternatively, a cost function of the form below can be employed:
This is similar to the previous cost function, but with the added parameter β. β is an optional parameter that helps equalize the numerical magnitude of pR and Σi∈RTi. The crash probability pR is usually O(10−5) or (10−6), and the driving time in seconds is usually O(102) or O(103). Without) β, the driving time can dominate for almost the whole range of α. If this technique sets β=Σi∈R Ti/pR, then the full range of a has a better chance of producing different routes. However, the method still holds for β=1.
The cost function in Equation (4) can be used to compute routes for the endpoints shown in
The discussion has shown how to use recorded data from vehicle crashes and vehicle counts to compute the probability of a crash along a driving route. This can involve estimating hourly traffic counts on unmeasured roads using a learned regression function and estimating crash risk as a function of environmental conditions using a crash occurrence classifier. The discussion showed how to use results from the crash occurrence classifier to estimate Bernoulli crash probabilities along segments of road and how to combine these probabilities to compute the crash probability of a route. These crash probabilities can be used in a Dijkstra algorithm to compute the safest route between two points as well as find compromise routes that trade off driving time for safety. Some implementations can employ a routing application that presents a user with this tradeoff, giving the driver the flexibility to make the tradeoff explicitly along with the knowledge of how their choice affects their safety. The route safety consideration can also be utilized in autonomous driving scenarios. Further, at such a time as adoption of route safety is high enough to affect traffic flows, dynamic balancing could be performed. For instance, if two routes each satisfy the user's safety preferences, but one route is congested and the other is not, the latter route could be suggested for the user over the former.
In the detailed example described above relating to Minneapolis, the crash information was limited. Results obtained from the present implementations could be improved with richer crash details. The severity of each crash and the number of vehicles involved would help refine the crash probability computations. Similarly, if the crash information explicitly stated which crashes occurred in the act of turning a corner, turn safety could be incorporated into the crash probability cost.
At block 702, the method can obtain crash information relating to a geographic region. In some cases, the crash information can be obtained by accessing a database populated by a transportation entity, a police entity, an emergency medical services entity, and/or an insurance entity. For instance, the database may be accessible at a website.
At block 704, the method can acquire routes between two points in the geographic region. In some cases, the routes can be acquired from a mapping entity. In other cases, the routes can be generated from information relating to the geographic region.
At block 706, the method can calculate crash probabilities for segments of the routes. In some cases, the calculating can consider past crash data, crash severity, weather conditions, and/or sun angle, among other parameters.
At block 708, the method can determine crash probabilities for individual routes based upon crash probabilities of individual segments of the individual routes. In some cases, the relative crash probabilities for individual routes can be determined by identifying a sum of the individual segments of the individual routes.
At block 710, the method can cause route information to be presented for a user planning to travel between the two points. The route information reflects the crash probabilities for at least some of the individual routes. In some cases the route information can be made available on a website or cloud-based service which can be accessed via a device, such as a user device. For instance, an app on the user's device may operate cooperatively with the cloud-based service. The cloud-based service can generate the routes which can be sent to the user's device and then the device can present the routes to the user.
The route information can be presented on a graphical user interface (GUI) on the user's device, such as in the form or a map and/or driving instructions. In one implementation, the GUI can show an individual route having a relatively low crash probability or the GUI can show multiple individual routes and convey relative crash probabilities of the multiple individual routes. The multiple individual routes can consider crash probability as a parameter and each route of the multiple individual routes can reflect multiple parameters. In some cases the parameters can be weighted equally. In other cases the multiple parameters can be weighted differently in different individual routes. For instance, an individual route could be shown that weights time (of travel) higher than safety, while another individual route weights safety higher than time. The weights could be determined automatically and/or the weights can be selected and/or adjusted by the user.
At block 802, method 800 can obtain crash probabilities for road routes for driving between two points. In some cases, the crash probabilities can be calculated for the routes from crash probabilities of road segments of the road routes. In other cases, the crash probabilities can be obtained for the road routes from a database or a website.
At block 804, the method can present multiple individual road routes that reflect both crash probabilities and estimated times between the two points. In some cases, the multiple individual road routes can be presented in different colors that reflect a relative safety of the individual road routes.
At block 806, the method can receive an indication that a user selected an individual one of the multiple individual road routes. For instance, the user may click on one of the presented routes.
At block 808, the method can provide driving instructions for the selected individual one of the multiple individual road routes to aid the user in reaching the destination.
The described methods can be performed by the systems and/or elements described above and/or below, and/or by other devices and/or systems. For instance, in one case, an entity, such as an automobile insurance provider may have an app that runs on the user's device (e.g., smartphone or the car itself). The app may track the user's location, weather conditions, etc. If the user enters a request for a route between two points and/or the provider identifies that the user is traveling between two points (e.g., work and home) the provider may offer routes on the device that consider safety. In some cases, the provider may offer incentives if the user travels suggested safe routes. In another case, the user may subscribe to a driving app on his/her device or car that provides routes between locations. The app may operate cooperatively with cloud-based resources to access crash info that can be used to identify routes for the user that reflect relative safety. Alternatively, an entity, such as a road department or an emergency service provider may calculate and/or utilize route safety as a tool to influence where to allocate resources (e.g., which roads to improve with existing budget dollars to make them safer or where to place a tow truck, ambulance, or fire station).
The order in which the methods are described is not intended to be construed as a limitation, and any number of the described acts can be combined in any order to implement the method, or an alternate method. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof, such that a device can implement the method. In one case, the method is stored on one or more computer-readable storage medium/media as a set of instructions (e.g., computer-readable instructions or computer-executable instructions) such that execution by a processor of a computing device causes the computing device to perform the method.
In either configuration 910, the device can include storage/memory 924, a processor 926, a battery (or other power source) 928, a communication component 930, and/or a route safety component (RSC) 932. The route safety component can include an instance of a crash occurrence classifier 934 (introduced but not designated above). The route safety component can also include and/or access crash information. In this case, the crash information is included in a crash database that can be accessed via a website. In some cases, the route safety component 932 can be part of, or work cooperatively with, a mapping entity/service, such as a driving app, that can exist on a client device and/or on the cloud-based resources 906. The route safety component can coordinate these aspects to produce route crash information for the user, such as in the form of a GUI (114,
In some configurations, each of devices 902 can have an instance of the route safety component 932. However, the functionalities that can be performed by individual route safety components 932 may be the same or they may be different from one another. For instance, in some cases, each device's route safety component can be robust and provide all functionality described above and below (e.g., a device-centric implementation). In other cases, some devices can employ a less robust instance of the route safety component that relies on some functionality to be performed remotely (e.g., an app-centric implementation that relies on remote (e.g., cloud) processing).
The term “device,” “computer,” or “computing device” as used herein can mean any type of device that has some amount of processing capability and/or storage capability. Processing capability can be provided by one or more processors that can execute data in the form of computer-readable instructions to provide a functionality. Data, such as computer-readable instructions and/or user-related data, can be stored on storage, such as storage that can be internal or external to the device. The storage can include any one or more of volatile or non-volatile memory, hard drives, flash storage devices, and/or optical storage devices (e.g., CDs, DVDs etc.), remote storage (e.g., cloud-based storage), among others. As used herein, the term “computer-readable media” can include signals. In contrast, the term “computer-readable storage media” excludes signals. Computer-readable storage media includes “computer-readable storage devices.” Examples of computer-readable storage devices include volatile storage media, such as RAM, and non-volatile storage media, such as hard drives, optical discs, and flash memory, among others.
Examples of devices 902 can include traditional computing devices, such as personal computers, desktop computers, servers, notebook computers, cell phones, smart phones, personal digital assistants, pad type computers, mobile computers, cameras, appliances, smart devices, IoT devices, vehicles, etc. and/or any of a myriad of ever-evolving or yet to be developed types of computing devices.
As mentioned above, configuration 910(2) can be thought of as a system on a chip (SOC) type design. In such a case, functionality provided by the device can be integrated on a single SOC or multiple coupled SOCs. One or more processors 926 can be configured to coordinate with shared resources 918, such as memory/storage 924, etc., and/or one or more dedicated resources 920, such as hardware blocks configured to perform certain specific functionality. Thus, the term “processor” as used herein can also refer to central processing units (CPUs), graphical processing units (GPUs), controllers, microcontrollers, processor cores, or other types of processing devices.
Generally, any of the functions described herein can be implemented using software, firmware, hardware (e.g., fixed-logic circuitry), or a combination of these implementations. The term “component” as used herein generally represents software, firmware, hardware, whole devices or networks, or a combination thereof. In the case of a software implementation, for instance, these may represent program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer-readable memory devices, such as computer-readable storage media. The features and techniques of the component are platform-independent, meaning that they may be implemented on a variety of commercial computing platforms having a variety of processing configurations.
Various examples are described above. Additional examples are described below. One example includes at least one computer-readable storage medium having instructions stored thereon that, when executed by a computing device, cause the computing device to perform acts, comprising obtaining crash information relating to a geographic region, acquiring routes between two points in the geographic region, and calculating crash probabilities for segments of the routes. The acts further comprise determining crash probabilities for individual routes based upon crash probabilities of individual segments of the individual routes, and causing route information to be presented for a user planning to travel between the two points, the route information reflecting the crash probabilities for at least some of the individual routes.
Another example can include any of the above and/or below examples where the obtaining crash information comprises accessing a database populated by a transportation entity, a police entity, an emergency medical services entity, a driving application entity, a mapping entity, and/or an insurance entity.
Another example can include any of the above and/or below examples where the acquiring routes comprises generating the routes or acquiring the routes from a mapping entity.
Another example can include any of the above and/or below examples where the calculating crash probabilities considers past crash data, crash severity, weather conditions, and/or sun angle.
Another example can include any of the above and/or below examples where the determining relative crash probabilities for individual routes comprises identifying a sum of the individual segments of the individual routes.
Another example can include any of the above and/or below examples where the causing route information to be presented comprises presenting a graphical user interface (GUI) on a user device.
Another example can include any of the above and/or below examples where the GUI shows an individual route having a relatively low crash probability.
Another example can include any of the above and/or below examples where the GUI shows multiple individual routes and conveys relative crash probabilities of the multiple individual routes.
Another example can include any of the above and/or below examples where the multiple individual routes consider crash probability as a parameter, and each route of the multiple individual routes reflects multiple parameters, and where the multiple parameters are weighted differently in different individual routes.
Another example can include any of the above and/or below examples where a first individual route of the multiple individual routes weights crash probability higher than time, and a second individual route of the multiple individual routes weights time higher than crash probability.
Another example can include any of the above and/or below examples where the causing route information to be presented comprises sending the route information to a user device.
Another example can include any of the above and/or below examples where the causing route information to be presented comprises making the route information available on a website.
Another example can include any of the above and/or below examples where the causing route information to be presented comprises making the route information available on a cloud-based service.
Another example can include a method comprising obtaining crash probabilities for road routes for driving between two points, presenting multiple individual road routes that reflect both crash probabilities and estimated times between the two points, receiving an indication that a user selected an individual one of the multiple individual road routes, and providing driving instructions for the selected individual one of the multiple individual road routes.
Another example can include any of the above and/or below examples where the obtaining comprises calculating the crash probabilities for the road routes from crash probabilities of road segments of the road routes.
Another example can include any of the above and/or below examples where the obtaining comprises obtaining the crash probabilities for the road routes from a database or a website.
Another example can include any of the above and/or below examples where the presenting comprises presenting the multiple individual road routes in different colors that reflect a relative safety.
Another example can include a system comprising storage storing computer-executable instructions for obtaining crash information relating to a geographic region, calculating crash probabilities for road segments in the geographic region using the crash information, and generating route information between a starting point and a destination point in the geographic region that reflects the crash probabilities of at least some of the road segments. The system further comprises a processing device that executes the computer-executable instructions.
Another example can include any of the above and/or below examples where the system is embodied on a user device.
Another example can include any of the above and/or below examples where the system is embodied on cloud-based resources.
Although the subject matter relating to route safety has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
