Technical Memorandum #1

tealackingAI and Robotics

Nov 8, 2013 (3 years and 7 months ago)

162 views

Technical Memorandum #1

Definition of Scope of Spatial Data Applications in
Transit

Version 1.0


July 25, 2001




Prepared for:

Jeff Orton,
Chair

Location Referencing Working Group

Tom Sullivan,
Chair

Technical Council

Richard Cox
, President

Transit Standa
rds Consortium,




Prepared by:

Paula Okunieff

Boston, MA

Nancy Neuerburg

Seattle, WA

Teresa Adams

Madison, WI

and

Society of Automotive Engineers

Project Manager




TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


ii

Acknowledgements


This memorandum was developed under the “Phase 1


Location Referencin
g Guidebook
Feasibility Study” funded by the Federal Transit Administration (FTA) under a
cooperative agreement with the Transit Standards Consortium FTA C
-
6, October 1, 1999,
Project Number NJ
-
26
-
7044.

This project was supported by the volunteer members o
f the Technical Working Group.
They generously gave their time and expertise to help shape and review the Technical
Memorandums. At the time that this document was prepared, the following individuals
were active members of the TSC Location Referencing Gu
idebook Technical Working
Group:

Jeff Orton
-

Chair

Utah Transit Authority

Bob Antonisse

Orbital Sciences Corporation

Mike Berman

King County Metro Transit Division

Jim Farley

Oracle Corporation

Cecil Goodwin

University of Tennessee

Louis Hecht

Open
GIS Consortium

Dennis Hinebaugh

Center for Urban Transportation Research

Jay Sandhu

ESRI

Somitra Saxena

GIS/Trans Ltd.

Howard Slavin

Caliper Corporation

Tom Vaughan

New York State Department of Transportation


The authors would like to acknowledge th
e following people and organizations:


Wayne Watanabe, who with Nancy Neuerburg, developed transit applications tables for
King County Metro's
GIS Project Phase I Feasibility Study

(July 1992). The application
tables served as a source for Appendix B, Ta
bles B
-
2 through B
-
13.


Utah Transit Authority, who gave permission to adapt Appendix B, Table B
-
1 from their
GIS Strategic Plan User Needs Assessment Document

(31 December 1997).


Thomas G. Ries for
permission to use Data Lifecycle diagram [
October 1997
]
as
illustrated in Figure 6.

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


iii

Executive Summary



Location Referencing Guidebook Feasibility Study

Given the importance to the transit industry of being able to use spatial data effectively to
support the business, the Federal Transit Administration (FTA) h
as funded a study to
identify the scope of a Location Referencing Guidebook (LRG) for the transit industry.


LRG Project Goals
. The goal of the LRG Project is to assist the transit industry by
facilitating more effective and minimizing the ambiguity in th
e exchange of spatial data.
The Location Referencing Guidebook will be helpful, both directly and indirectly.
Transit agencies, standards efforts and vendors will benefit from the identification of
business needs, issues and existing best practices. S
econdary benefits will be realized as
a result of improvements in standards and vendor tools that were facilitated by the
project's efforts.


Two Technical Memoranda were developed under this grant to serve as a resource for the
development of the Guidebo
ok. This Technical Memorandum #1 defines the scope of
spatial data applications in transit, their relationship to location referencing, and
significant barriers to the use of location referenced data. The companion document,
Technical Memorandum #2, descr
ibes existing and emerging spatial data interoperability
standards and issues related to how transit may use those standards.


Background

Most aspects of operating a transit agency have a spatial component. Passengers and the
operations center want to kno
w bus locations. Planners want to know where the
passengers load and alight. Maintenance staff wants to know where the facilities are
located and where work needs to be done. Safety and security staff wants to locate
problem areas. Community relations
staff wants to be able to show the public where
changes will occur. In short, transit has a wide variety of business area, information
system and technology applications that use spatial data (see Appendix B).


Transit is currently under pressure due to r
ising customer expectations for data integrated
between modes and service providers; rising costs for labor, benefits, fuel and programs;
increased operating challenges (e.g., growing congestion); and more competition for
resources. Many of the strategies

for dealing with these challenges, including Intelligent
Transportation Systems (ITS) applications, require the use of spatial data. To implement
those strategies, appropriate tools must be used to create, integrate, model, analyze and
manage spatial dat
a. Traditionally these tools have been gathered under the Geographic
Information Systems (GIS) umbrella. Other applications and data management tools have
begun to incorporate subsets of these GIS tools, sometimes creating more potential for
inconsistency
.


Location referencing issues are a frequent barrier to successful use of spatial data and the
implementation of tools that support improvements to transit service. The technical
definition of a location reference method is the position of an entity rela
tive to other
TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


iv

entities or to some external frame of reference (e.g., a bus stop might be represented by
latitude and longitude or by an offset from a side of an intersection). Within this
memorandum, location referencing may be defined as building a relat
ion between one
location representation

and another.


Barriers to Unambiguous Referencing of Transit Feature Location Attributes

Effective management and exchange of spatial location information may enable more
efficient service delivery, better quality se
rvices and improved integration between
modes and service providers. However, a variety of barriers exist that limit or prohibit
transit agencies from realizing those benefits. These barriers may be due to technical
and/or organizational issues. Technic
al Memorandum #1 discusses in more detail, the
observations on location referencing barriers that are listed below.



Multiple databases and applications can introduce barriers due to

o

Inconsistent naming conventions

o

Different transit data models

o

Embedded GI
S applications

o

Differences in data source quality

o

Transformations and translations

o

Poor documentation (metadata)

o

Use of different location referencing systems



Barriers can occur both within a transit agency and between organizations in a
region when data s
haring or systems integration is required



Barriers can emerge at the various stages of the data life cycle



Barriers can be created or made worse by:

o

Lack of knowledge of standards, existing tools and utilities

o

Poor RFP and systems specifications

o

Poorly def
ined operational and data maintenance responsibilities


Impacts of Barriers

Issues with spatial data representation and location referencing can be costly for transit
agencies. When new ITS or information reporting systems that depend on spatial data
face

difficulties and are delayed, the costs can be measured in additional staff, consultant
or vendor labor expenditures. Missed opportunity costs also occur from not deploying
the systems in a timely manner. Examples of potentially vulnerable ITS applicati
ons
include Itinerary Planning, AVL, APC and on
-
bus annunciators. Other impacts may
include the following:



Loss of cost savings from eliminating duplicative spatial data maintenance



Loss of cost savings from eliminating duplicative spatial database devel
opment



Delayed or unavailable analyses that are needed



Missed opportunities to leverage funds by sharing data regionally



Awkwardness from issuing conflicting information from different systems that were
unable to be integrated.


TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


v

Representing Transit Featur
es

The art of representing, reporting and managing (the representation) of a transit object is
a critical component of successful location referencing. Technical Memorandum #1
defines and identifies issues primarily related to representing and managing t
he lifecycle
of transit spatial feature sets. One key to minimizing ambiguity in the transfer of
spatially
-
based transit objects is ensuring the robust representation of transit features.


Transit features that are created and collected by transit agenci
es may be subject to
policies and procedures, or best practices, promoted by the organization. Therefore, in
defining the scope of what should be included in a Location Referencing Guidebook, the
memorandum identifies areas where best practices may be des
cribed within the context of
the data management and transit lifecycles.


