FGDC-STD-014.7d-2008

Geographic Information Framework Data Content 

Standard 

Part 7d: Transportation - Transit 

May 2008 
ii

Federal Geographic Data Committee 

Established by Office of Management and Budget Circular A-16, the Federal Geographic Data 

Committee (FGDC) promotes the coordinated development, use, sharing, and dissemination of 

geographic data. 

The FGDC is composed of representatives from the Departments of Agriculture, Commerce, 

Defense, Education, Energy, Health and Human Services, Homeland Security, Housing and 

Urban Development, the Interior, Justice, Labor, State, and Transportation, the Treasury, and 

Veteran Affairs; the Environmental Protection Agency; the Federal Communications Commission; 

the General Services Administration; the Library of Congress; the National Aeronautics and 

Space Administration; the National Archives and Records Administration; the National Science 

Foundation; the Nuclear Regulatory Commission; the Office of Personnel Management; the Small 

Business Administration; the Smithsonian Institution; the Social Security Administration; the 

Tennessee Valley Authority; and the U.S. Agency for International Development. Additional 

Federal agencies participate on FGDC subcommittees and working groups. The Department of 

the Interior chairs the committee. 

FGDC subcommittees work on issues related to data categories coordinated under the circular. 

Subcommittees establish and implement standards for data content, quality, and transfer; 

encourage the exchange of information and the transfer of data; and organize the collection of 

geographic data to reduce duplication of effort. Working groups are established for issues that 

transcend data categories. 

For more information about the committee, or to be added to the committee's newsletter mailing 

list, please contact: 

Federal Geographic Data Committee Secretariat 

c/o U.S. Geological Survey 

590 National Center 

Reston, Virginia 22092 

Facsimile: (703) 648-5755 

Internet (electronic mail): fgdc@usgs.gov 

 World Wide Web: http://www.fgdc.gov
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

iii

Contents 

Introduction.................................................................................................................................. vii

1 Scope........................................................................................................................................... 1

2 Normative references................................................................................................................. 1

3 Maintenance authority ............................................................................................................... 2

3.1 Level of responsibility...................................................................................................... 2

3.2 Contact information ......................................................................................................... 2

4 Terms and definitions ................................................................................................................ 2

5 Symbols, abbreviated terms, and notations............................................................................ 3

6 Transit system requirements .................................................................................................... 3

6.1 Introduction....................................................................................................................... 3

6.2 The context of the transit system ................................................................................... 5

6.3 TransitFeature................................................................................................................... 5

6.4 TransitStop........................................................................................................................ 6

6.5 ConnectionSeg ............................................................................................................... 10

6.6 TransitPath...................................................................................................................... 12

6.7 TimePoint ........................................................................................................................ 15

6.8 Pattern ............................................................................................................................. 18

6.9 TransitRoute.................................................................................................................... 21

6.10 Block................................................................................................................................ 23

6.11 PTVehicle......................................................................................................................... 26

6.12 TransferCluster............................................................................................................... 29

6.13 Landmark......................................................................................................................... 31

6.14 Facility ............................................................................................................................. 34

6.15 Amenity............................................................................................................................ 37

6.16 Fare .................................................................................................................................. 39

6.17 Trip................................................................................................................................... 41

7 Code lists................................................................................................................................... 43

7.1 AmenityType code list ................................................................................................... 43

7.2 FacilityType code list ..................................................................................................... 43

7.3 FareType code list .......................................................................................................... 44

7.4 FarePolicyType code list ............................................................................................... 44

7.5 ObstacleType code list .................................................................................................. 45

7.6 PatternType code list ..................................................................................................... 45

7.7 RouteDirectionType code list........................................................................................ 46

7.8 StatusType code list....................................................................................................... 46

7.9 TransitServiceType code list......................................................................................... 47

Annex A (informative) Trip itinerary planning use case.......................................................... 48

A.1 Introduction..................................................................................................................... 48

A.2 Supported operation ...................................................................................................... 48

A.2.1 Overview and description.............................................................................................. 48

A.2.2 Concept of operations ................................................................................................... 48

A.2.3 Enumeration of needs.................................................................................................... 48

A.3 Functional requirements for supported operation...................................................... 50

A.3.1 Overview of requirements ............................................................................................. 50

A.3.2 Detailed functional requirements ................................................................................. 50
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

iv

A.4 Mapping data requirements to current transit model................................................. 52

A.5 Guidance on how to specify a fare table using TCIP standard on fare collection 

business objects (NTCIP 1408:2001)......................................................................................... 55

A.5.1 General ............................................................................................................................ 55

A.5.2 Fare tables and fare policy type.................................................................................... 56

A.5.3 Calculating the cost based on fare media type........................................................... 58

A.5.4 Defining the time period table....................................................................................... 59

A.5.5 Defining fare instruments.............................................................................................. 60

A.5.6 Identifying exceptions.................................................................................................... 63

Annex B (informative) Public transportation stop inventory sharing use case ................... 65

B.1 Supported operation ...................................................................................................... 65

B.1.1 Overview and description.............................................................................................. 65

B.2 Enumeration of needs.................................................................................................... 65

B.3 Functional requirements for supported operation...................................................... 66

B.3.1 Overview.......................................................................................................................... 66

B.4 Mapping data requirements to current transit model................................................. 67

Annex C (informative) Unplanned re-routing use case .......................................................... 68

C.1 Supported operation ...................................................................................................... 68

C.1.1 Overview and description.............................................................................................. 68

C.1.2 Enumeration of needs.................................................................................................... 68

C.2 Functional requirements for supported operation...................................................... 69

C.2.1 Overview.......................................................................................................................... 69

C.3 Mapping data requirements to current transit model................................................. 71

Annex D (informative) Address extension to the transit model ............................................. 72

Annex E (informative) Bibliography .......................................................................................... 84

Figures 

Figure 1 – The transit system....................................................................................................... 4

Figure 2 – TransitFeature.............................................................................................................. 5

Figure 3 – TransitStop................................................................................................................... 6

Figure 4 – ConnectionSeg ......................................................................................................... 10

Figure 5 – TransitPath................................................................................................................. 12

Figure 6 – TimePoint .................................................................................................................. 15

Figure 7 – Pattern ........................................................................................................................ 18

Figure 8 – TransitRoute .............................................................................................................. 21

Figure 9 – Block........................................................................................................................... 23

Figure 10 – PTVehicle ................................................................................................................. 26

Figure 11 – TransferCluster........................................................................................................ 29

Figure 12 – Landmark ................................................................................................................. 31

Figure 13 – Facility ...................................................................................................................... 34

Figure 14 – Amenity .................................................................................................................... 37

Figure 15 – Fare .......................................................................................................................... 39

Figure 16 – Trip............................................................................................................................ 41 

Figure B.1 – Sample regional bus stop database structure.................................................... 67 

Figure D.1 – Illustration of address segment information requirements............................... 72

Figure D.2 – Suggested information attributes for AddressSeg and Address classes ....... 73

Figure D.3 – Data model extension to support address information transmission ............. 74

Tables 

Table 1 – Data dictionary for TransitStop ................................................................................... 7

Table 2 – Data dictionary for ConnectionSeg........................................................................... 11

Table 3 – Data dictionary for TransitPath ................................................................................. 13

Table 4 – Data dictionary for TimePoint.................................................................................... 16
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

v

Table 5 – Data dictionary for Pattern......................................................................................... 19

Table 6 – Data dictionary for TransitRoute............................................................................... 22

Table 7 – Data dictionary for Block ........................................................................................... 24

Table 8 – Data dictionary for PTVehicle .................................................................................... 27

Table 9 – Data dictionary for TransferCluster .......................................................................... 30

Table 10 – Data dictionary for Landmark.................................................................................. 32

Table 11 – Data dictionary for Facility....................................................................................... 35

Table 12 – Data dictionary for Amenity ..................................................................................... 38

Table 13 – Data dictionary for Fare............................................................................................ 40

Table 14 – Data dictionary for Trip............................................................................................. 42

Table 15 – CodeList for AmenityType ....................................................................................... 43

Table 16 – CodeList for FacilityType ......................................................................................... 43

Table 17 – CodeList for FareType.............................................................................................. 44

Table 18 – CodeList for FarePolicyType ................................................................................... 44

Table 19 – CodeList for ObstacleType ...................................................................................... 45

Table 20 – CodeList for PatternType ......................................................................................... 45

Table 21 – CodeList for RouteDirectionType............................................................................ 46

Table 22 – CodeList for StatusType .......................................................................................... 46

Table 23 – Codelist for TransitServiceType.............................................................................. 47 

Table A.1 – Trip itinerary planning (TIP) functional requirements ......................................... 50

Table A.2 – Trip planning data requirements ........................................................................... 52

Table A.3 – Fare definition steps ............................................................................................... 56

Table A.4 – Fare zone table (FcFareZoneTable)....................................................................... 57

Table A.5 – Fare distance calculations matrix (FcFareDistanceTable).................................. 57

Table A.6 – Data element code values for select FcFareCharacterCost fields ..................... 59

Table A.7 – Example of a FcTimePeriod table for weekday (day type).................................. 59

Table A.8 – TCIP definition of various fare instruments ......................................................... 60 

Table B.1 – Potential users of shared data............................................................................... 66

Table B.2 – Detailed functional requirements .......................................................................... 66 

Table C.1 – Unplanned re-routing stakeholders....................................................................... 68

Table C.2 – Detailed functional requirements .......................................................................... 69

Table C.3 – Data requirements for rerouting use case............................................................ 71 

Table D.1 – Data dictionary for AddressSeg and Address...................................................... 75
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

vi

Foreword 

Geographic information, also known as geospatial information, both underlies and is the subject 

of much of the political, economic, environmental, and security activities of the United States. In 

recognition of this, the United States Office of Management and Budget issued Circular A-16 

(revised 2002), which established the Federal Geographic Data Committee (FGDC) as a 

coordinating organization. 

Work on this standard started under the Geospatial One-Stop e-Government initiative. The 

standard was developed with the support of the member agencies and organizations of the 

FGDC and aids in fulfilling a primary objective of the National Spatial Data Infrastructure (NSDI), 

that is, creation of common geographic base data for seven critical data themes. The seven core 

data themes are considered framework data of critical importance to the spatial data 

infrastructure. 

As the Geographic Information Framework Data Content Standard was developed using public 

funds, the U.S. Government will be free to publish and distribute its contents to the public, as 

provided through the Freedom of Information Act (FOIA), Part 5 United States Code, Section 552, 

as amended by Public Law No. 104-231, “Electronic Freedom of Information Act Amendments of 

1996”. 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

vii

Introduction 

The primary purpose of this part of the Geographic Information Framework Data Content 

Standard is to support the exchange of transit transportation data. This part seeks to establish a 

common baseline for the semantic content of transit transportation databases for public agencies 

and private enterprises. It also seeks to decrease the costs and simplify the exchange of transit 

transportation data among local, Tribal, State, and Federal users and producers. That, in turn, 

discourages duplicative data collection. Benefits of adopting this part of the standard also include 

the long-term improvement of the geospatial transit transportation data within the community, the 

improved integration of safety, emergency response, and enforcement data, and streamlined 

maintenance procedures. 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

1

1 Scope 

The Geographic Information Framework Data Content Standard, Part 7d: Transit defines 

components of a model for describing public transportation (transit) systems, which is one of five 

modes that compose the Transportation theme of the digital geospatial data framework. The 

primary purpose of the Transit part of the standard is to support the exchange of spatial and 

temporal data related to public transportation. The emphasis in developing this part has been on 

supporting data exchange on a regional level to support itinerary planning, infrastructure 

inventories, and re-routing applications. It is the intent of this part to develop a consensus around 

a set of common definitions for real world transportation features to advance the goals of the 

NSDI. It is the intent of the part to set a common baseline that will foster the widest possible set 

of applications of public transportation data for both user and producer. It is also intended to 

foster improvements in the common spatial data infrastructure through enhanced data sharing 

and the reduction of redundant data production. 

As a transportation mode, transit differs substantially from other modes such as rail and road in 

that core operational features of the transit system consist of spatial and temporal elements that 

rest upon the transportation infrastructure. The classes, features, and characteristics included in 

Transit (Part 7d) were developed as part of a comprehensive review of several use cases that 

have been documented here. Although these use cases addressed the operational requirements 

of a broad selection of transit business scenarios, they did not provide sufficient input to design 

an all-inclusive transit model. Additional use cases will be required to identify the universe of 

classes, features, and characteristics necessary to fully describe transit geographic base data. 

This part of the Federal Geographic Data Content Standard can be implemented using a variety 

of software packages and is designed to accommodate data with or without geometry. It is 

designed to be able to depict the complete transit system at all levels of service and all functional 

classes that may be defined by a data-providing agency. 

This part of the standard is a companion to the Transportation Base (Part 7). It is also one of five 

thematic parts devoted to one of five primary modes of transportation: Air (Part 7a), Rail (Part 7b), 

Roads (Part 7c), Transit (Part 7d), and Inland Waterways (Part 7e). There are a number of 

issues common to the transportation domain that, because of their broader applications are 

covered in the Transportation Base (Part 7). Other issues, specific to the Transit part, are 

discussed in the informative annexes. 

Subsequent revisions to this part of the standard may lead to a more thorough treatment of 

specific technical and business issues, especially as the part is implemented. The developers of 

the current Transit part recognize the need to extend the model being developed in the Rail (Part 

7b) part for the purposes of transit modeling. 

The Transit part includes a data dictionary based on the conceptual schema presented below. To 

conform to this part, the user shall satisfy the requirements of the data dictionary. The user's 

conforming dataset shall include a value for each mandatory element, and a value for each 

