USF Libraries
USF Digital Collections

A geographic information system for dynamic ridematching

MISSING IMAGE

Material Information

Title:
A geographic information system for dynamic ridematching
Physical Description:
Book
Language:
English
Creator:
Dos-Santos, Sasha
Publisher:
University of South Florida
Place of Publication:
Tampa, Fla.
Publication Date:

Subjects

Subjects / Keywords:
Gis
Geodatabase
Spatial analysis
Carpool
Ridesharing
Dissertations, Academic -- Computer Science and Engineering -- Masters -- USF   ( lcsh )
Genre:
government publication (state, provincial, terriorial, dependent)   ( marcgt )
bibliography   ( marcgt )
theses   ( marcgt )
non-fiction   ( marcgt )

Notes

Abstract:
ABSTRACT: The Online Transportation Option System (OTOS) is a Geographic Information System (GIS) that addresses many of the limitations associated with traditional dynamic ridematching applications. The main improvements are in the areas of trip scheduling and match searching. OTOS is unique in its ability to accept trips with schedules that can not be expressed in terms of a regular weekly trip. OTOS also distinguishes itself in its use of spatial analysis techniques to locate matches. Specifically, the use of a shortest path solver enables the ridematching algorithm to perform a search along the path of a users trip, in addition to the customary radial search around the endpoints. The shortest path solver is also used to calculate the driving distance between the user and a match. This provides a more accurate measurement than the straight-line distance used by other algorithms, especially in the presence of barriers.
Thesis:
Thesis (M.S.C.S.)--University of South Florida, 2005.
Bibliography:
Includes bibliographical references.
System Details:
System requirements: World Wide Web browser and PDF reader.
System Details:
Mode of access: World Wide Web.
Statement of Responsibility:
by Sasha Dos-Santos.
General Note:
Title from PDF of title page.
General Note:
Document formatted into pages; contains 64 pages.

Record Information

Source Institution:
University of South Florida Library
Holding Location:
University of South Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
aleph - 001681072
oclc - 62745032
usfldc doi - E14-SFE0001046
usfldc handle - e14.1046
System ID:
SFS0025367:00001


This item is only available as the following downloads:


Full Text
xml version 1.0 encoding UTF-8 standalone no
record xmlns http:www.loc.govMARC21slim xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.loc.govstandardsmarcxmlschemaMARC21slim.xsd
leader nam Ka
controlfield tag 001 001681072
003 fts
005 20060215071211.0
006 m||||e|||d||||||||
007 cr mnu|||uuuuu
008 051227s2005 flu sbm s000 0 eng d
datafield ind1 8 ind2 024
subfield code a E14-SFE0001046
035
(OCoLC)62745032
SFE0001046
040
FHM
c FHM
049
FHMM
090
TK7885 (Online)
1 100
Dos-Santos, Sasha.
2 245
A geographic information system for dynamic ridematching
h [electronic resource] /
by Sasha Dos-Santos.
260
[Tampa, Fla.] :
b University of South Florida,
2005.
502
Thesis (M.S.C.S.)--University of South Florida, 2005.
504
Includes bibliographical references.
516
Text (Electronic thesis) in PDF format.
538
System requirements: World Wide Web browser and PDF reader.
Mode of access: World Wide Web.
500
Title from PDF of title page.
Document formatted into pages; contains 64 pages.
3 520
ABSTRACT: The Online Transportation Option System (OTOS) is a Geographic Information System (GIS) that addresses many of the limitations associated with traditional dynamic ridematching applications. The main improvements are in the areas of trip scheduling and match searching. OTOS is unique in its ability to accept trips with schedules that can not be expressed in terms of a regular weekly trip. OTOS also distinguishes itself in its use of spatial analysis techniques to locate matches. Specifically, the use of a shortest path solver enables the ridematching algorithm to perform a search along the path of a users trip, in addition to the customary radial search around the endpoints. The shortest path solver is also used to calculate the driving distance between the user and a match. This provides a more accurate measurement than the straight-line distance used by other algorithms, especially in the presence of barriers.
590
Adviser: Dr. Rafael Perez.
653
Gis.
Geodatabase.
Spatial analysis.
Carpool.
Ridesharing.
0 690
Dissertations, Academic
z USF
x Computer Science and Engineering
Masters.
773
t USF Electronic Theses and Dissertations.
4 856
u http://digital.lib.usf.edu/?e14.1046



PAGE 1

A Geographic Information System for Dynamic Ridematching by Sasha dos Santos A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science Department of Computer Science and Engineering College of Engineering University of South Florida Major Professor: Rafael Perez, Ph.D. Miguel Labrador, Ph.D. Dewey Rundus, Ph.D. Date of Approval March 31, 2005 Keywords: GIS, Geodatabase, Spatia l Analysis, Carpool, Ridesharing Copyright 2005, Sasha dos Santos

PAGE 2

i Table of Contents List of Tabl es---------------------------------------------------------------------------------------iii List of Figures---------------------------------------------------------------------------------------iv Abstract ----------------------------------------------------------------------------------------------vi Chapter 1 Introducti on ---------------------------------------------------------------------------1 1.1 Background -----------------------------------------------------------------------------1 1.2 Geographic In formation Systems -----------------------------------------------------1 1.3 Dynamic Ridematching----------------------------------------------------------------6 1.4 Motivation -------------------------------------------------------------------------------7 1.5 Objectives -------------------------------------------------------------------------------9 Chapter 2 System Architecture -----------------------------------------------------------------10 2.1 Introduction -----------------------------------------------------------------------------10 2.2 Geodatabase----------------------------------------------------------------------------11 2.3 GIS Server ------------------------------------------------------------------------------11 2.4 Web Server -----------------------------------------------------------------------------12 2.5 User Interf ace---------------------------------------------------------------------------12 2.6 Syst em Administration ---------------------------------------------------------------13 Chapter 3 Th e Geodata base---------------------------------------------------------------------14 3.1 Introduc tion------------------------------------------------------------------------------14 3.2 Locations Table ------------------------------------------------------------------------15 3.3 Trips Table ------------------------------------------------------------------------------16 3.4 Calendar Ta ble -------------------------------------------------------------------------17 3.5 Trip Schedules Ta ble-------------------------------------------------------------------17 3.6 Matches Table --------------------------------------------------------------------------18 3.7 Ro ads Feature Class -------------------------------------------------------------------18 3.8 Address Locator and Place Name Alias Table -------------------------------------20 3.9 Trips Feature Cl ass --------------------------------------------------------------------21 3.10 Geometri c Network--------------------------------------------------------------------21 3.11 Shortest Path F eature Class -----------------------------------------------------------22

PAGE 3