The memorandum and a best practices document can assist transit with:




Identifying transit program elements that use spatial data (see Appendix B which
lists uses within ITS fram
ework and by transit business area)



Understanding specific application quality (“fit for use”) and referencing
requirements, that is, how an agency understands the linkages among the various
applications that use the data



Identifying specific persons with
responsibility for managing the data sets;



Identifying specific procedures for handling the spatial data as it flows through
the lifecycle (e.g., collection, translation to base map, etc.)



Defining a common set of transit features, common names and format
s used
throughout the organization, including



General core spatial data (e.g., street network basemap, census data
boundaries)



Transit core data (e.g., routes, zones, facilities, ridership)



Non
-
core data (e.g., security incidents)



Referencing transit obje
cts to the transportation network (e.g. street, route, bike,
rail, navigable waterways)



For example, managing the challenges posed by GPS technology as
transit agencies try to align GPS data with their street network for
mapping and analysis purposes



Under
standing data lifecycle needs (how the data changes as it is collected)



Understanding error propagation issues during use and location reference
transformation



Identifying types of meta
-
attributes that capture data quality and procedures



Managing the str
eaming data sets that are produced by Automatic Vehicle
Location (AVL) and Automatic Passenger Counting (APC) systems. The
sampling rate and frequency of aggregation and reporting may be based on space
and/or time.


A best practices guidebook is key to e
nsuring that the industry understands and uses the
appropriate meta
-
attributes for referencing these spatial/temporal data sets and
determining the fitness for use of the data.

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


vi



The location referencing methods supported by the broader geospatial communit
y may
not meet all the referencing/accessing requirements for transit. There are key transit
feature referencing issues that are difficult to translate into the standard location
referencing methods given the tools available in today’s market place. Two e
xamples are
included below.




A spatial definition (latitude and longitude) of a bus stop is not sufficient for transit.
The direction or orientation of the bus stop along the route network and/or street
network is of equal, if not greater importance.




T
ime as the fourth dimension is frequently another important aspect of identifying
and representing transit features. Transit may overlay dozens of paths over the
same pattern that exist at different times, yet using existing location referencing
methods an
d tools the features cannot be readily distinguished and therefore
accessed.


Definition of best practices in this area will provide guidance to transit agencies on how
best to represent this information. Second, it will provide guidance to vendors of
ge
ographic information tools on how best to represent transit features.


Conclusion

Since many of transit’s data elements have a spatial feature, and are used in a wide
variety of transit applications, the need frequently arises for transforming a transit
fe
ature’s location representation between one or more location referencing methods. As
a result, transit agencies are frequently vulnerable to the many problems currently
associated with location referencing. The Location Referencing Guidebook would help
t
ransit agencies, vendors and standards efforts to overcome those problems by including
techniques, procedures and other best practices. Transit agencies will benefit as spatial
databases are built and expanded, as GIS and ITS applications are installed, as

ITS
applications are maintained and operated and as spatially based analyses are requested.


TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


vii

Table of Contents


SECTION 1: INTRODUC
TION

................................
................................
............

1

1.1 Background

................................
................................
................................
.................

1

1.2 Barriers to Unambiguous Location Referencing of Transit Features

...................

4

1.3 Impacts of Barr
iers

................................
................................
................................
.....

5

1.4 Goals

................................
................................
................................
.............................

6

1.5 Objectives
................................
................................
................................
.....................

6

1.6 Organization of the Tec
hnical Memorandums

................................
.......................

6

SECTION 2: IDENTIFIC
ATION OF TRANSIT APP
LICATIONS THAT USE
SPATIAL DATA

................................
................................
................................
....

8

2.1 What is a transit applicatio
n?

................................
................................
...................

8

2.2 The Transit Information Enterprise

................................
................................
.........

8

2.3 What is spatial data?

................................
................................
................................
.

9

2.4 Transit Applications

................................
................................
................................

12

SECTION 3: REPRESENT
ATION OF FEATURE DAT
A AND DATA FLOWS
..

14

3.1 Transit Feature Data

................................
................................
................................

14

3.2 Location Referencing Methods

................................
................................
................

15

3.3 Data flows

................................
................................
................................
..................

18

SECTION 4:

TECHNICAL CONSIDERAT
IONS OF TYPES OF GUI
DANCE
NEEDED FOR A TRANSIT

LOCATION REFERENCING

GUIDEBOOK

...........

22

4.1 Spatial/Temporal and Dynamic Data
................................
................................
......

22

4.2 Spatial Data Management

................................
................................
........................

23

4.3 Data lifecycle
................................
................................
................................
.............

25

4.4 Spatial Analysis Functions

................................
................................
.......................

29

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


viii

4.5 Transformation and translation

................................
................................
.............

30

4.6 Error propagation and reporting

................................
................................
............

30

4.7 Metadat
a

................................
................................
................................
....................

31

SECTION 5: PROPOSED
ISSUES AND REQUIREME
NTS FOR SUPPORTING
LOCATION REFERENCING

FOR TRANSIT

................................
.....................

32

5.1 Issues

................................
................................
................................
..........................

32

5.2 Requirements
................................
................................
................................
.............

33

5.3 Next Steps

................................
................................
................................
..................

35

5.4 Conclusion

................................
................................
................................
................

35

APPENDIX A: GLOSSARY

AND ACRONYMS

................................
.................

37

APPENDIX B: TRANSIT
APPLICATIONS/FUNCTIO
NS THAT USE SPATIAL
DATA AND ANALYSIS FU
NCTIONS (GIS TOOLS)

................................
.........

38

Table B
-
1a Transit Management System

................................
................................
.....

38

Table B
-
1b Automated Traveler Information System

................................
................

41

Table B
-
1c Electronic Fare Payment

................................
................................
...........

41

Table B
-
1d Transportation Demand Management

................................
......................

41

APPLICATION BY BUSI
NESS AREA. The following tables B
-
2 through B
-
13
present a broad set of examples of spatial data based transit applications or functions
organized by transit business area.
................................
................................
................

42

Table B
-
2 SERVI
CE AND CAPITAL PLANNING

................................
....................

42

Table B
-
3 SCHEDULING

................................
................................
............................

45

Table B
-
4 MARKET DEVELOPMENT

................................
................................
......

46

Table B
-
5 ACCESSIBLE SERVICES
................................
................................
..........

46

Table B
-
6 VEHICLE AND FACILITIES MAINTENANCE

................................
.....

47

Table B
-
7 SALES AND CUSTOM
ER SERVICES

................................
....................

49

Table B
-
8 VANPOOL PROGRAM
................................
................................
.............

50

Table B
-
9 RESEARCH AND EVALUATION

................................
...........................

50

Table B
-
10 TRANSIT OPERATIONS

................................
................................
........

51

Table B
-
11 RISK, SAFETY AND SECURITY

................................
..........................

53

Table B
-
12 COMMUNICATIONS AND COM
MUNITY RELATIONS

..................

54

Table B
-
13 PROPERTY AND RIGHT
-
OF
-
WAY

................................
......................

54

APPENDIX C: NOTATIO
N FOR CORE TRANSIT D
ATA MODEL (FIGURE 3)

................................
................................
................................
............................

56


TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


ix

Table of Figures


Figure 1: Example of Spatial Resolution of Bus Stop in an Intersection