conditional element for which the condition is true. It may contain values for any optional 

element. The data type of each value shall be that specified for the element in the data 

dictionary, and the value shall lie within the specified domain. This part only specifies the special 

requirements of conformance for a dataset containing transportation information. Conformance to 

the part requires additional actions specified in the Base Document (Part 0) and the appropriate 

modal parts 7a, 7b, 7c, 7d, and 7e. 

2 Normative references 

Annex A of the Base Document (Part 0) lists normative references applicable to two or more parts 

of the standard, including those other than the transportation parts. No additional normative 

references are specified in the Transportation Base (Part 7). Informative references applicable to 

the Transit part only are listed in Annex E. Informative references applicable to two or more 

transportation parts only are listed in Annex C of the Transportation Base. Annex D of the Base 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

2

Document lists informative references applicable to two or more of the parts, including those 

other than the transportation parts. 

3 Maintenance authority 

3.1 Level of responsibility 

The FGDC is the responsible organization for coordinating work on all parts of the Geographic 

Information Framework Data Content Standard. The United States Department of Transportation 

(USDOT), working with the FGDC, is the responsible organization for coordinating work on the 

Geographic Information Framework Data Content Standard, Part 7: Transportation Base and 

subparts (Parts 7a, 7b, 7c, and 7d, excluding 7e) and is directly responsible for development and 

maintenance of the transportation parts (excluding 7e) of the Framework Data Content Standard. 

3.2 Contact information 

Address questions concerning this part of the standard to: 

Federal Geographic Data Committee Secretariat 

c/o U.S. Geological Survey 

590 National Center 

Reston, Virginia 20192 USA 

Telephone: (703) 648-5514 

Facsimile: (703) 648-5755 

Internet (electronic mail): gdc@fgdc.gov

WWW Home Page: http://fgdc.gov

4 Terms and definitions 

Definitions applicable to the Transit part are listed here. Other terms and definitions applicable to 

multiple transportation parts of the standard are listed in the Transportation Base (Part 7). More 

general terms and definitions can be found in the Base Document (Part 0) part of the standard. 

Users are advised to consult these documents for a complete set of definitions. 

4.1 

amenity 

elements of a physical feature, a fixed location, or a transit facility 

NOTE An amenity may be described by one or more characteristics, or attributes, such as the year of 

construction or its current condition. 

EXAMPLE The amenities of a public transportation stop may include the shelter, platform announcement 

panel, and benches. 

4.2 

block 

sequence of revenue and non-revenue trips to which a transit vehicle may be assigned 

NOTE A block begins when the vehicle leaves a vehicle base and ends when it returns to a vehicle 

base. 

4.3 

facility 

physical place that is used by a transit agency 

EXAMPLE Transit facilities can include vehicle base, stop point, transit center, or administration building. 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

3

4.4 

pattern 

unique, non-branching, ordered sequence of time points, street links, or public transportation 

stops to be followed by a transit vehicle in scheduled service 

4.5 

public transportation vehicle 

revenue conveyance in a transit fleet 

4.6 

stop 

location where public transport customers may board or alight from a transit vehicle in revenue 

service 

4.7 

time point 

location along a pattern where trips are assigned arrival, dwell, or departure time periods 

4.8 

transfer cluster 

collection of one or more public transportation stops where transfer between routes is 

convenient 

4.9 

trip 

one-way scheduled movement of a transit vehicle between starting and ending time points

EXAMPLE A revenue-service trip will be an instance of a pattern. 

5 Symbols, abbreviated terms, and notations 

The following symbols, abbreviations, and notations are applicable to the Transit part. Those 

common to two or more transportation parts are listed in the Transportation Base (Part 7). 

Symbols, abbreviations, and notations applicable to multiple parts, including the transportation 