ii Chapter 4 Ridema tching Algorithm------------------------------------------------------------23 4.1 Introduc tion -----------------------------------------------------------------------------23 4.2 Using Round-trip/One-way Preference to Reduce the Search Space ------------23 4.3 Using Driver/Passenger Preference to Reduce the Search Space ----------------24 4.4 Using Trip Schedul es to Reduce the Search Space --------------------------------25 4.5 Geocoding the Sour ce and Destination ----------------------------------------------33 4.6 Finding the Shortest Path -------------------------------------------------------------35 4.7 Creating Buffe rs------------------------------------------------------------------------37 4.8 Using Buffers to Reduce the Search Space -----------------------------------------38 4.9 Sorting the Matc hes -------------------------------------------------------------------40 4.10 Calculating the Path De viation--------------------------------------------------------41 4.11 Im plementation--------------------------------------------------------------------------49 Chapter 5 Evaluati on ----------------------------------------------------------------------------50 5.1 Introducti on ----------------------------------------------------------------------------50 5.2 Different Source, Same Destination ------------------------------------------------50 5.3 Similar Source, Different Destin ation ----------------------------------------------51 5.4 Overlapp ing Time Windows ---------------------------------------------------------52 5.5 Recurrence Pattern -------------------------------------------------------------------53 Chapter 6 Conclusions and Future Work -----------------------------------------------------54 6.1 C onclusions ---------------------------------------------------------------------------54 6.2 Future Work ----------------------------------------------------------------------------55 References------------------------------------------------------------------------------------------56 Bibliography ---------------------------------------------------------------------------------------57

PAGE 4

iii List of Tables Table 1 Attributes of the Locatio ns Table --------------------------------------------------15 Table 2 Attributes of the Trip s Table -------------------------------------------------------16 Table 3 Attributes of the Calenda r Table ---------------------------------------------------17 Table 4 Attributes of the Trip Schedul es Table --------------------------------------------17 Table 5 Attributes of the Matche s Table ---------------------------------------------------18 Table 6 Attributes of the Roads Feature Class ---------------------------------------------19 Table 7 Attributes of the Trips Feat ure Class-----------------------------------------------21 Table 8 Attributes of the Shortest Path Feature Class ------------------------------------22 Table 9 Possible Combinations of Round-trip/One-way Preference --------------------24 Table 10 Possible Combinations of Driver/Passenger Preference ------------------------24 Table 11 Address Styles Perm itted by the Address Locator -------------------------------34 Table 12 Set Operations------------------------------------------------------------------------40 Table 13 Sorti ng the Matches -----------------------------------------------------------------41 Table 14 Overlapping Time Windows Test -------------------------------------------------52 Table 15 Recurrenc e Pattern Test -------------------------------------------------------------53

PAGE 5

iv List of Figures Figure 1 Representing Objects -----------------------------------------------------------------3 Figure 2 A Layer of Road Objects ------------------------------------------------------------4 Figure 3 A Layer of House Objects -----------------------------------------------------------4 Figure 4 A Layer of Airport Objects ----------------------------------------------------------5 Figure 5 Creating a Map from Layers --------------------------------------------------------5 Figure 6 A Typical User Interf ace for Entering a Trip Schedule -------------------------8 Figure 7 Syst em Architecture -----------------------------------------------------------------10 Figure 8 The User Inte rface -------------------------------------------------------------------13 Figure 9 Li ne Direct ion ------------------------------------------------------------------------19 Figure 10 Every Weekday ----------------------------------------------------------------------25 Figure 11 Every X Days ------------------------------------------------------------------------26 Figure 12 X Days On, Y Days Off ------------------------------------------------------------26 Figure 13 Every X Weeks on a Day of the Week -------------------------------------------27 Figure 14 1 st 2 nd 3 rd 4 th or Last Day of the Week of Every X Months -----------------28 Figure 15 Day Y of Every X Month(s) -------------------------------------------------------29 Figure 16 A Recurring Tr ip Without a Pattern -----------------------------------------------30 Figure 17 Overlappi ng Trip Dates -------------------------------------------------------------32 Figure 18 Overlappi ng Trip Times ------------------------------------------------------------33 Figure 19 Geocoding an Address -------------------------------------------------------------34

PAGE 6

v Figure 20 Calculating the Shortest Path ------------------------------------------------------35 Figure 21 Splitting the Pa th into Segments ---------------------------------------------------36 Figure 22 Creating Buffe rs ---------------------------------------------------------------------37 Figure 23 Appl ying Buffe rs --------------------------------------------------------------------39 Figure 24 The Shortest Path of the Dr iver ---------------------------------------------------42 Figure 25 The Shortest Path of the Passenger ------------------------------------------------42 Figure 26 Deviati ng from the Path ------------------------------------------------------------42 Figure 27 The Path from the Drivers Source to the Passengers Source ----------------43 Figure 28 The Path from the Passengers Source to the Passengers Destination--------43 Figure 29 The Path from the Passengers De stination to the Drivers Destination -----43 Figure 30 Two Houses Lie on Opposite Sides of a River ----------------------------------45 Figure 31 One Must Travel Over a Bridge to Get from One House to the Other -------45 Figure 32 The Path Around a Ri ver -----------------------------------------------------------45 Figure 33 Two Houses Lie on Opposite Sides of an Interstate ----------------------------46 Figure 34 One Must Travel to an Underpass to Get from One House to the Other -----46 Figure 35 The Path Ar ound an Inters tate -----------------------------------------------------46 Figure 36 A Users Shortest Path Includes Travel on an Interstate -----------------------47 Figure 37 A Match Lies Ne xt to the Interstate------------------------------------------------47 Figure 38 The User Must Get Back Onto the Interstate-------------------------------------47 Figure 39 Favoring the Di rection of Travel --------------------------------------------------48 Figure 40 Different Source, Same Destina tion Test -----------------------------------------51 Figure 41 Similar Source, Di fferent Destina tion Test --------------------------------------52

PAGE 7

vi A Geographic Information System for Dynamic Ridematching Sasha dos Santos ABSTRACT The Online Transportation Option System (OTOS) is a Geographic Information System (GIS) that addresses many of the lim itations associated with traditional dynamic ridematching applications. The main improveme nts are in the areas of trip scheduling and match searching. OTOS is unique in its ability to accept trips with schedules that can not be expressed in terms of a regular weekly trip. OTOS also distinguishes itself in its use of spatial analysis techniques to locate matches. Specifically, the use of a shortest path solver enables the ridematching algorithm to perform a search along the path of a users trip, in addition to the customary radial sear ch around the endpoints. The shortest path solver is also used to calculate the drivi ng distance between the user and a match. This provides a more accurate measurement than the straight-line distance used by other algorithms, especially in the presence of barriers.

PAGE 8

1 Chapter 1 Introduction 1.1 Background The Online Travel Option System (OTOS) is a project sponsored by the Center for Urban Transportation Research (CUTR) at the University of South Florida. The objective of the project is to help serve the transportation needs of the university community by promoting the concept of rideshar ing. Ridesharing refers to two or more people traveling together in the same vehicl e. The most common form s of ridesharing are carpooling and vanpooling. Carpools are arrangements of 2 4 people who travel in a personal vehicle. Vanpools are arrangements of up to 15 people who travel in a van. Ridesharing benefits the co mmunity by reducing traffic congestion and increasing the number of available parking spaces. OTOS acts as a ridematching system, matching individuals whose schedules and itinerarie s make them good candidates to form a carpool. 1.2 Geographic Information Systems The United States Geological Survey (U SGS) defines a Geographic Information System (GIS) as "a computer system capab le of assembling, storing, manipulating, and displaying geographically referenced informati on, i.e. data identified according to their

