An Automated Transit Stop Data Collection System
Albert Gan, Ike Ubaka, and Fabian Cevallos
ABSTRACT
A transit stop inventory is needed for various transit planning, operational, and maintenance
applications. The traditional methods of collecting data for a transit stop inventory using
clipboard, pencil, and paper are time-consuming, inaccurate, and difficult to update, which often
discourage transit agencies from committing resources to such effort. The accessibility of transit
agencies to an automated, affordable system that facilitates the collection and update of a transit
stop inventory is thus important to help improve transit service. The availability of such a
system will also contribute directly to the standardization of transit stop inventories, allowing the
development of customized tools and applications that can be used by multiple transit agencies.
This paper describes an effort to develop an automated system for the collection of a standard
transit stop inventory for Florida’s transit agencies. Taking advantage of today's computing,
imaging, and satellite technologies, the system allows both attribute and imagery data to be
entered or captured in the field and saved directly into a GIS database, thereby, eliminating the
labor-intensive task of entering data in office.
INTRODUCTION
A transit stop inventory is needed for tracking the location of stops, identifying the type and
conditions of amenities, determining how well areas of interest are served by transit service,
assessing the accessibility for disabled persons and ADA compliance, upgrading the right-of-way
appearance, etc. The advent of Advanced Public Transportation Systems (APTS) makes it even
more important for transit agencies to keep an up-to-date inventory of transit stop data. To
implement APTS projects such as automatic passenger counters, automatic vehicle locators,
computerized trip planners, and automatic voice annunciation systems, an accurate transit stop
inventory is necessary. However, many transit agencies still do not have a transit stop inventory
that can adequately support APTS applications, and many others do not have an inventory at all.
The traditional methods of collecting transit stop inventory using clipboard, pencil, and paper are
time-consuming, inaccurate, and difficult to update, culminating to the reluctance of transit
agencies to commit resources to such effort. The accessibility of transit agencies to an
automated and affordable system that can facilitate the collection and update of the transit stop
inventory can help improve transit service. The availability of such a system can also contribute
directly to the standardization of transit stop inventories in Florida. Currently, transit stop
inventories are developed separately by each transit agency and they do not share the same data
structure, attributes, accuracy, coordinate system, software platform, etc. A standard transit stop
inventory will allow customized tools that can be used by all agencies to be developed, thus
avoiding duplication of efforts by individual agencies.
This paper describes an automated system for the collection of a standard transit stop inventory
for Florida’s transit agencies. Taking advantage of today's computing, imaging, and satellite
technologies, the system will allow both attribute and imagery data to be entered or captured in
the field and saved directly into a GIS database, thereby, eliminating the labor-intensive task of
processing and recording data in office. The system facilitates the development of transit stop
inventory databases and help to establish a uniform standard of transit stop data attributes for
Florida’s transit systems.
SYSTEM COMPONENTS AND CONFIGURATION
It was envisioned that a system capable of recording both location and other transit stop
attributes in the field would meet the need. It was also desired for digital pictures to be collected
to allow transit agencies to view the actual transit stop and its surrounding areas. Accordingly,
the system would consist of the following components:
1.
2.
3.
4.
A handheld computer.
A GPS (Global Positioning System) unit.
A digital camera.
A database application for data recording.
As transit agencies are usually working on tight budgets, cost was a major criterion in the
development of the system. Accordingly, it was decided that each of the above component
would be acquired separately, as opposed to purchasing a bundled package (e.g., combining
components 1, 2, and 3 in a single unit) marketed by various vendors, which was relatively pricy.
This approach also provides the flexibility to upgrade individual components as needed.
ArcPad was selected as the platform for the database application component. ArcPad provides a
GIS interface and a relatively easy-to-use development tool called Application Builder. ArcPad
also provides functionality to communicate with a GPS receiver that can display the current GPS
location on the map. Because the ArcPad application is not stand-alone, each handheld computer
must be pre-installed with a copy of ArcPad in order to execute the application. The cost for
ArcPad licenses range from $495 for a single license to $300 per license for 51 or more licenses.
The developed field data collection system basically consists of an ArcPad application running
on a handheld computer that is wirelessly connected to a GPS receiver for location information.
The digital camera works as a stand-alone unit and is not connected directly to the handheld.
Pictures from the digital camera are merged with their respective transit stops based on time
stamps of the transit stop records and the picture files. This merging process is described in the
Post Processing section later in greater detail.
While a variety of handheld computers are available in the market, the highly popular HP iPAQ
Pocket PC was selected. However, any other brands can be used. Most handhelds today come
with at least 32 MB ROM and 32 MB of SDRAM that are sufficient for this application. A more
critical system requirement, however, is the CPU speed. Because the system is expected to make
uses of a street network and a list of street addresses, a faster CPU can help reduce the data
loading time. An iPAQ model that provides good performance at a reasonable cost is HP iPAQ
model hx2415. It includes 64MB ROM and 64MB SDRAM and comes with the Intel® 520MHz
processor. The estimated cost for the unit is about $400.
The HP iPAQ Navigation System was selected for the GPS component. The system is a selfpowered, Bluetooth-enabled unit capable of eight hours of continuous operation on a single
charge. The self-powered device, as opposed to the one that needs to be plugged to a charger,
allows the survey crew to leave their vehicle to collect data. Compared to those connected
through the Secure Digital slot, this stand-alone unit does not take away the slot that can be used
for additional memory for the handheld, nor does it consume the handheld’s limited battery
power. The unit provides a minimum of 16-meter location accuracy, which is sufficient for this
particular application. The price for the unit is about $270.
STANDARD TRANSIT STOP ATTRIBUTES
The first step in developing the ArcPad application was to identify a set of transit stop attributes
that can be treated as standard for Florida transit systems. A survey of Florida transit agencies
was conducted to obtain information on the state-of-the-practice in transit stop inventories. The
survey was sent to all 25 Florida transit agencies with fixed route services. A total of 16 systems
responded to the survey, yielding a 66% response rate. The survey included a total of 13
questions on inventory collection methods used, desirable transit stop attributes, transit stop data
applications, transit stop data maintenance, and transit stop data utilization.
Based on information obtained from the survey, a set of 36 transit stop attributes were identified.
These attributes assure that Florida’s transit system will have those attributes and with the same
consistent definitions. The standard attributes are defined and explained below:
•
•
•
•
•
•
•
•
•
•
•
•
Assessor: The name of the person who performs the field data collection.
Latitude and Longitude: The real-time latitude and longitude locations and are
automatically collected from a GPS unit.
Stop Number: A unique identifier assigned to a particular transit stop and sometimes
displayed on the transit stop sign.
Status: “Active” if the transit stop is currently being used or “inactive” if it is not.
Placement: The location of a transit stop in relative to the cross street. It can be “far” for
far-side stop, “near” for near-side stop, or “middle” for mid-block stop.
Route Direction: This is the route direction. Depending on the route structure, some
agencies may define this as one general direction for the whole route (e.g., NB for
northbound), while others may specify the direction of the route at the specific stop.
Distance to At-Street: The distance to the cross street in feet. If a measuring wheel is not
used, this can be a distance approximated by the assessor.
On-Street: This is the name of the street along the transit route.
At-Street: Enter the name of the closest cross street to the transit stop location.
Transit stop amenities: The following amenities are included: shelter, bench,
advertisement, trash can, schedule holder, lighting, info fare booth, bike rack, vending
machine, restroom, nearby phone, parking, electrical message, and info kiosk.
Sidewalk: Three levels of sidewalk conditions can be entered: no sidewalk, 5-foot or
wider sidewalk, and below 5-foot sidewalk.
ADA: There levels of ADA accessibility are used: accessible, functional, and not
accessible. A transit stop is considered accessible when it can be accessed by people in
wheelchair. Functional stops can be accessed by people in wheelchair, but they are not in
•
•
•
•
•
•
•
•
•
•
full compliance with ADA regulations. Not accessible stops are those that cannot be
reached by people in wheelchair.
Curb Cut: Whether there are ramps for people with wheelchairs to get to the transit stop.
Loading Pad: Whether there is a loading pad to load people in wheelchair.
Obstructions: Check if there are obstructions that will prevent people in wheelchair from
accessing the transit stop, including obstructions in any access directions.
Bay: Whether there is a transit bay, usually a bus bay.
Bike Lane: Whether there is a bike lane in front of the transit stop.
Trees: Whether there are trees beside the transit stop.
Stop Sign: Whether there is a transit stop sign.
Sign not Clear: Whether the information on the stop sign has become difficult to read.
Routes: The route numbers that are usually shown on the transit stop sign.
Post Type: The type of post to hold a transit stop sign: a dedicated post used exclusively
for transit stop sign, a utility pole, or any others.
In addition to the above attributes, a total of eight general attributes were included to allow
individual transit agencies to define their own additional attributes.
MOBILE GIS IMPLEMENTATION
After the transit stop attributes were identified, they were programmed using the ArcPad
Application Builder. The attributes were organized in four tabs, as shown in Figures 1(a) to (d),
respectively. Once the GPS is connected to the ArcPad application, the latitude and longitude
data fields are automatically filled in. To speed up data entry in the On-Street and At-Street
fields, a list of all possible street names are stored in a file and is automatically loaded when the
ArcPad application is executed. Within the data entry field, as soon as part of a street name is
typed in, all street names that match the tapped-in portion of the street name will be displayed.
The user can then identify and select the correct street name from the list and then go to the next
field. Alternatively, the user can type in the complete street name from the screen keyboard, if a
street name is not found on the list. In addition, the system allows setting overall default values
for entries that are seldom changed. The Assessor and On-Street fields can be set at a specific
value until a new value is reset. This is done by simply tapping the set button besides these entry
fields. For shelters and benches, the user enters the number of each. Other transit amenities that
are less common, thus only the presence of each is recorded with a check mark. All of these
features were designed with the intent to speed up data collection in the field.
POST PROCESSING
After returning from a field data collection session, the user may decide to transfer the collected
data resided from the handheld to a desktop computer. It is advisable that such data transfer be
done after each data collection session to avoid accidental data loss. If the file transfer is done
for the first time, the user first creates a project folder to store all the data for the entire data
collection project. For each data transfer, the user creates a subfolder to store the application
shapefiles. If pictures are collected for the transit stops, they are also transferred to the same
subfolder.
(a) Location Attributes
(c) ADA and Miscellaneous Other Attributes
(b) Amenity Attributes
(d) Additional User-Defined Attributes
Figure 1. Data Entry Screens on ArcPad
The Florida Transit Geographic Information System (FTGIS) was used as the desktop GIS
platform for these applications. FTGIS is a system component of the Florida Transit Information
System (FTIS)—a user-friendly software system designed specifically for transit planning
applications in Florida. As a stand-alone GIS system, FTGIS comes with ready-to-use GIS
shape files for Florida’s fixed-route transit systems as well as many easy-to-use, customized GIS
functions and applications. The system also provides functionality for retrieving the transit stop
attributes and pictures, querying the transit stop inventory, and visualizing the transit stop
summary data. For detailed information on FTIS and FTGIS, refer to the FTIS User’s Guide or
visit the FTIS homepage at: http://lctr.eng.fiu.edu/ftis/.
Since pictures for transit stops are taken and stored separately from the handheld, they must be
merged with their respective transit stops as part of the post-processing tasks. This is done by
matching the time stamps of transit stop records (i.e., the specific time at which each record is
saved) and the time stamps of pictures taken (i.e., the specific time at which each picture is
taken). FTGIS provides a function to automatically perform this linkage.
Figure 2 shows the main screen for this function. In this screen, the user first specifies the folder
that contains all the transit stop attribute data and the pictures collected from the field from
different time periods. The user can click the Browse button to bring up the screen shown in
Figure 3, which allows a folder that stores the collected transit stop data to be specified. As soon
as the folder is specified, all the subfolders under the folder will be listed on the list box.
Figure 2. Screen for Merging Transit Stop Databases
Figure 3. Screen for Searching and Specifying a Data Folder
Since the attribute data and the pictures are collected using two separate hardware units, the
difference in the system timers of the two units must be accounted for, so that pictures can be
correctly merged with their respective transit stop records based on the time stamps. As shown
in Figure 2, the timers for the camera and the handheld computer are entered in the second and
third columns, respectively. When these fields are left empty, it is assumed that the timers for
the two units were closely synchronized to at least within one minute at the time of data
collection.
For the merging scheme to work efficiently, the pictures must be the last item collected by the
data collector. This can be done either right before or right after an attribute record is registered
in the handheld computer for a transit stop, so the times from both devices are close. Since
multiple pictures for a transit stop can be taken at around the time the attributes for a transit stop
are saved, the merging process must allow a range of time within which the pictures are
considered to be those of the transit stop. This is by specifying a time in minutes under the
subfolder list box to tell the system to include pictures that are taken within a certain number of
minutes after the attribute record was registered in the database (i.e., saved to database).
The last step in completing the input specification for data merging is to indicate the output
shapefile layer that will store all the attribute records from all the subfolders, including
information on the merged pictures. Once this is completed, the user can click the Merge button
to start the merging process. Figure 4 shows an example report that summarizes the merging
results. The report gives the total number of pictures merged as well as the numbers and
percentages of stops with zero, one, and two and more pictures merged. The user can select to
list the transit stops that have a certain number of pictures successfully merged by clicking the
appropriate radio buttons. After transit stop pictures are merged with the database, the complete
transit stop inventory together with the merged pictures will be automatically stored under the
folder for the transit system from which the merging function was accessed.
Figure 4. Merging Result Summary
SAMPLE APPLICATIONS
The following subsections describe three applications of the standard transit stop inventory in
FTGIS.
Retrieving Transit Stop Attributes and Pictures
A basic need of transit agency for transit stop information is to be able to find out quickly the
conditions at a transit stop and its surrounding area. A function was developed in FTGIS to
allow the user to quickly retrieve all the attribute information of a transit stop. A sample output
of this function is shown in Figure 5, which lists transit stop attribute data side-by-side with
pictures. The user can click a picture to get an enlarged version of the picture, a sample of which
is shown in Figure 6.
Querying Transit Stop Inventory
A query function customized for the Florida standard transit stop inventory was developed to
allow users to quickly identify transit stops that possess a specific set of features. As an
example, Figure 7 display query specifications for amenity attributes. Specifications for these
attributes act as filters to retrieve only those transit stops that met the specified attribute
option(s). Once the query specifications are completed, the user can click the Apply button to
execute the query. All transit stops that satisfy the query conditions will be listed on the list box
below the tabs. The user can then select any one transit stop on the list by clicking on the
appropriate list item and then apply various functions, including saving selected stops as either
an Excel file or a Shape file, highlight a specific stop, and pan and zoom to a specific stop.
Figure 5. Retrieved Transit Stop Attribute Data and Pictures
Figure 6. An Enlarged Picture
Figure 7. Query Filters for Amenity Attributes
Visualizing Transit Stop Summary
A summary function was developed to allow the user to quickly obtain the number and
percentage breakdowns of each attribute option. For example, one can quickly find out the
percentage of transit stops that are ADA accessible. The statistics can be summarized for a
specific route or any combinations of routes. Figure 8 shows a screen that has four attributes
selected. Attributes are selected by clicking the checkboxes on the Attributes list on the top-left
corner. One or more routes may be selected. This is done by clicking the checkboxes on the
Routes list right below the Attributes list. When multiple routes are selected, the summaries
may be based on individual routes or all route combined. This option selection is given at the
bottom left of the screen. Note that because of missing values (i.e., null cells), the percentages
may not add up to 100%.
By default the system will display the tabulated summaries first. Summaries for different routes
are displayed in different rows. Summaries for different attribute options for one or more
attributes are displayed in different columns. When multiple attributes are selected, their
attribute options will be displayed in sequence. The tabulated summaries will give the number of
transit stops under each attribute option. Each number is accompanied by a percentage value that
is shown in parentheses. The same information displayed in table can be displayed by chart.
Figure 9 shows such an example.
Figure 8. Output Transit Stop Summary Displayed by Cross Table
Figure 9. Output Transit Stop Summary Displayed by Chart
SUMMARY AND FUTURE WORK
A transit stop inventory is needed for tracking the location of stops, identifying the type and
conditions of amenities, determining how well areas of interest are served by transit service,
assessing the accessibility for disabled persons and ADA compliance, upgrading the right-of-way
appearance, etc. The advent of Advanced Public Transportation Systems (APTS) makes it even
more important for transit agencies to keep an up-to-date inventory of transit stop data. This
paper has described an effort to develop a standard database for transit stop inventories for transit
agencies in Florida and a system for collecting the standard inventory. The application was
designed for easy data entry and recording in the field. It replaces the traditional methods of
collecting transit stop inventory using clipboard, pencil, and paper, which are time-consuming,
inaccurate, and difficult to update. The application also included a GPS that supplies location
information to the handheld computer through wireless connection. In addition, an optional
digital camera is used to capture the views of transit stops and their surrounding areas. The
system, which costs about $1,300, provides transit agencies an affordable automated system for
the collection and update of transit stop inventory. It also contributes directly to the
standardization of transit stop inventory in Florida.
To achieve the goals set out for the system, the Florida Department of Transportation (FDOT)
has decided to implement the following three tasks to facilitate and encourage deployment of the
system by transit agencies:
1. To procure the software and hardware components of the system for distribution to all
Florida transit agencies with a fixed route system.
2. To setup the ArcPad application such that the system will be ready to use by transit
agencies.
3. To hold workshops at various FDOT District Offices to distribute and demonstrate the
use of the system and to provide technical support on the use of the system.
Additional future work will involve continued development of functionality in the Florida
Transit Geographic Information System (FTGIS) to analyze data from the standard inventory.
AUTHORS’ INFORMATION
Albert Gan, Ph.D.
Associate Professor
Lehman Center for Transportation Research
Florida International University
10555 West Flagler Street, EC 3680
Miami, Florida 33174
Phone: (305) 348-3116
Fax: (305) 348-2802
Email: gana@fiu.edu
Ike Ubaka, AICP
Transit Program Manager
Public Transit Office
Florida Department of Transportation
605 Suwannee Street, MS 26,
Tallahassee, Florida 32399
Phone: (850) 414-4532
Fax: (850) 414-4508
Email ike.ubaka@dot.state.fl.us
Fabian Cevallos
Senior Research Associate
Center for Urban Transportation Research
University of South Florida
4202 East Fowler Avenue, CUT100
Tampa, Florida 33620-5375
Phone: (954) 234-4183
Email: cevallos@cutr.usf.edu