..........................

3

Figure 2:
Data Layers on a Digital Base Map
................................
................................
..

11

Figure 3: Core Transit Feature Data Model

................................
................................
.....

18

Figure 4: Sample Transit Feature Flow and Ev
olution

................................
....................

19

Figure 5: Relationship among Directed Graph, Geographic and Real World

.................

21

Figure 6: Spatial Data Lifecycle

................................
................................
.......................

28



TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


1

SECTION 1: INTRODUCTION


Given the importance to the transit industry of being able to use spatial data effectively to
support its business, the Federal Transit Administration (FTA) has funded a project to
develop a Location R
eferencing Guidebook for the transit industry. The intent of the
Guidebook is to help transit overcome many of the spatial location referencing issues that
are creating inefficiencies and barriers to transit’s sharing and use of spatial data. This
Techni
cal Memorandum #1 is designed to serve as a resource for the development of the
Guidebook.


To help scope the Guidebook, the Technical Memorandum will identify a broad range of
applications using spatial data that support the effective operation of a trans
it agency.
The list of applications can also be used by transit for obtaining ideas on the potential
uses and value of spatial/GIS applications. Understanding the range of spatial
applications in advance can improve planning, allowing for greater systems

implementation flexibility and integration options.


In addition, the Memorandum will define some of the organizational and technical
barriers that impede cost effective, successful, use of spatial data to support transit. A set
of those issues and bar
riers will be addressed in the Guidebook. The memorandum will
also identify key technical requirements of transit applications with respect to the
representation and use of transit features in spatial/temporal domains. For that reason,
the primary audien
ce for which this memorandum is written are transit staff and vendors
who deal with the technical issues related to collecting, developing, managing and
maintaining transit related spatial data sets and the developers of transit applications that
share tra
nsit related spatial data sets.

1.1 Background


Most of the data used in planning for, operating and assessing the performance of a
transit agency have a spatial component. Passengers and the operations center want to
know where the buses are. Planners w
ant to know where the passengers load and alight.
Maintenance staff want to know where the facilities are and where work needs to be
done. Safety and security staff want to know where the problem areas are. Community
relations staff want to be able to s
how the public where changes will occur. As a result,
spatial data can be a significant component of the information resources of a transit
agency.


Transit is being driven to alter the way it traditionally manages and uses information.
Rising costs and
increasing operating challenges create a need for better information and
performance indicators. Also, rising customer expectations and the goals of the US
Department of Transportation (US DOT) are driving the transit industry towards more
efficiency and
increased program integration. Transportation services and customer
information need to be better integrated across transportation modes and across service
areas. This drives the need for better integration of transit and spatial data across
TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


2

departments,
applications, adjacent transit agencies and with local DOTs and
Metropolitan Planning Organizations (MPOs).


Transit spatial data
. Spatial data in transit is commonly used to display the location of
routes and facilities. Many other transit variables a
nd attributes can also be spatially
represented, such as ridership, common accident locations and potential markets. In
addition to displaying transit attributes, the spatial representation of the underlying street
network and service area is critical. T
he spatial data can be used in new analyses, in
visual representations of findings, in providing various representations of customer
information and in driving new Transit Intelligent Transportation Systems (ITS).


Many of the ITS applications not only nee
d spatial data to operate, but also create data
with spatial components. A Geographic Information System (GIS) is a powerful spatial
data management tool that assists in supporting the data input to ITS applications,
managing the output of ITS applications

and completing spatial analyses.


Location Referencing
. A location referencing method is a used to determine the position
of an entity relative to other entities or to some external frame of reference (e.g., latitude
and longitude relative to the spheric
al geoid).


Transit applications face several barriers to exchanging transit features with respect to the
location reference method used. Among the most significant are the following:




Inconsistencies and incomplete information in representing the spati
al
characteristics in the transit feature record or entity.



Transforming spatial features from one frame of reference to another frame of
reference. (The frame of reference may be domain specific, that is within a
“transit frame of reference.”, from one b
ase map to another, or from a sensor
measurement to a base map)


When transit feature data flows from one application to another, its location referencing
method may change. Two of the scenarios that demonstrate the importance of
minimizing inconsistencie
s and incomplete feature representation include:




Accident feature information is collected using mile post information (from
physical signs) and transferred to a base map. Two criteria must be met: (1) the
milepost units must match the units contained i
n the base map; (2) the street name
fields and spelling should match the fields and spelling maintained by the base
map.



Accident feature information referenced using mile
-
post must be translated to a
street address for the Risk Management System. An accu
rate translation between
mile post and address is enabled by a well managed association table that relates
mile
-
post to address information.


With respect to transforming location references of transit features from one frame of
reference to another, the
re are a number of issues to consider:

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


3




Collecting sensor information and mapping it to a base map



Distinguishing multiple features located within the same likely location


Collecting Sensor Information
. If the accident example involved collecting the loc
ation
using GPS sensor measurements, the issues involved with transforming latitude and
longitude to address or mile post is different. The accuracy of the GPS sensor will only
match the base map accuracy within a probabilistic tolerance. So if the GPS s
ensor is
more accurate then the base map, then the placement of the accident on the base map may
not match reality even though the measurements are the same.


A best practice described in the
Bus Stop Inventory Guidebook

recommends a field
practice of co
llecting the street address and relative location to the intersection (e.g., near
-
side, far
-
side; and side of the street) along with the GPS sensor measurement when
performing a bus stop inventory. When the street address is not collected, the activity of

associating the bus stop on a base map is made more difficult, expends more time to
validate and produces unexpected errors.


Distinguishing multiple features
. Individual features are not always identified
unabiguously either within a GIS and base map,

or by a GPS sensor against data derived
from other sources. For example, using a base map of 40 meters accuracy, a GPS device
may place a bus stop on any one of eight sides of an intersection or as illustrated in
Figure 1, and mistake a North Street near

side bus stop for an East Street far side one.


East Street

North Street

Bus stop

40 ft. radi as around bus stop


Figure
1
: Example of Spatial Resolution of Bus Stop in an Intersection


A distinguishing frame of reference must be used to ensure unambiguous identi
fication of
the transit feature. In the case of transit, many applications rely on topology (i.e., a line
graph) and use a linear reference such as an intersection/offset method (e.g., run and
cross street, mid
-
block, far
-
side, near
-
side) for referencing
bus stops and timepoints. For
example, some vehicle scheduling and run cutting packages relate transit data to an
TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


4

abstract linear network that has limited or no geographic coordinate data. Problems may
arise when the user wants to transfer data from non
-
spatial or limited spatial applications
to spatial ones. In this case, the frame of reference is transit specific; it must be complete
and linked to the spatial reference (of the base map) to ensure proper identification to
minimize ambiguity.


Definition

of the various frames of reference, and strategies to collect the right
information and develop association and other types of authority tables are key to
building a robust spatial data information enterprise.

1.2 Barriers to Unambiguous Location Referenc
ing of Transit Features

Effective management and exchange of spatial location information may enable more
efficient service delivery, better quality services and improved integration between
modes and service providers. However, a variety of barriers exi
st that limit or prohibit
transit agencies from realizing those benefits. These barriers may be due to technical
and/or organizational issues.


The core of any information system is the logical organization of data. In the case of
spatial data, a truly