PAGE 9

2 locations. Practitioners also regard the total GIS as incl uding operating personnel and the data that go into the system. In a GIS, an object can be represented by a point, line, or polygon. For example, a house can be represented by a point, a road by a line, and an airport by a polygon (see Figure 1). An object may be associated with several descriptive attributes. For example, a house can be associated with its address, a road by its speed limit, and an airport with its name. The data in a GIS can be visualized on a map. A map consists of one or more layers. A layer is a collection of similar objects Each layer in a map represents a different view of the same geographic area. In this re spect, a layer is similar to a legend item on a paper map [1]. In Figures 2-5, a road layer, house layer, and airport layer are combined to form a map of Hillsborough County, FL. A GIS includes tools that can be used to perform spatial analysis, the study of the relationships between objects on a map. Using the map in Figure 5 as an example, the following tasks can be easily performed: Find the quickest path to get from House # 1 to House # 2 List the names of all roads that enter Tampa International Airport Count the number of houses that ar e within 1 mile from Platt Street

PAGE 10

Object Representation Figure 1 Representing Objects. Objects can be represented as points, lines, or polygons. 3

PAGE 11

Figure 2 A Layer of Road Objects Figure 3 A Layer of House Objects 4

PAGE 12

Figure 4 A Layer of Airport Objects Figure 5 Creating a Map from Layers. The result of overlaying the house, road, and airport layers. 5

PAGE 13

6 1.3 Dynamic Ridematching The Washington State Department of Transportation defines dynamic ridematching as an instant ridematching serv ice, usually provided via the internet. A survey of dynamic ridematching applications wi ll reveal that most follow the same basic algorithm: Ask the user for the day(s) of the week in which the trip will take place. Ask the user for the desired commute times. This is often done in terms of time to arrive at work and time to depart from work. (Optional) Ask the user if he would pref er to restrict the search to people who match a set of criteria. Common choices include: driver/passenger, male/female, smoking/non-smoking Ask the user for the address of his sour ce and destination. The user either types the address or selects one from a list. Convert the addresses into x and y coordinates (source and destination points). The coordinates can represent the actual a ddress or the centroid (center point) of the postal code or city. Draw a circle around the source and destination points. The radius of the circle is either hard-coded or set by the user. The ra dius is either a fixed (ex. 3 miles) or relative to the distance betw een the source and destinati on points (ex. 5 % of the total distance). Search for trips in the da tabase whose source and des tination points also reside within the circles.

PAGE 14

7 (Optional) Filter the results to include only those people who match the users trip schedule (day and time). Display the list of matches to the user. The match list often includes: 1) a description of the matchs trip schedule 2) the distance between the source points of the two trips, and 3) the distance between the des tination points of the two trips. If the results were not filtered in the previous step, the user must manually scan the list to see if anyone matc hes the users trip schedule. 1.4 Motivation In traditional ridematching a pplications, the user is presented with a very limited way of expressing his trip schedule. Figure 6 illustrates the typi cal user interface for entering a trip schedule. A trip entered in this fashion is assumed to take place on a weekly basis for as long as the trip re mains in the system (most applications automatically purge trips after some period of time). Two people do not need to have identical trip schedules in or der to be matched together. Fo r example, all other things being equal, if one person travels Monda y Friday and another travels Monday Wednesday, these people can be matched together. The problem with this approach is that it may be too restrictive to describe some users schedules. Some examples include: a trip that occurs on the first Monday of every month a trip that occurs every 2 days (regardless of the day of the week) a trip that only occurs once, on March 25, 2005

PAGE 15

Figure 6 A Typical User Interface for Entering a Trip Schedule In traditional ridematching applications, distances (ex. the distance between the source points of the user and match), are calculated by measuring the length of the straight line which connects two points. The problem with this approach is that it assumes that the straight-line distance is a good approximation for the actual driving distance between two points. Unless two points lie on the same street, the driving distance will always be greater than the straight-line distance. The difference between these distances can be quite large if two points lie on opposite sides of a barrier, such as a river or interstate. By definition, the presence of a barrier forces drivers to travel around it, possibly for miles, before reaching the other side. In traditional ridematching applications, the focus is placed solely on the source and destination points of the users trip. However, it is also possible to find matches that can be made along the path of the users trip. 8

PAGE 16

9 1.5 Objectives The system must be flexible enough to handl e a wide variety of trips, including: Frequent vs. Infrequent a full-time student with classes every week a part-time student with classes on the first Saturday of every month Recurring vs. One-time a student who goes to school every Wednesday a student who needs a ride home for the holidays Local vs. Long-Distance a student who travels from Tampa to St. Petersburg (a distance of 15 miles) a student who travels from Tampa to Orlando (a distance of 80 miles) One-way vs. Round-trip a student who would like to carpool with the same person to and from school a student who takes the shuttle to campus, but needs to carpool home The system should utilize GIS concepts to: calculate distances based on the actual path a driver would take, instead of relying on a strai ght-line distance allow for matches to be found along a users path provide researchers with the ability to visualize and analyze the data collected from users

PAGE 17

Chapter 2 System Architecture 2.1 Introduction The system architecture is illustrated in Figure 7. The architecture is based on a client/server model where a user communicates with the GIS via the Internet. A series of ASP.NET Web pages are used to collect information regarding the trip he would like to find matches for. A ridematching algorithm, implemented in Visual Basic .NET, searches for trips in the database which meet the users requirements. The results of the search are then instantly presented to the user. Figure 7 System Architecture 10

PAGE 18

11 2.2 Geodatabase The geodatabase stores the inputs and output s of the ridematching algorithm. The geodatabase is a model for storing and managing geographi c data using a relational database. It is based on a multitier arch itecture where an underlying database management system (DBMS) is responsible for the storage and retrie val of data, and an application tier, ArcSDE, is responsible fo r enforcing behavior and integrity rules. ArcSDE works with the DBMS to manage th e storage, indexing, acce ss, and editing of data. ArcSDE provides an interface by which applications can access the underlying database. This allows a developer to work w ith the high-level GIS da ta structures without concern for how they are implemented in a part icular database platfo rm [1]. OTOS uses Microsoft SQL Server 2000. The contents of the geodatabase are discussed in Chapter 3. 2.3 GIS Server ArcGIS Server is a platform for building GIS applications that are accessible via the Internet. It includes a Web Application Developer Framework (ADF) for building Web pages that make use of ArcObjects. ArcObject s is a library of software components (COM classes) that allow developers to incorporate GIS functionality into their Web pages or desktop applications [2]. The OT OS Web site consists of ASP.NET pages written in Visual Basic.NET.

PAGE 19

