Automatic Route-based Ridesharing on the Web

8/12/2019 Automatic Route-based Ridesharing on the Web

1/16

dinoride 1

dinoride: Automatic Route-based Ridesharing on the Web

Benjamin Carl Mearns

University of Pennsylvania


2/16

dinoride 2

Abstract

In the United States, interest in intercity automobile ridesharing abounds, as evidenced by

the large number of dedicated on and offline resources. Contemporary domestic travelers face

significant incentives to share rides with others passing along similar routes, amidst mounting

concern over inflating fuel prices, global warming, oil dependency, traffic congestion, and

airborne terrorism. This brief paper describes a web-based application, dinoride, which aims to

fill the need for a web-based centralized, automated, user-friendly rideshare application. The

rapid growth in availability of structured data -- such as the Craigslist RSS used by Dinoride --

has made it possible for the urban planning professional to implement user-focused solutions

leveraging vast sources of information, hitherto unavailable. Dinoride is unique in the tiny but

fast growing field of web-based ridesharing for its ability to access this type of information, as

well as for its implementation of a spatial algorithm better suited to the American ridesharing

landscape: relatively sparse residential settlement, many alternate routes, few available shares,

and long distances of travel. Dinoride will benefit further from refinement of routing and

matching rules, expansion of the data model, and extension of the user interface.


3/16

dinoride 3

dinoride: A Dynamic Web Ridesharing Application

In the United States, interest in intercity automobile ridesharing abounds, as evidenced by

the large number of dedicated on and offline resources. Contemporary domestic travelers face

significant incentives to share rides with others passing along similar routes, especially amidst

mounting concern about inflating fuel prices, global warming, oil dependency, traffic congestion,

and airborne terrorism. However, despite both high demand for connecting parallel travelers,

and booming social networking via the internet, available solutions do not fit the criteria of

centralized, automated, and user-friendly. This brief paper describes a web-based application,