parts, are listed in the Base Document (Part (0). 

ADA – American Disabilities Act 

CIS – Customer Information Service 

ITS – Intelligent Transportation System 

PTVehicle – Public Transit Vehicle 

TA – Transit authority 

TIP – Trip Itinerary Planning 

USNG – United States National Grid 

WMATA – Washington Metropolitan Area Transit Authority 

6 Transit system requirements 

6.1 Introduction 

The transit system model describes the geographic locations, interconnectedness, and 

characteristics of public transportation in the larger transportation system. The transit system 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

4

includes physical and non-physical components representing primarily the bus mode of travel, 

though subsequent versions of this part of the standard will include rail transit (for example, 

subway, light rail) as well. 

Transit systems include physical infrastructure components such as public transportation stops 

and facilities, as well as non-physical features such as routes and patterns that are used to define 

the movement of public transportation vehicles. 

Figure 1 – The transit system 

As shown in Figure 1, the framework transportation transit system has several principal features, 

including TransitStop, TimePoint, TransitPath, and Pattern. Transit paths are the portions of the 

physical transportation system (that is to say, roads) that are defined by the application domain 

using some business rules that may vary according to the business and technical requirements. 

Other features shown include: 

• TransferCluster 

• Landmark 

• Facility 

• PTVehicle 

• Amenity 

• Block 

• TransitRoute 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

5

• Trip 

• Fare 

These are discussed in subsequent sections. 

6.2 The context of the transit system 

This version of the Transit part is closely related to the Transportation Base (see Figure 2 in the 

Transportation Base). To ensure maximum utility in a variety of contexts, this transit model does 

not prescribe any specific business rules for the segmentation of the transportation network. The 

focus of this part is to define a way to encode transit features and their attributes. 

6.3 TransitFeature 

TransitFeatures are objects that represent real world public transport phenomena. 

TransitFeature is shown in Figure 2 and is a subtype of TranFeature. TimePoint, Facility, 

Amenity, and TransitStop are all subtypes of TransitFeature. 

Figure 2 – TransitFeature 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

6

6.4 TransitStop 

TransitStop is a central feature of the transit model because it conveys positional information that 

represents the key business need of providing service to travelers. For that reason, the feature is 

deemed essential to the exchange of transit data. The TransitStop is shown in Figure 3 as a type 

of TransitFeature. TransitStop has the geometry of type GM_Point as defined in ISO 19107. 

TransitStop is a Facility and may optionally be represented by its geometry. The TransitStop may 

be contained in a cluster of stops that form a TransferCluster wherein a transit rider may change 

routes. A TransitStop may optionally be associated with a TimePoint. A Pattern may be 

represented as a series of zero or more ordered TransitStops, or a series of TransitStops may be 

used to define a path along a TransitPath. The TransitStop is tied to the coverage geometry as 

well as the linear description of its environment including relativeLocation associated with the 

nearest intersection, alongLocation, heading and address. Service status conditions such as 

statusInfo and stopOwner are key attributes to determine usage and responsibility. 

Figure 3 – TransitStop 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

7

Table 1 – Data dictionary for TransitStop 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

1 TransitFeature <<Feature>> 2 TransitStop <<Feature>> 3 geometry Shape and geo-location of a TransitStop O 1 <<Type>> GM_Point 4 relativeLocation Place near another known place O 1 <<DataType>> RelativeLocation 5 address 

Single combination of street name, postal community, State, and postal code 

O 1 <<DataType>> CI_Address 

6 statusInfo Information on operational type applicable to the stop M 1 <<CodeList>> StatusType 7 stopOwner Organization that has jurisdiction over the transit stop O 1 <<DataType>> CI_ResponsibleParty 8 stopID Unique identifer for a transit stop O 1 <<DataType>> Framework::Identifier 9 alongLocation Place next to a street or address O 1 <<Type>> LR_PositionExpression 10 heading Direction of travel or orientation of a transit vehicle O 1 Angle 11 Role name: pattern O * <<DataType>> Pattern 12 Role name: timePoint O 1 <<Feature>> TimePoint 13 Role name: event O * 

<<DataType>> TransitPointFeature Event 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

8

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

14 Role name: facility O * <<Feature>> Facility 15 Role name: transferCluster O * <<Feature>> TransferCluster 16 TimePoint <<Feature>> 17 Role name: transitStop O * <<Feature>> TransitStop 18 TransitPath <<Feature>> 19 Role name: event O * 

<<DataType>> TransitPointFeature Event 

20 Facility <<Feature>> 21 Role name: servicedStop O * <<Feature>> TransitStop 22 TransferCluster <<Feature>> 23 Role name: publicStop 1 * <<Feature>> TransitStop 24 Pattern <<DataType>> 25 Role name: transitStop O * <<Feature>> TransitStop 26 TransitPointFeatureEvent <<DataType>> 27 Role name: path M 1 <<Feature>> TransitPath 28 Role name: stop O * <<Feature>> TransitStop 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

9

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

29 RelativeLocation <<DataType>> 30 onStreet On street carriageway M 1 CharacterString 31 atStreet At street M 1 CharacterString 32 distanceFromIntersection Distance from intersection M 1 Distance 33 placementRelativeToIntersection Feature placement relative to intersection M 1 <<CodeList> RelativeDirectionType 34 busPositionBay Position of bus bay O 1 CharacterString 35 streetSide Side street O 1 CharacterString 36 isOffStreet Is on (or off) street O 1 Boolean 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

10

6.5 ConnectionSeg 

A ConnectionSeg is a linear path allowing transit riders to move from one TransitStop to another, 

and is shown in Figure 4. The segment may be defined as a walking path, bike path, escalator, 

or other modal connection. ConnectionSeg is a subtype of TranSeg and describes a linear 

feature that allows a transit rider to move between TransitStops. Attributes include distance, 

fromStop, toStop, and connection instructions. Accessibility information in the form of 

ObstacleTypes may optionally be provided for ConnectionSegs. 

cd Context Diagram: Connection Seg

«Feature»

ConnectionSeg

+ instruction: CharacterString

+ distance: Length

+ accessibility: ObstacleType [0..*]

+ fromStop: T ransitStop

+ toStop: T ransitStop

«Abstract»

Transportation Base::

TranSeg

«Feature»

Transportation Base::

TranPoint

«CodeList»

ObstacleType

+ stairs

+ no grade passage

+ narrow sidewalk

+startedSegment

0..* +startPoint 1

+endedSegment

0..* +endPoint 1 +from 0..*

TranPointEquivalence

+to 0..*

+to 0..*

TranSegEquivalence

+from 0..*

Figure 4 – ConnectionSeg 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

11

Table 2 – Data dictionary for ConnectionSeg 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

37 ConnectionSeg <<Feature>> 38 instruction 

Suitable ordered set of directions (TranSegs to follow or turns to make) that describe in plain English how to get from fromStop to toStop (for example, walking directions between to places) 

M 1 CharacterString 

39 distance Length of the ConnectionSegment M 1 Length 40 accessibility 

Conditions that prevent persons with disabilities from using/traversing the ConnectionSegment 

O * <<CodeList>> ObstacleType 

41 fromStop Stop point identifier wherein the ConnectionSegment starts M 1 <<Feature>> TransitStop 42 toStop Stop point identifier wherein the ConnectionSegment ends M 1 <<Feature>> TransitStop 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

12

6.6 TransitPath 

TransitPath is a linear section of the transit network, which is designed for the movement of 

PTVehicles. TransitPath is a subtype of TranPath and is shown in Figure 5. Consequently, 

TransitPath has geometry of type GM_MultiCurve as defined in ISO 19107, and a topology of 

type TP_Complex. A TransitPath is an ordered set of zero or more TimePoint, TransitStop, or 

transportation segments from TranPath. Each TimePoint or TransitStop occurs at a location 

along the TransitPath. A TransitPath may also be known as a time point interval, route segment, 

variant or route pattern. TransitPaths may optionally have one or more patterns associated with it. 

These options reflect the wide variety of business practices in the transit community. 

Figure 5 – TransitPath 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

13

Table 3 – Data dictionary for TransitPath 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

43 TransitPath <<Feature>> 44 Role name: event O * 

<<DataType>> TransitPointFeature Event 

45 Role name: pattern O * <<DataType>> Pattern 46 Pattern <<DataType>> 47 Role name: transitPath M * <<Feature>> TransitPath 48 TimePoint <<Feature>> 49 Role name: event O * 

<<DataType>> TransitPointFeature Event 

50 TransitStop <<Feature>> 51 Role name: event O * 

<<DataType>> TransitPointFeature Event 

52 TransitPointFeatureEvent <<DataType>> 53 atPosition M 1 <<Type>> LR_PositionExpression 54 Role name: path M 1 <<Feature>> TransitPath 55 Role name: timePoint O * <<Feature>> TimePoint 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

14

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

56 Role name: stop O * <<Feature>> TransitStop 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

15

6.7 TimePoint 

The TimePoint is a location where trips are assigned arrival, dwell, or departure time periods. 

TimePoint is a subtype of TransitFeature and is shown in Figure 6. The position of a TimePoint is 

expressed as type GM_Point. One or more TransitStops may optionally be associated with a 

TimePoint, as they sometimes (but not always) are associated with a TimePoint as part of the 

scheduling process. An ordered sequence of TimePoints demarcates a Trip. Each TimePoint in 

the sequence becomes a TransitTemporalEvent of the Trip. A TimePoint may occur more than 

once in a single trip, however, each occurrence is a unique temporal event. A TimePoint can be 

associated with zero to many (non-ordered) TransitTemporalEvents. 

Figure 6 – TimePoint 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

16

Table 4 – Data dictionary for TimePoint 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

57 TransitFeature <<Feature>> 58 TransitStop <<Feature>> 59 Role name: timePoint O 1 <<Feature>> TimePoint 60 TimePoint <<Feature>> 61 geometry Shape and geo-location of a TimePoint M 1 <<Type>> GM_Point 62 time Point or period when something 

occurs 

M 1 DateTime 

63 Role name: event O * 

<<DataType>> TransitPointFeature Event 

64 Role name: transitStop O * <<Feature>> TransitStop 65 Role name: event O * <<DataType>> TransitTemporalEvent 66 TransitPath <<Feature>> 67 Role name: event O * 

<<DataType>> TransitPointFeature Event 

68 TransitPointFeatureEvent <<DataType>> 69 atPosition M 1 <<Type>> LR_PositionExpression 70 Role name: timePoint O * <<Feature>> TimePoint 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

17

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

71 Role name: path M 1 <<Feature>> TransitPath 72 Trip <<DataType>> 73 Role name: event M * <<DataType>> TransitTemporalEvent 74 TransitTemporalEvent <<DataType>> 75 Role name: timePoint M 1 <<Feature>> TimePoint 76 Role name: trip M 1 <<DataType>> Trip 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

18

6.8 Pattern 

Pattern, as shown in Figure 7, is defined as an ordered sequence of TransitStops or TransitPaths 

that is followed by a transit vehicle in scheduled service. A Pattern may consist of zero to many 

ordered TransitStops or one to many ordered TransitPaths. A Pattern has one TransitRoute 

associated with it. Optionally, a Pattern may have one or more TransferClusters and one or more 

Trips associated with it. 

cd Context Diagram: Pattern

«Feature»

TransferCluster

«Feature»

TransitStop

«DataType»

Pattern

+ patternType: PatternType [0..1]

+ routeDirection: RouteDirectionType [0..1]

+ transitServiceType: TransitServiceType [0..1]

+ timetableVersion: CharacterString [0..1]

«DataType»

Trip

«Feature»

TransitPath

«CodeList»

PatternType

+ revenue

+ revenueNonScheduled

+ training

+ maintenance

+ otherNonRevenue

+ pullIn

+ pullOut

+ deadhead

+ invalid

«CodeList»

RouteDirectionType

+ inbound

+ outbound

+ circular

+ north

+ south

+ east

+ west

+ northeast

+ northwest

+ southeast

+ southwest

+ clockwise

+ counterclockwise

«CodeList»

TransitServ iceType

+ regular

+ express

+ circular

+ radial

+ feeder

+ jitney

+ limited

+ charter

+ school

+ special

+ operator training

+ maintenance

+ no service

+ stand-by

+ extra

«DataType»

TransitRoute

+transitStop 0..*

{ordered}

+pattern 0..*

+transferCluster 0..*

+pattern 0..*

+pattern 0..1

+trip 0..*

+pattern

0..*

+transitPath

1..* {ordered}

+pattern 0..*

+route 1

Figure 7 – Pattern 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

19

Table 5 – Data dictionary for Pattern 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

77 TransferCluster <<Feature>> 78 Role name: pattern O * <<DataType>> Pattern 79 TransitStop <<Feature>> 80 Role name: pattern O * <<DataType>> Pattern 81 TransitPath <<Feature>> 82 Role name: pattern O * <<DataType>> Pattern 83 Pattern <<DataType>>> 84 patternType Class of Pattern O 1 <<CodeList>> PatternType 85 routeDirection Description of the bearing of a route O 1 <<CodeList>> RouteDirectionType 86 transitServiceType 

Class of the operations provision to the customer such as regular, express, charter, and so on 

O 1 <<CodeList>> TransitServiceType 

87 timetableVersion Unique identifier that associates the parts of a transit schedule O 1 CharacterString 88 Role name: transferCluster O * <<Feature>> TransferCluster 89 Role name: transitStop O * <<Feature>> TransitStop 90 Role name: transitPath M 1 <<Feature>> TransitPath 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

20

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

91 Role name: trip O * <<DataType>> Trip 92 Role name: route M 1 <<DataType>> TransitRoute 93 Trip <<DataType>> 94 Role name: pattern O 1 <<DataType>> Pattern 95 TransitRoute <<DataType>> 96 Role name: pattern O * <<DataType>> Pattern 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

21

6.9 TransitRoute 

A TransitRoute is a collection of patterns in revenue service with a common identifier. As shown 

in Figure 8, TransitRoute is a DataType associated with Patterns. One or more Patterns may 

optionally be associated with a TransitRoute and one TransitRoute is associated with a Pattern. 

A TransitRoute contains attributes that support the Transit Rider. The timeTableHeader is a 

summary of publically recognized TimePoints contained in a group of Patterns oriented in the 

same route direction, and is used to generate timetables. 

Figure 8 – TransitRoute 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

22

Table 6 – Data dictionary for TransitRoute 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

97 Pattern <<DataType>> 98 Role name: route M 1 

<<DataType>> TransitRoute 

99 TransitRoute <<DataType>> 100 timeTableHeader 

Sequence of TimePoint identifiers and/or their names used to define the order of TimePoints for all Patterns of the TransitRoute in a RouteDirection 

M 1 CharacterString 

101 routeNumber Unique identifier for a TransitRoute recognized by the agency M 1 CharacterString 102 name Unique identifier for a TransitRoute recognized by the customer M 1 CharacterString 103 Role name: pattern O * <<DataType>> Pattern 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

23

6.10 Block 

A Block is a sequence of trips over which a PTVehicle is assigned from pull out time to pull in 

time. A Block is associated with Trip as well as PTVehicle. Block is shown in Figure 9 and its 

composition includes scheduling information such as pull-in time, pull-out time, the pull-in base 

and pull-out base, status, and timetable version. There may be one-to-many ordered Trips 

associated with a Block, and one PTVehicle may optionally be associated with a Block. 

Figure 9 – Block 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

24

Table 7 – Data dictionary for Block 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

104 Block <<DataType>> 105 blockID Unique identifier for a block M 1 CharacterString 106 pullinTime 

Moment at which a transit vehicle is scheduled to arrive at its Base from its last TimePoint of its scheduled revenue service 

O 1 Time 

107 pullOutTime 

Moment at which a transit vehicle is scheduled to depart its Base to arrive at its first TimePoint of its scheduled revenue service 

O 1 <<Feature>> Time 

108 pullInBase 

Facility in which a revenue vehicle arrives after it completes its scheduled revenue service 

O 1 <<Feature>> Facility 

109 pullOutBase 

Facility from which a revenue vehicle leaves in order to begin its scheduled revenue service 

O 1 Facility 

110 status Condition of a person, place or thing O 1 <<DataType>> Status 111 timetableVersion Unique identifier that associates the parts of a transit schedule O 1 <<DataType>> Framework::Identifier 112 Role name: trip M * <<DataType>> Trip 113 Role name: vehicle O 1 <<DataType>> PTVehicle 114 Status <<DataType>> 115 activationDate O 1 Date 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

25

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

116 deactivationDate O 1 Date 117 modificationDate O 1 Date 118 placementDate O 1 Date 119 databaseModificationDate O 1 Date 120 statusTypeCode M 1 <<CodeList>> StatusType 121 history O 1 CharacterString 122 Trip <<DataType>> 123 PTVehicle <<DataType>> 124 Role name: blockAssignment O * <<DataType>> Block 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

26

6.11 PTVehicle 

PTVehicle is the data type that contains the public transportation vehicle, and PTVehicle refers to 

any public transit conveyance. PTVehicle is shown in Figure 10, and contains information about 

the vehicle including vehicle capacity, vehicle type, as well as real-time routing and scheduling 

status. A PTVehicle is assigned to one vehicle base or Facility (at a time), and zero to many 

Blocks may be associated with a PTVehicle. 

Figure 10 – PTVehicle 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

27

Table 8 – Data dictionary for PTVehicle 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

125 Facility <<Feature>> 126 Role name: PTVehicle O * <<DataType>> PTVehicle 127 PTVehicle <<DataType>> 128 vehicleCapacity 

Maximum number of people that can safely ride the vehicle at any one time 

O 1 CharacterString 

129 configurationComponents List of physical input and output components O * CharacterString 130 scheduleAdherence 

Time that a PTVehicle is ahead or behind its scheduled trip. The convention used is positive numbers indicate the PTVehicle is late and negative numbers indicating the PTVehicle is early 

O 1 CharacterString 

131 vehicleType Kind of vehicle within the agency fleet O 1 CharacterString 132 vehicleID Unique identifier for a PTVehicle M 1 CharacterString 133 routeAdherence Distance by which a PTVehicle is outside its expected path O 1 CharacterString 134 Role name: block assignment O * <<DataType>> Block 135 Role name: base M 1 <<Feature>> Facility 136 Block <<DataType>> 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

28

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

137 Role name: vehicle O 1 <<DataType>> PTVehicle 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

29

6.12 TransferCluster 

The TransferCluster is closely related to TransitStop since it is a collection of TransitStops where 

transit passengers can change routes. The TransferCluster has a geometry type of GM_Polygon 

as defined in ISO 19107 and is shown in Figure 11. The TransferCluster may be associated with 

zero to many Landmarks, or may be associated with zero to many Facilities. The TransferCluster 

is also a subtype of TranFeature. The TransferCluster may also optionally be associated with 

one or more Patterns. One or more TransitStops are aggregated to form a TransferCluster. 

Figure 11 – TransferCluster 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

30

Table 9 – Data dictionary for TransferCluster 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

138 TransferCluster <<Feature>> 139 geometry Shape and geo-location of a TransferCluster O 1 <<Type>> GM_Polygon 140 name Designation of a TransferCluster M 1 CharacterString 141 Role name: pattern O * <<DataType>> Pattern 142 Role name: publicStop M * <<Feature>> TransitStop 143 Role name: landMark O * <<Feature>> Landmark 144 Role name: facility O * <<Feature>> Facility 145 Facility <<Feature>> 146 Role name: transferCluster O * <<Feature>> TransferCluster 147 Landmark <<Feature>> 148 Role name: transferCluster O * <<Feature>> Transfercluster 149 TransitStop <<Feature>> 150 Role name: transferCluster O * <<Feature>> TransferCluster 151 Pattern <<DataType>> 152 Role name: transferCluster O * <<Feature>> TransferCluster 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

31

6.13 Landmark 

A Landmark is a point of interest. Landmark is shown in Figure 12 and is a subtype of 

TranFeature. Landmark has a geometry type of GM_Point as defined in ISO 19107. Landmark 

is comprised of a name, a type, and an address. There may be zero-to-many TransferClusters 

associated with a Landmark. One Facility may optionally be associated with a Landmark. 

Figure 12 – Landmark 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

32

Table 10 – Data dictionary for Landmark 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

153 TransferCluster <<Feature>> 154 Role name: landMark O * <<Feature>> Landmark 155 Landmark <<Feature>> 156 landMarkName Designation for a Landmark M 1 CharacterString 157 landMarkType Category of Landmark M 1 CharacterString 158 address 

Single combination of street name, postal community, State, and postal code 

M 1 <<DataType>> CI_Address 

159 Transportation Base:: TranPoint::geometry Shape and geolocation of a feature O * <<Type>> GM_Point 160 Transportation Base:: TranPoint::topology Connectivity of the participating elements O * <<Type>> TP_Node 161 Transportation Base:: TranFeature::lastUpdateDate Timestamp indicating when the Landmark object was last edited M 1 DateTime 162 Framework::Feature:: identifier Feature identifier for the Landmark M 1 <<DataType>> Framework::Identifier 163 Framework::FeatureCollection:: Feature::metadata Structured or unstructured metadata as defined by the community of practice O 1 CharacterString 164 Framework::Feature::attribute Producer-defined attribute for inclusion in transfer O 1 <<DataType>> Framework::Extended Attribute 165 Role name: transferCluster O * <<Feature>> TransferCluster 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

33

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

166 Role name: facility O 1 <<Feature>> Facility 167 Facility <<Feature>> 168 Role name: landMark O 1 <<Feature>> Landmark 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

34

6.14 Facility 

A Facility is a physical place that is used by a transit agency. Examples of transit facilities include 

parking locations, rail yards, and administrative offices. The Facility is a subtype of 

TransitFeature and is shown in Figure 13. Facility consists of a facility type code (code list given 

in Figure 13 below) and an address. One or more TransferClusters, TransitStops, and 

PTVehicles may optionally be associated with a Facility. One Landmark may optionally be 

associated with a facility. Figure 13 also shows that Facility is a subtype of TransitFeature. 

Figure 13 – Facility
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

35

Table 11 – Data dictionary for Facility 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

169 TransitFeature <<Feature>> 170 Facility <<Feature>> 171 facilityTypeCode Designation for a class of facility M 1 <<CodeList>> FacilityType 172 address 

Single combination of street name, postal community, State, and postal code 

O 1 <<DataType>> CI_Address 

173 Role name: landMark O 1 <<Feature>> Landmark 174 Role name: transferCluster O 1 <<Feature>> TransferCluster 175 Role name: servicedStop O * <<Feature>> TransitStop 176 Role name: PTVehicle O * <<DataType>> PTVehicle 177 Landmark <<Feature>> 178 Role name: faclity O 1 <<Feature>> Facility 179 TransferCluster <<Feature>> 180 Role name: facility O * <<Feature>> Facility 181 TransitStop <<Feature>> 182 Role name: facility O * <<Feature>> Facility 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

36

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

183 PTVehicle <<DataType>> 184 Role name: base M 1 <<Feature>> Facility 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

37

6.15 Amenity 

Amenity refers to the elements of a physical feature, a fixed location, or a transit facility and is 

shown in Figure 14. The amenities of a public transportation stop, for example, may include the 

shelter, schedule displays, and bike racks. Amenity is a subtype of TransitFeature and may have 

a geometry of GM_Point. Amenity consists of the amenityType (code list given in Figure 14), 

name, and the hostingFeature, a TransitStop or Facility. 

Figure 14 – Amenity 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

38

Table 12 – Data dictionary for Amenity 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

185 TransitFeature <<Feature>> 186 Amenity <<Feature>> 187 amenityType Class of amenity M 1 <<CodeList>> AmenityType 188 name Designation for an amenity M 1 CharacterString 189 geometry Shape and geo-location of a Amenity O 1 <<Type>> GM_Point 190 hostingFeature Feature with which this amenity is associated M * <<Union>> AmenityFeature 191 AmenityFeature <<Union>> 192 stop M 1 TransitStop 193 facility M 1 Facility 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

39

6.16 Fare 

The Fare is a data type that describes the cost for riding a transit vehicle. Fare is shown in Figure 

15. The fareValue is expressed as a real number, and is based on the fromStop and the toStop 

attributes. The FareType is the type of fare, such as reduced (for example, senior citizen, 

student, and so on), full-fare, transfer, or special. FarePolicyTypes are the methods by which 

customer fares are determined within an agency or between agencies. The code lists for 

FareType and FarePolicyType are given in Figure 15. 

Figure 15 – Fare 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

40

Table 13 – Data dictionary for Fare 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

194 Fare <<DataType>> 195 fareValue Monetary or ride amount M 1 Real 196 fareType Method by which the fareValue is determined M 1 <<CodeList>> FareType 197 farePolicy Method in which the fare structure is organized M 1 <<CodeList>> FarePolicyType 198 fromStop Origin of a customer's transit ride M 1 <<Feature>> TransitStop 199 toStop Destination of a customer’s transit ride M 1 <<Feature>> TransitStop 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

41

6.17 Trip 

A Trip is a one-way scheduled movement of a transit vehicle between starting and ending 

TimePoints. Each trip is an instance of a Pattern. Trip is a data type and is shown in Figure 16. 

One Pattern may optionally be associated with a Trip. One or more ordered Trips are aggregated 

to create one Block. Trip is demarcated by an ordered sequence of TimePoints. A Trip is 

composed of two or more ordered 'times' (TransitTemporalEvent instances). Each TimePoint in 

the sequence becomes a TransitTemporalEvent of the Trip. A TimePoint may occur more than 

once in a single trip, however, each occurrence is a unique temporal event. 

Figure 16 – Trip 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation - Transit

42

Table 14 – Data dictionary for Trip 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

200 TimePoint <<Feature>> 201 Role name: tevent O * <<DataType>> TransitTemporalEvent 202 TransitTemporalEvent <<DataType>> 203 Role name: timePoint M 1 <<Feature>> TimePoint 204 Role name: trip M 1 <<DataType>> Trip 205 Block <<DataType>> 206 Role name: trip M 1 <<DataType>> Trip 207 Trip <<DataType>> 208 fare O 1 <<DataType>> Fare 209 Role name: tevent M * <<DataType>> TransitTemporalEvent 210 Role name: pattern O 1 <<DataType>> Pattern 211 Pattern <<DataType>> Pattern 212 Role name: trip O * <<DataType>> Trip 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

43

7 Code lists 

7.1 AmenityType code list 

AmenityType is a CodeList of values for the attribute amenityType. 

Table 15 – CodeList for AmenityType 

Name Definition 

shelter Covered structure for passenger waiting 

bench Seat for passenger waiting 

phone Public Telephone 

scheduleDisplay Display for transit schedule 

bikeRack Racks for bicycles 

restrooms Public restrooms 

infoFareBooth Information/fare booth, kiosk, or display 

trashCan Trash receptacle 

other Amenity type not otherwise listed 

platformAnnouncementPanel 

7.2 FacilityType code list 

FacilityType is a CodeList of values for the attribute facilityTypeCode. 

Table 16 – CodeList for FacilityType 

Name Definition 

parking Parking for private vehicles 

transitCenter Centralized transit facility 

railStation Rail stop with associated station 

customerService Transit customer relations facility 

otherRealProperty Other real estate 

powerStation Electric power station 

railYard Switchyard for rail cars and locomotives 

maintenance Miscellaneous maintenance facility 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

44

Name Definition 

comfort Restrooms for transit agency personnel 

administrationBuilding Transit administrative office 

garagePullIn Base where transit vehicle arrives following completion of revenue service 

garagePullOut Base where transit vehicle departs to complete its assigned revenue 

service 

vehicleBase 

stopPoint 

7.3 FareType code list 

FareType is a CodeList of values for the attribute fareType. 

Table 17 – CodeList for FareType 

Name Definition 

reduced Discounted fare 

full-fare Regular fare 

transfer The cost for a proof of payment that permits transferring to another mode 

or service 

special Special fare 

7.4 FarePolicyType code list 

FarePolicyType is a CodeList for the attribute farePolicy. 

Table 18 – CodeList for FarePolicyType 

Name Definition 

flat Single price 

distance Distance-based pricing policy 

zone Zone-based pricing policy 

timeOfDay Time-based pricing policy 

transfers Inter-route transfer pricing policy 

specialRiderClass Fares for special classes of riders 

bulkPassDiscount Bulk ticket pricing policy 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

45

7.5 ObstacleType code list 

ObstacleType is a CodeList for the attribute accessibility. 

Table 19 – CodeList for ObstacleType 

Name Definition 

stairs Set of steps 

noGradePassage No paved path 

narrowSidewalk Constricted walkway 

7.6 PatternType code list 

PatternType is a CodeList for the attribute patternType. 

Table 20 – CodeList for PatternType 

Name Definition 

revenue Path representing a scheduled service provision for transit customers 

revenueNonScheduled Path representing an unscheduled service provision for transit customers 

training Path driven by transit operators in training 

maintenance Path driven by transit maintenance personnel to test transit vehicles 

otherNonRevenue A scheduled or unscheduled path over which service typically is not 

provided to transit customers 

pullIn Path between the last revenue service TimePoint of a Block and Pull-In 

location (for example, base entrance) 

pullOut Path between the Pull-Out location (for example, base exit) and first 

revenue service TimePoint in a Block 

deadhead Nonrevenue TransitPath between two revenue patterns 

invalid Not a known path 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

46

7.7 RouteDirectionType code list 

RouteDirectionType is a CodeList for the attribute routeDirection. 

Table 21 – CodeList for RouteDirectionType 

Name Definition 

inbound Traveling Inbound typically toward the business district according to the 

route direction 

outbound Traveling Outbound typically away from the business district according to 

the route direction 

circular Traveling clockwise or counterclockwise in a circular direction 

north Traveling in a northerly direction 

south Traveling in a southerly direction 

east Traveling in a easterly direction 

west Traveling in a westerly direction 

northeast Traveling in a northeasterly direction 

northwest Traveling in a northwesterly direction 

southeast Traveling in a southeasterly direction 

southwest Traveling in a southwesterly direction 

clockwise Traveling clockwise in a circular direction 

counterclockwise Traveling counterclockwise in a circular direction 

7.8 StatusType code list 

StatusType is a CodeList for the attributes statusInfo and statusTypeCode. 

Table 22 – CodeList for StatusType 

Name Definition 

active In active service 

inactive Not in active service 

obsolete Rendered obsolete 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation - Transit

47

7.9 TransitServiceType code list 

TransitServiceType is a CodeList for the attribute transitServiceType. 

Table 23 – Codelist for TransitServiceType 

Name Definition 

regular Local or typical service 

express Rapid service; may be due to fewer stops along the pattern 

circular Service operating in a circle 

radial Operations that coordinates service from a central location 

feeder Service that collects passengers from outlying locations to a centralized 

route 

jitney Service which allows potential customers to flag a transit vehicle 

limited Service which is limited to fewer stops 

charter Contracted services 

school Services provided to serve schools 

special Special services 

operatorTraining Service for operator to train on a route or pattern 

maintenance Service used for maintenance 

noService No service provided 

stand-by Operations waiting to provide services if necessary 

extra Operations that are ready to provide services if needed 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

48

Annex A 

(informative) 

Trip itinerary planning use case 

A.1 Introduction 

In developing this part of the Framework Data Content Standard, specific transit use cases were 

utilized to assist in defining the transit model. While these use cases are not comprehensive in 

defining all the potential uses of transit data, they were critical in providing focus for the 

development team. In future versions of the Transit part, additional use cases will be developed 

to facilitate expansion of the transit model. 

A.2 Supported operation 

A.2.1 Overview and description 

A customer seeks information related to point-to-point travel plans that includes public 

transportation services such as bus, rail, or other mode. The trip itinerary request may be based 

on several key criteria such as origin, destination, travel date/time, amenities desired, traveler 

profile, trip constraints (that is to say, lowest cost, shortest time, fewest transfers, mode, 

accessibility, time of day, day of week), and one way or return trip. Trip plan may include realtime information on schedule adherence, route adherence, and service changes due to 

“incidents” (see Annex C, Unplanned rerouting use case). 

A.2.2 Concept of operations 

Detailed below is the concept of operations for the trip itinerary planning use case. 

• Customer generates a trip request identifying origin, destination, and time/date of travel 

(potentially specifying preference criteria pertaining to cost, transfer, mode/carrier, and so 

on) 

• The Trip Planning System verifies that request is complete and accurate. When verified 

it processes customer request and generates a trip plan 

• The Trip Planning System verifies that the scheduled data is still valid on all legs for near 

term (review trip plan against reroutes, updates, and planned events). If there are 

exceptions, the system regenerates the itinerary 

For trip plans in the near future, the system checks real-time status of service. If there are 

exceptions, it regenerates the itinerary. 

A.2.3 Enumeration of needs 

The following functions are needed to respond to customer requests for trip itinerary requests. 

Request and verify customer trip criteria. 

• Provide options for selecting origin and destination 

o Potential origin and destination names should be comprehensive including 

addresses, vanity addresses, intersections, Landmarks (for example, malls, 

squares, hospitals, and so on), community centers (for example, Hyde Park in 

Chicago) 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

49

• Provide service and amenity options for different modes 

o Date 

o Departure or arrival time 

o Service area 

o Routes/trips 

o Public transportation stops 

• Provide options for criteria selection (“minimizing”) including 

o Shortest trip (travel time , trip distance) 

o Shortest walking/driving distance (access/egress) 

o Least number of transfers 

o Least costly 

• Provide options for including/excluding various criteria including 

o Mode 

o Via landmark 

o Amenity at stop point (for example, parking availability, accessibility) 

o Service types (for example, express or local) 

o Route 

o Fare media (for example, pass, cash, credit card) 

o Accessibility 

Provide transit trip itinerary plan based on customer criteria. 

• Provide driving or walking/biking directions and distances to/from selected public 

transportation stops to/from origin/destination 

o Identify obstacles, barriers, accessibility, amenities for directions to/from public 

transportation stops 

• Provide directions for walking between transfer points 

• Provide transit information on planned bus route numbers, travel direction, schedules and 

current operations including route numbers, departure/arrival times and locations, and 

transfers within a mode and between modes 

• Provide service information on different modes including planned and unplanned detours 

and real-time schedule adherence information 

• Provide amenity information on public transportation stops 

• Provide fare cost information for planned trip 

• Provide estimated travel time for the itinerary 

• Provide a written trip itinerary summary containing the sequential unlinked trip making 

activities including origin, boarding bus stop location and ID number, first transit route, 

alighting location, transfer to 2nd bus route information including boarding & alighting, and 

so on, until the final destination 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

50

To meet these user needs, the following data needs should be supported. 

• Provide a topologically complete and logically consistent transportation network including 

street names and addresses, alternate street names, cities, zip codes, barriers 

• Provide a complete list of street names and landmarks including park and rides, transit 

centers, and neighborhood locations 

• Provide a complete and logically consistent transit network and features 

o Patterns, public transportation stops and time points over all transit modes, and 

transfer points 

o Revenue trip times (particularly detailed bus trip schedules referenced to trip 

pattern spatially on a stop-by-stop or TimePoint-by-TimePoint level), and 

estimated transfer and wait times at stop points (by time of day) 

• Provide fare information for all combinations of itineraries (including transfers) 

• Provide real-time schedule adherence data 

• Provide park-n-ride, transit center data on location, size, amenity, and other 

characteristics description 

• Provide bus stops list on American Disabilities Act (ADA), amenity, shelter, and other 

relevant characteristics 

• Provide unplanned rerouting information (see Unplanned Re-routing use case) 

A.3 Functional requirements for supported operation 

A.3.1 Overview of requirements 

The Trip itinerary plan (TIP) use case is supported through various requirements. 

• Request and verify trip itinerary request 

• Provide trip itinerary plan to customer 

A.3.2 Detailed functional requirements 

Table A.1 below provides detailed functional requirements for TIP operations. 

Table A.1 – Trip itinerary planning (TIP) functional requirements 

Requirements 

TIP.1 – Request and verify trip itinerary criteria 

TIP.1.1 – The system shall provide options to the customer to create an itinerary request. The information components 

needed for this requirement are: 

Information on service area, modes, routes, public transportation stop points 

• Information on origin, destination, date, and time of travel 

• Information on service types and trips per route (including attributes of each trip in the route, for example, 

wheel chair accessibility, bike, or ski rack) 

• Information on fare media accepted 

• Information on public transportation stop points, their amenities, and accessibility 

• Information on allowable criteria selection features (include and exclude; minimize) 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

51

Requirements 

TIP.1.2 – The system shall verify that the customer request is complete and accurate. In addition to the information 

components listed in TIP 1.1, this requirement needs the following information components: 

• Information on addresses, vanity addresses, landmarks, alternate street names 

o Complete list of street names and landmarks 

TIP.2 – Provide transit trip itinerary plan to the customer 

TIP 2.1 – The system shall develop a transit trip itinerary based on customer criteria. To accomplish this, the systems 

shall determine several alternative itineraries. The internal functions are: 

• The location of entry and exit into the transit network 

• The most efficient path from entry to exit in the transit network (based on selected criteria), this may require 

incorporating walking and wait times at transfer locations 

• Walking directions for transfer 

• Walking and driving directions from/to origin/destination and to/from entry/exit points including barriers, 

obstacles, and modal network connections within the transportation network 

• List of amenities at specific public transportation stop points associated with plan 

• Calculate fares and allowable fare media (including transfers) per leg as well as total cost 

• Calculate total travel time 

• Calculate total walking time 

• Generate return trip (if requested) 

The information components needed for this requirement are: 

• For Origin/Destination and Walking and Driving Directions 

o Topologically complete and logically consistent transportation network including street names and 

complete addresses 

• For Developing the Transit Trip Plan 

o Complete and logically consistent transit network and features 

 Patterns, public transportation stop points and time points over all transit modes, and transfer points

 Revenue trip times (each bus trip can be geo-referenced by trip pattern spatially on a stop-by-stop 

or TimePoint-by-TimePoint level), and estimated transfer and wait times at stop points (by time of 

day) 

o Fare Information for all combinations of itineraries (including transfers) 

TIP 2.2 – The system shall verify the trip itinerary plan against any planned or unplanned detours, delays or special 

services. The information components needed for this function are: 

• Unplanned rerouting along the trip plan 

• Status of Planned/construction of TranSeg along the trip plan 

• Special service schedules (auxiliary parking facilities that are used as pick-up/drop-off points) 

<<The information components needed to support this function are not included in the Data Mapping section>> 

TIP 2.3 – The system shall provide real-time updates on itineraries that are scheduled for the near future (for example, 

within an hour). The information components needed for this function are: 

• Estimated departure/arrival times of vehicles designated to perform selected trips in itinerary 

<<The information components needed to support this function are not included in the Data Mapping section>> 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

52

A.4 Mapping data requirements to current transit model 

The data requirements necessary for trip itinerary planning use case are described in Table A.2 

below. 

Table A.2 – Trip planning data requirements 

Data Requirements Definitions Assumptions/Conditions 

Public transportation stop 

An established location 

where public transport 

customers may board or 

alight from a transit vehicle 

in revenue service 

Attributes: see Annex B (informative) Public 

transportation stop inventory sharing use case 

Include: 

• Wait times 

• Fare Zone (if applicable) 

Amenity 

The elements of a physical 

feature, a fixed location, or a 

transit facility. The 

amenities of a public 

transportation stop, for 

example, may include the 

shelter, platform 

announcement panel, and 

benches. An amenity may 

be described by one or 

more characteristics, or 

attributes, such as the year 

of construction or its current 

condition 

Unique ID, name, type. Domain types: list the known 

types and add “other” 

Transfer clusters 

A transfer cluster is a 

geographic location that 

encompasses more than 

one bus stop where a 

customer can move from 

one route to another. 

Defined the same as 

TransferCluster 

Transfer cluster could have an associated impedance. 

Then it might not be accessible. TransferClusters 

need to be composed of public transportation stops 

and unique identifier. Impedance, walking directions 

between stop points should also be included 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

53

Data Requirements Definitions Assumptions/Conditions 

Patterns (including routes) 

A unique, non-branching, 

ordered sequence of 

TimePoints, street links, 

public transportation stops 

from the beginning of a 

route to the end of a route 

Patterns provide the path of the trips, temporal service 

information is contained in the trips. Patterns serve a 

function similar to “anchor points” in Part 7c: Roads. 

The density of TimePoints is directly related to the 

accuracy needed in the schedule 

The pattern is an ordered sequence of road segments, 

as well as time points, and stops. But transit agencies 

usually use the whole segment, rather than portions of 

segments, even when the public transportation stop 

occurs in the middle of the block 

Fields include: 

• Pattern type 

• Service type – local/express 

• Schedule version 

Model Element: 

• Ordered sequence of streets (TranSeg) that 

make up the pattern, which furnishes 

geometry 

Note: At Washington Metropolitan Area Transit 

Authority (WMATA), path/route is an ordered 

sequence of TimePoints. For trip planning, there is an 

ordered set of road segments or an ordered set of 

TimePoints 

Streets 

Street links: 

• ID 

TranSeg: 

• Status 

• length 

• geometry (optional) 

• topology (optional) 

All other attributes that pertain to roads are classified 

as linear or point events 

Address ranges 

Set of sequential numerical 

addresses along a street 

segment 

See Annex D (informative) Address extension to the 

transit model 

Landmarks Points or areas of interest 

Landmark attributes: 

• Name 

• Type 

• Location 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

54

Data Requirements Definitions Assumptions/Conditions 

Parking lots 

Locations where public or 

pay spaces are available for 

motor vehicles 

Attributes: 

• ID 

• Public transportation stop(s) served 

• Transit routes served and schedules 

• Owner (optional) 

• Facility phone (optional) 

• Total spaces 

• Operating hours 

• Parking provided for each vehicle class 

(spaces, rates, permissible entrances, fill 

time, other information) (optional) 

• Availability of charging facility for electric 

cars (optional) 

• Bicycle storage and lock facility (optional) 

Walking distance TranSeg Linear distance as measured by the geographic 

transportation network 

Accessibility Category of difficulty in 

accessing a location 

Curb cuts and corners are needed for ADA 

compliance. They should be attached to the road 

segment 

Obstacles to walking, grade 

data 

Impediments to traversal of 

street and/or walkway areas 

An attribute is added to the TranSeg; “walking 

permitted – yes/no.” The attribute is applied to each 

individual road segment. An obstacle could be a 

linear event, but is often just a Boolean attribute on a 

segment. Typically, one can walk along or walk over. 

The value applies to the entire segment 

Fare data (based on distance, 

or zones, or flat) 

Information on the 

calculation of transit access 

prices 

Types of fare policies:

• Flat

• Distance

• Zone

• Time of day 

• Transfers

• Special rider classes (elderly, youth, 

disabled)

• Bulk pass discount

Six-dimension table is required to handle the 

relationships between all the variations in fare types 

See section 0 for guidance on TCIP Fare Collection 

Fare Tables (NTCIP 1408) 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

55

Data Requirements Definitions Assumptions/Conditions 

Schedules 

From TCIP: “A table that 

includes all the time points 

and trips on a route. 

Contained within the 

SchRoute is the Master 

Schedule Header 

information. Contained 

within SchTrip is the day 

type information” 

For each route: 

• Time table version 

• Activation date 

• Deactivation date 

• All supported trips assembled by route 

direction, service type, and day type 

• All supported trips in correspondence to the 

trip pattern number 

Trips 

One way scheduled 

movement of a transit 

vehicle between starting and 

ending time points 

Attributes: 

• ID 

• Trip type 

• Ordered sequence of time points with their 

times (of arrival) 

• Pattern ID (associated with) 

• Time table version 

Pedestrian (sidewalks, bike 

paths, walking paths, centerline 

dividers) 

Locations designated for 

pedestrian traffic 

Attributes: 

• TBD 

A.5 Guidance on how to specify a fare table using TCIP standard on fare 

collection business objects (NTCIP 1408:2001) 

A.5.1 General 

The TCIP fare collection standard supports a variety of fare tables. Each is packaged as data 

stream of fare character costs that is based on the fare policy and fare media used. The fare 

table includes identifiers to the data stream definition through the table-type-id (zone or distance 

based fare tables) and list-of-fare-character-cost (fare media type) fields. 

The steps for defining fare tables are defined in Table A.3 below. Each of these steps is 

discussed in more detail in the sections below. 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

56

Table A.3 – Fare definition steps 

1. Develop fare tables for a specific agency/mode based on the validity date of the fare policy (that is to say, activationdatetime, deactivation-datetime) 

2. Identify fare policy type and develop indices to define boarding/alighting pairs: 

• Zone 

• Distance 

• Flat fare is a generalization from either the zone or distance based fare (one dimensional matrix) 

3. Calculate the Cost based on Fare Media Type 

4. Define the Time Period Table 

5. Define the Fare Instruments 

6. Identify Exceptions 

FcFareTable ::=SEQUENCE { 

 id FC-FareTableID, 

 time-period-table-id FC-TimePeriodTabelID, 

 table-type-id CHOICE { 

 zone-table-id FC-FareZoneTableID, 

 distance-table-id FC-FareDistanceTableID } OPTIONAL, 

 mode CPT-Mode OPTIONAL, 

 agency-id CPT-AgencyID OPTIONAL, 

 activation-datetime CPT-DateTime OPTIONAL, 

 deactivation-datetime CPT-DateTime OPTIONAL, 

 list-of-fare-character-cost SEQUENCE OF FcFareCharacterCost, 

 input-parameters OCTET STRING OPTIONAL 

 --these are the base values of the table when an algorithm is 

 --specified in the FcFareCharacterCost record 

} 

A.5.2 Fare tables and fare policy type 

1. Develop fare tables for a specific agency/mode based on the validity date of the fare policy 

(that is to say, activation-datetime, deactivation-datetime) 

2. Identify fare policy type and develop indices to define boarding/alighting pairs: 

• Zone 

• Distance 

• Flat fare is a generalization of either the zone or distance based fare (one dimensional 

matrix) 

Zone based fare tables

Identify all combinations of boarding zones and alighting zones. Each cell has an index. 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

57

Table A.4 – Fare zone table (FcFareZoneTable) 

Boarding / Alighting Zone Zone 1 (boarding-zone-id) Zone 2 

Zone 1 (alighting-zone-id) 1 (index) 2 

Zone 2 3 4 

FcFareZoneTableEntry defines each cell index by boarding and alighting zones. 

 FcFareZoneTableEntry ::=SEQUENCE { 

 index FC-FareZoneIndex, 

 boarding-zone-id CPT-FareZoneID, 

 alighting-zone-id CPT-FareZoneID } 

FcFareZoneTable lists all the cells contained in the table (see Table A.4). Because the table may 

be valid at certain times or certain days (for example, peak hour fares) an optional field may be 

set to specify the validity of the activation and deactivation of date/time. Furthermore, there is a 

business rule that for each FcFareZoneTable (identified by a separate index – FCFareZoneTableID), each cell index (FC-FareZoneIndex) in the list-of-cell-indices shall be unique. 

FcFareZoneTable ::=SEQUENCE {id FC-FareZoneTableID, 

 list-of-cell-indices SEQUENCE OF FC-FareZoneIndex, 

 activation-datetime CPT-DateTime OPTIONAL, 

 deactivation-datetime CPT-DateTime OPTIONAL, 

 agency-id CPT-AgencyID OPTIONAL} 

Distance based fare tables

The Distance based fare tables are organized in a similar fashion. A basic matrix is defined by 

the FcFareDistanceTable (see Table A.5). Each entry or cell in the table is defined by a 

FcFareDistanceTableEntry. An assumption is made that there are a finite number of stop points 

in the system, and so, the FcFareDistanceTable is defined as a matrix of boarding and alighting 

stop points. 

Table A.5 – Fare distance calculations matrix (FcFareDistanceTable) 

Boarding / Alighting Stop Point Stop # 1001 (boarding-stop-point-id) Stop #1002 

Stop # 1001 (alighting-stop-point-id) 1 (index) 2 

Stop # 1002 3 4 

FcFareDistanceTableEntry ::=SEQUENCE { 

 index FC-FareDistanceIndex, 

 boarding-stop-point-id CPT-StopPointID, 

 alighting-stop-point-id CPT-StopPointID } 

The FcFareDistanceTable entry also includes a mandatory field on the type of distance that is 

calculated: linear (along the path) or line-of-sight. Similar to the zone based fare table, the 

distance table is identified by a unique index and each cell in the list-of-fare-cell-indices should be 

unique. 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

58

FcFareDistanceTable ::=SEQUENCE { 

 id FC-FareDistanceTableID, 

 type FC-FareDistanceType, 

 activation-datetime CPT-DateTime, 

 list-of-fare-cell-indices SEQUENCE OF FC-FareDistanceIndex } 

A.5.3 Calculating the cost based on fare media type 

The cost of a ride may be based on: 

• Rider classification (for example, regular, senior, child) 

• Service type (for example, regular, express, local, loop) 

• Time (period) of day traveling (see definition of FcTimePeriodTable below) 

• Fare instrument (see definition of FcFareInstrument below) 

• Distance or zones traveled through (FcFareZoneTable and FcFareDistanceTable) 

So the cost is based on a five dimensional table. The best way to approach defining the cost is to 

approach the first four fields: rider classification, service type, time period and fare instrument 

fixed and fill in the cost for the distance or zone policy. 

For example, the fare at Metro MTA on a bus for a regular rider, riding on an express during 

morning peak using cash will pay a monetary cost of monetary-value. Each unique definition for 

the FcFareCharacterCost will be associated with a unique index (FC-FareCharacterCostIndex). 

(See Table A.6 for character code values.) 

The amount of each character cost entry is defined by at least one of the following: 

• Monetary cost 

• Ride cost 

• Algorithm for calculating the value of either ride or monetary cost 

FcFareCharacterCost ::=SEQUENCE { 

 index FC-FareCharacterCostIndex, 

 rider-classification FC-RiderClassification, 

 service-type SCH-ServiceType OPTIONAL, 

 time-period-index FC-TimePeriodIndex OPTIONAL, 

 fare-type-index CHOICE { 

 fare-zone-index FC-FareZoneIndex, 

 fare-distance-index FC-FareDistanceIndex} OPTIONAL, 

 list-of-fare-instrument-ids SEQUENCE OF FC-FareInstrumentID, 

 monetary-value FC-FareCost OPTIONAL, 

 ride-value FC-RideValue OPTIONAL, 

 algorithm OCTET STRING OPTIONAL --(executable or algorithm for 

 -- calculating fare) 

} (WITH COMPONENTS {..., monetary-value PRESENT}| 

WITH COMPONENTS {..., ride-value PRESENT}| 

WITH COMPONENTS {..., algorithm PRESENT}) 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

59

Table A.6 – Data element code values for select FcFareCharacterCost fields 

Data Element Name Definition Code Values 

FC-RiderClassification 

A means of classifying the types 

of riders on public transportation 

vehicles 

FC-RiderClassification ::=INTEGER { 

 regular (1), 

 senior (2), 

 child (3), 

 student (4), 

 youth (5), 

 ada-customer (6), 

 promotional (7), 

 employee (8), 

 retired-employee (9), 

 public-assistance-customer (10) 

 -- 11-155 reserved 

 -- 156-255 local use 

} (0..255) 

SCH-ServiceType Type of transit service provided 

SCH-ServiceType ::=INTEGER { regular (1), 

 express (2), 

 circular(3), 

 radial (4), 

 feeder (5), 

 jitney (6), 

 limited (7), 

 nonRevenue (8), 

 unknown (9), 

 charter (10), 

 school (11), 

 special (12), 

 operatorTraining (13), 

 maintenance (14), 

 noService (15), 

 standBy (16), 

 extra (17) 

 -- 18-149 reserved 

 -- 150-255 local use 

} (0..255) 

A.5.4 Defining the time period table 

The fcTimePeriod table may be defined for the calendar or by day type. Each cell (each column 

in Table A.7) in the FcTimePeriod table is defined by FcTimePeriodEntry. 

Table A.7 – Example of a FcTimePeriod table for weekday (day type) 

begin-time to end-time 5:30-7:30 

(early am) 

7:30-9:30 

(morning peak) 

9:30-3:30 

(mid-day) 

3:30-7:00 

(afternoon 

peak) 

7:00-12:00 pm 

(night) 

index [FCTimePeriodIndex] 1 2 3 4 5 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

60

FcTimePeriodEntry ::=SEQUENCE{ 

 index FC-TimePeriodIndex, 

 begin-time TIME, 

 end-time TIME, 

 day CHOICE { 

 calendar-date CPT-CalendarDate, 

 day-type SCH-DayType } 

} 

The collection of FcTimePeriodEntry completes the FcTimePeriodTable. Each FCTimePeriodIndex shall be unique for a single time period table (FC-TimePeriodTableID). A 

calendar may be designed for this format. Each segment of time within a calendar date may be 

assigned a unique identifier. 

FcTimePeriodTable ::=SEQUENCE { 

 id FC-TimePeriodTableID, 

 list-of-time-period-indices SEQUENCE OF FC-TimePeriodIndex, 

 agency-id CPT-AgencyID OPTIONAL, 

 activation-date CPT-ActivationDate OPTIONAL, 

 deactivation-date CPT-DeactivationDate OPTIONAL 

} 

A.5.5 Defining fare instruments 

Many transit agencies support various types of fare categories and instruments (see Table A.8 for 

instrument names and definitions). There are daily, weekly and monthly passes, combination 

passes, tickets, trip checks, transfers, tokens, rider cards, rider discount cards, “golden” passes, 

and of course, cash. There are four ways of defining fare instruments: 

• Based on ride value 

• Based on cash value 

• Based on unlimited number of rides over a period of time 

• Other 

Also, fare instruments may be used in combination, for example, ten cents with a senior pass. 

Table A.8 – TCIP definition of various fare instruments 

Fare Instrument Name Fare Instrument Definition 

FcFareInstrument 

The definition of a valid fare instrument that can be used by a 

specific public transportation service. A fare instrument may be 

defined as multiple value instruments, for example, ten cents with a 

senior pass 

FcMonetaryInstrumentDefinition 

The definition of a type of instrument that possesses a monetary 

value including cash (bills and coins), tokens, tickets, passes, and so 

on 

FcFareMediaOtherDefinition 

A fare instrument which does not fall into monetary, ride, or pass 

categories. (This may include an employee or retired identification 

card) 

FcPassInstrumentDefinition A fare instrument which contains unlimited number of rides over a 

period of time, for example, monthly, weekly, and daily passes 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

61

Fare Instrument Name Fare Instrument Definition 

FcRideInstrumentDefinition 

The definition of a fare instrument that possesses a ride value for a 

trip on a public transportation vehicle serving a transit agency or a 

region fare structure 

Ride instrument definition

The ride instrument may be a token, ticket (like a transfer), pass fare card, or transit check. The 

value is expressed as a ride. There may be restrictions on the ride such as mode choice, route or 

line choices, or Transit agency providing the service. 

FcRideInstrumentDefinition ::=SEQUENCE { 

 id FC-RideInstrumentID, 

 type FC-RideInstrumentType, 

 description FC-RideInstrumentDescription, 

 value FC-RideValue, 

 agency-id CPT-AgencyID, 

 list-of-modes-accepted SEQUENCE OF CPT-Mode OPTIONAL, 

 list-of-routes-accepted SEQUENCE OF SCH-RouteName OPTIONAL 

 list-of-lines-accepted SEQUENCE OF SCH-BlockName OPTIONAL } 

FC-RideInstrumentType 

• token (1) 

• ticket (2) 

• pass-fare-card (3) 

• transit-check (4) 

Pass instrument definition

The pass instrument is typically a card, magnetic stripe, flash, transit check, or smart card. The 

pass permits unlimited travel for a certain period of time. Although many places issue magnetic 

stripe or smart cards for the value of one ride or for a purse of cash, this category should not be 

confused with those alternative instrument classifications. In the FcPassInstrumentDefinition 

message, the expiration-datetime defines the time and date that the card expires. If the 

instrument is activated on first use, then the field is set on entry to the system. With the pass 

instrument, there may be restrictions associated with its use such as mode, routes, and lines. A 

transfer may also be defined as a pass instrument if the transfer is based on its use over a period 

of time, for example, two hours since issue. 

FcPassInstrumentDefinition ::=SEQUENCE { 

 id FC-PassInstrumentID, 

 type FC-PassInstrumentType, 

 description-FC-PassInstrumentDescription OPTIONAL, 

 agency-id CPT-AgencyID OPTIONAL, --issuer of pass instrument 

 value FC-PassValue, 

 expiration-datetime FC-ExpirationDateTime OPTIONAL, 

 list-of-modes-accepted SEQUENCE OF CPT-MODE OPTIONAL, 

 list-of-routes accepted SEQUENCE OF SCH-RouteID OPTIONAL, 

 list-of-lines-accepted SEQUENCE OF SCH-BlockName OPTIONAL} 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

62

FC-PassInstrumentType 

• mag-stripe (1), 

• flash-pass (2), 

• transit-check (3), 

• smart-card (4) 

Monetary instrument definition

The monetary instrument is defined by categories set by an international standardization body. 

The FC-MonetaryInstrumentType is defined as: 

“A list of authorities and global currencies as specified by a 3 character ISO 4217 currency code 

or six character CPT-AgencyID. The ISO 4217 format includes a two character country code 

based on ISO 3166 plus a one-character currency designator.” 

This definition supports transit agencies that mint their own tokens. The default monetary 

authority in the USA is cents. 

FcMonetaryInstrumentDefinition ::=SEQUENCE { 

 id FC-MonetaryInstrumentTypeID, 

 type FC-MonetaryInstrumentType, 

 description FC-MonetaryInstrumentDescription, 

 authority FC-MonetaryInstrumentAuthority, 

 value FC-MonetaryInstrumentValue } 

FC-MonetaryInstrumentType 

• bill (1), --bill 

• coin (2), --coin 

• token (3), --token 

• ticket (4), --ticket 

• debit (5), 

o debit: money is in user’s acct and transferred to transit authority (TA) acct; 

o card is external to TA 

• stored-value (6), 

o --stored value: prepaid cash; internal cash instrument 

o --issued by property 

• charge (7), -- charge: Federal institution extends credit 

• hybrid (8), --hybrid 

• transit-check (9), -- transit check 

• Check-card (10) --check card 

Other fare media definitions

As described above, FcFareMediaOtherDefinition describes any other type of fare media. No 

value is provided for this type of instrument. Special rules shall be defined by the agency and 

vendor for the vendor product. 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

63

FcFareMediaOtherDefinition ::=SEQUENCE { 

 id FC-FareMediaOtherID, 

 description FC-FareMediaOtherDescription, 

 agency-id CPT-AgencyID OPTIONAL } 

Fare instrument definition

The fare Instrument defines all the fare instruments that are permitted for paying for services. In 

the fare instrument definition, multiple payment methods may be defined. So, using the example 

cited in this section: “ten cents with a senior pass”, the senior pass may be defined as a 

FcFareMediaOtherDefinition and ten cents as FcMonetaryInstrumentDefinition with a value of ten 

cents. The fare instrument definition is provided with a unique identifier (id FCFareInstrumentID). The ID may then be inserted into the FcFareCharacterCost.list-of-fareinstrument-ids as a permissible fare instrument. 

FcFareInstrument ::=SEQUENCE { 

 id FC-FareInstrumentID, 

 agency-id CPT-AgencyID, 

 monetary-instrument-type-id FC-MonetaryInstrumentTypeID OPTIONAL, 

 ride-instrument-id FC-RideInstrumentID OPTIONAL, 

 pass-instrument-id FC-PassInstrumentID OPTIONAL, 

 fare-media-other-id FC-FareMediaOtherID OPTIONAL, 

 riders-on-fi-max FC-RidersOnFIMax OPTIONAL, 

 activation-datetime CPT-DateTime OPTIONAL, 

 expiration-datetime FC-ExpirationDateTime OPTIONAL, 

 list-of-fi-standards SEQUENCE OF FC-FIStandard OPTIONAL, 

 instrument-physical-dimensions FOOTNOTE OPTIONAL } 

 (WITH COMPONENTS {..., monetary-instrument-type-id PRESENT}| 

 WITH COMPONENTS {..., ride-instrument-id PRESENT}| 

 WITH COMPONENTS {..., pass-instrument-id PRESENT}| 

 WITH COMPONENTS {..., fare-media-other-id PRESENT}) 

A.5.6 Identifying exceptions 

There are always exceptions to the best fare policies. As such, the standard recognizes a way of 

defining exceptions. Exceptions are described for any combination of the fields that were 

described above. For example, boarding/alighting location pair, service type, mode, time period 

traveled, fare instrument type. The money-deduct and ride-deduct fields define the cost of the 

specific service defined by the other fields. 

FcFareExceptionCell ::=SEQUENCE { 

 index FC-FareExceptionCellIndex, 

 boarding-stop-point-id CPT-StopPointID, 

 alighting-stop-point-id CPT-StopPointID OPTIONAL, 

 footnote FC-Footnote, 

 service-type SCH-ServiceType OPTIONAL, 

 mode CPT-Mode OPTIONAL, 

 list-of-time-period-indices SEQUENCE OF FC-TimePeriodIndex OPTIONAL, 

 monetary-instrument-id FC-MonetaryInstrumentTypeID OPTIONAL, 

 ride-instrument-id FC-RideInstrumentID OPTIONAL, 

 pass-instrument-id FC-PassInstrumentID OPTIONAL, 

 fare-media-other-id FC-FareMediaOtherID OPTIONAL, 

 money-deduct FC-ValueDeduct OPTIONAL, 

 ride-deduct FC-RideValueDeduct OPTIONAL 

} 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex A (informative): Trip itinerary planning use case

64

 (WITH COMPONENTS {..., monetary-instrument-id, money-deduct PRESENT}| 

 WITH COMPONENTS {..., ride-instrument-id, money-deduct PRESENT}| 

 WITH COMPONENTS {..., pass-instrument-id, money-deduct PRESENT}| 

 WITH COMPONENTS {..., fare-media-other-id, money-deduct PRESENT}| 

 WITH COMPONENTS {..., monetary-instrument-id, ride-deduct PRESENT}| 

 WITH COMPONENTS {..., ride-instrument-id, ride-deduct PRESENT}| 

 WITH COMPONENTS {..., pass-instrument-id, ride-deduct PRESENT}| 

 WITH COMPONENTS {..., fare-media-other-id, ride-deduct PRESENT}) 

Each cell is defined by a unique index and stored in the FcFareExceptionTable. The exception 

table is associated with a fare table. The thought is that the exception table is incorporated by the 

vendor as an exception to relevant list-of-fare-character-cost fields in the main fare table. 

FcFareExceptionTable ::=SEQUENCE { 

 id FC-FareExceptionTableID, 

 activation-date CPT-ActivationDate, 

 deactivation-date CPT-DeactivationDate OPTIONAL, 

 table-id FC-FareTableID OPTIONAL, 

 --index identifying exception to a fare table 

 time-period-table-id FC-TimePeriodTableID OPTIONAL, 

 agency-id CPT-AgencyID OPTIONAL, --that accepts exception 

 list-of-fare-cell-indices SEQUENCE OF FC-FareExceptionCellIndex} 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex B (informative): Public transportation stop inventory sharing use case

65

Annex B 

(informative) 

Public transportation stop inventory sharing use case 

B.1 Supported operation 

B.1.1 Overview and description 

Different transit organizations capture spatial and attribute information about public transportation 

stops using a variety of methods, with varying levels of accuracy, and for different business 

reasons. Quite often the geographic areas in which different agencies operate are overlapping. 

Even if they do not overlap, two agencies may provide services that are complimentary. There is 

a growing list of reasons organizations need to share information about public transportation 

stops. They include but are not limited to: 

• Public Safety 

• Avoiding duplication of effort (data collection) 

• Data maintenance 

• Coordination of maintenance activities 

• Supporting ITS applications 

• Coordination of marketing activities 

• More reliable data for trip planning activities 

• Cartographic output 

• Ridership analysis 

• System planning 

Complicating the sharing of this information is the fact that different organizations define public 

transportation stops differently. More importantly they may capture the spatial information about 

the same real world feature differently. For example, for one organization, the location of a bus 

stop is the location of the pole holding the bus stop sign. Another organization may capture the 

bus stop as the location of the bus when passengers are boarding and alighting. Another 

possible spatial definition is a GPS coordinate that would be captured by an on board GPS 

receiver at varying times of the day. A fourth representation may be a linear referenced feature 

along a centerline network, thus tying the accuracy of the bus stop to the accuracy of the 

centerline network. Because of these factors it is imperative that the information in a bus stop 

inventory be sharable independent of the geography. 

B.2 Enumeration of needs 

Table B.1 lists functions that would be performed using a regional public transportation stop 

inventory. Many of these functions are currently being performed however a regional public 

transit stop database would make these functions more efficient. To be consistent with other use 

cases, an actor has been identified who would perform each function. 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex B (informative): Public transportation stop inventory sharing use case

66

Table B.1 – Potential users of shared data 

Actor Responsibilities 

Maintenance personnel 

Maintain a facilities inventory of all maintainable facilities associated with public 

transportation stops. This would allow coordination with other maintenance operations 

divisions within the same geographic area 

Customer service personnel Identify stop amenities to the public for specific stops 

Public safety personnel 

Comprehensive maps and images of real world features when responding to 

emergency incidents. This would also provide the ability to plan and analyze public 

transit data across a large geographic area in conjunctions with emergency operations. 

An example would be the sniper incidents around Washington, DC, in the fall of 2002 

Route planners / system 

planners 

Plan for increased or decreased service based on the service of neighboring 

jurisdictions 

Operations personnel Provide necessary data to Intelligent Transportation System (ITS) applications 

B.3 Functional requirements for supported operation 

B.3.1 Overview 

Table B.2 lists data requirements for public transportation stop data sharing. There is one 

indispensable requirement for a regional public transportation stop inventory: a unique identifier 

for the public transportation stop. The unique identifier shall be something that each organization 

can maintain independently. It shall not be a number or series of characters that has an alternate 

meaning. 

Table B.2 – Detailed functional requirements 

Requirements 

PTS.1 – Public transportation stop data sharing 

PTS 1.1 – A regional public transportation stop inventory shall support the sharing of stop information across multiple 

agencies. The information components required for this requirement are: 

• A unique identifier 

• Latitude / Longitude (if exists) 

• Heading (if exists) 

• Date last update (if exists) 

• United States National Grid (USNG) Address (if exists) 

Optional data shall also be included if it exists such as the following: 

• Ridership data 

• Route data 

• Status (active, retired, and so on) 

• Amenity information 

• Engineering data (sidewalk, curb, and so on) 

The format of the optional data is not overly important as long as each table of associated information is linked to the 

regional ID 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex B (informative): Public transportation stop inventory sharing use case

67

B.4 Mapping data requirements to current transit model 

Figure B.1 shows a data requirement mapping example from the Washington Metro Area Transit 

Authority (WMATA). Items in bold reflect minimum requirements for this specific business 

application. 

StopID

PK,FK1 TAID

PK,FK1 StopID

FK4 RegionID

Latitude

Longitude

Heading

OnStreet

AtStreet

Position

Jurisdiction

DateLastUpdate

UserLastUpdate

Status

FK2 TAID

FK2 StopID

ActivationDate

DeactivationDate

ModificationDate

PlacementDate

DateLastUpdate

UserLastUpdate

TransitInfo

FK2 TAID

FK2 StopID

Owner

CaseType

PlacementDate

Schedule

ScheduleDate

VMS

AreaMap

AreaMapDate

Advertisement

RouteMap

RouteMapDate

SystemMap

SystemMapDate

UserLastUpdate

DateLastUpdate

Flag

PK,FK2 TAID

PK,FK2 StopID

MultipleOwner

FlagType

Owner

RouteGraphic

FlagCondition

DateLastUpdate

UserLastUpdate

RegionID

PK RegionID

USNGAddress

Latitude

Longitude

Heading

AtStreet

OnStreet

DateLastUpdate

UserLastUpdate

Bench

FK1 TAID

FK1 StopID

BenchMatl

BenchManu

BenchOwner

Advertisement

PlacementDate

BenchCondition

DateLastUpdate

UserLastUpdate

Photo

FK1 TAID

FK1 StopID

Photo

PhotoDate

DateLastUpdate

UserLastUpdate

Regional Bus Stop Inventory

Version 1.3

4 February 2003

Shelter

FK2 TAID

FK2 StopID

ShelterMatl

ShelterManu

ManuModel

Installer

Maintainer

Count

Foundation

Advertisement

PlacementDate

ShelterCondition

Size

BenchInShelter

DateLastUpdate

UserLastUpdate

Engineering

FK1 TAID

FK1 StopID

TypeInstallation

CurbCut

CutLength

BusCapacity

Sidewalk

PedestrianPad

BusPad

CrossWalk

Lighting

ADACompliant

TrafficControlDev

ZoneLength

ZoneRestrictions

TrashCan

DateLastUpdate

UserLastUpdate

Figure B.1 – Sample regional bus stop database structure 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex C (informative): Unplanned re-routing use case

68

Annex C 

(informative) 

 Unplanned re-routing use case 

C.1 Supported operation 

C.1.1 Overview and description 

As part of ongoing business operations, transit agencies often shall deviate from scheduled 

routings to accommodate a variety of dynamic situations. The duration for these deviations could 

be short or long depending on the event and the ability of the vehicle to return to the scheduled 

pathway. Examples of unplanned events requiring deviations from scheduled pathways include: 

• Roadway accidents 

• Unplanned or emergency construction activities 

• Weather 

These events usually result in an obstacle or blockage that closes the roadway to thru traffic 

necessitating the use of a detour. These detours are usually created in a spontaneous fashion, 

designed on the fly by field personnel, and then communicated to operations centers for ongoing 

use until the detour is no longer necessary. In emergency situations, first responders may 

designate detour routes. detour routings will likely affect the path the transit revenue vehicle 

takes, but they may also impact arrival/departure times, frequency of service, public 

transportation stop locations/accessibility, and others. 

A more complex situation involves a mode-substitution in response to an unplanned reroute. In 

fixed guideway service (for example, rail), an outage due to vehicle blockage or guideway 

problems can result in the need to provide an alternate route via a different mode. Most agencies 

have contingency plans to accommodate such events, but the specifics of the reroute path, 

vehicles used, frequency of service, and so on, is dependent upon the timing, location, and 

longevity of the event. The mode change scenario is not within the scope of this use case. 

C.1.2 Enumeration of needs 

Table C.1 lists functions that are necessary to respond to unplanned reroutes. For each function, 

an actor has been identified who would perform the function. 

Table C.1 – Unplanned re-routing stakeholders 

Actor Responsibilities 

Field personnel (in 

consultation with operations 

center and first responders 

if present) 

Identify appropriate detour path and new public transportation stops 

Identify estimated duration of detour 

Communicate path and public transportation stops to operations center 

Assist passengers needing to transfer to new mode or vehicle 

Identify cause and supervising agency (for example, EMS, utility, and so on) and key 

contact person; may also communicate duration of event. <<not in scope of our use 

case>> 

Continue to communicate unplanned event status. <<not in scope of our use case>> 

Vehicle Receive and store new automated announcements, interior and exterior sign detail, and 

schedule adjustments 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex C (informative): Unplanned re-routing use case

69

Actor Responsibilities 

Driver 

If driver receives run card via vehicle control head (mobile data terminal), acknowledge 

receipt of alternative route 

Provide verbal announcements of new public transportation stops and transfer points 

Customer information 

Inform customers of detour route path and duration 

Inform customers of changes to public transportation stop locations and times 

Operations center 

Identify affected routes and specific trips 

Provide operators with driving directions for detour route 

Identify new patterns and routing 

Adjust schedules for connecting services 

Generate and provide driver and/or vehicles with new automated announcements, 

interior and exterior sign detail, and schedule adjustments 

Coordinate incident response with supervising agency <<not in scope of our use case>> 

C.2 Functional requirements for supported operation 

C.2.1 Overview 

The requirements for supporting the rerouting use case are: 

• Identifying the changes to the transit system 

• Communicating those changes to various components of the system that need it. These 

are expanded below in Table C.2 

Table C.2 – Detailed functional requirements 

Requirements 

RR.1 – Identify necessary changes in scheduled paths and public transportation Stops. 

RR 1.1 – Field personnel and the operations center shall work together to identify the optimal detour path and changes 

in public transportation stop locations. This requirement shall contain the following information components: 

• Information about the incident such as location, type of incident (for example, fire, flood, and so on), estimated 

duration 

• Area affected, including streets and intersections 

• Duration of event 

• Obstacles to walking 

• Navigable streets 

• Public transportation stops excluded by the event 

• Public transportation stops created as a result of the event 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex C (informative): Unplanned re-routing use case

70

Requirements 

RR 1.2 – The operations center shall identify impacts on subsequent trips for the rerouted vehicles and impacts on 

public transportation stops outside of the immediate area affected by the event. This may include adjusting schedules of 

connecting services. The information components required for this requirement are: 

• Information about the incident such as location, type of incident (for example, fire, flood, and so on), estimated 

duration 

• Area affected 

• Duration of event 

• Navigable streets 

• Facility locations 

• Additional public transportation stops and facilities excluded by the event 

RR.2 – Communicate changes in schedule. 

RR 2.1 – The operations center shall communicate information about schedule changes to drivers, customer 

information, and revenue vehicles. This information may have to be communicated via a variety of mechanisms 

depending on the location of the receiver and the duration of the event. For example, on-duty drivers may need to 

receive the information by radio or digitally over a wireless communications link, whereas drivers who will experience 

the change in service on subsequent days may receive the information via hardcopy. The information components 

required for this requirement are: 

• Information about the incident such as location, type of incident (for example, fire, flood, and so on) 

• Area affected 

• Estimated duration of event 

• Public transportation stops excluded by the event 

• Public transportation stops created as a result of the event 

• Driving instructions 

• Revenue vehicles affected 

In addition, if the reroute is of sufficient duration to incorporate within the information and scheduling systems within the 

agency, then the following information is required: 

• Ordered set of street segments making up the reroute path. 

• Ordered set of TimePoints making up the reroute path. 

• Ordered set of public transportation stops making up the reroute path 

• New times or time offsets at affected TimePoints 

• New signage for the vehicle 

• New voice announcements for the vehicle 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex C (informative): Unplanned re-routing use case

71

Requirements 

RR 2.2 – The customer information systems shall communicate information about schedule changes to customers. The 

information components required for this requirement are: 

-- On Bus and Off Bus: 

• Information about the incident such as location, type of incident (for example, fire, flood, and so on) 

• Area affected 

• Estimated duration of event 

• Public transportation stops excluded by the event 

• Public transportation stops created as a result of the event 

-- On Bus Customer Information Service (CIS) 

• Announcement of public transportation stops excluded by the event 

• Announcements of new/temporary public transportation stops created as a result of the event 

• Announce estimated delay 

• New signage for the vehicle 

-- Off Bus CIS 

• Routes affected 

• Estimated delay (new times) at public transportation stops 

• Alternate path (with new/temporary public transportation stops) 

C.3 Mapping data requirements to current transit model 

See Table C.3 below for the data entities necessary for the rerouting use case include block, trip, 

route, public transportation stop, facility, and road segment. 

Table C.3 – Data requirements for rerouting use case 

Requirement Model Element 

Obstacles to walking TranSeg 

Navigable streets TranSeg 

Excluded public transportation stops TranSeg, TransitStop, Facility, Block 

New public transportation stops TranSeg, TransitStop, Facility, Block 

Driving instructions TranSeg 

Affected vehicles Block, PTVehicle 

New times (or delay offset) Trip, TimePoint, 

New signage Block, PTVehicle 

New announcement and sign triggers Pattern (if duration of event is sufficiently long) 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex D (informative): Address extension to the transit model

72

Annex D 

(informative) 

Address extension to the transit model 

This annex describes a general approach to support the transmittal of address information 

relevant to the operation of transit systems. Terms such as “road segment” are used in a general 

sense in this annex and do not necessarily refer to features in Part 7: Tansportation Base, Part 

7c: Roads, or Part 7d: Transit. In future versions of this standard, the methods and terms 

described here will be integrated with the transportation model as a whole. 

Address information is useful for several transit-related applications, such as itinerary planning 

and facility management. Addresses may define the location of customers, their designations, 

and the fixed facilities used by transit service providers. Specifically, the transit model needs to 

support transmittal of physical addresses, such as those defined by the proposed FGDC Street 

Address Data Standard for situs or delivery locations. This requirement includes a need to also 

identify the location of these physical addresses on the transportation system utilized by the 

transit service. The traditional approach, and the one supported by this proposal, is to define the 

addresses that exist along a particular street segment. This information is later used to place a 

physical address along the street segment. 

Address segments represent a contiguous portion of a named street with a continuous range of 

physical address numbers and a single combination of street name, postal community, State, and 

postal code. An address segment applies to all or part of a road segment. There may be one or 

more address segment records for each road segment feature. This model means that a single 

address segment cannot span multiple road segment features, and that each road segment 

feature can be subdivided into multiple, logically separate address ranges. 

Johnson St.

City ACity B

3600-3648 3500-3598

3601-3649 3501-3599

Bashir Ave.

4701-4799 4801-4849

4700-4798 4800-4848

Road Segment A Road Segment B Road Segment C

Figure D.1 – Illustration of address segment information requirements 

Figure D.1 shows four address segments covering three city blocks, each of which is represented 

in the local road database using a single road segment feature. Addressing jurisdiction changes 

in the middle of road segment B. (Jurisdiction could be stored in the road database using road 

segment linear events.) Each side of the road has its own address range, usually odd numbers 

on one side and even numbers on the other. In this example, street names and address segment 

patterns are unique to each city. Most street address database implementations use a single 

record with left- and right-side address ranges. However, a more robust data transfer mechanism 

would be constructed such that each address segment record contained the address range 

information applied to a single side of the road. This more complex structure allows the 

transmission of completely different address segment characteristics when, say, there are 

separate controlling political jurisdictions for each side of the road. 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex D (informative): Address extension to the transit model

73

Addresses are located by GIS software along address segments using a process called 

geocoding. In this process, the first step is to find the address segment on which the subject 

address should be located. For example, given an address of 3521 Johnson St., the geocoding 

processor would search the database to find one or more address segments that could include 

this value. The data in Figure D.1 provide at least one candidate, 3501-3599 Johnson St., which 

applies to the left side of road segment C. (Geocoding processors identify the odd and even 

sides of the street addressing system by examining the terminal address range values and/or by 

referencing a field that indicates which side of the road contains odd numbers.) The second step 

is to do straight-line interpolation using the relative position of the subject address along a 

segment, assuming an equidistant spacing of address values. Thus, the address of 3521 

Johnson St. would be placed at a position equal to the address’s offset distance along the 

address segment, as determined by: 

 Location = (Address – First Segment Address) / (Address Segment Range) 

 = (3521 – 3501) / (3599 – 3501) 

 = 20/98, or 20.4% from the start of the address segment 

The first problem for the transit MAT model, with regard to accommodating the transfer of 

address information, is to provide the means for transmitting the address segment records and 

the addresses, which requires two object classes. Figure D.2 illustrates the attributes required to 

express the address segment (AddressSeg) and address (Address) information exchange 

needed under virtually all circumstances. The optionality of fields is expressed using the UML 

[0..1] notation. The first "ID" field shown in both classes may be used as a relational key in 

database implementations. 

Figure D.2 – Suggested information attributes for AddressSeg and Address classes 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex D (informative): Address extension to the transit model

74

As reflected in the mandatory fields, the address information transfer mechanism requires that 

road segment features exist if AddressSeg records are conveyed, but that Address records alone 

may be transmitted. See Part 7: Transportation Base and Part 7c: Roads for model feature 

classes that correspond to road segments, from which TransitSegment features may be derived. 

Figure D.3 shows an illustrative example of this portion of the transit MAT data model with the two 

address classes. RoadSeg (shorthand for road segment), RoadSubSeg (shorthand for road subsegment), and TransitSegment (shorthand for a transit segment or path) are hypothetical feature 

classes that may include geometry. A TransitPath may be constructed from one or more 

RoadSubSeg features, each of which is part or all of a RoadSeg feature. A transportation agency 

may choose to represent the extent of a RoadSubSeg and/or an AddressSeg using a 

LinearAttributeEvent. Address classes extend Part 7c: Roads, but are required to meet transit 

model application needs. 

Figure D.3 – Data model extension to support address information transmission 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation – Transit Annex D (informative): Address extension to the transit model

75

Table D.1 – Data dictionary for AddressSeg and Address 

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

213 AddressSeg <<DataType>> 214 addressSegId 

Unique identifier for the address segment. An address segment is a portion of a named street with a continuous range of address numbers and a single combination of street name, postal community name, State, and postal code. A new address segment is created when any one of these attributes changes. Hundred-number block ranges that reset incrementally at intersections often additionally define address segments. Separate address segments may describe left and right sides of a named street 

M 1 Integer 

215 roadSegId 

Unique identifier for the roadway segment on which the address segment is located. Address segments cannot span multiple road segments, but multiple address segments may reference a single road segment 

M 1 Identifier 

216 recordDate Date the record was created M 1 Date 217 directionPrefix 

Cardinal direction used to differentiate one portion of a named street from another based on its displacement from a central address cross street 

O 1 CharacterString 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation – Transit Annex D (informative): Address extension to the transit model

76

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

218 typePrefix 

Means of differentiating one kind of road from another, used to make otherwise duplicative names unique 

O 1 CharacterString 

219 streetName Primary street name element, such as “Main” or “23rd M 1 CharacterString 220 typeSuffix 

Means of differentiating one kind of road from another, used to make otherwise duplicative names unique and coming after the primary street name component 

O 1 CharacterString 

221 directionSuffix 

Cardinal direction used to differentiate one portion of a named street from another based on its displacement from a central address cross street and coming after the primary street name component 

O 1 CharacterString 

222 completeName 

The full text of the street name with all applicable prefixes and suffixes, such as “N Main St.” Street names are typically decomposed in address databases into several constituent elements, expressed mainly as various prefixes and suffixes to the basic street name, as shown above. This field supports the transfer of a full street name as a single value 

O 1 CharacterString 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation – Transit Annex D (informative): Address extension to the transit model

77

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

223 alternativeStreetName Another name for the street (see completeName) O 1 CharacterString 224 oddSide 

The side of the street, as determined by applying the direction of increasing address numbers, on which odd numbered addresses are located. Used by some geocoding applications to properly place addresses along the address segment in lieu of using left- and right-side address ranges 

O 1 CharacterString 

225 sideOfStreet 

Side of a street to which this address-segment record applies. There is no implicit requirement that a matching odd-numbered side record balance an even-numbered side of the street record; both sides may contain odd- or even-numbered addresses 

M 1 CharacterString 

226 fromAddress 

Numeric value of the address that corresponds to the beginning point of the street segment. This is not necessarily the lowest address value however it can be. In a GIS each line has a beginning point and an end point. The directionality of the line is based on these points. The address range values correspond to this directionality. In Figure D.1, the fromAddress of road segment C would be 3599. In many systems, the fromAddress is broken down into both leftFromAddress and rightFromAddress 

M 1 Integer 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation – Transit Annex D (informative): Address extension to the transit model

78

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

227 toAddress 

Numeric value of the address that corresponds to the ending point of the street segment. This is not necessarily the highest address value, however it can be. In a GIS each line has a beginning point and an end point. The directionality of the line is based on these points. The address range values correspond to this directionality. In Figure D.1, the toAddress of road segment C would be 3500. In many systems the toAddress is broken down into both leftToAddress and rightToAddress 

M 1 Integer 

228 jurisdictionCity City with addressing jurisdiction for this address segment O 1 CharacterString 229 jurisdictionCounty 

County with addressing jurisdiction for this address segment. The term “county” includes parishes, townships, and similar terms, where applicable 

O 1 CharacterString 

230 jurisdictionState 

The State with addressing jurisdiction for this address segment. It is anticipated that only one of the three jurisdiction fields would be valid for any single address segment

O 1 CharacterString 

231 postalCommunity 

Name assigned by the postal authority for the general location within which the address information shall be unique. Postal community may differ from the name of the city with jurisdiction on this address segment 

O 1 CharacterString 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation – Transit Annex D (informative): Address extension to the transit model

79

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

232 postalState 

Name assigned by the postal authority for the State within which the address is located for delivery purposes. The term “State” includes provinces and similar terms, where applicable 

O 1 CharacterString 

233 postalCode 

General address location identifier used by the postal agency. In the United States, this is known as the ZIP code, and consists of five mandatory numbers and an optional “ZIP+4” extension consisting of a hyphen and four numbers 

O 1 CharacterString 

234 status Status of the address segment record O 1 CharacterString 235 Role name: address O * <<DataType>> Address 236 Address <<DataType>> 237 addressId 

Unique identifier for an address record. An address, in the context of this model, is a physical address (also known as delivery or situs address), as defined in the proposed FGDC Street Address Data Standard 

M 1 Integer 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation – Transit Annex D (informative): Address extension to the transit model

80

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

238 addressSegId 

Unique identifier for the address segment. An address segment is a portion of a named street with a continuous range of address numbers and a single combination of street name, postal community name, State, and postal code. A new address segment is created when any one of these attributes changes. Hundred-number block ranges that reset incrementally at intersections often additionally define address segments. Separate address segments may describe left and right sides of a named street 

M 1 Integer 

239 recordDate Date the record was created M 1 Date 240 addressNumber 

Portion of a street address that is not the street name, usually consisting of whole integer numbers with occasional fractional and alphabetic extensions. Address numbers generally identify an entire structure for the purposes of mail and package delivery 

M 1 Integer 

241 directionPrefix 

Cardinal direction used to differentiate one portion of a named street from another based on its displacement from a central address cross street 

O 1 CharacterString 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation – Transit Annex D (informative): Address extension to the transit model

81

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

242 typePrefix 

Means of differentiating one kind of road from another, used to make otherwise duplicative names unique 

O 1 CharacterString 

243 streetName Primary street name element, such as “Main” or “23rd M 1 CharacterString 244 typeSuffix 

Means of differentiating one kind of road from another, used to make otherwise duplicative names unique and coming after the primary street name component 

O 1 CharacterString 

245 directionSuffix 

Cardinal direction used to differentiate one portion of a named street from another based on its displacement from a central address cross street and coming after the primary street name component 

O 1 CharacterString 

246 completeName 

The full text of the street name with all applicable prefixes and suffixes, such as “N Main St.” Street names are typically decomposed in address databases into several constituent elements, expressed mainly as various prefixes and suffixes to the basic street name, as shown above. This field supports the transfer of a full street name as a single value 

O 1 CharacterString 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation – Transit Annex D (informative): Address extension to the transit model

82

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

247 unitType Type of mail delivery unit within a structure O 1 CharacterString 248 unitDesignation 

Identifier for the delivery unit, such as a letter or number that is unique within the structure(s) reached through the combination of an address number and complete street name location. May be used even when unitType is [null] in order to convey address information; for example, for duplexes identified with a letter suffix appended to the numeric address conveyed in addressNumber 

O 1 CharacterString 

249 secondLine 

Additional line for supplemental delivery address information, such as the floor on which an office is located 

O 1 CharacterString 

250 postalCommunity 

Name assigned by the postal authority for the general location within which the address information shall be unique. Postal community may differ from the name of the city with jurisdiction on this address segment 

O 1 CharacterString 

251 postalState 

Name assigned by the postal authority for the State within which the address is located for delivery purposes. The term “State” includes provinces and similar terms, where applicable 

O 1 CharacterString 
Federal Geographic Data Committee F

Geographic Information Framework Data Content Standard Part 7d: Transportation – Transit Annex D (informative): Address extension to the transit model

83

Line Name/Role Name Definition Obligation/ Condition Maximum Occurrence Data Type 

252 postalCode 

General address location identifier used by the postal agency. In the United States, this is known as the ZIP code, and consists of five mandatory numbers and an optional “ZIP+4” extension consisting of a hyphen and four numbers 

O 1 CharacterString 

253 status Status of the address segment record O 1 CharacterString 254 Role name: addSeg O 1 <<DataType>> AddressSeg 
Federal Geographic Data Committee FGDC-STD-014.7d-2008 

Geographic Information Framework Data Content Standard 

Part 7d: Transportation – Transit 

Annex E (informative): Bibliography

84

Annex E 

(informative) 

Bibliography 

The following documents contain provisions that are relevant to this part of the Framework Data 

Content Standard. Informative references applicable to two or more transportation parts only are 

listed in Annex C of the Transportation Base (Part 7). Annex D of the Base Document (Part 0) 

lists informative references applicable to two or more of the parts of the standard, including the 

transportation parts. For dated references, only the edition cited applies. For undated 

references, the latest edition of the referenced document applies. 

ANSI and ISO standards may be purchased through the ANSI eStandards Store at 

http://webstore.ansi.org/ansidocstore/default.asp, accessed October 2006. 

Federal Geographic Data Committee, Street address data standard, 

http://www.fgdc.gov/standards/projects/FGDC-standards-projects/streetaddress/index_html/?searchterm=Address%20Data%20Content%20standard, accessed October, 

(forthcoming) 

Transit Standards Consortium, 2001, Bus stop inventory best practices and recommended 

procedures 

NTCIP 1400:2000, Transit communications interface profile framework, Version 1.04, Draft 

NTCIP 1400 Amendment 1, September 2002 

NTCIP 1401:2000, Standard on common public transportation (CPT) objects, Version 1.02, Draft 

NTCIP 1401 Amendment 1, September 2002 

NTCIP 1402:2000, Standard on incident management (IM) objects, Version 1.02, Draft NTCIP 

1402 Amendment 1, September 2002 

NTCIP 1403:2000, Standard on passenger information (PI) objects, Version 1.02, Draft NTCIP 

1403 Amendment 1, September 2002 

NTCIP 1404:2000, Standard on scheduling/runcutting (SCH) objects, Version 1.02, Draft NTCIP 

1404 Amendment 1, September 2002 

NTCIP 1405:2000, Standard on spatial representation (SP) objects, Version 1.02, Draft NTCIP 

1405 Amendment 1, September 2002 

NTCIP 1406:2001, Standard on on-board (OB) objects, Version 1.02, Draft NTCIP 1406 

Amendment 1, September 2002 

NTCIP 1407:2001, Standard on Control Center (CC) objects, Version 1.02, Draft NTCIP 1407 

Amendment 1, September 2002 

U.S. Postal Service, 2000, Publication 28 – Postal addressing standards