12 2.4 Web Server The Web server hosts the Web pages that ac t as the user interface for the system. The ArcGIS Server ADF includes a Web applic ation runtime that is installed on the Web server. The runtime allows the Web server and GIS Server to communicate with each other. When a user requests a Web page that makes use of ArcObjects, the Web server creates and uses objects that run in the GIS Server [2]. OTOS uses the Internet Information Services (IIS) Web server. 2.5 User Interface The user interacts with the GIS through a series of Web pages (see Figure 8). The pages perform these basic functions: Collect information from the user and enter it into the geodatabase Use ArcObjects to perform the ridematching algorithm Display the results of th e ridematching algorithm Allow a user to e-mail a match for the purpose of setting up a carpool

PAGE 20

Figure 8 The User Interface 2.6 System Administration The system administrator is responsible for maintaining the system. The database and Web server are administered using their built-in tools. For SQL Server 2000 and IIS, these tools are SQL Server Enterprise Manager and IIS Internet Services Manager, respectively. ArcGIS Desktop is a suite of three applications, ArcCatalog, ArcMap, and ArcToolbox, which are used to create, manage, view, and edit geographic data [1]. 13

PAGE 21

14 Chapter 3 The Geodatabase 3.1 Introduction The geodatabase is a repository for all of the data collected by the user and output by the ridematching algorithm. The geodatabase is populated with tables that either explicitly or implicitly refer to geographic objec ts. These tables are related to each other through the use of common attribut es. Only the most relevant ta bles are discussed here. Tables with an explicit geographic referen ce use GIS data structures to represent objects. A feature represents an object as a row in a table. Ea ch feature has an associated shape attribute that describe s a point, polyline, or polygon. Common attributes associated with features include length, area, elevation, and name. A feature class is a collection of features and is stored as one table in the geodatabase. All of the features in a feature class have the same shape and represent the same type of object. The feature class is the implementation of the layer concept described in Secti on 1.2. A feature dataset is a collection of conceptually related feature clas ses. All of the feature classes used by the ridematching algorithm are stored in one feature dataset [1]. Tables with an implicit geographic refere nce describe, rather than represent, geographic objects [1]. Several of the tables in the geodatabase store descriptions of the users and the trips they would like to find matches for. The majority of this data is collected through the user interf ace. These tables implicitly refe r to feature classes in the

PAGE 22

15 geodatabase. For example, the geodatabase co ntains a table, Locations, which stores addresses. An address can be represented as a point in a feature class named Trips. Therefore, a record in the Locations table desc ribes a feature in the Trips feature class. Relationships among tables are create d using keys. A primary key uniquely identifies a record in a table. A foreign key is an attribute in one table that refers to the primary key of another table. For example, th e Trips feature class contains an attribute, Trip ID, which is the primary key for the Shortest Path feature class. The use of the Trip ID attribute creates a relations hip between the Trips and Shortest Path feature classes. Most of the tables and feature classes are related through the use of a Trip ID attribute. 3.2 Locations Table The Locations table stores the addresse s of source and dest ination points (see Table 1). Each location is asso ciated with a particular user and can be associated with several of the users trips. Th e table stores a location as a st reet address and as its x and y coordinates. Table 1 Attributes of the Locations Table Attribute Description Location ID Primary key User ID The user associated with this location. Location Description A name give n to this location by the user. Address The street address of this location. City The city where this location resides. State The state where this location resides. Zip Code The zip code or postal code of this location. X-Coordinate The x-coordinate. Y-Coordinate The y-coordinate.

PAGE 23

16 3.3 Trips Table The Trips table describes the trips that are taken by the users (see Table 2). Each trip is associated with tw o locations, source and destin ation. Once the ridematching algorithm determines the shortest path from source to destination, it st ores the length of this path in the table. Each trip has a time window, a time interval in which the user would like to arrive at his destination. Table 2 Attributes of the Trips Table Attribute Description Trip ID Primary key User ID The user associated with this trip. Trip Description A name give n to this trip by the user. Carpool Type Indicates if the user pref ers to be a driver or passenger. Source Location The Location ID for the source of the trip. Destination Location The Location ID for the destination of the trip. Roundtrip Indicates if the user would like to travel from the source to the destination and then back to the source. Recurring Indicates whether this trip occurs once or on a regular basis. Active Indicates if the user is still looking for matches for this trip. Earliest Arrival Time The earliest time that the user can arrive at the destination. Latest Arrival Time The latest time that the user can arrive at the destination. Earliest Departure Time The earliest time that the user can depart from the destination. This attribute is empty for one-way trips. Latest Departure Time The latest time that the user can depart from the destination. This attribute is empty for one-way trips. New Trip Indicates whether the ride matching algorithm has been run on this trip. Length The length of the shortest path from source to destination, as determined by the ridematching algorithm.

PAGE 24

17 3.4 Calendar Table The Calendar table is used, much like its namesake, to list and describe the days of the year (see Table 3). Table 3 Attributes of the Calendar Table Attribute Description Date The calendar date associ ated with this record. Weekday The value of this attribute is 1 if this date is a weekday. Year The year part of the date Month The month part of the date. Day of the Week The day of the w eek: M, T, W, Th, F, S, or Sun Week of the Year A number designating the week of the year th at this date takes place. 3.5 Trip Schedules Table The Trip Schedules table is used to store each occurrence of a trip (see Table 4). For example, a trip that is scheduled for ever y Friday in March will be associated with 4 records in the table. One of these records w ill correspond to the trip that occurs on Friday March 25. Table 4 Attributes of the Trip Schedules Table Attribute Description Trip ID The trip associat ed with this record. Earliest Arrival The earliest date and time that the user can arrive at the destination. Latest Arrival The latest date and time that the user can arrive at the destination. Earliest Departure The earliest date and time that the user can depart from the destination. This attribute is empty for one-way trips. Latest Departure The latest date and ti me that the user can depart from the destination. This attribute is empty for one-way trips.

PAGE 25

18 3.6 Matches Table The Matches table (see Table 5) stores the results of the ridematching algorithm. Each record in this table represents two users whose travel patterns make them ideal candidates to form a carpool. Table 5 Attributes of the Matches Table Attribute Description Match ID Primary key Trip ID 1 A trip that is similar in sc hedule and path to the trip represented by Trip ID 2. Trip ID 2 A trip that is similar in sc hedule and path to the trip represented by Trip ID 1. Source Difference The distance between the source points of the two trips. Destination Difference The distance between the destination points of the two trips. Path Length The length of the shortest path that incorporates the source and destination points of the two trips. 3.7 Roads Feature Class The ridematching algorithm requires a feature class that represents roads (interstates, highways, city st reets) as lines. This polyline feature cl ass is the foundation for all the spatial analysis done by the algorithm. Each feature has a shape attribute that stores the coordinates of the line. One endpoint of the line is regarded as the starting point and the ot her as the endpoint. This is to give the lines a sense of dir ection. The right and left portions of the road are relative to this sense of direction (see Figure 9). The dire ction is not related to the flow of traffic on the road [3].

PAGE 26

