Multi-modal Trip Planning for the San Francisco Bay Area - Mentz ...

4 mdv news I/2011
Figure 1: Management of traffic alerts received by
DATEX2 in the ICS
Figure 2: Integration of traffic alerts into the directions
(shown in a test layout)
Mapping Static and Dynamic Traffic Data
A challenge when integrating traffic alerts and
other information relevant for IT-routing is the
various reference graphs. This problem was also
confronted when developing the multi-modal
trip planner for the San Francisco Bay Area. Both
the traffic alerts and the speed profiles are referenced
to a network graph which is not identical
to the network graphs of the multi-modal
trip planner. As a consequence, the additional
information cannot be accounted for when
calculating car routes without converting
location references.
The GisImport and DivaGeo modules had to be
enhanced to calculate a conversion table
between two network graphs and feed the output
into an ASCII file. This table is subsequently
read by the ICS and ITProfileConverter applications
and used to convert location references.
As depicted in Figure 4, traffic alerts or characteristics
cannot be displayed on another network
graph without a conversion table. Using
the conversion table it is possible to show information
on the red line on one or more of the
green lines. Consequently, traffic alerts and
speed values from the profiles can be integrated
into the multi-modal trip planning
portal without any loss of information.
Time-bound Tolls
A further challenge to be overcome was the
integration of time-bound tolls, which are specific
to car routing in the Bay Area. All trips over
the bay bridges of San Francisco require tolls in
at least one direction and some tolls are even
dependent on the time of day travelled and
payment method used (cash or automatic easy
pass). The data model of the dynamic IT algorithm
was enhanced for this requirement and
the directions now indicate the tolls due based
on payment method and time of day.
Scenario 3: Drive&Park and Kiss&Ride
The last trip scenario for a comparison is
requesting a Drive&Park or Kiss&Ride route over
the multi-modal trip planning portal. In doing
so, the EFA system either automatically selects
the best Drive&Park parking spaces or lets users
choose a desired transition point for a
Drive&Park or Kiss&Ride trip from a list of
options.
Figure 4: Mapping between two network graphs
Parking Garages and Drop-off Points
The parking garages and drop-off points for a
Drive&Park or Kiss&Ride trip are converted into
GIS data using the GISImport application. The
parking garages and transition points constitute
a new point layer in the GIS data that can
be used save additional attributes relevant for
parking. Among other things, the number of
parking spaces, the coordinates of the
entrances and exits, the average duration
between entering and leaving the parking
garage and other numerous informative attri -
butes per parking garage are imported and
saved in the GIS data.
This information can be subsequently integrated
into the EFA system and requested with
assistance from the EFAParkingServer (see Figure
6). In order to automatically pre-select the
best Park&Ride parking spaces, the system uses
an escalating proximity search. If no parking
garages are found within a starting radius of 5
miles around the trip origin, the search is incrementally
widened until it reaches an indicated
maximum.
Automatic Selection of the Best Drive&Park
Routes
In the past, users were forced to select from a
list with preselected parking garages, before
the EFA system could calculate and present a
complete Drive&Park trip. This manual selection
is now complemented in the multi-modal trip
planning portal for the San Francisco Bay Area
by an automatic selection of the best
Drive&Park routes for an indicated departure or
arrival time.
As depicted in Figure 5, the process of automatically
selecting the best Drive&Park routes is a
complex orchestration of the various EFA components.
It begins with verification of trip origin
and destination (EFALocationServer), continues
with a search for Drive&Park parking spaces
near the starting point of the trip (EFAParkingServer),
a search for public transport stops
near the parking spaces and close to the destination
(EFAGISKernel), calculation of footpaths
between parking garages and origin stops,
between destination stops and the final trip
destination (EFAITRoutingKernel) and the