meaningful representation is geographic. The map database and
transit features provide that logical structure. However, because the diversity of
databases represent different realities and may use different location referencing methods,
integrating data

from different sources poses a challenge.


Observations on location referencing barriers that are listed below.



Multiple databases and applications can introduce barriers due to

o

Inconsistent naming conventions. A lack of common terminology for
transit da
ta variables and objects exists in transit between agencies and
sometimes, even between work groups within an agency.

o

Different transit data models

o

Embedded GIS applications

o

Differences in data source quality

o

Transformations and translations

o

Poor documen
tation (metadata)

o

Use of different location referencing systems



Barriers can occur both within a transit agency and between organizations in a region
when data sharing or systems integration is required



Cultural and organizational issues, usually about con
trol and dissemination of data,
can add another layer of complexity.



Problems with maintaining and integrating elements of different vendor basemaps can
create significant time and resource barriers



Spatial/temporal and dynamic data pose challenges due to
complexity, lack of “best
practices” and the need for additional software analysis tools.



Barriers can emerge at the various stages of the data life cycle



Barriers can be created or made worse by:

o

Few standards are available to transit for exchanging data
between
systems.

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


5

o

Lack of knowledge about the need for standards, existing software
applications, utilities for managing spatial data

o

Poor RFP and systems specifications

o

Poorly defined operational and data maintenance responsibilities

1.3 Impacts of Barrie
rs

Issues with spatial data representation and location referencing can be costly for transit
agencies. When new ITS or information reporting systems that depend on spatial data
face difficulties and are delayed, the costs can be measured in additional st
aff, consultant
or vendor labor expenditures. Missed opportunity costs also occur from not deploying
the systems in a timely manner. Potentially vulnerable ITS applications include Itinerary
Planning, real
-
time vehicle arrival times, AVL, APC and on
-
bus
annunciators. For
example, an RFP can be issued for an Itinerary Planning system and a project plan and
schedule is announced. The vendor is then selected and starts to install the software. The
project and schedule go awry when the existing data will n
ot work with the software
because of a variety of data problems, including location referencing issues. Other
impacts may include the following:



Loss of cost savings from eliminating duplicative spatial data maintenance



Loss of cost savings from eliminat
ing duplicative spatial database development



Delayed or unavailable analyses that are needed



Missed opportunities to leverage funds by sharing data regionally



Awkwardness from issuing conflicting information from different systems that were
unable to be in
tegrated.


Current Efforts to Reduce Barriers
. Today, many organizations, including the US
Geologic Survey (USGS), Federal Geographic Data Committee (FGDC), and others are
struggling with solving the problem of how spatial data can be exchanged and integr
ated
in an unambiguous manner. The issue on which they are focusing is not associated with
data definition and format, rather it relates to transformations between location
referencing methods and the unambiguous (automated) interpretation of the new loca
tion
reference. For transit ITS user services, this issue is crucial to deploying an integrated
transportation infrastructure. Dissemination of real
-
time transportation information, the
core of most user services, depends on a location reference that is
machine processed and
interpreted. Real
-
time travel information is not useful unless it can be transferred
efficiently, integrated into a service provider’s applications, and displayed expeditiously
with a high degree of accuracy (or at least an understan
ding of the data quality).


The Guidebook
. There are techniques to improve or convey the accuracy of the
transformations from one location referencing method to another. The guidebook may
identify those techniques and standardize the format of authority
tables, algorithms, and
quality reporting metrics. These methods will leverage existing best practices in the GIS
and GIS for Transportation (GIS
-
T) communities, and incorporate existing research,
standards and practices promulgated by standards organizat
ions, consortiums, federal
initiatives and GIS
-
T projects. By communicating transit’s needs for using and
transforming spatial data, the project hopes to promote a cycle of improvement that
involves both the transit industry, and database and software ven
dors.

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


6


1.4 Goals

LRG Project
. The goal of the LRG Project is to assist the transit industry by facilitating
more effective and unambiguous exchange of spatial data. The Location Referencing
Guidebook will be helpful, both directly and indirectly. Transi
t agencies, standards
efforts and vendors will benefit from the identification of business needs, issues and
existing best practices. Secondary benefits will be realized as a result of improvements in
standards and vendor tools that were facilitated by th
e project's efforts. Transit agencies
will benefit as spatial databases are built and expanded, as GIS and ITS applications are
installed, as ITS applications are maintained and operated and as spatially based analyses
are requested.


Technical Memorandum

#1
. The goal of this Technical Memorandum is to facilitate the
development of the Location Referencing Guidebook by defining the scope of spatial
data applications in transit and identifying key issues. The specific objectives of the
Technical Memorandu
m are listed below.

1.5 Objectives

The objectives of this Technical Memorandum #1 on "Definition of Scope of Spatial
Data Applications in Transit" include:




Identify barriers to transit spatial data transfer and management.



Develop a comprehensive list of

transit applications that use spatial data.



Develop a comprehensive list of spatial applications used in transit applications.



Identify other key technical requirements for representing transit features



Identify the types of location referencing methods
needed to exchange transit
feature data.


1.6 Organization of the Technical Memorandums

This technical memorandum, Technical Memorandum #1 (TM#1) on Definition

of Scope
of Spatial Data Applications in Transit