Left Side 19 Start Point End Point Right Side Figure 9 Line Direction Table 6 lists the attributes that the feature class is required to have. This is not a literal representation the actual storage is dependent on the company or agency that compiles the data. OTOS uses the Dynamap/Block Boundary v4.2 County Tile compiled by Geographic Data Technology [3]. Table 6 Attributes of the Roads Feature Class Attribute Definition Shape The coordinates of the line. Shape Length The length of the line. Length The length of the line in units consistent with that of the Speed Limit attribute. Speed Limit The maximum legal speed for traveling on the road. Cost of Travel Calculated by dividing the Length by the Speed Limit. This is set to -1 if travel in a direction is prohibited. Name One or more names associated with the road. House Addresses The range of house addresses on each side of the road. Zip Codes The zip code on each side of the road. Most commercially available data, including Dynamap, uses a geographic coordinate system. This system represents the earth as a spheroid. A point is represented by a longitude and latitude, which are the angles the point makes with the center of the earth. Degrees of longitude and latitude do not have a standard length across the earths surface and, therefore, should not be used to calculate distances, such as the length of a

PAGE 27

20 path. To overcome this difficulty, the data must be projected onto a two-dimensional surface using tools available in ArcGIS Desk top. A map projection uses a formula to transform spherical coordinates to planar coordinates. There are several projections available and each will cause distortions in shape, area, distance, or direction. It is important that a projection be chosen that minimizes the distorti on in the particular geographic area of study. The projection chosen for the Roads feature class is Universal Transverse Mercator North American Datu m 1983 Zone 17. This projection minimizes the distortion for the state of Fl orida (the panhandle region is slightly more distorted than the rest of the state) [4]. Because all of th e feature classes in the geodatabase participate in the same feature dataset, they must all use the same projection. 3.8 Address Locator and Place Name Alias Table The term geocoding refers to associating an address with x and y coordinates. It is accomplished using ESRIs built-in geocoding engine. The engine requires an address locator, a table in the geodatabase that spec ifies the types of addresses that can be matched and the reference data they are to be matched against. This table is created using tools available in ArcGIS Desktop [5]. Landmarks are geocoded with the assistance of a place name alias table. The table consists of two attri butes, Name and Address, which associates the name of a landmark with an address. This address can then be geocoded in the usual manner. The alias table contains airports, hospitals, malls stadiums, theatres, universities, and local

PAGE 28

21 attractions. Because the alia s table is manually created, only landmarks that are commonly referenced by the user group are included. 3.9 Trips Feature Class The Trips feature class (see Table 7) st ores the geocoded source and destination points of all the trips in the Tr ips table. This feature class is related to most of the user profile tables by the Trip ID attribute. Table 7 Attributes of th e Trips Feature Class Attribute Definition Object ID Primary key Shape The coordinates of this point. Trip ID The unique Trip ID associated with this trip. This is a foreign key linking this class with the Trips table. Class S if this point represents the source point. D if this point represents the destination point. 3.10 Geometric Network The Geometric Network is a data structure that stores the connectivity of features in the Roads feature class. In th e terminology of networks, each edge represents a road. The intersection of two or more roads is a junction [6]. A weight is a number that represents the co st of traversing an edge. Each edge is associated with two weights corresponding to the two ways of traver sing the edge. In the majority of cases, these weights are identical and equal to the length of the edge divided by its speed limit. Edges representing one-way roads are given a weight of -1 in the direction in which the road is impassable [7].

PAGE 29

22 3.11 Shortest Path Feature Class The Shortest Path feature class (see Table 8) stores the shortest path between two points (source and destination) in the Trips f eature class. This path is calculated by the ridematching algorithm. The algorithm splits the path into three line segments, so one trip is associated with three features. Table 8 Attributes of the Shortest Path Feature Class Attribute Definition Object ID Primary key Shape The coordinates of this line segment. Shape Length The length of the line segment. Trip ID The unique Trip ID associated with this trip. This is a foreign key linking this class with the Trips table.

PAGE 30

23 Chapter 4 Ridematching Algorithm 4.1 Introduction The ridematching algorithm searches the ge odatabase for individuals with similar schedules and itineraries. The algorithm is based on the basic algorithm described in Section 1.3, but with the following enhancements: Flexibility to accept any type of trip schedule Ability to search for matche s along the path of a trip Ability to calculate driving distances A user is asked to input a trip profile consisting of the sour ce and destination points, trip schedule, and other preferences. The algorith m will search for matches by comparing the users profile with those of othe r trips. The term 'match' is used to refer both to a trip in the geodatabase and the person associated with the trip. Initially, the search space consists of all the trips in the geodatabase The algorithm reduces the search space by applying a set of rules to reje ct potential matches. The rule s are presented here in the order in which they are applied. 4.2 Using Round-trip/One-way Prefer ence to Reduce the Search Space In a typical scenario, the user travels fr om the source to the destination and then returns back to the source at some later date or time. A round-trip requires that a match be

PAGE 31

24 available for both portions of the trip. In a one-w ay trip, the user is a) not returning to the source, b) not interested in carpooling for th e return trip, or c) not concerned with carpooling with different people on each portion of the trip. The search space is reduced based on the rules in Table 9. Table 9 Possible Combinations of Round-trip/One-way Preference User Potential Match Accepted? Round-trip One-way No Round-trip Round-trip Yes One-way One-way Yes One-way Round-trip No 4.3 Using Driver/Passenger Preference to Reduce the Search Space Users are given the option of limiting the search to only finding drivers or only finding passengers. If a preference is give n, the search space is reduced based on the rules in Table 10. Table 10 Possible Combinations of Driver/Passenger Preference User Potential Match Accepted? Driver Driver No Driver Passenger Yes Passenger Driver Yes Passenger Passenger No

PAGE 32

4.4 Using Trip Schedules to Reduce the Search Space A one-time trip is a trip that the user intends to make only once. The user may select a date (ex. April 4) or range of dates (ex. April 3 through April 5) when the trip can take place. A recurring trip is a trip that occurs more than once. In the majority of cases, a recurring trip occurs at regular intervals that can be modeled by a pattern. The length of an interval can be expressed in terms of days, weeks, or months. A user can describe these intervals by selecting from a list of recurrence patterns. Figures 10 15 lists each pattern along with an illustrative example. A trip that does not follow a pattern, but occurs more than once, can be entered on a day by day basis (see Figure 16). February 27 Sunday Monday Tuesday Wednesday Thursday Friday Saturday 28 March 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 April 1 2 March 2005 Figure 10 Every Weekday. Every weekday starting with March 1st 25

PAGE 33

February 27 Sunday Monday Tuesday Wednesday Thursday Friday Saturday 28 March 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 April 1 2 March 2005 Figure 11 Every X Days. Every 4 days starting with March 1st February 27 Sunday Monday Tuesday Wednesday Thursday Friday Saturday 28 March 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 April 1 2 March 2005 Figure 12 X Days On, Y Days Off. 3 days on, 2 days off starting with March 1 st 26

PAGE 34

