U.S. patent application number 16/891104 was filed with the patent office on 2020-11-05 for method and a computer system for providing a route or a route duration for a journey from a source location to a target location.
The applicant listed for this patent is Grzegorz Malewicz. Invention is credited to Grzegorz Malewicz.
Application Number | 20200348141 16/891104 |
Document ID | / |
Family ID | 1000004902658 |
Filed Date | 2020-11-05 |
View All Diagrams
United States Patent
Application |
20200348141 |
Kind Code |
A1 |
Malewicz; Grzegorz |
November 5, 2020 |
Method and a Computer System for Providing a Route or a Route
Duration for a Journey from a Source Location to a Target
Location
Abstract
Embodiments relate to producing a plan of a route in a
transportation system. The method receives route requirements,
including a starting and an ending locations. The method builds a
model of the transportation system from data about vehicles. The
model abstracts a "prospect travel" between two locations using any
of a range of choices of vehicles and walks that can transport
between the two locations. Given anticipated wait durations for the
vehicles and their ride durations, the method determines an
expected minimum travel duration using any of these choices. The
method combines the expectations for various locations in a
scalable manner. As a result, a route plan that achieves a shortest
expected travel duration, and meets other requirements, is computed
for one of the largest metropolitan areas in existence today. Other
embodiments include a computer system and a product service that
implement the method.
Inventors: |
Malewicz; Grzegorz; (Kielce,
PL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Malewicz; Grzegorz |
Kielce |
|
PL |
|
|
Family ID: |
1000004902658 |
Appl. No.: |
16/891104 |
Filed: |
June 3, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16180050 |
Nov 5, 2018 |
10712162 |
|
|
16891104 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 10/047 20130101;
G01C 21/343 20130101; G01C 21/3423 20130101 |
International
Class: |
G01C 21/34 20060101
G01C021/34; G06Q 10/04 20060101 G06Q010/04 |
Claims
1. A for providing a or a for a journey from a to a , the
comprising: (a) receiving a comprising the and the ; (b) the or the
; and (c) responding to the with information obtained using the or
the ; the characterized by the comprising: (d) determining ,
wherein each travel duration: i. is a , and ii. describes a
duration of travel from the to the ; and (e) using to determine the
or the .
2. The method of claim 1, wherein a first travel duration and a
second travel duration that are included in the describe travel by
two different , wherein routes of the , overlap by at least a
threshold.
3. The method of claim 1 wherein the is non-trivial.
4. A for providing a or a a journey from a to a , the method
comprising: (a) receiving a comprising the source and the ; (b) the
or the ; and (c) responding to the request with information
obtained using the or the ; the characterized by the comprising:
(d) determining a between a graph vertex within a first threshold
distance from the , and a graph vertex within a second threshold
distance from the , wherein the is included in a graph comprising:
i. a including at least two graph vertices that represent vehicle
stops, and ii. a including at least two graph edges that represent
vehicle travel durations; wherein the includes , wherein each :
iii. is included in the , and iv. leads from an of the to a of the
, both vertices included in the ; (e) determining , wherein each
travel duration: i. is a , and ii. describes a duration of travel
from a location of the to a location of the ; and (f) using the to
determine a duration of travel of the .
5. The method of claim 4, wherein the includes two graph prospect
edges.
6. The method of claim 4, wherein the is non-trivial.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of application:
TABLE-US-00001 [Country] [Application Number] [Filing Date] USA
62/180,050 Nov. 5, 2018
which is incorporated herein by reference.
BACKGROUND OF THE INVENTION
[0002] The present invention relates to route planning in a
metropolitan area. A goal of route planning is to determine how to
travel from one location to other location using the vehicles
available from various providers of transport services. Often it is
required for the travel to last as little time as possible, or
depart at a certain time, among other requirements. A route
typically specifies instructions for a rider, including walk paths
and vehicle ride paths.
BRIEF SUMMARY OF THE INVENTION
[0003] Embodiments include a method for computing routes, a
computer system that implements and executes the method, and a
computer service product that allows users to issue routing queries
and receive routes as answers.
[0004] According to an embodiment of the present invention, a
method for generating a route plan is provided. The method receives
a query in a form of a source and a target locations of a route,
and other requirements that may include a departure time or an
arrival deadline. The method builds graphs that model statistical
properties of the vehicles. One of the aspects is a "prospect edge"
that models travel from a location to other location using any of a
range of choices of vehicles and walks. In one embodiment, that
edge models an expected minimum travel duration between the two
locations. Using a graph, or its extension dependent on specifics
of the query, the method generates a route plan as an answer to the
query.
[0005] According to an embodiment of the present invention, a
computer system for generating a route plan is provided. The system
is a combination of hardware and software. It obtains information
about the transportation system and walks among locations from a
plurality of data providers. The system builds a plurality of
graphs that model the transportation system, and computes shortest
paths in graphs in order to generate a route plan.
[0006] According to an embodiment of the present invention, a
computer service product for generating a route plan is provided.
The service allows a user to specify queries through a User
Interface on a device, including a smartphone, and displays
generated route plans on the device.
[0007] The embodiments of the invention presented here are for
illustrative purpose; they are not intended to be exhaustive. Many
modifications and variations will be apparent to those of ordinary
skill in the art without departing from the scope and spirit of the
embodiments.
[0008] The data retrieval, processing operations, and so on,
disclosed in this invention are implemented as a computer system or
service, and not as any mental step or an abstract idea that is
disembodied.
[0009] In the presentation, the terms "the first", "the second",
"the", and similar, are not used in any limiting sense, but for the
purpose of distinguishing, unless otherwise is clear from the
context. An expression in a singular form includes the plural form,
unless otherwise is clear from the context.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING
[0010] The drawings included in the present invention exemplify
various features and advantages of the embodiments of the
invention:
[0011] FIG. 1: depicts a graph G0 according to an embodiment of the
invention;
[0012] FIG. 2: depicts a process flow for constructing graph G0
according to an embodiment of the invention;
[0013] FIG. 3: depicts a travel from c to c' involving a walk, a
wait, a bus ride, and a walk according to an embodiment of the
invention;
[0014] FIG. 4: depicts a travel from c to c' involving one bus line
but two ways of travel according to an embodiment of the
invention;
[0015] FIG. 5: depicts two bus lines, each offers a distinct way of
travel from c to c' according to an embodiment of the
invention;
[0016] FIG. 6: depicts a travel from c to c' involving a walk, a
wait, a subway ride, and a walk according to an embodiment of the
invention;
[0017] FIG. 7: depicts a prospect edge for three choices for travel
from c to c' according to an embodiment of the invention;
[0018] FIG. 8: depicts a prospect edge for two choices for travel
from c to c' given duration random variables conditioned on the
time of arrival of the rider at c according to an embodiment of the
invention;
[0019] FIG. 9: depicts pseudocode for computing prospect edges
under the interval model of wait durations and fixed travel
durations according to an embodiment of the invention;
[0020] FIG. 10: depicts how graph G1 extends graph G0 with edges
from sources, when sources in queries are known according to an
embodiment of the invention;
[0021] FIG. 11: depicts how graph G2 extends graph G0 with prospect
edges to targets, when targets in queries are known according to an
embodiment of the invention;
[0022] FIG. 12: depicts an example of computing choices for
prospect travel continuing from a penultimate stop/station, when
the target is revealed at query time according to an embodiment of
the invention;
[0023] FIG. 13: depicts a process flow of a computer system for
answering routing queries according to an embodiment of the
invention;
[0024] FIG. 14: depicts an example of a rendering of a route in
response to a query by a service product on a smartphone of a user
according to an embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
4 Detailed Description
[0025] A metropolitan transport system is composed of vehicles, for
example subways and buses. A common goal for a rider is to
determine a fastest route from a given location to other location
within the metropolitan area. A route can be computed using
timetables of the vehicles, and a desired departure time or arrival
deadline, as can be seen at major providers of mapping services
online. However, in practice some vehicles do not follow timetables
exactly, for example due to traffic. In contrast to prior art, the
present invention teaches how to compute routes using a mix of
vehicles that follow, and not follow, the timetables. The invention
utilizes route similarities and wait durations to improve routing
results.
[0026] Let us illustrate the improvements with a simple example.
Consider two consecutive bus stops b.sub.1 and b.sub.2 along the
route of a bus. A ride takes 20 minutes on average. Suppose further
that the bus arrives at b.sub.1 every 24 minutes on average. For a
rider arriving at b.sub.1 at a random time, the average travel
duration to b.sub.2 is 32 minutes (wait+ride). Now, suppose that
there is other bus that also rides between these two bus stops.
Under the same timing assumptions, and assuming independence of the
buses, the average travel duration is four minutes shorter. In
general, with n buses, the average is 20+24/(n+1) minutes. This
simply is because the rider can board a bus that arrives at b.sub.1
first.
[0027] However, a natural metropolis is more complicated than our
simple illustration: there can be sophisticated overlap patterns of
routes, with vehicles having differing arrival and speed patterns.
It is not even strictly necessary for routes to overlap to achieve
improvements, as riders may walk among vehicle stops. The transport
system may evolve over time, as subway timetables change and bus
routes get added, for example. Besides, we desire an efficient
method for computing routes, so as to enable a computer to quickly
answer many routing queries even for the largest metropolitan
areas.
4.1 Model Outline
[0028] We introduce a model of a transport system for computing
routes or route durations.
[0029] We assume that the transport system is composed of two types
of vehicles: (1) vehicles that follow fixed timetables, departing
and arriving at predetermined times of the day, for example
according to a schedule for weekdays; we call this vehicle a
subway, and call its stops subway stations, (2) vehicles whose
departure and arrival times are not fixed; we call this vehicle a
bus, and its stop bus stops. Both subway stations and bus stops
have fixed geographical locations, so we can determine walks among
them. Buses are grouped into bus lines. Any bus of a bus line rides
along a fixed sequence of bus stops, commonly until the terminal
bus stop of the bus line.
[0030] In practice, some buses may quite punctually arrive, which
may appear to not conform with our model. For example, consider a
bus dispatched from the first bus stop of the bus line according to
a fixed timetable. The bus may punctually arrive at the first few
stops, until reaching an area of the metropolis with unpredictable
traffic. When a rider arrives at one of these first bus stops after
a subway ride, the wait duration for the bus is predictable, and so
is the total subway-walk-bus travel duration. We can model this
case by conceptually adding a subway to represent this
multi-vehicle subway-walk-bus travel. Similarly, we can
conceptualize bus-walk-subway, bus-walk-bus, and
subway-walk-subway, and other combinations, when the rides are
synchronized or quite punctual. To simplify the presentation of the
disclosure, we maintain our assumption of fixed-timetable subways
and non-fixed-timetable buses in the rest of this invention
description.
[0031] Our method is not restricted to routing people by buses or
subway. In contrast, our method is more general. It captures many
kinds of vehicles that occur in practice. For example, these
include: a subway, a bus, a tram, a train, a taxi, a shared van, a
car, a self-driving car, a ferry boat, an airplane, a delivery
motorbike, a cargo lorry, or a container truck. A route produced by
our method can be used to route any object. For example, these
include: a person, a cargo, a package, a letter or a food item. We
sometimes refer to this object as a rider.
[0032] The transport system is modeled through a collection of
directed graphs, each consisting of vertices and edges. Each vertex
represents a bus stop, a subway station, or an auxiliary entity.
Other examples of vertex representations include a train station, a
taxi stand, a shared van pickup or drop-off location, a car park, a
self-driving car pickup or drop-off location, a platform, a floor,
a harbor, a ferry or air terminal, an airport, or a loading dock.
Any edge represents a wait, a travel from one to other location, or
an auxiliary entity. In one embodiment, an edge has a weight
denoting a duration of wait or travel. In other embodiment, a
weight is a random variable. In other embodiment, some random
variables are conditioned, for example on the time of the day,
holiday/non-holiday day type, among others. In other embodiment,
some random variables may be correlated with other random
variables.
[0033] In one embodiment, we determine a probability distribution
for a random variable from historical data. For example, we measure
how long a bus of a given bus line took to travel from a given bus
stop b.sub.1 to a given bus stop b.sub.2 throughout a period of a
month, and determine an empirical distribution of travel duration
from this one month of samples. In other example, we measure
arrival or departure times of a bus of a given bus line from a
given bus stop over a period of time, and determine an empirical
distribution of a wait time for a bus of the bus line, for each
minute of a weekday. In other example, we use a passing interval
reported by a bus operator to determine an average wait time. In
other example, a current location of a bus is used to compute a
more accurate distribution of a wait duration for the bus.
[0034] Some of the random variables used in our method are
non-trivial. A trivial random variable has just one value with
probability 1. Any other random variable is non-trivial.
[0035] A goal of any graph is to help answer any query to find a
route or a route duration between any two geographical locations.
The starting point of a route is called a source, and the ending
point called a target. The locations are determined by the
application of the routing system. For example, the locations could
be commercial enterprises, bus and subway stations themselves,
arbitrary points in a park, or the current location of a person
determined by a Global Positioning System. In one embodiment, we
search for a route by applying a Dijkstra's shortest paths
algorithm or an A* (A star) search algorithm to a graph, or some
adaptations of these algorithms as discussed later.
[0036] In some embodiments, we add restrictions on routes. For
example, these include: a vehicle type, a vehicle stop type, a
threshold on the number of vehicle transfers, a threshold on a wait
duration, a threshold on a walk duration, a type of object being
routed which may fit in only specific vehicles, a threshold on a
monetary cost of travel, a departure time from the source, an
arrival time at the target, or a desired probability of arriving
before a deadline.
[0037] In one embodiment, our method computes routes or route
durations that have a smallest expected duration. However, our
method is more general. It also computes routes or route durations
that are approximately fastest, or that may not be fastest, but
that limit the risk of arriving after a given deadline.
[0038] Our invention builds several graphs to answer routing
queries. Some embodiments extend a graph with extra vertices and
edges based on the query.
4.2 Graph G0
[0039] The graph called G0 represents routing among bus stops and
subway stations. A detailed description of its construction
follows. An illustration of a graph G0 is in FIG. 1, and an
illustration of the process flow of the construction is in FIG.
2.
4.2.1 Fixed Timetables
[0040] The first group of vertices and edges represents routing by
vehicles that follow fixed timetables. Because timetables are
fixed, we can use a known algorithm to compute a fastest route
between two locations, that can involve a sequence of multiple
vehicles with walks in-between. Hence, we use a single edge to
abstract this multi-vehicle travel from a source to a target.
[0041] We add vertices that model boarding subway without waiting,
as if the rider timed their arrival at a station with a departure
of the subway. We introduce two vertices for each subway station s:
[0042] SUBWAY_FROM_s and [0043] SUBWAY_STATION_s. For any two
distinct stations s and s', we have an edge [0044]
SUBWAY_FROM_s.fwdarw.SUBWAY_STATION_s' representing a ride duration
from s to s', possibly involving changing subways and walking (for
example from station s, first take subway A to station B, then walk
to station C, then take subway D to station s'); the edge is
labelled RideManyGetOff. In one embodiment, the weight of the edge
is a minimum ride duration during weekday morning rush hours. In
other embodiment, we use a random variable for each of many time
windows. In other embodiment, the random variable is conditioned on
an arrival time of the rider at a location of s, or a departure
time from a location of s.
[0045] We model an event when a rider arrives at a subway station
later during travel, and may need to wait for the subway. For any
two distinct stations s' and s'', we add a vertex [0046]
SUBWAY_FROM_TO_s'_s'' that denotes riding from s' to s''. There is
an edge [0047] SUBWAY_STATION_s'.fwdarw.SUBWAY_FROM_TO_s'_s''
labelled WaitGetOn representing a wait duration to get on a subway
traveling from s' to s''. In one embodiment, the weight of the edge
is set to an average wait for a subway that transports the rider to
s'' the earliest, given the rider arriving at s' at a random time
during weekday morning rush hours. In other embodiment, the weight
is set to half of an average interarrival time of any subway from
s' to s''. In other embodiment, we use a random variable for each
of many time windows. In other embodiment, the random variable is
conditioned on an arrival time of the rider at a location of s', or
a distribution of the arrival time.
[0048] We add an edge [0049]
SUBWAY_FROM_TO_s'_s''.fwdarw.SUBWAY_STATION_s'' labelled
RideManyGetOff representing a ride duration from s' to s'' possibly
involving changing subways and walking. In one embodiment, the
weight of the edge is set to an average shortest ride duration
during weekday morning rush hours. In other embodiment, we use a
random variable for each of many time windows. In other embodiment,
the random variable is conditioned on an arrival time of the rider
at a location of s', or a departure time from a location of s'.
4.2.2 Non-Fixed Timetables
[0050] The second group of vertices and edges represents routing by
vehicles that do not follow fixed timetables.
[0051] For every bus line, we add vertices that model its bus
stops, and a bus at the bus stops. The former abstracts a rider
outside the bus, the latter a rider inside the bus. Let b.sub.1, .
. . , b.sub.n be the n consecutive bus stops along a bus line e
(including on-demand stops). Then we add vertices [0052]
BUS_STOP_b.sub.k and [0053] BUS_AT_BUS_STOP_b.sub.k_k_e, for each
k, 1.ltoreq.k.ltoreq.n. Two bus lines may share a bus stop. There
is an edge [0054] BUS_AT_BUS_STOP_b.sub.k_k_e BUS_STOP_b.sub.k
labelled GetOff denoting disembarking the bus at this bus stop; the
edge has zero weight. There is an edge in the reverse direction
[0055] BUS_STOP_b.sub.k.fwdarw.BUS_AT_BUS_STOP_b.sub.k_k_e labelled
WaitGetOn representing a duration of waiting for a bus of bus line
e at bus stop b.sub.k before embarking. In one embodiment, the
weight of the edge is set to half of an average interarrival time
of a bus of bus line e during weekday morning rush hours, which is
the same for every bus stop of that bus line. In other embodiment,
we use a random variable for each of many time windows and bus
stops. In other embodiment, the random variable is conditioned on
an arrival time of the rider at a location of b.sub.k, or a
distribution of arrival time.
[0056] To model travel inside the same bus, we add an edge [0057]
BUS_AT_BUS_STOP_b.sub.k_k_e.fwdarw.BUS_AT_BUS_STOP_b.sub.k+1_k+1_e
labelled RideSame representing a duration of a ride from bus stop
b.sub.k to the next bus stop b.sub.k+1 by bus line e. In one
embodiment, the weight of the edge is set to an average ride
duration between these bus stops during weekday morning rush hours.
In other embodiment, we use a random variable for each of many time
windows and bus stops. In other embodiment, the random variable is
conditioned on an arrival time of a bus at a location of b.sub.k,
or a departure time from a location of b.sub.k.
4.2.3 Walks
[0058] We use walks to connect bus stop and subway station
vertices.
[0059] In this and other sections of the invention disclosure we
allow various requirements for walks. In one embodiment, we use a
walk with a shortest duration at a specific speed of 4 km/h. In
other embodiment, the weight is a random variable for each of
several walk path requirements, including speed 6 km/h, avoid
stairs, avoid dark streets. In other embodiment, we allow only
walks with duration at most a fixed amount of time, for example one
hour. In other embodiment, a walk is straight-line that ignores any
obstacles. In other embodiment, a walk can include travel by a
lift, a moving path, an elevator, or an escalator.
[0060] We add edges [0061] BUS_STOP_b.fwdarw.BUS_STOP_b', [0062]
BUS_STOP_b.fwdarw.SUBWAY_STATION_s, [0063]
SUBWAY_STATION_s.fwdarw.BUS_STOP_b, and [0064]
SUBWAY_STATION_s.fwdarw.SUBWAY_STATION_s', for any b, b', s, s',
when allowed by the requirements. Each edge is labelled Walk, and
its weight represents a duration of a walk.
4.2.4 Constraints
[0065] Next we add auxiliary vertices that enable modeling a
constraint on the first wait along a route. In one embodiment the
wait is zero, which models a rider walking to the stop/station just
early enough to catch a departing bus/subway, but not earlier. In
other embodiment, the wait depends on a start time of travel, which
models a rider starting the travel at a specific time; for example
leaving home at 8 am.
[0066] We cluster bus stops and subway stations based on their
geographical proximity. In one embodiment, we fix the cluster
radius to 2 meters. In other embodiment, we select the number of
clusters depending on a resource/quality trade-off required by the
user of the routing system. In other embodiment, the cluster radius
is 0 meters, in which case the clusters are simple replicas of bus
stops and subway stations.
[0067] For each cluster c, we add a vertex [0068]
STOPSTATION_CLUSTER_SOURCE_c and add edges connecting the cluster
to its buses and subways: [0069]
STOPSTATION_CLUSTER_SOURCE_c.fwdarw.BUS_AT_BUS_STOP_b.sub.k_k_e and
[0070] STOPSTATION_CLUSTER_SOURCE_c.fwdarw.SUBWAY_FROM_s, when
b.sub.k or s are in cluster c. The edges are labelled
FirstWaitGetOn. In one embodiment, the weight of the edge is 0. In
other embodiment, the weight of the edge is a random variable
denoting a wait duration for a vehicle (bus e, or subway)
conditioned on a time of arrival of the rider at the location of
the vertex (bus stop b.sub.k, or subway station s). In other
embodiment, the weight is increased by a walk duration between c
and b.sub.k or s, for example when cluster radius is large.
[0071] Note that any non-trivial path in the graph from [0072]
STOPSTATION_CLUSTER_SOURCE_c will traverse that FirstWaitGetOn edge
exactly once.
[0073] We add other auxiliary vertices. We cluster bus stops and
subway stations similar as before, and for each cluster c, add a
vertex [0074] STOPSTATION_CLUSTER_TARGET_c and edges [0075]
BUS_STOP_b.fwdarw.STOPSTATION_CLUSTER_TARGET_c and [0076]
SUBWAY_STATION_s.fwdarw.STOPSTATION_CLUSTER_TARGET_c, for every b
and s, when in cluster c. The edges are labelled Zero and have
weight 0. In other embodiment, the weight is increased by a walk
duration, for example when cluster radius is large.
[0077] The introduction of vertices [0078]
STOPSTATION_CLUSTER_TARGET_c can help decrease the size of the
graph when there are many routing target locations. In other
embodiment, we can replace these vertices with direct edges from
[0079] BUS_STOP_b and [0080] SUBWAY_STATION_s to the target, for
any b and s when appropriate.
[0081] The graph constructed so far models a duration of travel
from [0082] STOPSTATION_CLUSTER_SOURCE_c to [0083]
STOPSTATION_CLUSTER_TARGET_c', for any c and c', such that the
first bus or subway is boarded without waiting or with given
waiting, and after the rider gets off the bus or the subway
sequence, any subsequent vehicle ride requires waiting to
board.
4.2.5 Prospect Edges
[0084] Next we add auxiliary vertices and edges that reflect
improvements in travel duration due to using any of several
vehicles. The improvements may be caused by a shorter wait for any
vehicle, or a shorter ride by any vehicle.
[0085] The duration of waiting to board a vehicle can be modeled by
assuming that the rider arrives at a stop/station at a random time,
because of a stochastic nature of the vehicles that use non-fixed
timetables. If there were two consecutive RideManyGetOff vehicle
ride edges on a graph path, the edges could be replaced by one
RideManyGetOff edge.
[0086] We introduce a prospect edge, which abstracts travel between
two locations using one of several choices of vehicles. In one
embodiment, the weight of the edge is the value of an expected
minimum travel duration among these choices.
[0087] In this section, the two locations connected by a prospect
edge are near vehicle stops. However, this is not a limitation of
our method. Indeed, in a later section we describe a prospect edge
that ends at an arbitrary location that may be far from any vehicle
stop. In general, a prospect edge may connect arbitrary two
vertices in a graph. However, for the sake of presentation, in this
section we focus on prospect edges near vehicle stops.
[0088] We cluster bus stops and subway stations based on their
geographical proximity, similar as before. Given two distinct
clusters c and c', we consider any way of traveling from c to c' by
a walk, followed by a bus ride, followed by a walk, any of the two
walks can have length 0. For example, FIG. 3 depicts a case when
there is a walk from c to vertex [0089] BUS_STOP_b, and from there
a graph path involving bus line e with edges WaitGetOn, RideSame,
and GetOff, ending at a vertex [0090] BUS_STOP_b', and then a walk
from [0091] BUS_STOP_b' to c'. Let T be a random variable
representing a duration of travel from c to c' using the walks from
c to b and from b' to c', and a bus ride from b to b' modeled by a
graph path. This variable is just a sum of the random variables of
the graph edges along the path, plus the random variables of two
front and back walks. Its distribution can be established from the
constituent distributions. In one embodiment, we condition the
random variable on a departure time from c.
[0092] In one embodiment, this random variable T is uniformly
distributed on an interval [x, y], where the interval tips are
x=(minimum walk duration from c to b)+(sum of an expected RideSame
duration along the path edges)+(minimum walk duration from b' to
c'), and
y=x+2(expected WaitGetOn duration).
In other embodiment, the tips are adjusted by a multiplicity of a
standard deviation of the random variables. In other embodiment, we
consider c, b, b', c' only when the walk durations from c to b and
from b' to c' are at most a fixed amount time, for example one
hour. In other embodiment, any of the walks may be zero-length (an
optional walk). In other embodiment, we require a shortest duration
walk from c to b, or from b' to c'. In other embodiment, walks may
have embodiments as in Section 4.2.3. In other embodiment, the
random variable T is non-uniform. In other embodiment, the random
variable T is conditioned on an arrival time of the rider at a
location of c.
[0093] For a fixed bus line e, there may be many alternatives for
traveling from c to c', because the rider can board/get off at
various bus stops of that bus line, and use walks for the rest of
the travel. For example, FIG. 4 extends FIG. 3 by showing an
alternative ride: to one further stop [0094] BUS_STOP_b'' that
increases a total ride duration, but decreases a total walk
duration. In one embodiment, from among these alternatives, we take
a random variable T that has a lowest expectation. Let us denote
this variable T.sub.c,c',e. This is a fixed random variable for the
bus line e, and the start and the end clusters c and c'. The
variable denotes a fastest travel duration for getting from c to c'
by the bus line e stochastically. In one embodiment, when the
candidates for T.sub.c,c',e are uniformly distributed on intervals,
a lowest expectation candidate is just a candidate with a smallest
median value of its interval. In other embodiment, we use one
variable for each of many time windows, for example so as to
capture higher frequency of buses during peak hours, and also
higher road traffic. In other embodiment, the random variable is
conditioned on an arrival time of the rider at a location of c.
[0095] Let us consider all bus lines e.sub.1 through e.sub.n that
can help transport a rider form c to c'. Note that the constituent
walks and bus stops may differ. For example, FIG. 5 shows two bus
lines e.sub.1 and e.sub.2, each using distinct bus stops, and
having different walk durations. Let T.sub.c,c',e.sub.1 through
T.sub.c,c',e.sub.n be respective fastest travel duration random
variables, as defined before.
[0096] We can compute an expected minimum of the variables
E[min.sub.1.ltoreq.i.ltoreq.nT.sub.c,c',e.sub.i]. This expectation
models travel duration by "whichever bus will get me there faster".
In one embodiment, the random variables of different bus lines are
independent. That is T.sub.c,c',e.sub.i is independent from
T.sub.c,c',e.sub.j for any two distinct bus lines e.sub.i and
e.sub.j. In other embodiment, the random variables are independent
uniform on a common interval [x, y]. Then an expected minimum is
(y+nx)/(n+1). In other embodiment, we compute the expectation
through a mathematical formula, approximate integration, random
sampling, or other approximation algorithm or a heuristic for an
expected minimum. When an approximation algorithm is used, then our
method no longer produces shortest routes, but instead produces
approximately shortest routes.
[0097] Now we discuss how to include subways into a computation of
an expected minimum travel duration. Similar to buses, let
T.sub.c,c',s,s' be a random variable of fastest travel duration
from c to c' using walks and subway rides. As illustrated in FIG.
6, there is a walk from c to s, a path in the graph [0098]
SUBWAY_STATION_s.fwdarw.SUBWAY_FROM_TO_s_s'.fwdarw.SUBWAY_STATION_s',
and a walk from s' to c'. A distribution of this variable can be
established from constituent distributions. In one embodiment, we
condition the random variable on a departure time from c.
[0099] In one embodiment, T.sub.c,c',s,s' is uniformly distributed
on an interval [x, y], where the interval tips are
x=(minimum walk duration from c to s)+(expected RideManyGetOff
duration on the graph path)+(minimum walk duration from s' to c'),
and
y=x+2(expected WaitGetOn duration on the graph path).
In other embodiment, the tips are adjusted by a multiplicity of a
standard deviation of the random variables. In other embodiment we
restrict the walk durations from c to s and from s' to c' to at
most a fixed amount time, for example one hour. In other
embodiment, any of the walks may be zero-length (an optional walk).
In other embodiment, we require a shortest duration walk from c to
s, or from s' to c'. In other embodiment, walks may have
embodiments as in Section 4.2.3. In other embodiment,
T.sub.c,c',s,s' is non-uniform. In other embodiment,
T.sub.c,c',s,s' is conditioned on an arrival time of the rider at a
location of c. In other embodiment, we use one variable for each of
many time windows.
[0100] A complication arises in that the subway random variables
are pairwise dependent, because they are derived from fixed subway
schedules. This may complicate a computation of an expected minimum
travel duration from c to c'.
[0101] Let us consider all subway rides that can help transport a
rider from c to c', and let s.sub.1, s.sub.1', . . . , s.sub.m,
s.sub.m' be the m embarkation and disembarkation subway stations
with the respective random variables
T.sub.c,c',s.sub.1.sub.,s.sub.1.sub.' through
T.sub.c,c',s.sub.m.sub.,s.sub.m.sub.'.
[0102] In one embodiment, any one subway random variable together
with all bus line random variables are independent. In that case we
can compute an expected minimum travel duration for buses and
subways as a minimum of expected minima, adding one subway ride at
a time to the pool of bus rides, and denote it as P(c, c'), as in
the following equation:
P ( c , c ' ) = min 1 .ltoreq. j .ltoreq. m E [ min ( T c , c ' , s
j , s j ' , T c , c ' , e 1 , , T c , c ' , e n ) ] . ( 1 )
##EQU00001##
We call P(c, c') a prospect travel, because it is a travel form c
to c' involving any of several transportation choices,
opportunistically. We call the m+n constituent random variables
T.sub.c,c',s.sub.j.sub.,s.sub.j.sub.' and T.sub.c,c',e.sub.i the
choices.
[0103] In one embodiment, T.sub.c,c',e.sub.i is uniform over an
interval, and so is T.sub.c,c',s.sub.j.sub.,s.sub.j.sub.'. In that
case we compute an expected minimum E[min T.sub.i], for some number
of T.sub.i, each uniform over an interval [x.sub.i, y.sub.i].
[0104] For example, FIG. 7 shows travel from c to c' involving
three choices: [0105] bus line c' with wait uniform on [0,900] and
walk&ride 1700, [0106] bus line e'' with wait uniform on
[0,3600] and walk&ride 1000, [0107] subway with wait uniform on
[0, 300] and walk&ride 2200. In that case a minimum expected
travel duration is 2150=min{2150, 2800, 2350}, which does not
reflect improvements from travel by "whichever is faster". However,
an expected minimum is lower: P(c, c')=1933.
[0108] In other example, FIG. 8 illustrates probability
distributions conditioned on a time when the rider arrives at c
(the source of a prospect edge). There are two choices of getting
from c to c', one by bus and the other by subway. Each choice has
its own conditional probability distributions for wait and for
walks and ride.
[0109] There is a gain in duration due to a prospect travel, if the
value of P(c, c') is less than a minimum of expectations
min(min.sub.1.ltoreq.j.ltoreq.m
E[T.sub.c,c',s.sub.j.sub.,s.sub.j.sub.'],
min.sub.1.ltoreq.i.ltoreq.n E[T.sub.c,c',e.sub.i]). In that case,
we add to the graph: vertices [0110] PROSPECT_CLUSTER_SOURCE_c and
[0111] PROSPECT_CLUSTER_TARGET_c', and an edge [0112]
PROSPECT_CLUSTER_SOURCE_c.fwdarw.PROSPECT_CLUSTER_TARGET_c'
labelled AvgMinWalkWaitRideWalk with the weight P(c, c'). We also
add edges from bus and subway stations of the cluster c to the
vertex [0113] PROSPECT_CLUSTER_SOURCE_c, and edges from the vertex
[0114] PROSPECT_CLUSTER_TARGET_c' to bus and subway stations in the
cluster c'; these edges are labelled Zero and have zero weight. In
one embodiment we add the prospect edge only when its weight P(c,
c') results in a gain that is above a threshold, for example at
least 10 seconds.
[0115] We remark that our method does not require the rider to
board a first arriving of the transportation choices, simply
because a subsequent choice, even though requiring a longer wait,
may arrive at the destination faster (consider an express bus
versus an ordinary bus). Our method does not even require boarding
a bus at the same stop/station, because the rider may walk to other
stop/station, for example anticipating an express train departing
from there.
Definition 1
[0116] In one embodiment, prospect travel is defined in terms of:
[0117] any two locations c and c', [0118] any number k.gtoreq.2 of
random variables T.sub.1, . . . , T.sub.k, each representing a
duration of travel from c to c', [0119] the k variables are
independent, dependent, or correlated arbitrarily, [0120] any of
the k variables may be conditioned on a time A of arrival of the
rider at a location c; the time A may be a random variable. The
duration of prospect travel is a minimum min(T.sub.1, . . . ,
T.sub.k), which by itself is a random variable. The weight of a
prospect edge is an expected value of this minimum
P(c,c')=E[min(T.sub.1, . . . , T.sub.k)].
[0121] In other embodiment, a random variable T.sub.i is
distributed uniformly on an interval. In one embodiment, a random
variable T.sub.i is conditioned on an arrival time at c that falls
within a specific time window, or a probability distribution of
arrival time at c.
[0122] In one embodiment, in order to determine the random
variables T.sub.1, . . . , T.sub.k, we determine a list of vehicle
stops near c and durations of walks to these stops from c, and a
list of vehicle stops near c' and duration of walks from these
stops to c', and then for each pair of vehicle stops on the two
lists, we determine a travel duration random variable.
[0123] In one embodiment, we compute various statistics on a random
variable min(T.sub.1, . . . , T.sub.k). One is the already
mentioned expected value. But we also compute a probability mass,
which can be used to determine an arrival time that can be achieved
with a specific probability. In order to compute these statistics,
we use several methods, including sampling, a closed-form formula,
approximate integration, and other approximation algorithm or a
heuristic.
[0124] In one embodiment, we pre-compute a component of prospect
travel and store it, so that when prospect travel needs to be
determined, we can retrieve the component from storage and avoid
computing the component from scratch. Examples of such components
include: a random variable of a duration of travel between a pair
of vehicle stops; an expected minimum of two or more travel
duration random variables; a probability distribution of a minimum
of at least two travel duration random variables; or a path or a
travel duration between a pair of vehicle stops.
[0125] So far we have defined how to compute a prospect edge for a
given c and c'. We apply this definition to all pairs of distinct c
and c', which determines which prospect clusters get connected, and
which do not get connected, by a prospect edge, and of what
weight.
[0126] In one embodiment, instead of considering a quadratic number
of c and c' pairs, we perform a graph traversal. In one embodiment,
we use a "forward" traversal from vertex [0127]
PROSPECT_CLUSTER_SOURCE_c, for each c, towards every vertex [0128]
PROSPECT_CLUSTER_TARGET_c' that is reachable by
walk-bus/subway-walk. During this traversal, we identify the graph
paths that lead to the [0129] PROSPECT_CLUSTER_TARGET_c', for each
c'. Once we have identified all such paths for a specific c', we
have computed all the choices between the [0130]
PROSPECT_CLUSTER_SOURCE_c and the [0131]
PROSPECT_CLUSTER_TARGET_c', and thus can compute an expected
minimum of these choices (see FIG. 9 for a further example).
Because we limit the exploration to only the reachable parts of the
graph, we can often compute prospect edges more efficiently. In one
embodiment, we use a symmetric method of a "backward" traversal
from vertex [0132] PROSPECT_CLUSTER_TARGET_c', for each c',
backwards to every vertex [0133] PROSPECT_CLUSTER_SOURCE_c that is
reachable by a "reversed" path walk-bus/subway-walk.
[0134] FIG. 9 illustrates an embodiment of the process of adding
prospect edges to graph G0, in the case when any wait duration is
uniformly distributed on an interval [0, 2WaitGetOn] for the
respective edge, and a ride duration is deterministic.
4.3 Extensions of Graph G0
[0135] We describe extensions to the graph G0. Each extension is
useful for a specific kind of routing queries.
4.3.1 Sources Known Beforehand
[0136] In some embodiments the source locations of routing queries
are known in advance. For example, suppose that we are interested
in finding a shortest route from every restaurant in the
metropolitan area, and the restaurant locations are known. This can
be achieved with the help of an extended graph G0.
[0137] In one embodiment, for each such source s, we add a vertex
[0138] SOURCE_s. See FIG. 10 for an illustration. In one
embodiment, we add an edge from [0139] SOURCE_s to any bus stop and
subway station cluster [0140] STOPSTATION_CLUSTER_SOURCE_c in the
graph G0. The edge is labelled Walk, and its weight represents a
duration of a walk. In other embodiment, we use a shortest walk
with duration that is at most a threshold, or other embodiments as
in Section 4.2.3.
[0141] The resulting graph is denoted G1 (it includes G0). G1 can
be used to compute shortest paths from any [0142] SOURCE_s to any
[0143] STOPSTATION_CLUSTER_TARGET_c. In one embodiment, some paths
are pre-computed, stored, and retrieved from storage when a query
is posed.
[0144] In other embodiment, we use a symmetric method when targets
are known beforehand: for each target t, we add a vertex [0145]
TARGET_t, and add an edge from any [0146]
STOPSTATION_CLUSTER_TARGET_c to any [0147] TARGET_t labelled Walk.
The resulting graph is denoted G1'.
4.3.2 Targets Known Beforehand
[0148] In some embodiments the target locations of routing queries
are known in advance, and we extend G0 with prospect edges to the
targets.
[0149] For each target t, we add a vertex [0150] TARGET_t. See FIG.
11 for an illustration. In one embodiment, we add an edge from any
bus stop and subway station cluster [0151]
STOPSTATION_CLUSTER_TARGET_c in graph G0 to [0152] TARGET_t. The
edge is labelled Walk, and its weight represents a duration of a
walk. In other embodiment, we use a shortest walk with duration
that is at most a threshold, or other embodiments as in Section
4.2.3.
[0153] We add prospect edges according to a process similar to
Section 4.2.5. Specifically, for any [0154]
PROSPECT_CLUSTER_SOURCE_c and [0155] TARGET_t, we determine all
paths from c to t of two kinds:
[0156] (1) a ride by a bus with walks: walk from c to b, graph
path
BUS_STOP _b .fwdarw. BUS_AT _BUS _STOP _b _i _e ##EQU00002##
.fwdarw. BUS_AT _BUS _STOP _b ' _j _e .fwdarw. BUS_STOP _b '
.fwdarw. STOPSTATION_CLUSTER _TARGET _c '' .fwdarw. TARGET_t ,
##EQU00002.2##
[0157] (2) a ride by subways with walks: walk from c to s', graph
path [0158]
SUBWAY_STATION_s'.fwdarw.SUBWAY_FROM_TO_s'_s''.fwdarw.SUBWAY_STATI-
ON_s''.fwdarw.STOPSTATION_CLUSTER_TARGET_c'.fwdarw.TARGET_t. In
other embodiment, we use a shortest walk with duration that is at
most a threshold, or other embodiments as in Section 4.2.3. We
define the random variables of travel duration along each path just
like in Section 4.2.5.
[0159] In one embodiment, we assume that the kind (1) are
independent random variables, and the kind (2) are dependent. And
then we compute an expected minimum travel duration by considering
a pool of all kind (1) random variables (appropriately removing
duplicates for repeated bus lines), adding to the pool one kind (2)
random variable at a time, like in Equation 1 for P(c, c'). In
other embodiment, we use Definition 1 of prospect travel. This
defines P(c, t), called prospect travel from c to t.
[0160] When there is gain in travel duration over a minimum of
expectations, we add an edge from [0161] PROSPECT_CLUSTER_SOURCE_c
to [0162] TARGET_t labelled AvgMinWalkWaitRideWalk with weight P(c,
t). We use similar embodiments to these we used for the edge from
[0163] PROSPECT_CLUSTER_SOURCE_c to [0164]
PROSPECT_CLUSTER_TARGET_c' defined before.
[0165] In one embodiment, we use a "forward" or a "backward" graph
traversal as described in Section 4.2.5 to speed up a computation
of prospect edges between [0166] PROSPECT_CLUSTER_SOURCE_c and
[0167] TARGET_t, for all c and t. In other embodiment, this
traversal could be merged into a traversal when computing prospect
edges in G0.
[0168] The resulting graph is denoted G2 (it includes G0). G2 can
be used to compute shortest paths from any [0169]
STOPSTATION_CLUSTER_SOURCE_c to any [0170] TARGET_t. In one
embodiment, some paths are pre-computed, stored, and retrieved from
storage when a query is posed.
[0171] In other embodiment, we use a symmetric method when sources
are known beforehand: for each source s, we add a vertex [0172]
SOURCE_s, and compute a prospect edge from any [0173] SOURCE_s to
any [0174] PROSPECT_CLUSTER_TARGET_c. The resulting graph is
denoted G2'. 4.3.3 Source Revealed when Query is Posed, Targets
Known
[0175] In some embodiments the target locations of routing queries
are known in advance, but the source is revealed only when a query
is posed.
[0176] In one embodiment, we use the graph G2 of Section 4.3.2 to
compute a shortest ride.
[0177] When a query (s, t) is posed, we determine walks from the
location of s to each [0178] STOPSTATION_CLUSTER_SOURCE_c. In one
embodiment, we use a shortest walk with duration that is at most a
threshold, thereby generating a list of vehicle stops near the
source location, or other embodiments as in Section 4.2.3. We also
determine a shortest travel continuation from [0179]
STOPSTATION_CLUSTER_SOURCE_c to [0180] TARGET_t in graph G2. In one
embodiment, we pre-compute shortest path duration from each [0181]
STOPSTATION_CLUSTER_SOURCE_c to each [0182] TARGET_t, and store the
results. We look up these results from storage when a query is
posed. In other embodiment, we use a graph shortest path algorithm
in G2 to compute a duration when a query is posed.
[0183] We find a cluster c that minimizes a sum of durations of a
walk from s to c and a travel continuation from c to t. This
minimum is a shortest travel duration from s to t.
[0184] In other embodiment, we use a symmetric method when a target
is revealed only when a query is posed. Then, instead of generating
a list of vehicle stops near the source location, we generate a
list of vehicle stops near the target location.
[0185] In other embodiment, instead of using graph G2, we use graph
G1'.
4.3.4 Target Revealed when Query is Posed, Sources Known
[0186] In some embodiments the source locations of routing queries
are known in advance, but a target is revealed only when a query is
posed.
[0187] In one embodiment the graph G1 of Section 4.3.1 is used to
compute a shortest ride. However, we need to compute prospect edges
to the target. This computation is more involved than Section
4.3.2, because the target is unknown beforehand.
[0188] We recall how choices were computed for each prospect edge
in G0. For each clusters c and c', let choices(c, c') be these
choices used to compute P(c, c') for the edge from [0189]
PROSPECT_CLUSTER_SOURCE_c to [0190] PROSPECT_CLUSTER_TARGET_c' in
G0. It is possible that choices(c, c') has just one choice (e.g.,
one bus, or one subway ride). The choices(c, c') is defined even if
the prospect edge was not added in G0 due to lack of a sufficient
gain.
[0191] Let the posed query be (s, t), for a source [0192] SOURCE_s
in the graph G1, and an arbitrary target location t that may be not
represented in the graph.
[0193] A shortest path from s to t may involve just one bus or only
subways. In that case we need not consider prospect edges. We take
the graph G1, and further extend it. We add vertex [0194] TARGET_t,
and edges from [0195] STOPSTATION_CLUSTER_TARGET_c, for any c, to
[0196] TARGET_t. Each of these edges is labelled Walk, and its
weight is a walk duration. In one embodiment, any edge represents a
shortest walk duration that is at most a threshold, or other
embodiments as in Section 4.2.3. We compute a shortest path from
[0197] SOURCE_s to [0198] TARGET_t in the resulting graph, and
denote the path's length by A(s, t). This length is a candidate for
a shortest travel duration from s to t.
[0199] There is other candidate. It is also possible that a
shortest path involves more vehicles. In that case, there is a
penultimate stop/station along the path. To cover this case, we
compute prospect edges to t. The process is illustrated in FIG. 12.
To simplify the illustration, the drawing depicts singleton
prospect clusters (each has just one bus stop, or just one subway
station).
[0200] To compute prospect edges to t we start with a graph G1. We
enumerate the parts of the journey form s to t that end at a
penultimate stop/station. Specifically, we determine a shortest
travel duration from [0201] SOURCE_s to [0202]
PROSPECT_CLUSTER_SOURCE_c, for each c. We denote this duration by
shortest(s.fwdarw.c). For example, in FIG. 12 the value 900 on the
edge from [0203] SOURCE_s to [0204] SUBWAY_STATION_s.sub.1 denotes
a shortest travel duration from [0205] SOURCE_s to [0206]
PROSPECT_CLUSTER_SOURCE_s.sub.1. Note that this travel may pass
along a prospect edge in the graph G1. In one embodiment, this
duration can be pre-computed and stored before queries are posed,
and looked up from storage upon a query.
[0207] We determine how the journey can continue from each
penultimate stop/station to the target t, using prospect edges and
walks. For every [0208] PROSPECT_CLUSTER_SOURCE_c, we determine the
choices of moving from c to t by first going to an intermediate
[0209] PROSPECT_CLUSTER_TARGET_c', called choices(c, c'), and then
following by a walk from c' to t. In one embodiment, we consider
only shortest walks c' to t with duration that is at most a
threshold, or other embodiments as in Section 4.2.3. For example,
in FIG. 12 the choices(b.sub.1, b.sub.0) are depicted on the edge
from [0210] BUS_STOP_b.sub.1 to [0211] BUS_STOP_b.sub.0
[0212] there are two choices: bus line e'' with wait duration
uniform on [0,900] and travel duration 1600, and bus line e''' with
wait duration uniform on [0,3600] and travel duration 1000. It
takes 240 to continue by walk from [0213] BUS_STOP_b.sub.0 to
[0214] TARGET_t.
[0215] Because a rider located at c may pick any c' as a
continuation, we combine at t the choices across all c'. This
combination forms the choices for travel from c to t. For example,
in FIG. 12 there is other edge from [0216] BUS_STOP_b.sub.1; that
edge goes to [0217] BUS_STOP_b.sub.2. The choices(b.sub.1, b.sub.2)
depicted on that edge has just one choice: bus line e' with wait
duration uniform on [0,300] and travel time 900. It takes 500 to
continue by walk from [0218] BUS_STOP_b.sub.2 to [0219] TARGET_t.
The combination of choices(b.sub.1, b.sub.0) with choices(b.sub.1,
b.sub.2) yields three choices (bus lines e', e'' and e'''). These
are the choices of going from [0220] BUS_STOP_b.sub.1 to [0221]
TARGET_t. An expected minimum travel time using these choices is
2636.
[0222] We need to eliminate duplicate bus rides by the same bus
line, like in Section 4.2.5. For example, in FIG. 12 a rider can
depart from [0223] SUBWAY_STATION_s.sub.1 using the same bus line
e'', but going to two different locations: [0224] BUS_STOP_b.sub.2
and [0225] SUBWAY_STATION_s.sub.0. For any bus line at c, we retain
only the choice for this bus line that has a lowest expected travel
duration from c to t (eliminate any other choice for this bus line
at c). For example, in FIG. 12 we eliminate the choice to [0226]
SUBWAY_STATION_s.sub.0 because it has a higher expectation. We
compute an expected minimum travel duration, P(c, t), among the
remaining choices, similar to how we computed P(c, c') in Section
4.2.5.
[0227] A shortest path may pass any of the c, so we compute a
minimum across c, and denote it B(s, t)
B(s,t)=min.sub.c{shortest(s.fwdarw.c)+P(c,t)}.
For example, in FIG. 12 the minimum B(SOURCE_s,TARGET_t)=2445,
which is min{2636, 2445}, because it is more advantageous for the
rider to travel to a penultimate [0228] SUBWAY_STATION_s.sub.1,
rather than to a penultimate [0229] BUS_STOP_b.sub.1.
[0230] This quantity denotes a shortest travel duration from s to t
that involves a penultimate vehicle. B(s, t) is the other candidate
for a shortest travel duration from s to t.
[0231] Finally, a response to the query is a minimum of the two
candidates: min{A(s, t), B(s, t)}.
[0232] For example, in FIG. 12 a response to the query is still
2445, because we cannot shorten travel by using just one vehicle
that travels from [0233] SOURCE_s through [0234] BUS_STOP_b.sub.0
to [0235] TARGET_t, because this travel duration is A(SOURCE_s,
TARGET_t)=3000+240.
[0236] In other embodiment, instead of using graph G1, we use the
graph G2'.
[0237] In other embodiment, we use a symmetric method that computes
prospect edges from a source, when the source is revealed only when
a query is posed. Then, instead of considering a penultimate and a
last stops before arriving at the target, we consider a first and a
second stops after departing from the source.
4.3.5 Source and Target Revealed at Query Time
[0238] When both the source and the target of a query are unknown
beforehand, we select and combine the methods of previous sections.
In one embodiment, we determine walks from the location of the
source s to [0239] STOPSTATION_CLUSTER_SOURCE_c, for each c, and
then travel from [0240] STOPSTATION_CLUSTER_SOURCE_c to target t
(involving penultimate choices, or not). We respond with a minimum
sum, selected across c. In one embodiment, we use a shortest walk
with duration that is at most a threshold, or other embodiments as
in Section 4.2.3.
4.4 Variants
[0241] Many modifications and variations will be apparent to those
of ordinary skill in the art without departing from the scope and
spirit of the embodiments. We present of few variants for
illustration.
[0242] In one embodiment, we use a more general notion of a
prospect edge. When travel involves multiple vehicles and waits, a
shortest path search in a graph may traverse multiple prospect
edges, and these prospect edges along the path will together
abstract a sequence of more than one wait and ride. To capture this
multiplicity, in one embodiment, we use a more general notion of a
depth-d prospect edge that abstracts a sequence of at most d
waits&rides. For example, a path
c-walk1-wait1-bus1-walk2-wait2-bus2-walk3-c' could be abstracted as
a depth-2 prospect edge from c to c'. In one embodiment, we add
depth-d prospect edges for d larger than 1 to our graphs.
[0243] In one embodiment, our method constructs routes given a
departure time. For example, consider the case when the rider
wishes to begin travel at 8 AM on a Tuesday. Here, a routing query
specifies a departure time, in addition to the source and target
locations of travel. In one embodiment, the source is a [0244]
STOPSTATION_CLUSTER_SOURCE_s, and the target is a [0245]
STOPSTATION_CLUSTER_TARGET_t. We modify the graph G0, see FIG. 1.
Because here even the first ride may involve waiting, we remove the
FirstWaitGetOn edges and the [0246] SUBWAY_FROM_s vertices, but add
edges from each [0247] STOPSTATION_CLUSTER_SOURCE_c to [0248]
BUS_STOP_b and [0249] SUBWAY_STATION_s, for any b and s in the
cluster c. In one embodiment, we adopt the Dijkstra's shortest
paths algorithm to use prospect edges: For each vertex [0250]
PROSPECT_CLUSTER_SOURCE_c, we maintain a lowest known expected
arrival time of the rider at the vertex, and use this time to
condition the wait, walk and ride duration random variables to
compute prospect edges to each [0251] PROSPECT_CLUSTER_TARGET_c'.
Using thus computed edge weights, we update the lowest known
expected arrival times at [0252] PROSPECT_CLUSTER_SOURCE_c'. In
other embodiment, instead of maintaining or updating a lowest known
expected arrival time at each [0253] PROSPECT_CLUSTER_SOURCE_c or
at each [0254] PROSPECT_CLUSTER_TARGET_c, we maintain or update a
probability distribution of arrival time. In other embodiment, we
adopt other shortest paths algorithms, for example the A* (A star)
search algorithm in a similar fashion. In other embodiment, for
example when a departure time is "now/soon", the conditional random
variables are computed using the state of the transportation system
at the time of the query, to provide more accurate distributions of
wait and ride durations.
[0255] In one embodiment, our method constructs routes given an
arrival deadline. For example, consider the case when the rider
wishes to arrive at the target before 9 AM on a Tuesday. This is
equivalent to departure from the target at 9 AM, but going back in
time and space. This can be simply abstracted through an
appropriately reversed construction of any of our graphs (buses and
subways travel in reverse time and space).
[0256] In one embodiment, we determine prospect travel that meets a
desired probability p of arrival before a deadline. When
considering a prospect edge from c to c', we use a random variable
A denoting an arrival time of the rider at c. Then, given the k
random variables T.sub.1, . . . , T.sub.k of travel duration from c
to c' using choices, we determine a distribution of arrival time at
c' using the prospect travel, min(A+T.sub.1, . . . , A+T.sub.k).
Then we determine up to which time t this distribution has the mass
that is the desired probability p.
[0257] In one embodiment, we report the vehicles along a shortest
path, or times of arrival/departure for each point along the path.
This information can be simply read off the path in the graph and
the choices of prospect edges along the path.
[0258] In one embodiment, we answer routing queries on computing
devices with limited storage and restricted communication with a
backend server. For example, this can happen on a mobile phone for
a user concerned about privacy. In that case, we use an
appropriately small number of clusters in graph G0. Similar
techniques can be used in our other graphs.
[0259] In one embodiment, we impose requirements on a routing
answer, including a maximum walk duration, a maximum number of
transfers, a maximum wait duration, a restriction to specific types
of vehicles (e.g., use only express bus and subway). Our invention
realizes these requirements by an appropriate modification of
graphs and a shortest paths algorithm on the graphs.
[0260] In one embodiment, our method is applied to an imperfect
graph. For example, the weight of an edge WaitGetOn could inexactly
reflect an expected wait duration for a subway, perhaps because we
estimated the duration incorrectly, or there could be vertices and
edges for a bus that does not exist in the metropolitan area,
perhaps because the bus route was just cancelled by the city
government while our method was not yet able to notice the
cancellation, or we sampled the expectation of the minimum of
choices with a large error, or used an approximate mathematical
formula/algorithm. These are just a few non-exhaustive examples of
imperfectness. In any case, our method can still be applied. It
will simply produce routes with some error.
[0261] In one embodiment, we remove unnecessary vertices and edges
from a graph. For example, we collapse "pass through" vertices
[0262] SUBWAY_AVG_FROM_TO_s'_s'' in G0 by fusing the incoming edge
and the outgoing edge.
[0263] In one embodiment, the steps of our method are applied in
other order. For example, when constructing graph G0, we can
reverse the order described in Sections 4.2.1 and 4.2.2: first add
vertices and edges of the non-fixed timetable vehicles, and then
add vertices and edges of fixed timetable vehicles.
[0264] In one embodiment, we parallelize the method. For example,
instead of computing the prospect edges from each [0265]
PROSPECT_CLUSTER_SOURCE_c in turn, we can consider any two c.sub.1
and c.sub.2, and compute the prospect edges from [0266]
PROSPECT_CLUSTER_SOURCE_c.sub.1 in parallel with computing the
prospect edges from [0267] PROSPECT_CLUSTER_SOURCE_c.sub.2.
5 Computer System
[0268] One of the embodiments of the invention is a computer system
that answers routing queries.
[0269] In one embodiment, the system answers queries for a shortest
route between locations, given a departure time: any query is in
the form (source, target, minuteOfDay). An answer is in the form of
a route with durations and choices. An illustration of the
embodiment is in FIG. 13.
[0270] We use the term "module" in our description. It is known in
the art that the term means a computer (sub)system that provides
some specific functionality. Our choice of partitioning the
computer system into the specific modules is exemplary, not
mandatory. Those of ordinary skill in the art will notice that the
system can be organized into modules in other manner without
departing from the scope of the invention.
[0271] One module of the system (1202) reads information about the
metropolitan transportation system from a plurality of data sources
(1201). The module determines which vehicles, routes, or their
parts, are consider fixed timetable, and which non-fixed timetable.
The module computes routes for fixed timetable vehicles. The module
also computes distributions of wait and ride durations conditioned
on time for non-fixed timetable vehicles.
[0272] The output is passed to a module (1204) that computes
prospect edges. That module queries information about walks from a
plurality of data sources (1203). For selected prospect clusters c
and c' and arrival times of the rider at c, the module computes the
weight P(c, c') of the prospect edge and the choices, using random
variables conditioned on the rider arrival time at c. The results
are stored in storage (1205).
[0273] The modules (1202) and (1204) operate continuously. As a
result, the system maintains a fresh model of the transportation
system.
[0274] In the meantime, other module (1206) pre-computes shortest
paths. The module constructs graphs that link locations at times by
reading prospect edges from (1205) and non-prospect edges from
(1202). Shortest paths algorithms are applied to the graphs to
compute paths for selected queries in the form (stop/station
cluster source, stop/station cluster target, minuteOfDay). The
results are stored, so that a result can be looked up from storage
(1207) when needed later.
[0275] Concurrently, the query answering module (1208) answers
queries. When a query (source, target, minuteOfDay) arrives (1209),
the module computes a shortest path following Section 4. The module
contacts (1203) to determine walks between the source and the
target, and the stop/station clusters. The module looks up relevant
pre-computed shortest paths from (1207). When one is needed but not
available yet, the module requests a shortest path from module
(1206), and may store the resulting shortest path in storage (1207)
for future use. The module (1208) also looks up choices and times
from (1205). These walks, shortest paths and choices are combined
to generate an answer to the query (1210).
[0276] Aspects of the invention may take form of a hardware
embodiment, a software embodiment, or a combination of the two.
Steps of the invention, including blocks of any flowchart, may be
executed out of order, partially concurrently or served from a
cache, depending on functionality and optimization. Aspects may
take form of a sequential system, or parallel/distributed system,
where each component embodies some aspect, possibly redundantly
with other components, and components may communicate, for example
using a network of any kind. A computer program carrying out
operations for aspects of the invention may be written in any
programming language, including C++, Java or JavaScript. Any
program may execute on an arbitrary hardware platform, including a
Central Processing Unit (CPU), and a Graphics Processing Unit
(GPU), and associated memory and storage devices. A program may
execute aspects of the invention on one or more software platforms,
including, but not limited to: a smartphone running Android or iOS
operating systems, or a web browser, including Firefox, Chrome,
Internet Explorer, or Safari.
6 Computer Service Product
[0277] One of the embodiments of the invention is a service product
available to users through a user-facing device, such as a
smartphone application or a webpage. It will be obvious to anyone
of ordinary skill in the art that the invention is not limited to
these devices. It will also be obvious that the presentation of the
service in our drawings can be modified (including rearranging,
resizing, changing colors, shape, adding or removing components)
without departing from the scope of the invention.
[0278] In one embodiment, the service is accessed though a
smartphone application. A user specifies a departure time, and a
source and a target, by interacting with the User Interface of the
application on the smartphone. The service then generates a route,
and renders a representation of the route on the smartphone. FIG.
14 illustrates an example result for a query from A to L departing
at 8 AM.
[0279] In one embodiment, the service reports which choice yields a
shortest travel duration currently. In one embodiment, the system
highlights this faster choice (illustrated by 1401 on the route),
or shows the travel duration by the choice, or depicts a current
wait duration (illustrated by 1402 near D). In one embodiment, this
faster choice is computed given the current positions of the
vehicles. In one embodiment, this report is rendered when the user
is currently near the location of the choice; for example, when the
user is about to depart from A, the service may render that in the
current conditions, it is faster to get to F via D and E, rather
than via B and C.
[0280] In one embodiment, the service depicts a current wait
duration for each choice from among the choices at a location
(illustrated by 1403 near F), or an expected ride duration for each
choice (illustrated by 1404). This may help the user decide by
themselves which choice to take, even if not optimal.
[0281] In one embodiment, the service reports one expected wait
duration for all the choices at a location. The duration is an
expected wait duration assuming the user will board the choice that
achieves an expected minimum travel duration (illustrated by 1405
near H). In one embodiment, this report is rendered when vehicle
positions are uncertain, for example for a segment of the route far
down the road compared to the current position of the user. This
informs the user how long they will idle at a stop/station waiting
for a vehicle.
[0282] In one embodiment, the service reports a duration of
prospect travel between two locations (illustrated by 1406 on the
route). This is the value denoted P(c, c') in Section 4.
[0283] In one embodiment, the service responds to the user with at
least one of: [0284] 1. the source location rendered on a map;
[0285] 2. the target location rendered on a map; [0286] 3. a
location of any stop along a route rendered on a map; [0287] 4. a
sequence of locations along a route rendered on a map; [0288] 5. a
name, an address, or an identifier of any of: the source location,
the target location, or any stop along a route; [0289] 6. a
departure time; [0290] 7. a departure time range; [0291] 8. an
arrival time; [0292] 9. an arrival time range; [0293] 10. a
probability of arriving before a deadline; [0294] 11. a sequence of
locations along two or more choices that travel between two
locations rendered on a map; [0295] 12. directions for a walk
component in any choice; [0296] 13. a location or a duration of a
wait component in any choice; [0297] 14. directions for a ride
component in any choice; [0298] 15. an expected minimum wait
duration among at least two choices; [0299] 16. a current minimum
wait duration among at least two choices; [0300] 17. an expected
travel duration for any component of a choice, or a choice; or an
expected minimum travel duration among at least two choices; [0301]
18. a current travel duration for any component in a choice, or a
choice; or a minimum travel duration among at least two choices;
[0302] 19. an expected departure time or an expected arrival time
for: any component in a choice, a choice, or a minimum among at
least two choices; [0303] 20. a current departure time or a current
arrival time for: any component in a choice, a choice, or a minimum
among at least two choices; [0304] 21. a name or an identifier of
any vehicle in any choice; [0305] 22. a name, an address, or an
identifier of any stop of any vehicle in any choice; [0306] 23. a
current location of any vehicle in any choice; or [0307] 24. a
rendering of which choice, from among two or more choices, is
fastest given current locations of vehicles.
7 Claims
[0308] Those skilled in the art shall notice that various
modifications may be made, and substitutions may be made with
essentially equivalents, without departing from the scope of the
present invention. Besides, a specific situation may be adapted to
the teachings of the invention without departing from its scope.
Therefore, despite the fact that the invention has been described
with reference to the disclosed embodiments, the invention shall
not be restricted to these embodiments. Rather, the invention will
include all embodiments that fall within the scope of the appended
claims.
* * * * *