is a companion to Technical Memorandum #2
(TM
#2) on

Issues related to Existing and Emerging Spatial Data Interoperability
Standards.


The main focus of TM#1 is on functional requirements related to spatial data needed by
transit ITS and other automated systems that serve transit and its customers. I
t explores
the “problem space” of the proposed
Location Referencing Guidebook

with respect to
transit. The primary audience for TM#1 are transit staff, software developers and
vendors who deal with the projects, program elements and tools that collect, de
velop,
manage, use and disseminate spatial data associated with public transportation features or
attributes. The memorandum describes functions, data, quality, reporting,
transformations and other issues surrounding the functional requirements of these d
ata
employed by various transit program elements and applications.


TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


7

The main focus of TM#2 is on existing and emerging standards developed by the spatial
data, ITS and GIS for Transportation industries. As stated above, TM#2 discusses how
these standards
support handling, processing, and disseminating spatial/temporal transit
data and how that support applies to public transport requirements. A discussion on the
technical details of a standard requires expertise in the spatial data domain. For that
reaso
n, the intended audience of TM#2 includes transit staff who manage spatial data
(GIS specialists) and geo
-
processing/location
-
based service industry specialists interested
in public transportation applications that use spatial data.


Certainly, one cannot

review and apply these standards to transit without understanding
public transportation needs. Further, one cannot describe the functions, primitive data
elements, quality, reporting, transformations and other issues related to transit without
understand
ing the categories promoted in the broader geo
-
processing community. As
such, these two papers are inter
-
related in that they frame the discussion of the other.


This memorandum is organized so that the reader is introduced to some general
definitions bef
ore the transit specific applications, data flows, requirements and issues are
introduced. A glossary that defines the terminology and acronyms used in the memo is
provided in Appendix A. Appendix B contains a lengthier listing of potential GIS/spatial
d
ata applications by transit business area.



TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


8

SECTION 2: IDENTIFICATION OF TRANSIT APPLICATIONS
THAT USE SPATIAL DATA


The value of spatial data to transit, when it is used successfully, is demonstrated in this
section. Appendix B, which provides the det
ail for this section, contains a wide breadth
of spatial based applications that support the many business areas within transit. This
section briefly describes "transit application", the "transit information enterprise", and
"spatial data" before outlinin
g a broad range of examples of transit applications that use
spatial data. The full set of possible spatial data applications in transit continues to grow
as technology advances and transit refines and expands its expectations.

2.1 What is a transit appl
ication?


The scope of the Location Referencing Guidebook (LRG) should ensure that the “best
practices” cover major transit applications and apply in the environments in which transit
applications are deployed.


A transit application is any software modul
e used to achieve the business goals of a
transit agency. Key goals of a transit agency are as follows:




Provide mobility services for their customers



Effectively and efficiently manage the service provision


Many business areas in transit use software ap
plications to support their business
functions, including inventories (infrastructure) and services. These applications may
exist in the central headquarters, at a base or garage, at an application service provider,
DOT or MPO. Transit agencies may also
have roadside or mobile systems, including
hardware and software systems located at a bus stop or on transit vehicles, respectively.
New ITS software applications, such as Automatic Passenger Counting systems and
Smartcard systems, incorporate new technol
ogies and span the vehicle, the yard and the
central office.


The applications may include legacy systems such as payroll, personnel, financial and
inventory systems; custom built applications; adapted commercial off
-
the
-
shelf (COTS)
software such as Sched
uling and Runcutting software; or it may include general COTS
software that incorporates transit data sets, such as Geographic Information Systems
(GIS) and database management tools.


(Since the Location Referencing Guidebook will likely deal most direct
ly with transit
ITS, most human resource, administrative and financial systems are excluded from the
scope of this technical memorandum and may be excluded from the initial development
of the Transit Location Referencing Guidebook.)

2.2 The Transit Informa
tion Enterprise


TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


9

The transit information enterprise is comprised of the (1) transit applications and data
resources that are used throughout a transit organization (including data exchanged with
external organizations), the (2) information infrastructure s
uch as communications,
hardware and software (e.g., operating system) and the (3) organizational policies,
procedures and responsibilities related to data and communications resources.


Since transit business functions and work units are very interdepende
nt, an integrated
transit information enterprise is needed to effectively support the transit agency. Spatial
data and spatial functions/applications are a key component of the enterprise. As such,
they must be managed with respect to the enterprise as a

whole, considering both non
-
spatial and spatial relationships. For example, transit can incur data maintenance
inefficiencies, data consistency/integrity problems, data sharing difficulties and redundant
capital costs when street and route networks are a
cquired independently (e.g., within
Demand Responsive Reservation and Dispatch, AVL, Itinerary Planning systems,
Scheduling Software and GIS).


The Enterprise may be viewed from many perspectives, in particular, it may be data
-
centric or function
-
centric.

The data centric view is based on centralizing the data and
building the applications and services from the database management system. The
function centric system is based on coordinating the software applications and using the
software applications, th
at is Scheduling, Demand Responsive Reservation and Dispatch,
Computer Aided Dispatch, etc. to drive the data and integration requirements. As the IT
industry has identified, the data and function centered views must be overlaid, thus the
data concept des
cription, flow and all the transformations that occur within and between
transit components should be defined to maximize flexibility of data integration and
analysis.


A number of steps can help implement a “seamless information infrastructure.” Some
tra
nsit information enterprises are optimized by reducing or eliminating data redundancy,
automating and coordinating data collection, assigning “ownership” (e.g., update and
maintenance responsibilities), and developing an enterprise data dictionary and data

reference model.


Given the recent advances in spatial and data management tools, spatial and non
-
spatial
data can be more easily managed in conjunction, as an integrated transit information
enterprise resource. This can allow for more rapid development
of more complex
analyses and presentation graphics. With effective integration, a variety of transit
performance statistics such as ridership and fare recovery can be presented graphically,
relative to routes, stops and regions.

2.3 What is spatial data?

In a general sense,
spatial data

is any data that is associated with a location. For the
purposes of this technical memorandum, spatial data will be used interchangeably with
the data that composes a digital map database. Further, when we refer to a “lo
cation
referencing method” with respect to a public transportation domain object or feature, we
will assume that the “other entities” or “frame of reference” (as described in Section 1.1
TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


10

Location Referencing) include transit domain representations. For ex
ample, bus stop
#356032 may be characterized by numerous location referencing methods:




10 feet east on the south side from the corner on Elm intersecting with South
Streets.



Near
-
side on the corner of Elm and South [on street, cross street]



25 Elm Street,

Cambridge, MA 02140 USA



route #10 mile 1.2, inbound direction



<lat, long> WGS ‘84



<lat, long> MA State Plane



link #58673901 on the XYZ digital (vector) base map



Grid 45
-
245 on the ABC raster base map


All of these location referencing methods define the
same location or spatial data; they
are merely different representations of the same information. They may vary by the base
map type (e.g., vector, raster), feature attribution, indexing scheme, or some other ”frame
of reference”. Most public transportat
ion applications use vector data and spherical
coordinates, thereby combining linear and geographical layers.


The Guidebook can support the definition of a robust transit
-
oriented “frame of
reference” that is linked (by the vendor tools) to the digital ba
se map. Further, it may
identify key location referencing methods that should be collected and stored with
various types of transit features.


Classes of Features
. There are three main classes of primitive spatial features: point,
chain and polygon. (T
he primitive spatial features are usually defined relative to a single
external frame of reference such as a spherical geoid, World Geodetic System 1984


WGS ‘84) These classes of data include variants (e.g., rings and areas are subsets of
polygons) depe
nding on the level of detail and intermingling of linear and geographic
data.


Public transportation features use primitive spatial data to define, describe or attribute the
data. Examples of different ways of describing a bus stop location is listed abov
e. A
linear feature, such as a route pattern may be defined by a series of points, parametric
equations, reference to a spatial data chain index (e.g., link), or attributes of spatial data
(e.g., address range). Polygons may use series of points, chains
, centroid (point in the
center of the polygon), index to a predefined polygon (e.g., zip code), or attributes of
spatial data (e.g., landmark such as the Washington Monument).


Further, depending on its importance, a domain object may be described as an a
ttribute of
a feature or as a feature itself. For example, a transit station with multiple bays may
include a location reference for each bay or it may include the bay as an attribute of the
station. Some applications may require the former representatio
n while others may not.
The internal representation of multimodal facilities or vehicle bases are becoming
increasingly important in ITS projects.


TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


11

These types of issues impact data exchange. The Guidebook may provide information on
how best to represe
nt transit features that are based on certain types of spatial primitives,
and “transit frames of reference”. Once the best practices are described, then the industry
can urge vendors to support the feature representations that make the most sense to the
industry as a whole.


Data layers
. Spatial data may be thought as overlaying multiple layers of various types of
data, that is the digital map database may include multiple layers that support different
domains. For example, the base map may overlay t
he following layers: road network,
topography, hydrography,
Transportation Analysis Zones
(TAZ), route patterns, transit
service area, transit facilities, fare
zones and radio zones. Figure 2
shows three layers of themes.


Relationship between layers
. Th
e
features in the layers use a base
location referencing system. The
location referencing system may
establish rules for translating
features from one method to
another. For example, bus stops
may be captured through the
address closest to a stop, and ro
ute
patterns by the links with which
they coincide. In order to merge
the two transit features, the GIS or
other location reference system
provides rules for making the
translation.


Figure
2
: Data Layers on a Digital Base Map


When the spatial data comes from the same source, the transformation is more likely a
translation from one method to another with limited loss of information or propagation of
error. That is, the information may be derived from the source material to tran
slate from
one method to another, eg., an authority table of street names, association table of link
identifiers to termination nodes (in latitude and longitude).


However, when the data are derived from multiple sources, such as various navigation
sensor
s (e.g., Differential GPS on the AVL and GPS on the APC), different digital base
maps, or between applications that support their own cartographic rendering tools, the
translations may become approximations depending on the source quality (precision,
resol
ution, accuracy and extent). Bus stops may appear on the wrong side of a roadway,
Figure
2
: Data Layers on a Digital Base Map

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


12

ramps and station portals may disappear. One may classify these transformations as a
spatial function between
location referencing systems
.


There are many pitfalls that in
troduce errors and singificant ambiguities to the
transformation and decisions based on the data transformations. The Guidebook should
identify those pitfalls,and discuss techniques to avoid or mitigate the problems.
Specifically, when applying linear da
ta to various applications, there may be a need for
tools and guidelines to “generalize” the shape of very detailed features or, conversely,
increase the detail of very general features to meet other spatial applications’ needs. For
instance, given a requ
ired standard of location accuracy that an AVL application must
provide, how does one derive the fewest set of shape points needed to represent the route
pattern? Can this set be used with the APC and automated Annunciation system?


2.4 Transit Applicatio
ns

The transit information enterprise may be described by the types of functions that it
supports. Tables B
-
1 through 13, in Appendix B, contains an extensive list of transit
applications that use spatial data and analysis functions.




Tables B
-
1a throug
h B
-
1d provide examples of automated ITS based applications.
The applications are grouped in four broad ITS categories, Transit Management
System, Automated Traveler Information System, Electronic Fare Payment and
Transportation Demand Management. Table
B
-
1a also lists transit features used by
the application or function.



Tables B
-
2 through B
-
13 present spatial based applications by transit business area
without specifically highlighting ITS applications.


The following transit business areas are included

in the Appendix:




Service and Capital Planning

o

Service and Route Facilities Planning

o

Park
-
and
-
Ride Program

o

Passenger Shelters

o

Urban Arterial Improvement

o

Long Range Planning

o

Long Range Forecasting



Scheduling



Market Development



Accessible Services

o

Suppl
emental or Paratransit Services Program



Vehicle and Facilities Maintenance

o

Vehicle or Coach Maintenance

o

Trolley Overhead and Electrical Maintenance

o

Building and Facilities Maintenance

o

Engineering and Facilities Support



Sales and Customer Services

o

Sales

o

C
ustomer Services

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


13

o

Ridematching



Vanpool Program



Research and Evaluation



Transit Operations

o

Bus Operations

o

Operator Training

o

Subcontract Services

o

Street Supervision

o

Radio Communications



Risk, Safety and Security

o

Risk Management, Insurance and Safety

o

Secur
ity



Communications and Community Relations

o

Public Participation

o

Staff Information and Communications



Property and Right
-
of
-

Way



(Rail and Passenger Flow in Transit Facilities are not included in Appendix at this time)


The additional emphasis on the ITS r
elated applications is appropriate given that many
transit organizations are just beginning to implement these automated systems. Also,
these systems tend to have significant spatial data requirements and can create spatial
data issues within a transit or
ganization. A critical issue related to ITS Applications is
automating the transformation so that there is
no

ambiguity in understanding the location
of a transit feature; the computers that drive real
-
time systems do not tolerate ambiguity.


A listing o
f spatial analysis functions, such as geocoding and buffering, that support the
applications listed in Appendix B is included in Section 3.6.


TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


14

SECTION 3: REPRESENTATION OF FEATURE DATA AND DATA
FLOWS


3.1 Transit Feature Data


A lack of standard vocabul
ary or definition of transit spatial features often hampers
spatial data exchange within transit and the implementation of new vendor products.
Work completed in 1994 on the APTS Map Database User Requirements Specification
and more recent work on the Tra
nsit Communications Interface Profiles (TCIP) have
brought advances in the development of common definitions and standard formats.


Although spatial data sets are used extensively by transit, there are a few sets of feature
data that are key to defining, p
lanning, managing and maintaining the provision of transit
bus service. The following list includes examples of transit objects that may be defined
as features, or contain properties of transit features.


Transit Object

Definition

Amenity

A characterist
ic of a stop point such as lighting, bench, trash can,
shelter, kiosk, etc.

Block

The daily assignment of the transit vehicle. The block is an
ordered sequence of trips.

Event

A point where something is supposed to happen on board a transit
vehicle such

as change a sign, trigger the annunciator, send a
signal for priority treatment at a signalized intersection, leave a
deadhead location, leave/enter garage, stop at a rest point, change
operator duty, etc.

Pattern

(Route Pattern)

“One of multiple outer r
o畴攠獥gme湴猠ne牶r搠dy a⁳楮 汥⁴牡湳楴
route.”** Route segments that compose a route. The patterns
楮捬畤i⁲ 癥湵e⁳ g浥湴猠楮捬畤s湧⁢牡nc桩hg⁩渠敡c栠摩hec瑩潮o
⡥.g⸬⁩湢潵湤Ⱐ潵.扯畮搩⁡湤⁤na摨ea摳
瑵dn
-
a牯畮摳爠湯u
-
牥癥湵n⁳eg浥湴猩⸠⁔桥 灡瑴e
牮⁴y灩ca汬y⁩湣汵摥s⁡渠潲nere搠
獥煵q湣e映扵猠獴潰猠慮搠d癥湴猠n桡琠潣tu爠r汯l朠瑨攠g潵瑥⁡猠
瑲t癥牳r搠dy a
Public Transit Vehicle
.

Piece of Work

“A task or series of tasks that, when carried out, provide the basic
c潭灯湥湴猠潲⁢畩汤o湧 扬潣歳b⁴牡
nsit service delivery” ** An
潲摥牥搠c潬oec瑩潮o⁴ 浥⁰潩湴⁡獳潣楡瑥搠睩瑨⁡渠潰n牡瑯爠
assignment. The type of time points relate to the operator’s duties
a湤⁷潲欠牵汥猠摵物湧⁴ e⁰楥 e映f潲欮

m畢汩c⁔ a湳楴
噥桩捬hs

“Vehicles owned, leased or sub
c潮瑲octe搠dy⁡⁰ 扬bc⁴牡湳楴
agency to support service provision.” **

o潵瑥

“A collection of patterns in revenue service.” **

o畮

“The daily
pieces of work

assigned to a transit employee.” ** The
牵渠楳⁡渠潲nere搠獥煵e湣e映瑲楰献†周攠i畮ua汳漠l湣
汵摥猠l渠
潲摥牥搠c潬oec瑩潮o⁰楥ce猠潦⁷o牫r

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


15

Transit Object

Definition

Stop point

Bus stop or point at which passengers board or alight a transit
vehicle in revenue service.

Time point


“A geographic location which a transit agency uses to schedule
transit service and monitor a
dherence to the service schedule. It is
a point at which time is assigned to create trips.” **

Time point interval

The traversal between two consecutive trip time points. This
feature may include the average running time between the two
points. The av
erage running time may be segmented by running
time periods (time of day) or trip.

Transfer point

Collection of stop points where passengers may transfer from one
route to another, one mode to another.

Trip

“A one
-
way movement of a transit vehicle in rev
enue service
between two points.”** A trip is composed of an ordered
sequence of time points which are associated with the time the
transit vehicle is scheduled to enter (or leave) each time point
along the traversal.

Trip time point

“A specific time ass
igned to a timepoint on a trip.” **

** NTCIP 1404, TCIP SCH Objects


There are also spatial features related to transit infrastructure such as facility, radio zone,
fare zone, point of interest, service area that are related to the service components/
ent
ities. Also note this is mainly for rubber tired vehicles in fixed route revenue service.
Ferries, light and heavy rail, streetcars, trolleys, etc. require additional attributes. Also,
supplemental services, demand responsive, rideshare, car pool servic
es are not wholly
represented by these features. This is not to say that many of the features cannot be
shared with other modes.


Additional attributes of the features include:




Trip request (origin, destination, transfers, journey


time, distance, path)



Trip legs (walking, driving, transit paths)



Estimated rate of traversal of a path



Actual rate of traversal of a path



Average (maximum) rate of traversal of a path



Buffer around a corridor


Buffer around a time point, bus stop, intersection, trigger point
(includes time entered and
departed; opened and closed doors)

3.2 Location Referencing Methods

Transit feature data are defined in many ways. In the past, many transit agencies defined
routes purely in graph form. These line graphs were straight lines wi
th distance or time
values measuring the edges. The vertices or points are typically time points, not stop
points, along the route. Many route schedule guides are still presented in this way.

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


16


With the use of GIS and GPS technologies, more sophisticate
d location referencing
methods are being used to collect and represent data. Among the location referencing
methods currently being used by agencies and vendors include:


Geographic Referencing Methods



Latitude and Longitude



State Plane Coordinates



Modifi
ed Grid Systems (to reduce bandwidth requirements for radio
communications) based on service area, map pages, radio tower coverage or
vehicle depot/garage regions


Linear Referencing Methods



Offset from street intersection



Offset from route pattern



Relativ
e to intersection (near side, far side, mid
-
block near side, mid
-
block far
side)


Attribute Method



Address



Landmark


Many of the location referencing methods need further information to accurately
represent the transit features. Three examples follow.




Because many transit features rely on a directed graph
1
, the side of the street or the
direction of travel is important in defining location.



In some cases, transit deploys systems on multiple levels (e.g., underground tunnels,
and multilevel intermodal
stations), requiring knowledge of which level contains the
vehicle, customer, etc.



Further, the altitude or change in altitude (gradient) may affect system performance or
customer preference. For example, the ability of a bus to stop and start at a loca
tion
on a snowy road is affected by gradient. Similarly, a customer using a wheel chair
may select or reject a bus stop based on its gradient. Different bus fleets may be
tuned differently for operating in low elevation valleys versus at higher altitudes

in
the mountains.


For some applications and in some regions, these types of attributes may constitute
important attributes within the transit frame of reference and thus, must be included the
location reference method.





1

A directed graph is a topological structure composed of edges and vertices whe
rein the edges indicate
direction of flow. Figure 5 illustrates an example of a directed graph.

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


17

Hybrid Referencing Methods

Featu
re inventories usually contain multiple referencing methods. For example, the BSI
recommends the collection of at least three methods: Lat/Long, offset from intersection
and address.


Proposed Guidebook Issues Related to Location Referencing Methods

Pro
posed Guidebook Issues Related to Location Referencing Methods

There are many issues pertaining to location referencing that pose problems for transit
staff. As stated before, some of the issues are highly technical in nature, while others
have more to do

with data representation, data management and organizational/policy
decisions. Much time and energy is lost within the transit industry in trying to resolve
these spatial data and location referencing issues. In agency after agency, staff struggle
with
identifying and understanding the issues and barriers that prevent them from
completing their work. They develop creative “work
-
arounds” and are frequently faced
with project delays or failures. Some of the problems faced by transit staff can simplified
o
r eliminated by better technical tools. A sharing of the “best practices” in the industry
can help many of the other transit agencies avoid and solve location referencing related
problems. The Guidebook should describe in detail effective and robust meth
ods for
representing transit features, specifically,




Limiting ambiguities in representing a transit object



Developing a frame of reference (i.e., a transportation network as it relates to the
transit service provision) that is neatly mapped to and valid
ated against the map
database frame of reference (to more easily associate transit features with the
map base features)



Describing techniques and practices that transit professionals and application
vendor should use to describe transit objects that contai
n or are associated with
transit spatial features (e.g., passenger loads, annunciation points, trips)


For example, many transit agencies are deploying AVL, APC and automated annuciation
systems. These systems must be associated with bus stops, time point
s and other fixed
end data in order to assess performance monitoring goals and achieve customer service
goals. Barriers exist on many levels: how to keep current bus stop location information?
how to share bus stop location information? how to merge attr
ibute information
associated with each system? does each system maintain its own location information or
is there one set of “true” bus stop location information? and if so, is the representation of
the location referencing method sufficient for all upstr
eam and downstream applications?


Many of the on
-
board systems collect and manage their own bus stop location
information. Transit agencies believe that if the bus stop identifier is mapped to the
location data sets supported by each application, then the
y will be able to merge the data
when downloaded. There are operational considerations that must be considered when
taking this approach: schedule and route alignment changes; automated or manual
system updates of internal data sets; staff resources and
skill sets to validate operations;
and more. In the next section on Data Flows, we will explore the issues related to data
TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


18

dependencies and upstream and downstream data requirements, quality and reporting
practices.


3.3 Data flows


Figure 3 displays a da
ta model using a subset of transit objects defined in Section 3.1.
This data model, derived from the inherent relationships in the TCIP Scheduling and
Runcutting Standard Objects (NTCIP 1403], shows how transit objects incorporate transit
features within
their definitions. Though the relationships among these objects/entities is
important, the Guidebook need not describe a detailed data object model. Nevertheless,
these relationships impact the spatial transformations that occur during the course of the
data flow and evolution.




Figure
3
: Core Transit Feature Data Model
2


Transit features may pose additional challenges for transit staff as they flow through the
transit organization and its applica
tions. The form of each “entity” may change based on
the data used to derive it or the transit features used to describe it. For example, many
transit entities go through the following stages as shown in Figure 4:




2

See Appendix C for definition of data model notation.

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


19



Service
Planning


Planned
Assignment

(periodically)


Actual (as
dispatched)


Performance


Daily

Assignment


Detour/

Incident


Route
planning



Figur
e
4
: Sample Transit Feature Flow and Evolution


With each interface, transit spatial feature data may require translation and/or
transformation. Data flows defined in Figure 4 include the following:


Planning


Operations

Operati
ons


Actual

Actual


Monitoring, (Customer Information)

Monitoring


Performance

Performance


Planning


At each stage (data and transit domain lifecycle stage), the feature may require a different
location referencing method. Another aspect of the trans
formation occurs when a data
interface requires data transfer between two location referencing systems, and when
integrating a sensor measurement unto a base map or with a transit feature. Typically,
on
-
board systems use geographic measures such as latitu
de and longitude or grid based
measures. Fixed end systems that are used to support customer information typically use
linear and/or attribute descriptors such as street addresses or relative distance from an
intersection or landmark. Performance analysi
s typically use linear, domain measures,
that is an offset (time or distance) from a service provision point (e.g., time point time or
bus stop location). As the transit features flow from one interface to another, they
typically change format and represen
tation.

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


20


The APC demonstrates issues related to the changing transit feature representation.




Real
-
time monitoring and collection applications typically use latitude and
longitude generated by GPS to capture the information; dispatchers monitor
passenger

loads based on the latitide and longitude projected onto a base map.



Planning and performance applications that analyze passenger boardings and
alightings typically use network algorithms based on temporal and topological
(directed) graphs to determine
passenger loads by road segment and time of day.


The topologic and geographic representations are linked though geocoding transit feature
points (e.g., timepoints and stop points).


The temporal and topologic graphs are generated in temporal and overla
pping spatial
layers. For example, a time point interval may be attributed with different running times
depending on the time of day or time period (e.g., morning peak, mid
-
day, afternoon
peak, etc.). Further, a route may branch or contain different stop

points depending on the
trip type (e.g., express, special). A different route pattern may describe each branch or
each trip type, and it will be directed (e.g., inbound, outbound, circular).


Moreover, the quality requirement of the data may change, su
ch as the precision (e.g.,
number of decimal places), accuracy (e.g., degree of truth), resolution (e.g., scale) and
sometimes the extent (e.g., scope) of the data. A bus stop location used by an Automated
Passenger Counter (APC) demonstrates how this pla
ys out:




While collecting boardings and alightings, the vehicle may load passengers
anywhere in a 40 plus foot loading area (i.e., the length of a bus). So the data
resolution, no matter the sensor quality may propagate errors.



When associating APC data o
f boardings and alightings with bus stops on a street
centerline base map, the accuracy required may be 10 feet or less (since there are
other bus stops within 40 to 100 feet).


The example may become even more complicated, because transit agency policy ma
y
allow an operator to allow passengers to board or alight vehicles at locations other than
bus stops. Then the stop location must be associated with a point on a
trip
.


Furthermore, the quality of the base map will affect the actual association of the
attribute
linked to the GPS measured stop location and the bus stop feature validated on the base
map. In this case, in order to ensure unambiguous representation, the location
referencing method will require domain feature attributes such as distance fro
m trip start,
time from trip start, trip identifier, route id, route direction, route pattern id, or a
combination of these parameters.



TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


21

Trip 1
--
5:00 AM

Trip 2
--
5:15 AM

Trip 3
--
5:30 AM

Trip 4
--
5:45 AM

Route Pattern #1 InB

Real World (“Truth”)

Directed Graph Representation

Geographic Representation


Figure
5
: Relationship among Directed Graph, Geographic and
Real World


As illustrated in Figure 4 Transit Feature Flow and Evolution, transit core data flows
through many different stages in the course of its lifecycle. Further, it flows from one
transit application to another. For example, transit incident data

originates in at least two
or three places: an operator submits a report, dispatcher inputs a report, maintenance or
emergency crew (e.g., police) submits a report. These reports are integrated and
recorded. Insurance, federal reporting, auditing and ot
her business processes use the
information. A bus stop inventory is used by scheduling (service planning), automated
-

and staff
-
managed customer information systems, maintenance program elements, on
-
board systems (like passenger counting, automated annunc
iators and signage).



TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


22

SECTION 4: TECHNICAL CONSIDERATIONS OF TYPES OF
GUIDANCE NEEDED FOR A TRANSIT LOCATION
REFERENCING GUIDEBOOK


This section further identifies some of the uses and representations of transit spatial data.
It also highlights other
technical areas and issues that can affect the success of location
referencing efforts. A brief discussion is included on spatial data management, data
lifecycle, spatial analysis functions including transformation and translation, error
propagation and r
eporting and metadata.

4.1 Spatial/Temporal and Dynamic Data

Spatial data are used throughout transit's business units and applications, yet most transit
agencies still have significant unmet needs for spatial data analyses. This is not
surprising, given

that most infrastructure elements are distinguished spatially. Yet more
unmet needs will occur with the deployment of ITS, particularly with new customer
services, and performance and operational analyses.


These technologies raise customer expectation
s as well; a contemporary example is the
television commercial that shows Finnish school boys as they emerge from their school
and arm themselves with snowballs when they are electronically alerted to the imminent
arrival of the trolley
3
. Dynamic spatial
/temporal data are used to derive the estimated
time of arrival; the algorithms that generate the customer information require precise
location and time, rate of change and acceleration parameters. Among the transit
applications that are emerging include:




In the rail industry, Positive Train Control depends on a braking algorithm that
uses time or distance, velocity and acceleration parameters.



Dynamic scheduling and transfer connection protection will be aided with more
accurate spatial/temporal vehicle

status data overlaid with traffic flow predictions.



Transit signal control algorithms for near side stops are currently based on
accurately estimating dwell time, “Time Service Desired”

and “Time Estimated
Departure.” Another strategy included in TCIP1
4

uses a moving average
calculation that compares historical moving average values to current velocity
values.


For ITS applications, characterized by predicting and tracking vehicles and people, and
optimizing performance, new relationships among the spatia
l, spatial
-
temporal, and
dynamic representations are needed. These relationships are clearly defined by well
developed mathematical fields such as linear and dynamic systems (e.g., linear
regression/moving average, least mean estimation), as well as stoch
astic processes (e.g.,
Kalman filter). However, the relationships may vary depending on whether a real
-
time
application or an optimization analysis is required. In particular, with respect to



3

Hewlett Packard advertisement (March
-
April 2001).

4

These strategies are described in TCIP2 Dialogs W
hite Paper #8 on Transit Signal Priority
(
www.tcip.org
).

TM#1 Definition of Scope of Spatial Data Appli
cations in Transit

25 July 2001

Transit Standards Consortium: LRG Project


23

performance data, the best method to aggregate spatial
-
tempora
l data is not clear. What
is the optimal sampling rate? What is the best “averaging” algorithm? Over what duration
or distance should the data be aggregated? In
TCRP Synthesis 34

on
Data Analysis for
Bus Planning and Monitoring
5
, the author contends that


“Many AVL systems were not designed for off
-
line analysis…[and] the location
needs of off
-
line trip time analysis


time at given locations and time and location
for various events


differ from the demands of real
-
time monitoring.”


This statement ide
ntifies a growing need to understand relationships such as time
between location measurements (sample rates), and number of samples, distance or
duration of an aggregated data (window); and
the various requirements for transforming
these types of spatial/t
emporal series among real
-
time, optimization, and performance
applications and analyses.


4.2 Spatial Data Management

Although not a purely technical consideration, spatial data management is an integral part
of any guidelines document.
The management i
ssues surrounding the lifecycle
processes and quality requirements are key to effective use.

Computer systems and
transit customers may often be unforgiving in their need for accurate, complete,
consistent, up
-
to
-
date and available information. Lack of a
ttention to data management
issues by transportation agencies has frequently created increased costs for spatial data
sets, delays in availability of needed information, customer frustration, ITS project
implementation delays and awkward moments for manage
ment when data
inconsistencies become too public. In some cases the organizational placement of GIS,
ITS and IT staff can further contribute to problems with data quality and availability, if
the strong links to the transit business requirements are not m