February 27 Sunday Monday Tuesday Wednesday Thursday Friday Saturday 28 March 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 April 1 2 March 2005 Figure 13 Every X Weeks on a Day of the Week. Every 2 weeks on a Monday or Wednesday 27

PAGE 35

Figure 14 1 st 2 nd 3 rd, 4 th or Last Day of the Week of Every X Months. 1st Wednesday of every 1 month 28

PAGE 36

Figure 15 Day Y of Every X Month(s). The 1 st day of every 1 month 29

PAGE 37

February 27 Sunday Monday Tuesday Wednesday Thursday Friday Saturday 28 March 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 April 1 2 March 2005 Figure 16 A Recurring Trip Without a Pattern. The user enters the dates one by one. Each trip is associated with a time window, (Earliest Arrival Time, Latest Departure Time), in which the user would like to arrive at his destination. The size of this window can be expressed in terms of minutes or hours. The largest possible window is 23 hours, 59 minutes. The following are examples of possible time windows: (8:45 AM, 9:00 AM), (9:00 AM, 11:00 AM), and (10:00 PM, 2:00 AM). A round-trip is also associated with a second window, (Earliest Departure Time, Latest Departure Time), in which the user would like to depart for the return trip. A trip instance is defined as a specific occurrence of a trip. One-time trips are associated with one instance, while recurring trips are associated with several. For example, if a user travels to work every weekday, each week is associated with 5 30

PAGE 38

31 instances, one for Monday, Tuesday, etc. A trip instance is stored as one record in the Trip Schedules table. To reduce the search space, the Trip Schedules table is queried to locate overlapping trip instances. The trips that wi ll remain in the search space are those trips where at least one instance overlaps with an instance of the users tri p. It is important to emphasize that two trips do not have to have similar recurrence patter n in order to match. Figure 17 illustrates a scenario where two trip s have different recurrence patterns, but can still carpool on selected date s (instances). Trip 1, show n in red, takes place every Monday, Wednesday, and Friday. Trip 2, shown in blue, has a three days on, two days off pattern. Even though the recurrence patterns are different, the two trips have several dates in common when they could carpool (provided that both trip s meet all the other criteria to match). Figure 18 illustrates a scenario where several trip instances take place on March 25, 2005. Since the date is the same for each trip instance, only the time is considered in this example. A match can be made between 2 & 3, 3 & 4, or 3 & 5.

PAGE 39

February 27 Sunday Monday Tuesday Wednesday Thursday Friday Saturday 28 March 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 April 1 2 March 2005 Figure 17 Overlapping Trip Dates. One recurrence pattern is illustrated in red, the other in blue. 32

PAGE 40

Friday March 25, 2005 12 00 PM 12 30 PM 1 00 PM 1 30 PM 2 00 PM 2 30 PM 3 00 PM 1 3 30 PM 4 00 PM 4 30 PM 5 00 PM 5 30 PM 6 00 PM 6 30 PM 7 00 PM 7 30 PM 8 00 PM 8 30 PM 9 00 PM 10 00 PM 10 30 PM 11 00 PM 11 30 PM 4 2 3 5 Figure 18 Overlapping Trip Times 4.5 Geocoding the Source and Destination The addresses of the users source and destination can take the form of a house address, a street intersection, or a landmark (see Table 11). An address locator (as described in Section 3.8) is used to geocode the addresses into their x and y coordinates (see Figure 19). Addresses are geocoded by referencing the attributes of the Roads feature class. The attributes used are House Addresses, Zip Codes, and Name. The 33

PAGE 41

address locator is able to associate an address with a location relative to the start and end points of the line (ex. left side of the road, at a distance of 1 mile from the start point). Table 11 Address Styles Permitted by the Address Locator Address Style Example House Address 14535 Fletcher Ave. Tampa, FL 33613 Street Intersection Fowler Ave. & Skipper Road Tampa, FL 33613 Landmark University of South Florida 34 145 McKinley Drive Tam p a FL 33620 (a) A house is associated with an address. 145 McKinley Drive Tam p a FL 33620 (b) The address locator associates an address with a point on the earths surface. Figure 19 Geocoding an Address

PAGE 42

4.6 Finding the Shortest Path Dijkstras shortest path algorithm is used on the Geometric Network to calculate a path from source to destination (see Figure 20). This path represents the quickest way for the user to get from the source to the destination based on the weight of each edge. Recall from Section 3.10 that the weight is equal to the time it takes to traverse an edge in a specified direction. The shortest path solver is biased towards main roadways and highways because of their relatively high speed limit. A weight of -1 signifies that travel is not permitted in the specified direction. The shortest path solver regards a negative weight as a barrier and does not attempt to traverse the road in the specified direction. Source Source Destinatio n Destinatio n (a) Initial conditions (b) The shortest path is shown in red. Figure 20 Calculating the Shortest Path The shortest path is split into three segments (see Figure 21). The first segment represents the first 15% of the path. The second segment represents the middle 70% of the path. The third segment represents the final 15% of the path. The segments are stored in the Shortest Path feature class. 35

PAGE 43

Source Destina tion (a) Segment 1 represents the first 15% of the path. Source Destina tion (b) Segment 2 represents the middle 70% of the path. Source Destina tion (c) Segment 3 represents the last 15% of the path. Figures 21 Splitting the Path into Segments. The segments are highlighted in blue. 36

PAGE 44

4.7 Creating Buffers The next step is determining those trips in the search space whose source and destination are close to that of the user. Close is a relative term that, by default, is based on a percentage of the total length of the path. This allows the algorithm to scale to both local and long-distance trips. A buffer is a zone of a specified distance around a feature (see Figure 22). (The distances discussed here are the default distances.) Buffer 1 is applied around the source point with a radius of 15% of the path length. For example, if the total length of the path is 10 miles, the first buffer will represent a radial search of 1.5 miles. Buffer 2 is applied around Segment 2, the middle 70% of the path, with a radius of 5% of the path length. For a path of 10 miles, this buffer will represent half a mile on either side of the path. Buffer 3 is applied around the destination point with a radius of 15% of the path length. Buffer 1 Buffer 2 Buffer 3 Figure 22 Creating Buffers 37

PAGE 45

38 4.8 Using Buffers to Reduce the Search Space The Trips feature class is queried to find the Trip IDs of potential matches. Each query consists of a spatial element and an attribute element. The spatial element corresponds to one of the buffers. The attribute element will be either class = S for source or class = D for destin ation. The current users sour ce and destination point are excluded from the search. The result of each query is stored in a selection set. Set 1 contains those features that are in Buffer 1 and which represent a source. Set 2 contains those features that are in Buffer 2 and whic h represent a source. Set 3 contains those features that are in Buffer 3 and which re present either a source or destination. Using a series of set operations, the sear ch space is reduced and a match list is created. The first step is to deal with the ove rlap of Buffers 2 and 3. Any source that lies within Buffer 3 should not be considered as a potential match, even if it resides in the intersection of Buffers 2 and 3. A set difference, S2 S3, is used to remove from Set 2 those elements which are also in Set 3. The union of Set 1 and Set 2, S1 S2, results in a new set whose elements are features which re present a source. Set 3 is queried to find features whose Trip ID is e qual to one of the Trip IDs f ound in the union. These trips form the match list. This process is illustrated in Figure 23 and Table 12.

