ISSN 1055- 1425
August 2007
This work was performed as part of the California PATH Program of the
University of California, in cooperation with the State of California Business,
Transportation, and Housing Agency, Department of Transportation, and the
United States Department of Transportation, Federal Highway Administration.
The contents of this report reflect the views of the authors who are responsible
for the facts and the accuracy of the data presented herein. The contents do not
necessarily reflect the official views or policies of the State of California. This
report does not constitute a standard, specification, or regulation.
Final Report for Task Order 5402
CALIFORNIA PATH PROGRAM
INSTITUTE OF TRANSPORTATION STUDIES
UNIVERSITY OF CALIFORNIA, BERKELEY
Reservation, Scheduling, and Navigation System
for a Checkpoint DRT Service
UCB- ITS- PRR- 2007- 12
California PATH Research Report
Yuwei Li, Nicole Foletta, Ken Elkabany, Fan Yang,
Anthony Wee, Michael Cassidy
University of California, Berkeley
CALIFORNIA PARTNERS FOR ADVANCED TRANSIT AND HIGHWAYS
Reservation, Scheduling, and Navigation
System for a Checkpoint DRT Service
Yuwei Li, Nicole Foletta, Ken Elkabany, Fan Yang, Anthony Wee, and Michael Cassidy
California Partners for Advanced Transit and Highways
Institute of Transportation Studies
University of California at Berkeley
Final Report for PATH Task Order 5402
June 2006
2
Acknowledgement
This work was performed as part of the California PATH Program of the University of
California, under PATH Task Order 5402. The contents of this report reflect the views of
the authors who are responsible for the facts and the accuracy of the data presented
herein.
The authors thank Tony Divito, Senior Planner at AC Transit, for his ongoing support
and assistance. We also thank the managers and staff at the AC Transit Central Dispatch
in Emeryville for meeting with us and providing valuable information. Finally, we thank
Dan Lovegren and Lindsee Tanimoto of Caltrans Division of Research and Innovation
for their assistance.
3
Abstract
The report fully documents a prototype system that has been developed to serve Demand-
Responsive Transit ( DRT). The DRT service is provided by means of buses and has been
proposed for deployment ( as a pilot project) in Fremont, California. The service itself is
to be deployed in a “ hybrid” fashion; i. e., service alternates between a traditional fixed-route
mode and the DRT mode from one bus trip to the next.
The report describes the prototype systems from the perspective of the system users ( i. e.,
customers, bus drivers and administrators). Further, the report describes system
configuration and deployment. Software development notes are also provided so as to
document the lessons learned from our development work. In short, the works shows that
reserving DRT trips and dispatching the buses can be done in automated fashion.
Keywords: Automated Demand- responsive Dispatching System, Public Transit
4
Executive Summary
The report fully documents a prototype system that has been developed to serve Demand-
Responsive Transit ( DRT). The DRT service is provided by means of buses and has been
proposed for deployment ( as a pilot project) in Fremont, California. The service itself is
to be deployed in a “ hybrid” fashion; i. e., service alternates between a traditional fixed-route
mode and the DRT mode from one bus trip to the next.
Details of the DRT service strategy have been fully documented in an interim report
( submitted in May, 2005), and therefore only briefly described in the current report. The
primary objective of this present report is to present the communications systems that we
have developed to facilitate the DRT.
The prototype system includes a web- based user interface by which customers ( i. e.,
prospective bus passengers) can reserve trips on the DRT. Although the reservation
system is currently web- based, an automated telephone- based component can be added in
the future.
Customer requests are automatically entered in the dispatching system. This latter system
uses the request information to offer the customer a number of bus run options ( both
fixed- route and DRT) to satisfy customer travel needs. The system also determines
whether or not a DRT request can be honored ( since a limited number of customers can
be served on any single DRT run so that run times do not become large).
Any customers who make requests for a DRT run after that run has reached its capacity
to service requests are notified of the fixed- route bus runs nearest in time to the DRT run.
These customers may then elect to travel via a fixed- route bus. For DRT requests that can
be honored, the customer makes a reservation by entering the identification number of a
prepared ticket.
Once customer reservations for a given DRT run are finalized ( when the run has reached
its trip time constraint or shortly before the scheduled start of the run), the dispatching
component determines the route to be followed for that run. ( Note that a DRT bus can
take “ shortcuts” to reduce passenger trip times; the bus need only visit those stops along
the route needed to served reserved passenger trips.)
Bus routing on a DRT run is automatically performed in a fairly simple way, since
checkpoints ( i. e., bus stops) along the route are numbered in sequence and a bus always
visits checkpoints in ascending or descending numbered order..
Shortly before beginning a DRT run, the bus driver downloads to an onboard computer
( e. g. a Pocket PC) pertinent information about the run. These downloads are performed
via wireless communications. Once the run actually begins, the navigation component
embedded in the system provides the driver with driving directions by means of both
graphical displays and voice guidance.
5
The report describes the above systems from the perspective of the system users ( i. e.,
customers, bus drivers and administrators). Further, the report describes system
configuration and deployment. Software development notes are also provided so as to
document the lessons learned from our development work. In short, the works shows that
reserving DRT trips and dispatching the buses can be done in automated fashion.
6
Table of Contents
1 Introduction..................................................................................................... 8
2 Overview ........................................................................................................ 10
3 System Functionality and Usage...................................................................... 12
3.1 Reservation....................................................................................... 14
3.2 Navigation........................................................................................ 16
4 System Deployment and configuration ............................................................ 21
4.1 Reservation and Scheduling............................................................. 21
4.2 Route Data and Map Generation...................................................... 26
4.3 Navigation........................................................................................ 31
5 Software Development Notes.......................................................................... 33
5.1 Tools Used ....................................................................................... 33
5.2 Program Flow................................................................................... 33
5.3 Key Technical Details ...................................................................... 34
5.4 Source File Descriptions .................................................................. 37
5.5 Compilation Process ........................................................................ 37
5.6 Complications .................................................................................. 38
5.7 Conclusions ...................................................................................... 39
7
List of Figures
Figure 1: System Components ............................................................................. 10
Figure 2: Map of Proposed Checkpoint Service .................................................. 12
Figure 3: Route Selection..................................................................................... 14
Figure 4: Display of Bus Travel Times................................................................ 15
Figure 5: Trip Request ......................................................................................... 15
Figure 6: Reservation Confirmation .................................................................... 15
Figure 7: Startup Screen of Navigation Program................................................. 17
Figure 8: Configuration Screen............................................................................ 17
Figure 9: Route Setup .......................................................................................... 18
Figure 10: Manifest for a Bus Trip ...................................................................... 19
Figure 11: Route Navigation................................................................................ 20
Figure 12: Web- based Configuration Interface ................................................... 24
Figure 13: View and Configure Existing Route .................................................. 25
Figure 14: Route Creation.................................................................................... 27
Figure 15: Route Data Generation....................................................................... 29
8
1 INTRODUCTION
The dominant type of demand responsive transit ( DRT) in the United States is door- to- door
service. It is often offered in response to Title II of the Americans with Disabilities Act ( ADA)
of 1990 which states that public transit systems that provide fixed- route services must provide
both accessible fixed- route services and complementary paratransit service for disabled
persons who cannot use fixed- route transit. A major downfall of door- to- door DRT systems is
the high operating costs, which greatly outweigh revenues. For example, door- to- door DRT
service for AC Transit in 2003 had an average operating expense of $ 24.8 and revenue of $ 1.5
per passenger trip. This is due in part to the complexity of the system. Door- to- door services
usually cover a large service area with many possible combinations for sequencing passenger
pickups and for routing. In addition, it is difficult to add last minute trip requests, such that
reservations must often be made at least one day in advance.
On the other hand, fixed route bus service is often inefficient. Such service in areas of low
demand density is often characterized by long headways and empty buses.
In some circumstances, a checkpoint DRT strategy can be more attractive than the above
alternatives for serving the general population. In a checkpoint system, the bus will visit a pre-determined,
densely located set of stops. Unlike a traditional fixed route system, however, the
bus can take shortcuts along the route; routes are altered from one bus trip to the next in such
ways as to serve the passengers who reserved “ seats” for each trip.
In a previous report1, a checkpoint DRT service was proposed for a 3- square mile area in
Fremont, California, a suburb in the San Francisco Bay Area. Fixed- route service is currently
offered in the community by AC Transit, the regional bus provider.
Service reductions in the area occurred in 2003, a result of persistently low demand for bus
travel. Yet in order to satisfy certain policies concerning access ( e. g. maximum walking
distance to access bus lines), certain low- demand routes were retained.
We argue that the proposed checkpoint service is a means of providing high- quality service in
a cost- effective way. We therefore hope that the service might eventually be deployed ( at our
Fremont site) as a pilot project. This present report has been prepared to further this end.
Details concerning the delivery of this checkpoint DRT service have already been described in
the ( rather lengthy) interim report cited above and are therefore only briefly summarized here.
Most of this final report is instead dedicated to describing a prototype of an automated
passenger reservation and bus dispatching ( i. e. scheduling and navigation) system that
supports the proposed checkpoint service. This report has been guided by the stated interests
and preferences of key personnel at AC Transit, the capabilities of AC Transit’s current
information systems, and relevant literature on the specifications and procurement of DRT
software.
1 Li, Y et al, Design of a Demand- Responsive Transit System, California PATH Report, May 2005
9
The prototype system is web- based. It is, moreover, fully- automated; i. e., once configured,
there is no need for human intervention. The bus navigation component of the system has
been implemented on a Pocket PC. It obtains passenger reservation and bus scheduling
information via the internet, either through a wireless Local Area Network or through a data
network for mobile communications ( e. g. GPRS). This prototype system is overviewed in
Chapter 2.
The functionality and usage of the system is documented in Chapter 3. Descriptions adopt the
perspectives of the DRT users ( riders and drivers); i. e. we describe how users and drivers see
and interact with the system.
System configuration and deployment is described in Chapter 4. Here we adopt the
perspective of the transit operator ( e. g. AC Transit).
Software deployment notes are provided in Chapter 5. Source codes and executables for the
system are provided on the project website, http:// www. ce. berkeley. edu/~ yuli/ 5402/.
10
2 OVERVIEW
This chapter provides an overview of how the prototype reservation and dispatching system
serves the checkpoint DRT. Also noted here are possible future enhancements to the prototype
system.
Presently, the system is fairly “ bare- bones”. Given that our literature review indicated a
complete absence of commercially available software for performing the necessary tasks, we
developed the prototype system to verify and demonstrate the feasibility of reserving trips and
dispatching DRT vehicles in automated fashion. Certain enhancements to the system--
cosmetic and otherwise -- would be desirable prior to its wider- scale deployment in the field.
The system functions as per the simple chart in Figure 1.
Figure 1: System Components
The reservation system includes a user interface through which customers make trip requests.
Each customer specifies her origin and destination stops along with her desired time for
making a trip. The interface is currently web- based, but an automated telephone- based
reservation component can be added in the future.
The customer’s request is automatically entered in the dispatching system. It uses the request
information to offer the customer a number of bus runs that might satisfy her request.
Bus service is provided in a “ hybrid” fashion; i. e., buses that serve the route alternate between
a DRT mode and a fixed- route mode from one run to the next. This service scheme is briefly
descried in the following chapter. For DRT runs, the dispatching component accommodates
only those additional reservations that will not violate bus trip time constraints: a limited
number of customers can be served on a DRT run, so that run times are kept sufficiently
small. The dispatching component determines whether or not a DRT request can be honored.
It does so in a fairly sophisticated way as has been described in the interim report. Customers
who make requests for a certain DRT run after that run has reached the trip time constraint are
11
notified of the fixed- route bus runs nearest in time to the DRT run. These customers may then
elect to travel via the fixed- route component of the hybrid bus service.
For DRT requests that can be honored, the customer makes a reservation by entering the
number on a prepaid ticket. This entry is made in response to prompts from the interface.
Once customer reservations for a given DRT run are finalized ( when the run has reached its
trip time constraint or shortly before the scheduled start of the run), the dispatching component
determines the route to be followed for that run. As per discussion in the interim report, buses
on DRT runs serve only customer trips that have been reserved and as such, the route can vary
from one DRT run to the next.
Routing is automatically performed in a fairly simple way, since checkpoints ( i. e. bus stops)
along the route are numbered in sequence and a bus always visits checkpoints in ascending ( or
descending)- numbered order of their numbers. ( A summary of this routing strategy is offered
in the following chapter and full description has been furnished in the interim report.) As part
of future enhancements, routes might be determined in the presence of temporary road
closures and other alterations to the street network due to maintenance, incidents, etc.
Shortly before beginning a DRT run, the bus driver downloads to an onboard computer ( e. g. a
Pocket PC) pertinent information about the run via wireless communication. This information
includes the customers to be picked up and the checkpoints to be visited on the run. Once the
run actually begins, the navigation component embedded in the system provides the bus driver
with driving directions, both by means of graphical displays and voice guidance.
Key details of the system are further described in the next section.
12
3 SYSTEM FUNCTIONALITY AND USAGE
In the proposed checkpoint DRT system, buses run between the Fremont BART station and
Newpark Mall and will alternate between checkpoint DRT service and traditional fixed route
service from one run to the next. The fixed route is shown in Figure 2. Checkpoints are located
along the route and sequentially numbered, as in the figure.
Figure 2: Map of Proposed Checkpoint Service
The hybrid ( alternating service) system is unique in the following aspects:
· Service alternates between a checkpoint mode and a fixed- route mode. A complete
cycle includes four bus trips: 1) BART to Mall, checkpoint mode; 2) Mall to BART,
13
fixed- route mode; 3) BART to Mall, fixed- route mode; and 4) Mall to BART,
checkpoint mode.
· During a fixed- route bus trip, the bus will visit all checkpoints along the route.
· While in a checkpoint mode, the bus will only visit checkpoints that are required to
serve ( previously reserved) customer requests and can therefore take shortcuts
between checkpoints. Although some checkpoints are skipped, those remaining
must be visited in sequence ( according to their numbers).
· The bus always departs BART and the Mall at scheduled times. The trip time for a
fixed- route bus trip is fixed. The trip time for a checkpoint bus trip is by a specified
duration. Thus buses stay on time with this service.
· Rides on checkpoint bus trips must be reserved, and the number of reservations on a
bus trip is limited to ensure the trip time for the bus trip does not exceed the
predetermined upper limit. Those passengers that cannot be accommodated on a
checkpoint run are “ pushed” to earlier or later fixed- route runs.
· Customers who do not want to use the trip reservation system can be accommodated
on fixed route runs.
The prototype process of reservation, scheduling, and navigation was briefly described in the
previous chapter and can be summarized as follows:
· A customer goes to the reservation website2 to make a request. The request specifies
a pickup location, a dropoff location, and a desired departure time from the pickup
location or arrival time to the dropoff location.
· The information system examines the database, runs the scheduling program and
selects bus trips3 that can fulfill the request at times close to what was requested. The
options are presented to the customer.
· The customer either picks one bus trip, quits, or makes a new request. The customer
uses a prepaid ticket number to make a final reservation for a DRT bus trip. Once the
reservation is confirmed, the pickup and dropoff locations, as well as ticket number,
are recorded in the database. The customer is given an estimate of when the bus will
arrive to the origin checkpoint and to the customers’ destination as well.
· At specified times shortly before each DRT bus trip, the driver downloads via
wireless communications the checkpoints to be visited and other relevant information
about the upcoming trip. Information is loaded to the navigation software on the
driver’s information device, i. e. a Pocket PC.
· Once the driver begins a DRT run, the navigation system gives the driver directions
and voice guidance.
All of the above reservation and dispatching tasks are automatic. Use of the passenger
reservation system is next described in section 3.1. Use of the bus driver navigation system is
then described in section 3.2.
2 Currently, only a web- based reservation system has been developed to demonstrate the concept. Phone- based interface to the database can be
added later when needed.
3 These trips are selected from the table of trips created by an administrator.
14
3.1 Reservation
From the start page of the reservation website, the customer first selects a route of interest.
( Multiple DRT routes can be managed by the same reservation system.) Once the customer
selects a route, the map of the route with checkpoint ( stop) numbers is displayed, as shown in
Figure 3.
Figure 3: Route Selection
Once the route is selected, the customer specifies origin and destination stops of her trip. The
system then highlights these stops on the map. The customer also specifies the date of travel,
and the desired departure or arrival time. Once the request is submitted, available options, with
estimated bus departure times ( from the origin checkpoint) and arrival times ( to the destination
checkpoint) for each option, are presented, as shown in Figure 4.
For example, the customer can either select a static ( fixed- route) bus trip, or a dynamic
( checkpoint) bus trip. If she prefers a static bus trip, no reservation needs to be made. The
customer simply shows up at the origin stop by the estimated bus departure time. On the other
hand, if a dynamic bus trip is preferred, the customer can make a reservation by clicking the
“ Buy” button.
15
Figure 4: Display of Bus Travel Times
Figure 5: Trip Request
Figure 6: Reservation Confirmation
Once a dynamic bus trip is selected, the next screen verifies the request, as shown in
Figure 5. The customer enters a number from a pre- purchased ticket, and clicks the “ Yes”
16
button to complete the request. If the ticket number is valid, then the trip is reserved and
confirmed, as shown in Figure 6.
For a dynamic bus trip, the time that the bus reaches a certain stop is not fixed, thus ranges for
departure and arrival times are given. These ranges will be updated dynamically as more
customers make reservations for the same bus trip4.
3.2 Navigation
The bus driver is assisted by a stand- alone onboard navigation system consisting of a GPS
receiver and a Pocket PC running software we developed for this project. The navigation
system obtains reservation and scheduling information via the Internet through wireless Local
Area Network or a data network for mobile communications ( e. g. GPRS). The navigation
system has the following features:
1. It allows the driver to access an online database to download the trip manifest for
a specific route date and time;
2. it allows the driver to use a route that has been previously downloaded in the
event that internet connection is unavailable in a given location;
3. after arriving at each stop a popup is created, displaying the address of the next
bus stop, as well the ticket numbers of all passengers who are boarding or exiting
the bus;
4. text- to- speech support has been added to give out voice prompts of the street
names the driver must maneuver onto, as well as notification of the next bus stop
to be visited
Instructions are provided below on how to run the prototype system.
3.2.1 Launching the program
Start the program named “ DRT” on the Pocket PC on which the demo has been installed. This
can be done by using the File Explorer and navigating to the directory “ Program Files/ DRT”
which is where the DRT executable resides. From there, a screen ( see Figure 7) will pop up
with three buttons: Setup Next Trip, View History, and Logs.
4In future deployment of the system, the functionality to allow customers get an update shortly before she leaves her home can be added.
17
Figure 7: Startup Screen of Navigation Program
3.2.2 Configuring the Program
After launching the DRT Driver Interface Program, click on the “ Options” button on the menu
bar on the bottom of the screen ( see Figure 7). Click on “ Configure”, and a form will pop up
( see Figure 8). Verify that the domain specified is in fact the domain where the DRT Server
side files are installed. If the files do not reside there, change the domain in the input box, and
click “ OK.”
Figure 8: Configuration Screen
18
3.2.3 Setting up a New Trip
Before using this feature, connect the Pocket PC to the internet. Then from the main menu,
click on the “ Setup Next Trip” Button. This will bring up a new form ( See Figure 9). Click the
“ Download Routes” button to query the online database for all possible routes. In the list
boxes that are now highlighted, select the route and the direction of the trip. The date and time
option defaults to the current day and time. There is no need to change the time to the exact
bus route time, since another selection box with a more accurate listing of times will follow.
Once the options have been set, click the “ Download Times” button which will enable the
next options box where the driver may now select the exact time of the route. The closest time
to the time selected in the previous menu is selected by default, but may be changed. Once the
information is confirmed, the user may press “ Download Manifest” to proceed to the manifest
form.
Figure 9: Route Setup
19
3.2.4 Reviewing a Previously Downloaded Trip
This feature is used when the Pocket PC has already downloaded the next desired trip. From
the main menu, click on the “ View History” Button. This will bring up a form that will
contain information regarding each trip stored in the Pocket PC’s memory. Each entry will be
formatted and sorted in the following manner: < Route name> < Direction> < Date> < Time>.
Once the desired route is found, the user may select it and click the “ View Manifest” button to
proceed to the manifest form ( see Figure 10).
Figure 10: Manifest for a Bus Trip
3.2.5 Viewing the Manifest
The manifest form contains a listing of all the stops that will be visited by the bus, the number
of passengers boarding and exiting at each stop, and the ticket numbers used by passengers for
making reservations. From here, the driver may click “ Navigate with Destinator” to launch
the GPS navigation program.
3.2.6 Navigating with Destinator
Powerloc’s Destinator is the navigation software used by our demo software. Upon launching
Destinator through our program, the driver will be presented with the “ trips menu”. From
there, the driver may select the trip named “ DRT” where he will see the stops that will be
involved in the trip. The driver may select “ Show Route” to see ( at a high level) where the
route will be going. When the driver is ready, he may press Navigate to proceed to the first bus
stop ( see Figure 11, an electronic map of the Berkeley- Albany area is shown here for
illustration). At each stop, the driver will be given a popup with information pertaining to the
20
next ( upcoming) stop: the number of passengers boarding and exiting the bus at the upcoming
stop, and their respective ticket numbers for verification.
Figure 11: Route Navigation
21
4 SYSTEM DEPLOYMENT AND CONFIGURATION
In this chapter, we detail the requirement and processes for deploying and configuring the
components of the prototype system.
4.1 Reservation and Scheduling
The web- based reservation and scheduling system is developed for running on a host server
with Linux and Apache. The deployment and configuration of the system is machine-dependent.
However, the major steps are the same for any computer. We developed the
system on a dedicated local server running Fedora 4, then migrated the system to a remote
server running Red Hat Enterprise. Here we illustrate the process of setting up and
configuring the system on the remote server. For convenience, suppose that the files are stored
locally under the “ D:\ DRT\” folder and the web server’s root directory is “/ public_ html/”.
The URL for the reservation website is http:// www. xeeyee. net. The hosting service provides
a configuration tool at http:// www. xeeyee. net/ cpanel.
The steps for setting up the web server are:
1. Make certain the webserver’s root directory, / public_ html/, is writable by both
the owner and the group. Upload files in “ D:\ DRT\ website\” to the webserver’s
root directory, / public_ html/. The files include:
· The preliminary files:
- ConnectFunctions. php
- LoadFunctions. php
- ViewFunctions. php
- EditFunctions. php
- createDatabase. php
- emx_ nav_ left. css
· The files that implement the reservation website customer interface:
- index. php
- submitReservations. php
- chooseReservation. php
- purchase. php
· The files that implement the reservation website administrator configuration
interface:
- admin. php
- adminEditRoute. php
- adminViewInfo. php
- createTickets. php
· The graphics files:
- drt_ banner. gif
22
- depart. gif
- arrive. gif
- default_ map. gif
· The file that supports graphic display:
- wz_ jsgraphics. js
2. Create a directory “ externalacesss” under the webserver’s root directory, and
upload the files in “ D:\ DRT\ website\ externalaccess\” to
“/ public_ html/ externalaccess/”. These files are to be used for interfacing between
the online database and the driver’s navigation system.
- getReservations. php
- getRoutes. php
- getRouteSize. php
- getRouteStations. php
- getstations. php
- getTimes. php
3. Prepare the database5.
· Go to www. xeeyee. net/ cpanel and sign in.
· Under “ Databases” click “ MySQL Databases”.
· Add a new user in the “ Current Users” area ( the user name and password
entered here will be used in connectFunctions. php)
· Add a new database in the “ Current Databases” area ( again, the database
name here is used in connectFunctions. php)
· Under the “ Add Users To Your Databases” area, make sure the desired
user and database are selected in the combo boxes. For “ Privileges,”“ All”
should be selected. Click “ Add User to Database.”
4. Edit “ connectFunctions. php”, change variables for user, password, and database
to the ones that were selected in the previous step. Note: the user and database
name will contain more than your chosen names. For example, in creating a user,
if you typed “ user,” the actual user name would be “ xeeyee_ user.”
5. Run the file “ createDatabase. php”. Several tables will be created with the
following characteristics:
Table Name: Routes
5 This step is highly system dependent.
Field Name Type Length
Name Varchar 20
23
Table Name: Reservations
Table Name: Static_ Start_ Times
Table Name: Dynamic_ Start_ Times
Table Name: Verified_ Tickets
Warning: DO NOT RUN “ createDatabase. php” MORE THAN ONE TIME. The
tables can only be created once, and any other attempts to run this file will result
in an error.
PictureFile Varchar 50
startTime Integer 5
endTime Integer 5
freq Integer 5
daysRange Integer 5
leg1 Integer 5
leg1Rest Integer 5
leg2 Integer 5
leg2Rest Integer 5
leg3 Integer 5
leg3Rest Integer 5
leg4 Integer 5
leg4Rest Integer 5
Field Name Type Length
Route Varchar 20
Start_ time Integer 5
Date Date n/ a
Depart_ station Varchar 10
Arrive_ station Varchar 10
Direction Varchar 10
Ticket Varchar 10
Field Name Type Length
Direction Varchar 8
Time Integer 5
Route Varchar 20
Field Name Type Length
Direction Varchar 8
Time Integer 5
Route Varchar 20
Field Name Type Length
Ticket Varchar 8
24
Once the web server is setup, go to http:// www. xeeyee. net/ admin. php to configure the
reservation and scheduling system through a web- based interface, as shown in Figure 12.
Figure 12: Web- based Configuration Interface
The web interface allows the administrator to add new routes to the system, and also to view
important information about existing routes. The “ Station Data” and “ Route Map” files6
provide information about the route. In the “ frequency” box, the administrator fills in the
number of minutes between bus departures, assuming even bus headways7. The “ Legs”
represent one complete run of the route in a certain direction. For example, Leg 1 could be
driving the route going Northbound. The first leg is set to be static, meaning it will not take
reservations from the website and will simply run as a fixed- route service. Legs 2 and 3 are
dynamic, meaning they will be operating based upon the reservations made online, and will
only visit the stops requested. Leg 4 is static. Once a route has been created, it can be selected
in the “ Existing Routes” menu, and its information will be displayed, as shown in Figure 13.
6 The generation of these files is detailed in the next section.
7 Uneven bus headways may be preferable for certain values of round trip time. This refinement to the system can be added in field deployment.
25
Figure 13: View and Configure Existing Route
The route information may be edited if the administrator wishes to change the parameters of
the route. When an existing route is selected, the “ View” section allows the administrator to
see important information about the route, such as the station information, the dynamic and
static start times, etc. Under “ View”, select “ station information”, the administrator can add or
change the name for the bus stop. One can also view the current reservations for a route at a
certain day, time, and direction.
After the routes have been configured by the administrator, users can make trip reservations
by going to the reservation website ( e. g. www. xeeyee. net). The reservation process has been
explained in the previous chapter. Here we explain the files that implement the functionalities.
The main page is implemented by the file “ index. php.” Here, the customer can select the
desired route, starting checkpoint, ending checkpoint, and boarding or alighting time. The next
screen will be “ submitReservations. php.” This page displays all the scheduled start times for
the bus runs that are closest to the customer’s input. If a customer decides to reserve a specific
dynamic bus trip and clicks the corresponding “ Buy” button, the customer will be taken to the
next page, which is implemented by “ chooseReservation. php.” Here, the customer can review
the bus time information, and enter her previously purchased ticket number. After clicking
“ Yes,” the customer’s reservation will be made and her ticket number will no longer valid for
26
other trips. The customer will be brought to “ purchase. php,” where her reservation
information will be displayed once more.
Purely for demonstration purposes, we have created the file “ createTickets. php”. Running the
file creates twenty randomly generated ticket numbers. ( Additional numbers can be
generated— twenty at a time— by clicking the button “ Create ( 20) More Tickets.”). These
ticket numbers are stored in the table “ Verified_ Tickets”. When one ticket is used to make a
reservation, it will be deleted from the table “ Verified_ Tickets”, i. e., the number is no longer
valid for making future reservations.
4.2 Route Data and Map Generation
A prerequisite of the web- based reservation and scheduling system is the route configuration,
including the route map, the sequence of stops, and travel time between each stop pairs ( if all
intermediate stops are skipped). This information is contained in two data files, one
containing checkpoint data and one containing the route map. These data files are generated
through a program developed with Microsoft Mappoint SDK and used when the administrator
adds a route to the system ( see Figure 12 in the previous section). Below we describe the setup
and the usage of the route data and map generation program.
Suppose the program files are stored locally in directory “ D:\ DRT\ mappoint\”. The files
include:
- AxInterop. MapPoint. dll
- Interop. MapPoint. dll
- DRT Route Data. exe
Copy these files to a folder on a Windows- based computer with Mappoint installed, then run
“ DRT Route Data. exe” to start the program. Figure 14 shows the starting screen with two tabs
near the top: “ Create Route” and “ Calculate Table”. The first tab allows the administrator to
construct a route with multiple stops, then export ( by clicking a button) the addresses of the
stops to a text file for manual editing. Under the second tab, the administrator imports ( by
clicking a button) the edited list of stops; the program generates a table containing distances
and travel times between each stop pair; and the administrator exports the two files needed for
configuring the reservation and scheduling website.
27
Figure 14: Route Creation
4.2.1 The “ Create Route” Tab
Using the built in MapPoint program, the administrator can create a bus route consisting of
multiple stops and then use the Export button to save all of the stops to a text file, which will
be used in the second tab: “ Calculate Table”.
The “ Create Table” tab contains the map of the United States, the Route Planner and some
associated toolbars that are native in MapPoint. On the upper right is the Export button and
below that is a List Box, and on the very bottom is a “ Saved to:” label.
· MapPoint Control:
In creating a route, most of the time will be spent interfacing with this section of the tab. To
add a stop to a route, the administrator can either use the Route Planner’s text box “ Type place
or Address”, or click on a place in the actual map. Doing either will result in the address being
placed in the text box in the Route Planner, which must then be added as the next stop in the
route by clicking the “ Add to Route” button. Any stop added to the Route Planner must be a
valid address. If not, when the program tries to process the route for exporting, a “ Not a valid
address” message will be displayed that details which stops must be changed or removed.
· Export Button:
28
Clicking the “ Export” button ( right side of Figure 14) will process the map and find all the
locations along the route. These locations will be saved to a text file which will be used later.
If any of the stops are not a valid address ( e. g. missing the street address, city name, or state),
an error message is displayed.
· List Box:
The List Box on the right side of the screen below the Export button ( see Figure 14) is empty
when the map is first loaded. After the Export button is clicked, and if all of the stops are
valid, then the List Box will display what was saved to the file: The stop numbers and the
addresses.
29
4.2.2 The “ Calculate Table” Tab
By clicking the “ Calculate Table” Tab in Figure 14, one is presented with Figure 15. Using the
“ Load Route” button there, the administrator can import a route from a text file ( created by the
first tab: “ Create Route”) into the built in MapPoint program. After this, the administrator can
tell the program to calculate all the data ( bus travel time, distance, etc) between stops along the
route using the “ Create Table” button. 8 The resulting table will then be displayed in the Text
Box on the right. The calculated information can then be exported through the “ Export for
Database” button into files with specified format. These files are necessary when the
administrator adds a route to the system.
As shown in Figure 15, the “ Calculate Route” tab contains the MapPoint Control, three usage
buttons below it, and a List Box on the bottom left. The right side of the tab is the Text Box.
Figure 15: Route Data Generation
· MapPoint Control:
8 Travel time is calculated by Mappoint with driving speeds on arterial roads and streets set to 17 miles/ hour. This is equivalent to a bus effective
speed ( i. e. distance divided by travel time, including stopping time) of about 11 miles/ hour. Using these parameters will produce a bus schedule
close to the published schedule.
30
This MapPoint Control ( shown near the top of Figure 15) is used to display the route after the
route has been loaded by the “ Load Route” button.
· “ Load Route” Button:
This button is used to read a text file ( created by the “ Create Route” tab) that has the list of all
the stops along a route. Clicking the button will prompt the administrator for a text file to read
from. I the file selected is a valid DRT route file, then all the stops will be loaded into the
MapPoint Control and also listed in the bottom List Box for reference.
· Create Table Button:
The “ Create Table” button is used after the route has been loaded into the map. When clicked,
all the stops within the route will be scanned; and the distance and travel time between each
stop pairs will be calculated and placed in a table in the Text Box. If a route has not been
loaded into the map at the time when the button is clicked, a “ Please load a route” message
will be displayed and nothing will be calculated.
· Export for Database Button:
This button is used to create a text file with a specific format that is readable by the database
associated with the program. A route map (. bmp) is also created by pressing the “ Export for
Database” button.
· List Box ( Below Map):
The List Box is used for reference. Every stop will be added to it when the route is first loaded
using the “ Load Route” button.
· Text Box ( Right side of tab):
31
After clicking the “ Create Table” button, a square matrix will be created and displayed in the
“ Text Box”. Each cell will contain all the data calculated between its starting point and ending
point.
4.3 Navigation
The driver navigation system uses a mobile device to guide a driver through a dynamically
created bus route conveniently, accurately, and safely. The system has been implemented on
Pocket PC with Windows Mobile 2003. Destinator is selected as the underlying mapping and
navigation software on Windows Mobile mainly for the availability of Software Development
Kit ( SDK) for each. In addition, SmartySoft Mobile Speech SDK is used for text- to- speech on
Windows Mobile. A GPS receiver, either wired or wireless ( e. g. Bluetooth), can be used for
automatic vehicle location. Exchange of data between the server and the mobile device has
been tested using wireless LAN ( 802.11b) and GPRS data service. Below we describe the
installation and configuration of the system onto the mobile device.
To guarantee a successful installation, it is recommended that all these packages be installed
regardless of whether they have been previously installed on the Pocket PC. This ensures that
compatible versions of dependent software are used with the DRT Driver Interface program.
4.3.1 Install Destinator
After installing Destinator via its installation CDs ( acquired separately) onto your desktop,
launch the Destinator Console via the start menu. From there, click on the Install Software
button to install the Destinator software and Maps of the desired region onto the Pocket PC.
4.3.2 Configure Destinator
Run Destinator on the Pocket PC to accept the license agreement. Then from inside the
program, click on the “ Options” menu. First, switch to the desired map. Second, under the
Voice Alerts section, turn off all of Destinator’s voice alerts.
4.3.3 Install Microsoft . NET 2.0 Compact Framework
Go to the “ D:/ DRT/ ppc/ Prerequisites/ NET Compact Framework 2.0” folder. Try clicking on
the NETCFSetupv2. msi installer from Microsoft. If it works, you are done. If an error results,
then copy the NETCFv2. ppc. armv4. cab file to the Pocket PC. Then from the Pocket PC
( running Windows Mobile 2003), access the File Explorer program, navigate to the cab file
and run it.
4.3.4 Install the OpenNETCF Library
Open the “ D:/ DRT/ ppc/ Prerequisites/ OpenNETCF 1.4” folder. Copy the
OpenNETCF. SDF. wce4. armv4. cab file to the Pocket PC. From the Pocket PC click the cab
file from the File Explorer program to install it.
4.3.5 Install SmartySoft Mobile Speech SDK
Open the “ D:/ DRT/ ppc/ Prerequisites/ Smarty Soft Mobile Speech SDK” folder. Copy the
smmobile. ARM. CAB and smmobile. inf files to the Pocket PC. From the Pocket PC click the
smmobile. ARM cab file from the File Explorer program to install it.
4.3.6 Install the DRT Driver Interface Program
32
Open the “ D:/ DRT/ ppc/ Installer” folder. Copy the DRTinstaller. CAB and DRtinstaller. inf
files to the Pocket PC. From the Pocket PC click the DRTInstaller. CAB file from the File
Explorer program to install it.
4.3.7 External Dependencies
For the navigation program to download routes and manifests, a server running the DRT
server side software must exist; in particular, the database that holds all of the routing data.
Moreover, the directory “ externalaccess” in “ D:/ DRT/ ppc/ Prerequisites/ Server Files/” must be
in the root directory of the domain name. If the server was installed correctly, this directory
should have automatically been copied to the server.
In summary, the overall system consists of three components: 1) the web- based reservation
and scheduling system; 2) the PC- based route data and map generation system; and 3) the
Pocket PC- based driver navigation system. These components are developed and deployed on
different platforms and they work together to provide a functional prototype for the checkpoint
DRT service. More functionality can be added later to this prototype to meet the requirements
of field deployment.
33
5 SOFTWARE DEVELOPMENT NOTES
Among the three component systems developed and deployed on different platforms, the
navigation system poses most of the challenge because it is a mobile application with voice,
mapping, and communications. Therefore, we provide below detailed development notes for
the navigation system.
5.1 Tools Used
Because the DRT Driver Interface ties together a broad number of features and capabilities,
there were several development kits, libraries, and development environments used.
5.1.1 Software Development Kits
Microsoft Pocket PC 2003 SDK and Microsoft’s Mobile 2003 Developer Resources
These kits are provided by Microsoft to facilitate development on the Pocket PC. They contain
the necessary compiler tools to compile into ARM binaries that are compatible with Pocket
PC architecture. These kits also include emulators and debugging tools to develop mobile
applications on a standard desktop running Visual Studio.
Powerloc’s Destinator SDK 5.0 ( http:// www. destinatortechnologies. com)
The software used for navigation is bundled completely in the Destinator SDK. Destinator is a
leading consumer navigation program widely use in Europe. The SDK provides a COM
interface via a dynamically- linked library with accessor functions to the software.
SmartySoft’s Smart Read Mobile SDK 2.0 ( http:// www. smartysoft. com)
Though initial speech development for our system used Microsoft’s Speech SDK 5.1, it was
unfortunately not portable to mobile devices. We therefore chose SmartySoft’s Speech SDK
which provides a Text- to- Speech engine for the Pocket PC2003. Text- to- Speech was needed
to provide the user with a voice prompt of the exact street names a maneuver would be
occurring onto.
5.1.2 Libraries
OpenNETCF 1.4 ( http:// www. opennetcf. org)
The . NET Compact Framework has severe limitations when contrasted with its . NET
counterpart. The OpenNETCF Library alleviates these limitations by porting to the . NET
Compact Framework a select set of useful classes and functions that are available in . NET.
The DRT software uses the Core class in the OpenNETCF to change the Pocket PC 2003
Operating System’s primary volume. This functionality was required in order to silence
unwanted voice prompts by Destinator.
5.1.3 Integrated Development Environments
Microsoft Visual Studio 2005 ( http:// msdn. microsoft. com)
This latest Integrated Development Environment ( IDE) from Microsoft is fully compatible
with the . NET 2.0 Framework and the latest version of C#. The IDE allows easy integration of
the managed C# code, COM libraries, unmanaged libraries, and deployment to the Pocket PC.
5.2 Program Flow
34
The following is an overview of what development components are used in the application:
When the driver launches the program, he is launching an executable file compiled by
Microsoft Visual Studio. The very first menu attests to this with the usage of Windows Forms,
the main graphical user interface class used in . NET. The interface is completely programmed
in C#, as are the menus for downloading the next route. This programming takes advantage of
the System. Net namespace provided by . NET.
At the point the user clicks the “ Navigate with Destinator” button; Powerloc’s Destinator
takes over the foreground of the screen. However, the initial entry program is still running in
the background. As Destinator loads for the first time, the DRT program loads the checkpoints
into the Destinator software using the Destinator SDK’s COM interface. Moreover, the DRT
program readies the manifest information for the entire trip so that it may be displayed to the
driver as the trip progresses.
As the user drives from station to station, voice prompts are given to signal maneuvers that
must be made such as “ turn left” and “ turn right.” These prompts are given by the standard
Destinator software. However, following these prompts is another voice that states the street
name on which the maneuver is to be performed. For example, “ Turn left onto Oxford Street.”
Because the Destinator SDK does not support Text- To- Speech, the SmartySoft Mobile Speech
SDK was used to add this voice feature. Destinator signals to the DRT program that it is
prompting the driver about a maneuver, and then the DRT program creates a valid phrase to
give out and passes it on to the Speech Engine.
Upon arriving at a stop, the driver will see a popup window. This popup is a windows form
that is part of the Driver Interface program. It displays the ticket numbers of those passengers
getting on and off the bus, as well as the next checkpoint to be visited. This information was
saved when the initial manifest was downloaded. The driver may notice that the popup
window is slightly delayed; it does not popup immediately after the driver arrives at a station.
The reason for this is because Destinator gives voice prompts for the next stop right after a
station is received. Because we expect the bus driver to wait at the station instead of simply
driving by, we use the OpenNETCF library to turn off the Pocket PCs sound so that the driver
is not confused by the next prompt. After a second, the sound is turned back on, and the popup
window is displayed.
5.3 Key Technical Details
5.3.1 Storing routes in Destinator
In order to prevent old or outdated routes from populating Destinator’s route saving and
recalling system, routes stored in Destinator are kept to a minimal. Every time the “ Navigate
with Destinator” button is clicked in the DRT program after the manifest has been reviewed,
all the Destinator routes are deleted. Only the route about to be followed is input into
Destinator by the program. To see this, run Destinator independently of the DRT program.
Then click on the car icon on the left hand side of the screen, and click on the Trip planner
35
button. The only route available should be the “ DRT” route. Selecting this route will reveal
that “ DRT” holds all the stops of the last route that was downloaded by the DRT program.
5.3.2 Retrieving trips from the web server
There are several PHP scripts used to access the web server database in order to retrieve trip
data. They are described in the following table.
Table 1: Server- side scripts for interfacing with the navigation system
File Name Function
getRoutes. php Returns the names of all the different routes on the server
with new lines after each route.
Example return:
Route1
Route2
getRouteSize. php Returns an integer representing the size of a given route.
The file requires GET data to specify the route.
For example,
getRouteSize. php? route= Route1
Example return:
5
getRouteStations. php Returns all the stations in a given route with new lines
after each station address. The file requires GET data to
specify the route.
For example,
getRouteStations. php? route= Route1
Example return:
2000 Oxford St, Berkeley, CA 94704
2520 Durant Ave, Berkeley, CA 94704
getTimes. php Returns all the times a bus takes a specific route on a
given day. The file requires GET data to specify the route
and direction of travel.
For example,
getTimes. php? route= Route1& direction= Forward
Example return:
7: 25
7: 40
13: 55 ( Hours given in 24 hour time)
getReservations. php Returns all the reservations made for a particular bus leg.
It returns the ticket number of the passengers boarding and
36
exiting the bus. The file requires GET data to specify the
route, direction, date and time of the route. Date is
specified as year- month- day. Time is specified in minutes
rather than hours.
For example,
getReservations. php? route= Route1&
direction= Forward& date= 2006- 08- 19& starttime= 815
Example return:
65421660
1
8
91249707
3
5
The return format is a ticket number, followed by the
station that the ticket holder is picked up, and then the
station that he is dropped off at.. Stations are represented
as numbers that correlate to their order in the route.
37
5.3.3 Storing trips on the Pocket PC
When trips are downloaded to the Pocket PC via the “ Setup Next Trip” form, they are stored
on the Pocket PC for future offline use in the folder “ DRT/ History.” The format of the file
name is “< route name>< direction>< date>< time>. xml,” for example, newForward0623850.
This is the “ new” route in the forward direction, on February 3rd, 2006 at 850 minutes or
2: 10pm. Inside the file is an Xml Serialization of the Trip object, which is the program’s
internal representation of a trip. As per Xml standards, the file is composed of tags that denote
different member variables of the trip object. Its first tag is the Xml encoding version number,
1.0. Next is the trip tag denoting that the file contains a trip object. Then follows a list of the
stops a certain DRT trip will have. At each of these stops, a list of passengers getting on and
off the bus is provided. There is a second list containing all the possible stations on a given
route.
5.4 Source File Descriptions
There are many source files in the DRT program. Though they are commented, this table will
provide a brief overview of each file.
AddressTools. cs Tools for creating and manipulating Destinator Point objects.
ConfigureForm. cs Form for helping the user change program settings visually.
DestinatorTools. cs Tools for dealing with Destinator Trips.
DirectionsTools. cs Tools for modifying Destinator Maneuvers.
HTTPQuery. cs Class for http querying to download routing information.
MainForm. cs Main thread of application, includes initial form.
ManifestForm. cs Form that displays the next route's manifest.
NextStopPopUp. cs Form that alerts driver of next stop, boardings, and departures.
Program. cs Entry point for application.
Settings. cs Object for holding modifiable program settings.
SetupNextTripForm. cs Form to download information for the next trip.
Splash. cs Form that serves as a splash screen during loading.
Station. cs Station object to store relevant data for a stop.
TextToSpeech. cs Wrapper class for SmartRead Mobile Speech SDK.
TimeTools. cs Tools for manipulating time, particularly in order to consolidate
differences in representations between the time stored on the
server, and in this application.
Trip. cs Object to represent an entire trip, including its stops all possible
stations, and direction.
ViewHistoryForm. cs Form for viewing past trip entries. For reusing trips previously
downloaded.
5.5 Compilation Process
The DRT Driver Interface program was created using Microsoft’s Visual Studio 2005
Professional Edition. The . NET 2.0 Framework is necessary for the “ solution” to be compiled
properly. Visual Studio 2005 is required for the solution to be viewed and managed. Also, the
38
Pocket PC 2003 SDK must be installed for the compiler to create files deployable onto the
Pocket PC 2003 Operating System. The SDK is free and can be found in the following
directory: “ D:\ DRT\ ppc\ Prerequisites\ Microsoft Pocket PC 2003 Development Tools.”
To open the solution, find the file “ DRTpda. sln” under the “ D:\ DRT\ ppc\ source\ DRTpda.”
Opening the file launches Microsoft Visual Studio 2005. The solution contains two projects.
The primary project is DRT which is the mobile application. The other is DRTinstaller which
packages the DRT project into a cab file deployable on a mobile application.
Right clicking on each project name in the Solution Explorer will give you the option to
“ Build” each solution, which is equivalent to compiling. Building the DRTinstaller project
will output a cab file in the “ D:\ DRT\ ppc\ source\ DRTpda\ DRTinstaller\ Debug” folder that
can then be transferred to a Pocket PC in order to install the software. As for the DRT project,
since it is the default project, you can press F5 or go to Debug-> Start Debugging to
automatically deploy the program onto any Pocket PC currently interfaced with the computer
via ActiveSync.
5.6 Complications
Below is a list of programming problems we encountered in creating the prototype system.
The list is included here so that future work can benefit from our experience.
5.6.1 Windows Mobile 5.0 and Pocket PC 2003
To our dismay, Destinator SDK 5.0 is not fully compatible with Windows Mobile 5.0, which
was our initial operating system for development. There are two reasons for this. First,
Destinator is unable to write to the flash memory on the Pocket PC. This means that
Destinator was limited to single- point routing since it could not save multiple points for a
route. To overcome this obstacle, the decision was made to create an external multi- point
routing system. Unfortunately, the second problem with Destinator was that the graphical user
interface would not display correctly on a 640x480 resolution screen. A patch found for
Destinator to fix this problem did not fix the problem when the SDK was used, and was thus
insufficient for our needs. Therefore, we developed the navigation system on Pocket PC 2003
instead of Windows Mobile 5.0.
5.6.2 Destinator’s built in TTS
The decision to use a Text- to- Speech engine from a different source came late in the
development of the software. Originally, the Destinator SDK was used only to load points
into the software. Afterwards, the SDK COM would be shut down, and Destinator itself
would be run. When this was done, Destinator’s built in TTS would function correctly. But
the introduction of a popup to tell the driver the location of the next stop, as well as who was
boarding and exiting the bus at the current stop, means that the Destinator program would
have to be run through the Destinator SDK. Since the SDK did not support TTS, we had the
resort to SmartySoft’s Mobile Speech SDK to complete the TTS system.
39
5.6.3 Destinator SDK Bugs
Several bugs specific to the programming interface of the SDK hindered the development of
our software:
First, the Maneuver Object used by Destinator to specify the route a bus will be taking acts
haphazardly. On the PC version of Destinator, this object has a consistent state and can be
retrieved at any time via the COM interface. Yet, the Pocket PC version of Destinator acts
inconsistent with general programming principles. Calls to the object can only be done at
specific times, which are not explained in the Destinator SDK. Otherwise, exceptions are
thrown in the program which cannot be debugged since they take place in unmanaged code.
The placements of the current object retrievals are found completely on the basis of many
hours of trial and error.
Second, several functions in the Destinator SDK simply do not work. Among them, the
DestClass. ShowRoute() function crashes the Pocket PC. The ShowRoute() function would
have been useful for showing the driver the entire route initially before departing on the leg.
Other functions, such as DestClass. ReturnToMainDestinatorWindow(), either do not work, or
their specific usage is undocumented. Also the DestClass. MPRNavigate() function does
nothing, although this functionality was desired to free the bus driver from having to manually
select the DRT route, and click navigate to begin routing to their first stop. Unfortunately,
without these functions the driver is at times slightly inconvenienced.
5.6.4 Using . NET and an unmanaged COM
The initial prospects of using the Destinator SDK with . NET were grim. The best chance
appeared to be via the use of embedded Visual C++ 4.0 since the . NET Compact Framework
1.0 did not support Runtime COM Interoperability Services. Significant time was spent on
creating a wrapper class for the COM library in embedded Visual C++ 4.0 so that unmanaged
PInvoke calls could be made in the . NET class. These attempts were partially successful, but
implementing a wrapper for the entire COM library proved daunting. The solution came with
the release of . NET Compact Framework 2.0 in December 2005 which included Runtime
Interoperability making it substantially easier to make unmanaged calls to the Destinator
SDK.
5.7 Conclusions
Several lessons were learned over the course of development. First, the use of Destinator’s
prematurely released SDK created a plethora of problems. With bugs internal to the
Destinator SDK causing malfunctions, solutions were often nonexistent or excessively
inconvenient, ultimately hindering the capabilities of the DRT Driver Interface. On the other
hand, the . NET 2.0 Compact Framework from Microsoft proved to be reliable and powerful.
As such it is recommended in the future to use Microsoft and other established software
providers when dealing with the development of sensitive devices such as Pocket PCs.
40
Second, though Pocket PCs provide a low cost and mobile solution for a bus driver interface,
the limited size of the display has drawbacks. For example, it is desirable for the bus driver to
see the entire route at all times in either visual or text format. But with the limited screen size,
only the driver’s current position, and immediate maneuvers can be seen. There is no room for
any other concurrent display. An unexplored solution would be the use of a Windows CE
device, which are slightly larger, but also has accompanying compatibility issues.
Recommendations for similar future projects include using the . NET framework and . NET
compatible software to the extent possible to limit development hazards. A Windows CE
solution would seem most effective in terms of cost and mobility. Alternatively, a laptop
version might serve the driver better in displaying information. The Destinator SDK is
incomplete and “ buggy”, and though its superior competitor TomTom has released a stable
SDK, it is completely devoid of Text- to- Speech features. In the coming year, however, new
versions of both SDKs are being released which will increase the viability of future endeavors
similar to this project.
After the thorough exploration of mobile technologies, we believe the full aspirations of the
DRT Driver Interface ought to be attainable in the near future. The development of our
prototype system occurred between Microsoft’s transition from . NET CF 1.0 to . NET CF 2.0
in December 2005. The latter was made available in January 2006, and has made it much
easier to produce effective mobile applications. We recently learned that version 6.0 of
Windows CE is set to release soon. With this version, the developer will be able to choose
which features the operating system should support. This allows for a very compact and
efficient system. Mappoint will run very smoothly on it. This would simplify future
development of navigation applications.