dinoride (http://www.dinoride.com), which aims to fill an apparent public need.

Review of Context

In a previous essay (Mearns, 2007), I explore the range of contemporary rideshare

resources from low-tech cork ride boards to high-tech vehicle-integrated dynamic routing

systems and demonstrate that web based ridesharing systems have been woefully overlooked.

However, that survey missed a growing list of sites which offer dynamic ridesharing including

511.org in the San Francisco Bay area (http://www.511.org), Hitch in New Zealand

(http://www.hitch.net.nz/)and Jack Bell Rideshare in Canada (http://online.ride-share.com/).

While each of these applications have their own merits, they are neither adequate for typical

American intercity travel nor long distance commutes, which offer many re-routing opportunities

incorporating actual share locations.
http://www.hitch.net.nz/http://www.hitch.net.nz/


4/16

dinoride 4

Furthermore, the relatively small number of willing shares for an American intercity trip

or long-distance commute necessitates a centralized repository, allowing the user to take

advantage of the widest available rideshare information. No existing application has

incorporated external information, rather depending upon their separate, limited, user bases.

While external information has much potential for increasing the utility of ridesharing

applications, gathering and processing this spatial data requires novel strategies for achieving

uniformity and determining relevance.


5/16

dinoride 5

Description of Application

Dinoride is a system of complimentary scripts and databases consumed through a typical

dynamic web page. Therefore, among the technologies used are those which have implications

for the web server, database, and browser domains. PHP (http://www.php.net/documentation/),

residing within the web server, is a scripting language which allows automated interaction

between the database and browser domains. One can think of PHP as the script in an interactive

play in which the web server is the principal actor. When the audience arrives perhaps they

throw rotten tomatoes at the web server, our principal actor. It is the PHP, in which language the

web servers script is written, which tells it that it must react to the rotten tomatoes by searching

one of its bags of props, a database, for a zucchini which will be dealt with in a particular way,

maybe even in a different language. These actions are all described in the script, which itself

changes according to what the audience decides to hurtle at the web server, making for an

interesting play indeed! It is in this way that PHP gives the web server instructions on rendering

web pages, in this case in JavaScript (http://www.w3schools.com/js/), HTML, and CSS, based

on data from our databases, which are structured and dealt with in MySQL

(http://dev.mysql.com/doc/), and POSTGRE/POSTGIS (http://postgis.refractions.net/

documentation/). KML (http://code.google.com/apis/kml/documentation/) and the Google Maps

API (http://www.google.com/apis/maps/documentation/) also fit into the categories of

technologies which manifest specifically through our webpage. These technologies are more

familiar than you might think: KML has similarities to HTML and the Google Maps API is

accessed through JavaScript. Think of KML as the language by which the Google Maps API, a

third party mapping program (think Google Maps) which we have embedded in our web page,

renders our specific information of interest, such as markers. For those familiar with XML, think

of KML as Google proprietary version specifically for communicating geographic information.

Each of these technologies was chosen for particular reasons. PHP is open source, well
http://dev.mysql.com/doc/http://postgis.refractions.net/http://code.google.com/apis/kml/http://code.google.com/apis/kml/http://postgis.refractions.net/http://dev.mysql.com/doc/


6/16

dinoride 6

documented, easy to use, works on multiple platforms, and easily switches between interaction

with MySQL and POSTGRES. Dinoride also deals with information outside these realms,

specifically rideshare information coming from Craigslist in RSS format. Craigslist is the

largest classified advertisement resource in the world, and its free and online. Craigslist is also

the largest rideshare resource in the United States, measured by potential shares and certainly by

the range of cities covered. Craigslist makes much of the information on their site available to

third parties by offering RSS versions of much of the site. RSS is a cousin to XML (and

implicitly KML) listed above. It is basically a way of expressing information in a structured

way, similar to HTML, but with a much greater emphasis on hierarchy and relationships. RSS

allows sites like dinoride to easily include Craigslist information. In the past few years many

sites have taken advantage of the wealth of data to be found on Craigslist, especially information

in the RSS format. These applications are commonly termed mashups, because of their mashing

together of many technologies and data sources. Therefore, Dinoride can properly be included in

the category of mashup.


7/16

dinoride 7

This diagram describes the connections between separate scripts and entities (with blue borders). Arrows symbolize

the flow of data and instructions from one entity to the next. The white box represents a single web host server, withall external elements outside.

The heart of the application is spatial functionality within POSTGRES/POSTGIS which

determines desirable share cities, and their distance from a destination, within a certain distance

from an approximated route. Specifically POSTGRES/POSTGIS draws a straight line from

origin to destination, draws a buffer around this line, and then finds all city points which intersect

this buffer. Craigslist (http://www.craigslist.org) share ads are searched for intersecting cities.

This search specifically looks for share ads with shares traveling in the same direction as the user

according to word searches, for purposes of example, image the application searching from b

city to c city, b city and c city being alphabetically between a city (the origin) and d city (the


8/16

dinoride 8

destination) . The matching cities with eligible shares display, as well as a route line via Google

Maps which uses its own routing algorithm. You can see the entire process in action below.

Dinoride interface

Proposed Modifications

I have proposed modifications which have all yet to be realized to dinoride along

three different criteria: output should only include shares which are appropriate for the user

route, options and structure should meet the most critical user needs, and the interface itself


9/16

dinoride 9

should be as user-friendly as possible. I must point out that one user may think a certain feature

sorely needed while another may find that the lack of that feature makes the interface more user

friendly. This situation introduces the need for careful tradeoffs that I have attempted to make in

the following section.

Output should only include shares which are appropriate for the user route

Inappropriate shares are suggested for three reasons. First, current output occasionally

includes shares which are not appropriate for a given route, when that route greatly deviates from

a straight line due to due to the use of Euclidean distance and a straight line object rather than

geodesic or route distance and route object. A route object must be captured and stored in spatial

database so that operations can include this variable. It appears that this can be done with the

Google Maps API route object. Next, some suggested shares deviate from the route too much

to reasonably include in a route, once a destination has nearly been reached.

Suggested share 4, at Washington DC would not make The same route with more shares option. The great

sense in this case, since additional mileage would difference between matches for these two options isoverwhelm the additional shared mileage, especially evident.relative to the entire route.


10/16

dinoride 10

To resolve this issue, more intelligent matching should be used, especially as the number of

share results increases. In any event, better matching must take account of the extra mileage

necessary to meet a share as a proportion of mileage remaining in the route after that node. This

task can be completed once the route object has been captured. Finally, there is a great degree of

difference between shares returned on fastest versus most shares criteria. In order to allow

finer adjustments to these criteria, geometric database objects should be stored under a projected

spatial reference.

Options and structure should meet the most critical user needs

Most existing user options are in the demonstration phase and will only become possible

through a broader data model. For example, date can only currently be searched for by a single

number rather than a full month-day-year type date. The data model will be expanded according

to two strategies, one active and the other passive. The active strategy involves implementation

of pattern-based parsing and diversification of data searching. Pattern-based parsing will be

accomplished through string functions, either within the database or by server side script, based

on an expandable set of rules, determined by careful consideration of share ads. For instance, if

on is found in a text string followed by a non-spaced group of non-number characters matching

an entry in a table of possible month names followed by a number, the non-number character


11/16


12/16

dinoride 12

(http://tonto.eia.doe.gov/oog/info/gdu/gasdiesel.asp), as well as the mileage the user will travel

and the number of passengers. Users should be able to re-route by checking off listings and

cities from the list view and from the map view. When a city is checked on or off, the route and

dependent information should change by AJAX data requests and loading.

Unrealized mockup based on some of the considerations above including: rerouting based on most efficient route,full criteria options, and fuel share suggestions

Riders could be notified by email when a route becomes complete via a new nodal

connection that was previously incomplete. It seems there are an almost endless number of

enhancements to be made, however it is not necessary that Dinoride implement these directly but

rather could rather implemented by a third party through a Dinoride API, which could then be

expanded upon ad infinitum. These third parties, presumably running their own sites, would be

better suited to offer customized functionality for their distinctive user base.
http://tonto.eia.doe.gov/oog/info/gdu/gasdiesel.asphttp://tonto.eia.doe.gov/oog/info/gdu/gasdiesel.asp


13/16

dinoride 13

Business Model Options

I have considered a number of potential financial arrangements for deploying and

supporting dinoride. Below I have described three of the more hopeful concepts. The end result

will likely combine the best elements of each plan.

Offering premium rideshare listings to the general public would be a straightforward first

step, providing a needed stream of revenue, and improving the quality of share data. These

listings would be available to users who sign up for a period membership, which would entitle

them to post an unlimited amount of premium rideshare listings, include the maximum amount

of optional criteria, and show up at the top of any rideshare search, with a premium logo, perhaps

even allowing links to social networking sites for other premium users through APIs from those

sites.

Dinoride could be deployed with an institutional or collegiate focus, benefiting from both

the strengths of an institutional client, the particular niche needs of a university, and the student

demographic. Universities have the financial resources (expendable money and strong grant

capturing abilities) and the motives (prestige, good public relations) to invest in this technology

especially if their peer institutions are doing so. Consider a natural demographic synthesis: most

users of dinoride are likely to come from a university-aged demographic, since those within this

group are relatively more flexible, likely to try a novel concept, and comfortable with their age

cohort; Universities seem like a natural client. Premium or student listings could be offered to

university clients at a bulk rate. Students can then pick if they only want to ride with other

students, but would also be able to take advantage of premium listings.

Finally, making ride share matching capabilities available to third parties such as local

governments, travel businesses, and non-governmental organizations with fees according to the

number of matches made available to their site, perhaps through an API which can be used in a

customized deployment, doesnt just make good business sense, it also appears to be a working


14/16

dinoride 14

model in place at Hitch, the New Zealand rideshare application mentioned above. Hitch uses an

affiliate program to allow their search results to be seen by tourist transport agencies and local

government rideshare initiates alike, presumably for a fee.

Conclusion

The rapid growth in availability of structured data -- such as the Craigslist RSS used by

Dinoride -- has made it possible for the urban planning professional to implement user-focused

solutions leveraging vast sources of information, hitherto unavailable. Dinoride is unique in the

tiny but fast growing field of web-based ridesharing for its ability to access this type of

information, as well as for its implementation of a spatial algorithm better suited to the American

ridesharing landscape: relatively sparse residential settlement, many alternate routes, few

available shares, and long distances of travel. Any ridesharing solution must respond to this

situation, or risk continued irrelevance for the American roadway traveler. Dinoride, by taking

account of potential routes and potential shares living along those routes, offers such a solution.

Dinoride will benefit further from refinement of routing and matching rules, expansion of the

data model, and extension of the user interface. Whether dinoride be the realm of students,

specialized users such as tourists, or the general public, there is much room for expansion,

refinement, and excitement in the field of dynamic web-based ridesharing.


15/16

dinoride 15

References

Mearns, B (2007). A Client-Side Rideshare Application Described. Retrieved August 15, 2007,

Web site: http://cpln716.no-ip.org/d/web/ridesharing.htm


16/16

dinoride 16

User Interaction Sequence Diagram

Documents

Automatic Route-based Ridesharing on the Web