PAGE 46

Destinatio n Source Figure 23 Applying Buffers Shown here is the Roads feature class (in light blue), Shortest Path feature class (in red), Trips feature class (in green), and the buffers (in light gray). Each feature in Trips is represented as an ordered triple -(Object ID, Trip ID, Class). The TripID of the users trip is 162. All the trips are assumed to match the users schedule. 39

PAGE 47

40 Table 12 Set Operations Set Features (Object ID Trip ID, Class) Set 1 (471 305 S) Set 2 (447 301 S) (449 302 S) (451 303 S) (454 304 S) Set 3 (449 302 S) (452 303 D) (453 304 D) S2 S3 (447 301 S) (451 303 S) (454 304 S) S1 S2 (447 301 S) (451 303 S) (454 304 S) (471 305 S) Trips in S3 whose TripID matches a TripID in S1 S2 (452 303 D) (453 304 D) 4.9 Sorting the Matches The matches are stored in the Matches ta ble and are presented to the user as a sorted list. By default, the matches are sorted in the order that they are presented in Table 13. The matches are sorted based on the firs t criterion and then subsequent criteria are used as tiebreakers. For example, if two matches are equal in the Number of Trip Instances, then they will be sorted by their Pa th Deviation, and if this is also equal, by the

PAGE 48

41 Preferred Arrival Time, etc. At the users request, anothe r criterion may serve as the primary criterion. In this case, the Number of Trip Instances will serve as the first tiebreaker, and so on. Table 13 Sorting the Matches Criterion Definition Number of Trip Instances The number of trips instances that the user and match have in common Path Deviation An estimate of the distance the driver will cover to travel to the passengers source and destination. Preferred Arrival Time The time difference be tween the preferred arrival times of the user and match. Preferred Departure Time The time difference between the preferred departure times of the user and match. This criteri on is only used for round-trips. Age of Record The length of time since the matchs trip was entered into the geodatabase. 4.10 Calculating the Path Deviation The path deviation is an estimate of the di stance the driver will cover to travel to the passengers source and des tination (see Figures 24 26). Th e term driver is based on the users driver/passenger preference. The path deviation is the difference between the lengths of the drivers shorte st path and the new path that is required to pick up the passenger and drop him off. The new path is ca lculated in three step s (see Figures 27 29). Length 1 is the length of the shortest path from the drivers source to the passengers source. Length 2 is the length of the shorte st path between the passengers source and the passengers destination. Length 3 is the length of the shortest path from the passengers destination to the drivers destination.

PAGE 49

Source Destinatio n Figure 24 The Shortest Path of the Driver Source Destinatio n Figure 25 The Shortest Path of the Passenger Figure 26 Deviating from the Path 42

PAGE 50

Drivers Source Passengers Source Figure 27 The Path from the Drivers Source to the Passengers Source Passengers Source Passengers Destination Figure 28 The Path from the Passengers Source to the Passengers Destination Passengers Destination Drivers Destination Figure 29 The Path from the Passengers Destination to the Drivers Destination 43

PAGE 51

44 Calculating Length 1 and Lengt h 3 using shortest paths has several advantages over relying on the straight-line distance between features. A straight-line distance can be deceiving because it can not take into account ba rriers. A barrier can be either natural or man-made and impedes travel. Consider the following scenarios: Two houses lie on opposite sides of a river. To travel from one house to the other requires traveling to a bridge and cr ossing the river (see Figures 30 32). Two houses lie on opposite sides of an inters tate. To travel from one house to the other requires traveling to an underpass (see Figures 33 35). A users path requires travel on an inters tate. A match lies next to the interstate. The straight-line distance from the match to the interstate is negligible. However, the user must actually travel to the neares t exit, pick up the match, and travel back to the interstate before continuing his trip (see Figures 36 38).

PAGE 52

Source Destinatio n Figure 30 Two Houses Lie on Opposite Sides of a River Bridge Figure 31 One Must Travel Over a Bridge to Get from One House to the Other Source Destinatio n Figure 32 The Path Around a River 45

PAGE 53

Source Destinatio n Figure 33 Two Houses Lie on Opposite Sides of an Interstate 46 Underpass Figure 34 One must Travel to an Underpass to Get from One House to the Other Source Destinatio n Figure 35 The Path Around an Interstate

PAGE 54

Source Destinatio n Figure 36 A Users Shortest Path Includes Travel on an Interstate Source Match Exit Figure 37 A Match Lies Next to the Interstate Match Entrance Destinatio n Figure 38 The User Must Get Back Onto the Interstate 47

PAGE 55

The inclusion of Length 2 in the path deviation is to favor those matches that lie in the direction of the drivers travel. Consider a scenario where a driver and two passengers, Passenger A and Passenger B, have the same destination. The source points of the passengers lie at an equal distance on either side of the driver. This scenario is illustrated in Figure 39. Lengths 1 and 3 will be identical for both passengers. However, if Passenger B lies in the direction that the driver would normally travel and Passenger A lies in the opposite direction, these passengers will not have the same path deviation because Length 2 for Passenger B will be smaller than Length 2 for Passenger A. The path deviation for Passenger A is X + (2X+Y) + 0. The path deviation for Passenger B is X + Y+ 0. All other things being equal, if the driver must choose one passenger, Passenger B is the clear choice because the path deviation is smaller. 48 Figure 39 Favoring the Direction of Travel. Passengers A and B are equidistant from the driver, but B is a better match because he is in the direction the driver normally travels. A B Driver Destina tion X X Y

PAGE 56

49 4.11 Implementation The algorithm can be logically br oken into the following tasks: Geocode the source and destination point s: Geocoding is accomplished using the ArcObjects Location COM class. Translate the recurrence pattern into a list of calendar dates: ASP.NET pages (written in Visual Basic.NET) are respons ible for translating the input from the user into the search criteria for a SQL SELECT statement. The SQL SELECT statement is used to query the Calendar table for the actual dates which satisfy the recurrence pattern. Some of these queries make use of User Defined Functions (UDFs) that execute inside the SQL Serv er and return a value to the SELECT statement. UDFs are used to find the la st day of a month and to find the Nth occurrence of a day of the week (ex. last Monday in March, 2005). Find overlapping trip instances: Overlapping trip instances are determined using a UDF that compares each trip instance of the users trip with all of the other instances in the Trip Schedule table. Find the shortest path between two points: Shortest paths are calculated using the ArcObjects Network Analysis COM class. Create buffers and work with selection sets : Buffers and selection sets are parts of the ArcObjects Geodatabase COM class. Sort the match list: The match list is so rted using the SQL ORDER BY clause. The order in which attributes are to be sorted is specified by the user and the appropriate version of the ORDER BY clause is used.

PAGE 57

