At 306 Case Study The Newest Shipping Systems Its All About Rapid Informa...
FINAL-T.R.A.F.F.I.C -Thomas-Lawrence-Retting
1. T.R.A.F.F.I.C.:
Transit Response Analysis for Facilitating Informed Commuters
Donna Thomas, Justin Lawrence and Jacob Rettig
Department of Computer Science and Electrical Engineering
University of Maryland Baltimore County
Baltimore, Maryland 21230
{donna7, justin25, rettig1}@umbc.edu
Abstract— T.R.A.F.F.I.C is an acronym representing Transit
Response Analysis for Facilitating Informed Commuters.
T.R.A.F.F.I.C. is a web service hosted in the cloud which uses
Big Data sets from TRANSCOM, a non-profit firm. We are
mining for potential congested traffic patterns which may
impair one's timely commute during rush hour. T.R.A.F.F.I.C is
based on the service-oriented architecture (SOA) web service
technology. The project description, system design, key technical
challenges, lessons learned and related works are discussed in
this paper. The content in this paper not only gives a case study
for SOA, but also provides a new and effective solution for end-
users of Intelligent Transportation Services (ITS) solutions.
Index Terms—Service-Oriented Architecture, SOA, Service-
Oriented Computing, SOC, open architecture, web service,
Hadoop, HBASE, MapReduce, Big Data, Transportation,
Transit, Traffic, Congestion, Alerts, Intelligent Transportation
Systems, ITS, TRANSCOM, T.R.A.F.F.I.C., UMBC, WS-I,
ADA, W3C
I. INTRODUCTION
T.R.A.F.F.I.C. was inspired by a semester project assigned
by Dr. Milton Halem at the University of Maryland, Baltimore
County (UMBC) for the CMSC668 - Service-Oriented
Computing (SOC) course.
PROJECT REQUIREMENTS
The project requirements specified that we leverage a Big
Data set, creating a Web Service on an Apache/Axis server on
the UMBC Bluegrit cluster environment, which is cloud-based.
Our end-solution had to be elastic and scalable, and it had to
meet the OASIS Web Services Interoperability (WS-I)
standard for its system architectural design and login security.
II. PROJECT DESCRIPTION
Using Big Data sets, we mined for potential congested
traffic patterns which may impair one’s timely commute during
rush hour. When we discovered potential congested traffic
patterns, our web service would send notifications to service
subscribers. Our solution had to be elastic and scalable. Figure
1 below is a screenshot of our Home page.
Fig. 1. Home Page of T.R.A.F.F.I.C.
III. USERS
Our view for this solution was that any commuter would
find value in using this service to lessen the stress of enduring
delays in traffic. Many states have state laws that discourage
use of handhelds, calling, and texting, so our solution lessens
the need to use their mobile to maneuver through mobile apps
to find their answer. The design for this solution was directly
impacted by the pressing issues created when people try to use
their cell phones or tablets while driving.
IV. SCENARIOS
This service provides multiple objectives, including
assisting users in avoiding traffic delays, providing a civic
responsibility to commuters, and providing routing data to
local businesses. Users are able to avoid traffic delays by
querying traffic conditions before leaving for their destination,
or by receiving an email, short messaging service (SMS), or
really simple syndication (RSS) feed alert that a traffic event
has occurred on their selected route during their selected
timeframes. Another use of the service provides the ability for
local governments to update commuters on traffic conditions
2. via electronic roadway signs with local condition updates.
Finally, this service could be utilized by businesses to obtain or
be updated to local traffic conditions to prevent or minimize a
delay in delivery or service times.
V. FUNCTIONAL REQUIREMENTS
The major functional requirements for the T.R.A.F.F.I.C.
project are described below.
New User Registration
Input: The new user registration form will require the
following information as input: Email address and
password. The following information may also optionally
be entered: Twitter account name, RSS feed, cell number
and carrier information, or a secondary email account.
Reference Figure 2.
Services Required: A service is required to complete
the new user registration. The service needs to accept the
user completed data and pass it into the Hadoop
Distributed File System (HDFS).
Fig. 2. New User Registration Page of T.R.A.F.F.I.C.
Input: The new user registration form will require the
following information as input: Email address and
password. The following information may also optionally
be entered: Twitter account name, RSS feed, cell number
and carrier information, or a secondary email account.
Reference Figure 3.
Services Required: A service is required to complete
the new user registration. The service needs to accept the
user completed data and pass it into the Hadoop
Distributed File System (HDFS).
Results: After completing the required and optional
information defined above, the user will be taken to a
webpage noting the successful completion of the user
registration. If the data entered into the user registration
page is incomplete or does not meet the acceptance
criteria, the user will be shown which fields on the form
are incomplete and asked to fill in the missing data before
proceeding. Examples include an ill-formed email address
or non-matching initial passwords.
User Login
Input: On this form, the user should enter in the email
address they used to sign up for the service on the New
User Registration form. The user should also enter in their
current password.
Services Required: The service for the User Login
form needs to be able to be called with the desired user
email as the lookup value for the HDFS. The service will
then pass back a true or false message stating whether the
supplied user credentials are correct.
Fig. 3. User Login Page of T.R.A.F.F.I.C.
Results: Once the user has entered in the correct
information, they will be returned to the main page of the
T.R.A.F.F.I.C. system. The user will now have additional
options appearing on the left side of the main page,
including Logout, Register, Modify, and Unsubscribe. On
the login form, if the user enters incorrect login
credentials, the user will be directed to a page with the
following options:
Try Again
New User
Return Home
The Try Again option will allow the user another
attempt at entering in the correct login credentials to log
into the system. The New User option will bring the user
to the new user registration page outlined above, and the
Return Home option will bring the user to the main page
of the system.
Basic Security Authentication
Input: The login information will be gathered and
passed to the server. Reference Figure 3.
3. Services Required: The service will utilize SOAP
headers to communicate with the Bluegrit server and
authenticate the user credentials.
Results: The user information is gathered and passed
as a SOAP message to a service on the server. The service
will return back a value indicating if the user is permitted
to log into the server based on whether the user has
supplied the correct credentials.
Register Desired Alerts for Travel Needs
Input: On the Register form, the user will be required
to enter the following: Name of the Registration,
Notification method (Selecting from Twitter, RSS,
Texting, or Other Email), the start and end dates for the
alert, the days of the week that the alert is active, and
starting and ending addresses.
Services Required: A service is required to accept the
start and end addresses from the user input. The service
will call the MapQuest API and the result is passed back to
the register form. Once the user has completed finalizing
the route on the form, a service is required to accept the
user route input data and store it in the HDFS on the
server.
Fig. 4. Route Registration Page of T.R.A.F.F.I.C.
Results: The user will complete the required items on
the registration form. Once complete, the form will load a
map using MapQuest APIs, which will allow the user to
modify the selected path as needed to tailor the route to
their daily commute. Once the user has finalized the route
selection process on the form, the user will complete the
registration of the route by saving it. This will save their
selected route in the Routes column family in the HDFS
for later use in matching an event with their selected route.
VI. TECHNOLOGIES & HARDWARE USED
T.R.A.F.F.I.C. resides in a cloud implementation. Bluegrit
is the hardware grid computing cluster provided to implement
the Service-Oriented Computing project. The portion of
Bluegrit that was used in this implementation were a set of 12
RHEL5 blades with Apache Tomcat, Java 1.6, PHP, Apache
AXIS 1.4, Hadoop, HBASE, and MapReduce installed.
Technologies used for the presentation layer included an
Apache Tomcat server with PHP and SOAP,
XHTML/HTML5, CSS3, JQuery, and MapQuest API. The
MapQuest API provides turn-by-turn directions, a turn-by-turn
route between two chosen points as a path in JSON format,
map visualizations, and ability to change the suggested route
path via route drag and drop.
VII. DATA SOURCES
We used sources of data to provide this service to our
targeted users: (1) TRANSCOM and (2) MapQuest. How we
used them are described as follows:
A. Big Data – TRANSCOM
In our initial plan, we attempted to reach the University
of Maryland - College Park in hopes of using the live feeds
from the CapWIN project. However, this approach was
unsuccessful. Shortly after, we learned about the evolution
of the I-95 Corridor work and TRANSCOM's data feed for
New York tri-state area, covering New York, New Jersey,
and Pennsylvania. We were able to use the TRANSCOM
data feed thanks to Rob Bamford generously providing
access free of charge.
After reviewing the data received from TRANSCOM,
we realized each data request would return an xml file
several megabytes in size with many events in each feed.
We were able to construct a parser to convert the xml data
into a more manageable format. Using the parser, we then
constructed services to transfer the event data from the
parser to the HDFS. After storing the event data, we were
able to use the GPS locations from the user routes to search
for any potential alert matches. When any potential matches
were found, we were able to use soft matching on the local
street names to determine if there was any alerts that were
relevant to the beginning, ending and paths on the desired
commuter route.
B. Routing Information – MapQuest API
The MapQuest Licensed Data API was used after
registering our service and obtaining an AppKey with
MapQuest. By registering, it allowed our service to upload
custom route paths for alternative routes, giving our users
the ability to manually click-and-drag the MapQuest
overlay to the route they prefer, rather than the default
shortest-distance path returned by the MapQuest API.
By using the MapQuest API, we were able to get the
GPS locations of the user selected routes to store. When
overriding the default route with MapQuest, the sections of
the route which are altered from the original path is given
as JSON objects containing the GPS latitude and
longitudinal information. We then were able to store the
path information using a service created to transport and
4. insert the information into the HDFS. After storing the data,
we were able to perform event and route data matching as
described above to create the alerts for our registered users.
VIII. WEB SERVICES AND THE T.R.A.F.F.I.C. API
We logically placed the functions our design into two grouping
of web services: (1) User Services and (2) Route Services.
These services and their functions in each are described as
follows:
1. User Services - the collection of services for user
creation, authentication, and deletion.
Login Security/Authentication
o Input/Request - Username as a String and
Password as a String. Reference Figure 3.
o Output/Response - An integer value of -1
for error, 0 for not authorized, 1 for
authorized.
o Processing - Checks the HBASE table if
the user exists and the password provided
matches.
New User Registration
o Input/Request - Username as a String and
Password as a String. Reference Figure
2.
o Output/Response - An integer value of -1
for error, 0 for not authorized, 1 for
authorized.
o Processing - Checks the HBASE table if
the user exists and the password provided
matches.
Delete User Account
o Input/Request - Username as a String and
Password as a String. Reference Figure 5.
o Output/Response - An integer value of -1
for error, 0 for not authorized, 1 for
authorized.
o Processing - HBASE table deletes all
data related to desired account plus
account login credentials.
2. Route Services
Route Registration
o Input/Request – Days of Week,
Timeframes (departure and arrival),
Duration, desired commute path with
starting and ending addresses, the name
of the route, and deired notification
method are stored in a simple array.
o Output/Response - An integer value of -1
for error, 0 for not authorized, 1 for
authorized.
o Processing - Checks the HBASE table if
data is stored and no duplicate route is
already stored.
Modify Route Registration
o Input/Request – Current route is retrieved
– user modifies as necessary.
o Output/Response - An integer value of -1
for error, 0 for not authorized, 1 for
authorized.
o Processing - Checks the HBASE table if
updated data is stored.
Fig. 5. Unsubscribe Page of T.R.A.F.F.I.C.
Note: Field validation of data entry is handled in the PHP of
the GUI, and at logoff, the session and cookies are destroyed
from logic in the PHP of the GUI.
The user can log off of any page behind the secure screens,
by clicking on the button down the left-hand side of the
screens. Figure 6 below is a copy of the resulting screen
from logging off.
Fig. 6. Successful Logoff Page of T.R.A.F.F.I.C.
IX. SERVICES AND NETWORK ARCHITECTURE
To visually see how our architecture was built on blue grit
we have provided an architecture diagram as an attachment to
this paper.
The center part of our architectural design handles the
necessary WSDLs and SOAP messages to and from our web
5. services, which is our service integration layer. It handles
requests from the GUI and handles providing the
acknowledgements or requested data from it. It also handles
communicating with our HBase tables to extract and provide
data to the GUI.
We also have an implementation layer that handle cron jobs
to our big data sets to mini the data and generate alerts and
push them our based on the filed requests from our account
owners.
X. PROJECT DESIGN
The detailed design of our project is described as follows:
A. GUI
The graphical user interface (GUI) was designed
using strict XHTML, CSS, and PHP. The pages were
designed to enable the user to register as a user, login
and register desired paths and timeframes to monitor
potential traffic congestion problems.
The initial design was viewed as being accessible
via desktop or laptop where a worker could register to
use it before to departure for their commute. The design
also works flawlessly on mobile devices, but the intent
of end-value use is to use mobile devices to receive
alerts, not register for the alerts to be received.
The GUI is very easy on the eye, and has user help
and validation of fields done at the time they are being
filled out. The use of PHP is to receive the data from
the GUI and format it to be sent to the Java Web
Services. The PHP is also used for login security
validation, which prevents unregistered or unlogged
users from hacking our service. Copies of the many of
the screens are included as figures in this paper.
While not a project requirement, the design of the
project does happen to also meet W3C, and American
Disability Act (ADA) Standards. The pages were
validated using the validator found on the W3C.org
webpage and also evaluated/validated for web
accessibility errors using WAVE found at
http://wave.webaim.org/.
B. Security
For this project, we included a simple single login,
exploiting web services. Once logged in, you can
access your account, and register for the routes
monitored. You cannot access any of our pages if you
are not authenticated through login. If you are not
logged in, you can browse the home page, our credits
pages and register to be a user.
C. WSDLs
From our services, we have two WSDLs and they
have been attached to our paper. Our WSDLs match
the required format of the WS-I standard.
D. SOAP Messages
The web services also have a two-way
communication with the GUI and the HBASE data, and
one set of SOAP requests and responses are attached to
our paper. Our SOAP requests and responses contain
the required information based on the WS-I standard.
E. Hadoop
The Hadoop environment was set up, developed,
and administrated by UMBC. How we used it for this
project is described as follows:
1. HBASE
Using the HBASE shell through a terminal client
to the Bluegrit server, the unnormalized table used
was developed and altered through shell commands.
The structure of the table was created with three
column families: Users, Routes, and RouteSegments,
described below.
a) Users - The User column family was created
to hold the information about each user.
While this information was unstructured, the
data contained for our purposes included the
user login name, password, SMS cell
information, cell phone carrier, email, and
RSS feed, among other data items.
b) Routes - The Routes column family contains
information on the user's selected routes from
the HTML page using the MapQuest API.
The user's route was stored in this table for
later processing and matching.
c) RouteSegments - The RouteSegments column
family was created to hold the TRANSCOM
data received and parsed through our PHP
script. This column family holds data on the
location, time, and day of the event, along
with the traffic direction data and the reason
for the event. Using this data, we are able to
find matches between the traffic data and the
user route column family by utilizing the GPS
data and street names. Using a soft-matching
approach, we the pair the street name and
GPS data to confirm an event with the GPS
route data from the user's route.
2. MapReduce
Upon receiving updates from the TRANSCOM live
data feeds, we leveraged the MapReduce tool from
Hadoop to handle parallel processing across the 12
Blades on Bluegrit for which we had access.
F. Implementation
MapQuest was selected over alternative map APIs
because it had the ability to get the route information
needed for matching routes to alerts and all
capabilities in the visual MapQuest API can be called
via RESTful service calls. The SOAP services were
written in Java and deployed with Apache AXIS 1.4
which provided a WSDL and JAX-RPC calls that use
SOAP messaging protocol. The PHP web application
6. code accesses the SOAP enabled SOA web services
via the built-in PHP SOAP API and the URL to the
WSDL provided by Apache AXIS 1.4. The SOAP
enabled SOA web services accessed by the PHP
webpages are also accessible to other SOAP clients
which enables loose coupling of the implementation;
A mobile application can be created by changing only
the interface code and without changing the core
processing code. An SMTP server has also been setup
to send out alerts via email and to mobile phones via
the email-to-SMS services provided by mobile service
providers.
XI. FUTURE WORK
Future development of the T.R.A.F.F.I.C project would
include Twitter and social media integration, MapReduce
functions, additional related data feeds, tightened security, and
overall system hardening.
Twitter and Social Media
Future development work into the integration of
Twitter and social media would offer several benefits to
the project. These benefits include the ability for the user
to enter in their Twitter handle while registering for, or
modifying, alerts. The T.R.A.F.F.I.C system would then
be able to send a Tweet to the users' Twitter handle when a
new event has occurred that meets the alert criteria.
Utilizing Twitter in this way offers several benefits:
1. We are able to instantly Tweet the alert to the
user using Twitter's API,
2. Once a Tweet is sent, Twitter takes over the
delivery of the message, reducing T.R.A.F.F.I.C's
responsibility, overall cost, and testing
requirements.
3. Large social media outlets, such as Facebook,
have the ability to integrate with Twitter. This
allows users to share tweets and statuses about
traffic delays. Having a user share an alert Tweet
would allow for further exposure to the project
and help create a larger user base as the newly
exposed users also join T.R.A.F.F.I.C.
MapReduce and related data feeds
Developing the MapReduce functions of T.R.A.F.F.I.C.
would help to scale the overall project. Using MapReduce,
the processing of the incoming data can be reduced and
distributed over several nodes or grids. If a node fails
while processing the data, another node would be able to
recover from the failure and process the data. Utilizing
MapReduce, T.R.A.F.F.I.C. would be able to process data
more concurrently, recover gracefully from node failures,
and have the ability to easily add and remove processing
nodes as needed. Using MapReduce would especially help
when adding in new related data feeds. Coupling the
existing TRANSCOM data feeds with weather
information from National Oceanic and Atmospheric
Administration (NOAA), or adding in a new data feed
from CLARUS could be achieved by creating new
MapReduce functions to break down the data for
distribution for processing on sub-nodes. Creating these
new functions would help to scale the project as new feeds
and more complex data are consumed.
Security and system hardening
Finally, adding additional layers of security to
T.R.A.F.F.I.C., along with hardening the system would
help to improve the project by reducing potential
downtime and protecting sensitive user data. Adding
security features such as account lockout on too many
unsuccessful password attempts, slowing password
attempts to prevent automation software from performing
dictionary attacks on passwords, and adding a CAPTCHA
to the new user page to prevent the automation of new user
accounts would be helpful additions to the overall system
to aid in preventing potential abuse.
XII. RELATED WORKS
Throughout the semester, we discovered related works
that are important to our work.
• UMCP CapWIN -- This is a funded project by the
state of Maryland where research is being captured
and live data is being provided to the state.
• I-95 Corridor --This is a body work that was inspired
by CapWIN's work to focus on this road to capture
traffic data along I-95 which involves multiple along
the East Coast.
• TRANSCOM - This organization is a non-profit
research firm that has developed and delivered
multiple interfaces. After we completed the program,
Ms. Thomas discovered that they have an alert service
silimlar to our solution that involves every mode of
transportation and paths. (ie bus, railroad, subway,
roadside, etc.)
• INRIX -- They provide an alert service via mobile
computing only, which means that commuters can sit
and navigate their app while driving. Our team views
this as a related work, but it defies our mission of
providing a service that would discourage people
from extensively using their mobile phones or tablets
while driving.
• WeatherBug (now EarthNetworks) -- They also
provide a similar service as INRIX, but it also
requires extensive use of mobile devices while
driving.
• Dr. Kalpakis at UMBC - Under his research arm, he is
studying traffic models and how they might be used
for predictive modeling for congestion.
• Dr. Sherman at CapWIN - Under his research arm, he
has a collaborative relationship with CapWIN. We
7. discovered this too late in our design process to take
advantage of.
• MD 511 Telvent Solution -- Telvent designed and
delivered a 511 solution that has strictly a web
interface and integrate voice recognition (IVR)
delivery. Their solution is not a web service solution,
but rather an application only. The solution was
reported as successful, but Ms. Thomas interviewed
the responsible former software development manager
and they never completed their design as a web
sevice, per WS-I standard.
• PA 511 Telvent Solution -- For the state of
Pennsylvania, a 511 solution was provided and it was
reported that it was a web service. The only thing that
was a web service was the data feed from INRIX.
The feeds from the other two sources, and the solution
itself did not comply to the WS-I standard. The
insight on this project was shared by their former
software development manager.
• Waze -- Waze is a mobile application for Android and
iOS which allows drivers to share road details with
one another including areas of accidents, slow traffic,
or police. Waze also will notify the driver of any
upcoming issues they may face in their current route,
but requires the application be open on the user's
mobile device while driving to gather GPS data, tag
areas or events, or get notifications of an upcoming
traffic event.
• Twitter-integrated dashboards -- General Motors,
Ford, and Mercedes-Benz are creating car dashboards
with integrated social media applications. Facebook
and Twitter being two of the most popular. Using the
integrated car dashboards, we would be able to push
out a tweet directly to the user through the car
dashboard.
XIII. TEAM APPROACH
Our team approach to the project consisted of meetings held
in-person, on the phone via Skype, and over email to develop
an implementation plan, discuss ideas, and define direction.
We used Microsoft SkyDrive for storage and collaborative
editing of PowerPoint and Word documents, we held weekly
Skype meetings to update each other on progress made during
the week, and finally, we held face-to-face meetings to cover
tightly integrated areas of our work such as code and design
development.
XIV. CHALLENGES
From the onset, we anticipated that we would have
challenges related to big data analysis interpretation, event
driven path analysis, and getting access to traffic data. Of the
three, the event driven path analysis may be considered a
challenge, but we had to figure out how to isolate relevant data
against defined paths and only extract them for use, so we
could prevent the need to store all data. Once we found
TRANSCOM’s data set and was given access for research,
then we discovered that the big data analysis interpretation was
not difficult as TRANSCOM had well documented
descriptions of what we were getting.
What we had not anticipated, and it ended up being a huge
part of learning for us was what we could do versus what we
had no control over on Bluerit. From our working experience,
we naturally assumed that we would have root access, and that
we would even have access to an SMTP server. Because of the
number of people using the Bluegrit cluster for research, the
security requirements really challenged our minds. We can
recall discoveries that challenged us to do hacks and act like
McGyver to get our solution to work. Remember the
requirement was that our solution had to work on Bluegrit. No
exceptions.
Particular challenges with Bluegrit involved discovering
creative solutions for the PHP Proxy, and forcing alerts using
Bluegrit because the SMTP server was not installed. Complex
data types could not be used (we did not have access to
Hadoop – Axis specs on Bluegrit) so we used key value pairing
in simple arrays.
XV. RESPONSIBILITIES
We divided up the project work equitably among us with
Ms. Thomas finding and retrieving big data with
TRANSCOM, designing and implementing the GUI and SOAP
requests, and handling the security login authentication needs.
While not a project requirement, Ms. Thomas designed the
GUI to be ADA and W3C compliant.
The design of the HBASE tables, ingesting of big data, and
designing and pushing alert services were mostly Mr.
Lawrence’s responsibilities.
The event driven path analysis, design of our web services
and architecture and tying in the MapQuest API were mostly
Mr Rettig’s responsibilities.
Truth be known through collaboration, we all have touched
somehow the outcomes of these areas, and contributed to the
“hacks” to make our solution work on Bluegrit. In addition,
we all tested the solution and co-wrote this technical paper.
XVI. PERFORMANCE AND RESULTS
By week 3 of the semester, we delivered our proposal of
what we were intending to do. At that time, we had not located
a live datafeed of Big Data for our use.
Midway through the semester, we had all of the parts put
together and we were debugging our code to make it work on
Bluegrit. We were able to demonstrate the GUI and the output
of our event-driven path analysis.
At the time of our final presentation, we operated a fully
functional solution for our class and guests, Ms. Peggy Burns,
SVP of Xerox Corporation, and someone from Northrup
Grumman were impressed with our tool. We were invited to
visit Xerox and share our project with the technical
community.
8. XVII. SUMMARY
Our project’s focus was to create a service which would
allow people travelling in the NY tri-state area the ability to
avoid traffic congestion by leveraging event and link driven
data from TRANSCOM. We wanted to minimize or
discourage use of the mobile phones to look up information
while driving. Our solution sends alerts if there are any
problems which does not require human interaction while
driving.
Our web service solution is scalable to any travel location
nation-wide or internationally capturing event and link traffic
data.
We believe that this is the first real web service that meets
WS-I to support this need. All other solutions are provided via
mobile handset, web or IVR and require much interaction from
the users.
ACKNOWLEDGMENT
Thanks to our families and friends for putting up with the
long hours away from us. A special thanks to Dr. Halem and
his Teaching Assistant, Dr. Phuong Nguyen, for their guidance
and patience in tolerating our questions related to Bluegrit.
REFERENCES
[1] Barry, Keith. "The Future of In-Car Technology." Car and
Driver. N.p., 1 Apr. 2012. Web. 01 Oct. 2012.
<http://www.caranddriver.com/features/the-future-of-in-car-
technology>.
[2] "CATT Homepage, Clark School of Engineering, University of
Maryland." CATT Homepage, Clark School of Engineering,
University of Maryland. Center of Advanced Transportation
Technology, n.d. Web. 01 Oct. 2012. <http://catt.umd.edu/>.
[3] Chan, Alice. "Mercedes-Benz Dashboard Crowdsources Parking
Spots For Drivers Via Twitter - PSFK." Mercedes-Benz
Dashboard Crowdsources Parking Spots For Drivers Via
Twitter - PSFK. N.p., 12 Mar. 2012. Web. 01 Oct. 2012.
<http://www.psfk.com/2012/03/mercedes-benz-twitter-parking-
spots.html>.
[4] Chang, Fay, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh,
Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew
Fikes, and Robert E. Gruber. "Bigtable: A Distributed Storage
System for Structured Data." OSDI'06: Seventh Symposium on
Operating System Design and Implementation (2006): 1-14.
Web. 30 Sept. 2012.
<http://static.googleusercontent.com/external_content/untrusted
_dlcp/research.google.com/en/us/archive/bigtable-osdi06.pdf>.
[5] Chouffani, Reda. "4 Questions to Ask Before Starting a Big
Data Initiative." CIO. N.p., 21 Aug. 2012. Web. 01 Oct. 2012.
<http://www.cio.com/article/714309/4_Questions_to_Ask_Befo
re_Starting_a_Big_Data_Initiative>.
[6] Das Sarma, Anish, Lujun Fang, Nitin Gupta, Alon Halevy,
Hongrae Lee, Fei Wu, Reynold Xin, and Cong Yu. Finding
Realted Tables. Proc. of SIGMOD ’12, Scottsdale, Arizona,
USA. N.p.: ACM, 2012. 1-12. Print.
[7] Dresser, Michael. Maryland to launch 511 traffic tip service.
Baltimore Sun. 11 August 2012. Web. 01 December 2012
<http://articles.baltimoresun.com/2011-08-11/news/bs-md-511-
information-20110811_1_traffic-information-delays-system>
[8] Hadoop. n.d. n. page. Web. 15 Dec. 2012.
<http://hadoop.apache.org/docs/r0.20.2/quickstart.html >.
[9] Harris, Derrick. "How Facebook Made It Possible to Geo-tag
Everything â Cloud Computing News." GigaOM. N.p., 9 Mar.
2012. Web. 01 Oct. 2012. <http://gigaom.com/cloud/why-every-
location-tag-on-facebook-is-big-data-in-action/>.
[10] Holt, Kris. "Toyota Lets Drivers Tweet from the Dashboard."
Daily Dot. N.p., 28 Sept. 2012. Web. 01 Oct. 2012.
<http://www.dailydot.com/news/toyota-corolla-twitter-
dashboard/>.
[11] Horvitz, Eric. "Predictive Analytics for Traffic." Microsoft
Research. N.p., n.d. Web. 1 Oct. 2012.
<research.microsoft.com/en-us/projects/clearflow/default.aspx>.
[12] Kuehnhausen, Martin, and Victor S. Frost. Transportation
Security SensorNet: A Service Oriented Architecture for Cargo
Monitoring. Rep. no. ITTC-FY2010-TR-41420-22. N.p.:
University of Kansas Information & Telecommunications
Technology Center, 2010. Print.
[13] "New Maryland Law Bans Hand-held Mobile Phones Effective
October 1." Dagger News. 09 2010: n. page. Web. 15 Dec.
2012. <http://www.daggerpress.com/2010/09/28/new-maryland-
law-bans-hand-held-mobile-phones-effective-october-1/ >.
[14] "MapQuest Platform Web Services." MapQuest Developers. n.d.
n. page. Web. 15 Dec. 2012. <http://www.mapquestapi.com/>.
[15] Mazaré, Pierre-Emmanuel, Olli-Pekka Tossavainen, Alexandre
M. Bayen, and Daniel B. Work. "Trade-offs between Inductive
Loops and GPS Probe Vehicles for Travel Time Estimation: A
Mobile Century Case Study." Trade-offs between Inductive
Loops and GPS Probe Vehicles for Travel Time Estimation: A
Mobile Century Case Study. N.p., n.d. Web. 1 Oct. 2012.
<https://netfiles.uiuc.edu/dbwork/www/pdf/TRB12.pdf>.
[16] Newcomb, Doug. "Inrix | Autopia | Wired.com." Wired.com.
Conde Nast Digital, 05 June 0012. Web. 01 Oct. 2012.
<http://www.wired.com/autopia/tag/inrix/>.
[17] Ovide, Shriva. "Tapping 'Big Data' to Fill Potholes." Tapping
'Big Data' to Fill Potholes. Wall Street Journal, 12 June 2012.
Web. 1 Oct. 2012.
<online.wsj.com/article/SB100014240527023034442045774605
52615646874.html>.
[18] Staff. Telvent Wins Contract to Implement 511 System in
Pennsylvania. GlobalNewsWire.com. 18 November 2008. Web.
01 December 2012. <http://www.globenewswire.com/news-
release/2008/11/18/388653/154964/en/Telvent-Wins-Contract-
to-Implement-511-System-in-Pennsylvania.html>
[19] Staff, Datanami. "What It Takes to Deliver Real-Time Traffic
Info - Datanami." What It Takes to Deliver Real-Time Traffic
Info - Datanami. Datanami, 01 Aug. 2012. Web. 01 Oct. 2012.
<http://www.datanami.com/datanami/2012-08-
01/what_it_takes_to_deliver_real-time_traffic_info.html>.
[20] TRANSCOM. n.d. http://xcom.org. Web. 15 Dec. 2012.
<http://www.xcom.org>.
[21] Web Services - AXIS. n.d. n. page. Web. 15 Dec. 2012.
<http://axis.apache.org/axis/java/install.html >.
[22] Web Services Interoperability Organization website. n.d. n.
page. Web. 15 Dec. 2012. <http://www.ws-i.org/>.
[23] Willard, Frank. former Televent Software Development
Manager. Interview with Ms-Thomas. 3 Dec. 2012.