50 Chapter 5 Evaluation 5.1 Introduction OTOS was tested under several different sc enarios to assess its ability to perform the tasks described in the last chapter. Each scenario tested one aspect of the ridematching algorithm. For example, one scen ario tested the ability of the algorithm to find matches with overlapping time windows. All other variables (s ource, destination, recurrence pattern, etc.) were kept constant wi thin the set so that only the variable in question would determine the match list. For each scenario, an expected match list was created by manually reducing the search space. Fo r all of the scenarios, the algorithm had a 100% success rate when compared to the expected match list. The following sections describe each scenario. 5.2 Different Source, Same Destination The variable of interest is the sour ce point. Figure 40 shows the source points scattered throughout the map and labeled with th eir Trip ID numbers. All of the trips share the same destination point. Though all of the trips will ma tch based on Buffer 3, only those that are also present in Buffer 1 should be listed in the final match list.

PAGE 58

Destinatio n Figure 40 Different Source, Same Destination Test 5.3 Similar Source, Different Destination The variable of interest is the destination point. Figure 41 shows that the source point of every trip resides in the same general area, but the destination points are scattered throughout the map. Though all of the trips will match based on Buffer 1, only those that are also present in Buffer 3 should be listed in the match list. 51

PAGE 59

Source Points Figure 41 Similar Source, Different Destination Test 5.4 Overlapping Time Windows The variable of interest is the time window. Table 14 shows a small subset of the test data. The only trips that can match with each other are those with overlapping time windows. In Table 14, only trips 1 and 4 can produce a match. Table 14 Overlapping Time Windows Test # Earliest Arrival Latest Arrival Earliest Departure Latest Departure 1 7:30 a.m. 8:00 a.m. 4:45 p.m. 5:15 p.m. 2 4:45 a.m. 5:00 a.m. 7:45 p.m. 8:15 p.m. 3 7:45 p.m. 8:15 p.m. 4:45 a.m. 5:15 a.m. 4 8:00 a.m. 9:00 a.m. 5:00 p.m. 5:30 p.m. 52

PAGE 60

53 5.5 Recurrence Pattern The variable of interest is the recurr ence pattern. Table 15 shows a small subset of the test data. The only trips that can ma tch with each other are those that can take place within the same day and time. The star t and end dates of the recurrence are set to March 1, 2005 and April 1, 2005, respectively. For this period of time, trips 1, 2, 3, and 4 can match. Trip 5 does not have a match. Table 15 Recurrence Pattern Test # Recurrence Pattern 1 MWF every week 2 MTWRF every week 3 MW every 2 weeks 4 3 days on 3 days off 5 5 th day of every 1 month

PAGE 61

54 Chapter 6 Conclusions and Future Work 6.1 Conclusions The Online Transportation Option System (OTOS) is a Geographic Information System (GIS) that addresses many of the lim itations associated with traditional dynamic ridematching applications. The main improveme nts are in the areas of trip scheduling and match searching. OTOS is unique in its ability to accept trips with schedules that can not be expressed in terms of a re gular weekly trip. The ridematching algorithm can accept recurrence patterns expressed in terms of days, weeks, or months. The algorithms flexibility is due to the fact that a trips recurre nce pattern is translated into a series of trip instances. While traditional algorithms ar e designed to compare recurrence patterns, the OTOS ridematching algorithm compares individual trip instances. This allows users with different recurrence patterns to be matched together. OTOS distinguishes itself in its use of spatial analysis techniques to locate matches. The use of a shortest path solver enables the ridematching algorithm to calculate the shortest path from a users source to destination and th en perform a search along that path. This is in addition to the customary ra dial search around the endpoints. In the worst case, the algorithm will find the same matches that a traditional algorithm would. In the best case, the algorithm is able to find a dditional matches by looking along the path.

PAGE 62

55 OTOS introduces the idea of path deviati on as a factor when ranking or sorting match lists. The path deviation is an accurate measurement of the distance between the user and the match. OTOS bases its distan ce measurements on the driving distance, calculated by the shortest path solver, instea d of the straight-line approximation used by other algorithms. The advantage of such an appr oach is that it take s into account barriers and can be used to favor matches th at lie in the direction of travel. OTOS also provides transportation resear chers with the abil ity to analyze and visualize the data collected by the user. Researchers can access the contents of the geodatabase using the ArcGIS desktop suite. 6.2 Future Work While the focus so far has been on carpoo ling, the application can be extended to support vanpooling, as well. One possible st rategy is to periodically use the ArcGIS software to visualize the spat ial distribution of the trips in the geodatabase and have a person look for a cluster of individuals who are all traveling in the sa me direction at the same time. Another strategy is to build a vanpooling algorithm that will locate these clusters programmatically.

PAGE 63

56 References [1] What is ArcGIS?, Redlands, California: ESRI 2004. [2] ArcGIS Server Administrator and Deve loper Guide, Redlands, California: ESRI 2004. [3] Dynamap/Transportation User Manua l Version 4.3, Geographic Data Technology 2002. [4] Map Projections, Coordinate Systems, and Datums, [Online Document], Available at: http://www.sit.ecu.edu/planni ng/Burne/GIS/MapProjections.htm [5] The ArcGIS Network Model, [Online Document], Available at: http://arcgisdeveloperonline.esri.com/Arc GISDeveloper/default.asp?URL=/ArcGISDevel oper/ArcGISDevHelp/TechnicalDocuments /Network/ArcGISNetworkModel/ArcGISNet work.htm [6] The ArcGIS Network Weight Model, [Online Document], Available at: http://arcgisdeveloperonline.esri.com/Arc GISDeveloper/default.asp?URL=/ArcGISDevel oper/ArcGISDevHelp/Technica lDocuments/Network/ArcGI SNetworkWeight/NetworkW eights.htm

PAGE 64

57 Bibliography [1] M. Haselkorn, J. Spyridakis, C. Blumenth al, S. Michalak, B. Goble, and M. Garner, Bellevue Smart Traveler: Design, Demons tration, and Assessment. Report WA-RD 376.1. Technical Report, Washington State DOT, August 1995. [2] D.J. Dailey, D. Loseff, D. Meyers, and M.P. Haselkorn, Seattle Smart Traveler. Proceedings of the Transportation Research Board Annual Meeting January 1997. [3] D.J. Dailey, D. Loseff, D. Meyers, S eattle Smart Traveler: Dynamic Ridematching on the World Wide Web. Transportation Research C Vol. 7, pp.12-32, 1999. [4] J. Rodriguez, Ridematch System 21: Using Vector-Based Matching to Direct Ridematching Activities. Wo rking Paper, November 2003. [5] J. Rodriguez, Ridematch System 21: Th e Role of User Feedback in the Design and Implementation of Registration, Matching a nd Administrative Subsystems, Working Paper, Chicago Area Tr ansportation Study, May 2004. [6] M. Rose and I. Von Essen, Using ArcView to Enhance Regional Mobility Through Ridematching. Proceedings of the Seventeenth Annual ESRI User Conference July 1997.